新智元报道

编辑：LRST

【新智元导读】Anthropic发布了Programmatic Tool Calling（PTC）特性，让Claude通过代码编排工具执行，降低token消耗、减少延迟并提升准确性。不过，国产minion框架从一开始就采用类似架构，其LLM规划决策，代码环境执行，仅返回最终结果。相比PTC需显式启用，minion将此作为基础架构，还支持Python生态、状态管理、错误处理等功能，在实际应用中展现出更高的效率和灵活性。

2025年11月24日，Anthropic正式发布了Programmatic Tool Calling （PTC）特性，允许Claude通过代码而非单次API调用来编排工具执行。

这一创新被认为是Agent开发的重要突破，能够显著降低token消耗、减少延迟并提升准确性。

然而，Minion框架的创建者最近分享了一个有趣的事实：Minion从一开始就采用了这种架构理念。

代码链接:https://github.com/femto/minion

在PTC概念被正式提出之前，minion已经在生产环境中证明了这种方法的价值。

PTC解决了什么问题？

Anthropic在博文中指出了传统Tool Calling的两个核心问题：

1. Context污染问题

传统方式中，每次工具调用的结果都会返回到LLM的context中。例如分析一个10MB的日志文件时，整个文件内容会进入context window，即使LLM只需要错误频率的摘要。

2. 推理开销与手动综合

每次工具调用都需要一次完整的模型推理。LLM必须「眼球式」地解析数据、提取相关信息、推理片段如何组合，然后决定下一步——这个过程既缓慢又容易出错。

Minion的解决方案

天然的PTC架构

Minion框架从设计之初就采用了一种根本不同的架构：LLM专注于规划和决策，具体执行交给代码环境。

这正是PTC想要实现的效果，但minion将其作为基础架构而非可选特性。

实际案例对比

Anthropic博文中的预算合规检查示例。

任务：找出Q3差旅超预算的团队成员

传统Tool Calling方式：

获取团队成员 → 20人

为每人获取Q3费用 → 20次工具调用，每次返回50-100条费用明细

获取各级别预算限额

所有数据进入context：2000+条费用记录（50KB+）

LLM手动汇总每人费用、查找预算、比较超支情况

使用PTC后：

Claude写一段Python脚本编排整个流程

脚本在Code Execution环境运行

LLM只看到最终结果：2-3个超支人员

在Minion中，这种模式是默认行为，llm会生成代码：

关键区别在于，Minion是框架的核心设计，所有复杂任务都这样处理；

而PTC需要显式启用，存在多重架构限制：

必须显式标记哪些工具允许programmatic调用（allowed_callers配置）

运行在受限的Claude容器环境中，无法自由安装任意包

文件需要通过额外的Files API上传（单文件最大500MB限制）

工具必须在容器4.5分钟不活动超时前返回结果

Web工具、MCP工具无法通过programmatic方式调用

Minion的优势

更进一步

Minion不仅实现了PTC的核心理念，还提供了新万博体育：优势：

完整的Python生态系统

Minion中的代码执行环境拥有完整的Python生态访问权：

状态管理和持久化

Minion天然支持复杂的状态管理：

错误处理和重试逻辑

在代码中显式处理各种边界情况：

并行和异步操作

充分利用Python的异步能力：

性能数据对比

根据Anthropic的内部测试，PTC带来了显著改进：

Token节省：复杂研究任务从43,588降至27,297 tokens（减少37%）

延迟降低：消除了多次模型推理往返

准确率提升：

内部知识检索：25.6% → 28.5%

GIA基准测试：46.5% → 51.2%

在minion的生产使用中，能观察到类似甚至更好的指标，因为：

更少的模型调用：LLM只在规划阶段和最终总结时参与

更高效的资源利用：本地数据处理不消耗API tokens

更可预测的性能：代码执行路径明确，减少了LLM的不确定性

架构哲学

谁应该做什么？

