LLM-First 或 Code-First？智能在生产 AI 中的归属

如何决定模型应处理什么、代码应处理什么，以及如何将二者连接起来。

几年前，AI 应用的架构是这样的：向大型语言模型发送提示 → 获取响应 → 将其展示给用户。如今这已不再是全部。模型被要求解释意图、检索信息、选择工具、调用 API、制定计划并执行多步骤工作流。

这种转变将领域划分为两类——LLM 优先或代码优先。

在 LLM 优先的架构中，模型位于中心并决定接下来发生的事情。它读取请求，选择工具，决定操作顺序，检查中间结果，并在需要时调整方向。

在代码优先的架构中，软件/代码负责序列化、业务规则、验证、权限和执行。此时的 LLM 如同代码在需要语言理解或生成时调用的专家。

人们常争论哪种更好。我认为这是一种错误的争论。更好的问题是每种智能应归属何处。我见过的最强大的生产系统很少是单纯一种模式。它们将概率推理与确定性控制相混合，并且是有意为之。

为何 LLM 优先如此吸引人

传统软件在需求可以明确规定时运作良好。例如，用户选择商品，输入金额并提交付款。你在代码中定义允许的状态、验证规则、错误情况以及交易顺序。完成。

自然语言并不像那样配合。想象一下用户输入：“找出看起来异常的交易，解释发生了什么，并告诉我应该先调查什么。”

对于该请求没有固定的路径。系统需要判断“异常”指的是什么，弄清哪些数据重要，可能调用多个工具，权衡响应，并撰写可供人使用的解释。没有任何工程团队或无代码系统能够提前预见所有的表述方式和需求组合。

这正是 LLM 发挥关键作用的地方，它充当人类语言与确定性服务之间的灵活推理层。这也是代理受到广泛关注的原因。Google Cloud 的代理式 AI 架构指南 将代理描述为一种应用，其中 AI 模型充当推理引擎，而工具使其能够访问外部系统和数据。

Anthropic 的 构建高效 AI 代理 指南 做出了我一直反复提及的区分。在一个 工作流，模型和工具遵循你的代码定义的路径。在一个 代理LLM 主导自己的流程并决定如何使用工具。相同的指南建议从能够解决问题的最简架构开始，而不是通过反射添加代理式复杂性。我会把这条建议强调两次。

“让模型决定” 的局限性

模型可以推理应该发生的事情。推理并不等同于执行规则。

例如，考虑一个金融工作流。LLM 可能擅长理解“将上月发送给同一供应商的相同金额再次发送”。但它是否也应决定转账是否获授权、计算监管限额、核实账户所有权、覆盖安全策略并执行交易？

可能不会。这些工作是确定性的、可测试的、可审计的且可强制执行，这正是传统软件擅长的。随着模型获得工具的访问权，风险会增加。OWASP 的生成式 AI 安全指南 标记 过度的自主性 作为重大风险：为基于 LLM 的系统赋予超出任务需求的功能、权限或自主性。当模型仅生成文本时，异常或被操纵的输出已经是问题；当模型能够在现实世界中行动时，问题则大得多。

这些并不意味着模型永远不应采取行动，而是说明模型的自主性应受到确定性权威的约束。

代码优先仍然重要

随着 AI 发展迅速，人们很容易觉得传统工程已经过时。我则持相反观点。AI 让优秀的确定性系统变得更为重要，而非更少。

只要任务要求精确可重复，代码仍是正确的选择。身份验证是最简单的例子。模型不应“推理”某人是否拥有管理员权限。你的应用应向权威的身份与访问管理系统查询。同样的原则适用于金钱计算、权益检查、数据验证、监管约束、交易限额、模式验证以及任何不可逆的操作。这些需要明确的合约，而非最佳猜测。

这与更广泛的治理思路相吻合。 NIST AI Risk Management Framework要求组织在设计、开发、部署和使用阶段管理 AI 风险。其伴随的Generative AI Profile补充说，根据风险的不同，生成式系统可能需要额外的监督、文档、审查和控制。

因此，我发现将每个设计决策拆分为两个问题很有帮助：

应该发生什么？

以及

允许发生什么？

LLM 通常可以帮助完成第一项。确定性系统通常应负责第二项。

混合模式：概率推理，确定性执行

对于大多数企业应用而言，实际的答案是混合模式。LLM 充当解释和推理层。确定性服务则充当执行和强制层。

举个例子。假设 AI 助手帮助开发者创建临时的 API 测试环境，开发者输入：“给我一个用于客户入职工作流的沙盒”。

