AI Agent 入门

这个加号是工程组件的组合，不是强化学习里的形式化定义。公式只描述 Agent 边界之内的实现，不包含它交互的环境。环境给出观察，Agent 依据上下文选行动，行动改变环境状态，新状态再产生新观察——这是一切 Agent 交互的最小结构。

LLM 对应 Model；“上下文 + 工具”就是最小的 Harness。生产系统再在 Harness 里加约束、验证与纠正。Harness 可以创建、隔离或代理一个环境，但不包含环境本身的状态与转移规律。

这是映射，不是一一等同：上下文是观察与历史在 Agent 内部的表示，不等于整个观察空间；工具定义接口，工具背后的对象仍属于环境。

Harness 把环境观察转成上下文，再把模型选的行动转成工具调用。没进入上下文的信息，对模型等于不存在；没被动作接口允许的操作，模型知道怎么做也只能停在文字建议。

模型固定时，提升 Agent 表现最主要的工程手段，就是扩展观察空间与动作空间——也就是扩展上下文和工具。很多看似需要“更聪明的模型”的问题，其实是接口问题。

五类 Agent 产品，按三个维度拆

共同点：动作空间都是开放式的（能生成任意自然语言和代码，而非从几个按钮里选）；都会在行动前内部思考；都根据环境反馈持续调整。

感知类工具承载“环境 → Agent”的观察，执行类工具承载“Agent → 环境”的行动。按互动方向可分五类（完整体系见第四章）：

工具设计质量决定 Agent 能走多远：接口不清，模型就乱用；错误处理不到位，调用一失败就可能死锁；权限太宽，出错后难以挽回。

// ① 声明工具（开发者写在上下文里）tools: [{ name: "get_weather",  parameters: { city: "string" } }]

// ② 模型决定调用assistant: { tool_calls: [{  function: "get_weather",  arguments: { city: "北京" } }] }

// ③ 框架执行，结果追加到上下文tool: { tool_call_id: "call_1",  content: '{"temp":28,"sky":"晴"}' }

// ④ 模型基于结果回复assistant: {  content: "北京今天28°C，晴。" }

通用工具 vs 专用工具：从最窄的能力起步

通用基础能力用于组合与探索；专用工具用于约束高风险和强业务规则的操作。

收到请求后，LLM 要先解析真实意图（用户说的常常不是真正想要的），再拆成可执行步骤，执行中不断判断：下一步做什么、调不调工具、调哪个、传什么参数。它还能内部思考：行动前先推演，不改变环境却显著提升行动质量。推演依托预训练沉淀的数学定律、因果关系、分解策略，所以不像传统 RL Agent 那样盲目随机探索。

模型即 Agent，但模型越强，Harness 越关键

先进模型通过后训练（尤其 RL）把工具调用内化为原生能力。Harness 原意是马具：不是限制马跑，而是把力量引到正确方向。模型自主空间越大，出错影响面越大，越需要更精细的约束、验证与纠正。

RL 写进参数的是“决策”——何时调、调哪个、传什么、拿到结果是否继续；工具本身和执行仍在模型之外的基础设施里。

《苦涩的教训》：Harness 会被模型吃掉吗

Sutton 回顾 AI 七十年：把人类领域理解编码进系统，短期见效，长期总输给随算力扩展的搜索与学习。本书立场是方向认同，节奏务实：训练以月计，模型也不能一次内化所有业务约束；模型此刻的能力边界，就是 Harness 此刻的价值。仅在本章里，这种“吃掉”就已发生了几轮：

图 1-2 · Agent 的行为如何改变：三个时间尺度

上下文是每个决策点能看到的全部信息，就像决策时桌上摊开的资料。从 API 看，每次调用 LLM 的上下文由五部分组成：

上下文决定 Agent 能看到什么，Agent 只能基于它看到的做决策。但组件并不等价：衡量标准是它承载的信息能否从别处重建。而且“给出了回答”不等于“完成了任务”——上下文残缺时，典型失败不是报错，而是一个看上去毫无破绽的答案。换个模型，同一个消融完全可能得出不同结论，要靠实测。

