生产级 AI Agent 工程：从 API 调用到自主系统的 5 个层次

当下 AI 应用开发正在快速分化。一边是大量基于 LLM API 的薄层封装——聊天界面换个皮肤、Prompt 模板拼接一下就上线；另一边是真正需要架构设计能力的生产级系统——涉及编排、记忆、可观测性、成本控制和故障恢复。

两者的差距不在于用了什么模型，而在于是否具备系统性思维：你能不能在不确定性中做出合理的架构决策？能不能让一个 AI 系统在生产环境中可靠、可控、可演进？

下文按复杂度递进拆五层；每层都尽量交代取舍和线上常见坑，而不是堆概念。

生产级 AI 工程的五个层次

层次一：边缘推理 — 在资源受限环境中运行模型

核心命题：不是所有场景都该调云端 API。延迟、成本、隐私都可能要求你在端侧运行模型。

为什么重要

云端 API 有三个绕不开的问题：网络延迟（尤其在移动端和弱网环境）、持续调用的成本累积、以及用户敏感数据离开设备的隐私风险。边缘推理不是为了替代云端，而是为了让 AI 能力覆盖云端到不了的场景。

关键架构决策

模型选型与量化

生产中不会只用一种量化策略。合理的做法是根据设备画像动态选择：

检测设备的可用 RAM 和芯片代际，决定加载 4-bit 还是 8-bit 量化模型
对核心推理路径用高精度，对辅助功能（如文本分类）用激进量化
量化带来的精度损失不是线性的——你需要在自己的任务上做回归测试，而不是看通用 benchmark

内存管理的真实挑战

移动设备的内存管理和服务端完全不同。系统会在内存紧张时杀后台进程，不会给你优雅退出的机会：

懒加载模型：用到时才加载，而非启动时全量加载
监听系统内存压力信号（如 iOS 的 didReceiveMemoryWarning），主动卸载非活跃模型
关键状态持久化到磁盘，被杀后能恢复上下文而非重新开始

离线优先的数据同步

端侧 AI 应用天然面临离线场景。数据同步不能是事后想法：

所有用户数据本地加密存储，仅在用户授权 + 网络可用时同步
冲突解决策略：端侧更改优先（用户看到的就是真实的），云端做合并而非覆盖
同步失败不能阻塞本地功能——这是很多应用的低级错误

工程取舍

边缘推理最大的坑不是技术，而是维护成本。你需要同时管理多个量化版本、适配不同芯片、处理模型更新的分发。如果你的场景对延迟和隐私没有硬性要求，优先考虑云端 API + 缓存策略，别为了”酷”而上端侧。

层次二：自主 Agent 循环 — 从工具调用到闭环推理

核心命题：聊天机器人等待输入，Agent 追求目标。区别在于它能自主规划、执行、反思和修正。

为什么重要

大多数”AI 应用”本质上是单轮工具调用：用户说一句话，LLM 调一个函数，返回结果。这在简单场景下够用，但真实业务问题往往需要多步推理、错误恢复和策略调整。Agent 的核心不是”更智能的 Prompt”，而是一个工程化的执行循环。

Agent 循环的四个阶段

规划（Plan）→ 执行（Act）→ 观察（Observe）→ 反思（Reflect）→ 规划 ...

这个循环看似简单，但生产化需要解决大量工程问题：

1. 规划阶段：约束比能力更重要

LLM 的规划能力是不可靠的。不能让模型自由发挥，必须用结构化的 Action Space 约束它的选择范围
将复杂任务分解为有限步骤，每步的可选操作是枚举的、可验证的
规划结果需要经过校验层：步骤之间是否有依赖冲突？总步数是否超过预算？

2. 执行阶段：沙箱和资源隔离

Agent 最危险的能力就是”做事”。生产系统中，每个执行步骤都需要：

隔离的执行环境（容器/沙箱），限制 CPU、内存、执行时间
文件系统访问控制——只能操作指定目录，不能碰系统文件
网络访问白名单——Agent 不应该有能力访问任意外部地址
对高风险操作（数据库写入、外部 API 调用）要求显式审批

3. 观察阶段：结构化的结果解析

Agent 需要理解执行结果，但 LLM 对长文本的理解能力有限：

执行结果不能原样塞进上下文，需要提取关键信息（成功/失败、关键输出、错误信息）
设置上下文窗口预算：最近 3-5 轮的完整信息 + 更早轮次的压缩摘要
工具输出格式标准化——无论底层工具多复杂，返回给 Agent 的永远是结构化 JSON

4. 反思阶段：从失败中学习

这是区分玩具和生产系统的关键。好的 Agent 不是不犯错，而是不重复犯同样的错：

每次失败记录完整上下文：尝试了什么、为什么失败、最终怎么解决的
按错误模式建立索引（向量检索），下次遇到类似问题时先查历史方案
设置断路器：如果同一类操作连续失败 N 次，停止重试并升级给人工

