企业 AI Agent 的赛道正在快速升温。最近柏林一家名为 Telli 的创业公司拿到 1500 万美元融资目标就是扩展企业级 AI Agents。这类消息背后真正值得关注的不是“谁拿了多少钱”而是“企业 Agent 到底卡在哪里”。过去一段时间我接触过不少想把 Agent 接入业务系统的团队发现一个很普遍的现象概念 Demo 很好跑模型也能聊但真到企业内部环境第一步就会被“评估”卡住。不是模型能力不够而是你根本说不清楚 Agent 干得好不好、稳不稳、能不能上线。这篇文章就围绕企业 AI Agent 的“评估”和“规模化落地”拆开聊。适合正在推动 Agent 进入生产环境的开发者、技术负责人、架构师也适合刚接触 Agent、但对“怎么验收”没有章法的团队。先给结论企业 Agent 能不能上线不取决于它能完成多复杂的任务而取决于你有没有一套可重复、可监控、可回归的评估体系。下面按实际落地顺序拆一遍。1. 融资消息背后企业 AI Agent 真正的分水岭在评估环节1.1 先理解这类融资为什么都盯着“企业 Agent”这个方向个人助手类 Agent 大家已经见多了但企业级 Agent 是另一套逻辑。它的核心不是“陪人聊天”而是“完成业务动作”。比如根据工单内容自动生成处理建议从数据库里把经营数据拉出来整理成报告或者把合同里的关键条款和风险点提取出来供法务复核。Telli 这轮融资的方向也是这个逻辑。公开信息没有披露太多产品细节但从赛道来看它做的一定不是通用聊天机器人而是能嵌入企业工作流、承担具体任务的 AI Agent。这也是我判断“评估才是分水岭”的原因企业场景里的 Agent交付的不是一句“看起来有道理”的回复而是一个能被业务方验收的结果。如果这个结果无法被度量Agent 项目就会变成一场演示型工程——演示效果好上线却没人敢用。不少团队在立项初期特别关注模型推理能力、上下文长度、工具调用数量这些当然重要但它们不能作为上线标准。真正决定 Agent 能否进生产环境的是能不能稳定处理业务数据集里的常见任务并且在出问题时能被及时发现。1.2 企业环境和实验室 Demo 的差距到底在哪里实验室里跑 Agent输入通常干净、任务边界明确、失败重来一次也无所谓。企业环境完全不是这样。第一输入不稳定。用户提交的工单可能夹杂错别字、口语表达、多国语言甚至截图和附件。数据查询类任务里同一张表在不同业务线可能命名完全不同。如果 Agent 的评估只在标准数据集上做它根本覆盖不了真实输入分布。第二动作有后果。实验室里 Agent 调用一个假工具失败也没影响。企业里 Agent 如果调用了错误接口、写入了错误字段、向客户发送了错误回复影响就是实际的业务事故。所以评估不能只看“回答对不对”还要看“动作是否安全”。第三责任边界模糊。传统软件行为可预期出问题可以按代码逻辑定位。Agent 有随机性同样输入跑两次可能输出不同结果。没有评估基线你就没法区分这是模型正常波动还是回归缺陷。这意味着评估不是上线前的临时测试而是一个贯穿开发、测试、灰度、线上监控的持续过程。也只有理解了这一点后面搭建评估流程才不会跑偏。2. 拆开“Agent Evals”不是给模型打分是给任务链路做体检2.1 一句话说清 Evals 是什么Evals直译过来是“评估”在 AI Agent 语境下指的不是期末考式的一次性测评而是用一组任务样本和判定标准去检查 Agent 在不同条件下是否按预期工作。我比较喜欢用一个类比传统软件的测试是验证“输入-输出”是否符合预期Agent 的 Evals 更像是给一条自动化产线做巡检。产线上有多个工位模型理解任务、解析输入、选择工具、执行工具、生成答案。任何一个工位出问题整体结果都会异常。Evals 要做的就是把这条链路拆开逐段验证而不仅仅盯最后出口。所以不要把 Evals 理解成“用几个 Prompt 问模型几道题”。它不是简单的大模型选择题测评。它需要覆盖真实业务任务、需要定义判定标准、需要纳入工具执行结果还需要支持多次运行去观察稳定性。2.2 评估维度拆开看完成率、过程、稳定性、成本我给企业 Agent 做评估时会至少分四个维度看缺一个都不够完整。任务完成率。这是最基础的指标。准备一组代表真实业务的任务样本运行 Agent统计有多少任务达到预期结果。注意这里要有代表性不能几个样例就下结论。业务方可能遇到的输入类型、事件类型都要覆盖。过程正确率。结果对了过程不一定对。比如一个数据分析 Agent 最后给出了一个正确的汇总数字但调用的是另一个业务月份的数据库那结果没报错逻辑上是错的。所以评估时必须记录 Agent 选择了什么工具、传入了什么参数、中间做了哪些推理步骤。过程正确率的判定要能抓住这种“结果对但路径错”的情况。稳定性。Agent 有随机性同一个词面含义的输入多次运行可能得到不同结果。做评估时不能只跑一轮至少同一批测试样本跑 3 到 5 轮观察成功率波动、输出格式是否一致、关键信息是否漏项。如果波动很大说明 Prompt 或流程设计存在问题上线前需要处理。成本与耗时。Agent 的多步推理会反复调用大模型接口一次任务可能几千个 token。评估时如果不记录 token 消耗和响应耗时后面规模化就会很被动。成本不是单独压下来的是通过优化评估流程、减少无效工具调用、合并步骤等方式实现的。所以先把基线的 token 数和耗时记录好后面优化才有对比。2.3 为什么“人工看一眼”会漏掉大量问题有些团队早期推行 Agent 时喜欢靠人工抽查结果。拉一个表格让业务方看一眼打钩或者打叉。在小规模验证阶段这样做问题不大一旦任务量超过几百条问题就很明显。人工评估首先是不可重复。不同的人对同一结果可能有不同判断同一个人过了两天也可能改变标准。其次是无法回归。你改了一版 Prompt想确认有没有引入新问题人工抽查往往只能看最近几条覆盖不了全量。再次是效率太低。企业 Agent 的评估需要持续进行每次业务规则调整都要重新跑一遍靠人去刷根本刷不动。所以更稳妥的做法是用一组带判定标准的测试集配合自动化的评分脚本和日志记录先建立“机器跑分 人工抽检”的双层机制。机器能自动判断的指标就让机器判断机器判断不了的复杂语义质量再抽人工复核。这样才可持续。3. 搭建最小评估基线一个可以照做的流程3.1 先收集真实任务而不是先写框架很多团队做 Agent Evals 的失败不是评估工具不行而是测试集不行。测试集如果不来自真实业务评估结果就是自嗨。所以第一步放下框架先收集任务。任务收集可以做三件事从历史工单、客户记录、业务日志里抽样选取 20 到 50 条有代表性的输入。找业务方一起确认这些输入目前是怎么处理的标准输出长什么样。额外收集一批边界情况输入为空、信息缺失、表达不完整、需要多轮确认、工具返回异常等。20 到 50 条对这个阶段来说就够了。目的是快速跑通“评估闭环”不是做全面测评。等流程稳定了再逐步扩充到几百条、几千条形成完整回归集。这一步最容易被忽略的是业务方参与。如果测试集只由研发团队自己构造往往会漏掉业务里真正复杂、真正让系统犯迷糊的场景。所以无论如何至少让业务方参与任务筛选和标准定义。3.2 定义通过标准不是每个任务都有唯一正确答案测试集有了接下来是判定标准。这里最怕的是把标准定成“答案必须和参考答案完全一致”。Agent 场景里很多任务的正确表达不是唯一的。比如客服场景Agent 判断“用户是否要退款”它给出的解释措辞可以不同但行为结论应该一致数据查询场景数字要准确但报告措辞可以有差异。所以定义通过标准时要先区分任务的类型确定性任务结果有明确对错比如“从数据库查询本月销售额”。这类任务可以用程序精确校验数字或字段。语义任务表达不唯一但意图和关键点要对。比如“总结客户投诉的核心诉求”。这类任务可以由代码判断关键实体是否出现也可以配合人工抽检。链路任务需要多步操作才能完成。比如“读取合同附件并提取风险条款”。这类任务要看最终结果也要看中间步骤是否正确不能只看一句话结论。通过标准要写成可被执行的检查项而不是抽象描述。例如不要写“回答合理”而要写“回答包含订单号、退换货类型、时间信息和处理建议”。3.3 从单条到批量固定随机种子、日志、回归对比测试集和判定标准准备好之后就可以搭建最小评估流程。我建议按这几个步骤推进先单条跑。选一条任务看 Agent 的完整行为确认输入解析正常工具调用正确输出能被判定脚本识别。再小批量跑。比如 10 条任务跑一轮观察有没有崩溃、卡死、超时、格式错乱。引入日志。记录每轮运行的输入、模型输出、工具调用参数、耗时、token 数。没有日志评估就变成黑盒后面没法排错。跑回归基线。把 20 到 50 条测试集定为基线每次调整 Prompt、更换模型、修改工具定义后都跑一遍并与上一次结果对比。这里要注意一个细节如果使用的大模型服务不支持固定随机种子可以在日志里记录模型版本和主要参数。观察结果时不要依赖单次差异要看多次运行的统计结果。注意不要一上来就开最大并发。先用单条任务验证输入、输出和日志都正常再逐步提高批量数。企业 Agent 的评估不是压测核心目标是识别业务逻辑问题而不是把资源耗尽。4. 从评估到规模化部署生产环境不能只靠一次评测结果4.1 并发、限流和队列先把资源变化跑出来测试集跑通了不代表可以立刻上线。生产环境里一定有并发请求可能有多个业务方同时使用 Agent也可能有外部 API 调用限制。所以规模化部署前要做一轮资源侧的验证。我一般会先做三件事确定单任务的资源上限。跑一条普通任务需要多少 token、多少耗时、多少显存或内存。先摸清底线。跑小规模并发。比如从 5 并发开始逐步增加到 20、50观察响应时间、失败率、资源占用。特别注意外部模型接口的限流和超时。引入队列和重试。生产环境不能因为偶发超时就直接失败。要把任务放进队列按优先级或顺序处理并设计合理的重试和熔断机制。不要跳过这一步直接压满并发。Agent 任务不是简单的单次请求它内部可能涉及多轮模型调用资源消耗会成倍放大。你以为 50 并发没问题实际可能在第一个环节就触达接口限流。4.2 可观测性让 Agent 的每一步都留下记录传统服务部署只要记录请求日志、错误堆栈、响应时间就能排查大部分问题。Agent 不一样它内部有复杂的推理链路。如果日志只记录“用户输入”和“最终输出”中间发生了什么就是黑盒。出问题时你根本没法定位是模型理解错了、工具参数传错了还是输出解析失败。所以规模化部署阶段必须给 Agent 增加可观测性。至少包含以下几类记录每一次大模型调用的输入和输出。选择并执行了哪个工具传入了哪些参数工具返回了什么结果。Agent 内部完成了哪些中间推理比如重写了用户输入、拆分了子任务。每一步的耗时、token 数、是否重试。最终输出是否通过格式校验、是否触发告警。有了这些记录你才能在评估和生产之间建立同一个可对照的基准。线上出问题后把日志里的失败样本抽出来加入回归测试集再离线复现这是 Agent 工程化里非常重要的闭环。4.3 失败重试和人工兜底生产环境必须设计的边界Agent 不可能永远成功。不管测试集上跑得多好真实环境总会出现模型突然抽风、工具返回异常、外部服务超时这样的情况。所以生产设计里必须明确失败之后怎么办。我的建议是分三层兜底第一层是重试。瞬时网络超时、接口限流这类问题重试通常就能解决。但重试要设置次数上限并且做退避避免雪崩。第二层是降级。大模型不可用时是不是可以先返回默认模板、缓存的最近答案或者把任务转给人工处理。降级方案要提前设计而不是等故障发生后临时写。第三层是人工兜底。某些高风险任务比如对外发送回复、写数据库、生成合同条款不应该完全交给 Agent 自动执行建议设计成“Agent 生成建议 人工确认”的模式。这一步很关键。它会降低自动化比例但能显著降低出事概率。在生产链路里Agent 的价值不一定非是“全自动完成”。把它定位成“高效生成并按需确认”的助手反而更容易落地。4.4 权限和安全Agent 能访问什么必须显式声明企业 Agent 一定会涉及系统权限问题。一个能查询数据的 Agent如果权限范围定得太宽就可能在错误条件下读取敏感数据一个能调用业务接口的 Agent如果没有做参数校验就可能写入脏数据。这个环节我建议按最小权限原则设计。Agent 能调用的工具、能访问的数据表、能读取的文档目录都要做显式声明不能让它“尽力而为”。具体落地时可以做这么几件事给工具调用增加白名单Agent 只能调用预先注册过的接口。在工具层面对传入参数做校验不能直接透传给下游系统。对高危操作设置确认标志没有用户确认就拒绝执行。对 Agent 访问的文件和数据库账号单独分配并限定范围不共用高权限账号。这些不是评估指标但它们是规模化落地的底座。如果权限设计不到位Agent 的“聪明”本身就会变成风险。5. 企业 Agent 实战中的坑点与排查建议5.1 在普通硬件、外部 API 和私有数据约束下怎么跑在实际落地时很大一部分团队并不会从零开始微调大模型而是基于成熟的大模型 API 或开源模型做 Agent。环境约束往往来自三方面算力资源、外部接口限制、数据安全边界。如果机器配置不是特别高建议先把任务粒度拆小。不要让 Agent 一次处理超长文档或超多步骤而是拆分成“读取-提取-汇总-生成”多个子任务。每步单独评估单独计时这样定位性能问题也容易。即便是低配环境只要能控制好输入长度和并发数也能跑通不少场景。如果依赖外部模型 API必须提前确认两件事接口的并发上限和超时设置。很多 Agent 不稳定的问题根源不是 Prompt 写得不好而是外层服务超时设得太短模型还没来得及返回就断掉了。遇到“偶发失败”时先查超时和限流。数据安全方面如果企业内部数据不能出内网那就要优先考虑私有化部署或使用本地模型。这不是技术难题而是选型问题。很多项目前期都在模型效果上纠结到验收时才发现数据合规过不了返工成本很高。建议一开始就把数据边界写清楚再选模型方案。5.2 常见误区输出为空、答案飘、工具调用失败先查什么我在踩过不少坑之后整理了一个比较实用的排查顺序。遇到 Agent 表现异常时不要急着改 Prompt先按下面顺序走输出为空。先看是不是输入解析失败或者输出格式校验把结果过滤掉了。往往不是模型没生成而是解析代码容错太差。答案明显不对。先看是不是工具调用传参错误或者检索到了错误的数据片段。再查用户输入的意图理解是否正确。这两个环节的概率比模型本身乱说高得多。工具调用失败。先确认工具定义是否明确参数名称是否跟 Agent 使用的语言一致。再查接口超时、权限、返回格式。很多时候 Tool Schema 写得不清楚模型是对的是定义没传明白。结果时好时坏。先观察是不是输入本身存在歧义再看模型版本是否变化最后查日志里超时和重试的情况。时好时坏通常不是单一原因需要按状态分布看数据。排查的关键是日志。如果某个 Agent 项目上线后才发现无法定位问题说明前面可观测性的设计就没有做到位需要回补。5.3 给团队的推进建议小步快跑、先稳定再扩展最后给团队推进层面的经验这块我相信所有踩过 Agent 坑的人都能共鸣。第一不要一开始就追求“全流程自动化”。把 Agent 定位在“辅助人完成工作”的位置上先把一条业务链路跑稳再扩展到更多场景。Telli 这类公司从融资角度看可以做很大但对普通技术团队来说Agent 落地最忌摊大饼。第二评估集要持续维护。每次上线新功能、改 Prompt、换模型都要回来跑一遍回归集。要像维护单元测试一样维护 Evals 数据集。业务规则变了测试集也要跟着更新否则评估结果会逐渐失真。第三让业务方参与验收。Agent 的输出最终是给业务用的。如果业务方没有参与任务定义和结果验收Agent 就算技术上稳定也很难真正被用起来。所以从一开始就组一个“研发 业务 评估”的小团队比后期强行推广效果好很多。第四控制期望。模型能力在提升但企业 Agent 的成熟还需要一段时间。把目标定成“每季度提升成功率 5 个百分点”“减少人工复核比例多少百分比”这类可量化指标比抽象地追求“自动化”踏实得多。写在最后回到 Telli 这轮融资以及整个企业 AI Agent 赛道我最想表达的判断其实很简单钱进来了说明方向被认可但真正拉开团队差距的不是谁的模型更强而是谁能把评估、回归、监控、权限这些工程底座做扎实。如果你所在团队正准备把 Agent 推进生产环境我建议从今天开始做三件事收集真实业务任务建立一套最小判定标准给 Agent 加上完整日志。先把这三件事跑通再谈模型升级和规模扩展。踩过几次之后你会发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。Agent 项目的复杂度不在“智能”两个字上而在把它变成可靠工具的过程里。