多 Agent 并行：隔离与集成

🚧 本章正在开发中。以下是核心论点的概要，完整内容将在后续版本发布。

上一章让单个 Agent 能够自主完成任务。自然的下一步是：同时跑多个。前端一个，后端一个，测试一个。理论上，个人产出可以从五到十倍跃升到几十倍。

实际操作中，两类问题依次浮现。第一类是物理冲突：两个 Agent 改了同一个文件，后提交的覆盖先提交的。一个 Agent 改了数据库 schema，另一个还在用老的字段名。这类冲突很明显，报错信息直接指向问题。第二类更隐蔽：每个 Agent 各自通过了自己的测试，合并后系统崩溃。前端期望的 API 返回格式和后端实际返回的不一样，两边的假设是矛盾的，但各自的测试只验证了各自的假设。

这两类问题对应两层解决方案。隔离机制（独立工作空间、git 分支、模块边界）防止物理冲突。契约和集成测试防止逻辑冲突，API 契约定义接口行为的规范，集成测试在合并前验证多个模块的协作。这两层之下还需要基础设施支撑：分层反馈系统（从毫秒级的 lint 到分钟级的集成测试）、可复现的环境、机器可读的信号格式。这就是 platform engineering 在 Agent 开发场景下的核心关切。

多 Agent 并行还引入了一个管理问题：你同时能管几个？三个 Agent 还能靠自己协调，再多就分不清谁在干什么、问题是谁引入的。管理幅度不取决于你的精力，取决于验证自动化的成熟度。当 CI 能自动定位问题来源并生成可操作的反馈时，你能管的 Agent 数量就上升。当合并后需要你手动排查是哪个 Agent 引入的回归时，三个就是极限。

本章从隔离到集成再到平台基础设施，构建多 Agent 并行开发的完整方案。

Harness Engineering Playbook · AgentsZone Community