LLM时代的可扩展软件

# 大语言模型时代的可扩展软件 | Jeremy Morrell 来源：https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/ 我们今天接触到的大多数网络软件都是静态的。开发者的的时间和注意力有限，他们会专注于为最大用户群体构建功能。需求曲线的顶端已被现有软件充分满足，但还存在一条因用户而异的未满足需求的长尾。 （图表：映射用户需求的长尾分布，从常见的导航问题到小众的历史查询 (https://x.com/tophtucker/status/1280992756278714373) ） 即使开发者极有动力去堆砌所有功能，用户界面在变得无法使用之前，其复杂程度也是有限的。（https://newsletter.getprimitive.ai/p/when-to-design-for-emergence） 每增加一个额外功能，都会使产品对其他所有用户变得更复杂。如果该功能的市场需求很小，它实际上可能会让所有不需要该功能的用户体验变差。在这种背景下，大语言模型辅助编码的兴起，确实赋予了所有那些有需求落入长尾范围的人力量。 ## 软件变得……软了 （https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#software-has-gotten-all-squishy） 显然，大语言模型非常擅长构建 **面向单人的软件 (Software for One)** (https://www.ajwaxman.com/writing/software-for-one)。这些个人应用绕过了企业软件的所有复杂性和责任，专为个人工作流定制。 Y Combinator 的 Pete Koomen (https://koomen.dev/) 认为，他们称之为 **小型软件 (Small Software)** (https://x.com/ycombinator/status/2079963726435021232) 的领域存在机会。我觉得他们说到点子上了。 [](https://x.com/ycombinator) https://x.com/ycombinator/status/2079963726435021232 > 智能体使您可以轻松为自己或团队构建个人工具。但部署、保护和共享这些软件，远比创建它要复杂得多。一个为小型软件构建的云平台可以消除这种复杂性，使定制工具像共享一份 Google 文档一样简单。 > 2026年7月22日 **Pi** (https://pi.dev/) 是一个很好的例子，我开始将其视为 **大语言模型原生软件**：一个经过实战检验的核心，但几乎可以无限扩展，只需通过对话请求，用户就能将自己的定制化成果与他人共享。 **在过去的一年里，你的用户突然获得了用语言“说”出代码的能力。** 大多数现有软件无法利用这一点。而 Pi 拥抱了它。 （梗图。用户说“添加我的自定义功能”。电脑：“功能已添加。”用户说“不错”） 我怀疑我们将开始看到更多遵循这种自我扩展模式的软件。然而，我们现有的可插拔软件大多是本地软件：AI 智能体、开发者 IDE、视频游戏模组、Blender 插件、CAD 扩展。这些通常是专业工具，入门门槛很高。 **网络是世界上最成功的软件分发系统。** 它不应被落下。我的假设是，**网络上的可扩展软件存在一个新机遇**。大语言模型极大地降低了编写扩展的成本，现代沙箱原语降低了部署成本并提供了良好的安全边界。我们可以将我们的应用构建为一个可靠、可负责的核心，并通过让大语言模型填补缺失的部分，允许用户安全地向多个方向扩展它。 **我们可以赋予用户超能力。** *披露：我目前就职于 Cloudflare，在这里大量接触 Kenton Varda (https://x.com/kentonvarda) 的文章，塑造了我大部分的思考。在文末，我将论证 **Dynamic Workers** (https://developers.cloudflare.com/dynamic-workers/) 为何特别适合这种模式，但在此之前我会先介绍几种替代方案。* ## 这会是什么样子？ （https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#what-would-this-look-like） 当今许多网络系统依赖 webhook 来让用户对应用中的变更做出反应。这**勉强能用**，但它为扩展设定了非常高的门槛：需要构建和维护一个完全独立的服务，并处理可能出现的投递问题。 我希望能够在记录更新时接入，插入我自己的逻辑。“当我为记录附加这个标签时，运行我的函数”。“每天按计划为我执行这个操作”。 实际上，我完全不想考虑这些。我想告诉我的“稍后阅读”应用： - 请将我收藏的每篇超过4000字的文章发送到我的`` - 每周查找发表在``上的新论文，在顶部添加你关于其与我工作关系的摘要，并标记为`` - 默认算法完全搞乱了``。提取几个样本，为它制作一个自定义解析器。 然后，机器人会挤出那些笨拙的代码片段，将它们钩入某些扩展点，并让这成为可能。我也应该能够与任何其他可能也需要相同功能的人分享我所做的东西。¹ (https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#user-content-fn-participation-inequality) 这里还有一些我希望看到采用大语言模型原生扩展方式的领域。 #### AI 智能体 （https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#ai-agents） 好吧，这是显而易见的一个。[pi](https://pi.dev/)、[deepseek](https://www.deepseek.com/harness/en/) 和 [opencode](https://x.com/thdxr/status/2087945880863191162) 都在这个领域进行实验。 与其将每个新想法添加到其核心，Pi 为工具、命令、事件和 UI 提供了稳定的钩子，因此它可以将请求转换成一个小的 TypeScript 扩展并原地重新加载。这些扩展随后可以被打包成可共享的软件包，让生态系统吸收长尾的想法，而不会使容器本身变得臃肿。 *（来自 deepseek 视频的截图。智能体容器内的一个卡通鲸鱼和一个贪吃蛇游戏）* Deepseek 通过演示用户仅通过提示就在 UI 中添加了一个鲸鱼伙伴和一个贪吃蛇游戏，展示了其容器的可扩展性。 然而，这些工具的受众，至少就目前而言，相当小。你必须乐于在本地机器上运行自定义软件。在企业环境中，**组织**必须乐于让你运行那些从未有人看过、也永远没人会去看的软件。除非你自己为 Pi 设置沙箱，否则 Pi 扩展运行时的权限与 Pi 本身相同。软件工程师会找到办法，但会计师、医生、律师以及成千上万的其他职业也值得拥有更好的工具。他们需要能够安全且轻松地根据自己的领域和工作流进行定制的智能体。如果我们希望更多人使用智能体，那不意味着让他们成为软件开发人员，而是意味着让软件适应他们的需求。 #### 企业内部平台 （https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#internal-corporate-platform） 所有公司最终都会拥有海量数据。员工需要查看数据、查询数据、调查数据、将此系统的数据与其他系统关联、查找遇到``的客户、查找即将流失的客户，以及无数其他事项。 许多公司正在尝试允许 AI 爱好者员工使用“氛围编程”构建自己的工具，也许部署到某个 PaaS。这个方向是对的，但产生了很多后续问题。一旦你有了数百或数千个这样的应用，你如何维护它们？它们如何访问所需的数据？如何让它们**只访问所需的数据**？我们如何审计这些软件在做什么？如果我们依赖访问令牌，它们的范围是什么？谁来轮换它们？如何确保我们不会将客户信息记录到第三方？如何确保我们不会违反 GDPR？或者真实企业需要担心的无数其他合规性和安全问题。 如果我们给它们一个部署代码的地方，在那里没有可以泄露的认证令牌？数据访问由一个内部平台团队处理，他们可以确保所有合规性框都被勾选？给它们构建自己自动化或自定义视图的空间，但是安全地。² (https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#user-content-fn-vibe-coding-platforms) *剧透：这基本上就是 [Cloudflare OS](https://github.com/cloudflare/cloudflare-os)。* #### 支持平台 （https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#support-platform） *（支持页面原型图，包含自定义部分）* 我职业生涯中花了很长时间处理棘手的支持工单。不可避免地，我最终需要在仪表盘中挖掘、搜索日志、从无数不同的地方拉取数据。 让我创建扩展，将来自我特定系统的、与提交工单用户相关的数据呈现到支持界面中。给我钩子，这样我甚至在查看工单之前，就可以启动智能体为我进行第一轮调查。如果有像“重置特定配额 X”这样的常见任务，让我在我的视图中添加一个可以执行该操作的按钮。然后也让我与团队分享这些，这样我们就可以互相帮助。 #### 可观测性平台 （https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#observability-platform） *（来自 deepseek 视频的截图。智能体容器内的一个卡通鲸鱼和一个贪吃蛇游戏）* 每个可观测性工具（Many Observability tools）已经趋同于相同的功能集：一个带有顶部小柱状图的日志搜索栏。用于查看单个追踪的瀑布视图。可自定义的指标仪表盘。也许还有一个服务地图。少数工具正在尝试新的可视化方式 (https://embrace.io/)，尤其是随着智能体的兴起 (https://www.honeycomb.io/blog/agent-timeline-flight-recorder-for-your-ai-agents)。 经典的追踪瀑布图对于请求/响应形态的系统非常有用，这些系统主要关心延迟和成功率。我们许多人发现自己拥有的系统有点更……有状态化……或动态化。现代应用正在运行非确定性智能体或持久工作流引擎，其中单个操作可能需要数小时或数天。追踪 span 是一个很好的事实来源，可以在此基础上构建，但让我尝试我自己的可视化方式（或安装别人的）。³ (https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#user-content-fn-frontend-sandboxing) 除了我可以查看的漂亮界面，让我注入我自己的逻辑： - 数据摄入时的任意转换 - 让警报触发我自己的脚本：确定性代码或我自己的智能体 - 给我选项在风险最高的时候运行我自己的代码：部署或功能标志发布 - 如果我的日志中有一个特殊的`MyResourceID`，让我把它变成一个链接，直接跳到另一个平台上的该资源。 [](https://x.com/bentlegen) https://x.com/bentlegen/status/2087948548155297894 > 所有软件可能都应该看起来像这样。 [](https://x.com/thdxr) https://x.com/thdxr/status/2087945880863191162 > 我们在 opencode2 中做出的一个架构性改变是，几乎所有东西都是内部插件。有 68 个插件覆盖了我们内置的智能体、集成、配置加载等。这意味着你可以禁用任何行为，我们也正确地“吃自己的狗粮”，使用自己的插件 API。 *（opencode2 插件目录截图，包含 commands、providers、skills、system prompts 和 web search 等文件夹）* https://x.com/thdxr/status/2087945880863191162 2026年8月13日 ## 网络上的可扩展软件更……难 （https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#extensible-software-on-the-web-is-harder） 我刚刚把这一切都说得很简单。事实并非如此。我是 Obsidian 的忠实粉丝，无论是作为我每天使用的工具，还是作为一款软件。它看起来像一个基本的 Markdown 编辑器，但只需点击几下，你就可以扩展它来做几乎所有事情：在看板中跟踪你的任务 (https://publish.obsidian.md/kanban/Obsidian+Kanban+Plugin) 或者将你的笔记变成数据库 (https://github.com/blacksmithgu/obsidian-dataview)。想把所有笔记塞进向量数据库进行语义搜索？尽管去做 (https://motherduck.com/blog/obsidian-rag-duckdb-motherduck/)！如果你想更进一步，底层的 web UI 原语很容易被黑客修改。 然而，这种强大能力是有代价的：Obsidian 的扩展模型要求你信任你安装的每一个插件。一个插件基本上可以做任何事情 (https://cyber.netsecops.io/articles/obsidian-plugin-abused-in-campaign-to-deploy-phantom-pulse-rat/)。Obsidian 通过自动化和手动审查 (https://obsidian.md/blog/future-of-plugins/) 以及验证插件作者来应对这一安全挑战。对于笔记应用来说，这可能是正确的权衡。它有效是因为风险较低，且社区相对较小。但这种模式一旦你想在持有他人数据（客户记录、金融交易、私信）的软件中实现同等水平的可扩展性时，就会崩溃。 可扩展性和网络服务一直是个挑战。执行任意代码充满了安全和滥用挑战。不完整列表如下： - 用户代码中的错误或无限循环绝不应导致你的服务宕机 - 拥有访问密钥权限的客户扩展可以将它们转发给第三方 - 同样，如果你暴露了敏感数据，确保它无法被渗出 - 确保这个系统不能被滥用进行拒绝服务攻击 - 确保用户不会意外地对你进行拒绝服务攻击 - 防范 Spectre (https://meltdownattack.com/) 攻击 - 如果人们可以用你的钱免费算力挖矿，他们会的 - 以及更多... ## 但肯定有人做过了？ （https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/#but-surely-someone-has-done-this） 在我们认定这不可行之前，有一个明显的例子表明这种网络上的可扩展性已经在巨大的规模上实现了：Salesforce。 *（有人在 Salesforce 办公楼外拍照。广告牌上有一堆卡通吉祥物，写着 "Engie is a Trailblazer"）* 是的，就是 Salesforce。 而且他们从 2007 年就开始这么做了 (https://www.eweek.com/enterprise-apps/salesforce-com-issues-summer-07-release-apex-code/)。（作为参考，AWS S3 和 EC2 是在 2006 年推出的 (https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Services)。） *（Salesforce 营销幻灯片，展示其所有产品。有 Slack。Customer 360。不知为何有 MCP。由于云已经过时，现在经常使用 "agent" 一词）* 如果你在试图理解 Salesforce 做什么时感到困惑，情有可原。 问大多数技术人员 Salesforce 是什么，你可能会得到茫然的眼神，或者类似“他们不是做 CRM 的吗？”的回应。然而，将 Salesforce 描述为一个庞大的、多租户的、可编程的平台更为准确。在早期的云时代，这显得格格不入：没有容器，强迫人们使用一种奇怪的、类似 Java 的自定义语言 Apex (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm)。然而，随着无服务器计算的兴起，这个平台开始看起来熟悉多了。考虑一些例子： 如果我需要暴露一个自定义端点，我可以用几行代码完成。平台处理路由、认证、租户隔离、执行。没有 web 服务器需要部署。 眯着眼看，你可以认为它是现代无服务器计算的前身 (https://developers.cloudflare.com/workers/examples/return-json/)。 ``` apex @RestResource(urlMapping='/customer-health') ```