用于 Amazon Bedrock Automated Reasoning 策略的 Agent Skills

采用 Amazon Bedrock Automated Reasoning 检查的团队，通常希望以代码方式运行策略生命周期。将其置于代码中执行，可以让工作具备可重复性、可审查性，并由团队已经使用的编码 Agent 驱动。编写高质量的 Automated Reasoning 策略存在一定学习曲线，而且其生命周期中也有一些容易造成问题的约束。你需要使用 SMT-LIB 的一个子集（一种自动定理证明器的标准输入格式）编写规则，并调整变量描述，直到服务能够正确翻译真实用户使用的自然语言。你还需要通过具有专属 API 和约束的构建、测试与迭代流程来推进策略。

Automated Reasoning 检查值得投入这些工作，因为它们会依据形式逻辑验证输出，而不是对输出进行统计抽样。这种方法能够以数学确定性保证 AI 响应符合你的规则。在使用 Amazon Bedrock 上的 Automated Reasoning 构建可靠 AI 系统中，我们曾介绍如何在 Amazon Bedrock 控制台中完成这一流程。控制台是入门和与领域专家协作的合适场所。

本文将介绍如何使用一套 Agent Skills，从编码 Agent 端到端构建、测试、部署和验证 Amazon Bedrock Automated Reasoning 策略。你还将了解，将这套工具用于 Amazon Bedrock 后，我们对服务行为获得了哪些认识。

什么是 Agent Skills？

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

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

一次 Automated Reasoning 检查分为两个步骤，理解这种拆分是正确使用它的关键。首先，一组基础模型（FMs）会将问题和答案翻译成形式逻辑，把自然语言映射至策略中的变量。随后，SMT 求解器（Satisfiability Modulo Theories，即一种依据约束检查逻辑公式的自动推理引擎）会依据你的规则验证这些逻辑，并返回裁定结果。验证步骤具有数学可靠性：如果翻译是忠实的，裁定就是正确的。这种可靠性也使结果具备可解释性。每个裁定结果都会附带支持或反驳该结果的具体规则。

图 1：Automated Reasoning 检查的工作方式

相关工作位于这项检查周围的生命周期中。你需要从源文档中提取规则，审查服务生成的内容，编写反映用户实际提问方式的测试，诊断失败原因，并在 Guardrail 后部署版本化策略。每一步都有特定的 API 形式，其中一些还存在容易导致问题的约束。这是一类重复性强、细节密集、规则和失败模式清晰的工作；如果给予正确指令，编码 Agent 很擅长处理这类工作。

覆盖策略生命周期的六项 Skill

该套件由六项 Agent Skill 组成，每项对应生命周期中的一个阶段。每项 Skill 都是一个简短的指令文件，向 Agent 传授该阶段所需的判断方法，并由调用 Amazon Bedrock Automated Reasoning API 的小型可运行脚本提供支持。这些 Skill 共用一份参考文档，其中描述了 API 接口、发现类型和规则语法，以确保整套工具的指导保持一致。

图 2：覆盖策略生命周期的六项 Skill

在创作阶段，builder Skill 根据源文档创建策略，并提取其中的规则和变量。reviewer Skill 读取构建生成的质量与保真度报告，标记冲突规则、未使用变量和孤立断言等问题。tester Skill 生成场景，并运行问答测试，检查策略是否会按你的预期翻译和验证真实输入。debugger Skill 诊断失败并修复策略，其工作基于一项原则：错误的裁定几乎总是源于翻译问题，而非规则本身。

在运行阶段，deployer Skill 会创建带编号的策略版本快照，并将其附加到 Guardrail。validator Skill 使用 ApplyGuardrail API 检查答案。它还可以运行一个重写循环：将失败答案所违反的规则反馈给模型，直到答案满足逻辑要求。

Skill 的结构

每项 Skill 都遵循标准的 Agent Skills 布局。SKILL.md 文件包含该阶段的核心指令，包括 Skill 的适用时机及其特有的判断准则。references/ 文件夹包含更深入的材料，例如发现类型和规则语法，Agent 仅在需要细节时才加载这些材料。scripts/ 文件夹则包含调用 Amazon Bedrock Automated Reasoning API 的可运行 Python 脚本。这些脚本均可独立运行，并支持 --help 标志和 --dry-run 标志。你可以了解某项操作的用途，并在请求发送至 Amazon Bedrock 前检查其精确请求内容。六项 Skill 下方的共享库则负责通用工作，包括创建客户端、轮询构建工作流、解析发现结果，以及管理本文后续将介绍的构建槽位限制。

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

