新智元报道

编辑：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专注于规划和决策，具体执行交给代码环境。

Minion的典型工作流包括： 1. LLM分析用户需求，制定执行计划； 2. LLM生成Python代码来编排工具调用； 3. 代码在隔离环境中执行，处理所有数据操作； 4. 只有最终结果返回给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会生成代码：

LLM生成的计划代码 team = await get_team_members("engineering") 数据处理在本地完成 exceeded = [] for member in team: expenses = await get_expenses(member["id"], "Q3") total = sum(e["amount"] for e in expenses) budget = budgets[member["level"]] if total > budget["travel_limit"]: exceeded.append({ "name": member["name"], "spent": total, "limit": budget["travel_limit"] }) return exceeded Minion可以直接使用任何Python库import pandas as pdimport numpy as npfrom sklearn.cluster import KMeans 复杂的数据科学任务model = KMeans(n_clusters=3)clusters = model.fit_predict(spending_patterns)

状态管理和持久化

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

class BudgetAnalyzer: def __init__(self): self.cache = {} self.history = [] async def analyze_department(self, dept): 合理的默认值 raise Exception(f"Failed after {max_retries} attempts")

并行和异步操作

充分利用Python的异步能力：

同时分析所有部门 results = await asyncio.gather(*[ analyze_department(dept) for dept in departments ]) Minion的工具分层策略class MinionToolRegistry: def __init__(self): self.core_tools = [] 按需加载 self.rare_tools = {} 智能工具选择 tools = self.core_tools.copy() 使用embedding的工具搜索from sentence_transformers import SentenceTransformerclass SemanticToolSearch: def __init__(self, tool_descriptions): self.model = SentenceTransformer('all-MiniLM-L6-v2') self.tool_embeddings = self.model.encode(tool_descriptions) def find_tools(self, query, top_k=5): query_embedding = self.model.encode([query]) similarities = cosine_similarity(query_embedding, self.tool_embeddings) return self.get_top_tools(similarities, top_k)

实际应用

Minion在生产环境

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

案例1：大规模数据分析

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

async def detect_anomalies(): 执行代码直接处理大数据集 transactions = await fetch_all_transactions(start_date, end_date) 使用机器学习检测异常 anomalies = detect_with_isolation_forest(features) 并行获取所有数据源 crm_data, support_tickets, usage_logs, billing_history = await asyncio.gather( fetch_crm_data(customer_id), fetch_support_tickets(customer_id), fetch_usage_logs(customer_id), fetch_billing_history(customer_id) ) 多步骤工作流，每步都有条件逻辑 2. 构建和推送镜像 image = await build_docker_image() await push_to_registry(image) 监控5分钟 metrics = await get_canary_metrics(canary) if metrics.error_rate > 0.01: await rollback_canary(canary) return {"status": "rolled_back", "metrics": metrics} 简单任务：直接工具调用if task.complexity < THRESHOLD: result = await simple_tool_call(task) 记忆化的数据获取@lru_cache(maxsize=1000)async def cached_get_user_data(user_id): return await fetch_user_data(user_id) 规划用强模型plan = await claude_opus.create_plan(user_request) 执行和监控result = await execute_with_monitoring(code) Anthropic的PTC需要特定配置{ "tools": [ { "type": "code_execution_20250825", "name": "code_execution" }, { "name": "get_team_members", "allowed_callers": ["code_execution_20250825"], ... } ]} Minion的工具定义是标准Pythonclass MinionTools: @tool async def get_team_members(self, department: str): """Get all members of a department""" return await self.db.query(...) @tool async def get_expenses(self, user_id: str, quarter: str): """Get expense records""" return await self.expenses_api.fetch(...) 直接调用工具函数 team = await tools.get_team_members("engineering") 任意复杂度的数据处理 analysis = perform_complex_analysis(expenses_by_user) return analysis

关键区别：

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

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

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

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

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

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

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

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

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

传统模式：LLM <-> Tool <-> LLM <-> Tool <-> LLM (慢) (贵) (脆弱)编排模式：LLM -> [Code: Tool+Tool+Tool+Processing] -> LLM (快) (省) (可靠)经过验证的架构：PTC的发布证明了架构选择的正确性——这不是投机性的设计，而是行业领先者独立得出的结论。
先发优势：在PTC成为官方特性之前，minion已经在生产环境积累了经验和最佳实践。
更广泛的适用性：

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

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

丰富的Python生态系统集成。

社区和生态：300+stars代表的不仅是认可，还有潜在的用户基础和贡献者社区。

结论

架构的必然收敛

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

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

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