agent tool 方法过多

很多人做 agent， 一 开始只会写 to call 令，但工具一多，问题就来了，谁来注册工具？谁来描述工具？谁来执行工具，工具失败了谁来兜底？这时候就需要 to list tree， 你 可以把它理解成 agent 的 工具注册中心，每个工具都会在这里登记工具名、工具描述、参数、 cd 码、执行函数和风险等级。大模型本身看不到 python 代码，它能看到的只有 name、 description 和 parameters， 所以 description 写得好不好会直接影响大模型会不会选对工具。 to register 的 核心流程很简单，第一步， l l m 根据工具描述决定调用哪个工具。第二步， to register 根据工具名找到真实函数。第三步，执行工具拿到结果。第四步，把 up s vision 再交回给 l l m， 让它继续推理或生成答案。这里最关键的一点是，工具失败不能让 a 阵 t 崩掉。工具不存在 参数错误，执行异常都应该统一返回 air， 这样 l l m 能知道工具调用失败，而不是整个接口直接五百。 to register 还要负责风险控制， low 风险工具，比如查时间计算，搜索知识库，可以自动执行 a 害风险工具，比如删除文档，发送邮件，必须进入审批流程。所以 to register 不是 普通工具列表，它是 agent 工具列表，它是 agent 工具调用的统一入口， 也是错误兜底和风险控制的核心。记住一句话， l l m 负责决定要不要调用工具。 to register 负责找到工具，执行工具都注错误。

大家好，今天是 ai agent 的 设计模式系列第七篇 to use， 让模型具备行动能力的最小闭环。上期瑞乌最后提了一句，其实工具调用还有不少角度可以聊，后面有机会再展开，这期就来展开，只是这期有点特殊， 前面我们讲了 react plan and execute reflection multi agent 瑞乌，但这一期不一样，它不是又一个上层策略，而是这些模式共同依赖的基石能力。 先问一个问题， aint 和纯聊天模型最关键的差别是什么？很多人会说 aint 可更聪明、更主动，更像个助手，但这些描述都太模糊。真正本质的差别其实很简单，有没有工具调用能力。看屏幕向左右两侧的对比， 左边是没有工具调用的状态，右边是有了工具调用之后没有工具调用。大模型主要还是会说，你问他天气，他可能给你编一段，今天北京大概二十度， 有了工具调用模型才开始真正会做。同样是问天气，他会调用天气接口，把真实数据拿回来，然后告诉你答案。 这就是 a g t 和纯聊天模型的分水岭，不是嘴上更厉害，而是真的能动手。那工具调用到底是什么？简单说就是三步循环，模型输出结构化调用意图。工程曾执行真实函数，结果塞回上下文，让模型继续 整个过程。模型没动手指，但结果是真的。屏幕下方的伪代码展示的就是这个最简形态。屏幕上这三张卡片就是这三部的拆解模型输出结构化意图，工程层接管执行 tour result 回流上下文。所以它不是和前面几期并列的上层模式，而是它们共同依赖的底层能力。 讲清楚它前面几期的逻辑会更清晰。接下来看论文层工具调用，有没有一篇像 react 那 样的代表作。答案是，没有那么单一，它更像一条逐步发展的研究脉络。我选了三篇来讲， 第一篇是二零二二年五月的 m r k l systems， 论文，编号 r c v 二二零五点零零四四五。它的核心贡献是把语言模型放在一个可路由的模块化系统里，重点不只是调用工具，而是模型加外部模块加支持元的系统架构， 这是工具调用的系统化起点。第二篇是二零二二年十月的 react， 论文，编号 act 两千两百一十点零三六二九。我们前面专门讲过这篇，严格说它不是纯工具调用论文，但它第一次把工具调用放进了思考、行动、观察的循环里， 让工具调用有了工程上可落地的执行范式。第三篇是二零二三年二月的 tofoam， 论文，编号 act 二三零二点零四七六幺。 这是最有代表性的工具调用论文之一。他直接回答了模型怎么学会，何时调用工具调用，哪个传什么餐，怎么把结果拼回去。核心是自监督学习，让模型自己 学会在什么位置插入工具调用。从时间线看，这三篇刚好对应三个阶段，先有系统设想，再有工程循环。 最后模型学会了自主调用。再看工程层屏幕上方两张卡片，是行业里最主流的两种接口形态，欧佩 ai 走函数调用接口， antropic 走原生的工具调用和工具结果消息快，接口形式不同，工程闭环的逻辑是一样的。 antropic 官方在工具调用文档里专门写了一节最佳实践 核心点，对应屏幕下方的三张卡片。第一，描述字段是整个工具定义里最关键的部分，模型靠它决定调用不调用这个工具。 antropic 的 介意是描述要写清楚这个工具做什么， 什么情况该用，什么情况不该用。第二，参数结构要最小化，能用媒体直覆盖的，不开放自由文本参数越多，模型生成脏参数的概率越高。第三，错误处理不能抛异常工具失败时要返回描述性文字作为 tool result， 让模型自己决定重试换工具还是报错。 这是工具调用可恢复性的核心，也是 on top 文档里反复强调的。我们重点拆一个工程壁环，看看 copy code 源码是怎么做的。 入口在奎瑞点 t s 这个文件里的奎瑞路派函数，这个 while true 不是 第一次在这个系列出现了。第四期， reflection 收过，模式一变，他承担的角色就变了。第五期，一个循环学会了，生出新的循环。第六期，在 runtooth 里做并发症。 这次我们从工具调用的视角来拆它，把夸克扣底元码的核心骨架抠出来。就这四步，第一步，调用模型流势，接收模型输出，同时收集所有 to o u s 请求。这里对应前面讲的模型，判定是否调用工具输出结构化调用意图。第二步，判断是否还需要继续。 如果这一轮没有产生任何工具调用，奎瑞洛普直接 return complete 退出，相当于模型主动决定不再调用工具，这一轮结束。第三步，调用 run to s 执行所有 to load use 请求，把执行结果收集起来。 这里就是工程层找工具叫验参数、查权限、执行真实函数的落地代码。第四步，状态更新，把模型的回复和工具执行结果一起并入对话历史，然后回到循环顶部，进入下一轮。 to 下划线， result 回流上下文的关键就在这一步，整个闭环就这四步， 其他代码都是围绕它做异常恢复、上下文压缩、权限校验这些工程加固，想跟原码的同学搜 query、 loop、 调用模型、 run tos 三个关键字就能拉出主线。 还有个有意思的点，上期我们看 roundtooth 里做了并发症，这期再看同一个位置，它还藏了另一层东西。 屏幕右侧的代码框展示的就是这个结构。在 roundtooth 调用执行器的前后， clock code 分 别挂了前置勾子和后置勾子。前置勾子做预检，可以在工具真正执行前拦截改写参数或请求用户确认。后置勾子在工具返回后运行，可以补充上下文，修饰结果， 甚至阻断整个循环继续。这层扩展能力让工具调用不只是调用函数，而是真正变得可控、可观测、可拦截。软件工程新范式系列第五期里，我们拆过 bash to 我 的九个独立校业模块， 它其实就是前置钩子在生产环境里的真实形态。工具调用的工程价值不在于能调用，而在于可控制。 最后，我们把工具调用和前面讲过的模式放到一张图里看看看屏幕上这三层结构， react action plan and execute the execute revolve the worker reflection 反思的对象说他们都依赖工具调用，对谈不够准确，具体怎么依赖得分层看。 第一层，直接依赖 react 的 action， 步骤就是工具调用。没有工具调用的话， action 只是语言输出。 multi agent 的 派生子， agent 靠的是 agent two， 而 agent two 本身就是一次 too 了 use 这两个模式在机制层面直接绑定。第二层，间接依赖 plan and execute 和瑞乌执行时都要用工具，但让它们独特的地方不是用工具这件事，而是它们各自的规划方式。 rev the work orders 虽然就是预排好的工具调用列表，但它之所以是锐入，靠的是先想后做的组织方式，工具只是执行手段。第三层， reflection actor 在 某些任务里会用工具，但这不是 reflection 的 定义特征。 reflection 的 本质是语言反思与跨轮次记忆， 它可以包裹任意执行模式和工具调用，没有直接因果，所以没有 to use。 前面这些模式讲的所有行动都只是语言幻觉。本期内容就到这里了，感觉有所收获的同学可以点赞、收藏加关注，我们下期见！

