从原则到模式：AI 系统的工程化落地 从原则到模式：AI 系统的工程化落地

本篇是《大模型不是魔法》系列的第二篇。第一篇我们证明了 SOLID、KISS、DRY 和各种 *ility 在 AI 时代依然有效。这篇回答的问题是：原则知道了，具体怎么做？

某公司的 AI 客服系统上线三个月后，CTO 盯着账单发呆。

月消耗从 5000 美元涨到 75000 美元，涨幅 15 倍。排查发现，80% 的请求是重复的——用户翻来覆去问那 20 个常见问题，系统每次都调用 GPT-5 重新生成答案。缓存命中率不到 5%。

更讽刺的是，团队为了”Agentic”，把原本一个 Prompt 能搞定的流程拆成了 5 个 Agent 编排。Token 消耗翻了 15 倍，准确率反而因为级联错误下降了。

这不是架构升级，这是架构负债。

一、LLM Gateway：不是封装 SDK，而是重建入口

很多团队对 LLM Gateway 的理解停留在”封装 OpenAI SDK，加个超时重试”。这太浅了。

一个生产级的 LLM Gateway，和传统的 API 网关（Nginx、Kong、AWS API Gateway）承担的职责高度重叠：统一入口、智能路由、缓存加速、限流保护、成本计量。区别只在于，它处理的对象从 HTTP 请求变成了 Token 流。

这正是第一篇讲的单一职责原则（S) 和依赖倒置原则（D） 在 AI 场景下的落地——Gateway 只做”接进来”这一件事，业务逻辑不感知具体模型供应商。

1.1 路由：从轮询到语义分发

传统负载均衡按轮询或权重分发请求。LLM 场景下，这种粗粒度分发是浪费——简单 FAQ 和复杂推理任务的成本差距可达 100 倍。

2026 年的主流做法是 Query Classifier：一个轻量级分类器（规则引擎或小模型，延迟几毫秒）先判断查询复杂度，再决定路由到哪个模型层级。

实测效果：80% 的请求走轻量模型，20% 走旗舰模型，总成本降低 60-70%，质量几乎无损。

这正是第一篇讲的开闭原则（O）——新增模型只需改 Gateway 配置，业务代码完全不动。也和传统架构的分层服务是一个思路——读请求走从库，写请求走主库；静态资源走 CDN，动态资源走源站。不是每个请求都需要最高规格的处理能力。

现实选择：买还是造？

2026 年的 LLM Gateway 市场已经成熟，大多数公司不需要从头搭建：

市场上对”AI 架构师”的期待往往包含”从零搭建 LLM Gateway”。但 2026 年的现实是：绝大多数公司的 Gateway 是配置现成的托管服务或开源代理，不是从零写代码。就像传统架构师很少自己写 Nginx，而是配置 Nginx 一样。

反模式：一刀切路由。 所有请求都走 GPT-5，因为”怕小模型搞不定”。结果是简单查询烧了 50 倍不该花的钱。

1.2 缓存：三层策略，层层递进

缓存是软件工程里最古老的优化手段。LLM 场景下，它的价值被严重低估。

Exact Match Cache 最简单：输入字符串哈希 → 查缓存 → 命中即零成本。托管网关（如 Portkey）通常内置此功能，开箱即用。自建的话，Redis 或 Memcached 即可满足。

Semantic Cache 稍复杂：输入文本向量化 → 向量数据库检索相似结果 → 相似度超过阈值则返回缓存。Portkey 等托管服务在 2026 年已内置 Semantic Cache，支持相似度阈值可调（保守 0.95 到激进 0.85），客服类场景命中率 30-50%。自建的话，需要一个 embedding 模型和一个向量数据库（Pinecone、Weaviate 或 pgvector），维护成本不低。

Prompt Caching 是供应商层面的优化，不需要自建。Anthropic、Google、OpenAI 在 2026 年均支持缓存折扣——读取缓存 Token 按 10% 价格计费。一个 2000 Token 的系统 Prompt，在 100 万次请求中重复，缓存可节省 20 亿 Token 的费用。开启方式通常是 SDK 里加一个参数，如 Anthropic 的 cache_control。

这正是第一篇讲的KISS 原则——能用简单方案（Exact Match）就不用复杂方案（Semantic Cache），能用供应商自带功能（Prompt Caching）就不用自建基础设施。三层缓存和传统 Web 缓存的分层策略（浏览器缓存 → CDN → 源站）是一个逻辑。区别在于：Web 缓存按 URL 命中，LLM 缓存按语义向量命中。

