让几个 agent 互相说话 — 分工是靠三样硬拦撑住的
这一章讲三件事: 让两个程序互相说话能省掉什么; 光「让它们聊」为什么不够、要靠哪三样硬拦; 以及书里没讲的那一格——下一个谁说话,本身是一个可以选的策略。
它在全书链条里的位置: 前十一章的主角都是一个程序。 这一章第一次出现两个及以上。 但机制没有变:每一个还是第 01 章那一圈, 只是它们的输入来自彼此,而不是来自人。
1. 一个人自问自答,和两个人对话,差在哪
这一节讲这条路的动机,而这个动机比你想的实在。
书的起点是一个很朴素的观察:模型的表现在很大程度上依赖于通过用户的输入来引导; 如果你能把任务和需求描述得很细、并和它建立连贯的上下文,它往往能答得更好。 但为它提供这种引导是一个既费时又费力的任务1。
然后书问了一个好问题:能否让模型自己生成这些引导文本?
这就是这条路的全部动机。 不是「两个比一个聪明」,而是—— 让一个程序去扮演那个原本要你来当的、不停下指令的人。
书里那个框架的核心创新用了三个名词,先把它们各讲一句,再看原话。
第一个是角色扮演——给每个程序分派一个身份,让它按这个身份说话。
第二个名词管的是这件事:只在开头给一次交代,之后两边就自动互相提示、不用你再插手。 书里管它叫启发式提示(名字里那三个字是那篇论文起的叫法,不必按字面理解); 原文的说法是这种提示工程只用在角色扮演的初始阶段,主要用于明确任务和分配角色; 当对话开始后,双方会自动相互给出提示,直到对话结束2。
第三个是交流 agent——一种可以和人或其他程序对话的程序。
有了这三个词,原话就好读了:这个框架的核心创新是 通过角色扮演和启发式提示来引导 agent 的交流过程3。
2. 中间还有一个角色:把一句模糊的话改具体
这一节讲一个很容易被跳过、但设计上很聪明 的零件。
书的做法是:人只给一个粗想法,中间先有一个专门的角色把它改具体4。
为什么要这一步? 书给的理由很实在: 对于非领域专家来说,创建具体的任务提示可能具有挑战性或耗时。 换句话说——人写不出好任务,那就让模型先替你写一遍。
书里那趟的真实改写是这样5:
人给的原始任务:
整理出一个夏季玫瑰之夜的营销活动的策略
改写之后:
为夏季玫瑰之夜策划主题装饰,策划特价活动,制定营销推广方案,
组织娱乐活动,联系合作伙伴提供赞助
图说:从一句话变成五件事。
**这五件事后面两个角色会一件件谈过去 —— 也就是说,
这一步实际上决定了整趟对话的骨架。**
这一步的设定里有一个细节值得记: 它用的模型和后面两个角色不是同一个, 而且它的温度旋钮拧到了 1.0(书里那句提示还写着「请发挥你的创意和想象力」), 而后面两个角色都是 0.26。一个负责放开想,两个负责往回收。
3. 两个角色:一个只下指令,一个只给方案
这一节讲分工怎么落到文字上。答案还是那句:靠一段提示词。
书里那趟的角色设定只有三行7:
| 谁 | 是什么 | 干什么 |
|---|---|---|
| AI 用户 | 花店老板 | 只下指令,不回答 |
| AI 助手 | 花店营销专员 | 只给方案,不提问 |
| (人) | — | 只给了最开头那一句话 |
注意这个分工是反直觉的:扮演「用户」的那一个才是任务规划者。 书说得很明白:一方面 AI 用户是任务规划者,负责发出以完成任务为导向的指令; 另一方面 AI 助手是任务执行者,遵循指令并提供具体的解决方案8。
两段开场提示词都很长,而且写得像一份协议。 助手那一段的骨架是9:
永远不要忘记你是{花店营销专员},我是{花店老板}。永远不要角色互换!永远不要指示我!
…
我每次只能给你一个指令。
你必须写出一个恰当完成指令的具体解决方案。
如果由于物理、道德、法律等原因或你的能力问题,你无法执行我的指令,
你必须诚实地 拒绝我的指令并解释原因。
除了对我的指令的解决方案之外,不要添加任何其他内容。
你永远不应该问我任何问题,你只回答问题。
…
除非我说任务已经完成,否则你应该总是这样回应:
解决方案:<YOUR_SOLUTION>
始终以"下一个请求。"结束<YOUR_SOLUTION>。
请数一数这段话里有多少个「永远不要」「必须」「只」。 这不是提示词,这是一份格式规范。 书自己也这么形容: 这种设计更像是一种交互协议或规范10。
4. 主走查:那三样硬拦
这一节是本章的主走查。
输入: 人只给一句话——「整理出一个夏季玫瑰之夜的营销活动的策略」5。 设定: 两个角色(花店老板 / 花店营销专员),各配一段开场提示词,温度都是 0.26。
一个必须先说清的限制: 两个角色实际对话的原文, 书里只给了一张截图(图 9.13),正文一个字都没印11。 所以这条走查不走「它们说了什么」,走「是什么撑住了它们没跑飞」—— 而这三样在书里全是可引的真实文本。
第 1 步 · 任务被改写。 一句话 → 五件事(第 2 节那段真实原文)。这是走查的起点。
第 2 步 · 硬拦一:永远不要角色互换。
两段提示词的第一行都是同一句:永远不要忘记你是 X,我是 Y。永远不要角色互换!12
这一条防的是什么? 书说得很直白: 这是为了防止在对话中出现角色互换的情况,例如 AI 助手突然开始指导 AI 用户13。
为什么会出现这种情况? 回想第 03 章:模型干的事情是续写一段文字。 一段两个人来回说话的文字摆在它面前,它天然会把两边都续写下去。 「你是哪一边」这件事,对它来说不是常识,是每一轮都要重新交代的东西。
第 3 步 · 硬拦二:一个收尾暗号。
用户那一段提示词的最后写着:当任务完成时,你只须回复一个单词 <CAMEL_TASK_DONE>;
除非我的回答能使你完成你的任务,否则永远不要说它14。
书给的理由堪称全章最有画面感的一句: 这确保当用户满意时可以随时终止对话, 否则,Agent 可能会陷入对话循环,无限制地互相说「谢谢」或「再见」15。
请把这一条和第 01 章第 4 节那条对上。 那一章说,一圈的出口是「模型不再派活」; 这里的出口是「模型说出一个约定好的暗号」。 形式变了,机制没变—— 出口永远是模型的一句话,而不是代码里的一个条件。
第 4 步 · 硬拦三:外面还有一个轮次上限。
代码里写着:chat_turn_limit, n = 30, 0,然后 while n < chat_turn_limit16。
也就是最多聊 30 个来回。
给这个 30 配参照: 第 11 章那一趟的上限是 6,第 05 章那个执行器的默认上限是 15。 30 是这本书里最大的一个上限——而且它是唯一一处「写在代码里、模型说了不算」的出口。
一趟的三层保险:
①提示词里的角色约束 ← 软的。第 11 章证明过:写了不一定听
②收尾暗号 <CAMEL_TASK_DONE> ← 半软。要模型主动说出来才生效
③代码里的 30 轮上限 ← 硬的。模型说了不算
图说:三层从软到硬。**只有第③层是保证。**
前两层管的是「正常情况下好好走」,第③层管的是「实在不行也得停」。
第 5 步 · 循环怎么写。 每一轮里发生两件事: 先让用户角色说一句(把上一轮助手的话当输入),再让助手角色说一句(把刚才那句当输入); 每轮结束检查一次那个暗号在不在16。
这就是全部。 没有裁判、没有仲裁、没有共享的黑板—— 两个程序之间唯一的连接,就是「你上一句话是我这一句的输入」。
5. 书里没讲的:下一个谁说话,本身是一个策略
这一节补一格书里完全没有的东西,而它恰恰是多方协作最要紧的那一格。
第 4 节那趟只有两个角色,所以「下一个谁说话」不成问题——永远是另一个。
可一旦超过两个呢? 书对这件事的全部交代只有两个笼统的说法: 联合聊天(两个或多个可以直接双向交流)和层级聊天(交流遵循一种层级结构)17。 这两句话里没有任何机制。
补充(不在书里,依据我们的前沿框架书架): 「下一个谁发言」在今天是一个明确抽象出来的方法,而且至少有三种现成实现。 依据: shelf=ai-frontier-reference/autogen#03-teams-groupchat.md @027ecf0a379bcc1d09956d46d12d44a3ad9cee14 事实=一个群里有一个主持人,它每轮调用同一个
select_speaker方法挑下一个发言人, 三个团队各给一套实现:轮流(按顺序取模轮一圈,不需要模型)、 让模型挑(把角色描述、参与者名单和历史塞进一段提示, 再从模型的回复里用正则匹配出被提到的名字,匹配不上就给条反馈让它重选)、 按交接单接力(不轮转也不问模型,而是看最近一条交接消息指向谁)。18
第二种那个「从回复里正则匹配名字」的细节值得单独记。 它说明了一件事: 即使你把「请说出下一个发言人的名字」写进提示词,模型也可能说出一个不存在的名字、 或者一口气说出好几个。 所以那套实现里配了重试: 没提到合法名字、提到多个、或者(在不许重复时)提到上一个人,都会被打回去重选。
这和第 11 章第 6 节那条是同一件事的两次出现:提示词是建议,不是规则。 区别在于这一家把「不听话」当成了正常情况来设计,而不是当成异常。
6. 书里没讲的:另一种连法,公共板加订阅
这一节补第二格。它是一种和「对话」完全不同的连法。
第 4 节那趟里,两个程序是直接对着说话的:A 的输出就是 B 的输入。 三个人以上,这种连法就要开始算「谁跟谁说」了。
书在讲另一个框架时提了一句:每个角色关注特定的事件(通过 _watch 方法定义),
并根据这些事件执行相应的动作19。书的交代到此为止,只给了一个方法名。
补充(不在书里,依据我们的 agent 生态书架): 那个方法名背后是一整套「公共板 + 订阅」的连法,和对话是两回事。 依据: shelf=ai-agent-reference/metagpt#03-environment-message-bus.md @11cdf466d042aece04fc6cfd13b28e1a70341b1f 事实=有一个居中的「环境」对象充当消息总线:一封消息只负责说清「发给谁」, 完全不关心「对方在哪、怎么送过去」;环境持有一本地址簿 (每个角色对应它的一组地址),分发时逐个角色判断这封信的收件人和它的地址有没有交集, 有就投进那个角色的私有信箱。角色订阅的不是「谁发的」,而是「因何而发」—— 它盯的是某一类动作的产物,所以不必知道是谁产出的。20
「订阅的是因何而发,不是谁发的」这一句是这套连法的全部精髓。
把两种连法并排放:
| 对话式(第 4 节那趟) | 公共板式(本节) | |
|---|---|---|
| 谁的输出给谁 | 写死:A 给 B,B 给 A | 看订阅:谁盯着这类产物,谁就收到 |
| 加一个新角色要改什么 | 得重新安排谁跟谁说 | 只需要声明它盯什么 |
| 谁决定下一个谁干活 | 轮流 | 产物的类型决定的 |
第二列那个「加一个新角色只需要声明它盯什么」,是这套连法真正的价值。 它也解释了第 8 节那家「软件公司」为什么能把六个岗位串成一条流水线。
7. 另一支:两个程序,一个写代码一个跑代码
这一节走书里的第二个例子。它比第 4 节那趟更接近真实工作。
书给的那趟任务是:绘制今年两支股票价格的变化图。过程有九步,最值得看的是中间四步21:
③助手写出画图的代码,发回给用户角色
④用户角色真的去跑,报错:所需的 yfinance 包没有安装
⑤助手指示用户角色先装这个包
⑥用户角色装好包、跑通代码,生成了图
这四步里有一件前十一章都没出现过的事:一个程序在跑另一个程序写的代码, 并且把报错原样送了回去。
这就是第 05 章第 5 节那条机制跨到两个程序之间的样子: 错误不是终点,错误是对方的下一份输入。
后面还有一段更有意思的:用户角色指出生成的图不符合要求—— 要的是价格的百分比变化,而不是绝对价格变化;助手理解了这个反馈,给出新代码; 跑通22。这一段里,「验收」这个动作是由一个程序完成的。
书里另有一次真实运行,是花语秘境的三件事(查库存、分析市场、写博客), 配了三个助手角色和两个用户代理23。书对这一趟结果的评价很克制: 虽然经过几十轮对话,但它不一定能够完成任务; 在执行过程中会遇到一些问题,不过它会自己尝试解决,并朝着最终目标前进24。
「不一定能够完成任务」这七个字,是这本书对多方协作最诚实的一句评价。
8. 另一支:一行需求,一家软件公司
这一节走第三个例子,它的野心最大。
那个框架的做法是把标准操作程序——一家公司里写好的、固定的办事流程—— 和多个程序结合起来:用这套流程去组织每个角色看到的那段交代,以确保产出是结构化的、模块化的25。
核心理念被写成一个公式:Code = SOP(Team)——
把一套办事流程套用在一个由模型组成的团队上,产出就是代码25。
书给的例子是一家软件公司,六个岗位各是一个程序26:
| 岗位 | 干什么 |
|---|---|
| 老板 | 提出最初的需求 |
| 产品经理 | 写和改需求文档 |
| 架构师 | 写和改设计,审需求文档和代码 |
| 项目经理 | 拆任务、派任务,审需求文档、设计和代码 |
| 工程师 | 写、审、调代码 |
| 质量保证 | 写测试、跑测试 |
输入一行需求,输出用户故事、竞争分析、需求、数据结构、接口、文档。
书里那趟实战是把它换到花店场景: 三个角色(处理订单、管库存、客服), 输入一句「一束红玫瑰」,跑 10 轮27。运行日志——程序一边跑一边打出来的流水账—— 里能看到成本在一行行往上走: 0.001 → 0.002 → 0.009 → 0.016 美元,预算上限 10 美元28。
给这几个数配参照:整趟跑下来花了不到两分钱,而预算是 10 美元——用掉了千分之一点六。 这也顺带说明第 11 章那趟六轮任务循环有多便宜:这类实验的成本几乎可以忽略。
但这一趟的产出值得泼一盆冷水。 三个角色的回答里, 后两个基本是在复述前一个说过的话:管库存那个列了「更新库存、处理订单、客服」三条, 客服那个又把这三条原样总结了一遍,加上「行动已采取」和「后续步骤」的排版29。
学生自己在书里说了实话: 从实验室试验到真正的企业级项目落地, 其间有很多工程上的细节必须补全30。
9. 这三个框架今天的状态
这一节盘现状。三个框架,三种不同的走向。
补充(不在书里,依据我们的前沿框架书架): 第 7 节那个框架已经进入维护模式。 依据: shelf=ai-frontier-reference/autogen#index.md @027ecf0a379bcc1d09956d46d12d44a3ad9cee14 事实=该拆解在开头挂了一条警示:上游已进入维护模式(仓库说明文件顶部有相应徽章), 官方建议新项目改用它的后继者;但它的分层设计仍然是研 究「多个程序怎么排班」的极佳样本。31
补充(不在书里,依据我们的 agent 生态书架): 第 8 节那个框架长出了一层动态调度,把写死的流程换掉了。 依据: shelf=ai-agent-reference/metagpt#05-mgx-rolezero.md @11cdf466d042aece04fc6cfd13b28e1a70341b1f 事实=第二代默认开启:关掉固定流程,换上一个居中收发消息、派活的队长角色; 此后每个角色不再走固定剧本,而是每一轮都让模型现场决定「这一步调哪个工具、传什么参数」。 该拆解给出的两代对比是:第一代强在确定性(步骤写死、产物齐整), 弱在僵——遇到剧本没覆盖的需求就抓瞎。32
补充(不在书里,依据我们的 agent 生态书架): 本章主走查用的那个框架,在「两个人对聊」之外又长出了一层任务分派。 依据: shelf=ai-agent-reference/camel#03-workforce.md @13dc7a7dda66d943949e5448d55e70d5a9481cfe 事实=它今天用来排班派活的主力做法叫「工作队」:内部有三类角色—— 一个规划师把大任务拆成子任务、一个协调者按每个工人的能力描述派活、 若干工人各自执行;活通过一条传送带式的任务通道派出去、收回来; 任务失败时,协调者用模型选一条补救策略(重试、重新规划、再拆、 甚至运行时新造一个工人)。33
三条现状放在一起,能看出一条共同的线:
判断(我们的,不是书里的): 三家都在往「有人居中调度」的方向走, 而不是往「更多平等的对话」走。 第 5 节那个主持人、第 9 节那个队长、这里这个协调者——都是同一个位置。 书里那种「两个角色直接对着说、靠三条提示词硬拦」的形态, 在今天更像是一个教学模型而不是工程做法。 如果错,会错在: 如果这三家只是恰好都做了同样的架构选择、 而别的路线(比如真正去中心的多方协商)也在同时发展,那这条判断就以偏概全了。 不过第 6 节那套「公共板 + 订阅」也是一种居中调度,只是调度的是消息而不是发言权。
10. 可带走的
- 这条路的动机不是「两个比一个聪明」,是让一个程序去当那个原本要你来当的、不停下指令的人;
- **人写不出好任务,那就让模型先替你写一遍:**书里那句「整理一个营销策略」被改写成了五件具体的事;
- 改写那一步用的是不同的设定:温度 1.0 负责放开想,后面两个角色 0.2 负责往回收;
- 分工是反直觉的:扮演「用户」的那一个才是任务规划者,扮演「助手」的只负责给方案;
- 两段开场提示词写得像一份格式规范,满是「永远不要」「必须」「只」——书自己说它更像交互协议;
- **三样硬拦从软到硬:**角色不互换(软)、收尾暗号(半软)、代码里的 30 轮上限(硬);
- 「防止无限制地互相说谢谢和再见」是书给的最有画面感的理由;
- 两个程序之间唯一的连接,就是「你上一句话是我这一句的输入」——没有裁判、没有共享黑板;
- 书里完全没讲「下一个谁说话」这一格; 今天它是一个明确的方法,至少三种实现:轮流、让模型挑、按交接单接力;
- 让模型挑发言人那一种要配重试——因为它可能说出不存在的名字、或一口气说好几个;
- 另一种连法是公共板加订阅:订阅的是「因何而发」而不是「谁发的」,所以加一个新角色只需声明它盯什么;
- 一个程序跑另一个程序写的代码、把报错送回去——这是第 05 章那条机制跨到两个程序之间的样子;
- 书对多方协作最诚实的一句评价是「虽然经过几十轮对话,但不一定能够完成任务」;
- **三个框架今天各自的走向:**一个进了维护模式、一个换上了动态调度的队长、一个长出了协调者加工人的工作队——方向都是「有人居中调度」。
11. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 动机:提供引导既费时又费力 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:5(搜「既费时又费力」) |
| 三个名词:交流、 角色扮演、启发式提示 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:21(搜「通过角色扮演和启发式提示」) · text/62-ch09-03-9-3-camel.txt:29(搜「交流Agent") · text/62-ch09-03-9-3-camel.txt:91(搜「只用在角色扮演的初始阶段」) |
| 任务改写那一步与它的理由 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:57(搜「任务指定Agent」) · text/62-ch09-03-9-3-camel.txt:69(搜「创建这样具体的任务提示可能是具有挑战性」) · text/62-ch09-03-9-3-camel.txt:222(搜「为夏季玫瑰之夜策划主题装饰」) |
| 两个角色的设定与温度 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:186(搜「花店营销专员」) · text/62-ch09-03-9-3-camel.txt:210(搜「temperature=1.0」) · text/62-ch09-03-9-3-camel.txt:308(搜「temperature=0.2」) |
| 谁是规划者、谁是执行者 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:87(搜「AI用户是任务规划者」) |
| 助手那段开场提示词 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:229(搜「永远不要角色互换」) |
| 更像交互协议 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:127(搜「更像是一种交互协议或规范」) |
| 角色不互换的理由 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:111(搜「防止在对话中出现角色互换」) |
| 收尾暗号与它的理由 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:125(搜「无限制地互相说」) · text/62-ch09-03-9-3-camel.txt:268(搜「CAMEL_TASK_DONE」) |
| 30 轮上限与循环 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:328(搜「chat_turn_limit」) |
| 对话原文只有截图 | 9.3 CAMEL | text/62-ch09-03-9-3-camel.txt:342(搜「输出结果如图9.13所示」) |
| 联合聊天与层级聊天 | 10.1 AutoGen | text/65-ch10-01-10-1-autogen.txt:29(搜「联合聊天」) |
| 股票图那趟九步 | 10.1 AutoGen | text/65-ch10-01-10-1-autogen.txt:45(搜「yfinance」) · text/65-ch10-01-10-1-autogen.txt:51(搜「百分比变化」) |
| 花语秘境那趟与那句评价 | 10.1 AutoGen | text/65-ch10-01-10-1-autogen.txt:74(搜「查看当前库存中各种鲜花的数量」) · text/65-ch10-01-10-1-autogen.txt:158(搜「虽然经过几十轮对话」) |
| 标准操作程序与那个公式 | 10.2 MetaGPT | text/66-ch10-02-10-2-metagpt.txt:13(搜「标准操作程序」) · text/66-ch10-02-10-2-metagpt.txt:15(搜「Code = SOP」) |
| 六个岗位 | 10.2 MetaGPT | text/66-ch10-02-10-2-metagpt.txt:23(搜「老板（Boss）」) |
| 订阅方法名 | 10.2 MetaGPT | text/66-ch10-02-10-2-metagpt.txt:61(搜「_watch」) |
| 花店那趟与成本 | 10.2 MetaGPT | text/66-ch10-02-10-2-metagpt.txt:190(搜「一束红玫瑰") · text/66-ch10-02-10-2-metagpt.txt:197(搜「Total running cost") · text/66-ch10-02-10-2-metagpt.txt:229(搜「Total running cost: 0.016") |
| 工程细节必须补全 | 10.2 MetaGPT | text/66-ch10-02-10-2-metagpt.txt:237(搜「工程上的细节必须补全") |