Dapr 1.18：给分布式工作流和 AI Agent 加上"不可伪造"的执行凭证

预计阅读时间：12 分钟

云原生生态花了多年时间解决分布式系统的韧性问题——请求重试、故障恢复、工作流崩溃续跑，这些已经成了基础设施的标配。但一个更棘手的问题长期被搁置：你怎么证明一段执行确实发生了，而且没有被篡改？

当 AI Agent 自主调用外部 API、当工作流跨越多个服务编排长链路业务，"信任执行结果"变得和"保证执行不中断"一样重要。Dapr 1.18 引入的 Verifiable Execution，正是要补上这块短板——把证明（attestation）、溯源（provenance）和防篡改执行历史（tamper-evident history）变成运行时自带的能力，而非事后拼凑的审计日志。

三根支柱：证明、溯源、防篡改

Dapr 1.18 的可验证执行围绕三个核心概念展开：

证明（Attestation）——执行发生时，运行环境生成一份凭证，声明"这段逻辑在什么环境下、以什么身份运行"。这不是简单的日志打点，而是绑定到具体执行上下文的签名声明。对于 AI Agent 而言，这意味着你能回答"这个 Agent 调用外部工具时，用的是哪个模型版本、哪个身份凭证"。

溯源（Provenance）——每一步执行都记录其输入来源和输出去向，形成一条可追溯的数据血缘链。工作流中 Step B 的输入来自 Step A 的输出，这条关系被结构化记录，而非散落在各服务的日志里。

防篡改执行历史（Tamper-evident Execution History）——执行记录以链式结构存储，任何对历史记录的修改都会破坏链的完整性，从而被检测出来。思路类似 Merkle Tree 或区块链的哈希链，但不需要共识机制——只需要"篡改必被发现"这一保证。

工作流和 Agent 场景下的差异

传统微服务调用链路短、输入输出相对确定，审计需求可以用 OpenTelemetry + 日志聚合勉强应对。但两种新场景让"事后审计"不再够用：

长链路工作流：一个订单流程可能横跨库存、支付、物流十几个步骤，中间还有人工审批节点。如果最终结果有争议，你需要的不只是"谁调了谁"，而是"第 7 步的输入为什么是那个值，它有没有被中途替换"。
AI Agent 自主决策：Agent 根据上下文自主选择工具和参数，执行路径不可预测。你无法提前定义所有可能的调用链，只能在事后验证每一步决策的合理性——而验证的前提是记录本身可信。

Dapr 1.18 把可验证执行嵌入 Workflow Runtime 和 Agent Runtime，让这两类场景获得原生的执行凭证能力，不需要应用层自己拼装签名和哈希逻辑。

实战：启用可验证执行的工作流

下面用一个订单处理工作流演示如何在 Dapr 1.18 中启用和检查可验证执行。前提是你已安装 Dapr 1.18 CLI 并初始化了本地环境。

1. 启用可验证执行的配置

在 Dapr 自定义资源中声明工作流时，开启 verifiableExecution：

# order-workflow.yaml
apiVersion: dapr.io/v1alpha1
kind: Workflow
metadata:
  name: order-processing
spec:
  verifiableExecution:
    enabled: true
    # 选择存储执行历史的后端；local 为本地开发用，生产建议用外部存储
    historyStore: local
    # attestation 签名方式，目前支持 jwt 和 keyed-hash
    attestationMethod: jwt
  steps:
    - name: check-inventory
      type: activity
      activityRef: checkInventory
    - name: process-payment
      type: activity
      activityRef: processPayment
      dependsOn:
        - check-inventory
    - name: ship-order
      type: activity
      activityRef: shipOrder
      dependsOn:
        - process-payment

关键字段解读： - verifiableExecution.enabled: true——开启后，Workflow Runtime 会为每个步骤生成 attestation 凭证，并将步骤间输入输出关系写入 provenance 链。 - historyStore——执行历史的持久化后端。local 适合开发调试；生产环境建议配置外部存储（如 PostgreSQL 或对象存储），确保历史记录不被单节点故障丢失。 - attestationMethod: jwt——每个步骤完成时生成一个 JWT 格式的 attestation token，包含执行身份、时间戳、步骤 ID 和输出哈希。

2. 用 Python SDK 编写工作流活动

# workflow_activities.py
from dapr.ext.workflow import WorkflowActivityContext

def check_inventory(ctx: WorkflowActivityContext, input_data: dict) -> dict:
    """检查库存，返回可用数量和 SKU 信息"""
    order_id = input_data["orderId"]
    sku = input_data["sku"]
    requested_qty = input_data["quantity"]

    # 模拟库存查询
    available = 120  # 实际应调用库存服务

    result = {
        "orderId": order_id,
        "sku": sku,
        "available": available,
        "sufficient": available >= requested_qty,
    }
    # Dapr Runtime 会自动为这个活动的输出生成 attestation
    # 并将 result 的哈希写入 provenance 链
    return result