工程取舍

Agent 循环的最大风险是失控。没有上限的循环会消耗大量 Token（成本）和时间。生产中必须设置：最大迭代次数、单次任务 Token 预算、总执行时间上限。宁可让 Agent 带着部分结果”认输”，也不能让它无限循环。

层次三：多模态处理 — 超越文本的理解与生成

核心命题：真实业务数据不只是文本。图像、音视频、文档、表格混合的场景才是常态。

为什么重要

文本是 LLM 的舒适区，但业务场景充满非文本数据：医疗影像、工业检测图像、会议录音、合同 PDF、监控视频。能处理多模态输入的 Agent 才能覆盖真实业务流程。

关键架构决策

多模态融合策略

不同模态的处理方式差异很大，融合方式决定了系统的上限：

早期融合：将不同模态转为统一的 embedding 空间后再推理。优点是信息交叉丰富，缺点是对模型能力要求高
晚期融合：各模态独立处理后合并结论。更稳定，但可能丢失跨模态关联
实践中常用混合方案：视觉和文本用早期融合（VLM 擅长这个），音频单独处理后在决策层合并

意图到参数的翻译

用户的自然语言描述和系统的具体参数之间需要一个翻译层：

用户说”让画面更暖一些”→ 需要翻译为色温 +500K、饱和度 +10%、橙色通道 +5%
这个翻译不能硬编码。建立一个”意图-参数”映射库，通过 few-shot 示例让 LLM 做精确翻译
翻译结果需要校验：参数是否在合理范围内？组合是否会产生异常效果？

增量处理而非全量重算

处理视频、长文档等大体积数据时，全量重新处理是不可接受的：

建立内容索引：对视频按场景切分、对文档按章节切分，每段独立 hash
修改时只重新处理受影响的片段，未变更部分直接复用缓存
这不仅是性能优化，更是成本控制——多模态模型的 Token 计费远高于纯文本

工程取舍

多模态系统的复杂度呈指数增长。每增加一种模态，测试矩阵就翻倍。务实的策略是：先把一种模态做到生产级，再逐步扩展，而不是一开始就试图支持所有模态。

层次四：持久记忆与个性化 — 让 Agent 具备长期上下文

核心命题：没有记忆的 Agent 每次对话都从零开始，无法提供真正的个性化服务。

为什么重要

LLM 的上下文窗口是有限的，即使是 128K 的窗口也无法容纳一个用户数月的交互历史。生产级 Agent 需要独立于上下文窗口的持久记忆系统，才能实现真正的个性化和持续学习。

记忆系统的层次架构

参考人类记忆模型，Agent 的记忆可以分为三层：

层次	容量	生命周期	实现方式
工作记忆	小（当前上下文窗口）	单次会话	LLM 上下文 + 系统提示
情景记忆	中（近期交互历史）	天/周级别	向量数据库 + 时间衰减
语义记忆	大（提炼后的知识）	持久	知识图谱 + 结构化存储

工作记忆管理

当前会话的上下文不能无限增长，需要动态压缩
策略：保留最近 N 轮的原始对话 + 更早内容的 LLM 生成摘要
关键实体（人名、项目名、决策）即使超出窗口也要保留在系统提示中

情景记忆的检索

过去的交互按语义分块后存入向量数据库
检索时不只用语义相似度，还需要结合时间衰减和访问频率
最近的记忆权重高于久远的，频繁被引用的记忆权重高于一次性的

语义记忆的提炼

定期（如每天）运行总结进程：将情景记忆压缩为结构化知识
提取模式而非细节：“用户偏好简洁的代码风格”而不是”在 3 月 5 日的对话中用户说 prefer concise code”
冲突处理：新的观察与已有知识矛盾时，以最近的为准并标记变化

隐私和安全

记忆系统天然涉及大量用户数据，隐私架构不是可选的：

所有记忆数据用用户独立的密钥加密存储
提供”遗忘”接口：用户可以删除特定记忆或全部记忆
记忆数据不跨用户共享，不用于模型训练
敏感信息（密码、密钥、个人身份信息）在入库前自动脱敏

工程取舍

记忆系统最容易被过度设计。实际上，大多数业务场景只需要工作记忆 + 简单的情景检索。知识图谱这类重型方案只有在用户交互非常长期（月/年级别）且高度个性化的场景下才值得投入。先从简单方案开始，用数据驱动决定是否升级。

层次五：工作流编排 — 多 Agent 协作与自主运营

核心命题：单个 Agent 的能力有上限。复杂业务流程需要多个专家 Agent 协作，并与现有系统深度集成。

为什么重要

真实的企业工作流跨越多个系统（Slack、Jira、数据库、监控平台），涉及多种专业能力（数据分析、文档撰写、代码审查、客户沟通）。没有一个全能 Agent 能处理所有事情。编排层的价值在于将多个专精 Agent 组合为一个可靠的工作流。

