专题研修

17|多Agent内部:DAG、上下文交接、并发冲突与相关错误

专题研修约 3 千字1 组分步图解

目标:能判断什么值得拆分、如何可靠合并,以及为什么多Agent可能更差。先建立单Agent基线,不把角色数量当能力指标。

本章目录

沿着对象与状态理解本章

任务图首先服务于独立性和交接,不应为了图漂亮强行并行共享修改。

下方图解的固定输入在“输入与适用条件”中声明。它用于解释本章机制,不与本章其他独立例子的数值暗中接续。

动态图解 · O11

多Agent:可并行的工作,比Agent数量重要

为什么任务拆得更细,有时完成得更慢、更差?

并行能缩短独立子任务的关键路径,却增加委派、重复取证、结果整合和共享状态成本。子Agent拥有独立上下文还会引入交接损失。先找确实能分开的工作,再设计明确交接;简单集中任务往往单Agent更容易做好。

依赖某一步必须等待另一结果才能进行。
交接包目标、范围、证据、约束、当前状态与交付要求。
冲突多个执行者竞争同一份可变状态。

输入与适用条件:固定A6秒、B8秒、集成3秒;第二/三帧仅改变交接成本2→8秒。这是教学算账,不是商业多Agent实测。

1 / 4 · 顺序完成两个独立子任务

第1步,共4步

窄屏可左右滑动图形,或点击“放大图形”。文字解释紧随图后。

多Agent:可并行的工作,比Agent数量重要:顺序完成两个独立子任务主任务共同目标与约束子任务A6秒 / 证据与结果子任务B8秒 / 证据与结果集成3秒 / 当前版本验证

任务A6秒、B8秒、集成3秒,顺序耗时17秒。先假定两项确实独立、都必需。

交接开销=0秒;顺序=17秒

默认静止。用“下一步”看完解释再继续;播放到最后一步自动停止。键盘聚焦播放器后,可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分,含义同时用文字注明。

为什么需要

利用真正独立的研究或实现方向,并隔离无关上下文。

怎样实现

按依赖和写入边界分工,交接必要证据,主任务核验整合结果。

可能的代价与误解

重复搜索、同文件覆盖、相关错误和过度委派会提高时间与Token成本。

如何判断是否做对

与单Agent同任务同预算对照,记录集成缺陷和重做次数。

1. 多Agent能带来什么真实收益

相对独立的信息搜索可并行,不同任务可拥有不同上下文与工具,部分审查可隔离实现者的假设。Anthropic研究系统提供了主Agent协调、子Agent并行探索的工程案例;Agentless则提示某些软件任务中结构化简单流程也有竞争力。二者回答的任务与设置不同,不存在一条“多Agent总是更好”的结论。[N26][N47]

多Agent增加的成本包括任务说明、重复检索、上下文交接、合并、冲突解决和额外模型调用。若所有人修改同一段核心逻辑,分工可能只把原本连续的思考切碎。若任务本身很小,协调成本甚至超过实现成本。

2. 用关键路径而不是Agent数量估计加速

设工作中可并行比例p,理想N个执行者的加速上界近似1/[(1−p)+p/N];再加入协调、通信、重复和合并开销,真实速度更低。这是Amdahl式推导的应用,不是模型实验结果。

以两个独立模块各自修改、最后集成为例,理想耗时是二者最大值加集成时间,而不是两者相加。但如果第二模块需要第一模块确定接口,存在依赖边,不能真正并行。任务DAG应表达产出依赖,而不是按“分析/实现/审查”机械切成固定三层。

共享限流也会破坏理想并行。四个Agent同时请求同一外部API,可能互相限流;总Token预算固定时,扩大并发也会挤压每个任务可用证据。评估应统计完整任务墙钟时间与总资源,而不是只看某个子任务很快。

3. 委派契约需要哪些信息

委派说明至少应有目标、范围、当前事实、必要约束、可用工具、预期返回形式与完成条件。信息要充分但不复制整段主会话。重要假设应明确是待验证,不要作为事实灌输给所有子Agent。

