前面的几篇文章，我们一直在解决一个问题：

如何让 AI 从“聊天助手”变成真正参与工作的系统。

第一篇，我们把 Hermes 从聊天机器人改造成 24 小时 AI 工作台。

解决的是：

任务从哪里进入？

通过：

Gateway
Cron
Webhook

让 Agent 不再只是等待用户提问，而能够主动接收任务。

---

第二篇，我们讨论多 Agent 协作为什么不能靠聊天。

解决的是：

多个 Agent 怎么一起完成复杂任务？

通过：

Kanban
Task
Dispatcher

把一次性对话变成可追踪、可恢复的任务流程。

---

第三篇，我们讨论为什么一个 Agent 不应该承担所有角色。

解决的是：

不同工作应该由谁负责？

通过：

Profile

把研究、开发、写作、运维拆成不同工作身份。

---

第四篇，我们继续补齐工具层。

解决的是：

Agent 怎么连接真实系统？

通过：

MCP

让 Agent 能访问：

• GitHub；

• 文件系统；

• 数据库；

• 浏览器；

• 内部 API。

---

但到了真正的软件开发场景，又会出现一个新的问题：

如果已经有：

• Hermes；

• Claude Code；

• Gemini CLI；

• Codex；

这些 AI 工具，到底应该怎么组合？

很多人第一反应是：

哪个模型写代码最好？

哪个工具能力最强？

我要不要只选一个？

但实际工程里，这个问题可能问错了。

因为一个真实的软件任务，并不是简单的“写几行代码”。

它通常包含：

不同阶段，需要的能力并不一样。

研究阶段需要找到事实。

设计阶段需要理解架构。

实现阶段需要精准修改。

审查阶段需要发现风险。

如果让一个 Agent 从头做到尾，它最终还是会回到前面提到的问题：

• 上下文越来越长；

• 工具权限越来越多；

• 角色边界越来越模糊；

• 失败以后很难恢复。

所以，我现在更倾向于另一种设计：

不要寻找一个万能 Agent，而是组建一支 AI 工程队。

---

一、从万能 Agent 到 AI 工程队

在人类软件团队里，不会要求一个人同时承担：

• 产品经理；

• 架构师；

• 开发工程师；

• 测试工程师；

• 运维工程师。

原因不是这个人一定做不到。

而是长期来看：

角色混合，会导致上下文、责任和质量标准混乱。

AI 也是一样。

更合理的方式是：

              Hermes

                │

        任务拆解与调度

                │

 ┌──────────────┼──────────────┐

 │              │              │

Researcher   Architect      Developer

 │              │              │

Gemini CLI   Claude Code    Codex

其中：

• Hermes 负责组织任务；

• 不同 Worker 负责执行；

• 每个 Worker 输出标准交付物；

• 下一阶段继续消费上一阶段结果。

重点不是让几个 AI 聊天。

而是让几个 AI 像团队成员一样交付。

---

1. 以一个登录 Bug 为例，看 AI 工程队如何工作

假设收到一个需求：

用户登录失败后，希望增加自动重试机制。

如果直接丢给一个 Agent：

帮我优化登录失败问题。

它需要自己猜：

• 当前问题在哪里？

• 哪些代码相关？

• 是否需要修改接口？

• 有没有历史原因？

• 测试怎么补？

结果往往不可控。

更好的拆法：

---

第一步：Researcher 收集事实

任务：

分析登录失败问题。

交付：

问题现象：

相关模块：

历史提交：

已有方案：

风险点：

待验证问题：

它关注的是：

把未知问题变成已知信息。

---

第二步：Architect 设计方案

任务：

根据分析结果设计修复方案。

交付：

修改范围：

涉及文件：

技术方案：

兼容风险：

测试策略：

它关注的是：

确定应该怎么改。

---

第三步：Developer 执行修改

任务：

按照方案实现代码修改。

交付：

修改文件：

代码 Diff：

测试命令：

测试结果：

剩余风险：

它关注的是：

在明确边界内完成实现。

---

第四步：Reviewer 验收

任务：

检查实现是否满足要求。

交付：

发现问题：

风险等级：

建议修改：

是否通过：

它关注的是：

证明事情真的完成。

---

这时候你会发现：

真正驱动系统运行的，不是某个模型有多强。

而是：

这才是 AI 工程化的核心。

---

二、Claude Code、Gemini CLI、Codex：不要比较谁更强，要明确谁负责什么

