当搜索索引失效、供应商 API 对你限流、数据库只读副本出现延迟，或者下游微服务开始返回 503 错误时，你的智能体（agent）必须决定该做什么。在大多数生产环境的智能体系统中，这个决定从未被真正做出。它是被“默默继承”下来的——往往来自于编写工具封装（tool wrapper）的工程师在项目第三周周二下午 4 点随手写下的代码。
其结果就是你的客户最终替你写出的内容：一个 Reddit 帖子、一份客服对话记录，或者是新闻稿中的一段引述。“助手告诉我余额是 0 美元，但其实我的账户没问题——结果发现是他们的查询服务挂了。”那段话就是你的团队没写的降级模式规范。现在它公开了，它属于客户了，而且你的工程部门在接下来的整个季度里都将忙于应对它。
追踪记录看起来很干净。Agent 调用了 get_inventory_status，工具返回了 {"available": 142, "warehouse": "SEA-3"}，模型将这些信息编织成了一个自信的回答。客户下单了。仓库却说该商品自上午 9 点以来一直缺货。缓存的行数据是四小时前的。团队中没人决定过四小时是可接受的 —— 这只是平台团队连接包装器（wrapper）时，缓存框架默认的设置。
这种失效模式经常被误归类为幻觉。模型并没有在胡编乱造；它是在忠实地根据一个过期的工具结果进行推理，而没人费心将该结果标记为过期。追踪记录显示的是一次干净的调用和干净的响应，评估集（eval set）从未见过过期缓存的情况，而这种退化在每一个撞上相同 TTL 窗口的客户身上悄无声息地累积。
演示总是成功的。这是 AI 产品开发中最昂贵的一句话。产品经理看到模型处理好了理想路径（happy path），工程师发布了该功能的直观版本，六周后，支持队列里塞满了指标未能预见的投诉。模型本身没有退化。提示词（prompt）也没有变糟。只是该功能的形态并非模型所擅长的，而团队在工作开始前没有办法指出这一点。
相当大一部分已发布的 AI 功能都是以这种方式失败的——不是因为模型不好，而是因为任务错了。产品需要的输出是确定性的，而引擎是随机性的。用户对长尾误差的容忍度是千分之一的错误率，而模型的失败分布比这更厚。单位经济效益（unit economics）要求的延迟预算只有你在可负担范围内模型所能提供的一半。评估质量所需的地面真值（ground truth）并不存在，也无法低成本创建。这些都不是模型问题。它们是任务形态（task-shape）问题，应该在写下第一条提示词之前就被筛选出来。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