反模式：不设缓存。 “每个用户的问题都是独特的”——这是幻觉。客服场景 80% 的问题是重复的，只是措辞不同。

1.3 限流与预算：从 QPS 到 Token

传统 API 限流按”每秒请求数”。LLM 场景下，这个指标太粗糙——一个请求可能消耗 100 Token，也可能消耗 10 万 Token。

2026 年的生产级限流是多维度的：

托管网关通常内置多维限流：单请求 Token 上限、单用户配额、全局成本告警，配置即可启用。自建的话，需要在 Gateway 层解析请求体，预估 Token 数（用 tiktoken 或供应商的 Token Count API），再决定是否放行——这属于”造轮子”，除非你有特殊需求。

超限处理策略也和传统配额一样：拒绝、降级、排队、或触发告警通知管理员。

反模式：只限请求数，不限 Token 数。 一个 10 万 Token 的失控请求，在 QPS 限流下安然通过，然后烧掉你一天的预算。

二、Agent 编排：先问”需不需要”，再问”怎么排”

2026 年最危险的架构决策，不是”选错了编排模式”，而是”不该用编排的时候硬上编排”。

2.1 判断标准：单 Agent 够不够用？

行业数据很直白：多 Agent 系统的 Token 消耗是单 Agent 的 15 倍。如果单 Agent 能搞定，上多 Agent 就是纯纯的成本浪费。

判断标准三个问题：

1. 任务是否有天然的分阶段边界？（研究 → 分析 → 写作 → 审核）
2. 各阶段是否需要不同的专业能力？（技术审查 vs 法律合规 vs 用户体验）
3. 是否存在合规或安全隔离需求？（财务数据不能泄露给内容生成 Agent）

三个问题都是”否”？用一个 Prompt 解决。别为了”Agentic”而 Agentic。

反模式：过早多 Agent 化。 Azure Architecture Center 2026 年文档列出的第一条反模式：“Creating unnecessary coordination complexity by using a complex pattern when basic sequential or concurrent orchestration would suffice.”

某团队做一个”从邮件提取待办事项”的功能。方案 A：一个 Prompt 直接解析。方案 B：Planner → Researcher → Writer → Critic → Reviewer，5 个 Agent。

方案 B 的 Token 消耗是方案 A 的 15 倍，延迟从 2 秒变成 30 秒，准确率反而因为级联错误下降了。

这不是架构，这是炫技。

2.2 好的编排：可靠、可控、可观测

确定需要多 Agent 之后，真正的挑战不是”选哪个框架”，而是怎么设计一个可靠、可控、可观测的编排。

2026 年的生产血泪史证明：框架再强大，糟糕的编排设计照样会崩。好的编排遵循三个原则。

原则一：可靠——假设任何节点都会失败

这正是第一篇讲的 Robustness（鲁棒性）——不是假设系统完美运行，而是假设它会犯错，提前设计容错路径。多 Agent 系统的可靠性不是乘法是除法：单节点 99% 的可靠性，10 个节点串联后只剩 90.4%。

可靠的编排必须做到：

• 状态持久化：每个节点执行完，状态立即 checkpoint 到数据库。节点崩溃后，从断点恢复，不是从头重来。这和数据库事务的 WAL（Write-Ahead Logging）是一个逻辑。
• 超时熔断：每个节点设超时（如 30 秒），超时不响应则标记失败，触发降级或重试。不是无限等待。
• 失败隔离：一个节点失败，不影响其他独立节点。Fan-Out 模式下，三个子任务中的一个失败，另外两个的结果仍然可用，只是汇总时标注”部分数据缺失”。

原则二：可控——人在回路，不是人在旁观

这正是第一篇讲的 **Availability（可用性）**的延伸——不是追求 100% 自动化，而是在关键节点保留人工干预的能力。完全自主的 Agent 是噩梦。2025 年某知名案例：一个自主 Agent 在测试环境误操作，删除了生产数据库。原因是它把”清理测试数据”的指令理解成了”清理所有数据”。

可控的编排必须做到：

• 关键节点人工审核：涉及资金、数据删除、外部通信的操作，必须在执行前暂停，等待人工确认。不是事后审计，是事前拦截。
• 能力边界白名单：每个 Agent 明确知道”我能做什么”，而不是”我想做什么”。查询 Agent 只有读权限，修改 Agent 需要额外授权。
• 紧急停止开关：任何时候，运营人员可以一键暂停整个工作流，不需要等它自己跑完。

这和工业控制系统的安全联锁是一个逻辑——不是信任机器不会犯错，而是假设机器会犯错，提前设计好停机路径。

