从MCP到PTC Anthropic回归Code Execution路线，AiPy的范式被再次验证

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

2025年11月4日，Anthropic发布了关于MCP代码执行能力的更新：

Code execution with MCP: Building more efficient agents https://www.anthropic.com/engineering/code-execution-with-mcp

随后在同年11月24日，又推出了开发者平台上的高级工具调用功能：

Introducing advanced tool use on the Claude Developer Platform https://www.anthropic.com/engineering/advanced-tool-use

该文章正式提出了“Programmatic Tool Calling”这一概念。其中，“Code execution with MCP”的发布引发了广泛关注与讨论。由于我们团队早期便基于Python-use（即Code-use）范式开发了AiPy系统，不少熟悉我们的朋友看到相关动态后纷纷转发给我。当时我在社交平台上表达的第一反应是：“Anthropic自己说MCP是‘脱裤子放屁’了”。

实际上，我是较早关注并实践MCP模式的一批人之一。直到我们提出Python-use范式，并在《【Agents/MCP可能不存在了】No Agents, Just Python-use！》一文中深入探讨了技术路线的选择问题。在我看来，Anthropic从“Code execution with MCP”演进到“Programmatic Tool Calling”，某种意义上可视为对其原有路径的一次修正。而这一修正的核心动因，其实是为了解决多MCP、多工具调用所引发的上下文膨胀难题——这本质上属于“上下文工程”的范畴。尽管如此，Anthropic最终的解决方案仍回归到了“代码执行”本身。

以下是Anthropic所展示的技术演进路径：

MCP?--> Code execution with MCP --> Programmatic Tool Calling

表面上看，这条路径具备清晰的逻辑链条和因果关系，呈现出一种自我迭代与优化的趋势。但如果跳出Anthropic自身的叙事框架去审视，就会发现MCP路线在其设计初期就注定了其发展过程必然是曲折且结构臃肿的。

相比之下，Python-use范式则显得更为直接和简洁，更贴近第一性原理的设计思想。

这也解释了为何我一直非常认同某位用户的评价。

当Anthropic在介绍Programmatic Tool Calling时提到其所面临的挑战：

例如分析1000万条日志的场景，而这正是AiPy项目诞生的初衷。相关内容详见“英雄LGX拯救AI章鱼的故事”，收录于《【Agents/MCP可能不存在了】No Agents, Just Python-use！》一文。本地化的数据处理需求，一直是AiPy最受推荐的应用场景之一。虽然很多人认为这种优势源于本地环境的特殊性，而像Manus这类云端系统受限于运行环境难以实现类似功能，但如今随着Claude Code的推出（需注意：AiPy的出现早于Claude Code），Anthropic也开始重视此类本地化诉求，也因此暴露出了上下文爆炸的问题。而“代码执行”机制恰好能有效缓解这一困境。

归根结底，这是一个“技术路线选择”的问题。Python-use（或称Code-use）范式与Anthropic早期路线之间的差异，在它们诞生之初就已经决定了各自的发展轨迹。尽管两者都试图构建自洽的逻辑体系，但在效率与简洁性上，显然存在高下之分。

关于CodeAct：

在我们提出Python-use范式之后，有朋友于10月份在我发布的《【Agents/MCP可能不存在了】No Agents, Just Python-use！》文章下方留言提到了CodeAct项目：

其相关论文资料如下：

Executable?Code?Actions?Elicit?Better?LLM?Agents?

https://arxiv.org/html/2402.01030v4

https://github.com/xingyaoww/code-act

事后我进行了回溯研究。CodeAct项目大约出现在今年4月，而AiPy的启动时间为3月。坦白讲，在当时并未产生太多共鸣，主要原因在于彼时正处于AiPy推广初期，我的注意力集中在“No Agents / No Tools”这一理念上。而CodeAct仍然沿用了传统的多工具调用模式（Function calling）。随着AiPy应用范围扩大，我们陆续收到来自内部和外部的反馈，其中最集中的问题集中在LLM生成代码的稳定性以及代码复用方面。

举例来说，若用户先查询“北京”的天气，再查询“益阳”的天气，AiPy每次都需要重新生成代码，且不同次生成的技术实现方式可能不一致。这就导致在处理简单重复任务时，Python-use范式表现出一定的不稳定性，同时也造成了token资源的浪费，进而引发质疑。针对此问题，我在《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》一文中已有详细阐述。

在早前关于「Python-Use范式“劣势”」的讨论中，曾提及通过“Packages Calling”结合“角色市场”、“API市场”与“插件市场”的方式来应对新问题的稳定性挑战。随后，在10月份发表的《Code是AI的手：姚顺雨访谈与Python-Use范式的对话》一文中，进一步探讨了“可靠性 与 创造性”之间的张力。

