跳到主要内容

工具与环境 — 智能体如何接上世界

这一章讲三件事: 模型怎么从「告诉你该做什么」变成「真的去做」——函数调用与协议标准化的那套机制; 当没有现成 API、只有网页和桌面软件时,智能体怎么在脏乱的真实软件世界里站稳; 以及动作开始改变外部世界之后,接口本身要补上的安全工程——隔离、幂等、最小授权、可观测。

它在全书链条里的位置:第 11 章把闭环立了起来,这一章把闭环伸出去的手臂做结实—— 观察(§9 界面接地)与行动(§10–§13 安全接口)两头都靠接口层撑着;检索这条线同时是第 04 章 RAG 伏笔和第 13 章记忆外置的过渡。

顶层全景:接口的三个层次​

  第一层:动作怎么发出去                    §2–§5
    函数调用 → 结构化输出 → MCP 协议 → 工具检索与工具库
  第二层:世界不是 API,是屏幕              §6–§9
    RAG 补知识 → Agentic RAG 边推边查 → 浏览器/终端/桌面 → GUI 界面接地
  第三层:会改世界的接口要可信              §10–§15
    沙箱隔离 → 工具编排 → 幂等/确认 → 最小授权/临时凭证 → 观测探针 → 生态治理

图说: 三层各管一件事:第一层让动作「发得出」,第二层让智能体「进得去」真实世界,第三层让它「闯了祸收得住」。 同一张对照表(§1)从头贯到尾:接口每加一道约束,模型犯错的空间就小一分。

1. 接口决定能力上限​

先立一个反转常识的判断:很多看起来像模型能力不足的问题,其实是接口没有把工具边界、 失败信号、副作用和权限交代清楚1。书里给了那张著名的对照表,值得整个搬走2:

接口要素粗糙接口良好接口
工具描述只写「搜索」「下单」等宽泛动词说明适用场景、输入来源、输出含义和不能做什么
参数约束参数靠自然语言猜,错了调用后才暴露类型、必填项、枚举值和校验规则提前显式化
失败信号失败只返回空结果或模糊报错区分权限不足、参数错误、外部超时、无匹配结果
副作用读、写、提交、删除混在一个入口只读查询和改状态的动作分开,标明影响范围
权限边界默认给模型过大的通行证最小授权、分级审批、按任务临时收回
观测反馈调用后只给最终答案记录请求、返回、关键证据、人工确认和异常路径

大模型提供的是「通用认知内核」,接口决定这个内核能接触什么、能改变什么、能验证什么3。 没有接口,再强的模型也只能停留在文本世界里。

2. 函数调用:从 prompt 技巧到核心抽象​

最基本的接口是函数调用(function calling):把外部能力包装成一组可调用的操作, 让模型除了生成回答,还能输出结构化的动作请求——查数据库、读文件、跑命令、发邮件、提交工单4。

但「能调用」离「调得稳」很远:模型得清楚每个工具的输入格式、输出结构、使用边界和失败信号, 光给一长串函数清单远远不够。否则会出现一种表面智能、实际脆弱的状态—— 模型频繁调工具,却不知道什么时候该调、参数怎么填、失败后怎么办5。 还有一个容易被忽略的事实:工具越多,错误类型也越多——调错工具、填错参数、顺序颠倒、重复执行、忽略异常, 这些都不是纯对话时代的问题;工具调用把系统从「回答问题」推进到「执行问题」, 工程复杂度一起被推了上去6。

这条范式本身也在三年里走完了一段进化路,书里给它画了清晰的时间线7: 早期是「开发者用 JSON Schema(一种描述「参数该长什么样」的标准格式)声明函数,模型决定调不调、生成参数」; 随后「函数」抽象成更通用的「工具」,一轮对话可发多个调用; 再往后,结构化输出把「参数符合 JSON Schema」从软约束变成解码期的硬约束,非法 JSON 大幅减少; 最终,工具调用、推理、检索、代码执行被统一进更完整的 agent API—— 函数调用从「一种 prompt 技巧」演化成了大模型 API 的核心抽象。

3. 三类原语与协议标准化​

工具一多,标准化问题立刻浮出水面:如果每个应用都用自己的方式描述工具、权限和返回值, 智能体就没法稳定接入不同系统。MCP(Model Context Protocol,即模型上下文协议——直译就是「给模型用的通用上下文接口」)由此受到关注: 它给模型应用与外部工具、数据源之间提供一套统一连接方式,让工具从「某个产品里的私有按钮」 变成可以被通用地发现、调用和管理的接口8。

任何这类协议本质上都在回答三个问题:工具如何被发现(怎么知道它存在、声称能做什么)、 如何被描述(输入输出结构、边界、权限、失败语义以机器可读方式暴露)、 如何被调用(通道、认证、流式约定)9。

补充(不在书里,依据我们的协议书架):MCP 规范把提供方一侧的能力分成 tools / resources / prompts 三类原语,并按「谁来控制」划线:工具由模型决定何时调用, 资源是应用控制的只读数据,提示模板由用户触发——「发现-描述-调用」三问在规范里各有对应的机制。 依据: shelf=ai-protocol-reference/mcp-spec#03-server-primitives.md @4e67bdc2f3403a8602f72025b28ac27fe7fd4e44 事实=规范将能力分为 tools(模型控制)、resources(应用控制的应用数据)、prompts(用户控制), 与原书「可调用的动作、可读取的数据、可注入的模板」三分法一一对应。

三个易混的名字,书里做了一次干净的了断10:

  • Function Calling:单次请求内的工具清单,生命周期与一次对话绑定,解决「这一次调用」;
  • OpenAPI/GraphQL:给程序员看的老牌 Web API 描述规范,塞给模型太冗长,也缺「权限/副作用」这类模型需要的语义;
  • MCP:客户端(发起请求的一方)对服务端(持续运行、随时应答的一方)的协议,服务端持续运行,暴露可调用的 tools、可读取的 resources、可注入的 prompts; 客户端(嵌在 Claude Desktop、Cursor 等应用里)统一负责发现、鉴权和调用——解决「任何模型应用持续接入」。

三者不互斥,回答的是不同时间尺度的问题11。但书里按了一句冷静的限定,值得抄下来: 协议化只解决连接和描述问题,并不自动解决权限、幂等、回滚和执行可靠性—— 后面几节的工程问题,恰恰是在协议层稳定之后才成为主角12。

