---
{
  "series": "Harness工程研究：让AI Agent好用的工程实践",
  "article_index": 1,
  "topic": "Harness比模型重要：为什么你该在运行环境上投入更多",
  "created": "2026-04-25",
  "deai_score": 85.0,
  "pipeline": "series"
}
---

目前的 AI 开发界正在陷入一种集体性质的模型依赖幻觉：当复杂的代码迁移任务在 Agent 手中卡壳，开发者的第一反应通常是检查底层模型是否切换到了最新的旗舰版，或者在 System Prompt 里堆砌带有情绪色彩的强调词。

这种路径选择反映了当下 AI 工程界的一种潜意识：模型能力就是全部的生产力。

近期多个 SWE-bench 风格的编程能力评测正在挑战这种直觉。在一些公开排行榜上，有团队在模型参数完全没有变动、甚至没有调整 Prompt 的前提下，仅仅通过引入一套严密的任务边界定义和实时异常捕获机制，成绩就出现了大幅跃升。这种提升指向了一个被长期忽视的变量：Harness（运行环境工程）。

Agent 的最终表现由模型能力和运行环境共同决定。目前的竞争焦点正在从追求更强的模型转向对运行环境的精细化治理。

## 意图模糊背后的执行权力真空

工程师在调研 AI 开发工具时，往往会陷入一种周期性的挫败。这种疲劳感的来源在于：人类在试图规避规范化定义的繁琐过程时，将过度且模糊的自主权让渡给了 AI。

目前真实的瓶颈在于缺乏约束导致的 Specification Gap。很多团队习惯假设模型具备"心领神会"的智力，能够捕捉那些甚至还未在开发者脑中成型的构思。现实情况是，在一个没有任何硬性约束、缺乏实时反馈的环境中，即使是最强的模型也会频繁撞墙，并在 Context Window 中留下大量自我纠错的无效噪音。

模型幻觉在工程实践中往往可以追溯到具体的权限缺失。模型无法给出正确答案，是因为程序没有向 AI 开放查看控制台、读取日志或实时访问受限文件系统的底层权限。模型看不到报错信息、读不到运行状态，只能靠猜。

一份结构清晰的 CLAUDE.md 或者项目准则定义，对最终交付质量的拉动作用已经超过了模型之间那百分之几的 Benchmark 差异。准则的作用是建立执行边界，明确模型在什么时候必须停下来请求权限，以及在什么路径下可以进行破坏性的修改。

## 确定性反馈的纠偏效果

OpenAI 的内部工程实践提供了一个具体的参考坐标。根据其公开披露的信息，他们在几个月内利用一套高度机械化的执行环境生成了约 100 万行代码，平均每位工程师每天交付的 PR 数量达到了 3.5 个。

这种高频产出建立在仓库原生知识（Repository Knowledge）、自动化执行链路和强反馈路径的基础之上。当模型被置于一个具备强制性校验机制的管道中时，效率才会发生质变。

当模型输出的每一行代码都被硬性要求通过 Linter 检查、类型系统校验和 CI 测试时，这些信号是二进制的、不可商榷的。这种确定的负向反馈对 Agent 的逻辑具备极强的纠偏效果。

观察目前市场上失败的 Agent 项目，大部分都折在完成写操作后的验证环节。由于缺乏自我验证的循环，模型在写完代码后只能通过文字描述来猜测代码是否能跑通。

Anthropic 在 SWE-bench 上的实验数据佐证了这一点：在任务难度恒定的情况下，维持模型不变，仅仅引入"执行并根据报错信息自动重试"的简单逻辑，解题成功率就从 52.8% 跃升到了 66.5%。报错信息、测试用例和沙箱权限这些确定性工具，为大模型的随机性提供了硬性支撑。当约束被硬编码进环境，模型的智力才会被放大。

## 模型越强，Harness 越需要进化

一个容易被忽视的现象是：Harness 的复杂度并不随着底层模型能力的提升而线性增长。

在早期的弱推理模型时代，开发者需要构建极其复杂的脚手架（Scaffolding）来防止模型跑偏，甚至需要规划每一个微小的步骤。而进化到如今具备原生复杂推理能力的前沿模型时，这种过度的工程设计反而会成为干扰。一个具备高度推理能力的模型，在过细的流程约束下会表现出过度服从的僵化。

这种演进趋势导致了 Harness 的重心发生位移。相比在表面铺设密集的脚手架，在深度上强化 OS 级的沙箱约束更有效。

当模型变得更强大，它在错误路径上的惯性也会更强。大模型可能会在几秒钟内递归式地清空整个测试环境，因为它认为这样可以提升任务效率。Claude Code 的实践表明，在引入了精细的沙箱权限确认机制后，虽然人工确认的环节增加了，但误操作导致的系统崩溃频率大幅下降（具体数据将在本系列第三篇中详述）。

模型能力的更迭速度极快，但回归测试套件、评估体系以及这些自动化的基础设施，其价值是具备持久性的长资产。

## 从这里开始

投资 Harness 的本质是在充满不确定性的 AI 交互中锚定确定性。如果一个团队至今还没有建立一份基本的 CLAUDE.md 或者项目开发规范文件，那么任何关于 Agent 孰优孰劣的讨论都缺乏根基。

具体的下一步建议：

- 为项目从零开始建立一系列简单的原则定义文本文件（例如以 CLAUDE.md 作为起始入口），清晰界定模型可以做什么、不可以做什么，以及遇到哪些情况必须停下来问人
- 配置一套能在每次 Agent 提交后自动运行的测试沙箱，哪怕只覆盖核心路径
- 在 CI 中接入 Linter 和类型检查，让报错信息自动回传给 Agent 作为重试依据

这些改动的成本很低，但它们建立的反馈回路是持久的。确定的产出来自本地的执行环路，而不是云端的参数升级。

这只是起点。Harness 还有两个核心维度需要深入讨论：Context 的精细化治理，以及约束机制的设计。下一篇《Context是稀缺资源》将展开第一个维度。