这是《深入理解 AI Agent》精读专题的第三篇。读的是李博杰的开源书第一章的 ReAct 循环与「模型即 Agent」，写下我自己的理解——不是摘抄，是用我的话重新讲一遍。
本章思维导图见 专题页 · 章节思维导图

先补个尾巴：ReAct 循环

第一篇留了个钩子：ReAct 循环没展开，这次补上。

Agent 干活的核心模式叫 ReAct（Reasoning + Acting）。名字里只有思考和行动两个词，循环其实有三个环节：模型先思考该做什么，然后调用工具行动，再观察工具返回的结果，接着想下一步。想 → 做 → 看，不断循环，直到任务完成。

上一轮工具返回的观察，就是下一轮思考的输入。这个循环要做的事，是让模型的每一步决策都踩在真实结果上，而不是踩在参数记忆里。

新范式：模型即 Agent

书里抛出的新范式叫「模型即 Agent」（Model as Agent）：先进模型通过后训练（特别是强化学习），把工具调用能力内化为原生能力——何时调用工具、调哪个、传什么参数，模型自己决定，不需要人工编排。

听起来像框架要完。书里马上补了一句：恰恰相反，模型越强大，围绕模型构建的 Harness 越关键。空口无凭，上两个实验。

Kimi K3：决策进了参数，执行没有

实验 1-2 用的是 Kimi K3：约 2.8 万亿参数的混合专家（MoE）模型——像一个专家团队，面对不同的问题自动派合适的专家上阵，能力和效率兼得。

但要分清因果：让 K3 对工具调用熟练的不是参数多，是强化学习把决策策略写进了参数——何时调用、调用哪个、传什么参数，都由模型自主决定。书里给了一个直观的数字：它能连续执行 200～300 次工具调用而保持思考的一致性，多数模型在几十次后就开始退化。

然后是我读这部分抓到的最重要的一句话：

编排循环并没有消失，而是从客户端移到了服务端，决策权则交给了模型。

K3 依然不能真正执行工具——web_search、code_runner 的真实实现在模型之外的基础设施里，由一个叫 Formula 的服务端脚本引擎运行。决策权交了出去，执行没有。

GPT-5.6：两个变化，都还在接口层

实验 1-3 用的是 GPT-5.6，两个变化：

1. 自由格式工具调用（Freeform Tool Calling）：不再把参数打包成严格的 JSON，模型可以直接给工具发原始文本——一段 Python、一条 SQL。但书里特意补了一句：这是 API 参数格式的演进，而非模型架构的革新，客户端的工具调用循环逻辑一个字没变。
2. Deep Research 能力：Responses API 内置了联网搜索和代码解释器，在服务端形成「搜索 → 阅读 → 分析 → 再搜索」的闭环；而且模型在动手之前会先和用户交互，问几个澄清问题得到用户的真实意图——问的是「你偏好哪个数据源、要看哪些技术指标」，不是闷头去搜。

两个变化都指向同一个方向：把编排从客户端往服务端收。但注意第一条的定性——连「不再拘泥 JSON」都只是接口层的演进，谈不上模型学会了什么新东西。

我的判断：搬了个家，没长出手

两个实验看完，我的判断是：「模型即 Agent」更多只是转移到了服务端，并没有真正让模型具备真实运行工具的能力。

循环的结构一模一样，搬了位置而已。理由可以拆成两层：

第一层，执行的本质是对真实环境产生状态变化，而模型只会生成 token——生成不等于执行。写 SQL 是 token，把一条 UPDATE 真的跑进生产数据库是另一回事。书里的论证很硬：强化学习写进参数的是决策，工具及其执行在模型之外的基础设施里完成。

第二层是我自己的延伸：工具是实时的，而模型是现有数据集之下的产物。搜索结果、股价、天气每天都在变，训练数据永远是历史快照——工具的返回值没法提前内化进参数，只能在推理时现场取。这也顺手解释了书里实验 1-1 的现象：上下文里缺了工具执行结果时，模型会就地编造，因为它只剩参数记忆可用了。

当然要留余地。书里对「模型吃掉 Harness」的立场是「方向认同、节奏务实」：决策这一层确实已经被内化了——这正是「模型即 Agent」的实质；执行这一层短期内看不到被吃掉的可能，因为它从来就不在参数里。

下一步

• 第 1 章还剩最后一块：编排模式（工作流 vs 自主），下篇补上
• 第一篇欠的 context 实验还挂着，和下篇一起跑

参考来源

• 《深入理解 AI Agent：设计原理与工程实践》第 1 章「AI Agent 入门」，李博杰著，GitHub 开源
• 本篇覆盖第一章「ReAct 循环」与「模型即 Agent」（实验 1-2、1-3）；官方学习建议

这是《深入理解 AI Agent》精读专题的第二篇。读的是李博杰的开源书第一章末尾「Agent 的学习机制」与第二章开头「上下文的构成」，写下我自己的理解——不是摘抄，是用我的话重新讲一遍。
本章思维导图见 专题页 · 章节思维导图

模型的持续学习：三条路径