4. 工具检索:几十个工具就会吃光预算​

接入几十个工具后,新问题来了:模型怎么在成百上千个工具里找到「这一刻该用哪个」? 把所有工具描述塞进上下文,预算很快见底,何况大多数工具对当前任务根本不相关13。

思路是把「工具」当「文档」一样建索引(像给书编目录),这叫工具检索:给每个工具写说明(功能、输入、典型用例), 用嵌入模型编码,问题来时按相似度召回前几个候选,再让模型决定调哪个14。 书里顺手指出了三个常见的坑,每个都来自真实翻车现场:工具描述写得敷衍会让召回失准; 不同工具的描述风格差异大会让相似度失真;某些工具在示例语料里出现太多会被过度召回。 进阶做法包括两阶段检索(先按关键词过滤再排序)、工具图谱检索(按「这个工具的输出常被下一个工具消费」建链)、 以及基于历史轨迹的检索(用成功过的「问题-工具集合」训练嵌入)15。

5. 工具库与工具学习:把会用工具训进模型​

检索的前提是有一座结构良好的工具库。工业级的工具库不是一堆零散函数,通常包含五件套: 统一的描述格式(参数 schema、副作用声明、失败模式)、分类层级、版本管理(签名变更保留旧版以便回放)、 执行沙箱、监控与配额——这些让工具既「可调用」又「可治理」16。

另一条路是把用工具的经验直接训进模型参数:用大量调用轨迹做监督微调打底, 再用强化学习在可验证任务(写代码、跑测试)上精调;数据可以人工标注、强模型生成后过滤、 或从产品日志反向蒸馏(须先脱敏——把「是谁」的信息洗掉)17。这条线上的名字:Toolformer、ToolBench 是学术代表, Berkeley 的 BFCL 榜单到 2025 年已是工具调用领域的公认标尺18。 书里点出这条路上最容易被忽视的四件事,每一件都比记住 API 名字难: 何时不该调工具、何时应该并行调、参数怎样填对、调用失败后如何恢复—— 这也是通用模型和专门工具模型的分水岭19。

6. 检索质量才是天花板​

工具解决「能不能动手」,检索解决「能不能补上参数之外的知识」。 朴素 RAG 只有两步:把用户问题转成向量,从知识库里找最相关的几段(典型 3–10 段); 再把它们拼进提示当参考资料,让模型基于它们回答20。 它火了,靠的是两个最现实的便宜:知识时效性(训练截止后的事,重新索引即可,不必重训)和 知识私有性(公司内部文档、个人笔记放外部即可)21。第 04 章 RAG 一节埋的「知识时效性/私有性」两条好处,在此收口。

一个常见误解必须拆掉:「RAG 主要靠模型够强」。实际上模型只占成败的一小部分—— 检索回来的资料不准,模型再强也是基于错误前提回答。 工业级系统的大量功夫全在检索侧:长文档怎么切成合理的块、嵌入模型怎么按自己的语料调教、 怎么用「稠密嵌入 + 关键词 BM25」双路召回、怎么用重排序模型从几百个粗筛候选里挑出真正相关的几段22。 书里补了 2025 年工业界的几条新主线:Reranker 成为标配(先宽召回 100–500 条,再精选 5–10 段); 切块策略从递归切块、语义切块进化到「晚切块」和「上下文检索」(每块前面补一段它在文档里的位置背景,大幅降低检索 miss); 多向量式检索(与早期语言模型 BERT——2018 年那个双向理解的鼻祖——同一血统的 ColBERT 系列)在词元级保留多个向量换精细度; 混合检索加融合(RRF)则是企业部署的默认配方23。 结论一句话顶一万句:一个顶级大模型加朴素召回的系统,常常输给一个中等模型加精心调过的混合检索加重排序的系统24。 幻觉在 RAG 里没有消失,只是换了形态——从「模型胡编」变成「模型基于错误资料回答」, 所以严肃系统会强制引用来源,让每个事实都挂着检索片段编号25。

RAG 也有边界:需要全文理解的长期合同、长论文,切片反而丢关键关联,该用长上下文; 需要改变行为风格和专业深度,该用微调;更多场景是三者组合——框架靠模型,事实靠检索,长文档靠整体阅读26。

补充(不在书里,依据我们的前沿框架书架):检索质量的评测同样有自己的尺子—— 忠实度分数(衡量回答是否忠于所引资料)把回答拆成陈述句逐条对照检索证据,拆句时明确要求不用代词、判定要先写理由, 这正是「强制引用来源」的量化版本。 依据: shelf=ai-frontier-reference/ragas#01-metrics-engine.md @298b68274234c060deacab3cf5fb52aa3a20e885 事实=faithfulness 的三步是「拆陈述 → 逐句判定 → 忠实句数比总句数」,与本节「答案挂检索片段编号」同源。

7. 边推理边检索:Agentic RAG​

智能体场景里,检索不再是「一次检索、一次回答」。系统可能先搜索、再筛选、再打开文档、 再根据新发现追加检索——一个多轮迭代的证据收集过程,这叫 Agentic RAG27。 它和传统 RAG 的分野在:检索本身进入了决策闭环——模型要判断搜什么、何时停、证据够不够、来源冲突了怎么办28。

书里那个企业问答案例值得完整读一遍。用户问:「这份新合同能不能用去年模板里的责任限制条款?」 传统 RAG 检索「责任限制」「模板」相关片段,一次性作答;Agentic RAG 会把问题拆成几步: 先找新合同的责任限制、赔偿、适用法律条款,再找去年模板的对应条款, 接着核对两份文档是否同一个业务对象、同一个司法辖区;若新合同多了数据处理或第三方服务条款, 还要追加检索隐私附件。最后的回答除了结论,还应附证据表、冲突点和仍需人工确认的问题29。 它的工程要点从「召回几个片段」变成了「管理一次调查」:记录检索意图、命中文档、被舍弃的证据、 冲突来源和停止理由;并给自己写死几类停止条件——独立证据已经足够、继续搜收益太低、 冲突大到必须交给人30。每一次检索由上一轮证据触发,并且留下可回放的证据链——检索次数多本身不算数31。

8. 浏览器、终端与桌面:脏乱的真实软件世界​

