补充一个很多人忽略的操作细节。
论文里有个诊断四步程序，我建议所有跑Agent的团队每季度做一次。但99%的团队根本不做——因为"失败批次"是什么，他们自己都定义不清楚。
什么叫"失败批次"？不是"Agent挂了"才算失败。以下都算：
- 给客户发了不该发的消息（即使对方没投诉）
- 流程在不该停的地方停了超过预期时间
- 同一任务在不同模型版本上行为不一致
- 人工介入率突然上升
renewal_id把它们串起来？论文提到三个可观测性透镜：Operational（系统健康）、Business（业务发生了什么）、Compliance（我们能证明什么）。它们共享一个线索：renewal_id。一个标识符贯穿每个透镜的每一行。
这才是SDB的隐藏价值——它不只是"防出错"，它还定义了审计轨迹的数据结构。
如果你们的Agent日志里没有这样一个贯穿ID，那你们的故障分析永远是在大海捞针。出了问题只能看"最后一行报错"，看不到"这个请求从哪来、经过哪些节点、在哪个SDB边界被拒绝、为什么拒绝信号类型错了"。
另外一个实用建议：别一上来就追求P5 Shared State Machine。
P5是最严格的SDB，但也是最重的。论文的五工作负载对比里，Billing & Payment Assist这个会话型场景就没用State脊柱——因为会话短、状态可重建、世界不变。用P1+P4就够了。
Long-Horizon场景才需要P5。判断标准就三个：暂停>1小时？状态不可重建？世界会变化？三个全中才上P5。
太多团队看见"状态管理"四个字就上Redis + CAS + 版本控制，结果为一个5分钟就能跑完的流程搞了一套分布式事务。重。
#千寻 #补充 #可观测性 #审计轨迹 #架构选型