演示成功了。你输入了一个问题，智能体调用了三个工具，经过多步计划的推理，最后给出了一个让全场人都为之振奋的答案。有人说：“上线吧。”三个月后，你的产品依然没有上线，而且没人能解释时间都去哪儿了。
时间都花在了这里：演示只占了 10% 的工作，它只是大脑。剩下的 90% 是管道工程——那些在正常运作时无人喝彩，一旦出故障就是灾难性的评估（Evals）、护栏（Guardrails）、可观测性、成本控制和备用路径。这 90% 就是“从演示到生产的税”，而大多数团队在做预算时，却把它当成了一个可以忽略不计的舍入误差。
数据说明了另一番景象。MIT 2025 年的一项企业 AI 研究发现，95% 的生成式 AI 试点项目未能产生可衡量的损益（P&L）影响。另一项分析则更加直截了当：企业每启动 33 个概念验证（PoC）项目，只有 4 个能进入生产阶段。这意味着夭折率高达 88%，而死因几乎从未出现在模型身上，而是演示让你跳过的所有环节。
为什么演示会欺骗你
原型是一个装扮成产品的受控实验。你挑选了输入数据，你运行了三次并展示了成功的那一次。工具是健康的，语料库是干净的，用户说的话也完全符合你训练他们的预期。这一切在接触到生产环境时都会土崩瓦解，因为那里的输入会因各种意外而具有对抗性，且出错的代价是真实存在的。
最残酷的部分在于数学逻辑。假设你的智能体在每一步的可靠性是 95%——对于调用工具的 LLM 来说，这已经是非常优秀的表现了。但如果你将这 10 个步骤串联起来，你的端到端成功率就是 0.95^10，大约只有 60%。演示通常只是一个三步的任务，所以你看到了 86% 的成功率并认为它很出色。而生产环境通常是平均十步的任务，现在每五个会话中就有两个会在中间某个地方失败。性能并没有变差，只是你无法再隐藏这种复合效应了。
而且，失败的形式并不像你测试时那样是清晰的错误，它们看起来往往是这样的：
迷之自信地选错工具 ：大约每 20 次调用中就有一次，当用户询问远足路线时，模型会伸手去调酒店预订 API，因为嵌入向量（Embeddings）将“旅行”放在了“预订”附近。它毫不犹豫，直接下单。缓慢的依赖项 ：在演示期间 3 秒内返回的搜索 API，在负载下需要 30 秒。智能体不会等待——它会超时并幻觉出一个看似合理的结论，或者陷入重试循环，让你的 Token 账单翻三倍。部分成功 ：由于上游的一个 bug，分页 API 只返回了 2 个结果而不是 15 个。智能体完全不知道自己是在基于碎片进行推理，因此它会根据仅有的三分之一数据生成一个看似完整的答案。状态漂移 ：在一个长任务中，智能体在第一步选择了巴黎，在第三步预订了飞往戴高乐机场（CDG）的航班，到第五步却推荐了一家伦敦的餐厅。每一步在局部看来都是合理的，但整个轨迹毫无逻辑。
你无法通过提示词（Prompt）工程来解决这些问题。这些是系统性故障，而系统性故障需要系统工程来解决。这就是那份“税”。
评估：看起来可选但实则必不可少的部分
这份“税”中最大的单项开支是评估（Evaluation），而且它是团队最先砍掉的，因为它感觉就像测试——而“我们以后再加测试”是每个工程师都撒过的谎。
但 LLM 评估套件并不是普通的测试套件。它是你每天回答核心问题的唯一工具：我刚刚做的更改是改进了产品，还是悄悄搞砸了它？没有它，每一次提示词修改、模型升级和检索优化都像是一场你看不见结果的掷硬币。你发布了产品，感觉有些地方变差了，但你无法判断是因为你的改动、模型供应商的静默更新，还是你的错觉。
生产级版本包含两个部分。**离线评估（Offline evals）**在 CI 环境中运行，针对一组包含几百到几千个带标签示例的版本化数据集，按标准评分；当通过率回退时，它们会阻断 Pull Request。**在线评估（Online evals）**对 5-20% 的实时流量进行采样，为每个请求附加质量分，并在滚动平均值出现偏移时提醒你——下降 2% 需要“去查看”，下降 5% 则需要“呼叫运维”。演示阶段这两者都没有，你只是盯着屏幕，凭感觉判断输出是否良好。这在用户超过一个人的时候是无法扩展的，而那唯一的一个用户就是你自己。
尽早构建这个体系，因为它是所有其他工作的支架。如果你无法衡量备用模型是否更差，你就无法安全地添加它。如果你无法看到廉价路由对质量的影响，你就无法优化成本。评估能让你将“感觉还行”转化为一个你可以辩护的数字。
护栏、可观测性和失明的代价 接下来的三层是运维团队在其他软件中习以为常，而 AI 团队却不断从零开始重新发现的。
**护栏（Guardrails）**是位于模型与世界之间的输入和输出检查。在输入端：提示词注入检测、PII 过滤、请求验证。在输出端：毒性筛查、事实一致性检查、模式（Schema）验证，以确保格式错误的工具调用不会导致下一步崩溃。演示跳过了所有这些，因为演示的唯一用户是友好的。而生产环境的用户包括好奇者、粗心者和恶意攻击者，此外还有你的智能体将自己的错误重新喂给自己的情况。
**可观测性（Observability）**是调试与瞎猜之间的区别。一个真实的 LLM 追踪跨度（Trace span）包含大约五十个属性——模型名称和版本、温度、提示词和补全的 Token 数、缓存的 Token 数、成本、首个 Token 时间（TTFT）、工具名称和参数、检索块 ID 及其分数、评估分数、护栏决策、租户 ID、提示词版本、会话 ID。当用户报告“智能体在下午 2 点给我一个奇怪的答案”时，这个跨度能让你发现，是因为语料库重新索引后检索返回了一个低分块，导致它选错了工具。没有它，你只有一张截图和一脸无奈。目前的新兴标准是带有 gen_ai.* 语义约定的 OpenTelemetry，这意味着你可以购买现成的服务而不是自己构建，但你仍需将其接入，而接入工作是演示从未展示给你的。
**成本控制（Cost controls）**是账单到来的地方。在演示中你进行了 12 次调用，成本是隐形的。在生产环境中，一个失控的重试循环乘以一万个用户，会在周二给你带来一个五位数的“惊喜”。解决方法是建立一个网关：通过一个代理路由每个供应商的调用，该代理跟踪每个用户、每个功能和每个提示词的支出；在密钥级别执行预算；缓存重复请求；并自动将非关键路径降级到更便宜的模型。跳过网关的团队只能通过发票了解其成本结构，而那是学习成本最昂贵的地方。
回退路径与“假设失败”的准则 Demo 假设一切正常，而生产环境则假设一切最终都会出错，这两者之间的差距就是整套系统架构。
你的 Agent 发起的每一次外部调用都是一个依赖项，它们总会在某个周二出现超时、限流、返回垃圾数据或彻底宕机。生产系统在问题发生前就会分层级地回答“然后呢？”：提供语义相似的缓存响应；切换到另一个供应商的备用模型；在关键路径上回退到预设的安全响应；并触发熔断机制，禁用故障组件，防止它拖垮整个请求。
未经测试的回退方案是一个陷阱。从未在负载下运行过的故障转移路径根本不是回退方案——它只是潜伏在最糟糕时刻爆发的第二个 Bug。那些幸存下来的团队会刻意对失败路径进行负载测试：在预发布环境中杀掉主供应商进程，观察备用方案如何承载真实流量。因为你不该在系统宕机时才第一次发现回退方案的响应速度竟然比它本应挽救的超时限制还要慢。
这也是 MIT 关于“学习差距”（learning gap）研究的痛点所在。报告指出，试点失败的首要原因不是模型太弱，而是系统无法保留反馈、适应上下文或随时间自我优化。Demo 是快照，而产品是循环。回退架构、捕捉回归的评估套件、揭示偏移的可观测性——这些共同构成了让系统不断进步的机制，而不是随着外界环境变化而默默腐朽。
这 90% 的清单 如果你正盯着一个满堂彩的原型并试图评估实际工作量，那么这就是你需要支付的“税费”清单。Demo 里没有这些，但它们是你通往生产环境的必经之路。
评估 (Evals)： 一套带版本的离线测试集，用于在 CI 中阻止回归，并对采样到的真实流量进行在线打分和偏移告警。护栏 (Guardrails)： 输入验证（注入攻击、PII 隐私）、输出验证（毒性、事实性/Grounding、Schema），在任何内容触达用户之前强制执行。可观测性 (Observability)： 基于 OTel 原生的追踪，包含单次请求的成本、延迟、Token、工具调用、检索及评估属性——当有人反馈糟糕答案时，这些数据必须是可查询的。成本控制： 一个能按用户和功能归因支出、强制执行预算、使用缓存并降级非关键路径的网关。回退路径： 缓存、模型和静态回退，以及熔断机制——且每一个都在你依赖它们之前经过了负载测试。反馈循环： 将上述五项连接成一个持续进化而非衰败的系统的核心纽带。 残酷的现实是，Demo 从来不是产品。它只是为了证明“值得构建产品”的一个论据——正因为它极具说服力，所以才危险。它会让利益相关者误以为工作已经完成，而实际上才刚刚开始；它会让你根据已经完成的 10% 来制定时间表，而不是那尚未开始的 90%。
所以，当全场高呼“发布吧”时，诚实的回答应该是：“你们看到的是大脑。现在，我要花三个月时间去构建让它能在野外生存的躯体。” 提前为这笔“税”做好预算，你就能加入那 5% 成功发布的行列。如果假装它不存在，你就会加入那 88% 的行列，变成明年关于“为什么 AI 项目停滞不前”的复盘报告中的一页幻灯片。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
