TL;DR

早期进展比预期慢，不是因为 Codex 能力不足，而是因为环境 underspecified。

OpenAI 的 Harness 工程文章最令人印象深刻的地方，不是那些惊人的数字（5个月、100万行代码、0手写），而是诚实地面对限制。他们详细记录了：什么不起作用、瓶颈在哪里、系统何时失败。这种诚实不仅展示了可能性，也划定了边界——Harness 工程不是银弹，它有明确的适用场景和根本性的限制。

📋 本文结构

  1. 诚实的起点 —— 为什么承认限制很重要
  2. OpenAI 遇到的瓶颈 —— 环境、QA、上下文管理
  3. Carlini 观察到的限制 —— 上下文污染、时间盲症、自我毁灭
  4. 尚未解决的挑战 —— 创造性设计、长期架构、跨系统协调
  5. 承认边界不是失败 —— 正确设定期望
  6. 人类角色的重新定义 —— 从执行到设计
  7. 未来的研究方向 —— 创造性 Agent、长期规划、社会技术系统
  8. 今日毒舌 —— 关于 AI 炒作的清醒剂
  9. 结语 —— 实事求是地构建未来

诚实的起点

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

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

而是诚实地面对限制。

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

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

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

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

OpenAI 遇到的瓶颈

瓶颈 1：环境 Underspecified

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

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

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

大目标
    ↓
分解为小构建块
    ↓
提示 Agent 构建这些块
    ↓
用它们解锁更复杂任务
    ↓
失败时问：
"缺少什么能力？
 如何让它对 Agent 可读且可执行？"

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

瓶颈 2：人类 QA 容量

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

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

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

应用 UI    ──Chrome DevTools Protocol──→ Agent 可浏览
日志       ───────LogQL 查询───────→ Agent 可分析
指标       ───────PromQL 查询──────→ Agent 可验证

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

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

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

瓶颈 3：上下文管理

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

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

原因：

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

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

Carlini 观察到的限制

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

限制 1：上下文窗口污染

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

症状：

Agent: 我看到 5000 行测试输出...
Agent: 让我看看...
Agent: (context window full)
Agent: 等等，任务是什么来着？

解决方案：

# ❌ 不好
print(f"Test results: {json.dumps(all_results, indent=2)}")
# 5000 行输出

# ✅ 好
print(f"SUMMARY: {passed}/{total} passed")
print(f"FAIL: {failed_tests}")
print("Details: see test.log")
  • 最多只打印几行输出
  • 重要信息记录到文件
  • 预计算统计摘要

限制 2：时间盲症

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

症状：

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

解决方案：

# 默认快速模式
--fast  # 只运行 1% 或 10% 的随机测试

# 定期进度提示
echo "Progress: 30% (elapsed: 5min, est remaining: 12min)"

限制 3：自我毁灭

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

案例：

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

应对：

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

尚未解决的挑战

OpenAI 的文章在某处截断，但暗示了持续存在的挑战。结合业界实践，我们可以识别一些尚未完全解决的问题：

挑战 1：创造性设计

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

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

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

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

为什么：这些活动需要：

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

人类仍然需要主导这些活动。

挑战 2：长期架构演进

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

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

当前 Agent 的能力：

  • ✅ 增量改进
  • ❌ 全局重构

为什么：

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

挑战 3：跨系统协调

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

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

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

承认边界不是失败

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

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

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

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

人类角色的重新定义

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

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

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

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

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

未来的研究方向

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

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

今日毒舌

Harness 工程的边界探索，给了 AI 炒作一剂清醒剂。

在过去的两年里，我们被各种”AI 将取代程序员”的标题轰炸。从 Copilot 到 Devin，从 GPT-4 到 Claude 3.7，每一次发布都伴随着”程序员末日”的论调。

但 Harness 工程诚实地告诉我们：

Agent 可以写代码，但不能做设计。 Agent 可以修复 Bug，但不能判断方向。 Agent 可以执行任务，但不能定义目标。

这不是”AI 还不够好”的暂时性问题。这是根本性的能力边界。

所以下次有人告诉你”AI 将取代所有程序员”时，你可以平静地回答：

“也许吧。但首先，它得学会参加那些毫无意义的站立会议，学会在项目延期时写 PPT 给老板解释，学会在架构评审会上和政治斗争。

在那之前，我还是安全的。”

结语

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

OpenAI 的 100 万行代码和 Carlini 的 C 编译器证明了一个重要可能性：在正确设计的约束下，Agent 可以成为可靠的生产力倍增器。

但他们遇到的瓶颈也清楚地表明：

  • Agent 需要精心设计的环境
  • Agent 需要高质量验证器
  • Agent 需要有效的知识管理

最重要的是：Agent 需要人类的设计和判断。

Harness 工程不是人类的退场，而是人类以新的方式参与——从执行到设计，从实现到评判，从编码到架构。

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

参考来源：

  • 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 工程系列