打造 AI 冒险团：HagiCode 多 Agent 协作配置实战

打造 AI 冒险团：HagiCode 多 Agent 协作配置实战

在现代软件开发中，单一 AI Agent 已经难以满足复杂需求。如何让来自不同公司的多个 AI 助手在同一项目中协同工作？本文将分享 HagiCode 项目在实际开发中探索出的多 Agent 协作配置方案。

背景

相信很多开发者都有过这样的经历：项目中引入了 AI 助手辅助编程，效率确实提高了。但随着需求越来越复杂，一个 AI Agent 开始不够用了——你想让它同时处理代码审查、文档生成、单元测试等多个任务，结果往往是顾此失彼，输出质量参差不齐。
更头疼的是，当你尝试引入多个 AI 助手时，问题就变得更复杂了。每个 Agent 有自己的配置方式、API 接口和执行逻辑，彼此之间甚至会产生冲突。这就像一支球队，每个球员都很厉害，但没有人知道该怎么配合，结果踢得乱七八糟。
HagiCode 项目在开发过程中也遇到了同样的困扰。作为一个涉及前端 VSCode 扩展、后端 AI 服务、跨平台桌面客户端的复杂项目，我们需要同时对接来自不同公司的多个 AI 助手：Claude Code、Codex、CodeBuddy、iFlow 等等。如何让它们在同一项目中和谐共处、发挥各自特长，成了必须解决的关键问题。
其实这也罢了，毕竟谁愿意每天跟一群打架的 AI 打交道呢。
本文分享的方案，正是我们在 HagiCode 项目中实际踩坑、实际优化出来的多 Agent 协作配置实践。如果你也在为多 AI 助手协作而头疼，相信这篇文章会给你一些启发。或许吧，毕竟每个人的情况都不一样。
关于 HagiCode

HagiCode 是一个 AI 代码助手项目，采用多 AI 引擎协同工作的"冒险团"模式。项目地址：github.com/HagiCode-org/site。
本文分享的多 Agent 配置方案，正是 HagiCode 能够在复杂项目中保持高效开发的核心技术之一。也没什么特别的，就是把一群 AI 变成一支能打配合的冒险团而已。
HagiCode 的多 Agent 架构设计

从"单打独斗"到"团队协作"

在 HagiCode 项目早期，我们也尝试过只用一个 AI Agent 来处理所有任务。很快我们就发现，这种方式存在明显的瓶颈：不同的任务需要不同的能力侧重点，有的任务需要更强的上下文理解能力，有的则需要更精准的代码修改能力。一个 Agent 很难在所有方面都表现出色。
这让我们意识到，必须让多个 Agent 协同工作。但问题是，如何让不同公司的 AI 产品在同一个项目中和平共处？我们需要解决几个核心问题：

• 配置管理复杂性：每个 Agent 有不同的配置方式、API 接口和执行模式
  
• 通信协议统一：需要一种标准化的方式让不同 Agent 之间进行数据交换
  
• 任务分工协调：如何合理分配任务，让每个 Agent 发挥特长
  

带着这些问题，我们开始设计 HagiCode 的多 Agent 架构。其实也没那么复杂，只是想明白了而已。
整体架构一览

经过多次迭代，我们最终确定的架构是这样的：

1. ┌─────────────────────────────────────────────────────────────────┐
2. │                    AIProviderFactory                             │
3. │  (工厂模式统一管理所有 AI Provider)                               │
4. ├─────────────────────────────────────────────────────────────────┤
5. │  ClaudeCodeCli  │  CodexCli  │  CodebuddyCli  │  IFlowCli    │
6. │  (Anthropic)   │  (OpenAI)  │  (智谱 GLM)     │  (智谱)      │
7. └─────────────────────────────────────────────────────────────────┘

复制代码

核心思路是：通过统一的 Provider 接口，让不同的 AI Agent 可以被同一套代码管理。同时使用工厂模式动态创建和配置这些 Provider，确保系统的扩展性和灵活性。
这就像生活中的分工，每个人都有自己的角色，只是这里把这种分工变成了代码架构而已。
Agent 类型与职责分工

根据 HagiCode 项目的实际使用经验，我们为每个 Agent 分配了不同的职责：
Agent提供商模型主要用途ClaudeCodeCliAnthropicglm-5-turbo生成技术方案和ProposalCodexCliOpenAI/Zedgpt-5.4执行精准的代码修改CodebuddyCli智谱glm-4.7优化提案描述和文档IFlowCli智谱glm-4.7归档提案和历史记录OpenCodeCli--通用代码编辑GitHubCopilotMicrosoft-辅助编程和代码补全这种分工的背后逻辑是：每个 Agent 都有自己擅长的领域。Claude Code 在理解和分析复杂需求方面表现出色，所以让它负责前期的方案设计；Codex 在代码修改方面更精准，适合处理具体的实现任务；CodeBuddy 性价比高，用来优化文档再合适不过。
毕竟适合自己的才是最好的，条条大路通罗马，只是有的路好走一点，有的路稍微曲折一点罢了。
核心配置机制