以下演练针对一项简短的人力资源策略运行完整生命周期，该策略用于判断员工是否符合育儿假资格。为了清晰展示流程，该示例保持精简；同样的步骤也适用于贷款资格策略、保险保障策略，以及其他要求答案严格遵循书面规则的领域。

前提条件

你需要一个 AWS 账户，并且该账户可以在支持 Automated Reasoning 检查的 AWS Region 中访问 Amazon Bedrock；还需要具备 Amazon Bedrock 控制平面和运行时 API 的权限，以及用于运行脚本的 Python 和 uv。关于各 Region 的功能可用性，请参阅 Amazon Bedrock 文档中的 Automated Reasoning 检查。克隆仓库，然后将这些 Skill 安装到你的编码 Agent 中。

在 Claude Code 中，将该套件添加为插件市场，并安装所需的 Skill：

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

对于其他支持这一开放格式的 Agent，例如 Kiro、Cursor 和 Codex，请使用 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 都会自动激活，例如根据文档创建策略，或调试失败的测试。

创建策略并提取规则

先从一份以自然语言陈述规则的简短源文档开始。例如，文档可以规定：服务期超过 12 个月的全职员工符合育儿假资格，兼职员工则不符合。builder Skill 会创建策略资源，并启动构建流程，从文档中提取形式化规则和变量架构。

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 会获取质量报告和策略定义，并对其进行汇总。

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

审计报告会给出规则、变量和类型的数量，然后按严重程度标记结构性问题。对于该策略，报告指出了一个未使用变量和一组不相交规则；两者均为低严重性事项，需要考虑，但并非错误。报告还指出，未生成保真度报告，因为标准内容构建不会生成该报告。当你希望为领域专家提供源文档依据视图时，需要通过单独的构建类型请求该报告。

编写并运行测试

tester Skill 会创建问答测试，并针对已完成的构建运行测试。一个测试包含用户可能提出的问题、模型可能给出的答案，以及你期望得到的裁定。

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>

测试工作流会返回预期裁定和实际裁定，以及二者是否匹配。对于该策略，答案被验证为 VALID，实际结果与预期结果一致。

在 Guardrail 后部署并验证答案

策略通过测试后，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 会返回发现结果，并确认检查已经运行。在这里，答案返回为 VALID，并附带支持该结论的规则；这就是应为已验证响应保留的审计轨迹。

运行该套件带来的经验

将完整生命周期用于 Amazon Bedrock 后，有两项经验尤为突出，并且都影响着这些 Skill 的行为方式。

第一项经验是，可解释性处于该功能工作方式的核心。每项裁定都会返回其背后的规则：VALID 答案会返回支持规则，INVALID 答案会返回反驳规则。validator Skill 会记录这些规则，因此，经验证的答案在发布时会附带有关其为何被允许的、可由数学验证的证明；被拒绝的答案则会将其违反的精确规则带入重写步骤。下图展示了这一运行时重写循环：检查返回非 VALID 的裁定及答案违反的规则，模型依据该规则重写答案，随后再次运行检查，直至答案满足逻辑要求。

图 3：运行时重写循环

第二项经验是，SATISFIABLE 裁定并不代表失败。Automated Reasoning 区分与策略一致的答案和由策略蕴含的答案。假设一条规则规定，任职时间足够长的全职员工符合资格。一个断言其符合资格的答案与策略一致，但策略并未证明该断言，因此服务会返回 SATISFIABLE 而不是 VALID。将该结果理解为失败，会导致你修改原本正确的规则。debugger Skill 编码了这种区别，使 Agent 能够按照服务定义的方式解释裁定结果。

还有一个值得注意的实际约束，Skill 会为你处理它。一项策略允许的并发构建工作流数量有限，而长时间的迭代会话可能达到这一上限。每次构建前，Skill 都会通过移除最早完成的构建来自动释放一个槽位，因此，Agent 在进行多轮迭代时不会因触及上限而停滞。

清理

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

结论

Automated Reasoning 检查能够为 AI 答案提供可验证、可解释的裁定，而这些裁定的质量取决于其背后的策略。A

Teams that adopt Amazon Bedrock Automated Reasoning checks often want to run the policy lifecycle in code. Running it in code keeps the work repeatable, reviewable, and driven by the coding agent they already use. Authoring a good Automated Reasoning policy has a learning curve, and the lifecycle has constraints that can trip you up. You write rules in a subset of SMT-LIB (a standard input format for automated theorem provers) and tune variable descriptions until the service translates real user language correctly. You also move a policy through a build, test, and refine loop with its own APIs and constraints.

Automated Reasoning checks are worth that effort because they validate outputs against formal logic rather than sampling them statistically. That approach gives you mathematical certainty that AI responses comply with your rules. In Build reliable AI systems with Automated Reasoning on Amazon Bedrock, we walked through this loop in the Amazon Bedrock console. The console is the right place to start and to collaborate with subject matter experts.

