Simon Willison 引述 Jeremy Morrell，但安全的 AI 扩展不止需要一个沙箱

Simon Willison 在 2026 年 8 月 19 日指出了一个具体矛盾：LLM 让软件扩展更容易编写，但其生成的代码仍难以令人信任。

这一观点来自 Jeremy Morrell。他认为，Web 应用可以将可问责的核心与用户编写的扩展结合起来。大语言模型将生成这些扩展，而浏览器沙箱则会限制生成代码可访问的范围。

这一模式挑战了两种熟悉的做法。传统应用提供由开发者选定的固定功能。通用 AI 智能体则获得广泛访问权限，并尝试代表用户操作现有界面。

Morrell 提出了第三条路径。应用保留其可靠的中心，用户则可在遇到能力缺口时描述所需功能。LLM 提供受限代码，而不是控制整个产品。

这一提议听起来很简单，因为浏览器已经具备隔离机制。然而，代码生成与安全执行只解决了问题的一部分。产品还必须控制权限、数据流动、更新、问责机制，以及扩展行为异常时的恢复方案。

因此，真正的竞争并非固定软件与无限定制之间的对抗，而是可问责的可扩展性与不受限制的 AI 自主性之间的较量。

Simon Willison 将可扩展软件重新带回议程

重要事件并非一次产品发布，而是为 AI 软件提出了一个更鲜明的架构假设。

在其 8 月 19 日的文章中，Simon Willison 引述了 Morrell 关于可扩展 Web 软件新机遇的观点。该文章将这一理念归入沙箱化、LLMs、AI 和生成式 AI 标签之下。

Morrell 的假设结合了两项经常被分开讨论的变化。LLM 降低了生成少量应用代码所需的成本。现代 Web 平台则提供了原语，可限制这些代码的运行位置及其可执行的操作。

任何一项变化都不能消除软件工程的必要性。不过，两者结合后，会改变仅服务于一个人或一个团队的功能的经济性。

传统产品团队必须评估需求、设计交互、实施功能、测试、编写文档并持续维护。对于广泛共享的功能，这一流程是合理的。但对于仅由少数人使用的狭窄工作流，它往往难以适用。

LLM 可以将具体需求转化为代码，无需等待该功能进入公开路线图。生成的扩展可能用于转换文档、添加自定义可视化、验证表单，或连接两个获准的数据源。

这并不意味着生成的代码必然正确，但确实大幅降低了尝试首次实现的成本。

Morrell 论述的另一半涉及部署。历史上，安装第三方扩展通常意味着信任一个软件包、授予广泛权限，或在具有高权限的应用进程中运行代码。

浏览器提供了不同的基础。沙箱化框架会创建独立的浏览上下文，除非宿主明确恢复相关能力，否则这些能力将被禁用。

可用的控制措施是具体的，而非象征性的。宿主可以限制脚本、表单、弹窗、下载、存储访问和顶层导航，也可以对摄像头、麦克风等功能施加 Permissions Policy。

这些控制措施使建立有意义的安全边界成为可能，但并不会自动为每个扩展形成正确的边界。

Morrell 所说的“坚实、可问责的核心”是这一提议的决定性部分。宿主应用将继续负责身份、持久数据、授权、审计历史和关键操作。

生成的扩展将在核心周边填补局部缺口。它们不会悄然取代原有安全模型，也不会成为权威记录。

这一区别将可扩展软件与通用编程聊天机器人区分开来。聊天机器人可以生成一个文件，然后把安全运行它的责任留给用户。可扩展应用则可以定义生成代码的运行位置、它获得哪些接口，以及如何审查其行为。

它也将这一理念与普通插件商店区分开来。传统插件通常面向大量用户编写、作为产品打包，并通过审查流程分发。LLM 生成的扩展则可以针对单一工作流，同时仍在受控运行时内运行。

这一事件之所以重要，是因为 Willison 的文章为该架构提供了简洁的公开框架。其主张并非 AI 应重构每一个界面，而是 AI 可以让经过审慎限制的定制变得经济可行。

这比“智能体将取代应用”更为克制，也更容易验证。

