模型-Harness 共进化 —— 薄 vs 厚的终极辩论与未来展望

一、场景切入：两条路线的正面碰撞

2026 年春天，AI 工程社区围绕一个问题分裂成了两个阵营：模型越来越强，Harness 还重要吗？

一边是 Anthropic。Claude Code 的创造者 Boris Cherny 在 Sequoia AI Ascent 2026 上说："随着模型变得更强，Harness 的重要性在下降。"他在 Y Combinator Lightcone 播客中进一步解释：你可以围绕模型搭建脚手架来提升 10%-20% 的性能，但"这个增益在下一次模型升级时基本就被抹平了。所以你要么不断重建脚手架，要么等下一个模型直接白拿这个提升。"Cherny 的团队甚至把 Richard Sutton 的《苦涩的教训》挂在工位旁边，作为指导原则：永远押注模型的通用能力，而非特定场景的临时脚手架。

另一边是 LangChain。2026 年 2 月，LangChain 工程师 Vivek Trivedy 发表了一篇博客，标题直截了当：他们的编程 Agent deepagents-cli 在 TerminalBench 2.0 上"从 Top 30 跃升至 Top 5。我们只改了 Harness。"模型全程固定为 gpt-5.2-codex，得分从 52.8% 提升到 66.5%——13.7 个百分点的提升，完全来自 Harness 层的改动。Trivedy 的总结凝练了 Harness 派的核心理念："Harness 的目标是把模型内在的、参差不齐的智能塑造成我们关心的任务所需的形状。"

LlamaIndex 的联合创始人 Jerry Liu 在 2026 年 4 月的 X 帖子中提出了更为激进的"大 Harness 论"：模型是"白板"，AI 价值的最大障碍是用户自己工程化上下文和工作流的能力。复杂业务流程需要复杂的 Harness 设计。

这两条路线的碰撞引出了本系列 17 篇文章积累的核心张力：如果你不是模型，你就是 Harness——但如果模型什么都能做，Harness 还有意义吗？

二、社区大辩论：模型派 vs Harness 派

2.1 模型派：Harness 的价值会被稀释

模型派的核心论点很简单：模型能力在快速提升，今天需要的 Harness 复杂性，明天会被模型"原生"处理。

Cherny 的立场最为鲜明。在 Every.to 播客（2025 年 10 月）中，他说 Claude Code 是"模型外面最薄的包装"，而"曾经是脚手架的东西……会被推进模型本身"。他的团队构建 Harness 功能时就预期要删除它："我们构建大部分东西……即使这意味着三个月后必须把它删掉。如果有任何区别的话，我们希望三个月后就能删掉它。"在 Sequoia 的演讲中，他甚至预测："一年后 Claude Code 本身可能只有 100 行代码。"

Claude Code 产品负责人 Cat Wu 的表述更生动："模型会把你的 Harness 当早餐吃掉。"她的团队在每次新模型发布时都会审查整个系统提示词，删除新模型已经能原生处理的部分。

数据似乎支持这一立场。Anthropic 2025 年 2 月发布 Claude 3.7 Sonnet 时，在 SWE-bench Verified 上使用了"最小脚手架"——仅提供 bash 工具和文件编辑工具，不使用复杂的编排逻辑。结果是：Claude 3.7 Sonnet 在无特殊脚手架的情况下达到 63.7%，而 Claude 3.5 Sonnet 约为 49.0%——约 14.7 个百分点的提升，完全来自模型本身的能力进步，与 Harness 优化无关。

OpenAI 的 Noam Brown 从另一个角度支持了这一立场。在 No Priors 播客中，他指出"模型的能力现在是你投入多少钱的函数"——给 10,000 美元预算的模型远比给 10 美元的强。他同时警告：脚手架可以轻易推高 Benchmark 分数（比如跑五次取最优），但"一旦你控制了测试时计算量，这些看起来更好的东西实际上并没有更好"。Brown 在 ICML 2026（2026 年 7 月）上进一步指出，下一个飞跃是"操作视野"——从完成响应到拥有项目，模型将能自主工作数小时到数周。

