评估与监控为什么不能分家Agent-19 的起因我在第一次接手 Agent-19 的时候心里其实不太愿意再听一遍评估和监控都很重要这种话。谁不知道重要难的是它们到底怎么在同一条业务链路上配合而不是各管一段。Agent-19 是某团队维护的一套内部智能体系统代号来自第十九次重构时的版本号它不是研究用的 Demo而是每天挂在真实工作流里跑的那种生产系统把半结构化材料整理成下游岗位需要的结果中间要调用检索接口、做条件判断、生成书面回复。听起来不算炫但这种系统恰恰最容易在看起来一切正常的过程里慢慢腐烂。当时团队的评估方式还非常传统准备一批标注好的验证样本把 Agent 跑一遍算算得分。得分稳定就认为这轮迭代可以发布。但验证样本是静态的而 Agent 是动态的。底层检索库的排序算法会变上游接口的字段格式会调提示词的措辞会被反复改写甚至用户输入的习惯都会随业务季节变化。离线评估对这堆变化完全没有感知。于是发生了我在 Agent-19 上看到的第一次严重事故某天业务人员发现系统在一个重要任务里材料缺失的情况下自己补了一段看起来合理但与事实不符的内容。回查轨迹时才看到它其实已经连续做了好几个低置信度的动作后面的每一步都在错误前提上空转但最终输出还是成功地在内部指标上正常通过。这件事让我真正开始怀疑整套评价体系的问题我们到底在评估什么如果只是一堆最终输出样本的正确率那中间的路径越黑盒评估就越失真。后来我把的精力逐步从怎么构造更多测试集转向怎么把过程信息变成可分析、可反馈、可追责的证据链。这个过程里轨迹分析是最先落地的部分监控体系是随后接上去的最后我们干脆把 Agent 的定位从内部工具改成了可问责承包商——不是字面意义上的外包合同而是从权责边界、交付标准、定期复查和退出机制这四个角度像管理一个承包方那样管理它。这篇文章我打算把这段演进整理成一条线先说轨迹分析怎么作为地基去收集过程证据再说监控怎么跟轨迹联动而不是只看输出指标接着把可问责承包商这个心智模型讲透最后聊聊执行过程中一定会遇到的几类阻力。1. 轨迹分析先把过程证据收集起来1.1 轨迹不只是日志我要先把一个常见的误解纠正过来轨迹分析不是让你多打几条日志。日志记录的是已经发生的事实而轨迹要回答的是它为什么这样做以及它当时还有哪些选择。Agent-19 的每条轨迹在设计上至少包含三个层面。第一个层面是事件流记录所有外部可见的动作调用了什么接口、传了什么参数、返回了什么结果、是否失败、失败后是重试还是放弃。这个层面的难度最低很多团队会用埋点解决。第二个层面是状态锚点也就是在每个决策点前后Agent 当时的状态摘要。我们不会直接存完整上下文因为那样成本太高而且可能涉及敏感信息而是存提示词版本号、上下文长度、关键字段的哈希摘要、模型输出的置信度这类统计信息。有了状态锚点你才能回答是不是在输入侧就已经被带偏了。第三个层面容易被忽略但也最有价值分支信息。在 Agent 做选择的那个节点不仅要记录它实际上选了哪条路还要尽量记录它考虑过哪些替代路径。这个做不到百分之百准确但哪怕是基于模型概率分布的抽样候选也会对事后复盘有巨大帮助。我在 Agent-19 上落地的事件结构大概长这样{ trace_id: tr_8f3a1c, type: decision_point, ts: 2025-06-01T10:22:31Z, context_hash: sha256:ab12..., decision: { selected: search, confidence: 0.61, alternatives: [extract, ask_user] }, payload: { tool: search, query: 更新后的客户账单状态 } }如果你不把决策点单独拆出来后面的分析基本就是在看黑盒。你可以回放事件但永远不知道 Agent 是坚定地选错了路还是犹豫半天后在两个糟糕选项里扔了硬币。这两种情况对应的修法完全不同。1.2 回放、抽检与对抗式复盘留下几千条轨迹是很简单的事服务器上堆就是了。真正有价值的是让它变成一种团队能持续投入的工作方式。我见过有些团队把轨迹导出成 JSON 文件让人工抱着文本慢慢看这坚持不了两周就会沦为摆设。我们后来做了一个轻量级的回放界面把每个事件渲染成类似聊天界面的卡片你可以在一个决策点上展开它的候选和置信度也可以查看某个工具调用前后的状态变化。界面本身没什么技术含量真正改变工作习惯的是固定节奏。我们团队有一件事坚持到了最后每周固定抽三条轨迹做对抗式复盘。所谓对抗式是刻意不挑明显出错的案例而是挑那些没出错但动作已经变形的样本。比如本来可以直接回答的问题它绕了三圈工具调用比如某个分支里置信度一路下行但最终结果碰巧正确。这类轨迹不看得分完全靠人去判断这条动作路径是否仍然合理。我把这项任务轮岗不让固定的一两个人占据话语权效果出奇地好——新加入的成员往往能问出为什么要走这里这种老手早已默认接受的关键问题而这正是路径漂移最容易漏掉的部分。1.3 轨迹数据能支撑的三类事后分析从 Agent-19 的实践来看轨迹分析至少覆盖三类明确需求不只是事后看视频。归因分析是需求最清晰的场景。一旦最终输出出问题你得能从轨迹里一步步回溯找到第一次出现错误信号的关键节点。这不是靠人肉翻日志而是靠把决策点上的置信度、上下文哈希、候选集这些字段串起来定位。比如我们后来排查过一类答非所问的问题最终输出的文本看起来完整但回溯后发现在第二步检索时查询词就被改写成了另一个业务含义后面的所有内容都在跑题。没有轨迹这个问题几乎无法定位。策略偏差分析是另一类场景。我们要统计在长时间段里Agent 在不同类型任务上的行为分布比如它是不是更喜欢调用某个接口、是不是倾向于在不该生成时强行生成了内容、是不是在面对模糊指令时过度规避。这类分析需要的是聚合数据而不是单条轨迹所以轨迹设计从一开始就要考虑可以被分组统计。成本与效率分析则更现实。异常延迟往往跟特定的决策路径绑在一起比如某类任务反复触发重试或者上下文越滚越大导致生成时间激增。从轨迹里看这类问题比看监控报表直观得多你能具体看到卡点对应哪一个决策类型然后决定是不是要给这个分支单独加约束。路径走的验证多了你才敢说评估是建立在过程证据上的。在此之前评估只是一堆数字玩具。2. 监控怎么接住轨迹里的异常2.1 把指标下沉到过程侧监控体系一开始给我的教训是只看输出指标会太晚。输出指标包括任务完成率、用户反馈分数、最终格式正确率这些它们成本低、好理解但它们有一个致命弱点——当它们开始恶化问题往往已经扩散一段时间了。干预太晚等于被动挨打。Agent 系统的监控应该至少分三层输入侧、过程侧、结果侧。输入侧观察的是上下文和触发条件比如每次请求携带的材料数量是否异常、提示词版本是否被意外切换、上游接口返回的数据格式是否波动。过程侧观察的是决策路径的特征比如单次任务的步骤数分布、工具调用失败率、重试占比、决策点置信度的移动平均。结果侧才是传统那套输出质量、耗时、下游反馈。这三个层次里过程侧最容易被忽略但它恰恰是早期异常信号最密集的地方。我在 Agent-19 上经历过一次比较典型的事故足以说明三层指标为什么需要联动。某个业务检索接口在周末升级了排序逻辑返回值格式发生了一点变化以前空结果列表是这样表示的升级后变成了包含一个错误码的空数组。Agent 没有感知到这种变化依然把所有查询都送进了原来的成功分支但后续的解析步骤全都拿不到有效内容于是它反复重试置信度一路下滑。这段时间里结果侧的输出指标居然还维持在正常范围附近因为有些任务只是绕了远路最终还是拼凑出了差不多的答案。但过程侧的工具调用失败率和低置信决策占比已经明显攀升。如果监控只在结果侧设置了红线我们就会错过几天的修复窗口。2.2 用相对阈值而不是死记绝对阈值过程侧指标有一个共同特点它们对业务周期非常敏感。同一个工具失败率月初和月末可能有完全不同的合理范围同一个置信度分布换一波输入数据也会有明显变化。所以监控阈值的设计不建议一上来就写死绝对数值而是先采集至少两到四周的基线再用与基线周期的相对偏差作为告警条件。比如决策点低置信占比这个指标我们设定的告警条件是连续十五分钟超过基线均值的百分之三十并且当前样本量达到一定最小值。为什么加样本量限制因为低流量时段偶尔的抖动会造成假阳性加了样本量下限之后告警的稳定性明显提升。工具调用失败率则更简单直接绝对阈值加持续时间比如超过百分之五并持续三分钟才触发主要想挡的是秒级抖动不打扰人长期恶化才介入。下面这张表是我后来总结的常用分层顺序是按反应速度从快到慢排的指标建议的检测方式用途决策点低置信占比与基线均值偏差超30%持续15分钟捕捉路径漂移是最早信号工具调用失败率绝对阈值超5%持续3分钟快速发现上游接口异常重试与自修复次数单轨迹内重试2次时计数发现绕路兜底行为关键字段空值率必须为0或由业务方定义容错防止结构性断裂2.3 告警疲劳的本质是缺少行动关联很多人问我为什么监控做了一堆指标最后还是没人看我的答案很直接因为每条告警都没有跟一个具体的行动按钮绑定。一个告警如果只告诉你指标偏高却不说该由谁去处理、去哪看轨迹、处理完怎样算闭环它本质上只是一个噪音源。我们的做法是给每一条告警指定一个响应路径当某类告警触发时值班的人点进去首先看到的不是仪表盘大屏而是最近十分钟内触发这个指标的轨迹列表。你不需要自己现找系统已经帮你把可疑轨迹关联好了。处理完成后必须在这个告警上回填一个结论哪怕是一句话上游字段变化导致已通知相关方。这样积累两三个月后我们手里就有了一份非常有价值的告警去重清单——哪些告警经常出现但不需要人介入哪些告警一旦出现就必须立刻处理。这个清单反过来又能帮助调低一部分告警频率让真正重要的信号浮出水面。把告警数量降下来这件事我认为应该被当成一个正式目标来看而不是顺带做做。没人愿意看的监控无论技术多先进最后都只是一堆图形。宁可少保留十条告警只要每一条被触发时都有人能迅速采取行动也比三千条红色面板天天闪烁要强。3. 从审计到问责把智能体当成外部承包商3.1 审计只是记录问责才是闭环到这一步时我们已经有了相对完整的轨迹数据和监控体系可以把发生过的每件事都翻出来。但我逐渐意识到一个尴尬的问题记录是多了反馈闭环却还没有建立。你可以精确指出 Agent 在哪一步跑偏但如果没有一个机制让这个问题被正视、被修复、甚至让系统的相应权限被调整那这堆证据很快就变成了某种形式上的存档没人继续在意。所以我把思维方式从审计转到了问责。一个企业如果请外部承包商来做一单生意不会只看它最后交的东西对不对还要看过程是否合规、有没有超出边界、是否在关键环节主动汇报。更重要的是如果承包商连续交付不合格你会终止合同而不是无限期给它机会。把 Agent 也放到同样位置我们的目光就不再局限于这轮准确率是多少而会延伸到它是否对自己的行为负责、我们能否对它的权限进行动态调整。3.2 承包商视角的四个关键要素如果要把 Agent 当作可问责承包商来管理我建议至少从四个维度建立契约。职责边界是第一项。所谓 contractor不是全能的助手而是被授予特定权限、在特定范围内工作的承担体。落到 Agent 上包括允许调用哪些接口、不允许修改哪些对象、什么情况下必须请求人工确认、什么时候可以自主决策。边界画得越清楚后面的追责才有依据。如果 Agent 什么都能做那么出问题后我们就只能对着整个系统叹气。交付定义是最核心的条款。传统测试集的通过率不是交付定义的全部。我们团队和业务方一起写每类任务的完成标准要求具体到可以被验证例如客户账单查询任务输出里必须包含账期、金额、状态三个字段金额不得对缺失字段进行推断填报再比如材料整理任务如果不能确认某个来源必须在回复中标注待确认而不是自动补全。这类规则看着朴素但真正有效因为它们把看起来合理变成了可核查的正确。绩效复核的节奏也很重要。承包商不会只在项目结束时被验收而是阶段性地看工作质量。我们后来会固定周期对 Agent 的运行情况进行复核抽检一部分轨迹把其中的问题按严重程度归档可分轻微偏差、条款违规、重大事故。进入复核流程的不只是评估团队还要有下游使用方参与否则很容易出现模型得到高分但业务部门不信任的脱节。最后是终止条款。这可能是我在整件事里认识到的最重要的一点Agent 也会被解雇。如果一个任务场景下的重复失败率超过设定底线连续几次修正后依然没有起色它就会被降级为需人工介入模式自动权限被收回。这听起来残酷但对生产系统是必需的。你让一个连续出错的员工继续独立操作大额订单风险是无法接受的。3.3 给 Agent 建一份信誉档案落到具体执行上我们给每个 Agent 角色建了一份档案记录三个方面按任务类型拆分的失败率、近期重大事故清单、以及权责条款的变更历史。每次迭代发布时这份档案会跟着更新。发布一个不达标的版本它的权限就可能缩小一步而不是默认保持原来的访问范围。这背后其实有一个很简单的观念反转模型是参数但它在业务系统里是一个承担角色。我们要让这个角色和外部承包商一样因为行为才获得相应信用而不是因为它是自研的就无限包容。组里当时有人担心这样会不会阻碍创新我的回答是创新可以在隔离实验环境里随便跑但生产系统的核心目标永远是稳定可预期。你想尝试更大胆的路径就去专门的沙箱里做那里没有合同约束一旦上了正式链路就得按承包商规则来。在一段时间之后你会发现问责机制不只是限制它也带来了一种正面变化因为有了明确的边界和验收标准Agent 的设计反而更容易被优化。开发人员不再去猜它应该多想一步还是少想一步而是直接根据契约条款来调整行为策略。模糊地带变少之后业务方也更愿意信任这个系统因为他们知道出了事有对应规则和响应路径而不是一句冷冰冰的算法原因。4. 落地评估与监控体系时的真实阻力4.1 数据权限与隐私轨迹不能裸奔先泼一盆冷水轨迹分析落到真实业务里最大的阻力往往不是技术而是数据权限。轨迹里带着上下文的内容摘要、字段哈希、甚至某些小片段的原文这些在安全审计上都非常敏感。你不能因为要做评估就无条件地把所有过程记录都堆在一起供人翻阅。我们的做法是分级存储。决策点信息里只保留脱敏状态和哈希摘要完整上下文演进版只临时存在于回放工具中并且访问需要审批审计可追溯。明文的数据默认不落盘只在个例深度调查时按需调取。这不仅是为了合规也是为了让轨迹分析团队自己省心数据越少审查成本越低。另一个经验是轨迹保留时长要跟业务协商不宜一刀切。有些场景可能需要保留九十天以上用于跨周期对比有些高频低风险场景保留三十天就足够。毫无策略地保留全部轨迹既浪费存储也让每次事故调查时面对一堆无关信息。4.2 链路成本不能忽略的采样策略每条轨迹从产生到入库都会带来额外的计算和存储开销。Agent-19 刚上线完整轨迹采集时我一度觉得系统没有明显变慢但等监控报表出来才发现轨迹写入把整体延迟平均抬高了十几个百分点存储也在飞速增长。解决路径是分层处理。实时监控只需要读取轻量指标比如置信度移动平均、失败率、步骤数分布这部分用很小比例的采样就能支撑粗粒度的轨迹流保持全量写但可以压缩后存入成本更低的离线存储真正完整的现场回放数据只在需要时保留或者按需捕获可以加一个当某告警触发时才开启详细记录的开关。我自己的经验是先算账再做全量铺开。每条轨迹按五十 KB 估算每天五万条任务就是 2.5 GB 的增量如果你没有对应的冷存储空间和半年后的归档策略还是趁早设计裁剪规则。4.3 评估组和业务组的协作谁也别甩锅还有一个经常被低估的阻力组织协作。评估团队习惯用技术指标说话业务方习惯用感受和案例说话两边如果不建立一个共同复盘机制很快会变成各说各话。A 同学觉得离线指标很好看业务反馈却一直抱怨B 同学觉得业务方提出的问题很模糊没法转成可验证的标准。我们后来的解法是固定举行联合复盘会让两边坐在同一个回放界面前面把有争议的轨迹逐条过。业务方说不清感觉不对时我们就在界面上把它指着是这一步的检索范围不合理还是它在缺失信息时自动补全了还是回复风格不符合既定模板一旦把模糊感受拆解到具体轨迹节点定义验收标准就变得容易许多。反过来评估组也能更直接地看到哪些指标在业务视角里毫无意义该删就删。这种协作不需要太多流程但需要双方都放下我来评价你的姿态改成我们一起看这单承包方的活干得怎么样。4.4 避免监控内卷最后提一个现象监控指标越堆越多但真正被使用的不超过三分之一剩下的全是为了更全面而存在的。每次事故发生后团队容易的本能反应是再加一条指标防止同类问题再发生。指标不是不能加但如果每条指标都不能明确回答它顶部的行动是什么那它就是在制造噪音。我的做法是像维护代码一样维护监控指标列表周期性做治理每一个指标都需要说清楚它在哪类告警里使用、对应哪个级别的响应、最近三个月被触发过几次。如果某个指标长期没有触发或者触发了也无人跟进就把它移除或合并。Dashboard 长得漂亮不应该是目标它的目标只有一个当出现问题时值班者能早于用户感知并且顺着它的指引在轨迹里找到证据、完成闭环。5. 从 Agent-19 里得到的一套可复用做法纵观 Agent-19 的整个演进如果让我提炼出对任何类似智能体系统都能立马上手的几个动作我会列出这几点。先建决策点的过程证据再谈评估。没有轨迹数据的人为评分等于让裁判闭着眼睛打分。哪怕初期只能用最朴素的 JSON 记录工具调用和置信度也比没有强。在此基础上把每周轨迹复盘变成一个固定日程哪怕一次只看三条也要从这条轨迹最近变得不对劲了吗这种问题出发而不是只看结果对错。监控没有准确的基线之前宁可用更粗的绝对阈值守住不发生大问题也不要虚构一个看起来精确但毫无动作关联的告警规则。引入承包商契约时先从一项最高风险的任务开始试点。找一个业务方最容易投诉、影响面最大的场景和业务方坐下来一起写出完成标准和终止条件再逐步推广。相比一开始就铺到整个系统这个试点方式更容易取得共识别人也能从中看到效果。数据权限和成本问题不要等到铺开了才处理首日就要想清楚哪些字段能存哪些只存哈希哪些需要分级访问。轨迹不是拿来堆的而是用来在关键时刻还原真相的。我在 Agent-19 上最大的一点体会是做评估和监控不是为了把系统钉在一个安全框里而是为了让使用它的人拥有一份清晰的确定性。知道它的边界在哪、它的交付标准是什么、出问题时谁能依据过程证据快速定位这套能力比任何单独的高分测试集都更有价值。如果你现在还在为评估分数不错但业务总出问题发愁我建议你先别急着加测试集去把已经发生的轨迹找出来挑三条最近看起来别扭的约上业务方一起过一遍。先让过程证据在团队里流动起来很多问题的答案会自然浮现。