压力落在固定 SaaS 产品与广泛授权的 AI 智能体身上

产品如今面临的压力是：既要提供定制能力，又不能放弃对用户数据和核心工作流的控制。

固定软件通过预测共性需求来运作。其设计者在客户遇到各自的边缘案例前，就决定了可用的对象、命令、视图、集成和自动化规则。

这一模式带来了统一性，也形成了长期积压的需求：它们过于具体，难以证明值得进行共享开发。

企业客户会通过电子表格、脚本、浏览器扩展、集成平台和手动流程来弥补这些缺口。每一种变通方案都会增加一个逻辑可能过时或变得不可见的位置。

可扩展软件将这些逻辑移至更靠近掌握相关数据的应用之处。生成的扩展可使用宿主定义的狭窄接口，而无需抓取屏幕或将记录复制到其他地方。

设想一位项目经理希望根据几个不寻常的元数据字段建立审查面板。由于只有少数客户需要该面板，产品可能永远不会提供这一精确功能。

一个扩展可以请求获准的记录，计算所需分组，并渲染临时视图。核心应用仍将继续执行用户可读取哪些记录的权限控制。

研究人员可能需要一个用于重复文档格式的一次性提取器。工程师可能需要一个适配私有部署约定的仪表板。销售团队可能希望设置一条与自身客户流程相关的验证规则。

这些需求对多数路线图而言太小，却又因重复性而不适合手工处理。它们构成了 Morrell 假设背后的经济机遇。

Geoffrey Litt 在其早期关于可塑软件的研究中描述过相关愿景。Litt 认为，LLM 可以在用户已经理解的计算环境中充当本地开发者。

这一历史参照之所以重要，是因为终端用户编程并非新事物。电子表格、宏、HyperCard、浏览器脚本和可视化自动化工具，都曾让人们能够修改自己的工作环境。

长期存在的瓶颈不只是语法。用户需要将非正式目标转化为可执行逻辑，理解可用接口，并调试结果。

LLM 压缩了这一转化过程的部分环节。用户可以用领域语言描述期望结果，检查拟议扩展，并通过示例对其进行修改。

扩展仍然需要稳定的底层基础。没有定义清晰的对象和能力，模型就必须猜测应用如何运行。这会产生脆弱代码，并助长屏幕自动化。

这促使 SaaS 厂商提供更小、更安全的构建模块。一个仅为人类点击而设计的产品，能为 LLM 提供的可靠扩展方式更少。

同样的压力也适用于广泛授权的 AI 智能体。一个可访问电子邮件、文件、浏览会话和内部工具的智能体可以完成多种工作，但这种访问也会扩大错误指令造成的后果。

受限扩展采取相反的方法。它只获得完成单项任务所需的最低能力，周围的应用则调解敏感操作。

代价是自主性降低。狭窄的扩展无法跨越所有服务即兴操作，也无法检索任意数据。这种限制是其目的，而非缺陷。

对于采购方而言，问题将比产品是否“具备 AI”更具体。他们可以询问，用户能否在不授予模型无限制访问权限的情况下创建本地能力。

他们还可以审视生成的行为是否保持可见。发生错误后，隐藏的智能体计划难以审计；已安装的扩展则可以公开其代码、声明的权限、输入、输出和修订历史。

固定应用不会在这一模式下消失。共享功能仍需要专业设计、无障碍工作、性能测试、支持和长期维护。

可能出现的压力在于这些功能的边界。将每个工作流都保持封闭的厂商，必须与允许用户安全完成最后一公里的产品竞争。

团队还需要更好的方法来保留自定义行为背后的上下文。一个可搜索的工程知识库可以记录扩展为何存在、它基于哪些假设，以及由谁负责。

当生成的扩展从单个用户扩散到整个部门时，这些记录将变得至关重要。低成本创建并不能消除机构记忆的成本。

沙箱降低部署成本，而非问责成本

沙箱可以约束代码执行，但产品仍必须设计跨越边界的每一条有意义路径。

浏览器沙箱并非一道单一的保护墙，而是一组覆盖源、脚本、导航、存储、设备能力以及与宿主通信的限制措施。

