首先感谢datawhale教程地址https://github.com/bojieli/ai-agent-book/tree/main概念学习1 Single-Agent 与 Multi-Agent 的区别一句话区别不是几个 Agent 在跑而是有没有引入单个 Agent 生成时无法获得的新信息。协作模式是否引入新信息效果同一模型自我审查否通常无效甚至有害不同 Agent 辩论同一段文本否等计算量下与单 Agent 持平审核者使用测试执行结果审查代码是执行反馈显著提升审核者查看渲染截图审查前端/PPT是视觉反馈显著提升审核者使用外部工具验证事实是工具反馈显著提升单 Agent 真正的天花板原书开篇PAGE 272单个 Agent 终究受限于自身的模型能力边界和上下文窗口。注意是两个限制不只是上下文——很多人只记得前者。但原书立刻给了一个诚实的补充 ⚠️在 OpenAI 五级能力框架中多 Agent 协作常被类比为通向第五级Organizations的路径之一。**需要说明的是此处 Organizations 指的是AI 能完成整个组织的工作这一能力级别而非对系统架构的要求足够强大的单个 Agent 理论上也能达到。**即多 Agent 不是目的是手段。 达到同一能力级别架构上未必非要多个 Agent。一个必须能说清的矛盾一些学术研究认为多 Agent 并不能提升 Agent 能力上限但工程实践中多 Agent 确实表现得更好。矛盾的根源在于两者讨论的是不同类型的多 Agent学术研究中比较的多是「多个 Agent 看着同一段上下文互相讨论」工程实践中有效的多 Agent 往往包含外部反馈环路代码执行、视觉渲染、工具调用。前者没有引入新信息后者引入了。2 多 Agent 中的角色设计两个基础维度10.1上下文是否共享共享后续 Agent 继承前序完整轨迹信息不丢但上下文易膨胀、有角色惯性。不共享每个 Agent 独立上下文靠显式通信交换产物模块化好、可并发但需设计接口。协作拓扑对等协作Peer2–3 个平等 Agent 迭代互评如提议者-审核者、辩论、头脑风暴、专家小组。管理者Orchestration中心 Manager 拆解、调度、整合子 Agent 各司其职。去中心化Decentralized无中心调度控制权在 Agent 间流转如 OpenAI Swarm 的 handoff、MetaGPT 的消息池 订阅、AutoGen 的 group chat。角色设计的关键原则每个角色的 system prompt 要明确职责边界、输入、输出格式、验收标准而不是笼统描述。角色之间的差异应主动体现在模型、上下文、工具、可见证据或职责上否则会同质趋同——同一模型、相似上下文生成的多个意见不能自动视为独立证据Anthropic 实验30 个 Agent 有 18 个创建了同名 Git 分支。角色规程的载体选择如果角色差异主要是知识/流程/写作风格用 Skill固定 system prompt 按需加载如果涉及权限、工具隔离、合规边界用独立 Agent 或transfer_to_agent替换 system prompt 工具集并在 Harness 层用代码强制。3.3 任务拆解与角色分工管理者模式的拆解流程以书籍翻译为例Glossary Agent识别全书术语产出glossary.json术语、译法、语境。Translation Agent × N每章一个实例输入 当前章节 术语表 翻译指南输出chapterN_zh.md。Proofreading Agent读全部译文 术语表产出review_report.md。Manager Agent只维护任务描述、执行计划、各 Agent 调用记录和文件索引不装全文。拆解的核心原则上下文隔离每个 Agent 只看与自己职责相关的最小信息避免信息过载导致注意力分散。产物落盘大产物写文件Agent 之间传路径字符串而不是全文内容。Manager 保留全局视图但不背全文它知道哪一章在哪个文件不需要把每章内容装进上下文。Plan-and-Act 的启示弱规划者是整个系统最关键的瓶颈应把最强的模型和最精心的提示词分配给 Manager而不是平均分配。3.4 Agent 之间的信息传递与协作三种通信机制不共享上下文时机制对应 IPC 范式适用场景工具调用参数消息传递同步结构清晰、类型确定的短数据共享文件系统共享内存产物大、需持久化、多方读写消息总线消息传递异步Agent 多、需异步并行、解耦收发Agent 虚拟文件系统的四类区域表10-3区域可见性生命周期读写并发控制Agent 专属工作区/scratch/id仅该 Agent随实例销毁读写不需要多 Agent 共享空间/workspace/shared所有 Agent 用户随任务持续读写需要乐观锁 / worktree外部挂载资源/mnt/gdrive视外部授权由外部源决定多为只读由外部源负责系统内置资源/skills所有 Agent跨会话稳定只读不需要控制平面的四个原语对应操作系统spawn_subagent↔ forksend_message_to_subagent↔ 消息cancel_subagent↔ kill优雅终止 SIGTERM / 强制终止 SIGKILLlist_agents↔ ps终止的级联借鉴 Go 的context取消一个 Agent它派生的所有子 Agent 随之取消避免孤儿 Agent。跨组织协作A2A 协议Agent Card 任务生命周期状态机 不透明协作与 MCPAgent 与工具分工不同。3.5 典型多 Agent 工作流Planner → Researcher → Executor → Reviewer书中最接近这个形状的是管理者模式10.4.4和提议者-审核者10.4.3.2的组合。角色职责关键设计要点Planner把模糊目标拆成可执行步骤输出结构化步骤 每步的输入、输出、验收标准不执行任务Researcher为每步收集证据必须带来源线索区分可确认事实与一般性知识Executor基于计划和笔记产出答案严格引用笔记不引入笔记外事实笔记未覆盖处要明说Reviewer独立审查产物必须拿到 Executor 看不到的证据原始笔记、独立清单退回时给出可定位的修复条件提议者-审核者的最小不变量书中伪代码textcandidate proposer(task, constraints) evidence execute_or_render(candidate) # 测试 / 状态 / 截图 / 事实 review independent_reviewer(candidate, evidence) while review.veto and budget_remaining: candidate proposer.repair(candidate, review.findings) evidence execute_or_render(candidate) review independent_reviewer(candidate, evidence) if review.pass: publish(candidate, evidence, review) else: escalate_or_reject(review)审核者不能修改测试、证据采集器或发布门槛否则独立验证退化为自我批准。3.6 什么时候该用多 Agent什么时候单 Agent 就够场景建议理由任务简单、边界清晰、一个上下文能装下单 Agent多 Agent 的额外 token 成本换不来信息增量需要执行反馈测试、渲染、工具验证多 AgentReviewer 拿到了 Executor 生成时不存在的新信息需要多来源交叉验证 / 独立搜索多 Agent覆盖不同信息源避免单一检索盲区只是让模型再检查一遍单 Agent即可无新信息自我审查效果有限甚至有害子任务可并行且依赖少多 Agent真正的时间加速 上下文隔离子任务严格串行、上下文够用单 Agent 工作流多 Agent 增加通信与同步成本成本提醒多 Agent 的并行探索和反复迭代要消耗数倍乃至一个数量级的 token收益必须覆盖这些开销否则一个调校得当的单 Agent 更划算。实验学习一实验结果打印单 Agent 基线多Agent协作并不总是比单Agent更优因为协作过程中存在通信成本、协调难度和同步问题可能导致整体效率降低。例如当任务简单、环境稳定且Agent间无需共享信息时单Agent可以更快地完成任务。而一个具体的判据是当任务复杂需要多个Agent共同处理且各Agent之间需要共享信息、协同决策时采用多Agent协作会更合适。此时多Agent可以发挥各自优势提高整体效率和解决问题的能力。[tokens] 173四角色 · Reviewer 有笔记--- Plan ---[{step: 1, action: 定义多 Agent 协作和单 Agent 的概念, expected_output: 解释多 Agent 协作和单 Agent 的定义, acceptance: 用户能够理解多 Agent 协作和单 Agent 的基本概念}, {step: 2, action: 列出多 Agent 协作可能的优势, expected_output: 列出至少两个多 Agent 协作可能的优势, acceptance: 用户能够理解多 Agent 协作的一些潜在好处}, {step: 3, action: 列出多 Agent 协作可能的不利因素, expected_output: 列出至少两个多 Agent 协作可能的不利因素, acceptance: 用户能够理解多 Agent 协作的一些潜在问题}, {step: 4, action: 提供一个具体的判据用于判断何时使用多 Agent, expected_output: 提出一个具体的判据说明在什么情况下应该使用多 Agent, acceptance: 用户能够根据提出的判据判断何时使用多 Agent}]--- Research ---[{step: 1, fact: 多 Agent 协作指的是多个智能体Agent相互协作以完成一个共同的任务或目标。, source: 一般性知识无外部来源}, {step: 1, fact: 单 Agent 指的是一个独立的智能体它没有与其他智能体协作的能力。, source: 一般性知识无外部来源}, {step: 2, fact: 多 Agent 协作可能的优势之一是提高任务处理的效率因为多个智能体可以同时工作。, source: 一般性知识无外部来源}, {step: 2, fact: 另一个优势是增强系统的鲁棒性因为即使一个智能体失败其他智能体仍然可以继续工作。, source: 一般性知识无外部来源}, {step: 3, fact: 多 Agent 协作可能的不利因素之一是通信开销智能体之间需要交换信息这可能导致额外的计算负担。, source: 一般性知识无外部来源}, {step: 3, fact: 另一个不利因素是协调复杂性多个智能体之间的协作可能需要复杂的协调机制。, source: 一般性知识无外部来源}, {step: 4, fact: 一个具体的判据是当任务需要处理大量数据或执行复杂的决策时使用多 Agent 协作可以提高处理速度和决策质量。, source: 一般性知识无外部来源}]--- Answer ---多 Agent 协作是指多个智能体Agent相互协作以完成一个共同的任务或目标而单 Agent 指的是一个独立的智能体它没有与其他智能体协作的能力。多 Agent 协作可能的优势包括提高任务处理的效率因为多个智能体可以同时工作以及增强系统的鲁棒性即使一个智能体失败其他智能体仍然可以继续工作。然而多 Agent 协作也存在不利因素如通信开销和协调复杂性智能体之间需要交换信息这可能导致额外的计算负担并且需要复杂的协调机制。一个具体的判据是当任务需要处理大量数据或执行复杂的决策时使用多 Agent 协作可以提高处理速度和决策质量。因此如果任务的数据量巨大或决策过程复杂那么多 Agent 协作可能是一个更好的选择。--- Review ---{pass: true,issues: []}[tokens] 3016消融 · Reviewer 无笔记--- Review ---json{pass: true,issues: []}[tokens] 2600run Multi(no notes) Multi(notes) SingleagentExecutor 896 917 0Planner 394 397 0Researcher 716 732 0Reviewer_no_notes 594 0 0Reviewer_with_notes 0 970 0SingleAgent 0 0 173总 token 对比Single: 173Multi(notes): 3016Multi(no notes): 2600总结1、token 17 倍但答案质量没有提升方案token答案特征单 Agent173简洁直接给出判据多 Agent有笔记301617.4×更罗列、更模板化没有新增事实多 Agent无笔记260015.0×—书中明确说多 Agent 带来的收益必须足够大能够覆盖数倍乃至一个数量级的额外开销否则一个调校得当的单 Agent 往往是更划算的选择。这里 17 倍成本换来的答案论信息量反而不如单 Agent——这正是无效多 Agent的典型。2、Researcher 的 source 全是一般性知识无外部来源看研究笔记source: 一般性知识无外部来源× 7 条全部如此。这意味着Researcher 没有引入任何单 Agent 看不到的信息——它只是把 GLM-4-Flash 自己脑子里已有的东西重新组织了一遍。这正是书中的核心判据失效多 Agent 是否真正优于单 Agent核心判据只有一条——协作过程是否引入了单个 Agent 在生成时无法获得的新信息。Researcher 没接搜索工具、没读外部文档它和单 Agent 用的是同一个模型的同一份内部知识。所以后面 Executor 和 Reviewer 再怎么努力都只是在同一份信息上反复加工。3、Reviewer 两次都pass: true、issues: []这是最值得警惕的一条有笔记版970 tokens理论上应该能发现这条 fact 没有来源——但它直接pass。无笔记版594 tokens也pass。两者 output 完全一样。这说明Reviewer 根本没有做逐条核对它只做了读一遍感觉还行放行这种表层审查。书中把这种失败叫同质趋同Homogeneous Convergence同一模型、相似上下文生成的多个审核意见不能自动视为相互独立的证据。这里更极端Reviewer 连是否独立都没做到它和 Executor 是同一个 GLM-4-Flash、同一种写作风格天然倾向于认可对方的输出。这就是书中 ICLR 2024 那篇论文的结论——没有外部反馈时模型自我审查几乎不起作用。实验学习二实验结果打印单 Agent 一次性翻译 chapter1 人工智能代理是一种以大型语言模型作为其推理核心的系统。代理通过循环操作观察环境、决定行动并调用工具来改变世界。ReAct 模式将这一循环形式化为推理、行动和观察。一个框架包围着模型并管理上下文、工具接口、约束、验证和修正。提示注入是一种核心安全威胁攻击者将指令隐藏在外部内容中如网页代理可能会执行这些指令。 chapter2 记忆和知识是两回事。用户记忆存储跨会话的偏好和过去交互而知识库存储共享的领域文档。检索增强生成RAG检索相关片段并在模型生成答案之前将其注入上下文中。一个常见的失败是代理检索了过多的不相关片段这会分散注意力并增加成本。分块策略、嵌入模型选择和重新排序都会影响检索质量。[tokens] 472 多 Agent 流水线 [Glossary] 提取 11 个术语[Translation] chapter1 完成171 字[Translation] chapter2 完成149 字[Proofreading] 一致None, 问题数0--- Manager 最终说明 ---术语一致性通过无问题需要返工。交付状态术语一致译文无误。[tokens] 3321--- 多 Agent 译文chapter1---人工智能代理是一种使用大型语言模型作为其推理核心的系统。该代理在一个循环中运行它观察环境决定一个动作并调用一个工具来改变世界。ReAct 模式将这个循环形式化为推理、行动和观察。一个约束框架围绕着模型并管理上下文、工具接口、约束、验证和纠正。提示注入是一个核心安全威胁攻击者将指令隐藏在外部内容如网页中代理可能会执行它们。--- 多 Agent 审校报告 ---{consistent: null,issues: []}Token 对比Single: 472Multi: 3321倍率: 7.04x多 Agent 各角色 tokenGlossary total 671 calls1Translation_chapter1 total 696 calls1Translation_chapter2 total 673 calls1Proofreading total 723 calls1Manager_final total 558 calls1术语表AI agent - 人工智能代理 (准确反映其作为智能系统的角色)large language model - 大型语言模型 (直接对应英文术语避免误解)ReAct pattern - ReAct 模式 (保持原术语便于专业交流)harness - 约束框架 (准确描述其功能避免误解为马具)prompt injection - 提示注入攻击 (强调安全威胁性质避免误解为普通注入)user memory - 用户记忆 (强调记忆的所属主体)knowledge base - 知识库 (直接对应英文术语避免误解)retrieval-augmented generation - 检索增强生成 (准确描述技术特点)chunking strategy - 分块策略 (直接对应英文术语便于专业交流)embedding model - 嵌入模型 (直接对应英文术语便于专业交流)reranking - 重新排序 (直接对应英文术语便于专业交流)总结复现了书中实验10-2书籍翻译 Agent的管理者模式以两章技术文本为对象用 GLM-4-Flash 跑了 Glossary / Translation×2 / Proofreading / Manager 四角色流水线与单 Agent 基线。结果显示上下文隔离有效Manager 只消耗 558 token低于其他角色确实没背全文符合书中Manager 上下文保持在可管理范围内的设计目标。成本 7.0× 但质量未提升多 Agent 译文在术语上更照表但出现了约束框架……约束……这类因术语窄化导致的同句重复比单 Agent 更生硬。Proofreading 返回consistent: nullGLM-4-Flash 未严格遵循 JSON schematry_parse_json把不合规输出静默降级成None掩盖了执行失败。Manager 在信息缺失时编造结论输入consistent: null输出术语一致性通过无问题需要返工——这是书中 10.5.2错误级联放大的典型信息在一次转述中从未确定变成了通过且下游用户会信以为真。结论多 Agent 的风险不只在于成本高收益低实验一 的问题更在于链条中某个环节静默失败后下游角色替它编造结论。改进方向是给 Manager 加信息完整性检查null必须报审校未完成、用确定性检查器替代抽象 LLM 审查、让 Glossary 的译法选择更保守。 
长河君 · 2026/10/28 19:03:30 · 阅读 1.2k agent学习笔记6
首先感谢datawhale教程地址https://github.com/bojieli/ai-agent-book/tree/main概念学习1 Single-Agent 与 Multi-Agent 的区别一句话区别不是几个 Agent 在跑而是有没有引入单个 Agent 生成时无法获得的新信息。协作模式是否引入新信息效果同一模型自我审查否通常无效甚至有害不同 Agent 辩论同一段文本否等计算量下与单 Agent 持平审核者使用测试执行结果审查代码是执行反馈显著提升审核者查看渲染截图审查前端/PPT是视觉反馈显著提升审核者使用外部工具验证事实是工具反馈显著提升单 Agent 真正的天花板原书开篇PAGE 272单个 Agent 终究受限于自身的模型能力边界和上下文窗口。注意是两个限制不只是上下文——很多人只记得前者。但原书立刻给了一个诚实的补充 ⚠️在 OpenAI 五级能力框架中多 Agent 协作常被类比为通向第五级Organizations的路径之一。**需要说明的是此处 Organizations 指的是AI 能完成整个组织的工作这一能力级别而非对系统架构的要求足够强大的单个 Agent 理论上也能达到。**即多 Agent 不是目的是手段。 达到同一能力级别架构上未必非要多个 Agent。一个必须能说清的矛盾一些学术研究认为多 Agent 并不能提升 Agent 能力上限但工程实践中多 Agent 确实表现得更好。矛盾的根源在于两者讨论的是不同类型的多 Agent学术研究中比较的多是「多个 Agent 看着同一段上下文互相讨论」工程实践中有效的多 Agent 往往包含外部反馈环路代码执行、视觉渲染、工具调用。前者没有引入新信息后者引入了。2 多 Agent 中的角色设计两个基础维度10.1上下文是否共享共享后续 Agent 继承前序完整轨迹信息不丢但上下文易膨胀、有角色惯性。不共享每个 Agent 独立上下文靠显式通信交换产物模块化好、可并发但需设计接口。协作拓扑对等协作Peer2–3 个平等 Agent 迭代互评如提议者-审核者、辩论、头脑风暴、专家小组。管理者Orchestration中心 Manager 拆解、调度、整合子 Agent 各司其职。去中心化Decentralized无中心调度控制权在 Agent 间流转如 OpenAI Swarm 的 handoff、MetaGPT 的消息池 订阅、AutoGen 的 group chat。角色设计的关键原则每个角色的 system prompt 要明确职责边界、输入、输出格式、验收标准而不是笼统描述。角色之间的差异应主动体现在模型、上下文、工具、可见证据或职责上否则会同质趋同——同一模型、相似上下文生成的多个意见不能自动视为独立证据Anthropic 实验30 个 Agent 有 18 个创建了同名 Git 分支。角色规程的载体选择如果角色差异主要是知识/流程/写作风格用 Skill固定 system prompt 按需加载如果涉及权限、工具隔离、合规边界用独立 Agent 或transfer_to_agent替换 system prompt 工具集并在 Harness 层用代码强制。3.3 任务拆解与角色分工管理者模式的拆解流程以书籍翻译为例Glossary Agent识别全书术语产出glossary.json术语、译法、语境。Translation Agent × N每章一个实例输入 当前章节 术语表 翻译指南输出chapterN_zh.md。Proofreading Agent读全部译文 术语表产出review_report.md。Manager Agent只维护任务描述、执行计划、各 Agent 调用记录和文件索引不装全文。拆解的核心原则上下文隔离每个 Agent 只看与自己职责相关的最小信息避免信息过载导致注意力分散。产物落盘大产物写文件Agent 之间传路径字符串而不是全文内容。Manager 保留全局视图但不背全文它知道哪一章在哪个文件不需要把每章内容装进上下文。Plan-and-Act 的启示弱规划者是整个系统最关键的瓶颈应把最强的模型和最精心的提示词分配给 Manager而不是平均分配。3.4 Agent 之间的信息传递与协作三种通信机制不共享上下文时机制对应 IPC 范式适用场景工具调用参数消息传递同步结构清晰、类型确定的短数据共享文件系统共享内存产物大、需持久化、多方读写消息总线消息传递异步Agent 多、需异步并行、解耦收发Agent 虚拟文件系统的四类区域表10-3区域可见性生命周期读写并发控制Agent 专属工作区/scratch/id仅该 Agent随实例销毁读写不需要多 Agent 共享空间/workspace/shared所有 Agent 用户随任务持续读写需要乐观锁 / worktree外部挂载资源/mnt/gdrive视外部授权由外部源决定多为只读由外部源负责系统内置资源/skills所有 Agent跨会话稳定只读不需要控制平面的四个原语对应操作系统spawn_subagent↔ forksend_message_to_subagent↔ 消息cancel_subagent↔ kill优雅终止 SIGTERM / 强制终止 SIGKILLlist_agents↔ ps终止的级联借鉴 Go 的context取消一个 Agent它派生的所有子 Agent 随之取消避免孤儿 Agent。跨组织协作A2A 协议Agent Card 任务生命周期状态机 不透明协作与 MCPAgent 与工具分工不同。3.5 典型多 Agent 工作流Planner → Researcher → Executor → Reviewer书中最接近这个形状的是管理者模式10.4.4和提议者-审核者10.4.3.2的组合。角色职责关键设计要点Planner把模糊目标拆成可执行步骤输出结构化步骤 每步的输入、输出、验收标准不执行任务Researcher为每步收集证据必须带来源线索区分可确认事实与一般性知识Executor基于计划和笔记产出答案严格引用笔记不引入笔记外事实笔记未覆盖处要明说Reviewer独立审查产物必须拿到 Executor 看不到的证据原始笔记、独立清单退回时给出可定位的修复条件提议者-审核者的最小不变量书中伪代码textcandidate proposer(task, constraints) evidence execute_or_render(candidate) # 测试 / 状态 / 截图 / 事实 review independent_reviewer(candidate, evidence) while review.veto and budget_remaining: candidate proposer.repair(candidate, review.findings) evidence execute_or_render(candidate) review independent_reviewer(candidate, evidence) if review.pass: publish(candidate, evidence, review) else: escalate_or_reject(review)审核者不能修改测试、证据采集器或发布门槛否则独立验证退化为自我批准。3.6 什么时候该用多 Agent什么时候单 Agent 就够场景建议理由任务简单、边界清晰、一个上下文能装下单 Agent多 Agent 的额外 token 成本换不来信息增量需要执行反馈测试、渲染、工具验证多 AgentReviewer 拿到了 Executor 生成时不存在的新信息需要多来源交叉验证 / 独立搜索多 Agent覆盖不同信息源避免单一检索盲区只是让模型再检查一遍单 Agent即可无新信息自我审查效果有限甚至有害子任务可并行且依赖少多 Agent真正的时间加速 上下文隔离子任务严格串行、上下文够用单 Agent 工作流多 Agent 增加通信与同步成本成本提醒多 Agent 的并行探索和反复迭代要消耗数倍乃至一个数量级的 token收益必须覆盖这些开销否则一个调校得当的单 Agent 更划算。实验学习一实验结果打印单 Agent 基线多Agent协作并不总是比单Agent更优因为协作过程中存在通信成本、协调难度和同步问题可能导致整体效率降低。例如当任务简单、环境稳定且Agent间无需共享信息时单Agent可以更快地完成任务。而一个具体的判据是当任务复杂需要多个Agent共同处理且各Agent之间需要共享信息、协同决策时采用多Agent协作会更合适。此时多Agent可以发挥各自优势提高整体效率和解决问题的能力。[tokens] 173四角色 · Reviewer 有笔记--- Plan ---[{step: 1, action: 定义多 Agent 协作和单 Agent 的概念, expected_output: 解释多 Agent 协作和单 Agent 的定义, acceptance: 用户能够理解多 Agent 协作和单 Agent 的基本概念}, {step: 2, action: 列出多 Agent 协作可能的优势, expected_output: 列出至少两个多 Agent 协作可能的优势, acceptance: 用户能够理解多 Agent 协作的一些潜在好处}, {step: 3, action: 列出多 Agent 协作可能的不利因素, expected_output: 列出至少两个多 Agent 协作可能的不利因素, acceptance: 用户能够理解多 Agent 协作的一些潜在问题}, {step: 4, action: 提供一个具体的判据用于判断何时使用多 Agent, expected_output: 提出一个具体的判据说明在什么情况下应该使用多 Agent, acceptance: 用户能够根据提出的判据判断何时使用多 Agent}]--- Research ---[{step: 1, fact: 多 Agent 协作指的是多个智能体Agent相互协作以完成一个共同的任务或目标。, source: 一般性知识无外部来源}, {step: 1, fact: 单 Agent 指的是一个独立的智能体它没有与其他智能体协作的能力。, source: 一般性知识无外部来源}, {step: 2, fact: 多 Agent 协作可能的优势之一是提高任务处理的效率因为多个智能体可以同时工作。, source: 一般性知识无外部来源}, {step: 2, fact: 另一个优势是增强系统的鲁棒性因为即使一个智能体失败其他智能体仍然可以继续工作。, source: 一般性知识无外部来源}, {step: 3, fact: 多 Agent 协作可能的不利因素之一是通信开销智能体之间需要交换信息这可能导致额外的计算负担。, source: 一般性知识无外部来源}, {step: 3, fact: 另一个不利因素是协调复杂性多个智能体之间的协作可能需要复杂的协调机制。, source: 一般性知识无外部来源}, {step: 4, fact: 一个具体的判据是当任务需要处理大量数据或执行复杂的决策时使用多 Agent 协作可以提高处理速度和决策质量。, source: 一般性知识无外部来源}]--- Answer ---多 Agent 协作是指多个智能体Agent相互协作以完成一个共同的任务或目标而单 Agent 指的是一个独立的智能体它没有与其他智能体协作的能力。多 Agent 协作可能的优势包括提高任务处理的效率因为多个智能体可以同时工作以及增强系统的鲁棒性即使一个智能体失败其他智能体仍然可以继续工作。然而多 Agent 协作也存在不利因素如通信开销和协调复杂性智能体之间需要交换信息这可能导致额外的计算负担并且需要复杂的协调机制。一个具体的判据是当任务需要处理大量数据或执行复杂的决策时使用多 Agent 协作可以提高处理速度和决策质量。因此如果任务的数据量巨大或决策过程复杂那么多 Agent 协作可能是一个更好的选择。--- Review ---{pass: true,issues: []}[tokens] 3016消融 · Reviewer 无笔记--- Review ---json{pass: true,issues: []}[tokens] 2600run Multi(no notes) Multi(notes) SingleagentExecutor 896 917 0Planner 394 397 0Researcher 716 732 0Reviewer_no_notes 594 0 0Reviewer_with_notes 0 970 0SingleAgent 0 0 173总 token 对比Single: 173Multi(notes): 3016Multi(no notes): 2600总结1、token 17 倍但答案质量没有提升方案token答案特征单 Agent173简洁直接给出判据多 Agent有笔记301617.4×更罗列、更模板化没有新增事实多 Agent无笔记260015.0×—书中明确说多 Agent 带来的收益必须足够大能够覆盖数倍乃至一个数量级的额外开销否则一个调校得当的单 Agent 往往是更划算的选择。这里 17 倍成本换来的答案论信息量反而不如单 Agent——这正是无效多 Agent的典型。2、Researcher 的 source 全是一般性知识无外部来源看研究笔记source: 一般性知识无外部来源× 7 条全部如此。这意味着Researcher 没有引入任何单 Agent 看不到的信息——它只是把 GLM-4-Flash 自己脑子里已有的东西重新组织了一遍。这正是书中的核心判据失效多 Agent 是否真正优于单 Agent核心判据只有一条——协作过程是否引入了单个 Agent 在生成时无法获得的新信息。Researcher 没接搜索工具、没读外部文档它和单 Agent 用的是同一个模型的同一份内部知识。所以后面 Executor 和 Reviewer 再怎么努力都只是在同一份信息上反复加工。3、Reviewer 两次都pass: true、issues: []这是最值得警惕的一条有笔记版970 tokens理论上应该能发现这条 fact 没有来源——但它直接pass。无笔记版594 tokens也pass。两者 output 完全一样。这说明Reviewer 根本没有做逐条核对它只做了读一遍感觉还行放行这种表层审查。书中把这种失败叫同质趋同Homogeneous Convergence同一模型、相似上下文生成的多个审核意见不能自动视为相互独立的证据。这里更极端Reviewer 连是否独立都没做到它和 Executor 是同一个 GLM-4-Flash、同一种写作风格天然倾向于认可对方的输出。这就是书中 ICLR 2024 那篇论文的结论——没有外部反馈时模型自我审查几乎不起作用。实验学习二实验结果打印单 Agent 一次性翻译 chapter1 人工智能代理是一种以大型语言模型作为其推理核心的系统。代理通过循环操作观察环境、决定行动并调用工具来改变世界。ReAct 模式将这一循环形式化为推理、行动和观察。一个框架包围着模型并管理上下文、工具接口、约束、验证和修正。提示注入是一种核心安全威胁攻击者将指令隐藏在外部内容中如网页代理可能会执行这些指令。 chapter2 记忆和知识是两回事。用户记忆存储跨会话的偏好和过去交互而知识库存储共享的领域文档。检索增强生成RAG检索相关片段并在模型生成答案之前将其注入上下文中。一个常见的失败是代理检索了过多的不相关片段这会分散注意力并增加成本。分块策略、嵌入模型选择和重新排序都会影响检索质量。[tokens] 472 多 Agent 流水线 [Glossary] 提取 11 个术语[Translation] chapter1 完成171 字[Translation] chapter2 完成149 字[Proofreading] 一致None, 问题数0--- Manager 最终说明 ---术语一致性通过无问题需要返工。交付状态术语一致译文无误。[tokens] 3321--- 多 Agent 译文chapter1---人工智能代理是一种使用大型语言模型作为其推理核心的系统。该代理在一个循环中运行它观察环境决定一个动作并调用一个工具来改变世界。ReAct 模式将这个循环形式化为推理、行动和观察。一个约束框架围绕着模型并管理上下文、工具接口、约束、验证和纠正。提示注入是一个核心安全威胁攻击者将指令隐藏在外部内容如网页中代理可能会执行它们。--- 多 Agent 审校报告 ---{consistent: null,issues: []}Token 对比Single: 472Multi: 3321倍率: 7.04x多 Agent 各角色 tokenGlossary total 671 calls1Translation_chapter1 total 696 calls1Translation_chapter2 total 673 calls1Proofreading total 723 calls1Manager_final total 558 calls1术语表AI agent - 人工智能代理 (准确反映其作为智能系统的角色)large language model - 大型语言模型 (直接对应英文术语避免误解)ReAct pattern - ReAct 模式 (保持原术语便于专业交流)harness - 约束框架 (准确描述其功能避免误解为马具)prompt injection - 提示注入攻击 (强调安全威胁性质避免误解为普通注入)user memory - 用户记忆 (强调记忆的所属主体)knowledge base - 知识库 (直接对应英文术语避免误解)retrieval-augmented generation - 检索增强生成 (准确描述技术特点)chunking strategy - 分块策略 (直接对应英文术语便于专业交流)embedding model - 嵌入模型 (直接对应英文术语便于专业交流)reranking - 重新排序 (直接对应英文术语便于专业交流)总结复现了书中实验10-2书籍翻译 Agent的管理者模式以两章技术文本为对象用 GLM-4-Flash 跑了 Glossary / Translation×2 / Proofreading / Manager 四角色流水线与单 Agent 基线。结果显示上下文隔离有效Manager 只消耗 558 token低于其他角色确实没背全文符合书中Manager 上下文保持在可管理范围内的设计目标。成本 7.0× 但质量未提升多 Agent 译文在术语上更照表但出现了约束框架……约束……这类因术语窄化导致的同句重复比单 Agent 更生硬。Proofreading 返回consistent: nullGLM-4-Flash 未严格遵循 JSON schematry_parse_json把不合规输出静默降级成None掩盖了执行失败。Manager 在信息缺失时编造结论输入consistent: null输出术语一致性通过无问题需要返工——这是书中 10.5.2错误级联放大的典型信息在一次转述中从未确定变成了通过且下游用户会信以为真。结论多 Agent 的风险不只在于成本高收益低实验一 的问题更在于链条中某个环节静默失败后下游角色替它编造结论。改进方向是给 Manager 加信息完整性检查null必须报审校未完成、用确定性检查器替代抽象 LLM 审查、让 Glossary 的译法选择更保守。