METR 的研究提供了更微妙的视角。他们的评估指南明确承认"后训练增强（系统提示调优、脚手架设计）可以使性能产生与从 GPT-3.5 Turbo 到 GPT-4 相当的偏移"。但在实际评估 OpenAI GPT-5.1-Codex-Max 时，METR 发现 OpenAI 自己的 Codex 脚手架在他们的一线测试集上表现反而比 METR 的默认脚手架更差。这说明脚手架的效果是高度任务依赖的，不是通用乘数。

2.2 Harness 派：数据不会说谎

Harness 派的回应同样有力：在固定模型的前提下，Harness 优化带来的提升是真实且显著的。

LangChain 的 TerminalBench 2.0 数据是最直接的证据。固定模型为 gpt-5.2-codex，通过四项 Harness 改动——Plan-Build-Verify-Fix 强制闭环、环境上下文注入、死循环检测、推理三明治策略——得分从 52.8% 提升到 66.5%，排名从 Top 30 以外冲进 Top 5。约 25 个排名位置的跨越，全部来自 Harness 层。

TerminalBench 2.1 排行榜（2026 年 6 月）提供了更多同模型不同 Harness 的对比数据。同一个 GPT-5.5 模型，在 Codex CLI 的 Harness 中得分 83.4%，在 Terminus 2 的 Harness 中得分 78.2%——5.2 个百分点的差距，完全归因于 Harness 工程。正如分析者所言："模型是相同的；Harness 工程解释了这个差距。"

本系列第 17 篇引用的 Meta-Harness 研究进一步量化了这一点：仅改变 Harness 层（不做任何模型修改），同一 Benchmark 上的性能差距可达 6 倍。

2.3 两派都在说真话

关键洞察是：这两派并不矛盾，它们描述的是不同时间尺度和不同任务复杂度下的不同真理。

模型派看到的是趋势线：从 Claude 3.5 到 3.7 再到 Opus 5，模型原生能力在快速逼近需要 Harness 辅助的水平。Harness 派看到的是横截面：在今天的任何一个时间点，固定模型后改变 Harness，效果差异显著。两者都是事实——区别在于一个是纵向比较（跨时间），一个是横向比较（同一时间点）。

三、时间尺度决定论：不是非此即彼

与其争论谁对谁错，不如问一个更务实的问题：在什么条件下，哪种策略更优？

答案是任务复杂度和持续时间的函数：

短期 / 简单任务（<10 步，<30 分钟）：大模型胜出。模型的推理能力足以覆盖短任务的全部需求，薄 Harness 甚至"哑循环"（dumb loop）就够了——组装 Prompt、调用模型、执行工具调用、重复。Anthropic 的 Claude Agent SDK 就是这种设计：模型决定一切，Harness 只做最基本的循环。

中期 / 中等任务（10-50 步，小时级）：模型 + Harness 共同决定。这个区间是 Harness 工程的主战场。LangChain 的 TerminalBench 数据就落在这里——13.7 个百分点的提升来自死循环检测、环境上下文注入、推理三明治等中等复杂度的 Harness 优化。

长期 / 复杂项目（50+ 步，天级，跨会话）：厚 Harness 不可或缺。Stripe Minions 每周 1,300 个 PR 的运作需要五层管道架构、Devbox 标准化环境、Blueprint 混合编排、CI 循环自动修复——这些是任何模型都无法"原生"处理的系统级约束。

用一个比喻：让一匹好马跑 100 米不需要缰绳；拉货跑 100 公里穿越山路，没有缰绳不行。 模型派看到的是赛马场上的 100 米冲刺——模型一骑绝尘；Harness 派看到的是 100 公里的山地越野——没有装备和路线规划，再好的马也会迷路。

METR 的"时间视野"研究为这个框架提供了量化支撑。他们发现前沿 AI 的 50% 任务完成时间视野自 2019 年以来大约每 7 个月翻倍，而 Claude 3.7 Sonnet 的时间视野约为 50 分钟。这意味着：在当前模型能力下，低于 50 分钟的任务模型基本能独立完成，超过这个阈值就需要 Harness 的检查点、恢复机制和跨会话记忆来延伸有效工作时间。

后端类比：薄 vs 厚 Harness 的辩论 ≈ 轻量级框架 vs 重量级框架的永恒辩论。就像 Spring Boot Starter 和 Micronaut 的选择不是"谁更好"而是"什么场景下合适"——快速原型用薄框架，企业级生产用厚框架。Agent 工程同样如此：任务复杂度和持续时间决定 Harness 厚度，不存在一刀切的最优解。两者的"为什么需要它"（复杂度需求不同）和"它如何工作"（按需选择工具集大小）完全一致。