不知道大家有没有发现，那些整天把 ag 的 挂在嘴边，左手一个 skill， 右手一个 mcp 的 人，你就让他讲讲 function calling to mcp skill 到底有什么区别？大部分人啊，可能都说不清， 现在的 ai 让所有人都觉得什么都能包成一个 skill， 仿佛万物皆可 skill 化。那今天我就把这四个词从底往上的帮你拆解一遍。 先说我的结论，这四个东西啊，本质上都是软件工程里面的老物件了，换了个 ai 时代的名字而已。比如说 function calling 就是 函数的调用，错，就是工具的执行， m c p 就是 原本的客户端加上服务端的机制， skill 则是原本的按需加载。这些啊，只要做过几年软件的人都见过，所以没什么神秘的。 但我今天不是来否定他们的，就瓶装新酒啊，不是坏事，关键是你得搞清楚这个瓶子是什么形状的，不然一堆名词满天飞，你分不清楚他们是一回事还是不同的概念出了问题也不知道该去哪里查。那我相信看完今天的视频，你将会对这些名词有更深刻的认知。 先从最底层的说起，方克逊 calling 也叫 to use， 是 同一个东西，只不过不同的厂商叫法不同而已。要理解方克逊 calling 啊，我们先得承认大模型一个本质上的局限，有时大模型只能输出文字，不能执行任何的操作。 比如说你让他帮你查询今天最新的国际新闻，大模型是没有办法自己发送查询请求的，那怎么让他调用工具呢？工程师想了个办法，让他输出一种特殊格式的文字结构化的调用意图。 大模型不会直接回答你查询新闻，而是输出调用 get news 这个工具，然后由外面的程序去解析这段指令，真正发请求去拿新闻，拿到结果之后再喂给模型，模型最后生成你想要看到的那句回答， 这就是 function calling。 大 模型能识别出我们提供给他的工具清单，并且它能够准确地根据我们的需求识别出需要调用的工具。说白了， function calling 就是 大模型的一种能力。 这里有一个细节很重要，就是执行循环，完整的流程是你发消息，模型输出调用的意图，程序执行结果返回给模型，模型继续推理，可能再调用下一个工具再执行，直到模型觉得够了，输出最终的回答， 这个循环可能会转很多圈。复杂任务里面调用五六个工具啊，是很正常的。管理这个循环是应用层的责任，不是模型的。 那现在很多大模型开发用的 longchain、 spring ai 这类框架，本质上就是帮你去管理这个循环的，它帮你把代码里的函数转成模型，需要的 json 帮你跑。执行循环帮你屏蔽各家的 api 格式差异，比如说 open ai 叫 tools， astropik 叫 tool use。 但你要知道一件事，框架是换汤不换药的，核心的决策永远是大模型在做，要调用哪个工具，什么时候调，参数是什么，这些判断全是模型的， 那模型下完指令后，谁来执行呢？执行的那个东西啊，就叫拓工具，本质上就是一个代码的函数和方法，你可以理解为大模型是只动嘴不动手的，那拓就是给它赋予了可支配操作的能力。 拓可以根据 a 件的边界分为两类，第一类，内部工具，比如说读文件、写文件，执行终端命令， a 件的在内部可以直接搞定，你用格式扣的帮你改写代码，他调用的大量的都是这些类，全在本地的文件系统里面转。 第二类，外部工具，比如本地 agent 不 具备调用第三方服务的能力，得通过另一种方式集成进来。这种实现方式啊，就是 m c p。 m c p 接进来的能力本质上是属于外部工具，只不过走的是标准化路由。这里先记住一个结论， m c p 和 two 是 平级的关系， m c p 是 外部工具的一种接入方式，不是比 two 更高一层的东西。从本质上来说， m c p 的 机制其实就是软件工程的客户端和服务端架构换了个名字而已。 m c p client 就是 客户端， m c p server 就是 服务端。 m c p 的 协议就是定义两端是怎么通信的接口，规范他们怎么握手，怎么传数据，用什么格式。如你做过后端啊，一听就会明白，这个东西就是你一直在写的 rest api， 或者 r p c。 现在直播叫 m c p， 那为什么要叫 m c p？ 我 觉得一部分是 ai 时代的命名游戏概念重新包装，听起来更有分量，但这不是重点，重点是它解决了一个真实的工程问题。在 m c p 出现之前， ai 工具的集成是一坨烂账。 假设你有三个 ai 的 客户端， cloud code codex cursor， 你 想让他们都能接入查询新闻的服务，那三个团队需要各自去写新闻集成同样的活做三遍，这是任何工程师都不想碰的重复劳动。 那 m c p 就是 ai 工具生态的管理标准。比如说新闻中心按 m c p 的 规范做一个 server， 所有的兼容 m c p 的 客户端都能够接受，这就是 m c p 的 核心价值， 不是技术革命，是标准化带来的效率提升。但是 m c p 确实有一个地方比传统的 rest api 多了一层，叫能力字描述普通 api， 你 的客户端必须提前知道它有哪些接口，参数是什么，要么读文档，要么硬编码，不知道就没法用。 mcp server 就 不一样，他一启动就会主动的告诉 plan， 我 这里有这些工具，这些数据源，这些功能，用标准的格式自动列出全部的能力。 plan 运行时动态发现，不需要提前印编码。 这对 ai 的 场景来说非常的关键，因为大模型需要在运行时知道我现在手里有哪些武器，才能够做出正确的工具选择。这个动态发现的能力是 mcp， 比普通 api 调用真正多出来的地方。 说到这，你肯定就会发现，本质上 to 也能够实现 m c p 的 功能。比如说查询新闻的 m c p， 我 也可以在自己的 a 站内部直接对接查询新闻的 api， 把它包装成一个 to， 作为内部的 to 来调用。所以了解了这两个的本质啊，在合适的场景下使用不同的方式才是最关键的。 那现在大模型具备了 function calling 的 能力，也有了 two m c p 的 工具清单，但有时候还是发挥不稳定怎么办？这时候就需要 skill 登场了。但是 skill 是 我觉得最容易被过度包装的一个，说白了还是提示词，只不过用了按需加载的逻辑。 先说为什么要按需加载，因为 agent 能力越来越多，但是上下文是有限的，你不可能把几十个工作流的完整提示词全部塞进上下文里面，这样的话不止脱口成本会爆炸，模型在一堆信息里面反而选不准，甚至超出了窗口的限制。 解决方案很简单，上下文里面只需要放能力的目录，每项能力只有一个名字和一句话，说明模型选中某个能力之后，再把这个能力的完整内容加载进来，用完就清掉。就是这个逻辑，没有更复杂的东西。 那在 skill 这个词出现之前，很多成熟的 ag 的 系统其实早都已经在用了。 esoteric 不是 发明了这个东西，而是把它规范化了，起了个名字，做成了可以分发的标准格式。你可能会说，那这不就是换汤不换药吗？ 对，原理层面确实是，但是规范化之后啊，有一个真实的价值能力是可以被分发和附用的。你自己做了一套好用的工作流，打包成 skill 发布出去，其他人可以直接安装。直接用个人做的东西啊，可以被放大，这个杠杆效应是散装提示词做不到的。 你的能力不只是在自己的电脑上跑，也可以跑在成千上万人的工具里面。好，现在我们把四层放在一起，从底往上的总结一遍。第一层，大模型本底只做下面令，但是不会直接动手，突出的是结构化的调用意图。 第二层， function calling 是 大模型的一种能力，规定了指令的格式和传递方式，框架负责跑直线循环，把结果未回给模型。第三层， to 和 mcp 本质上都是执行单元，内部工具本地直接跑外部工具，通过 m c p 这套标准化路由出去，两者是平级的。第四层， skill 能力打包层，按需加载，解决标准化流程和上下文装不下的问题， 同时创造了能力可以分发的生态。这四个概念各守一层，没有谁替代谁，出了问题也是各自负责那一层要解决的事情。 ok， 那 以上就是本期关于 function calling two mcp skill 的 概念分享，如果对大家有帮助的话，希望能得到你们的点赞和关注。我是布鲁，一位专注于 ai 科普和高阶玩法的博主，我们下期视频再见。

工具、 m c p， 技能，这三个词几乎总一起出现，可它们各有各的角色，特别容易搞混。 先说工具英文 tool， 它是 ai 能动手做的一个动作，发一条数据库，查询、读一个文件，调一个接口，每个都得单独写一套对接，又累又乱。 m c p 不是 工具，它是一个标准接口， 它之于 ai， 就 像 usb 之于硬件。以前你想让 ai 连上你的数据库，你的 github， 你 的文档，每一个都得单独写一套对接，又累又乱。 mcp 把这事标准化了， 工具和数据照同一个口来，接，一次接好，哪个 ai 都能用。所以它管的不是做什么，是怎么接进来。 技能英文 skill 是 一套做事的套路，他自己不动手，而是教 ai 遇到这类活，分几步，先调哪个工具，按什么顺序。说白了是给 ai 的 一份说明书， 串起来就清除了。你问 ai 上个月哪个产品卖得最好，他去发查询，把数据捞出来，靠的是工具，他能连上你那个数据库，靠的是 m c p 这个标准口， 他知道该查哪张表，怎么把结果讲成人话，靠的是技能。工具给他手， m c p 给他接口，技能给他章法，这三样配齐，才把一个模型变成一个真能干活的 ai。

大家好，因为 opencloud 带来的 agent 热度不减，从今天开始，我开启一个新的专栏，叫做 agent skill 设计范式，希望通过这个系列，让大家人人都能够用得上 agent， 并且设计出更好的智能题。 今天先来讲一讲 agent skill 设计九大模式里的 tour wrapper 工具封装模式。在聊这个模式之前，咱们先用大白话解释一下什么是 agent skill。 你可以把大模型，也就是 ai 想象成一个刚毕业博学多才但是缺乏社会经验的大学生，虽然他什么都懂一点，但如果你直接让他去写你们公司的代码或者处理合同，他肯定会因为不了解你们公司的规矩而碰壁。 agent skill 就是 给你的这个 ai 穿上职业装， 或者说是递给他的岗位手册，让他能从一个通采瞬间变成某个领域的专家。那么这种 tour wrapper， 也就是工具封装类型的 agent skill 到底是什么呢？我们可以打个比方想象一下，大模型就是一个非常厉害的厨师，他会做全世界的菜，但是每个厨房的灶具不一样， 调料放的位置也不一样。如果你直接跟他说给我做个红烧肉，他可能因为找不到你们家的老抽在哪，或者不知道你们家习惯使用电磁炉还是燃气灶，最后做的一塌糊涂。这时候托尔韦普就出场了， 他就像是为这个厨师专门准备的一个厨房外挂包，这个包里不装具体的食材，而是装满了你们家厨房的使用说明书和操作规范。比如调料放在哪层， 火会怎么控制，抹布必须怎么叠，为什么要费劲做这个封装呢？主要有两个原因，一怕他记不住。虽然 ai 知道通用的知识，但他不知道你们公司特定的技术约束或者规范。比如虽然他会写代码，但他不知道你们团队规定变量命名必须用驼峰命名法。 二是怕他脑子乱。如果你把成千上万页的说明书一股脑的塞到 ai 的 脑子里，也就是塞进上下文里，它处理起来就会非常的慢，甚至会产生幻觉。 toypper 的 核心思想就是平时不加载， 只有当活儿来了，需要用到这个特定技能时，才让 ai 临时翻阅这个专家手册。在实际应用中， toypper 非常常见，比如代码规范， 把你们团队的 react 或 python 代码的开发最佳实践封装起来。当 ai 帮你写代码时， 他就像是坐在你对面有着十年经验的同事，你们的代码风格也一模一样。平台接入，比如你们公司有一个复杂的内部报销系统，你可以把系统的 api 调用规则封装成 skill， ai 不 需要背下整个系统的逻辑，只要他知道现在需要报销了，我要去翻那本报销手册， 它就能精准地完成任务。简单来说， tourwiper 就是 把复杂的工具规则 sdk 包装成一个按需加载的模块，让 ai 在 特定领域内变得既专业又挺化。它经常和 rooting， 也就是路由模式配合使用， 由路由来判断现在的活需不需要打开这本专家手册，这个 rooting 也是我们后续会分享的设计模式之一。下个视频我们说一说 agent skill 的 第二个设计范式， renderer， 也就是生成器模式，我们下个视频见。

你以为工业 agent 就是 大模型 top rank？ 再加点工具调用？我跟你说句大实话，这么干在工业现场必出事。 不是效果差，是你这套东西压根没资格上线。工业 agent 跟你平时聊的这个聊天， a 型的完全是两个物种，你那套多人对话，工具调用，向量解锁，在工业里面只有一个结局，翻车。为什么？因为工业现场有四条铁律，一条都不能破。第一，不能错， 错一次可能就是停产，设备损坏甚至安全事故。第二，必须可控人，随时能接管。 ai 不是 老板， ai 只是建议者。第三，必须实时好，秒级响应，不是秒级，更不是分钟级。 第四，必须稳定，七天二十四小时不崩，断网断电，异常输入都得扛得住。所以你从一开始就得转思路，不是做一个聪明的 ai， 而是做一个不会出事的系统。 第一，架构问题，云还是边，我直接说答案，控制必须在边缘。你想想工厂断网了， a 型的还能不能干活？不能的话这项目就别上了，还要设计降级方案。 ai 不 行，能不能切回规则，系统，能不能人工接管？这些没想清楚，连试点的资格都没有。第二，闭环设计，这是生死线。 工业 agent 不是 聊天，是一个完整的闭环，感知、决策、执行、反馈、校验、修正，你发的指令，谁确认执行成功了？失败了？是从事回滚还是报警？ 很多人做的 agent 看起来很聪明，但一问闭环就卡住，等于没做。第三，大模型别乱用，尤其是别让他直接控制设备，这是最大的坑。正确姿势应该是，大模型负责决策建议 规则，系统负责审核效应 l l m 提案，工业规则过滤确认后才执行，不然一个幻觉现场就出事故。第四点， 幻觉不是优化问题，是事故源。你必须做到三点，能验证的走 red 带依据不确定的坚决不执行，所有决策全留痕，可追溯。记住一句话，在工业现场，不确定等于禁止执行。 第五，真正的难点不在模型，在工程协议对接 modbus o p c u a m q t t。 当数据处理、异常检测、设备适配，甚至很多设备连接口都不给你，这才是现实，模型再牛，接不上设备等于零。第六，安全机制必须拉满 高危指令，走白名单，操作分权限，关键动作二次确认。一句话，工业环境里， ai 没有自由发挥的空间。第七，开源 a 型的框架级别神话 auto gpt， long graph， 这些能用，但也只限于流程编排， 真正核心的东西你得自己写。安全效益成工业工具库，审计系统、人工接管机制框架给不了你这些，所以你一定要明白，你不是在做更聪明的 ai， 你 是在做一个绝对安全、绝对可靠、绝对可控的工业系统。最后，我把二零二六年进阶大模型的最新路线整理出来了， 大厂资深算法工程师准备的内部文档，模型原理、产品落地、完整，思维框架都有，从懂一点到能做项目啊，那条路写的清清楚楚，需要的话直接安排。

