标题：Amazon Bedrock 中用于自动推理策略的 Agent Skills

AWS ML Blog 2026-08-12T12:28:07.588905

采用 Amazon Bedrock 自动推理（Automated Reasoning）检查的团队，往往希望在代码中跑完整个策略生命周期。在代码里运作，意味着工作可重复、可审查，还能交给团队已经使用的编码代理来执行。不过，要写好一条自动推理策略本身有学习成本，生命周期里的各种限制也容易让人踩坑。你需要用 SMT-LIB 的一个子集来写规则——SMT-LIB 是自动定理证明器的标准输入格式——还要反复调优变量描述，直到服务能把真实用户的语言准确翻译成规则。接下来，你还要把策略放进构建、测试、优化这个循环里，而这个循环有自己独立的 API 和约束条件。之所以值得花这些功夫，是因为自动推理检查是用形式逻辑来验证输出，而不是用统计方式抽样。这种方法能给你数学级的确信：AI 的回答确实符合你的规则。

在《使用 Amazon Bedrock 上的自动推理构建可靠 AI 系统》那篇文章里，我们在 Amazon Bedrock 控制台上演示了这个循环。控制台适合入门，也适合与领域专家协作。而在这篇文章中，你将学会如何用一组 Agent Skills，从编码代理出发，端到端地构建、测试、部署并验证一条 Amazon Bedrock 自动推理策略。你还会看到，把这组技能拿到 Amazon Bedrock 上实际跑一遍后，服务表现出的一些真实行为。

什么是 Agent Skills？

Agent Skills 是 Anthropic 推出的轻量级开放格式。一项技能可以给编码代理补充专门的知识和工作流程。它其实是一份结构化的上下文包，教会代理如何正确使用某个特定服务或领域。这样一来，代理不再依赖可能过时或不完整的通用训练数据。每项技能里都包含了经过验证的用法、需要避开的常见错误，以及一步步的操作流程。有了这些指引，代理就会针对任务发出正确的调用，而不是给一个听起来合理的猜测。因为格式是开放的，任何支持它的代理都能安装技能，包括 Kiro、Claude Code、Cursor 和 Codex。当代理收到涉及该技能覆盖范围的任务时，它会自动激活。

Agent Skills 为 Amazon Bedrock 中的自动推理策略而生

为什么 Agent 适合自动推理的完整流程

一次自动推理（Automated Reasoning）检查分两步完成，理解这个拆分是掌握它的关键。首先，一组基础模型（Foundation Model，简称 FM）把问题和答案转换成形式逻辑，将自然语言映射到你策略里的变量上。随后，一个 SMT 求解器（Satisfiability Modulo Theories，一种自动推理引擎，用于对照约束条件检验逻辑公式）用你的规则去校验这段逻辑，并给出判定结果。

校验这一步在数学上是严谨的：只要翻译是忠实的，判定就是正确的。这种严谨性也正是结果可解释的原因——每个判定都会附带支持或否定它的具体规则。

图 1：自动推理检查的工作原理

真正的工作量集中在围绕这次检查的整个流程上。你需要从源文档中提取规则、审查服务生成的结果、编写反映用户真实提问方式的测试、诊断失败原因，最后在防护栏（guardrail）背后部署一个带版本号的策略。每一步都有特定的 API 形态，其中几步还存在容易踩坑的约束条件。

这是一项重复性高、细节密集的工作，规则清晰、失败模式明确——只要给出正确的指令，这正是编码 Agent 能出色完成的那类任务。

覆盖策略全流程的六项技能

这套方案由六项 Agent Skills（Agent 技能）组成，每一项对应策略生命周期中的一个阶段。每个技能都是一份简短的指令文件，教会 Agent 在该阶段如何做出判断，并配有可直接运行的脚本，用于调用 Amazon Bedrock 的自动推理 API。这些技能共享一份参考文档，其中描述了 API 接口、发现类型（finding types）和规则语法，确保整套方案中的指导口径保持一致。