四、脚手架原则：为移除而构建

如果时间尺度决定论告诉我们"不同场景需要不同厚度的 Harness"，那一个更深的问题出现了：今天搭建的 Harness，明天该怎么办？

答案是 2026 年 AI 工程社区逐渐形成的共识——脚手架原则：为移除而构建（Build to Remove）。

4.1 核心思想：Harness 是临时基础设施

OpenAI Codex 工程负责人 Thibault Sottiaux 在 2026 年 2 月的 Dev Interrupted 播客中把这个理念讲得最透彻。他将 Harness 描述为"临时基础设施，目标是随着时间推移逐步移除"。Sottiaux 警告了一个他称之为"能力悬崖"（capability overhang）的反模式：当 Harness 过度约束时，即使模型能力跳升了，也无法表达新能力——因为脚手架把它框死了。

他的核心论点被中文媒体精炼为："脚手架是拐杖，不是翅膀。" 你给模型搭临时支撑，目标是随着模型能力增强逐步拆除，让模型独立站立。但很多团队走向了反方向——把脚手架当喷气背包，不断往里塞工具、塞逻辑、塞规则，系统越来越重。

4.2 实证：Manus 和 Anthropic 的"减法"

这个原则不是理论推演，而是来自一线实践。

Manus 是 2025 年最受关注的 Agent 产品之一。其联合创始人 Yichao "Peak" Ji 在 2025 年 7 月的博客中写道："上下文工程完全不是简单的事。它是一门实验科学——我们已经重建了四次 Agent 框架，每次都是在发现更好的上下文塑造方式之后。"到 2025 年 10 月，在一个公开网络研讨会上，Peak 透露 Manus 自 3 月发布以来已经重构了五次。Peak 引用 Hyung Won Chung 的观点来总结这个原则："为当前水平的算力和数据添加所需的结构。之后移除它们，因为这些捷径会成为进一步提升的瓶颈。"

Peak 还用一个比喻浓缩了整个理念："如果模型进步是涨潮，我们要让 Manus 成为船，而不是钉在海床上的柱子。"

Anthropic 的实践更为系统化。2026 年 7 月，Anthropic 工程师 Thariq Shihipar 在官方博客中披露："我们为 Claude Opus 5 和 Claude Fable 5 删除了 Claude Code 超过 80% 的系统提示词，在我们的编码评估上没有可测量的损失。"他直言团队发现自己在"过度约束"模型——许多约束曾经是必需的，但新模型"有更好的判断力，可以在没有明确规则的情况下处理这些决策"。

被删除的内容包括一条具体的规划指令——旧系统提示要求"除非用户要求，否则不要创建规划、决策或分析文档"。新系统提示改为更简洁的判断式指引："写与周围代码风格匹配的代码。"这不是放宽标准，而是信任模型自己判断何时需要规划。

Cherny 在 Y Combinator 播客中描述了他们的审计方法："你删掉整个系统提示词，然后逐行加回来，搞清楚每一行的具体影响。"结果令人惊讶："有趣的是，没有这些提示词，模型实际上更聪明了一点。"他给用户的建议是："每六个月删掉你的 Claude MD，删掉你的 Skills，删掉你的 Hooks，看看模型会做什么。"

独立测量佐证了这一趋势。开发者 Chen Cheng 捕获了不同模型版本下 Claude Code 的系统提示词长度：Opus 4.7 约 15,225 字符，Opus 4.8 降至约 4,467 字符（约 70% 削减），Opus 5 回升至约 7,694 字符（添加了针对性指引，但仍比 4.7 短约 50%）。

4.3 脚手架债务：一个新概念

Aman Bhandari 在 2026 年 4 月提出了"脚手架债务"（scaffolding debt）的概念，精确描述了不遵循"为移除而构建"的后果："这是为昨天的模型写的规则，今天仍然作为承重基础设施存在。它是提示词工程版本的遗留代码——每个人都不敢删，因为没人记得当初为什么写的。"