很多任务没有现成 API,它们活在网页、命令行和桌面软件里。这些环境比「标准函数调用」脏乱得多: 状态不一定结构化,反馈不一定即时,错误也不一定有统一格式—— 一个终端命令失败,返回的可能是一段日志和报错混杂的文本;一页看起来没变的网页, 按钮位置、弹窗状态和登录态可能都变了32。

这条路线的两个代表方向:Computer Use 让模型通过截图、鼠标、键盘操作整台计算机; Browser Use 专注网页浏览、点击、填表和跨页导航33。时间线很紧凑: Anthropic 2024 年 10 月发布 Computer Use 测试版;OpenAI 2025 年 1 月推出 Operator(订餐填表订票), 同年并入 ChatGPT agent;Google 从 Mariner 原型推进到 Gemini 2.5 Computer Use; 开源侧的 browser-use 把浏览器自动化、规划和轨迹记录打包,降低了入场门槛34。 趋势一句话:模型可操作的对象从函数,扩展到浏览器,再扩展到整台电脑——每往前一步, 权限、隐私和可回滚的难题同步放大35。

两者的取舍也清楚:Computer Use 面向跨应用流程(整理本地文件、读邮件附件、开表格写报告), 工程面更宽、权限过大的代价更高;Browser Use 面向网页流程(检索、比价、填报销单), 风险集中在网页权限、账号会话和表单提交上36。未来更可能是混合型:简单网页流程走 Browser Use, 跨应用跨系统的步骤切到 Computer Use 或结构化 API 连接器37。

关键的不对称在失败的样子:API 世界里动作出错多半返回错误码;GUI 世界里出错常常只是点错地方、 切错窗口、误触弹窗——没有错误码,只有安静走偏。所以操作型智能体的难点不是「会不会点」, 而是「点完之后能不能确认自己没有走偏」38。

9. 界面接地:把画面当成会变的状态​

在屏幕上做事,模型需要一种叫界面接地(GUI grounding)的能力: 把视觉界面里的元素和语义动作对应起来——哪块区域是输入框,哪个按钮可点, 哪个提示框意味着失败39。它和第 08 章的多模态一脉相承,但要求变了: 视觉理解不再停留在「描述图片内容」,而要服务于行动;模型要把眼前的画面当成一个可操作的界面状态, 而不是一张静态照片——要认出元素,更要判断元素与任务目标的关系40。

难点也很实:界面元素随分辨率、主题、滚动位置、权限状态变化;同一个按钮的语义依赖上下文; 有些反馈只存在于短暂的过渡动画里。书里给它的定性很准:GUI grounding 归根到底是一个持续状态感知问题, 不是识别一次就完事41。

10. 沙箱与执行隔离​

进入真实软件环境后,最容易引发的事故往往不在「没看懂屏幕」,而在「看懂了但权限太大」—— 一个会执行命令的智能体若直接跑在真实操作系统里,理论上它能删任何文件、改任何配置。 再聪明的安全检查也难保万无一失,更稳妥的工程做法是先把它关进沙箱42。

隔离分三级,严一个数量级贵一个数量级43:

层级手段适用
进程级独立工作目录、受限的配置项读取、限制网络出口日常工具调用
容器级Docker、Firecracker 等容器/微虚拟机,独立文件系统与互相隔离的网络边界,出事整个销毁代码执行、文件操作
虚拟机级完整虚拟操作系统,与宿主机不共享内核高度不可信的代码

沙箱也不是装上就完事:研究界还在盯沙箱逃逸——智能体通过意外的副作用绕过隔离, 比如把恶意指令写进共享日志文件、在临时目录留后门。所以沙箱必须和权限收缩配合; 书里的总结是:沙箱、最小授权、观测接口三者构成智能体与外部世界之间的安全外壳,缺一不可44。

11. 接口组合与工具编排​

单个工具好不好用当然要紧,但真实任务的难点常在多个工具之间:检索到资料要不要交给摘要工具, 代码搜索后要不要接编译测试,网页读取后要不要调结构化抽取。对智能体来说, 世界不是一堆孤立按钮,而是一张带前后依赖的工具网络45。 成熟的系统还要管工具之间的契合度:输入输出格式是否自然衔接、状态能否跨工具传递、 失败时能否退回上一层重新选路——缺少可组合性,模型即使会分别调用,也拼不出稳定工作流46。 书里对编排本质的定性很漂亮:它是在把原本属于「人类经验」的流程知识显式化—— 熟练的人自然知道先查什么、出问题跳到哪;智能体要复制这种能力,工具层就必须把隐性流程拆成 能逐步调用、能在某一步失败时退回的明确分支47。

12. 凭证怎么发:最小授权、临时凭证与执行会话​

授权不能只是「给了能用/不给不能用」,而应该尽量做到最小化、短时化、会话化。 理由冷峻而清晰:权限不仅是功能开关,更划定了系统判断失误时最多能把错误扩散到多大范围—— 一个只能读某个目录、只能在短时间窗口内调某个接口的智能体,即使走偏,后果也和拿着长期高权限 令牌(通行凭证)的系统完全不同48。

成熟系统的做法分三层49:

  • 最小授权(least privilege):不是所有工具都需要长期可写权限,不是所有任务都需要完整账号上下文; 先给只读、低风险、窄范围的能力,完成观测和计划之后,再在关键动作前申请更高一级的短时权限—— 这把高风险动作从「默认状态」改成了「显式承诺状态」;
  • 临时凭证:长期静态凭证把「单次任务需要的能力」和「系统长期持有的能力」混在一起, 一旦某个环节被污染就成了持续暴露面;凭证只对当前任务、当前会话、当前动作类别生效, 风险就被压缩进一个小时间窗。未来的方向是:系统用机器可读的策略说明自己要做什么, 换取一次有范围、有时限、有用途约束的执行许可,而不是「先拿着,之后再说」的万能钥匙;
  • 执行会话:把授权组织成可管理的运行单元——一个会话内能访问哪些资源、消耗哪些配额、 写入哪些审计记录,绑定在同一边界里,任务完成统一撤销清理,中断时冻结现场50。

13. 幂等、确认语义与副作用控制​

接口从「读数据」走向「改世界」的那一刻,一个问题立刻变得致命:同一个动作执行两次,会发生什么? 人类程序员熟悉幂等性(idempotency——同一操作做一次和做多次,效果相同);对智能体它更关键, 因为模型会因网络抖动、反馈延迟、状态误读而再次发起相同动作——没有清楚的幂等语义, 就可能重复提交表单、重复写入、重复建任务,在用户察觉之前把小错误放大成一串副作用51。

