技术笔记

深入理解 AI Agent（一）：Agent = LLM + 上下文 + 工具

李博杰《深入理解 AI Agent》第1章读书笔记：核心公式的三重视角、上下文消融实验、ReAct 循环、模型即 Agent 与 Harness 工程，附思考题延伸

深入理解 AI Agent（一）：Agent = LLM + 上下文 + 工具

资料源：李博杰《深入理解 AI Agent：设计原理与工程实践》第1章 开源仓库：https://github.com/bojieli/ai-agent-book （v1.4，2026-08-13）

一句话主线

现代 Agent 的最小工程实现，可以压缩成一个公式：

Agent = LLM + 上下文 + 工具

这本书用 10 章把这一句话展开成完整的工程方法论。第 1 章是全书的"概念地图"：它不追求深度，而是快速建立统一的术语和参照坐标——后面每一章都会回来细化地图上的某个区域。所以这一章的读法不是"记住所有概念"，而是"建立整体印象"。

三重视角：同一个 Agent，三种说法

公式里的三个词，从不同抽象层次看有完全不同的名字，但指向同一个对象：

直觉层工程实现层学术层（RL）含义
大脑LLM策略（Policy）决定"下一步做什么"的决策内核
眼睛上下文观察与历史每个决策点能看到的信息
手脚工具观察/行动接口能读取什么、能改变什么

为什么值得同时记住三层？因为不同场景下最顺手的语言不同：和产品同学聊用"大脑/眼睛/手脚"，读代码用"LLM/上下文/工具"，读 RL 论文用"Policy/Observation/Action"。而且这套映射有个重要的边界声明——上下文只是环境在 Agent 内部的表示，工具背后的文件系统、数据库、网页、用户仍然属于环境，不因为被工具访问就变成 Agent 的一部分。

这个边界是后面所有架构讨论的地基：Agent 与 Environment 是闭环交互的两方，而不是彼此的组成部分。环境返回观察 → Agent 基于上下文决策 → 行动改变环境 → 新的观察再回来。

为什么"扩展眼睛和手脚"比"换更聪明的大脑"更有效

公式给出后，作者马上抛出一个反直觉的判断：在底层模型固定时，提升 Agent 任务表现最主要的系统工程手段，是重新定义或扩展观察空间与动作空间——也就是扩展上下文和工具。

道理很朴素：没有进入上下文的信息，对模型来说就像不存在；没有被动作接口允许的操作，模型只能停留在文字建议上。所以很多看似"需要更聪明模型"的问题，其实只是接口问题——把任务所需的数据纳入上下文，或把操作封装成工具，原本不可解的任务就变得可解。

书里用两个产品演进验证了这一点：

  • Manus：在它之前，Deep Research、Coding、Computer Use 是三条相对独立的 Agent 路线。Manus 的突破不是换了个更强的模型，而是把三者的观察空间和动作空间取并集——虚拟浏览器扩大观察，文件系统+代码执行+命令行扩大动作，同一个 Agent 就跨越了原有产品边界。
  • OpenClaw：把接口延伸到用户的数字生活——通过 WhatsApp/Telegram/Slack 等消息渠道触达，用本地 Gateway 连接 Google Drive、Notion 和本地文件系统，让分散在不同账号与设备中的文件都能进入同一个观察空间。

一个值得注意的细节：Manus 后来也加了 Google Drive 连接器和桌面端本地访问——产品能力的演进往往就是观察空间和动作空间的演进，这句话反复被验证。

上下文消融实验：Agent 的五官缺一不可

上下文由五个部分构成，前两项是静态前缀，后三项是随交互增长的动态轨迹：

  • 系统提示词（System Prompt）——开发者的"岗位说明书"，定义身份、权限、行为准则
  • 工具定义（Tool Definitions）——声明可用工具的名称、功能、参数格式
  • 用户消息（User Messages）——用户输入，可能含 RAG 检索引入的外部知识
  • 模型回复（Assistant Messages）——最多含三部分：思考过程（reasoning）、文本内容（content）、工具调用请求（tool_calls）
  • 工具执行结果（Tool Results）——框架执行工具后返回的结果

