AI 编程工具对照

AACWorkflow 内置支持 16 款 AI 编程工具。它们都实现了同一套接口——排队、派发、执行、结果回传，所以你可以从 AACWorkflow 的同一个看板上指挥任意一款。但它们在能力细节上差异很大：会话恢复是否真用、是否支持 MCP、skill 文件该放在哪里、模型怎么选。这一页是完整对照。

创建智能体时挑选工具的指引见 创建和配置智能体。

能力对照矩阵

每款工具的定位

Antigravity

Google 出品。CLI 二进制名为 agy，搭配 Google Antigravity 服务，默认走 Gemini 系列模型。AACWorkflow 使用 agy -p 启动 Antigravity，因为这是适合 daemon 后台任务的一次性非交互模式；agy -i 需要连接 TTY，不适合后台执行。当前 Antigravity CLI 在 agy -p 下仍可执行工具，但 stdout 是纯文本而非结构化事件流，所以 AACWorkflow 会把 transcript 作为 text 转发，暂时无法展示逐工具 telemetry。会话恢复真用——通过 --conversation <id>，守护进程从 CLI 的日志文件里抓取 conversation UUID。模型选择真用——通过 --model flag（agy 1.0.6 新增）：守护进程用 agy models 枚举可选项，并把选中的值原样传入。注意这些是 Claude Opus 4.6 (Thinking) 这样的人类可读显示名，而非 provider/model slug；而且 agy 遇到无法识别的值会静默空跑，所以优先从发现列表里挑选，不要手填。Skill 文件写入 .agents/skills/（CLI 沿用 Gemini CLI 的 workspace 布局——见 Antigravity 迁移文档）。

Claude Code

Anthropic 出品。新用户首选——功能最完整：会话恢复真用，会读 MCP 配置，支持 --max-turns、--append-system-prompt 等细调参数。需要一个 Anthropic API 密钥。

CodeBuddy

Tencent 出品。一款兼容 Claude Code 的 CLI agent——AACWorkflow 用和 Claude Code 一样的 stream-json 协议驱动它，所以会话恢复可用（通过 --resume），MCP 配置通过 --mcp-config 传入。CodeBuddy 使用自己原生的配置目录，而不是复用 Claude 的，所以 skill 放在 .codebuddy/skills/，运行时说明写入 CODEBUDDY.md。模型为动态发现。

Codex

OpenAI 出品。使用 JSON-RPC 2.0 协议，状态化更强，approve 机制更细（手动批准 exec_command 和 patch_apply）。MCP 配置会写入单次任务的 $CODEX_HOME/config.toml。会话恢复可用——AACWorkflow 通过 Codex app-server 的 thread/resume 续接；如果已保存的 thread 不存在或过期，会回退到新 thread，让任务继续执行。

Copilot

GitHub 出品。模型路由走你的 GitHub 账号权益——工具自己不做模型选择，由 GitHub 决定给你用哪个模型。skill 放 .github/skills/ 是 GitHub CLI 的原生发现机制。

Cursor

Anysphere 出品，Cursor 编辑器的 CLI 对应物。会话恢复可用——当前 Cursor Agent 的 stream-json 事件会返回 session_id，AACWorkflow 会在下一次运行时通过 --resume <id> 传回去。MCP 配置会写入任务工作区的 .cursor/mcp.json，Cursor 的项目 approval 文件写在单次任务的 CURSOR_DATA_DIR 下，因此托管的 MCP server 不依赖用户全局 Cursor approvals。

Hermes

