旧有的 Agent 框架, 愈发类似于那种借助低代码拖拽方式的「机器人编排器」。

-采用 则是径直用 将 Agent 逻辑予以实现出来, 致使代码成为 Agent。”。

多数时候, Agent框架将“工具”视为黑盒API, 此时, 知道创宇AI业务部总经理王利伟, 与其团队在思索他法, —— 若代码为工具, 且LLM擅写代码, 为何不让AI自体运行以完成任务?

在此次访谈里头, 王利伟条理分明地系统讲述并且阐释了 “-use 范式”, 这是一种将 Agent 逻辑直接撰写成能够执行的极为简约的思考路径, 它摒弃了繁杂的注册、编排以及多 Agent 协商, 达成了细粒度代码控制, 使得逻辑具备可控性、可进行调试以及最少的 Token 浪费。

本周六, 王利伟会去参加称为【Al Agent: 从工具助手到自主行动】的 OSC 源创会・杭州站活动, 要发表叫作《基于 -use 范式的开源 Agent》的主题演讲, 讲讲怎样促成 LLM 与生态构建成强大的智能体, 凭借独创的 -use 范式, 使得 AI 不但会运用工具, 而且还会自行创造工具。

即刻报名：

问: 您所提及的 “-use 范式” 跟传统 Agent 开发框架的核心差别是什么, 它怎样去解决现有 Agent 工具调用能力方面存在的局限性的?

答：

在回答这个问题以前, 我们先来界定一下什么被称作 “工具”, 大家都清楚 “工具” 调用属于 Agent 的基本能力当中的一种。那工具究竟是什么呢? 是各种各样的应用程序, 还有接口对不对。从本质上来说都是代码, 代码构成了 MCP 工具、API 工具以及各种各样的应用程序。用范式是回归到第一性原理, 将代码视作工具, 代码是所有工具最为基本的构成部分, 代码能够组合成各式各样的工具, 而语言模型对代码的理解以及编写能力均足够强大, 相较于依赖现成工具, 用范式是从代码着手, 具备灵活性、扩展性。当然, 在这个过程中用范式也是支持对现有工具进行调用的, 例如MCP、用范式等等。而在一些呈现碎片化的场景当中, 存在着没有标准工具、也没有现成工具能够加以运用的情况, 在这样的场景里, use能够依赖于通过编码自行寻觅到更富有创造性的方案。

一句话总结：

被称作「机器人编排器」的东西, 更倾向于是借助低代码拖拽特点的传统Agent框架。

那就直接运用, 将 Agent 的逻辑给实现出来, 使得代码成为 Agent。

维度

传统 Agent 开发框架

-use 范式

任务驱动逻辑

经由「规划、调度、工具调用、反馈」这般的多层 Agent 以及子 - Agent, 达成任务的拆解与执行, 通常呈现为图状、嵌套且多 Agent 的形态。

按照「任务目标」, 而后写出遵循「代码逻辑」, 最后进行「执行」的脚本, 以此来解决任务, 代码是规划、工具调用以及执行整合而成的统一体。

工具调用

由 Agent 通过有限的模板化调用（受限于预定义接口和框架支持的函数集合）, 工具通常封装为 / Tool 类、API。

任意调用, 那生态里的库、API、命令行、HTTP、数据库等等, 甚至是动态生成并运行代码, 都不用提前去注册工具。

灵活性

注重框架里的一致性以及安全性, 然而却舍弃了灵活性, 增添一个全新工具务必去撰写、登记、再次训练或者进行适配。

因为能够直接去写 代码, 从而可以在任何时候进行引入新出现的任何工具, 随意地进行组合库的工作, 甚至进而达成嵌入 shell/JS 等结果, 具备最大灵活性。

执行粒度

凭借大量的 LLM 推理, 加上中间规划, 其执行的粒度较为粗大, 进而容易出现浪费 token 的情况, 还容易招致出错。

细粒度代码控制，逻辑可控、可调试、最少 token 浪费。

至于怎样去解决现有的 Agent 工具调用能力方面存在的局限性, 大致上的分析情况是这样:

现有 Agent 框架在工具调用上主要有两个局限：

1、工具注册存在繁琐以及封闭的状况, 具体而言, 要求开发者将工具撰写成契合接口的模样, 接着把它注册到 Agent 系统当中, 其灵活性比较低, 扩展速度较为缓慢, 有标点。

2、推理所需成本偏高, 进而导致出现的错误过多: 具体表现为, 每一次进行工具调用的时候, 都极有可能需要借助语言模型去揣度究竟哪个工具适用, 以及怎样去填充相关参数, 这样做不仅极易出现差错, 而且进程颇为缓慢。

-use 通过：

就是代码作为接口, 它不需要任何预先定义, 也不需要进行注册, 其中能够通过 /pip 来找到的库, 以及所调用的 API, 这些统统都是工具。

针对动态生成工具, 其中能够即时生成函数, 能够再生成类, 能够接着生成模块, 甚至还能够做到临时对代码进行下载, 或者对代码进行拼接, 之后再去执行, 并且是完全不会受到任何限制的。

全栈生态, 具备可调用系统命令的能力, 拥有能操作数据库的本事, 有着发起网络请求的条件, 存在进行爬虫工作的可能, 包含开展机器学习的情形, 涵盖可使用云 API 的状况, 不会再受到框架内置工具集的限制。

例如：

要是你打算在传统 Agent 框架之中, 增添对于某一个第三方 CRM 的支持, 那就需要去撰写 Tool 类, 还要进行注册, 此外, 要让 LLM 学会去调用。

-use 里，你直接用 或 SDK 写个接口调用完事。

传统 Agent 范式假设：