怎么证明"每个组件都不可或缺"？书里的实验 1-1 做了消融实验（Ablation Study）——像医生诊断时逐一排除病因：保留全部组件的完整基线，再四组各去掉一个组件对照。结果非常直观：

去掉什么现象
工具定义完全丧失行动能力，无法调用任何工具
工具执行结果看不到上一步反馈，反复调用同一个工具，无限循环
思考过程（reasoning）前后决策互相矛盾
历史消息等于失忆，从头重复已完成的任务

核心洞察一句话：上下文决定了 Agent 能看到什么，而 Agent 只能基于看到的信息做决策。 蒙住眼睛的人做不出合理判断，缺任何一个组件，Agent 的决策能力都会严重退化。

这个实验的方法论也值得记住——当你想论证"某个组件有没有用"，消融实验是最直接的武器。这对评估类工作尤其重要（后面第 6 章会系统展开）。

ReAct 循环：想 → 做 → 看，轨迹就是记忆

三个组件如何协同？答案就是 ReAct（Reasoning + Acting）循环：模型先思考当前该做什么 → 调用工具行动 → 观察工具结果 → 再思考下一步。循环不断重复直到任务完成。

关键概念是轨迹（trajectory）：Agent 执行过程中不断积累的消息历史。于是：

1

Agent 的上下文 = 静态前缀（系统提示词 + 工具定义）+ 轨迹（消息历史）

书里用"多币种收入汇总"的例子走了一遍完整轨迹：第一轮，模型看到任务后并行调用三个货币转换工具（EUR/GBP/JPY → USD）；第二轮，拿到转换结果后调用代码解释器做汇总计算；第三轮，确认计算完成，生成最终答案。3 次迭代、4 次工具调用就完成了多步骤任务。

最小运行骨架（伪代码，示意机制而非某个 SDK）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

trajectory = [user_request]

repeat:
    decision = Model(static_prefix + trajectory)
    if decision 没有工具调用:
        return decision.answer

    for call in decision.tool_calls:        # 相互独立的调用可并行
        validated_call = Harness.validate(call)
        observation = Environment.execute(validated_call)
        trajectory.append(observation)

轨迹不仅是执行记录，更是能力载体：通过分析大量轨迹可以发现行为模式、优化决策路径；轨迹还能沉淀到知识库，或作为 RL 的训练数据——这是后面第 8 章"持续进化"的伏笔。

模型即 Agent 与苦涩的教训：Harness 会被吃掉吗？

第 1.1.3 节介绍了当前最前沿的范式——模型即 Agent（Model as Agent）：先进模型通过后训练（特别是 RL）把"何时调用工具、调哪个、传什么参数"的决策内化为原生能力。书中实验 1-2（Kimi K3）和 1-3（GPT-5.6 Deep Research）展示了这一点：模型自己决定何时搜索、搜索什么，连续执行 200-300 次工具调用仍保持思考一致性。

这里作者专门厘清了一个常见误解（issue #30 读者指出的）：RL 内化的是"用不用、怎么用"的决策策略，而不是把搜索引擎或代码沙盒"装进"模型权重。工具本身及其执行（web_search、code_runner 的真实实现、沙盒环境、结果回传）仍在模型之外的基础设施里完成。编排循环没有消失，只是从客户端移到了服务端。

这引出一个更深的问题（书的立场值得细品）：如果模型持续变强，今天的 Harness 会不会被模型"吃掉"？

Rich Sutton 的《苦涩的教训》回顾了 AI 七十年反复上演的一幕：研究者一次次把自己对领域的理解编码进系统，短期见效，长期却总是输给能随算力与数据规模扩展的通用方法（搜索与学习）。以此衡量，Harness 里的约束、验证与纠正，有多少属于"人的先验"，注定会被模型内化？