Minion的设计基于一个核心信念：

LLM擅长理解、规划和推理；Python擅长执行、处理和转换。

这种职责分离带来了清晰的架构：

这不仅仅是优化，而是一种架构级别的重新思考。

Tool Search Tool

Minion的动态工具发现

Anthropic的另一个新特性是Tool Search Tool，解决大型工具库的context消耗问题。Minion在这方面也有相应的机制：

分层工具暴露

向量搜索工具发现

实际应用

Minion在生产环境

Minion框架已经在多个实际场景中证明了这种架构的价值：

案例1：大规模数据分析

金融科技公司使用minion分析数百万条交易记录，寻找异常模式：

结果：

处理100万条记录

LLM仅消耗~5K tokens（传统方式需要500K+）

端到端延迟：30秒（vs 传统方式的5分钟+）

案例2：多源数据整合

SaaS公司使用minion整合来自多个API的客户数据：

案例3：自动化工作流

DevOps团队使用minion自动化复杂的部署流程：

超越PTC

Minion的未来方向

虽然PTC是一个重要的进步，但minion的架构设计让我们能够探索新万博体育：可能性：

混合推理模式

在一个会话中智能切换：

增量计算和缓存

智能重用中间结果：

多模型协作

不同模型处理不同阶段：

开源的力量

社区驱动的创新

Minion作为开源项目（300+ GitHub stars），其发展得益于社区的贡献和反馈。这种开放性带来了：

快速迭代：社区发现问题和用例，推动快速改进

多样化应用：用户在我们未曾想象的场景中使用minion

相比之下，PTC虽然强大，但：

需要显式配置（allowed_callers,defer_loading等）

依赖特定的API版本和beta功能

与Claude的生态系统紧密耦合

Minion的设计原则是provider-agnostic——你可以用任何LLM后端（Claude, GPT-4, 开源模型），架构优势依然存在。

技术细节

实现对比

深入比较实现细节。

PTC的实现方式

Minion的实现方式

关键区别：

PTC：工具调用通过特殊的API机制，有caller/callee关系

Minion：工具就是普通的Python async函数，LLM生成标准代码

为什么这个架构如此重要？

随着AI Agent向生产环境发展，业界面临的核心挑战是：

规模：处理百万级数据，不能全塞进context

可靠性：生产系统需要确定性的错误处理

成本：token消耗直接影响商业可行性

性能：用户体验需要亚秒级响应

传统的单次工具调用模式在这些维度上都遇到瓶颈。代码编排模式（无论是PTC还是minion）提供了突破：

支持多种LLM后端（Claude, GPT-4, 开源模型）；

灵活的部署选项（云端、本地、混合）；

丰富的Python生态系统集成。

结论

架构的必然收敛

Anthropic推出PTC不是偶然——这是agent架构演进的必然方向。当你需要构建能处理复杂任务、大规模数据、多步骤流程的生产级agent时，你会自然而然地得出这样的结论：

LLM应该专注于它擅长的（理解和规划），让代码处理它擅长的（执行和转换）。

Minion从一开始就拥抱了这个理念，并将继续推动这个方向：

?今天：完整的PTC式架构，生产环境验证

明天：更智能的工具发现、更高效的状态管理

未来：混合推理、增量计算、多模型协作

视频演示

作者信息

郑炳南，毕业于复旦大学物理系。拥有20多年软件开发经验，具有丰富的传统软件开发以及人工智能开发经验，是开源社区的活跃贡献者，参与贡献metagpt、huggingface项目smolagents、mem0、crystal等项目，为ICLR 2025 oral paper《AFlow: Automating Agentic Workflow Generation》的作者之一。

参考资料：

https://github.com/femto/minion

https://github.com/femto/minion/blob/main/docs/advanced_tool_use.md

秒追ASI

?点赞、转发、在看一键三连?

点亮星标，锁定新智元极速推送！