In this post, you learn how to use a suite of Agent Skills to build, test, deploy, and validate an Amazon Bedrock Automated Reasoning policy end to end from a coding agent. You also see what running the suite against Amazon Bedrock revealed about how the service behaves.

What are Agent Skills?

Agent Skills are a lightweight, open format from Anthropic. A skill extends a coding agent with specialized knowledge and workflows. It’s a structured context package that teaches the agent how to use a specific service or domain correctly. The agent no longer relies on general training data that may be incomplete or out of date. Each skill carries validated patterns, the common mistakes to avoid, and step-by-step workflows. With that guidance, the agent produces the right calls for the task instead of a plausible guess. Because the format is open, a skill installs into any agent that supports it, including Kiro, Claude Code, Cursor, and Codex. It then activates automatically when you ask the agent about the task it covers.

Why an agent fits the Automated Reasoning lifecycle

An Automated Reasoning check runs in two steps, and understanding the split is the key to working with it. First, a set of foundation models (FMs) translates the question and answer into formal logic, mapping the natural language to the variables in your policy. Then an SMT solver (Satisfiability Modulo Theories, an automated reasoning engine that checks logical formulas against constraints) validates that logic against your rules and returns a verdict. The validation step is mathematically sound: If the translation is faithful, the verdict is correct. That soundness is also what makes the result explainable. Every verdict comes back with the specific rules that support or contradict it.

Figure 1: How an Automated Reasoning check works

The work sits in the lifecycle around that check. You extract rules from a source document, review what the service produced, write tests that reflect how your users actually ask questions, diagnose the failures, and deploy a versioned policy behind a guardrail. Each step has a specific API shape, and a few have constraints that can trip you up. This is repetitive, detail-heavy work with clear rules and clear failure modes, which is the kind of work a coding agent handles well when you give it the right instructions.

Six skills across the policy lifecycle

The suite is a set of six Agent Skills, one for each stage of the lifecycle. Each skill is a short instruction file that teaches the agent the judgment for its stage, backed by small runnable scripts that call the Amazon Bedrock Automated Reasoning APIs. The skills share one reference document that describes the API surface, the finding types, and the rule syntax, so guidance stays consistent across the suite.

Figure 2: The six skills across the policy lifecycle

At authoring time, the builder skill creates a policy from a source document and extracts its rules and variables. The reviewer skill reads the quality and fidelity reports the build produces and flags issues such as conflicting rules, unused variables, and bare assertions. The tester skill generates scenarios and runs question-and-answer tests that check whether the policy translates and validates real inputs the way you expect. The debugger skill diagnoses failures and repairs the policy, working from the principle that a wrong verdict almost always comes from a translation problem rather than the rules.

At runtime, the deployer skill snapshots a numbered policy version and attaches it to a guardrail. The validator skill checks answers with the ApplyGuardrail API. It can also run a rewrite loop that feeds a failing answer’s contradicting rules back to the model until the answer is sound.

How the skills are structured

Each skill follows the standard Agent Skills layout. A SKILL.md file holds the core instructions for that stage, including when the skill applies and the judgment calls specific to it. A references/ folder holds deeper material, such as the finding types and the rule syntax, that the agent loads only when it needs the detail. A scripts/ folder holds the runnable Python that calls the Amazon Bedrock Automated Reasoning APIs. The scripts are standalone and take a --help flag and a --dry-run flag. You can read what an operation does and inspect the exact request before it reaches Amazon Bedrock. A shared library underneath the six skills handles the common work: creating clients, polling build workflows, parsing findings, and managing the build-slot limit described later in this post.

From a policy document to a verified answer

The following walkthrough runs the full lifecycle on a short human resources policy for parental leave eligibility. The example is compact so the flow is clear, and the same steps apply to a loan eligibility policy, an insurance coverage policy, or other domains where answers must follow written rules.

Prerequisites

You need an AWS account with access to Amazon Bedrock in an AWS Region where Automated Reasoning checks are available, permissions for the Amazon Bedrock control plane and runtime APIs, and Python with uv to run the scripts. For feature availability by Region, refer to Automated Reasoning checks in the Amazon Bedrock documentation. Clone the repository, then install the skills into your coding agent.

In Claude Code, add the suite as a plugin marketplace and install the skills you want:

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

For other agents that support the open format, such as Kiro, Cursor, and Codex, install with 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 '*'

Either way, a skill activates automatically when you ask your agent about the matching task, such as creating a policy from a document or debugging a failing test.

Create the policy and extract rules

