当模型不再决定一切:Harness 成为 Coding Agent 的分水岭
2026 年下半年,一个工程界的共识逐渐清晰:在 Coding Agent 赛道上,模型之间的差距已经很难拉开,真正决定 Agent 表现的是 Harness —— 也就是围绕模型那一整套脚手架,包括工具接口、上下文管理、权限控制、验证回路和扩展点。一份长期维护的官方文档对比表显示,主流的 CLI Coding Agent —— Claude Code、OpenAI Codex CLI、Gemini CLI、Copilot CLI 以及后来衍生出的 Goose、OpenCode、Qwen Code —— 在操作系统支持、模型家族、MCP 协议、子代理、Hooks、headless 模式、IDE 集成、配置文件、开源许可、鉴权方式这十个轴上,各自做出了不一样的工程取舍。
这篇对比表每月维护一次,每次产品有官方文档变更就在原地修订,所有条目都标注了官方文档链接,而不做主观打分。这种"只列事实不排榜"的做法,本身就在传递一个信号:Harness 的差异不是简单的谁好谁坏,而是各自适合不同的工程约束。本文结合这份对比矩阵与一份独立的 narrative handbook,把主流 Harness 的工程取舍拆开,讲清楚企业做落地决策时应该看哪些维度。
三套核心机制:Hooks、Subagents 与权限模式
把所有主流 Harness 放在一起看,它们在三个机制上几乎都做出了自己的取舍:Hooks(确定性生命周期钩子)、Subagents(子代理隔离)与权限模式。
Claude Code 在这套机制上的思路最为典型。它的工具集保持极简 —— Read、Edit、Write、Bash、Glob、Grep、WebSearch、WebFetch 这几个工具加上 Agent/Task 工具构成全部。这种小而精的工具菜单不是偶然,而是为了让每一种动作都可以独立做权限控制、沙箱隔离和结果反馈。它的扩展点 Skills(技能)、Subagents、Hooks、Plugins(插件)、MCP(模型上下文协议)以及 CLAUDE.md 项目记忆,每一个都对应了 Harness 工程里的不同问题。
Claude Code 的 Skills 是一组可按需加载的 know-how 包。每个 Skill 是一个文件夹里的 SKILL.md,带 YAML frontmatter 描述触发时机。模型在会话开始时只看到一行描述,知道能力存在;只有真正用到时,完整指令才被加载进上下文。这种渐进式披露让模型可以在窗口里同时挂载几十个 Skill 而不付出成本。Subagents 进一步把重活外包出去 —— 主对话通过 Agent 工具委派任务给子代理,子代理在自己的上下文里独立工作,只把最终结论送回主对话。这样,几十次文件读取和长命令输出污染的是子代理的窗口,主对话始终保持清爽。
Hooks 则和 Skills、Subagents 完全不同:它是确定性控制,不依赖模型是否配合。Hook 是一段 shell 命令,挂载在 SessionStart、UserPromptSubmit、PreToolUse、PostToolUse 等生命周期事件上,可以阻断某个动作、自动追加上下文,也可以无脑放行。它的典型用法包括每次 Write 后自动跑 formatter、阻止写入受保护的文件、在对话压缩后重新注入关键上下文。换句话说,Hooks 让 Harness 拥有了一份"模型不配合也能生效"的安全网。
Claude Code 的权限模式也很有讲究。文档化的模式包括 default、plan、acceptEdits、auto、bypassPermissions 这几种,对应从最保守到完全放开的不同风险偏好。default 下读类动作自由,大多数写类需要问;plan 是只读探索;acceptEdits 让文件编辑和常见文件操作自动跑;auto 给更宽的自主权但有后台分类器检查每一个动作;最后一种 bypassPermissions 完全不弹提示,只在隔离 VM 里用。在这一层之上,还有一份基于 allow/ask/deny 的精细规则 —— 比如允许 Bash(npm test)但禁止 Bash(rm *)。
Codex CLI 的另一条路:OS 沙箱 + 审批政策
Codex CLI 走了一条非常不同的工程路线,它的核心思路是把"能不能做"和"该不该做"拆成两层独立的控制。Codex CLI 本身是开源的(Apache-2.0,Rust 核心),可以通过 npm install -g @openai/codex、Homebrew 或官方安装脚本装上。它有两种运行模式 —— 交互式 TUI 用 codex 启动,非交互模式用 codex exec 给 CI 跑,可以流式输出 JSON 事件。
Codex CLI 的沙箱是在操作系统层强制实现的,不是纸面上的策略。沙箱模式分三种:read-only 只读不写;workspace-write(默认)允许在当前工作目录内读写,网络访问默认关闭,要开必须显式打开;danger-full-access 完全去掉文件系统和网络的边界。沙箱的执行是真正的内核级隔离:macOS 上跑 Apple Seatbelt(sandbox-exec)加针对性 profile;Linux 和 WSL2 上用 bubblewrap 加 user namespace、seccomp、Landlock。这就是说,即便模型想绕过,代码层面也走不通。
和沙箱正交的是审批政策(approval policy),即什么时候停下来问人。untrusted 会自动跑已知安全的读操作,在改状态前问;on-request(默认)在沙箱升级、网络访问、危险操作前弹提示;never 完全不弹。在交互式 TUI 里,这两层被聚合成三个预设(/permissions 里切换):Read Only、Auto(默认 workspace-write + on-request)、Full Access。三层互不耦合的好处是:可以单独把沙箱开到 read-only 让 Agent 看不了写不了,同时审批政策放最宽让交互更轻。
Codex CLI 的项目记忆文件叫 AGENTS.md,默认拼接上限是 32 KiB(可调)。合并规则简单可预测:从仓库根一路走到当前目录,每层取一个 AGENTS.md,按层级拼接。越靠近当前工作目录的指引优先级越高。这个格式刻意做成纯 Markdown、不绑定 Codex 自己 —— 别的 Agent 也能读懂。配置走单一 TOML 文件 ~/.codex/config.toml,字段直白对应 Harness 的各个维度。
GitHub Copilot CLI 与跨厂商一致性
在 Codex CLI 这种"OS 沙箱优先"和 Claude Code 这种"工具精细化 + 渐进式披露"之外,GitHub Copilot CLI 走的是另一条中间路线。它的定制 agent 和指令文件允许团队把内部规范编码进 Harness,但沙箱执行和审批流程的颗粒度更偏向企业统一管控,而非像 Codex CLI 那样把 OS 沙箱和审批政策解耦给开发者细调。这种取舍在企业落地时非常实用 —— 大型企业 IT 部门希望统一配置而不是给每个工程师放开。
Copilot CLI 的一项关键差异是它的开源策略:CLI 本身是 source-available(可见但不开源修改权),不是 Apache-2.0 这类宽松协议。这一点经常成为法律合规团队评估的重点 —— Agent 工具在企业的安全审计下,源码可见和源码可改差别很大。Codex CLI 和 Qwen Code 是 Apache-2.0,Goose 也是,OpenCode 是 MIT,这些都允许企业修改和再分发;Claude Code、Copilot CLI、Q Developer CLI(已改名 Kiro CLI)都是闭源或 source-available。
AGENTS.md 与 CLAUDE.md:跨厂商的项目记忆公约
这些 Harness 在配置文件上逐渐形成了一个有意思的趋同:都用一个 Markdown 文件作为项目级持久记忆。OpenAI Codex CLI、GitHub Copilot CLI 和 OpenCode 这三个开源派系共享 AGENTS.md 这个名字;Claude Code 用 CLAUDE.md;Gemini CLI 用 GEMINI.md;Qwen Code 用 QWEN.md。命名不同,但结构高度一致 —— 都是从仓库根到当前目录的层级合并,越靠下优先级越高,内容都是纯 Markdown。
这种命名分散本身说明一件事:Agent 社区目前还没有一个统一的项目记忆标准,各家按自家产品名派生文件。但底层的设计思想已经收敛 —— 把项目约定写成纯 Markdown,让任何 Harness 都能读。这种"通过命名而非墙标"的生态位,正是开源项目的标准养成方式:先分散出现几个事实标准,再由社区或某个有影响力的玩家推动合并。AGENTS.md 因为 Codex CLI 和 Copilot CLI 同时采用,目前已经成为事实上的多厂商公约。
对企业的实际意义是:即使将来换 Harness,项目记忆的迁移成本也比想象的低。把 AGENTS.md 写好,它能被多数主流 Harness 读懂;写 CLAUDE.md 也只是名字不同,内容几乎一致。这种可迁移性正是 Harness 工程应该追求的目标 —— 把项目知识从工具里解耦出来,而不是被某个 Harness 绑死。
MCP:跨 Harness 的工具接口标准
在工具接口这个最关键的轴上,各家不约而同地选择支持 Model Context Protocol(MCP)。Claude Code 把 MCP 当成扩展工具集的标准方式,Codex CLI 既是 MCP client 又是 MCP server —— 别的 Agent 可以通过 codex mcp-server 把 Codex 当作子工具调用。GitHub Copilot CLI、Goose、OpenCode、Qwen Code 也都是 MCP client。
MCP 之所以被普遍接受,核心原因是它解决了工具的可移植性问题。一个内部 API server 写好 MCP 协议,就能被所有支持 MCP 的 Agent 调用,不依赖 Slack / IDE 这种产品形态。这对企业落地的意义是:内部工具接入 Agent 的成本,从以前给每个 Agent 都写一份适配,降到了只写一份 MCP server。这是过去几年 Agent 生态最务实的一次收敛。
但 MCP 不是万能的。它解决的是"工具怎么接入",不解决"工具返回的内容怎么被 Agent 理解"。一份独立的安全研究在 Stroq 那篇里专门讨论过:工具返回的内容可能携带间接 prompt injection,Agent 不能因为这条内容来自 MCP server 就信任它。MCP 是接入标准,信任分层要单独实现。
子代理与多代理:Harness 的复杂度天花板
所有主流 Harness 都把子代理或多代理当作扩展点。Claude Code 的 Agent/Task 工具可以启动子代理,每个子代理有独立上下文窗口、系统 prompt、工具权限和模型选择;Codex CLI 自己的 Codex 也支持类似机制,通过 MCP server 接口让别的 Harness 把自己当作子代理调用。Goose、OpenCode、Qwen Code 也都有等价的 sub-agents 或 extensions 机制。
多代理机制的设计取舍在于:主代理是不是有能力在不同子代理之间做规划协调。一些 Harness 让主代理显式负责规划,然后委派;另一些 Harness 让多个 Agent 自组织。在企业落地里,前者更可控,后者更灵活但也更容易失控。对于生产环境的合规审计来说,显式协调 + 决策日志的设计更友好,因为能清楚地回答"这一步是谁做的、依据是什么、下一步是什么"。
另一个被低估的子代理能力是上下文隔离。一个有几十个文件读、几百次工具调用的长任务,如果不隔离上下文,主对话的窗口早就爆了。Subagents 解决了这个工程问题,但代价是子代理之间的通信路径变长,中间结果不直接可见。企业落地时必须有意识地决定哪些任务用 sub-agent 跑、哪些任务留在主对话里,不能交给 Harness 自己拍。
权限与企业落地:Harness 是合规审计的关键层
企业落地 Coding Agent 的关键不在模型选哪家,而在三个问题能不能回答:Agent 做了什么、是否在策略范围内、出了事能不能追溯。这三个问题的答案不在模型里,在 Harness 里。
权限模式决定了"是否在策略范围内"。Claude Code 的五档模式给了工程师从最保守到最激进的选择;Codex CLI 的沙箱 + 审批政策两层独立控制,让企业 IT 部门可以在不让开发者感知的前提下,锁定某些危险动作。这些差异在实际落地里比模型本身的分数重要得多。
Harness 还能回答"做了哪些事"。Claude Code 的 Hooks 配合会话日志,可以把每一次 PreToolUse 和 PostToolUse 留痕;Codex CLI 的会话记录和沙箱拦截日志,可以让审计团队回放 Agent 的完整执行轨迹。如果 Harness 没有这些日志,模型再怎么聪明,企业也不会让它进入生产环境。
这是为什么 Harness 的对比表里"配置文件"和"权限模式"两列比"支持的模型"列更重要。一个 Harness 即使支持再多模型,如果权限模型粗糙,企业落地就要走定制开发的弯路;反过来,如果 Harness 的权限模型和日志能力足够强,模型本身的分数退一档完全可以用业务团队的执行经验补上。
企业落地的三条新基线
第一条基线是把 Harness 而非模型作为选型对象。看一份对比表时,优先看权限模型、子代理能力、Hooks/扩展点、配置文件这四列,再看支持的模型。原因:模型会变,三年前 GPT-4 不可想象,三年后某个模型可能又是新的行业标准。但 Harness 的设计哲学一旦定型,改动成本很高,大部分厂商会延续自己的核心设计。
第二条基线是用 MCP 而不是私有协议接入工具。一个企业要让内部 API server 能被 Agent 调用,投入资源写 MCP server 一定是回报最高的做法,因为所有主流 Harness 都支持它,而私有协议只对单一 Harness 有意义。MCP 是这一轮 Harness 工程最务实的一次收敛,不要错过。
第三条基线是把 AGENTS.md 作为项目记忆的标准载体,而不是分散到每个 Harness 的私有格式里。即使团队目前用的是 Claude Code,写项目记忆时也应该优先写 AGENTS.md 的内容(配合小部分 CLAUDE.md 专属指引),这样在切换 Harness 时迁移成本最低。这是看清单得出的最务实结论:AGENTS.md 已经事实上成为跨厂商公约。
把以上三条放在一起,可以画出 2026 年下半年企业 Coding Agent 落地的新基线:用 Harness 而非模型做选型、用 MCP 而非私有协议做接入、用 AGENTS.md 而非私有格式做记忆。这三条不是"哪个 Harness 更好"的答案,而是"无论选哪个 Harness 都要遵守的工程约束"。Harness 工程的进步正在把 Agent 从"个人生产力工具"推向"企业级生产基础设施",而这三条基线是这一进程里最务实的安全网。
