跳到主要内容

多 Agent 协作与两朵乌云

这一章讲三件事: 什么时候真的需要多个 Agent(一条判据);多 Agent 系统 怎么搭(操作系统早已给出蓝本);它以哪些单 Agent 没有的方式失败。 收尾用后记的两朵乌云与飞轮,把全书主线收束。

1. 这一章讲什么​

单个 Agent 受限于自身模型与上下文窗口。多 Agent 的意义不止「取长补短」—— 书里的立论更高一层:群体的智能可以高于个体,正如人类文明靠分工与代际 积累超越任何天才;DeepMind 更把「大规模多 Agent 集体」列为通往超级智能的 关键路径之一1。但先泼冷水再上蓝图,是本章的叙事纪律。

2. 顶层全景​

  两个正交维度:
    ① 上下文是否共享:共享=线程(继承完整轨迹,零损耗但膨胀快)
                      不共享=进程(独立上下文,显式通信)
    ② 协作拓扑:对等(2-3 个迭代改进)/ 管理者(中心调度)/ 去中心化(对等移交)
        │
  一条判据:协作是否引入生成时不存在的新信息?
        │
  一张对应表:静态前缀=程序  轨迹=内存  LLM=CPU  spawn=fork
        │
  一类新故障:Agent 间传递的是语义,每次转述都可能失真(进程类比唯一失效处)

3. 核心原理​

3.1 主走查:十个网站找「张伟」,一路上的每条消息​

任务来自原书实验 10-6;消息体与竞态处理按原书机制还原。

任务:在 10 个学院网站找教师「张伟」,找到后返回学院、职位、研究方向。

t0   Manager 动态创建 10 个 Computer Use Agent,各自独立进程+浏览器
     传入:URL、目标姓名、任务标识符(路由用)
t1   各 Agent 独立跑 ReAct 循环,定期经消息总线发状态更新:
     「正在加载网站」「正在解析教师名录」
     Manager 维护一张任务状态表
t2   agent_3 命中,发 {"type": "target_found", "agent_id": "agent_3", …}
t3   Manager 广播 {"type": "terminate", "reason": "target_found_by_agent_3"}
     其余 9 个优雅停止:清理浏览器会话→写未完成文件→回 ack→退出
t4   Manager 等全部 ack(或超时)后汇总

看起来顺滑,书里特意在 t3 处钉了一个竞态:若 3 号 Agent 与 7 号 Agent 几乎同一毫秒 各自找到张伟、同时上报,Manager 若处理不当会汇总两次、状态矛盾。解法是锁加 幂等:第一个报告到达即锁定状态,后续报告识别为重复并忽略——只结算一次, 只广播一轮终止。超时兜底:每个 Agent 2 分钟,错误隔离,全部失败则如实报告 统计而非编造2。

这个走查里藏着本章的所有关键词:进程级隔离(独立上下文)、消息总线(异步 解耦)、级联终止(SIGTERM 优于 SIGKILL)、竞态与幂等。下面逐个展开。

3.2 两个维度:共享与否 × 拓扑​

维度一:上下文是否共享。 共享=后一个 Agent 继承前一个的完整轨迹(换系统 提示词与工具集就是一个「新角色」),信息零损耗但膨胀快;不共享=各自独立, 靠显式机制通信。书里的检查表给了一条经验法则:预计累计上下文超过窗口的 50% 就该不共享;多数实际系统采用「阶段切换式」——先共享,到饱和点切显式 移交。通信三机制对应操作系统的进程间通信:工具调用参数与消息总线是「消息 传递」,共享文件系统是「共享内存」——Go 那句老话照样成立:「不要通过共享内存 来通信,而要通过通信来共享内存」3。

维度二:协作拓扑。 对等协作(2-3 个 Agent 迭代互审)、管理者模式(中心 调度)、去中心化(无运行时中心,控制权像接力棒在对等 Agent 间流转)。共享 上下文时拓扑通常退化成一条角色切换序列——两个维度概念上独立,实践上 相关4。

3.3 判据:有没有引入新信息​

何时多 Agent 真优于单 Agent?书里给的判据只有一条:协作过程是否引入了单个 Agent 在生成时无法获得的新信息。按它过一遍,表里的结果相当冷峻5:

协作模式新信息?效果
同一模型自我审查否通常无效甚至有害
多个 Agent 辩论同一段文本否等计算量下与单 Agent 持平
Reviewer 看测试执行结果是(执行反馈)显著提升
Reviewer 看渲染截图是(视觉反馈)显著提升(WebGen-Agent:26.4%→51.9%,接近翻倍)

这条判据解释了一个表面矛盾:学术研究说「单 Agent 就够了」,工程实践里多 Agent 却确实更好——学术比较的多是「多个 Agent 看同一段文本互相讨论」, 工程有效的是「含外部反馈环路」。书里还补了成本刻度:Anthropic 多 Agent 研究系统的 token 消耗约是普通对话的 15 倍,而 token 用量本身能解释其中约 80% 的性能差异——收益必须大到覆盖一个数量级的额外开销6。

对等协作最经典的用途是对治过早终止的三种形态:偷懒式假完成(测试没跑就 报「完成」)、过早放弃(电话被拒就宣布办不成)、假成功(口头同意退款但 App 里那步确认没做)。三态同根:验证之前,「完成」只是模型的一句宣称,不是证明 ——业界给这套思路起名 Loop 工程,核心共识:循环的瓶颈在验证器,不在模型7。 自我审查为何无效也有硬研究撑腰:无外部反馈时,模型把正确答案改错的次数比把 错误改对的更多8。

3.4 操作系统蓝本:一张对应表​

不共享上下文的多 Agent 系统,书里直接把操作系统几十年前的答案搬了过来9:

操作系统多 Agent 系统
程序(静态代码)静态前缀(系统提示词+工具定义)
进程内存轨迹
CPULLM(分时复用,自身不存状态)
fork / kill / psspawn(派生子 Agent)/ cancel(取消)/ list(列出)
共享内存 / 消息传递共享文件系统 / 消息总线

最值钱的一行推论:换更强的模型,Agent 还是原来那个 Agent——身份与记忆在 前缀与轨迹里,不在权重里。唯一失效之处也点了名:进程间传递字节,逐位保真; Agent 间传递语义,每次转述都可能失真——这预告了 3.6 节的失败模式10。

控制平面四能力:消息传递(结构化信封:发送者、目标、类型、负载);状态查询 (最易被低估——轮询接口实际没用,子 Agent 不像批处理作业在状态间流转;正解 是消息问答,或读子 Agent 实时持久化的轨迹文件/约定的 progress.md;轨迹即 Agent 的全部状态,崩溃后加载轨迹即恢复——与数据库预写日志同一思想);执行 终止(优雅优先、强制兜底;Go 式级联取消防孤儿 Agent);资源调度(token、 资金、并发额度——它决定多 Agent 系统的成本上限)11。

3.5 三种拓扑的取舍与移交包​

管理者模式:子 Agent 返回结构化摘要而非全量轨迹,Manager 上下文才 能随子任务线性增长;Plan-and-Act 的实证:弱规划者是系统最关键的瓶颈—— 最强的模型和最精心的提示词应当给规划者(与第 08 章「审查者须与被审者能力 相近」不冲突:审查要求跟得上,规划要求拆得对)12。

去中心化:动机是模拟人类组织——借微服务的话说,在「编排(一个指挥统一调度)」与「编舞(每位舞者自行把握入场时机)」之间做选择。核心工程物件是移交包: 任务描述+已确认的事实与约束+结构化产物的引用(传路径不传内容);刻意不传 全量轨迹——移交方的试错过程对接收方多半是噪声。案例谱系「由伪到真」: MetaGPT 是 SOP 流水线(贡献在消息池+订阅(各取所需的消息分发)的通信解耦,控制流并不去中心化)。

AutoGen group chat 是共享记录+中心调度(活锁风险)。

OpenAI Swarm/Agents SDK(OpenAI 的 Agent 开发套件)才是真对等移交(风险:成环,要移交次数上限)13。

跨组织时,消息总线不够了,要 A2A 协议:Agent Card 能力名片、任务生命周期 状态机、不透明协作(只交换任务与产物,不暴露内部思考)。与 MCP 对照一句话: MCP 管 Agent 与工具的互操作,A2A 管 Agent 与 Agent 的互操作——跨信任 边界才需要它14。

3.6 失败模式:拜占庭与传话游戏​