书里给的接口设计守则非常具体,可以照抄进任何工具的规范里52:

  • 把「预览 / 执行 / 确认 / 提交」阶段区分开:低风险动作直接执行; 高风险动作先返回草案或差异,由系统或人类显式确认;
  • 写操作带清楚的成功标志和请求标识,让系统能分辨「这是第一次提交」还是「这是重试」;
  • 不可逆动作给更窄的动作粒度和更严格的条件检查;
  • 支持「读后写」「写前验证」「写后检查」:改之前确认状态仍符合预期,改之后读取结果确认副作用没越界53。

最后一条定性判断值得记住:长任务里最危险的不是模型第一次判断错,而是错误动作在反复重试、 跨步骤传递和状态污染中不断放大——一个支持预览、确认、幂等重试和结果校验的接口, 显著缩小这条放大链条54。越是缺少清楚反馈的动作,越不适合作为高自主性智能体的默认工具55。

14. 观测接口与差分反馈​

动作接口决定「能做什么」,观测接口决定「怎么知道自己做完了什么」。 长任务里的智能体需要稳定的状态探针:页面是否真的跳转了、文件是否真的写入、 表单字段是否还保持着刚才的值。缺了这些,系统只能靠自然语言描述、截图和模糊日志猜状态, 误判和重试随之放大56。

比把整页原始内容扔给模型更稳的,是结构化探针:页面元素树、任务状态对象、变更前后 diff、 资源版本号、最后一次操作结果、当前权限态和显式错误码——模型做完动作后不必重新猜「世界变了没有」, 直接围绕关键状态做验证57。 差分反馈则更进一步:不重发全部状态,只告诉系统「这一步之后哪些对象变了、哪些约束变了、 哪些仍未满足」——既省上下文,又适合日志回放和异常定位58。 一个既能执行动作、又能返回稳定差分的接口,比只会返回大段自由文本的接口更容易形成可靠闭环。

15. 生态治理:壁垒在接口层​

最后升到生态层。工具和接口一多,新问题随之出现:谁保证这些接口持续可用、版本兼容、权限清楚、 行为可审计?书里把这一层叫「平台治理」:工具注册、版本管理、权限声明、失败语义、日志格式、使用配额, 从零散约定变成平台规则——没有这些规则,接口一多, 开放生态就会滑向不可维护的混乱集合59。

然后是本章的收束判断,也是最值得带走的一句:智能体生态真正的壁垒也许不在某个模型有多强, 而在接口层是否足够成熟——只有当工具可以被稳定发现、清楚描述、安全调用、持续审计, 模型外面的世界才会变成真正适合智能体长期工作的环境;否则每个智能体都只能围着一小堆私有接口 手工集成,形不成可复用能力60。 接口回答了「如何接触世界」;下一章的记忆、规划与协作,回答的是「如何在时间中持续行动」。

主走查:一张餐费发票,从拍照到提交​

这条走查贯穿本章。 输入:一张手写金额的餐费发票照片 + 一句「按公司制度提交报销」。 九步走完,每步标注它落在哪一节。

① 读发票。(§9 界面接地) 模型把照片当成界面状态而非静态照片:识别出金额 ¥287.00、日期 2026-08-14、 税号和「餐饮」类别(金额等为演示设定)。它没有只做「描述图片内容」—— 这些字段接下来要进表单,识别错误会在下游滚大。

② 查制度。(§6 检索质量) 「按公司制度」四个字靠检索兑现:问题编码后在制度库里双路召回(嵌入 + 关键词), 重排序后取回《差旅费管理办法》第 12 条:单张餐饮发票超过 500 元需部门主管二次审批 (条款内容为演示设定)。切块时制度文档按条款切分而不是按字数——否则这条规则会被切碎召回不全。

③ 第一轮没搜到,换关键词再来。(§7 Agentic RAG) 「报销时限」这个关键词没命中(制度里写的是「费用申报期限」)。检索进入决策闭环: 模型判断证据不够,换词重搜,拿到「需在费用发生 30 日内申报」,并记下这条证据链。

④ 解析脚本进沙箱。(§10 执行隔离) 发票上有手写备注需要 OCR(把图片里的文字认出来)加一段解析脚本。脚本在容器级沙箱里跑:独立文件系统、 限制网络出口——它读的是发票副本,就算脚本有 bug 也毁不掉真实文件。

⑤ 打开报销页面填表。(§8 浏览器环境) 没有现成 API,只有公司内网的报销网页。Browser Use 打开页面、识别登录态, 把金额、日期、类别填进表单,处理下拉框和必填项校验。

⑥ 弹层挡住了确认按钮。(§9 §8) 点击「提交」时弹出一个 「本月餐饮额度不足,是否继续?」的对话框——GUI 世界里没有错误码, 只有安静出现的新状态。界面接地让模型认出这不是失败弹窗而是决策弹窗;按 §8 的纪律, 「网页变动、弹窗打断」时它选择停下来评估而不是硬点。

⑦ 提交前先拿短时凭证。(§12 凭证) 确认继续后,系统不是拿着员工的长期令牌去提交,而是为这次会话申请一张 只对「报销提交」类动作生效、30 分钟过期的临时凭证(演示设定)。 就算这条链路中途被污染,泄露的也只是这半小时内的一类权限。

⑧ 网络抖动,重试一次。(§13 幂等) 提交请求超时。因为接口带请求标识、语义幂等,重试不会创建两条报销单—— 系统先查「这次提交是否已经生效」,确认没有,才重发。

⑨ 提交后重读页面。(§14 观测与差分) 最后一步不是「相信返回成功」,而是重新读取页面:报销单号 BX-2026-0814-0332、 状态「待主管审批」(单号为演示设定)。差分反馈告诉它:哪些字段已锁定、哪一步还在等人。 整条链的轨迹——两次检索、一次沙箱执行、一次弹窗停顿、一次幂等重试——全部留痕,可回放。

作者的判断与证据​