原则三：可观测——能回答”它当时在做什么”

这正是第一篇讲的 Observability（可观测性）——不是看单个节点是否健康，而是看请求在整个链路中经历了什么。多 Agent 系统最难 debug，不是因为复杂，而是因为错误会跨节点传播——A 节点的幻觉被 B 节点当成事实，C 节点基于 B 的输出做出错误决策。等你发现时，原始错误已经淹没在层层传递中。

可观测的编排必须做到：

• 全链路 Trace：每个请求有一个 TraceID，贯穿所有节点。你能看到”用户问了什么 → A 节点怎么理解 → B 节点查了什么 → C 节点怎么推理 → 最终输出什么”。
• 状态快照：每个节点执行前后的状态变化都记录下来。不是只记输入输出，而是记”它从什么状态变成了什么状态”。
• 决策理由：模型不是黑盒输出结果，而是输出”我为什么这样决策”。这在 2026 年通过推理模型的 thinking trace 或强制输出 reasoning 字段实现。

这和微服务的分布式追踪是一个逻辑——不是看单个服务是否健康，而是看请求在整个链路中经历了什么。

三种模式的实现要点

框架只是工具，原则才是根本

LangGraph、CrewAI、Temporal 这些框架提供了实现上述原则的基础设施——checkpoint、interrupt、tracing。但用不用、怎么用，取决于你的设计。

没有状态持久化的 Pipeline，崩溃后从头重来，不可靠。没有人工审核节点的 Supervisor，自主删除数据，不可控。没有全链路 Trace 的 Fan-Out，错误传播无处追溯，不可观测。

关键洞察：好的编排不是”用了多 Agent”，而是”每个 Agent 的行为都在预期之内”。

反模式：为了演示效果堆砌 Agent。 5 个 Agent 的 demo 看起来很酷，但生产环境每天烧掉 15 倍 Token，错误传播路径复杂到无法 debug。

三、推理缓存：被忽视的降本杠杆

缓存的价值在 LLM 场景下被严重低估。不是因为技术难，而是因为团队没意识到”用户的问题大部分是重复的”。

3.1 三层缓存策略

Exact Match Cache 实现最简单，效果最直接。适合 FAQ、固定模板生成、批量处理中的重复输入。托管网关通常内置，自建的话 Redis 即可。

Semantic Cache 是 2026 年的关键优化。用户问”怎么退款”和”如何申请退货”，在向量空间里距离很近，可以共享同一份缓存结果。Portkey 等托管服务已内置 Semantic Cache，客服类场景命中率 30-50%。自建的话，需要 embedding 模型 + 向量数据库，维护成本不低。

这和传统 CDN 的边缘缓存是一个逻辑——不是等用户打到源站，而是在边缘节点就近响应相似请求。

Prompt Caching 是供应商层面的优化，零成本启用。Anthropic、Google、OpenAI 在 2026 年均支持缓存折扣——读取缓存 Token 按 10% 价格计费。开启方式通常是 SDK 里加一个参数。

一个实际案例：某客服系统系统 Prompt 2000 Token，日均 100 万轮对话。不缓存时，系统 Prompt 每天消耗 20 亿 Token。启用 Prompt Caching 后，缓存读取按 10% 计费，每天节省 18 亿 Token 的费用——降幅 90%。

这和数据库的查询计划缓存是一个逻辑——同样的查询模式，复用已编译的执行计划。

反模式：三层缓存只做了一层。 很多团队只做了 Exact Match，漏掉了 Semantic Cache 和 Prompt Caching，白白浪费 40-60% 的可节省成本。

3.2 缓存设计的三个原则

有了三层缓存，怎么设计才能用好？2026 年的生产实践提炼出三个原则。

原则一：命中优先——先算命中率，再谈技术方案

这正是第一篇讲的 KISS 原则——不是每个场景都值得上复杂方案。判断标准是：同样的输入（或语义相似的输入）在 24 小时内重复出现的概率是否超过 20%？

• 客服 FAQ：重复率 80%+，缓存价值极高
• 个性化推荐：每个用户输入独特，缓存价值极低
• 代码生成：相似需求重复出现，Semantic Cache 有价值

原则二：失效可控——数据更新时，缓存必须知道

这正是第一篇讲的 Maintainability（可维护性）——缓存不是设完就忘，数据变了缓存必须同步变。缓存最怕的不是没命中，而是命中了过期的内容。某电商系统缓存了”商品库存”，用户下单时发现缓存显示”有货”，实际已售罄。

