同一套问题三种回答Anthropic、OpenAI、Cursor 的 Harness 方案深度对比参考来源一文读懂Harness Engineering微信公众号/ Anthropic / OpenAI / Cursor 系列工程博客2025.11–2026.3前置知识建议先阅读《同样的模型换个壳就能从 52.8% 冲到 66.5%Agent Harness 工程十五个月演进全览》在 Agent Harness 这条技术路线上Anthropic、OpenAI、Cursor 三家头部公司面对同样的命题——如何管住 AI Agent 让它靠谱地干活——走出了三条截然不同的路径。Anthropic 管流程用 JSON 物理锁、三步唤醒、Context Reset 构建了一套严格的打卡制度OpenAI 管环境用 Repo-as-truth 和自动化 Linter 把整个代码仓库变成 Agent 唯一能感知的现实Cursor 管并发用 Planner-Worker-Judge 三层阶级和 8 通道盲审压制了多 Agent 的无政府状态。本文从设计哲学、核心机制、适用场景三个维度进行系统对比帮你理解每种方案在什么条件下最优。文章目录同一套问题三种回答Anthropic、OpenAI、Cursor 的 Harness 方案深度对比一、三条路径一个起点二、Anthropic管流程——用制度替代信任2.1 核心哲学不信任模型2.2 关键机制2.3 一个典型的 Anthropic 风格设计2.4 适用场景三、OpenAI管环境——仓库即现实3.1 核心哲学不控制行为控制认知3.2 关键机制3.3 设计哲学的核心差异3.4 适用场景四、Cursor管并发——用层级压制混乱4.1 核心哲学AI 没有集体意识4.2 关键机制4.3 Cursor 最狠的设计8 通道盲审4.4 适用场景五、交叉对比不是替代是互补六、选择框架你的系统该走哪条路七、结语一、三条路径一个起点如果把 Harness Engineering 的演进史看作一张地图你会发现一个有趣的现象在三家公司的实践中Harness 的加法几乎是同步进行的——大家都在发现 Bug、都在搭机制、都在加组件。但在加什么这件事上三家选择了完全不同的着力点。Anthropic 最早入场从 2024 年底的《Building effective agents》开始摸索到 2025 年 11 月的《Effective harnesses for long-running agents》体系成型走的是管住 Agent 的行为路线。OpenAI 的 Codex 团队从 2025 年 8 月一个空仓库起步到 2026 年 2 月发布《Harness engineering: leveraging Codex in an agent-first world》走的却是管住 Agent 的认知路线。Cursor 则从产品实战中杀出来2026 年 1 月的《Scaling long-running autonomous coding》记录了并发崩塌的惨烈现场逼出了管住 Agent 之间的关系路线。同一个起点——模型会乱来。三种回答——管行为、管认知、管关系。这不是谁对谁错的问题。三家面对的项目规模、团队结构、应用场景不同因此最需要被管住的东西也不同。二、Anthropic管流程——用制度替代信任2.1 核心哲学不信任模型Anthropic 的设计哲学可以用一句话概括绝不信任模型能记住、能自觉、能判断。他们是最早发现记事本不够的团队。Context Engineering 把信息存好了但模型不翻、翻了不照做、做完不验证。于是他们的应对方向不是优化记事本而是建管理制度。2.2 关键机制机制解决的问题设计原则JSON 物理锁虚标完成、提前交卷出题人和答题人分离只能标状态不能改题目三步唤醒仪式失忆实习生每次启动强制翻交接簿不信任 Agent 自己记得Git 存档 revert跑偏后无法自救不指望金鱼自己撤销错误直接给时间机器Context Reset上下文撑爆不压缩直接换一条新金鱼只给交接单2.3 一个典型的 Anthropic 风格设计最有代表性的是 JSON 物理锁的细节初始化 Agent 生成的功能清单使用 JSON 而非 Markdown。这不是技术偏好。选 JSON 的真实原因是JSON 的 Schema 可以做强校验。Markdown 是给人读的模型可以随便加一行 “done” 就算完成。JSON 里你只能改一个字段的值不能增减字段违规直接解析报错。给模型自由度的同时用数据结构本身限制它能做的操作。这就是 Anthropic 的流程管控逻辑不是告诉模型你应该怎么做而是让模型只能这么做。2.4 适用场景Anthropic 方案最适合的场景是单 Agent 长程任务——一个任务要跑几个小时、需要几十轮 Session 接力。如果你的瓶颈是 Agent 记不住、不自觉、爱偷懒这套打卡制度就是最优解。三、OpenAI管环境——仓库即现实3.1 核心哲学不控制行为控制认知OpenAI 的 Codex 团队走了另一条路。他们的实验设定本身就足以说明问题三个工程师不写一行代码。所有代码——逻辑、测试、部署配置、文档、监控——全部由 Codex Agent 生成。五个月一百万行代码一千五百个 PR零行人工输入。在这种极端设定下他们得到的核心认知是Repo-as-truth仓库即现实。从 Agent 的角度看它在运行时无法访问的东西就是不存在的。Slack 上的讨论不存在。团队脑子里的共识不存在。Google Docs 里的方案不存在。唯一存在的是代码仓库里那些版本化的、Agent 能直接读到的文件。3.2 关键机制机制解决的问题设计原则AGENTS.mdAgent 不知道去哪找信息不是百科全书是目录——只告诉去哪找更深的信息Linter 自动化检查Agent 读了规则但不遵守关键规则变成可执行检查挂在 CI 上不合规就合并不进去分层仓库结构依赖混乱每个业务域固定层级依赖方向严格单向Doc-gardening Agent文档和真实代码脱节专职文档园丁每天巡逻过时文档自动发起修改请求3.3 设计哲学的核心差异对比 Anthropic 和 OpenAI 面对同一类问题的处理方式差异一目了然进度管理Anthropic 用 JSON 物理锁——出题人和答题人分离答题人只能改状态位。OpenAI 则反过来——它不管 Agent 怎么管理进度它只管规则写没写进仓库、Linter 能不能自动拦住违规。规则遵守Anthropic 用三步唤醒仪式强制 Agent 翻本子。OpenAI 用 custom linter 规则挂在 CI 流水线上——Agent 不需要记住规则它只需要根据报错信息改到通过为止。用一个比喻Anthropic 是给工人定了一套严格的操作规程工人必须打卡、翻交接簿、按清单干活。OpenAI 是改造了整个工厂——车间布局、流水线、质检机器全部为工人重新设计工人想出错都没有出错的机会。Anthropic 管控的是 Agent 的行为OpenAI 管控的是 Agent 能感知到的整个世界。3.4 适用场景OpenAI 方案最适合的场景是多人多 Agent 混合协作的大规模项目——当代码库膨胀到百万行、几十个 Agent 同时读写时单靠流程管控已经力不从心。你需要让环境本身变成约束。如果你的瓶颈是信息散布在 Slack、文档、人脑子里Agent 拿到的永远不是最新最全的现实Repo-as-truth 就是最优解。四、Cursor管并发——用层级压制混乱4.1 核心哲学AI 没有集体意识Cursor 的切入点最为独特——他们不是从单 Agent 的可靠性出发而是从并发崩塌出发。当几百个 Agent 涌入同一个代码仓库时他们观察到的现象超出了所有人的预期Agent 不只互相堵塞还会主动摸鱼。核心代码被占用后它们就改注释、调空格、整缩进——不是恶意而是为了显示自己还在工作。这暴露了一个根本问题AI 没有集体意识。单个 Agent 各自最优的行为在多 Agent 环境下会叠加成全局最劣。4.2 关键机制机制解决的问题设计原则Planner-Worker-Judge 三层多 Agent 无政府状态DAG 引擎硬锁Planner 没批Worker 一步也动不了交接报告制度偏离计划无人发现每个 Worker 必须提交工作总结发现的问题偏离说明8 通道并行盲审裁判模型也被代码表象欺骗打乱顺序 → 独立发现 → 多数投票 → 验证器过滤周期性 fresh start系统长期运行后性能漂移不修复累积问题直接清空重建4.3 Cursor 最狠的设计8 通道盲审在验证环节Anthropic 用了一个 Evaluator 对抗一个 Generator。Cursor 觉得远远不够。他们在实践中发现即使是裁判模型也极容易被代码表面的逻辑自洽所欺骗。一段代码看着自洽、编译能过、测试通过实际逻辑是错的——单个裁判模型很难发现。于是他们搞出了 8 通道并行盲审拉起 8 个独立的 Bugbot每个拿到的代码差异顺序被随机打乱顺序不同 → 推理路径不同 → 幻觉不容易同步每个通道独立标记 Bug最后多数投票合并只在一个通道被标记的 Bug 直接过滤掉大概率是幻觉合并结果再过一遍验证器捕捉残留误报这背后的洞察很深模型不仅会犯错还容易集体犯同样的错。打乱输入顺序是一种廉价的去偏技巧——用最少的成本打破模型的思维惯性。4.4 适用场景Cursor 方案最适合的场景是高并发 Agent 协作——当你需要几十上百个 Agent 同时修改同一个代码库时扁平结构必然崩塌。如果你的瓶颈是 Agent 互相踩踏、锁竞争、集体摸鱼层级结构加门控就是最优解。五、交叉对比不是替代是互补把三套方案放在一起看维度AnthropicOpenAICursor核心命题Agent 不可信任Agent 的环境不完整Agent 没有集体意识管控对象行为流程认知环境关系并发核心手段打卡制度 物理锁Repo-as-truth Linter层级门控 盲审关键假设模型会偷懒、会忘记、会虚标信息散布在各处Agent 拿不到完整现实多 Agent 各自最优 ≠ 全局最优典型规模单 Agent 长程任务多人多 Agent 混合协作高并发 Agent 集群独特贡献Context Reset、JSON 锁AGENTS.md 目录式指令、Doc-gardening8 通道盲审、DAG 门控一个重要的事实是这三套方案不是互斥的。Anthropic 管的是 Agent 的执行纪律——即使有了 OpenAI 的 Repo-as-truthAgent 还是可能提前交卷。Cursor 管的是多 Agent 调度——即使每个 Agent 都按 Anthropic 的流程跑20 个同时跑还是会互相堵塞。它们解决的是同一个问题的不同层面。在实际工程中三家的方案会自然叠加用 OpenAI 的方式管仓库结构用 Anthropic 的方式管单个 Agent 的执行纪律用 Cursor 的方式管多 Agent 的并发调度。但叠加有个前提先搞清楚你的系统当前最痛的点在哪一层。六、选择框架你的系统该走哪条路判断你的 Harness 方案应该侧重哪条路线问自己三个问题问题一Agent 做对了吗如果你的 Agent 产出质量本身堪忧——功能跑不通、逻辑有漏洞、测试过不了——那问题在第一层和第三层。先从 Anthropic 的流程管控入手JSON 锁保证不虚标、Context Reset 保证不丢记忆。如果功能性测试通过了但主观质量差再加上 OpenAI 的 Linter 或 Cursor 的盲审。问题二Agent 看到的是真实世界吗如果你的 Agent 技术水平没问题但产出的东西和你的预期对不上——它理解偏了需求、用了过时的 API、遵循了已废弃的架构规范——那问题在环境层。走 OpenAI 的 Repo-as-truth 路线把所有决策写进仓库用 AGENTS.md 做目录用 Linter 做自动化门禁。问题三Agent 之间在互相拖累吗如果你的单 Agent 任务一切正常但一上规模就崩溃——锁竞争、改注释摸鱼、吞吐量暴跌——那问题在并发层。走 Cursor 的层级门控路线Planner-Worker-Judge 分层DAG 引擎硬锁强制执行先规划后执行。一个常见的错误在不痛的层面加机制。很多团队在单 Agent 还没跑稳的时候就去搞多 Agent 并发调度结果 Agent 本身就不靠谱并发只是让不靠谱加速扩散。先跑稳单 Agent再上并发——这是三家公司的实践里反复验证的顺序。七、结语Anthropic、OpenAI、Cursor面对同一个问题——怎么让 Agent 靠谱地干活——给出了三种完全不同的答案。Anthropic 说不信任它用制度管住它的行为。OpenAI 说不控制它改造它看到的世界。Cursor 说不指望它自觉用层级压住它们之间的关系。这三套方案之间没有绝对优劣。它们的价值取决于你的项目当前最痛的点在哪里。真正重要的是——先诊断再开药。而更有趣的问题在后面这三套方案都不是终点。Anthropic 随着 Opus 4.6 的发布已经开始拆自己当年搭的组件——Context Reset 拆了Sprint Contract 简化了。每一层补偿都是临时的。下一篇我们来聊聊这个最核心的洞察为什么 Harness 的每一块砖最终都会被拆掉本文说明本文基于 Anthropic、OpenAI、Cursor 公开发布的工程博客与技术论文整理。所有引用数据均来自原始文献。核心参考文献微信公众号《一文读懂Harness Engineering》Anthropic《Building effective agents》2024.12Anthropic《Effective harnesses for long-running agents》2025.11Anthropic《Harness design for long-running application development》2026.3OpenAI《Harness engineering: leveraging Codex in an agent-first world》2026.2Cursor《Scaling long-running autonomous coding》2026.1Cursor《Building a better Bugbot》2026.1感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
同一套问题三种回答Anthropic、OpenAI、Cursor 的 Harness 方案深度对比参考来源一文读懂Harness Engineering微信公众号/ Anthropic / OpenAI / Cursor 系列工程博客2025.11–2026.3前置知识建议先阅读《同样的模型换个壳就能从 52.8% 冲到 66.5%Agent Harness 工程十五个月演进全览》在 Agent Harness 这条技术路线上Anthropic、OpenAI、Cursor 三家头部公司面对同样的命题——如何管住 AI Agent 让它靠谱地干活——走出了三条截然不同的路径。Anthropic 管流程用 JSON 物理锁、三步唤醒、Context Reset 构建了一套严格的打卡制度OpenAI 管环境用 Repo-as-truth 和自动化 Linter 把整个代码仓库变成 Agent 唯一能感知的现实Cursor 管并发用 Planner-Worker-Judge 三层阶级和 8 通道盲审压制了多 Agent 的无政府状态。本文从设计哲学、核心机制、适用场景三个维度进行系统对比帮你理解每种方案在什么条件下最优。文章目录同一套问题三种回答Anthropic、OpenAI、Cursor 的 Harness 方案深度对比一、三条路径一个起点二、Anthropic管流程——用制度替代信任2.1 核心哲学不信任模型2.2 关键机制2.3 一个典型的 Anthropic 风格设计2.4 适用场景三、OpenAI管环境——仓库即现实3.1 核心哲学不控制行为控制认知3.2 关键机制3.3 设计哲学的核心差异3.4 适用场景四、Cursor管并发——用层级压制混乱4.1 核心哲学AI 没有集体意识4.2 关键机制4.3 Cursor 最狠的设计8 通道盲审4.4 适用场景五、交叉对比不是替代是互补六、选择框架你的系统该走哪条路七、结语一、三条路径一个起点如果把 Harness Engineering 的演进史看作一张地图你会发现一个有趣的现象在三家公司的实践中Harness 的加法几乎是同步进行的——大家都在发现 Bug、都在搭机制、都在加组件。但在加什么这件事上三家选择了完全不同的着力点。Anthropic 最早入场从 2024 年底的《Building effective agents》开始摸索到 2025 年 11 月的《Effective harnesses for long-running agents》体系成型走的是管住 Agent 的行为路线。OpenAI 的 Codex 团队从 2025 年 8 月一个空仓库起步到 2026 年 2 月发布《Harness engineering: leveraging Codex in an agent-first world》走的却是管住 Agent 的认知路线。Cursor 则从产品实战中杀出来2026 年 1 月的《Scaling long-running autonomous coding》记录了并发崩塌的惨烈现场逼出了管住 Agent 之间的关系路线。同一个起点——模型会乱来。三种回答——管行为、管认知、管关系。这不是谁对谁错的问题。三家面对的项目规模、团队结构、应用场景不同因此最需要被管住的东西也不同。二、Anthropic管流程——用制度替代信任2.1 核心哲学不信任模型Anthropic 的设计哲学可以用一句话概括绝不信任模型能记住、能自觉、能判断。他们是最早发现记事本不够的团队。Context Engineering 把信息存好了但模型不翻、翻了不照做、做完不验证。于是他们的应对方向不是优化记事本而是建管理制度。2.2 关键机制机制解决的问题设计原则JSON 物理锁虚标完成、提前交卷出题人和答题人分离只能标状态不能改题目三步唤醒仪式失忆实习生每次启动强制翻交接簿不信任 Agent 自己记得Git 存档 revert跑偏后无法自救不指望金鱼自己撤销错误直接给时间机器Context Reset上下文撑爆不压缩直接换一条新金鱼只给交接单2.3 一个典型的 Anthropic 风格设计最有代表性的是 JSON 物理锁的细节初始化 Agent 生成的功能清单使用 JSON 而非 Markdown。这不是技术偏好。选 JSON 的真实原因是JSON 的 Schema 可以做强校验。Markdown 是给人读的模型可以随便加一行 “done” 就算完成。JSON 里你只能改一个字段的值不能增减字段违规直接解析报错。给模型自由度的同时用数据结构本身限制它能做的操作。这就是 Anthropic 的流程管控逻辑不是告诉模型你应该怎么做而是让模型只能这么做。2.4 适用场景Anthropic 方案最适合的场景是单 Agent 长程任务——一个任务要跑几个小时、需要几十轮 Session 接力。如果你的瓶颈是 Agent 记不住、不自觉、爱偷懒这套打卡制度就是最优解。三、OpenAI管环境——仓库即现实3.1 核心哲学不控制行为控制认知OpenAI 的 Codex 团队走了另一条路。他们的实验设定本身就足以说明问题三个工程师不写一行代码。所有代码——逻辑、测试、部署配置、文档、监控——全部由 Codex Agent 生成。五个月一百万行代码一千五百个 PR零行人工输入。在这种极端设定下他们得到的核心认知是Repo-as-truth仓库即现实。从 Agent 的角度看它在运行时无法访问的东西就是不存在的。Slack 上的讨论不存在。团队脑子里的共识不存在。Google Docs 里的方案不存在。唯一存在的是代码仓库里那些版本化的、Agent 能直接读到的文件。3.2 关键机制机制解决的问题设计原则AGENTS.mdAgent 不知道去哪找信息不是百科全书是目录——只告诉去哪找更深的信息Linter 自动化检查Agent 读了规则但不遵守关键规则变成可执行检查挂在 CI 上不合规就合并不进去分层仓库结构依赖混乱每个业务域固定层级依赖方向严格单向Doc-gardening Agent文档和真实代码脱节专职文档园丁每天巡逻过时文档自动发起修改请求3.3 设计哲学的核心差异对比 Anthropic 和 OpenAI 面对同一类问题的处理方式差异一目了然进度管理Anthropic 用 JSON 物理锁——出题人和答题人分离答题人只能改状态位。OpenAI 则反过来——它不管 Agent 怎么管理进度它只管规则写没写进仓库、Linter 能不能自动拦住违规。规则遵守Anthropic 用三步唤醒仪式强制 Agent 翻本子。OpenAI 用 custom linter 规则挂在 CI 流水线上——Agent 不需要记住规则它只需要根据报错信息改到通过为止。用一个比喻Anthropic 是给工人定了一套严格的操作规程工人必须打卡、翻交接簿、按清单干活。OpenAI 是改造了整个工厂——车间布局、流水线、质检机器全部为工人重新设计工人想出错都没有出错的机会。Anthropic 管控的是 Agent 的行为OpenAI 管控的是 Agent 能感知到的整个世界。3.4 适用场景OpenAI 方案最适合的场景是多人多 Agent 混合协作的大规模项目——当代码库膨胀到百万行、几十个 Agent 同时读写时单靠流程管控已经力不从心。你需要让环境本身变成约束。如果你的瓶颈是信息散布在 Slack、文档、人脑子里Agent 拿到的永远不是最新最全的现实Repo-as-truth 就是最优解。四、Cursor管并发——用层级压制混乱4.1 核心哲学AI 没有集体意识Cursor 的切入点最为独特——他们不是从单 Agent 的可靠性出发而是从并发崩塌出发。当几百个 Agent 涌入同一个代码仓库时他们观察到的现象超出了所有人的预期Agent 不只互相堵塞还会主动摸鱼。核心代码被占用后它们就改注释、调空格、整缩进——不是恶意而是为了显示自己还在工作。这暴露了一个根本问题AI 没有集体意识。单个 Agent 各自最优的行为在多 Agent 环境下会叠加成全局最劣。4.2 关键机制机制解决的问题设计原则Planner-Worker-Judge 三层多 Agent 无政府状态DAG 引擎硬锁Planner 没批Worker 一步也动不了交接报告制度偏离计划无人发现每个 Worker 必须提交工作总结发现的问题偏离说明8 通道并行盲审裁判模型也被代码表象欺骗打乱顺序 → 独立发现 → 多数投票 → 验证器过滤周期性 fresh start系统长期运行后性能漂移不修复累积问题直接清空重建4.3 Cursor 最狠的设计8 通道盲审在验证环节Anthropic 用了一个 Evaluator 对抗一个 Generator。Cursor 觉得远远不够。他们在实践中发现即使是裁判模型也极容易被代码表面的逻辑自洽所欺骗。一段代码看着自洽、编译能过、测试通过实际逻辑是错的——单个裁判模型很难发现。于是他们搞出了 8 通道并行盲审拉起 8 个独立的 Bugbot每个拿到的代码差异顺序被随机打乱顺序不同 → 推理路径不同 → 幻觉不容易同步每个通道独立标记 Bug最后多数投票合并只在一个通道被标记的 Bug 直接过滤掉大概率是幻觉合并结果再过一遍验证器捕捉残留误报这背后的洞察很深模型不仅会犯错还容易集体犯同样的错。打乱输入顺序是一种廉价的去偏技巧——用最少的成本打破模型的思维惯性。4.4 适用场景Cursor 方案最适合的场景是高并发 Agent 协作——当你需要几十上百个 Agent 同时修改同一个代码库时扁平结构必然崩塌。如果你的瓶颈是 Agent 互相踩踏、锁竞争、集体摸鱼层级结构加门控就是最优解。五、交叉对比不是替代是互补把三套方案放在一起看维度AnthropicOpenAICursor核心命题Agent 不可信任Agent 的环境不完整Agent 没有集体意识管控对象行为流程认知环境关系并发核心手段打卡制度 物理锁Repo-as-truth Linter层级门控 盲审关键假设模型会偷懒、会忘记、会虚标信息散布在各处Agent 拿不到完整现实多 Agent 各自最优 ≠ 全局最优典型规模单 Agent 长程任务多人多 Agent 混合协作高并发 Agent 集群独特贡献Context Reset、JSON 锁AGENTS.md 目录式指令、Doc-gardening8 通道盲审、DAG 门控一个重要的事实是这三套方案不是互斥的。Anthropic 管的是 Agent 的执行纪律——即使有了 OpenAI 的 Repo-as-truthAgent 还是可能提前交卷。Cursor 管的是多 Agent 调度——即使每个 Agent 都按 Anthropic 的流程跑20 个同时跑还是会互相堵塞。它们解决的是同一个问题的不同层面。在实际工程中三家的方案会自然叠加用 OpenAI 的方式管仓库结构用 Anthropic 的方式管单个 Agent 的执行纪律用 Cursor 的方式管多 Agent 的并发调度。但叠加有个前提先搞清楚你的系统当前最痛的点在哪一层。六、选择框架你的系统该走哪条路判断你的 Harness 方案应该侧重哪条路线问自己三个问题问题一Agent 做对了吗如果你的 Agent 产出质量本身堪忧——功能跑不通、逻辑有漏洞、测试过不了——那问题在第一层和第三层。先从 Anthropic 的流程管控入手JSON 锁保证不虚标、Context Reset 保证不丢记忆。如果功能性测试通过了但主观质量差再加上 OpenAI 的 Linter 或 Cursor 的盲审。问题二Agent 看到的是真实世界吗如果你的 Agent 技术水平没问题但产出的东西和你的预期对不上——它理解偏了需求、用了过时的 API、遵循了已废弃的架构规范——那问题在环境层。走 OpenAI 的 Repo-as-truth 路线把所有决策写进仓库用 AGENTS.md 做目录用 Linter 做自动化门禁。问题三Agent 之间在互相拖累吗如果你的单 Agent 任务一切正常但一上规模就崩溃——锁竞争、改注释摸鱼、吞吐量暴跌——那问题在并发层。走 Cursor 的层级门控路线Planner-Worker-Judge 分层DAG 引擎硬锁强制执行先规划后执行。一个常见的错误在不痛的层面加机制。很多团队在单 Agent 还没跑稳的时候就去搞多 Agent 并发调度结果 Agent 本身就不靠谱并发只是让不靠谱加速扩散。先跑稳单 Agent再上并发——这是三家公司的实践里反复验证的顺序。七、结语Anthropic、OpenAI、Cursor面对同一个问题——怎么让 Agent 靠谱地干活——给出了三种完全不同的答案。Anthropic 说不信任它用制度管住它的行为。OpenAI 说不控制它改造它看到的世界。Cursor 说不指望它自觉用层级压住它们之间的关系。这三套方案之间没有绝对优劣。它们的价值取决于你的项目当前最痛的点在哪里。真正重要的是——先诊断再开药。而更有趣的问题在后面这三套方案都不是终点。Anthropic 随着 Opus 4.6 的发布已经开始拆自己当年搭的组件——Context Reset 拆了Sprint Contract 简化了。每一层补偿都是临时的。下一篇我们来聊聊这个最核心的洞察为什么 Harness 的每一块砖最终都会被拆掉本文说明本文基于 Anthropic、OpenAI、Cursor 公开发布的工程博客与技术论文整理。所有引用数据均来自原始文献。核心参考文献微信公众号《一文读懂Harness Engineering》Anthropic《Building effective agents》2024.12Anthropic《Effective harnesses for long-running agents》2025.11Anthropic《Harness design for long-running application development》2026.3OpenAI《Harness engineering: leveraging Codex in an agent-first world》2026.2Cursor《Scaling long-running autonomous coding》2026.1Cursor《Building a better Bugbot》2026.1感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