iframe 上的 sandbox 属性以限制性姿态开始。随后，应用可以通过显式令牌恢复选定能力。

这是一种能力模型，即代码获得特定权限，而不是继承宿主拥有的全部特权。宿主可以允许渲染和计算，同时拒绝下载、顶层导航或同源存储。

浏览器文档也指出了一种危险组合：在某些条件下，一个被授予脚本和同源权限的同源框架，可以移除自身的沙箱属性。

这一警告说明了更大的规则。只有当其配置、源设计和周边接口维持预期隔离时，沙箱才依然有用。

从独立源提供扩展代码，可以在代码变得恶意时减少损害。它也会根据浏览器的同源策略，阻止代码直接访问宿主页面的文档对象模型。

通信可以通过 postMessage 进行，它允许窗口跨源交换结构化消息。宿主仍必须验证发送者、消息类型、载荷以及请求的操作。

不安全的消息桥接可能会抵消审慎配置的 iframe。如果生成的代码可以向毫无审查的宿主发送“删除所有记录”，那么阻止直接访问数据库也难以令人安心。

更好的设计是暴露狭窄的动词。扩展可能会请求 readSelectedDocuments、renderChart 或 proposeMetadataUpdate，并接受授权和验证。

敏感变更应通过可问责的核心执行。该核心可以检查当前用户、当前记录版本、允许的字段集合，以及适用的组织政策。

它也可以要求确认。读取用于图表的已批准值，与将这些值发送到外部服务器是两回事。

内容安全策略又增加了一层防护。内容策略允许网站限制脚本、图像、框架、样式和网络请求可从哪些来源加载。

对于生成式扩展而言，网络控制与代码执行同样重要。一个看似无害的小部件，如果能够将应用内容传输到任意域名，就可能成为数据外泄通道。

严格的策略可以阻止大多数出站连接。主机随后可以通过一项施加身份验证、速率限制、日志记录和目标地址规则的服务，代理经批准的请求。

WebAssembly 为受限计算提供了另一种可能的运行时环境。其安全模型描述了在沙箱环境中执行，以及通过嵌入方提供的显式 API 进行访问。

WebAssembly 并不决定产品权限。它提供了一种更底层的执行格式；当与精心设计的主机配合使用时，可以支持隔离。

有些扩展根本不需要任意代码。产品可以让 LLM 生成一份声明式规范，描述字段、筛选条件、布局、计算和允许的操作。

应用随后使用可信组件解释该规范。这种方法限制了表达能力，但使行为更容易检查和验证。

其他任务则需要真正的代码。数据转换、自定义可视化和专门解析通常超出固定模式的限制。

成熟的平台可能支持多个执行层级。简单扩展使用声明式规则；更复杂的扩展则在更严格的审查和更窄的权限下运行 JavaScript 或 WebAssembly。

主机必须在每个层级都将模型输出视为不可信。自然语言意图并不能保证生成的代码实现了相同意图。

模型可能误解字段、颠倒条件、遗漏边缘情况，或依赖未记录的行为。它也可能复现从公开代码中学到的不安全模式。

提示词注入带来了另一种风险。处理文档或网页的扩展可能遇到旨在改变模型行为的文本。

OWASP 的提示词注入指南解释了为何模型指令与外部数据并不总能被清晰分离。仅靠过滤无法消除这个问题。

因此，运行时应假设生成的逻辑可能出错，即使不存在攻击者也是如此。权限限制后果，而测试和预览有助于发现错误。

一个有用的创建流程应在安装前展示所请求的行为、生成的实现、声明的输入、权限和示例输出。

扩展首次运行时应接收测试夹具，而非生产数据。用户可以比较预期行为与实际行为，而不会冒不可逆变更的风险。

对于写入操作，主机可以呈现差异对比。扩展提出变更建议，核心只有在验证或确认后才会应用它们。

回滚同样重要。如果扩展按照错误规则正确地更新了大量记录，沙箱在技术上虽已成功，用户却依然遭受了损失。

一个可问责的平台需要不可变历史记录或补偿操作。它应能识别每项变更由哪个扩展版本引起，以及由谁批准执行。

