一、三类错，一类比一类难发现

三类里第三类最阴。它发生在两轮之间，单看每一轮的回答都正常。 所以多 Agent 的测试集要连着跑，不能一句一句测。一句一句测，第三类永远测不出来。 第一类最省钱但最伤体验：主 Agent 硬答，答得浅、没错、也没用。 用户会觉得这个助手「说了跟没说一样」。

二、十二句跑一遍

十二句里交接对 8 句，四句错的全是同一种：该跳没跳，主 Agent 自己接了。 没有一句是「跳错人」——因为跳错人要先跳出去才可能错，这四句索性没跳。 四句里有三句带着「适合」「第二天」「多少钱」这种词，而关键词表里一个都没有。 这不是模型笨，是词表不全。

三、补词再跑一遍

补七个词：适合、小众、远不远、第几天、第二天、一晚、多少钱。再跑一遍，十二句全对。

补词这件事看着土，但它是多 Agent 里最有效的调节手段——比改人设快，比改描述准。 真机上不用手工补词，主 Agent 读描述就能判。 可「描述里没写这个场景」和「词表里没这个词」是同一类问题：覆盖不全。 所以补词这一步在真机上依然要做，只是形式变成「往描述里加一句」。

四、三类错的代价

第三行打横线，是因为它没法在这一列里记：「跳了没回来」发生在两轮之间，哪一句单独看都正常。 要看它，只能用连续对话。 第 16.2 节第 7 轮那句「再推荐两个景点」就是例子——它前面刚由路线 Agent 答完， 主 Agent 手上没有上下文，接得就很虚。 单句测试测的是分类，连着测的才是交接。 这是多 Agent 测试和普通工作流测试最大的不同。

五、项目小结：九个案例，一件事

这一章真正的新东西只有一个：跳转。其余全是前面用过的。 而跳转带来的问题也很单一：交接。谁交给谁、交的时候带不带上下文、交完回不回来。 三个问题都有答案了，多 Agent 就做完了。 三个问题里漏一个，它就会在某一轮突然变得很蠢——而那一轮单独看，往往看不出问题。

六、这套东西能用到哪

三行的共同点：活能明显切成几块，每块的「答得好」标准不一样。 切不开的，别硬分。 反例：一句话问答、单轮查询、纯计算。这些用单 Agent 更快、更便宜、更好调。 多 Agent 不是升级，是另一种取舍。 换来的是可预期，付出的是多一跳和一套跳转规则。

七、动手 Demo：多 Agent 测的是交接，不是单个的回答

先列三类错，再拿十二句跑一遍，看错在哪一类。 补七个词再跑一遍，最后看三类错各自的代价。

def sweep(experts, tag):
    for say, tgt in TESTS:
        e, _r = Q.route(say, experts)
        got = e.name if e.score(say) > 0 else MAIN
        if got == tgt:   mark = u'对'
        elif got == MAIN: mark = u'该跳没跳'
        else:             mark = u'跳错人'

实跑输出：

--------------------------------------------------------------------
多 Agent 测的是交接，不是单个的回答
--------------------------------------------------------------------


  ① 三类错，一类比一类难发现
  --------------------------------------------------------------------

| 错法 | 表现 | 为什么难发现 |
|---|---|---|
| 该跳没跳 | 主 Agent 自己硬答了 | 答案浅，但不报错 |
| 跳错人 | 交给了不该管的那个 | 答非所问，用户会重说一遍 |
| 跳了没回来 | 专家答完，主 Agent 不知道 | 下一句接不上，像换了个人 |

  三类里第三类最阴。它发生在两轮之间，单看每一轮的回答都正常。
  所以多 Agent 的测试集要连着跑，不能一句一句测。 一句一句测，第三类永远测不出来。

  ② 十二句跑一遍
  --------------------------------------------------------------------
  第一版：交接对 8 句、该跳没跳 4、跳错人 0。