很多人在选择 AI 编程工具时，第一反应是做排名：

Claude Code 谁更强？
Gemini CLI 上下文更长吗？
Codex 写代码是不是更快？

但真正进入工程场景后，这个问题的意义并不大。

因为一个完整研发任务，并不是只有“写代码”这一件事。

它包含：

每个阶段需要的能力不同。

如果让一个工具承担全部环节，短期看起来方便，长期一定会遇到和“万能 Agent”一样的问题：

• 上下文越来越混乱；

• 工具权限越来越大；

• 任务边界越来越模糊；

• 出问题后无法定位责任。

所以更合理的方式不是寻找一个“最强 Agent”。

而是建立一支 AI 工程队。

---

1. Gemini CLI：研究员角色，负责把事实搞清楚

在这套体系里，我更倾向于把 Gemini CLI 放在 Researcher 的位置。

它主要负责：

发现信息
分析资料
整理证据
输出研究结果

适合处理：

• 阅读官方文档；

• 查询 API 变化；

• 分析 GitHub Issue；

• 阅读大量日志；

• 对比技术方案；

• 总结已有实现方式。

它的核心价值不是马上修改代码。

而是降低后续执行者的不确定性。

例如，一个登录失败问题。

研究任务不应该直接变成：

“帮我修复登录失败。”

而应该拆成：

任务：
分析登录失败原因。

输入：
Issue、日志、认证模块代码、官方文档。

输出：
1. 已确认事实；
2. 可能原因；
3. 相关代码位置；
4. 排除项；
5. 建议修复方向。

最终产物应该类似：

research-report.md

内容包括：

问题现象：
登录接口返回 401。

确认原因：
Token 刷新逻辑存在边界问题。

证据：
auth/token.go 第 128 行。

相关影响：
移动端登录流程可能受影响。

建议：
调整 refresh token 生命周期判断。

这个结果交给后面的工程角色，而不是让每个 Agent 重新调查一次。

---

2. Claude Code：架构工程师角色，负责理解和设计

Claude Code 更适合承担复杂代码理解和方案设计。

它的优势不只是“写代码”。

更重要的是：

理解大型代码库里的关系。

例如：

一个需求：

给支付系统增加失败重试机制。

真正困难的不是增加一个 if 判断。

而是需要知道：

• 当前支付流程在哪里；

• 哪些服务调用它；

• 重试是否会导致重复扣款；

• 哪些异常可以重试；

• 哪些异常必须立即失败；

• 测试覆盖在哪里。

这类任务更像高级工程师工作。

因此 Claude Code 更适合输出：

design.md

例如：

修改范围：

payment/service.go

payment/retry.go


不修改：

数据库结构

支付接口协议


风险：

重复支付风险

需要增加幂等检查。


验证：

新增支付失败测试。

这个阶段最重要的是：

不是马上改。

而是先判断：

“应该怎么改。”

---

3. Codex：执行工程师角色，负责明确边界内完成修改

Codex 更适合进入执行阶段。

当目标已经明确：

• 改哪些文件；

• 不改哪些内容；

• 如何验收；

它可以快速完成：

• 修改代码；

• 创建测试；

• 执行命令；

• 修复编译错误；

• 输出变更结果。

比如：

不要给 Codex：

帮我优化认证模块。

这个任务太开放。

应该给：

目标：
修复登录失败重试问题。

输入：
research.md
design.md

限制：
只修改 auth 目录。
不修改 API 协议。
不改变数据库结构。

输出：
1. 修改文件列表；
2. 测试结果；
3. 剩余风险。

这时候执行 Agent 的效率会明显提升。

因为它不需要猜方向。

它只需要完成明确任务。

---

三、不要互相替代：能力重叠，不等于职责重叠

很多人会觉得：

“既然 Claude Code 也能查资料，Gemini CLI 也能写代码，Codex 也能分析代码，为什么还要拆？”

原因很简单：

能力重叠，不代表职责应该重叠。

人类团队也是如此。

架构师也会写代码。

程序员也会查资料。

测试工程师也懂业务。

但是不会因为这些能力重叠，就让所有人承担所有职责。

因为长期协作需要的是：

• 清晰责任；

• 稳定交付；

• 风险隔离。

---

1. 一个错误设计

最后会变成：

一个超级 Agent

+
越来越大的上下文

+
越来越多权限

+
越来越难控制