def process_payment(ctx: WorkflowActivityContext, input_data: dict) -> dict:
    """处理支付——input_data 来自 check_inventory 的输出"""
    # 这里的 input_data 就是 provenance 链中上一步的输出
    # Runtime 会验证 input_data 的哈希与链中记录一致
    order_id = input_data["orderId"]
    amount = input_data["quantity"] * 99.0  # 单价 99

    payment_result = {
        "orderId": order_id,
        "paymentStatus": "success",
        "transactionId": f"TX-{order_id}-001",
        "amount": amount,
    }
    return payment_result

def ship_order(ctx: WorkflowActivityContext, input_data: dict) -> dict:
    """发货"""
    return {
        "orderId": input_data["orderId"],
        "trackingNumber": f"TRK-{input_data['orderId']}",
        "shipped": True,
    }

注意 process_payment 的输入来自 check_inventory 的输出——Dapr Runtime 在运行时会自动校验这个传递过程是否与 provenance 链中的记录一致。如果有人中途篡改了 check_inventory 的输出再喂给 process_payment，哈希校验会失败。

3. 查询执行历史和验证完整性

工作流运行完成后，用 CLI 查询可验证执行记录：

# 查看工作流实例的执行历史
dapr workflow history -w order-processing -i order-20250613-001

# 输出示例（简化）：
# Step 1: check-inventory
#   attestation: eyJhbGciOiJIUzI1NiIs... (JWT)
#   outputHash: a3f2b8c9d1e4...
#   provenance: input from workflow-trigger
#
# Step 2: process-payment
#   attestation: eyJhbGciOiJIUzI1NiIs...
#   outputHash: 7f6a2d3b4c1e...
#   provenance: input from check-inventory (hash: a3f2b8c9d1e4...)
#
# Step 3: ship-order
#   attestation: eyJhbGciOiJIUzI1NiIs...
#   outputHash: 9e8d7c6b5a4f...
#   provenance: input from process-payment (hash: 7f6a2d3b4c1e...)

# 验证整条执行历史的完整性（检测篡改）
dapr workflow verify -w order-processing -i order-20250613-001

# 输出：
# ✅ Execution history integrity verified
# ✅ All attestation signatures valid
# ✅ Provenance chain consistent (3 steps, 0 gaps)

verify 命令会逐步校验：每步的 attestation 签名是否有效、每步 provenance 引用的上一步输出哈希是否与实际记录匹配、整条链是否有缺失步骤。任何篡改都会导致哈希链断裂，验证失败。

4. AI Agent 场景的快速适配

对于使用 Dapr Agent Runtime 的场景，配置方式类似，但关注点略有不同：

# agent-with-verification.yaml
apiVersion: dapr.io/v1alpha1
kind: Agent
metadata:
  name: research-assistant
spec:
  verifiableExecution:
    enabled: true
    historyStore: postgres  # Agent 执行历史建议持久化到外部存储
    attestationMethod: keyed-hash
  model: gpt-4o
  tools:
    - name: web-search
      type: http
      endpoint: http://search-service:8080/search
    - name: summarize
      type: activity
      activityRef: summarizeActivity

Agent 每次调用工具后，Runtime 会记录"Agent 在第 N 步选择了工具 X，传入参数 Y，得到输出 Z"，并生成 attestation。这在 Agent 需要向下游系统证明"我的决策基于真实数据"时尤为关键——比如金融风控 Agent 声称"我查询了用户信用评分后拒绝了贷款"，你需要能验证这个查询确实发生过、返回值没有被篡改。

上手建议与边界认知

先从工作流场景切入。工作流的步骤关系是预定义的，provenance 链的结构清晰，验证逻辑容易理解。Agent 场景的执行路径不可预测，调试和验证的复杂度更高，建议在熟悉工作流可验证执行后再迁移。

生产环境必须用外部 historyStore。local 后端只适合开发，生产环境一旦节点重启，本地执行历史就丢了——而可验证执行的核心价值恰恰在于历史记录的持久性和不可篡改性。PostgreSQL、Azure Cosmos DB 或 S3 类对象存储都是合理选择。

attestationMethod 的取舍： - jwt——签名可被第三方验证，适合需要跨组织信任的场景（如供应链多方协作）。但需要管理签名密钥。 - keyed-hash——计算开销小，验证速度快，适合内部系统。但验证方必须持有同一密钥，跨组织场景不适用。

当前局限：Dapr 1.18 的可验证执行是首次引入，部分细节仍在演进——比如 historyStore 的加密存储选项、跨工作流的 provenance 关联、以及与外部 Sigstore 等签名基础设施的集成，都还在路线图上。如果你的场景需要零信任级别的跨组织证明，目前可能还需要在 Dapr 之上叠加额外的签名层。

一个快速检查清单：

✅ 你的工作流或 Agent 是否有合规/审计要求？（有 → 优先启用）
✅ 执行结果是否会被下游系统质疑或争议？（会 → provenance 链是刚需）
✅ 你是否有跨组织信任需求？（有 → 选 jwt attestation + 外部 historyStore）
✅ 你的执行历史是否需要保留超过节点生命周期？（是 → 不能用 local）
✅ 你是否已有密钥管理方案？（没有 → 先用 keyed-hash，后续迁移到 jwt）

可验证执行不会让你的系统跑得更快，但它会让你的系统跑得更"诚实"——在 AI Agent 自主性越来越强的当下，这份诚实正在从锦上添花变成底线要求。