用自然语言编写 Amazon Bedrock AgentCore 的 Dogwood 策略

AI agent 不只是回答问题，还可能调用工具、修改数据、发送消息或触发业务流程。当 agent 的行为超出组织政策时，仅依赖提示词并不足够。Amazon Bedrock AgentCore 的 Policy 能在 agent 执行操作时提供控制，并支持基于时间的约束；Policy Authoring 则可以把自然语言政策文档转换为 Dogwood 策略，帮助团队减少手写策略时的遗漏和语义歧义。

从业务规则到可执行控制

一条政策通常包含四类信息：谁可以执行操作、允许执行什么操作、作用于哪些资源，以及在什么条件下允许执行。自然语言适合业务人员表达规则，但不适合直接交给策略执行引擎，因此需要经过结构化转换。

例如，业务政策可以这样写：

客服 agent 可以在工作日 09:00 到 18:00 读取订单状态，也可以为客户创建退款申请，但退款金额超过 500 美元时必须转人工审核。非工作时间不得修改订单或发起退款。

这条规则至少包含以下约束：

• 主体：客服 agent。
• 允许操作：读取订单状态、创建退款申请。
• 时间条件：工作日的 09:00 至 18:00。
• 金额条件：退款金额超过 500 美元时不能直接执行。
• 例外处理：需要人工审核，而不是简单返回成功。
• 默认边界：非工作时间禁止修改订单或发起退款。

Policy Authoring 的价值不只是生成一段策略文本，而是把这些自然语言中的主体、动作、资源和条件映射到 Dogwood 能够评估的结构中。生成后仍应由工程团队检查动作名称、资源类型、时间区域和拒绝行为是否与实际 agent 工具定义一致。

时间约束会改变策略设计

时间条件看起来简单，实际很容易产生边界问题。下面几项需要在生成和审查时明确：

• 使用哪个时区，例如 UTC、业务总部时区，还是租户所在时区。
• 09:00 和 18:00 是否包含在允许区间内。
• 工作日由固定星期定义，还是由企业节假日日历定义。
• 夏令时切换时如何解释本地时间。
• 时间信息由平台可靠提供，还是来自 agent 可修改的请求参数。

可以把自然语言政策写得更精确：

按 America/New_York 时区计算。周一至周五 09:00:00（含）至 18:00:00（不含）允许读取订单状态。退款申请只有在该时间窗内才允许提交；退款金额大于 500 USD 时必须拒绝自动提交，并要求人工审核。

这种写法会减少“工作时间”“超过”“当天”等模糊词带来的解释差异。时间约束也不应只依赖 agent 的系统提示词，因为 prompt 可能被后续上下文影响，而策略层应该在工具调用真正执行前检查条件。

一个可改造的 Dogwood 策略草稿

下面的示例采用便于审查的 YAML 表达策略意图。它是一个示意性策略草稿，用于展示自然语言规则如何落成结构化约束；实际部署时，应根据 Amazon Bedrock AgentCore 当前支持的 Dogwood schema、工具注册信息和组织的策略 API 进行字段映射，不能直接假设字段名与生产环境完全相同。

将以下内容保存为 customer-service-policy.yaml，然后把主体、动作、资源和时区替换成项目中的真实标识：

version: "1"
name: customer-service-agent-hours
subject:
  type: agent
  id: customer-service-agent