书里给出可核事实或公开来源的地方:

  • MCP 由 Anthropic 在 2024 年 11 月发布,三类资产(tools/resources/prompts)与其客户端形态,与公开规范一致(本组拆解另加了协议书架锚核对)10;
  • 2025 年 RAG 工业主线(Reranker 型号、晚切块、上下文检索、ColBERT、RRF)是书里点名归纳的公开实践23;
  • Computer Use(2024-10 beta)、Operator(2025-01)、Mariner、Gemini 2.5 Computer Use、browser-use 的时间线,与公开发布记录一致34;
  • BFCL 榜单覆盖的场景清单(simple/multiple/parallel/relevance/REST)是可查的公开基准描述18。

书里标成判断或立场的地方:

  • 「很多模型能力问题其实是接口问题」——全书这一章的立论判断,以对照表论证,无单一实证1;
  • 「RAG 的天花板在检索工程,顶级模型加朴素召回常常输给中等模型加精调检索」——作者的行业判断,陈述为经验规律24;
  • 「凭证应短时化、会话化,未来系统用机器可读策略换执行许可」——带有前瞻性质的判断49;
  • 「智能体生态的壁垒在接口层不在模型层」——收束性判断,理由充分但属于可辩驳的立场60。

判断(我们的,不是书里的): 本章 15 节其实描绘了一场权力转移:接口层正在从「模型的下游」 变成「模型的立法者」。工具描述决定它看见什么选项,权限边界决定它能做什么,失败语义决定它如何归因, 观测探针决定它相信自己看到了什么——模型只是在这套法律框架内做近似判断的书里那句话 (§1)反过来说就是:谁控制接口,谁就控制了智能体的实际能力上限,哪怕模型本身继续变强。 这解释了为什么协议(MCP)和技能规范会成为 2024–2025 年的争夺焦点:标准即权力。 如果错,会错在: 若模型能力涨到「能从任意粗糙接口里自行归纳出可靠语义」 (相当于模型自带接口翻译层),接口质量的重要性会相对下降——第 07 章那种长思考

  • 工具学习的组合若持续兑现,这个可能性不能排除,但书里和今天的实践都还不支持它。

边界与局限​

  • 对应关系: 本章对应原书第 11 章全文;原书把「用户怎么把任务说清楚」明确推给了它的第 7 章,本组拆解对应第 07 章,同样不重复。
  • 没展开的: 工具检索的进阶算法(两阶段/图谱/轨迹)只各留一句;SFT+RL 训工具能力的完整流水线在第 14 章;提示注入(在喂给模型的内容里藏指令)的三层防御在第 17 章(本章只在驾驶舱安全检查处埋了词);多模态感知的网络结构细节归第 08 章。
  • 一处取舍声明: 原书表 11.1(粗糙接口 vs 良好接口)六行全部保留,因为它是全章的骨架;原书 11.2.1.2 里五种切块策略的细节做了合并,保留了名字和一句机制。
  • 时效性: RAG 产品名(Cohere Rerank 3.5、BGE、Jina)与榜单格局截至成书;「工具检索像建索引」的机制描述不随产品漂移。

可带走的​

  1. 「模型不够聪明」的第一嫌疑人是接口:边界、失败信号、副作用、权限没交代清楚,神仙模型也会错;工具调用还把「回答问题」升级成了「执行问题」。
  2. MCP 三原语记住一个分工:tools 模型调、resources 只读、prompts 用户触发;协议只管连接和描述,不管权限与幂等。
  3. 工具列表塞满上下文是错误做法,几十个工具就该像检索文档一样检索工具。
  4. RAG 的天花板在检索不在模型:切块、混合召回、重排序、强制引用来源,四道工序决定上限。
  5. Agentic RAG 是「管理一次调查」:搜什么、何时停、证据够不够、来源冲突了怎么办——检索次数多不算数,证据链可回放才算数。
  6. GUI 世界没有错误码,只有安静走偏;界面接地是持续状态感知,不是识别一次就完事——把画面当状态,别当照片。
  7. 沙箱、最小授权、观测接口是安全外壳三件套,缺一不可;差分反馈优于全文重发——告诉系统「哪些变了」,比把整个世界再读一遍更省更准。
  8. 凭证要短时化、会话化:权限的大小 = 判断失误时错误能扩散的范围。
  9. 高风险接口把「预览/执行/确认/提交」分开,写操作带请求标识;幂等是长任务闭环的救生衣。
  10. 生态的壁垒在接口层不在模型层——能被稳定发现、清楚描述、安全调用、持续审计的工具,才构成平台。

原文地图​

