我要投稿

为什么同一个模型，在 Claude Code/Codex CLI 里感觉像换了个脑子？

发布日期：2026-05-07 02:01:55 浏览次数： 1601

作者：硅基生命AIGC

微信搜一搜，关注“硅基生命AIGC”

很多人用 Claude Code 和 Codex CLI 之后都会这样一种感觉：为什么它们比模型在普通聊天窗口里用起来更强？

其实现在 AI 领域的很多实际进展，已经不是模型本身变得多强，重要的是我们怎么用它周围的那一层系统，包括工具调用、上下文管理、记忆，扮演了和模型同等重要的角色。

套在模型外面的 harness，正在成为胜负的关键。

01. LLM、Reasoning Model、Agent、Harness

LLM：最核心的 next-token 模型，原始发动机；
Reasoning model：仍然是 LLM，但被训练成在给出答案之前，先做更多的推理、验证和候选比较；
Agent：一个在模型外的控制循环——给定一个目标，这一层决定接下来去看什么、调哪个工具、怎么更新状态、什么时候停；
Agent harness：agent 的软件控制层，负责管上下文、工具、prompt、状态、控制流；
Coding harness：agent harness 的一个特化版本，专门为软件工程优化——管代码上下文、工具、执行、反馈迭代。

我们谈某个模型的编程能力时，往往把模型能力、推理行为、agent 产品揉成一坨。但实际上，写代码不只是生成 token，还是仓库导航、搜索......执行测试、检查错误，并把所有相关信息留在上下文里。这些基本都不在模型本体的能力范围。

如果把最新的开源权重模型（如 GLM-5）放进一个类似的 harness 里，它很可能和 Claude Opus 4.6 在 Claude Code 里的表现相持平（当然，harness-specific 的后训练还是有用的——OpenAI 历史上曾维护通用 GPT 和专门为代码优化的 Codex 两条平行产品线。）

在当前这批原始模型能力已经高度接近的前提下，harness 才是那个让产品体验拉开差距的变量。

02. Coding Agent 的六个核心组件

以下是 Coding Agent 的六个核心组件：

1、实时仓库上下文

Agent 在开始运行前，先得知道自己在哪个位置。

当用户说“修一下测试”或“实现 xyz”时，模型应该知道自己是不是在一个 Git 仓库里、当前在哪个分支、哪些项目文档可能包含指令。

如果 agent 能看到 AGENTS.md 或项目 README，可以知道该跑哪个测试命令。如果它知道仓库根目录和布局，可以去对的地方找文件，不是靠猜。Git 分支、状态、commit 信息能告诉它当前进行中的改动在哪。

具体的做法是：agent 在任何工作开始前，先收集一份 stable facts，作为 workspace summary。这样每一轮交互都不是从零开始。

(很多 coding agent 表现不稳定，根源就是每轮都在问模型你猜现在哪个文件重要？这种问题，没有把事实先结构化地灌进去。)

2、提示结构和缓存复用

Agent 拿到仓库信息之后，下一个问题是怎么喂给模型。普通做法是把工作区摘要和用户请求拼起来，每轮重新处理一遍。但这很浪费——coding session 是重复性的，agent 的规则、工具描述基本不变，工作区摘要也大多不变，每轮在变的是最新的用户请求、最近的对话记录、短期记忆。

所以聪明的你会把 prompt 拆成两部分：

稳定前缀：通用指令、工具描述、工作区摘要，这部分基本稳定，可以缓存复用；
动态部分：短期记忆、最近会话记录、最新用户请求，这部分需要每轮更新。

这是 prompt cache 能真正发挥价值的前提——prompt 的拼装方式本身要为缓存服务，把可变部分和不可变部分分离，这是架构层面的决定，不是参数调优。

（顺带说一句，这也是为什么直接拿 API 做 agent 的人，常常发现自己的 token 消耗比同样任务下的 Claude Code 高几倍。）

3、工具访问与结构化调用

这是从普通聊天变成 agent 的关键转折点。普通模型是在文字里说出“你应该跑 pytest”，但 coding harness 里模型需要把这个命令跑起来并拿到结果。

但这不能让模型随便发挥。harness 会提供一个预定义的、命名清晰的工具列表，每个工具有清晰的输入和边界，模型发出的是一个结构化的 action。

整个工具使用流程是这样的：模型发出一个结构化 action → harness 验证它 → 可选地请求用户批准 → 执行 → 把有限制的结果喂回 loop。