Nous Research 出品。使用 ACP 协议（和 Kimi 共享传输层）。会话恢复真用，MCP 配置通过 ACP mcpServers 传入。Hermes 只从自己的 home 目录（~/.hermes/skills/）和配置的 skills.external_dirs 发现 skill，没有工作区相对发现。因此，只有当智能体分配了 skill 时，AACWorkflow 才会把 HERMES_HOME 指向你 ~/.hermes/ 的单次任务 overlay：真实 home 用软链镜像（含 auth／密钥，令牌刷新可传播），派生的 config.yaml 把你已有的 skill 作为只读 external root 引用，只有被分配的 skill 写入它的 skills/ 目录并具更高优先级。你的全局 skill 照常可用。AACWorkflow 不会直接写你的共享 ~/.hermes/（只读取并链接进去），但 Hermes 自己通过被镜像的软链写入时（如刷新令牌）会传播。custom_args 里的 -p/--profile 选择会被尊重：overlay 从该 profile 的 home 播种，且该标志会从启动命令里消费掉，无法绕过 overlay。任务记忆按任务隔离：一个全新的 memories/ 目录，外加在派生配置里禁用外部 memory.provider 后端，所以磁盘上的笔记和共享的 Supermemory/Hindsight 之类记忆库都不会在任务间串用（受管、按 agent 隔离的记忆后端是后续单独决策）。state.db SQLite 会话库及其日志文件也按任务隔离，由 Hermes 在 overlay 内创建；宿主会话历史不会被链接或复制，Windows 上运行中的 WAL 锁也不会阻塞环境准备。没有分配 skill 的 Hermes 任务按真实 home 原样运行。另外,home 的平台默认值在原生 Windows 上是 %LOCALAPPDATA%\hermes。

指定 Hermes profile。 要让 Hermes 使用某个 profile 启动，把智能体的 custom_args 设成 profile flag 和 profile 名两个独立条目。例如使用名为 research 的 profile：

["-p", "research"]

不要合成一个字符串 "-p research"；AACWorkflow 会把数组里的每一项作为一个独立 argv 参数传给工具。custom_args 是按智能体配置的——见 创建和配置智能体。

Kimi

Moonshot 出品，中国市场向。和 Hermes 共享 ACP 协议，MCP 配置同样通过 ACP mcpServers 传入；但 skill 路径 .kimi/skills/ 是 Kimi CLI 的原生发现机制——和 Hermes 的 fallback 不一样。

Kiro CLI

Amazon 出品。通过 kiro-cli acp 使用 ACP stdio 协议。会话恢复走 ACP session/load，MCP 配置通过 ACP mcpServers 传入，模型选择走 session/set_model，skill 会复制到 .kiro/skills/ 让 Kiro 做项目级原生发现。

OpenCode

SST 出品，开源。动态发现可用模型和模型 variant（扫 CLI 的配置文件）。会话恢复真用，会消费智能体的 mcp_config 字段——AACWorkflow 通过 OPENCODE_CONFIG_CONTENT 环境变量内联注入，让智能体的 MCP server 直接到达 OpenCode，不会去碰任务工作目录里的 opencode.json（那个文件归智能体或用户所有）。当模型暴露 variant 时，AACWorkflow 会把它显示成智能体的思考强度选择，并通过 opencode run --variant 传给 OpenCode。适合爱折腾、想自定义模型目录的开发者。

DevEco Code

DevEco Code 是华为面向鸿蒙开发的独立编程智能体（deveco CLI，gitcode.com/openharmony-sig/deveco-code）。它基于 OpenCode 引擎构建，自身已是一款完整成熟的产品——自带模型目录与 provider（内置 deveco/GLM-5.1）、自带华为账号认证、自有配置与 skill 体系（~/.config/deveco/ 与 .deveco/skills/）。AACWorkflow 通过 deveco run --format json 驱动它，解析其 NDJSON 事件流。会话恢复可用（--session <id>），模型通过 deveco models 动态发现，系统上下文通过单次任务的 AGENTS.md 投递。MCP server 通过 DevEco 原生的 DEVECO_CONFIG_CONTENT 通道配置；AACWorkflow 侧的 mcp_config 透传正在开发中，因此目前 DevEco 智能体的 MCP 标签页暂先隐藏。认证用 deveco auth login（华为账号）。

OpenClaw

商用项目，CLI agent 编排器。MCP 配置通过 AACWorkflow 的单次任务配置 wrapper 写入。模型绑定在智能体层（openclaw agents add --model）——不能在单次任务里覆盖。配置严格受控：用户不能传 --model 或 --system-prompt，由智能体注册时的配置决定。

Pi

Inflection AI 出品，极简主义。会话恢复机制特殊——session ID 是磁盘上的文件路径（~/.pi/...），而不是字符串 ID。其他工具里，resume id 是 CLI 返回的字符串；Pi 里，resume id 就是会话文件本身。

Qoder