这实际上又回到了第一篇文章的问题。

---

2. 更合理的设计

这里每个工具都发挥自己的优势。

同时，每个工具都有明确边界。

---

四、真正重要的是交付物，而不是聊天过程

多 Agent 系统最容易犯的错误：

让几个 Agent 开会。

例如：

Gemini：
我觉得可能是 Token 问题。

Claude：
我认为应该看看中间件。

Codex：
我可以尝试修改。

Gemini：
补充一点……

看起来很智能。

实际上没有形成工程资产。

因为聊天记录不是交付物。

真正有效的协作应该是：

每一步都留下：

• 输入；

• 输出；

• 判断依据；

• 下一步动作。

这样 Hermes 才能继续调度。

---

AI 工程队和普通聊天最大的区别，就是它不是交换观点，而是在交换可验证的工作成果。

五、Hermes 调度架构：Kanban + Worker + MCP

前面两部分解决了两个问题：

第一个问题：

为什么不要让一个 Agent 做所有事情？

答案是：

因为研究、设计、编码、审查需要不同能力和不同边界。

第二个问题：

Claude Code、Gemini CLI、Codex 为什么不能互相替代？

答案是：

因为它们应该成为不同岗位，而不是三个聊天机器人。

但还有一个关键问题：

谁负责把这些岗位组织起来？

如果没有调度层，最后还是会回到：

用户：
帮我解决登录问题。

Gemini：
我查了一些资料。

Claude：
我觉得应该这样改。

Codex：
我改了一版代码。

Gemini：
我再看看。

Claude：
我补充一下。

看起来大家都参与了。

实际上没有项目管理，没有任务状态，也没有明确交接。

这也是为什么前面几篇一直强调：

多 Agent 的核心不是增加 Agent 数量，而是建立任务协议。

而 Hermes 扮演的，就是这个协议执行层。

---

1. Hermes 不应该成为第四个 Worker

很多人理解 Hermes 时，会产生一个误区：

看到 Claude Code、Gemini CLI、Codex 都能写代码，就想：

“那 Hermes 是不是也应该成为一个更强的编码 Agent？”

我认为不是。

如果 Hermes 也加入代码竞争，它最终会变成：

Gemini 查资料

Claude 分析

Codex 写代码

Hermes 又重新分析一遍

结果：

• 成本增加；

• 上下文重复；

• 任务边界混乱。

Hermes 更像一个工程管理层。

它负责：

类似一个技术负责人。

它不一定亲自提交每一行代码。

但它知道：

• 现在谁在做什么；

• 下一步应该交给谁；

• 哪个环节失败；

• 什么条件才能进入下一阶段。

---

2. Hermes + Kanban：让 AI 团队真正有“项目状态”

前面讲 Kanban 时提到：

聊天记录不是任务状态。

这句话在多工具协作里更加重要。

因为三个 Worker 的工作方式完全不同。

Gemini CLI 可能花 20 分钟阅读文档。

Claude Code 可能花 30 分钟分析代码结构。

Codex 可能需要多轮修改和测试。

如果全部存在聊天上下文里：

Gemini:
我找到几个相关 Issue。

Claude:
好的，我开始分析。

Codex:
我改了一版。

Claude:
等等，我没看到完整背景。

任务马上失控。

Kanban 的作用，就是把每个阶段固化成任务卡。

例如：

---

Task 1：问题研究

标题：
分析登录失败原因


负责人：
researcher


输入：
用户反馈
错误日志
Issue


执行：
Gemini CLI


输出：
research.md


验收：
包含：
- 已确认事实
- 相关代码位置
- 历史问题
- 建议方向

---

Task 2：方案设计

标题：
设计登录重试方案


负责人：
architect


输入：
research.md


执行：
Claude Code


输出：
design.md


验收：
包含：
- 修改范围
- 技术方案
- 风险分析
- 测试策略

---

Task 3：代码实现

标题：
实现登录失败重试


负责人：
coder


输入：
research.md
design.md


执行：
Codex


输出：
patch
test-result.md


验收：
- 测试通过
- 无接口破坏
- 输出修改文件

---

Task 4：代码审查

标题：
Review 登录重试改动


负责人：
reviewer


输入：
代码 diff
测试结果


输出：
review.md


验收：
- 风险确认
- 是否允许合并

---

这时候 AI 团队才真正像一个工程团队。

不是：

几个 AI 在聊天

