摘要
- 构建基础AI智能体极其容易，但使其可靠极其困难。
- 可靠性来自架构，而不仅仅是模型。
- 智能体需要回合制思维：理解 → 行动 → 验证 → 转换。
- 上下文维护防止智能体忘记他们学到的内容
- 95%每动作可靠性对于20步任务降至36%。
- 成功需要防御性架构和明确验证。
构建基础AI智能体 trivialmente fácil。连接一个LLM到工具，写一个提示，你就得到了看起来工作的东西。但把它放在真实用户面前，一切都会崩溃。
来自MIT等机构的研究发现，高达95%的AI智能体概念验证未能进入生产，通常是由于从演示到现实部署时才出现的可靠性问题。
在演示智能体和生产就绪智能体之间 lies a deep and wide chasm。弥合它需要理解可靠性不在于模型，而在于其周围的架构。
回合制现实
智能体在回合中运行，每个需要四个步骤：
- 理解状态。
- 决定行动。
- 执行。
- 验证结果。
大多数基础智能体只处理步骤2和3，即决定和执行。它们跳过理解和验证，这是可靠性死亡的地方。
想象雇佣一个从不确认理解或检查其行动是否有效的人类助理。那就是今天大多数智能体。
行动前检查
在行动之前，智能体必须验证他们理解请求。这听起来很明显但通常被跳过。
必需的行动前检查：
- 状态验证：拥有所有必需信息（订单ID、客户详情等）
- 歧义检测：在行动前捕获多重解释
- “更新我的送货地址” → 哪个订单？哪个地址（家庭 vs 工作）？
- “给我预订去芝加哥的航班” → 哪些日期？什么舱位等级？从哪个出发城市？
- “取消我的订阅” → 哪个订阅？立即取消还是在续订时？
- 前提条件验证：检查操作是否可能 given current constraints
- “取消我的订单” → 验证订单是否已经发货或交付
- “应用折扣码” → 检查码是否有效、未过期、是否满足最低购买要求
- “安排会议” → 确保参会者可用且房间未被 double-booked
- “删除此文件” → 确认文件未被其他进程或用户锁定
- 权限边界：验证授权 before taking irreversible actions
- “退款此购买” → 检查用户是否有退款特权或金额是否超过授权限制
- “删除这些客户记录” → 验证用户是否有管理员权限且记录不受数据保留策略保护
- “访问财务报告” → 确认用户对敏感数据有适当的基于角色的访问权限
- “批准此费用” → 确保用户在批准限额内且未超过月度预算
**快速失败与提问比自信地做错事更可靠。**用户可以原谅提问，不能原谅错误。
行动后验证
知道行动是否成功与执行它一样重要。APIs return 200 status codes 而操作失败，数据库接受撰写而被 silently modified，外部服务 timeout 离开未知状态。
必需的行动后检查：
- 明确的成功标准：验证结果，而不仅仅是API响应。如果你更新了邮件，查询它回来确认
- 状态一致性：在多个行动之后，验证最终状态匹配期望
- 回滚检测：检查业务逻辑是否悄悄撤销了你的”成功”行动
- 部分失败识别：检测行动只有部分成功时（5封邮件发送了3封）
回合转换
在回合之间，智能体必须 maintain coherent state。两个问题扼杀可靠性：
上下文降级：智能体忘记先前信息，迫使用户重复，摧毁信任。
真实示例：
- 客户支持智能体在3轮故障排除后忘记订单号，在处理退款时问”您的订单号是多少？”
- 旅行智能体在预订过程中失去旅行者的 frequent flyer number，然后在添加忠诚度福利时再次询问
- 银行助手在处理多个转账后忘记用户正在讨论哪个账户，要求用户重新指定”从我的储蓄账户，不是支票”
目标漂移：智能体失去目标 track，从用户真正想要的事情上分心。
真实示例：
- 电商智能体试图处理退货时陷入支付系统调试循环，而不是提供 store credit或交换选项
- 日历智能体遇到调度冲突时开始调查 room booking system architecture，而不是建议替代时间或位置
- IT支持智能体遇到权限错误时开始解释 LDAP authentication protocols，而不是升级给可以批准请求的管理员
必需的转换实践：
- 明确状态跟踪：维护 known、goal 和 attempts 的结构化记录
- 进度监控：检测当无进展时——三次失败后升级
- 对话检查点：总结关键信息以早期捕获漂移
可靠性数学问题
这就是为什么鸿沟如此 wide：可靠性指数级复合，数学是残酷的。
假设你的智能体每个单独行动正确率95%。这听起来 pretty good，对吧？孤立来看，这意味着1/20的行动失败。
但智能体不是在孤立中工作。它们执行行动序列，每个行动必须成功才能完成整个任务。这创造了复合效应，其中总体可靠性 dramatically drops：
对于10个行动：60%成功率（0.95 × 0.95 × 0.95… 十次）
- 你有40%的完全失败机会
- 超过1/3的多步骤任务会在某处中断
对于20个行动：36%成功率
- 三分之二的任务完全失败
- 你现在比抛硬币更差
对于30个行动：21%成功率
- 五分之四的任务失败
- 你的”95%可靠”智能体80%的时间失败
想想这在实践中意味着什么。一个客户服务智能体需要：(1)找到客户，(2)定位订单，(3)检查状态，(4)识别问题，(5)应用解决方案，(6)确认解决，(7)更新系统，(8)发送确认——这已经是8个行动。在任何边缘案例或 complication 之前，你以66%的可靠性运营。
这解释了为什么演示智能体感觉功能正常但在生产中失败。开发测试 simple workflows；生产 demand complex multi-step tasks。你令人印象深刻的95%每动作可靠性变成了 real work 的抛硬币。
解决方案很明确：将每动作可靠性推向100%。每一个检查——行动前验证、行动后验证、回合转换连贯性——指数级重要。从95%提升到99%每动作可靠性将20步任务的成功率从36%提升到82%。这是破碎系统和有用系统之间的区别。
可靠性心态
构建可靠智能体需要架构思维，而不仅仅是提示工程。你需要：
防御性架构：假设LLMs会幻觉和误解。建立 guardrails。
明确验证：将检查作为 first-class citizens 在设计——它们是产品，不是 overhead。
优雅降级：安全失败，维护关于失败的上下文，适当恢复或升级。
可观察的行为：查看智能体在每个回合 exactly what it is thinking。日志记录对于调试可靠性问题 essential。
跨越鸿沟
成功的团队意识到：**智能体不是带有工具的LLM——它是一个系统，其中LLM是一个组件，可靠性来自其周围的一切。**你的架构需要从第一天起就具有回合制思维：
- 行动前：理解和验证
- 行动：执行带错误处理
- 行动后：验证和确认
- 转换：维护上下文并跟踪进度
每个回合是一个契约：行动前理解，行动后验证，真实地携带转发上下文。打破契约，失去信任。 consistently 维持它，建立可靠的东西。
鸿沟 wide 但并非不可逾越。可靠性通过架构纪律 earned，而不是提示工程 magic。建立 self-checking 的系统。建立知道何时不知道的智能体。为现实世界构建，而不是演示。
构建智能体容易。构建能连续工作 10,000 次的智能体？那才是真正的挑战。