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

一、一个被反复推翻的困惑

数学家高斯曾说过一句话：“工匠总是在建筑完成后，把脚手架拆除。”这句话放在今天的软件工程语境里，格外耐人寻味——我们花了二十年搭建的应用层，会不会正是那层即将被拆除的脚手架？

过去很长一段时间，关于 AI 是否是泡沫的争论从未停歇。有人将其与曾经的元宇宙热潮类比，认为一阵风过后便会消散。这种判断并非毫无依据：在相当多的行业会议上，当被问及“有多少企业真正投入了预训练”时，数百人的会场里举手的往往只有三四人；真正参与后训练的更少，绝大多数只是在外围做套壳调用。预训练一轮的成本动辄以百万美元计，而如今模型参数量动辄上千亿，投入更是难以估量。“重视 AI”和“实际参与核心训练”之间，存在的是一道巨大的鸿沟。

与此同时，另一组对比也值得玩味：用于辅助驾驶的芯片算力大约在数百 TOPS 量级，售价不过几百美元；而用于大规模训练的高端加速卡算力可达其数十倍，价格则高达数万美元。两者之间的差异，不只是数字上的倍数关系，而是“推理部署”与“模型生产”这两种截然不同的工程范式的差异。

在过去几个月里，从 AI Coding、AI Agent 开发、AI 安全、AI 伦理到“10x 超级个体”，各类分享层出不穷。许多人的心路历程是：从最初的焦虑，到摄入新知识后的新奇与满足，再到最后慢慢变得迷惑。因为关于 AI 的论述经常走向两个极端——“AI 无所不能，大部分岗位将被取代”与“AI 不过是几个矩阵相乘，没必要神话它”。

其中一个被广泛引用的观察是：过去三十年，全球每年毕业的 NLP 方向博士约千人，累计数万人，在分治后的各个细分领域提出了种种创新方法。但在大语言模型到来之后，这些工作中相当一部分失去了原有的意义。这提醒我们：当底层范式发生迁移时，上层积累的许多“手艺”可能会被重新定价。

二、从技术视角拆解：LLM 的不确定性究竟来自哪里

在讨论应用层该构建什么之前，有必要先厘清一个基础问题：大模型到底“确定”到什么程度？

一个常见的困惑是：Embedding 查表、Attention 计算中的各种权重矩阵、FFN 与 Linear 层的权重和偏置，在训练完成后都已固定；Positional Encoding、残差连接（Add）和归一化（Norm）也都是确定性计算。那么，为什么把 Temperature 设为 0，对于固定输入，输出仍然会变化？

这个问题的答案，恰恰是理解 AI Agent 工程的关键。不确定性主要来自以下几个层面：

1. 浮点运算的非结合律

GPU 上的并行计算会因线程调度、归约顺序不同，导致浮点加法不满足结合律：(a+b)+c ≠ a+(b+c)。在数十亿参数的矩阵乘法中，这种微小误差会被逐层放大。即使 Temperature 为 0，logits 的微小差异也可能改变 argmax 的结果。

2. 批处理与动态批调度

推理服务通常采用动态批处理来提升吞吐。同一个请求在不同批次中，由于 padding、kernel 选择、内存布局的差异，计算结果会有细微不同。这不是模型本身的问题，而是服务工程的副作用。

3. MoE 与稀疏激活的路由抖动

在混合专家架构中，token 到专家的路由本身可能依赖浮点比较。当两个专家的得分极为接近时，微小的数值扰动就会导致路由结果不同，从而改变后续计算路径。

4. Temperature=0 并不等于贪心解码的绝对稳定

许多推理框架在 Temperature=0 时仍会保留 top-k 或 top-p 的采样逻辑，或者在数值实现上使用近似。所谓“确定性”更多是工程目标，而非数学保证。

5. 上下文与状态的外部性

在多轮对话或 Agent 循环中，输入本身取决于上一轮输出。一旦某一步出现微小差异，后续就会产生“蝴蝶效应”。

理解这一点非常重要：不确定性不是 bug，而是这类系统的固有属性。 应用层的职责，从“消除不确定性”转变为“在不确定性之上构建可控的行为”。

三、应用层的“坍塌”：胶水代码为何不再足够

传统应用层的核心价值，在于把业务规则翻译成确定性的控制流：

def calculate_discount(user, order):
    if user.level == "VIP" and order.amount > 1000:
        return order.amount * 0.8
    return order.amount

这类代码的特点是：输入确定，输出确定，逻辑可枚举，测试可覆盖。应用层的复杂度，主要来自业务规则的组合爆炸，而不是计算本身的不确定性。

但在 AI Agent 时代，越来越多的“业务逻辑”被下沉到模型内部：