这正是 Morrell 所说的“可问责核心”比“现代沙箱原语”更重要的地方。沙箱化降低了实现隔离的基础设施成本。问责则需要产品设计、治理和运营纪律。

生成的扩展必须从属于这些系统。否则，平台只是把广泛的 AI 行动权迁移到了一个更小的窗口中。

缺失的一层：面向一次性代码的治理

廉价代码生成会带来维护问题，因为有用的扩展很少会一直是一次性的。

用户可能为一次会议生成一个一次性工具，然后再也不打开它。这是最简单的情况，因为扩展的价值与风险会一同结束。

成功的扩展则不同。同事会复制它们，工作流开始依赖它们，临时假设逐渐成为非正式基础设施。

到了这一步，作者身份就变得复杂。用户提供意图，模型提供了大部分实现，而主机提供接口和运行时控制。

平台仍然需要一个责任主体。必须有人决定，在应用数据、政策或 API 发生变化后，该扩展是否仍然有效。

生成代码的替换成本或许很低，但围绕它的工作流未必如此。团队可能依赖某份报告来做出运营或财务决策。

可问责核心应根据影响范围和后果对扩展进行分类。个人只读视图应采用比拥有写入权限的全组织自动化更轻量的流程。

推广可以触发更强的控制措施。共享扩展可能需要自动化测试、明确的负责人、权限审查和到期日期。

更广泛的部署可能需要管理员或应用负责人批准。审查应聚焦能力和数据流，而不只是源代码。

仅靠代码审查并不足够，因为生成的代码可能频繁变化。审查者需要稳定的说明，明确扩展读取、发送、修改和保留哪些内容。

这些说明应当被强制执行，而不是仅作装饰。如果扩展声明它读取选定记录，运行时就应阻止它访问无关记录。

版本控制同样重要。根据用户请求重新生成扩展会产生新行为，即使其可见名称保持不变。

平台应保留每个版本、其生成请求、模型配置、权限、测试和审批状态。现有用户不应收到静默变更。

模型更新又引入了另一层不确定性。提供商更换模型后，同一条指令可能生成不同的代码。

可复现性可能要求存储生成产物，而不是每次运行时重新生成。该产物可以在执行前接受测试和签名。

依赖项带来相关风险。允许生成代码导入任意软件包会扩大可信边界，并使长期运行更复杂。

受限的标准库灵活性较低，却更可靠。主机可以为图表、解析、日期、存储和用户交互提供经过审查的组件。

扩展可以组合这些组件，而无需下载新代码。当出现漏洞时，平台可以集中更新共享组件。

用户体验同样需要边界。要求人们批准一长串技术权限，只会导致习惯性点击，而非知情同意。

权限请求应使用任务语言描述后果。“将选定文档发送到 api.example.com”比笼统的网络访问提示更有用。

默认设置应偏向只读行为、有限范围和临时授权。持久访问应需要与重复性工作流相关的理由。

因此，对 Morrell 假设最有力的反对并不是沙箱化会失败，而是吸引人的演示在治理开始之前就结束了。

生成的小部件在一次提示后就可能看起来很成功。可靠的扩展系统必须经受共享使用、政策变化、恶意输入、模型变化和人员流动。

这项工作可能超过最初编写代码的成本。应用运行在浏览器中也不会让它消失。

还存在产品设计风险。无止境的定制会让应用更难理解、支持和一致地使用。

两位同事可能在看似相同的产品中看到不同的命令、字段和计算方式。支持团队可能难以复现问题。

组织可能通过标准化成功扩展来应对。平台可以观察反复出现的本地需求，并将成熟方案提升为受支持的功能。

这会形成一个有益的反馈循环。用户探索长尾需求，而供应商识别值得永久设计和维护的模式。

模型并不会在这个循环中取代产品团队。它帮助用户为未被满足的需求制作原型证据。

始终保持狭窄范围的扩展可以留在本地。变得重要的扩展则可以经过更严格的审查，并最终进入核心。

这比将每个生成产物都视为一次性产品或生产就绪产品更具问责性。它承认，随着人们开始依赖软件，软件的状态也会改变。

