agent-">业务逻辑的“坍塌”：当应用层只剩下胶水代码，在 AI Agent 时代，我们该构建什么

一、概念定义：什么是业务逻辑的“坍塌”

“业务逻辑坍塌”并非一个已被标准化的学术术语，而是对一种正在发生的工程现象的概括性定义：

当应用层的核心价值——业务规则的编排、状态管理、决策路径与领域知识的表达——被逐步上移到大模型或Agent运行时中，传统应用层退化为仅负责输入输出拼接、协议适配与工具调用的“胶水代码”，这一过程即为业务逻辑的坍塌。

要理解这个定义，需要区分三个层次：

• 胶水代码（Glue Code） ：不承载业务语义，仅完成数据格式转换、接口串联、参数传递的薄层代码。它本身不产生业务价值，只是让不同组件“能一起工作”。
• 业务逻辑（Business Logic） ：领域规则、流程编排、条件分支、状态机、校验策略、计算逻辑等构成应用核心价值的代码。
• 坍塌（Collapse） ：业务逻辑从应用层“流失”，不再由开发者显式编写和维护，而是以提示词、工具描述、上下文约束等形式隐式地存在于Agent运行时中。

这一现象的本质问题是：当业务逻辑不再存在于代码中，它去了哪里？它是否仍然可控、可测试、可审计？

二、背景与价值：为什么会出现这种坍塌

2.1 从“模型即函数”到“模型即运行时”

传统软件架构中，大模型通常被视为一个函数：输入文本，输出文本或结构化结果。应用层围绕这个函数构建完整的业务逻辑。

但在Agent架构中，模型不再只是函数，而是运行时本身。它负责：

• 决定调用哪个工具
• 决定以什么顺序调用
• 决定何时停止
• 决定如何处理异常
• 决定如何向用户呈现结果

这些决策在过去都是业务逻辑的一部分，现在被“委托”给了模型。

2.2 预训练与后训练的门槛效应

行业内普遍观察到：真正参与预训练的企业极少，多数参与者集中在应用层。这意味着：

• 模型能力由少数掌握预训练资源的机构定义
• 应用层开发者无法改变模型的基础能力边界
• 应用层的差异化越来越依赖“如何组织上下文与工具”，而非“如何编写业务规则”

当模型能力足够强时，开发者自然倾向于把更多逻辑交给模型，而不是用代码显式表达。这就是坍塌的驱动力。

2.3 经济性与迭代速度的权衡

用代码表达业务逻辑需要：需求分析、设计、编码、测试、部署、维护。用提示词或Agent配置表达业务逻辑，迭代周期可以缩短到分钟级。

这种效率差异导致一个现实结果：即使开发者知道应该用代码表达逻辑，也会选择更快的路径。 坍塌因此加速。

三、核心组成：AI Agent 时代应用架构的关键模块

在Agent架构下，一个典型的应用系统可以拆解为以下模块：

3.1 模型运行时

负责推理、决策、生成。它接收上下文，输出动作或文本。模型运行时是Agent的“大脑”。

3.2 工具层

一组可被模型调用的函数或服务。每个工具通常包含：

• 名称与描述（供模型理解）
• 输入参数模式
• 执行逻辑
• 输出格式

工具层是Agent与外部世界交互的边界。

3.3 上下文管理器

负责构建、裁剪、压缩传递给模型的上下文。包括：

• 系统提示词
• 历史对话
• 工具调用结果
• 外部检索内容
• 状态变量

上下文管理器决定了模型“看到什么”，从而间接决定了它的行为。

3.4 状态与记忆

Agent需要跨轮次保持状态。状态可以存储在：

• 对话历史中
• 外部键值存储中
• 向量数据库中
• 结构化数据库中

状态管理是业务逻辑的重要载体，但在Agent架构中往往被弱化。

3.5 编排层

决定Agent的调用流程：是单轮还是多轮？是否并行调用工具？失败后如何重试？何时交还控制权给用户？

编排层是业务逻辑最集中的地方，也是坍塌最严重的区域。

3.6 可观测与治理

包括日志、追踪、评估、安全过滤、权限控制等。在Agent架构中，这些能力需要重新设计，因为执行路径不再是静态的。

四、工作原理：业务逻辑如何从代码中“流失”

4.1 传统架构中的业务逻辑

以一个订单处理系统为例，传统代码可能是：

def process_order(order):
    if not validate_order(order):
        return error("invalid order")
    if order.amount > CREDIT_LIMIT:
        if not check_credit(order.user):
            return error("credit check failed")
    discount = calculate_discount(order)
    total = order.amount - discount
    if total < MIN_ORDER_AMOUNT:
        return error("below minimum")
    return create_payment(order, total)

这段代码显式表达了：校验规则、信用检查、折扣计算、最小金额限制、支付创建。这些是业务逻辑。

4.2 Agent架构中的等价实现

在Agent架构中，上述逻辑可能变成：

• 系统提示词：你是一个订单处理助手。请校验订单、检查信用、计算折扣、确认金额、创建支付。
• 工具：validate_order、check_credit、calculate_discount、create_payment
• 用户输入：帮我处理这个订单

模型自行决定调用顺序、是否跳过某些步骤、如何处理异常。业务逻辑从代码变成了提示词与模型决策。

4.3 坍塌的临界点

当以下条件同时满足时，坍塌变得不可逆：