我们当时设计并实现了一种被称为“Python Function Calling（PFC）”的机制。从本质上看，这仍属于“Python Packages Calling”的延伸范畴。传统意义上的Function Calling依赖OpenAI定义的JSON格式进行调用，而基于Python-Use范式的调用，则是由大模型直接生成并执行已注册功能函数的代码。这一过程目前在CUI界面中尚不支持，相关工具的具体实现代码可位于/plugins/目录下，用户也可自行开发并注册新的工具函数。

在此基础上，我重新研读了CodeAct项目的论文及其源码。论文核心观点明确提出“Code as Actions”，即“代码即行动”，强调代码本身即是标准操作单元。这一点与Python-Use范式所倡导的“Code is Agent”理念高度一致。相较于传统的JSON或文本格式交互，该方法展现出显著优势。

两者之间最关键的差异在于“No Agents/No Tools”的设计理念。CodeAct通过预先编写和注册功能函数来实现工具调用，这种方式与早期OpenAI的Function Calling演进路径——即Function Calling → MCP → PTC（Programmatic Tool Calling）——一脉相承，都是由开发者事先定义好函数接口供LLM调用。但关键区别在于：

• Function Calling → MCP → PTC 使用的是基于JSON的调用协议；
• 而CodeAct与Python-Use则采用LLM直接生成并执行函数代码的方式完成调用。

由此可见，Programmatic Tool Calling的发展最终趋向于CodeAct所代表的代码直驱模式。唯一的例外是Anthropic当前仍在沿用MCP遗留下来的JSON通信机制。

这一现象本质上仍回归到前述的「可靠性 与 创造性」矛盾。Python-Use范式在创造性方面表现突出，尤其体现在其与环境交互时所具备的高度可扩展性与灵活性。当然，这种开放性也带来了系统稳定性的挑战。我记得在一次内部交流中曾提到：这种不确定性，恰恰是Python-Use范式的核心优势所在！

作为一种技术范式，它天然具备良好的兼容能力。针对现阶段对系统稳定性的实际需求，Python-Use范式完全可以适配：

Python-use 范式 = API Calling + Python Packages Calling + Python解释器 = “万物互联” + “万物编程” + “万境直通”

此前提到的“Python Function Calling（PFC）”，若称为“Python-use Function Calling（PFC）”可能更准确，因其源自“Python Packages Calling”的架构设计。该思想最早体现在AiPy核心中的runtime对象（尽管当前代码可能已有调整）。例如，runtime.install_packages() 方法用于动态安装所需依赖包。在早期系统的提示词中，可以找到如下说明：

全局 `runtime` 对象

`runtime` 对象提供辅助代码完成任务的相关方法。

`runtime.install_packages` 方法

• 功能：申请安装完成任务所需的额外模块
• 参数：一个或多个 PyPi 包名，如：'httpx', 'requests>=2.25'
• 返回值：True 表示成功，False 表示失败

示例如下：

if runtime.install_packages('httpx', 'requests>=2.25'):
    import datasets

https://www.anthropic.com/engineering/advanced-tool-use

“Python-use Function Calling（PFC）”实际上是将此类接口向用户开放，其本质仍未脱离“Python Packages Calling”的框架。从这个角度看，“Python-use Function Calling（PFC）”实质上已等同于一个CodeAct的实现形态。

Python-use 的范式具备良好的工具函数兼容性，但在实际应用中，MCP、PTC、PFC 和 CodeAct 等机制都面临一个共同问题：它们依赖于预先定义的功能实现，必须由开发者主动开发和维护。换句话说，若缺乏开发者的支持或没有对应的工具模块，用户便无法驱动模型在具体环境中执行任务。日常使用中，人们接触的工具可能较为有限，但在专业场景下，这种限制尤为突出。某种程度上可以推测，部分开发者或许乐于看到用户因功能受限而不得不求助的情形。

关于 Python-use Function Calling（PFC）的具体实现方式，可参考以下内容：

https://github.com/knownsec/aipyapp/blob/main/aipyapp/plugins/p_web_tools.py

在 AiPy 的 CLI 版本中，可通过 /plugin 命令查看相关插件支持情况：

>> /plugin

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Available Plugins

┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━┓

┃ ? ?Name ? ?┃ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Description ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?┃ Type ┃ Version ┃ ?Author ? ┃

┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━┩

│ web_tools ?│ Web Tools - Provides web?page?scraping, URL analysis, and HTTP request capabilities. │ TASK │ ?1.0.0? │ AiPy Team │

