从模型调用到生产系统：AI System Design 经验分析

很多 AI 应用的原型都从一个很短的链路开始：用户提问，后端调用模型，再返回答案。这个链路能跑通，说明想法可以继续验证；离生产服务还差一段工程工作。

真实用户带来的问题更具体：流量会不会突然升高？员工能否看到不属于自己的数据？模型服务中断时请求怎么处理？费用由谁控制？系统上线一段时间后，怎么发现答案质量变差？

Piyush Kashyap 的《AI System Design: A Practical Guide to Production AI》用虚构的企业 IT helpdesk 讨论这些问题。文章覆盖需求、容量、架构、安全、检索、工具、模型选择和上线后的运营。本文按这条脉络整理其经验，同时把示例和可迁移的方法分开看。

一、生产 AI 设计的对象，不只是模型

文章对 AI system design 的定义是：为一个 AI 功能设计完整的系统，使它能够可靠、安全且高效地交付结果。模型只是其中一个组件，周围还可能包括认证、数据检索、缓存、使用限制、模型路由、后台任务、监控和恢复机制。

这个定义有一个直接含义：同一个自然语言请求，不一定都应该交给 LLM。

例如，IT helpdesk 可以把“如何连接公司 VPN”交给知识检索和生成流程；查询已有工单状态，需要调用后端 API；创建工单，需要经过授权操作；重置密码，则可能需要身份验证和明确的审批流程。它们都可以出现在同一个聊天界面中，但背后的系统路径并不相同。

按任务选处理路径，比把所有请求都交给同一个模型更贴近文章的做法。生成答案不等于验证身份、执行授权或确认操作成功；这些职责仍要由应用中的规则和业务系统承担。

Vault 中已有的 Harness 笔记也讨论了运行时底座、工具治理和可观测性。这里两者的交集仅在于：模型之外的工程职责会影响系统能否投入使用。

二、需求分析与容量规划应该连在一起

1. 先回答“系统究竟要做什么”

文章把需求分成三类。

第一类是功能需求，例如回答常见问题、搜索内部文档、解释批准的流程、分类支持请求、创建工单、查询工单状态，以及在无法解决时转交人工。

第二类是非功能需求，例如首 Token 延迟、完整响应延迟、可用性、吞吐量、成本和数据安全。文章特别提醒，“响应速度”不能只写成一个模糊目标。首 Token 延迟描述用户何时看到第一段输出，完整响应延迟描述整个答案何时结束，两者影响不同。

第三类是自动化边界，也就是系统明确不能独立完成什么。例如不能泄露其他员工的信息，不能在缺少验证时重置账户，不能虚构工单创建成功，也不能绕过公司安全策略。

这些边界不是上线前的补丁，而会反过来决定系统需要什么架构。只读 FAQ 助手和能够修改账户、执行敏感操作的助手，复杂度并不在同一个数量级。

2. 容量估算不能只看注册用户数

文章使用 Northstar 的示例说明容量估算过程：先根据用户数量和使用频率估算日请求量，再换算平均请求速率，进一步估计峰值流量、并发请求、输入和输出 Token，以及模型成本。

文章列出的估算项包括：

文章用 Little's Law 解释请求速率与并发的区别：平均在途请求数约等于到达速率乘以平均停留时间。对 AI 应用而言，这一点尤其重要，因为模型调用可能持续数秒，Agent 工作流还可能顺序调用多个工具，流式响应也会延长连接的生命周期。

这些计算只是启动阶段的假设。文章中的峰值倍数、Token 量和价格均属于示例，不能直接当作当前供应商报价或通用容量基准。真实系统还需要结合访问日志、压测、供应商 quota 和实际 Prompt 结构进行修正。

三、先按职责拆架构，再选择技术

文章把生产 AI 应用拆成客户端、入口、应用、AI 处理、数据和运营六个逻辑层。图中把请求处理路径与横向运营职责放在一起；这表示职责关系，不意味着要部署成六个独立服务。

客户端层

负责用户输入和结果展示。它不应该保存私有 API Key，也不应该承担特权业务决策。

入口层

负责让请求通过一个受控入口进入系统，通常涉及 API Gateway、身份认证、限流、请求校验、流量过滤和负载均衡。

应用层

这里是业务编排所在的位置：识别请求类型，检查权限，决定走知识检索、业务 API、确定性处理还是人工流程。文章将这一组件称为 orchestrator，但它的重点不是“让模型自主决定一切”，而是把不同处理路径组织起来。

AI 处理层

包括意图分类、语义缓存、RAG、模型路由、AI Gateway 和输入输出安全检查。文章反复强调，不是所有请求都需要所有组件：问候语可以由确定性处理完成，故障排查可能需要 RAG，敏感请求则可能需要授权业务流程。

数据层

包含文档库、向量索引、工单数据、业务数据库和其他应用数据。这里的关键并非“是否使用向量数据库”，而是不同类型的数据是否有合适的来源、权限和同步策略。

运营层

