用Agent管理Bedrock推理策略全流程

采用 Amazon Bedrock Automated Reasoning checks 的团队，通常希望通过代码运行完整的 policy 生命周期。将整个流程代码化，可以让工作可重复、可审查，并由团队已经在使用的 coding agent 驱动。编写一套优秀的 Automated Reasoning policy 存在一定的学习曲线，而且生命周期中的一些约束也很容易让人踩坑。你需要使用 SMT-LIB 的一个子集编写规则——SMT-LIB 是自动定理证明器使用的标准输入格式——并不断调整变量描述，直到服务能够正确地将真实用户语言转换为形式化表达。你还需要通过各自具有专用 API 和约束的构建、测试和优化循环来迭代 policy。

Automated Reasoning checks 值得投入这些精力，因为它不是通过统计采样，而是依据形式逻辑验证输出。这种方式可以在数学意义上确保 AI 响应符合你的规则。在《使用 Amazon Bedrock Automated Reasoning 构建可靠的 AI 系统》中，我们曾通过 Amazon Bedrock 控制台演示这一循环。控制台是开始使用该功能，以及与领域专家协作的合适场所。

本文将介绍如何使用一套 Agent Skills，直接从 coding agent 端到端地构建、测试、部署和验证 Amazon Bedrock Automated Reasoning policy。你还将看到，在 Amazon Bedrock 上实际运行这套技能之后，我们发现了哪些服务行为特征。

什么是 Agent Skills？

Agent Skills 是 Anthropic 推出的一种轻量级开放格式。Skill 可以通过专业知识和工作流扩展 coding agent 的能力。它是一种结构化的上下文包，用于教会 Agent 如何正确使用某项特定服务或处理某个专业领域。这样一来，Agent 不再依赖可能不完整或已经过时的通用训练数据。每个 Skill 都包含经过验证的模式、需要避免的常见错误，以及分步骤的工作流。有了这些指导，Agent 能够针对任务生成正确的调用，而不是给出一个看似合理的猜测。由于这一格式是开放的，因此 Skill 可以安装到任何支持该格式的 Agent 中，包括 Kiro、Claude Code、Cursor 和 Codex。当你向 Agent 提出该 Skill 所覆盖的任务时，它就会自动激活。

为什么 Agent 适合 Automated Reasoning 生命周期

一次 Automated Reasoning check 分为两个步骤，理解这种分工是正确使用它的关键。首先，一组 foundation models（FMs）会把问题和答案转换为形式逻辑，将自然语言映射到 policy 中的变量。随后，SMT solver（Satisfiability Modulo Theories，一种根据约束检查逻辑公式的自动推理引擎）会依据规则验证这些逻辑，并返回 verdict。验证步骤在数学上是可靠的：只要转换忠实于原文，verdict 就一定正确。这种可靠性也让结果具备可解释性。每个 verdict 都会附带支持或反驳它的具体规则。

图 1：Automated Reasoning check 的工作方式

真正的工作集中在这次检查周围的生命周期中。你需要从源文档中提取规则，审查服务生成的结果，编写能够反映用户真实提问方式的测试，诊断失败原因，并将带版本号的 policy 部署到 guardrail 后面。每一步都有特定的 API 结构，其中一些步骤还存在容易踩坑的约束。这类工作重复、注重细节，而且拥有明确的规则与失败模式；只要为 coding agent 提供正确的指令，它就非常擅长处理这种任务。

覆盖 policy 生命周期的六个 Skill

这套工具由六个 Agent Skills 组成，分别对应生命周期的一个阶段。每个 Skill 都包含一个简短的指令文件，负责向 Agent 传授该阶段所需的判断方法，并配有调用 Amazon Bedrock Automated Reasoning APIs 的小型可执行脚本。这些 Skill 共用一份参考文档，其中描述了 API 接口、finding 类型和规则语法，从而确保整套工具的指导保持一致。

图 2：覆盖 policy 生命周期的六个 Skill

在编写阶段，builder skill 会根据源文档创建 policy，并提取其中的规则和变量。reviewer skill 会读取构建过程生成的质量报告和保真度报告，并标记规则冲突、未使用的变量和裸断言等问题。tester skill 会生成测试场景，并运行问答测试，检查 policy 对真实输入的转换和验证结果是否符合预期。debugger skill 则会诊断失败并修复 policy，其依据的核心原则是：错误的 verdict 几乎总是来自转换问题，而不是规则本身。