图 2：策略生命周期上的六项技能

在编写阶段，builder 技能负责根据源文档创建策略，并提取其中的规则和变量。reviewer 技能则负责阅读构建过程生成的质量报告和保真度报告，标记出规则冲突、未使用的变量、裸断言（bare assertions）等问题。

测试技能会生成测试场景并运行问答测试，用来检查策略是否能按你的预期翻译并验证真实输入。调试技能负责诊断失败并修复策略，其依据的基本原则是：错误的裁决几乎总是源于翻译问题，而不是规则本身。在运行时，部署技能会对带编号的策略版本做快照，并将其挂接到护栏上。验证技能通过 ApplyGuardrail API 检查答案，此外还可以运行一个重写循环：把失败答案中相互矛盾的规则反馈给模型，直到答案变得合理为止。

技能的结构

每个技能都遵循标准的 Agent Skills 布局。SKILL.md 文件保存该阶段的核心指令，包括该技能何时适用、该阶段有哪些需要判断的地方。references/ 文件夹存放更深入的资料，例如发现类型和规则语法，代理只在需要细节时才加载这些内容。scripts/ 文件夹存放可运行的 Python 脚本，用于调用 Amazon Bedrock 自动推理 API。这些脚本是独立的，带有 --help 和 --dry-run 标志。你可以在请求到达 Amazon Bedrock 之前，查看某项操作的作用并检查确切的请求内容。六个技能之下的一个共享库负责处理公共工作：创建客户端、轮询构建工作流、解析发现结果，以及管理本文后面介绍的构建槽位限制。

从策略文档到经过验证的答案

下面的演示在一条关于育儿假资格的简短人力资源策略上运行完整的生命周期。这个示例很紧凑，便于看清流程，同样的步骤也适用于贷款资格策略、保险覆盖策略，以及其他答案必须遵循书面规则的领域。

前提条件

你需要一个 AWS 账户，并在支持自动推理检查的 AWS 区域中能够访问 Amazon Bedrock；同时需要 Amazon Bedrock 控制平面和运行时 API 的权限，还需要带 uv 的 Python 环境来运行脚本。各区域的功能可用性，请参阅 Amazon Bedrock 文档中的“自动推理检查”一节。

先克隆仓库，再把技能安装到你的编程代理（coding agent）中。在 Claude Code 里，把整套技能作为插件市场添加进来，然后选择并安装你需要的技能：

/plugin marketplace add ./amazon-bedrock-samples/responsible_ai/automated-reasoning-checks-skills

Agent Skills for Automated Reasoning policies in Amazon Bedrock

对于支持开放格式（open format）的其他代理（如 Kiro、Cursor、Codex），可以使用 npx 安装。技能位于子文件夹中，因此需要将 npx 指向完整的树 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 '*'

无论采用哪种方式，当你向代理询问匹配的任务（比如根据文档创建策略，或调试失败的测试）时，技能都会自动激活。

创建策略并提取规则

从一个简短的源文档开始，用通俗语言描述规则。例如：全职员工如果服务满 12 个月，就有资格休育儿假，而兼职员工则没有。构建器技能（builder skill）会创建策略资源，并启动构建任务，从文档中提取正式规则和变量模式（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."

在一次运行中，构建过程从三句源文本中提取了六条规则、四个变量和一个自定义类型，其中包括一条用于确保在职时长非负的边界规则。

审查服务生成的结果

规则提取并非确定性操作，因此请在测试前审查结果。审阅者技能会拉取质量报告和策略定义，并对其进行总结。

uv run audit_policy.py --policy-arn

审计会报告规则、变量和类型的数量，然后按严重级别标记结构性问题。对于此策略，它指出一个未使用的变量和一个不相交的规则集，两者都属于低严重级别的待考虑项，而非错误。审计还报告未生成保真度报告，因为标准内容构建不会生成该报告。当你需要面向主题专家的源文本对照视图时，可以通过单独的构建类型来请求该报告。