大家好，欢迎来到阿新聊 ai， 希望看完关注我哦，有企业咨询、企业 ai 转型定制的需求也要找我哦。今天这期我们讲 to call 领深入，它适合正在做 agent、 函数调用、工具编排或者企业 ai 落地的人看。很多人第一次接触这个概念，会以为它就是给模型挂几个工具，让模型需要的时候调用一下。 但真正放进生产系统里，你会发现问题复杂的多。模型可能选错工具参数可能传错，返回结果可能不稳定，权限边界也可能被越过。 所以这期不是讲怎么把放声 callin 打开，而是讲 to callin 这条链路到底该怎么设计。 我们会从 toolscape 开始讲，工具选择参数、传递结果返回、错误处理、权限控制和审计日制，最后收束成一套能上线前检查的设计 checklist。 先讲最底层也最重要的一层 toolscape， 你 可以把它理解成工具的身份证和使用说明， 他告诉模型这个工具叫什么，能做什么，需要什么参数，最后会返回什么格式。一个完整的 skin mark 通常有四块，第一块是 name， 也就是工具名称，最好让模型一眼就知道他大概干什么。 第二块是 description， 也就是工具描述，这是模型选择工具时最主要的依据。 第三块是 parameters， 要把类型是否必填、格式要求和范围约束写清楚。 第四块是 returns， 也就是调用完成后给模型什么结构的数据。如果这四块写得含糊，后面所有环节都会跟着歪。模型不是读心术，它只能读你写在接口里的东西。 to schema 里最容易被低估的是描述。很多团队会写一句很短的搜索信息，查询数据，发送消息，然后就期待模型自己理解边界， 这其实很危险。好的描述应该至少包含三层，第一，这个工具具体做什么。第二，适合在什么场景使用。第三，不适合在什么场景使用。 比如社区 web。 不要只写搜索工具，而要写它根据关键词搜索互联网上的公开信息， 返回标题、摘要和链接。适合获取最新资讯、公开数据和行业动态，不适合查询内部数据库或私有知识库。你会发现不适用场景特别关键， 因为它是在帮模型排除错误选项。描述越清楚，模型做工具选择时的歧义就越少。 接下来讲工具选择模型怎么知道该用哪个工具？本质上，它是在做一次受限条件下的推理，它会看当前任务目标是什么，有哪些工具可用？ 每个工具的描述说了什么，然后判断哪个工具最能帮它接近目标。举个例子，如果目标是获取半导体行业的市场规模数据后，选工具有 search web query database 和 calculate matrix， 模型会根据描述判断市场规模属于行业公开信息，可能需要搜索互联网，所以 search web 更像首选 数据库也许有历史数据，但不一定有最新数据。计算工具和当前任务就不直接相关。这里的关键是模型需要足够清楚的工具描述才能做出这样的判断。如果描述都很模糊，他就很容易误选 工具选对以后，下一步就是传参数，而这一层特别容易出事。最常见的问题有四类， 第一，类型错误，比如工具要求 integer， 模型却传了 string。 第二，格式错误， 比如日期要求 y y y m e， d d， 模型却给了二零二四年一月一日。第三，必填参数缺失，因为模型以为上下文理已经够了。第四，参数值不合理，比如 max yos， 明明只允许一到十，模型直接传了一百。 解决思路不是让模型更聪明一点，而是把约束写清楚，自断类型、格式、上下界默认值，甚至一个简短视例，都能显著减少歧义。 参数设计的核心原则是最少必要，不要让模型传他不需要的参数，也不要遗漏真正关键的参数。 很多人把精力都放在选工具和传参数上，却忽略了结果返回。同样，关键 工具调用完成以后，如果返回结构不稳定，模型下一步就很难可靠处理。比如这次返回对象，下次返回宿主，这次字段叫 title， 下次又改成 name， 或者一次性塞给模型一千条，结果看起来信息很多，但模型既吃不下，也分不清重点。好的返回结果有两个关键词，第一，结构稳定，要和 schema 的 returns 定义一致。 第二，数据克制，只返回当前决策真正需要的那一层信息。对 to callin 来说，返回不是给人看的报表，而是给模型继续推理的输入，所以越可预测越好。 再往后看，错误处理也不能糊弄工具。世界不是理想世界，它会超时，会限流、会权限不足、会参数校验失败。如果你只返回一句调用失败， 模型根本不知道下一步该怎么办，它不知道应该马上重试，还是等一会，还是换一个工具，还是直接停止？ 更好的做法是结构化错误信息，至少要告诉模型什么错了，为什么错，有没有错误码，以及是否存在 richer after 这样的重置提示。你可以把错误信息理解成模型的决策输入，输入越清楚，失败后的行为就越可控。 如果你要把 to calling 放进真实系统，权限控制就是绕不过去的底线。不是所有 agent 都应该碰所有工具，也不是所有参数都应该让模型自由发挥。 通常至少要有三层控制，第一层是工具白名单，也就是这个 agent 到底能调用哪些工具。 第二层是参数限制，即使某个工具能调，哪些字段能传，目标对象是谁，范围到哪里也要卡住。 第三层是高风险操作审批，比如发邮件、创建任务、写数据库、删除文件，这种动作很多时候就不应该自动放行。你会发现，从 demo 到生产以后， to calling 的 问题不再只是调用对不对？还包括这次调用有没有越权。 除了权限控制，另一个生产级必需品是审计日制。因为当 agent 行为异常时，你第一件要问的不是模型为什么这么想， 而是他什么时候调用了什么工具，传了什么参数，拿到了什么结果。没有这些记录，你几乎没法还原现场。 审计日制至少应该包含调用时间、 a 卷的身份、工具名称、输入参数、执行结果、耗时和错误信息。 它有两个核心用途，一个是调试，帮助你回放调用链路。另一个是合规，尤其涉及外部系统敏感数据或高风险动作时，你必须知道 ai 系统到底做过什么。 当然，日制本身也要注意脱敏、权限控制和保留期限，否则它又会变成新的风险源， 最后做一个收束。如果把前面的内容压成一套 checklist， 主线其实很统一， 名称和描述要清楚，尤其要写清适用和不适用场景。参数要最少，必要把类型、格式、范围和势力交代明白。返回结构要稳定，数据量要克制 错误返回要帮助模型做下一步决策。权限控制要分层，白名单、参数、边界和审批缺一不可。所有调用都要能被追踪和复盘。 你会发现这些看起来像工程细节，但本质上都在做同一件事，让模型以更低歧义、更低风险的方式使用系统能力。真正可用的 two calling 一定同时有两根支柱，一根是能力接口设计，一根是风险治理设计。 只有这两根都在，它才不是一个 demo 功能，而是生产里可靠的一条能力链路。 ok， 这次就聊到这里，欢迎关注阿新聊 ai， 也欢迎在评论区留下你的看法，希望看完关注我哦，有企业咨询、企业 ai 转型定制的需求也要找我哦！