在运行时阶段，deployer skill 会创建一个带编号的 policy 版本快照，并将它挂载到 guardrail。validator skill 使用 ApplyGuardrail API 检查答案。它还可以运行一个重写循环：把失败答案所违反的规则重新交给模型，直到模型生成逻辑可靠的答案。

Skill 的结构

每个 Skill 都遵循标准的 Agent Skills 目录结构。SKILL.md 文件包含该阶段的核心指令，其中包括 Skill 的适用场景，以及该阶段特有的判断规则。references/ 文件夹存放 finding 类型、规则语法等更深入的资料，Agent 只会在需要相关细节时加载它们。scripts/ 文件夹存放调用 Amazon Bedrock Automated Reasoning APIs 的可执行 Python 脚本。这些脚本可以独立运行，并且支持 --help 和 --dry-run 参数。你可以阅读某项操作的作用，并在请求真正发送到 Amazon Bedrock 之前检查完整的请求内容。六个 Skill 底层共用一个共享库，用于处理创建客户端、轮询构建工作流、解析 findings，以及管理本文稍后介绍的构建槽位限制等通用工作。

从 policy 文档到经过验证的答案

下面的演练将针对一份简短的人力资源 policy，运行完整的生命周期，用于判断员工是否符合育儿假资格。这个示例刻意保持简洁，以便清晰展示流程；同样的步骤也适用于贷款资格 policy、保险保障范围 policy，以及其他要求答案必须遵循书面规则的领域。

你需要准备一个 AWS 账户，并能够在支持 Automated Reasoning checks 的 AWS Region 中访问 Amazon Bedrock；还需要具备调用 Amazon Bedrock 控制面和运行时 APIs 的权限，以及安装了 uv 的 Python 环境来运行脚本。关于不同 Region 的功能可用性，请参阅 Amazon Bedrock 文档中的 Automated Reasoning checks。克隆代码仓库，然后将这些 Skill 安装到你的 coding agent 中。

在 Claude Code 中，将这套工具添加为 plugin marketplace，并安装所需的 Skill：

/plugin marketplace add ./amazon-bedrock-samples/responsible_ai/automated-reasoning-checks-skills
/plugin install ar-policy-builder@automated-reasoning-skills

对于 Kiro、Cursor 和 Codex 等支持开放格式的其他 Agent，可以使用 npx 安装：

# the skills live in a subfolder, so point npx at the full tree URL
REPO=https://github.com/aws-samples/amazon-bedrock-samples
SUBDIR=responsible_ai/automated-reasoning-checks-skills

npx skills add $REPO/tree/main/$SUBDIR --skill '*'

无论采用哪种方式，当你向 Agent 提出与某项 Skill 匹配的任务时，例如根据文档创建 policy 或调试失败的测试，该 Skill 都会自动激活。

创建 policy 并提取规则

首先准备一份简短的源文档，用自然语言陈述规则。例如，工作时间超过 12 个月的全职员工符合育儿假资格，而兼职员工不符合资格。builder skill 会创建 policy 资源，并启动构建流程，从文档中提取形式化规则和变量 schema。

uv run create_policy.py --name "hr-leave-policy" \
--description "Validates parental leave eligibility answers"

uv run build_from_document.py --policy-arn <policy-arn> \
--file leave-policy.txt --doc-name "Leave Policy" \
--instructions "Capture full-time status and tenure in months; focus on eligibility."

在其中一次运行中，构建流程从三句话的源文本里提取出了六条规则、四个变量和一个自定义类型，其中还包括一条确保任职时长不为负数的边界规则。

审查服务生成的结果

规则提取并不是确定性的，因此在测试之前需要审查结果。reviewer skill 会获取质量报告和 policy 定义，并对其进行汇总。

uv run audit_policy.py --policy-arn <policy-arn>

审计报告会列出规则、变量和类型的数量，然后根据严重程度标记结构性问题。对于这份 policy，它发现了一个未使用的变量和一组彼此不相交的规则；两者都属于需要留意的低严重度问题，而不是错误。报告还指出系统没有生成保真度报告，因为标准内容构建不会生成该报告。如果希望为领域专家提供源文档依据视图，则需要通过另一种构建类型单独请求。

tester skill 会创建问答测试，并针对已经完成的构建运行测试。每个测试都需要指定用户可能提出的问题、模型可能给出的答案，以及你预期得到的 verdict。

uv run create_test.py --policy-arn <policy-arn> \
--input "I'm full-time with 18 months. Am I eligible for leave?" \
--output "Yes, you are eligible for parental leave." \
--expected VALID