返回结果应区分结论、证据位置、已执行动作、未解决问题。主Agent只接收漂亮摘要而没有原始来源,就无法判断冲突或复核。需要精确代码时,应读取子Agent标明的当前版本,而不是让它在摘要里手工重写一段可能错的源码。

不同宿主的上下文继承方式不同,有独立上下文也有fork;工具与权限也由产品配置决定。设计时先核实宿主机制,不应在技能里写一个抽象“继承全部权限”就当作已经实现。[N21][N22]

4. 文件并发与集成边界

对独立写任务,分支或worktree可降低直接覆盖,但不能消除语义冲突。两个补丁分别通过测试,合并后可能改变共享接口、依赖版本或配置行为。合并后的当前工件必须重新验证,不应沿用各分支的绿色结果。

对同一文件的修改,先定义责任范围或串行化关键部分。内容哈希/CAS可防覆盖,但失败后仍需人工或Agent理解冲突,不能自动选择最后写者。某些任务适合子Agent只研究,主Agent集中实施,减少并发写冲突。

如果子Agent能修改测试,主Agent需要识别测试是否被弱化。验证资源应有明确所有权,高风险验收可放在工作区外或受限执行环境。把“测试全绿”当成果时,先确认测试本身仍验证原要求。

5. 独立Review不等于独立错误

同一模型、同一提示和同一上下文可能共享错误前提。实现者的解释先展示给审查者,会让其被结论锚定。独立审查可先看原需求、当前diff和测试,再看实现理由;但这也增加阅读成本,需用于值得的任务。

多数投票只在错误具有足够独立性、投票目标可识别时才有预期收益。若所有Agent都相信过期API文档,投票不会恢复事实。更有效的方法可能是增加独立证据,例如读取当前接口或运行测试,而不是再加入第五个相同审查者。

小问题可在当前Review中直接修复并验证,不必退回重新分析、重新设计、再次Review的完整循环。涉及目标改变、破坏性架构决策时才需要回到设计。风险驱动而非仪式驱动。

6. 取消、失败与部分完成

一个子任务失败不一定使所有任务无效。主Agent应知道哪些产物可复用、哪些依赖失败结果。取消后可能仍有在途工具动作,需要等待可确认的终态或记录unknown。不要通过删除子任务日志假装一切未发生。

对超时任务,先读取已持久化证据,避免重做;对无进展循环,调整任务边界或缩小问题。重启新Agent并复制全部历史,有时只把同一失败再次运行。恢复策略应针对错误类型,而不是统一“再试一次”。

7. 何时不拆分

目标清晰、修改小、证据集中、验证便宜的任务,单Agent往往足够。跨语言/独立模块/广泛研究且结果容易独立核验的任务,更可能受益于并行。这个判断应由实际依赖和风险支撑,不要求为每个任务创建复杂度分数。

验收题:四个研究Agent产出四份不同结论,应该总结平均意见吗?不应。先比较来源、时间、作用域和证据质量;有些分歧只是条件不同,有些是真矛盾。整合是证据裁决,不是语言折中。

运行示例 · S17

相关错误下,三位Agent不应按独立概率相乘

输入与条件。假设三位审查者面对相同错误资料,总会一起判断错误。每次任务共同出错概率20%。

步骤与对象内部动作中间结果 / 新状态
1边际错误每位都是20%单独观察看起来一样。
2错误相关三位一起错的概率仍20%不是0.2³=0.8%。
3多数票共同错误仍获全票通过投票没有改善这一类失败。
4独立证据增加运行测试或新版本读取可能打破共同前提,但要实测。
5工程成本三倍调用却无新增信息应考虑减少重复审查而不是加第四位。

把过程连起来。概率乘法需要独立条件;多Agent通常共享模型、上下文和环境,不能默认独立。

边界与反例。完全相关是极端构造,用于反例;真实相关度介于多种情况之间,需要实际数据估计。

依据与适用范围:[DERIVE]。示例输入和场景由本书明确设定。

记录保存在本机浏览器。

输入关键词即可检索。

↑ ↓ 选择 Enter 打开Esc 关闭 · 仅本地搜索

阅读设置

阅读设置仅保存在本机浏览器,不上传任何数据。