《互联网产品的 AI 架构·模型接入与能力边界》序

从两套书结束的地方开始

前两套书讲的是同一款产品的两种视角。

《互联网产品的服务端架构》从机房看「回声」：账号、内容、订单、支付、流量与容量。它关心的是请求进来以后，服务端怎样在可接受的延迟里给出可解释的结果。《互联网产品的客户端架构》从用户手里的设备看它：状态归属、路由、缓存、离线与版本分裂。它关心的是同一份事实到了端上，怎样在不可靠的环境里保持一致。

两套书写完，还有一大块空白：模型。

模型不属于服务端，也不属于客户端。它像一个外部供应商，按 token 计费、按能力承诺、按版本变化，而且经常在不可预期的时候变慢或不可用。产品把它接进来以后，原来的很多默认假设都不成立了：

• 一次请求的成本不再只由机器数量决定，而由用户输入的长度和模型输出的长度决定。
• 一次请求的延迟不再稳定，首 token 可能很快，完整回答可能要十几秒。
• 一次请求的结果不再确定，同一输入可能得到不同输出。
• 一次故障的影响面不再清晰，某个模型不可用可能只影响一类功能，也可能影响全部。

这些差异不是“接入一个 SDK”能解决的。它们改变的是边界：谁定义能力，谁承担失败，谁为成本负责，谁能在出问题时把行为降下来。这就是这本《互联网产品的 AI 架构》要讨论的问题。

为什么“接入模型”会变成架构问题

大多数团队第一次接入模型，路径都差不多：找一个模型，写一段提示，把结果塞进界面，灰度一小部分用户。演示效果通常不错，问题在上线后出现。

常见的问题有五类。

第一类是成本失控。演示时只有几十个请求，成本可以忽略；上线后请求量上来，长上下文、重复调用、失败重试叠加，账单可能比预估高出一个数量级。更麻烦的是，账单出来时已经无法归因到具体功能、具体租户或具体模型。

第二类是延迟不可控。同一个按钮，有时一秒出结果，有时八秒没反应。用户不会等，连续点击会触发重复请求，重复请求又进一步抬高延迟。团队以为是模型慢，实际上是排队、重试和超时预算没有设计。

第三类是失败没有边界。模型服务超时，代码直接抛异常，页面白屏。或者模型返回了不符合格式的内容，解析失败，整个链路中断。团队没有定义“这个能力不可用时产品应该是什么样”，于是每次故障都变成一次线上事故。

第四类是数据出了域。为了调试方便，把用户私信原文、订单号、手机号一起塞进提示词；为了效果更好，把检索到的内部文档直接发给第三方模型。等到合规评审时，才发现没有任何字段级白名单，也说不清数据去了哪个区域。

第五类是变更无法回滚。提示词改了一个词，效果变好还是变坏没人知道；模型从 A 换到 B，行为差异没有记录；临时降级开关加了三个月，没人敢关。系统的行为在悄悄变化，但没有版本、没有评审、没有退出条件。

这五类问题有一个共同点：它们都不是模型能力问题，而是架构问题。模型再强，也不能替产品决定“失败时给用户看什么”；模型再便宜，也不能替团队决定“这个功能值不值得花这么多钱”。

三套书的分工

把三套书放在一起看，分工是清楚的：

三套书共享同一个案例「回声」，但各自回答不同的问题。服务端问“这个请求怎么处理”，客户端问“用户看到什么”，AI 架构问“这项能力凭什么可以对外承诺”。

这不是把三本书简单叠加。同一件事在三本书里会呈现不同侧面。比如“重试”：服务端关心重试会不会放大流量，客户端关心重试会不会重复提交，AI 架构关心首帧之前和首帧之后的重试语义完全不同。把三个视角放在一起，团队才不会在评审会上各说各话。

这套书的四个判断

本书建立在四个判断上。后面的每一章，都是这四个判断的展开。

判断一：能力先于模型。 产品对外承诺的是能力，不是模型。用户点“智能回复”，他要的是一段得体的回复，不是某个厂商的某个版本。能力必须有输入、输出、质量、延迟、成本与失败语义六面契约；模型只是实现能力的一种资源，可以替换、可以并存、可以降级。

判断二：网关是稳定层。 模型会换、供应商会变、区域会调整，但业务方不应该跟着改。网关负责认证、配额、路由、缓存、观测与审计，把这些变化挡在业务之外。网关不负责业务语义，也不承担长事务；它必须无状态、可水平扩展、可独立降级。

判断三：失败是常态。 模型服务会超时、会限流、会返回不合格式的内容，供应商会变更版本，区域会出故障。产品必须在设计阶段就回答：这个能力不可用时，是缺失、变弱，还是阻塞？没有答案的能力，不应该上线。

判断四：可计量才可治理。 一次请求花了多少、用了哪个模型、结果是否被采纳、失败发生在哪个阶段，必须能被记录和查询。没有计量，成本无法归因；没有观测，质量无法讨论；没有版本，变更无法回滚。

AI 能力与传统下游服务的五个差异

如果把模型当成普通的下游服务，会漏掉五件事：

这五个差异决定了架构的默认值必须改变。