主题原书节原文位置
接口决定上限11 引言text/12-ch11.txt:5(搜“能力上限的决定”) · text/12-ch11.txt:8(搜“能改变什么、能验证什么”) · text/12-ch11.txt:10(搜“而在接口层”)
粗糙 vs 良好11 引言(表 11.1)text/12-ch11.txt:26(搜““搜索””) · text/12-ch11.txt:34(搜“失败信号”) · text/12-ch11.txt:40(搜“权限边界”)
函数调用定义11.1.1text/12-ch11.txt:53(搜“函数调用（function calling）”) · text/12-ch11.txt:57(搜“真的去做”)
工具多错误多11.1.1text/12-ch11.txt:62(搜“自动提升模型的整体可靠性”) · text/12-ch11.txt:63(搜“重复执行”)
三年演进11.1.1text/12-ch11.txt:73(搜“JSON Schema 声明函数”) · text/12-ch11.txt:76(搜“解码约束”) · text/12-ch11.txt:79(搜“核心抽象”)
MCP 定位11.1.2text/12-ch11.txt:83(搜“Model Context Protocol”) · text/12-ch11.txt:85(搜“私有按钮”)
三个问题11.1.2text/12-ch11.txt:86(搜“如何被发现”) · text/12-ch11.txt:87(搜“失败语义以何种机器可读”)
只解决连接11.1.2text/12-ch11.txt:94(搜“零散 API 再多也补不上”) · text/12-ch11.txt:95(搜“并不自动解决权限”)
三者对比11.1.2text/12-ch11.txt:100(搜“Function Calling更像”) · text/12-ch11.txt:108(搜“三类资产”) · text/12-ch11.txt:118(搜“不同时间尺度的问题”)
工具检索11.1.3text/12-ch11.txt:121(搜“找到“这一刻该用哪个””) · text/12-ch11.txt:123(搜“吃光预算”) · text/12-ch11.txt:126(搜“Top-𝑘 个候选工具”)
检索的坑与进阶11.1.3text/12-ch11.txt:127(搜“召回失准”) · text/12-ch11.txt:129(搜“两阶段检索”) · text/12-ch11.txt:130(搜“输出常被下一个工具消费”)
工具库五件套11.1.3text/12-ch11.txt:134(搜“统一工具描述格式”) · text/12-ch11.txt:136(搜“执行沙箱”) · text/12-ch11.txt:137(搜“可治理”)
训练进模型11.1.3text/12-ch11.txt:141(搜“监督微调”) · text/12-ch11.txt:146(搜“按结果给奖励”) · text/12-ch11.txt:152(搜“BFCL”)
四件更难的事11.1.3text/12-ch11.txt:154(搜“何时不该调工具”) · text/12-ch11.txt:155(搜“分水”)
RAG 两步走11.2.1.1text/12-ch11.txt:176(搜“嵌入模型，比如 BGE”) · text/12-ch11.txt:178(搜“拼到提示里”)
时效与私有11.2.1.1text/12-ch11.txt:180(搜“知识时效性”) · text/12-ch11.txt:181(搜“模型不知道公司内部文档”)
检索是瓶颈11.2.1.2text/12-ch11.txt:189(搜“模型只占成败的一小部分”) · text/12-ch11.txt:191(搜“chunking”) · text/12-ch11.txt:195(搜“天花板”)
幻觉换形态11.2.1.2text/12-ch11.txt:196(搜“变成“模型基于检索回来的错误”) · text/12-ch11.txt:198(搜“citation”)
2025 新主线11.2.1.2text/12-ch11.txt:204(搜“Reranker 模型成为标配”) · text/12-ch11.txt:209(搜“语义切块”) · text/12-ch11.txt:211(搜“上下文检索”) · text/12-ch11.txt:219(搜“RRF”)
顶级模型输给精调检索11.2.1.2text/12-ch11.txt:224(搜“输给一个用中等模型”)
RAG 边界11.2.1.3text/12-ch11.txt:228(搜“全文理解”) · text/12-ch11.txt:231(搜“微调（第5章）比 RAG 更直接”)
Agentic RAG11.2.1.4text/12-ch11.txt:237(搜“决策”) · text/12-ch11.txt:238(搜“何时停”) · text/12-ch11.txt:243(搜“知道去哪里继续找”)
合同案例11.2.1.4text/12-ch11.txt:253(搜“责任限制条款”) · text/12-ch11.txt:256(搜“追加检索隐私附件”)
证据链与停止条件11.2.1.4text/12-ch11.txt:258(搜“检索次数多本身并不算数”) · text/12-ch11.txt:262(搜“停止条件”) · text/12-ch11.txt:266(搜“可审计的调查流程”)
真实软件世界11.3.1text/12-ch11.txt:293(搜“脏乱得多”) · text/12-ch11.txt:294(搜“日志和报错的文”) · text/12-ch11.txt:296(搜“非结构化的行动世界”)
Computer Use 与 Browser Use11.3.2text/12-ch11.txt:303(搜“两个代表性方向”) · text/12-ch11.txt:307(搜“权限边界和可回滚机制”)
API vs GUI 出错方式11.3.2text/12-ch11.txt:309(搜“错误码”) · text/12-ch11.txt:311(搜“没有走偏”)
时间线11.3.2text/12-ch11.txt:316(搜“三件套操作真实计算机”) · text/12-ch11.txt:318(搜“Operator”) · text/12-ch11.txt:322(搜“扩展到整台电脑”)
两者取舍11.3.2text/12-ch11.txt:330(搜“适用范围”) · text/12-ch11.txt:336(搜“安全风险”) · text/12-ch11.txt:345(搜“混合型智能体”)
报销实战切面11.3.2text/12-ch11.txt:349(搜“可追踪的报销记录”) · text/12-ch11.txt:352(搜“重复报销提示”) · text/12-ch11.txt:356(搜“金额超过阈值”) · text/12-ch11.txt:360(搜“该交给人”)
ACI11.3.3text/12-ch11.txt:363(搜“Agent-Computer Interface”) · text/12-ch11.txt:367(搜““机机界面””) · text/12-ch11.txt:371(搜“压给模型自己猜”)
GUI grounding11.3.4text/12-ch11.txt:381(搜“界面接地（GUI grounding）”) · text/12-ch11.txt:386(搜“而非一张静态照片”) · text/12-ch11.txt:391(搜“持续状态感知问题”)
沙箱三级11.4.1text/12-ch11.txt:407(搜“能删任何文件、”) · text/12-ch11.txt:410(搜“沙箱（sandbox）”) · text/12-ch11.txt:412(搜“容器级隔离”) · text/12-ch11.txt:413(搜“虚拟机级隔离”)
沙箱逃逸与三件套11.4.1text/12-ch11.txt:419(搜“沙箱逃逸”) · text/12-ch11.txt:423(搜“安全外壳，缺一不可”)
工具编排11.4.2text/12-ch11.txt:428(搜“工具编排问题”) · text/12-ch11.txt:430(搜“前后依赖关系的工具网络”) · text/12-ch11.txt:436(搜“人类经验””) · text/12-ch11.txt:439(搜“搭建一套可被模型操作的行”)
幂等11.4.3text/12-ch11.txt:444(搜“幂等性（idempotency）”) · text/12-ch11.txt:446(搜“重复提交表单”)
四阶段与写校验11.4.3text/12-ch11.txt:448(搜““预览””) · text/12-ch11.txt:452(搜“草案或差异”) · text/12-ch11.txt:453(搜“请求标识”) · text/12-ch11.txt:459(搜“写前验证””)
长任务的放大链11.4.3text/12-ch11.txt:466(搜“不断放大”) · text/12-ch11.txt:467(搜“缩小这种”) · text/12-ch11.txt:464(搜“默认工具”)
最小授权11.4.4text/12-ch11.txt:473(搜“判断失误时最多能把错误”) · text/12-ch11.txt:477(搜“least privilege”) · text/12-ch11.txt:481(搜“显式承诺状态”)
临时凭证与会话11.4.4text/12-ch11.txt:485(搜“持续暴露面”) · text/12-ch11.txt:485(搜“当前动作类别生效”) · text/12-ch11.txt:488(搜“万能钥匙”) · text/12-ch11.txt:494(搜“可治理的系统”)
观测接口11.4.5text/12-ch11.txt:498(搜“怎么知道自己做完了什”) · text/12-ch11.txt:497(搜“状态探针”) · text/12-ch11.txt:505(搜“结构化探针”)
差分反馈11.4.5text/12-ch11.txt:509(搜“差分反馈同样关键”) · text/12-ch11.txt:510(搜“哪些对象变了”) · text/12-ch11.txt:511(搜“稳定差”)
接口设计与治理11.5text/12-ch11.txt:524(搜“系统性脆弱”) · text/12-ch11.txt:528(搜“失败信号可识别”) · text/12-ch11.txt:540(搜“平台规则”) · text/12-ch11.txt:541(搜“不可维护的混乱集合”)
壁垒在接口11.5.2text/12-ch11.txt:543(搜“壁垒也许不在某个模型有多强”) · text/12-ch11.txt:551(搜“可复用能力”)

