Harness Engineering：编码智能体的高级上下文工程
演讲者：Dex（12-Factor Agents 作者）| 来源：AI Engineer 大会 | 2026-03-23
核心论点
AI 编码在复杂项目中产出大量”slop”（低质量代码），根本原因不是模型不够好，而是上下文管理不善。通过系统化的上下文工程，3 人团队实现了 2-3 倍的产出提升，且质量不降。
关键洞察
1. 「笨蛋区」理论（Dumb Zone）
上下文窗口使用率超过约 40% 后，模型表现开始显著下降。如果加载了太多 MCP 工具定义，你的所有工作都在”笨蛋区”进行，永远得不到好结果。
核心公式：上下文窗口使用越多 → 产出质量越差。
2. 刻意压缩（Intentional Compaction）
不要等上下文窗口耗尽才重启。主动将当前对话压缩为 Markdown 文件（包含具体文件名和行号），新会话直接加载这份压缩结果，跳过重复的代码探索过程。
上下文窗口中最占空间的内容：文件搜索、代码流理解、文件编辑、测试/构建输出。
3. 轨迹污染（Trajectory Poisoning）
反复纠正 AI → AI 出错 → 你骂它 → AI 继续出错。这不是偶然——LLM 看到”出错-被骂”的对话模式后，最可能的下一个 token 就是继续出错。发现偏离方向时，应该开新会话而不是反复纠正。
上下文质量的危害排序：错误信息 > 缺失信息 > 噪音过多。
4. 子智能体的正确用法
子智能体不是用来模拟角色（前端 agent、后端 agent、QA agent——请停止这样做）。它们是上下文隔离工具：派一个子智能体去探索代码库，它消耗大量上下文做搜索和阅读，最后只返回一句精炼结论给父智能体。
5. Research → Plan → Implement 工作流
| 阶段 | 目的 | 产出 |
|---|---|---|
| Research | 理解系统运作方式，定位关键文件 | 压缩的”真相快照”——基于代码本身的研究文档 |
| Plan | 列出精确步骤，包含文件名、代码片段、测试方案 | 压缩的”意图” |
| Implement | 按计划执行，保持低上下文 | 代码变更 |
每个阶段都是一次压缩：Research 压缩真相，Plan 压缩意图。
6. 按需上下文 vs 静态文档
不要维护大量静态文档来 onboard AI——文档会过时，而且”从代码到函数名到注释到文档，谎言含量递增”。
更好的方式：每次任务时，用 Research 阶段动态生成针对当前任务的上下文快照。这样保证信息是真实的、精简的、按需的。
7. 心智对齐（Mental Alignment）
Code Review 的核心价值不是”检查代码是否正确”，而是让团队保持对代码库变化方向的共识。当 AI 让代码量翻倍时，技术负责人读不完所有代码，但可以读 Plan 来保持同步。
建议：在 PR 中附上 AI 会话记录和执行步骤，让 reviewer 看到”旅程”而非只看到结果。
8. 错误放大效应
一行错误的代码就是一行错误的代码。Plan 中一行错误可能导致 100 行错误代码。Research 中一处误解，整个方向都会偏掉。
人类应把精力投入在最高杠杆的环节——越上游的错误，放大效应越大。
9. 不要外包思考
AI 不能替代思考，只能放大你已完成的思考（或你未完成的思考）。没有完美的 prompt，没有银弹。你不读 Plan，流程就不会起作用。
实用指导：何时用多少上下文工程
| 任务复杂度 | 建议做法 |
|---|---|
| 改个按钮颜色 | 直接对话，不需要额外流程 |
| 小功能开发 | 简单 Plan 即可 |
| 跨多个模块/仓库的中等功能 | 完整 Research + Plan |
| 复杂系统级改动 | 多轮 Research + 详细 Plan + 可能需要回退到白板 |
判断标准：需要练习。专注一个工具，积累经验。不要在多个工具间来回切换优化。
团队采纳的现实挑战
高级工程师不用 AI（因为提速不明显）→ 中级工程师大量使用（填补能力差距但产出 slop）→ 高级工程师每周清理更多 slop → 更讨厌 AI。这不是 AI 的错，也不是中级工程师的错——文化变革必须自上而下推动。