├────────────┼──────────────────────────────────────────────────────────────────────────────────────┼──────┼─────────┼───────────┤

│ image_tool │ ? ? ? ? ?Image?Tool - Provides?image?recognition and analysis capabilities. ? ? ? ? ?│ TASK │ ?1.0.0? │ AiPy Team │

└────────────┴──────────────────────────────────────────────────────────────────────────────────────┴──────┴─────────┴───────────┘

需要特别指出的是，PFC 的核心是基于 Python 包调用（Python Packages Calling）机制构建的。这一点凸显了 Python-use 作为 Agent 实现范式的广泛兼容能力。我一直坚持认为：

大模型与环境数据之间实现无限扩展的能力，才是 AI Agent 能够真正落地的关键所在。

从 Agent 开发的角度来看，当智能体与外部环境进行交互时，“环境数据”——也可理解为私有或本地数据——的处理最终仍归结为“上下文工程”的范畴。Anthropic 提出的 PTC 实质上也是围绕这一理念所做的优化与调整。

skills 功能的出现与误解

原本 skills 并不在本文讨论范围之内，但自 2025 年 10 月 16 日 Anthropic 正式发布 skills 功能以来，引发了诸多讨论：

https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

不少人认为 skills 是为了取代 MCP，理由在于它不再局限于提示词层面，而是引入了“代码执行”能力。即用户可以在特定的 skills 文件夹中预置并运行代码，从而完成过去需依赖 MCP 才能实现的任务。然而，我认为这是一种误读。如果你熟悉 Agent 的开发逻辑，尤其是从 Claude Code 的角度出发，就会发现实现相同功能的方式多种多样。本质上，这仍然属于提示词工程的延伸。例如，在我们的 AiPy CLI 中，无论是通过插件系统、角色设定，还是 API 描述，都可以引导模型完成指定功能的开发与调用。

在我看来，skills 更像是对 Claude Code 中 Custom slash commands 的一次进化升级。

https://code.claude.com/docs/en/slash-commands

今年 8 月初，在我们实现了 Python-use Function Calling（PFC）之后，注意到 slash-commands 使用的是 Markdown（md）格式来定义命令逻辑。实际上，选择 md 格式并非随意之举，我们在早期 AiPy 的实现过程中也曾对此做过深入探讨。直到看到 Anthropic 的设计后，才获得新的启发。随后，我们的开发成员章鱼英雄 lgx 再次出手，成功实现了 AiPy CLI 的 commands 功能：

https://github.com/knownsec/aipyapp/blob/main/dev/UserCommand.md

记得当时 lgx 完成功能开发后还略显兴奋地分享了他的成果：

我随即进行了体验，整体流程非常流畅，主要体现在以下两大特性上：

一、模板渲染：基于 Jinja2 模板引擎处理动态内容

支持 Jinja2 意味着可以在提示词中实现高度动态化的内容处理，使整个过程具备“可编程性”：

更重要的是，该机制还支持：

{%?include?"common.md"?%}

这意味着命令之间可以相互嵌套调用，并且能够访问 AiPy 内部的函数变量，例如：

Current LLM: {{ctx.tm.get_status().client}}

二、代码块执行：支持 Python 与 Bash/Shell 代码块运行（MAIN 模式）

这是我们另一个创新点：直接在 Markdown 文件中标识本地代码段并执行。

这是否让你联想到前文提到的 skills？没错，AiPy 在 8 月中旬就已经实现了代码执行功能，比 skills 的正式发布早了两个月。当然，这并不意味着领先多少，毕竟实现路径不同。但从设计上看，代码标记在 skills 中显得有些突兀；而 skills 本身作为一个文件夹结构，能够包含多种资源文件（包括代码文件），这种组织方式确实值得借鉴。

有兴趣测试的用户可以将以下目录：

https://github.com/knownsec/aipyapp/tree/main/examples/commands

复制到 ~/.aipyapp/commands/ 路径下。例如，将下面这个 system_info.md 示例代码保存至该目录：

---

name:?"sysinfo"

description:?"Display comprehensive system information"

modes: ["main"]

arguments:

? - name:?"--detail"

? ??type:?"flag"

? ??help:?"Show detailed information"

---

# System Information

重新进入 AiPy Cli 的主任务界面，只需输入 / 即可调用：

>>?/sysinfo?--detail

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓

┃ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??System?Information ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ┃

┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??Current?Configuration

?? Working Directory:?/Users/xxxx/aipython/aipyapp-0.4/aipyapp/work

???Current?LLM: trustoken/trust:auto

???Current?Role: aipy

?? Display Style: classic

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Detailed?System?Status

?##?System?Details

