Agent 的降级边界，要按业务动作划，不能按服务名称划

“物流服务是弱依赖”听起来很合理，直到同一个服务同时提供订单轨迹和结算运费。轨迹不可用时，页面可以保留订单基础信息；运费不可用时，结算 Agent 却不能擅自宣布包邮。强弱依赖是某个动作的属性，不是给整个供应商贴上的永久标签。

图中的三级兜底是策略讨论的概念图，不代表一次已经完成的宕机演练。本文把注意力放在三个不同结果：可以缺少附加信息、必须暂停确认、已经发起动作但结果未知。它们不适合共用一句“系统已先行受理”。

先决定允许缺什么，再决定备用模型是谁

LangGraph 关于工作流与 Agent 的文档，把预先确定的路径与动态决策区分开。发生故障时，涉及价格承诺与资金动作的边界，更适合由明确规则执行，而不是让备用模型自由解释“尽量完成任务”。模型可以组织解释，不能凭语言补出业务事实。

下面用纯标准库决策表说明。保存为 fallback.py，运行 python3 fallback.py。传入的 receipt 在示例里是测试夹具；生产中必须来自已验证、与动作绑定的权威查询结果。

from enum import Enum

class Action(str, Enum):
REVIEW_SUMMARY = "review_summary"
SHIPPING_QUOTE = "shipping_quote"
REFUND_SUBMIT = "refund_submit"

class Receipt(str, Enum):
COMMITTED = "committed"
REJECTED = "rejected"
UNKNOWN = "unknown"

def on_failure(action, receipt=Receipt.UNKNOWN):
if not isinstance(action, Action) or not isinstance(receipt, Receipt):
raise ValueError("unknown policy input")
if action == Action.REVIEW_SUMMARY:
return {"status": "partial", "notice": "评价摘要暂缺，未据此作推荐结论"}
if action == Action.SHIPPING_QUOTE:
return {"status": "blocked", "notice": "运费尚未确认，暂不提交结算"}
if receipt == Receipt.COMMITTED:
return {"status": "confirmed", "notice": "查询回执确认退款已提交"}
if receipt == Receipt.REJECTED:
return {"status": "rejected", "notice": "查询回执确认本次申请被拒绝"}
return {"status": "unknown", "notice": "退款结果待核实，请勿重复提交"}

assert on_failure(Action.REVIEW_SUMMARY)["status"] == "partial"
assert on_failure(Action.SHIPPING_QUOTE)["status"] == "blocked"
assert on_failure(Action.REFUND_SUBMIT)["status"] == "unknown"
assert on_failure(Action.REFUND_SUBMIT, Receipt.COMMITTED)["status"] == "confirmed"
assert on_failure(Action.REFUND_SUBMIT, Receipt.REJECTED)["status"] == "rejected"
try:
on_failure("new_unknown_tool")
raise AssertionError("unknown action must not receive a default success")
except ValueError:
pass
print("optional, required and uncertain-action policies checked")

本地测试只验证决策分支，没有请求任何物流、支付或模型服务，也没有测得可用率。退款的 confirmed 仅表示可信回执确认“已提交”，不自动等于资金已经到账。

陈旧缓存也有使用条件

故障时返回旧数据，至少要知道租户与主体范围、业务版本、有效时间和该动作是否允许陈旧读取。历史运费可以展示成“上次估算”，不能悄悄成为本次扣款依据。缓存为空、缓存不可读和业务记录不存在，也应是不同状态。

备用小模型同样需要原有权限和工具边界。它能否提取参数、能否在特定任务上达到质量门槛，需要单独评测，不能因它部署在本地就承诺与主模型完全等价。

演练时，应逐个动作检查用户可见状态和真实副作用：附加信息缺失有没有被伪装成确定结论，结算是否停止，未知动作是否被重复执行。系统恢复后还要确认旧队列与迟到回执如何对账。把这些边界跑通，比写一个漂亮的“全链路自动兜底成功率”更有用。

参考：LangGraph：Thinking in LangGraph、MCP 安全边界。