去年十一月， ansorepic 发布了一系列新的测试版功能，只在解决我们在构建 ai 智能体时遇到的一些实际问题。 工具定义在你发送第一条消息之前就已经占用了大量的上下文。当智能体连续执行多个工具调用时，这些工具调用的中间结果会进一步膨胀上下文。 而且随着你在系统中增加工具的数量，智能体在为任务选择合适工具时会变得非常吃力。因此，这些测试版功能帮助解决了这些问题。而且随着两周前 sony 四点六的发布，这些功能已经在云 api 上全面开放。 在他们的原始帖子中，他们展示了这些功能如何帮助实现了八十五百分之的 token 使用量减少。 这也导致一些网友宣称 entropic 已经终结了工具调用，或者至少是传统的工具调用方式。虽然这种说法有些夸张而且确实不准确，但这两个功能编程是工具调用和工具搜索工具 确实是非常巧妙的解决方案，在集成到任何 ai 智能体中时都能发挥极高的效用。而且关键在于这些功能并不是云 api 独有的，也并非最初就是 entropic 的 创意。 这些是智能体构建的核心模式，适用于任何框架或模型。我会解释这两种高级工具调用如何运作，并演示如何集成到你的定制智能体中。 这正是我在这里所做的事情。我已经把它集成进了我的系统，这个系统是我用 python 和 react 定制开发的应用，这是我在本频道过去四期视频中逐步搭建出来的。 我还用全新的困三点五，拥有二百七十亿参数的模型来测试这些高级工具调用方法。所以与其直接跳进理论部分，不如我们在应用里演示一下。 而最简单的切入点大概就是先演示一下工具搜索工具。所以即使只是打个招呼，我们也能收到一个简短的回复。但在底部，你可以看到我们正在追踪本次绘画的上下文窗口。 我们已经用了一万三千个 token， 为了弄清楚发生了什么，如果我们切换到 langfuse， 如果我们看一下这个生成追踪，你会发现已经有六十个不同的工具被加载到上下文中了。 虽然听起来很多，但实际上只有两个 mcp， 就是 playrite mcp 和 github mcp， 再加上一些我在前几期节目中开发的工具。 所以工具搜索工具的关键点在于你不会一开始就加载所有内容。你会延迟加载让代理去搜索他，所以他会多出一个额外的步骤。现在我会把这些 m c p 服务器标记为延迟加载，然后让我重启一下服务器。 如果我再次问同样的问题，比如我们打开一个新的聊天窗口，输入 hello， 然后得到一个回复，你可以看到我们现在只用了六千三百个 tokens。 如果我们看一下这个追踪，你会发现现在只有十二个工具被加载到上下文中。第十二个就是这个工具搜索工具。 这个工具允许代理在工具注册表中搜索，通过名称或关键词来发现并加载工具。为了演示工具搜索的实际效果，我们让他获取这个项目的最新提交。这是一个私有项目，所以他需要使用 m c p。 你 可以看到他现在正在触发工具搜索。他找到了一个工具， 就是 list commits 工具，然后他用仓库的信息触发了这个工具。好了，我们得到了提交 id 以及提交内容的信息。 如果我们查看这次工具搜索的响应，你会发现 listcommits 是 一个延迟加载的 mcp 工具，它会把这个工具的完整模式加载到上下文中。 现在这个工具已经被加载到接下来对话的上下文中了。所以如果我再问任何后续问题，就不需要再去搜索这个工具了。比如说给我最后一个提交，我就可以直接使用 listcommits 工具。 如果我们切换到 langfuse， 在 我发送的第一条消息中，你可以看到只有十二个可用工具。然后在它触发工具注册表搜索后， 在下一次调用中，我们有了十三个工具，包括 list commits， 并且它能够对此作出响应。而在我后续的问题中，我们同样有十三个可用工具。 简而言之，这就是工具搜索实际的工作方式。虽然这已经非常有用，但我认为以编程方式调用工具更加令人印象深刻。如果我们开启一个新的聊天，现在我们在 opodder 上使用的是 cloud hikou， 我 一会会切换到 queen 三点五。但我想先给大家展示一下云端模型和开源模型在这里是如何工作的。为此，我们将使用 anthropic 在 其文章中发布的官方示意。 这里他给出了一个预算合规检查的例子。然后问题是哪些团队成员超出了他们第三季度的差旅预算？ 这里有三个可用工具，分别是获取团队成员，获取支出和按级别获取预算。他在这里展示了传统的方法，也就是需要大量的工具调用和许多中间响应，这会导致上下文窗口被迅速填满， 所以我已经写好了云端代码来生成这个场景的虚拟数据。首先我们来看一下传统的做法，我已经关闭了沙河，现在我来提问哪些团队成员超出了他们第三季度的差旅预算。 正如我之前提到的，我们现在用的是嗨酷模型，所以他正在执行工具搜索，获取报销数据，获取团队成员。现在他正按照这种传统方式操作，需要为每一位成员逐一获取报销信息， 让我们看看会得到什么答案。所以第三季度差旅预算分析显示，有三个人超出了他们的差旅预算，这是他给出的结果。 根据测试数据，这个答案是正确的，但实际上应该有四个人，所以他似乎漏掉了一个。 marcus johnson 超出了预算一千七百， 所以这种传统方法实际上消耗了大量的工具调用。实际上有五十六次工具调用。正如你在这里看到的， 它处理了七万六千个 tokens， 但实际上并没有给出一个准确或者说全面的答案。这正是程序化工具调用能够解决的问题，因为所有这些其实都可以通过脚本自动完成。 因为一旦你知道了团队成员和预算水平，你就可以用一个负循环来获取每个用户的开销，并计算实际的超支情况。 那么现在让我们起用沙盒，并尝试用程序化工具调用来实现。好的沙盒已经开启，让我们重启后端，打开一个新的聊天窗口。好的哪些团队成员超出了他们第三季度的差旅预算？现在正在进行工具搜索。他找到了所需的三个工具。 现在他进入了编程模式，并创建了一个即将被执行的脚本。他抛出了一个错误。这其实并不奇怪，因为他并不知道这些工具的输出结构。所以本质上，如果没有所有信息，他就无法一次性完成。 现在他正在不断迭代自己的代码，实际上是在尝试得到一个结果。你可以看到他不断抛出错误，并且正在逐步解决。 与 anthropomorphic 的 论文相比，这可能是更贴近现实的程序化工具调用方式。因为我相信在 anthropomorphic 的 论文中，它是一次性完成的，而实际上并不会这样。经过多次迭代后，我们得到了一个准确的答案， 所以二千二百， sarah， chen， marcus， alex， emily。 所以 我们得到了所有正确的答案。 这很好，但这才是程序化工具调用的现实。它的方法相当迭代，就像 cloud code 或 open code 一 样。出于兴趣，我们再运行一次，看看能不能得到正确的答案。它会不会走一条不同的路径。我们假设是的， 很有趣。这一次它实际上是在预算层面获取团队成员的信息，所以它实际上是先获取所需的数据，然后再生成代码。所以这次它可能一次性就能完成。 但实际上他并没有做到，他仍然在自我迭代。不过我们确实得到了正确的答案，所以结果是对的，每一次都是如此，只是到达结果的路径不同。所以我们来看看这两条追踪记录。在我刚才运行的那一次中，总共进行了六轮调用， 总共调用了十二次工具，总提示词数为五万八千。现在如果我继续这个对话，目前只用了一万三千，但这是在与大语言模型进行了六轮来回交互的情况下。而之前那一次是在十一轮中用了十一万六千个 prof tokens， 都是为了得到正确的答案， 所以我确实没有看到 anthrax 所报告的八十五百分之的 token 节省。但这其实非常依赖具体的用力。 比如说这里我是在和二十个团队成员一起工作的，如果你有两千个团队成员，那情况就完全不同了，因为大圆模型需要运行两千次单独的调用，这根本行不通， 所以在那种情况下，就需要程序化的工具调用。或者你就需要一个真正的端点，让实际的数据处理在服务器端完成，而你只是获取信息并将其展示给用户。所以这其实切中了这个话题的核心。 也就是说，你的大圆模型到底应该像这样临时进行数据处理，还是应该仅仅从一个预先创建的脚本中传递信息？ 比如说这个脚本可以放在一个技能文件夹里，因为这是我们在上一个视频中搭建的一个完整的技能部分。你可以有一个 python 文件，一旦创建测试并验证后，它就能真正完成这项工作，或者你也可以把它放在工具调用的 m c p 端，这样它就只是简单地传递接收到的信息。 那么我们把 cloud haiku 换成 queen 三点五二十七亿参数，来看看它的实际表现如何。我现在是在网络上运行这个模型，这里用的是欧拉玛，我有一个十万个上下文窗口长度，这里用的是 rtx 五零九零，显卡有三十二 gb 的 显存。 那么我们保存一下，重启服务器，然后问同样的问题，哪些团队成员超出了他们第三季度的差旅预算？现在加载需要一点时间，因为他需要把模型加载到内存中。好了，他已经触发了工具搜索，然后直接开始生成代码。 他实际上在工具调用之间没有输出文本，但你可以看到他正在生成代码本身，而且他正在经历和嗨酷一样的迭代过程，他正在从错误中学习， 并且在不断完善。看看，这就是我们的答案。让我看看二二百十五十七，还有三百，看起来很准确，我觉得这比嗨酷用的 tokens 更少，这很酷，我们来深入看看追踪记录吧。 是的，这次用了四万五千个 tokens 就 得到了准确的回应，这真的很棒，只用了四次工具调用，这已经相当不错了。这是我们 ai builder 系列的第五个视频。在这个系列中，我们正在用云端代码构建一个功能完善的 ai 系统。 本模块的 prd 可以 在我们的公共 github 仓库中获取完整的课程和代码库则在我们的社区中提供 相关链接在下方描述中。那么好吧，这一切到底是如何运作的呢？因为你可以看到我们正在这里的沙箱中触发代码执行，但这实际上意味着什么呢？所以这是一个完全本地化的系统。 我之前用的是嗨酷配合 open router， 但现在用的是 queen 三点五，这里内置了一些文档和 r a g 功能，使用的是 queen 三的嵌入模型。所以你看到的这个代码执行其实是在 docker 中触发了一个沙箱。你可以看到 现在所有这些容器都已经启动了。这里有一些孤立的容器是因为我一直在重启后端。但总体来说，代码执行都是在这里的一个隔离沙箱中进行的。 而这个架构安全性的一个关键部分就是工具桥的概念。所以从头到尾，当用户提出问题时，他会先到 fast api， 然后到 python， 接着再转发到 ai 模型。无论是远程还是本地的， 我们会收到一个工具调用，也就是你需要去执行这段 python 代码，这时后端就会启动一个沙箱容器。 我在上一个视频里已经介绍过这个的设置过程，但本质上我们用的是这个 github 仓库，也就是 llm sandbox。 这是一个非常清亮即可移植的沙箱环境，你可以配合 docker 这样的工具使用。或者如果你不用 docker， 也可以用 portman。 但本质上，这大大简化了启动这些环境的复杂性。 它们支持多种语言，还有许多不同的高级功能。你可以预先启动容器，而不是按需启动。 你也可以使用自定义镜像。这个项目里有很多很棒的功能，所以我会在描述区留下相关链接。我在上一个视频里已经非常详细的讲解过了，所以基本上我们就触发了那个容器的创建， 然后我们会把代码和一个绘画 id 一 起传递进去。所以现在在这个容器里，我们有一个 python 运行器，它会执行那段代码。在我们之前的例子中，有很多不同的工具需要被触发，比如获取预算水平、获取部门、获取团队成员， 而所有这些都可以存在于比如说一个外部系统中，但我们并不希望让沙乡访问外部服务。 相反，我们创建了一个安全的工具桥梁连接回 python 应用程序，然后每当工具或函数在 python 脚本中被触发时，都必须通过这个桥梁。正如你之前看到的，单个脚本中可能会有五十次不同的 api 调用或工具调用， 所以对于每一次工具调用都需要通过这个桥梁，它会使用绘画 id 来进行身份验证， 然后 python 应用程序会将该调用路由到外部系统获取响应后再将其发送回沙乡。因此，除了访问这个 python 应用程序中的 fast api 之外，沙乡没有任何互联网访问权限。从安全角度来看，你可以对这个 fast api 进行严格限制， 这些限制是基于工具本身的精确模式，所以所有这些工具片段、工具定义都是在创建时作为存根发送到沙箱中的。因此，多个工具调用会在 python 代码中，比如说在一个 for 循环内进行， 而且这样做速度非常快，因为此时你完全忽略了 l l m 没有任何中间代码堵塞上下纹。在这里， l l m 完全不参与这个过程，直到 l l m 完成脚本并生成响应。你在之前的演示中已经看到了， 然后这个响应看起来大致是这样的，这就是我们的脚本结果，然后这个结果会被反馈给 l l m。 l l m 接着可以决定下一步该做什么。 如果它已经获得了所有需要的信息，就可以生成综合响应并返回给用户。或者正如你在演示中看到的，它需要对代码本身进行迭代。在很多情况下，它会生成更多的代码，并再次触发沙盒环境。 这就是端到端的流程。我在这里提到了 gviser， 因为 docker 容器并不是你能拥有的最安全的隔离沙盒，因为它们与整个系统共享内核。 所以为了真正保障像 ram， sandbox 这样的安全性，我建议你搭配 gviser 一 起使用。 cloudflair 曾经做过一些有趣的研究，探讨了 ram 在 生成 python 代码或 type script 以及触发工具和 mcp 方面的有效性。他们发现，当工具以 type script api 的 形式呈现，而不是标准的 mcp 时，智能体能够处理更复杂的工具。 我认为这是有道理的，因为他们在训练时接触了大量原生的 python 和 javascript， 所以 在 cloudflared code mode 版本中，也就是我们所做的类似，他们会把 mcp 的 schema 转换成 type script， 因此 l l m 只是生成 type script 代码来触发 m c p。 这和我们正在做的事情非常相似。所以我刚才提到，工具存根被发送到沙盒中。因此，我们在智能体层面定义的 m c p 和工具会被转换成 python 存根 自动生成的 python 函数。这样，当 ai 为沙盒生成代码时，它实际上只是触发 python 函数， 而且因为这是原声 python， 所以 它在这方面会非常擅长。而且重要的是，沙盒永远不会接触到 api 凭证，它永远不会接触到任何机密信息或类似的内容。 我之前提到过需要高效的工具设计，因为在早期，有太多的 mcp 服务器完全塞满了你的上下文窗口，让你根本无法完成任何实际工作。 即使在 anspec 自己的文章中，他们试图解决的挑战也是关于臃肿的 mcp。 在 这里，他们提到 github 的 mcp 有 三十五个工具和两万六千个 tokens。 但即使是在这篇文章发布之后， github 也发布了他们 mcp 的 新版，现在这个数字大约是四千个 tokens。 所以 在 mcp 和工具调用端其实可以做很多工作来确保不会无谓的给你的上下文窗口增加负担。 最后， entropy 在 他们的高级工具调用工具包中还加入了另一个功能，就是关于工具使用视力的这个概念。因为虽然 jason schema 非常擅长定义结构，但它无法表达使用模式。 他们举了一个例子，比如说截止日期，它的数据类型是自复串。日期格式有很多种传递方式， 那么他们到底希望用哪种日期格式呢？除非你真的引导他，否则大圆模型是不会知道的。所以，通过工具使用势力，你可以为每个字段提供一个势力，以便让大圆模型朝着正确的方向前进。比如在这里，日期格式就是年月 日。在他们的测试中，他们发现这能将复杂参数处理的准确率从七十二百分之提升到九十百分之，这很合理，因为本质上这就是多轮提示。你只是给了一个你想要的视力，这绝对会引导模型朝着正确的方向。 实际上，我不确定你是否需要把这个设置成系统中完全独立的功能。我认为，使用技能这个概念意味着你可以在加载技能时提供视力，这样就可以触发你想要实现的任务的执行顺序。 你会发现 cloud 也有点类似，里面有很多功能是重叠的。 antropic 之所以没有取消工具调用，是因为他们认为你应该有策略力对这些功能进行分层。 所以，如果你的上下文因为工具定义工具搜索而变得臃肿，如果你有大量中间结果污染了上下文，那就走沙河路线。或者，如果 ai 总是把错误的值传递给参数，那么使用工具势利就是有意义的。非常感谢你的观看，我们下期再见。

