播客·视频

OpenClaw 在同一组演讲里暴露了两个数字：安全报告量达到 curl 的 60 倍，skill 贡献里至少 20% 带恶意。我的判断很直接：这不是某个项目运维吃紧，而是“可组合代理平台”这条路线把插件时代的老问题放大了一个量级。普通开源库的风险多半停在代码执行、依赖污染、维护者权限。代理栈再往上叠一层 skill、工具调用、外部服务凭证、用户环境访问，攻击面天然更宽，回报也更高，所以恶意贡献比例冲到 20% 我一点不意外，反而觉得这个数字已经算克制。标题给了“史上增长最快的开源项目”，正文没披露 OpenClaw 的架构、发布时间、治理机制，这几个关键信息没给，增长叙事就站不稳。 我一直觉得，开源代理项目最容易被外界误判成“下一个 Linux 时刻”。其实吧，它更像 2000 年代浏览器插件商店加 2010 年代 npm 供应链事故，再叠一层会自己调用工具的执行权限。过去一年这个方向的信号已经很多了：MCP 生态刚起来时，大家先兴奋的是互通性，后面才开始补 prompt injection、tool poisoning、credential exfiltration 这些洞；开源 agent 框架一多，默认信任第三方工具描述、自动拉取 skill、把模型输出直接接执行器的做法就越来越常见。你把这些机制放在一个增长极快的项目里，安全团队收到 60 倍于 curl 的报告，并不说明 OpenClaw 比 curl “差”，说明两者根本不是一个风险层级。curl 处理的是协议与实现，OpenClaw 这类东西处理的是执行链、身份、外部状态，还有人类根本审不过来的社区扩展。 我对这条叙事里最警惕的一点，是公开舞台还在讲“开源奇迹”，工程侧已经在讲“扩展难题和事故洪峰”。这不是传播口径差异这么简单。项目如果真处在超高速增长期，最先被压垮的往往不是核心代码，而是治理接口：谁能发 skill，谁来审，撤回多快，权限模型默认给多少，签名和沙箱是不是强制，漏洞披露窗口多久，维护者是不是有能力做 provenance。标题和摘要都没给这些细节，我没法判断 OpenClaw 是靠制度扛，还是靠核心团队硬扛。如果是后者，那规模越大越危险。开源世界里“先增长、后治理”在包管理器时代都吃过亏，到了代理栈时代只会更疼，因为一次恶意 skill 不只是污染依赖，它能直接碰用户文件、浏览器会话、企业内网工具。 还有个上下文，文章里没展开，但从业者应该都懂：过去一年大家对 agent 的关注点，已经从模型能力慢慢转到 harness 和权限边界。Latent Space 这篇 AINews 同一期里就在讲，很多团队发现问题不在最大模型，而在脚手架、路由、上下文边界、工具接口。这个转向很关键。因为一旦价值主要来自 harness，开源社区就会把可复用 skill 和 tool adapter 当成增长引擎；可复用件越多，供应链就越脆。npm 当年是 install 阶段出事，代理栈是 run 阶段出事，后者的损失面通常更直接。 我还有个疑虑：60 倍、20% 这两个数字听起来很猛，但口径没交代清楚。安全报告是按总量算，还是按活跃用户、按提交量、按时间窗口归一？curl 作为对照也有点奇怪，它是成熟基础设施，不是高速扩展的 agent 平台，拿它做基线很抓眼球，但不一定最公平。恶意贡献 20% 是指被识别的提交、PR、skill 包、还是整套社区插件？如果只是“贡献尝试”里 20% 恶意，那含义和“已合入内容”差得非常大。这个我没查到，正文也没给，所以我不会顺着标题去夸大结论。 说真的，这条新闻让我更确信一件事：开源代理栈的分水岭不会先出在 benchmark，也不会先出在 demo，而会出在治理原语。谁先把 skill 签名、权限分级、沙箱执行、审计日志、可撤销分发、凭证最小化这些东西做成默认项，谁才配谈平台化。只靠社区热度和贡献速度往前冲，最后多半会把维护者变成 SOC 值班员。OpenClaw 现在像是把这个问题提前暴露了。坏消息是风险已经跑在前面。好消息是，至少工程侧有人开始公开讲真话。

GitHub 在 2026 年给开源仓库加上“可关闭 PR”选项，这不是 PR 已死，而是 GitHub 亲手承认：PR 不再适合所有代码生产流。我的判断很直接，这次变化首先服务的不是人类开发者，而是成批出现的 agent。人类提 PR，是把意图压缩成 diff 给另一个人看；agent 产出代码，问题反而变成你敢不敢执行、怎么隔离、能不能复现、谁来担责。协作单位一旦从“代码差异”变成“沙箱里的可审计运行”，PR 的中心地位就会松。

