6.1 Harness 工程要解决的问题
前情回顾
前五章分别解决了 Agent 的各个子问题：
| 章节 | 解决的问题 | 核心方案 |
|---|---|---|
| 第 2 章 | LLM 怎么接入 | 会话管理、流式输出 |
| 第 3 章 | 上下文从哪来 | 记忆、检索、规范 |
| 第 4 章 | Agent 怎么守规矩 | Skill（操作流程）、Rule（编码约束） |
| 第 5 章 | Agent 怎么使用工具 | Tool 系统、多 Agent 编排 |
每个子系统独立工作都没问题。但当它们合在一起时，新的问题出现了。
问题 1：组件是散的，缺少"胶水"
记忆系统知道用户偏好，但 Skill 不知道。Rule 约束了代码风格，但 Agent 调用工具时不受 Rule 约束。上下文提供者链自动注入信息，但没人管这些信息是否冲突。
每个组件都在做自己的事，但没有一个"总指挥"把它们组织起来。
问题 2：LLM 的输出不可控
LLM 是概率模型，输出有不确定性：
- 结构性问题：缺少章节、字段格式错误、JSON 损坏
- 行为性问题：忘记调用工具、调用了错误的工具
- 语义性问题：内容偏离需求、包含幻觉
- 安全性问题：输出了敏感信息
你无法保证 LLM 每次都输出正确的结果。
问题 3：出了问题不知道出在哪
Agent 执行了一连串操作——加载记忆 → 注入 Skill → 调用 LLM → 执行工具 → 返回结果。中间任何一步出问题，最终结果都可能不对。但没有统一的追踪机制，排查问题全靠猜。
三阶段演化模型
在讲具体架构之前，先退后一步看全局。
Agent 架构的演化，经历了三个阶段：
| 阶段 | 核心问题 | 解决方案 | 对应章节 |
|---|---|---|---|
| 提示词工程 | 模型听不懂 | 设计精确指令 | 第 2 章 |
| 上下文工程 | 模型记不住 | 管理对话历史 + 知识注入 | 第 3-4 章 |
| Harness 工程 | 模型管不住 | 约束行为边界 + 评估校验 | 本章 |
三个阶段不是替代关系，是叠加关系——后面的阶段建立在前面的基础之上。
- 提示词工程解决了"怎么跟 LLM 说话"
- 上下文工程解决了"怎么给 LLM 信息"
- Harness 工程解决的是最后一个问题：怎么让 LLM 可控地发挥能力
LLM 的五个固有缺陷
Harness 的设计出发点，是 LLM 的五个固有缺陷：
| 缺陷 | 表现 | Harness 对策 |
|---|---|---|
| 有自己的偏好 | 喜欢深层嵌套、吞异常、过度兼容 | Rule：用工程约束覆盖训练数据默认值 |
| 没有边界 | 会改不该改的文件、碰不该碰的模块 | AGENTS.md + Rule：定义行为边界 |
| 会迎合用户 | 你说什么它都说对 | EvalCheck：输出后自动校验 |
| 会一根筋 | 陷入死循环、重复尝试同一方案 | Monitor：超时检测 + 自动中断 |
| 会偷懒 | 跳过步骤、输出不完整 | Skill：标准化操作流程 |
Harness 不是一个"新东西"——它是把前面五章的组件按这五个缺陷组织起来，形成一套完整的治理体系。
本章导读
接下来几节的结构：
- 6.2 标准 Harness 工程的设计清单——一个完整的 Harness 需要哪些组件，每个组件做什么
- 6.3~6.5 产品实战——我的工作流 Agent 系统是怎么设计的，从整体架构到单个 Agent 到 Agent 间协作
- 6.6 如何学习 Harness 工程——怎么用 AI 读框架源码，学习别人的实现