单个 a a i agent 的 上下文窗口是有限资源，任务一复杂，调查 bug， 修代码，跑测试，写 p r。 一个 agent 要么塞满上下文，要么压缩丢细节。更关键的是单 agent 没法并行。 cloud code 给出了三种递进方案，今天逐一拆解所有 agent 派生走同一个入口。 agent two， 它的输入 schema 不是 写死的，而是根据 feature flag 动态组合模型看到的参数列表，精确反映当前能用什么能力。 fork 模式开启时， ram 下划线，硬下划线， background 的 参数会被移除，因为 fork 下所有 agent 自动后台化模型，不需要手动控制。 多 agent 病发时身份隔离靠 node js 的 a single local storage， 每个异步链独立上下文 agent a 的 事件不会串到 agent b。 最基础的派生模式，子 agent 从零开始只看到副 agent 传给他的 prompt， 不知道副 agent 的 对话历史。就像一个刚走进房间的聪明同事，他可以递归派生自己的子 agent， 形成层级结构。 fork 的 核心价值是提示词缓存共享，它完整继承父 agent 的 对话上下文和系统提示词构造字节相同的 api 请求前缀，最大化缓存。命中 代价是禁止地归 fork， 防止无限分裂。检测机制有两层， query source 主检查和消息标签备用检查。即使上下文被压缩，也能识别。 一句话区分三种模式，子 agent 要隔离， fork 要共享，缓存协调者要集中控制。三种模式各有取舍，关键是在上下文共享和执行隔离之间找对平衡。 协调者自己不写代码，只负责理解和分配。四阶段流程， research 让 worker 并行调查 synthesis， 由协调者亲自理解问题，写规格 implementation， 让 worker 按规格改代码 verification， 让 worker 验证。 提示词中最强调的原则是永远不要委托理解，不能写。根据你的发现，这种措辞把理解的责任推给了 worker。 验证 agent 的 设计特别精致，它有两个明确声明的失败模式，一是验证回避，找理由不查，写个 pass 就 过。二是被前百分之八十迷惑，界面漂亮就通过，没注意一半按钮不工作。 它是只读的，不能编辑项目文件，但可以在 t n p 写临时测试脚本输出必须以严格格式结尾。 pass fail 或 partial partial 只用于环境限制，不能用于我不确定。 他还要求至少跑一个对抗性探测，并发请求边界值密等性。前面三种模式都跑在本地 bridge 子系统把 agent 能力延伸到网络之外，从 cloud ai 的 web 界面远程触发本地机器上的 agent 绘画。 三、组建架构， web 界面 and phropic。 服务端，本地 bridge 主循环 bridge 通过轮询获取新绘画，用紫禁城执行 and jason 流逝通信。 最精妙的是全线远程代理紫禁城要写文件，请求经 bridge 转发到服务端，用户在浏览器里点 allow deny 决策，原路返回。 bridge 绘画本质上就是一个没有上下文继承的远程子 agent， 核心的 agent loop 完全不需要改。 bridge 只是在外围包了一层网络传输和认证 cloud code 的 agent 派生光谱，从本地子 agent 到 fork 缓存共享，到协调者集中编排，再到 bridge 跨网络投射，每一层都是在上下文共享和执行隔离之间找不同的平衡点，不存在一个通用方案，也不需要一个通用方案。

好，接下来我们看一下怎么在 spring 阿里巴巴 agent 的 framework 里面往 tool 去传递当前的上下文。 我们来说一个场景啊，比如说我们当前的用户进行了登录，然后通过大模型进行对话和调用了 tool， 那 么在这个 tool 当中呢，我想根据当前登录的用户来获取一些数据，比如说 usid 啊， 或者 username， 怎么获取呢？那听过之前徐老师讲的 siri 系列课程啊，大家应该知道，我是通过 inheritable siri local 来获取的。那我这里整理了一套 java 程序员学习 ai 的 完整学习路线图，加完整学习视频加配套代码笔记加配套的项目实战，从大模型选型到微调，再到 ai 开发 agent 的 框架，最后到项目实战，你像智能客服 reg 知识库， 首都小龙虾垂直 agent 的 workflow 流程开发，最后到部署。为了让大家更好的去面试呢，还整理了一套 java 家 ai 的 高频面试资料，通通无偿分享，需要的小伙伴留下 ai 就 行。但是在阿里巴巴 agent 的 workflow 当中可以做到吗？我们来测试一下。好吧，我先说结论啊， 在错方法当中是可以的，但是在流式请求 stream 是 不可以，来我们看一下。好吧，那么当然有同学啊，他遇到过这样的一个问题，呃，他在这个 react agent 的 病里面啊， 去设置那个啊， serata， 这里面是不能去设置的，因为你要知道这个 add 并的方法它是在什么时候运行的，它是在 spring boot 的 启动的时候运行的，而我们用户请求对话的时候， 请求对话大模型的时候，它又是另外一个县城啊，这肯定是不同的县城，你再怎么通过 siri 的 logo 或者 inheritable siri 肯定都不行，好吧，所以记住啊，不是在这个配置 react 并里面去配置， 我们要在对话的时候啊，再去配置，好不好？那么在这里啊，为了去模拟这个对话，我们用一个单元测试，当然你也可以自己写一个 control 了来去测试，好吧，我们用单元测试更方便一点来，比如说我在当前的 这个 tool 里面，好吧，我们存储当前的这个啊 user id， 好 吧，然后呢，我在这个 tool 里面啊，我就直接打印一下， 好吧，在实际的这个应用当中呢，我们肯定会根据当前的 user id 来获取对应的一些数据。完了之后呢，我们在这个用户对话的时候，我们进行缓存，我忘记把那个访问权限啊，给它改成 public static 来， 再回到刚刚的代码，我们去设置，比如我设置一个当前的登录人，假设是虚入，好吧， 那我们在这里呢，通过调用或方法，也就是同步的方式去请求我们来看一下能不能正常地获取到呃，这个 to 里面的 setlocal 的 值，好吧，那么这里的这个注意啊，这里的这个 react agent 我是 在上面 配置的一个并，对吧？所以我在这个单元测试里面呢，直接自动注入进来，呃所，呃，那么在上面呢，我已经 绑定了这个 tool， 好 吧，我只需要去请求一个查询天气，那么它就会去调用这个 tool 了。 ok， 那 么我们这里代代码去请求的也是查询，比如说北京的天气，对吧，它就会去调用对应的那个 tool， 我 们来看一下能不能正常获取到啊？来， 你看这里呢，就正常地输出了，说明呢，我们通过 tool 方法用 third 对吧？ serverlocal 肯定是没有问题的，那么你用 incorridable serverlocal 肯定也是没有问题的。好吧，这个我就不去测了，但是如果我们换成 stream， 好 吧，我们换成 stream 的 话，这里你想一下它能获取到吗？我们之前测试 spring ai 当中，它是可以正常的。我们来看一下阿里巴巴 agent framework， 它能不能正常地获取到答案呢？获取不到， 好吧，因为我刚刚已经说了嘛，好吧，这种方式，无论你是 seruo 还是 incurable， 也就是这种子父现成的都不可以，你看这里获取不到，对吧？它输出为 non。 所以 我们完全可以得出一个结论， 在阿里巴巴 a 证的宏观里面，通过扩方法，它去执行大模型，然后再去调用，整个过程呢，它都是用的同一个现成，对不对？ 那么我们用 stream， 很 明显，它在调用大模型和 for 的 过程当中呢，明显就不是同一个县城了，那么用这种方式呢，就 获取不到，它就丢失了。所以在这里呢，我建议大家，我们可以采用阿里巴巴 agent 的 from mark 单独提供的这个 runnable config 来进行传递。 来，我给大家演示一下。那么之前呢，我们通过这个 runnable 统 fig 给大家演示了不同的聊天记录， 进行隔离，这样的一个效果对不对？我们用的是什么？用的是 siri 的 id， 对 吧？比如说我在这个 siri 的 id 当中呢，去设置一个唯一的标识，我们通过这个就可以去隔离不同，你可以作为将用户 id 作为不同的一个呃分离的维度，也可以将比如说绘画的 id， 不 同的绘画窗口作为不同的唯一标识去隔离聊天记录，聊天记录， 好吧，然后我们在啊对话的时候啊，在对话的时候就需要把这个 group 给它传过去，这是第一步 传递 runnable 宏 big， 然后第二步我们需要在这个 word 当中把这个 function 接口啊给它改成 b i function。 为什么要改成 b i function 呢？因为 b i function 啊，它多了一个环形，我们就可以在这里呢 去接收一个叫做 tool context， 也就是工具的上下文，然后你就可以在下面的这个作方法，我们接收这个 tool context， 好 吧，也就是这个 b i 方式啊，它有三个范型，一个用来规定我们的 呃接收的数据的参数，第二个就是指定 to o config， 然后第三个参数指定这个方法的返回值， ok， 那 么通过这个 to o context， 那 么我们就可以呢 get context， 然后呢 去获取一个叫做这个 agent 的 config， 这个常量好不好，那么我们就可以呢给它转换成 runable config， 那 么进而呢， 我们就可以从这个 runnable config 里面去获取到那个 thread id， 好 吧，那么这里的这个 threadlocal 我 们就可以去掉了，因为这种方式它不起作用嘛。好吧，我注视一下这种方式，它在呃 string 方式里面呢不起作用， 当然我不知道它是故意为之，还是说啊，这是一个以后会改进的地方，我们这个就不往下面去深究了，只需要知道现在的版本呢，它这种方式不起作用， 我们可以通过这个 to contest 来进行完毕，好吧， ok， 来，我们再去请求一下看一下啊，刚刚那个代码，我需要把这个 server log 赋值给它去掉，好吧， 好，我们再运行看一下，所以记住这几步，第一步我们去申明一个 runnable config， 然后在呃调用 agent 的 时候呢，把它传进去，然后就可以在这个 tool 当中 通过我们的 tool context 来去获取。 ok， 我 们来看一下结果。哎，这里报错了 哦，我们这里获取的这个场量不对啊，好吧，我刚刚应该是是这个 config 的 场量，好吧，是这个 config 的 场量刚刚弄错了。来，我们再重新运行一下，来， 我们可以看到在这里呢，它就输出了一个 optional 类型的，里面就有虚数了，对不对？那么这样呢，我们就可以进行 tool 的 一个上下文的传递 啊，当然算到这里啊，其实我们还可以进行一个改进，假如说啊，现在我们隔离聊天记录用的不是用户的 id， 比如我们用的是， 对吧？绘画的 id， session 的 id， 我 随便说一个，好吧，我们假设就是这个就是 session id， 那 这个 sir 的 id 它被占用了， 那我怎么传递用户 id 呢？对吧？毕竟这个 server 的 id 它只能传一个，我不可能给它拼接上去吧，对吧，这也太蠢了。实际上它还提供了一个叫做啊 meta data， 好 吧，我们可以通过 add meta data 呢，来单独的去添加需要传递的这样的一个原数据，好吧，在这里你就可以呃去维护任意的 t y 里的一个数据了，好吧，比如说 use id， 那 么对应的，当然在那个 tool 当中，你也是需要 通过那个 meta data 来去获取，好吧？ user id， ok， 好 吧，所以，呃，正常的方式呢，我们应该是通过 meta data 来进行传递会更加的合理，因为你也不知道不确定 这个用来隔离聊天记录的它会设置什么，对吧？ ok， 那 这就是我们怎么通过这个 tool context 来传递 上下文。当然除了去设置一些原数据用户 id 以外，其实这个 tool context 里面啊，它还可以去获取我们 当前的这个聊天记录，比如说你从里面啊去获取这个 state， 好 吧，这个 state 呢，它属于阿里巴巴 graph 当中的一个概念， 里面它其实就存储了我们当前的一个啊聊天记录，你就可以在这个里面呢来进行获取。 ok， 我 这个笔记里面呢也都有，我就 不给大家啊去演示这个了，我直接把这个呢拿出来，好吧，我们可以调试，给您调试看一下里面的数据是什么样的。 好，来，你看这个 state 里面啊，它里面就包含了，你看包含了我们用户的提示词，对吧？还包含了大模型的响应提示词 啊，当然这里的大模型呢，是 cool cos， 也就是代表呢，它需要请求的是啊，错，然后里面就包含请求的错的名字，然后呢里面的参数北京，对吧？ 所以如果你还想在 to 当中去获取一些例子的聊天记录，那可以通过这个常量，好吧，这个带了 state 的 这个常量呢来进行获取， ok， 好， 那这个关于工具的上下文传递，我就给大家讲到这里。