而是：

几个 AI 在交付

---

3. 完整 AI 工程队调度架构

整个系统可以抽象成下面：

这里有几个关键点。

---

4. Hermes 不直接传递聊天，而传递任务

错误方式：

Gemini：
我发现登录模块有问题。

Hermes：
Codex，你看看。

这是聊天。

正确方式：

Task:
实现登录失败重试


Input:
research.md


Constraint:
禁止修改数据库结构


Output:
代码修改 + 测试结果

这是工程协作。

---

5. Worker 不共享全部上下文

很多人会犯一个错误：

把所有聊天记录全部塞给每个 Agent。

结果：

Coder 看到：

• 用户历史讨论；

• Gemini 搜索过程；

• Claude 的所有推理；

• 大量无关信息。

上下文越来越长。

更好的方式：

只传递必要交付物。

例如：

Codex 不需要知道：

Gemini 看过哪些网页。

它只需要：

research.md
design.md
验收条件

这叫：

基于交付物的上下游协作。

---

六、一个真实开发流程示例

假设需求：

给订单系统增加自动退款功能。

传统方式：

开发人员自己完成：

AI 工程队模式：

---

阶段 1：需求进入

用户：

增加自动退款功能。

Hermes 创建：

Epic:
订单退款自动化

拆成：

Task-001
调研退款流程

Task-002
设计技术方案

Task-003
实现接口

Task-004
测试验证

Task-005
生成发布说明

---

阶段 2：Research

Gemini CLI：

读取：

• 产品文档；

• API 文档；

• 历史 Issue；

• 数据库结构。

输出：

refund-research.md

内容：

当前退款入口：
xxx


涉及服务：
order-service


风险：
支付状态同步问题

---

阶段 3：Architecture

Claude Code：

读取：

refund-research.md

分析：

• 修改哪些模块；

• 是否需要新增接口；

• 是否影响订单状态机。

输出：

refund-design.md

---

阶段 4：Implementation

Codex：

读取：

refund-design.md

执行：

• 修改代码；

• 添加测试；

• 执行 CI。

输出：

commit
test-report.md

---

阶段 5：Review

Reviewer：

检查：

• diff；

• 测试；

• 风险。

输出：

review-report.md

---

最终 Hermes 汇总：

需求：
完成


代码：
commit xxx


测试：
全部通过


风险：
支付接口仍需人工确认


状态：
等待发布

这才是一条完整闭环。

---

七、为什么这种模式比“超级 Agent”更稳定

超级 Agent 最大的问题：

所有东西都在一个上下文里。

长期运行会出现：

记忆污染
+
权限扩大
+
任务混乱
+
无法恢复

AI 工程队模式：

Hermes：
负责组织


Gemini：
负责寻找事实


Claude：
负责判断方案


Codex：
负责执行修改


Review：
负责验证

每个人只需要做好自己的工作。

系统复杂度反而降低。

---

八、落地原则 + 总结收束

前面三部分，我们把一套 AI 工程队拆开了。

不是：

一个超级 Agent

而是：

Hermes
负责调度

Profile
负责角色隔离

Skill
负责工作方法

Kanban
负责任务状态

MCP
负责连接系统

Claude Code / Gemini CLI / Codex
负责具体执行

这套结构的重点，不是让 AI 数量变多。

而是让每个 AI 都知道：

自己负责什么，输入是什么，输出是什么，什么时候应该停下来等待。

这才是 AI 从 Demo 走向生产工作的关键。

---

1. 不要一开始就搭“全自动 AI 软件公司”

这是很多团队最容易踩的坑。

看到 Agent、MCP、多模型协作，很容易产生一个想法：

能不能直接让 AI 自动接需求、自动写代码、自动上线？

技术上可以探索。

但工程上风险很高。

因为真正复杂的不是：

AI 会不会写代码

而是：

需求是否理解正确？
修改范围是否合理？
风险有没有识别？
上线是否允许？
出了问题谁负责？

所以第一阶段，不应该追求：

完全自动化

而应该追求：

可控自动化

---

更现实的路线：

阶段 1：AI 辅助

目标：

让 AI 提高个人效率。

例如：

Gemini CLI
查资料

Claude Code
分析方案

Codex
执行修改

人负责：

• 判断方向；

• 审核结果；

• 决定是否采用。

---

阶段 2：AI 协作

目标：

让多个 Agent 开始分工。

加入：