统一的 Provider 接口设计

要让不同的 AI Agent 能够被统一管理，首先需要定义一套统一的接口。HagiCode 中定义了这个接口：

1. public interface IAIProvider
2. {
3.     // 统一的 Provider 接口
4.     Task<IAIProvider?> GetProviderAsync(AIProviderType providerType);
5.     Task<IAIProvider?> GetProviderAsync(string providerName, CancellationToken cancellationToken);
6. }

复制代码

这个接口看起来很简单，但它是整个多 Agent 系统的基石。通过统一的接口，我们可以无视底层是哪个公司的 AI 产品，都以相同的方式进行调用。
其实这就是把复杂的事情简单化了，毕竟简单才是美。
Provider 工厂模式实现

有了统一的接口，接下来就是如何创建这些 Provider 实例。HagiCode 使用了工厂模式：

1. private IAIProvider? CreateProvider(AIProviderType providerType, ProviderConfiguration config)
2. {
3.     return providerType switch
4.     {
5.         AIProviderType.ClaudeCodeCli =>
6.             ActivatorUtilities.CreateInstance<ClaudeCodeCliProvider>(_serviceProvider, Options.Create(config)),
7.         AIProviderType.CodebuddyCli =>
8.             ActivatorUtilities.CreateInstance(_serviceProvider, Options.Create(config)),
9.         AIProviderType.CodexCli =>
10.             ActivatorUtilities.CreateInstance(_serviceProvider, Options.Create(config)),
11.         AIProviderType.IFlowCli =>
12.             ActivatorUtilities.CreateInstance<IFlowCliProvider>(_serviceProvider, Options.Create(config)),
13.         _ => null
14.     };
15. }

复制代码

这里用到了依赖注入的 ActivatorUtilities.CreateInstance，它可以在运行时动态创建 Provider 实例，并且自动注入依赖项。这种设计的好处是：新增一个 Agent 类型时，只需要添加对应的 Provider 类，然后在工厂方法中加一个 case 分支即可，完全不需要修改现有代码。
这也罢了，毕竟谁愿意每次加新功能都要改一堆旧代码呢。
动态配置解析

为了让配置更灵活，我们还实现了类型映射机制：

1. public static AIProviderTypeExtensions
2. {
3.     private static readonly Dictionary<string, AIProviderType> _typeMap = new(
4.         StringComparer.OrdinalIgnoreCase)
5.     {
6.         ["ClaudeCodeCli"] = AIProviderType.ClaudeCodeCli,
7.         ["CodebuddyCli"] = AIProviderType.CodebuddyCli,
8.         ["CodexCli"] = AIProviderType.CodexCli,
9.         ["IFlowCli"] = AIProviderType.IFlowCli,
10.         // ...更多类型映射
11.     };
12. }

复制代码

这个映射表的作用是将字符串形式的 Provider 名称转换为枚举类型。这样一来，配置文件就可以使用直观的字符串名称，而代码内部则使用类型安全的枚举进行处理。
毕竟配置这东西，越直观越好，谁愿意记一堆复杂的代码呢。
配置文件示例

实际使用时，只需要在 appsettings.json 中配置即可：

1. AI:
2.   Providers:
3.     Providers:
4.       ClaudeCodeCli:
5.         Enabled: true
6.         Model: glm-5-turbo
7.         WorkingDirectory: /path/to/project
8.       CodebuddyCli:
9.         Enabled: true
10.         Model: glm-4.7
11.       CodexCli:
12.         Enabled: true
13.         Model: gpt-5.4
14.       IFlowCli:
15.         Enabled: true
16.         Model: glm-4.7

复制代码

每个 Provider 都可以独立配置开关、模型版本、工作目录等参数。这种设计既保证了灵活性，又便于管理和维护。
其实配置文件就像人生的选项，你可以选择开启或关闭某些功能，只是代码里的选择更容易后悔罢了。
冒险团任务流转

任务分工的艺术

有了统一的技术架构，接下来就是如何让多个 Agent 协同工作了。HagiCode 设计了一套任务流转机制，让不同的 Agent 处理不同阶段的任务：

1. 提案创建 (用户)
2.     │
3.     ▼
4. [Claude Code] ──生成提案──▶ 提案文档
5.     │                        │
6.     │                        ▼
7.     │               [Codebuddy] ──优化描述──▶ 优化后提案
8.     │                        │
9.     │                        ▼
10.     │               [Codex] ──执行修改──▶ 代码变更
11.     │                        │
12.     │                        ▼
13.     └───────────────▶ [iFlow] ──归档──▶ 历史记录

复制代码

