博客 • AI / Agent

AI Coding Agent 已经不只是补全代码：Codex、Claude Code、OpenCode、DeepSeek Harness 正在竞争什么？

两年前，多数人说的「AI 写代码」还是编辑器里的下一行建议。2026 年，终端里跑着的是另一类产品：Codex、Claude Code、OpenCode、DeepSeek Harness——它们改文件、跑测试、调 MCP，还能开子 Agent 并行排查。

表面上四家都在卖同一套能力：LLM + 工具 + Agent loop。真正的战场不在功能清单，而在架构中心：谁强化 Agent，谁管执行边界，谁押模型无关，谁把运行时本身做成可替换件。

这篇文章会讲清：

• Coding Agent 相对补全，多出来的到底是什么
• 四家各自优化的核心问题
• Claude Code / Codex / OpenCode / DeepSeek Harness 的架构差异
• 控制权地图：模型、运行时、策略、人各管什么
• JSON Schema 与工具契约为何仍是共同底层，以及怎么在 JSONNote 本地校验

真正在竞争什么

补全解决的是「下一行写什么」。Coding Agent 解决的是「这个目标怎么在真实仓库里做完」：读上下文、选工具、改代码、跑命令、看结果、再决策。

底层循环几乎相同：

User goal
  → Agent loop
  → LLM decides next action
  → Tool / environment executes
  → Result returns to context
  → Agent decides again

模型负责推理与下一步动作；harness 决定它能看见什么、能调哪些工具、工具实际做什么、状态如何保存、哪些动作要审批、怎样算任务完成。模型再强，上下文残缺、工具契约松、权限过大、失败无法恢复，结果照样垮。

所以 2026 年的竞争，不再只是「谁的基准分更高」，而是「谁把智能、执行、策略、工具与人的控制组织得更清楚」。四层拼装可参考：

2026 AI Agent 技术栈：LLM、MCP、Function Calling、JSON Schema

四个架构中心

先画边界。功能清单会越来越像，但中心问题不同：

最后一行不是排名，而是产品边界：你买的是「更强的助手」，还是「更可控的执行环境」，还是「可扩展的 Agent 平台」。

Claude Code：Agent 中心

Claude Code 最好理解为以主 Agent 为中心的产品。Skills、MCP、子 Agent、Hooks、权限都在让同一个 Claude Agent 更有效，而不是把 Agent loop 本身拆成可替换内核。

典型扩展点包括：

• CLAUDE.md：项目级上下文与约定
• Skills：可复用的经验与工作流包
• MCP：连接外部系统
• Subagents：隔离专业子任务与上下文
• Hooks / Permissions：在生命周期上挂确定性规则

它的工程妥协很清晰：概率性 Agent + 确定性 Hooks。改完跑测试、危险命令拦截、受保护路径先审批——这些不该指望模型「每次都记得」。

适合：明确工作流、重视体验与上下文质量、用 Skills 和子 Agent 扩展主循环的团队。

Codex：执行中心

Codex（含 Codex CLI）把问题推到执行层：Agent 一旦能改文件、跑 shell、装依赖、碰网络与凭证，就必须回答两件不同的事——能力边界与当前许可。

两套机制分工：

原则是能力最小化：不要先给满权限再要求「小心一点」，而是先收紧环境，再按需放宽。Rust 实现的 CLI、默认贴着 OpenAI 端点、以及偏强的沙箱叙事，都符合「Agent 要在真实计算机上干活」这条线。

适合：高风险副作用、需要可审计执行轨迹、把审批与隔离当一等公民的场景。开源仓库见：

openai/codex。

OpenCode：模型无关

OpenCode 的差异化不在「多一套 Skills 语法」，而在默认立场：模型可换。MIT 开源、终端优先，并支持大量提供商与本地模型（如 Ollama / LM Studio）。灵活性主要落在配置层——providers、models、permissions、themes——而不是把 harness 内核拆成插件总线。

这带来一个很实际的产品结论：如果你不信任单家锁定，或同一会话需要在多家模型间切换，OpenCode 的中心问题就是「如何不被模型供应商绑死」。

它通常赢在：

• 多模型 / 多提供商作为默认能力
• 开源许可与社区生态
• 把「换模型」当成一等操作，而不是厂商附赠

代价是：执行边界与插件深度未必是卖点第一名。你买的是可换模型的 harness，不是最重的沙箱产品，也不是「Everything is a plugin」的平台内核。

DeepSeek Harness：运行时中心

DeepSeek Harness（dsh）把问题再往里推一层：如果 Agent Loop 本身也不该是永久内核呢？公开预览里的口号是 Everything is a plugin——模型、工具、skills、会话、沙箱、存储、loop、调度、UI 都可以替换。

这和「稳定核心 + 外围扩展点」不同。它把边界往内推：驱动 Agent 的机制也可以重组。能力缝（capability seam）让消费者依赖契约而非单一实现：本地 shell 与容器 shell、远端模型与本地推理、ReAct loop 与工作流 loop，可以换提供方而不重写所有工具。

