# 与别家 agent 互通 · grok 怎么「假装」成 Codex/Cursor/Claude

> grok 工具系统最有意思的设计：一种行为、多套 wire 格式。它内置了 Codex 的 apply_patch、opencode 的工具名、Cursor 的 .mdc 规则、Claude 的工具别名——好让你把现成的 CLAUDE.md / .cursor/rules / codex 配置直接搬过来就能用。

- 作者：David（道雾轩）
- 专栏：Grok Build 源码解读（https://daiw.org/manual/grok-build.md）
- 最后更新：2026-09-15
- 原文：https://daiw.org/manual/grok-build/agent-interop
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 与别家 agent 互通 · grok 怎么「假装」成 Codex/Cursor/Claude

Part 2 收官，聊一个我觉得最能体现「产品思维」的设计。回顾[工具契约](https://daiw.org/manual/grok-build/tool-contract)那章：grok 工具系统的组织法是**一种行为(`ToolKind`)、每个 namespace 一套 wire 格式**。这一章看它把这个能力用到了极致——**兼容别家 agent**。

## 一种行为，五套 namespace

同一个 `read_file`/edit/grep,grok 内置了多套「换皮」实现，分属不同 namespace:

| namespace | 来自 | 特点 |
| --- | --- | --- |
| `GrokBuild` | grok 自己 | 标准格式 |
| `GrokBuildConcise` | grok | 省 token 版 |
| `GrokBuildHashline` | grok | 行锚点版 |
| `Codex` | OpenAI Codex | `apply_patch` 等 |
| `OpenCode` | sst/opencode | opencode 的工具名 |

一个会话激活**匹配当前 harness** 的那一套。这意味着：同样让模型「改文件」，你若把 grok 当 Codex 用，它就说 Codex 的 `apply_patch`；当 opencode 用，它就说 opencode 的 `edit`。

## Codex：逐字照搬 apply_patch

`codex/apply_patch` 的工具描述，是 OpenAI Codex 的 apply-patch 规范**逐字**搬来的：`*** Begin Patch` … `*** End Patch` 信封，`*** Add/Delete/Update File:`,`@@` hunk。执行分三段：解析(`parser.rs`)→ 内存里算出所有变更 → 落盘，还带模糊上下文匹配(`seek_sequence.rs`)。为的就是让**习惯了 Codex 的模型和用户**无缝切过来。

## OpenCode：连参数名都一样

`opencode/` 下的工具是从 [sst/opencode](https://github.com/sst/opencode)(MIT)移植的，连参数名都用 opencode 的(`filePath`、`oldString`、`newString`……)。目的是让 grok 对那个 harness **呈现一模一样的工具面**。

## Cursor：读文件时自动带上 .mdc 规则

`cursor_rules_on_read` 复刻了 Cursor 的行为：解析 `.cursor/rules/*.mdc` 的 frontmatter(`alwaysApply`、`globs`、`description`)，**当你读的文件匹配某条规则的 glob 时，把规则正文作为提醒附在读结果后面**(每条只注一次)。你的 Cursor 规则，在 grok 里照样生效。

## Claude：一张工具别名表

`types/claude_alias.rs` 是一张表，把 Claude Code 的工具名映射到 grok 的 `ToolKind` 和具体工具名：`Read→[read_file, hashline_read]`、`Write→[write, search_replace, hashline_edit]`、`Edit→[search_replace, hashline_edit]`、`Bash→[run_terminal_command]`、`Grep→[grep]`、`Skill→[skill]`……两个消费者：**hooks 匹配器**(认 Claude 的工具名)和 **agent 构建器**(把你 `tools:` 白名单里的 Claude 名字解析成 `ToolKind`)。

<Callout type="info">
  把这些拼起来看，意图很清楚：**你不用为 grok 重新配一遍**。你的 `CLAUDE.md`(还记得[system prompt 那章](https://daiw.org/manual/grok-build/system-prompt)里 AGENTS.md 发现会扫 `~/.claude`、`~/.cursor` 吗)、`.cursor/rules`、opencode 配置、Codex 的 apply-patch 习惯——搬过来直接能用。这是「兼容既有生态、降低迁移成本」的产品决策，落到代码里就是「一种行为、N 套 wire 格式 + 一张别名表」。
</Callout>

## 和《从 LLM 到 Coding Agent》对照

这一章几乎没有对照——因为「兼容别家 agent 的工具约定」是纯**产品生态**的关注点，教学最小实现里根本不存在。它恰恰说明：一个 agent 从「能跑」到「有人用」，中间隔着的正是这类「不酷但要命」的兼容工作。这也是读 grok 这种**生产开源实现**、而不只是教学实现的价值所在。

Part 2 工具系统到此为止。下一部分[工作区与 Git](https://daiw.org/manual/grok-build/workspace-abstraction)，看 grok 怎么理解你的代码库。

---

上一篇：[Web 工具](https://daiw.org/manual/grok-build/web-tools)