一、三件事，三套标准

三件事的「答得好」标准完全不一样：景点要敢取舍，路线要算得清，食宿要报得出价。 塞进一个提示词里，模型每轮都要猜「这次该用哪套标准」。 猜错的表现很明显：你问景点，它给你排了个三日游行程。 而且它猜错的时候不会告诉你。 这是多 Agent 存在的第一个理由——不是性能，是可预期。

二、三套规则放一起会打架

三条规则本身都对，一共 40 字，也不长。问题不在长度，在冲突。 「只推三个」和「每天不超过四个点」是两个数：推荐三个景点，排四天路线就得重复。 模型碰到这种冲突，会自己选一条遵守，另一条当没看见。 它不会告诉你它选了哪条。 这就是把人设塞一起最要命的地方——你从输出里看不出它漏了什么。

这一条比「模型不够聪明」严重得多。不够聪明你能感觉到，悄悄丢规则你感觉不到。

三、分工之后

三个专家各只有四到六个关键词。分诊靠的就是这几个词。 真机上这一步是主 Agent 读各专家的「描述」来判断，不用关键词。 本课用关键词替身，替的是「判断该找谁」那一步，不是路由机制本身。 这一点要分清：替身换的是判断方式，不是架构。 架构是「一个分诊 + 三个专家」， 这一条在真机上一模一样。

四、跑八句话，看落到谁

八句里七句有人接。第八句（问天气）三个专家都不认——它本来就不该由这三个管。 这一句最值得看。它不是失败案例，是「三个专家都不该接」的正确答案。 主 Agent 这时候该自己兜住，或者说「这个我不管」。 如果这一句被硬塞给了景点推荐，那说明三个专家的描述写得太宽——宽到什么都能沾上边。

五、分工的第一件事是「谁不干什么」

大家写多 Agent 的时候，第一反应都是列「景点专家能干什么、路线专家能干什么」。 但真正决定边界的，是「谁不干什么」。 不写后者，什么都会被硬塞给某个人。

三行「不干什么」写下来，边界就清楚了。写不出来的，说明这三个专家本来就该合成一个。 这也是一个自检：如果三个专家的「不干什么」互相重叠很多，那你分得不对，该重分。

六、动手 Demo：一个 Agent 干不好，因为它要同时演三个人

先看三件事的三套标准，再把三条规则放一起看它们怎么打架。 最后给三句话分别找专家，看第八句为什么没人接。

EXP = [
    Q.Expert(u'景点推荐', u'去哪玩', [u'景点', u'好玩', u'值得', u'打卡'], ...),
    Q.Expert(u'路线规划', u'怎么走', [u'几天', u'路线', u'行程', u'怎么安排'], ...),
    Q.Expert(u'食宿安排', u'住哪吃啥', [u'住', u'酒店', u'民宿', u'吃', u'美食', u'预算'], ...),
]

e, rank = Q.route(u'杭州有哪些必去的景点', EXP)

实跑输出：

--------------------------------------------------------------------
一个 Agent 干不好，因为它要同时演三个人
--------------------------------------------------------------------


  ① 三件事，三套规则
  --------------------------------------------------------------------

| 活 | 要回答什么 | 什么算答得好 |
|---|---|---|
| 景点推荐 | 什么值得去、什么时候去、怎么避坑 | 要具体，要有取舍 |
| 路线规划 | 几天几晚、每天几个点、怎么走顺 | 要有顺序，要算时长 |
| 食宿安排 | 住哪片、吃什么、预算多少 | 要给价位，要能订 |

  三件事的「答得好」标准完全不一样。景点要敢取舍，路线要算得清，食宿要报得出价。
  塞进一个提示词里，模型每轮都要猜「这次该用哪套标准」。
  猜错的表现是：问景点，它给你排了个三日游行程。

  ② 三套规则放一起会互相打架
  --------------------------------------------------------------------

