《深入理解 AI Agent》学习笔记-第十章Multi Agent一、从 Single-Agent 到 Multi-Agent解决什么问题Single-Agent单智能体一个 Agent 在同一执行轨迹中理解任务、规划、使用工具和修正结果。它已经能够实现多步骤自主工作优势是控制结构简单、上下文连续、协调成本低不足是复杂长任务中容易出现上下文膨胀、专业任务切换负担、长链错误累积以及单个模型能力或工具权限难以同时满足多种要求。Multi-Agent多智能体把任务交给多个拥有各自职责、上下文和工具权限的 Agent通过交接、消息与共享产物完成共同目标。它不是把一次 LLM 调用复制多份而是要设计任务依赖、角色接口、信息通路、调度策略、验证与终止条件。多 Agent 可拓宽搜索范围、隔离中间噪声、利用异构能力也会引入通信损耗、共享资源冲突和协调者瓶颈。维度Single-AgentMulti-Agent任务覆盖一个执行者负责端到端由多个专业执行者协同完成上下文通常是同一条逐步增长的轨迹可以继承完整轨迹也可以隔离并按需交接控制与接口一个决策循环结构较简洁需要调度/移交协议、消息或文件索引质量保障工具反馈、自检、外部验证可设独立 Reviewer利用新证据审核主要代价单体能力/上下文受限额外推理、协调、同步、失败传播风险选型不能凭任务“看起来复杂”做决定应先实现并测量强单 Agent 基线再判断拆分能否引入新证据、真实并行性、必要的权限隔离或明确的领域专长。教材第 10.2 节尤其强调“协作过程是否引入单 Agent 原本拿不到的新信息”这一判断框架。二、两条正交的架构轴上下文 × 协作拓扑1. 上下文是否共享第 10.1.1 节共享上下文 / 继承式协作新阶段可切换系统提示词与工具集却继承前面完整的用户消息和工具轨迹。信息损失较少但上下文增长快角色容易互相干扰。也可以用加载Skill而非更换 system prompt 实现角色差异当区别仅在知识、流程、风格时更合适涉及硬权限与工具隔离时应由独立 Agent / Harness 强制约束。独立上下文 / 隔离式协作每个 Agent 只接收自己完成子任务所需的信息交换文件、结构化参数或消息而不共享完整推理历史。优点是模块化、便于复用并行、减少主上下文噪声难点是交接的信息保真与同步。教材**图 10-1第 273 页**将两者并排展示左边由需求分析师、工程师、审查员共享同一执行历史右边由 Glossary、Translation、Proofreading Agent 使用独立上下文通过共享文件系统移交术语表、译文和审校报告。这不是简单的“分多个人”而是上下文组织方式改变了。2. 协作拓扑第 10.1.2 节拓扑谁决定下一步典型形态适用条件对等协作Peer少数角色互相交接或评价Proposer ↔ Reviewer迭代修改、独立复核、角色数量少管理者编排OrchestrationManager 分解、派发、监控、汇总Manager → 多个 Worker依赖清晰、需要集中预算与状态管理去中心化Decentralized各 Agent 自主选择交接对象Handoff 网络、发布/订阅动态同伴发现、无需单点调度这与教材“Graph 工程”的执行图思路相联系节点是 Agent/程序/人工审批边定义依赖、路由与失败去向。固定 SOP 流水线不等于真正去中心化教材特别指出 MetaGPT 的共享消息池是解耦机制但其原始控制顺序仍接近固定工作流AutoGen 群聊还有中心化发言者选择OpenAI Swarm 更接近对等 handoff。三、角色设计、任务拆解与接口契约设计多 Agent 时首先不是给 Agent 起名字而是明确每个角色的输入、责任、工具、输出和验收条件。教材第 10.4.4 节的 Manager 主要负责规划与调度Worker 执行专业子任务Reviewer 审查独立证据。角色关键责任输入输出与完成标准Planner / Manager分解任务、排序依赖、预算与异常处理用户目标、限制、可用角色任务 DAG、负责人、完成条件、产物索引Researcher查询知识、收集可追溯证据研究子题、来源范围事实、来源、冲突与未证实项Executor实施具体行动、生成产物确认的任务包、工具与权限文件/API 结果、执行日志、结构化状态Reviewer对结果实施独立检验产物与来自环境的证据通过/否决、缺陷定位、修复要求任务拆解的工程约束子任务应具有明确的输入/输出避免“把剩下的工作都完成”独立任务可以并行依赖前一步结果的任务串行共享文件采用唯一命名或版本控制高风险动作执行前必须校验权限每个子任务设预算、超时和取消路径。需要避免 Manager 既分配任务又亲自收集所有大段原文把子 Agent 的上下文噪声重新搬回中心。示例Planner → Researcher → Executor → Reviewer通过缺陷定位用户目标Planner / ManagerResearcher证据与出处Executor执行并生成产物Reviewer独立检查证据交付这是理解角色分工的教学示例并不是教材实验 10-2 的实际角色列表。它必须设计反馈回路Reviewer 不仅评价“看起来不错”还要检查执行/测试/截图/权威来源后生成可修复的问题单Planner 据此局部重排并再次派发。否则四个名称可能只是昂贵的线性文本传话。四、Agent 间如何通信与交换状态第 10.1 和 10.4 节将 IPC 思路引入 Agent 协作共享存储与消息传递。工具调用参数下游 Agent 作为上游可调用的工具传入结构化 JSON同步、类型清晰适合固定依赖。共享文件系统传递glossary.json、chapter01_zh.md、review_report.json等持久产物消息只带路径适合体积大的代码、书籍、媒体文件。消息总线异步发布任务、进度和事件适合多 Agent 并行、生命周期监控和取消通知。教材图 10-2第 278 页划分四类资源Agent 私有 Scratchpad随实例结束、任务级共享 Workspace需并发控制、外部授权挂载弱一致性、谨慎写回、全局只读系统资源Skills/模板。真正的多 Agent 系统需要同时维护数据平面文件和证据与控制平面spawn、send、status、cancel、ack。**推荐的交接包Handoff Contract**应至少记录任务 ID、发送方、接收方、目标、约束、已验证事实、产物引用、剩余预算和已访问 Agent 链。接收者只读取经允许的任务材料visited_agents与预算限制有助于阻断 A→B→A 无限回转。跨组织 Agent 互操作可以使用A2AAgent Card 用于能力发现Task 状态机用于生命周期管理任务与产物交换不暴露内部提示词MCP 连接 Agent 与工具A2A 连接 Agent 与 Agent定位不同。五、什么时候多 Agent 真正有价值教材表 10-1第 274 页的关键区别是有无外部新信息同一模型重看原答、多个角色只争论相同文本不意味着可靠改进代码测试结果、渲染截图、外部事实核验能够提供生成时没有的信息因此更可能提升最终质量。独立多路径搜索还可能增加覆盖率但须付出额外计算成本并在验证后才能结算“完成”。优先单 Agent任务范围紧凑、工具集可组合、全程状态易于管理各子任务高度依赖同一上下文多个角色只是换一种措辞并没有新信息成本/延迟敏感且多 Agent 优势未经测试。考虑多 Agent长书翻译、并行研究、多模态执行、大型软件开发等具有明显可分割的产物专业工具/权限必须隔离多个独立 Worker 可以并行审核者能读取真实执行反馈子任务需要不同模型、不同工作区或独立审计。可把选择写成一个简化原则预期的质量提升 并行节省 上下文隔离收益应当大于协调与额外推理开销。教材同时强调步骤预算意识Agent 不会因给它更多步骤就自动更好Manager 应按任务难度分配轮数并在剩余预算减少时从广泛探索转向集中验证。六、多 Agent 的常见失败及治理第 10.5 节列出六类工程风险失败模式典型后果可操作的治理共享文件并发冲突后写覆盖先写跨文件图片编号失配乐观锁 / Git worktree / 合并时语义验证错误级联放大一个未经核查的结论被多级转述并强化独立源证据、结构化交接、审核不看原推理同质趋同相同模型同时创建同名资源或犯同类错误命名空间、不同来源、权限和资源配额互相扯皮角色目标冲突、撤销对方工作全局优先级、资源归属、冲突人工仲裁循环失控重试或 handoff 空转最大迭代 / 步数预算 / 回环检测 / 熔断理解债与认知投降人不再理解成果仅接受 Agent 结论保留关键决策依据、验收证据和可回滚修改尤其要防范“声明已成功 ≠ 已验证成功”。并行系统的“首个赢家”必须由外部验证器确认、通过幂等操作结算随后向其他任务发送优雅取消信号并等待确认失败时保留日志与部分进度。安全审查不应与提议者共用可被污染的推理轨迹也不应允许被审查方改写测试标准。七、教材实验 10-2书籍翻译 Agent1. 原始实验目标与架构第 285–286 页对一本图文并茂、包含代码的技术书籍进行英文→中文翻译并与单 Agent 翻整本书比较翻译质量、执行效率、上下文与资源消耗。要求四类 AgentAgent接收的必要输入写入共享空间的产物Glossary Agent全书内容、专业词典/编辑规范glossary.json/ CSV规范术语Translation Agent ×N当前章节、术语表、风格指南chapterNN_zh.md未知术语待审Proofreading Agent章节译文、术语表与源证据proofreading_report.json不一致定位Manager Agent任务、计划、文件索引、审核摘要调度日志、定向返修指令、完成判定教材**图 10-5第 286 页**清晰说明Glossary→Translation→Proofreading→Manager 根据报告返修。Manager不把完整译文装入自身上下文只保存路径及元数据这是实验最重要的架构点。2. 本次可运行实现与环境边界本次在本地 Python 环境实现了离线四角色机制复现自编四章英文技术小书包含四幅 SVG 插图、四个 Python 代码围栏及四个外部参考链接独立的 Agent 角色类、glossary.json、按章译文、审校报告、Manager 调度轨迹、单 Agent 对照轨迹和自动化测试。所有关键产物落盘不在 Manager 上下文中复制全文。重要边界环境没有可用的模型 API 凭证实际执行0 次 LLM API 调用。译文来自人工编写的段落级双语 fixture系统以确定性程序运行角色与流程它不是模型自主翻译也不是作者仓库正式 10-2 完整验收不能声称已测得真实模型翻译质量、真实 token 成本或生产延迟。源材料是短小的自编技术样本而非几百页的真实书籍。这样的复现能够验证任务拆分、信息交接、结构保真、审校和返修不等于验证模型能力。python agents.py --inject-drift python-mpytest-qtest_experiment.py--inject-drift会主动将第三章的一处“词元”换成“令牌”用于检查 Proofreading Agent 是否能够发现偏差、要求 Manager 定位返修并重新审校该错误是人为注入的测试用例不是模型自然发生的幻觉。3. 实际运行结果本次离线复现指标本次实际测量英文技术样本4 章源 Markdown 共3,959 UTF-8 字节图 / 代码围栏 / 外部链接4 / 4 / 4角色Manager、Glossary、Translation、Proofreading共 4 类主/Manager 上下文峰值2,820 UTF-8 字节单 Agent 连续上下文峰值7,781 UTF-8 字节上下文峰值相差约 2.76 倍字节计不是 token人为注入的术语偏差1 项检出、1 次定向返修最终审核通过两组代码/图像/链接保真各 4/4 章节通过编辑部词表字符串匹配受替换规则影响Manager41/4493.2%单 Agent32/4472.7%自动化 pytest10/10 通过真实 LLM API 请求0这里的**“字节数”是实际创建的文本 UTF-8 长度**不能换算成已经测得的模型 token。术语匹配率是特定人工翻译 fixture 与字面匹配器的结果实验对照组事先选择了不统一的默认译词因此不构成公平的模型能力比较或显著性结论Manager 组也有 3 个匹配缺口说明简单字符串统计存在边界。计时只反映毫秒级脚本运行不能据此推断多 Agent 的真实推理延迟优势。核验文件output/experiment_results.json保存两组指标output/manager/manager_trace.json保存任务调度与返修记录output/manager/proofreading_report.json保存最终审校结果output/manager/chapters/和output/single_agent/chapters/保存两组译文运行日志与 pytest 输出保留在压缩包中。4. 与作者公开的正式模型实验区分作者的 chapter10/book-translation 官方项目 已另行公布真实模型的正式实验以英文版前两章为素材242,090 字节、23 个图像引用、14 个代码块拆成 26 个翻译单元。该正式运行报告的主上下文峰值为 Manager4,618 tokens、单 Agent94,355 tokens翻译总 token 为203,277 vs 1,317,808匿名质量评分为4.654 vs 4.481 / 5墙钟时间则为270.829 秒 vs 254.127 秒即 Manager 反而略慢。作者同时记录了代码 payload 和部分图像目标未完全保真的负面结果说明**“上下文更省”绝不等于“各项指标全面更好”**。这些数据来自作者的实验报告不是本次运行的结果。八、成果与收获第一文件引用是协作的关键接口。如果 Manager 在每轮调度时都读取所有译文所谓多 Agent 便失去上下文隔离的意义。本次 Manager 峰值明显小于不断追加源文与译文的单 Agent 基线验证了这个有限样本中的机制性区别不等于真实 LLM token 节省倍数。第二角色应由输入/输出契约定义而不是由身份提示词定义。Glossary 生成受控词表Translation 只负责章节Proofreading 读取原文与结果进行独立检查Manager 决定是否回滚与返修。这种清晰边界更容易记录责任、查找失败并更换实现。第三多 Agent 的可信度来自外部证据。本实验通过源 Markdown 代码围栏、图片路径、链接目标和编辑部译法进行确定性验证故意引入一处错误时Reviewer 发现事实偏差Manager 才能发起有定位的闭环修复。如仅让两个 Agent 互相夸奖译文无法验证是否漏掉代码或改坏图片。第四必须正视实验可复现性与性能评估的边界。本次完成了离线协作的代码和测试但尚未完成完整技术书籍的真实模型质量评测。下一步正式验收需接入模型 API、使用真正的长篇英文技术书、对齐同模型和任务预算、记录 providerusage及时延加入独立盲评与语义级质量评价并同时检查它改变了什么、不应改变什么。总的来说先证明一个 Agent 不足再引入恰好需要的协作关系。对于可拆解、独立证据可验证、允许隔离上下文的任务多 Agent 是有价值的系统工程方案对简单或强共享依赖的任务一个工具完善、反馈闭环可靠的单 Agent 可能更高效。多 Agent 的重点是信息增量、协议清晰、责任边界与可验证交付不是角色数量。 
长河君 · 2026/10/28 19:09:31 · 阅读 1.2k 深入理解 AI Agent》第十章学习笔记：多 Agent 协作
《深入理解 AI Agent》学习笔记-第十章Multi Agent一、从 Single-Agent 到 Multi-Agent解决什么问题Single-Agent单智能体一个 Agent 在同一执行轨迹中理解任务、规划、使用工具和修正结果。它已经能够实现多步骤自主工作优势是控制结构简单、上下文连续、协调成本低不足是复杂长任务中容易出现上下文膨胀、专业任务切换负担、长链错误累积以及单个模型能力或工具权限难以同时满足多种要求。Multi-Agent多智能体把任务交给多个拥有各自职责、上下文和工具权限的 Agent通过交接、消息与共享产物完成共同目标。它不是把一次 LLM 调用复制多份而是要设计任务依赖、角色接口、信息通路、调度策略、验证与终止条件。多 Agent 可拓宽搜索范围、隔离中间噪声、利用异构能力也会引入通信损耗、共享资源冲突和协调者瓶颈。维度Single-AgentMulti-Agent任务覆盖一个执行者负责端到端由多个专业执行者协同完成上下文通常是同一条逐步增长的轨迹可以继承完整轨迹也可以隔离并按需交接控制与接口一个决策循环结构较简洁需要调度/移交协议、消息或文件索引质量保障工具反馈、自检、外部验证可设独立 Reviewer利用新证据审核主要代价单体能力/上下文受限额外推理、协调、同步、失败传播风险选型不能凭任务“看起来复杂”做决定应先实现并测量强单 Agent 基线再判断拆分能否引入新证据、真实并行性、必要的权限隔离或明确的领域专长。教材第 10.2 节尤其强调“协作过程是否引入单 Agent 原本拿不到的新信息”这一判断框架。二、两条正交的架构轴上下文 × 协作拓扑1. 上下文是否共享第 10.1.1 节共享上下文 / 继承式协作新阶段可切换系统提示词与工具集却继承前面完整的用户消息和工具轨迹。信息损失较少但上下文增长快角色容易互相干扰。也可以用加载Skill而非更换 system prompt 实现角色差异当区别仅在知识、流程、风格时更合适涉及硬权限与工具隔离时应由独立 Agent / Harness 强制约束。独立上下文 / 隔离式协作每个 Agent 只接收自己完成子任务所需的信息交换文件、结构化参数或消息而不共享完整推理历史。优点是模块化、便于复用并行、减少主上下文噪声难点是交接的信息保真与同步。教材**图 10-1第 273 页**将两者并排展示左边由需求分析师、工程师、审查员共享同一执行历史右边由 Glossary、Translation、Proofreading Agent 使用独立上下文通过共享文件系统移交术语表、译文和审校报告。这不是简单的“分多个人”而是上下文组织方式改变了。2. 协作拓扑第 10.1.2 节拓扑谁决定下一步典型形态适用条件对等协作Peer少数角色互相交接或评价Proposer ↔ Reviewer迭代修改、独立复核、角色数量少管理者编排OrchestrationManager 分解、派发、监控、汇总Manager → 多个 Worker依赖清晰、需要集中预算与状态管理去中心化Decentralized各 Agent 自主选择交接对象Handoff 网络、发布/订阅动态同伴发现、无需单点调度这与教材“Graph 工程”的执行图思路相联系节点是 Agent/程序/人工审批边定义依赖、路由与失败去向。固定 SOP 流水线不等于真正去中心化教材特别指出 MetaGPT 的共享消息池是解耦机制但其原始控制顺序仍接近固定工作流AutoGen 群聊还有中心化发言者选择OpenAI Swarm 更接近对等 handoff。三、角色设计、任务拆解与接口契约设计多 Agent 时首先不是给 Agent 起名字而是明确每个角色的输入、责任、工具、输出和验收条件。教材第 10.4.4 节的 Manager 主要负责规划与调度Worker 执行专业子任务Reviewer 审查独立证据。角色关键责任输入输出与完成标准Planner / Manager分解任务、排序依赖、预算与异常处理用户目标、限制、可用角色任务 DAG、负责人、完成条件、产物索引Researcher查询知识、收集可追溯证据研究子题、来源范围事实、来源、冲突与未证实项Executor实施具体行动、生成产物确认的任务包、工具与权限文件/API 结果、执行日志、结构化状态Reviewer对结果实施独立检验产物与来自环境的证据通过/否决、缺陷定位、修复要求任务拆解的工程约束子任务应具有明确的输入/输出避免“把剩下的工作都完成”独立任务可以并行依赖前一步结果的任务串行共享文件采用唯一命名或版本控制高风险动作执行前必须校验权限每个子任务设预算、超时和取消路径。需要避免 Manager 既分配任务又亲自收集所有大段原文把子 Agent 的上下文噪声重新搬回中心。示例Planner → Researcher → Executor → Reviewer通过缺陷定位用户目标Planner / ManagerResearcher证据与出处Executor执行并生成产物Reviewer独立检查证据交付这是理解角色分工的教学示例并不是教材实验 10-2 的实际角色列表。它必须设计反馈回路Reviewer 不仅评价“看起来不错”还要检查执行/测试/截图/权威来源后生成可修复的问题单Planner 据此局部重排并再次派发。否则四个名称可能只是昂贵的线性文本传话。四、Agent 间如何通信与交换状态第 10.1 和 10.4 节将 IPC 思路引入 Agent 协作共享存储与消息传递。工具调用参数下游 Agent 作为上游可调用的工具传入结构化 JSON同步、类型清晰适合固定依赖。共享文件系统传递glossary.json、chapter01_zh.md、review_report.json等持久产物消息只带路径适合体积大的代码、书籍、媒体文件。消息总线异步发布任务、进度和事件适合多 Agent 并行、生命周期监控和取消通知。教材图 10-2第 278 页划分四类资源Agent 私有 Scratchpad随实例结束、任务级共享 Workspace需并发控制、外部授权挂载弱一致性、谨慎写回、全局只读系统资源Skills/模板。真正的多 Agent 系统需要同时维护数据平面文件和证据与控制平面spawn、send、status、cancel、ack。**推荐的交接包Handoff Contract**应至少记录任务 ID、发送方、接收方、目标、约束、已验证事实、产物引用、剩余预算和已访问 Agent 链。接收者只读取经允许的任务材料visited_agents与预算限制有助于阻断 A→B→A 无限回转。跨组织 Agent 互操作可以使用A2AAgent Card 用于能力发现Task 状态机用于生命周期管理任务与产物交换不暴露内部提示词MCP 连接 Agent 与工具A2A 连接 Agent 与 Agent定位不同。五、什么时候多 Agent 真正有价值教材表 10-1第 274 页的关键区别是有无外部新信息同一模型重看原答、多个角色只争论相同文本不意味着可靠改进代码测试结果、渲染截图、外部事实核验能够提供生成时没有的信息因此更可能提升最终质量。独立多路径搜索还可能增加覆盖率但须付出额外计算成本并在验证后才能结算“完成”。优先单 Agent任务范围紧凑、工具集可组合、全程状态易于管理各子任务高度依赖同一上下文多个角色只是换一种措辞并没有新信息成本/延迟敏感且多 Agent 优势未经测试。考虑多 Agent长书翻译、并行研究、多模态执行、大型软件开发等具有明显可分割的产物专业工具/权限必须隔离多个独立 Worker 可以并行审核者能读取真实执行反馈子任务需要不同模型、不同工作区或独立审计。可把选择写成一个简化原则预期的质量提升 并行节省 上下文隔离收益应当大于协调与额外推理开销。教材同时强调步骤预算意识Agent 不会因给它更多步骤就自动更好Manager 应按任务难度分配轮数并在剩余预算减少时从广泛探索转向集中验证。六、多 Agent 的常见失败及治理第 10.5 节列出六类工程风险失败模式典型后果可操作的治理共享文件并发冲突后写覆盖先写跨文件图片编号失配乐观锁 / Git worktree / 合并时语义验证错误级联放大一个未经核查的结论被多级转述并强化独立源证据、结构化交接、审核不看原推理同质趋同相同模型同时创建同名资源或犯同类错误命名空间、不同来源、权限和资源配额互相扯皮角色目标冲突、撤销对方工作全局优先级、资源归属、冲突人工仲裁循环失控重试或 handoff 空转最大迭代 / 步数预算 / 回环检测 / 熔断理解债与认知投降人不再理解成果仅接受 Agent 结论保留关键决策依据、验收证据和可回滚修改尤其要防范“声明已成功 ≠ 已验证成功”。并行系统的“首个赢家”必须由外部验证器确认、通过幂等操作结算随后向其他任务发送优雅取消信号并等待确认失败时保留日志与部分进度。安全审查不应与提议者共用可被污染的推理轨迹也不应允许被审查方改写测试标准。七、教材实验 10-2书籍翻译 Agent1. 原始实验目标与架构第 285–286 页对一本图文并茂、包含代码的技术书籍进行英文→中文翻译并与单 Agent 翻整本书比较翻译质量、执行效率、上下文与资源消耗。要求四类 AgentAgent接收的必要输入写入共享空间的产物Glossary Agent全书内容、专业词典/编辑规范glossary.json/ CSV规范术语Translation Agent ×N当前章节、术语表、风格指南chapterNN_zh.md未知术语待审Proofreading Agent章节译文、术语表与源证据proofreading_report.json不一致定位Manager Agent任务、计划、文件索引、审核摘要调度日志、定向返修指令、完成判定教材**图 10-5第 286 页**清晰说明Glossary→Translation→Proofreading→Manager 根据报告返修。Manager不把完整译文装入自身上下文只保存路径及元数据这是实验最重要的架构点。2. 本次可运行实现与环境边界本次在本地 Python 环境实现了离线四角色机制复现自编四章英文技术小书包含四幅 SVG 插图、四个 Python 代码围栏及四个外部参考链接独立的 Agent 角色类、glossary.json、按章译文、审校报告、Manager 调度轨迹、单 Agent 对照轨迹和自动化测试。所有关键产物落盘不在 Manager 上下文中复制全文。重要边界环境没有可用的模型 API 凭证实际执行0 次 LLM API 调用。译文来自人工编写的段落级双语 fixture系统以确定性程序运行角色与流程它不是模型自主翻译也不是作者仓库正式 10-2 完整验收不能声称已测得真实模型翻译质量、真实 token 成本或生产延迟。源材料是短小的自编技术样本而非几百页的真实书籍。这样的复现能够验证任务拆分、信息交接、结构保真、审校和返修不等于验证模型能力。python agents.py --inject-drift python-mpytest-qtest_experiment.py--inject-drift会主动将第三章的一处“词元”换成“令牌”用于检查 Proofreading Agent 是否能够发现偏差、要求 Manager 定位返修并重新审校该错误是人为注入的测试用例不是模型自然发生的幻觉。3. 实际运行结果本次离线复现指标本次实际测量英文技术样本4 章源 Markdown 共3,959 UTF-8 字节图 / 代码围栏 / 外部链接4 / 4 / 4角色Manager、Glossary、Translation、Proofreading共 4 类主/Manager 上下文峰值2,820 UTF-8 字节单 Agent 连续上下文峰值7,781 UTF-8 字节上下文峰值相差约 2.76 倍字节计不是 token人为注入的术语偏差1 项检出、1 次定向返修最终审核通过两组代码/图像/链接保真各 4/4 章节通过编辑部词表字符串匹配受替换规则影响Manager41/4493.2%单 Agent32/4472.7%自动化 pytest10/10 通过真实 LLM API 请求0这里的**“字节数”是实际创建的文本 UTF-8 长度**不能换算成已经测得的模型 token。术语匹配率是特定人工翻译 fixture 与字面匹配器的结果实验对照组事先选择了不统一的默认译词因此不构成公平的模型能力比较或显著性结论Manager 组也有 3 个匹配缺口说明简单字符串统计存在边界。计时只反映毫秒级脚本运行不能据此推断多 Agent 的真实推理延迟优势。核验文件output/experiment_results.json保存两组指标output/manager/manager_trace.json保存任务调度与返修记录output/manager/proofreading_report.json保存最终审校结果output/manager/chapters/和output/single_agent/chapters/保存两组译文运行日志与 pytest 输出保留在压缩包中。4. 与作者公开的正式模型实验区分作者的 chapter10/book-translation 官方项目 已另行公布真实模型的正式实验以英文版前两章为素材242,090 字节、23 个图像引用、14 个代码块拆成 26 个翻译单元。该正式运行报告的主上下文峰值为 Manager4,618 tokens、单 Agent94,355 tokens翻译总 token 为203,277 vs 1,317,808匿名质量评分为4.654 vs 4.481 / 5墙钟时间则为270.829 秒 vs 254.127 秒即 Manager 反而略慢。作者同时记录了代码 payload 和部分图像目标未完全保真的负面结果说明**“上下文更省”绝不等于“各项指标全面更好”**。这些数据来自作者的实验报告不是本次运行的结果。八、成果与收获第一文件引用是协作的关键接口。如果 Manager 在每轮调度时都读取所有译文所谓多 Agent 便失去上下文隔离的意义。本次 Manager 峰值明显小于不断追加源文与译文的单 Agent 基线验证了这个有限样本中的机制性区别不等于真实 LLM token 节省倍数。第二角色应由输入/输出契约定义而不是由身份提示词定义。Glossary 生成受控词表Translation 只负责章节Proofreading 读取原文与结果进行独立检查Manager 决定是否回滚与返修。这种清晰边界更容易记录责任、查找失败并更换实现。第三多 Agent 的可信度来自外部证据。本实验通过源 Markdown 代码围栏、图片路径、链接目标和编辑部译法进行确定性验证故意引入一处错误时Reviewer 发现事实偏差Manager 才能发起有定位的闭环修复。如仅让两个 Agent 互相夸奖译文无法验证是否漏掉代码或改坏图片。第四必须正视实验可复现性与性能评估的边界。本次完成了离线协作的代码和测试但尚未完成完整技术书籍的真实模型质量评测。下一步正式验收需接入模型 API、使用真正的长篇英文技术书、对齐同模型和任务预算、记录 providerusage及时延加入独立盲评与语义级质量评价并同时检查它改变了什么、不应改变什么。总的来说先证明一个 Agent 不足再引入恰好需要的协作关系。对于可拆解、独立证据可验证、允许隔离上下文的任务多 Agent 是有价值的系统工程方案对简单或强共享依赖的任务一个工具完善、反馈闭环可靠的单 Agent 可能更高效。多 Agent 的重点是信息增量、协议清晰、责任边界与可验证交付不是角色数量。