相较于其他, 传统 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 工具以及各类应用程序。Use范式回归第一性原理, 将code视作工具, code是所有工具的最基本构成部分, code能够组成各式各样的工具, LLM对code的理解能力与编写能力均足够强, 相较于依赖现成工具, use从代码着手, 具备灵活性、扩展性, 当然, 在此过程中use也支持现有工具的调用, 例如MCP、use等等。然而, 针对某些呈现碎片化的场景, 也就是那种不存在标准工具、也没有现成工具以供使用的场景, use 能够依靠编码自行探寻到更具创造性的方案。
一句话总结：
传统的 Agent 框架, 更像是那种借助低代码拖拽方式的, 所谓的「机器人编排器」。
采用则是径直去用, 将会把Agent逻辑予以实现出来, 致使代码成为Agent。
维度
传统 Agent 开发框架
-use 范式
任务驱动逻辑
借助「规划, 调度, 工具调用, 反馈」这样的多层 Agent 以及子 - Agent 来达成任务的拆解和执行, 通常会呈现为图状、嵌套且多 Agent 的形式, 是这样的情况。
径直写出, 将「任务目标 → 代码逻辑 → 执行」的脚本用以解决任务, 代码乃是规划、工具调用以及执行的统一整体。
工具调用
通常而言所谈到的工具, 会被封装成为, /Tool类、API, 而这是要通过Agent, 借助有限的模板化调用方式来达成的, 不过这种调用是受限于预定义接口以及框架所支持的函数集合范围之内的。
不用事先去注册工具, 能够直接去调用生态里随便哪一个库、API、命令行、HTTP、数据库诸如此类的, 甚至于能够动态地生成以及运行代码。
灵活性
着重突出框架范围之内的一致性以及安全性, 不过呢, 灵活性却遭受了 。增添一个全新的工具, 就得去进行书写、注册、重新训练或者适配。
借着直接书写代码的方式, 能够随时引入任何全新的工具, 将任意的库进行多种组合, 甚至嵌入 shell 或者 JS 等, 其灵活性是最为突出的。
执行粒度
依靠大量的语言模型推理, 以及中间规划, 执行的粒度较为粗糙, 易于造成token的浪费, 还容易出错。
细粒度代码控制，逻辑可控、可调试、最少 token 浪费。
那么, 关于怎样去处理现有的 Agent 工具调用能力方面存在的局限性, 大致的分析情况是这样的:
现有 Agent 框架在工具调用上主要有两个局限：
1、工具进行注册这个行为, 是既繁琐又封闭的那种情况, 具体表现为开发者得动手, 把工具撰写成契合接口的形式, 然后再将其注册进Agent系统之中, 它存在灵活性不高、扩展速度缓慢的问题。
2、推理所需成本比较高, 出现的错误数量较多。每一次当进行工具调用的时候, 都极有可能需要借助LLM去进行推理判断究竟是哪一项工具, 以及应该怎样填写相关参数, 不仅仅容易出现差错, 而且整个过程的速度较为缓慢。
-use 通过：
代码当属接口, 无需任何预先定义, 无需注册, 其中能通过/pip获取的库, 以及所调用的API, 皆为工具。
动态生成的工具, 能够在其中即时构建函数, 还能够创建类, 也能够打造模块, 甚至可以临时性下载代码, 或者拼接代码, 之后去执行, 并且全然不受任何限制。
全栈生态, 具备可调用系统命令的能力, 拥有操控数据库的本事, 能够发起网络请求, 涉足爬虫领域, 进行机器学习相关操作, 还能运用云 API等, 不会再被框架所内置的工具集给限制住。
例如：
在传统 Agent 框架之中, 若你打算增添对某一第三方 CRM 的支持, 那就需要去撰写 Tool 类, 还要进行注册, 并且要让 LLM 学会去调用。
-use 里，你直接用 或 SDK 写个接口调用完事。
传统 Agent 范式假设：
人类运用自然语言表述 "你去做 X", 人工智能承担将其拆解为多步计划, 并且调度各式各样的工具来达成的任务。
-use 范式更像：
由人类编写一段程序, 以此告知AI该怎么做, 或者使得AI直接生成一段程序, 并用来做这件事。
即：
传统是 LLM + 流程编排器 + 有限工具集
-use 是 LLM+ 解释器 + 全 生态
想问一下, "让AI自己去制造工具"这一点是那场演讲里的突出之处, 能不能阐释LLM在-use这个范式里是怎样达成从"运用工具"转变为"生成工具"的这样一种跨越的, 其关键的技术难点又是什么?
答：
生产运用工具这种行为, 实际上仅仅是一种思维方式存在着差异, 而制造生产工具, 它仅仅如同薄如蝉翼的一层遮挡物一般轻薄, 仅仅只是众人对于语言大模型的领会理解以及运用方式方面存在着不同而已。假定要处理的任务都有各种能用于使用的现成工具, 这是关于使用工具的情况, use有着同样的能力, 并非它不支持对现有工具进行调用, use觉得code是agent, code是, 它能够use各类工具, use能够使用use去使用各类工具, 它可以借助code来进行编码、编写工具。
在传统 Agent 中：
LLM 能做到的通常是：
选择一个已有工具
正确填写参数调用
（最多）按照文档组合几个已有工具完成目标
它的 "能力边界" 被框架里预定义的 / 限死了。
在 -use 中：
LLM 不光能调用库和工具，还可以：
根据任务需要动态生成代码段（工具）
把这段代码封装成函数 / 类 / 模块 / 脚本
并且可以即时运行、测试、调试它
也就是说，它不只是 "调用工具"，它还能写工具！
举个例子：
协助我, 将那数量众多的Excel, 按照各个部门进行区分, 拆分成不一样的PDF, 并且发送邮件出去。
找不见现成的"可将 Excel 拆开并发送为 PDF"的工具, 进而导致任务失败, 或者鉴于此需要人手来将工具完成扩展。
-use：LLM 生成一个函数
def ():
, fpdf, 逻辑
执行测试, 对发现的 bug 予以修复, 之后进行保存。此段代码乃是新构建而成的 "工具", 在下次能够直接加以运用。
为什么 -use 能支持 "造工具"？关键在于：
当然，这个跨越不是轻易做到的，主要有几个挑战：
代码生成的正确性
上下文管理
安全性
怎么克服这些难点也有对应的思路和方案，比如：
总结一句话：
以 -use 来讲, LLM 并非仅仅是 "选工具", 而是能够直接创写出契合当下任务的全新工具, 并且能够做到即写即用。
传统的 Agent 呢, 它是停歇留在叫做 "调用已有工具" 的那个阶段的, 被框架的工具集给限制住了。
问: 生态存在着数量众多的开源库, 然而大型语言模型常常因为依赖、环境方面的问题导致调用失败。那么, "使用"怎样达成大型语言模型与本地环境的高效且安全的交互呢?
答：
这个问题所提出的，是极为出色的, 的确存在着各种各样的版本方面的问题, 以及兼容性的问题, 还有依赖关系之类的问题等等。其解决方案在于, 它于执行任务之时, 并非局限于一种方案, 一种方案行不通便会切换至另外的方案, 大模型懂得怎样去解决。如今vibe都是大致相同的思路, 出现错误了, 再次丢给大模型去做分析从而提出修正便是了, 直至运行成功。
另外还有一个方法, 那就是。在执行任务之际, 会对有关关联用户系统相应的版本信息, 还有所处环境信息予以收集。之后会把其发送出去。发送到什么地方? 发送给模型, 还有。也就是我们的token分发平台以及网关装置。在这个处于上位的平台之上, 会集成涵盖众多场景的 "最佳实践" 部分内容。进而形成经验库以及知识库。如此一来便能够帮会依据用户环境, 去进行最优匹配操作。可以理解为, 在上面做了诸多优化举措。
对于安全问题, 就像上个问题所提及的那样, 从理论层面来讲, 确实是存在安全方面的风险的, 我们也思索过安全模块, 并且也具备相应的方案, 然而还未到展开实施的时刻。有一家安全公司在进行产品制作期间, 没有将安全机制摆放于首要位置, 这是有着其他方面的考量的, 我们是完全能够打造一个沙盒的, 可是为何没有去构建沙盒呢, 因为将其放置于沙盒之中会对诸多功能形成限制, 实际上我们电脑上的大部分软件都是在本机运行的, 并没有沙盒环境, 唯有杀毒软件那类才会存在沙盒状态。从理论角度出发, 安全风险在任何行为中都是存在的, 要与安全风险相伴前行, 不能因为有风险就轻易放弃。实际上, 从目前处于几万注册用户的使用反馈情况来看, 尚无安全问题被提出来, 当然, 伴随项目迈向成熟, 会把相应的机制逐步予以完善, 当下是存有想法却缺乏精力, 从技术范畴来讲非是无法解决的难题。
问句呈现为这般: 于操作那一物联网设备期间, 智能体究竟怎样去统一处置不同品牌以及协议设备的接口差异, 是不是依赖预先设定的插件?
答：
对于大模型, 要给予充分信任并加以利用, 他知晓众多现有的品牌协议, 学习过主流的接口标准、协议, 在这些知识方面比人还要精通些。要是存在定制化软件他未曾学习过的情况, 那就直接将其写入 API 描述之中, 让大模型借助 API 描述进行学习, 如此一来, 对 API 描述便定会有一定要求, 实在是他不懂的内容就为其添加外挂说明。AiPy 操作物联网设备并非依靠插件, 主要是借助 API, 当然若有可供调用的插件也是很不错的, 实际上我们也正筹备发布插件商城。