Start from a short source document that states the rules in plain language, for example that full-time employees with more than 12 months of service are eligible for parental leave and part-time employees aren’t. The builder skill creates the policy resource and starts a build that extracts formal rules and a variable schema from the document.

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."

In one run, the build extracted six rules, four variables, and one custom type from three sentences of source text, including a boundary rule that keeps tenure non-negative.

Review what the service produced

Rule extraction is not deterministic, so review the result before you test it. The reviewer skill pulls the quality report and the policy definition and summarizes them.

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

The audit reports the rule, variable, and type counts, then flags structural issues by severity. For this policy it noted one unused variable and one disjoint rule set, both low-severity items to consider rather than errors. It also reports that a fidelity report wasn’t produced, because a standard content build does not generate one. You request it with a separate build type when you want the source-grounding view for a subject matter expert.

Write and run a test

The tester skill creates a question-and-answer test and runs it against the completed build. A test states the question a user might ask, the answer your model might give, and the verdict you expect.

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>

The test workflow returns the expected and actual verdicts and whether they match. For this policy the answer validated as VALID, with the actual result matching the expected result.

Deploy behind a guardrail and validate an answer

After the policy passes its tests, the deployer skill snapshots an immutable numbered version and attaches it to a guardrail, and the validator skill checks a live answer.

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."

The validator returns the finding and confirms that the check ran. Here the answer came back VALID with the supporting rule attached, which is the audit trail you keep for a validated response.

What running the suite taught us

Two lessons stand out from running the full lifecycle against Amazon Bedrock, and both shape how the skills behave.

The first is that explainability sits at the center of how the feature works. Every verdict returns the rules behind it, the supporting rules for a VALID answer and the contradicting rules for an INVALID one. The validator skill logs these so a validated answer ships with mathematically verifiable proof of why it was allowed, and a rejected answer carries the exact rule it broke into the rewrite step. The following diagram traces that runtime rewrite loop. The check returns a non-VALID verdict with the rule the answer broke, the model rewrites the answer using that rule, and the check runs again until the answer is sound.

Figure 3: The runtime rewrite loop

The second is that a SATISFIABLE verdict isn’t a failure. Automated Reasoning distinguishes between an answer that’s consistent with your policy and one that is entailed by it. Suppose a rule says full-time employees with sufficient tenure are eligible. An answer that asserts eligibility is consistent with the policy but not proven by it, so the service returns SATISFIABLE rather than VALID. Reading that result as a failure leads you to change rules that were correct. The debugger skill encodes this distinction so the agent interprets verdicts the way the service defines them.

A practical constraint is worth noting because the skills handle it for you. A policy allows a limited number of concurrent build workflows, and a long refinement session can reach that limit. The skills release a slot automatically before each build by removing the oldest completed build, so an agent working through several refinements doesn’t stall on the cap.

Clean up

To avoid ongoing charges, delete the resources you created in dependency order, because a policy won’t delete while its test cases, build workflows, or versions still exist. Remove the test cases first, then the build workflows and the numbered version, then the policy, and finally the guardrail. The skills follow this sequence when they tear down resources, and you can also delete everything from the Amazon Bedrock console.

Conclusion

Automated Reasoning checks give you verifiable, explainable verdicts on AI answers, and the quality of those verdicts depends on the policy behind them. The Agent Skills in this post move the full authoring lifecycle into code, so building, reviewing, testing, debugging, deploying, and validating a policy become repeatable steps your coding agent can run and you can review. The approach is not limited to the parental leave example or to one agent. It applies to various policy domains, from finance to insurance to healthcare, and installs into the coding agents you already use.

To get started:

1. Install the skills from the code repository into your coding agent.
2. Point the builder skill at your own policy document and review the quality report.
3. Add question-and-answer tests that reflect how your users ask questions, and refine until they pass.
4. Deploy a versioned policy behind a guardrail and validate answers with the runtime skill.

To go deeper, explore these related resources:

---

About the authors

Adewale Akinfaderin

Adewale is a Sr. Data Scientist for Generative AI on the Amazon Bedrock team at AWS, where he works on innovations in foundation models and generative AI applications. His expertise is in reproducible, end-to-end AI/ML methods, and helping global customers build scalable solutions to interdisciplinary problems. He holds two graduate degrees in physics and a doctorate in engineering.

Nafi Diallo

Nafi is a Sr. Applied Scientist at Amazon Web Services, specializing in AI safety, formal verification, and guardrails implementation for trustworthy AI solutions. She brings deep experience evaluating and improving the reliability of generative AI and agentic systems on Amazon Bedrock. Nafi also serves as the Regional Lead for North America for the Women in AI and ML (WAIML) organization at AWS, where she supports chapter growth and advances WAIML’s mission across the region.