验证环节运行时会问：这是不是一个已知工具？参数合法吗？需要用户批准吗？请求的路径是不是在工作区里？全部通过之后才会真正执行。

某种意义上，harness 给了模型更少的自由，但同时提升了可用性。

（边界约束越清晰，执行者反而发挥得越稳定。）

4、压缩上下文膨胀

上下文膨胀不是 coding agent 独有的问题，当前 LLM 也支持越来越长的上下文，但长上下文成本很高，而且会引入噪声（如果大量信息不相关）。

一个好的 coding harness 会用至少两种压缩策略：

裁剪（Clipping）：缩短长文档片段、大段工具输出、记忆笔记、会话记录条目。防止某一段话因为本身很长，就把整个 prompt 预算给占了；
会话压缩（Transcript reduction）：把完整的会话历史变成一个更小的可提示摘要。

对最近的事件保留更丰富的信息，对更早的事件更激进地压缩——因为最近的事件更可能影响当前这一步。同时对早期的重复文件读取做去重，不要让模型一遍又一遍看同一个文件。

我认为这是一个被低估但很关键的部分。很多看起来像模型质量的东西，其实是上下文质量。

5、结构化会话记忆

这块容易和刚刚提到的上下文压缩搞混。

结构化会话记忆关注点是保留一份更完整的会话记录作为可恢复状态，外加一层更关键的记忆。

状态分成至少两层：

工作记忆：agent 显式保持的小而浓缩的状态；
完整会话记录：完整记录所有用户请求、工具输出、LLM 响应。

这两个文件通常以 JSON 文件的形式存在磁盘上。完整会话记录存的是完整历史，agent 关掉之后可以恢复。工作记忆是蒸馏版本，保留当前最重要的信息。

这两者的分工不一样：压缩后的会话记录是为 prompt 重建服务的（给模型一个压缩的近期视图），工作记忆是为任务连续性服务的（跨轮次显式维护的小摘要，比如当前任务、关键文件、近期笔记）。

6、编排

Agent 有了工具和状态之后，下一个有用的能力是编排。主 agent 可能正在做一件事，但还需要一个旁支——比如某个 config 说了什么、为什么某个测试失败了。把它拆成一个有边界的子任务，比让一个 loop 同时扛所有线程要好。

但 subagent 有个棘手的设计问题：必须有足够的上下文才能真正地工作。但如果我们不限制它，就会有多个 agent 在重复工作。

具体做法是：让 subagent 有足够的上下文，但同时要被严格约束（比如只读、递归深度受限）。

例如：Claude Code 很早就支持了 subagent，让它们继承主 agent 的沙盒和审批设置。

(这让我想起了分布式系统里的 actor 模型——怎么拆分是简单的，难的是怎么设计消息边界、生命周期和失败处理。agent 的 subagent 问题，本质上是一个分布式系统问题。)

03. 从 Prompt Engineering 到 Harness Engineering

这条线大概是这样的：

2022–2023：prompt engineering——把一个问题问得更好
2024–2025：context engineering——给模型提供更合适的上下文、RAG、工具调用
2026 起：harness engineering——设计围绕模型的完整软件控制层

Prompt engineering 没“死”，它只不过变成了 harness engineering 的一个子问题。

模型之间的差距在变小，harness 之间的差距在变大。

同时这也表明创业机会的重心在转移：

模型层：仍然是巨头主导，开源和闭源的差距在缩小
Harness 层：空间还很大，Claude Code 和 Codex 也只是专门针对 coding 的，其他领域（数据分析、研究、设计、法律）的 harness 都还没真正被做出来
垂直 harness：针对特定工作流深度优化的 harness，可能是对抗通用大模型降维打击最实际的路径

Coding agent 专门服务于一个开发者在仓库里写代码；OpenClaw 则更像一个本地通用平台，能跨多个场景长期运行，编程只是它其中一块能力。

同样是 harness，垂直 harness 和通用 harness 完全不同。中间的差距，可能是下一波 agent 公司分化的主轴。

04. 结论

Deepmind 的 Philipp Schmid 去年做过一个判断："The Harness is the Dataset."——Harness 本身就是数据集。当时听起来有点激进，但现在越来越觉得这个判断会在未来两年变成行业共识。

未来很多看起来像模型能力的东西，其实是 harness 能力。

到那时候 LLM 代表的，可能早就不是 3 年前的那个 next-token 预测了。