Alibaba 出品。一款 agentic 编程 CLI。使用 ACP 协议（和 Hermes、Kimi、Kiro CLI 共享传输层）。会话恢复通过 ACP session/resume 工作，MCP 配置通过 ACP mcpServers 传入，模型为动态发现，skill 复制到 .qoder/skills/ 做原生发现。

Trae

ByteDance 官方 TRAE CLI（traecli，搭配 Trae IDE，不是开源的 bytedance/trae-agent）。它是 ACP 原生工具，AACWorkflow 通过 traecli acp serve --yolo 在 stdio 上驱动它，传输层和 Kiro、Qoder 相同。会话恢复通过 ACP session/load 工作，MCP 配置通过 ACP mcpServers 传入，模型为动态发现并可通过 session/set_model 在任务中切换，skill 复制到 .traecli/skills/。

Grok

xAI 的 Grok Build CLI（grok）。AACWorkflow 通过 grok --no-auto-update agent --always-approve stdio 接入 ACP。initialize 返回后，AACWorkflow 从 CLI 公布的认证方式中选择 xai.api_key（已设置 XAI_API_KEY 时优先）或 cached_token，等待 authenticate 成功后才创建或加载会话；没有可用方式时会明确失败。会话续接走 ACP session/load，模型从 session/new 动态发现并通过 session/set_model 切换。grok-4.5 的 reasoning effort 只提供官方支持的 low、medium、high。MCP 配置通过 ACP mcpServers 传入。Skill 文件写入 .grok/skills/；用户 skill 从 $GROK_HOME/skills/（默认 ~/.grok/skills/）和通用目录 ~/.agents/skills/ 发现。

会话恢复：谁真的支持

会话恢复的机制在 执行任务 里讲过。所有支持的工具都能恢复会话——传 resume id，任务就会从上次的上下文接着继续。唯一的特例是 Pi：它的 resume id 是磁盘上的会话文件路径，而不是字符串 ID（见上文 Pi）。

MCP 配置：按工具不同

16 款工具里有 12 款实际消费 mcp_config：Claude Code、CodeBuddy、Codex、Cursor、Hermes、Kimi、Kiro CLI、OpenCode、OpenClaw、Qoder、Trae CLI、Grok。其他 4 款（Antigravity、Copilot、DevEco Code、Pi）会接收这个字段但忽略——不报错、不警告，只是配置不生效。

各工具的接入方式不同：Claude Code 和 CodeBuddy 通过 --mcp-config 加 --strict-mcp-config 接收；Codex 会把 daemon 管理的 mcp_servers block 写入单次任务的 $CODEX_HOME/config.toml；Cursor 会写入 .cursor/mcp.json，并把项目 approval 写到单次任务的 CURSOR_DATA_DIR；Hermes、Kimi、Kiro CLI、Qoder、Trae CLI、Grok 通过 ACP mcpServers 接收；OpenCode 通过 OPENCODE_CONFIG_CONTENT 环境变量内联接收；OpenClaw 通过 AACWorkflow 的单次任务配置 wrapper 接收 mcp.servers。OpenCode 这条路径不会改写项目里的 opencode.json。

skill 文件该放哪儿

每款工具用自己的 skill 发现路径。AACWorkflow 的守护进程在执行任务前把 workspace 的 skill 文件复制到对应路径下：

fallback 路径对应的工具是否真的读取这个目录，取决于工具本身的文档——没保证。如果你的 skill 对 OpenClaw 没起效，先查这个问题。

对原生项目级路径来说，repo-scoped discovery 是预期行为：如果检出的仓库已经包含对应目录，底层工具可以自己发现这些提交在仓库里的 Skill。你不需要为了在这个仓库里使用这些 repo skills 而先把它们导入 AACWorkflow。AACWorkflow 会保持这些仓库文件不变。如果某个工作区 Skill 的自然目录名相同，守护进程会把工作区副本写到类似 review-helper-aacworkflow 的无冲突 sibling 目录。

skill 的创建和使用详见 技能。

下一步

• 创建和配置智能体 —— 给你的智能体挑一款工具
• 执行任务 —— 任务的生命周期和会话恢复机制
• 守护进程与运行时 —— 工具跑在哪里、怎么连进 AACWorkflow