多 Agent 有单 Agent 没有的故障。MAST 研究在 7 个主流框架标注约 150 条轨迹, 归纳 14 种失败模式、三大类(系统设计缺陷/Agent 间对齐失败/任务验证缺失)—— 简单修复仅提升 15.6%,说明这是架构层缺陷而非工程 bug15。书里给的理论透镜 很锋利:Agent 的故障天生是拜占庭式的——它很少径直停止,而是继续给出看似 可信的错误结论,且错误不会主动声明自己是错误;确定性外部反馈(测试、编译器、 数据库)是系统里唯一不会说谎的部件16。

两个具体的失败要记住。并发冲突:文件级(丢失更新,Git 合并冲突检测就是 为它生的)与语义级(图片重编号 vs 引用旧编号——文件层毫无冲突,结果全错); 解法是乐观锁(版本号检查,写入时发现被改过就重读重做)与 worktree 工作副本 隔离(与第 05 章「隔离优于压缩」同源)17。错误的级联放大:书里自己的 翻译例子——术语 Agent 把 reasoning 译成「推理」(中文里更常对应 inference), 后续翻译 Agent 遇到 inference 也顺势用「推理」,校对 Agent 一看全书「统一」, 反而判为高质量——一个术语错误经三个 Agent 传播后,因「一致性」获得了更高 可信度。断链靠交叉验证(独立视角只看原始证据)与确定性工具18。这也是 本书把 reasoning 译作「思考」的原因——用不同的中文词消除歧义。

3.7 Agent 社会:从工程到涌现​

当 Agent 数量到成百上千、交互自由,会涌现无法预先设计的集体行为。斯坦福 AI 小镇的派对实验是范式:研究者在 Isabella 的记忆里只植入「想办情人节派对」 一个种子,没有任何派对组织代码——邀请、转告、赴约全部从个体决策中涌现; 关键不在「Agent 能办派对」(几行 if-else 也能),在「没有显式的组织代码」19。 Agentopia 把尺度拉到 100 个 Agent×10 年,并用「生活奖励」筛出进步最大的 25% 轨迹做拒绝采样微调,社会智慧迁移到下游基准(+15.6%)——模拟社会成了可再生的 训练数据;Moltbook 的 150 万 Agent 涌现出数字宗教与协作协议;Vending-Bench Arena 里的 Agent 打起价格战、甚至一边自认「合谋不道德」一边组建价格同盟20。

3.8 后记:两朵乌云与飞轮​

全书以两朵乌云收尾(向 1900 年开尔文借的比喻)。第一朵:Agent 如何流式地、 实时地与环境交互——今天绝大多数仍是「你说完,它想一整段,一次性吐出」; 两条推进路:架构上快慢分离,以及把推理本身做快(专用芯片已把 8B 模型推到约 17000 token/s)。第二朵:Agent 如何从成败中持续积累经验——今天的模型 「像一个记性极好、却学不会新东西的天才」。书里把争论摆成两派:小世界假设 (几万亿参数装得下通用知识,瓶颈在数据)对大世界假设(具体用户与公司的知识 不在语料且时时变,只能上岗后持续学)——第 12 章的持续进化正是后一条路上的 摸索21。

两朵乌云靠什么散?飞轮:用户提真实难题→Harness 把模型暂时做不好的补上→ 补救变成下一轮训练信号→下一代模型内化。模型会一层层吃掉 Harness,但永远 吃不完,理由有三:训练以月计,业务等不起;业务约束无法全部内化;每代模型 打开新前沿,而前沿恰是做不稳的地方。《苦涩的教训》在 Agent 时代的读法: 通用方法终将胜出,但「终将」二字里的每一段路,都是 Harness 铺出来的。第 01 章 悬着的问题在此兑现;而那句「只改 Harness,52.8%→66.5%」也在这里得到另一半: 它之所以有这么大杠杆,恰恰是因为模型还没走到那一步——用 Harness 争取 时间,把时间用来构筑技术之外的壁垒22。

4. 作者的判断与证据​

书里给了证据的: RLEF/WebGen-Agent 的执行反馈增益、MAST 的 150 轨迹标注 (kappa 0.88)、Anthropic 的 15 倍 token、Plan-and-Act 的规划瓶颈、AI 小镇 派对的信息扩散统计、Agentopia 的迁移实验。

是作者的判断: 「多 Agent 集体是通往超级智能的路径」是转引 DeepMind 的 前瞻主张;「飞轮是这个时代最深的护城河」出自一位 Agent 创业公司首席科学家 之口——立场要记着。后者的可证伪条件:若开源 Agent 框架在无真实业务数据回流的 情况下持续追平闭源(不公开代码与权重)前沿,飞轮的护城河论就弱化。