书的立场是"方向认同，节奏务实"：不怀疑模型会持续吃掉 Harness（工具调用、长程规划都曾靠外部编排，如今已是原生能力）；但"吃"的速度远比直觉慢——训练以月计，模型无法一次内化真实业务中所有的约束与偏好。模型此刻的能力边界，就是 Harness 此刻的价值所在。 Harness 工程不是对苦涩教训的抵抗，而是这一教训在工程时间尺度上的实践：模型还做不稳的，Harness 先补上；模型每内化一层，Harness 就卸下一层，转而兜底新的能力前沿。

这个"吃与被吃"的动态关系，是理解 Agent 工程未来走向的元问题。

Agent 的三条学习路径：不同时间尺度的协同

顺带第 1.1.3 节还给出了一个重要的分类框架——Agent 的行为改变发生在三个层次：

  1. 任务内上下文适应：示例、状态、检索结果进入上下文，立即调整行为，但任务结束不保留。快速、低成本。
  2. 跨任务外部产物更新：把事实写成知识文档、把策略写进 Prompt/Skill、把流程写成程序/Harness。可审计、可修订。
  3. 模型参数更新：SFT/偏好训练/RL，用于难以显式表达的高维能力（医疗影像理解、隐式决策策略）。部署成本高，泛化能力强。

三条路径不是互斥分类，而是不同时间尺度上的协同机制：上下文负责临场适应，外部产物负责可控积累，参数负责内化难以表达的能力。

Harness 工程：模型之外的竞争力

第 1.2 节是本章的重心。前半章回答"Agent 是什么"，这半章回答"Agent 如何可靠地运行"。

生产形态的完整公式展开：

1
2

Agent = Model + Harness
Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正

Harness 这个词原指马具——缰绳和挽具不是为了限制马的奔跑，而是把力量引导到正确的方向。模型是那匹强大但不可预测的马，Harness 是把它的能力引导成可靠任务执行的工程外壳。

五要素的分工：

  • 上下文：为模型提供感知信息——信息充分性，让每个决策点基于足够的信息判断
  • 工具接口：为模型提供观察与行动手段——接口清晰，命名直观、参数有例子、边界有说明
  • 约束：设定行为边界——故障安全默认值，所有能力默认关闭，必须显式开放（类似手机 App 权限管理）
  • 验证：自动判断操作结果对错——输入隔离，安全检查只看结构化数据（工具返回的 JSON 字段），而不是模型自由生成的文本，因为攻击者可能通过提示注入操纵模型输出
  • 纠正：发现问题时自动修正或回退——在确认无法恢复之前不暴露中间态（先静默重试，不把半成品展示给用户）

生产控制骨架（伪代码）：

1
2
3
4
5
6
7
8
9

decision = Model(Harness.build_context(state, trajectory))
allowed_action = Harness.constrain(decision)          # 约束
observation = Environment.apply(allowed_action)
evidence = Harness.verify(allowed_action, observation) # 验证

if evidence 通过:
    trajectory.append(observation)
else:
    trajectory.append(Harness.correct(evidence))       # 纠正

一个很有说服力的例证：Claude Code 的 Harness 中，绝大部分代码是约束、验证与纠正，而不是上下文与工具本身——工具（文件读写、命令执行、搜索）只是一小部分，围绕工具构建的保障机制（流程状态管理、多层上下文压缩、权限分类、熔断器、错误恢复）才是真正的核心。

作者还给出工程范式演进弧线，五层层层包含：

1

提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程 ⊂ Graph 工程

每一层都在前一层基础上扩展工程师的关注范围：从"优化输入文本"到"管理模型看到的所有信息"到"组织模型运行并与环境交互"到"跨轮次的持续自主运转"到"把循环/程序/审批组织成显式执行图"。

为什么说这是竞争力所在？LangChain 在 Terminal Bench 2.0 上的实践是硬证据：他们的 Coding Agent 从 52.8% 提升到 66.5%（排行榜 30 名开外跃升至前 5），改变的不是模型，而是 Harness——让 Agent 自动检查执行结果、检测重复循环、优化思考策略。当各家模型能力越来越接近，竞争优势就转移到了模型之外的工程实践。

编排模式：工作流 vs 自主 Agent

Harness 中"上下文与工具"的组织方式有两种极端：