2026 年的做法：

• TTL 兜底：所有缓存设过期时间（如 10 分钟），过期自动失效
• 主动失效：数据更新时，主动清除相关缓存键
• 版本标记：关键数据带版本号，缓存命中时校验版本是否最新

这和传统 Web 缓存的Cache Invalidation是一个逻辑——只是 LLM 场景下，“数据更新”可能是知识库文档变了、Prompt 模板变了、或模型版本变了。

原则三：成本可算——缓存本身也有成本

这正是第一篇讲的 **Scalability（可扩展性）**的延伸——任何优化都有成本，算不清账的优化不如不做。缓存不是免费的：Semantic Cache 需要 embedding 模型和向量数据库，Prompt Caching 需要供应商支持（部分供应商收费）。

判断标准是：缓存的维护成本（基础设施 + 运维人力）是否低于它节省的模型调用成本？

• 日请求量 < 1 万：Exact Match 足够，Semantic Cache 可能不划算
• 日请求量 > 10 万：三层缓存全开，ROI 明显
• 日请求量 1-10 万：先做 Exact Match + Prompt Caching，Semantic Cache 视命中率决定是否上

关键洞察：缓存是成本优化手段，不是技术炫技。算不清账的缓存，不如不做。

四、多租户与资源隔离

当多个业务线共享同一个 LLM 基础设施时，资源隔离和成本分摊就成了必答题。

4.1 配额管理：各用各的，互不干扰

托管网关通常内置配额管理：按虚拟 key 或 API key 分配预算，独立计量、独立限额，月底自动出报表。自建的话，需要在 Gateway 层维护配额状态，复杂度不低。

这和传统云计算的资源配额管理没有本质区别。AWS 的 EC2 有实例限制，S3 有存储配额，LLM 有 Token 预算——都是防止资源滥用的手段。

4.2 优先级队列：谁优先，谁等待

当 GPU 资源紧张时，谁优先？

托管网关通常内置优先级队列，配置即可。自建的话，需要用 Redis 有序集合或类似机制实现调度——这属于”造轮子”。

这和传统操作系统的进程调度是一个逻辑。高优先级进程抢占 CPU，低优先级进程等待时间片。

4.3 成本归因：谁用的谁买单

月底出账单时，需要知道”哪个业务线、哪个功能、哪个用户”消耗了多少 Token。

托管网关通常内置成本归因：每个请求带上标签（team_id、feature_id、user_id），自动汇总出报表。自建的话，需要在 Gateway 层记录并汇总，对接 BI 系统。

这和传统云计算的**成本归因（Cost Attribution）**没有区别。AWS Cost Explorer 按服务、按标签、按项目出账单，LLM 成本分析按模型、按功能、按用户出账单——只是计量单位不同。

反模式：成本黑盒。 “这个月烧了 10 万美元，但不知道是谁烧的”——这种团队离预算失控只差一个爆款活动。

4.4 多租户设计的三个原则

原则一：边界清晰——谁的数据、谁的配额、谁的责任

这正是第一篇讲的 接口隔离原则（I）——每个租户只接触自己的资源，不接触别人的。租户隔离不是技术问题，是组织问题。最常见的错误是按”技术团队”划分租户，而不是按”业务边界”划分。

正确的做法是：每个租户对应一个独立的业务域，有明确的 Owner、独立的预算、独立的数据权限。客服团队的 Agent 不能访问财务数据，内容团队的模型不能调用支付接口——这不是技术限制，是组织边界。

原则二：争抢有序——资源不足时，规则比人情重要

这正是第一篇讲的 Scalability（可扩展性）——资源不足时，不是无限扩容，而是按规则分配。GPU 资源紧张时，谁优先？不能靠”谁嗓门大谁优先”，必须靠预设规则。

2026 年的最佳实践是多层仲裁：

• 第一层：配额内自由使用——每个租户在配额内不受限制
• 第二层：超配额按优先级排队——高优先级租户的超额请求先处理
• 第三层：全局资源紧张时按比例分配——所有租户按配额比例共享剩余资源

这和传统云计算的资源调度是一个逻辑——AWS 的 Spot Instance、Google 的 Preemptible VM，都是”资源紧张时按规则分配”。

原则三：账单透明——每个 Token 都能说出归属

这正是第一篇讲的 Observability（可观测性）——不是月底看总账，而是实时知道谁在用什么。成本归因不是月底算总账，而是实时可见。每个租户应该能随时看到：我今天用了多少 Token、花了多少钱、还剩多少预算。

