简介：当业务逻辑从应用层向模型层、数据层和执行层迁移，传统应用层逐渐退化为胶水代码。本文从运行机制、模块协作、状态变化与技术边界等角度，系统解释这一“坍塌”现象为何发生，并说明在智能体时代应构建哪类承载业务语义的新基础设施。
本文讨论的不是某个具体框架或产品，而是一个结构性现象：在 AI Agent 逐步参与软件系统决策与执行的背景下，过去集中在应用层的业务逻辑，为什么会发生位置迁移、形态变化和职责弱化。
更具体地说，本文尝试解释以下问题：
为了回答这些问题，需要先理解传统应用层为什么存在，以及它承担了哪些不可替代的职责。只有理解了“坍塌”之前的结构，才能理解“坍塌”本身意味着什么。
在经典的软件架构中，系统通常被划分为若干层，例如接入层、应用层、领域层、基础设施层。应用层往往承担着“用例编排”的职责：接收外部请求，协调领域对象、数据访问、外部服务、消息队列和事务边界，最终返回结果。
这一结构之所以长期有效，是因为它解决了几个关键问题。
第一，业务规则需要稳定表达。一个订单能否取消、一次库存是否可扣减、一个用户是否有权限执行某操作，这些规则需要被显式编码、测试和审计。
第二，流程需要被可靠执行。业务过程通常包含顺序、分支、回滚、补偿和异常路径。传统应用层通过代码明确控制这些路径，从而保证行为可预测。
第三，职责需要被清晰隔离。接入层处理协议，领域层表达业务概念，基础设施层屏蔽存储和网络细节。应用层处于中间，负责把一次业务请求翻译为多个领域操作，并控制整体一致性。
因此，传统应用层并不是“胶水代码”，而是一段具有明确业务语义的编排逻辑。它之所以看起来像胶水，是因为随着模型能力的引入，编排逻辑本身开始从确定性代码向概率性执行过程转移。
这里的“坍塌”不是一个崩溃概念，而是一个结构迁移概念。它并不表示业务规则消失，而是业务规则的表达位置和执行位置发生了变化。
可以将其理解为三个层面的迁移：
这种迁移带来的直接结果是：应用层不再需要像过去那样，显式描述每一个业务分支。它的职责逐渐变为组装模型、工具、检索、权限和上下文，然后把控制权交给模型或代理运行时。
因此，所谓“坍塌”，本质上是业务逻辑的确定性表达被概率性调度所替代。应用层从“业务规则的执行者”转变为“模型与外部世界之间的适配层”。
要理解这种迁移，需要先拆解一个典型的 AI Agent 系统由哪些模块组成。
模型层负责理解用户意图、生成计划、选择工具、合成答案，并在必要时进行推理。模型不再是单纯的文本生成器，而是一个参与控制流的决策组件。
模型输入通常包括系统提示、历史上下文、工具定义、检索结果和用户消息。模型输出可能是最终答案，也可能是工具调用意图或中间步骤。
工具层将外部能力封装为模型可调用的接口。例如查询订单、创建工单、搜索文档、发送通知等。每个工具通常带有一段结构化的描述，用于让模型判断何时应该调用它。
工具层的关键点在于，业务规则的一部分被编码在工具描述中，而不是应用代码中。例如“该工具只能查询当前用户自己的订单”，这条语义可能既存在于代码校验中，也存在于自然语言描述中。
上下文中介层负责在每轮推理前，把合适的业务信息注入模型上下文。它可能包括检索模块、用户画像、租户信息、历史记录和系统状态。
这一层的出现，使得许多原本由代码查询数据库并组合对象的工作，被转移到上下文的动态组装中。
代理运行时是实际驱动 Agent 运行的引擎。它管理模型调用、工具执行、重试、超时、循环终止和错误恢复。
代理运行时的控制流通常是：模型输出动作，运行时执行动作，执行结果回填上下文，再次调用模型。这一循环替代了传统应用层中固定的业务编排逻辑。
业务服务层仍然存在，但它不再负责高层流程编排，而是提供细粒度、可复用、可校验的基础业务能力。例如库存锁定、订单状态变更、权限校验等。
这一层需要保持确定性。因为这些能力是模型调度外部世界的“稳定接口”。如果这一层也变得不确定，整个系统的可靠性将进一步下降。
下面通过一个通用流程，说明 AI Agent 系统如何在一次请求中运行。这个流程可以抽象为六个阶段。
外部请求到达接入层后，系统进行基础的安全校验、租户识别和上下文初始化。此时业务操作尚未发生，但请求已经被赋予了基本身份信息。
系统根据用户身份和任务类型，从业务服务层读取相关数据，并可能通过检索获取额外信息。这些数据被打包为模型可读的上下文。
这一阶段传统上由应用层完成大量数据组合，现在则更多由上下文组装器或数据编织层完成。
模型基于上下文生成下一步动作。动作可以包含查询、更新、创建或调用外部服务。模型也可能决定继续提问、终止流程或返回结果。
此阶段的核心特征是：下一步动作不是由固定代码逻辑决定的，而是由模型生成并交由运行时解析的。
工具层实际执行业务操作，返回结构化结果。执行前后都可能触发权限校验、审计记录和数据变更。
执行失败时，运行时需要决定进行重试、回退还是终止。重试策略、异常解释是否合理，会直接影响业务结果的可信度。
确定性业务服务层对关键操作进行最终校验。例如金额不为负、状态流转符合状态机、资源归属正确等。
这一阶段是保障业务安全的关键机制。模型参与决策并不意味着模型可以绕过约束。稳定的业务约束仍需由确定性系统兜底。
最终结果返回给用户。整个过程中的决策轨迹、工具调用记录、关键数据变更和模型输出被写入日志或审计系统。
审计机制的重点不再是“调用了哪个函数”，而是“模型在当时上下文下选择了什么动作、为什么这样选择、外部系统如何响应”。
传统应用层的核心价值在于控制流程。模型引入后，流程控制权被部分转移给模型。模型根据语义理解动态决定调用什么工具、以什么顺序执行、何时停止。
这意味着，原先写在代码中的分支和顺序，不再完全由开发者静态定义，而是在运行期动态生成。这种机制大幅提高了灵活性，也带来了不可完全预知的行为。
在传统系统中，业务规则通常写为 if-else、状态机、规则引擎或工作流定义。在 Agent 系统中，许多规则通过提示词、工具描述和检索上下文间接表达。
例如，一条“优先选择耗时最短的物流方式”的规则，过去可能由代码排序实现；现在可能被写成一句自然语言指令，放入系统提示中。模型是否始终遵循这条规则，取决于模型对语境和示例的理解程度。
传统应用层按固定顺序调用服务，而 Agent 系统采用“语义调度”。模型在每一步根据当前状态决定下一步动作，形成动态执行图。
这种机制的优点是能处理长尾任务和不规则输入，缺点是执行路径难以提前穷举，坑位分析、故障排查和回归测试都变得更复杂。
为了保持关键业务的安全性，许多系统把强约束逻辑从应用层下沉到业务服务层。例如库存扣减总额校验、订单金额不变性、权限条件等，统一由底层服务强制保证。
于是，应用层不再承担这些强约束，而是负责调用这些能力。这正是“应用层只剩胶水代码”这一说法的技术来源。
传统应用层实现“取消订单”通常包含以下步骤：
接收请求检查订单状态检查用户权限判断是否可取消执行取消操作发送通知返回结果
每一步都有明确的代码路径和异常处理。
在 Agent 系统中的可能流程变成：
用户输入目标模型判断需要调用“订单取消”工具工具描述和上下文帮助模型判断前置条件模型生成工具调用动作业务服务层校验状态和权限执行取消并返回结果模型根据结果解释是否成功
关键是，模型并不是直接执行取消动作，而是通过工具描述理解业务边界，并把真实校验交给业务服务层。应用层在这里的作用，主要是注册工具、组装上下文、驱动运行时和处理最终响应。
业务逻辑没有消失，而是被拆分成两部分：
应用层夹在中间，自然会变得更薄。
这一机制带来三个明显收益。
第一，复杂意图处理能力增强。系统不再需要为每一种输入组合预先设计完整代码路径，模型可以在语义空间中组合已有工具。
第二，迭代方式发生变化。新增业务能力可以更快地通过新增工具或调整提示词完成，而不必立即修改核心流程代码。
第三，业务表达更接近自然语境。业务人员可以更直接地理解系统如何决策，因为规则以更接近自然语言的形态存在。
限制同样明显。
第一，执行路径不稳定。相同输入可能因为模型采样、上下文差异或温度设置而产生不同中间路径。即使结果相同，中间工具调用顺序也可能不同。
第二，故障分析难度上升。传统断点调试和调用栈分析不再完全适用，仍需结合决策轨迹和上下文快照进行回溯。
第三，审计要求提高。业务操作由动态生成的动作触发，审计日志不仅要记录“发生了什么”，还要记录“模型当时认为应该发生什么”。
第四，测试复杂度增加。无法仅靠固定用例覆盖所有分支，因为分支空间显著扩大，需要补充语义级测试和反事实测试。
模型无法且不应取代全部业务规则。金额、权限、审计、状态机等强约束仍需确定性服务承担。模型适合负责语义理解和非结构化流程，不适合作为交易一致性的唯一保障。
应用层并没有消失，而是职责发生了改变。它从“业务编排者”变成“系统适配者”。工具注册、上下文策略、运行时代理、异常兜底和审计采集，依然需要应用层提供工程化支撑。
工具描述只是影响模型判断的因素之一。提示词质量、上下文长度、示例充分度、模型版本差异、采样参数和系统状态都会影响模型行为。单纯堆工具并不能自动带来稳定系统。
把所有规则塞进提示词，会导致语境过长、规则冲突和不可维护。合理的做法是区分哪些规则需要硬约束，哪些规则可以作为软性引导，并设计对应的服务层和上下文策略。
如果传统应用层的业务逻辑正在被模型、工具和上下文重新分配，那么新的构建重点应集中在以下几个方向。
将资金、库存、权限、状态流转等关键约束封装为细粒度、可组合的服务。模型可以调用这些服务，但不能绕过这些服务。业务安全边界应尽量下沉到基础设施层。
建立工具的统一注册、版本管理、权限声明和调用审计机制。工具描述需要像 API 文档一样被严格治理，因为它会影响模型的决策质量。
业务系统需要显式控制哪些信息进入模型、哪些信息被屏蔽、哪些信息需要动态刷新。上下文不只是一个输入通道，而是业务语义的载体。上下文策略将直接影响模型的判断准确率和行为稳定性。
传统监控面向请求耗时、错误率和资源占用，而 Agent 系统需要额外跟踪决策轨迹、工具调用链、模型输出差异、上下文变化和关键业务结果。可观测性机制需要从“监控代码”扩展到“监控决策”。
由于大部分流程不再由固定代码定义，系统需要持续采集真实运行数据，构造评估集，对模型选择和工具使用效果进行回归分析。只有在闭环中不断校准，业务系统才能在模型迭代下保持稳定。
业务逻辑的“坍塌”不是软件系统的失败，而是控制权重新分配的结果。模型参与了流程决策，上下文承载了业务语义，确定性服务保住了关键约束，而传统的应用层则被挤压成一个更薄、更偏适配功能的层次。
理解这一现象的关键在于：业务逻辑没有被消除，而是被迁移和重述。一部分进入模型提示与工具描述，一部分进入上下文工程，一部分下沉到强约束服务。应用层不再是唯一承载业务语义的位置，而需要与其他层次共同构成新的运行结构。
在这个背景下，真正值得构建的不是更复杂的应用编排代码，而是一套能够让模型在边界内安全决策、让工具被准确理解、让执行可观测、让业务结果可验证的基础能力体系。这套体系，才是 AI Agent 时代新的“业务逻辑承载层”。