Harness

发表于 | 分类于 | 阅读次数

当 AI 模型从“问答工具”进化为“自主执行任务的 Agent”时，工程的重心不再是“如何让它生成代码”，而是“如何设计一套系统环境、工具链和工作流，让它能可靠地完成并验证任务”。

人类不再用编程语言与机器沟通，而是用 Markdown（规则与规划）、测试契约（验收标准）和架构蓝图 与智能体集群沟通。

什么是 Harness Engineering

Harness是包围在基础大模型外围的提示词系统、上下文管理机制、工具集和工作流的总和。

  • 核心痛点： 模型在处理长任务时容易出现“上下文遗忘”、“上下文焦虑（怕超出 token 而过早草草收尾）”以及“盲目自信（自我评估能力极差）”。
  • 解决方案： 通过 Harness Engineering 提供外部记忆、验证工具和独立的评估者。

Harness 的四大工程维度

  1. Prompt（提示词）工程化：渐进式披露
    • 反直觉经验： 不要把所有规则都塞进一个巨大的 System Prompt 或 AGENTS.md 里，这会导致“上下文污染”和 Agent 抓不住重点。
    • 最佳实践： 采用“目录式导航”。提供一个轻量级的入口文件（如包含代码库结构的地图），让 Agent 需要时自己去 docs/ 目录下读取详细的设计文档或规则（渐进式披露）。
  2. Context（上下文）工程化：状态外置
    • 解决“上下文焦虑”： 当任务过长时，采用 Context Resets（上下文重置）。
    • 最佳实践： 将 Agent 的进度和状态保存为外部文件（如 Markdown 记录、Git 日志）。每次开启新 Session 时，新 Agent 只需读取外部文件就能无缝接力，而不是硬扛超长上下文。
  3. Tools（工具）工程化：赋予“验证”能力
    • 核心痛点： Agent 很容易在“看起来写完了代码”时提前结束，但代码根本跑不通。
    • 最佳实践： 给 Agent 接入环境验证工具。例如 OpenAI 接入了 Chrome DevTools（让模型看 UI 快照和网络请求）、本地日志查询（LogQL）；Anthropic 接入了 Playwright MCP（让模型像真人一样点击浏览器测试）。让 Agent 看到自己的运行结果，而不是盲写。
  4. Workflow（工作流）工程化：构建执行路径
    • 将复杂任务拆解为原子单元，设置检查点和反馈回路（如 Ralph Wiggum 持续迭代循环），不要让 Agent “自己看着办”。

核心协作模式：Generator-Evaluator（生成者-评估者）

灵感来自 GAN（生成对抗网络），这是处理复杂/主观任务最有效的多 Agent 架构。

  • 为什么需要？ Agent 自己当裁判时极其宽容，往往对自己的垃圾代码/设计打高分（自信偏差）。
  • 三角色架构（Anthropic 实践）：
    1. Planner（规划者）： 将用户简单的一句话提示转化为极其详尽的“产品规格说明书（Spec）”。
    2. Generator（生成者）： 负责按 Spec 写代码，并且在写之前要和 Evaluator “签订契约（确定验收标准）”。
    3. Evaluator（评估者/QA）： 拥有真实测试工具（如 Playwright），负责在浏览器里乱点乱测，拿着量化指标（如设计感、原创性、代码质量）严格打分。只要有一项不达标，立刻打回重做。

面向 Agent 编程：如何打造“Agent 可读”的代码库

OpenAI 的团队进行了一场硬核实验：用 5 个月时间，由 3-7 名工程师组成的团队，在 0 行手写代码的情况下，完全由 Codex 生成并维护了一个包含 100 万行代码的内部测试产品。

  1. 将环境打造为“代理可读 (Agent-Readable)” （通过feedback改善结果）
  • 打破黑盒：如果 AI 看不到，它就不存在。人类的 Slack 聊天、脑海中的设计都必须转化为 Markdown 存入代码库。
  • 赋予 AI 观测能力：OpenAI 为 Codex 接通了 Chrome DevTools（用于查看 DOM、截图重现 UI 错误）和本地可观测性技术栈（LogQL、PromQL）。当要求 AI“优化启动时间”时，AI 可以自己跑一遍应用，查日志、看指标并自动修复。
  1. 重新定义上下文管理（控制认知框架）
  • 摒弃巨型系统提示词：一个包含所有规则的巨大 AGENTS.md 会让 AI 抓不到重点且容易过时。
  • 目录式管理 + 文档园丁：将庞大的知识库拆分成结构化的 docs/ 目录，AGENTS.md 仅作为目录索引（Map）。并配备一个后台“文档园丁（Doc-gardening）”智能体，专门负责自动扫描和修复过时的文档，保证文档和代码行为一致。
  1. 严格的架构约束与“AI 垃圾回收”（控制能力边界，对工具的限制，利于agent的工具等）
  • 机械化的层级限制：通过 Linter 和结构化测试，严格限制业务代码的依赖方向（如 Types → Config → Repo → UI），不允许越级调用。在框架内给予 AI 高度自由，在边界上极其严苛。
  • 后台自动重构 (Garbage Collection)：完全由 AI 生成的代码必然会产生模式漂移（熵增）。OpenAI 设立了后台 AI 任务，像垃圾回收一样定期扫描不符合“黄金原则”的代码并自动提交 PR，让人类工程师只需花 1 分钟就能合并修复。

  1. 工作流的演变 （使用标准工作流控制）

    因为 AI 产出极高、修复成本极低，团队放弃了传统的“阻塞式合并要求”。测试不稳定可以随时重跑，重点是速度和持续运转，而不是追求单次生成的完美。

  2. 不同模型可能适合不同的Harness 框架

Harness 工程化

长对话触发 Context 压缩（Compact）导致关键约束遗忘（如单位定义、表结构约束丢失）:在对话截断或压缩后自动重新注入约束，杜绝“越聊越失忆

能写成代码的规则，不要只写 Prompt：通过一些关键节点hook进去控制模型行为（压缩前后，使用工具前后等）

高频工作沉淀成 Skill，而不是每次重新 Prompt

把整个流程自动化循环化（带状态、验证、失败处理和反馈的闭环执行）Plan（规划）➔ Act（执行）➔ Verify（验证/门禁）➔ Feedback（报错捕获与重试） 的