如何开发类似 Coding Agent 的多 Agent 系统并实现子 Agent 通信？

核心回答

可以先搭一个主Agent加有限职责子Agent的编码系统：主Agent理解需求、维护全局状态并整合结果；探索、实现、测试或审阅子Agent处理边界清楚的任务。每个子Agent有独立上下文、工具和产物要求，通信通过任务与结果契约，调度器控制依赖、并发和完成状态。

第一版不必让所有子Agent互相聊天。主Agent派发任务、收回结构化结果，已经能实现清楚的协作；只有持续协商或跨服务调用确有需要时，再增加消息总线或远程协议。

子任务怎样定义

派发内容包括目标、输入证据、基线代码版本、允许修改范围、依赖、预期产物和完成依据。探索者返回文件与符号线索；实现者返回diff及说明；测试者返回命令、环境、结果和失败位置。详细日志存为产物，主Agent按需回查。

共享状态只放全局目标、任务表、依赖、结果槽和预算；每个角色自己的工具历史保留在局部上下文。结果必须带task_id、run或版本及来源，防止重试和迟到消息混入其他任务。

通信和调度怎么做

同进程可用函数、异步任务或队列返回值；跨进程再用任务队列、RPC或合适协议。应用内多Agent不要求A2A；MCP用于能力接入，也不负责替代全部任务协调。

调度器只启动前置条件满足的任务，并限制并发、时限和重试。任务完成时校验产物与验收条件，再推进下游。子Agent输出只是待整合结果，主Agent不能因为收到“已完成”文本就忽略实际diff和测试。

如何处理并行代码修改

独立模块可以拆分，修改同一文件的工作应串行或明确合并者。需要隔离时用独立工作区或worktree，固定基线后合并diff并统一验证；小任务无需为每个步骤都创建分支。

冲突按接口契约、现有规范、运行证据和用户目标解决，不能单靠投票。测试失败先区分实现缺陷、环境问题与测试本身错误。对重复调度、取消和结果未知，保存任务状态并使用幂等处理，避免一项修改被执行两遍。

怎样证明拆分有价值

用同一批任务对照单Agent与多Agent，比较成功、耗时、Token、重复工作和整合失败。子任务高度依赖同一上下文时，多角色可能只增加通信；这时保留单Agent加清楚状态更合适。

对应教程

参考资料