为什么我不只用 ChatGPT，而要用 Codex：模型之外，才是 Agent 的战场

1. 一个经常被问到的问题

很多人问过我一个问题：

我直接用 ChatGPT，不也能写代码、查资料、改方案吗？为什么还要用 Codex / Claude Code 这类工具？

这个问题非常关键。

因为从表面看，它们确实都在和大模型交互。你给一个需求，模型给一个回答；你继续追问，它继续补充。ChatGPT 可以写代码，Codex 也可以写代码。那区别到底在哪里？

我的回答是：

区别不只在模型，而在模型外面的 Harness。

同一个模型，放在聊天框里，它主要是在生成回答；放进 Codex / Claude Code 这样的系统里，它就开始接触文件、命令、测试、diff、权限、上下文、长期状态和人工确认。

这不是入口差异，而是工作环境差异。

2. ChatGPT 和 Codex 的核心区别

先看一个简单对比。

这也是为什么很多人用 ChatGPT 会觉得“有帮助，但不彻底”。

模型很聪明，但它站在工作系统外面。你要把上下文搬进去，把代码搬出来，把错误搬回去，把新结果再搬出去。最后人变成了模型和工作系统之间的搬运工。

而 Codex / Claude Code 这类工具的价值，是把模型接进工作现场。

3. Harness 是什么

Lilian Weng 在 2026 年 7 月 4 日写了一篇长文，叫Harness Engineering for Self-Improvement。

它不是传统意义上的单篇论文，更像一篇技术综述和观点文章。里面把很多方向串在一起：Agent、context engineering、workflow optimization、self-improvement、coding agent、eval、file system memory。

这篇文章给了一个很适合解释当前 Agent 演化的词：Harness。

可以把 Harness 理解为：

围绕 base model 的运行系统。它决定模型如何接收上下文、调用工具、保存状态、执行任务、评估结果、处理失败，并在关键节点接受人类确认。

也就是说，Harness 不是 prompt 模板，也不是 UI。它是模型外面的工程系统。

一个最小化的 Agent Harness 可以拆成这些部分：

如果只有模型，没有 Harness，AI 主要是在回答问题。

有了 Harness，模型才可能开始进入真实工作流。

4. 从 Prompt Engineering 到 Harness Engineering

过去几年，很多 AI 应用优化都从 prompt 开始。

Prompt 写得更清楚，模型输出通常会更好。后来大家又开始做 context engineering：如何给模型更好的背景信息、检索结果、历史状态和任务结构。

但对于复杂任务来说，这还不够。

真正的问题逐渐变成：

• 任务如何拆解？
• 工具如何调用？
• 中间产物如何保存？
• 失败如何被记录？
• 测试如何反馈给模型？
• 人类什么时候介入？
• 结果如何验收？
• 下一次任务如何复用上一次经验？

这就是 Harness Engineering 的范围。

可以把演化路径粗略理解成：

这条线的重点是：优化对象越来越从“给模型的一句话”扩展到“模型所处的整个工作系统”。

5. 为什么 Codex 是 Harness 思路的典型例子

以 Codex / Claude Code 这类 coding agent 为例，它们真正重要的不是“模型会写代码”，而是它们把模型放进了一个工程闭环。

这个闭环里，模型只是其中一个核心组件。

真正让它可用的是：

• 它能读项目文件；
• 它能修改真实代码；
• 它能运行命令；
• 它能看到失败信息；
• 它能继续修；
• 它的修改有 diff；
• 它的高风险动作受权限控制；
• 它最终需要开发者确认。

这就是 Harness 的价值。

它不是让模型“更像人”，而是让模型进入一个可以行动、验证、追踪和受控的系统。

6. 文件系统为什么是长期记忆

Lilian Weng 文章里一个很重要的点，是文件系统可以成为长期记忆。

长任务不能只靠上下文窗口。因为上下文窗口会满，会压缩，会丢失细节，也很难沉淀成可复用经验。

对于一个真实 Agent 来说，很多东西应该被持久化：

• 实验日志；
• 代码 diff；
• 错误 trace；
• 任务计划；
• 中间产物；
• 失败原因；
• 人类审查意见；
• 最终验收结论。

这也是为什么“聊天记录”不等于“工作记忆”。

聊天记录适合回顾对话，但真实任务需要更结构化的状态。例如：

所以，一个成熟 Agent 系统一定会越来越重视文件系统、结构化状态和长期记忆。

7. Harness 自我改进意味着什么

Lilian Weng 这篇文章更进一步讨论了自我改进。

这里的自我改进，不一定是模型明天直接改自己的权重。短期内更现实的路径，可能是模型参与改进自己的外部系统。

也就是：

• 改进 prompt；
• 改进 structured context；
• 改进 workflow；
• 改进 harness code；
• 改进 optimizer；
• 生成更好的 eval；
• 根据失败 trace 调整工具和流程。

这比“模型自己重写模型”更接近当前工程现实。

举个例子，一个 coding agent 反复失败后，不只是让模型下次“更努力”，而是可以让系统沉淀规则：

• 哪类任务要先跑测试；
• 哪类文件不能自动改；
• 哪些错误应该先搜索历史 issue；
• 哪些命令失败后需要换策略；
• 哪些修改必须拆成更小 diff；
• 哪些输出必须经过人工确认。

这些不是模型权重变化，但它们会让整个 Agent 系统变强。

这就是 Harness Self-Improvement 的现实意义。

8. 边界：不能让系统改掉自己的安全约束

但 Harness 自我改进不能只讲兴奋点。

如果一个 Agent 可以改进自己的 Harness，那么最危险的问题也会出现：

• 它能不能改自己的权限边界？
• 它能不能修改自己的 eval？
• 它能不能绕过人工确认？
• 它能不能把安全规则当成“效率瓶颈”优化掉？
• 它能不能隐藏失败 trace？

所以越是进入 Harness 自我改进阶段，越要把关键边界放在循环外面。

一个可靠的 Agent Harness 至少需要这些边界：

真正可靠的 Agent，不是“什么都能自动做”。

相反，它应该知道什么可以自动推进，什么必须停下来问人。

9. 回到问题：为什么不只用 ChatGPT

现在回到文章开头的问题：

为什么我不只用 ChatGPT，而要用 Codex？

不是因为 ChatGPT 不够聪明。

而是因为重要工作需要的不只是聪明回答，还需要一个可以执行、验证、记录、修正、回滚、审查的系统。

ChatGPT 更像高智商顾问。Codex / Claude Code 更像把这个顾问接进了真实工作台。

这也是 Agent 和聊天机器人的根本区别：

未来 AI Agent 的竞争，不只是模型更强，而是谁能把模型放进更可靠、更可观测、更可控的工作循环。

这就是 Harness Engineering 真正重要的地方。

它不是又一个技术热词，而是在提醒我们：AI Agent 的下一层竞争，已经从模型本身，转向模型外面的运行系统。

参考来源

• Lilian Weng: Harness Engineering for Self-Improvement
  https://lilianweng.github.io/posts/2026-07-04-harness/

• Self-Harness: Harnesses That Improve Themselves
  https://arxiv.org/abs/2606.09498

• Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses
  https://arxiv.org/abs/2604.25850