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 的关系一样。

选工具的正确姿势不是"哪个最强"，而是"我现在在哪一层有瓶颈"。