22 篇博文 含有标签「ai-infrastructure」

当一个多租户 SaaS 团队在其系统提示词（system prompt）中添加第三个 if tenant_industry == "healthcare" 分支时，那一刻他们其实已经在不经意间为自己聘请了一位编译器工程师。没有人申请过这个人头（headcount），也没有人事先规划过这项工作。团队以为自己在交付一个功能，实际上交付的是一套构建系统，而这套系统仅靠 f-strings 勉强维系。

任何试图将 AI 功能推广到具有哪怕轻微差异的客户群体的团队，最终都会撞上同一堵墙。租户 A 属于医疗行业，需要符合 HIPAA 标准的回答框架。租户 B 属于法律行业，需要严格的引用规范。租户 C 是购买了自定义安全准则的大型企业。租户 D 是免费层级用户，使用默认设置。最直觉的做法是用运行时条件语句（runtime conditionals）处理差异，这些条件不断嵌套，直到除了作者之外没人能读懂这个提示词。第二种直觉——也是大多数团队在撞墙后得出的方案——是提示词编译（prompt compilation）：规范的“提示词”不再是一个字符串，而是一个源码产物（source artifact），最终触达模型的则是编译后的输出。

一位资深工程师将 Prompt 的更改通过 10% 的灰度发布（canary）推送到生产环境。到了第二天早上，灰度组的有用性评分（helpfulness score）下降了四个点，值班人员发现了这一点，团队做了每个团队都会做的事情——撤回提交（revert commit）并重新部署。仪表板没有恢复。第二天也没有恢复。三天后，一份复盘报告显示，看到糟糕 Prompt 的那一组用户仍然在看到退化的输出，因为他们的对话历史中现在包含了由已撤回的 Prompt 生成的助手回复，而模型正基于这些回复进行预测。提交已经消失了，但损害仍在。

这是 LLMOps 中“像对待代码一样对待 Prompt”这一建议悄悄跳过的部分。代码回滚是文本替换，用于恢复确定性的过去状态。Prompt 回滚必须处理一系列副作用——缓存、历史记录、评估基准、实验分组、下游契约——这些都是糟糕的 Prompt 已经印刻在生产环境中的。git revert 翻转了文本，但它没有翻转后果。

你的 AI 功能在测试中运行完美。单轮问答，毫无问题。但在生产环境中，当真实用户进行一场 10 轮调试对话时，它却失败了——不是因为模型出了问题，而是因为你的速率限制器是为一个完全不同的世界设计的。

标准 API 速率限制是专为无状态 REST 调用设计的粗糙工具。每个请求被视为一个独立的、大致等量的消耗单元。对于 CRUD 端点而言，这种模型运行良好，因为每次调用确实具有可比性。但对于多轮对话，这种模型就行不通了——每一个后续轮次的成本都在递增，一次用户交互可能触发数十次内部模型调用，而会话中途被切断造成的损害，远比一次失败的单次查询严重得多。

大多数 AI 流水线（pipelines）在编写时，都好像每一个请求都值得进行一次完整的 LLM 调用。用户提交一条消息，流水线将其传递给模型，等待响应并返回——每一次都无条件地如此操作。这虽然可行，但既昂贵又缓慢，而且通常是不必要的。

实际上需要完整 LLM 推理的请求比例比大多数工程师预想的要小。关于 token 级别路由的研究表明，1.5B 和 32B 参数模型之间只有约 11% 的 token 存在差异，且只有 4.9% 的 token 是真正的“发散性”的——这意味着如果由较小的模型处理，它们会改变推理路径。生产环境中的语义缓存显示，65% 的传入流量在语义上与流水线已经回答过的内容相似。这些并不是边缘案例。它们占据了流量的大部分，而你却在为处理它们支付全额费用。

解决方法是惰性求值（lazy evaluation）：在确认确实需要昂贵模型之前，不要调用它。

