AI Agent 真正进入生产环境后，难点往往不在于能否调用模型，而在于一次执行失败之后，系统能否从正确的位置恢复，并且让团队确认这次执行确实按预期发生过。Diagrid Catalyst 2.0 围绕这一问题，引入了基于 Dapr 的恢复能力、签名的工作流历史，以及执行证明机制，试图为 Agent 工作流补上耐久性与可验证性。
这类能力值得关注，但不应直接等同于“所有 Agent 都应该迁移到 Catalyst”。架构师仍需要把它与 Agent 框架自带的 durable execution 能力、成熟工作流引擎，以及团队已有的观测和审计体系放在同一张比较表中。
Agent 生产化后，失败会变成状态问题
一个简单的 Agent 调用可以抽象成：接收任务、调用模型、执行工具、等待外部系统、汇总结果。真正运行时，任何一步都可能遇到超时、进程重启、网络抖动、重复投递或第三方 API 的部分成功。
如果工作流没有持久化状态，服务重启后通常只能从头执行。这会带来几个直接后果：
- 已经完成的工具调用可能被重复执行。
- 具有副作用的操作可能产生重复订单、重复通知或重复写入。
- 调试人员很难判断失败发生在哪一个步骤。
- 审计人员无法可靠地重建一次执行的实际路径。
Dapr 的组件化运行时可以把状态存储、消息传递和工作流执行等能力接入统一的应用模型。Catalyst 2.0 的方向，是在这些基础能力之上，为多个 Agent 框架提供更持久的执行上下文，而不是只依赖某一个框架进程的内存状态。
三个值得拆开看的能力
1. 基于 Dapr 的恢复
耐久执行的核心不是“失败后重新跑一遍”，而是保存足够的步骤状态，让系统知道哪些步骤已经完成、哪些步骤需要重试，以及重试是否安全。
这要求每个工具步骤具有明确的输入、输出和副作用边界。对于支付、发货、发送邮件等不可轻易重复的操作，还需要幂等键、去重记录或事务性协调。恢复机制只能恢复执行状态，不能自动消除业务副作用。
2. 签名的工作流历史
持久化日志解决“发生了什么”的记录问题，签名历史进一步解决“记录有没有被事后修改”的可信度问题。对高价值 Agent 工作流来说，模型输入、工具参数、工具结果、人工批准和最终输出都可能需要纳入可审计历史。
但签名并不会自动证明业务结果正确。它更准确地证明：某份执行历史在签名后没有被无声篡改。团队仍需定义签名覆盖范围、密钥轮换、时间戳、密钥托管和验证失败后的处理流程。
3. 执行证明
执行 attestation 关注的是对一次运行给出可验证的执行证据。对于跨服务 Agent，调用链可能穿过模型网关、工具服务、数据库和人工审批系统。只有把这些边界定义清楚，证明才有实际价值。
评估时要问的不是“有没有 attestation”这么简单，而是：谁签名、签名什么、验证方是谁、证据保存多久，以及验证失败是否会阻止下游动作。
一个可落地的最小工作流
下面是一个与这些原则相符的最小伪实现。它不依赖 Catalyst 的具体 SDK，目的是展示应用层仍然需要明确步骤状态、幂等键和可验证事件。运行前安装 Python 3.10 或更高版本。
# durable_agent.py
from dataclasses import dataclass, asdict
import hashlib
import json
from pathlib import Path
STATE_FILE = Path("agent-state.json")
@dataclass
class StepEvent:
name: str
status: str
idempotency_key: str
payload: dict
def load_state():
if not STATE_FILE.exists():
return {"events": []}
return json.loads(STATE_FILE.read_text())
def append_event(state, event):
state["events"].append(asdict(event))
STATE_FILE.write_text(json.dumps(state, indent=2))
def run_once(task_id: str):
state = load_state()
completed = {e["name"] for e in state["events"] if e["status"] == "completed"}
if "plan" not in completed:
plan = {"action": "send_report", "recipient": "ops@example.com"}
append_event(state, StepEvent("plan", "completed", task_id + ":plan", plan))
if "notify" not in completed:
# 真实系统应把幂等键传给邮件或消息服务。
key = hashlib.sha256((task_id + ":notify").encode()).hexdigest()
append_event(state, StepEvent("notify", "completed", key, {"sent": True}))
return load_state()
if __name__ == "__main__":
print(json.dumps(run_once("ticket-1042"), indent=2))
执行命令：
python durable_agent.py
python durable_agent.py # 第二次运行不会重复追加已完成步骤
生产实现还应把本地 JSON 替换为可靠状态存储，把事件写入与业务副作用设计成可恢复的协议，并为事件增加签名。例如，可以对规范化后的事件 JSON 计算摘要，再使用服务端密钥签名；验证方则在接受下游动作前检查签名和事件顺序。上面的代码只用于说明结构，不应直接作为跨进程审计存储。
如何与其他方案比较
比较 Catalyst 2.0 时，建议从执行语义而不是功能清单开始：
| 维度 | 需要确认的问题 |
|---|---|
| 恢复 | 进程重启、网络超时和节点故障后从哪里继续？ |
| 一致性 | 步骤状态与外部副作用如何协调？ |
| 幂等性 | 重试时如何避免重复操作？ |
| 可信历史 | 哪些输入、输出和审批事件被签名？ |
| 框架适配 | 是否覆盖团队实际使用的 Agent 框架？ |
| 运维成本 | 状态存储、密钥、升级和故障排查由谁负责？ |
| 证据质量 | 是否有公开基准、故障注入结果和端到端案例？ |
框架原生 durability 的优势通常是集成路径短、开发体验一致；成熟工作流引擎的优势则是重试、定时器、补偿和可观测性经过长期验证。Catalyst 的价值可能在于把这些能力以更统一的运行时方式带给多个 Agent 框架，但这个判断必须结合实际基准和运维边界，而不能只依据产品描述。
采用前的检查清单
可以先选择一个副作用可控的 Agent 工作流做试点，例如内部报告生成或工单分类，并记录以下数据：
- 正常路径和故障恢复路径的延迟。
- 重试次数、重复工具调用率和最终成功率。
- 节点重启、消息重复和外部 API 超时下的行为。
- 执行历史的存储成本、检索速度和签名验证耗时。
- 密钥轮换、权限隔离和验证失败时的人工处置流程。
结论应来自故障注入、基准测试和运维演练。对于低风险、短生命周期的 Agent，框架自带的状态能力可能已经足够；对于跨服务、长时间运行、需要审计或包含高价值副作用的工作流，耐久执行和可验证历史才更可能成为架构要求。