产品团队发布了个性化功能。智能体（Agent）现在会直呼用户姓名，根据用户的偏好调整回答长度，了解用户在医疗行业工作，并尊重用户在提及日期时所处的时区。用户满意度的提升是真实且可衡量的——A/B 测试显示点赞率提升了四个百分点，随后功能全量上线。三周后，财务部门指出推理成本大约翻了三倍，而 AI 团队中没人能立即解释原因。
解释就在系统提示词（System Prompt）构建器中一行被埋没的代码修改里。每个用户的上下文——姓名、偏好的回答长度、行业、时区——都被添加到了系统提示词的开头，以便模型在每一轮对话中都能看到。这使得从第一个 Token 开始，每个用户的 Prompt 都是独一无二的。你的供应商提供的 Prompt 缓存——原本能以标准价格的十分之一服务大约 90% 的输入 Token——失效了。延迟几乎没有波动，所以性能仪表盘（Performance Dashboard）依然显示绿色。直到月底，计费仪表盘才反映出这一情况。
按 token 付费的心智模型训练了一代工程师，让他们认为 AI 成本是使用量的函数。没有请求，就没有账单。这是一个令人慰藉的模型，对于 API 调用本身而言，这基本属实。但它只描述了生产级 AI 功能的一个层面，而并非那个悄悄吞噬预算的层面。
预置吞吐量、预留 GPU 容量、预热向量索引以及待机微调端点都是按时长计费，而不是按计数器计费。无论流量是否到来，它们都为你提供服务流量的权利而收费。即便周六没人碰某个功能，计费表依然在转动。在办公时间内由 12 个人使用的内部工具，每周 168 小时都在计费。你为了 3 月份发布而准备的资源预置，在 5 月份流量洪峰平息很久之后，依然占据着预留额度。
这就是闲置成本。它之所以野蛮生长，原因并非技术层面，而是组织层面：没有一个单一的角色能看到它，也没有一个单一的角色负责它。
当一个多租户 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 查询决定的——在模型占据九成预算时，没人关心这些。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