LLM 可以解释该请求，推断出可能指的是哪个工作流，阅读文档，并建议可能相关的 API。但实际创建环境不应依赖自由形式的生成文本。代码可以确认所请求的 API 是否存在，验证其合约，检查授权，强制资源限制，生成批准的配置，并执行部署。

大致的划分如下：

• LLM：理解、推理、分类、提出、总结。
• 代码：验证、授权、计算、持久化、强制、执行。

每一方都专注于自己最擅长的工作，且不会被要求冒充对方的优势。

随着代理变得更强大，边界变得更为重要

随着我们从助手转向代理，这种分离变得更加重要。一个给出错误答案的助手会给人带来不便，而拥有生产写入权限的代理可能导致更大的混乱。

解决方案不一定是剥离自主性，而是要逐步添加自主性，同时保持明确的控制点。Google关于多代理系统的指南建议将动态 AI 行为与确定性的安全控制、可观测性、明确定义的自主性以及对业务关键场景的人类监督相结合。

人工批准也可以直接嵌入工作流，而不是作为非正式的安全网。Microsoft’s agent framework documentation例如，支持工具调用在有人明确批准请求的操作之前暂停。

原则很简单：行动后果越严重，围绕它的确定性控制就应越强。

在将任务交给 LLM 之前应提出的五个问题

当我决定一个组件是应采用 LLM 优先还是代码优先时，我会逐一考虑以下问题：

1. 任务是否有唯一客观正确的答案？如果是，则倾向于使用确定性代码。税务计算、权限和模式验证不应因模型今天的读取方式不同而改变。
2. 是否涉及模糊的语言或非结构化信息？如果是，LLM 可能会带来实际价值。
3. 如果模型出错会怎样？会议摘要的合适架构与发起支付的合适架构截然不同。
4. 输出是否可以独立验证？当确定性规则能够在执行前检查生成的行动时，LLM 生成的计划会更安全。
5. 这真的需要代理吗？如果你已经了解步骤，使用少量针对性的 LLM 调用的常规工作流通常更简单、更便宜、更易测试和运营。

最后一个问题值得额外关注。代理之所以强大，正是因为它们能够处理你无法预测每一步的情况。但如果你能够预测这些步骤，将其转化为开放式推理问题往往会增加变数，却并未提升智能。

可靠性是架构属性，而非提示

许多团队一开始尝试几乎完全通过提示工程来提升可靠性。提示固然重要，但它们无法承担全部责任。

生产系统应该假设模型输出有时会不完整、格式错误、出乎意料，甚至完全错误。OWASP LLM 应用的前十风险列出了诸如 提示注入 和 不当的输出处理，这强化了一项关键习惯：将模型输出视为下游系统的不可信输入，而不是自动执行的指令。

这会改变你提出的问题。不要问“我该如何编写一个提示，使模型始终遵循规则？”，而应问“我该如何设计系统，使得即使模型出错也无法破坏规则？”

这是一项软件架构问题，而不是提示问题。提示可以告诉代理不要执行未授权的操作。授权服务则可以真正阻止它。这两种控制并不等同。

超越争论：意图优先系统

思考这些，我相信 LLM 优先与代码优先的争论指向了第三种思路：意图优先 架构。

在意图优先系统中，应用程序首先要理解用户想要完成的目标。这正是 LLM 最有价值的地方，因为人们很少能精准表达自己的需求。随后，系统会逐步将这种模糊转化为结构化、确定性的操作。

类似“帮助我解决客户的付款问题”这样的请求可能会被拆解为一条流水线：理解意图、检索交易、识别失败原因、推荐解决方案、请求批准、执行已批准的操作。

其中一些阶段受益于语言模型的推理，其他阶段则应由固定服务完成。架构的定义并不取决于 AI 还是代码“占上风”，而是取决于不确定性可以被接受的环节。

结论

随着模型的提升，诱惑会越来越大，想要让它们掌控更大范围的系统层级。有时这确实是正确的选择。但在其他系统中，最成熟的设计往往是有意让模型拥有 更少的 权限。

最终，生产 AI 工程的核心是将智能置于恰当的边界。应在解释、推理、综合和适应能够创造价值的场景使用语言模型；在一致性、授权、精确性和强制执行至关重要的场景使用确定性软件。随后通过狭窄、可观测且经过充分测试的接口将二者连接。

企业 AI 的未来可能既不是纯粹的 LLM 优先，也不是纯粹的代码优先。它是在不确定性需要智能的地方使用 LLM，在确定性需要控制的地方使用代码。

这种区别可能比选择哪种模型更为重要。