AI Platform 不是套个聊天框：我故意让模型限流、Worker 崩溃、记忆过期，才看清生产架构
先说结论
一个能聊天的 Demo 只需要模型、Prompt 和网页；一个敢碰业务系统的 AI Platform，还必须回答身份、权限、审批、任务状态、幂等、记忆、追踪、成本和故障恢复。模型负责提出下一步，平台负责决定这一步能不能做、由谁做、做坏了如何停、重试会不会做两遍、事后能否解释。 为了验证这套边界，我写了一个只用 Python 标准库、零网络调用、零真实凭据的故障注入实验：让主模型路由返回合成 429、让高风险重启动作卡在审批门、让提示词注入在模型和工具执行前被拒绝、让 Worker 在副作用完成但检查点未写入时崩溃，再验证恢复不会重复执行；同时让一条记忆过期，确认它不会进入上下文。macOS 与 Linux 两套 Python 环境均通过六项验收。本文给出我认为能称为「旗舰版」的四平面、一条身份脊柱和一套可落地的生产架构。
图 1：原创 SVG 封面。标题里的「模型限流」是确定性故障注入，不调用任何真实模型或供应商；它验证的是平台控制逻辑，而不是供应商 SLA。
一、问题背景：为什么聊天框一进生产就「露馅」
AI Demo 的路径通常只有三步：用户输入一句话，后端拼 Prompt，模型返回一段字。现场演示很惊艳，因为正常路径像一条笔直公路。但生产环境不是发布会：用户会中途打断，模型会限流，工具会超时，队列会重投，权限会变化，旧记忆会过期，攻击者会把「忽略之前规则」塞进网页或文档，财务还会追问这一轮为什么花了这么多 Token。
这时很多团队会把每个问题都继续塞回 Prompt：
- 用 Prompt 提醒模型「不要泄密」；
- 用 Prompt 要求「高风险操作先询问」；
- 用 Prompt 告诉模型「失败就换另一个模型」；
- 用聊天记录假装任务状态和长期记忆；
- 用应用日志猜一次工具到底执行了几遍。
这相当于让一名很会说话的导游同时兼任机场安检、塔台、机务、会计和事故调查员。导游再聪明，也不应该拥有所有钥匙。自然语言擅长表达意图，确定性系统擅长执行约束；生产架构必须让两者各做擅长的事。
二、问题表现：AI Demo 变成生产系统后的七种怪病
- 身份丢失：模型知道「有人说要重启」，却不知道租户、用户、设备、角色和会话是否可信。
- 降级失控：任何错误都换模型重试，连 401、欠费、策略拒绝也被掩盖，最后重复计费还查不到根因。
- 审批只是聊天文字：模型问「确定吗」，用户下一句含糊的「行吧」就被当作批准；参数已经改变，旧批准仍有效。
- Worker 重投造成双写：工具已成功，进程在写完成状态前崩溃；队列重投后再执行一次，重启变两次、转账变两笔。
- 记忆越多越危险：三个月前的服务名仍被召回，模型语气很坚定地操作一个已经退役的目标。
- 日志很多，因果链没有：Web 层、模型网关、工具服务各有一段日志，却没有同一个 trace ID 串起「谁批准了什么」。
- 成功率看起来很高：被策略正确拒绝的危险请求被算作失败；回答完成却没有解决问题的请求被算作成功。
这些不是再加一句系统 Prompt 就能治好的问题，它们属于平台职责。
三、问题根因：把「对话状态」误当成「业务状态」
聊天消息可以被截断、压缩、重排或重新生成，而业务任务必须有明确状态、版本和所有者。对话里写着「已经执行」不等于数据库里真的只有一次副作用；模型说「用户批准」也不等于有一张不可抵赖、绑定参数且未过期的批准记录。
最小可行 Demo 把所有事情塞进一条上下文；生产平台要反过来做：将体验、控制、执行、数据与证据拆成可独立扩缩、独立授权、独立失败的平面，再用身份上下文和 trace 串起来。
图 2：原创图。这不是按团队名字分盒子，而是按失败边界分责任。某个 Worker 崩溃不应丢掉对话；某个模型限流不应绕过策略；某条记忆过期不应污染执行。
四、旗舰架构：四平面 + 一条身份脊柱
4.1 体验平面：管理一次「轮次」，而不只是一个 HTTP 请求
体验平面包含 Web/App/语音/IM 等渠道适配器，以及 Turn Manager。它把不同渠道统一成一个带身份、语言、设备、附件、截止时间和取消信号的请求封套；负责流式输出、引用、断线重连、语音打断（Barge-in）和重复消息去重。
打个小学生也能懂的比方：老师问问题后，小明已经举手说出一半，老师突然说「题目改了」。一个只会 HTTP 请求的系统会让小明继续把旧答案讲完；Turn Manager 会把取消信号一路传给模型流、检索和工具，让旧轮次停下。取消不是前端隐藏气泡，而是一条跨层传播的 context。
4.2 控制平面：AI Gateway 不是普通反向代理
控制平面包含身份解析、AI Gateway、模型路由、上下文装配、策略引擎、审批、任务编排和预算。普通 API Gateway 关心 URL、认证、限流；AI Gateway 还要理解模型能力、上下文长度、数据分类、Token 预算、供应商地域、流式协议、工具调用和降级资格。
模型可以输出「建议调用 service.restart」，但策略引擎应根据角色、租户、目标范围、风险等级和当前审批，独立返回 ALLOW、DENY 或 REQUIRE_APPROVAL。模型没有最后决定权。
4.3 执行平面：把副作用从聊天进程里拿出来
执行平面包含持久任务队列、Worker、沙盒、工具适配器、MCP Client/Server 边界、租约、超时、并发限制和幂等记录。读健康状态和删数据不能共用相同权限的万能 Worker；高风险工具应进入专门队列，使用短期凭据和严格网络出口。
每次副作用都带 idempotency key。它像快递单号：同一包裹因为网络问题被扫描两次，仓库只能出库一次。没有它，「至少一次投递」的队列会把「至少执行一次」变成「可能执行很多次」。
4.4 数据与证据平面：记忆不是向量库的同义词
这一平面保存会话记录、结构化记忆、检索文档、任务与审批、工具结果、制品、审计日志、指标、Trace、评测和成本。不同数据有不同保留期和权限：用户偏好可以长期保存，原始语音也许数天删除，批准记录需要按审计要求保留，Secret 不应进入 Prompt 和普通日志。
结构化记忆至少包含 source、scope、version、expires_at、敏感级别和删除能力。向量相似只回答「像不像」，不能回答「是否仍然有效」。
4.5 身份脊柱：每一次交接都不能掉身份证
租户、用户、角色、设备、会话和委托链必须从入口传播到模型路由、策略、任务、工具和审计。不要把用户名字拼进 Prompt 后就认为身份已传递；策略判断需要的是经过验证、不可由模型改写的结构化声明。
实验的正常只读路径把这条链完整打印出来：
图 3：真实实验输出截图。合成身份经过策略，路由到本地模拟 provider，只读工具被允许，结果先脱敏再进入最终响应，状态为 COMPLETED。实验没有调用真实模型或工具。
五、一次请求究竟经过什么：像坐飞机一样分工
把「检查存储设备健康并给出建议」作为例子，一次请求应该经历这些交接：
- Channel Adapter 验证渠道签名，生成统一 envelope。
- Turn Manager 建立轮次、截止时间和取消树。
- Context Assembler 只装配该租户、该用途、仍有效的数据。
- AI Gateway 按能力、数据分类、延迟和成本选择模型。
- 模型提出计划或工具意图，不直接拿生产凭据。
- Policy Engine 重新检查工具名、参数、作用域和风险。
- 需要批准时，任务持久化为 WAITING_APPROVAL，前端展示精确影响。
- Worker 领取租约，在沙盒里用短期凭据执行，写入幂等结果。
- Sanitizer 过滤工具输出；Turn Manager 流式返回。
- Trace、审计、Token、成本和业务结果用同一个请求标识归档。
图 4：原创图。就像坐飞机：售票、安检、登机口、机组和行李追踪是不同岗位。把所有岗位交给「会说话的机长」不会更智能，只会让事故无法隔离。
这里最重要的设计原则是：每一跳都传递结构化上下文，每一个副作用都重新授权。 不能因为入口鉴权过一次，就默认模型生成的任意工具参数都可信。
六、故障一：模型 429，什么可以降级，什么必须停
平台收到 429 或短暂 5xx 时，可以在有限重试预算内切换兼容模型；收到 401、无效凭据、余额/合规拒绝时应立即暴露根因。把所有错误都包装成 fallback，会让配置错误变成贵而慢的幽灵故障。
图 5：真实实验输出截图。主路由合成返回 429，备用路由返回 200；重试预算 1，明确记录降级原因，并注明认证错误不具备降级资格。
图 6：原创图。路由不能只看「哪个模型在线」，还要看数据能否离开当前区域、目标模型是否支持工具/结构化输出、剩余预算和截止时间。
一个可审计的路由决策至少记录：候选集、被排除原因、最终路由、模型/Prompt 版本、重试次数、每次错误类型、Token 与成本。否则「系统自己换了模型」会成为所有质量波动的万能借口。
七、故障二：审批门必须在模型外面
高风险写操作不能靠模型问一句「你确定吗」。批准记录要绑定具体工具、规范化参数、资源范围、申请人、批准人、过期时间和一次性 nonce；计划参数发生变化时，批准自动失效。
图 7：真实实验输出截图。即使合成身份具备平台管理员角色，策略仍返回 REQUIRE_APPROVAL；任务持久化等待，工具没有被调用。角色够高不等于免审批。
图 8：原创图。权限矩阵只是起点；生产还要叠加租户、资源标签、时段、变更窗口、风险分和职责分离。模型只提交申请，确定性策略盖章。
审批 UI 也不能只显示模型总结「将优化服务」。它应展示真正参数差异、影响对象数量、回滚动作、证据链接和超时时间。批准的是一张明确的施工单，不是给模型一张空白授权书。
八、故障三：Prompt Injection 不是 Prompt 能单独解决的
提示词注入可以来自用户，也可以藏在网页、邮件、PDF、代码注释和工具返回值里。它本质上是「不可信数据试图伪装成控制指令」。只在系统 Prompt 里写「不要听坏人的话」，就像在校门贴一张「坏人不得入内」——有提醒价值，但不是门禁。
图 9：真实实验输出截图。合成输入同时包含覆盖指令和 Secret 外泄意图，策略返回 DENY；模型未调用、工具未调用、Secret 未写日志。实验中的关键词策略只用于演示控制点，不能冒充完整生产防护。
生产防线应分层：标记内容来源与信任级；把检索文本放进明确的数据边界；工具采用 allowlist 和参数 schema；读取与写入凭据分离；敏感操作要求批准；限制网络出口；对输入、计划、工具结果和最终输出分别扫描；用红队样本持续评测。即使模型被诱导，策略和执行平面仍应让它「说错但做不了错事」。
九、故障四：Worker 在最危险的一毫秒崩溃
分布式系统最棘手的时刻是：工具已经产生副作用，但 Worker 还没来得及把任务写成 COMPLETED 就崩溃。队列只看见租约超时，于是重新投递。没有幂等记录时，第二个 Worker 会再做一次。
图 10：真实实验输出截图。第一次执行已产生 1 次合成副作用后崩溃；任务从 before_tool 检查点恢复，第二次调用命中幂等记录，最终副作用仍是 1，任务完成。
图 11：原创图。对话可以关闭，持久任务仍有状态。生产还应有 CANCEL_REQUESTED、DENIED、FAILED、COMPENSATING 等状态，并定义谁能转换、超时如何处理。
幂等键应由「租户 + 业务任务 + 工具 + 规范化参数 + 版本」产生，并和结果原子落库。对于无法天然幂等的外部系统，要使用对方支持的请求键、业务唯一约束或补偿事务。仅在 Worker 内存里放一个 already_done = true，进程死后等于没放。
十、故障五：记忆过期，比没有记忆更危险
模型忘记用户偏好会让人失望；模型记住已退役服务、旧联系人或过期权限会造成事故。记忆系统必须同时回答：谁说的、对谁有效、哪个版本、何时过期、是否可删除、召回时为何相关。
图 12：真实实验输出截图。有效记忆带来源和版本，过期记忆计数为 1 且没有进入 Prompt；记忆明确可删除。
图 13：原创图。记忆像图书馆借书，不是纹身：要有来源卡、借阅范围和归还日期。向量库负责找相似书，策略负责决定这本书现在能不能借。
建议把记忆分为：会话工作记忆、用户确认的长期偏好、从行为推断的低置信信息、组织知识和任务制品。推断内容不能悄悄升级成事实；用户纠正后要生成新版本并压制旧版本；涉及人员、权限和生产资源的记忆应更短、更严格。
十一、可观测性：不要只看最终答案，要看「为什么这样决定」
AI 请求的延迟不是一个数字。TTFT（首 Token 时间）回答「多久开始说话」；完整响应时间回答「多久说完」；工具型任务的 E2E 回答「多久真正完成事情」。就像外卖：骑手接单很快不等于饭送得快，App 显示已送达也不等于你拿到了正确餐品。
一个 trace 应串起入口、检索、每次模型尝试、策略决定、审批等待、工具执行、重试、流式返回和最终业务结果。Token、成本和模型版本是 span 属性；Prompt/工具内容按数据等级脱敏或只存哈希，不能为了排障制造新的泄密库。
图 14：真实实验输出截图。故障实验把 ai.request、gen_ai.chat 与 tool.execute 放进同一瀑布；时长很小是因为全部为本地合成逻辑，不代表真实模型延迟。
图 15：原创图。平台看板至少要同时回答快不快、贵不贵、有没有解决、有没有越权。单独优化 Token 或延迟，会把系统带到错误方向。
推荐指标分四组：
- 体验：TTFT、E2E、取消传播时间、流中断率、用户重试率。
- 推理：模型错误率、fallback 率、上下文大小、输入/输出 Token、结构化输出校验失败。
- 行动：工具成功率、审批等待、重复副作用、超时、补偿成功率。
- 结果与风险：任务解决率、正确拒绝率、人工接管率、每个成功结果成本、注入/越权拦截率。
「正确拒绝」应该算安全成功，不该污染业务成功率；回答一段漂亮文字却没完成目标，也不能只因 HTTP 200 就算成功。
十二、MCP 的位置：协议边界不是权限边界
MCP 让 Host、Client、Server 之间用统一协议暴露 tools、resources 和 prompts，极大降低集成成本。但「能发现工具」不等于「有权调用工具」。MCP Server 描述的是能力，平台仍要在调用前做租户隔离、参数校验、风险分级、批准和网络策略。
把 MCP 想成统一插座：插头规格统一后，台灯和电钻都能接上；插座不会自动判断小学生能不能拿电钻。权限、漏电保护和施工许可仍是房子的责任。
高风险 Server 最好单独进程/容器、最小凭据、固定出口，不能把文件系统、Shell、生产控制面和个人数据打包进一个「万能 MCP」。工具清单也要版本化；模型看到的 schema、策略校验的 schema 和 Worker 实际执行的版本必须一致。
十三、部署形态：无状态边缘扩容，有状态核心明确所有权
图 16：原创图。横向扩容不是把每个盒子复制三份；关键是任务只有一个租约持有者、副作用只有一份幂等记录、审批和审计有一个可信事实源。
推荐的物理落地可以是：Channel/Turn/Gateway/Policy/API 保持无状态，多副本部署；任务、审批、幂等键进入事务数据库；队列负责租约和重投；Worker 按工具风险拆池并沙盒化；大制品进对象存储；Memory/RAG 使用带租户过滤和版本元数据的存储；OpenTelemetry Collector 汇聚 traces/metrics/logs，审计流进入更严格的不可变存储。
早期团队不需要一上来拆成二十个微服务。四平面是责任边界，可以先在模块化单体中实现；当扩缩、权限或故障域出现分歧时再拆进程。为了「看起来旗舰」而提前分布式化，只会先收获网络超时和一致性问题。
十四、从 Demo 到平台：一条现实的 90 天路线
第 1—30 天：先把刹车装上。 统一身份 envelope；工具 allowlist 与 JSON Schema；读写凭据分离；高风险批准；全链路 trace ID；模型路由记录；建立最小红队集。此阶段宁可少接工具，也不要让模型持有万能 Token。
第 31—60 天：把任务从对话中剥离。 建持久状态机、租约、超时和 idempotency；实现取消传播；结构化记忆加来源/版本/TTL；区分可重试错误；按结果而非 HTTP 码定义成功。
第 61—90 天：用证据运营。 建黄金任务集和离线评测；上线前 shadow/canary；按租户、模型、工具看成本与质量；演练 provider 429、队列积压、Worker 崩溃、审批超时、Memory Store 不可用和审计链路中断；把恢复结果写进发布闸门。
每阶段只在有清晰痛点时增加组件。一个 10 人内部工具和面向多租户的企业平台可以共享原则，但不该复制相同部署规模。
十五、可复现实验：六个 PASS 证明了什么
本文的 Python 故障注入脚本 只使用标准库中的 SQLite、哈希、JSON 和计时器；不访问网络、不调用真实模型/工具、不加载 Secret。Windows 11 可运行：
py -3 ai_platform_fault_lab.py --clean
Ubuntu 26.04 与 macOS 26 可运行：
python3 ai_platform_fault_lab.py --clean
它验证的是控制边界，不是模型质量、生产安全认证或性能跑分。完整说明见 README，结构化 traces.jsonl 和 metrics.json 也可直接下载检查。
图 17：真实实验输出截图。只读身份链、429 有界降级、高风险审批、注入前置拒绝、崩溃续跑去重和过期记忆排除全部通过；成本为 0，因为没有外部调用。60% 的 successful_requests 不含一次正确拒绝和一次等待审批，恰好说明「成功率」必须按状态解释。
相同脚本已在两个不同平台的 Python 环境执行，验收项一致；Trace 的微秒/毫秒值会因运行环境变化，属于预期现象。生产实现需要把这里的玩具关键词策略换成分层控制，把 SQLite 换成可靠共享状态，并把模拟工具换成最小权限适配器。
十六、Q&A
Q1：用了最强模型，是否可以少做一些平台控制？
不可以。模型能力提高会减少某些推理错误，却不会替你提供事务、身份、审批、幂等和审计。跑得更快的车更需要可靠刹车，而不是更少刹车。
Q2：AI Gateway 和普通 API Gateway 到底差在哪？
普通网关主要处理路由、认证、配额和协议；AI Gateway 还处理模型能力与版本、上下文窗口、数据地域、Token/成本预算、流式事件、工具调用、fallback 资格和模型级可观测性。两者可以部署在相邻层，也可以共享基础设施，但责任不同。
Q3：为何不让模型直接判断 Prompt Injection？
模型可以作为一个检测信号，但不能成为唯一裁判。攻击内容和正常文档可能高度相似，模型也会被同一上下文影响。确定性 allowlist、参数 schema、权限、沙盒、出口限制和人工审批提供模型之外的硬边界。
Q4：所有工具调用都要人工审批吗？
不需要。只读、低风险、可撤销且作用域小的操作可以策略自动允许；高风险、不可逆、跨租户或影响面大的操作才进入审批。审批过多会产生「闭眼点同意」的疲劳，所以风险分级必须准确。
Q5：Exactly-once 能彻底解决重复副作用吗？
端到端 exactly-once 很难承诺。工程上更现实的是至少一次投递 + 幂等执行 + 唯一约束 + 可审计结果；对无法幂等的动作准备补偿或人工对账。文章中的实验验证的是「重投不重复该副作用」。
Q6：RAG、长期记忆和聊天历史有什么区别？
聊天历史记录本轮发生了什么；RAG 从外部知识源找当前问题的材料；长期记忆保存跨会话仍有价值、带来源和生命周期的信息。三者可以共同进入上下文，但权限、保留期和置信度不同。
Q7：MCP Server 自带权限说明，平台还要再检查吗？
要。Server 的能力描述不能替代调用方的身份和策略；远端 Server 也可能升级或被攻陷。平台应钉住版本、限制工具、验证 schema、设置网络出口和超时，并在每次高风险调用前重新授权。
Q8：是否必须上微服务、Kubernetes 和向量数据库才叫 AI Platform？
不必须。旗舰首先是责任与证据完整，不是组件数量。模块化单体 + 事务数据库 + 可靠队列也能实现四平面边界；负载、团队和合规真的需要时再拆。
Q9：如何衡量平台是否「真的有用」？
用任务结果：一次解决率、人工节省时间、正确拒绝率、事故数、每个成功任务成本和用户复用率。BLEU、模型榜单或 Token 数只能解释局部，不代表业务完成。
Q10：这份架构最先应该实现哪三件事？
身份 envelope、工具前确定性策略、贯穿请求/模型/工具的 trace ID。它们分别回答「谁在做」「能不能做」「到底发生了什么」，是后续审批、幂等、记忆和评测的地基。
继续阅读：把旗舰架构拆成五场生产实验
本文负责给出全局边界；下面五篇把最容易出事故的控制点逐一拆开，并提供可复现的故障注入与验收证据。完整导航也可以回到 AI Platform 架构实践阅读地图。
- 一次任务为什么执行两遍：Worker 崩溃、幂等与持久任务
- 你都喊停了，AI 为什么还在执行：Turn Manager、取消传播与语音打断
- 429 就换模型？AI Gateway 路由、降级与熔断实战
- AI 记住你，不一定是好事：结构化记忆的完整生命周期
- 别只测“回答对不对”：AI Platform 生产发布闸门
十七、参考资料与架构底线
- NIST AI Risk Management Framework
- OWASP Top 10 for LLM / GenAI Applications
- Model Context Protocol：Architecture
- OpenTelemetry Generative AI Semantic Conventions
- HumanLayer：12-Factor Agents
这套架构可以少组件、可以先做成模块化单体，也可以随着规模演进；但有一条底线不能打折：模型永远不应同时成为意图解释者、权限批准者、副作用执行者和事故审计者。模型提出建议，平台承担责任。