生效之后
请求发出去了，回复没有来。
- 会发生什么
- 智能体无法判断动作是否已经发生。
- 为什么容易被忽视
- 超时常被当成失败，于是动作又被发了一次。
- 设计目标
- 结果不明时先停下，查清楚再决定是否发送。
执行失效模式
关于 AI 智能体的讨论，大多在问智能体会不会守规矩。下面这些问题，即使智能体守规矩也会发生。它们来自超时、重试、并行工作和迟到的回复——分布式系统里再平常不过的事。
生效之时
停下智能体，不等于停下动作。
- 会发生什么
- 智能体被关掉了，但它已经发出的请求还在路上。
- 为什么容易被忽视
- 紧急停止作用于智能体，而不是它已经发起的动作。
- 设计目标
- 已经发出的动作要被跟踪，直到结果清楚。
生效之后
恢复运行，不等于可以安全重发。
- 会发生什么
- 任务在崩溃后恢复，重复了最后一步。
- 为什么容易被忽视
- 恢复逻辑恢复的是任务，不是"哪些已经生效"的认知。
- 设计目标
- 重启之后，先弄清之前的动作进行到了哪一步。
生效之时
两个智能体，一个业务动作。
- 会发生什么
- 两个智能体，或两条路径，请求同一笔退款或同一个变更。
- 为什么容易被忽视
- 防重复机制通常假设只有一个调用方、用同一个键重试。
- 设计目标
- 同一个业务效果只生效一次，不论哪个智能体发起。
生效之时
被替换的任务迟到回复。
- 会发生什么
- 一个任务被替换后，旧任务的结果才到。
- 为什么容易被忽视
- 迟到的结果常被当作当前结果接受。
- 设计目标
- 被替换的任务不能重新获得执行的权利。
生效之前
检查之后，批准被撤回。
- 会发生什么
- 检查时批准有效，动作执行前被撤回。
- 为什么容易被忽视
- 只在开始时检查一次。
- 设计目标
- 在动作生效之前，再检查一次。
生效之时
批准的是一件事，请求的是另一件。
- 会发生什么
- 批准的是退 ¥49.90 到一个账户，到达的请求却是 ¥499，或者退到另一个账户。
- 为什么容易被忽视
- 检查只确认"有批准"，没确认"这个请求与批准一致"。
- 设计目标
- 在生效之前，把每个请求与批准的内容——动作、客户、金额和去向——逐项比对。
生效之后
结果对了，路径错了。
- 会发生什么
- 智能体报告成功，但走的不是批准的那条路。
- 为什么容易被忽视
- 只检查结果。
- 设计目标
- 记录每个动作依据的是哪一次批准、实际发送了什么。
生效之前
委托工作，泄露数据。
- 会发生什么
- 编排智能体把原始客户数据交给它分配的每个智能体。
- 为什么容易被忽视
- 数据访问跟着流程走，而不是跟着任务走。
- 设计目标
- 智能体可以委托任务，不能转交数据访问权。
生效之前
模型看到的比它需要的多。
- 会发生什么
- 姓名、身份证号和账号被发送给外部模型。
- 为什么容易被忽视
- 保护只做到提示词为止，或者根本没有做。
- 设计目标
- 模型只看到任务需要的内容；真实值只在最后一步、在业务系统中使用。