为什么换更强的模型救不了你的 Agent，先修 Harness
模型是司机，Harness 是车；交付不了多半是车的问题，不是司机。
为什么能力强的模型仍然交付不了
你接了当时最强的模型，写了一段你自认精巧的 prompt，Agent 跑起来了——前三步漂亮，第四步开始胡来：调错工具、丢了上下文、把没要求的功能也「贴心」补上、出错后既不重试也不报警，最后给你一坨看似完成实则不可用的东西。
第一反应往往是「模型不够聪明，换个更强的」。这是这一讲要拆掉的第一个错误直觉。
有一句话值得先钉在墙上：
Agency（感知、推理、行动的能力）来自模型训练，不来自外部代码编排。但一个可用的 Agent 产品两者都需要——模型是司机，Harness 是车。
把它翻译成可操作的判断：当 Agent 交付不了，问题分两类。一类是司机问题——模型真的推理不动这道题，这种换模型有用；另一类是车的问题——工具没给对、知识没注入、状态没存住、出错没人接、权限没设界。后者占绝大多数，而换模型对它们一点用都没有，因为你换的是司机，坏的是车。
不修 harness 直接换模型的代价是复利式的：
- 你为「换模型」付的钱和等待，本可以省下，因为根因没动。
- 你把工程缺陷误判成模型缺陷，于是永远在追逐「下一个更强的模型」，而真正的瓶颈一直在原地。
- 更隐蔽的代价：把 if-else 分支、硬编码路由越堆越多，企图用程序流程「模拟」出智能。这是典型的鲁布·戈德堡机器——一堆机关看着在动，但它模拟的是流程，不是 Agency。模型越强，这堆脚手架反而越碍事。
所以这一讲的核心理念只有一句：遇到失败，先修 harness，再考虑换模型。 Module B 整个模块都在教你怎么把这辆车造结实。
Harness 由什么构成
先给定义：Harness 是 Agent 运作的基础设施——模型权重之外的一切工程件。模型负责「想」，Harness 负责让模型「在这个具体领域里能真的跑起来」。
它由五个子系统构成。下面用一个通用的「语音外呼 Agent」（自动给客户打电话、查资料、记录结果）作为落地物的例子：
| 子系统 | 解决什么问题 | 典型落地物 |
|---|---|---|
| Tools（工具） | 模型光会想不会做，得有执行动作的手 | 语音识别、语音合成、CRM 查询、挂机接口 |
| Knowledge（知识） | 通用模型不懂你这个领域的专有规则 | 主提示词 + 按需注入的领域知识字段 |
| Observation（观测） | 模型看不到环境就无法决策 | 语音流、情绪信号、对话历史、状态反馈 |
| Action（行动） | 想法要能落到真实环境里 | 语音输出、日历预约、触发人工转接 |
| Permissions（权限） | 没有边界的 Agent 是事故源 | 通话时长上限、行业合规词过滤、动作白名单 |
理解这张表的关键，是把它当成排错清单而不是知识点。Agent 出问题时，逐个子系统过一遍：是没工具，还是工具没派对？是缺知识，还是知识没注进去？是没观测到状态，还是观测到了不会用？是行动接口断了，还是越权了被拦？五栏里几乎总有一栏先亮红灯——那才是你该修的地方。
需要专门强调一句它不是什么：Harness 不是 Prompt Engineering。把分支逻辑和路由硬编码堆在一起，是用程序流程模拟智能；Harness 是给模型搭基础设施，让它自己的 Agency 能发挥出来。两者方向相反。
一个常被忽略的第六块：成熟的 Harness 还会在「执行循环」之外挂一条「自我改进循环」——活干完后反问一句「这次该学到什么」，把成果沉淀成更好的技能 / 记忆。Harness 不只让模型把活干完，还让它越干越好。
几个真实的数字与例子
术语三义，开会前先对齐用哪一义。 「Harness」这个词在业内被用成三种意思，不先声明就容易各说各话：
| 语境 | Harness 指什么 | 侧重 |
|---|---|---|
| 课程/基础设施义（本讲主体） | Tools / Knowledge / Observation / Action / Permissions 五子系统 | 结构：让模型在领域里跑起来 |
| 工程实践义 | 多层防御：持久化层（规范文件 + 记忆）/ 自动化钩子层 / 上下文隔离层（子 Agent） | 流程：把规范从模型记忆迁到确定性文件系统 |
| 质检/eval 义 | 标准化评测出口（提示词→上下文→Harness，即「怎么问→喂什么→怎么验」） | 出口：评测确保可靠 |
这三义不矛盾：eval 是出口、多层防御是结构、运行基础设施是底座。但你对外做分享时，必须先声明自己用的是哪一义，否则会被人拿另一套定义对线。
两个硬阈值，来自一个能自我改进的 Agent 系统。 它把「什么时候该沉淀」做成了事件驱动的数字触发，可以直接抄进你的 SOP：
- 单次任务 超过 5 次工具调用 → 这套工作流复杂到值得固化成一个可复用技能（已有相近的就更新，别新建）。
- 每 10 条消息 → 强制暂停反思一次，决定什么进长期记忆。
给记忆文件加字符上限，是 feature 不是 bug。 同一系统给紧凑记忆文件设了硬上限（用户画像约 500 token、核心记忆约 800 token），完整会话则全量入库可搜。上限看着像限制，实则是强制只留相关信息——否则文件越堆越多，未来的每一次运行反而更重、更慢，而不是更聪明。
隐性功能复刻陷阱。 在工程实践中观察到，Agent 联调时会自动补全你没明说的功能。这意味着你的验证环节必须专门防守这一点——不能默认「我没要求它就不会做」。这条直接对应「验证的完整性」：测它做了什么，而不只是测它做了你要求的。
可操作做法
当你的 Agent 交付不了，按下面的顺序走，不要跳步：
- 先归因，再动手。 问自己：这是司机问题（模型推理不动）还是车的问题（工程缺陷）？没有证据证明是前者，就默认是后者。
- 拿五子系统当排错清单。 Tools / Knowledge / Observation / Action / Permissions 逐栏过，定位先亮红灯的那一栏。
- 抵制「再加个 if-else」的冲动。 每次你想用分支硬编码补一个 case，停一下——你是在搭基础设施，还是在造鲁布·戈德堡机器？
- 把规范从模型记忆迁到文件系统。 能写进确定性文件（规范文档 / 钩子 / 记忆）的，就别留在 prompt 里靠模型自觉。
- 给状态找个磁盘上的家。 任务状态持久化，支持断点续跑；并发优先用目录隔离而非加锁。
- 设权限边界，且默认收紧。 通话时长、合规词、动作白名单先立起来。没有边界的 Agent 不是更自由，是更危险。
- 给记忆设上限。 紧凑文件加硬字符上限，全量历史另存可搜。
- 验证要防隐性补全。 测 Agent 实际做了什么，专门为「它自作主张多做的事」写检查。
- 换模型放在最后。 上面都过了一遍、确认根因在司机而非车，再谈换模型。
收口
模型是司机，Harness 是车。交付不了的时候，先检查车，别急着换司机——最好的 Agent 产品，来自把自己的工作理解成「造车」而非「造智能」的工程师。