Bhandari 借鉴了编译器工程的经验：编译器工程师知道，每个优化提示或类型标注都是对编译器当前局限性的押注。一个有纪律的工程师会在编译器改进后重新审视这些提示。Agent Harness 工程同理。

未来验证测试：当你替换更强的模型后，如果性能提升且不需要增加 Harness 复杂性——你的 Harness 设计是合理的。如果换了更强模型后性能反而下降，说明你的 Harness 与特定模型"共进化"了（过拟合）。Cherny 的做法——"删掉整个系统提示词，逐行加回来"——本质上就是一个极端版本的过拟合检测。

后端类比：脚手架原则 ≈ 技术债管理。就像后端团队引入抽象层时需要定期评估"这个抽象还有必要吗"，Harness 工程师需要定期评估"这个脚手架组件还有必要吗"。两者的"为什么需要它"（临时解决方案随系统演进而失去价值）和"它如何工作"（定期审计 → 移除冗余 → 验证无退化）完全一致。关键区别：传统技术债的"债权人"是代码可维护性，脚手架债的"债权人"是模型能力进步——后者变化更快，债务积累更快。

五、模型-Harness 共进化挑战

"为移除而构建"听起来很优雅，但实践中面临一个根本性的工程挑战：模型和 Harness 不是独立演化的，它们在共进化。

5.1 什么是共进化

模型在训练时"见过"某些 Harness 模式——特定的 Prompt 结构、特定的工具调用格式、特定的推理链模板。这导致模型对这些 Harness 模式形成了"偏好"：在"见过"的 Harness 上表现好，在"没见过"的 Harness 上表现差——即使后者在理论上更优。

2026 年 7 月，香港大学和中国移动的联合论文 HASE（Harness-Aware Self-Evolving，arXiv:2607.03935）正式定义了这个问题："自进化框架通常优化任务解决方案，同时将周围的 Harness 视为固定不变……但这个 Harness 与模型本身同等重要——它决定了模型观察到什么、哪些动作可用、以及候选方案如何评分。"论文的核心贡献是让模型权重、Harness 代码和任务解决方案三者协同进化。

一篇 2025 年 10 月的论文（"Prompting Inversion"，arXiv:2510.22251）从实证角度佐证了这一现象：复杂的约束式 Prompt 对弱模型更有帮助（在 GPT-4o 上达到 97% 准确率 vs 标准 CoT 的 93%），但对强模型的边际收益递减。这意味着"模型变强后 Harness 重要性下降"这一趋势确实存在，但下降速度取决于模型在训练时见过多少 Harness 模式。

5.2 被折叠进训练的 Harness

更深层的变化正在发生：Harness 正在被折叠进模型的训练过程本身。 前沿模型已经开始在 post-training 阶段对自己的 Harness 模式做训练——模型不仅学会了使用工具，还学会了"理解"特定工具调用的失败模式、特定 Prompt 结构的含义。Xiaomi 的 HarnessX 系统通过"跨 Harness GRPO"（在不同 Harness 版本间汇聚 Agent 执行轨迹进行微调），让底层模型内化高层策略转变，而非仅仅记忆特定 Harness 的模式。

这带来了一个微妙但重要的后果：

这解释了为什么薄派和厚派都在说真话：薄派看到的是"模型变强 → Harness 可减薄"的趋势线（阶段 1→2）；厚派看到的是"今天换一个 Harness，即使理论更优，实际可能更差"的事实（阶段 3→4）。两者描述的是模型-Harness 共进化的不同阶段。

METR 的数据提供了间接证据：他们发现 OpenAI 自己的 Codex 脚手架在 METR 的一线任务集上表现反而比 METR 的默认脚手架更差。这不是因为 Codex 脚手架设计得差，而是因为它"为略微不同的工作流而设计"——模型在不同脚手架上的表现取决于训练时的匹配度。

5.3 对工程师的启示

共进化挑战给工程师的实际启示是：选择 Harness 时要考虑"这个 Harness 是否与特定模型绑定"。

如果你选择了一个高度依赖某模型特定行为的 Harness（比如利用了某模型对特定 Prompt 格式的偏好），当模型升级时你可能面临两个风险：一是旧 Harness 组件变成了死代码（模型不再需要它），二是旧组件可能反而阻碍新模型（能力悬崖）。

