新智元報道

編輯：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

?點贊、轉發、在看一鍵三連?

點亮星標，鎖定新智元極速推送！