你 Prompt 仓库中的 diff 显示有三行发生了变化。生产环境中的行为差异却显示一切都变了。安全团队将一条拒绝规则从第 14 行移动到了第 87 行，目的是为了“将其与相关的防护栏归类”；产品团队没有注意到这一点，因为措辞完全相同；一周后，评估套件显示在对抗性输入上的得分下降了 9 个百分点。没有人修改这条规则，只是有人移动了它。在一个拥有 2,400 token 的系统 Prompt 中，由于对防护栏存在首因效应（Primacy Bias），对指令遵循存在近因效应（Recency Bias），移动一条规则所带来的行为改变与重写它一样具有承重性——而你的工具对这两者都无法感知。

这是 AI 团队在回归评审结束时，而非开始时才会发现的合并冲突模式。系统 Prompt 在 2025 年底的某个时候增长到了 2K token 以上。安全团队负责顶部，产品团队负责中间，智能体（Agent）团队负责底部。三个月的“小幅编辑”在无声无息中重新排列了每个人的意图，因为原本适用于代码的基于行的 diff 工具无法告诉你一条指令已经跨越了区域边界。Bug 不在任何一次单一的编辑中。Bug 在于位置现在即策略，而你对位置却没有任何策略。

走进任何一家有五十名工程师在生产环境编写 LLM 代码的公司，你都会发现七个网关形态的产物。推荐团队造了一个用于在 OpenAI 和 Anthropic 之间路由。支持机器人团队写了一个用来挂载他们的 Prompt 注册表。平台团队有一个半成品代理，处理鉴权但不处理限流。增长团队有一个 Lambda，在数据发出时进行 PII 脱敏。数据科学团队直接调用供应商 SDK，而且没人告诉他们停止这样做。没有共享网关。只有七个共同的问题，每个都被孤立且拙劣地解决了，而首席财务官 (CFO) 正准备询问为什么 AI 账单环比增长了 40%，却没有任何明确的负责人。

这与行业在 2016 年和 2017 年遇到微服务时的架构节奏完全相同。成千上万的外部依赖，每个团队都有相同的共同关注点——鉴权、重试、可观测性、策略——以及在“解决一次”或“随处重新发明”之间做出选择。当时的答案是服务网格 (Service Mesh)。现在的答案是内部 LLM 网关，而大多数公司仍处于“随处重新发明”的阶段。

两年前，一个团队将他们的检索索引指向了 Wiki、Zendesk 导出文件以及公共文档的快照。上周，同一个索引返回了一个已弃用的运行手册（runbook），告诉 SRE 去重启一个已不存在的服务。该运行手册已经废弃了 18 个月。没人负责它的下线工作，所以没人把它删掉。Agent 自信地引用了它。模型没有错；错的是语料库（corpus）。

这是检索评估（retrieval evals）中不会出现的故障模式：语料库被视为一次性的工程决策，而实际上它是一个持续的治理问题。负责初始摄取（ingestion）的团队早已解散。本应标记出客户机密 PDF 的法律审查从未发生，因为没人告诉法务部门存在这个流水线（pipeline）。“新鲜度策略”（freshness strategy）只是一个在第三季度离职的人留下的 Slack 消息。检索索引变成了任何人抓取过的每一份文档的共享收件箱，而纳入标准已逐渐演变为“任何容易摄取的内容”。

2025 年 5 月 13 日，纽约南区的一位联邦地方法官签署了一项保护令，用一个词取代了一家消费级 AI 公司的保留政策：永远。OpenAI 被指示保留并隔离其 Free、Plus、Pro 和 Team 等所有层级的每一份输出日志——包括用户已明确删除的对话，以及隐私法原本要求删除的对话。到 11 月，同一法院下令将其中 2000 万份去标识化的转录文本作为抽样取证（sampled discovery）提供给《纽约时报》及其共同原告。这一无限期保留义务一直持续到当年的 9 月 26 日。在这五个月里，“删除”的实际含义是“保存在隔离的保险库中，供对方当事人日后查阅”。

该命令是对每一个基于 LLM 构建产品的团队发出的警告信号。如果你的产品存储了聊天记录，你的保留政策距离被法院认为合理的任何规定所取代，仅隔着一场潜在的诉讼。工程上的问题不在于这是否会发生在你身上，而在于你的存储架构是否能够承受这种变化，而不至于让你的产品变成法务部门的责任引擎。

电子邮件的保留手册无法直接套用。AI 对话包含的内容远多于用户输入的内容，而这“多出的部分”正是取证争端的开始。