这种分工的好处是：每个 Agent 只需要专注于自己擅长的任务，不需要"什么都会"。Claude Code 负责从无到有生成提案，Codebuddy 负责把提案描述得更清晰，Codex 负责把提案变成实际的代码变更，iFlow 则负责把这些变更归档保存。
其实这就像生活中的团队合作，每个人都有自己的角色，合起来才能完成一件大事。只是这里的团队成员是 AI 而已。
关键实践要点

在实际运行中，我们总结了以下几点经验：
1. Agent 选择策略很重要
不是随便分配任务，而是要根据每个 Agent 的特长来分配：

• 提案生成：使用 Claude Code，因为它有更强的上下文理解能力
  
• 代码执行：使用 Codex，因为它在代码修改方面更精准
  
• 提案优化：使用 Codebuddy，因为它的性价比高
  
• 归档存储：使用 iFlow，因为它稳定可靠
  

毕竟让合适的人做合适的事，这是千古不变的道理。
2. 配置隔离确保稳定性
每个 Agent 的配置独立管理，支持环境变量覆盖，工作目录也相互独立。这样一来，一个 Agent 的配置出错不会影响到其他 Agent。
这就像生活中的界限，每个人都有自己的空间，互不干扰才能和谐共处。
3. 错误处理机制
单个 Agent 失败不应该影响整体流程。我们实现了降级策略：当某个 Agent 执行失败时，系统可以自动切换到备用方案，或者直接跳过该步骤继续执行后续任务。同时，完整的日志记录也便于事后排查问题。
毕竟谁也不能保证永远不会出错，关键是怎么处理错误。这就像人生，总会遇到挫折，重要的是怎么走出来。
4. 监控与可观测性
通过 ACP 协议（我们自定义的通信协议，基于 JSON-RPC 2.0），可以追踪每个 Agent 的执行状态。会话隔离确保了并发安全，动态缓存则优化了性能表现。
毕竟看不见的东西最容易出问题，有点监控总好过两眼一抹黑。
实际效果与收益

采用这套多 Agent 协作配置后，HagiCode 项目的开发效率有了明显提升。具体表现在：

• 任务处理能力翻倍：以前一个 Agent 需要同时处理多种任务，现在可以并行处理，吞吐量翻倍不止
  
• 输出质量更稳定：每个 Agent 只专注于自己擅长的任务，输出结果的一致性和质量都更高
  
• 维护成本降低：统一的接口和配置管理，让整个系统更容易维护和扩展
  
• 新增 Agent 简单：如果要接入新的 AI 产品，只需要实现接口、添加配置，不需要修改核心逻辑
  

这套方案不仅解决了 HagiCode 自身的问题，也证明了多 Agent 协作确实是一种可行的架构选择。
其实效果还挺明显的，只是过程有点折腾罢了。
总结

本文分享了 HagiCode 项目在多 Agent 协作配置方面的实践经验。核心要点包括：

• 标准化接口：通过 IAIProvider 统一不同 Agent 的行为，让代码可以无视底层是哪个公司的产品
  
• 工厂模式：使用 ActivatorUtilities.CreateInstance 动态创建 Provider 实例，支持运行时配置和依赖注入
  
• 协议统一：ACP 协议实现 Agent 间的标准化通信，基于 JSON-RPC 2.0 的双向通信机制
  
• 任务分流：合理分配任务给不同的 Agent，让它们各展所长，而不是试图让一个 Agent 做所有事情
  

这种设计不仅解决了"多 Agent 打架"的问题，还通过冒险团的任务流转机制，实现了开发流程的自动化和专业化。
如果你也在考虑引入多个 AI 劏手，希望本文能给你一些参考。当然，每个项目的情况不同，具体方案还需要根据实际情况调整。毕竟没有放之四海而皆准的方案，适合自己的才是最好的。
美的事物或人，不一定要占有，只要她还是美的，自己好好看着她的美就好了。技术方案也是如此，适合自己的，就是最好的......
参考资料

• HagiCode 项目地址：github.com/HagiCode-org/site
  
• HagiCode 官网：hagicode.com
  
• 视频演示：www.bilibili.com/video/BV1pirZBuEzq/
  
• 安装指南：docs.hagicode.com/installation/docker-compose
  
• Desktop 桌面端：hagicode.com/desktop/
  

如果本文对你有帮助，欢迎来 GitHub 给个 Star，您的支持是我们继续分享的动力。公测已开始，欢迎安装体验。
感谢您的阅读,如果您觉得本文有用,快点击下方点赞按钮,让更多的人看到本文。
本内容采用人工智能辅助协作,经本人审核,符合本人观点与立场。

• 本文作者: newbe36524
  
• 本文链接: https://docs.hagicode.com/blog/2026-03-17-hagicode-ai-agent-party/
  
• 版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。版权所有!
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！