“传统 Agent 框架更像是用低代码拖拽的「机器人编排器」，   

 Python-use 则是直接用 Python 把 Agent 逻辑实现出来，让代码就是 Agent。”  

当大多数 Agent 框架还在把“工具”当作黑盒 API 时，知道创宇 AI 业务部总经理王利伟和其团队在思考另一种方式——如果代码就是工具，而 LLM 恰好擅长写代码，为什么不干脆让 AI 自己用 Python 把任务跑出来？

在这篇访谈中，王利伟系统阐述了“Python-use 范式”——一种把 Agent 逻辑直接写成可执行 Python 的极简思路。它抛弃繁复的 Schema 注册、Workflow 编排和多 Agent 协商，实现细粒度代码控制，逻辑可控、可调试、最少 Token 浪费。

本周六，王利伟将出席【Al Agent：从工具助手到自主行动】OSC源创会·杭州站活动，并发表《基于 Python-use 范式的开源 Agent》主题演讲，介绍如何撮合 LLM ➕Python 生态形成强大的智能体，通过独创的 Python-use 范式，让 AI 不光会调用工具，也会自己造工具。

即刻报名：https://www.oschina.net/event/8597955

问：您提出“Python-use 范式”与传统 Agent 开发框架的核心差异是什么？它如何解决现有 Agent 工具调用能力的局限性？

答：

回答这个问题之前，我们先定义一下什么是“工具”，众所周知“工具”调用是Agent的基本能力之一。工具到底是什么呢？是各种应用程序，接口对吧。从根本上来讲都是代码，代码组成了MCP工具、API工具以及各类应用程序。Python use 范式是回归第一性原理，把code当成工具，code是所有工具的最基本构成，code可以组成各种各样的工具，而LLM对code的理解和编写能力都足够强，相比依赖于现成的工具，Python use 是从代码出发，具有灵活性、扩展性。当然，在这过程Python use 也是支持现有工具的调用的，比如MCP、browser use 等等。而对于一些碎片化的场景，没有标准工具、现成工具可以用的场景，Python use 可以依赖于Python 编码自行找到更具创造性的方案。

一句话总结：

传统 Agent 框架更像是用低代码拖拽的「机器人编排器」；

Python-use 则是直接用 Python 把 Agent 逻辑实现出来，让代码就是 Agent

至于如何解决现有Agent工具调用能力的局限性大体分析如下：

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

1、工具注册繁琐且封闭：需要开发者把工具写成符合接口的形式并注册进Agent系统。灵活性低、扩展慢。

2、推理成本高+错误多：每次工具调用都可能需要LLM去推理哪个工具+如何填参数，容易出错，且慢。

Python-use 通过：

代码即接口：不需要任何预定义schema、function calling注册。Python里能 import / pip install 的库、调用的API，都是工具。

动态生成工具：Python里可以即时生成函数、类、模块，甚至临时下载或拼接代码然后执行，完全不受限。

全栈生态：Python能调用系统命令、数据库、网络请求、爬虫、机器学习、云API… 不再被框架内置的工具集限制。

例如：

传统Agent框架里，你要增加对某个第三方CRM的支持，得写Tool类、注册schema、让LLM学会调用。

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

传统Agent范式假设：

人类用自然语言说“你去干X”，AI负责拆解成多步计划+调度各种工具完成。

Python-use范式更像：

人类写出一段Python程序告诉AI怎么干，或者AI直接生成出一段Python程序来干。

即：

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

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

问：“让 AI 自己造工具”是演讲的亮点。能否解释 LLM 在 Python-use 范式中如何完成从“使用工具”到“生成工具”的跨越？关键技术难点是什么？

答：

使用工具其实只是一个思维方式的差别生产工具，只是一张窗户纸，只是大家对LLM的理解以及应用方式的差别。使用工具tool use是假定要处理的任务都有各种现成的工具可以使用，Python use 一样也具备这个能力，并不是说它就不支持现有工具的调用，Python use 认为code is agent ，code is everything，Python 可以use network、use computer 可以use 各类工具，它可以use code去编码、写工具。

在传统Agent中：

LLM 能做到的通常是：

1. 选择一个已有工具

2. 正确填写参数调用

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

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

在 Python-use 中：

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

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

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

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

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

举个例子：

“帮我把一堆Excel按部门拆分成不同的PDF并发邮件”

传统Agent：找不到现成的“拆Excel发PDF”工具，任务失败或需要人手扩展工具。

Python-use：LLM生成一个函数

def split_excel_and_send():

# pandas, fpdf, smtplib逻辑

运行测试、修复bug、保存。这段代码就是一个新造出来的“工具”，下次还能直接用。

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

• LLM生成的就是代码，代码本身就是工具

• Python解释器支持动态定义、动态执行、动态import模块

• 全Python生态的库让“造工具”成本极低

• 人类可以随时review、微调、持久化新工具

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

代码生成的正确性

• LLM写出的代码可能语法正确但逻辑错误

• 对外部库版本/接口调用不熟导致出错

• 没有即时验证的环境，bug率高

上下文管理

• 造出来的工具需要有清晰的输入输出和作用域

• 如果任务复杂，代码的组织结构（函数拆分、模块化）很容易混乱

安全性

• 动态生成的代码有潜在的安全风险（注入恶意代码、破坏环境、泄露数据）