2026 年的做法：Gateway 层实时推送用量数据到租户仪表盘，接近配额阈值时自动告警。不是月底收到一张”惊喜账单”，而是每天都知道”我还剩多少”。

这和传统云平台的用量仪表盘是一个逻辑——AWS 的 CloudWatch、Azure 的 Cost Management，都是实时可见，不是月底 surprise。

五、落地 Checklist

如果你正在设计 AI 系统的工程架构，先确认这六个问题。每个问题都有合格标准和改进行动：

这六个问题里没有一个是”AI 专属”的。它们分别是：网关设计、缓存策略、负载均衡、架构简化、资源配额、成本归因——软件工程 201 的内容。

换个更容易记的说法：一个 AI 系统的工程架构，本质上就是**“接进来、分出去、省下来、管起来”**——接进来靠 Gateway，分出去靠路由和负载均衡，省下来靠缓存和架构简化，管起来靠配额和成本归因。

这也正是第一篇讲的 SOLID、KISS、DRY 和各种 *ility 在这篇的具体落地——原则没变，只是穿上了 AI 的外衣。

Cloud Native 时代的特殊性

2026 年的 AI 系统几乎全都跑在云上，但 Cloud Native 不是”把模型塞到容器里”那么简单。它带来了三个新挑战。

挑战一：GPU 不是 CPU，K8s 的默认调度逻辑不够用

传统 K8s 调度按 CPU/内存配额分配 Pod。GPU 是整卡分配——你要么拿到一整张 H100，要么什么都没有。2026 年的 Kubernetes 1.34 引入了 DRA（Dynamic Resource Allocation），支持按 GPU 显存粒度分配（如”给我 10GB 显存”而不是”给我 1 张卡”），还支持 MIG（Multi-Instance GPU）——一张 H100 可以切分成 7 个独立实例，服务多个模型。

这和传统云计算的虚拟机资源超售是一个逻辑——不是每个用户都需要整台物理机，按需求切分才能提高利用率。

挑战二：Serverless GPU 的冷启动陷阱

Serverless（如 Modal、RunPod）按需分配 GPU，不用时释放，成本极低。但 GPU 模型加载到显存需要 30 秒到 2 分钟——用户不会等。

2026 年的做法是混合架构：保留一小批”常驻暖机”的 GPU 实例处理实时请求，突发流量路由到 Serverless。这和传统架构的预留实例 + Spot 实例组合是一个逻辑——核心负载用稳定资源，弹性负载用廉价资源。

挑战三：多区域部署的延迟与合规

模型推理需要靠近用户（延迟敏感），但模型权重传输成本极高。2026 年的做法是模型权重就近缓存——在多个区域部署相同的模型实例，用户请求路由到最近的区域。这和 CDN 的边缘节点缓存源站内容是一个逻辑。

EU AI Act 等法规则要求数据不出境——这意味着你需要在每个合规区域独立部署模型实例，不能简单地把全球流量打到美国数据中心。

关键洞察：Cloud Native 没有改变架构原则，只是增加了新的约束条件——GPU 调度、冷启动、区域合规。解决这些约束的方法，和传统分布式系统一模一样：分层、缓存、冗余、就近服务。

六、结语：模式是原则的落地，不是新概念的堆砌

第一篇我们说：AI 没什么特别的，经典原则依然有效。

这篇我们说：AI 确实有些新东西，但这些新东西都可以用熟悉的模式来解决。

LLM Gateway 是 API 网关的语义版本。Agent 编排是分布式计算的三种基本拓扑。推理缓存是 Web 缓存的向量版本。多租户隔离是云计算资源配额的 Token 版本。

没有魔法，只有映射。

高级的架构师设计 AI 系统时，脑子里想的不是”这个框架很酷”，而是”这个模式和当年设计的那个系统很像”。

下一篇是升华篇——当工程基础设施成熟之后，架构师的终极价值是什么？我们会讨论一个更深的问题：当系统从”确定性”走向”概率性”，从”控制”走向”引导”，架构师的思维方式需要怎样进化？

从”怎么做”到”为什么做”——这才是三篇系列的真正终点。

“Gateway 不是新东西，是 Nginx 学会了理解语义。”

“Agent 编排不是新范式，是 MapReduce 穿上了 AI 的外衣。”

“缓存不是新发明，是 Redis 学会了判断相似性。”

“15 倍的 Token 消耗不是技术债，是架构师没有说’不’的勇气。”

“最便宜的优化，是不做不必要的优化。”

本文首发于「谢先生的 AI 深析札记」