Gemma 4 首周拿下约 200 万次下载，这个数说明 Google 终于学会了怎么发开源模型。我的判断更直接：这次赢的先不是模型分，而是分发纪律。Hugging Face、vLLM、llama.cpp、Ollama、NVIDIA、MLX 一起到位，用户拿到权重后几乎不用等生态补票，这才把“发布日”变成“部署日”。Google 过去几次开源发布，模型常常不差，社区热度却掉得快，问题就在这里。 2 million 这个数好看，但别把它看得太满。文章自己给了对比：Gemma 3 一年 670 万，Gemma 2 从 2024 年 6 月到现在 140 万，Qwen 3.5 在约 1.5 个月里 2700 万。放进这个坐标系，Gemma 4 更像一次有效反弹，不是格局已定。Qwen 的量级高一个数量级，背后不是单次 launch 运气好，而是阿里把尺寸带、许可证、中文社区、蒸馏链路、推理框架适配一起铺开了。Google 现在补上了后半段，前半段的社区心智还没拿回来。 我对“下载量”这套叙事一直保留意见。Hugging Face download 不是活跃部署，也不是生产调用，更不是留存。一个团队拉了 4 个 quant、3 个 GGUF、2 个 safetensors，数字就会上去。文章没披露去重口径，也没给 API 调用、活跃项目数、微调 fork 数、企业采用数。所以 200 万更适合当分发热度指标，不够当市场份额指标。说实话，我有点烦现在很多开源发布都拿下载量直接替代使用量，这会把“会被试一下”误写成“会被长期用”。 我更在意的是那个 iPhone 17 Pro 跑 Gemma 4 E2B、MLX 下约 40 tok/s 的演示。这个数字要是条件属实，信号比下载量硬。原因很简单：本地可用性一旦跨过“能忍受”的门槛，用户会重写工具选择。40 tok/s 不只是 demo 顺滑，它已经够做轻 agent、检索问答、代码辅助、离线多模态助手。Apple 端这两年其实一直缺一个足够像样、又能被主流框架快速接住的开放模型。Llama 在本地生态里一直强，但 Meta 对多模态和小模型实用性的节奏并不总稳定；Mistral 的本地体验不错，分发声量没这么大；Qwen 本地化也很猛，但在 Apple 开发者心智里没形成压倒性默认项。Gemma 4 这次踩中的，就是这个空位。 这里还有一层经常被低估。Google 自家 Gemini 明明主打云端闭源订阅，却同时把 Gemma 往边缘和本地推，这看上去像左右手互打，我倒觉得这是现实主义。云端旗舰模型的毛利更高，没错；问题是 2026 年的开发者已经不再接受“所有 agent 都经 API 计费”这条默认路径。谁能把一部分工作负载拉回端侧，谁就能先占住开发入口。Meta 早就懂这个逻辑，所以 Llama 的意义从来不只是模型收入。Google 以前懂得不够坚决，这次算是补课。 我也得泼点冷水。文章里列了很多生态名字，正文却没给关键兼容细节。比如函数调用格式是否统一，视觉输入在各框架里的 preprocess 是否一致，量化后工具调用掉点多少，31B 在消费级 GPU 上的吞吐和显存门槛是多少，这些都没披露。Red Hat 提到量化版 Gemma 4 31B 有 NVFP4 和 FP8-block，推理跟随评测在线，reasoning 和 vision 评测待补。换句话说，今天能确认的是“跑起来了”，还不能确认“跑得稳、跑得值”。这两者差很远。 再补一个文章外的上下文。我印象里，过去一年开源模型的竞争早就不是谁单点榜单更高，而是谁能在发布当天让四类人都开工：本地玩家、推理服务商、企业私有化团队、做 agent 框架的人。Meta 在 Llama 3 那波靠的是品牌和先发。Qwen 3.5 靠的是极密集的型号覆盖和社区渗透。Gemma 4 这次第一次有点像样地进入这场比赛，但它还没证明自己会留下来。Google 历史问题不是做不出好模型，而是经常把开发者关系做成“发布会项目”。 所以我对这条的结论是：Gemma 4 不是 Google 开源翻身仗的终局，它只是第一次把模型、框架、端侧、云侧在同一周里接上了。要不要把它当成长期变量，不看下载总数，看两个更硬的后验数据：一是一个月后 llama.cpp、Ollama、vLLM 里的持续拉取和 issue 走势；二是端侧 demo 会不会变成真实产品，尤其是 iOS、Mac、本地 agent 工具链有没有开始默认支持 Gemma 4。要是只有首周热度，这条很快会掉回“Google 又发了个不错的开放模型”。要是端侧工作流真长出来，Gemma 4 才算把 Google 从发布者往平台方推了一步。

