读完一堆 Agent 实践之后，我改了个问法

这两年 Agent 的实践文章我攒了三十多篇，腾讯技术工程、高德、小米零售、阿里那几篇都读过，论文也翻了几篇。读完最大的感受不是谁做得更好 —— 是这些人踩的坑长得差不多，只不过每篇只讲自己那一块，你读完只知道他那一块踩过什么，不知道整套问下来哪一块最空。

所以我后来换了个问法：不问这个 Agent 聪明不聪明，问它在哪一件事上最容易露馅。归下来四种，这四种在我读过的每一篇里都能找到影子。每一节我都配一个具体数字，数字是哪家的就写在那一节里，不藏着。

读法上我有个笨办法：不按主题读，按出事场景读。哪篇讲「上线之后炸了」的，就把它的前后测和指标口径抄下来；哪篇讲「成本降了」的，只看它的账单拆到哪一层。读完三十多篇翻来覆去就是那几种场景 —— 好办就好办在，同一个人写十篇也是那十几种，写成文章之后看着像十套方案。

评测集怎么铺也有讲究：50 到 200 条高质量 golden case 覆盖核心路径和高风险边界，跑稳之后再扩分类采样集、长尾集、对抗集、线上回流集。随机抽样凑不出这个覆盖 —— 线上绝大多数是正常样本，随机抽一千条也碰不到决定事故率的那些边界。

演示能跑通，真实流量过不了#

这一类被写的最多。小米零售那篇 AI 问数实践里，一次评测放了 18 个指标、122 条用例，中间层返回的结构化查询构造准确率 93.2%，这一层判的是查询构造得对不对；另建 44 条专项用例复测，专门盯同一根因，构造准确率还是 93.2%，最终答案准确率 100%（44/44）。两个数字都真实，说的是两件事 —— 一个查询有没有构造对，一个用户实际拿到什么。

17 条失败里 8 条来自同一个根因，时间字段和偏移规则分了两套口径，占掉将近一半。这条我记下来了：按原题逐条修 Prompt，能把这 8 条修到通过、看板立刻变绿，却只覆盖这 8 条；按根因聚类补专项用例，修的是一整类。看板变绿和系统在变好是两件事。

上线之后那组数更值得看：服务 1000 多名店长，渗透率 88.8%（活跃店长里用过问数的比例），同期沉淀约 1.6 万条真人对话，满意度 4.32 分（满分 5 分）。离线评测通过而线上关键指标恶化是真实存在的，所以腾讯 SRE 那条错误码排查线上给过一组可比的数量级：同一批 50 条 case，判定与人工的一致率从 33÷50 提到 44÷50，硬冲突从 10÷50 降到 0，两个分母都是这 50 条。

阿里那篇把 Skill 做成可评测之后，新增一个用例只要改一份声明式配置，公共部分和单用例部分分开写，单用例只声明输入、断言和判定方式。脚手架太贵的评测，跑两次就没人愿意再跑。腾讯 SRE 那条线上还有个做法我记得很清楚：规则层先粗筛，把明显通过、明显失败、存疑三类分开，只把存疑的交给模型精判，高风险和低置信的直接走人工。精判的时候 Judge 读的是 Trace 里的事实，不读最终回复 —— 判断这一次工具到底有没有被调用、入参是什么、返回是什么。从回答文本里推断调用过没有，那是在猜。

我读完能带走的一条很朴素：一个评测范围只留一个主指标，其余降级成诊断维度。几个指标一起做 AND，一个格式问题就能否定一个内容完全正确的用例；一起做 OR，几乎什么都能通过。

还有一条我数着读出来的：这三十多篇里把指标口径写清楚的只有一半左右。写清楚的那些，前后测和算式都在；没写的那些只会说「降了 50%」，而这个 50% 往往是分项降幅代入分布反推出来的，不是端到端 A/B。同样一句降幅，可信度差一档，所以我后来读文章先看它有没有给分母。

答得通顺，依据全是猜的#

高德本地生活那篇 AI Native 实践里，批量交付时引用来源从 731 条收敛到 179 条，口径是一次返修实际携带的引用条数；同时把共享引用压平，最大引用深度从 13 层降到 4 层，指的是一条引用最多还能往下追几层。两项压下去之后，批量效率约为人工的 22 倍 —— 这个 22 倍是他们自己折算的，分母是人工单单元约 1 小时乘一轮约 22 个业务单元。

同一件事在成本这一侧看得更清楚。腾讯技术工程那篇把账单拆得很细：主 Agent 端到端 token 从 708,783 降到 315,266，降幅 55.5%，算式是差值 393,517 除以 708,783；单轮输入从 1,030,000 降到 634,905，降幅 38.4%，算式是差值 395,095 除以 1,030,000。降幅不在首次调用上，在后面几十轮不再重复携带原始数据。轮次从 17 降到 9，省的是链路里原本多余的往返。这组数不是我的账单，是他们那篇里的，我照它的口径复述了一遍。

高德那篇里还有一句我抄下来了：只用来判断「有没有数据」的返回值，摘要成一句结论就够；后面还要逐条处理的，反而要付两次钱，一次压缩，一次重新取。判断该不该摘要只看一件事 —— 它后面还要用上几次。

同一篇里还有一组更细的账：装 20 个 Skill，初始化那一次只放进来 1000 到 2000 token，约为单体式提示词的一到两成，比全量常驻少约 90%；长期记忆先读几十行的 INDEX，再按相关度取命中条目读正文，记忆的价钱就跟文档总数脱钩了。另一篇讲后端知识库体系的长文把知识分成业务层、架构层、系统层、基建层四层，切的理由跟这里一样 —— 读写的人不同，更新节奏也不同，混在一层里治理方式自己先打架。