输出不确定，意味着校验不能省。契约必须包含“输出不符合格式时怎么办”，而不是假设模型一定按提示返回。

成本随输入增长，意味着上下文不是越多越好。把整篇文档塞进提示，效果可能更好，但成本可能翻十倍；预算必须成为请求的一部分。

延迟分阶段，意味着“平均延迟”没有意义。用户感受到的是首字延迟，系统承受的是完整生成时间；两者要分别预算、分别观测。

版本不可锁定，意味着变更需要灰度与回滚。模型名称没变，行为也可能变；提示与模型的组合必须被记录。

失败混合，意味着错误必须归一。把提供方的几十个错误码直接透给业务方，最后没有人能写出正确的重试逻辑。

这五条差异会在卷一的不同章节反复出现。它们不是模型厂商的缺陷，而是这类服务的固有属性；架构的任务是把这些属性关进可管理的边界里。

一次接入事故的完整复盘

为了说明“架构问题”长什么样，先看一次典型事故。细节是构造的，但组合在真实项目里很常见。

「回声」的智能回复上线两周，效果不错。第三周，运营在活动页加了一个“生成祝福语”的入口，复用了同一个能力和同一个提示模板。

问题在一周后集中出现：

• 祝福语请求的输入很短，但输出很长，单次成本是私信回复的三倍。
• 活动页没有做频率限制，用户连续点击会重复生成。
• 峰值时网关把两类请求混在一个队列里，私信回复的首字延迟从 800 毫秒涨到 3 秒。
• 为了“提升效果”，有人把提示模板改长了；改完后没有记录版本，回滚时找不到旧模板。
• 模型限流时，代码直接返回空字符串，前端显示一个空的输入框。

事后看，这五个问题分别属于成本、配额、隔离、版本与失败语义。它们中的任何一个，都可以在架构层面提前处理：

• 能力契约里写明输出上限与单次成本预算。
• 网关按能力与租户做配额，活动页单独限流。
• 关键能力与营销能力使用不同的队列或优先级。
• 提示模板进入版本库，变更走灰度。
• 明确定义模型不可用时的用户可见行为。

没有这些边界，团队的最后结论往往是“模型不稳定”。但模型只是按自己的方式工作：输入长、输出长、峰值会排队、限流会拒绝。真正缺失的是产品对能力的承诺。

为什么还是「回声」

「回声」是一个为技术书稿构造的假想产品：内容流、私信、站内下单，三个足够典型又足够简单的面。前两套书已经把它从服务端和客户端拆过一遍，这一套继续用它，有三个好处。

第一，读者不需要重新理解业务。智能回复、搜索重排、长文摘要、内容审核、客服辅助，这些能力都能自然长在「回声」上，不需要为了举例再造一个产品。

第二，问题可以跨层对照。同一个“智能回复”，服务端关心它怎样排队与限流，客户端关心流式文本怎样渲染与取消，AI 架构关心它的能力契约、模型路由、成本预算与降级路径。三本书对照着读，能看到同一件事在不同层的约束。

第三，失败可以具体。书里的每类事故都对应「回声」的一个真实场景：私信里的重复回复、审核队列的积压、合作方租户的数据串扰、账单上的异常峰值。具体场景比抽象原则更容易记住。

书中出现的用户量、请求量、延迟、成本与比例，除明确标注为本机测试输出外，都是案例假设值，用来演示推导过程，不是任何真实系统的实测。

这一卷的边界

卷一《模型接入与能力边界》只做一件事：把“调用一次模型”变成“承诺一项能力”。

它讨论能力契约、模型选型、网关、路由、流式、提示、结构化输出、延迟与成本、缓存、降级、安全与观测。第 13 章把前面的模块组合成一条可运行的基线。

它不讨论以下内容：

• 模型训练、微调与推理引擎优化。这些属于站内的 AI 推理与 LLMOps 专题。
• 推理性能与成本工程：调度、缓存、压缩替代、容量与成本归因。这是卷二的内容。
• 多能力协同：交接契约、执行图、失败传播与编排级治理。这是卷三的内容。
• 平台化、多团队治理与长期运营。这是卷四的内容。
• 具体厂商的模型对比与价格表。价格与能力变化太快，写进书里很快过期；本书只保留判断方法。

把这些边界画清楚，是为了让每一卷都能独立成立。卷一只需要读者理解一次请求的生命周期，不需要先懂性能优化或编排。

与站内其他内容的分工

站内已经有不少 AI 相关专题。本书与它们不是替代关系：

• AI 推理专题讲引擎、量化、KV Cache、GPU 调度与集群。本书不重复这些，只在需要时引用它们的延迟与成本口径。
• LLM 应用专题讲 API 调用、提示技巧、RAG 入门与 Agent 入门。本书假设读者已经会调用模型，重点放在“接进产品以后”的架构问题。
• LLMOps 专题讲评测、灰度、可观测工具。本书讨论这些能力应该放在链路的哪一层，以及它们怎样与网关、缓存、降级配合。
• MCP 专题讲协议、SDK 与工具生态。本书只讨论工具调用的授权边界与副作用分级。

