❝2026 年大模型之间的智商差距正在缩小到小数点后一位。真正拉开差距的不再是模型有多聪明而是模型之外的那套基础设施有多扎实。❞一、一个正在发生的认知转变过去两年AI Agent 领域最热闹的话题永远是哪个模型更强。GPT-4o 还是 Claude OpusGemini 还是 DeepSeek我们盯着排行榜上的分数像追赛季积分一样计较着每零点几的差距。但在生产环境里做过 Agent 系统的人正在经历一个集体的认知转变「模型本身越来越不是瓶颈了包裹在模型外面的那套东西才是。」Phil SchmidHugging Face 技术专家在 2026 年初发表了一个很有洞察力的观点顶级模型在静态基准测试上的差距确实在缩小但这是一种错觉。真正的差距在模型执行第 50 步、第 100 步工具调用之后才显现出来。他把这个叫做「耐久性Durability」——模型在长链路任务中保持指令遵循和推理一致性的能力。但耐久性不是光靠模型训练就能解决的。你需要一整套上下文管理、错误恢复、状态持久化的机制来托住模型。这套机制就是「Agent Harness」。二、Harness 不是缰绳是操作系统很多人第一次听到 Harness 这个词直觉反应是给 AI 加限制、套个缰绳让它别乱跑。这个理解不能说错但格局小了。Phil Schmid 给了一个更精准的类比「如果模型是 CPU上下文窗口是 RAM那 Agent Harness 就是操作系统。」操作系统不是用来限制 CPU 的。它管理内存分配调度进程处理 I/O提供文件系统——它让 CPU 的算力被高效、可靠、持续地利用。没有操作系统的 CPU 就是一堆晶体管什么也干不了。同样没有 Harness 的大模型就是一个孤立的推理引擎。它很聪明但它不知道该记住什么、忘掉什么不知道工具调用失败了该怎么重试不知道任务做到一半被打断了该怎么恢复。Agent Harness 要管理的核心维度至少包括五个「上下文管理」什么信息进入模型的上下文窗口以什么顺序什么时候该驱逐过时的内容「工具选择」模型可以调用哪些能力这些工具的接口如何设计才能最大化模型的理解和使用效果「错误恢复」工具调用失败了怎么办推理走进死胡同了怎么回退重试逻辑怎么设计「状态管理」Agent 如何在多轮对话、跨会话、甚至跨上下文窗口边界之间记住自己做到了哪一步「外部记忆」如何在有限的上下文窗口之外存储和检索历史信息这五个维度中的每一个都不涉及让模型更聪明——它们解决的都是「让模型的聪明被持续、稳定地发挥出来」的问题。三、从一个朴素的问题说起聊 Harness 的设计有个问题绕不开「面对一个具体任务到底该用多重的智能来处理它」这不是一个理论问题。每次 Agent 调用都在烧 token如果一个 JSON 格式转换也要走一遍大模型推理那账单会先把你逼疯。围绕这个问题业界有一个流传很广的分层思路——三层能力金字塔▲ / \ Agent智能体 / \ 动态决策 · 全自主 · 最慢最贵 /─────\ / \ Skill技能 / \ 半结构化 · 混合执行 · 中等成本 /───────────\ / \ Script脚本 /───────────────\ 逻辑固定 · 零token · 最快最稳「底层 Script」处理所有确定性任务格式转换、数据校验、模板渲染。给定输入输出 100% 可预测。零 token 消耗毫秒级完成。「中层 Skill」是半结构化的混合体流程骨架固定但某些环节需要 AI 的判断力。比如从知识库检索相关内容并组织成回答——检索是确定性的组织需要语义理解。「顶层 Agent」负责真正开放的决策需求不明确、路径不确定、需要动态规划和试错的任务。核心原则是能往下沉的就往下沉——能用脚本的不要用 Skill能用 Skill 的不要动用 Agent。这个分层思路在 Harness 体系里对应的其实是工具选择这个维度——决定用什么样的执行方式去消化一个任务。思路本身没问题但顺着往下想有两个地方让我觉得不太对劲。沉淀是对的但别沉太死往下沉的思路暗含一个假设沉淀下来的东西是稳定的。但在 AI 能力快速迭代的今天这个假设值得质疑。Phil Schmid 在文章中引用了 Rich Sutton 著名的苦涩的教训The Bitter Lesson——「利用计算的通用方法总是能打败手工编码的人类知识。」他观察到许多公司包括 LangChain、Vercel 等不得不频繁重构它们的 Agent 系统因为新模型的发布改变了构建 Agent 的最佳方式。今天需要复杂管道才能实现的功能明天可能只需要一个提示词。这意味着什么「你辛辛苦苦沉淀下来的 Script 和 Skill可能在下一个模型版本发布时就过时了。」过早、过度地把能力固化到底层可能让你的系统变得僵硬——它很快但它无法适应变化。Phil Schmid 给出的建议是Build to Delete——「架构必须模块化随时准备撕毁昨天写的智能逻辑。」这和单纯的能往下沉就往下沉有本质区别。不是不该沉淀而是沉淀时要留好退路让每一层都可以被轻量级地替换。分好层之后Agent 跑偏了怎么办分层解决了任务该交给谁的问题但还有一个更现实的问题Agent 在顶层跑那些复杂任务的时候谁来兜底上下文溢出了怎么办执行到第 30 步突然忘了前面的约定怎么办工具调用超时了怎么降级这些不是分层能解决的它们属于 Harness 的另外几个维度——上下文管理、错误恢复、状态持久化。分层只是告诉 Agent 做什么但 Harness 还得管住 Agent 怎么做以及做砸了怎么兜。所以分层只是 Harness 的一个切面远不是全部。四、当人类不再写代码OpenAI 的一次激进实验说完了分层的思路和它的局限我们来看一个更具体的案例。OpenAI 在 2026 年 2 月公开了一项实验算是目前 Harness 实践中最激进的样本。他们的团队做了一件听起来很疯狂的事「用 Codex Agent 从零构建一个软件产品五个月交付上线约一百万行代码——工程师被禁止直接写代码。」不是大部分 AI 生成而是从第一个 git commit 开始应用逻辑、测试、CI 配置、API 文档——全部由 Agent 自主产出。结果呢3 人团队后扩展至 7 人合并了 1,500 个 PR效率大约是传统开发的 10 倍。他们把这种新的工作方式叫做「Harness Engineering」。这里面最值得注意的不是效率数字而是「工程师角色的根本性转变」「传统模式」工程师是实现者Implementer直接操作代码细节「Harness 模式」工程师是环境设计师Environment Designer核心工作是构建让 Agent 有效工作的脚手架和反馈循环OpenAI 把这个演进总结为三个阶段「Prompt Engineering → Context Engineering → Harness Engineering」。从如何跟模型对话到如何给模型投喂背景知识再到如何构建一个让模型持续可靠工作的系统。他们踩过的坑也很有启发「第一个坑AI 废料AI Slop。」没有约束的 Agent 会以机器速度全天候生成垃圾代码。最初团队每周要花 20% 的时间清理AI 废料。后来他们把团队的编码标准直接写进 Harness——通过自动化的 Linter、架构约束测试和黄金原则检查在 CI 阶段就拦截不合格的代码。「第二个坑代码漂移。」Agent 高速生成代码系统很快就会偏离最初的架构设计。他们的解决方案是建立垃圾回收机制——定期运行专门的重构 Agent 扫描代码库中的偏离项自动发起修复 PR。这就像内存的 GC 一样对抗系统熵增。「第三个坑隐性知识丢失。」Agent 不像人类同事它无法自主学习团队的品味。解决方案是「知识外化」——把所有关于什么是好代码的判断标准、架构约束、审美偏好显式地转化为机器可读的规则。这些实践揭示了 Harness 的另一个核心职能「它不仅管理 Agent 怎么跑还管理 Agent 产出的质量怎么收。」五、沉淀与撕毁前面聊分层的时候提到了沉淀。这个思路本身没问题——把 Agent 探索出的成熟模式逐步固化为 Skill 和 Script确实能降低成本、提升稳定性。以 AI 辅助代码审查为例。一开始什么都交给 Agent 做成本高、速度慢。跑了一段时间后你发现 Agent 反复在做一些类似的检查——命名规范、错误处理完整性、接口参数验证。于是把这些模式提炼成 Skill。再进一步你发现 Skill 里面函数超过 80 行报警、import 没分组提示这类判断根本不需要 AI纯脚本就能搞定。于是固化为 Script。整个系统越跑越快、越跑越便宜。这是沉淀的价值。「但问题是这个循环不能只往一个方向转。」除了沉淀你还需要准备好撕毁。当新的模型版本发布当业务场景发生变化你之前固化的那些 Script 和 Skill 可能不再是最优解。这时候不是修修补补的问题而是可能需要直接删掉一层让 Agent 用新的能力重新来过。这就形成了一个更完整的循环Agent 探索 → 发现模式 → 沉淀为 Skill/Script ↑ | | ↓ 模型能力升级 持续运行、降低成本 ↑ | | ↓ 撕毁旧的固化逻辑 ←← 边界被打破 / 更优解出现「好的 Harness 设计不仅要让系统能沉淀还要让系统能优雅地遗忘。」每一层都应该是可热插拔的撕毁一个 Skill 不应该导致整个系统崩溃。六、几点不太一样的看法聊了这么多说几个我自己的判断不一定对但觉得值得讨论。省钱不是目的数据飞轮才是很多人讨论 Harness 时关注点在节省 token 成本。没错但这不是最重要的。Phil Schmid 指出了一个更深层的价值「Harness 捕获的轨迹数据是训练下一代模型的关键资产。」Agent 在第 50 步开始偏离指令在第 80 步走进死胡同——这些失败案例如果被结构化地记录下来就是改进模型的最佳训练素材。「好的 Harness 不只是消费模型能力它还在生产模型训练数据。」Agent 用得越多Harness 捕获的数据越多模型改进得越快Agent 做得越好。省钱只是副产品这个飞轮才是真正的竞争壁垒。验证比生成更值钱OpenAI 的实验揭示了一个转变当代码生成成本趋近于零时「价值锚点从写出正确的代码转向定义什么是正确和高效验证产出。」对应到 Harness 设计上Script 层的重点不该是替代 Agent 生成内容而是快速验证 Agent 生成的内容是否合格。Linter、测试、架构约束检查、格式校验——这些确定性的验证逻辑才是 Script 层该干的活。这和朴素的能脚本做的就不用 Agent有微妙区别。不是让脚本替代 Agent而是让脚本守住 Agent 的输出底线。两者是配合关系不是替代关系。敬畏变化苦涩的教训在 Agent 领域大概率会重演。今天精心设计的三层架构明年可能被一个能力更强的模型直接碾平。Harness 太重、太刚性反而会成为适应新模型的障碍。所以我的建议是「沉淀时保持轻量固化时留好接口随时准备把智能还给 Agent。」好的 Harness不是把 Agent 的工作抢过来自己做而是在 Agent 需要的时候提供支撑不需要的时候退到一边去。工程纪律是前置条件OpenAI 的实验还有一个反直觉的发现「在 Agent-First 的世界里传统软件工程的纪律不仅没过时反而变得前所未有地重要。」缺乏文档、测试或架构约束的代价被 Agent 无限放大了——因为 Agent 会以机器的速度全天候重复相同的错误。一个 Agent 可以在一天内产出 100 个 PR如果没有自动化的质量门禁你需要多少人来审查Harness 说到底不是什么高深的 AI 架构它首先是「把好的软件工程实践真正落地」——清晰的架构文档、完善的测试覆盖、自动化的 CI/CD、可观测的运行时监控。这些在人类写代码时代是应该做但经常偷懒的事情在 Agent 时代变成了不做就出事的事情。七、写在最后Agent Harness 到底是一个新概念还是旧概念的新包装老实说两者都有。上下文管理、状态持久化、错误重试、任务分层——这些在分布式系统、微服务架构、DevOps 领域都有成熟的实践。Agent Harness 并没有发明什么全新的东西。但它确实在一个新的维度上重新组合了这些旧概念「模型是不确定的。」传统软件的每一行代码都是确定的你调一个函数返回值是可预测的。但 Agent 不是。它的每一次推理都可能给出不同的结果它会遗忘、会走神、会犯懒。这种不确定性要求我们在传统工程纪律之上再加一层——不仅要管代码怎么跑还要管智能怎么用。这就是 Harness 的独特价值。「2026 年的竞争不再是谁的模型更强而是谁的 Harness 更稳。」当所有人都能调用同一个顶级模型时真正拉开差距的是你的上下文管理有多精细错误恢复有多靠谱质量门禁有多自动化数据飞轮转得有多快。模型是大家共享的弹药Harness 才是你自己的阵地。