适用读者：要判断"我的问题该换模型还是换接口"、要给 Agent 划边界（它能看什么、能动什么）的人。
前置：S21-B01（Agent 是什么）、B02（ReAct）。
覆盖旧文：A-4567（AI Agent 入门，第 1 章，37,199 字符）→ 16 小节 / 约 3.7 万字符。
扩展点：E-S21-026（Model–Harness 两层抽象）、E-S21-027（观察空间/动作空间是工程杠杆）、E-S21-028（五类工具与四步工具调用）。
上一篇：S21-J07 · ADK 多智能体编排
下一篇：S21-J09 · 上下文工程。
1. 一句话结论
"更聪明的模型"通常不是解法，"更大的观察空间 + 动作空间"才是。 模型固定时，Agent 的表现主要由两件事决定：它能看见什么（上下文）和它能做什么（工具）。没有进入上下文的观察，对模型等于不存在；没有被动作接口允许的操作，模型再懂也只能停在建议层面。
出处：《AI Agent 深入理解》第 1 章（
A-4567）。
Agent = LLM（策略） + 上下文（观察与历史） + 工具（观察/行动接口）
2. 两层抽象：Agent ↔ Environment，Model ↔ Harness（E-S21-026）
外层：Agent ⇄ Environment（文件、数据库、网页、用户、其他 Agent、物理世界）
内层：Model（策略） + Harness（构造上下文、暴露工具、维护循环与状态、权限/验证/纠正）
| 层次 | 含什么 | 边界 |
|---|---|---|
| Agent ↔ Environment | 观察流入、行动流出，环境状态随之改变 | 环境有自己的转移规律，不属于 Agent |
| Model–Harness | Harness 环绕模型，是"模型之外"的全部工程 | Harness 可以创建/隔离/代理环境，但不包含环境状态 |
判据："上下文 + 工具"就是最小 Harness；生产系统再往里加约束、验证、纠正。分清这两层，才能回答"这个 bug 该改模型还是改工程"。
2.1 三个组件与学术概念的映射（不是一一等同）
| 直觉 | 实现 | 学术 | 含义 |
|---|---|---|---|
| 大脑 | LLM | 策略 π | 面对当前信息挑下一步动作 |
| 眼睛 | 上下文构造 | 观察与历史 | 把观察与轨迹组织成决策输入 |
| 手脚 | 工具与适配器 | 观察/行动接口 | 能读什么、能发什么、什么格式 |
注意：上下文 ≠ 整个观察空间（它只是被选进来的那部分）；工具定义接口，工具背后的对象仍属于环境。
3. 观察空间与动作空间：真正的工程杠杆（E-S21-027）
没有进入观察通道 → 对模型不存在
没有被动作接口允许 → 只能给建议
| 产品 | 眼睛（感知） | 手脚（行动） | 策略 |
|---|---|---|---|
| Coding Agent（Cursor 类） | 需求、代码片段、目录、终端输出 | 开放式：搜索/读写文件/执行命令 | 增量开发：理解→搜索→编辑→测试→修复 |
| Deep Research | 搜索结果、网页、摘要与引用 | 开放式：查询、读页、生成报告 | 迭代深化 |
| Browser Use | 截图、DOM/无障碍树、操作结果 | 点击、输入、滚动、执行代码 | 视觉感知 + 操作 |
| 手机助手 | 截图、App 界面状态 | 点击、滑动、输入、开 App | 意图理解 + App 操控 |
| 个人办事 Agent | 授权后的账单、服务商资料 | 打电话、发邮件、填表、与用户确认 | 多步执行与协商 |
共同特征：开放式动作空间（不是选按钮，而是生成代码/自然语言）、内部思考、持续交互。
两个产品案例，说明"扩展空间"就是产品演进：
| 产品 | 扩了什么 | 结果 |
|---|---|---|
| Manus | 合并 Deep Research / Coding / Computer Use 三套空间：虚拟浏览器 + 文件系统 + 代码与命令行 | 一个 Agent 跨过三条产品边界 |
| OpenClaw | 接入 WhatsApp/Telegram/Slack/Discord/iMessage；本地 Gateway 连 Drive/Notion/本地文件 | 数字生活整体进入观察空间（需用户授权） |
判据："任务不可解"先当作"接口不足"来排查：数据是否进了上下文？操作是否被封成了工具？
4. 五类工具与四步调用（E-S21-028）
| 类 | 方向 | 例子 |
|---|---|---|
| 感知 | 环境 → Agent | 搜索、文件读取、API/数据库查询 |
| 执行 | Agent → 环境 | 代码执行、文件写、系统命令、外部 API |
| 协作 | Agent ↔ Agent/人 | 委托子 Agent、请人确认、多 Agent 协调 |
| 事件触发 | 外部 → Agent 启动 | 新邮件、定时、Webhook（不是主动调用） |
| 用户沟通 | Agent → 用户 | 文字、语音、邮件（传信息而非改世界） |
四步循环：
① 上下文里声明工具（名称/用途/参数）
② 模型决定：调不调、调哪个、传什么
③ 框架执行，把结果追加回上下文
④ 模型据此决定下一步 —— 回到 ①/②
# 核心循环（伪代码；生产必须加 max_iterations）
while True:
r = client.chat(model=MODEL, messages=messages, tools=tools)
m = r.choices[0].message
messages.append(m) # 模型回复（含 tool_calls）
if not m.tool_calls: # 没有调用 → 收尾
print(m.content); break
for tc in m.tool_calls: # 有调用 → 执行并回填
messages.append({"role": "tool", "tool_call_id": tc.id,
"content": execute(tc.function.name, tc.function.arguments)})
判据：Agent 框架的核心工作就是"管好这个 messages 列表"。 后文所有上下文技术（J09）本质上都在优化这个列表的内容与结构。
5. 反例与排障
| 现象 | 根因 | 处理 |
|---|---|---|
| 工具被乱用 | 描述含糊、参数语义不清 | 改工具描述与 schema（J11） |
| 工具失败后死循环 | 无错误语义、无上限 | 结构化错误 + 迭代上限 |
| 权限过宽出事 | 动作空间没设边界 | 白名单 + 人工确认（A02） |
| 模型"知道但不做" | 操作没被封装成工具 | 补工具，而非换模型 |
| 上下文缺失导致重复问 | 观察通道没接 | 接数据源，而非加提示词 |
6. 常见误区
| 误区 | 纠正 |
|---|---|
| "能力不够就换更大的模型" | 多数是接口不足（观察/动作空间） |
| "上下文就是 prompt" | 上下文 = 静态前缀 + 轨迹 |
| "工具越多越强" | 工具越多，选择成本越高（J11） |
| "Agent 包含环境" | 环境有自己的规律，Agent 只是接口方 |
| "Harness 是框架细节" | 它是模型之外的竞争力所在 |
7. 自测
- Model–Harness 与 Agent–Environment 两层各管什么？为什么环境不属于 Agent？
- 为什么说"没有进入观察通道的信息对模型不存在"？
- 五类工具中，哪一类不是 Agent 主动调用的？
- 模型"知道该做却不做"，最可能缺什么？
答案
- 内层管决策与上下文/工具/循环；外层管交互。环境有独立状态转移，Agent 只能通过接口影响它。
- 模型的输入只有上下文；没被选进上下文的观察不参与决策。
- 事件触发工具（由外部事件驱动）。
- 缺动作接口——该操作没被封装成工具。
8. 下一篇
S21-J09 · 上下文工程 —— 静态前缀 + 轨迹的结构、KV Cache 友好的布局、压缩时该保什么，以及为什么"前面不能动、后面可以压"。
本篇属于系列《S21 · Agent 工程与 MCP》。旧文来源：A-4567（《AI Agent 深入理解》第 1 章）；扩展点 E-S21-026/027/028。产品资料引用见原文脚注。