7 篇博文 含有标签「llm-infrastructure」

多租户 SaaS 在十年前就解决了数据隔离问题。Postgres 中的行级安全性（Row-level security）、每个租户的加密密钥、范围限定为租户前缀的 S3 存储桶策略——到 2018 年，这套方案已经非常成熟，以至于当审计员询问“向我展示客户 A 的数据如何无法触及客户 B 的数据”时，只需要提供一份一页纸的回答，并在每一层附上引用即可。AI 功能悄然重新引入了这个问题，而现在的答案不再只有一页纸。

有趣的部分并不是 AI 破坏了隔离。有趣的是它在 哪里 破坏了隔离：不是审计团队守卫了十年的数据层，而是没有人画在图表上的四个新层级。提示词缓存前缀（Prompt cache prefixes）以跨请求共享 KV 状态的方式，将首字生成时间（time-to-first-token）变成了一个侧信道。在聚合客户数据上训练的微调模型会记住特定租户的措辞，并将其反馈给错误的客户。当威胁模型要求物理分离时，嵌入索引（Embedding indexes）却通过查询过滤器进行逻辑分区。跨请求的 KV 缓存重用创建了时间信道，而当“共享推理没问题”被视为一种合理的捷径时，没有人对此进行过威胁建模。

本篇文章讨论了发生了哪些变化，以及当你认真对待这个问题时，这种规范看起来是什么样子的。

一个每步成功率为 95% 的智能体并不是一个 95% 可靠的智能体。将 20 个步骤串联起来，端到端的完成率就会下降到 36%。这是大多数团队在智能体上线生产环境后才发现的算数逻辑，也是为什么这么多“运行良好”的原型在真实流量涌入的瞬间就会陷入停滞。解决方法不是更好的提示词或更大的模型，而是一个乏味的分布式系统基础设施，大多数 AI 团队在第三次宕机被迫应对之前都会试图避开它。

这种基础设施就是“持久化执行”（durable execution）——这是一种让多步骤工作流在崩溃、重启和局部故障中幸存且不丢失进度的准则。这并不是什么新鲜主意。Temporal、Restate、DBOS、Inngest 和 Azure Durable Task 已经为此推销多年。2026 年的新变化是，每个严肃的智能体框架都已悄然承认持久化执行是入场券：LangGraph 现在内置了 PostgresSaver 检查点，OpenAI Agents SDK 暴露了 resume（恢复）原语，Anthropic 的 Managed Agents 运行在内部的持久化基座上。如果你的智能体架构仍然依赖 Celery 队列和乐观主义，那么你是在 2026 年解决一个整个行业在 2024 年就不再假装视而不见的问题。

本文探讨的是无状态 LLM 与必须包装它的有状态工作流引擎之间的架构接缝。接缝之处正是可靠性所在，也是大多数团队目前编写 Bug 的地方。

这个 Demo 只需 20 分钟就能构建完成。你粘贴一个 URL，大语言模型（LLM）读取 HTML，结构化数据就从另一端输出了。这感觉就像网页数据提取的未来已经到来。

然后，你以每小时 1,000 页的速度运行它。成本飙升，屏蔽不断积累，提取出的字段开始以一种看起来不像错误的方式发生偏移——它们看起来像正常数据，直到你的下游流水线已经默默地摄取了三周的垃圾。“LLM 读取页面”的模式并没有错，只是它的定价更适合原型的吞吐量。

智能体（Agentic）网页提取确实解决了传统爬虫无法解决的问题。但要将其扩展到概念验证（PoC）阶段之后，需要理解一组与大多数团队预期不同的故障模式。

大多数 AI 产品都是为单一用户、单一意图、单一对话线程和单一身份构建的。当产品是个人生产力工具（如写作助手、代码补全引擎、摘要生成器）时，这运作得足够好。但当团队开始协作使用 AI 时，情况发生了变化：产品会以难以诊断且更难修复的方式悄然失效。两个用户同时向 AI 提问，其中一个输入消失了。五个工程师共享的上下文窗口充满了重复的历史记录。AI 使用用户 B 的权限回答用户 A 的问题。没有人为这些情况做过设计，因为交付多用户共享上下文意味着要面对现代 AI 基础设施中最难的分布式系统问题之一。

本篇文章将探讨为什么同步多用户 AI 会话如此困难、生产团队尝试了哪些方案，以及新兴的架构模式是什么。如果你正在构建协作 AI 功能并疑惑为何它感觉复杂得离谱，这就是原因。

两个智能体收到同一条用户消息。一个在 3 秒内用 400 个 Token 完成任务；另一个进入 Reflexion 循环，耗尽 40,000 个 Token，在任务中途触及上下文限制，产出一个半成品答案。两个系统都没有预测到会是哪种结果。这不是边缘情况——这是智能体在没有对任务深度建立任何模型的情况下启动任务时的默认行为。

基于 LLM 的智能体在执行前对任务范围没有天然感知。用自然语言读起来简单的请求可能需要十几次工具调用和多轮规划；听起来复杂的请求可能只需一次查找即可解决。没有执行前的复杂度估算，智能体就会盲目提交资源：随着轮次历史积累，上下文窗口呈二次方填满；规划开销主导执行时间；等到系统检测到问题时，导致问题的早期决策已经无法撤销。

大多数使用 LLM 构建产品的团队都在针对错误的工作负载进行优化。他们过分痴迷于首个 token 生成时间（time-to-first-token）、流式传输延迟和响应速度——结果却发现，其 LLM API 支出的 60% 或更多实际上流向了无人实时监控的夜间摘要任务、数据扩充流水线和分类运行。适用于聊天应用的“延迟优先”思维模式正在主动破坏这些离线工作负载。

LLM 批处理流水线是生产环境 AI 中那些不起眼但至关重要的“劳模”。它是每晚对 50,000 张工单进行分类的任务，是每周用公司描述丰富 CRM 的流水线，也是每天为新文档生成嵌入（embeddings）的运行任务。这些工作负载的设计约束与实时服务有着本质的不同。如果将它们视为聊天 API 的“慢速版本”，问题就由此产生了。

大多数多租户 LLM 产品都存在一个其工程师尚未测试过的安全漏洞。这并非理论上的漏洞 —— 而是一个实实在在的漏洞，已有记录在案的攻击向量和真实的确认案例。这个漏洞在于：现代 AI 栈中的每一层都引入了自己的隔离原语，而每一层都可能以静默的方式失效，导致一个客户的数据进入另一个客户的上下文。

这与提示词注入（prompt injection）或越狱（jailbreaking）无关。它关乎基础设施本身 —— 提示词缓存（prompt caches）、向量索引（vector indexes）、内存存储（memory stores）和微调流水线（fine-tuning pipelines） —— 以及大多数团队在未经核实的情况下就交付的“隔离”这一组织层面的虚构。