Harness 工程：提示词→上下文→驾驭

观点：Agent = 大模型 + Harness。评价一个 Agent 不看它模型多强，看模型外面那四层驾驭结构齐不齐——同样的模型换个工具效果差一截，差的从来不是模型。

三个工程是递进关系：提示词工程管”别乱说话”，用角色、限制、输出格式把发散的预测收窄；它其实是上下文工程的一部分。上下文工程管”有限的窗口里塞对信息”，动作就三个——召回（从聊天记录、代码环境、报错里找出最相关的）、压缩（信息变小）、组装（顺序影响理解，越靠后越被关注）；窗口打满硬塞会”上下文腐化”，模型开始记不住、前后不一致。但上下文组织得再好，模型也只是会聊天不会干活，驾驭工程（Harness）补的就是这一环，它拆成四层：执行层给模型接上 bash、沙箱、文件系统、MCP，让它能读写代码跑命令；记忆层把项目目标、技术栈、禁止事项写成规则文件（CLAUDE.md、AGENTS.md、各家 rules）固定注入每次调用，写长了就拆成 bg.md、stack.md 加一层路由，平时只注路径、用时才加载全文；反馈层把 lint、单测、CI 的报错回传进上下文，驱动 Agent 下一轮自动修复；规划层把大任务拆成有明确结束条件的子任务，没有它 Agent 会跑偏甚至陷入无效死循环。落地最轻的做法就是写好 CLAUDE.md（背景、要做什么、别做什么、验收命令、可用 skill 五件事），再往上是 spec-kit 这类扩展的 SDD 流程——按阶段拆需求，每阶段刷新一次约束文件，保证注入的始终是核心信息。

洞察：这套四层划分的真正价值是诊断而不是定义——缺哪层，故障就在哪层：目标被冲淡是记忆层的病，只会聊天是执行层的病，错了没人发现是反馈层的病，停不下来是规划层的病。它把”模型不行”这个万能借口从排查清单里删掉了，只补缺的那层，不换模型。

启示：规则文件的最小可用集是五件事——背景、要做什么、禁止事项、验收命令、可用 skill 清单，其中”禁止事项”最容易被漏写却收益最高，模型发散往往不是不知道做什么，是没人告诉它边界（“不要乱改我的代码”就是原片的例子）。往远看一步：程序员的产出物正从代码变成规则和 skill，代码退居为约束的执行结果。也可以换维度问自己一句：我的任务里”什么算可机器校验的通过”——答得上来的部分，都可以交给 Harness。

提醒：四层是作者归纳的叙事结构，不是业界标准，当思考工具用没问题，当”标准定义”引用会被反驳；它不给量化指标，只宜定性诊断、不宜选型排序。例子全部来自 coding Agent，UI 美观、文案这类”人说了算”的领域反馈层是空的，“产出物变规则”也只在任务能被机器验收时成立——而且这是趋势判断不是已发生的事实，能写出好规则的人通常本来就会写那段代码。spec-kit 作者自己承认不够强，等更全面的替代方案。

---

📺 小白debug，抖音，2026-04-08 · 原视频 · 库内 2026-04-08-HarnessEngineering是什么 · 速览 速览/2026-04-08-Harness工程是什么