工具清单那块也一样：角色专属的工具白名单是一举两得的，一个只做数据分析的 Agent 不需要看到写库和删除的接口，挂 40 个工具的 MCP Server 光工具定义每轮就 10 到 15KB。工具数是安全和成本同一个动作。

所以我的问法落在两处：这次推理必须知道的东西，每一样答得出从哪取、取不到怎么办；这一轮做完之后，凭什么说它完成了。前一句管的是依据，后一句管的是证据，两句话拆开问比合成一句有用得多。

什么都答应，做不出来也不报错#

能力边界这一块，只有干过的人才知道文档上写一句没用。我在数象那套投关问答上碰过一次：给字段加了「只能新增、不能改语义」的规矩，写进规范文档，Agent 照样改历史字段，文档一个字没提校验。后来补了三样才闭环 —— 一个 schema 校验脚本、一条回归用例、一个灰度开关。规矩没变，只是从一句话变成了三个能跑的东西。

这件事后来在别人的文章里反复出现，我才敢把它当成一条通例：约束写得再对，落不到一个会红的地方就等于没写。落地的写法得指到东西上，哪个校验脚本会拦、哪条单测会红、哪个接口会返回错误。

阿里那篇架构师 Agent 给过一个能用的口径：需求覆盖这一维能到 95% 以上，算法是拿有证据支撑的需求条目除以原始需求条目。它跟上线成功率、免人工比例是三回事，但至少能指到一个可改对象，不像「智能化程度提升」那种没法验收的目标。

另一篇讲把判断从大模型里拆出来的那篇，给的是另一个方向：主链上能确定化的部分写成固定流程，只在真需要判断的地方放循环。整条链路都交给模型自由发挥，出问题就定位不到是哪一步偏的。

边界画得对不对，有个能直接盯的数：转人工率，口径是转人工的会话占总会话的比例。它不看你这一问答得对不对，只看用户要不要再问一次。

出事那天，谁也说不清走到哪一步#

排在最后的这一类，我读到的每一篇都只在自己的角落里提了一句，但它最要命。腾讯 SRE 那条线上靠的是把过程拆成几件可查的事：必需查询有没有执行、参数对不对、工具失败有没有显式降级、证据支不支持结论、置信度匹不匹配，每一项单独判一遍。

状态这一块我比较信一个很朴素的问法：把当前会话最新的一条消息删掉，系统还能不能从断点继续往下跑。恢复就两条路，看任务形态选 —— 检查点把中间状态整体存下来、恢复时直接读回，适合状态紧凑的；事件溯源只记动作、恢复时重放，适合动作可重放但状态很大。

信任层我只盯一件事：系统有没有可能在回答里谎称完成。降级之后仍报告成功，用户就会拿一个空结果当结论往下走。不可逆动作没有把关、出事追不到人，是这类系统最常被拖到最后才补的一块。会话跑到一半等外部审批、等人工输入、等下游回包，这三种等待的持久化方式也不一样。一个结论成形之前已经发生的副作用能不能安全重放，得先想清楚 —— 已经写下去的那几步不回滚，重放只会再写一遍。检查点的粒度也有个判据：恢复时重放的动作超过一次人工能等的时间，就说明切得太粗。

还有一类我只在别人的文章里见到：让 Agent 给自己打分，闭环自己爬分，爬到看板全绿底下那几层其实没东西托着 —— 评测集一旦参与出题和判分，它自己就成了被测对象。这个坑有文章专门写，我不展开。

归下来就这四类#

先说一句如果只能挑一类查，我挑验证和上下文。这两样空着照样能演示，其余几样空着，顶多让演示不好看一点。

这四类不是我拍出来的，是从那三十多篇的失败叙述里倒推的：作者写「评测没覆盖到长尾」，归第一种；写「答复看着对、引用却是编的」，归第二种；写「什么都答应，做不出来也不报错」，归第三种；写「出事那天谁也说不清走到哪」，归第四种。归完自己一看，这四种比八种十种好记。

这四样还能按两件事分：前两样决定它看起来像不像能用，后两样决定它真出事那天还能不能救。我从那三十多篇里摘的其实都是这个分法 —— 每篇作者只会讲自己那半边，讲成本的不提验证，讲评测的不提信任。

读完这三十多篇之后，我真正改掉的不是某条做法，是一个问法：先问哪一类最空，再问聪明不聪明。因为四类里最前面两样空着照样能演示 —— 验证层空了没有门禁，问题只在真实流量里显形；上下文层空了，答复通顺到肉眼根本看不出来。后两样不一样，能力边界一问就露，状态出事那天才知道，所以它排最后。

上面这些没有一条是我一个人跑出来的结论，都是别人那几篇里已经有的东西被我归到一起。我自己能添的只有那个问法本身，以及一句更实在的：看完别人的实践，最好用的动作不是照搬他那一套，是把他的失败形态摘出来，套到自己的系统上问一遍。

顺便说一句，下面这条是我在自己的用例集里补的，不在任何一篇文章里：上游没跑通的时候，下游指标记 error 并跳过统计，failed 只留给真做错的模块。这两行在看板上都显示成红色，指向的却是两件不同的事。

写到这里该说实话了：这篇不是一次评审的产物，是我把三十多篇反复读、反复归之后攒下来的，里头每个数字都标了是哪一篇的。你要是也在读这类文章，拿它当索引比当答案有用。