因此它更像平台：

• Coding Agent：ReAct 循环
• Workflow Agent：工作流 + Agent
• 长时任务：目标 + 调度 + Job
• 异构子 Agent：甚至可挂接其他产品后端

可组合性有代价：Plugin / Service / Provider / Effect / Session 等概念面更大。对「只想让仓库被改完」的终端用户，学习曲线可能高于 Claude Code 或 Codex；对要造可扩展 Agent 平台的团队，这正是卖点。

若你更关心 DeepSeek 模型 API 与 JSON 输出，可先看：

DeepSeek V4-Pro 完整解析

控制权地图

比功能打勾更有用的，是问每项决策归谁。下表压缩四家的控制风格（OpenCode 与 dsh 在「可替换性」上接近，但深度不同）：

再往下一层：理解任务与生成计划偏模型；校验参数、判断权限、执行工具、终止运行偏程序与策略；高风险动作还要人。四家都覆盖这些词，但把砝码压在不同格子上。

JSON 契约仍是共同底层

无论你选哪家 harness，工具调用最终都要落到可机器执行的结构上：函数名 + 参数 JSON。MCP 的 inputSchema / outputSchema、Function Calling 的 parameters、Structured Output 的 response_format，底层语言仍是 JSON Schema。

契约出现的位置：

常见翻车：模型侧 parameters 与 MCP inputSchema 各写一份，字段或枚举漂移，看起来像「模型总调不好工具」。修复方式是一份契约、两处挂载。背景见：

AI 为什么需要 JSON Schema与AI Agent 的 JSON Schema 完全解析。

{
  "name": "run_tests",
  "description": "Run the project test suite and return a structured summary.",
  "parameters": {
    "type": "object",
    "properties": {
      "suite": { "type": "string", "enum": ["unit", "integration", "e2e"] },
      "path": { "type": "string", "minLength": 1 }
    },
    "required": ["suite"],
    "additionalProperties": false
  }
}

调试这条路径时，可以在浏览器本地完成，数据不上传：

1. 1
   格式化 arguments

   把模型返回的 arguments 字符串粘进JSON 格式化，先确认是不是合法 JSON。

2. 2
   对照 Schema 校验

   用JSON Schema工具核对 required、enum、additionalProperties。

3. 3
   对比漂移

   模型侧 parameters 与 MCP inputSchema 用JSON Diff看字段是否一致。

怎么选

按约束选，而不是按热度选：

• 工作流清晰、要强体验与 Skills：偏 Claude Code
• 真实机器副作用大、要沙箱与审批：偏 Codex
• 多模型、防锁定、开源优先：偏 OpenCode
• 要造可扩展 Agent 平台、loop 可换：偏 DeepSeek Harness

也可以组合：例如用 OpenCode / dsh 做多模型实验，生产副作用走 Codex 式边界；或主循环用 Claude Code，外部系统走 MCP。关键是别把「模型分数」当成唯一采购指标。

常见问题

AI Coding Agent 和代码补全有什么本质区别？

补全只建议下一行；Coding Agent 能读仓库、改文件、跑命令、调工具，并在循环里根据结果继续决策。竞争重点从「生成质量」变成「执行边界与运行时控制」。

Codex、Claude Code、OpenCode、DeepSeek Harness 谁最好？

没有统一冠军。看你优化什么：体验与 Skills 选 Claude Code；沙箱与审批选 Codex；多模型与防锁定选 OpenCode；可替换运行时与平台化选 DeepSeek Harness。

DeepSeek Harness 和 OpenCode 都是开源，差别在哪？

OpenCode 的灵活性主要在模型与提供商配置；DeepSeek Harness（dsh）把模型、工具、loop、沙箱、会话等都做成可替换插件，更像可组合的 Agent 运行时平台。

为什么还要谈 JSON Schema？

工具参数、MCP inputSchema/outputSchema、Structured Output 底层都是 JSON Schema。harness 再强，脏参数进执行层一样会出事——契约校验仍是 Runtime 的责任。

选 Agent 时最该盯哪一层？

盯控制权：谁决定工具、谁校验参数、谁审批高风险动作、谁终止任务。模型分数只是输入之一；harness 决定任务能否安全做完。

小结

Codex、Claude Code、OpenCode、DeepSeek Harness 共用同一套词汇：LLM、工具、loop、上下文、Skills、子 Agent、权限、沙箱。它们不再只是「更强的补全」，而是在争控制权落点。

Claude Code 强化一个 Agent；Codex 让 Agent 在真实环境里可控地行动；OpenCode 押模型可换；DeepSeek Harness 把运行时与能力做成可组合平台。

重要问题已经不是「怎么调用模型」，而是「智能、执行、策略、工具、上下文与人的控制如何组织」。工具契约层的 JSON，仍然是你可以本地核对的那一层。

← 返回博客