编排架构

事件源 → 编排器（Orchestrator）→ 专家 Agent 集群 → 行动执行 → 结果汇报
         ↑                                              ↓
         └──────────── 反馈与学习 ←──────────────────────┘

事件驱动触发

监听多个事件源：Slack 消息、Jira 状态变更、监控告警、定时任务
事件分类器判断是否需要触发工作流、触发哪个工作流
去重和防抖：同一事件不重复处理，短时间内的相关事件合并处理

MCP 协议的角色

编排层的核心挑战是：如何让 Agent 标准化地接入各种工具和数据源？这正是 MCP（Model Context Protocol） 要解决的问题；协议与 Host / Client / Server 分工见同专栏《Function Call 与 Agent》中的 MCP 一节：

每个工具/数据源实现 MCP Server，暴露标准化的能力描述和调用接口
编排器通过 MCP Client 发现和调用工具，不需要为每个集成写适配代码
新增工具只需部署一个 MCP Server，无需修改编排层代码

多 Agent 委派

编排器不直接做事，而是将子任务分配给专家 Agent：

分析 Agent：查询日志和数据库，执行根因分析
通信 Agent：处理所有外部消息（Slack 通知、邮件）
文档 Agent：生成报告和文档
代码 Agent：执行代码审查、生成修复方案

每个 Agent 有独立的工具集和权限范围，互不干扰。

容错与自愈

分布式系统的所有经典问题在这里都会出现：

每个步骤设置超时和重试策略，瞬态故障用指数退避重试
持久化工作流状态，进程崩溃后能从断点恢复而非重新开始
断路器模式：某个工具/服务连续故障时，自动降级而非阻塞整个工作流
关键操作实现幂等性——重试不会产生副作用

可观测性

Agent 系统的调试难度远高于传统系统，因为行为具有不确定性：

每个 LLM 调用记录完整的输入、输出、耗时、Token 用量
工作流级别的追踪：从触发事件到最终结果的完整链路
业务指标：工作流成功率、平均处理时间、人工升级率
成本指标：每个工作流的 Token 消耗、API 调用费用

人机协同

完全自主不是目标，可控的自主才是：

高风险操作（生产环境变更、大额支出、对外沟通）要求人工审批
Agent 在置信度低时主动升级给人工，而不是硬猜
提供”解释”接口：每个决策都能追溯推理链和依据数据

工程取舍

编排系统最大的陷阱是过早追求通用性。不要一上来就建”万能编排平台”。从一个具体的业务工作流开始，把它做到可靠，再抽象共性。另外，多 Agent 系统的 Token 消耗是单 Agent 的数倍——成本控制从第一天就要考虑，设置每工作流的 Token 预算上限。

贯穿所有层次的工程原则

以上五个层次的技术各有不同，但有几条原则贯穿始终：

成本即架构约束

LLM 调用不是免费的。每一次 API 调用都有成本，而生产系统的调用量可能是开发时的千倍。从第一天就要把成本当作架构约束来考虑：

能缓存的结果一定要缓存（语义缓存、结果缓存）
能用小模型解决的问题不要上大模型（路由策略）
能在端侧处理的不要发到云端
设置预算告警，避免异常情况导致成本失控

确定性优先于智能

在 Agent 能自主决策的每个环节，都优先考虑：能不能用确定性逻辑替代 LLM 推理？

输入校验、格式转换、权限检查——用代码写死，别让 LLM 判断
只在真正需要语言理解和推理的环节使用 LLM
混合架构（确定性逻辑 + LLM 推理）比纯 LLM 方案更可靠、更便宜

可观测性不是事后补丁

AI 系统的行为具有不确定性，没有可观测性就是在盲人摸象：

日志、指标、追踪从第一行代码就要有
重点不是记录”发生了什么”，而是能回答”为什么会这样”
建立基线，监控偏离——模型输出质量、延迟、成本的异常波动都是信号

从简单开始，用数据驱动演进

每个层次都有从简单到复杂的光谱。不要一上来就瞄准最复杂的方案：

记忆系统：先用简单的 key-value 存储，发现不够了再上向量数据库
Agent 循环：先实现单步工具调用，验证价值后再加反思循环
编排：先硬编码一个工作流，跑通业务后再做通用抽象

过度工程化比技术不足更常见，也更致命——它消耗时间、增加复杂度，却不创造业务价值。

写在最后

AI 工程的核心不在于掌握了多少模型或框架，而在于能否在不确定性中做出合理的工程决策。每一个架构选择都是取舍——性能 vs 成本、自主性 vs 可控性、通用性 vs 落地速度。

这些取舍没有标准答案，但有一个判断标准：它是否解决了真实的业务问题？

技术服务于业务。能把 AI 的能力转化为业务价值的人，才是市场真正需要的。