从上下文工程到 Harness Engineering：驾驭模型而不只是使用模型
AI Coding 工具出现后，一个反直觉的现象正在扩散：代码生成速度提高了一个数量级，但研发团队普遍觉得更累了。
原因不复杂。编码只占软件开发工作量的 30% 左右，测试、验证、Code Review、部署这些”非编码工作”占了 70%。AI 加速了 30% 的部分，却没有触及剩下的 70%——反而因为代码产出激增，后续环节的工作量跟着指数级上升。人成了 AI 的”调试器”，陷入局部最优陷阱。Harness Engineering 就是为了打破这个陷阱。
Harness 的原意是马具——骑手用它驾驭马的力量，而不只是让马跑更快。放到 AI 工程里，Harness Engineering 就是为模型构建一套可控的工作环境，让 Agent 能执行跨越整个开发生命周期的长时间闭环任务。
这个概念最早由 OpenAI 在 Harness Engineering (opens in a new window) 一文中提出（我之前整理过这篇文章），周晓在 D2 大会上把它进一步拆解成了三个维度：
- 工程师角色转变——从”编写代码”转向”设计环境、明确意图”
- 构建 Agent 专属工具链——实现受控执行，而不是放任自由发挥
- Agent 可读性——代码库重塑为模型能”读懂”的环境
范式演进的路径很清晰：Cursor 代表的代码补全 → Claude Code 代表的 Agentic Coding → Harness Engineering。每一步的本质都是让任务运行得更长、让 Agent 接管更多闭环。
Harness Engineering 建立在对模型物理限制的理解之上——顺应它，而不是对抗它。周晓从 Transformer 原理出发，提炼了三条约束：
自回归决定了速度上限。 LLM 本质是”下一个 token 预测器”，每个 token 都基于前面所有 token 生成。上下文越长，Prefill 阶段越重，首 token 延迟越大。流式输出不是产品设计选择，是物理现实。
KV Cache 决定了成本结构。 推理分两阶段：Prefill 全量计算 KV，Decode 复用 KV。追加新内容极度便宜（复用已有缓存），但中间修改极其昂贵（修改点之后的所有缓存全部作废）。周晓给出一条黄金定律：一切上下文工程，本质上都是为了”尽量不破坏前缀”。
注意力稀释决定了效果上限。 上下文越长，注意力被稀释得越严重。在万行代码中，关键逻辑往往被掩埋。幻觉不是模型故意欺骗，而是当上下文缺少事实锚点时，模型为维持概率连贯做出的”合理猜测”。
以 Prompt Cache 为例，Claude Sonnet 的 Cache Read 价格是 $0.30/MTok，仅为基础输入价格的十分之一。命中缓存意味着成本降低 90%、推理速度大幅提升。但前提是前缀稳定——哪怕在 system prompt 开头加一个精确到秒的时间戳，也会让后续所有缓存失效。
这些约束和 Manus 团队在上下文工程实践中得出的结论高度一致：KV Cache 命中率是生产阶段 AI Agent 最重要的单一指标。
理解了这些约束，上下文工程的策略就容易理解了。
周晓把一次 Agent 任务背后的 Prompt 拆成五层：System 提示、AGENTS.md、项目快照、会话历史、工具定义。重点不在于塞多少内容进去，而在于把关键信息放到注意力权重最高的位置。
几条实践原则：
- AGENTS.md 是项目宪法。 自动放置在 Prompt 最前面，不会被压缩或总结，所有 Agent 默认遵守。适合写入技术栈、代码风格约定、安全边界；不适合写入一次性需求或经常变动的信息。
- 主动 Compaction。 在关键节点将对话状态浓缩为结构化 snapshot 文件，清理对话历史。既防止上下文膨胀，又保留了可 review 的状态锚点。
- 记忆外包给文件系统。 不在代码仓库里的隐形知识，对 Agent 来说就是不存在的。执行完一个阶段后，把结论写成 Markdown 文件，下次
read_file即可恢复——文件系统是大小不受限、天然持久化的外部记忆。
这和之前整理的 Manus 文章中”把文件系统当外部记忆”的做法完全吻合。
上下文治理只是一半，工具设计同样重要。工具是给 Agent 用的 API，不是给人用的 UI。
周晓给出了三条标准：
- 贴近物理上限——秒级冷启动与响应，防止 Agent 注意力涣散
- 结构化输出——禁止 PDF 截图，必须输出 JSON 或 Markdown，用最少的 token 传递最多信息
- 痛觉反馈——错误信息是闭环的起点，需精确到行号与类型。错误可能比正确更重要：基于 ReAct 循环，模型通过错误反馈更接近解决问题
在工具架构上，MCP、Skill 和 Sub Agent 三层分工各有位置：
| 层级 | 定位 | 特点 |
|---|---|---|
| MCP | 原子动作 | 常驻上下文，提供基础能力（GitHub、Slack、DB） |
| Skill | 固化 SOP | 按需激活，把成熟打法编码为可执行文件夹，降低上下文消耗 |
| Sub Agent | 并行外包 | 完全独立的会话和上下文，适合超长任务拆解 |
这三层解决同一个问题：用架构隔离对抗长任务的熵增。MCP 扩展工具能力，Skill 把领域知识渐进式交给模型，Sub Agent 把上下文限制分摊到多个独立会话。
LSP 的例子最能说明”闭环”的价值。没有 LSP 接入时，Agent 感知不到代码中的语法错误——人能看到的红色高亮，对模型来说不存在。接入 LSP 后，Agent 就能自动执行”Lint → Fix → Verify”闭环：静态分析发现冲突，增量重构应用修复，动态验证运行测试。
没有这种自动闭环，Agent 会在错误上堆叠错误，直到上下文爆炸。
周晓在字节的实践更进一步：Agent 改完代码后，通过内置 cli-test Skill 在沙盒环境中自行测试，最终产出包含变更说明、截图对比和测试报告的交付文档。人只需要审阅交付物，不需要审阅每一行代码。
换句话说，从 Review 代码变成 Review 交互和测试结果。
Harness 的边界在于人机分工。Agent 自主执行的前提是：Spec 明确、有闭环验证、工具能力覆盖完整、失败可自动回退。不满足这些条件时，Agent 应该在第一轮就向人求助——不猜，直接报告”意图模糊""环境信息不足”或”涉及不可逆操作”。
好的工具链让 Agent 知道自己能做什么、不能做什么——这本身就是 Harness。
周晓在分享最后提了四个方向：从编码者转为 Builder、驾驭模型物理限制、通过工具连接物理世界、让 AI 释放人类注意力。压缩一下就是：模型只是一个巨大的函数，你给它什么环境、什么工具、什么反馈，决定了它能做到什么。
如果只能先做一件事，我的建议和之前整理 OpenAI Harness Engineering 文章时一样：从仓库知识体系化开始——把分散在聊天、会议和脑内的规则迁移到版本化文档，并给它配套验证机制。这是 Harness Engineering 最小可行的起点。