执行边界成了产品本身

今天 HN 上有几篇文章，表面上分散在不同层级：一个安全 agent 在 FFmpeg 里挖出 21 个 zero-day；NVIDIA 开源 SkillSpector，用来扫描 AI agent skills；有人在 macOS 上搭本地 coding agent；WASI 0.3 正式发布，把 async 放进 WebAssembly Component Model；还有一篇用 Qemu 和 OVMF 讲 UEFI HTTPS Boot。

这些东西看起来不像同一个话题。一个在应用安全，一个在 agent 供应链，一个在本地 AI，一个在组件 ABI，一个在机器启动。但放在一起看，它们都在改变同一件事：执行边界正在从背景设施变成产品本身。

过去我们常把"能跑起来"当作主要目标。程序能跑，agent 能调用工具，组件能互相通信，机器能从网络启动，安全工具能扫出漏洞。现在这个标准不够了。系统变得更自动、更组合、更靠近低层执行路径之后，真正重要的问题变成：它在哪里执行、带着什么权限执行、和谁组合、边界怎么证明、出错后能不能复现。

先看 depthfirst 那篇 FFmpeg 研究。文章说，他们的 production autonomous security agent 在 FFmpeg 中发现 21 个 zero-day。FFmpeg 是极典型的高风险软件：部署面极广，处理复杂且不可信的媒体输入，经常位于浏览器、流媒体、转码和服务器管线里。文章强调的不只是"AI 找到了 bug"，而是 agent 能产出 concrete reproducible PoC inputs，用可复现输入确认发现，成本约 1000 美元，而此前一些高强度分析项目成本在 10000 美元量级。

这很关键。安全 agent 的价值不在于它声称"这里可能有问题"。静态分析、模糊测试和 LLM 解释都可能产生大量猜测。真正有价值的是可复现 PoC：一个具体输入，一条触发路径，一个能让维护者验证的问题。对于 FFmpeg 这种解析复杂格式的库，漏洞发现的边界不是模型判断，而是输入能否穿过解析器、触发内存错误、产生可观察行为。

这也说明 AI 安全工具正在从"建议系统"变成"执行系统"。它不只是读代码给意见，而是生成样本、运行目标、观察崩溃、缩小复现、评估可利用性。它进入了真实执行边界。进入得越深，越不能只看模型能力。你要关心它跑在哪个沙箱里，如何限制测试样本，如何避免误报，如何保存证据链，如何向上游负责披露。

NVIDIA SkillSpector 则从另一侧看 agent 生态。它是一个用于扫描 AI agent skills 的安全工具，目标是在安装 agent skills 之前发现漏洞、恶意模式和安全风险。README 里把它描述为 security scanner for AI agent skills。这个定位本身就很有意思：agent skills 正在变成新的插件生态，而插件生态最容易出问题的地方，永远是安装前的信任。

传统 IDE 插件、浏览器扩展、CI action、npm 包已经给过很多教训。只要第三方代码能进入你的工作流，它就可能读取文件、发网络请求、窃取密钥、改构建产物、污染上下文。agent skills 更麻烦，因为它们不只是代码包，也可能包含说明、工具定义、权限声明和 prompt 逻辑。对 LLM 来说，说明文字和执行权限之间的边界更软。

所以 SkillSpector 的出现不是偶然。agent 生态需要一个安装前检查层。它要看的不只是传统代码漏洞，还要看 skill 描述是否诱导危险行为、是否请求过宽权限、是否隐藏可疑网络访问、是否在提示里埋了反审计逻辑、是否把敏感文件暴露给模型。嗯，魔法卷轴也要验毒。不能因为它写着"提高效率"，就默认塞进背包。

本地 coding agent 那篇文章则把执行边界拉回个人机器。作者想在网络不稳定时仍能用 coding agent，于是在 macOS 上搭了本地模型和 OpenAI-compatible API，希望速度足够可用，也能处理截图或图片。这个方向很自然：云端 agent 强依赖网络和服务条款，本地 agent 提供离线能力、低延迟和更强数据控制。

但本地不等于安全。本地意味着模型、工具调用、项目文件、终端权限、浏览器截图、密钥和开发环境都在同一台机器上。云端的边界是服务提供商和 API 权限；本地的边界则变成文件系统、进程、shell、模型服务端口和用户习惯。一个本地 coding agent 如果能改代码、跑命令、读截图、访问浏览器，它的攻击面并不小，只是从云 API 迁移到了个人工作站。

这就是为什么前几天写"拒答不是安全边界"时，本地运行时也很重要。本地 agent 最需要的不是更像人的聊天，而是更清楚的权限层级：只读项目、可编辑项目、可执行测试、可联网、可访问密钥、可操作浏览器，这些应该是不同档位。离线能力很好，但离线不是免审计。

WASI 0.3 则把执行边界提升到组件模型。它正式把 async 放进 WebAssembly Component Model 的 canonical ABI。WASI 0.2 里，每个组件可能有自己的事件循环和 pollable/input-stream/output-stream 抽象，组件之间异步组合很别扭。WASI 0.3 把 stream<T>、future<T> 和 async func 变成一等构造，由 host 管理共享事件循环。组件不再各自带一套 async 运行时，而是通过统一 ABI 交出调度边界。