• 模型能力足够强，能处理大多数边缘情况
• 业务规则变化频繁，代码维护成本高于提示词调整
• 团队缺乏对Agent行为的完整测试能力
• 业务方更关心“能不能跑通”而非“是否可解释”

此时，应用层只剩下：调用模型、传递上下文、执行工具、返回结果。这就是胶水代码。

五、LLM 不确定性的技术根源：为什么 Temperature=0 仍有变化

这是理解Agent行为的关键问题。即使所有参数固定、Temperature设为0，固定输入仍可能产生不同输出。原因包括：

5.1 浮点运算的非确定性

GPU并行计算中，浮点加法不满足结合律。不同的计算顺序会产生微小差异，这些差异在深层网络中可能被放大。

5.2 批处理与并行调度

推理时，请求可能与其他请求一起批处理。批处理大小、顺序、内存布局的变化会影响计算结果。

5.3 注意力机制的数值稳定性

Softmax、LayerNorm等操作对数值精度敏感。不同硬件、不同算子实现可能产生不同结果。

5.4 采样策略的残留随机性

即使Temperature=0，某些实现仍可能使用Top-K或Top-P的变体，或在平局时随机选择。

5.5 上下文长度的细微差异

如果上下文构建过程中有任何非确定性（如时间戳、随机ID、并发写入顺序），输入就会不同。

结论：LLM的不确定性不是单一原因造成的，而是浮点计算、并行调度、数值稳定性、采样策略与上下文构建共同作用的结果。 这意味着，即使你把业务逻辑全部交给模型，也无法保证相同输入产生相同输出。

六、典型场景：坍塌发生在哪些领域

6.1 客服与对话系统

过去：意图识别、槽位填充、对话状态机、业务规则引擎。
现在：系统提示词+工具调用+模型决策。
坍塌程度：高。对话流程不再显式编码。

6.2 代码生成与开发辅助

过去：模板引擎、代码生成器、AST操作。
现在：模型直接生成代码，开发者审核。
坍塌程度：中高。生成逻辑不可解释。

6.3 数据分析与报表

过去：SQL模板、ETL流程、指标定义。
现在：自然语言转SQL，模型决定查询逻辑。
坍塌程度：中。查询正确性依赖模型能力。

6.4 工作流自动化

过去：BPMN、状态机、规则引擎。
现在：Agent编排，模型决定下一步。
坍塌程度：高。流程不可静态验证。

6.5 安全与合规审查

过去：规则库、策略引擎、审计日志。
现在：模型判断+人工复核。
坍塌程度：中。但合规要求高的场景难以接受。

七、相关概念区别

7.1 胶水代码 vs 业务逻辑

胶水代码不表达领域规则，只负责连接。业务逻辑表达“在什么条件下做什么”。坍塌的本质是业务逻辑被胶水代码替代。

7.2 Agent vs 工作流引擎

工作流引擎的执行路径是预定义的、可静态分析的。Agent的执行路径是运行时生成的、不可完全预测的。Agent更灵活，但可验证性更差。

7.3 提示词工程 vs 传统编程

提示词工程用自然语言表达意图，传统编程用形式语言表达规则。前者迭代快、门槛低，但可测试性、可复用性、可组合性差。

7.4 模型不确定性 vs 系统不确定性

模型不确定性来自浮点计算与采样。系统不确定性来自上下文构建、工具调用、外部状态。两者叠加，使Agent行为难以完全复现。

八、使用注意事项

8.1 不要把所有逻辑都交给模型

对于合规、资金、安全相关的逻辑，应保留显式代码表达。模型可以辅助决策，但不应成为唯一决策者。

8.2 建立Agent行为的可观测性

记录每次调用的：输入上下文、模型输出、工具调用序列、最终结果。没有可观测性，就无法调试和优化。

8.3 设计可测试的Agent

将Agent行为拆解为可独立测试的单元：工具调用是否正确、上下文构建是否符合预期、异常处理是否合理。

8.4 控制上下文膨胀

上下文越长，不确定性越大，成本越高。需要设计裁剪、摘要、检索策略。

8.5 明确人机边界

哪些决策由模型做，哪些由人做，哪些由代码做。边界清晰，系统才可控。

8.6 版本化提示词与工具描述

提示词和工具描述是业务逻辑的新载体，应像代码一样版本化、评审、回滚。

九、总结：在坍塌之后，我们该构建什么

业务逻辑的坍塌不是灾难，而是一种架构演进。它把开发者从繁琐的规则编码中解放出来，但也带来了新的挑战：如何让隐式的业务逻辑仍然可控、可测、可审计。

在AI Agent时代，我们该构建的不是更多的胶水代码，而是：

1. 可观测的Agent运行时：让每一步决策都有迹可循。
2. 可测试的工具层：每个工具都是纯函数或幂等服务，可独立验证。
3. 可版本化的上下文管理：提示词、工具描述、状态结构都应纳入版本控制。
4. 可回滚的编排策略：当Agent行为异常时，能快速切换回确定性流程。
5. 人机协作的边界设计：明确哪些决策必须由人确认。

回到高斯的比喻：工匠在建筑完成后拆除脚手架。但在Agent时代，脚手架可能永远不会被拆除——因为建筑本身在持续变化。我们能做的，是确保脚手架足够坚固、透明、可调整，让建筑在变化中仍然屹立。

业务逻辑没有消失，它只是换了一种存在形式。理解这一点，是构建下一代应用系统的起点。