uv run run_tests.py --policy-arn <policy-arn>

测试工作流会返回预期 verdict、实际 verdict，以及两者是否匹配。对于这份 policy，答案被验证为 VALID，实际结果与预期结果一致。

部署到 guardrail 后面并验证答案

policy 通过测试之后，deployer skill 会创建一个不可变的带编号版本快照，并将它挂载到 guardrail；随后，validator skill 会检查实时答案。

uv run create_version.py --policy-arn <policy-arn>
uv run deploy_guardrail.py --policy-arn <policy-arn> \
--policy-version 1 --guardrail-name hr-leave-guardrail

uv run validate_response.py --guardrail-id <guardrail-id> --guardrail-version 1 \
--question "I'm full-time with 18 months. Am I eligible for parental leave?" \
--answer "Yes, you are eligible for parental leave."

validator 会返回 finding，并确认检查已经运行。在这个示例中，答案返回 VALID，同时附带了支持它的规则；这就是你需要为经过验证的响应保留的审计轨迹。

运行这套 Skill 后得到的经验

在 Amazon Bedrock 上运行完整生命周期后，有两点经验尤其突出，它们也直接影响了这些 Skill 的行为方式。

第一，可解释性处于该功能工作机制的核心。每个 verdict 都会返回其背后的规则：VALID 答案会附带支持它的规则，INVALID 答案则会附带与它冲突的规则。validator skill 会记录这些规则，因此经过验证的答案在交付时会附带一份可从数学上验证的说明，解释它为什么被允许；被拒绝的答案则会把它违反的具体规则带入重写步骤。下面的示意图展示了这一运行时重写循环：检查返回一个非 VALID verdict，并附上答案所违反的规则；模型使用该规则重写答案；然后再次运行检查，直到答案在逻辑上可靠。

图 3：运行时重写循环

第二，SATISFIABLE verdict 并不代表失败。Automated Reasoning 会区分“答案与 policy 一致”和“答案可以由 policy 推导出来”这两种情况。假设有一条规则规定，任职时长足够的全职员工符合资格。某个直接断言员工符合资格的答案可能与 policy 一致，但无法由 policy 证明，因此服务会返回 SATISFIABLE，而不是 VALID。如果把这个结果当成失败，就会导致你修改原本正确的规则。debugger skill 内置了这种区分，因此 Agent 能够按照服务定义的方式解释 verdict。

还有一个实际约束值得注意，因为这些 Skill 已经替你处理了它。一个 policy 只允许有限数量的并发构建工作流，长时间的优化会话可能会达到这个上限。每次构建之前，Skill 都会删除最早完成的构建，自动释放一个槽位，因此 Agent 即使连续进行多轮优化，也不会因为达到上限而停滞。

为了避免持续产生费用，请按照依赖顺序删除创建的资源，因为只要 policy 的测试用例、构建工作流或版本仍然存在，就无法删除该 policy。首先删除测试用例，然后删除构建工作流和带编号的版本，接着删除 policy，最后删除 guardrail。这些 Skill 在清理资源时会遵循这一顺序；你也可以通过 Amazon Bedrock 控制台删除所有资源。

Automated Reasoning checks 可以针对 AI 答案给出可验证、可解释的 verdict，而这些 verdict 的质量取决于背后的 policy。本文介绍的 Agent Skills 将完整的编写生命周期迁移到了代码中，使构建、审查、测试、调试、部署和验证 policy 都成为可重复的步骤，由 coding agent 负责运行，并由你进行审查。这种方法并不局限于育儿假示例，也不局限于某一种 Agent。它适用于从金融、保险到医疗健康等各种 policy 领域，并且可以安装到你已经在使用的 coding agent 中。

将代码仓库中的 Skill 安装到你的 coding agent。

让 builder skill 读取你自己的 policy 文档，并审查质量报告。

添加能够反映用户真实提问方式的问答测试，持续优化，直到所有测试通过。

将带版本号的 policy 部署到 guardrail 后面，并使用 runtime skill 验证答案。

如需进一步了解，可以探索以下相关资源：

《使用 Amazon Bedrock Automated Reasoning 构建可靠的 AI 系统》，了解控制台工作流。

《Amazon Bedrock 中的 Automated Reasoning checks 如何改变生成式 AI 合规》，了解合规视角下的应用。

《Automated Reasoning checks 重写聊天机器人》，了解运行时参考实现。

《Amazon Bedrock Automated Reasoning checks 用户指南》和《Amazon Bedrock API 参考》。