多 Agent 工作流实践：从 tri-agent 到 penta-agent 的本地协作契约

一位开发者在 Dev.to 上分享了他构建多 Agent 工作流的实践经验。文章从一个实际的困扰开始：长任务被配额限制中断、对话变得过于沉重、审查需要在窗口间笨拙地复制上下文。为了解决这些问题，他在 VS Code + Arch Linux 上构建了一个多 Agent 工作流，最初叫 tri-agent，几个月后演变为 penta-agent——一个仍然不完美的协调方式，用于在他的工作流中组织 Agent、角色、权限和追踪。

背景：为什么需要多 Agent

单 Agent 的局限

使用单个 AI Agent 处理复杂任务时，会遇到几个问题：

1. 上下文溢出：长任务的对话历史越来越长，超出模型的上下文窗口
2. 配额限制：API 调用次数或 token 用量达到限制，任务被中断
3. 角色混淆：同一个 Agent 既要写代码、又要审查、还要测试，角色边界模糊
4. 注意力分散：单一上下文包含太多信息，模型难以聚焦当前任务
5. 难以追踪：复杂任务的中间产物分散在长对话中，难以追踪和复盘

多 Agent 的优势

多 Agent 系统通过分工协作解决这些问题：

• 职责分离：每个 Agent 有明确的角色和职责
• 上下文隔离：每个 Agent 有独立的上下文，不会互相干扰
• 专业聚焦：每个 Agent 专注于特定类型的任务
• 可追踪：每个 Agent 的输出是独立的产物，便于追踪
• 可并行：独立的 Agent 可以并行工作

这不是什么

作者明确指出，这不是：

• 全新的想法：多 Agent 系统已经被广泛讨论和实践
• 完全自主的承诺：系统需要人工维护和监督
• 银弹：它仍然不完美，需要持续调整

它是一个本地工作契约，规定谁执行、谁审查、何时使用 MCP、何时使用 Gemini/Antigravity、何时 Copilot 仅作为支持、加载哪些技能、以及最终应该存在什么证据或产物。

系统架构：从 tri-agent 到 penta-agent

演进过程

tri-agent (3个Agent)
    │
    ▼ 增加审查和测试角色
penta-agent (5个Agent)

最初的 tri-agent 有 3 个角色，后来扩展为 5 个角色的 penta-agent。

五个核心角色

1. 执行者（Executor）

• 职责：执行主要任务，编写代码、撰写文档、实现功能
• 工具访问：代码编辑器、终端、文件系统
• 输出：可运行的代码、文档草稿、实现方案
• 特点：行动导向，注重产出速度

2. 审查者（Reviewer）

• 职责：审查执行者的输出，检查质量、安全性、正确性
• 工具访问：代码读取、静态分析工具
• 输出：审查意见、问题列表、改进建议
• 特点：批判性思维，注重质量和安全

3. 测试者（Tester）

• 职责：编写和运行测试，验证功能正确性
• 工具访问：测试框架、覆盖率工具、CI/CD
• 输出：测试用例、测试报告、覆盖率数据
• 特点：系统性思维，注重边界情况

4. 架构师（Architect）

• 职责：设计整体架构，评估技术选型，确保一致性
• 工具访问：设计文档、架构图工具
• 输出：架构设计、技术选型建议、接口定义
• 特点：全局视角，注重可扩展性和可维护性

5. 协调者（Coordinator）

• 职责：协调各 Agent 之间的工作，管理任务流程，整合输出
• 工具访问：任务管理、文件系统、所有 Agent 的输出
• 输出：任务计划、进度报告、最终整合产物
• 特点：组织能力，注重流程和协作

角色间的工作流

用户需求
    │
    ▼
┌────────────┐
│  协调者      │  分析需求，制定计划，分配任务
└─────┬──────┘
      │
      ▼
┌────────────┐
│  架构师      │  设计架构，定义接口
└─────┬──────┘
      │
      ▼
┌────────────┐
│  执行者      │  实现功能，编写代码
└─────┬──────┘
      │
      ├──────────────┐
      ▼              ▼
┌────────────┐ ┌────────────┐
│  审查者      │ │  测试者      │
│  代码审查    │ │  编写测试    │
│  安全检查    │ │  运行测试    │
└─────┬──────┘ └─────┬──────┘
      │              │
      └──────┬───────┘
             ▼
      ┌────────────┐
      │  协调者      │  整合反馈，决定是否需要返工
      └─────┬──────┘
            │
       ┌────┴────┐
       │ 有问题?  │
       └────┬────┘
        是│    │否
         ▼    ▼
    执行者返工  最终产物

