今天是2025年最后一天，从3月基于Python-use（Code-use）范式的AiPy项目开始，到年底逐步看到了很多大厂或者大佬的一些理念认知逐渐的趋同，这说明我们的Python-use范式的理念及AI Agent应用方向的理解还算是比较先进、深入的。这些我在之前的文章都有详细的介绍，而且很多点都是反复的说，当然很多细节点可能需要真正去实践才有可能“感同身受”，可惜的是缺少点“大厂”的光环 ...
在MCP到PTC Anthropic回归Code Execution路线，AiPy的范式被再次验证" data-itemshowtype="0" linktype="text" data-linktype="2">《从MCP到PTC Anthropic回归Code Execution路线，AiPy的范式被再次验证》发布之后，我看到了来自Anthropic的两位Skills提出者的的演讲视频：
Don't Build Agents, Build Skills Instead – Barry Zhang & Mahesh Murag, Anthropic
https://www.youtube.com/watch?v=CEvIs9y1uog
在这个演讲里他们提出了一个核心观点：
"The future of AI isn't more agents—it's one universal agent powered by a library of domain-specific skills."
也就是说：“AI 的未来，不是更大的 Agent，而是 一个通用 Agent + 无数可复用的技能模块。”
在他们的演讲里明确提到的标题："Code is all you need" 、 "Code is the universal interface"，包括他们对Claude Code定位（不再局限在IDE），到“可扩展（scalable）”、“API调用” 、“环境”等概念的理解，基本上都可以在我以往的介绍Python-use的相关文章里见到。
尤其是最开始的《【Agents/MCP可能不存在了】No Agents, Just Python-use！》明确了"No Agents, Code is Agent/No Agents, Just Python-use！"的核心观点，这个内容其实我在之前发过朋友圈并同步到一些AI相关的群里，其实我也知道反复去讲这些必然会引起一些人的不适，比如最早我们提出的"No Agents、No MCP、No Workflow、No Clients ..." 其实在我们内部也有很多不一样的看法意见，尤其是MCP我们AiPy实际上也是支持MCP的，包括我们的AiPy Pro的智能体也是兼容MCP的，这个都是基于“产品”维度选择，这些都可以理解，所以我在以往的文章里说：大家都被MCP绑架了～～
而我这里其实是基于“范式”的角度去探讨的，基于“范式”那肯定是要看整体上的，而不是具体一个词、一个概念。当时有人就说了你这个Code use的方式人家很早就有了，包括CodeAct（CodeAct的相关 我已经在《从MCP到PTC Anthropic回归Code Execution路线，AiPy的范式被再次验证》进行探讨），可能还有人会提到通过Code来完成任务的模式很早有模型厂商或者Agent用过了，实际上我在《【Agents/MCP可能不存在了】No Agents, Just Python-use！》就提到GPT-4o的方式，至于其他Agent他们都是把Code当成了几个Agents中的一个Agent去调用，包括Manus 这些其实都是相对片面的视角。我们看一个“范式”需要更加完整的视角去看!
至于skills除了我在《从MCP到PTC Anthropic回归Code Execution路线，AiPy的范式被再次验证》提到的"code execution"部分之外，真正提到的“技能”这个最早是AiPy里我们称为“最佳实践”：
当然他还拥有任务理解规划、代码最佳实践方案、记忆管理注意力调整、任务反思反馈的能力，甚至我们认为通过Python Use这种范式，可以让各种AI章鱼和谐统一的为人类工作（类“MOE”模式），甚至可以让AI章鱼的自我进化，不只是手和脚，可以促进眼睛、鼻子、嘴巴等多模态能力的进化！最终实现AGI，这才是真正的“智能体”
heige，公众号：黑哥虾撩【Agents/MCP可能不存在了】No Agents, Just Python-use！
# 任务最佳实践- 分析本地浏览器数据画像：直接使用读取本地浏览器数据库- 图片OCR提取文字及对应坐标方案：paddleocr 或 easyocr- 图片中图标标记并定位： openvc- claude调用：anthropic包- 天气查询：request + 高德API或中国天气网 ，当用户没有指定地理位置时，请调用高德API进行定位- 股票查询：yfinance- 网页访问：playwright 具体方案参考 "playwright方案规则"- 浏览器访问网页：browser-use LLM使用openai gpt4o ，具体方案参考 “browser-use方案规则”- 数据可视化图表：matplotlib 注意中文字体选择：'windows': ['Microsoft YaHei', 'SimHei'],'darwin': ['Kai', 'Hei'],'linux': ['Noto Sans CJK SC', 'WenQuanYi Micro Hei', 'Source Han Sans SC']- 视频处理：ffmpeg-python- 网络搜索：request + Tavily API，并触发网页访问阅读相关网页内容- 反爬访问：playwright 或 browser-use- 验证码、发帖、发微博：browser-use- 图片生成或修改：request +Google Gemini API 注意LLM模型使用 gemini-2.0-flash-exp-image-generation - 华为鸿蒙手机USB控制命令： • 截屏：hdc shell uitest screenCap -p /data/local/tmp/screen.png • 回到屏幕首页：hdc shell uitest uiInput keyEvent Home • 返回：hdc shell uitest uiInput keyEvent Back • 向下滑动：hdc shell uitest uiInput dircFling 3 10000 • 向上滑动：hdc shell uitest uiInput dircFling 2 10000 • 左滑：hdc shell uitest uiInput dircFling 0 1500 • 右滑：hdc shell uitest uiInput dircFling 1 1500 • 输入框：hdc shell uitest uiInput inputText x y hello • 模拟点击：hdc shell uitest uiInput click x y- 打开手机对应app 先通过OCR识别【应用名称】文字坐标 → 向上偏移【120】像素获取图标中心 → 用【HSV色彩空间】验证图标主色调 → 最终点击坐标修正【±5】像素容差- 拨打电话：（注意需要在终端显示标记的图片） 通过USB连接了我的鸿蒙手机，请通过hdc shell进行管理，回到手机屏幕首页，但后找到手机按钮坐标，模拟点击手机按钮进入拨号键面，最后通过hdc shell uitest uiInput click x y 方式依次点击对应坐标拨打用户输入的电话号码，注意在电话号码输入完整后再点击拨号按键。
上面这个是我早期AiPy里的提示词，根据不通任务去选择对应的Python Packages或者 命令工具及代码调用 模型调用方式等，这个最早是放在AiPy系统提示词里，这导致的如果场景越多最终你的这个内容越多，占用的tokens会越到，注意力也可能不够集中，所以后面我们把这部分进行拆分和优化，一部分我们分化出了“角色”这个概念，用户可以通过不通“角色”来定一个这个“最佳实践”，当然后面我们“命令”也是可以做这部分工作，而另外一部分我们通过API Calling来实现云端智能选择，也就是你的任务提示词提交给大模型之前，会通过API Calling得方式去请求我们云端的“小模型”，做提示词优化，而这个“小模型”的目的就是根据你的任务选择并生成“最佳实践”。
实际上在我的视角，如果你认识到了"No Agents, Code is Agent"，这些“最佳实践”就是“自然而然”，“水到渠成”的事情，这个是Python-use范式的先天优势，这段时间Skills火了后，我看到一些有意识的评论，比如：
响马这个看法不就是“No Workflow”嘛，其实在我上面给出最佳实践里：
- 华为鸿蒙手机USB控制命令： • 截屏：hdc shell uitest screenCap -p /data/local/tmp/screen.png • 回到屏幕首页：hdc shell uitest uiInput keyEvent Home • 返回：hdc shell uitest uiInput keyEvent Back • 向下滑动：hdc shell uitest uiInput dircFling 3 10000 • 向上滑动：hdc shell uitest uiInput dircFling 2 10000 • 左滑：hdc shell uitest uiInput dircFling 0 1500 • 右滑：hdc shell uitest uiInput dircFling 1 1500 • 输入框：hdc shell uitest uiInput inputText x y hello • 模拟点击：hdc shell uitest uiInput click x y- 打开手机对应app 先通过OCR识别【应用名称】文字坐标 → 向上偏移【120】像素获取图标中心 → 用【HSV色彩空间】验证图标主色调 → 最终点击坐标修正【±5】像素容差- 拨打电话：（注意需要在终端显示标记的图片） 通过USB连接了我的鸿蒙手机，请通过hdc shell进行管理，回到手机屏幕首页，但后找到手机按钮坐标，模拟点击手机按钮进入拨号键面，最后通过hdc shell uitest uiInput click x y 方式依次点击对应坐标拨打用户输入的电话号码，注意在电话号码输入完整后再点击拨号按键。
就有点“Workflow”的味道？！这个是2025年4月份通过AiPy尝试phone use控制纯血鸿蒙系统成功拨号的效果：
而在2025年12月在豆包手机短暂火一把之后 智谱开源的
github.com/zai-org/Open-AutoGLM
方式其实跟我当时使用的方式是一样的，只是我当时识别图片坐标的是Claude模型，当时缺少针对性的手机GUI训练的模型，效果还是非常不稳定。
在某种角度这也说明了：“模型越强，AiPy就越强的”，这个是由于Python-use范式里“Freedom AI”解放大模型最好的诠释！
在AI Agent领域，基础模型是至关重要的，这个为什么Manus大火后很多人觉得效果有很大一部分是Claude模型的功劳，而被Manus很多人藐视仅仅是“套壳”而已，并且在manuse之后大部分的Agent的创业产品都选择使用Claude等国外闭源一线模型，实际上我们的AiPy一直都是使用的国产模型，而这些包括“技能”支持的效果，实际上是非常考验模型能力的，这个也是为什么早期Skills只在Claude Code上表现好，而在其他模型上表现效果可能没有那么好也有一定相关性，万幸的是2025年国产模型发力，逐步缩小不少差距！有兴趣的可以看看AiPy以往的模型测评结果：https://www.aipyaipy.com/ （点击“测评报告”）
Andrej Karpathy - 2025 LLM Year in Review
在聊完Skiils两位缔造者的演讲后，我们再看看我们的“老朋友”Andrej Karpathy发布的2025的总结：
https://karpathy.bearblog.dev/year-in-review-2025/
Andrej Karpathy在吹火Vibe Coding后，后面他的推特基本上都会被热捧，在Vibe Coding之后他又提出了"Context Engineering"，所以在前面他写的《2025 LLM Year in Review》总结里对这些都有覆盖，他这个总结有6点，用notebooklm总结了下面三个方面：
当然我这里主要是一下交互相关的也就是Karpathy总结了的后4点，对应Vibe Coding我之前写过一篇专文《从 Vibe Coding 到 Vibe Working》 实际上我也算是最早实践者之一，而且还是在Vibe Coding这个概念提出之前，可以参考《0基础到纯血鸿蒙APP开发实践》
当然我这里其实是想强调下相比Vibe Coding，Vibe Working这个词更符合Python-use范式。
然后就是 "3. Cursor / new layer of LLM apps" Cursor是一只都有推荐的并不是2025年菜火，我觉得Karpathy之所以2025年的总结里提出是为了说明："Context Engineering"，在目前的AI Agent的领域我觉得"Context Engineering"核心中的核心，很多的问题其实就是围绕"Context"展开的，在这里我需要说明下的是我认为的"Context Engineering"是不只是与LLM对话的上下文，而是与“环境”交互的所有内容，包括了对话过程、记忆、技能（最佳实践）、APIkey（认证凭证）及API或者其他工具说明等等
其实我在《Code是AI的手：姚顺雨访谈与Python-Use范式的对话》一文中有说明：
在这个理解层面，Cursor在代码角度确实是做的比较好的，当然我在《Code是AI的手：姚顺雨访谈与Python-Use范式的对话》已经说明过了：
实际上Anthropic提出的包括MCP、PTC、Skills甚至包括SubAgent这些都是围绕"Context Engineering"而探索的结果，我在下面这个经典的图上做个标识可能更好理解：
当然Karpathy原文里还提到了Cursor在2025年终于意识到他不只是个IDE这些问题，这个我在之前那些文章也有提到当时被IDE局限的问题，当然在上面提到的Skills两位也开始意识到Claude Code的定位问题，都是一样的...
“4. Claude Code / AI that lives on your computer”
其实我看到Karpathy的文章的时候，我第一反应就是这个第4点应该是AiPy啊，又是“羡慕嫉妒恨”大厂的时候：
这个完完全全就是AiPy的描叙，AiPy的推出比Claude Code要早，在范式角度实际上强调了本地环境的重要性和扩展性，这个理念我在《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》一文做了详细的阐述，包括我最早看到MCP的优势其实，也是在于本地环境的交互上，当然可能是这篇文章写了大量的案例导致可能关注度（阅读量）少了点。
比较有意思的Karpathy还吐槽了Codex最开始的路走错了：
“I think OpenAI got this wrong because they focused their early codex / agent efforts on cloud deployments in containers orchestrated from ChatGPT instead of simply localhost. ”
这个跟我在《从 Vibe Coding 到 Vibe Working》也提到了类似问题，当然最早在《【Agents/MCP可能不存在了】No Agents, Just Python-use！》提到了“AI章鱼关了起来，并对它的触手安装了巨大的枷锁”很大部分就是这个环境交互的问题，这个其实也包括Manus这种云端的模式，所以我在祝福Manus被Meta收购成功上岸的同时，是不看好这种模式的，因为这种模式最终模型厂商都会内化
“6. Nano banana / LLM GUI”
当然这个点入选一点也不意外，Google的Gemini3和香蕉模型的成功，到现在估计仍然还是“奥特曼”的噩梦，即使是“边角料”应用的NotebookLM因为香蕉模型的加持，直接改写了那些PPT agent进程历史，在我个人看来NotebookLM的信息图及ppt生成，真正做到了可实际应用的阶段，在我的心里是可以Cursor时刻相媲美，当然还有很多细节值得优化，可惜看起来Google对NotebookLM的重视程度在我看来远远不够 ...
有点跑偏了，在本文这个背景下其实应该关注的是LLM GUI，因为在AI Agent的领域里Agent 2.0还有一个拼图就是LLM GUI，对操作系统、APP等的GUI的理解，实际上到现在Python-use的范式，对于GUI的控制是非常有限的，主要依赖API服务的能力，在上文提到的phone use的尝试就是这样，当然在后续有对应的模型出现，比如智谱AutoGLM-Phone-9B等模型，会通过API Calling实现MOE方式完全是可以兼容的，只是这个依赖模型厂商提供的模型能力。
小结
2025年最后一天，在2025年Python-use范式的诞生，有幸看到了很多的理念与大佬的理解认识趋同的地方，当然不管是什么样的范式和技术路线，最终的效果可能都是一样的！最后我也想表达一下对于Python-use范式的核心关键在于：Code就是标准协议、与环境交互接口。有着天然的完整性和扩展性。
最后提一下Manus被收购的这个事情，其实我在很多次都提到Manus与Cursor是AI Agent领域创业非常值得学习研究的对象，因为他们打破了“大厂”的魔咒，Manus的成功上岸，取决于他们的运作及产品本身，在当时那个时间节点Manus的产品有它的亮点和优势，然后可能是结合他们在Web3领域的项目运营经验，能一举突破，都是值得研究的。而且有个既定的事实：实际上到目前为止很多人可能都不知道Cursor是什么，Manus又是什么？知道的可能也有很多人并没有用过Manus ...
至于Meta收购Manus妄想继续WhatsApp类似的收购案例的复刻，我估计不太可能，现在其实这种云端的Agent更多的依赖模型，而Meta目前看上去在基础大模型上已经掉队很久了，当然Meta不差钱，后面还能不能力挽狂澜，还得看基础大模型，单凭个Manus很难！！！ 当然这种其实可能都是小波浪，因为在现在LLM模式下还没有看到一个符合现在LLM模式的商业基础模式，现在还在技术变革的阶段，就像豆包手机那样，可能就是一个小插曲！
祝大家在2026年66大顺～～