| 用户说 | 该谁管 | 实际谁管 | 判定 |
|---|---|---|---|
| 带老人适合去哪 | 景点推荐 | 旅行助手 | 该跳没跳 |
| 第二天去哪 | 路线规划 | 旅行助手 | 该跳没跳 |
| 那里远不远 | 路线规划 | 旅行助手 | 该跳没跳 |
| 多少钱一晚 | 食宿安排 | 旅行助手 | 该跳没跳 |

  四句错的全是同一种：该跳没跳，主 Agent 自己接了。
  没有一句是「跳错人」——因为跳错人要先跳出去才可能错，这四句索性没跳。
  四句里三句带着「适合」「第二天」「多少钱」这种词，关键词表里一个都没有。

  ③ 补词再跑一遍
  --------------------------------------------------------------------
  第二版：交接对 12 句、该跳没跳 0、跳错人 0。
  补了 7 个词：适合、小众、远不远、第几天、第二天、一晚、多少钱。
  四句全对上：「带老人适合去哪」靠「适合」，「第二天去哪」靠「第二天」，
  「那里远不远」靠「远不远」，「多少钱一晚」靠「一晚」和「多少钱」。
  ! 补词这件事看着土，但它是多 Agent 里最有效的调节手段——比改人设快，比改描述准。

  ④ 三类错的代价
  --------------------------------------------------------------------

| 错法 | 第一版 | 第二版 | 代价 |
|---|---|---|---|
| 该跳没跳 | 4 | 0 | 低：答案浅但没错 |
| 跳错人 | 0 | 0 | 高：答非所问 |
| 跳了没回来 | — | — | 中：下一轮要重说 |

  第三行打横线，是因为它没法在这一列里记：「跳了没回来」发生在两轮之间，哪一句单独看都正常。
  要看它，只能用连续对话。
  第 16.2 节第 7 轮那句「再推荐两个景点」就是例子——它前面刚由路线 Agent 答完，
  主 Agent 手上没有上下文，接得就很虚。
  单句测试测的是分类，连着测的才是交接。 这是多 Agent 测试和普通工作流测试最大的不同。

  ⑤ 项目小结：这一章和前八章的关系
  --------------------------------------------------------------------

| 部分 | 是什么 | 内容 |
|---|---|---|
| 第 1~7 章 | 零件 | 节点、插件、知识库、数据库、提示词 |
| 第 8~15 章 | 八个案例 | 一条直线、分支兜底、包外部服务 |
| 第 16 章 | 把智能体也当零件 | 一个主 Agent + 三个专家 |

  这一章真正的新东西只有一个：跳转。其余全是前面用过的。
  而跳转带来的问题也很单一：交接。谁交给谁、交的时候带不带上下文、交完回不回来。
  三个问题都有答案了，多 Agent 就做完了。
  三个问题里漏一个，它就会在某一轮突然变得很蠢——而那一轮单独看，往往看不出问题。

①三类错：该跳没跳、跳错人、跳了没回来，第三类最难发现。 ②十二句第一版：对 8、该跳没跳 4、跳错人 0。 ③四句错的都是该跳没跳，因为句里的词表里没有。 ④补七个词之后十二句全对。 ⑤三类错代价表，第三行打横线——它没法逐句记。

30 秒实验

1. 给你的多 Agent 标十二句测试集，每句写「该谁管」。标不出来的，说明边界没定。
2. 连着跑十轮，看有没有「跳了没回来」——单句测是测不出来的。
3. 把三类错各记一个数。只记一个总准确率，你分不清是没跳还是跳错。

常见误区

1. 「一句一句测就够了。」「跳了没回来」发生在两轮之间，单句测永远测不出来。
2. 「该跳没跳不算错。」答得浅、没错、也没用，用户会觉得说了跟没说一样。
3. 「多 Agent 比单 Agent 高级。」是另一种取舍。切不开的活，别硬分。

全书到这里就完了。九章零件、八个案例、一个多 Agent，剩下的是把它们排对。

• ☐ （全书完）

相关笔记

• 多 Agent 模式开发实战操作：上一节的配置
• 完整工作流测试与优化：智能客服的三层判定
• 创建对话流与基础配置：意图识别放在哪一层
• 🐦 扣子开发 AI Agent · 索引