Hermes
+
Kanban
+
Profile

让任务可以：

• 自动分配；

• 状态跟踪；

• 失败恢复；

• 留存记录。

---

阶段 3：AI 工作流自动运行

目标：

处理固定类型任务。

例如：

每天：

这时候 AI 才真正成为工作系统的一部分。

---

2. 第一个 AI 工程队，不要超过 4 个角色

很多人设计 Agent 架构时，会直接创建：

需求 Agent

产品 Agent

架构 Agent

开发 Agent

测试 Agent

安全 Agent

运维 Agent

文档 Agent

最后发现：

管理 Agent 比管理人还麻烦。

对于个人和小团队，我建议从最小配置开始：

也就是：

1. Researcher

负责：

• 查资料；

• 看 Issue；

• 分析日志；

• 整理事实。

工具：

• Gemini CLI；

• 浏览器；

• 文档 MCP。

输出：

research.md

---

2. Engineer

负责：

• 方案设计；

• 修改代码；

• 测试验证。

工具：

• Claude Code；

• Codex；

• Git；

• Terminal。

输出：

design.md

patch

test-result.md

---

3. Reviewer

负责：

• 检查风险；

• 验证结果；

• 提出问题。

输出：

review.md

---

不要追求 Agent 数量。

先让三个角色稳定协作，比十个角色互相聊天更有价值。

---

3. 真正决定效果的不是模型，而是任务设计

很多人测试 AI 工具时，会问：

“哪个模型写代码最好？”

这个问题有价值，但不是最核心。

因为同一个模型：

给它：

帮我优化一下订单系统。

结果可能很差。

给它：

目标：
增加退款重试机制。


范围：
只修改 payment-service。


限制：
不能修改订单状态定义。


输入：
refund-design.md。


输出：
代码修改、
测试结果、
风险说明。


验收：
支付测试全部通过。

结果完全不同。

区别在哪里？

不是模型。

是任务协议。

---

AI 工程真正需要标准化的是：

输入标准

明确：

任务背景

已有资料

限制条件

参考文件

---

执行标准

明确：

允许做什么

禁止做什么

使用哪些工具

---

输出标准

明确：

代码在哪里

报告在哪里

测试是否通过

剩余风险是什么

---

这也是为什么 Hermes + Kanban 有价值。

它把这些东西固定下来。

---

4. 不要让 Hermes 变成新的万能 Agent

这是最后一个容易犯的错误。

很多人搭完：

Hermes
+
Claude Code
+
Gemini
+
Codex

之后，会发现：

Hermes 越来越聪明。

于是开始：

• 自己查资料；

• 自己写代码；

• 自己 Review；

• 自己决定上线。

最后又回到了：

万能 Agent

只是换了一个名字。

正确定位应该是：

Hermes = Orchestrator

它负责：

知道有什么任务

知道谁负责

知道什么时候交接

知道什么时候等待

知道什么时候请求人工确认

而不是：

所有事情自己做

---

5. 工具会变化，但架构不会

这一点非常重要。

今天：

Claude Code
Gemini CLI
Codex

可能是优秀选择。

未来可能出现：

新的 Coding Agent。

新的模型。

新的工具协议。

甚至新的 MCP 替代方案。

但是稳定的部分不会变：

任务拆解

角色边界

状态管理

工具权限

交付验收

这些才是 AI 工作系统的基础设施。

---

6. 最终架构：AI 从聊天到工程系统

整个 Hermes AI 工程队，可以总结成：

最终形成：

这就是一个真正可运行的 AI 工作流。

---

写在最后：不要寻找最强 Agent，要设计最好的团队

过去我们习惯问：

哪个 AI 最强？

但进入 Agent 时代，问题正在变化。

更重要的问题是：

这件工作应该交给谁？

一个优秀的软件团队，不是因为每个人都一样强。

而是因为：

产品知道目标。

架构知道方向。

开发知道实现。

测试知道验证。

管理知道协调。

AI 工程队也是一样。

Hermes 不需要成为世界上最强的编码 Agent。

Claude Code 不需要替代所有工具。

Gemini CLI 不需要负责所有研究。

Codex 不需要承担所有执行。

它们只需要在正确的位置发挥作用。

最终：

不是让 AI 替代工程团队，而是让 AI 自己形成一支可管理、可协作、可验证的工程团队。

这才是 Hermes 这类 Agent 系统真正值得探索的方向。

---