一、全局设置四样

第三行最容易漏。主 Agent 什么都答，三个专家就白分了。 第四行是体验细节。跳转时不吭声，用户会以为自己那句话被吞了。 说一句「换人」，他知道还在同一家公司里。 开场白那句把四个信息一次收齐，是为了减少跳转次数。 信息不全，专家接手还得再问一遍，用户就得多说一轮。

二、跳转规则：三条路

书上三种都用了：先按意图判，判不出来看关键词，用户点名就直接跳。 第三条是兜底里的兜底。用户已经说清要找谁了，系统还在那儿判，就是蠢。 三条路的优先级也要定：点名最高，其次关键词，最后才是意图判断。 反过来会让用户觉得「我说了它也不听」。

三、跑一段八轮对话

八轮里跳了六次。这个数偏高——用户每换一个话题就换一个人，手感上像「被踢皮球」。 一次不跳又说明根本没分工。 第 1 轮和第 8 轮都在主 Agent：一句是开场收信息，一句是收尾。这两头留在主 Agent 是对的。 第 6、7 轮是回跳：从食宿回到路线、从路线回到景点。回跳必须支持，不然用户改主意就没路走。

真实的对话很少这么整齐。这段是「一路往下问」的理想轨迹，用来检查跳转规则有没有漏。

四、循环怎么收口

最危险的不是跳错，是回不来。 A 交给 B，B 又交回 A，用户一句话被两个 Agent 轮流接，永远没有答案。

第一条最稳：专家之间不互相跳，只跟主 Agent 打交道。 主 Agent 是唯一的调度者。 这样做的好处是永远不会成环——星形结构没有环。代价是多一跳，慢一点点。 第三条是体验底线。 食宿 Agent 接手时如果不知道用户已经说了「三天」「两个人」，它会重新问一遍，用户会觉得刚才白说了。

五、三个专家的配置差别

三行「最常犯的错」都不是能力问题，是倾向问题。写人设的时候，把你最不想要的那个倾向写死。 比如景点那个：加一句「不要列十个让我自己挑，就推三个」，它就不写百科了。 这条技巧在单 Agent 里也成立，只是多 Agent 里更好使——每个专家只管一件事，倾向可以写得很具体。

六、动手 Demo：全局设置、跳转规则、循环怎么收口

先看全局设置四样，再看三条跳转路，然后跑一段八轮对话看轨迹。 最后看循环收口的三种做法和三个专家最容易犯的错。

FLOW = [(u'想去杭州玩三天', u'旅行助手'),
        (u'有哪些景点必去', u'景点推荐'),
        (u'三天怎么安排',  u'路线规划'), ...]

for say, _tgt in FLOW:
    e, _rank = Q.route(say, EXP)          # 落到谁
    got = e.name if e.score(say) > 0 else MAIN

实跑输出：

--------------------------------------------------------------------
全局设置、跳转规则、循环怎么收口
--------------------------------------------------------------------


  ① 全局设置里要写什么
  --------------------------------------------------------------------

| 项 | 这一版怎么写 | 为什么 |
|---|---|---|
| 人设 | 你是旅行助手，能安排景点、路线、食宿 | 写清管什么 |
| 开场白 | 想去哪、几天、几个人、大概预算？ | 一句话收齐四个信息 |
| 不管什么 | 机票改签、签证、天气 | 明确拒绝的清单 |
| 跳转语气 | 这块我让专门的同学来答 | 让用户知道换人了 |

  第三行最容易漏。主 Agent 什么都答，三个专家就白分了。
  第四行是体验细节：跳转时不吭声，用户会以为自己刚才那句话被吞了。
  说一句「换人」，他知道还在同一家公司里。

  ② 跳转规则：两条路
  --------------------------------------------------------------------

| 路 | 怎么触发 | 特点 |
|---|---|---|
| 按意图自动跳 | 主 Agent 读完描述自己判 | 自然，但可能判错 |
| 按关键词硬跳 | 命中某个词就跳 | 准，但生硬 |
| 用户点名要谁 | 「我要找管住宿的」 | 必须有，是兜底 |

  书上三种都用了：主 Agent 先按意图判，判不出来看关键词，用户点名就直接跳。
  第三条是兜底里的兜底。用户已经说清要找谁了，系统还在那儿判，就是蠢。

  ③ 跑一段八轮对话
  --------------------------------------------------------------------