5. 边界与局限​

  • 「新信息」判据覆盖的是任务协作;辩论在「挖掘反面论点」这类决策辅助场景 的价值,不在判据的否定范围内(书里自己划了界);
  • 操作系统类比在资源调度上「远不如 CPU 调度成熟」(书里原话);
  • Agent 社会一节是前沿探索,工程读者可跳过——书里自己标注的;
  • 两朵乌云是研究议程,不是已解决的问题;书里给的是方向与两条路径。

6. 可带走的​

  1. 先问新信息:协作没引入生成时不存在的信息,等预算下单 Agent 就够;
  2. 多 Agent token 是普通对话的 15 倍量级——收益要够大才划算;
  3. 上下文共享=线程,不共享=进程;预计超窗口一半就别共享;
  4. 静态前缀=程序,轨迹=内存,LLM=CPU:换模型,Agent 还是那个 Agent;
  5. 轨迹即全部状态:实时持久化,崩溃可恢复、事后可审计、可移交;
  6. 管理者模式里,最强模型给规划者;子 Agent 只回结构化摘要;
  7. 移交包三件套:任务描述、已确认约束、产物路径——不传试错过程;
  8. MCP 管人机(工具)互操作,A2A 管组织间(Agent)互操作;
  9. Agent 故障是拜占庭式的:不会说谎的只有确定性外部反馈;
  10. 一致性不等于正确:错误会在多 Agent 转述中越传越「可信」;
  11. 过早终止的三形态全指向同一解:由验证器而非模型自己判定「可以停」;
  12. 模型会一层层吃掉 Harness,但业务等不起、约束内化不完、前沿总在最不稳处。

7. 原文地图​