人类使用自然语言表述 “你去做 X”, 人工智能承担将其拆解成多步计划这样的职责, 接着还要负责调度各种工具进而达成完成的结果。

-use 范式更像：

于某一人而言, 写出一段程序并且让其将告知AI如何去做, 再不然呢, AI直接生成出一段程序，而后凭借这段程序去做。

即：

传统是 LLM + 流程编排器 + 有限工具集

-use 是 LLM+ 解释器 + 全 生态

被问到的是, “让AI自己造工具”属于演讲的闪光点, 能不能阐释LLM于-use范式里怎样达成从“使用工具”至“生成工具”的跨越, 关键的技术难点是什么?

答：

生产工具, 实际上只是一张窗户纸, 而使用工具, 其实仅仅是对LLM的理解以及应用方式的差别, 这只是思维方式的不同而已。使用工具, 即假定要处理的任务存在各种可供使用的现成工具, “use”同样具备此能力, 并非意味着它不支持现有工具的调用, “use”认为代码是智能体, 代码是, 可以使用、使用能够使用各类工具, 它能使用代码去编码、写工具。

在传统 Agent 中：

LLM 能做到的通常是：

选择一个已有工具

正确填写参数调用

（最多）按照文档组合几个已有工具完成目标

它的 “能力边界” 被框架里预定义的 / 限死了。

在 -use 中：

LLM 不光能调用库和工具，还可以：

根据任务需要动态生成代码段（工具）

把这段代码封装成函数 / 类 / 模块 / 脚本

并且可以即时运行、测试、调试它

也就是说，它不只是 “调用工具”，它还能写工具！

举个例子：

帮忙实现这样的操作, 将数量众多的Excel分别按各个部门进行拆分, 使其成为不一样的PDF, 然后把这些PDF通过邮件发送出去。

传统的 Agent, 没能找寻到现成的能操作 “把 Excel 拆开并发送成 PDF” 的工具, 致使该任务以失败告终。或者, 就需要人工去扩展工具。

-use：LLM 生成一个函数

def ():

# , fpdf, 逻辑

使测试得以运行, 将存在的漏洞予以修复, 随后进行保存。这之中所涉及的这段代码, 乃是全新构建生成的一种“工具”, 往后再次使用时能够直接运用。

为什么 -use 能支持 “造工具”？关键在于：

当然，这个跨越不是轻易做到的，主要有几个挑战：

代码生成的正确性

上下文管理

安全性

怎么克服这些难点也有对应的思路和方案，比如：

总结一句话：

于 -use 里, LLM 并非仅仅是 “挑选工具”, 而是能够直接撰写出契合当下任务的全新工具, 并且是写完即可使用。

而传统的 Agent , 它是停留在”调用已有的工具“这个阶段的, 并且还受到框架的工具集的限制！

答: 生态当中有着大量的开源库, 然而, 大型语言模型常常因为依赖这方面的问题以及环境方面的问题, 导致调用出现失败的情况。使用该模型, 怎样能够达成大型语言模型与本地环境之间的高效以及安全的交互呢?

答：

这个问题所提相当优质, 的确存在各种各样的版本方面的问题、兼容性的问题、依赖关系方面的问题等等。解决办法是它于执行任务之际并不限定于一种方案, 要是一种不行便会切换至另外的方案, 大模型晓得如何去解决。如今vibe大致都是类似的思路, 倘若出现错误, 再重新抛给大模型去剖析并提出修正即可, 直至运行成功。

还有一种方式是, 在开展任务期间，将会对用户系统关联的版本讯息以及环境情况加以收集。之后, 把这些收集到的内容发送给模型, 也就是我们所说的token分发平台以及相应的网关。在这个平台和网关上, 会融合诸多场景里的“最佳实践”, 进而构建起经验库与知识库。通过这样的方式, 便能依据用户所处的环境进行最优匹配。可以这么理解, 就是在上面实施了大量的优化措施。

且说那安全问题, 就如上个问题所提及的那般, 从理论层面来讲, 确实是存在着安全方面的风险的, 我们, 已经对安全模块有所考量, 并且也具备相应的方案, 只是尚未有时间去付诸行动罢了。有一个安全公司, 在进行产品制作的过程当中, 并未将安全机制置于首要位置, 这是有着其他方面的考虑因素的, 我们其实完全能够打造出一个沙盒, 然而为何没有去做沙盒, 因为将其放置于沙盒之中会对诸多功能造成极大的限制, 实际上, 我们电脑上的大多数软件都是在本机上运行的, 并没有沙盒环境, 只有杀毒软件才会存在沙盒这种情况。从理论意义上讲, 无论做什么事情安全风险都是实实在在存在的, 即便是要与安全风险一同前行, 也不能因恐惧风险而停止不前, 使得行事畏缩不前而废弃进取。实际情况是, 就当前几万注册用户所反馈的使用体验而言, 尚未出现被提及的安全方面的问题, 当然, 随着项目一点点成熟, 与之相应的机制会逐步得以进一步完善。目前, 有着相关想法但精力上不太允许, 从技术层面思考的话, 这并非是没办法去解决的难题。

问: 于操作物联网设备之际, 智能体怎样去统一处理那些不同品牌、协议设备的接口差异? 它是不是依赖预设的插件?

答：

他对现有的品牌协议全都明白, 主流的接口标准、协议他都曾学习过, 这些知识他比人更为熟悉, 他充分信任并利用大模型。若遇到定制化软件他未曾学习过, 便直接写进 API 描述里, 使大模型依据 API 描述进行学习, 当然这对 api 描述是有一定要求的, 实在不懂的就给他加上外挂说明。AiPy 操作物联网设备并非依赖插件, 主要借助 API , 当然有插件可供调用也是很不错的, 实际上我们也在筹备发布插件商城。