ReAct = Reasoning + Acting，实际有三环：思考该做什么，调用工具行动，观察结果再想下一步。轨迹是这一过程中不断累积的消息：用户消息、模型回复（思考 + 工具调用）、工具结果。

Agent 的上下文 = 静态前缀 + 轨迹。每次调用 LLM 都把前缀拼在整条轨迹前面；LLM 的输出又追加进轨迹，供下一次调用使用。

trajectory = [user_request]repeat:  context = stable_prefix + trajectory  decision = Model(context)  trajectory.append(decision)  if decision has no tool call:    return decision.answer  for call in decision.tool_calls:  # 独立调用可并行    validated = Harness.validate(call)    obs = Environment.execute(validated)    trajectory.append(obs)

基本机制能跑，但也暴露出脆弱点：幻觉出不存在的工具或参数、选错工具、出错后无法自救。能跑的 Demo 和可靠的产品之间隔着一道鸿沟，Harness 工程就是填它的。Harness 是Agent 边界内、模型之外的运行与治理层：工具定义、调用适配器、沙箱的权限与重置机制属于 Harness；沙箱里随行动变化的文件和进程、数据库、网页、用户、物理世界属于 Environment。即使仿真环境和 Agent 跑在同一进程，它仍是 Environment。

observation = Environment.observe()trajectory = [observation]while true:  actions = Model(Harness.build_context(trajectory))  if len(actions) == 0: break  allowed = Harness.constrain(actions)  observation = Environment.apply(allowed)  if not Harness.verify(Environment):    observation = Harness.correct(Environment)  trajectory.append(allowed, observation)

上下文与工具让 Agent“能做事”；约束预防错误、验证发现偏差、纠正闭合回路，让它“不做错事”。早期框架只关心前者，生产级系统的重心已转向后者。以 Claude Code 为例，Harness 中绝大部分代码是约束、验证与纠正，工具本身只占一小部分。

例：退款 Agent 把政策放进上下文，用权限和金额规则约束调用，用数据库状态验证结果，超时就重试或回退。

1.2.1 · 五波工程范式：层层包含，不是替代

1.2.2 · 构建有效 Agent 的三条原则（Anthropic）

1.2.3 · 如何选择模型

编排模式决定上下文如何在 LLM 调用之间流动、工具如何调度、执行路径是预设还是动态生成。Anthropic 与数十个团队合作的经验：最成功的实现往往不是复杂框架，而是简单、可组合的模式。

Harness 重要，不等于越复杂越好。“Less structure, more intelligence.”（Manus）：给能力足够的 Agent 清晰目标、必要上下文和可组合工具，程序只固化必须始终成立的边界（权限、不覆盖原始材料、原子发布）。只有业务约束要求、或评估反复暴露稳定失败时，才升级为专门验证器、独立 Agent 或确定性流程。

护栏是分层防线，管数据隐私风险（如防系统提示泄露）和声誉风险（如符合品牌形象）。先针对已识别风险设置，发现新漏洞再加。单个护栏不够，多个专门护栏组合才有韧性。

三层按“被绕过的难度”排，而不是按处理顺序：越靠下越不依赖模型自己的判断，越难被一次攻击穿透。全书的安全讨论都挂在这棵树上。

1.2.6 · Harness 五要素与第二至五章

全书骨架只有一个：Agent = LLM + 上下文 + 工具（二至六章构建，七至九章评估与进化，十章协作）。Agent = Model + Harness 是“构建”部分内部的观察视角，把上下文与工具细分为五项职责。第六章（交互）扩展的是观察与动作空间的模态与时机，不属于五要素；安全是横切关注点，按三层护栏组织。

Anthropic 构建长时运行 Agent 时，把任务拆成“初始化 Agent”（设环境、分解任务列表）和“执行 Agent”（每个会话增量推进并留下清晰交接产物），用结构化 Harness 解决了“上下文耗尽”和“过早声明完成”。