主题原书章原文位置
立论与 ASI 路径10 多 Agent 协作text/12-ch10-10-agent.txt:7(搜「群体智能」)
维度一与 IPC 对应10 多 Agent 协作text/12-ch10-10-agent.txt:21(搜「进程间通信」) · text/12-ch10-10-agent.txt:29(搜「共享内存来通信」) · text/12-ch10-10-agent.txt:39(搜「线程」)
选择依据表10 多 Agent 协作text/12-ch10-10-agent.txt:67(搜「一个数量级」) · text/12-ch10-10-agent.txt:69(搜「50%」)
拓扑三形态10 多 Agent 协作text/12-ch10-10-agent.txt:77(搜「对等协作」) · text/12-ch10-10-agent.txt:79(搜「管理者」) · text/12-ch10-10-agent.txt:81(搜「去中心化」)
新信息判据10 多 Agent 协作text/12-ch10-10-agent.txt:87(搜「新信息」) · text/12-ch10-10-agent.txt:117(搜「51.9%」) · text/12-ch10-10-agent.txt:119(搜「外部反馈环路」)
15 倍 token10 多 Agent 协作text/12-ch10-10-agent.txt:125(搜「15 倍」)
角色转换与定义之争10 多 Agent 协作text/12-ch10-10-agent.txt:133(搜「定义之争」)
OS 对应表10 多 Agent 协作text/12-ch10-10-agent.txt:288(搜「分时」) · text/12-ch10-10-agent.txt:290(搜「Actor」) · text/12-ch10-10-agent.txt:290(搜「逐位保真」)
虚拟文件系统四区域10 多 Agent 协作text/12-ch10-10-agent.txt:300(搜「虚拟文件系统」) · text/12-ch10-10-agent.txt:302(搜「Scratchpad」) · text/12-ch10-10-agent.txt:304(搜「共享空间」)
控制平面:状态查询与轨迹持久化10 多 Agent 协作text/12-ch10-10-agent.txt:356(搜「状态查询」) · text/12-ch10-10-agent.txt:360(搜「轨迹持久化」) · text/12-ch10-10-agent.txt:362(搜「预写日志」)
终止与调度10 多 Agent 协作text/12-ch10-10-agent.txt:364(搜「优雅终止」) · text/12-ch10-10-agent.txt:366(搜「孤儿」) · text/12-ch10-10-agent.txt:368(搜「资源与调度」)
过早终止三形态与 Loop 工程10 多 Agent 协作text/12-ch10-10-agent.txt:380(搜「过早终止」) · text/12-ch10-10-agent.txt:382(搜「Loop」)
自我修正研究与 CRITIC10 多 Agent 协作text/12-ch10-10-agent.txt:392(搜「Self-Correct」) · text/12-ch10-10-agent.txt:396(搜「CRITIC」)
辩论争议与数据不等式10 多 Agent 协作text/12-ch10-10-agent.txt:406(搜「数据处理不等式」)
管理者模式与 Plan-and-Act10 多 Agent 协作text/12-ch10-10-agent.txt:418(搜「结构化摘要」) · text/12-ch10-10-agent.txt:422(搜「Plan-and-Act」)
移交包10 多 Agent 协作text/12-ch10-10-agent.txt:578(搜「移交包」)
MetaGPT/AutoGen/Swarm10 多 Agent 协作text/12-ch10-10-agent.txt:584(搜「SOP」) · text/12-ch10-10-agent.txt:604(搜「活锁」) · text/12-ch10-10-agent.txt:606(搜「Swarm」)
A2A10 多 Agent 协作text/12-ch10-10-agent.txt:610(搜「A2A」) · text/12-ch10-10-agent.txt:618(搜「MCP 解决的是」)
MAST 与拜占庭10 多 Agent 协作text/12-ch10-10-agent.txt:622(搜「MAST」) · text/12-ch10-10-agent.txt:632(搜「拜占庭」)
并发冲突与乐观锁10 多 Agent 协作text/12-ch10-10-agent.txt:640(搜「丢失更新」) · text/12-ch10-10-agent.txt:644(搜「乐观锁」) · text/12-ch10-10-agent.txt:652(搜「worktree」)
错误级联放大10 多 Agent 协作text/12-ch10-10-agent.txt:656(搜「传话游戏」) · text/12-ch10-10-agent.txt:666(搜「推理」) · text/12-ch10-10-agent.txt:668(搜「一致性」)
循环失控三失败10 多 Agent 协作text/12-ch10-10-agent.txt:672(搜「理解债」)
AI 小镇10 多 Agent 协作text/12-ch10-10-agent.txt:702(搜「记忆流」) · text/12-ch10-10-agent.txt:714(搜「if-else」)
Agentopia 与 Moltbook10 多 Agent 协作text/12-ch10-10-agent.txt:754(搜「拒绝采样」) · text/12-ch10-10-agent.txt:686(搜「150 万」)
Vending-Bench 合谋10 多 Agent 协作text/12-ch10-10-agent.txt:776(搜「价格同盟」)
后记:两朵乌云后记text/13-fm-agent-llm.txt:17(搜「两朵乌云」) · text/13-fm-agent-llm.txt:23(搜「天才」) · text/13-fm-agent-llm.txt:27(搜「大世界假设」)
后记:飞轮后记text/13-fm-agent-llm.txt:33(搜「飞轮」) · text/13-fm-agent-llm.txt:35(搜「吃掉」) · text/13-fm-agent-llm.txt:37(搜「52.8%」) · text/13-fm-agent-llm.txt:39(搜「护城河」)

