大模型时代，软件如何真正“可扩展”？

在软件工程领域，“可扩展性”一直是一个核心追求。然而，随着大语言模型（LLM）的崛起，我们过去对“扩展”的理解正受到前所未有的挑战。传统的扩展手段——无论是插件系统、精心设计的API，还是旨在标准化AI交互的模型上下文协议（MCP）——似乎都未能完全抓住LLM带来的范式转变。本文旨在探讨：在LLM时代，真正“可扩展”的软件应该是什么样子？

传统扩展方式的局限性

首先，我们需要理解为何现有方案显得力不从心。

插件系统：允许用户或第三方添加新功能，但本质上是在预定义的“插槽”里放入具体实现。这更像是“功能的扩展”，而非“能力的涌现”。它要求开发者在最初就设计好扩展点，缺乏应对完全未知需求的灵活性。
API与SDK：通过暴露一组标准化的操作来让外部系统与之交互。这种方式在确定性工作流中非常高效，但它本质上是“命令式”的——调用者需要知道要调用哪个具体接口来完成某个具体任务。对于模糊的、高层的目标（例如“帮我优化这个项目的代码”），API显得过于僵硬。
模型上下文协议（MCP）：作为一种新兴标准，MCP旨在为LLM提供统一的上下文访问方式，使其能与各类工具和数据源交互。这无疑是巨大的进步，但它主要解决了LLM“如何看”和“如何用”的问题，仍未解决软件系统“如何被扩展”以更好地理解和执行复杂、开放的任务。

这些方案的共同点在于，它们将软件视为一个功能的集合，扩展即是增加新的功能模块。但在LLM时代，软件的核心价值可能需要从“提供功能”转向“达成意图”。

核心挑战：从“功能”到“意图”的范式转移

LLM的核心能力是理解自然语言描述的高层意图，并规划、生成解决方案。当这样的“大脑”被嵌入软件系统时，系统扩展的挑战就变成了：如何让系统理解并承载不断演进的用户意图，而不仅仅是执行预设的指令？

想象一下，你不再是对一个编辑器说“加粗选中文字”，而是对它说：“把这份报告的结论部分变得更醒目一些，用符合我们公司品牌风格的方式。” 这背后需要的是一个系统能够理解“醒目”、“公司品牌风格”等抽象概念，并将其转化为一系列具体的文档操作。

一条可行的路径：意图抽象与领域模型

文章作者提出的设计理念，我认为极具启发性。其核心是两层结构：

意图抽象层（Intent Abstraction Layer）：这是一个薄层，其职责是将用户输入（无论是通过聊天框、API调用还是其他方式）解析为结构化的“意图表示”。这个表示不应是具体的函数调用，而是一个描述“做什么”和“为什么”的数据对象。例如， { "goal": "summarize_report", "focus": "conclusions", "style": "brand_guidelines" }。
丰富的领域模型（Rich Domain Model）：这是系统的“肌肉”。它包含了一系列领域特定的概念、规则和能力。当意图抽象层传入一个意图后，领域的“调度器”或“执行引擎”会负责将意图分解、映射到领域模型中的具体操作序列上。这个过程可能由LLM辅助完成，也可能基于精心设计的规则引擎。

这个设计的美妙之处在于：

扩展即扩展领域模型：要支持新功能，不再仅仅是添加一个新的插件或API端点，而是向领域模型中注入新的概念、关系和行为规则。这使得系统能以更有机的方式成长。
解耦意图与执行：用户关注意图，系统负责如何用已有的领域能力去满足意图。这允许系统在不改变意图层的情况下，优化底层实现。
LLM成为“粘合剂”与“推理器”：LLM可以自然地用于意图解析（将自然语言转为结构化意图），也可以在领域模型执行过程中，处理那些需要常识推理或灵活映射的部分。

这种思路在一些前沿的开发范式中已有雏形，例如文档驱动开发（SDD），它也强调在编码前构建一个丰富的、可执行的领域知识层。而LLM的加入，让这个知识层变得更加动态和易于交互。

与更宏观的AI发展叙事的共鸣

这种设计哲学也与当前对AI应用路径的务实思考相契合。与其盲目追求一个全知全能的通用人工智能（AGI）来解决一切，不如像“超级能力而非超级智能”的观点所主张的那样，专注于让AI在特定领域、针对特定意图展现出超人般的可靠性。上述架构，正是为实现这种“领域超级能力”提供了软件层面的蓝图。

从软件设计的历史回望，这种“意图-能力”的分层也似曾相识。还记得早期CD-ROM容量有限时，《雷神之锤》如何精妙地“装不下”又装下了吗？那时的挑战是物理限制下的创意扩展。而今天，我们面临的挑战是如何在无限算力与智能的背景下，设计出同样优雅且强大的软件扩展模式。

结论

在LLM时代，可扩展性的内涵正在演变。它不再仅仅是代码层面的开放接口，更是系统认知层面的开放架构。通过引入“意图抽象”和“丰富的领域模型”，我们可以构建出真正理解用户目标、能动态整合能力、并随着LLM能力提升而同步进化的软件系统。这或许是通往下一代智能应用的一条值得探索的务实路径。

未来的竞争，可能不再是看谁的插件多、API全，而是看谁的系统能更深刻、更灵活地理解和满足用户的意图。