查一条订单，Agent 为什么走了 109 步？一个 Agent 评测失败案例的归因分析
导读：本文复盘一个 Agent 评测失败案例：用户只问"我接的订单在哪里看，给我链接"，Agent 却走了 109 步、调用 82 次工具（其中 44 次盲猜 API 路径），最终仍没查出订单数据，而正常路径只需 5～10 步、10～30 秒。归因得出五层系统性叠加的问题——技能路由失败致订单查询技能从未进入主路径、身份与技能可见范围配置错误（服务者身份下暴露的是员工端技能）、RAG 泛化替代（20 次知识库检索兜底）、会话旧记忆干扰（翻历史会话"考古"旧技能名）、无约束的暴力盲探（44 次猜 URL），并给出对应五层改进建议；对评测侧的关键启示是"不能只盯是否碰到过某个工具，更要盯是否路由到正确技能并在合理步数内完成任务"。适合做 Agent 评测、平台工程或 LLM 应用工程化的人阅读。
分类：AI评测 ｜ 标签：Agent、评测、归因分析、失败案例
从一个「离谱」的评测结果说起
在自研 Agent 平台上评测一个由多个技能组合而成的智能体时，我拿到了一份奇怪的 Trace：用户只是问了一句「我接的订单在哪里看，给我链接」——一句像正常人说的话，Agent 却整整走了 109 步、调用了 82 次工具，最后还没有查出任何订单数据。
拿到结果的第一反应是：「评测用例是不是写坏了？」但把这条提问放到自然语言层面看，它没有任何歧义，就是一个再普通不过的业务查询。问题出在 Agent 本身——它没有走通「技能短路路径」，而是把一道查订单的题，做成了一场「查记忆 → 搜知识库 → 看错技能 → 翻旧会话 → 猜 44 个 API」的冗长探索。
这类「超长探索」在 Agent 评测里并不少见：表面看是模型没答对，实际上往往是技能路由、身份可见范围、上下文记忆等系统性问题层层叠加后被放大。这篇文章把这个失败案例拆开，逐层归因。
现象：109 步、82 次调用，其中 44 次在盲猜 API
先用数据说话。这次任务的时间线（Timeline）统计如下：
| 指标 | 数值 |
|---|---|
| 总步数 | 109 |
| 工具调用次数 | 82 |
| 其中业务 HTTP 查询（猜测 API 路径） | 44 次 |
| 其中知识库混合检索 | 20 次 |
| 其中历史会话检索 | 8 次 |
| 其中技能查看 | 4 次 |
| 其中记忆画像 / 技能列表 / 知识库列表 | 各 2 次 |
而正常路径应该是什么样？路由到「业务订单查询技能」→ 读取技能说明 → 调用 1～2 次业务 HTTP 接口 → 拼出订单链接回复。整个过程大约 5～10 步、10～30 秒。
实际走了 109 步。差在哪？逐层看。
归因一：技能路由失败——该用的技能根本没被选中
复盘的第一步就发现了问题。Agent 查询技能列表，只返回了 2 个技能：
- 「视频简历」技能
- 「员工端」技能
「业务订单查询技能」压根不在列表里。 也就是说，Agent 从第一步开始就在「猜该用谁」，而不是执行已经部署好的订单查询技能。这是整条失败链的地基问题。
归因二：身份与技能可见范围配置错误——Agent 不知道自己能调什么
Trace 的第 20～21 步，Agent 加载了「员工端」技能（面向销售/经纪人的技能），然后它自己都判断出来了：
「这是员工端的，用户是服务者，不是员工。」
一个模型自己都能看出来的身份错配，说明身份配置 + 技能可见范围这两层出了问题：服务者身份下，技能列表暴露的是员工端能力，而真正该暴露的订单查询技能却不可见。Agent 不是「不会选」，是「没得选」。
归因三：RAG 泛化替代——用通用检索代替业务技能
技能列表里没有可用的订单技能，Agent 于是启动了「通用路径」：在第 10～18 步、23～24 步等位置，连续做了 20 次知识库混合检索，搜索「App 使用」「H5 链接」「打卡」之类的词。
结果搜到的全是产品操作说明（比如 App 里怎么打卡、怎么看订单），而不是用户真正要的「我接的订单 + 具体链接列表」。这是典型的 RAG 泛化回答路径——用知识库检索兜底，替代了本应由业务技能执行的路径。检索再多次，也查不出订单数据。
归因四：会话旧记忆干扰——Agent 在「考古」上一个任务的残留
更微妙的问题出现在第 32～36 步。Agent 试图加载技能「订单列表技能」（一个在历史会话里出现过的旧技能名），得到的返回是 Skill not found——当前环境根本没有这个技能。
它没有就此停手，而是继续翻历史会话，去找「旧对话里出现过的技能名」。这说明当前环境的技能集合和历史会话里的技能集合不一致，Agent 被上一轮任务的旧记忆带偏，开始了一场「会话考古」。上一个任务的残留（旧技能名、旧路径）污染了本次任务的探索方向。
归因五：长探索放大——没有约束的暴力盲探
第 38 步之后，最夸张的一幕出现了：44 次业务 HTTP 查询，全部在猜 URL 路径——形如 /api/order/list 的各种 path 变体，挨个试过去。
这是在没有技能说明文档（SKILL.md 中本应给出标准接口入参）情况下的暴力试探：每次失败就换一个 URL，所以从外部看就是「Agent 一直在转、特别长」。44 次盲探既是前四层问题的下游结果，也是 109 步的主要放大因素。
结果：最终回复偏离用户意图
第 109 步，Agent 的思考结论是：
订单在 App 里看，没有独立网页链接，给 App 入口说明。
用户要的是「我接的订单 + 链接清单」，Agent 给的是产品使用说明——从头到尾没有真正查出订单数据。执行了 109 步，又回到了路径起点。
与评测 FAIL 的关系：评测侧该盯什么
在这次评测里，L1（评测分层）期望是「业务 HTTP 查询被调用」。从 Trace 看，这个条件其实「满足」了——44 次调用。但结果仍然 FAIL，可能的原因有两类：
- 技能路由错误：订单查询技能从未被加载；
- 业务未完成：HTTP 调用全部失败，或未返回有效订单数据。
这给评测侧提了个醒：不能只盯「有没有碰到过某个工具」，更要盯「是否路由到了正确技能 + 是否在合理步数内完成了任务」。109 步本身，就应该是 FAIL 的信号。
改进建议
基于上面的五层归因，改进方向也分五层：
- 技能可见性：服务者身份下，确保「业务订单查询技能」在技能列表中可见，可见范围与身份权限正确绑定；
- 路由规则：把「我接的订单 / 链接 / 打卡」这类意图直接映射到「业务订单查询技能」，命中后第一步就加载该技能，禁止先走 RAG；
- 探索深度限制：同一意图下业务 HTTP 查询连续失败超过 3 次应自动停止，禁止 40+ 次猜 URL；
- 禁用错误技能：服务者场景下不要暴露「员工端」技能，即便误加载也要立即中止；
- 会话记忆治理：旧技能名在当前环境不存在时，停止继续翻历史会话，不给旧记忆带偏的机会。
一句话总结
不是模型「不会说话」，而是 Agent 把一道「查我接的订单」做成了「查记忆 → 搜知识库 → 看员工技能 → 翻旧会话 → 猜 44 个 API」的冗长探索；正确的业务技能从头到尾没有进入主路径。
这条失败案例的价值在于：109 步不是模型笨，而是技能路由、身份可见范围、RAG 兜底、会话记忆、探索约束五层问题在单次评测里层层叠加。Agent 评测要抓的，正是这些隐藏在步数背后的系统性问题。