你有没有被 a 诊的误删过文件，或者透露过自己的一些个人隐私信息，怎么防范呢？我们来学习一种叫做人机协调或者叫做人工介入的方式， 它可以针对一些高风险的错，比如我们刚说的删除文件或者修改数据库，或者要用支付接口啊等等。 凡是这种具有不可逆性或者破坏性或者合规风险的，沃尔就可以让 ai 在 调用之前让人工呢再去确认一遍是否可以操作。所以这种机制呢，它是针对沃尔来进行精准拦截， 而你不需要介入的 to 呢？它依然是可以正常执行的，只有那些高风险的 to， 你 通过配置才会进行人工干预，比如我们人工同意或者拒绝 agent 才会执行后续的流程。那我们来通过 spring 阿里巴巴 agent 文档，以删除文件为例，看一下这个人工介入的机制是怎么实现的。首先它是通过后壳机制， 也就是它提供了一个内置的人工介入的 hulk， hulk 呢，我们之前也介绍过，它是专门用来拦截或者干预 agent 在 执行过程当中的一种方式。那么在这个人工介入的 hulk 当中，我们就可以进行配置，你需要 拦截的是哪一个工具进行人工介入，那么我们在下面就提供了一个叫做 delete file， 也就是删除文件的工具。 那么这里指定的这个名字就是我们看见这个 tool 的 时候指定的这个名字，好吧，不是这个类名啊，这里你要搞清楚。然后呢，你也可以给他提供一些 当触发了人工介入需要提供的描述，懂吧？所以我们要实现人工介入这个 human in the loop hope， 它是最关键的第一个点。那么第二个点呢，我们需要提供记忆的实现，因为在整个执行过程当中，如果出现了错误的拦截，需要人工介入， 你需要把之前的整个执行过程，它的聊天记录肯定都要存下来， 要不然你再进行后续的执行，前面的聊天记录都忘了，那肯定是不行的。所以在这里呢，我就提供了当然最简单的记忆实现，我们之前呢也讲过 radis 来存储记忆，你也可以改成 radis 的 记忆实现，好吧， 所以这是它的第二个关键点，第三个关键点，通过 react agent 去直定我们刚刚声明的这个 human in the loop hook， 那 么另外你这里进行人工干预的这个 to 肯定也要配置进去，好吧，所以我们这里除了一个删除文件的 to， 还有一个 查询文件列表的 to 来我们运行看一下这个结果。那么在这里呢，我会通过 spring ai 阿里巴巴生态下的 studio， 也就是这个聊天 ui 界面来进行演示，毕竟这个视力当中呢，它需要我们人工的进行审批，是同意还是拒绝， 这里涉及到一些 ui 的 交互，如果我们要自己去实现的话比较麻烦，毕竟它的生态当中呢，都已经实现了，我们直接就用它的这个现成的轮子来去演示。那么现在比如说我让他给我删除文件， 我随意地去指定一个，比如说第一盘 temp 下的询数这个文件，那么此时你就可以看到它就会去调用我们的 delete field tool， 并且把这个要删除的文件作为参数传进去了， 所以在这里就触发了人工介入，这里呢有三个选项，第一个是同意拒绝，还有修改同意跟拒绝呢，就很好理解，对吧？同意肯定就会直接去调用这个 tool 执行删除， 那么拒绝呢，肯定就直接就会中断我们当前的呃执行，就不会去调用这个工具了。那么另外呢，还有一个修改，这里就可以去修改 调用这个库涉及到的参数。比如我不让他删除徐树，我让他删除徐树六六六这个文件，那么在这里就可以保存，然后再提交，此时呢你就会发现他删除的就是徐树六六六这个文件，你看到没有？ 那么我这里呢，这个学术六六六的文件就没有了，之前是有的，那我们再来说一下它又是怎么运作的呢？其实核心机制是借助我们之前讲的这个 hock， hock 它主要的特性就是可以去中断或者停止干预我们 agent 执行过程，只借助 hocks 的 话还不够， 这里涉及到了一个叫做 interruptible action 这样的一个机制，它其实就是一个接口，我们可以稍微看一下源码，它这里啊实现了一个叫做 interruptible action 的 这样的一个接口， 那么这个接口呢，它提供了一个方法叫做 interrupt， 这个方法如果你直接返回的是一个空值， 那么就代表呢我不会中断。如果你返回的是一个 interuptation meta data， 那 么它就会触发中断。所以在这里呢，它主要就是借助的这个 interruptable action， 在 agent 执行过程当中呢，它的底层就会自动判断你的 code 有 没有实现这个接口，如果实现了， 它就会去调用 interrupt 的 方法，看你是否需要中断，好吧，如果需要中断呢，它就会去翻译一个 interruption meta data 的 数据返回给前端，那么前端接收到你这个数据呢，就会构建出一个人工反馈的界面出来， 进而呢再提交给 agent。 那 么这一块的源码我们也可以稍微看一下，也就是这个 interrupt data 它是怎么返回给前端的，这里呢会涉及到我们需要通过这个阿里巴巴 studio 这一块的源码来进行观看，也就是我们在这里点击这个发送按钮， 它实际上就会去调用阿里巴巴 studio 这个 execution 控制器里面的这个 run sse 接口，然后呢就会接收到用户发送的消息，然后去执行这个 execute agent， 那 么在里面呢进行流式的请求，然后进行响应式的判断当前的消息类型， 那么其中呢，就有一个判断分支，判断当前是不是 interuptation metadata， 如果是的话，那么就把当前的 这个所需要的数据构建成一个 dto 传递给前端，那么前端一旦通过 或者拒绝，然后点击这个 sub meet 按钮，就会去调用另外一个接口，也就是这个 read consumer s s e 接口，从而呢就会拿到前端返回的这个结果，封装在了这个 result 的 结果里面，然后呢就会再一次地去执行 agent 的 stream 流逝响应的方法，继续 执行下面的操作。那由于我们的记忆是通过当前的这个对话 siri 的 id， 也就是我们每一次对话呢，都会有一个 siri 的 id 作为当前对话窗口的记忆存储，所以当我们再一次去提交用户接入的反馈， 他是知道我们之前对应的聊天记录的，然后呢，就可以继续执行后面的操作了。那我这里整理了一套 java 程序员学习 ai 的 完整学习路线图，加完整学习视频加配套代码笔记加 配套的项目实战，从大模型选型到微调，再到 ai 开发 agent 的 框架，最后到项目实战，你像智能客服 reg 知识库，手撸小龙虾，垂直 agent 的 workflow 流程开发，最后到部署。为了让大家更好地去面试呢，还整理了一套 java 加 ai 的 高频面试资料，通通无偿分享，需要的小伙伴留下 ai 就 行， nice！

hello， 大家好，这里是永泽，今天我们来讲 ai 应用工程师学习路线的第三阶段，动起来的 agent。 上一阶段我们为大家讲了一二阶段，也就是 ai 应用基础以及 ai 扫描。那么今天来讲动起来 agent 核心突破点，让 agent 不 仅仅只能对话。在之前我们使用一些比较耳熟能详的大模型，例如 excel， gpt 等等，在二二年的时候啊，我们还是只能跟它对话，它不能帮助我们完成一些简单的一些 coding 等等。或者说在我们使用 deepsafe 的 时候，我们想让它生成一个 word 文档， 他只能给出我们 word 文档的内容，而不能在本地直接生成。但是现在我们在使用呃 cloud code 等等的时候，他可以直接帮我完成编码，或者说呃直接在本地生成一些基础方案文档。那么这个能力是怎么完成的呢？这是我们今天要学习的内容， 我们要学什么？第一个就是拓系统，你要理解拓就是 api 抽象拓就是调用互断接口能力。简单来说， cloud code 它实现呃编码或者实现生成文档的能力，都是它调用一个个拓，调用一个个它所拥有的工具来完成它想要的一些效果。 第二个就 m c p。 相信 m c p 是 一个大热词，大家在面试的时候常被问到，我面试的时候也被问到过 m c p， fashion， calling 以及 skills 的 区别。在我的理解中， m c p 就是 一个通用层的一个协议 大模型，可以拥有很多的拓尔，但是这些拓尔来自很多地方，我们引入一个不同的拓尔，就要引入它不同的 s、 d k， 就 像我们平常进行代码编写时，时候我们需要引入编码的各种依赖，那么 m c p 呢？让大模型接入 s d k 接入拓尔能力 啊，实现了这么一个统一，我们只用关注在 m c b 层实现了这么一个协议，而不用关注具体 s d k 的 接入。这这个统一让我们接入大拇指兔耳这么一个呃能力，让我们接入兔耳更加的方便， 那本质呢，就是安一阵能接外部世界有一些能力，比如说查天气，调教育系统，调音乐，声声服务等等。第三个就是 skill， 相信大家如果在一些中大上实习的话， skill 也绝对是你公司的热词，每个小组都有一定的 a 呃， kpi 要求你去产出不同呃各种各样关于你业务 skill， 那 么 skill 呢？给大家说，这里有一个解释，这些 a 制呢？还是只能对话，我们想让它自动干一些东西怎么办呢？需要安装上手和脚，通过 mcd 协议能实现 api 调用， 但是随入随着传入 a 阵子， m c p 工具描述协议越来越多， i a m 处理巨量输入上下文是有困难的，所以 skill 诞生了。 skill 本身就是为了解决 m c p 上下文爆炸的思想，叫做间接式加载，把每个 m c p 的 详细协议细节都给省略描述工具名称和作用。 本来说 skill 就是 秃人目录导引加载，解决问题呢就是上下文爆炸和 toc 目录报告，本质思想就是不要把所有 api 丢给 i m 之类的目录。 那么在我的理解中， skill 就 像是我们完成一件事情需要一个 s o p， 比如说我们在新进入一个大厂有个来定期呃，大厂托运给我们一个 s o p 文档，让我们进行这么一个相应的学习，这就是我认知中的一个 skill。 阶段三的一个 demo 啊。作业一，就是自动生成音乐这么 a 帧的啊，这有详细的这么一个流程，我们有不同的 tour 热门抓取了，包括音乐特征分析，对吧？ i m 不 断地去调用 tour， 不 断有它有那么个 rack 循环嘛， 然后在项目里头可以探呃，加入一些元素，失败重试啊，超时控制等等，这还是后端的一些基本素养。作业二，基于阶段一，我们阶段一已经通过 rock 实现了一个支支付问答的一个 a 帧等， 那么我们在这个 a 阵的技术可以加入三个拓，也就是三个可以调用 api， 百度搜索，天气日历等等。嗯，这就是本阶段的一个简单一个内容啊。后续呢，我们把所有的学习路线介绍完，我们也会把这个 demo 的 编辑 呃与讲解提上日常吧，我们也会把这个路线中涉及到一个 demo， 我 们自己动手实现，来给大家完成这么一个讲解。那么阶段四，也就是最近比较火的 highness engineer 啊，我们后续也会也会再出，这就是今天的所有内容，谢谢大家。