实践建议是 Cherny 的审计方法——定期删除和逐行加回：每当你升级模型时，先删掉所有非安全相关的 Harness 组件，跑一遍评估，然后逐个加回，只保留确实带来正向贡献的组件。这个过程虽然耗时，但能确保你的 Harness 不会积累脚手架债。

后端类比：模型-Harness 共进化 ≈ 框架与语言的耦合。Rails 与 Ruby 深度耦合——Rails 利用了很多 Ruby 的元编程特性，你很难把 Rails 移植到 Python 上而不损失功能。同理，特定 Harness 利用模型的特定行为模式，两者共进化后迁移成本很高。两者的"为什么需要它"（深层 API 级耦合导致迁移困难）和"它如何工作"（一方变化需要另一方同步适配）一致。关键区别：语言-框架耦合是双向设计选择，模型-Harness 耦合更多是训练数据的副产品——工程师可以主动选择"不绑定特定模型"的 Harness 设计。

六、工程师价值的重新定义

本系列开篇（第 1 篇）引用了那句在 2026 年 AI 工程社区广为流传的话："如果你不是模型，你就是 Harness。"经过 17 篇的深度拆解，我们现在可以回答：那 Engineer 又是什么？

答案是分阶段的：

OpenAI 工程师 Ryan Lopopolo 在 2026 年 2 月的博客"Harness Engineering: Leveraging Codex in an Agent-First World"中记录了一个极端实验：3 名工程师在 5 个月内构建了一个约 100 万行代码的产品，0 行人工编写代码。他的关键发现不是"Agent 能写代码"，而是"人工不写代码引入了一种不同类型的工程工作——专注于系统、脚手架和杠杆效应"。他写道："Agent 缺乏推进高层次目标所需的工具、抽象和内部结构。我们工程团队的主要工作变成了让 Agent 能做有用的工作。"

Lopopolo 用一句话总结了新的工程哲学："人类掌舵，Agent 执行。"

这个转变与后端工程师熟悉的演进完全平行。从"手写每一行代码"到"设计让 Agent 可靠运行的环境"，本质上是从"开发工程师"到"平台工程师"的自然延伸。后端工程师一直在做"让不可靠组件可靠运行"——数据库主从切换、消息队列重试、缓存雪崩防护。Harness 工程只是把这个能力从"基础设施层"延伸到"模型层"。

未来的工程师价值不在于写更多代码，而在于知道在什么场景下用多厚的 Harness，以及何时该移除它。这需要的不是编码能力，而是系统判断力——这正是后端架构师的核心竞争力。

七、AI 工程三层演进的未来展望

把视野拉到更宏观的层面，AI 工程正在经历一个与云计算惊人相似的三层演进：

模型层正在快速收敛。METR 的数据显示前沿 AI 的时间视野大约每 7 个月翻倍，几大厂商的模型能力差距在缩小。这就像云计算早期 IaaS 层的竞争——最终会变成基础设施，差异化转向上层。

Harness 层是当前的主战场。从本系列 18 篇文章的拆解可以看出，Harness 工程的差异化空间巨大：循环架构（Loop / Graph / Microkernel / MultiAgent 四种模式）、记忆设计（三层架构 + 8 级优先级）、工具系统（从 Function Calling 到 MCP）、评估体系（Benchmark + Evals + 持续优化闭环）、运维（部署 + 多租户 + 成本管理）——每一个维度都有大量工程设计空间。这对应 PaaS 层的竞争——Heroku vs App Engine vs Elastic Beanstalk，各家通过运行时抽象和开发者体验竞争。

应用层将看到 Harness 能力变成"隐形基础设施"。就像今天的 SaaS 开发者不需要关心服务器配置和负载均衡，未来的 Agent 应用开发者将不需要关心 Agent Loop 的实现细节、记忆管理的压缩策略、工具调用的沙箱隔离——这些都会被 Harness 平台抽象掉。应用开发者专注于业务逻辑。Stripe Minions 已经展示了这个趋势——他们的工程师专注于 Blueprint 设计和 CI 循环优化，而非 Agent Loop 的底层实现。