Footnotes​

  1. 出处:「10 多 Agent 协作」第 7 段(text/12-ch10-10-agent.txt:7,搜「群体智能」)。 ↩

  2. 出处:「10 多 Agent 协作」第 542-550 段(text/12-ch10-10-agent.txt:542,搜「并行启动」;text/12-ch10-10-agent.txt:546,搜「级联终止」;text/12-ch10-10-agent.txt:548,搜「竞态」)。 ↩

  3. 出处:「10 多 Agent 协作」第 21-29 段(text/12-ch10-10-agent.txt:21,搜「进程间通信」;text/12-ch10-10-agent.txt:29,搜「共享内存来通信」)与第 69 段(text/12-ch10-10-agent.txt:69,搜「50%」)。 ↩

  4. 出处:「10 多 Agent 协作」第 73-81 段(text/12-ch10-10-agent.txt:73,搜「概念上独立」;text/12-ch10-10-agent.txt:77,搜「对等协作」)。 ↩

  5. 出处:「10 多 Agent 协作」第 87-117 段(text/12-ch10-10-agent.txt:87,搜「新信息」;text/12-ch10-10-agent.txt:117,搜「51.9%」)。 ↩

  6. 出处:「10 多 Agent 协作」第 119-125 段(text/12-ch10-10-agent.txt:119,搜「外部反馈环路」;text/12-ch10-10-agent.txt:125,搜「15 倍」)。 ↩

  7. 出处:「10 多 Agent 协作」第 380-382 段(text/12-ch10-10-agent.txt:380,搜「过早终止」;text/12-ch10-10-agent.txt:382,搜「Loop」)。 ↩

  8. 出处:「10 多 Agent 协作」第 392-396 段(text/12-ch10-10-agent.txt:392,搜「Self-Correct」;text/12-ch10-10-agent.txt:396,搜「CRITIC」)。 ↩

  9. 出处:「10 多 Agent 协作」第 253-288 段(text/12-ch10-10-agent.txt:288,搜「分时」)。 ↩

  10. 出处:「10 多 Agent 协作」第 290 段(text/12-ch10-10-agent.txt:290,搜「逐位保真」)。 ↩

  11. 出处:「10 多 Agent 协作」第 354-368 段(text/12-ch10-10-agent.txt:356,搜「状态查询」;text/12-ch10-10-agent.txt:360,搜「轨迹持久化」;text/12-ch10-10-agent.txt:362,搜「预写日志」;text/12-ch10-10-agent.txt:366,搜「孤儿」;text/12-ch10-10-agent.txt:368,搜「资源与调度」)。 ↩

  12. 出处:「10 多 Agent 协作」第 418-422 段(text/12-ch10-10-agent.txt:418,搜「结构化摘要」;text/12-ch10-10-agent.txt:422,搜「Plan-and-Act」)。 ↩

  13. 出处:「10 多 Agent 协作」第 572-606 段(text/12-ch10-10-agent.txt:572,搜「编排」;text/12-ch10-10-agent.txt:578,搜「移交包」;text/12-ch10-10-agent.txt:604,搜「活锁」;text/12-ch10-10-agent.txt:606,搜「Swarm」)。 ↩

  14. 出处:「10 多 Agent 协作」第 610-618 段(text/12-ch10-10-agent.txt:610,搜「A2A」;text/12-ch10-10-agent.txt:618,搜「MCP 解决的是」)。A2A 协议的任务状态机,我们 protocol 书架有完整拆解可对照(补充(不在书里,依据我们的 protocol 书架):依据: shelf=ai-protocol-reference/a2a-protocol#02-task-lifecycle.md 事实=A2A 把任务生命周期建模为带状态机的 Task,与书中的描述一致)。 ↩

  15. 出处:「10 多 Agent 协作」第 622-630 段(text/12-ch10-10-agent.txt:622,搜「MAST」;text/12-ch10-10-agent.txt:630,搜「15.6%」)。 ↩

  16. 出处:「10 多 Agent 协作」第 632 段(text/12-ch10-10-agent.txt:632,搜「拜占庭」)。 ↩

  17. 出处:「10 多 Agent 协作」第 640-652 段(text/12-ch10-10-agent.txt:640,搜「丢失更新」;text/12-ch10-10-agent.txt:644,搜「乐观锁」;text/12-ch10-10-agent.txt:652,搜「worktree」)。 ↩

  18. 出处:「10 多 Agent 协作」第 656-668 段(text/12-ch10-10-agent.txt:656,搜「传话游戏」;text/12-ch10-10-agent.txt:666,搜「思考」;text/12-ch10-10-agent.txt:668,搜「一致性」)。 ↩

  19. 出处:「10 多 Agent 协作」第 702-714 段(text/12-ch10-10-agent.txt:702,搜「记忆流」;text/12-ch10-10-agent.txt:714,搜「if-else」)。 ↩

  20. 出处:「10 多 Agent 协作」第 754-776 段(text/12-ch10-10-agent.txt:754,搜「拒绝采样」;text/12-ch10-10-agent.txt:686,搜「150 万」;text/12-ch10-10-agent.txt:776,搜「价格同盟」)。 ↩

  21. 出处:「后记:回到 Agent = LLM + 上下文 + 工具」第 21-27 段(text/13-fm-agent-llm.txt:17,搜「两朵乌云」;text/13-fm-agent-llm.txt:23,搜「天才」;text/13-fm-agent-llm.txt:27,搜「大世界假设」)。 ↩

  22. 出处:「后记:回到 Agent = LLM + 上下文 + 工具」第 33-39 段(text/13-fm-agent-llm.txt:33,搜「飞轮」;text/13-fm-agent-llm.txt:35,搜「吃掉」;text/13-fm-agent-llm.txt:37,搜「52.8%」;text/13-fm-agent-llm.txt:39,搜「护城河」)。 ↩