关键设计决策

1. 本地优先

作者强调这是一个本地工作契约：

• 数据本地：所有对话和产物保存在本地
• 工具本地：使用本地的 VS Code、终端、文件系统
• 控制本地：用户完全控制工作流，不依赖云端服务
• 隐私保护：敏感数据不需要发送到第三方服务

2. 明确的角色边界

每个 Agent 有明确的角色定义：

• 职责清单：明确列出每个角色负责什么、不负责什么
• 工具权限：每个角色只能访问特定的工具
• 输出格式：每个角色的输出有标准格式
• 交接规范：角色之间的交接有明确的规范

角色定义示例：

执行者:
  职责: 实现功能、编写代码、修复bug
  工具: 代码编辑器、终端、文件系统读写
  输出: 可运行的代码、实现说明
  不负责: 架构设计、代码审查、测试编写

审查者:
  职责: 代码审查、安全检查、质量评估
  工具: 代码读取、静态分析（只读）
  输出: 审查报告、问题列表、改进建议
  不负责: 直接修改代码、执行测试

3. 追踪与证据

每个 Agent 的工作都有可追踪的证据：

• 对话记录：每个 Agent 的对话历史独立保存
• 产物文件：每个 Agent 的输出保存为独立文件
• 变更日志：记录每次修改的内容和原因
• 决策记录：记录重要的技术决策和理由

这使得复盘和审计成为可能。

4. MCP 的使用时机

MCP（Model Context Protocol）的使用有明确的时机：

• 执行者：使用 MCP 访问代码库、文档、数据库
• 审查者：使用 MCP 读取代码、运行静态分析
• 测试者：使用 MCP 运行测试、查看覆盖率
• 架构师：使用 MCP 查看项目结构、依赖关系
• 协调者：使用 MCP 管理任务、整合产物

5. 不同模型的分工

作者使用了多个不同的模型，各有分工：

• Gemini / Antigravity：用于复杂推理、架构设计、长文本处理
• Copilot：用于代码补全、简单重构、日常辅助
• 其他模型：根据任务特点选择最合适的模型

这体现了"没有万能模型"的理念——不同模型有不同的优势，应该根据任务选择。

实际应用场景

作者列举了他使用这个工作流的实际场景：

1. 备忘录和文档

• 执行者：起草备忘录初稿
• 审查者：检查逻辑、清晰度、准确性
• 协调者：整合反馈，生成最终版本

2. 法规审查

• 架构师：分析法规要求，定义合规框架
• 执行者：实现合规检查逻辑
• 审查者：审查合规性，识别风险
• 测试者：编写合规测试用例

3. 电子表格和统计模型

• 执行者：构建电子表格和统计模型
• 审查者：检查公式、数据、假设
• 测试者：验证计算结果，测试边界情况

4. 家庭服务器脚本

• 执行者：编写自动化脚本
• 审查者：审查安全性、可靠性
• 测试者：在测试环境运行验证

5. 系统定时器和自托管云

• 架构师：设计系统架构
• 执行者：实现配置和部署脚本
• 审查者：审查安全性、可维护性

6. 路由器安全和备份

• 架构师：设计安全策略和备份方案
• 执行者：实现配置
• 审查者：安全审计
• 测试者：验证备份恢复流程

7. 博客和日常维护

• 执行者：撰写博客文章、执行维护任务
• 审查者：编辑和校对
• 协调者：发布和记录

经验教训

1. 维护需要投入

作者坦诚地说："维护它需要工作。"

• 配置维护：角色定义、工具权限、工作流需要持续调整
• 模型更新：模型更新后可能需要调整提示词和工作流
• 问题排查：多 Agent 系统的问题排查比单 Agent 复杂
• 成本控制：多个 Agent 意味着更多的 API 调用和成本

2. 不是所有任务都需要多 Agent

• 简单任务：单 Agent 足够，多 Agent 反而增加 overhead
• 短任务：任务时间短，多 Agent 的启动成本不值得
• 低风险任务：不需要严格审查的任务，单 Agent 即可
• 建议：根据任务复杂度和风险等级选择是否使用多 Agent

3. 协调者是关键

多 Agent 系统的效率很大程度上取决于协调者：