rules:
  - name: read-order-during-business-hours
    effect: allow
    actions:
      - order.read_status
    resources:
      - order/*
    conditions:
      time:
        timezone: America/New_York
        weekdays: [MON, TUE, WED, THU, FRI]
        start: "09:00:00"
        end: "18:00:00"
        start_inclusive: true
        end_inclusive: false

  - name: submit-small-refund-during-business-hours
    effect: allow
    actions:
      - refund.create
    resources:
      - order/*
    conditions:
      time:
        timezone: America/New_York
        weekdays: [MON, TUE, WED, THU, FRI]
        start: "09:00:00"
        end: "18:00:00"
      amount:
        currency: USD
        less_than_or_equal: 500

  - name: require-human-review-for-large-refund
    effect: require_review
    actions:
      - refund.create
    resources:
      - order/*
    conditions:
      amount:
        currency: USD
        greater_than: 500

  - name: deny-order-mutating-actions-outside-hours
    effect: deny
    actions:
      - order.update
      - refund.create
    resources:
      - order/*
    conditions:
      time:
        timezone: America/New_York
        outside:
          weekdays: [MON, TUE, WED, THU, FRI]
          start: "09:00:00"
          end: "18:00:00"

这个草稿有两个值得保留的工程习惯。第一，时间区间明确写出包含关系，避免 18:00:00 到底是否允许调用。第二，把“大额退款”写成独立规则，便于把它映射到人工审核流程，而不是把所有不允许的请求都混成普通拒绝。

如果当前 Dogwood 运行时不支持 require_review 这样的效果，可以将其映射为拒绝，并让 agent 返回一个带有人工审核标识的结果：

{
  "decision": "deny",
  "reason": "refund_amount_exceeds_500_usd",
  "next_step": "human_review"
}

这里的 JSON 是应用层返回值示例，不代表 AgentCore 策略引擎的固定响应格式。生产代码应使用实际 SDK 或 API 返回结构，并记录策略 ID、决策结果和关联请求 ID。

用命令行做最小验证

策略发布前，可以准备一组固定请求，在允许和拒绝边界分别验证。下面的 curl 命令是通用 HTTP 调用模板，URL、认证方式和请求字段需要替换为实际的 AgentCore 策略评估入口：

export POLICY_EVALUATOR_URL="https://example.internal/policy/evaluate"
export AGENT_ID="customer-service-agent"

curl --fail-with-body --request POST "$POLICY_EVALUATOR_URL" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $POLICY_TOKEN" \
  --data @- <<'JSON'
{
  "agentId": "customer-service-agent",
  "action": "refund.create",
  "resource": "order/12345",
  "context": {
    "amount": 500,
    "currency": "USD",
    "timestamp": "2025-03-10T17:59:59-04:00",
    "timezone": "America/New_York"
  }
}
JSON

建议至少覆盖以下测试矩阵：

测试请求中的时间必须由可信的评估上下文提供。不要让 agent 从用户文本中读取“现在是工作时间”，也不要把客户端传来的时间直接当成权威时间，否则调用方可能通过修改时间绕过控制。

Policy Authoring 的审查清单

自然语言生成策略能减少起草工作，但不能替代策略评审。上线前可以逐项检查：

• 每个自然语言动作是否对应一个真实注册工具，而不是相似但更宽泛的动作。
• 资源匹配是否足够具体，order/* 是否会覆盖不应由该 agent 访问的订单。
• 允许规则和拒绝规则冲突时，实际评估优先级是否符合预期。
• 未命中任何允许规则时，默认行为是否为拒绝。
• 时间条件使用的时区是否写入策略，而不是藏在应用配置中。
• 金额、货币、精度和舍入规则是否明确。
• “人工审核”是否真的连接到人工队列、工单系统或暂停执行机制。
• 生成的 Dogwood 策略是否通过语法校验、静态检查和边界测试。
• 策略变更是否有版本号、审批记录、回滚方案和审计日志。

如何落地更稳妥

适合把 Policy Authoring 当作策略起草和转换工具，而不是无人审核的发布流水线。团队可以让业务人员维护自然语言政策，安全或平台工程师负责确认实体映射、冲突规则、默认拒绝行为和运行时字段，随后用固定测试集验证生成结果。

时间策略尤其适合从小范围开始：先保护读取和写入动作边界，再加入退款、付款、删除等高风险操作；先固定单一时区，再处理跨地区租户和节假日。这样既能验证 Dogwood 策略与 agent 工具调用之间的契合度，也能在规则出错时控制影响范围。

最终目标不是生成更多策略，而是让每一次 agent 行动都能回答三个问题：谁发起了操作、操作发生在什么上下文中、为什么策略允许或拒绝它。自然语言负责表达意图，Dogwood 负责执行约束，测试和审计则负责证明约束确实生效。