Amazon Bedrock 现在支持自动细化 Automated Reasoning policy。系统会分析未通过的测试，判断问题来自形式规则还是自然语言表达，随后提出修复建议；任何修改都必须经过人工批准才会生效。这个机制把策略维护从“手工猜测并反复重测”变成了一条可审查、可控制的诊断流程。
两类失败，需要两种修复思路
Automated Reasoning policy 的测试失败，不一定意味着同一种问题。细化引擎将问题区分为两个方向。
规则问题：形式逻辑没有准确表达约束
规则问题发生在策略的逻辑结构中。例如，业务要求是“只有完成培训并通过背景审查的员工才能访问生产环境”，但策略错误地把两个条件写成了“满足任意一个即可”。测试能够暴露这个逻辑缺口，而细化引擎会提出形式规则层面的修改。
可以把预期约束抽象为：
can_access_production(employee)
-> training_completed(employee)
AND background_check_passed(employee)
这类修复的重点不是润色文字，而是改变规则的逻辑含义。审批人需要检查修改是否扩大或缩小了授权范围，并确认正常路径与拒绝路径都仍然成立。
语言问题：规则可能正确，但输入表达无法稳定映射
另一类失败来自语言层。用户可能写“已经完成安全课程”，策略词汇却只识别“培训完成”；也可能因为否定、缩写或模糊指代，使自然语言没有正确映射到形式变量。
语言细化通常调整术语、描述或表达映射，而不应悄悄改变底层业务规则。例如：
“安全课程已结业” -> training_completed = true
“背调仍在处理中” -> background_check_passed = false
审查语言修复时，要特别关注同义词是否过宽。把“参加过培训”直接映射成“已完成培训”，就可能制造错误授权。
从诊断到生效：审批是流程边界
完整工作流可以理解为五个阶段：
- 运行策略测试，并收集失败用例及期望结果。
- 启动细化，让引擎诊断规则问题或语言问题。
- 查看建议修改、诊断理由以及受影响的测试。
- 由策略负责人逐项批准或拒绝建议。
- 应用获批变更，并重新执行完整回归测试。
在控制台中，可以从失败测试进入细化流程，选择对应的细化模式，检查建议后再批准。关键点是：建议不会因为生成完成而自动进入生产策略，批准动作仍由用户掌握。
API 集成也应保留同样的状态机，而不是把“生成建议”和“应用建议”合并成一个无人值守步骤：
TEST_FAILED
-> REFINEMENT_REQUESTED
-> PROPOSAL_READY
-> HUMAN_REVIEW
-> APPROVED | REJECTED
-> APPLIED
-> REGRESSION_TESTED
这条边界对权限策略、合规要求和高风险业务尤其重要。自动诊断能缩短排查时间，但不能替代业务责任人的判断。
可以这样实践：在流水线中加入显式批准门
由于来源摘要没有给出具体 SDK 操作名和请求字段，下面的示例不声称是 Bedrock 的正式 API 封装。它是一个可直接运行的本地审批门示例：实际接入时，将 proposals.json 替换为细化 API 返回的数据，并把批准结果提交到当前 AWS SDK 或 API 模型提供的应用操作。
先创建 proposals.json：
[
{
"id": "proposal-001",
"mode": "RULE",
"diagnosis": "Access is allowed when either prerequisite is true.",
"before": "training_completed OR background_check_passed",
"after": "training_completed AND background_check_passed",
"affected_tests": ["deny-missing-training", "deny-pending-check"]
},
{
"id": "proposal-002",
"mode": "LANGUAGE",
"diagnosis": "The phrase 'course completed' is not mapped to training completion.",
"before": "recognized phrase: training completed",
"after": "recognized phrases: training completed, course completed",
"affected_tests": ["allow-course-completed-phrase"]
}
]
再创建并运行 review_refinement.py：
import json
from pathlib import Path
proposals = json.loads(Path("proposals.json").read_text(encoding="utf-8"))
decisions = []
for proposal in proposals:
print("\n" + "=" * 72)
print(f"ID: {proposal['id']}")
print(f"Mode: {proposal['mode']}")
print(f"Diagnosis: {proposal['diagnosis']}")
print(f"Before: {proposal['before']}")
print(f"After: {proposal['after']}")
print("Affected tests: " + ", ".join(proposal["affected_tests"]))
answer = input("Approve this change? [y/N]: ").strip().lower()
decisions.append({
"proposal_id": proposal["id"],
"decision": "APPROVE" if answer == "y" else "REJECT"
})
Path("decisions.json").write_text(
json.dumps(decisions, indent=2),
encoding="utf-8"
)
print("\nWrote review decisions to decisions.json")
执行命令：
python3 review_refinement.py
cat decisions.json
在真实 API 工作流中，可以按以下方式改造：
- 测试任务失败后，把测试运行标识传给细化接口。
- 轮询或订阅细化任务状态，直到建议可供审查。
- 将建议、原规则、修改后规则和受影响测试写入审批系统。
- 只把
APPROVE的建议提交给应用变更接口。 - 应用后重新运行整个策略测试集，而不只是此前失败的用例。
接入前应以当前区域的 Amazon Bedrock API 模型和 SDK 文档为准，确认正式操作名、字段、权限以及服务可用性，避免把示例中的抽象状态直接当成 AWS 请求参数。
回归测试要覆盖“修好了什么”和“破坏了什么”
只重跑失败用例是不够的。规则修改可能让原来的失败测试通过，同时破坏原本正确的行为。一个更稳妥的测试集至少包含：
- 应当允许的典型输入。
- 缺少单个前置条件时应当拒绝的输入。
- 同义表达、缩写和否定句。
- 多条件同时出现且互相冲突的输入。
- 接近规则边界的模糊语句。
- 与当前修改无关的既有回归用例。
语言细化还应加入反例。例如，在接受“课程已完成”的同时，验证“课程已报名”和“课程正在进行”不会被误判为完成。
上线前的采用清单
自动细化适合用来压缩诊断时间，但不应成为绕过策略治理的自动发布通道。落地时建议确认以下事项：
- 生成建议与应用变更使用不同权限，避免单一身份完成整条链路。
- 审批记录包含建议内容、审批人、时间、理由和测试结果。
- 每次细化都产生可追踪的策略版本，并能够回滚。
- 规则修复由业务规则负责人审核，语言修复同时邀请领域专家检查术语边界。
- 批准后执行完整回归测试，再将策略推广到生产环境。
- 对高风险策略设置双人审批或变更窗口。
这项能力真正有价值的地方，不是让模型直接改写策略，而是把失败测试转化为结构化、可解释的修复候选。自动诊断负责缩小问题范围，人类审批负责守住业务含义，回归测试则验证修改没有引入新的漏洞。