AI 应用系统：模型、网关、编排、终端四层架构

先放下架构图，想一个问题：消费者使用 AI 产品时，真正在乎的是什么？

稳定的响应速度、合理的价格、持续改进的功能。但这三件事，本质上在 AI 场景里是同一个问题：把模型的 token 大规模转化为生产力和用户价值。token 是成本，用户价值是产出。架构设计的目标就是提高这个转化率——用更少的 token 产出更多的价值。

能把转化率做高的团队不多。原因不是算法不行，而是基础设施的每一层都互相牵扯：换一个模型要改两周代码、用户量上来后延迟就飙、想加个新能力发现架构接不住。

这篇文章从 token 利用率出发，推导出支撑它的四层架构。目的是提供一个框架，让团队能快速落地，在可控的人力和成本下持续演进。

消费者要什么

消费者不在乎用 GPT 还是 Claude、网关是 Portkey 还是自建。他们在乎四件事：

• 回答快不快：首 token 延迟和总响应时间直接影响留存
• 能力全不全：能不能读图、能不能联网、能不能处理长文档
• 价格合不合理：成本结构最终会体现在订阅费上
• 迭代快不快：上周说的功能这周上线了吗

这些约束直接决定了底层架构应该长什么样。反过来——先画好架构图再看它能满足什么——通常是错的。

四层架构

把消费者的需求翻译成架构语言，得到四层：

这四层不是四个模块，而是四个决策域。每一层解决一组独立的问题，独立选型和替换。分层的价值体现在：替换一层时，不需要重写其他层。

每一层的价值逻辑

引入一层的理由只有一个：没有它，消费者的体验会变差。

模型层提供能力天花板。选闭源 API 还是开源权重、选哪个提供商，决定了能拿到什么水平的推理能力。这一层不应影响其他层的架构——更换模型时，其他层应该零改动。

网关层保护迭代速度，守住稳定性。当团队需要接入第二个模型时，网关层确保这是一行配置的改动，下游零影响。它通过负载均衡让请求在多实例间分摊，避免单点过载。同时提供计费计量和成本量化——每一笔 token 消耗都可以追溯到具体的调用方和应用。

编排层协调多个不同能力的 Agent。编排层做的不是简单链式调用——它需要打通不同 Agent 之间的上下文，理解每个 Agent 擅长什么，把任务拆解后分发到对应的 Agent，最后汇聚结果。它能在大规模下调度成百上千个 Agent 实例协同工作。如果场景只是单次模型调用或固定顺序的几步链式调用，不需要编排层。

举一个公司内部技术支持的场景：员工在 Slack 上描述一个系统问题。理解 Agent 先解析意图，判断这是权限问题还是配置问题；检索 Agent 根据判断结果去查内部知识库和工单历史；解决 Agent 生成答案并自动创建 Jira 工单。编排层让这三个 Agent 共享同一段对话上下文，不需要把用户的问题分别发给每个 Agent 重读一遍。高峰期有几十个员工同时提问，编排层自动调度多个 Agent 实例并行处理，排队、上下文分发、结果汇聚都由编排层完成。

终端层交付最终价值。消费者不关心有几层架构，只关心界面好不好用。终端的职责是把下层能力以低门槛的方式交付。一个设计良好的终端层能掩盖下层所有复杂度，让消费者只感知到"这个工具好用"。

这么多层怎么选

四层是完整形态。但大多数团队从不需要那么多。

过早分层增加复杂度，过晚分层增加重构成本。从当前状态出发，只加当前需要的层。网关层通常值得提前考虑——部署成本低且后续大概率用得上。

成本：token 利用率

成本不是一个"多少钱"的问题，而是每个 token 产出了多少用户价值。

直接成本来自模型层的 token 消耗。API 按量计费，自托管开源模型固定成本高但边际成本低。网关层通过缓存和路由决策减少不必要的调用，同时提供计费和成本量化——每一笔 token 消耗追溯到调用方，让成本不再是黑箱。

隐形成本主要来自人力和状态管理。编排层在内存中维护大量 Agent 上下文会快速消耗资源，这是最容易低估的部分。自建终端同样——一个全功能的 AI 终端（流式渲染、工具调用展示、对话历史）不是小工程，复用成熟产品更划算。

速度成本通常是最贵的一种。新模型出来多久能接入？业务从单次对话扩展到多 Agent 协作要改多少代码？架构的响应速度决定了迭代速度，这项收益可能远超 token 差价。

落地路径

把"先搭基础设施再写业务"的顺序反过来，从消费者端开始：

1. 先用现有产品验证需求 — 不自己建终端，直接用 ChatGPT、Claude 等成熟工具。最快的落地就是直接交付。
2. 必要时加网关 — 当业务需要第二个模型，或需要监控用量时，部署一个网关层。这一步半天内可以完成。
3. 需要时再加编排 — 当任务涉及多个 Agent 协作、需要跨会话上下文或大规模分发时，引入编排层。这一步最需要谨慎——先确认单次调用或简单链式调用确实解决不了问题。
4. 最后考虑自建终端 — 产品验证成功后，如果需要品牌封装或深度定制，再建设自有终端。

每一层都应该等到"没有它不行"的时候再建。

技术革命的共性

这种规模化不是新事物。回顾几次大的技术革命，每个阶段的核心能力都经历了一个"从可用到大用"的过程。

蒸汽机刚发明时，效率只有 1%，勉强能抽矿井的水。几十年后，通过传动系统、标准轨距、钢铁冶炼等配套基础设施，蒸汽动力才真正驱动了整个工业革命——工厂不再必须建在河边，铁路网重塑了物流和城市形态。

电气化也是如此。爱迪生的珍珠街电站 1882 年发电时，只有 59 个客户。真正改变世界的是之后几十年建成的输电网络、变压器标准、交流/直流之争后的统一电网。电是能力，电网是基础设施。

计算机从 ENIAC 到个人电脑再到云计算，也是同一条路。硬件性能飞速提升，但让计算机真正进入每个家庭和企业的，是操作系统、图形界面、互联网、应用商店这些"规模化层"。

AI 正在走同样的路。模型的推理能力（token）相当于当年的蒸汽动力、电力、网络速率。但把 token 从实验室能力变成大规模生产力，需要配套的基础设施——这就是网关、编排、终端这些层要做的事。没有这些层，模型能力再强也只能停留在 API 调用层面，无法嵌入真实的生产流程。

四层架构本质上是在搭建 AI 的电网和操作系统——让 token 这种原始能力变成可大规模使用的基础服务。

参考

本文的框架建立在以下工作的基础上：

1. Emerging Architectures for LLM Applications — Matt Bornstein, Rajko Radovanovic, a16z, 2023 年 6 月。最早系统描述 LLM 应用技术栈的文章，将数据管道、向量数据库、编排框架、模型 API、可观测性等纳入统一架构视图。链接
2. Building Effective Agents — Anthropic, 2024 年 12 月。提出了 workflow 和 agent 的区分，以及五种可组合的工作流模式。链接
3. Generative AI Lens - AWS Well-Architected Framework — AWS, 2025 年 11 月。从可靠性、安全性、性能效率、成本优化等维度给出了生成式 AI 应用的架构最佳实践。链接

系列预告

这是系列的第一篇，目的是搭框架。后续每篇深入一层：

• 第二篇：模型层 — 提供商生态与接入策略（已发布）
• 第三篇：网关层 — 统一 API 管理实践（已发布）
• 第四篇：编排层 — 从框架到协议（已发布）
• 第五篇：终端层 — 自建还是复用（待发布）

下一篇从模型层开始。