• 需要沙箱或审核机制

��

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

• 内置单元测试和验证，让LLM顺便生成测试用例或自动运行测试，提高正确性。

• 设计合理的prompt模式，指导LLM输出模块化、注释良好、易维护的代码。

• 用虚拟环境+沙箱，让生成和执行的代码不破坏主环境，保障安全。

• 版本控制+注册，把造出来的工具保存到Git、注册到私有PyPI或工具库中。

总结一句话：

在 Python-use 中，LLM 不只是“选工具”，而是可以直接写出满足当前任务的新工具、即写即用；

而传统Agent则停留在“调用已有工具”阶段，受限于框架的工具集。

问：Python 生态有海量开源库，但 LLM 常因依赖、环境问题调用失败。Python-use 如何实现 LLM 与本地 Python 环境的高效安全交互？

答：

这个问题提的非常好，确实是有各类的版本问题、兼容性、依赖关系问题等等。解决方案是它在执行任务的时候不局限一个方案，一个不行会切换到另外的方案，大模型知道怎么解决。如今vibe coding 都是差不多的思路，有错误，再重新丢给大模型去分析提出修正就好了，直到运行成功。

另外一个方法是，在执行任务的时候会把用户系统相关的版本信息、环境信息做收集，发给模型和TrusToken-也就是我们的token分发平台及网关，TrusToken上会集成很多场景的“最佳实践”形成经验库、知识库，从而帮会根据用户环境做最优匹配，可以理解是TrusToken上面做了很多优化。

至于安全问题，上个问题也提到过，理论上确实存在安全风险，我们也有考虑安全模块，也有方案，还没来得及做。一个安全公司在做产品的时候并没有把安全机制放在首位是有其他考虑，我们完全可以做个沙盒，但是为什么不做沙盒，放到沙盒限制了太多功能，实质上我们电脑上大多数软件都是运行在本机，并没有沙盒，只有杀毒软件才会有。理论上安全风险干什么都存在，与安全风险共舞，不因噎废食。实质上，从现在几万注册用户的使用反馈来讲，还没有安全问题被提出。当然，随着项目的成熟会把响应的机制逐渐完善，现在是有想法没精力，从技术上来讲不是不可解决的难题。

问：在操作物联网设备中，智能体如何统一处理不同品牌/协议设备的接口差异？是否依赖预设插件？

答：

充分信任和利用大模型，他对现有的品牌协议他都懂，主流的接口标准、协议他都学习过的，这些知识他比人熟。如果是定制化的软件它没有学习过，直接写到API描述里，大模型通过API描述学习，当然对api描述就有一定的要求，实在它不懂的就给他外挂说明。AiPy操作物联网设备并不是依赖插件，主要是通过API Calling ，当然有插件可以调用也是极好的，实际上我们也在准备发布插件商城。

提到这个问题不得不提一下我们团队的另外一个产品ZoomEye.org，它是全球领先的网络空间资产测绘平台，它通过对全球IPv4和IPv6地址进行探查，能够识别数十亿联网设备的开放端口、服务类型、协议栈、操作系统、硬件厂商、固件版本等关键资产信息。换句话说，ZoomEye 就像是整个网络世界的“显微镜”或“地图系统”，让你可以一眼看清某个 IP 背后部署了哪些设备、跑着什么服务、使用了什么协议。它支持的协议识别范围极广，涵盖操作系统、网络设备等传统IT系统、工业控制系统（如Modbus、BACnet）、摄像头设备（如ONVIF）、网络存储（如NAS）、IoT中控网关、智能家居等，这些恰恰是大多数传统Agent系统难以应对的“黑盒”。我们正在探索将 ZoomEye 的识别能力与 AiPy 结合：AI 可以在执行任务前，通过 ZoomEye 自动识别目标设备类型、开放接口、固件版本，进一步提高调用准确率和安全性。这种从“识别 → 理解 → 控制”的闭环，将极大提升 AI 操控物联网设备的普适性与稳定性。现在ZoomEye也已经发布了MCP和API，大家可以去体验。

问：如何吸引开发者加入Python-use生态？会提供哪些SDK或工具链降低接入成本？

答：

因为项目还在初期，暂时还没有SDK之类的工具，为了方便开发者调试，给大家的支持就是提供了大量Token进行试错调试，默认1000万token，开发者可以凭贡献持续兑换。我们后续会开放商城，商城里可以发布各种插件、成果、知识库、角色、API、MCP等等，开发者也可以贡献各类插件或应用到商城，优秀的成果我们也会做一些激励措施。

随着项目的推进我们会持续优化改进生态，也欢迎大家提意见。

问：对于想尝试Agent开发的团队，您认为切入此领域最应优先掌握的三大能力是什么？

答：

说实话这个问题我并不太敢回答，一是因为我们走的路和别人不一样，二我们自己还并没有成功，没有资格去给别人指点什么。只能单纯的分享自己的几个感受：

模型能力足够强，有很大的挖掘潜力。

以前是语料驱动模型，现在是数据驱动Agent，对要做的场景know how 掌握了多少是关键。

不管你啥范式，啥技术，不出1个月时间大家都能做到，大家也看到了现在大模型之间的能力差距差别是越来越小了，技术之外的优势可能才是竞争力。