TL;DR

本文核心观点：

  1. 诚实面对边界 — Harness 工程最宝贵的不是 5个月/100万行代码的数字，而是诚实地记录了什么不起作用、瓶颈在哪里、系统何时失败。
  2. 环境设计是核心 — 人类的工作从”写代码”升级为”设计环境”：深度优先的工作方式、让系统组件对 Agent 可读、地图而非百科全书的知识管理。
  3. Agent 有根本性限制 — 上下文窗口污染、时间盲症（花数小时运行测试而非推进任务）、自我毁灭风险（pkill -9 bash），以及创造性设计、长期架构演进、跨系统协调的根本局限。
  4. 人类角色重新定义 — 不是被取代，而是升级：从执行层到决策层，专注于定义目标、设计验证器、做创造性判断。

诚实的起点

OpenAI 的 Harness 工程文章，最令人印象深刻的地方不是那些惊人的数字：

  • 5 个月
  • 100 万行代码
  • 0 手写

而是诚实地面对限制。

他们没有讲述一个”AI 接管一切”的乌托邦故事。相反，他们详细记录了：

  • 什么不起作用
  • 瓶颈在哪里
  • 系统何时失败

这种诚实是 Harness 工程最宝贵的部分——它不仅展示了可能性，也划定了边界。

在 AI 炒作达到狂热的今天，这种清醒尤为珍贵。

💡 一个观察：过去两年，从 Copilot 到 Devin，从 GPT-4 到 Claude 3.7，每一次发布都伴随着”程序员末日”的论调。但 Harness 工程的实践者告诉我们一个不同的故事——Agent 可以写代码，但不能做设计；可以修复 Bug，但不能判断方向；可以执行任务，但不能定义目标。这不是”AI 还不够好”的暂时性问题，而是根本性的能力边界。

OpenAI 遇到的瓶颈

瓶颈 1：环境 Underspecified

问题：早期进展比预期慢。

诊断：不是 Codex 能力不足，而是 Agent 缺乏完成任务所需的工具、抽象和内部结构。

解决方案：深度优先的工作方式——

关键洞察：在 Harness 工程中，人类的工作是设计环境，而不是编写代码。

瓶颈 2：人类 QA 容量

问题：随着代码吞吐量增加，人类 QA 成为限制因素。

诊断：固定约束是人类的时间和注意力。

解决方案：让更多系统组件对 Agent 可读——

每个 git worktree 有独立的可启动实例，Agent 可以：

  • 自主复现 Bug
  • 验证修复
  • 推理 UI 行为

结果：验证不再是人类的专属职责。

瓶颈 3：上下文管理

问题：大型复杂任务中，Agent 容易迷失方向。

失败的尝试：”One Big AGENTS.md”——试图把所有知识塞进一个巨大文档。

原因：

  • 上下文窗口被挤占
  • 重要约束被淹没
  • 文档迅速腐烂
  • 无法机械化验证

解决方案：地图而非百科全书（详见本系列文章《地图而非百科全书》）。

Carlini 观察到的限制

Anthropic 研究员 Nicholas Carlini 的并行 Agent 实验，揭示了另一组限制。

📌 来源说明：以下案例来自 Carlini 的博客文章《Building a C compiler with a team of parallel Claudes》（2025），是真实实验的一手观察。

Carlini 观察到的限制

限制 1：上下文窗口污染

问题：测试框架输出太多无用信息，挤占了 Agent 的思考空间。

症状：

  • 最多只打印几行输出
  • 重要信息记录到文件
  • 预计算统计摘要

限制 2：时间盲症

问题：Claude 无法感知时间，会花数小时运行测试而非推进任务。

症状：

“Claude 会 happily spend hours running tests instead of making progress.”

限制 3：自我毁灭

问题：Agent 可能意外执行破坏性操作。

真实案例：

“有一次我看到 Claude 意外执行 pkill -9 bash，杀死了自己和整个循环。Whoops!”

应对：

  • 容器化隔离
  • 定期人类检查
  • 从失败中恢复的机制

尚未解决的挑战（作者观点）

⚠️ 声明：以下三个挑战是基于 OpenAI 文章的暗示和业界观察的作者个人归纳，并非经过严格验证的结论。这些判断可能存在争议，欢迎讨论。

挑战 1：创造性设计

Harness 工程在明确目标的任务上表现出色：

  • ✅ 构建编译器
  • ✅ 实现功能
  • ✅ 修复 Bug

但在需要创造性设计的场景，Agent 的能力明显受限：

  • ❌ 全新产品的概念设计
  • ❌ 用户体验的创新
  • ❌ 商业模式的探索

💡 Key Insight

Harness 工程能可靠地执行已知路径的任务（构建、修复、实现），但无法代替人类走未知路径——这不是模型能力的问题，而是目标定义本身需要人类判断。

