基于Python-use范式的开源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 不光会调用工具，也会自己造工具。

　　问：您提出 “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、子 - Agent、workflow 实现任务拆解和执行。往往是图状、嵌套、多 Agent。

　　直接写出「任务目标 → 代码逻辑 → 执行」的 Python 脚本来解决任务，代码即规划 + 工具调用 + 执行的统一体。

　　直接调用 Python 生态中任意库、API、命令行、HTTP、数据库等，甚至动态生成和运行代码，无需提前注册工具。

　　强调框架内一致性和安全性，但牺牲了灵活性。增加一个新工具需要写 schema、注册、重训练或适配。

　　由于直接写 Python 代码，可以随时引入任何新工具、任意组合库、甚至嵌入 shell/JS 等。灵活性最大。

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

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

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

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

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

　　人类写出一段 Python 程序告诉 AI 怎么干，或者 AI 直接生成出一段 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：找不到现成的 “拆 Excel 发 PDF” 工具，任务失败或需要人手扩展工具。

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

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

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

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

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

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

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

　　提到这个问题不得不提一下我们团队的另外一个产品它是全球领先的网络空间资产测绘平台，它通过对全球 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，对要做的场景 know how 掌握了多少是关键。

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