编写并运行测试

测试者技能会创建问答测试，并对已完成的构建运行该测试。测试内容包含用户可能提出的问题、你的模型可能给出的答案，以及你期望得到的判定结果。

uv run create_test.py --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

测试流程会返回预期判定和实际判定，并显示二者是否匹配。对于此策略，答案验证结果为 VALID，实际结果与预期结果一致。

部署到护栏后面并验证答案

策略通过测试后，部署者技能会生成一个不可变的编号版本快照，并将其附加到护栏上；验证者技能则会检查实时答案。

uv run create_version.py --policy-arn

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

uv run validate_response.py --guardrail-id --guardrail-version 1 \
--question "I'm full-time with 18 months. Am I eligible for parental leave?" \

验证器（validator）返回检查结果，确认这次检查确实执行了。以上面的输出为例，回答返回的是 VALID，并附带了一条佐证规则——这就是你为已验证回答保留的审计追踪记录。

--answer "Yes, you are eligible for parental leave."

跑完整个生命周期后，我们得到两条重要经验，它们都直接影响这些技能的行为方式。

第一，可解释性是这套功能的核心。每一个裁决（verdict）都会返回它背后的规则：VALID 回答附佐证规则，INVALID 回答附矛盾规则。验证器技能会把它们记录在案，于是被放行的回答自带数学上可验证的依据，被拒绝的回答也会把触犯的那条规则原样带入重写步骤。下图展示了这个运行时重写循环：检查返回非 VALID 裁决并附上回答违反的规则，模型据此重写回答，再重新检查，直到回答合法为止。

图 3：运行时重写循环

第二，SATISFIABLE 裁决不等于失败。Automated Reasoning 会区分两种回答：一种是「与你的策略一致」，另一种是「由策略推导出来（entailed）」。假设某条规则规定「全职员工且任职满一定年限即有资格」，那么一个声称有资格的回答只是与策略一致，并没有被策略本身证明。因此服务返回的是 SATISFIABLE 而不是 VALID。如果把这当成失败，你可能会去修改本来就没问题的规则。调试器（debugger）技能把这一区别内化在自身逻辑里，让智能体（agent）按服务定义的方式去解读裁决结果。

还有一个实际限制值得注意，技能已经替你处理好了。策略对并发构建工作流的数量设了上限，长时间的优化会话可能触达这个上限。技能会在每次构建前自动释放一个插槽——删除最旧的已完成构建——这样智能体在多次优化迭代中不会因为上限卡住。

清理资源

为避免持续产生费用，请按依赖顺序删除你创建的资源。原因是：只要测试用例、构建工作流或版本仍然存在，策略（policy）就无法被删除。

先删除测试用例，然后删除构建工作流和带编号的版本，再删除策略，最后删除护栏。这些技能在拆除资源时按此顺序执行，你也可以直接从 Amazon Bedrock 控制台删除所有内容。

结论

Automated Reasoning 检查为 AI 回答提供可验证、可解释的判定，而这些判定的质量取决于其背后的策略。本文中的 Agent Skills 将完整的策略编写生命周期迁移到代码中，使得构建、审查、测试、调试、部署和验证策略成为可重复的步骤，你的编码代理可以运行这些步骤，你也能对它们进行审查。该方法不仅限于育儿假示例，也不仅限于单个代理。它适用于从金融、保险到医疗保健等多个策略领域，并且可以安装到你已有的编码代理中。

要开始使用：

要深入了解，可探索以下相关资源：

关于作者

Adewale Akinfaderin

Adewale 是 AWS Amazon Bedrock 团队负责生成式 AI 的高级数据科学家，致力于基础模型和生成式 AI 应用的创新。他的专长在于可复现的端到端 AI/ML 方法，并帮助全球客户构建可扩展的跨学科问题解决方案。他拥有两个物理学研究生学位和一个工程学博士学位。

查看原文