负责日志、指标、追踪、告警、成本控制、部署、回滚和故障恢复。它也是 AI 应用和普通 API 服务差异最明显的地方之一：系统即使返回了 HTTP 200，也可能给出了错误答案。

六层拆分描述的是职责，不是部署拓扑。团队可以先据此划清模块边界，再根据流量、团队规模和故障隔离要求决定是否拆服务。Vault 中的 Agent 生命周期框架也把架构与能力边界放在前面，随后再讨论评估和迭代；这里是结构上的呼应，不是说两套框架完全等同。

四、安全和可靠性不是附录

文章后半部分把大量篇幅用于控制措施，这些内容可以归纳成几个连续的控制点。

入口控制。 认证回答“谁在访问”，授权回答“这个用户允许做什么”，限流既保护系统也控制模型成本。对多租户应用来说，身份和权限不能交给模型从自然语言中自行推断。

输入和输出控制。 Prompt injection 不是单靠改 Prompt 就能解决的问题。输入需要经过校验和安全策略，输出也要检查敏感信息、越权结果和不允许的承诺。隐私保护还应该进入工作流，而不是只在日志系统里做事后清理。

检索与缓存控制。 RAG 需要考虑索引如何从真实来源同步，数据变化后多久可见，分块策略是否适合当前内容，以及缓存何时失效。变化频繁的数据未必适合用静态检索索引解决，缓存也不能只有命中逻辑而没有失效策略。

模型与供应商控制。 不同任务可能使用不同模型，路由可以基于规则，也可以由模型辅助，但路由本身仍需要成本、延迟、质量和安全约束。AI Gateway 可以集中处理凭证、配额、重试、降级和供应商切换，但“更换 endpoint”并不等于完整的故障转移：不同模型的上下文、工具调用和输出格式可能并不兼容。

工具与人工控制。 工具契约需要窄而明确，调用应遵循最小权限，并考虑重复执行的幂等性。涉及账户修改、资金、权限和其他不可逆动作时，人工审批不应只是一个提示语，而应该是工作流中的真实控制点。

队列与扩展控制。 交互式请求和后台任务可以使用不同的处理路径。队列能够吸收突发流量，但同时需要处理背压、重试、死信和重复消费。应用服务的扩容也不等于模型供应商容量同步增加，二者必须分别规划。

这些控制点共同说明：生产 AI 的风险通常不是集中在某一段 Prompt 中，而是分布在身份、数据、工具、供应商和运行时状态之间。

五、运营时要同时看“系统”和“答案”

文章对可观测性的区分很重要。传统服务会关注延迟、错误率、吞吐量、可用性和资源使用；AI 应用除了这些指标，还需要判断回答是否正确、是否使用了合适的来源、是否遵守权限、是否完成了任务，以及是否应该升级给人工。

也就是说，下面两种情况都可能发生：

• 系统运行正常、响应很快，但模型生成了错误答案；
• 模型给出了高质量答案，但请求延迟过高、成本过高或系统不具备可持续运营能力。

因此，监控和评估需要有两条线：一条观察基础设施与请求生命周期，另一条观察 AI 结果质量与业务完成度。知识库中关于 Agent 评估的既有整理也强调，质量评估不能被单一分数或基础设施健康状态替代；不过，具体阈值仍需要由业务场景定义。

文章还将 Prompt、模型、检索配置和工具描述视为生产资产，建议通过测试、回归、持续交付、灰度发布和逐步放量管理这些变化。这意味着一次 Prompt 修改也可能需要像代码变更一样进入验证流程。

六、哪些经验可以迁移，哪些不能直接照搬

从文章的章节安排中，可以整理出一条设计路径：

这条路径把问题定义放在技术选型之前，随后再处理容量、职责划分和风险控制，最后进入质量评估与持续发布。它是对文章经验的归纳，不是要求每个团队按固定顺序完成所有环节；项目可以依据风险和规模调整深度。

它也不能替代具体架构设计，或推导出所有系统都需要六层完整实现、模型路由、队列和多供应商故障转移。

文章的适用边界同样需要保留。它是一篇 Medium 上的经验型长文，使用虚构的 IT helpdesk 作为示例；其中的价格、峰值倍数、目标值和供应商能力没有在本文中独立核验。对于只读、低风险、小流量的功能，完整生产架构可能过重；对于涉及敏感数据和不可逆操作的系统，文章强调的权限、审批、审计和恢复机制则更值得优先考虑。

结语

这篇文章提供的不是一张固定的“生产 AI 架构图”，而是一份从原型走向生产时可以逐项追问的问题清单：系统要完成什么任务？需要承受什么流量？哪些数据和动作受权限约束？模型失败或供应商不可用时如何恢复？如何知道返回的答案真的有用？

把这些问题放在模型选型之前，能够让 AI 系统设计从“调用能力”进入“组织可靠交付”的层面。至于最终使用哪种模型、数据库、Agent 框架或部署方式，仍然应该由业务风险、数据特征、流量、成本和验证结果共同决定。

来源：Piyush Kashyap，《AI System Design: A Practical Guide to Production AI》，2026-10-17。Medium 原文。