模型的行为改变不只发生在训练阶段。按更新发生的位置和持续时间，有三条互补的路径：

• 上下文适应（临场）：通过填充上下文让模型”学”——示例、状态、检索结果进入上下文后，模型立即调整行为。优势是快、低成本；局限是会话结束就没了，不改模型，受上下文窗口约束。
• 外部产物（持久化）：把经验整理为知识文档，把可语言化的策略写进 Prompt 或 Skill，把确定性流程写成程序。这些产物跨任务保留、可审计、可修订。
• 参数更新（内化）：SFT、强化学习，直接改模型。部署成本最高，但泛化能力最强——适合医疗影像理解这类外部规则难以完整表达的高维能力。

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

大模型为什么是通用底座

大语言模型是提前对海量数据做自监督学习训练出来的模型：参数量巨大，并且随规模出现了涌现能力——小模型没有、参数跨过某个量级后突然出现的能力。

这件事对 Agent 的意义在于：模型具备了通用化的任务能力，人们靠指令就能让它完成新任务，而不需要为每个任务定制一个模型。这是”Agent = Model + Harness”成立的全部前提——如果每个任务都要重训模型，Harness 的价值就不存在了。

模型会”吃掉”外部工程

模型是可以具备学习能力的，而且随着时间发展，它会逐步内化一些之前不具备的能力——包括更好的工具调用。今天靠提示词绕出来的能力，下一代模型可能原生就有。

后果是真实的：新模型发布后，一些老的提示词技巧、外部工程和环境适配就失效了。书里对这条趋势的立场是”方向认同，节奏务实”：模型内化一层，Harness 就卸下一层，转而兜底新的能力前沿——模型此刻的能力边界，就是 Harness 此刻的价值所在。

专业领域怎么补

医学、法律这类专业领域，主流是两条路：

1. 把领域知识送进上下文：RAG 检索、工具接入专业知识库——知识在模型外，随用随取，更新成本低
2. 后训练进参数：领域 SFT/RL——适合外部规则难以完整表达的高维能力（如医疗影像），部署成本高但泛化强

一个提醒给自己：知识问题和边界问题是两回事。工具/RAG 解决”模型不知道”，约束（Constrain）解决”模型不能做”——专业领域的准确性靠前者，行为边界靠后者，别混。

上下文的五个部分

每次调用大模型时的上下文由五个部分构成：

1. 系统提示词：开发者编写，相当于 Agent 的”岗位说明书”（身份、权限、行为准则），还会包含跨会话的用户记忆
2. 工具定义：声明 Agent 可用工具的名称、功能描述和参数格式
3. 用户消息：用户输入，可能包含 RAG 动态检索引入的外部知识
4. 模型回复：最多包含三部分——思考过程（reasoning 思考链）、文本内容（content）、工具调用请求（tool_calls）
5. 工具执行结果：Agent 下一步思考的直接依据，也是它”从执行结果中学习”的来源

结构上分两段：前两项构成静态前缀，后三项是随交互动态增长的消息历史。

一个重要的精确化（我原来的理解偏差）：静态前缀不是”它们天然静态”，而是工程上要刻意保持稳定——因为前缀稳定是 KV Cache 命中的前提，改前缀的几个字符，缓存全部失效、重新计算。所以”前面不能动、后面可以压缩”不是巧合，是 KV Cache 友好设计的基础，也是第二章后面所有上下文布局技术的出发点。

下一步

• 精读第二章 KV Cache 一节（原理、与 Prompt Cache 的两个层级、缓存作为架构约束）
• 跑通第 2 章 context-compression Starter 实验

参考来源

• 《深入理解 AI Agent：设计原理与工程实践》第一章「Agent 的学习机制」、第二章「从 API 视角看上下文的构成」，李博杰著，GitHub 开源
• 官方学习建议

这是《深入理解 AI Agent》精读专题的第一篇。读的是李博杰的开源书第一章「AI Agent 入门」，写下我自己的理解——不是摘抄，是用我的话重新讲一遍。
本章思维导图见 专题页 · 章节思维导图

一个公式，两个层次

最小实现是 Agent = LLM + 上下文 + 工具——大脑负责决策，眼睛（上下文）接收观察，手脚（工具）作用于环境。到了生产形态，同一个系统展开为 Agent = Model + Harness，其中：

1

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

这两个公式不是宏观与微观之分，而是同一个系统的 Demo 视角和生产视角：最小形态的 Harness 就是「上下文构造 + 工具接口」，生产系统还要在同一层加上约束、验证、纠正三层保障。

最容易记错的一点：Harness 不是模型的内部环境，原文的边界划得很死——Agent 边界内、模型之外。它环绕模型运行、治理模型与环境的交互，但沙箱里随行动变化的文件、外部数据库、网页和用户，永远属于 Environment。物理部署位置不决定概念归属。

Agent 和外部世界打交道，只靠两个接口

