为什么我不只用 ChatGPT而要用 Codex模型之外才是 Agent 的战场1. 一个经常被问到的问题很多人问过我一个问题我直接用 ChatGPT不也能写代码、查资料、改方案吗为什么还要用 Codex / Claude Code 这类工具这个问题非常关键。因为从表面看它们确实都在和大模型交互。你给一个需求模型给一个回答你继续追问它继续补充。ChatGPT 可以写代码Codex 也可以写代码。那区别到底在哪里我的回答是区别不只在模型而在模型外面的 Harness。同一个模型放在聊天框里它主要是在生成回答放进 Codex / Claude Code 这样的系统里它就开始接触文件、命令、测试、diff、权限、上下文、长期状态和人工确认。这不是入口差异而是工作环境差异。2. ChatGPT 和 Codex 的核心区别先看一个简单对比。维度ChatGPT 聊天框Codex / Claude Code 类工具工作位置工作系统外部工作目录 / 代码库内部上下文来源用户手动粘贴文件系统、项目结构、历史修改、命令输出输出形态回答、解释、代码片段文件修改、diff、命令结果、任务状态验证方式用户手动验证后反馈可运行测试、构建、lint、搜索、日志检查失败处理用户把错误贴回去Agent 读取错误并继续修正权限边界主要靠用户自己控制复制粘贴工具权限、审批、沙箱、人工确认可追踪性聊天记录为主diff、命令、trace、任务过程典型角色高智商顾问接入真实工作台的执行系统这也是为什么很多人用 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 可以拆成这些部分模块作用Context选择、压缩、组织任务所需上下文Tools让模型调用文件系统、搜索、命令、API、浏览器等能力Memory保存长期状态、实验日志、历史决策、可复用经验Permission控制哪些动作可以自动执行哪些必须人工确认Eval判断结果是否正确提供自动化反馈Trace记录过程、失败、重试和关键判断Human Review在关键节点让人类确认方向、风险和最终交付如果只有模型没有 HarnessAI 主要是在回答问题。有了 Harness模型才可能开始进入真实工作流。4. 从 Prompt Engineering 到 Harness Engineering过去几年很多 AI 应用优化都从 prompt 开始。Prompt 写得更清楚模型输出通常会更好。后来大家又开始做 context engineering如何给模型更好的背景信息、检索结果、历史状态和任务结构。但对于复杂任务来说这还不够。真正的问题逐渐变成任务如何拆解工具如何调用中间产物如何保存失败如何被记录测试如何反馈给模型人类什么时候介入结果如何验收下一次任务如何复用上一次经验这就是 Harness Engineering 的范围。可以把演化路径粗略理解成Prompt EngineeringContext EngineeringWorkflow EngineeringHarness EngineeringHarness Self-Improvement这条线的重点是优化对象越来越从“给模型的一句话”扩展到“模型所处的整个工作系统”。5. 为什么 Codex 是 Harness 思路的典型例子以 Codex / Claude Code 这类 coding agent 为例它们真正重要的不是“模型会写代码”而是它们把模型放进了一个工程闭环。否是否是开发者提出任务Agent 读取项目上下文Agent 修改文件生成 diff运行测试 / 构建 / lint结果是否通过读取错误与日志开发者审查是否接受提交 / 继续下一步这个闭环里模型只是其中一个核心组件。真正让它可用的是它能读项目文件它能修改真实代码它能运行命令它能看到失败信息它能继续修它的修改有 diff它的高风险动作受权限控制它最终需要开发者确认。这就是 Harness 的价值。它不是让模型“更像人”而是让模型进入一个可以行动、验证、追踪和受控的系统。6. 文件系统为什么是长期记忆Lilian Weng 文章里一个很重要的点是文件系统可以成为长期记忆。长任务不能只靠上下文窗口。因为上下文窗口会满会压缩会丢失细节也很难沉淀成可复用经验。对于一个真实 Agent 来说很多东西应该被持久化实验日志代码 diff错误 trace任务计划中间产物失败原因人类审查意见最终验收结论。这也是为什么“聊天记录”不等于“工作记忆”。聊天记录适合回顾对话但真实任务需要更结构化的状态。例如内容聊天记录是否够用更适合的保存方式一次报错日志勉强可以日志文件 / trace多轮代码修改不够Git diff / patch实验结果不够实验记录 / JSON / Markdown人类决策可以但容易淹没决策记录 / review 文件可复用经验不够规则、memory、skill、文档所以一个成熟 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 至少需要这些边界边界为什么重要权限边界防止模型自行扩大可执行动作Eval 边界防止被评测系统自己定义成功标准Human Review保留人类对目标、风险和交付的判断权Audit Trace让每次执行、失败、重试都可追踪Rollback出问题时能恢复到已知安全状态Scope Control防止小任务扩散成大范围不可控修改真正可靠的 Agent不是“什么都能自动做”。相反它应该知道什么可以自动推进什么必须停下来问人。9. 回到问题为什么不只用 ChatGPT现在回到文章开头的问题为什么我不只用 ChatGPT而要用 Codex不是因为 ChatGPT 不够聪明。而是因为重要工作需要的不只是聪明回答还需要一个可以执行、验证、记录、修正、回滚、审查的系统。ChatGPT 更像高智商顾问。Codex / Claude Code 更像把这个顾问接进了真实工作台。这也是 Agent 和聊天机器人的根本区别类型核心能力主要限制聊天机器人生成回答、解释、建议不直接进入工作环境Agent 工具在环境中行动并根据反馈修正需要更强的权限、审计和边界控制Harness 系统组织模型、工具、上下文、记忆、评估和人类协作工程复杂度更高未来 AI Agent 的竞争不只是模型更强而是谁能把模型放进更可靠、更可观测、更可控的工作循环。这就是 Harness Engineering 真正重要的地方。它不是又一个技术热词而是在提醒我们AI Agent 的下一层竞争已经从模型本身转向模型外面的运行系统。参考来源Lilian Weng: Harness Engineering for Self-Improvementhttps://lilianweng.github.io/posts/2026-07-04-harness/Self-Harness: Harnesses That Improve Themselveshttps://arxiv.org/abs/2606.09498Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesseshttps://arxiv.org/abs/2604.25850
为什么我不只用 ChatGPT而要用 Codex模型之外才是 Agent 的战场1. 一个经常被问到的问题很多人问过我一个问题我直接用 ChatGPT不也能写代码、查资料、改方案吗为什么还要用 Codex / Claude Code 这类工具这个问题非常关键。因为从表面看它们确实都在和大模型交互。你给一个需求模型给一个回答你继续追问它继续补充。ChatGPT 可以写代码Codex 也可以写代码。那区别到底在哪里我的回答是区别不只在模型而在模型外面的 Harness。同一个模型放在聊天框里它主要是在生成回答放进 Codex / Claude Code 这样的系统里它就开始接触文件、命令、测试、diff、权限、上下文、长期状态和人工确认。这不是入口差异而是工作环境差异。2. ChatGPT 和 Codex 的核心区别先看一个简单对比。维度ChatGPT 聊天框Codex / Claude Code 类工具工作位置工作系统外部工作目录 / 代码库内部上下文来源用户手动粘贴文件系统、项目结构、历史修改、命令输出输出形态回答、解释、代码片段文件修改、diff、命令结果、任务状态验证方式用户手动验证后反馈可运行测试、构建、lint、搜索、日志检查失败处理用户把错误贴回去Agent 读取错误并继续修正权限边界主要靠用户自己控制复制粘贴工具权限、审批、沙箱、人工确认可追踪性聊天记录为主diff、命令、trace、任务过程典型角色高智商顾问接入真实工作台的执行系统这也是为什么很多人用 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 可以拆成这些部分模块作用Context选择、压缩、组织任务所需上下文Tools让模型调用文件系统、搜索、命令、API、浏览器等能力Memory保存长期状态、实验日志、历史决策、可复用经验Permission控制哪些动作可以自动执行哪些必须人工确认Eval判断结果是否正确提供自动化反馈Trace记录过程、失败、重试和关键判断Human Review在关键节点让人类确认方向、风险和最终交付如果只有模型没有 HarnessAI 主要是在回答问题。有了 Harness模型才可能开始进入真实工作流。4. 从 Prompt Engineering 到 Harness Engineering过去几年很多 AI 应用优化都从 prompt 开始。Prompt 写得更清楚模型输出通常会更好。后来大家又开始做 context engineering如何给模型更好的背景信息、检索结果、历史状态和任务结构。但对于复杂任务来说这还不够。真正的问题逐渐变成任务如何拆解工具如何调用中间产物如何保存失败如何被记录测试如何反馈给模型人类什么时候介入结果如何验收下一次任务如何复用上一次经验这就是 Harness Engineering 的范围。可以把演化路径粗略理解成Prompt EngineeringContext EngineeringWorkflow EngineeringHarness EngineeringHarness Self-Improvement这条线的重点是优化对象越来越从“给模型的一句话”扩展到“模型所处的整个工作系统”。5. 为什么 Codex 是 Harness 思路的典型例子以 Codex / Claude Code 这类 coding agent 为例它们真正重要的不是“模型会写代码”而是它们把模型放进了一个工程闭环。否是否是开发者提出任务Agent 读取项目上下文Agent 修改文件生成 diff运行测试 / 构建 / lint结果是否通过读取错误与日志开发者审查是否接受提交 / 继续下一步这个闭环里模型只是其中一个核心组件。真正让它可用的是它能读项目文件它能修改真实代码它能运行命令它能看到失败信息它能继续修它的修改有 diff它的高风险动作受权限控制它最终需要开发者确认。这就是 Harness 的价值。它不是让模型“更像人”而是让模型进入一个可以行动、验证、追踪和受控的系统。6. 文件系统为什么是长期记忆Lilian Weng 文章里一个很重要的点是文件系统可以成为长期记忆。长任务不能只靠上下文窗口。因为上下文窗口会满会压缩会丢失细节也很难沉淀成可复用经验。对于一个真实 Agent 来说很多东西应该被持久化实验日志代码 diff错误 trace任务计划中间产物失败原因人类审查意见最终验收结论。这也是为什么“聊天记录”不等于“工作记忆”。聊天记录适合回顾对话但真实任务需要更结构化的状态。例如内容聊天记录是否够用更适合的保存方式一次报错日志勉强可以日志文件 / trace多轮代码修改不够Git diff / patch实验结果不够实验记录 / JSON / Markdown人类决策可以但容易淹没决策记录 / review 文件可复用经验不够规则、memory、skill、文档所以一个成熟 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 至少需要这些边界边界为什么重要权限边界防止模型自行扩大可执行动作Eval 边界防止被评测系统自己定义成功标准Human Review保留人类对目标、风险和交付的判断权Audit Trace让每次执行、失败、重试都可追踪Rollback出问题时能恢复到已知安全状态Scope Control防止小任务扩散成大范围不可控修改真正可靠的 Agent不是“什么都能自动做”。相反它应该知道什么可以自动推进什么必须停下来问人。9. 回到问题为什么不只用 ChatGPT现在回到文章开头的问题为什么我不只用 ChatGPT而要用 Codex不是因为 ChatGPT 不够聪明。而是因为重要工作需要的不只是聪明回答还需要一个可以执行、验证、记录、修正、回滚、审查的系统。ChatGPT 更像高智商顾问。Codex / Claude Code 更像把这个顾问接进了真实工作台。这也是 Agent 和聊天机器人的根本区别类型核心能力主要限制聊天机器人生成回答、解释、建议不直接进入工作环境Agent 工具在环境中行动并根据反馈修正需要更强的权限、审计和边界控制Harness 系统组织模型、工具、上下文、记忆、评估和人类协作工程复杂度更高未来 AI Agent 的竞争不只是模型更强而是谁能把模型放进更可靠、更可观测、更可控的工作循环。这就是 Harness Engineering 真正重要的地方。它不是又一个技术热词而是在提醒我们AI Agent 的下一层竞争已经从模型本身转向模型外面的运行系统。参考来源Lilian Weng: Harness Engineering for Self-Improvementhttps://lilianweng.github.io/posts/2026-07-04-harness/Self-Harness: Harnesses That Improve Themselveshttps://arxiv.org/abs/2606.09498Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesseshttps://arxiv.org/abs/2604.25850
