本文来自微信公众号： AIGC从0到1 ，作者：王零壹，题图来自：AI生成
最近看各家Agent平台的更新，我注意到一个很一致的动作。
4月，Google发布Gemini Enterprise Agent Platform，把模拟、评测和可观测性放进了Agent的“优化”层。5月的Microsoft Build上，Foundry展示了多轮评测、生产轨迹抽样、轨迹回放和由轨迹生成测试集。7月，Grafana把Agent Observability推到通用可用，还把agent session称作指标、日志、链路追踪、性能剖面之外的第五类遥测信号。
这些产品原本不在一条起跑线上。Google在做云上的Agent平台，微软想把Agent开发和运维收进Foundry，Grafana则来自传统可观测性世界。但它们最近都在补一件看上去不太显眼的事：给Agent装质检线。
原因也不难理解。Agent已经不满足于聊天框里给个答案了。它开始进CRM、工单、支付、代码库和内部系统，替人跑一段段实际流程。到了这个阶段，“它会不会做”还只是第一问。更难的那一问是：它做完这件事，到底算不算做对？
企业真正担心的，往往不是模型突然胡说八道，而是另一种更安静的失败。
它替销售更新了CRM，字段写到了另一个客户身上；它说退款已处理，实际上只完成了查询；它说代码修好了，测试过了，但线上权限被一并改坏了。更麻烦的是，今天的版本看起来没有问题，下周换一个模型、改一句系统提示词、接入一个新工具，行为就可能慢慢变样。
这就是为什么现在要谈Eval和Observability。它们是Agent真正开始干正事后，迟早要补上的一课。
一、系统没报错，事仍可能办错
传统软件出问题，通常有迹可循：接口报错、服务超时、数据库连不上、CPU被打满。运维系统盯住日志、指标和调用链，至少能回答“哪里坏了”。
Agent不一样。它可以在所有技术指标都正常时，把业务办错。
举个很常见的例子。一个差旅Agent接到指令，为某位员工订明天去上海的机票。它理解了请求，查到了航班，调用订票接口时返回200，最后在聊天框里写下“已完成预订”。从传统监控看，这次任务很健康。
但它可能订成了后天，填错了乘机人，或者只拿到了报价，根本没有生成订单。
系统没有崩，用户却会在机场发现自己白忙了一场。
这也是Agent和聊天机器人的差别。聊天机器人说错一句话，用户通常看得见，也能马上纠正。Agent一旦有了支付、修改数据、发邮件、部署代码的权限，它的错误会直接落到真实世界里。很多时候，最危险的不是一眼就能看出来的荒唐操作，而是一次看起来顺顺当当的“已完成”。
今年4月，Anthropic对Claude Code一次质量问题的公开复盘，很能说明这种复杂性。用户持续感觉Claude Code变笨了：容易忘事、重复、工具选得奇怪。后来查下来，模型本身没有被降级，问题出在产品层的几处变化叠在一起：默认推理强度被调低，一次上下文清理优化有bug，为减少冗长加入的系统提示词也伤到了编程质量。
Anthropic承认，内部使用和既有评测一开始都没有复现用户指出的问题。
这件事并不说明评测没用。它说明今天一个Agent的表现，早就不是模型分数的简单投影。提示词、上下文管理、缓存、记忆、工具描述、权限、检索、路由、Harness和运行环境，都会改变最终体验。
模型跑分可以告诉你哪个模型更有能力，却回答不了另一个更实际的问题：眼前这个版本的Agent，在这套系统和这批真实用户里，是否还在把事办对。
二、Eval和Observability，管的不是一回事
先把这两个词说得简单一点。
可观测性管的是“刚才发生了什么”。一次执行里，用户提了什么要求，Agent调了哪些工具，参数怎么填的，在哪一步重试，耗了多少时间和成本，最后改了哪些状态，都应该留下记录。工程里把这叫trace，或者执行轨迹。
它更像一份执行回放：系统能证明的输入、调用、状态变化和输出，都留在里面，方便排查，也方便审计。
Eval管的是“这次算不算做对”。退款是否真的到账，工单有没有真正关闭，代码是否通过测试，用户明确要求转人工时有没有转，敏感信息是否泄露，Agent有没有调用本不该碰的高风险工具。这些都属于评测。
两件事很容易被混在一起，其实各有用处。
没有轨迹，团队知道一次任务失败了，也很难找到问题出在模型、工具、上下文还是权限。只有轨迹也不行。你可能存下了几十万条执行记录，却说不清哪一条只是绕了点路，哪一条已经是事故。
微软在Foundry的表述很准确：轨迹回答发生了什么，评测判断好不好，优化决定下一步改哪里。
以前做Agent，很多团队的工作方式都差不多：用户投诉，开发者翻翻对话记录，改一行提示词，再发个版本试试。规模小时，这种方式还跑得动。Agent一旦要处理成百上千种任务，问题就来了。它不是每次只回答一段文字，而是要连续做判断、查资料、调用工具、改写环境。
前面一步偏了，后面几步往往会跟着偏。一次检索失准，可能带来错误的工具选择，错误的状态更新，再被模型当成新的事实继续往下推。
如果一个任务有十个关键步骤，每一步成功率都是95%，十步全部正确的概率也只剩六成左右。真实场景当然比这个算式复杂得多，错误也不会彼此独立，但它足够说明一件事：单看最后一段回答，已经不够。
现在的Agent Eval开始同时看结果和过程。
结果要优先。用户并不在意Agent有没有说“已完成”，在意的是订单、工单、文件、数据库和权限系统里，是否真的出现了正确状态。
过程也不能不看。一个Agent即使最后退成了钱，若跳过身份验证、泄露了另一位客户的信息，或者为了完成任务反复调用收费工具几十次，这次执行也谈不上合格。
三、质检线不是加一个面板就有了
这轮产品更新里，很多平台开始试着把下面这条链路接起来：
`真实执行->留下轨迹->找到失败->归类原因->变成测试样本->修改系统->回归验证->小流量上线->继续观察`
微软提出“把生产轨迹转成评测数据集”，很能代表这个方向。
过去的测试集，大多由团队在会议室里设计：列出一些常见问题，写好预期答案，再看模型能否通过。这当然需要做，但它总会漏掉现实。真实用户的表达方式很杂，权限和工具一叠加，边缘情况往往也比产品经理预先想象的多得多。
生产环境里出现过的失败，反而是最值得留下来的题目。
比如，有客户连续三次要求转人工，Agent仍在安慰和解释；某类历史订单一查就让工具参数错位；合规审查在长对话之后悄悄丢掉了一条关键限制。问题查清后，不该只在工单里关掉。它们应该被清理、脱敏、标注，放进下一版Agent的回归测试里。
这样做没有多玄妙。修过一次的错误，别让它换个用户再犯一遍。
这件事和软件工程里的测试、持续集成很像，只是Agent多了一个会波动的模型，还会遇到多轮对话、外部工具和不断变化的环境，事情更难控。
所以，一条靠谱的质检线，不会只靠一种裁判。
订单有没有生成、金额是否正确、数据库状态是否更新、权限有没有越界、代码能不能通过测试，这类问题能用规则、接口和测试脚本确认，就别再让另一个模型去猜。
LLM更适合处理开放性的判断：这段回复是否准确，解释是否完整，客服有没有真正理解投诉，研究报告是不是有依据。它能看懂语境，也会波动，成本也不低。因此，人仍然要在场，尤其是高风险样本、裁判意见分歧大的样本，以及一开始就说不清业务标准的地方。
人不可能逐条检查海量对话。更现实的做法，是让系统先把新的失败类型、重要客户和高风险动作挑出来，人再去看最值得看的部分。
四、评测逼着企业讲清楚：什么算做好
很多人以为Eval是工程团队的活。其实它先是产品和业务的活。
因为一旦决定给Agent建评测，就得把那些平时说得很顺的要求重新说清楚。
“让客服更有帮助”，到底是什么意思？问题被解决才算，还是先把用户安抚住也算？什么时候该继续回答，什么时候必须转人工？“让销售更懂客户”，是多给推荐，还是别把A客户的资料写进B客户记录？“让研究Agent输出高质量报告”，是字数更多，还是关键结论都能追到可靠来源？
人类员工遇到模糊处，会追问、协商，也会用经验补全。Agent同样会补全，只是它补出来的未必是企业真正想要的答案。
于是，评测有一个常被忽略的作用：它迫使组织把资深员工脑子里的验收标准写出来。哪些结果必须达到，哪些操作绝对不能做，哪些情况必须升级，什么样的成本可以接受，这些过去散在流程、会议和个人经验里的东西，开始被变成一条条可检查的规则。
这也是垂直场景的Eval会越来越值钱的原因。
通用模型可以换，编排框架也可以换。一家金融机构如何判断合规，一家电商如何认定售后真正解决，一家软件公司如何定义“修复完成”，却都藏在长期的业务细节里。失败样本、验收规则和真实结果数据积累起来，才会形成更难复制的东西。
大厂当然也看到了这一层。Google想把构建、运行、治理和优化收进Agent Platform；微软希望将轨迹、评测、监控、优化和ROI放进Foundry；Grafana的逻辑不同，它本来就握着企业的监控体系，现在把Agent当成一种需要接入同一套遥测系统的新工作负载。
表面上，它们在争开发者会在哪个控制台里看数据。再往下看，争的是企业把“什么算一次可靠交付”的标准，交给谁来保存、计算和执行。
这也是OpenTelemetry一类开放标准开始变重要的原因。模型调用、工具调用、token消耗、会话和状态变化，能否用比较通用的语义记录下来，决定了企业将来换模型、换框架、换平台时，能不能把自己的运行经验带走。标准远没有尘埃落定，但平台锁定和互操作之间的拉扯已经开始了。
五、一个高分，不等于事情已经清楚
给Agent打分，很容易让人放心。仪表盘上写着92分，看上去问题已经有了答案。
现实没这么省事。
题目可能写得不够清楚，运行环境可能不稳定，评分器可能检查错了东西。Anthropic在评测实践里提醒过：当前沿模型在大量尝试中总是拿零分，很多时候该先检查任务和评分器，而不是马上断言模型不会做。反过来，一套过于讨巧的测试，也会把系统的能力吹得很高。
还有一点尤其容易被忽略：别把“正确路径”写死。
一个开放任务，只要最后结果正确，没有碰安全和权限红线，Agent找到的路径未必需要和人类预先想的一样。把工具调用顺序规定得过细，可能会把更快、更省甚至更好的方案判错。
过程评测该严格的地方，是安全、合规、权限、成本和那些不可逆的高风险动作。至于很多开放性的工作，最终业务结果仍然应该排在前面。
可观测性本身也有代价。轨迹里会有用户输入、内部文档、客户资料、工具参数和业务状态。企业不能一边要求完整回放，一边不管谁能看、保存多久、哪些字段必须脱敏、什么情况下能导出。追踪系统也属于权限系统的一部分。
成本同样绕不过去。把每一次线上执行都交给另一个模型重新打分，既贵，也未必值得。生产轨迹抽样之所以会成为一个产品能力，就是因为团队需要在“什么也看不见”和“每条都检查到破产”之间，找到一个能持续运行的办法。
六、最后留给用户的，不该是一串trace
这些后台能力，最终不该以一串复杂的trace出现在普通用户眼前。
更好的产品体验，可能是一张清楚的行动回执：我理解了什么，准备做什么，已经调用了哪些系统，哪些关键动作完成了，哪里需要你确认，出问题后能回到哪里。
用户未必关心token、span或rubric。他只会问：你替我做了什么，我能不能相信。
过去，AI产品主要在争谁的回答更聪明。Agent开始接管实际任务后，竞争多了一条更难的线：谁的行动更可见，结果更可验收，出了错也更容易被纠正。
这不意味着Agent必须变成永远不犯错的机器。那种承诺既不现实，也没有必要。真正能进企业核心流程的Agent，应该知道什么能自己做，什么地方该停下来；系统也该知道它做过什么，并把一次已经发生的错误，变成下一次上线前必须重新检查的案例。
Agent已经开始干正事。接下来该补上的，是一条真正能工作的质检线。