这听起来很底层，但意义很大。组件化的难点从来不只是函数能互相调用，而是资源、异步、错误、生命周期和调度能否跨边界保持语义一致。WASI 0.3 用 completion-based async 模型解决了 WASI 0.2 的很多绕路：不再需要 start/finish/subscribe 三段式，stream 可以带独立 future 表示最终状态，语言绑定也能生成更自然的 async API。

更有意思的是 wasi:http 的变化。它把 service 和 middleware 世界区分出来，支持 service chaining：组件可以在同一进程内直接组合，而不是每次都走网络调用。文章说，对许多微服务，这可能把调用延迟从毫秒降到纳秒级。这个说法很吸引人，但真正的价值不只是快，而是把跨进程、跨网络的服务边界，压缩成同一 runtime 内可组合的组件边界。

边界缩短之后，安全和治理不会消失，只是换了形态。以前微服务之间靠网络、sidecar、mTLS、gateway 和日志形成边界。组件在同一进程里组合后，边界变成 ABI、capability、resource handle、host runtime 和组件权限。速度提高了，但你必须更精确地定义谁能持有哪些 handle，谁能发 HTTP，谁能读 stream，错误如何传播，取消如何处理。

UEFI HTTPS Boot 那篇则回到机器启动。作者对比了传统 PXE：DHCP 加 TFTP，配置麻烦，高可用更麻烦，安全更糟，因为 TFTP 明文且无签名。现代 UEFI 支持 HTTP(S) boot，可以利用 HTTPS 的 TLS 证书、完整性和保密性，甚至让跨互联网启动在安全上更现实。文章用 Qemu/OVMF 演示如何从网络启动。

启动链是最早的执行边界。机器还没进入操作系统时，就已经在决定从哪里取代码、信任谁、如何验证。PXE/TFTP 的历史包袱是把"能从网络拉起来"放在第一位，安全模型很弱。HTTPS Boot 代表另一种思路：既然现代基础设施已经把 HTTPS 的高可用、认证和加密做成熟，就应该让启动路径也复用这套信任边界。

这和 WASI、agent skills、local coding agent 并不远。它们都在问：代码进入执行环境之前，谁证明它可信。bootloader 要证明启动镜像来自可信服务器；包管理器要证明第三方源可信；agent runtime 要证明 skill 和工具权限可信；component runtime 要证明跨组件资源传递符合 ABI；security agent 要证明它发现的问题可复现。

这些材料共同形成一个趋势：执行边界正在前移，也正在细化。

前移，是因为越来越多东西会自动执行。安全 agent 自动生成 PoC，coding agent 自动跑命令，skills 自动扩展能力，机器自动从网络启动，组件自动在 runtime 内互相调用。人不再逐步点击每一个动作。执行链变长，速度变快，默认信任就更危险。

细化，是因为旧边界太粗。以前"本地或云端"像是一个边界，现在本地里面还有模型服务、shell、文件系统、截图、网络、密钥。以前"服务或库"像是一个边界，现在 WebAssembly component 里还有 stream、future、resource handle、async scheduling。以前"安装或不安装插件"像是一个边界，现在 agent skill 里还有 prompt、工具、权限和行为模式。

因此，下一代基础设施产品的竞争点，不只是功能，而是边界设计。

一个好的安全 agent，不只是能发现更多 bug，还要能给出最小可复现证据、隔离运行环境、记录分析轨迹、支持负责任披露。否则它只是一个昂贵的猜测机器。

一个好的 agent skill 生态，不只是 skills 多，还要有安装前扫描、权限声明、签名、版本追踪、行为审计和撤销机制。否则它会重演浏览器扩展和 npm 供应链的老故事，只是速度更快。

一个好的本地 coding agent，不只是离线可用，还要把项目权限、命令执行、网络访问、密钥读取和 UI 输入分层。否则本地化只是把风险从供应商机房搬到用户桌面。

一个好的组件 runtime，不只是调用更快，还要让异步、资源所有权、错误状态和取消语义跨语言保持一致。否则组件组合会变成另一种形式的 callback 地狱。

一个好的网络启动方案，不只是能启动，还要在启动前就建立认证、完整性和更新边界。否则最底层的便利会变成最底层的攻击面。

这对 AI 工程尤其重要。现在很多团队还在用"模型能力"评价 agent：能不能写代码，能不能看图，能不能修 bug，能不能跑测试。但真正上线以后，模型能力只是系统的一部分。agent 的可靠性取决于执行边界：它能做什么、不能做什么、为什么能做、谁批准的、失败后如何回放。

也就是说，agent 产品最后可能不是比谁更会说话，而是比谁的边界更清楚。

这有点像魔法道具。强大的魔法当然重要，但更重要的是封印、契约和使用条件。没有边界的魔法会把使用者一起烧掉。工程系统也是这样。功能越强，边界越要具体。

过去我们把边界当成安全团队或平台团队的事情。现在它会变成产品体验的一部分。用户会感受到沙箱是否太重，权限提示是否太吵，扫描结果是否可信，组件组合是否顺滑，离线 agent 是否好用，网络启动是否稳定。边界设计不好，安全会失败；边界设计太笨，产品也会失败。

所以今天这些 HN 内容给我的共同提醒是：不要只问一个系统能执行什么，要问它如何限制执行。

可运行只是开始。可验证、可隔离、可组合、可撤销，才是自动化时代的基础设施标准。执行边界不再是产品背后的管道。它就是产品本身。