哈喽，大家好，你是否听说过多 agent 的 架构啊，甚至在面试的时候可能也会遇到这个问题啊？面试官问我们是否有做过多 agent 的 架构，如果我们没有做过啊，可能会有点心虚，甚至会支支吾吾的不敢说啊，但听完这期之后啊，你就可以理直气壮的跟面试官说了，不是做不了多 agent 的 架构啊，而是单 agent 更有性价比。 欢迎大家来到 agent 第二十八期啊，也是我们拓展篇的第一期，下面让我们正式开始吧。我们首先来看一下这个多 agent 架构到底是什么？那简单来说呢，多 agent 架构啊，就有点类似于像一个团队，那怎么理解呢？它是多个单独的 agent 进行分工协助的，然后是一起完成一个整体的任务的，那 它运行的一个本质是什么呢？运行的本质就是我们把复杂的任务给拆解掉，那拆解成一些简单的任务，那让各个 agent 各司其职来做就行了，这个定义特别的好理解，那就有点像是市场的分工一样的，对 专业的人，专业的 agent 做专业的事情就可以了。但是呢，这里确实有一个真实的真相啊，就是说市场上大多数所谓的这种 agent， 其实本质上是什么呢？本质上是异步风流加上工作流。如果你前面有跟进我们相关的课程啊，那么对这两个东西应该不陌生啊，简单来说就是我们识别用户的问题是什么？ 然后呢，再执行对应的固定的工作流程，那这个呢，就是市场上大多数的一个 agent 的 一个真实的底色了。 而右边这个部分呢，就是对于我们的 do agent 架构啊，一个任务的拆解，当我们一个复杂的任务输入进来的时候，这个时候怎么办呢？那我们首先肯定是进行意图的分流和相关的拆解，来识别一下这个问题到底是一个怎样的问题。然后呢，识别完了之后，不同 agent 去做不同的事情，最终呢把这个结果进行整合，整合之后相关的输出就行了。 那么既然我们已经知道了 do agent 架构是什么样子的了，那么市场上有哪些对应的类型呢？我们可以一起来看一下。那么第一种类型啊，也是最常见的类型，其实就是对应的组成式的， 那他怎么理解呢？其实本质上就是一个主要的 agent 负责什么呢？负责意图的识别，了解用户的问题，然后去拆解用户的问题，拆解了之后他去调度对应的各个 agent 进行相关执 行，完成对应的子任务。其实就是我们前面的主要的这个结构了，我们可以举一个简单的例子啊，就是淘宝客服这个例子我们举过很多次了，经常会拿淘宝客服来举例啊，用户说我要退货，而且呢你给我推荐一个新的商品，当然了，很多时候用户不会这么去表达， 它不会同时有两个意图。那我们假设用户这么说了，那这个时候怎么办呢？我们会去用一个 agent 来负责拆解用户的问题，那我们拆解出来是有什么呢？我们拆解出来是用户有退货和推荐这两个不同的意图，那这两个不同的意图呢？会下发给两个不同的 agent 进行相关的处理，退货的 agent 自然处理退货，推荐的呢，则处理对应的推， 那这是最典型的，也是最常见的一个 agent 的 架构是组成式的，那么第二种架构则是流水线式的，那这个怎么理解呢？流水线式啊，它有点像是对应的工作流，它是多个对应的 agent， 它们彼此啊，各自都会有一定的自主理解和规划的能力，那按照顺序来进行执行任务，上一个 agent 输出完了之后，然后给下一个 agent， 那么下一个 agent 呢？再进一步的去处理这个任务，如此的去反复循环，直到最终输出对应的一个结果，那它会有一个怎样的例子呢？那比如说啊，很典型的就在于对应的内容生产啊，内容生产的话，可能从刚开始一个 agent 去对应的定义这个相关的题目，也就是选择题，那下一个 agent 呢？进行相关的 写作，然后呢进行叫对，然后排版，然后再进行输出最终的一个结果，那不同的 agent 在 这个链路上面，他们执行着不同的任务，而 都是在同一条线上的。那么还有一种架构是什么呢？就是这种偏联邦式的，就是多个 agent， 它们的地位是相对平等的。那这种联邦式的多 agent 的 架构更多的应用在哪里呢？其实更多的应用在一些需要去投票的环节啊，就比如说像商业的决策，头脑风暴啊，还有一些比如说在标注评测上面，可能我们让大模型来去给大模型进行评测， 那在评测的过程中呢，可能要多个模型进行投票来去打分，看一下这个对应的结果是不是 ok 的。 如果多个模型都识别是 ok 的， 那我们这一条就认为没有问题，所以的话这是一种偏联邦式的对应的 a 型的架构。 那我们既然已经理解了多 a 型的架构有哪些了，那我们什么时候会用到这些对应的架构呢？那简单来说啊，就是我们必须要用到多 a 型架构的，其实它的场景非常的有限啊， 往往集中在一些任务非常的复杂，必须要多个角色进行相关的写作的场景之下啊，比如说我们前面提到的相关的专业的评测，或者说是写行业的报告，那或者说是比如说在一个复杂的客服的场景之下，这些可能是需要的，因为他的任务是比较难的，无法以单一的一个 a g 城来进行独立完成的。那 什么时候是不需要的呢？自然是在前面这个的反面，如果说我们是单一的任务，比如说只是去查个物流或写个周报之类的，那是不需要的。还有一些高风险的场景，这种高风险的场景怎么理解呢？就比如说涉及到资金啊，合规安全的操作啊等等，这些的话，我们甚至连 agent 都不用，更不可能用多 agent。 那 还有一些可能，比如说在成本比较敏感的一些场景，因为多一个 agent， 自然它就会多一个模型的输入和输出，它就会多一份对应的成本，所以的话，那在一些成本比较敏感的场景，我们往往是不会去用的。 我们既然知道了在很多的场景之下，其实不会用多 agent 的， 那这种场景第一呢是不需要，第二呢其实是多 agent。 还有一些我们没有想象到的风险，那比如说是哪些呢？比如说多 agent 架构啊，它的成本会比较高，那 这个我们前面已经说了，多一个 agent 自然就会多一个成本。第二的话则是它的稳定性会比较差，一个 agent 出错的时候，这个时候它整个任务会产生一些相关的影响，你去定位问题往往会比较麻烦和困难。 那第三个呢，则是你的调试会比较的复杂，因为你去调试的时候去，比如说我到底判断能不能上线啊？你多进程意味着要每一个环节都要去做对应的评测的，那这个投入的神力和效率往往来说就不太可控了。 所以他既然有了这么多的问题，那我们在很多场景之下当然是不用的。如果我们能够用工作流解决的，则优先用工作流，我们甚至连进程都不用了。如果我们能用单独的一个进程来解决问题的，往往不用多 engine 的 架构啊。 do engine 它确实是一个比较美好的一个未来的方向，但是目前确实是不太成熟，它比较适合一些低风险场景，高复杂度的一些场景，以及是对于成本容忍度比较高的场景去做探索的，往往是不能直接的用于企业内部的这种生产环境的。 既然了解了这些啊，我们自然可以回应面试官最初问的那个问题啊，你在项目中啊，到底用过多 a 型架构吗？像以前的时候，我们可能还会畏畏缩缩，可能还会吱吱呜呜不敢回答，那我们现在就可以理直气壮的说了，假如说我们确实做过，那我们当然说啊，比如说我们在什么场景下做过，就比如说我在行业报告的场景之下，那面对的问题非常的复杂，这个时候呢需要多个 a 型者来进行同步去写作， 但是呢，如果我们没有做过，其实也可以去回答他了，我们就可以直接的说啊，我确实有尝试过这种多 h 的 架构啊，最后验证了之后发现它的成本很高，稳定性也不足，但 h 就 够了，所以呢，我就没有去让它进行上线，所以的话，在这种场景之下，面试官往往也是能够理解的。 那么好，讲到这，我们就已经把多 h 的 架构已经基本上全部讲完了，那你还有哪些相关的疑问呢？欢迎在评论区进行相关的留言分享啊，以及我们在接下来也会分享更多的 h 拓展相关的内容，期待你的关注，我们下一期见。

最近很多 ai 一 群项目开始从 mcp 转向 coi 工具了，比如说小龙虾的项目，比如说 publicity， 最近发博课说他们准备全面抛弃 mcp 转向 coi 了。 今天就跟大家聊一下为什么 ai agent 的 项目越来越喜欢 c r i 了。首先第一个问题就是 m c p， 它有严重的上下文污染问题，因为 m c p 的 工具调用方式是 agent 一 启动就需要把所有的工具全部加载进上下文中。 如果你有十个 m c p server， 一 百个工具，这些工具描述会在一开始就全部加载进模型的上下文里面去，这会导致大模型在做脱扣的时候，上下文变得非常长。 而 c l i 的 模式就完全不一样，它支持工具的渐进式的批录。 agent 可以 通过 c l i 的 命令一步一步探索，比如可以通过刚刚 help 的 命令去查看到底支持什么工具， 还可以通过指令率去查看工具支持什么样的参数，这些工具信息是逐步加载的， 而不是一开始就塞进模型的上下文里面。第二就是 c o r 工具天然对大模型比较友好，因为整个 linux 和开元社区 有大量的 c i 命令和使用文档，所以大模型其实早就驯服了这些数据。而 m c p 的 调用方式是大量的 jason scammer， 这对大模型来说会更加复杂，而且还要输出很多跟 jason 格式相关的格式化的头肯。 第三点就是 coi 工具，它可以支持一些 type 操作。很多 mcp 的 工具返回结果的时候呢，其实你是需要一些后处理的，比如说一些过滤的操作， 还有就是搜索截取关键的片段。以前 mcp 想要支持这种后处理操作的时候，你是需要额外的工程代码去处理的。 但如果是 coi 的 话，你可以直接用，可以用 pipe 操作， agent 只需要输出几个 linux 命令，然后通过 pipe 操作连接在一起，通过 gui， file， find 等 linux 命令 就可以完成对工具结果的后处理，这对工程来说更简单更灵活，维护的成本也会更低。 最后就是 coi 其实非常适合和 skill 进行搭配，你可以在 skill 点 md 里面去教 ai a 人怎么样用你的 coi 命令， 在不同的场景下应该用怎么样子的 coi。 如果你用 mcp 的 话呢，就会在 skill 点 md 里面出现大量的方寸扣啊，这声 scammer 等等，会使得你的整个 skill 点 md 非常混乱。 所以总结来说， c l i 在 模型上下文以及工具结果后处理的角度呢，它都有非常巨大的优势，这。