?-?Python Version:?3.13.0?(main, Oct?16?2024,?09:15:13) [Clang

?18.1.8?]

?-?Python Executable:?/Users/xxxx/aipython/aipyapp-0.4/aipyapp/.venv/bin/python3

?-?Platform: darwin

?-?Current?User: xxxx

?-?Current?Directory:?/Users/xxxx/aipython/aipyapp-0.4/aipyapp/work

?-?Home Directory:?/Users/xxxx

?## Task Statistics

?-?Total Tasks:?0

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Use?--detail flag for comprehensive system information

在功能实现上，存在一些细节差异。例如，在命令与技能（skills）对模型的支持方面，Claude Code 可以精确指定特定模型执行特定操作，因其无需兼容其他厂商的模型体系，架构更为专一。而 AiPy 支持多模型环境，难以针对某一厂商的特定模型进行强绑定，灵活性更高但定制化略显不足。

“大厂放个屁都是香的”——这句调侃揭示了头部企业在行业中的天然优势。这种品牌势能使得其任何动作都容易被放大关注。回顾 Python-use 范式（即 AiPy）自发布以来的发展历程，我们其实完成了诸多具有原创性的探索。甚至在时间线上，AiPy 的实践早于 Claude Code 的正式推出，率先落地了真正的 Vibe Coding 理念，并最早提出并实现了 Vibe Working 的工作模式。

然而，这些技术创新对于大多数用户而言属于“然并卵”——使用何种范式、依赖哪种技术并不重要，关键在于是否能够切实解决实际问题。令人遗憾的是，尽管 ChatGPT 引爆市场已逾三年，许多人的认知仍未完成转变。近日我在内部交流中再次分享了“黑哥尔的模型三大定律”，引发了广泛共鸣。

对于技术社区的开发者而言，建议更多关注技术或产品演进的完整脉络，理解其发展背景与设计动机，有助于深入掌握核心思想。当前仍有不少 Agent 开发者在“通用型”与“垂直型”之间徘徊不定，但实际上这一选择并非纯粹的技术问题，而是涉及产品定位、市场需求和场景适配等多维度的综合判断。理论上，通用型系统同样可以通过深度定制切入垂直领域。

更值得警惕的是一个正在浮现的现象：“当你拥有了超能力后，你根本不知道自己要做什么。” 当前许多 Agent 的应用场景仍停留在设想阶段，属于主观“脑补”的需求，真正具备长期价值且高频使用的场景依然稀缺。现阶段更应致力于拓展真实可用的应用边界，充分挖掘大模型在不同行业与情境下的潜力，唯有如此，才能最大化释放其能力，实现真正的智能解放。

此外，采用代码驱动（Code-use）范式还带来一系列附加优势。此前有群友提及一个类似项目 X-Master，其采用 CodeAct 方式实现 Deep Research 功能。通过 Agent 处理结构化数据，可在一定程度上减少模型幻觉的发生。例如，在测试随机数学乘法运算时，若让模型直接输出结果，极易出现错误且难以肉眼验证；而在 Code-use 模式下，该问题基本得以规避。同理，在搜索问答类任务中，Agent 的执行路径也更具可靠性。尽管如此，这种方式仍无法完全解决搜索引擎结果被 SEO 或 GEO 污染的问题。

SciMaster: Towards General-Purpose Scientific AI Agents, Part I. X-Master as Foundation: Can We Lead?on?Humanity's Last Exam?

https://arxiv.org/abs/2507.05241

后续我通过 AiPy 调用 Google 等平台的搜索 API 进行了一系列测试，包括复现 X-Master 所附带的部分案例，均取得了良好效果。

系统状态信息如下：

• Working Directory: {{ctx.tm.get_status().workdir}}
• Current LLM: {{ctx.tm.get_status().client}}
• Current Role: {{ctx.tm.get_status().role}}
• Display Style: {{ctx.tm.get_status().display}}

## Current Configuration

{%?if?detail %}

## Detailed System Status

````python

import?sys

import?os

from?pathlib?import?Path

# System information

print("## System Details")

print(f"- Python Version:?{sys.version}")

print(f"- Python Executable:?{sys.executable}")

print(f"- Platform:?{sys.platform}")

print(f"- Current User:?{os.getenv('USER',?'unknown')}")

# Directory information

cwd = Path.cwd()

print(f"- Current Directory:?{cwd}")

print(f"- Home Directory:?{Path.home()}")

# Task statistics

tasks = ctx.tm.get_tasks()

print(f"\n## Task Statistics")

print(f"- Total Tasks:?{len(tasks)}")

````

{% endif %}

---

*Use `--detail` flag?for?comprehensive system information*

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：EXECUTION code COD cut EXE