工作流（Workflow）——预定义的确定性代码路径。每个节点做什么、下一步去哪都是代码写死的，LLM 只在节点内部负责理解和生成。以订机票为例：核实身份 → 搜索航班 → 完成付款 → 确认预订，流程固定，系统绝不会在付款前订座。

  • 优势：严格流程控制（业务规则靠代码强制，不依赖 LLM 判断）+ 安全性（执行路径确定，提示注入最多影响当前节点内部，攻击面被限制在单节点内）
  • 局限：缺乏变通性——预设流程外的场景（用户临时改签、航班取消要推荐替代）只能走异常分支或交还人类

自主 Agent——执行路径由 Agent 根据环境反馈实时决定。同样的订机票任务：先搜索航班 → 发现要登录 → 核实身份 → 再搜索 → 发现最便宜的航班要转机 → 主动询问用户 → 用户不要转机 → 调整条件……本质上就是 ReAct 循环。必须设计明确的停止条件（任务完成/调用 final_answer/无工具调用/错误超限/最大轮次），否则容易死循环或过度执行。

  • 优势：能处理开放式、步骤数不可预测的问题（SWE-bench、Computer Use、迭代研究）
  • 代价：更高成本 + 复合错误风险，需要在沙盒充分测试、设护栏监控、关键决策点加人机检查点

实践中的关键原则是从简单到复杂：先试单个 LLM 调用（优化提示词和示例）→ 需要多步骤但步骤固定时用工作流 → 只有需要动态决策时才上自主 Agent。而且两者不是非此即彼——n8n 这类平台允许在同一个系统里混合：严格合规的流程用工作流，需要灵活决策的部分切自主模式。Agent 系统通常用延迟和成本换取更好的任务性能，这个交换是否值得要谨慎权衡。

护栏与安全性：分层防御，且要防"误拒绝"

护栏是约束/验证/纠正的实现手段，按防护位置分三层：

  • 输入侧：请求到达 Agent 之前拦截——相关性分类器（标记偏离主题的查询）、安全分类器（检测越狱和提示注入；越狱是用户自己试图绕过安全限制，提示注入是攻击者通过外部数据间接操纵模型）、内容审核、基于规则的过滤（黑名单/长度限制/正则）
  • 执行侧：工具调用时验证——核心是工具风险评级：按可逆性、权限等级、财务影响给工具标低/中/高，高风险操作需额外审查或人工确认
  • 输出侧：响应返回用户前检查——PII 过滤器、输出验证

两个值得记住的设计点：

  1. 误拒绝也是失败：为了降低危险请求被放行，模型可能同时拒绝合法但形式敏感的任务（授权的安全测试、模型蒸馏研究）。所以护栏评估不能只测"应当拒绝的是否被拦截"，还要测"明确允许的是否能正常完成"——评估体系必须双向。
  2. Constitutional Classifiers（Anthropic）：规则驱动（用自然语言"宪法"生成合成训练数据）+ 上下文联合判断（把用户提问和模型回答放一起检查，因为"如何使用食品调味料"单独看没问题，对照提问才发现是化学试剂暗语）+ 两级筛查（极轻量探针先过滤所有对话，可疑的再交给强分类器复审）。

**人工干预（Human in the loop）**是兜底：超过失败阈值（重试/操作次数上限）或高风险操作（大额退款、不可逆操作）时升级到人工。部署早期尤其重要——识别失败模式、发现边缘情况、建立评估周期。

思考题与延伸：两个值得反复咀嚼的观点

读完本章后做了一遍思考题，其中两个观点特别想记下来——它们都指向同一个判断标准，对做 Agent 相关工作很有用。

为什么模型越自主，Harness 越重要

模型在工具调用决策上越来越自主。harness 就是为了让 agent 在执行过程中能够不偏离目标，能够完整的完成目标，能够减少出错，减少一些意外与安全问题，更好的让模型/agent 工作（上下文，记忆，工具，skill…）。我认为 agent 框架未来的核心价值就是，让 agent 在掌控之中做得更好。