Andreessen 这次把 Pi/OpenClaw 定义成 5 个部件：LLM、shell、filesystem、markdown、cron loop；这比他那句“浏览器之死”更有含金量。标题把注意力拉去平台替代，正文能落地的其实是 agent runtime 的最小可行结构，而且这个结构确实足够具体，工程师能复现，能改，能迁移。 我对他这套说法的接受度，大概是 60 分。高的那 60 分给“文件即状态”。agent 把记忆、计划、工具输出都落到文件里，确实比把状态锁死在某家模型 API 或闭源 session 里靠谱。这个想法跟 Unix 那套“文本文件 + 小工具组合”有明显血缘，跟今天很多 agent 框架把状态藏在数据库、向量库、专有 tracing 平台里，方向也不一样。你要迁移模型，换 Anthropic、OpenAI、Qwen、DeepSeek，文件态资产理论上都能带走。这一点我认。过去一年，大家在 agent 上反复撞墙，很多时候不是模型不够强，是状态不可见、不可调、不可回放。把中间过程写回 markdown 和文件系统，至少给了调试面。 我不买账的地方也很明确。Andreessen把这套东西讲成“几十年来最大的架构突破之一”，这个调门有点过。LLM + shell + filesystem + 定时循环，工程上当然有用，但它离“新平台”还差两层：权限模型和失败恢复。文章提到 cron loop，没给隔离、回滚、审计、资源上限这些条件。只要 agent 能碰 shell 和文件系统，安全边界就不是附属问题，而是主问题。Anthropic 去年推 Computer Use 时，外界最关心的就不是它会不会点按钮，而是它会不会误点、会不会被 prompt injection 带偏。OpenAI 后来做 Operator 也是同一个坎：demo 很顺，进生产就卡在权限、观察、补救。Pi/OpenClaw 如果没有这一层，只能算很好用的黑客脚手架，不是成熟的软件架构。 “浏览器会死”这句更像风险投资叙事，不像产品判断。正文给了 76 分钟访谈、给了 5 个组件、给了 Unix 类比，但没给时间表，没给替代路径，也没给哪类任务先脱浏览器。这个缺口很大。浏览器今天承载的不只是渲染，而是身份、支付、权限、扩展、跨站协议、企业管理。你可以说 agent 会吞掉一部分交互层，我同意；你要说浏览器要死，至少得回答两件事：第一，agent 用什么通用容器接住网页级权限模型；第二，开发者为什么要放弃现成的 URL 分发和 view-source 式可检查性。文章正好提到他怀念 text protocols 和 human readability，我反而觉得这证明浏览器精神没死，只是界面会改。 外部参照也摆在这。过去一年，Manus、OpenAI Operator、Anthropic Computer Use、各种 Claude Code 式工作流，都在把“模型 + 工具 + 长时状态”推成主线。Andreessen没看错方向，他只是把已有趋势包装得更像平台宣言。另一边，浏览器厂自己也没站着挨打。Perplexity 的 Comet、The Browser Company 的 Dia、还有 Chrome 系里不断加的 AI 助手，本质上都是把 agent 往浏览器里塞，不是把浏览器扔掉。我自己更倾向一个难听但更现实的判断：先发生的不是 browser death，而是 browser colonization。agent 先寄生，再夺权，最后才谈替代。 还有一层背景不能忽略：a16z 刚募了 150 亿美元。这个时间点由 Andreessen 出来讲“this time is different”，我会天然多一分警惕。基金规模越大，越需要一个足够长、足够硬的平台叙事来承接部署周期、基础设施 capex 和应用估值。叙事不一定错，但它一定有资本结构上的动机。说实话，我对“旧 Nvidia 芯片会更值钱”“需求已在这里所以这轮不同”这些线也保留意见。2000 年光纤泡沫不是因为需求不存在，而是供给和兑现节奏错位。AI 现在也有同一类风险，只是买家从电信运营商换成了超大厂和模型公司。 我还是认可他点出来的一个硬问题：agent 的可移植性。谁能把 agent 的状态、工具调用、审计日志做成跨模型可迁移资产，谁就比只卖单次推理更接近软件层。标题里最响的是 browser death；我看下来更像 file-backed agents 在争夺新默认面板。这个方向我信，前提是有人把权限、安全、回放补齐。现在文章没给这些细节，我还没法把它从黑客范式升格成平台范式。