AI Agent 的缰绳：什么是 Harness，为什么它比模型本身更重要
大模型会聊天，但不会干活。真正让 AI Agent 能接住复杂任务的，不是模型有多聪明，而是外面裹着的那层"缰绳"——Harness。
一个真实的场景
你让 AI 帮你做一件事："查一下最近的天气，写一段播报文稿，用女主持人的声音生成音频，发到飞书群里。"
这件事至少涉及四个步骤、三个外部 API、两种文件格式。大模型能理解你的意思，但它自己完不成——它不会调 API，不会管理文件，不知道上一步的输出怎么喂给下一步，更不知道 API 挂了该怎么办。
把这些"模型做不了的事"全部管起来的那一层，就是 Harness。
Harness 是什么
直译是"挽具"——套在马身上的那套缰绳、马鞍和辔头。马有力气，但没有挽具，它就是一匹野马，想跑哪跑哪，拉不了车也犁不了地。
放到 AI 的语境里：
| 比喻 | 实际含义 | |
|---|---|---|
| 大模型 | 烈马 / 发动机 | 语言理解、推理、生成能力 |
| Harness | 缰绳 + 马鞍 + 赛道 + 刹车 | 执行调度、状态管理、异常处理、输出规范 |
| AI Agent | 骑手 + 马 + 全套装备 | 大模型 + Harness + 工具集 |
Harness 不增加马力。它的价值是：让已有的马力跑在正确的路上，不翻车，不跑偏，能回头。
Harness 具体管什么
拆开来看，Harness 干的事情可以分成五个层面：
1. 调度循环（Orchestration Loop）
一个 Agent 的核心是一个循环：模型生成响应 → 如果有工具调用就执行 → 把结果喂回去 → 模型再生成 → 直到任务完成。
这个循环本身就是 Harness 的核心逻辑。它要决定：
- 什么时候调用工具，什么时候直接回复
- 什么时候追问用户要更多信息
- 什么时候判定任务已完成
- 超过多少轮该强制停止（防止死循环）
看起来简单，但实际上每一个判断都是工程决策。比如模型说"我来帮你查一下"，但没有产出任何工具调用——Harness 需要识别这种"空转"并处理。
2. 状态与记忆管理（State & Memory）
大模型是无状态的。每次调用，它只看到你喂给它的那些消息。Harness 负责维护整个对话的状态：
- 对话历史：哪些消息该保留，哪些可以压缩
- 上下文窗口管理：模型有 token 上限，快超了怎么办？丢弃早期消息？还是做摘要压缩？
- 跨会话记忆：上周聊的事情，今天还记不记得？
- 任务状态：一个多步任务做到第几步了，中间结果存在哪
没有这层管理，模型就像一条金鱼——每隔几分钟就忘了所有事。
3. 上下文工程（Context Engineering）
这是最容易被低估的部分。每一步给模型看什么信息，直接决定了它的表现。
- 系统提示词怎么组装（角色设定、技能列表、用户偏好、当前时间……）
- 工具返回的结果太长怎么办（一个搜索返回 50KB 文本，全塞进去模型会晕）
- 多个工具并行调用时，结果怎么拼接
- 敏感信息（API Key、用户隐私）怎么脱敏
好的上下文工程能让一个中等模型表现得像顶级模型。差的上下文工程能让顶级模型表现得像废物。
Andrej Karpathy 最近说的那句话："Context engineering is the new prompt engineering"——上下文工程正在取代提示词工程，成为 AI 应用开发的核心技能。 他的意思不是 prompt 不重要了，而是单靠一句好 prompt 已经不够用了。当你的 Agent 要处理多步任务、调用多个工具、管理长对话时，每一步给模型看什么、不看什么、怎么组织，才是真正决定成败的地方。
4. 工具编排（Tool Orchestration）
Agent 的"手"是工具——搜索、文件操作、代码执行、API 调用。Harness 管理整个工具生命周期：
- 工具注册与发现：有哪些工具可用，它们的参数是什么
- 参数校验：模型填的参数合不合法
- 执行与重试：调用失败了重试几次，超时了怎么处理
- 结果处理：工具返回的原始数据怎么格式化后喂给模型
一个实际的例子：模型想调用一个文件读取工具，但给了一个不存在的路径。Harness 捕获错误，把"文件不存在"这个信息告诉模型，模型再尝试换一个路径。这个"出错 → 反馈 → 重试"的循环，全靠 Harness 驱动。
5. 安全与合规（Safety & Governance）
模型可能产出危险操作——删除文件、执行 rm -rf /、泄露敏感信息。Harness 是最后一道防线：
- 危险命令检测：识别高风险操作，拦截或要求人工审批
- 输出格式规范：确保回复符合预期格式
- 权限控制：哪些工具在哪些场景下可用
- 审计日志：记录每一步操作，出了问题可以追溯
Harness vs Prompt vs Agent
这三个概念经常被混用，但它们是不同层次的东西：
| 维度 | Prompt | Harness | Agent |
|---|---|---|---|
| 本质 | 一段文本指令 | 一套运行时系统 | 一个自主行为体 |
| 解决的问题 | 让模型"听得懂" | 让模型"做得稳" | 让模型"能干活" |
| 生命周期 | 单次交互 | 持续运行 | 任务全程 |
| 类比 | 对马说"走" | 缰绳 + 马鞍 + 赛道 | 骑手 + 马 + 装备 |
Prompt 是一句话，Harness 是一套系统，Agent 是一个角色。
Prompt 告诉模型"你是一个助手，请帮我做 XXX"。Harness 确保模型在做 XXX 的过程中不会跑偏、不会卡住、不会搞砸。Agent 是最终面向用户的那个"能干活的 AI"。
为什么说 Harness 比模型更重要
这话听起来有点反直觉，但在工程实践中是成立的。
同一个模型，配上不同的 Harness，表现天差地别。 GPT-4 配上一个粗糙的循环（调用 → 返回 → 结束），和配上一个成熟的 Harness（带重试、带记忆、带上下文压缩、带错误恢复），完成复杂任务的成功率可以差三到五倍。
反过来，一个中等模型配上优秀的 Harness，往往比一个顶级模型配上简陋的 Harness 表现更好。 因为复杂任务失败的原因，大多数时候不是"模型不够聪明"，而是"上下文丢了""工具调用失败没处理""跑到第七步忘了第一步在干嘛"。
这就是 Harness 的价值：它不提升智商，但它防止犯蠢。
一个具体的例子
用一个真实场景来看 Harness 的每个组件怎么协作：
用户说："帮我把昨天的新闻整理成一个播客，用女主持人和男嘉宾的声音，发到飞书群。"
调度循环启动：
- 模型理解任务，决定先搜索新闻 → Harness 执行搜索工具
- 搜索返回 5 条新闻，太长了 → 上下文工程介入，裁剪到关键信息
- 模型根据裁剪后的内容写出对话脚本 → Harness 保存到文件
- 模型调用音频生成 API → API 超时了 → 工具编排自动重试
- 重试成功，得到音频文件 → Harness 记录文件路径（状态管理）
- 模型调用飞书发送 → 发送成功 → 循环结束
整个过程中，模型只做了三件事：理解意图、写脚本、决定调用什么工具。剩下的全是 Harness 在干。
如果没有 Harness，第 4 步 API 超时后模型会直接告诉用户"生成失败了"——任务就废了。有了 Harness，它会自动重试，甚至在 API 持续不可用时切换到备选方案。
构建 Harness 的关键设计决策
如果你正在构建自己的 Agent 系统，以下是几个核心设计决策：
循环策略
- ReAct 模式：思考 → 行动 → 观察 → 思考……最经典的循环
- Plan-then-Execute：先规划所有步骤，再逐步执行
- 混合模式：先粗规划，执行中动态调整
上下文管理策略
- 滑动窗口：只保留最近 N 条消息
- 摘要压缩：用另一个模型把早期对话压缩成摘要
- 分层记忆：短期记忆（当前对话）+ 长期记忆（跨会话持久化）
错误处理策略
- 自动重试：工具调用失败，等几秒重试
- 降级方案：主工具不可用，切换备选
- 人工兜底：多次失败后，请求用户介入
安全策略
- 白名单 vs 黑名单：只允许特定操作 vs 禁止特定操作
- 审批机制：高风险操作需要人工确认
- 沙箱隔离：代码执行在隔离环境中运行
写在最后
大模型的能力在飞速进步，但"能力强"和"能干活"之间，永远隔着一层工程。
Harness 就是这层工程。它不性感，不会上新闻头条，但它是决定一个 AI Agent 能不能真正投入生产的关键。
下次有人问你"AI Agent 是怎么工作的"，别只说"用了 GPT-4"。告诉他：模型负责想，Harness 负责管。没有 Harness 的模型，就是一匹没有缰绳的野马——跑得快，但你骑不了。