| 轮 | 用户说 | 上一轮在谁那 | 这一轮到谁 | 跳没跳 |
|---:|---|---|---|---|
| 1 | 想去杭州玩三天 | 旅行助手 | 旅行助手 | — |
| 2 | 有哪些景点必去 | 旅行助手 | 景点推荐 | 跳 |
| 3 | 三天怎么安排 | 景点推荐 | 路线规划 | 跳 |
| 4 | 住哪片方便 | 路线规划 | 食宿安排 | 跳 |
| 5 | 预算三千够吗 | 食宿安排 | 食宿安排 | — |
| 6 | 那路线要改吗 | 食宿安排 | 路线规划 | 跳 |
| 7 | 再推荐两个景点 | 路线规划 | 景点推荐 | 跳 |
| 8 | 谢了 | 景点推荐 | 旅行助手 | 跳 |

  八轮里跳了 6 次。这个数偏高——用户每换一个话题就换一个人，手感上是「被踢皮球」。
  一次不跳又说明根本没分工。
  第 1 轮和第 8 轮都在主 Agent：一句是开场收信息，一句是收尾。这两头留在主 Agent 是对的。
  第 6、7 轮是回跳：从食宿回到路线、从路线回到景点。回跳必须支持，不然用户改主意就没路走。

  ④ 循环怎么收口
  --------------------------------------------------------------------
  最危险的不是跳错，是回不来。A 交给 B，B 又交回 A，用户一句话被两个 Agent 轮流接，永远没有答案。

| 做法 | 怎么实现 | 评价 |
|---|---|---|
| 只跳一次 | 每个专家只接一次，第二次交回主 Agent | 最稳 |
| 设最大跳转次数 | 三次之内必须给结果 | 简单，但可能截断 |
| 跳转要带上下文 | 下一个 Agent 知道前面说了什么 | 必须有 |

  第一条最稳：专家不互相跳，只跟主 Agent 打交道。 主 Agent 是唯一的调度者。
  第三条是体验底线。
  食宿 Agent 接手时如果不知道用户已经说了「三天」「两个人」，
  它会重新问一遍——用户会觉得刚才白说了。

  ⑤ 三个专家的配置差别
  --------------------------------------------------------------------

| 专家 | 人设重点 | 最常犯的错 |
|---|---|---|
| 景点推荐 | 要敢取舍，说清哪个可以不去 | 容易写成旅游百科 |
| 路线规划 | 要算时长，每天不超过四个点 | 容易排得太满 |
| 食宿安排 | 要给价位和渠道 | 容易只说「有很多选择」 |

  三行「最常犯的错」都不是能力问题，是倾向问题。写人设的时候，把你最不想要的那个倾向写死。
  比如景点那个：加一句「不要列十个让我自己挑，就推三个」，它就不写百科了。

①全局设置四样，第三样「不管什么」最容易漏。 ②三条跳转路：意图、关键词、点名。优先级是点名最高。 ③八轮跳了六次，偏高。第 1、8 轮留在主 Agent 是对的。 ④回跳必须支持：第 6、7 轮就是从食宿回到路线、从路线回到景点。 ⑤收口最稳的做法：专家只跟主 Agent 打交道，星形结构没有环。

30 秒实验

1. 把你的主 Agent 的「不管什么」写出来，至少三条。写不出来，说明它还在什么都答。
2. 跑一段真实对话，记下每轮的落点。跳转超过一半轮次的，考虑合并两个专家。
3. 检查你的跳转带没带上下文：让下一个 Agent 复述用户已经说过的信息。说不出来就是没带。

常见误区

1. 「跳得越勤说明分工越细。」跳太多像踢皮球。三到五个专家就够，再多合并。
2. 「专家之间互相跳更灵活。」容易成环。星形最稳，慢一点但不会卡死。
3. 「人设写全一点，什么都能干。」人设越全，倾向越模糊。要把最不想要的倾向写死。

配好了，下一节测。多 Agent 测的不是单个回答，是交接。

• ☐ （本篇完，下一篇 16.3 旅游助手功能测试）

相关笔记

• 认识多 Agent：上一节的多 Agent 思路
• 创建对话流与基础配置：会话变量与跨轮记忆
• 旅游助手功能测试：下一节测试
• 🐦 扣子开发 AI Agent · 索引