后端类比：AI 工程三层演进 ≈ 云计算三层演进（IaaS → PaaS → SaaS）。两者的"为什么需要它"（分层抽象让上层专注业务逻辑）和"它如何工作"（底层逐渐商品化，中层成为竞争焦点，上层最终受益于下层抽象）完全一致。关键启示：后端工程师在 IaaS→PaaS→SaaS 演进中积累的"什么时候自建、什么时候用平台、什么时候用成品"的判断力，可以直接迁移到 AI 工程的模型层→Harness 层→应用层的选型决策。

八、给后端工程师的行动建议

理论讲够了，最后给出落地指南——按投入时间从短到长排列：

今天就能做（< 1 天）

1. 在项目里写 AGENTS.md（不是 README，不是百科全书，是一张"地图"）。告诉 Agent：项目结构、关键约束、禁止事项。参考 Claude Code 的 CLAUDE.md 设计理念——每次会话自动注入，就像环境变量。
2. 把反复出现的 Code Review 意见变成 Linter 规则。如果你发现自己在 Review 中反复说"不要在循环里创建数据库连接"，那就把它编码成 ArchUnit 规则或自定义 Lint 检查。约束代码化是 Harness 的第一步。

一周内能做（< 1 周）

1. 给 AI 工具加"完成前必须验证"的规则。在系统提示里加一条："在声称完成之前，必须运行测试并确认通过。"这是第 13 篇讲的 Plan-Build-Verify-Fix 闭环的最小实现。
2. 建立进度追踪文件（progress.md）。让 Agent 在每次会话结束时写入当前进度、下一步计划、遇到的问题。下次会话开始时读取这个文件，实现跨会话连续性。

需要投入时间（1-2 个月）

1. 让日志和指标对 Agent 可查。在第 14 篇讲过"可观测性注入"——给 Agent 工具列表加一个 search_logs 工具，让 Agent 能像运维工程师一样"看监控"来定位问题。
2. 定期跑"清洁 Agent"任务。每周一次，让 Agent 检查文档与代码的一致性、删除无用依赖、更新过时的 API 调用。这是第 2 篇讲的"Garbage Collection"运维的落地。

长期关注

1. Meta-Harness 研究进展。第 17 篇拆解的自动优化 Harness 方向正在快速发展，LangSmith Engine 已经将学术研究产品化。
2. 模型-Harness 共进化的最佳实践。关注 Anthropic 和 LangChain 的工程博客——前者代表"减法"实践，后者代表"加法"实践，两者都是必要的参考。
3. Agent 工程的标准化。关注类似 12-Factor App 的"Agent 12-Factor"倡议——Harness 工程正在从"手艺"变成"工程规范"。

九、总结与系列收官

本文核心要点

作为系列收官，本文回答了贯穿全系列 18 篇的终极问题：

一句话总结：薄 Harness 和厚 Harness 不是非此即彼的选择，而是任务复杂度和模型-Harness 共进化阶段的函数。"为移除而构建"是调和框架——今天搭建的 Harness 复杂性应该随模型能力提升而逐步移除。未来工程师的核心价值不是写更多代码，而是知道在什么场景下用多厚的 Harness，以及何时该做减法。

系列回顾

18 篇文章，从认知重构到未来展望，我们构建了完整的 Agent Harness 工程能力体系：

第一阶段（认知重构）：从 Prompt 到 Harness 的三次范式跃迁 → 工程师角色重定义 → Agent Loop 本质 → 工具系统设计 → 记忆架构

第二阶段（架构设计）：四种 Harness 架构对比 → 控制平面与执行平面 → 单 Agent vs 多 Agent

第三阶段（工程实现）：上下文管理 → 验证与修复 → 可观测性 → 评估体系

第四阶段（生产化）：AgentOps 部署运维 → Meta-Harness 自我进化 → 本文：薄 vs 厚的终极辩论

回到开篇的问题

本系列开篇说："如果你不是模型，你就是 Harness。"18 篇之后，我们可以给出更完整的回答：

如果你不是模型，你不仅是 Harness——你更是决定 Harness 厚度、审计 Harness 债务、在模型-Harness 共进化中找到平衡的人。 这个工厂未来还需要吗？需要。但它会变得越来越薄、越来越自动、越来越像"隐形基础设施"——就像你不再关心服务器的负载均衡器，但它一直在那里，默默运行。

这正是后端工程师最擅长的事情：让不可靠的组件可靠运行，让复杂的系统简单使用。Harness 工程不是新技能，是旧技能在新领域的应用。