# 诊断系统中的 Agent Runtime 对比：OpenCode / Claude Code / Codex

本文整理了一个面向诊断系统的判断框架，回答两个问题：

1. `OpenCode`、`Claude Code`、`Codex` 各自更适合什么
2. 为什么很多时候会感觉 `Claude Code` 的实际诊断能力更强

## 结论

如果讨论的是“人工协同诊断”的实际体验，`Claude Code` 在很多场景下确实更容易表现出更强的调查能力，尤其是下面这类任务：

- 读日志
- 跑 shell / `kubectl` / `curl` / SQL
- 顺着线索持续收敛根因
- 在长会话里不断调整调查方向

但这里要先区分清楚产品层级：

- `OpenCode` 更像开源 agent runtime / 外壳，本身重点是编排、权限、MCP/ACP、多模型接入
- `Claude Code` 是 Anthropic 提供的一体化 coding agent 产品
- `Codex` 是 OpenAI 提供的一体化 coding agent 产品

因此，`OpenCode` 和 `Claude Code` / `Codex` 并不是完全同一维度的竞争关系。很多“能力差异”实际上来自：

- 底层模型差异
- agent 产品默认的工具编排策略差异
- 长会话记忆、交互设计、权限流和任务分解方式差异

## 各自定位

### OpenCode

`OpenCode` 适合做平台层。它的优势是：

- 开源，可审计、可改造、可私有控制
- 支持多 provider / 多模型配置
- 适合把内部 MCP、诊断规则、权限模型、审计逻辑统一编排起来
- 可以把不同 agent 的职责拆开，并给它们分配不同模型

官方文档明确支持为 agent 配置独立 prompt、model 和权限控制，这说明它的强项是“编排层”而不是单一默认 agent 体验。

参考：
- https://opencode.ai/docs/agents/
- https://opencode.ai/docs/providers

### Claude Code

`Claude Code` 更像“现场调查型” agent。它的官方文档强调：

- 读取代码库
- 编辑文件
- 运行命令
- 与外部工具集成
- 通过 MCP 接入 Jira、Slack、Google Drive 等数据源
- 在终端、IDE、桌面和浏览器中统一使用

这类能力和诊断系统高度契合，因为诊断工作的核心往往不是一次性生成答案，而是通过工具不断拿证据、修正假设、缩小问题范围。

参考：
- https://code.claude.com/docs/en
- https://docs.anthropic.com/en/docs/claude-code/tutorials

### Codex

`Codex` 更偏“工程执行和自动化平台”。OpenAI 当前公开强调的方向包括：

- 多 agent 并行工作
- 云环境和 worktree
- skills
- automations
- 持续处理告警、CI/CD、issue triage 等后台任务

这使它在持续自动化、批量处理和团队化工程流程里很有吸引力。

参考：
- https://openai.com/codex/
- https://platform.openai.com/docs/codex/overview

## 为什么会感觉 Claude Code 的诊断能力更强

### 1. 它更贴近排障工程师的工作方式

诊断不是单纯“回答问题”，而是一个连续调查过程：

- 先拿到第一批线索
- 形成初步假设
- 调更多工具验证
- 推翻错误假设
- 再继续调查

在这个流程里，用户通常更在意：

- agent 是否会主动收集关键上下文
- 是否能顺着证据继续追
- 是否会因为上下文切换而丢失调查主线
- 是否善于处理不完整、含糊、冲突的信息

`Claude Code` 的交互方式、工具使用方式和长任务工作流，普遍更容易让人产生“它在真的排障”的感觉。

### 2. 诊断场景比代码生成更依赖调查链路质量

对于诊断系统，真正拉开差距的通常不是“写代码有多强”，而是：

- 会不会选对工具
- 什么时候该停止猜测、去拿证据
- 会不会遗漏关键分支
- 会不会被某个早期假设带偏

如果一个 agent 在代码实现上很强，但在调查过程中过早下结论，实际诊断效果就不一定好。

### 3. 你当前看到的对比未必是同层对比

如果当前系统底层是 `OpenCode`，再拿它和 `Claude Code` 比，很多时候实际在比的是：

- `OpenCode + 某个模型 + 你自己的 prompt / MCP / 权限编排`
- 对比
- `Claude Code + Claude 模型 + Anthropic 默认的 agent 设计`

这不是“runtime 对 runtime”的纯对比，而是“一套自建系统”对“一体化成品 agent”的对比。

## 面向诊断系统的选择建议

### 什么时候优先用 OpenCode

优先 `OpenCode`，如果你的目标是：

- 自己控制 agent 行为、权限和审计
- 深度接入内部系统、私有 MCP、企业工具
- 对不同任务做模型路由
- 把诊断 agent、执行 agent、review agent 拆成不同角色

一句话：`OpenCode` 适合作为诊断系统的“控制层”和“编排层”。

### 什么时候更看重 Claude Code

优先考虑 `Claude Code` 的思路，如果你的核心目标是：

- 提高人工协同调查的质量
- 提高根因定位的稳定性
- 强化终端排障、日志分析、上下文追踪能力
- 降低 prompt 和 agent 编排成本，先拿到更强的默认体验

一句话：`Claude Code` 更适合作为“深度调查执行层”的参考对象，很多时候也是更强的底模和默认 agent 行为组合。

### 什么时候更看重 Codex

优先考虑 `Codex` 的思路，如果你的核心目标是：

- 大量后台自动化任务
- 并行 agent
- 长时间运行的工程任务
- 与工程交付、CI/CD、issue triage 紧密结合

一句话：`Codex` 更适合作为“自动化工程执行层”的参考对象。

## 推荐架构

对于 Investibook 这类诊断系统，更稳妥的方向通常不是二选一，而是分层：

- 外层继续使用 `OpenCode` 做 runtime、权限、MCP/ACP 编排和审计
- “根因分析 / 深度调查”类 agent 优先接入更适合诊断的模型与 prompt 体系
- “修复建议 / 批量执行 / 自动化收尾”类 agent 再评估是否使用更偏工程执行的 agent 配置

也就是说，不必把 `OpenCode` 和 `Claude Code` / `Codex` 看成完全互斥的选择。更现实的做法是：

- `OpenCode` 负责平台能力
- 底层模型与 agent 配置按任务路由

## 评估时不要只看主观印象

如果要验证“Claude Code 是否真的更强”，建议用诊断系统自己的指标来做评测，而不是只看单次体验：

- 根因定位准确率
- 首次有效证据命中时间
- 无效调查步数
- 工具调用成功率
- MCP 利用率
- 长会话稳定性
- 单案例 token / 成本
- 最终结论的可验证性

这样可以把“感觉更强”变成“在哪些任务上更强、强多少、代价是什么”。

## 最终判断

简化成一句话：

- `OpenCode` 强在编排和平台控制
- `Claude Code` 往往强在交互式诊断和调查体验
- `Codex` 往往强在并行化、自动化和工程执行

如果当前感受是 `Claude Code` 的实际诊断能力更强，这个判断在很多人工协同诊断场景里是合理的；但更准确的表述应该是：

`Claude Code` 往往在“默认 agent 行为 + 底层模型 + 调查工作流”这一整套组合上，更容易表现出强诊断体验，而不是因为 `OpenCode` 这个 runtime 天生就弱。