尚未解决的问题是：供应商是否会在用户创建失控的影子生态系统之前构建这一生命周期。LLM 已经让代码生成变得足够容易，足以超越治理的速度。

Simon Willison 的读者接下来应关注什么

当产品提供受约束的扩展系统，而普通用户无需授予广泛的代理访问权限即可操作时，这一假设将更具可信度。

第一个信号是真正为生成式扩展设计的权限模型。关注那些提供细粒度能力、分离执行源、出站网络控制和可读权限清单的产品。

有说服力的实现会让拒绝成为默认选项。扩展应只获得实现其声明目的所需的数据和操作。

最有力的证据将来自能够安全处理写入权限的系统。预览、差异对比、确认、审计记录和回滚应协同工作，而非作为彼此独立的选项出现。

如果供应商推出这些控制措施，Morrell 的可问责核心模型就会得到实质性加强。如果扩展经常需要广泛令牌或完整页面访问权限，该模型就会被削弱。

第二个信号是平台如何管理扩展在首次成功运行后的状态。创建演示很常见，但生命周期证据仍然更有价值。

关注版本固定、自动化测试、所有权、到期机制、依赖控制，以及从个人使用到团队使用的推广路径。

平台还应展示其 API 变更后会发生什么。扩展需要兼容性契约或明确的失败提示，而不是悄无声息地给出错误结果。

成功的生命周期管理将证明，低成本创作不会产生无法管理的软件债务。频繁故障则会强化怀疑论观点。

第三个信号是用户行为。该理论取决于人们是否会创建具体工具，而这些工具能否比通用代理或外部变通方案更安全、更有用。

有价值的指标包括扩展复用率、权限拒绝次数、回滚频率、修复时间，以及创建内容中成为重复性工作流的比例。

这些数据应谨慎解读。高创建数量可能表明实验、困惑或新鲜感，而非持久价值。

更有说明力的结果是，用户是否在不增加安全事件或支持负担的情况下，解决了此前被忽视的任务。

研究人员和企业采购方还应关注扩展的运行位置。浏览器隔离很有吸引力，但某些工作负载需要本地文件、私有服务或密集计算。

平台可能使用远程容器、边缘隔离环境、WebAssembly 运行时，或这些系统的组合。每一种选择都会改变延迟、成本、数据暴露和运营责任。

浏览器依然很有价值，因为它已经承担了来源、权限和用户交互的中介角色。安全团队也普遍熟悉其控制机制。

但没有任何运行时能够从生成的代码中推断出正确的业务授权。宿主必须从其可信核心提供这项策略。

对开发者而言，实际问题并非 LLM 能否编写扩展。它们已经足够频繁地生成有用代码，使这一设计空间值得认真探讨。

问题在于，应用能否让失败变得寻常且可恢复。糟糕的输出应当受到约束、清晰可见、可以撤销，并且替换成本低廉。

对企业采购方而言，应要求供应商演示一个恶意或错误的扩展，而不只是展示成功案例。观察它能够访问哪些数据，以及宿主拒绝执行哪些操作。

对知识工作者而言，应寻找在聊天结束后依然易于理解的定制功能。你应当能够检查工具的行为、修改它、禁用它，并识别其产生的影响。

Simon Willison 的引述之所以重要，是因为它将 AI 生成的代码定位为一个组件，而非整个产品。正是这种克制的表述赋予了这一理念可信度。

Morrell 的假设并不要求每位用户都成为软件工程师。它要求应用提供安全的构件，让 LLM 能够在用户指导下进行组合。

机会确实存在，但胜出的产品不会是生成代码最多的那个，而是让生成行为能够被追责的那个。

在评估下一款可扩展 AI 产品时，先请求一项范围狭窄的定制，然后刻意向它提供误导性输入。你能否看到它的权限、检查其拟议变更，并撤销结果？

这些问题比精致的生成演示更能说明问题。它们检验的是，产品是否建立了 Morrell 所描述的坚实核心。

继续关注 Simon Willison 对具体实现的报道，但也应以同样的标准评估每一个系统。它只是运行 AI 编写的代码，还是让这些代码在整个有效生命周期内都可被治理？