• 任务分配：协调者需要正确地将任务分配给合适的 Agent
• 进度跟踪：协调者需要跟踪每个 Agent 的进度
• 冲突解决：当 Agent 之间有分歧时，协调者需要裁决
• 整合输出：协调者需要将多个 Agent 的输出整合为最终产物

如果协调者能力不足，整个系统会陷入混乱。

4. 上下文传递是难点

• 信息丢失：Agent 之间传递信息时，重要的上下文可能丢失
• 信息过载：传递太多信息会导致新的上下文溢出
• 格式不一致：不同 Agent 的输出格式可能不一致
• 解决方案：定义标准的交接格式，使用结构化的中间产物

5. 可能产生虚假的数字主权感

作者自我反思："也许这也是一种虚假的数字主权感。我不能免疫于此。"

• 本地不等于自主：即使工作流在本地，仍然依赖外部的 AI 模型 API
• 控制幻觉：可能过度估计了自己对系统的控制程度
• 持续审视：需要持续审视多 Agent 系统的实际价值和局限性

与其他多 Agent 框架的对比

实践建议

对于想尝试多 Agent 的开发者

1. 从 2 个 Agent 开始：先尝试执行者 + 审查者的简单组合
2. 定义清晰的角色：花时间写清楚每个角色的职责和边界
3. 使用文件系统交接：用文件作为 Agent 之间的交接媒介，简单可靠
4. 从小任务开始：先用简单任务验证工作流，再逐步扩展
5. 记录问题：记录遇到的问题和解决方案，持续改进

对于已经在使用多 Agent 的团队

1. 评估效率：定期评估多 Agent 工作流是否真的提高了效率
2. 优化协调：重点优化协调者的能力，这是系统的瓶颈
3. 标准化交接：建立标准的 Agent 间交接格式和协议
4. 监控成本：监控多 Agent 系统的 API 调用成本
5. 知识沉淀：将多 Agent 工作流中的经验沉淀为可复用的模板

常见误区

1. Agent 越多越好：不是，Agent 数量应该根据任务需要确定
2. 完全自主：多 Agent 系统仍然需要人工监督和干预
3. 一次配置永久使用：工作流需要持续调整和优化
4. 替代人工审查：多 Agent 审查不能完全替代人工审查
5. 适用于所有任务：简单任务用单 Agent 更高效

未来展望

短期

• 更好的协调工具：专门的多 Agent 协调工具会更加成熟
• 标准化协议：Agent 间通信和交接的标准化协议
• 本地模型支持：更好地支持本地模型，降低对云端 API 的依赖
• 可视化工作流：可视化的多 Agent 工作流设计和监控工具

中期

• 自适应角色：Agent 能够根据任务自动调整角色和职责
• 动态团队组建：根据任务需求自动组建合适的 Agent 团队
• 经验学习：Agent 能够从过去的协作经验中学习，改进协作方式
• 人机协作优化：更好地平衡人工和自动化的分工

长期

• 完全自主的多 Agent 系统：能够自主完成复杂任务的多 Agent 系统
• Agent 经济：Agent 之间可以交易服务和资源的经济系统
• 通用人工智能的路径：多 Agent 协作可能是实现通用人工智能的路径之一

总结

多 Agent 工作流是解决复杂任务的有效方式，但它不是银弹。

核心要点：

1. 背景：单 Agent 面临上下文溢出、配额限制、角色混淆等问题，多 Agent 通过分工协作解决
2. 架构：从 tri-agent 演进到 penta-agent，五个核心角色——执行者、审查者、测试者、架构师、协调者
3. 关键设计：本地优先、明确角色边界、追踪与证据、MCP 使用时机、不同模型分工
4. 应用场景：备忘录、法规审查、统计模型、服务器脚本、系统运维、博客维护等
5. 经验教训：维护需要投入、不是所有任务都需要、协调者是关键、上下文传递是难点、可能产生虚假主权感
6. 实践建议：从 2 个 Agent 开始、定义清晰角色、使用文件系统交接、从小任务开始、记录问题

对于个人开发者来说，构建一个适合自己工作流的多 Agent 系统是值得尝试的。它可以帮助组织复杂任务、提高产出质量、减少上下文管理的负担。但正如作者所强调的，这需要持续的维护和调整，而且不是所有任务都适合用多 Agent。关键是根据自己的实际需求，找到合适的平衡点。

原文链接：https://dev.to/tatanlabra/multi-agent-work-in-three-spoonfuls-what-worked-for-me-and-what-did-not-44g9