很多人一听到工具必要用，就会想到一整套框架工具定义模式，注册、绑定执行器运行时， factor 四，想把这件事拆干净。工具不是魔法，框架工具就是大语言模型输出的一段结构化数据，然后触发你自己的确定性代码。比如用户说三乘四 模型真正需要输出的不是一次函数调用，而是一个数据对象，意图是乘法，参数 a 是 三，参数 b 是 四。接下来戴默尔看到这个意图，走分支路，由执行乘法得到十二，再把结果写回对话线成。 所以关键分工是模型决定做什么，代码控制怎么做。工具的定义也很朴素，每个工具都有一个显示的意图，指段参数就是数据类里的指段，再用联合类型限定可用工具级。比如加减、乘除模型只能从这些结构里选，不能临时发明新动作。 完整念入就是现成，进入提示词，提示词给出可选结构化数据代码，根据告一分支制行结果，再追加回现成。 fico 四最重要的读查是一次工具调用，不等于一次原子接口调用。同一个意图在代码里，可以是一行加法，也可以是一整套部署工作流叫验参数，锁定环境，触发流水线，通知团队启动接口检查模型，只看到做什么，真正的怎么做留在你的代码里。 还有些意图不是传统工具，而是控制流信号，比如先暂停表示等外部出发补充信息表示，等待批改。 他们告诉智能体循环先天下来，并继续自嗨测试。也因此很简单，给定一个现成断言模型输出的是乘法，一读参数 b 是 四人类纠中以后再断言他理解了新的参数， 所以这一集的记忆解释工具就是模型的结构化输出，触发你可通的圈利息代码，把工具看成数据而不是框架魔法，你会更容易测试，更容易审计，也更容易把复杂工作率放回自己可控的工程系统里。

给 agent 配了一百个工具，结果他调用准确率从百分之九十五调到百分之五十。不是模型变差了，是工具太多，把 l l m 的 注意力稀释了。工具数量翻二十倍，成本翻二十倍，准确率腰斩。 这讲讲凸尔盖用 r a g 的 思路管工具，每次推理前只绞索最相关的几个，让 agent 在 工具堆里也能精准出手。 问题是怎么来的，得从一个具体的场景说起，把 ai agent 想象成一个超级能干的私人助理。工具箱里只有五件工具，锤子、螺丝刀、扳手、剪刀、卷尺。 你说帮我修个柜子，他扫一眼就知道拿哪几样干净利落。但现在工具箱里塞了两百件，他得从头翻到尾，越翻越乱。光是找工具这件事，就花掉了大半时间，还可能拿错。早期的 agent 工具少，把所有工具的说明书一股脑给 ai 看没问题， 但企业应用越来越复杂，工具数量膨胀到几十上百个。这个方案从速度、准确率、费用三个维度同时崩掉了。 背后其实是 ai 的 脑容量问题，把它想象成桌面，桌面上能摆放的东西就那么多，满了就没地方放新东西了。 ai 的 上下文窗口就是这块桌面，一次能记住的内容总量是固定的， 一百个工具的说明书大约要占掉两万到五万字的空间。本来这些空间是用来记对话内容、任务细节的，全被工具说明书霸占了。 更糟的是 ai 的 注意力机制，就像读文章时，眼睛会重点扫描关键词。工具越多，每个工具分到的关注度越少，功能相似的工具之间的细微差别就容易被忽略，就像让人从两百张长得很像的脸里认出某一张，比从五张里认出要难的多。 解决思路其实来自一个很朴素的生活智慧。图书馆不会把所有书摆在你桌上，而是让你先去剪辑，再按需取书。这套方案叫做 tool rack 工具剪辑增强生成 核心转变就一句话，不把所有工具说明书全塞给 ai， 而是任务来了，先解锁出最相关的几个工具，只把这几个的说明书交给 ai， 其余的全部暂时收起来。桌面清爽了， ai 才能专心干活。这个思路说起来简单，但真正做起来有几个关键步骤，我们一个一个来拆。 第一步，给每个工具做一张坐标身份证。每个工具都有一段文字描述，叫什么名字，能做什么，需要哪些参数，系统会把这段描述转换成一串数字坐标，也就是向量。向量就是用几个数字来描述一件事物的特征， 就像用身高、体重、年龄来描述一个人。这几个数字放在一起，就能在坐标系里给这个人定一个位置。工具也一样， 功能相近的工具坐标也会靠得更近。发邮件的工具和发短信的工具坐标位置挨在一起，查数据库的工具和发邮件的工具距离就远得多。这张坐标地图就是后续解锁的基础。 有了坐标地图，任务来了就好办了。当 ai 收到一个任务，比如帮我查一下数据库里的销售数据，系统同样把这句话转换成坐标，然后在工具地图上找距离最近的几个工具，也就是语义上最相关的工具。 这里不是靠关键词匹配，而是靠语义理解。就算用户说的话里没有出现数据库这个词，只要意思相近，坐标距离就近，照样能找到。只把这几个工具的说明书交给 ai， 其余的全部暂时收起来。这个动作本身非常聪明，他把一个选择题从两百选一变成了五选一，难度不是一个量级。 这个细节很多人忽略。 ai 完成任务往往需要好几步，第一步查完数据库发现数据有问题，下一步需要发邮件通知同事。这时候，需要的工具完全变了，如果一开始解锁的工具一用到底，第二步就会抓瞎。 所以 toreg 的 做法是，每轮 ai 推理之前都重新解剖一遍，根据当前最新的进展，判断现在需要什么工具，再动态注入进来。就像做饭时，切菜阶段递菜刀，炒菜阶段换锅铲，而不是一开始把所有厨具全堆在灶台上。 这个动态更新的设计，才是让多部复杂任务真正跑通的关键。再往深一层， toreg 还引入了分组管理 工具，按业务类别分组，比如文件操作组、数据库组、发邮件组。绞索时先确定大方向去哪个组，再在组内细找。这就像图书馆，先按文学、科学、历史分区，再在区内找具体书目，比在整个管理忙找快的多，找到的也更准。 数据说话不分组，直接检测，召回率是百分之八十二，分组之后，召回率提升到百分之九十一，响应时间反而更短。这个结果之所以重要，是因为它证明了一件事，结构化的鲜艳知识，能让语义检测变得更聪明，而不是互相冲突。 那怎么知道剪辑做的好不好？ two rag 引入了一个叫 recall act 衡量标准，拆开来理解，剪辑出前 k 个结果，真正需要的工具被找到的比例就是召回率。可以把它理解成考试分数，告诉你答得有多准。 有了这把尺子，工程师才能知道哪里出了问题，该怎么改进工具描述或剪辑策略，而不是靠感觉猜。 这个细节很值得说。很多 ai 系统的问题，不是技术做不到，而是根本没有合适的指标去衡量结果，优化，无从下手。有了 ricochet， 整个改进过程才变得可以被量化，可以被追踪 数据说话比什么都有力。把一百个工具全部塞给 ai， 响应时间高达两千八百毫秒，将近三秒。 更糟的是，工具数量从十个增长到两百个，成本翻了整整二十倍。而工具调用的准确率却从百分之九十五腰斩到只剩百分之五十。也就是说， ai 有 一半儿概率用错工具， 这在实际业务里几乎是不可接受的。引入 tourag 之后，分组加两级路由的方案，召回率达到百分之九十四，响应时间四百一十毫秒。用生活中的参照物来理解，原来找工具要等将近三秒，现在不到半秒，速度快了将近七倍。 原来每十次有五次用错工具，现在不到一次出错，从抛硬币级别回到了可以信赖的水平。 这项技术正在悄悄影响你每天用到的产品。客服机器人变得更聪明了，以前企业 ai 客服只能处理有限的问题类型，有了工具解锁，同一个客服， ai 可以 同时处理查订单、改地址、申请退款、查物流、开发票等几十上百种操作，而且不会搞混。 企业内部的 ai 助手也更实用了。大公司内部系统复杂，各种数据库、审批流程、通知系统都有对应工具，以前 ai 助手只能对接少数几个，现在可以对接几百个，按需调用。 更关键的是，整理上个月销售数据，找出异常，发邮件给相关负责人。这种多步骤复杂任务动态解锁，让 ai 能在任务进行中灵活切换，真正跑完全程。 但事情没那么简单。这套方案虽然大幅改善了工具太多的问题，仍有几个明显的局限值得说清楚。召回率百分之九十四听起来不错，但意味着仍有百分之六的情况下，真正需要的工具没被找到。 一旦工具没被解锁进来， ai 根本不知道它的存在，任务就会卡死或走弯路。而且工具描述质量决定一切，如果工具的文字说明写的太技术化、太模糊，解锁就找不准。这对工具说明书的注写提出了很高要求，目前还高度依赖人工来保证质量。 这个描述质量的问题是目前最难啃的骨头，因为它不是纯技术问题，而是需要人真正理解业务场景，才能写好 整个逻辑串起来就是这样，工具太多，会让 ai 助手又慢又贵，还容易出错。根本原因是 ai 的 脑容量和注意力都是有限的。 two rag 的 思路就像图书馆的剪辑系统，不把所有书对。

谷歌团队最近通过研究整个 ai 生态系统中技能的构建方式，发现从 antlrack 的 存储库到 vsell 和 google 的 内部指南，反复出现了这五种设计模式，它能帮你彻底解决 agent 输出乱不稳定的痛点。第一种， tool rapper 工具包装器， 把任何第三方库或 api 封装成 ai 智能体，可直接调用的工具用，到时才加载，不用硬塞提示词，秒变领域专家。第二种， generate 生成器模式，用模板加样式指南，保证输出结构统一、格式稳定， 写报告、做文档、生成提交信息再也不会每次都不一样。第三种， reviewer 审核员模式，对照检查清单，逐条评分，按错误等级输出结果，换个清单就是新能力。第四种， version 反转模式，不让 a 诊瞎猜，先当面试官执行任务前，主动面试你 澄清需求，确认边界，大幅减少返工。第五种是排查流水线模式，复杂任务拆成多步骤，每部设检查点，强制按顺序执行， 上一步不过关就不往下走，适合代码审查、内容发布、合规审核等高质量管控场景。这五种模式不是孤立的， 还能自由组合流水线加审核生成器，配反转复杂工作流，轻松拆解，不用再堆很长提示词。用好这五种设计模式，你的 agent 能力直接升级，稳定又好用。