Harness Engineering：把 AI 编程助手变成可进化系统
英文原题：Harness Engineering: What Separates Top Agentic Engineers Right Now。本课解释为什么真正拉开差距的不是“换一个更强模型”，而是你能否为模型搭好上下文、工具、流程和反馈闭环。
一、问题引入：为什么“会提示词”已经不够了
这支视频抓住了 2026 年 AI 编程工作流里一个很实际的变化：很多工程师已经不再只问“Claude Code、Codex、Cursor 哪个更聪明”，而是开始问“我能不能把这些工具组织成一个可靠的工程系统”。Cole Medin 把这个方向称为 harness engineering，也就是围绕模型搭建可控的外层工程装置。
视频最有价值的地方不在于发明一个新名词，而是把“模型失败”重新解释成“系统可改进的信号”。当 agent 忘记团队约定、乱跑危险命令、丢失上下文、无法收敛到可验证结果时，常见反应是等待下一代模型。但 harness engineering 的视角会要求你把这些失败沉淀成规则、技能、hook、评审流程和多会话编排，让下一轮工作天然少踩同一个坑。
模型本身不会访问文件系统、运行 Git、执行测试或理解团队流程；这些能力来自外层 harness。
从一次性提示词转向可复用 AI layer：rules、skills、MCP、hooks、sub-agents 和知识检索。
把大型任务拆给多个聚焦会话，使用交接文档、自动验证和反馈闭环持续推进。
二、核心概念：模型、工具 harness 与你自己的 AI layer
视频先把一个 agent 拆成三层。最里面是大语言模型，例如 GPT 或 Claude，它提供推理能力，但单独存在时没有项目文件、终端命令、版本控制或测试环境。中间层是你选择的 AI 编程助手本身，例如 Claude Code、Codex 或其他 coding agent，它们给模型接上文件系统、命令执行、编辑器能力和默认系统提示。最外层才是你真正可以持续建设的部分：你的 AI layer。
AI layer 包含全局规则、项目约定、技能、MCP 服务器、代码搜索、LSP、知识图谱、hooks 和 sub-agents。它们共同决定 agent 在你的代码库里“知道什么、能做什么、什么时候必须停下来验证、失败后如何修正”。所以 harness engineering 不是简单地给模型塞更多上下文，而是把上下文、动作、控制和反馈设计成一个可进化的系统。
可以把每一次 agent 的失误都当作 harness 的改进机会：不知道约定就写入规则，危险操作就用 hook 阻断，验证不足就把测试门禁变成自动流程。
1. 与 context engineering 的关系
视频承认，单会话内的很多 harness 工作确实延续了 context engineering：把正确的文档、约定、工具说明、代码入口和历史决策提供给模型。但它进一步强调“控制”这件事，包括如何阻止危险命令、如何在完成声明后强制跑测试、如何把任务拆成多个会话而不是让一个上下文窗口吞掉全部需求。
2. 为什么工具选择只是第一层
选择 Claude Code、Codex 或其他工具，本质是在选择厂商替你工程化的一层 harness。不同工具在文件访问、命令执行、补丁策略、上下文窗口和默认行为上各有取舍。但真正决定长期效率的是你能否在这些工具之上，建立团队自己的规则、脚本、验证和交接机制。
3. “技能问题”的重新定义
视频引用的核心判断是：agent 做蠢事时，问题通常是可读的。它不知道某个 convention，就把 convention 写入 `AGENTS.md`；它尝试危险命令，就写 pre-tool hook；它完成后没有验证，就写 stop-validation hook。这种心态把“模型不够强”改写成“系统还没有学会”。
三、关键论点与实操步骤
步骤一：先列出你的 AI layer 资产
不要急着上来写复杂 orchestrator。先盘点团队已经有哪些稳定资产：全局规则、项目 README、架构文档、常用调试命令、测试命令、发布命令、代码搜索方式、禁用目录、代码审查标准。把这些资产以 agent 能读懂、能执行的方式组织起来，才有资格谈后续自动化。
- Rules：编码风格、目录边界、命名约定、禁止操作、提交策略。
- Skills：计划、实现、验证、发布、回滚等可复用工作流。
- MCP/Tools：数据库、浏览器、文档、Figma、GitHub、内部系统等外部能力。
- Code intelligence：LSP、ripgrep、CodeGraph、知识图谱和跨仓库索引。
- Hooks：工具调用前安全检查、文件编辑后 lint、完成前测试门禁。
步骤二：把计划、实现、验证拆成不同会话
Cole 特别强调，长任务不应该一次性塞给同一个 agent 会话。更稳的做法是让 planning session 只负责探索和输出计划，让 implementation session 只处理清晰范围内的补丁，让 validation session 或 review agents 分别检查正确性、安全性和简洁性。每一步都产出可交接的 markdown 或结构化结果。
这个建议背后的工程理由很朴素：上下文越大，模型越容易把要求混在一起；职责越含糊，agent 越容易把“看起来完成了”当成真正完成。把任务分段后，每个会话都更聚焦，也更容易设置确定性验收条件。
步骤三：用 hooks 把安全和验证前移
视频提到两个很实用的 hook 场景。第一个是 pre-tool-use hook，在 agent 写文件、读敏感路径或执行命令前拦截风险，例如阻止读取 `.env`、阻止破坏性删除、限制未批准的网络动作。第二个是 stop-validation hook，在 agent 宣称完成时自动运行测试、lint、typecheck 或质量门禁；如果失败，就把错误送回 agent 继续修。
这一步看似“不智能”，但正是 harness engineering 的价值所在：把必须可靠的部分交给确定性脚本，而不是依赖模型自觉记住。
步骤四：让每次失败反馈到规则库
如果某次 agent 误改了历史页面，就把“只允许 append，不允许重写旧页面”写进 skill；如果某次漏了线上验证，就把 curl 检查做成完成门禁；如果某次总结里夸大了状态，就把“失败命令类别必须明说”写入自动化要求。harness 的成熟度来自这种小步沉淀，而不是一次性设计完美。
步骤五：进一步构建多会话 Ralph loop
视频后半段用 Ralph loop 说明更高阶的 harness：一个外层脚本接收大需求，拆成多个迭代项，逐个启动 coding agent 会话，读取交接文件，运行验证，直到出现明确的 `done.txt` 或等价完成信号。它的关键不是“让一个 agent 无限工作”，而是让多个聚焦会话按流程协作。
四、对比表格：不同 harness 层级怎么选
| 层级 | 适用场景 | 优点 | 风险 | 决策建议 |
|---|---|---|---|---|
| 单次提示词 | 小改动、一次性解释、低风险脚本 | 启动成本最低，适合探索想法 | 经验无法沉淀，失败容易重复出现 | 只用于临时任务；出现第二次同类问题就沉淀规则 |
| 项目规则与技能 | 重复开发流程、固定验证步骤、团队约定明显的仓库 | 最容易落地，能立刻降低 agent 漏步骤概率 | 规则过长会稀释重点，过时规则会误导执行 | 把规则写短、写可执行，并定期删除无效内容 |
| MCP 与工具层 | 需要访问 GitHub、文档、浏览器、设计稿、数据库或内部系统 | 让模型从“写文本”变成“操作真实系统” | 权限边界、凭据泄露、工具错误都会放大影响 | 给工具加最小权限，并用 hook 限制敏感动作 |
| Hooks 与质量门禁 | 安全敏感、发布链路、自动化任务、多人协作仓库 | 用确定性检查补足模型不稳定性 | 门禁过粗会误杀，过松会变成摆设 | 先覆盖最常见失败：测试、lint、diff 范围、线上 HTTP 200 |
| 多会话编排 | 大型 PRD、跨模块改造、需要评审与返工循环的任务 | 每个 agent 上下文更小，职责更清晰，可并行评审 | 外层 orchestrator 复杂，交接文档质量决定成败 | 从 plan → implement → review → fix 的最小闭环开始 |
五、引用块：这支视频真正想让你记住什么
Harness engineering 的重点不是追逐 buzzword，而是承认 agent 的表现由模型、工具和你设计的 AI layer 共同决定。
当任务变大时，不要把整个 PRD 塞进一个会话；把计划、实现和评审拆开，让每个会话只承担清晰职责。
这两句话合起来，就是今天最实用的 takeaway：优秀的 agentic engineer 不只是“更会问模型”，而是会把模型放进一个可观察、可限制、可验证、可迭代的工作流里。
六、时间戳目录
七、相关推荐
如果你想把这支视频的观点落到实践，可以继续看这些课程页：它们分别覆盖工具选择、MCP、子智能体和多 agent 编排。