成本仪表盘一片绿意。自从级联路由（cascade router）上线以来，单次请求的支出下降了 62%。CFO 很开心。平台团队正在庆祝。而与此同时，你的 p95 延迟悄然上升了 40%，你最重要的客户刚刚流失，理由是“机器人在处理关键查询时变笨了”，而实验团队已经连续两周在追踪一个根本不存在的幻影回归（phantom regression）了。

这就是级联路由的可靠性陷阱。它是每一个“先尝试廉价模型，如果不成功再升级”架构的隐蔽失败模式，也是生产环境 LLM 系统中最少被讨论的二阶效应之一。成本上的收益是真实的、可衡量的，且易于归因。而可靠性上的损失则是弥散的、统计性的，几乎无法追溯到导致它们的路由。因此，成本上的胜利受到赞彰，可靠性上的损失被归咎于“模型变差了”，团队就这样把自己优化进了一个坑里。

打开任何 2024 年时代的 AI 功能链路追踪 (trace)，模型调用就像是一头巨鲸。八百毫秒的生成时间，包裹在检索、鉴权和数据库查询组成的薄壳中，后者的时间几乎可以忽略不计。那一年的每一个架构决策——缓存、预取、流式 UX——都是为了隐藏那头“巨鲸”。

现在，查看运行在 2026 年推理栈上的相同功能的链路追踪。那头巨鲸已经变成了一只海豚。缓存后的预填充 (prefill) 在 180ms 内返回第一个 token。解码 (decode) 以每秒 120 个 token 的速度流式传输。模型不再是慢节点。你自己的基础设施才是，而且大部分基础设施还没有意识到这一点。

这种顺序重排是今年最重要的性能转变，也是各团队一直反应不足的一个。现在，AI 请求的 p99 底限是由特征存储 (feature store) 调用、鉴权中间件以及那些一直都很慢的 Postgres 查询决定的——在模型占据九成预算时，没人关心这些。

大多数团队在发布智能体时，其威胁模型中都潜伏着一个沉默的假设：当模型调用工具时，返回的任何内容都是可以安全读取的。在这个剧本里，用户提示词是唯一的对手，而工具输出则被视为“仅仅是数据”——搜索结果、收件箱摘要、数据库行、RAG 分块、文件内容、网页抓取。正是这种观念导致提示词注入（prompt injection）不断出现在生产环境中。工具输出并不是数据。它们是进入规划器（planner）的另一个输入通道，拥有与用户提示词相同的权限，却完全没有被怀疑。

如果这种说法听起来有些抽象，请考虑 2025 年 6 月 Microsoft 365 Copilot 内部发生的事情。一名研究人员发送了一封带有隐藏指令的电子邮件；受害者从未点击过链接，从未打开过附件，甚至从未亲自阅读过该邮件。一个常规的“总结我的收件箱”查询请求 Copilot 读取该邮件。智能体忠实地执行了在正文中发现的指令，访问了 OneDrive、SharePoint 和 Teams，并在任何人察觉之前通过受信任的 Microsoft 域名外泄了组织数据。该 CVE（2025-32711，“EchoLeak”）获得了 9.3 的 CVSS 评分和服务器端修补，但这类漏洞并未消失。它不可能消失，因为生产环境中智能体上的每一个读取工具都是那个电子邮件收件箱的变体。

这篇文章讨论的是能让你摆脱困境的思维转变：停止将“提示词注入”视为用户输入问题，并开始将每一个工具输出视为一个恰好与你的系统提示词共享 Token 流的不可信渠道。

你的智能体调用了一个数据库工具。查询返回了8000个Token的原始JSON——嵌套对象、null字段、分页元数据，以及每一行都带有时间戳。智能体只需要其中三个字段。你刚刚为7900个噪音Token付了费，并把它们全部注入上下文，让它们与真正的任务争夺注意力。

这就是工具输出注入问题，也是智能体设计中最被低估的架构决策。大多数团队都是在付出代价后才意识到这一点：演示运行顺畅，生产逐渐退化，却没人能解释为什么模型开始对之前能自信回答的问题开始含糊其辞。