——这是我对思考题 3 的原始直觉。细想之后，这个答案可以再推进一步：两个趋势不是并列共存，而是因果关系。模型自主决策空间越大，出错时的影响面越大，因此需要更精细的约束、验证和纠正机制来确保可靠性（这正是书中 1.1.3 节的原话逻辑）。模型吃掉的是"编排决策"（何时调工具、调哪个、传什么参数），但正是这种自主性把 Harness 的治理价值抬高了。

由此可以整理出框架未来核心价值的完整清单：

  • 约束/验证/纠正（可靠性）——模型负责"做得快"，Harness 负责"做得对、可控、可审计"
  • 上下文经济性（KV Cache / 压缩）——上下文管理的成本与质量，让长任务跑得起
  • 工具生态（MCP）——工具接入的标准化，降低生态摩擦
  • 可观测性与评估——把表现变成可比较的信号，驱动迭代
  • 安全护栏——分层防线 + 人工干预，兜住自主性的影响面

什么会被模型"吃掉"：教模型 vs 治理模型

思考题 10 问：好的设计原则穿越模型迭代周期，但具体工程手段会随模型能力进步而过时——举一个例子。这道题我一开始完全没头绪，补课后想明白了。

书给的理论框架是：模型每内化一层，Harness 就卸下一层。所以被吃掉的都是"人类把领域知识硬编码去补偿模型短板"的手段。最典型的例子是客户端手写 ReAct 编排循环（检测 tool_calls → 执行工具 → 回传结果）——五年前每个 Agent 框架都在写这段代码，现在 GPT-5.6 的 Responses API、Kimi 的 Formula 把编排搬到服务端闭环执行，模型原生决策，这正是"模型即 Agent"范式。同类还有：显式 ReAct 提示词（思考模型原生就会）、few-shot 示例教工具调用（RL 已内化）、XML/JSON 格式约束（原生 structured output 取代）。

由此提炼出一个判断标准：

凡是"教模型怎么做"的手段都可能被吃掉；凡是"治理模型"的手段（约束/验证/纠正/审计/可观测）反而升值——因为自主性越大，治理需求越大。

评估任何 Agent 工程手段的价值时，先问它属于哪一类：是"教模型"（迟早被内化），还是"治理模型"（越自主越值钱）。

其余思考题的一句话快答

  • Q1（只加一项能力）：看瓶颈在哪——“看不到信息"加上下文，“做不到"加工具，“想不通"换模型；模型有天花板且不可控，上下文和工具完全在自己掌控内
  • Q4（死循环）：除了缺工具结果，还有重试循环、状态振荡、计划翻新、子 Agent ping-pong、上下文遗忘导致重做；检测靠执行预算 + 循环签名 + 进展信号 + 熔断器（详见活页夹 thoughts.md）
  • Q7（动态风险评估）：业界第一线不是小模型，是确定性参数规则（如 Claude Code 的 deny/ask 参数级匹配）；小模型作为两级筛查的第二级，延迟只加在可疑样本上
  • Q9（人工干预）：先分类"哪些必须等人”，队列化 + 异步通知，超时走安全默认；Claude Code auto 模式的本质是让一个 supervisor 层决定"什么时候该问”

小结：一张概念地图

第 1 章建立的框架可以浓缩为五点：

  1. Agent = 大脑 + 眼睛 + 手脚：LLM 是大脑，上下文是眼睛，工具是手脚，三者缺一不可
  2. 扩展眼睛和手脚是最主要的能力杠杆：模型固定时，扩展观察空间与动作空间往往直接把不可解变可解
  3. 上下文是决定性的：静态前缀 + 动态轨迹，消融实验证明每个组件都不可缺失
  4. Harness 是竞争力所在：模型能力商品化，差异在约束、验证、纠正——“能做事” vs “可靠地做事”
  5. 从简单到复杂：先提示词 → 再工作流 → 最后自主 Agent；安全从第一行代码就要考虑

下一章进入 Harness 最核心的组件——上下文工程（KV Cache、提示工程、Agent Skills、上下文压缩）。