• 意图识别不再靠 if-else，而是靠 prompt + 模型判断；
• 信息抽取不再靠正则，而是靠结构化输出；
• 流程编排不再靠状态机，而是靠 Agent 的自主规划；
• 异常处理不再靠异常捕获，而是靠模型的重试与反思。

于是应用层逐渐退化为“胶水代码”：拼接 prompt、转发请求、解析 JSON、调用工具。这些代码本身没有业务含义，只是模型与外部世界之间的管道。当业务逻辑被模型吸收，应用层就出现了“坍塌”——它的厚度在变薄，它的不可替代性在下降。

这正是标题所指的现象。而“坍塌”带来的直接后果是：单纯会写胶水代码的开发者，其价值会被快速稀释。

四、AI Agent 时代，我们该构建什么

如果应用层不能再靠“实现业务规则”立足，那么新的价值锚点在哪里？我认为至少有五个方向。

4.1 构建约束系统，而非逻辑系统

模型负责生成，工程负责约束。约束系统包括：

• 输出模式约束：用 JSON Schema、类型系统、语法约束解码，把自由文本收敛为可程序化处理的结构；
• 工具调用约束：定义清晰的工具边界、参数校验与权限控制，让 Agent 的行动空间可控；
• 预算约束：对 token、调用次数、执行时长设置硬上限，防止成本失控；
• 安全约束：输入过滤、输出审查、敏感操作二次确认。

# 示意：用模式约束把模型输出收敛为可校验结构
from pydantic import BaseModel, Field
class RefundAction(BaseModel):
    order_id: str = Field(pattern=r"^ORD-\d{8}$")
    amount: float = Field(gt=0, le=10000)
    reason: str = Field(max_length=200)
def parse_agent_output(raw: str) -> RefundAction:
    return RefundAction.model_validate_json(raw)

约束系统的价值，在于它把“不可靠的生成”转化为“可靠的接口”。

4.2 构建评估与可观测体系

在确定性系统中，测试即验证。在概率性系统中，评估才是核心工程。需要构建：

• 离线评估集：覆盖典型场景、边界场景、对抗场景；
• 在线指标：任务完成率、工具调用成功率、平均轮次、成本分布；
• 轨迹追踪：记录每一步的输入、输出、工具调用与耗时，支持回放与归因；
• 回归门禁：任何 prompt、模型、工具的变更，都必须通过评估基线才能上线。

没有评估体系的 Agent，等于没有测试的分布式系统——能跑，但不可维护。

4.3 构建记忆与状态管理

Agent 的“智能”很大程度来自上下文。但上下文窗口有限，且成本随长度增长。因此需要：

• 短期记忆：当前任务的对话与工具结果；
• 长期记忆：用户偏好、历史决策、领域知识，通常落在外部的存储与检索系统中；
• 状态机：把长流程拆成可恢复的步骤，支持中断、重试与人工介入。

这部分工作，本质上是在为不确定的模型提供确定的“外部大脑”。

4.4 构建人机协作界面

Agent 不是要取代人，而是要在关键节点让人做决策。需要设计：

• 置信度暴露：让用户知道模型有多确定；
• 可解释轨迹：展示 Agent 的推理与行动路径；
• 干预机制：允许暂停、修正、回滚；
• 责任边界：明确哪些操作必须人工确认。

4.5 构建领域知识与数据飞轮

通用模型不懂你的业务。真正的壁垒在于：

• 领域数据：高质量的指令数据、偏好数据、评测数据；
• 检索增强：把私有知识库接入推理流程；
• 微调与蒸馏：在通用能力之上叠加领域专长；
• 反馈闭环：把线上交互转化为训练信号。

数据飞轮一旦转起来，就会形成“越用越好、越好越用”的正循环。

五、开发者的角色迁移

在这样的背景下，开发者的核心能力需要迁移：

传统能力	新能力
编写业务逻辑	设计约束与评估
调试确定代码	分析概率行为
优化算法复杂度	优化 token 与延迟成本
维护状态机	维护记忆与上下文
单元测试	评估集与回归门禁

这不是说传统能力不再重要，而是说它们从“核心价值”变成了“基础素养”。真正的稀缺能力，是在不确定性之上构建可靠系统的能力。

六、结语：脚手架拆除之后

回到高斯那句话。脚手架被拆除，不是因为工匠不努力，而是因为建筑已经建成。应用层的“坍塌”，也不是开发者的失败，而是技术栈重心迁移的必然结果。

在 AI Agent 时代，我们该构建的，不再是层层叠叠的业务逻辑，而是：

• 让模型可控的约束系统；
• 让行为可测的评估体系；
• 让智能可持续的记忆与数据飞轮；
• 让人机可协作的交互界面。

这些工作，比写胶水代码难得多，也比写胶水代码有价值得多。当脚手架被拆除，留下来的是地基与承重结构——那才是真正值得构建的东西。