如果你已经读过这些专题，本书会帮你把它们放进一个统一的产品架构；如果你没读过，本书也会在需要的地方给出最小必要的背景，并指向对应专题。

写给谁

这本书主要写给三类读者。

正在把 AI 接进产品的工程师。 你可能已经能调通模型，但不确定网关该做什么、失败该怎么处理、成本该怎么算。卷一会给你一套可以直接落地的边界与模块。

负责架构评审的技术负责人。 你需要判断一个 AI 方案是否成立，而不是自己写代码。书里的判据、清单与反例，可以直接用于评审会。

产品与运营同学。 你不需要读代码，但需要理解为什么“再加一个模型”不是免费的，为什么“失败时降级”必须在需求阶段决定。每篇末尾的「常见错误与边界」是为你准备的。

读这本书需要的基础不高：了解 HTTP 请求与响应的基本概念，能读懂 TypeScript 或任意一门现代语言，知道什么是超时、重试与缓存。不需要机器学习背景，也不需要部署过 GPU 集群。

关于代码与实验工程

书里的代码不是伪代码。每一段标记了 // file: 的代码块，都与实验工程 ai-lab 中的文件逐字节一致；标记了 // verify: 的命令，都可以在本地真实运行。

技术栈是 TypeScript + Node 26，零第三方依赖，只使用 node: 内置模块。选择它的原因不是 TypeScript 最适合 AI，而是它足够轻：不需要安装依赖、不需要编译、不需要容器，读者可以在几分钟内把整卷代码跑起来。架构判断与语言无关，代码只是把判断固定下来。

所有模型调用都由确定性 mock provider 完成，不依赖任何真实 API。这意味着书里的测试在任何机器上都能复现；也意味着书里不会给出“某个真实模型在某个榜单上的分数”这类很快过期的数字。

关于时间、版本与数字

写作时的环境是 Node 26.5.0。书里的命令、导入方式与类型剥离限制都按这个版本验证。如果你用的是更早的版本，部分示例可能需要调整。

书里的数字分两类：

• 本机运行输出：会明确写出命令、输出与执行时间，读者可以复现。
• 案例假设值：用于演示推导，例如“假设日活 100 万、人均 3 次调用”，不构成任何容量或成本承诺。

没有真实跑过的数字，不会写成“实测”。这条规则看起来保守，但它是技术书最基本的诚实。

三个常见误解

在开始之前，先拆掉三个常见误解。

误解一：接入模型就是调 API。 调 API 是第一步，后面还有能力定义、配额、路由、缓存、降级、观测与治理。一个只有 API 调用的功能，可以演示，但不能承诺。

误解二：模型越强，架构越简单。 模型越强，能做的事越多，需要约束的边界也越多。强模型不会自动处理超时、成本、租户隔离与版本回滚；这些问题与模型能力正交。

误解三：架构是上线前才需要考虑的。 能力契约、失败语义与预算，恰恰是需求阶段的问题。等到上线后再补，通常意味着要改产品行为、改提示、改数据结构，成本高得多。

这三个误解的共同点，是把“工程实现”当成了“架构设计”。实现回答“怎么做”，架构回答“为什么这样做、边界在哪、失败怎么办”。

读这套书需要什么基础

最低要求只有三条：

1. 理解 HTTP 请求与响应的基本结构，知道状态码、超时与重试是什么。
2. 能读懂 TypeScript 或任意一门现代语言，不需要精通。
3. 知道缓存、队列、限流这些词的大致含义。

不需要机器学习背景，不需要训练过模型，也不需要部署过 GPU。卷一讨论的是产品与模型之间的边界，不是模型内部。

如果你有服务端或客户端架构经验，会更容易理解“边界”与“失败语义”的讨论；如果没有，书里会在需要的地方补最小背景。

写作与验证方式

这本书的写法与大多数 AI 书不同：先写判据，再写代码，最后用测试把两者对齐。

每一节的结构大致是：先描述一个具体场景与失败，再给出判断维度或分类，然后用一段可运行代码把判断固定下来，最后用测试覆盖边界。文章里的代码块不是示意，而是实验工程里的真实文件；标记了 // verify: 的命令都可以直接执行。

验证分三层：

• 结构验证：篇数、front matter、导航、代码块闭合。
• 代码验证：书稿代码块与实验工程逐字节一致。
• 运行验证：node --test 全绿。

这三层验证不能证明观点正确，但能保证书里的代码不是“看起来能跑”。对技术书来说，这是最低标准。

最后

AI 架构最容易犯的错误，是把模型当成一个普通的下游服务：加个超时、加重试、加个开关，就以为接好了。模型不是普通下游，它的输出不确定、成本随输入增长、能力随版本变化，而且经常无法解释。

因此，这本卷子不从“怎么调模型”开始，而从“产品到底承诺了什么”开始。把承诺写清楚，网关、路由、缓存、降级与观测才有判断标准；否则，所有的技术选择都只是在猜。

如果你读完卷一，只能带走一句话，希望是这一句：

先定义能力，再选择模型；先定义失败，再谈体验。

下一卷会从知识与检索开始，讨论当模型需要“知道得更多”时，架构要付出什么代价。