1.2 Harness Engineering 是什么？
定义
Harness Engineering：通过机制设计（而非 prompt）来确保 Agent 输出质量的环境工程。
关键词不是"提示"，不是"信息"，而是机制——可执行、可验证、不可绕过的规则和流程。
高速公路类比
把 AI Agent 想象成在高速公路上行驶的汽车：
没有路面，车开不了；没有护栏，车会冲下悬崖；没有限速，车会失控。
三者的组合，才构成一条安全可行驶的高速公路。
核心公式
$$Agent = Model + Harness$$
☀️ Model 是天花板
模型的能力决定了 Agent 理论上能达到的上限。更强的模型 = 更高的天花板。
🏠 Harness 是地板
Harness 的设计决定了 Agent 实际能稳定达到的下限。更好的 Harness = 更高的地板。
一个天花板很高但地板很低的 Agent，就像天才实习生没有流程保障——偶尔惊艳，经常翻车。
层级关系
每一层都是上一层的超集。Harness 包含 Context，Context 包含 Prompt。
Context vs Harness：六维对比
Context 与 Harness 的核心差异
关键区别
Context 告诉 Agent "应该怎么做"，Harness 确保 Agent "不会做错"。前者靠自律，后者靠机制。
场景：电商支付模块
假设你要让 AI 写一个电商支付模块：
❌ 纯 Context 方案
"这是我们的支付 API 文档、数据库 Schema、技术规范，请按照这些要求实现支付模块。"
结果：Agent 可能：
- 写出了正确调用 API 的代码，但忘了处理并发问题
- 知道要校验金额，但校验逻辑写在了前端而不是后端
- 参考了旧代码，但把已废弃的接口也抄了进来
✅ Context + Harness 方案
在 Context 的基础上，再搭建：
- 类型系统约束：用 TypeScript 严格模式，金额字段必须是
Decimal类型 - 自动化测试：支付模块必须通过单元测试和集成测试
- Lint 规则：禁止直接调用外部支付 API，必须走 PaymentService 封装
- CI 流水线：代码提交后自动检查，不通过就不让合并
结果：Agent 即使想绕过 PaymentService 直接调 API——也做不到，因为 Linter 会直接报错。
不是替代，而是叠加
重要认知
Harness 不是 Context 的替代品，而是 Context 的兜底层。
理想工作流：
- Prompt 定方向
- Context 补知识
- Harness 保底线
三者缺一不可，但 Harness 是让整个体系从"偶尔好用"变成"持续可靠"的关键一层。
本节小结
📌 本节核心要点
- 定义：Harness Engineering 是通过机制设计确保 Agent 输出质量的环境工程
- 类比：Tools=路面、Boundaries=护栏、Rules=限速标志
- 公式：Agent = Model + Harness，Model 是天花板，Harness 是地板
- 层级：Harness >= Context >= Prompt，每层是上层超集
- 核心区别：Context 是软约束，Harness 是硬约束；Context 管信息，Harness 管环境
- 叠加而非替代：Context 告诉"应该怎么做"，Harness 确保"不会做错"
思考题
- 你当前的 AI 工作流中，哪些规则是"软约束"（依赖模型自觉遵守）？如果改成"硬约束"（机制保障），你会怎么设计？
- 举例说明：一个 Context 搞定但 Harness 搞不定的场景，和一个 Harness 搞定但 Context 搞不定的场景。
- "Model 是天花板，Harness 是地板"——在实际项目中，你应该先提升天花板还是先提升地板？为什么？
下一节预告
理解了 Harness 是什么，接下来我们深入分析 Agent 在实际运行中遇到的五大类问题——第一个问题：Agent 越界。