观察通道和动作接口共同构成 Agent 与外部环境之间的边界。上下文是眼睛——但它不只是”历史数据”，而是 Agent 在每个决策点收到并保留的全部信息：环境观察、用户记忆、领域知识、自身状态、任务进展。工具是手脚——从预定义的工具调用到动态生成代码，从委托子 Agent 到主动与用户沟通。

原文里我最认同的一句判断：没进上下文的信息，对模型来说不存在；没被动作接口允许的操作，模型即使知道该怎么做，也只能停留在文字建议上。

模型固定时，Harness 是唯一杠杆

许多看似需要「更聪明模型」的问题，其实只是接口问题：把任务所需的数据纳入上下文，或把完成任务所需的操作封装成工具，原本不可解的任务就可能变得可解。

这不是空话。LangChain 在 Terminal Bench 2.0 上从 52.8% 提升到 66.5%（排行榜 30 名开外跃升前 5），改变的不是模型，是 Harness——让 Agent 自动检查执行结果、检测循环、优化思考策略。所以书里说：当各家模型能力越来越接近，竞争优势就转移到了模型之外的工程实践。Harness 的五要素是一个闭环：上下文与工具让 Agent「能做事」，约束预防错误、验证发现偏差、纠正让闭环形成——三者共同让 Agent「不做错事」。

观察与动作空间的扩张

• 三条路线各自为政：Deep Research（深度调研）、Coding（代码生成）、Computer Use（电脑操控）长期独立发展
• Manus 首先合并：把三者放进同一个生产级 Agent——云端虚拟机里，虚拟浏览器扩大了观察空间，文件系统、代码执行与命令行扩大了动作空间
• OpenClaw 再推一层：本地优先，跑在用户自己的设备上；通过 WhatsApp、Telegram 等消息渠道随时触达，本地 Gateway 把 Drive、Notion、本地文件——分散在各账号与设备的数字生活——在授权后拉进同一个观察空间

Pattern 清晰：谁扩大了观察与动作空间，谁就重新定义了 Agent 的能力边界。

下一步

• 本章的 ReAct 循环与编排模式（工作流 vs 自主）部分，第二篇笔记补全
• 跑通第 1 章配套实验 context（Starter 入口），把「最小 Harness」亲手搭一遍

参考来源

• 《深入理解 AI Agent：设计原理与工程实践》第 1 章，李博杰著，GitHub 开源
• 本篇理解覆盖第一章「三要素与 Harness 工程」部分；官方学习建议中的难度分级与实验入口

你好，我是东玄蟒，一名后端工程师。这是我博客的第一篇文章，写点自己是谁、在做些什么、以及为什么开这个博客。

乱花渐欲迷人眼，浅草才能没马蹄。

我的经历

从大数据引擎起步。 职业生涯的第一段是大数据方向，做 Hive 引擎相关的工作。长时间泡在分布式计算和 SQL 引擎的细节里，理解了一条查询语句从解析、优化到执行的完整链路，也体会过让大规模数据作业又快又稳需要付出什么。

大厂后端锤炼。 之后进入大厂做后端开发，在真实业务的规模和复杂度下打磨工程能力：高并发场景下的服务设计、稳定性保障、线上问题的排查与复盘。大厂教会我最重要的一课是——系统可靠比系统聪明更难，也更值钱。

转型 AI Agent 开发。 现在的主线是大模型应用方向：从传统后端转向 AI agent 开发，研究 agent 的任务规划、工具调用、记忆机制与多智能体协作，也在动手用 agent 重构自己的工作流。后端工程的底子让我更关注工程化的问题——agent 如何稳定、可观测、可回滚。

AI 短视频赛道探索。 同时在做 AI 短视频赛道的创业尝试：观察真实需求、做小原型、快速验证，尝试把内容生产流水线交给 AI——从选题、脚本到成片的自动化。这条路上的一切思考都会记录在博客里。

博客内容方向

这个博客会围绕下面五个方向持续更新（各方向的学习进度见学习路径页面）：

1. 短视频赛道：AI 短视频的实践、赛道观察与思考
2. AI 基础知识：用大白话讲清楚 AI 的基础概念和原理，给转型路上的同学铺路
3. 前沿 skill 分享：值得上手的新工具、新玩法、新工作流
4. AI 优秀开源项目解析：带着问题去看源码——为什么这样设计、能抄什么作业
5. 投资相关分享：认知、方法论与记录

为什么写博客

把做过的东西写清楚，才算真的理解它。这个博客是我的「外置大脑」：

1. 记录：踩过的坑、想通的原理、排查过的疑难问题，写下来防止遗忘，也帮后来的少走弯路
2. 打磨：写作是压测思路的最好方式，含糊的地方在文字面前无处藏身
3. 连接：希望这些内容能遇到同样对技术和创业感兴趣的人，欢迎交流

关于本站

博客基于 Hexo + GitHub Pages 搭建，源码和文章都在 GitHub 上，全部内容仅代表个人观点。

联系我

如果你对上面任何话题有共鸣，或者正在做类似的事情，欢迎加微信交流：

微信号：abc15917977506（请备注「博客」或来意，更容易通过）

感谢你的到访，希望这里的内容对你有价值。