2026 AI Agent 工具全景:执行层、编排层与 IDE 层的分工与选型
写于 2026 年 6 月 | 面向希望在团队中系统性引入 AI Agent 的工程师

背景:为什么现在需要区分这些工具
过去一年,AI 编程工具的数量爆炸式增长。Claude Code、Cursor、Hermes、Multica、Kiro......每隔几周就有新项目冲上 GitHub Trending。但大多数讨论都停留在"哪个更好用"的横向比较,忽略了一个更重要的问题:这些工具根本不在同一个抽象层上,拿来直接比较本身就是错的。
本文的目标是建立一套清晰的分类框架,厘清三类工具的定位、边界与组合方式,帮助你做出有依据的选型决策。
一、三层架构模型
理解当前 AI Agent 生态,最有效的切入点是一个三层模型:
┌─────────────────────────────────────────┐
│ 编排层 Orchestration │ ← Multica
│ 任务分配 · 进度追踪 · 技能库 · 审核 │
├─────────────────────────────────────────┤
│ 执行层 Execution │ ← Hermes · OpenClaw · Claude Code · Codex
│ 读写文件 · 跑测试 · 调 API · 提交代码 │
├─────────────────────────────────────────┤
│ IDE 层 Interface │ ← Cursor · Kiro · Windsurf
│ 代码补全 · Spec 生成 · 内嵌 Chat │
└─────────────────────────────────────────┘
每一层解决的问题不同,因此衡量它们的指标也不同。把 Multica 和 Hermes 放在一起比"哪个更强",就像比较 Kubernetes 和 Docker------前者调度,后者运行,本质上是上下游关系。
二、执行层(Execution Layer)
执行层工具的核心职责是接收一个任务,把它做完。它们直接操作文件系统、终端、浏览器和外部 API。
代表工具对比
| Claude Code | Hermes Agent | OpenClaw | Codex CLI | |
|---|---|---|---|---|
| 出品方 | Anthropic | Nous Research | 开源社区 | OpenAI |
| 发布时间 | 2025 年 | 2026 年 2 月 | 2025 年 | 2025 年 |
| 运行方式 | 终端 CLI | 后台服务 + 消息平台 | 终端 CLI | 终端 CLI |
| 跨会话记忆 | 依赖 CLAUDE.md(人工维护) | 三层持久记忆(自动) | SOUL.md(人工维护) | 无 |
| 技能自进化 | 无 | 有(自动提取 Skill 文件) | 无 | 无 |
| 模型支持 | 仅 Anthropic | 400+ 模型(OpenRouter/Ollama 等) | 多模型 | 仅 OpenAI |
| 沙箱隔离 | 有 | Docker / 多后端 | 有 | 有 |
| 适合场景 | 大型代码库重构、深度推理任务 | 长期运行、需要积累经验的任务 | 多渠道接入、灵活路由 | 轻量脚本、快速一次性任务 |
核心差异:有无"记忆"
执行层工具最本质的分水岭是是否有跨会话记忆:
- 无记忆型(Claude Code、Codex CLI):每次任务从零开始,上下文靠人工在配置文件里维护。优点是行为可预期、可审计,适合对一致性要求高的生产环境。
- 有记忆型(Hermes):完成任务后自动将可复用步骤提取成 Markdown 技能文件,下次遇到类似任务直接调用。优点是越用越强,缺点是早期对话里记录的错误信息可能"污染"后续行为,需要定期维护技能库。
选型建议:一次性任务或需要严格可审计 → Claude Code / Codex CLI;长期运行、希望 Agent 积累项目经验 → Hermes。
三、编排层(Orchestration Layer)
编排层工具不执行具体操作,它的职责是管理执行层工具的工作流:谁去做、什么时候做、做完了没有、结果是否符合预期。
代表工具:Multica
Multica 是目前开源生态中最典型的编排层工具,其核心设计理念是将 Agent 视为与人类平等的"一等公民"------Agent 拥有个人档案,出现在看板上,接受任务分配,汇报进度,就像一个真实的团队成员。
核心能力:
- Issue 与看板:任务以 Issue 形式创建,可分配给人类或任意 Agent CLI(claude、codex、hermes、kiro-cli 等均支持)
- 技能库(Skills):Agent 解决过的问题沉淀为团队共享技能,下次其他 Agent 遇到类似问题可直接复用
- 运行时管理(Runtimes):统一监控所有本地 daemon 和云端运行时的实时状态
- 自部署支持:完全开源(Apache 2.0 修改版),可用 Docker Compose 部署在自己的服务器上,代码和 API Key 不经过第三方
和执行层的关系:
Multica(编排)
└─ 分配 Issue ──▶ Hermes daemon(执行)──▶ 完成任务,汇报状态
└─ 分配 Issue ──▶ Claude Code daemon(执行)──▶ 完成任务,汇报状态
└─ 分配 Issue ──▶ 人类工程师──▶ 完成任务,更新状态
适合场景:有多个 Agent 并行运行、需要统一追踪进度的团队;或者希望将 AI Agent 纳入现有项目管理流程(类似 Linear 但 Agent 是一等公民)的场景。
不适合场景:只有一个开发者、偶尔让 AI 改改代码------引入编排层的管理开销大于收益。
四、IDE 层(Interface Layer)
IDE 层工具的核心价值是降低开发者与 AI 交互的摩擦,它们嵌入在编写代码的工作流中,提供补全、内嵌 Chat 和 Agent 模式。
代表工具对比
| Cursor | Kiro | Windsurf | |
|---|---|---|---|
| 出品方 | Anysphere | AWS | Cognition AI |
| 底层 | VS Code fork | Code OSS | AI 原生 IDE |
| 核心差异 | 速度优先,Tab 补全最强 | Spec 驱动,先规划再写码 | Flow State 上下文追踪 |
| Agent 模式 | Background Agent,8 路并行 | Auto Agent + Spec 模式 | Cascade Agent |
| AWS 集成 | 无 | 原生(Lambda/CDK/CloudFormation) | 无 |
| 定价 | $20/月 | 免费层 + $19/月 | 免费层 + 订阅 |
| 国内网络 | 相对友好 | AWS 后端,无国内节点 | 相对友好 |
Kiro 的特殊性:Spec-Driven Development
Kiro 是这一层里定位最独特的工具。它的核心理念是在写任何代码之前,先把需求想清楚------输入一个自然语言描述,Kiro 先生成 requirements.md、design.md、tasks.md,经你审核确认后再动手写代码。
这个思路对复杂功能和团队协作场景有明显价值:需求文档本身成为活的规范,减少"AI 理解偏差导致的返工"。代价是对改个 CSS 这类小任务来说明显偏重。
2026 年 5 月,AWS 关闭了 Amazon Q Developer 的新用户注册,Kiro 成为 AWS 官方 AI 编程工具的唯一入口,对 AWS 技术栈团队来说迁移几乎是必然的。
五、一张表总结
| 维度 | 执行层(Hermes / Claude Code) | 编排层(Multica) | IDE 层(Cursor / Kiro) |
|---|---|---|---|
| 核心问题 | 怎么把一件事做好 | 谁去做、做完了没有 | 写代码时怎么和 AI 协作 |
| 使用者 | 被调用的 Agent | 团队/项目管理者 | 写代码的开发者 |
| 有无 UI | 终端 CLI | Web 看板 | IDE 界面 |
| 跨任务记忆 | Hermes 有,其他基本没有 | 技能库跨 Agent 共享 | 通常无 |
| 可并行度 | 单任务为主 | 天然支持多 Agent 并行 | 部分支持(Cursor 8 路) |
| 成本 | API token 费用 | 平台免费(自部署)+ API 费用 | 0--20/月订阅 |
| 典型比喻 | 工人 | 工头/项目经理 | 工人的工具台 |
六、常见组合方案
方案 A:个人开发者,快速迭代
Cursor(IDE 层)+ Claude Code(执行层,按需调用)
不引入编排层,管理开销最小。Cursor 处理日常编码,Claude Code 处理需要自主执行的复杂任务。
方案 B:小团队,多 Agent 并行
Multica(编排层)+ Hermes + Claude Code(执行层)
在 Multica 看板上创建 Issue,分配给不同 Agent,统一追踪进度。Hermes 处理需要长期积累经验的任务,Claude Code 处理一次性深度推理任务。
方案 C:AWS 技术栈团队
Kiro(IDE 层)+ Multica(编排层)+ Claude Code(执行层)
Kiro 负责需求规范化,生成 Spec 后交给 Multica 分配执行,Claude Code 作为底层 Agent 处理具体代码任务,并原生集成 Lambda/CDK 部署。
七、选型决策树
你的核心需求是什么?
│
├─ 写代码时需要 AI 辅助补全和 Chat
│ └─ 需要 AWS 集成或严格需求管理? ──是──▶ Kiro
│ └─否──▶ Cursor(速度优先)
│
├─ 需要 AI 自主执行完整任务(读写文件、跑测试等)
│ └─ 需要跨任务积累经验? ──是──▶ Hermes
│ └─否──▶ Claude Code / Codex CLI
│
└─ 有多个 Agent 或人+Agent 混合团队,需要统一管理
└─ 需要自部署/数据不出内网? ──是──▶ Multica(自部署)
└─否──▶ Multica Cloud
结语
当前 AI Agent 生态的混乱,很大程度上来自于不同层次的工具被混在一起比较。理解"执行层 / 编排层 / IDE 层"这个三层模型,是做出清醒选型决策的前提。
短期内,这三层工具会持续分化和专业化:执行层会卷模型能力和工具覆盖范围,编排层会卷多 Agent 协调效率和可观测性,IDE 层会卷补全速度和开发者体验。它们不会互相取代,而是会越来越紧密地组合在一起------就像 Kubernetes、Docker 和 VS Code 的关系一样。
选工具的正确姿势不是"哪个最强",而是"我现在在哪一层有瓶颈"。