前面Anthropic连续发布了很多跟Agent技术相关的更新，在Nov 04, 2025发布了：
Code execution with MCP: Building more efficient agents https://www.anthropic.com/engineering/code-execution-with-mcp
随后在Nov 24, 2025发布的：
Introducing advanced tool use on the Claude Developer Platform https://www.anthropic.com/engineering/advanced-tool-use
文章里正式提出了"Programmatic Tool Calling" 这个概念，在"Code execution with MCP"发布后，引发了大量的关注及吹嘘。当然也有熟悉我们的朋友，知道我们做了AiPy是基于Python-use（Code-use）范式的Agent，所以当时就有很多个朋友看到Anthropic文章转发给我看，我在朋友圈也说了我看到"Code execution with MCP"第一感受就是：："anthropic自己说MCP是 '脱裤子放屁'了"。
我其实算是关注并实践并推荐MCP很早的一批人了，直到我们提出Python-use范式，在 《【Agents/MCP可能不存在了】No Agents, Just Python-use！》 文章里提到了"路线问题"，在我看来现在Anthropic提出的"Code execution with MCP"到"Programmatic Tool Calling"在某种角度上也算是一个路线的修正，当然他们这个修正的主要目的其实还是在于多MCP多工具后引起的上下文爆炸的问题，在这个角度上看这个属于"上下文工程"范畴，只是Anthropic的解决方案最终还是回归到"Code execution"上：
在Anthropic的路线：
MCP --> Code execution with MCP --> Programmatic Tool Calling看起来这个是Anthropic自我进化（修正）的路线，有完整的逻辑及因果关联，但是如果你脱离这个Anthropic路线逻辑本身来看，在从MCP这个路线设计之初就决定了他这个路线的是曲折、"臃肿"的。
而Python-use的范式就显得直接明了，更符合第一性原理。
（所以为什么我一直喜欢这个用户评价）
在Anthropic在提出Programmatic Tool Calling时候提到的挑战：
提到的分析10M日志的场景，而这个场景其实就是我们AiPy诞生初衷，详见"英雄LGX拯救AI章鱼的故事"：
【Agents/MCP可能不存在了】No Agents, Just Python-use！
这种本地数据分析处理的场景也是AiPy最早备受推荐的场景之一，当然这个可能大家更多的是认为这个是本地环境导致的，而Manus那种云端受限于环境是没办法处理的，而现在Anthropic有推出Claude Code后（AiPy的出现是在Claude Code发布之前）开始关注这种本地诉求，而导致出现的上下文爆炸的事情，所以这个也是"Code execution"带来的好处之一。
这其实是个"路线问题"，这是Python-use（Code-use）范式与Anthropic的路线在诞生之初就决定了的... 看起来都有着他们的逻辑自洽性。
CodeAct
在我们提出Python-use范式后，10月份有朋友在我《【Agents/MCP可能不存在了】No Agents, Just Python-use！》 文章里留言提到CodeAct这个项目：
CodeAct的论文：
Executable Code Actions Elicit Better LLM Agents https://arxiv.org/html/2402.01030v4https://github.com/xingyaoww/code-act后面我回溯了下，我们留意到CodeAct应该是在今年4月份（AiPy是在3月开始的），说实话当时没有太大的共鸣，因为那时候在AiPy的推广初期，我把关注点放在了"No Agents/No Tools"上了，但是CodeAct使用的还是多Tools模式（Funciton），随着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下的仍然是依靠大模型直接去调用实现部署注册好的Function。具体放在插件部分调用了（注意这个部分目前CUI是不支持的），具体工具的实现代码，你可以在/plugins/目录下找到，你也可以自己注册开发对应的工具。
这个时候我重新找并阅读了CodeAct的项目的论文及代码，从论文来看CodeAct强调并解决的是"Code as Actions"这个跟我们Python-use范式提出的"Code is Agent"完全是一致的，这个其实也是这个论文的核心观点："代码就是标准，代码就是行动"，论文明确对比传统的JSON/Text的方式有明显的优势：
从上面我们提到了与我们最早Python-use范式最大的区别点在于："No Agents/No Tools"，所以CodeAct是通过事先编写注册对应的功能函数来实现Tools，其实这个是最早OpenAI的Function Calling --> MCP --> PTC(Programmatic Tool Calling) 都是事先由开发者写好对应的功能函数后交给LLM调用，但是这个调用方式有一个区别：
Function Calling --> MCP --> PTC 使用的JSON去实现Calling，而CodeAct及Python-use是直接LLM直接生成并调用对应函数的代码。
所以在这个角度上看Programmatic Tool Calling最终回归到了CodeAct，唯一的区别在于Anthropic还在使用MCP路线遗留的JSON。
https://www.anthropic.com/engineering/advanced-tool-use这个问题其实在本质上还是上面提到的「可靠性 与 创造性」的问题，显然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对象（现在代码可能有变化）在某个角度也就是Packages Calling，比如runtime.install_packages()用来安装包，在我们的早期版本的系统提示词里可以看到这些包函数的调用说明：
全局 `runtime` 对象
`runtime` 对象提供一些协助代码完成任务的方法。
......
`runtime.install_packages` 方法
功能: 申请安装完成任务必需的额外模块
参数: 一个或多个 PyPi 包名，如：'httpx', 'requests>=2.25'
返回值: True 表示成功，False 表示失败
示例如下：
```python
if runtime.install_packages('httpx', 'requests>=2.25'):
import datasets
```
......
而"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 Packages Calling，这只是这个来强调我们Python-use作为一个Agent实现范式的兼容性，而我一直认为：大模型与环境数据的无限扩展能力才是AI Agent真正落地的关键
从Agent开发角度，当Agent与环境交互中的"环境数据"（可以理解为"私有数据"），最后落地其实还是在于"上下文工程"上，Anthropic的PTC其实从这个角度上看也还是围绕"上下文工程"去做的修正！
skills
这个本应该不属于今天文章的范畴的，只是在2025年10月16 Anthropic发布skills
https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills后，很多人觉得这个是Anthropic是用来取代MCP，因为skills 不在是纯粹的提示词，而是加入了"code execution"，也就是在对应的skills文件夹里可以包含预设的代码并执行，在某种角度上看用户可以通过Claude Code直接通过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 使用的是md，实际上对这个md选择还是很有讲究的，我们之前在AiPy的实现里纠结过很久，当看到slash-commands后，还是很受启发的，于是我们的章鱼英雄lgx再次出手，实现了AiPy Cli的commands 功能
https://github.com/knownsec/aipyapp/blob/main/dev/UserCommand.md我记得当时lgx在实现AiPy cli的自定义命令功能后，小激动了一把：
随即我体验了一把，非常丝滑，最大的两个特点：
一、模板渲染: 使用 Jinja2 模板引擎处理动态内容
支持Jinja2意味着可以各种动态处理提示词中的各种内容实现"可编程"
最重要的还支持
{% include "common.md" %}这意味着可以相互命令可以相互嵌套调用，而且还支持AiPy内部函数变量的调用：
Current LLM: {{ctx.tm.get_status().client}}二、代码块执行: 支持 Python、Bash/Shell 代码块执行（MAIN 模式）
这个可以算是又一个我们创新的方式，直接在md里支持本地代码标记并执行
这是不是让你想起了上面提到的skills，是的没错AiPy在8月中旬就已经实现了对代码执行的支持（比skills早2个月），当然这个并不能说明什么，代码标记实际上在skills的设计中显得有的突兀的，当然skill本事是个文件夹，支持各种资源文件包括代码文件，这一点确实是值得学习的
具体测试大家可以把
https://github.com/knownsec/aipyapp/tree/main/examples/commandscommands目录 cp 到~/.aipyapp/commands/
比如下面的 system_info.md 代码，然后保存到~/.aipyapp/commands/下
---name: "sysinfo"description: "Display comprehensive system information"modes: ["main"]arguments: - name: "--detail" type: "flag" help: "Show detailed information"---
# System Information
## Current Configuration- **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}}
{% if detail %}## Detailed System Status
````pythonimport sysimport osfrom pathlib import Path
# System informationprint("## 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 informationcwd = Path.cwd()print(f"- Current Directory: {cwd}")print(f"- Home Directory: {Path.home()}")
# Task statisticstasks = ctx.tm.get_tasks()print(f"\n## Task Statistics")print(f"- Total Tasks: {len(tasks)}")````{% endif %}
---*Use `--detail` flag for comprehensive 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本身不需要对其他家的模型做兼容，所以它可以很好的指定对应的模型去做对应的命令或者skills，而AiPy是多模型支持的，不是很方便去指定对应哪家的哪个模型。
"大厂放个屁都是香的"
这个是大厂的先天优势，所以只有"羡慕嫉妒恨"的份，回想一下Python-use范式（AiPy）发布后到现在，其实我自认为我们还是做了很多独创性的工作的，甚至我们AiPy都比Claude Code发布还早，更早的实践了真正的Vibe Coding 最早的提出并实现Vibe Working ... 当然这些都是"然并卵"的事情，对于用户来说你用什么范式，用什么技术其实都不重要，重要的是你能真正解决问题 ...
只是可惜的是具体ChatGPT大火已经三年了，很多的的意识却还没有转变，今天我又在我们VIP群里发了"黑哥尔的模型三大定律"，引起共鸣。
对于技术社区的朋友，其实我是比较建议去关注并了解下某个技术或者产品的更新发展的脉络，这样能更好的理解来龙去脉。另外现在还有Agent开发者在纠结通用还是垂直，这个在之前的文章里我也提过这个实际上不是技术问题，而是产品定位及市场定位等综合问题，理论上通用类型的也可以做垂直定制深挖。
而且我注意到现在还有一个更可悲的事实："当你拥有了超能力后，你根本不知道自己要做什么" ，其实很多Agent的场景很多是脑补出来的需求，然后即使是常用的真正有价值场景可能还非常有限，而现在更需要扩展更多的场景，充分发挥大模型的在这种不通领域不同场景中的价值，这种才能最大程度的释放大模型的能力，解放大模型。
其他
实际上通过Code的方式，其实还有很多其他的优势，比如前面在一个群里有群友提到另外一个与AiPy类似的项目：X-Master
论文：
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
X-Master其实是CodeAct的方式去实现了Deep Research，实际上通过Agent的方式来处理格式化完成的数据是回减少很多幻觉的，比如之前测试数学随机乘法让模型直接出结果很可能出现幻觉而且可能还没办法肉眼验证是不是正确，而换在Code-use范式的场景这个问题就不存在了，而在通过搜索来找问题答案场景，这个也是一样的通过Agent的方式可能更加，当然这个不能解决SEO/GEO被污染的问题。后面我通过AiPy调用Google等搜索API 然后做了一部分的测试包括X-Master带的一些测试都是没有问题的：