Footnotes​

  1. 出处:「第11章」引言第 20 段(text/12-ch11.txt:20,搜“接口没有把工具边界”)与第 21 段(text/12-ch11.txt:21,搜“更容易被治理的行动通道”)。 ↩ ↩2

  2. 出处:表 11.1 第 24 至 44 段(text/12-ch11.txt:24,搜“接口要素”;text/12-ch11.txt:34,搜“失败信号”;text/12-ch11.txt:40,搜“权限边界”;text/12-ch11.txt:43,搜“观测反馈”)。 ↩

  3. 出处:引言第 7 段(text/12-ch11.txt:7,搜“通用认知内核”)。 ↩

  4. 出处:「11.1.1」第 53 段(text/12-ch11.txt:53,搜“function calling”)与第 56 段(text/12-ch11.txt:56,搜“告诉你应该做什么”)。 ↩

  5. 出处:第 58 段(text/12-ch11.txt:58,搜“失败信号，而光”)与第 59 段(text/12-ch11.txt:59,搜“表面智能、实际脆弱”)。 ↩

  6. 出处:第 63 段(text/12-ch11.txt:63,搜“错误类型也会随之增加”)。 ↩

  7. 出处:「从函数调用到结构化输出」第 79 段(text/12-ch11.txt:79,搜“prompt 技巧”)至第 79 段(text/12-ch11.txt:79,搜“核心抽象”)。 ↩

  8. 出处:「11.1.2」第 83 段(text/12-ch11.txt:83,搜“Model Context Protocol”)。 ↩

  9. 出处:第 86 段(text/12-ch11.txt:86,搜“如何被发现”)。 ↩

  10. 出处:「MCP 与 Function Calling、OpenAPI 的差别」第 97 段(text/12-ch11.txt:97,搜“2024 年 11 月正式发布”)与第 108 段(text/12-ch11.txt:108,搜“三类资产”)。 ↩ ↩2

  11. 出处:第 118 段(text/12-ch11.txt:118,搜“不同时间尺度的问题”)。 ↩

  12. 出处:第 95 段(text/12-ch11.txt:95,搜“并不自动解决权限”)。 ↩

  13. 出处:「11.1.3」第 121 段(text/12-ch11.txt:121,搜“这一刻该用哪个”)与第 123 段(text/12-ch11.txt:123,搜“吃光预算”)。 ↩

  14. 出处:「工具检索（tool retrieval）方法」段(text/12-ch11.txt:124,搜“像“文档”一样建索引”)。 ↩

  15. 出处:第 127 段(text/12-ch11.txt:127,搜“召回失准”)与第 129 段(text/12-ch11.txt:129,搜“两阶段检索”)、第 130 段(text/12-ch11.txt:130,搜“输出常被下一个工具消费”)。 ↩

  16. 出处:「工具库构建」段第 134 段(text/12-ch11.txt:134,搜“统一工具描述格式”)与第 137 段(text/12-ch11.txt:137,搜“可治理”)。 ↩

  17. 出处:「工具学习训练」段第 141 段(text/12-ch11.txt:141,搜“监督微调”)与第 146 段(text/12-ch11.txt:146,搜“按结果给奖励”)、第 147 段(text/12-ch11.txt:147,搜“SFT 先打底”)。 ↩

  18. 出处:第 152 段(text/12-ch11.txt:152,搜“BFCL”）与第 153 段(text/12-ch11.txt:153,搜“REST 等多种场景”)。 ↩ ↩2

  19. 出处:第 154 段(text/12-ch11.txt:154,搜“何时不该调工具”)。 ↩

  20. 出处:「11.2.1.1」第 177 段(text/12-ch11.txt:177,搜“𝑘 = 3–10”)与第 179 段(text/12-ch11.txt:179,搜“参考资料”)。 ↩

  21. 出处:第 180 段(text/12-ch11.txt:180,搜“知识时效性”)与第 181 段(text/12-ch11.txt:181,搜“模型不知道公司内部文档”)。 ↩

  22. 出处:「11.2.1.2」第 189 段(text/12-ch11.txt:189,搜“模型只占成败的一小部分”)与第 191 段(text/12-ch11.txt:191,搜“chunking”)、第 192 段(text/12-ch11.txt:192,搜“hybrid retrieval”)。 ↩

  23. 出处:「2025 工业级 RAG 的几条新主线」第 204 段(text/12-ch11.txt:204,搜“Reranker 模型成为标配”)、第 209 段(text/12-ch11.txt:209,搜“语义切块”)、第 210 段(text/12-ch11.txt:210,搜“晚切块”)、第 211 段(text/12-ch11.txt:211,搜“上下文检索”)、第 215 段(text/12-ch11.txt:215,搜“ColBERT”)、第 219 段(text/12-ch11.txt:219,搜“RRF”)。 ↩ ↩2

  24. 出处:第 223 段(text/12-ch11.txt:223,搜“不在生成模型”)与第 224 段(text/12-ch11.txt:224,搜“输给一个用中等模型”)。 ↩ ↩2

  25. 出处:第 196 段(text/12-ch11.txt:196,搜“基于检索回来的错误”)与第 198 段(text/12-ch11.txt:198,搜“citation”)。 ↩

  26. 出处:「11.2.1.3」第 228 段(text/12-ch11.txt:228,搜“全文理解”)与第 231 段(text/12-ch11.txt:231,搜“微调（第5章）比 RAG 更直接”)、第 232 段(text/12-ch11.txt:232,搜“长文档靠长上下文整体阅读”)。 ↩

  27. 出处:「11.2.1.4」第 236 段(text/12-ch11.txt:236,搜“多轮迭代的证据收集过程”)。 ↩

  28. 出处:第 237 段(text/12-ch11.txt:237,搜“决策”)与第 238 段(text/12-ch11.txt:238,搜“何时停”)。 ↩

  29. 出处:「Agentic RAG 的实际形态」段第 253 段(text/12-ch11.txt:253,搜“责任限制条款”)与第 255 段(text/12-ch11.txt:255,搜“同一司法辖区”)、第 256 段(text/12-ch11.txt:256,搜“追加检索隐私附件”)。 ↩

  30. 出处:第 259 段(text/12-ch11.txt:259,搜“管理一次调查”)与第 262 段(text/12-ch11.txt:262,搜“停止条件”)、第 265 段(text/12-ch11.txt:265,搜“交给人判”)。 ↩

  31. 出处:第 258 段(text/12-ch11.txt:258,搜“检索次数多本身并不算数”)。 ↩

  32. 出处:「11.3.1」第 293 段(text/12-ch11.txt:293,搜“脏乱得多”)与第 294 段(text/12-ch11.txt:294,搜“日志和报错的文”)。 ↩

  33. 出处:「11.3.2」第 303 段(text/12-ch11.txt:303,搜“两个代表性方向”)。 ↩

  34. 出处:「2024–2025 时间线」第 316 段(text/12-ch11.txt:316,搜“三件套操作真实计算机”)、第 314 段(text/12-ch11.txt:314,搜“Operator”)、第 320 段(text/12-ch11.txt:320,搜“browser-use”)。 ↩ ↩2

  35. 出处:第 322 段(text/12-ch11.txt:322,搜“扩展到整台电脑”)。 ↩

  36. 出处:「两条路径的取舍」第 330 段(text/12-ch11.txt:330,搜“适用范围”)与第 336 段(text/12-ch11.txt:336,搜“安全风险”)。 ↩

  37. 出处:第 345 段(text/12-ch11.txt:345,搜“混合型智能体”)。 ↩

  38. 出处:第 309 段(text/12-ch11.txt:309,搜“错误码”)与第 311 段(text/12-ch11.txt:311,搜“没有走偏”)。 ↩

  39. 出处:「11.3.4」第 381 段(text/12-ch11.txt:381,搜“界面接地（GUI grounding）”)。 ↩

  40. 出处:第 386 段(text/12-ch11.txt:386,搜“而非一张静态照片”)。 ↩

  41. 出处:第 391 段(text/12-ch11.txt:391,搜“持续状态感知问题”)。 ↩

  42. 出处:「11.4.1」第 407 段(text/12-ch11.txt:407,搜“能删任何文件、”)与第 410 段(text/12-ch11.txt:410,搜“沙箱（sandbox）”)。 ↩

  43. 出处:第 411 段(text/12-ch11.txt:411,搜“进程级隔离”)、第 412 段(text/12-ch11.txt:412,搜“容器级隔离”)、第 413 段(text/12-ch11.txt:413,搜“虚拟机级隔离”)。 ↩

  44. 出处:第 419 段(text/12-ch11.txt:419,搜“沙箱逃逸”)与第 423 段(text/12-ch11.txt:423,搜“安全外壳，缺一不可”)。 ↩

  45. 出处:「11.4.2」第 428 段(text/12-ch11.txt:428,搜“工具编排问题”)与第 430 段(text/12-ch11.txt:430,搜“前后依赖关系的工具网络”)。 ↩

  46. 出处:第 433 段(text/12-ch11.txt:433,搜“持续传递”)与第 434 段(text/12-ch11.txt:434,搜“可组合性”)。 ↩

  47. 出处:第 436 段(text/12-ch11.txt:436,搜“人类经验”)与第 439 段(text/12-ch11.txt:439,搜“搭建一套可被模型操作的行”)。 ↩

  48. 出处:「11.4.4」第 473 段(text/12-ch11.txt:473,搜“判断失误时最多能把错误”)。 ↩

  49. 出处:第 477 段(text/12-ch11.txt:477,搜“least privilege”)、第 480 段(text/12-ch11.txt:480,搜“短时权限”)、第 485 段(text/12-ch11.txt:485,搜“持续暴露面”)、第 485 段(text/12-ch11.txt:485,搜“当前动作类别生效”)。 ↩ ↩2

  50. 出处:第 489 段(text/12-ch11.txt:489,搜“执行会话”)与第 491 段(text/12-ch11.txt:491,搜“统一撤销”)。 ↩

  51. 出处:「11.4.3」第 444 段(text/12-ch11.txt:444,搜“幂等性（idempotency）”)与第 446 段(text/12-ch11.txt:446,搜“重复提交表单”)。 ↩

  52. 出处:第 448 段(text/12-ch11.txt:448,搜““预览””)、第 452 段(text/12-ch11.txt:452,搜“草案或差异”)、第 453 段(text/12-ch11.txt:453,搜“请求标识”)。 ↩

  53. 出处:第 459 段(text/12-ch11.txt:459,搜“写前验证”)与第 459 段(text/12-ch11.txt:459,搜“写后检查”)。 ↩

  54. 出处:第 466 段(text/12-ch11.txt:466,搜“不断放大”)与第 467 段(text/12-ch11.txt:467,搜“缩小这种”)。 ↩

  55. 出处:第 464 段(text/12-ch11.txt:464,搜“默认工具”)。 ↩

  56. 出处:「11.4.5」第 498 段(text/12-ch11.txt:498,搜“怎么知道自己做完了什”)与第 500 段(text/12-ch11.txt:500,搜“稳定的状态探针”)。 ↩

  57. 出处:第 505 段(text/12-ch11.txt:505,搜“结构化探针”)与第 507 段(text/12-ch11.txt:507,搜“世界有没有变化”)。 ↩

  58. 出处:第 509 段(text/12-ch11.txt:509,搜“差分反馈同样关键”)与第 510 段(text/12-ch11.txt:510,搜“哪些对象变了”)。 ↩

  59. 出处:「11.5.2」第 540 段(text/12-ch11.txt:540,搜“平台规则”)与第 541 段(text/12-ch11.txt:541,搜“不可维护的混乱集合”)。 ↩

  60. 出处:第 543 段(text/12-ch11.txt:543,搜“壁垒也许不在某个模型有多强”)与第 551 段(text/12-ch11.txt:551,搜“可复用能力”)。 ↩ ↩2