前面讲了模型、循环、工具、上下文、记忆、MCP、Skills。把这些组装起来、让 Agent 真正跑起来的那层程序，叫做运行框架，业内常称 Harness。同一个模型，放在不同的 Harness 里，表现可能天差地别。

一、Harness 是什么

回顾第 04 篇的 Agent Loop，那几十行代码就是一个最简单的 Harness。模型只负责「想」，其余所有事情都由 Harness 来做：

             ┌──────────── Harness ────────────┐
用户 ──────▶ │ 组装上下文 → 调用模型 → 解析输出  │
             │      ▲                  │         │
             │      │            工具调用？      │
             │      │                  ▼         │
             │  回填结果 ◀── 权限检查 → 执行工具 │
             └──────────────────────────────────┘

常见的 Agent 产品（编码助手、桌面助手等）以及各种 Agent 开发框架，本质上都是 Harness 的不同实现。

二、Harness 的核心职责

1. 组装上下文

每次调用模型前，决定放进去什么：System Prompt、工具定义、Skills 的名称和描述、记忆、历史消息。第 07 篇讲的上下文工程，大部分都在这里实现。

2. 管理工具

• 注册内置工具（读写文件、执行命令、搜索网页等）；
• 连接 MCP Server，把它们的工具合并进来；
• 执行工具调用，处理超时和错误，把结果整理后回填。

3. 权限控制

模型请求执行一个操作，Harness 决定允不允许：

• 直接允许：只读操作，比如读文件、查数据。
• 询问用户：有副作用的操作，比如修改文件、发送消息、执行命令。
• 直接拒绝：明确禁止的操作，比如删除系统文件、访问不在白名单里的地址。

好的 Harness 让用户可以配置这些规则，比如「这个目录里的文件可以随便改，其他目录要问我」。

4. 上下文压缩

监控上下文长度，接近上限时自动压缩历史（第 07 篇）。用户感觉不到，但长任务能一直进行下去。

5. 子 Agent 调度

提供一个「启动子 Agent」的工具，负责为子 Agent 创建独立的上下文、限制它能用的工具、收集它的结果（第 11 篇）。

6. 状态与持久化

保存会话记录，支持中断后恢复；管理待办列表、记忆文件这些跨步骤的状态。

三、Hooks：在关键节点插入自己的逻辑

很多 Harness 提供 Hooks（钩子）机制：在特定事件发生时，自动运行你写的脚本。常见的触发点：

Hooks 的价值在于确定性。你可以在提示词里写「每次改完代码都要运行测试」，但模型可能会忘；写成 Hook，就一定会执行。一个实用的原则是：必须每次都发生的事，用 Hook；需要判断的事，交给模型。

四、为什么 Harness 决定了 Agent 的上限

模型能力是基础，但很多体验上的差异来自 Harness：

• 工具设计得好不好，决定了模型能不能高效完成任务；
• 上下文管理得好不好，决定了长任务会不会中途崩溃；
• 权限设计得好不好，决定了用户敢不敢放手让它干活；
• 错误处理得好不好，决定了遇到意外时是自动恢复还是直接失败。

这也是为什么用同一个模型，不同产品的效果差别很大。

五、自己写还是用现成的

建议的学习路径：先自己写一个最小 Harness 理解原理（第 04 篇的练习），再用现成产品加上自己的 MCP Server 和 Skills 解决实际问题，真有需要再用框架开发专门的 Agent。

本篇小结

• Harness 是模型之外的那层运行程序，负责除「思考」以外的一切。
• 核心职责：组装上下文、管理工具、权限控制、上下文压缩、子 Agent 调度、状态持久化。
• Hooks 在关键节点运行确定性逻辑：必须每次发生的事用 Hook，需要判断的事交给模型。
• Harness 的质量很大程度上决定了 Agent 的实际表现。

思考与练习

• 如果你要做一个帮团队查业务数据的 Agent，它的 Harness 需要哪些 Hooks？
• 列出你的 Agent 中「直接允许」「询问用户」「直接拒绝」三类操作各有哪些。

上一篇：AI Agent原理篇14：Skills：按需加载的能力包
下一篇：AI Agent原理篇16：Agent 间通信：A2A 等协议
返回系列总目录