| 序 | 给谁 | 规则 | 字数 |
|---:|---|---|---:|
| 1 | 景点 | 只推三个，说清哪个可以不去 | 13 |
| 2 | 路线 | 每天不超过四个点，要算路上时间 | 15 |
| 3 | 食宿 | 必须给价格区间和预订渠道 | 12 |

  三条规则本身都对，字数也不多（一共 40 字）。问题不在长度，在冲突。
  「只推三个」和「每天不超过四个点」是两条不同的数：推荐三个景点，排四天路线就得重复。
  模型碰到这种冲突，会自己选一条遵守，另一条当没看见。
  它不会告诉你它选了哪条。 这就是把人设塞一起最要命的地方。

  ③ 分工之后：一个分诊，三个专家
  --------------------------------------------------------------------

| 专家 | 管什么 | 关键词 |
|---|---|---|
| 景点推荐 | 去哪玩 | 景点、好玩、值得、打卡 |
| 路线规划 | 怎么走 | 几天、路线、行程、怎么安排 |
| 食宿安排 | 住哪吃啥 | 住、酒店、民宿、吃、美食、预算 |

  三个专家各自只有 4 到 6 个关键词。分诊靠的就是这几个词。
  真机上这一步是主 Agent 读各专家的「描述」来判断，不用关键词。
  本课用关键词替身，替的是「判断该找谁」那一步，不是路由机制本身。

  ④ 跑八句话，看落到谁
  --------------------------------------------------------------------

| 用户说 | 落到谁 | 得分 |
|---|---|---:|
| 杭州有哪些必去的景点 | 景点推荐 | 1 |
| 三天两晚怎么安排比较顺 | 路线规划 | 1 |
| 西湖边上有什么好吃的 | 食宿安排 | 1 |
| 住哪个区方便一点 | 食宿安排 | 1 |
| 预算三千够不够 | 食宿安排 | 1 |
| 帮我规划一条带娃的路线 | 路线规划 | 1 |
| 有什么小众的地方值得去 | 景点推荐 | 1 |
| 明天天气怎么样 | 没人接 | 0 |

  八句里 7 句有人接，第 8 句（问天气）三个专家都不认——它本来就不该由这三个管。
  这一句最值得看。 它不是失败案例，是「三个专家都不该接」的正确答案。
  主 Agent 这时候该自己兜住，或者说「这个我不管」。
  ! 分工的第一件事不是「谁能干什么」，是「谁不干什么」。不写清后者，什么都会被硬塞给某个人。

①三件事三套标准：景点要取舍、路线要算清、食宿要报价。 ②三条规则 40 字，问题在冲突不在长度：三个景点排四天必然重复。 ③三个专家四到六个关键词，分诊靠这几个词。 ④八句里七句有人接，第八句问天气没人接——这是对的。 ⑤第五节：分工的边界靠「谁不干什么」定，不靠「谁能干什么」。

30 秒实验

1. 把你的业务拆成三件事，各写一条「什么算答得好」。写不出区别的，说明不该拆。
2. 给每个 Agent 写三行「不干什么」。三行重叠很多的，重新分。
3. 拿一句话去试：「今天天气怎么样」。它被硬塞给了某个专家，就说明描述太宽。

常见误区

1. 「一个提示词塞三套人设，模型能分清。」碰到冲突它会自己选一条，还不告诉你。
2. 「规则不长就不会打架。」40 字照样打架。冲突看的是内容，不是长度。
3. 「什么都能接才叫强。」三个专家都不接的时候，正确答案就是「我不管」。

分工想清了，下一节动手：全局设置、跳转规则、还有循环怎么收口。

• ☐ （本篇完，下一篇 16.2 多 Agent 模式开发实战操作）

相关笔记

• 工作流调试与优化：上一章的收尾
• 扣子快速开发入门：人设怎么写
• 多 Agent 模式开发实战操作：下一节动手配
• 🐦 扣子开发 AI Agent · 索引