Agent开发入门系列第 1 篇 · 读这一篇需要 5 分钟
你有没有遇到过这种情况：看 AI Agent 的文章，每篇都在讲新概念，看完还是说不清它到底是什么。
那我们换个做法。这一整个系列只干一件事：把那些密度极高的概念，一个一个拆开、揉碎、讲透。每篇只讲 1-2 个知识点，不赶进度。
从最基础的那个公式开始。
一、一个公式，三样东西
原书开篇给出了一个公式，我认为它是理解整个 Agent 领域的钥匙：
Agent = LLM（大语言模型）+ 上下文 + 工具
如果觉得太抽象，作者给了一个更好记的版本：
Agent = 大脑 + 眼睛 + 手脚
这三个比喻不是修辞，而是严格的职责划分。让我们逐个拆开。
大脑：LLM 负责"想"
LLM 在 Agent 里承担的职责，其实可以精确列成一份清单：
- 理解用户的真实意图（而不只是字面意思）
- 思考、规划、拆解复杂任务
- 选择下一步行动
- 决定是否调用工具
- 决定调用哪个工具
- 生成工具的调用参数
- 根据结果继续判断
注意这份清单里没有一项是"执行"。LLM 从头到尾只做一件事：产出决策。它自己不查数据库、不读文件、不发邮件、不跑代码。所有真实动作，都发生在它看不见的地方。
这里有个容易被忽略的细节：LLM 的决策能力不是凭空来的。它主要来自两类训练------
预训练 ：在海量互联网文本上训练，学到语言规律、世界知识，以及问题分解的策略。这一层给模型的是"结构化经验的直觉"。
后训练：通过监督微调、强化学习等手段，把"决策"这件事固化为模型能力。这一层给的才是"什么时候该动手"的判断力。
这个区分后面会反复出现------第 6 篇讲"模型即 Agent"时，会详细拆解哪些能力被内化进了参数、哪些永远留在模型之外。
眼睛：上下文负责"看"
上下文是 Agent 在每一个决策点上接收并保留的全部信息。
这个定义比大多数人第一反应的要宽。它不只是"用户刚说的那句话"，而是一个复合体：
| 组成 | 内容 |
|---|---|
| 环境观察 | 读到的文件内容、网页、数据库记录、终端输出 |
| 用户记忆 | 这个用户的偏好、历史习惯 |
| 领域知识 | RAG 检索出来的外部资料 |
| 自身状态 | 当前处于哪个阶段、已经做过什么 |
| 任务进展 | 还剩哪些步骤没完成 |
| 历史消息 | 之前的每一轮对话 |
| 工具结果 | 每一次工具调用的返回值 |
进入上下文的信息，决定了模型能够感知到什么。
这句话是整个系列的钥匙之一，我们在下一篇会展开它的工程含义。现在只需要记住：上下文不是"输入框里的文字"，而是 Agent 的全部感知输入。
手脚：工具负责"做"
工具是 Agent 与外部世界交互的接口，分成三个方向：
- 感知外部信息 --- 读文件、搜索、查数据库
- 改变外部状态 --- 写文件、跑代码、调 API
- 与他人协作 --- 委托子 Agent、请人确认
但"工具"这个词容易让人以为它就是几个函数或 API。真实的工具系统还包括：
- 工具定义（名字、功能、参数格式）
- 调用协议（怎么发起、怎么收回结果）
- 适配器（把不同来源的工具统一成同一套调用方式）
- 代码执行沙箱
- 子 Agent 委托机制
- 主动与用户沟通的通道
同样是"工具"，一个孤零零的 get_weather() 函数和一个完整的工具系统，能力差距是数量级的。
二、更精确的公式：Agent = Model + Harness
上面那个公式还有一层。真正跑在生产环境里的 Agent，光有"大脑+眼睛+手脚"是不够的。
于是有了第二个公式：
Agent = Model + Harness
Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正
这两个 Agent 概念就分成了两层：
**Model（模型层）**只负责三件事：理解上下文、制定策略、决定下一步。
**Harness（运行治理层）**环绕在模型周围，负责：构造上下文、暴露工具接口、管理运行循环、维护状态和轨迹、实施权限、执行验证、纠正错误。
Harness 到底是什么东西？
这是全书最容易被误解的词。很多人的第一反应是"限制模型的框架"。恰恰相反------Harness 是为了把模型能力引导到正确方向而存在的。
打个比方：Model 是一匹马，Harness 是缰绳、挽具、马车和车夫。
- 缰绳 --- 约束（不让它往悬崖跑）
- 挽具 --- 让它的力气用对地方
- 马车 --- 装载工具，承载状态
- 车夫 --- 验证结果、纠正错误、决定何时停下
车夫不会削弱马的能力。相反，越强的马越需要好的车夫------因为它跑得越快、越自主，出错时的影响范围也越大。
一个必须分清的边界
Harness 和 Environment 不是一回事。这是原书特别强调、也最容易被跳过的一点：
Harness 可以创建、隔离或代理一个环境，却不因此包含环境自身的状态与转移规律。
举三个例子就清楚了：
| 东西 | 归属 |
|---|---|
| 沙箱的权限设置、重置机制 | Harness |
| 沙箱里的文件、进程、运行状态 | Environment |
| 数据库的行级安全、约束、校验器 | Environment 侧机制，或由 Harness 调用的校验能力 |
Harness 管的是"怎么访问环境"，Environment 管的是"环境本身是什么样"。
三、完整的图景：闭环
把两层结构画出来，Agent 的完整样貌是这样的：
图里有两层抽象，需要分开看。
外层是 Agent 与 Environment 的闭环。 Environment 向 Agent 提供观察，Agent 通过行动改变 Environment，新的状态产生新的观察，循环持续。Environment 可以是文件、数据库、网页、用户、其他 Agent、物理世界、仿真世界。
内层是 Model--Harness 结构。 Model 做策略决策，Harness 是环绕它的运行与治理层。
注意图里那两支方向相反的箭头，它们是整个系统的命脉：
- 观察（Environment → Agent）：Harness 把环境状态翻译成模型能理解的上下文
- 行动（Agent → Environment）：Harness 把模型的选择翻译成环境可执行的操作
没有这两支箭头，Agent 只是一个在文本框里说话的人。
四、两条边界，比能力更值得记住
原书提出了两个非常锋利的判断，我觉得是全章最有价值的部分之一。
边界一：观察空间决定"能不能想到"
没有进入上下文的信息，对模型而言等同于不存在。
哪怕信息就在环境里躺着------数据库里有这条记录、磁盘上有这个文件、网页上有这段说明------只要它没被 Harness 转换成上下文放进那个窗口，模型就完全不知道它存在。
这就是为什么一个"数据库明明有数据，Agent 却说查不到"的 bug，根因往往不在模型，而在 Harness 的上下文构造策略。
边界二：动作空间决定"能不能做到"
没有被动作接口允许的操作，即使模型知道怎么做，也只能停留在文字建议层面。
一个模型完全知道应该怎么给你的数据库加索引，但它手里没有执行权限，那它能做的最多是给你一段 SQL 文本。
把这两条合起来，得到一个反直觉但极其重要的工程结论：
在底层模型固定时，提高 Agent 能力最有效的工程手段之一，是扩充上下文和工具、改善观察通道和动作接口------而不是换一个更强的模型。
用一张表看清各家的能力差异
原书用"眼睛 / 手脚 / 策略"这三个维度，对比了五类典型 Agent：
| 产品类型 | 眼睛：感知 | 手脚：行动 | 策略 |
|---|---|---|---|
| Cursor 类 Coding Agent | 需求、代码片段、目录结构、终端输出 | 搜索、读写文件、执行命令 | 理解需求→搜索→编辑→测试→调试 |
| Deep Research | 搜索结果、网页、论文和引用 | 搜索、读网页、生成报告 | 迭代深化和综合 |
| Browser Use | 截图、DOM、无障碍树、操作结果 | 点击、输入、滚动、截图、代码执行 | 观察→识别→操作→验证 |
| 手机助手 | 截图、App 状态、系统反馈 | 点击、滑动、输入、打开 App | 意图理解→定位 App→操作→确认 |
| 个人办事 Agent | 账户记录、账单、服务商资料 | 打电话、发邮件、填表单、确认 | 收集→制定策略→联系→谈判→汇报 |
看出规律了吗？它们的"策略"部分几乎长得一样------都是观察、判断、行动、修正。差异全在眼睛和手脚上。
这印证了开头那个公式：真正拉开产品差距的，是观察空间和动作空间的并集，而不是"脑子"有多好。
五、Manus 为什么让人觉得"什么都能干"
拿 Manus 当例子特别能说明问题。
Manus 本身没有发明新算法，它的厉害之处是把原本相对独立的三类能力合并到了一起：
- Deep Research 的信息获取
- Coding 的代码执行
- Computer Use 的界面操作
而这些能力边界的来源非常朴素------它挂了什么：
| 挂载的东西 | 扩大了哪一维 |
|---|---|
| 虚拟浏览器 | 观察空间（能看见网页内部结构，而不只是截图） |
| 文件系统 | 文件和资源的访问能力 |
| 代码执行 | 计算能力（从"会说"变成"会算"） |
| 命令行执行 | 系统操作能力 |
核心不是它换了一个更强的模型，而是它扩大了观察空间和动作空间的并集。
后来 OpenClaw 走得更远，把接口接到 WhatsApp、Telegram、Slack、Discord、iMessage、Google Drive、Notion 和本地文件系统上，特点是本地优先、常驻个人助手、多消息渠道接入、云服务与本地能力结合。
而 Manus 后来也加入了 Google Drive 连接器和桌面端本地访问。
这两个产品的演进方向，恰好印证了本章的主张：Agent 产品能力的发展，很大程度上就是观察空间与动作空间的发展。
六、什么时候这个公式会失效
写到这里该说边界了。这个公式很好用，但它有明确的适用边界，说清楚比吹得天花乱坠更有价值。
第一，它不适用于纯问答场景。 如果任务就是"解释这段代码"，不需要任何工具、不需要任何环境反馈，那么"眼睛"和"手脚"都是空的------直接调 LLM 更快、更准、更便宜。给一个翻译任务套上 Agent 循环，是纯粹的浪费。
第二，它不适用于步骤完全确定的流程。 如果业务逻辑是"校验身份 → 搜索航班 → 付款 → 出票"，每一步都已经写死了，那 Agent 的"自主决策"能力不仅没用，还会引入不确定性。这类场景应该用确定性工作流，模型只负责节点内部的自然语言理解。
第三，它假设了 Harness 的存在，但 Harness 不是免费的。 完整的 Agent 需要上下文压缩、权限管理、验证纠错、沙箱隔离------这是一整套工程投入。任务简单时，这套投入的收益覆盖不了它的成本。这也是为什么"能跑起来"和"能可靠地完成任务"之间隔着十万八千里，后者才是 Harness 工程要解决的问题。
第四，它描述的是结构，不是质量。 三件套齐了不代表 Agent 就有用。上下文塞满了无关噪声、工具命名含糊不清、约束和业务规则对不上，一样会得到一个废物 Agent。组件是必要条件，不是充分条件。
小结
这一篇只做了一件事：把整个 Agent 领域的骨架立起来。
ini
Agent = LLM（大脑）+ 上下文（眼睛）+ 工具（手脚）
Agent = Model + Harness
Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正
Agent ↔ Environment（闭环）三条必须记住的边界：
- 没进上下文的信息 = 不存在
- 没被动作接口允许的操作 = 做不到
- 模型固定时，扩上下文和工具往往比换更强的模型更有效
下一篇，我们钻进"眼睛"里。把上下文的五个组成部分彻底拆开，看看每一块到底装了什么、有多重要、以及删掉它会发生什么。
下一篇：《上下文：Agent 的眼睛里到底装着什么》
关注这个系列，我会持续更新。觉得有用的话，欢迎点个赞------它会让我更有动力把下一篇写好。