为什么（作者推测）：这些活动可能需要：

  • 模糊目标的导航
  • 跨领域知识的创造性组合
  • 对用户需求的主观理解
  • 审美判断

💡 反方观点：也有研究者认为，当前模型在 UI 设计、创意文案等领域已有相当表现。这个判断是否正确，可能需要更多实证研究来验证。

挑战 2：长期架构演进

当系统需要根本性重构时：

  • 技术栈迁移
  • 架构范式转变
  • 大规模数据模型变更

当前 Agent 的能力：

  • ✅ 增量改进
  • ❌ 全局重构（作者观察）

为什么（作者推测）：

  • 需要跨越多个季度的规划
  • 涉及复杂的权衡取舍
  • 需要人类架构师的判断

挑战 3：跨系统协调

当变更涉及多个独立系统、团队或组织边界时：

  • 需要复杂的利益相关者管理
  • 涉及非技术因素（政治、文化、合规）
  • 需要权衡无法量化的因素

这些场景可能超出了当前 Agent 的能力边界。

承认边界不是失败

重要的是理解：承认限制不是对 Harness 工程的否定。

相反，诚实地划定边界，让我们能够：

  1. 正确设定期望
    • 知道什么该用 Agent
    • 知道什么该用人
  2. 聚焦改进方向
    • 明确当前系统的短板在哪里
    • 有针对性地研究
  3. 避免过度承诺
    • 防止”AI 万能”叙事后的失望反弹

OpenAI 和 Carlini 的诚实，恰恰证明了 Harness 工程的成熟度——它不是实验室玩具，而是经过实战检验的工程方法，其倡导者清楚知道它能做什么、不能做什么。

人类角色的重新定义

面对这些限制，人类的角色不是被”取代”，而是被重新定义：

传统角色 Harness 工程角色
编写代码 设计环境——让 Agent 能可靠工作
调试程序 调试约束——修复反馈回路
代码审查 设计验证器——定义”正确”的标准
项目管理 系统架构——确保知识正确流动
实现功能 创造性决策——Agent 无法处理的判断

这不是降格，而是升级——从执行层到决策层。

当机器承担了实现层面的工作，人类可以专注于更高层次的思考：

  • 应该构建什么？
  • 为什么这样设计？
  • 如何判断好坏？

未来的研究方向

Harness 工程的边界，指明了未来的研究方向：

方向 核心问题 可能路径
创造性 Agent 如何让 Agent 参与创造性设计？ 探索-利用权衡、人机协同创造
长期规划 如何处理跨越数月的架构演进？ 路线图推理、技术债务管理
社会技术系统 如何在复杂组织环境中运作？ 利益相关者建模、组织政治感知

结尾

经过以上分析，我们可以给出一个更具体的判断框架：

✅ Harness 工程适合的场景

场景特征 示例
目标明确 实现指定功能、修复已知 Bug、构建标准组件
验证标准清晰 有自动化测试、有明确的成功标准
环境可控 代码库结构良好、工具链成熟、文档相对完整
增量式工作 功能迭代、代码重构（非架构迁移）

❌ Harness 工程不适合的场景

场景特征 示例
创造性设计 新产品概念、UX 创新、商业模式探索
长期架构决策 技术栈迁移、大规模重构、跨季度规划
复杂组织协调 多团队协作、利益相关者管理、组织变革
高风险操作 生产环境变更、安全关键系统、合规敏感项目

一个务实的建议

如果你正在考虑引入 Harness 工程，先问自己：

  1. 这个任务的”完成标准”能用自动化测试验证吗？
    • 如果不能，人类 QA 会成为瓶颈
  2. 这个任务的目标在 1-2 周内能保持稳定吗？
    • 如果需求频繁变动，Agent 会反复迷失
  3. 如果 Agent 犯错，能在 10 分钟内发现并回滚吗？
    • 如果不能，风险太高

如果三个问题的答案都是”是”，Harness 工程可能是个好选择。如果有一个”否”，你需要重新设计任务或环境。如果三个都是”否”，这个任务目前还不适合用 Agent。

深度阅读时间：约 8 分钟

Harness 工程最宝贵的贡献，不是展示了”AI 能做什么”，而是诚实地展示了”AI 还不能做什么”。

当我们理解并接受这些边界，我们就能更有效地利用这项新技术——既不盲目乐观，也不无谓恐惧，而是实事求是地构建人机协作的未来。

参考来源：

  • OpenAI: Harness engineering: leveraging Codex in an agent-first world
  • Carlini: Building a C compiler with a team of parallel Claudes (Anthropic)
  • George: Harness 工程就是控制论

← 返回 AI-Native 工程系列