# AWS阐述Trust in Depth：在可验证的边界内扩大智能体自主权

- Source: MechNext — https://mechnext.eu/zh/article/43-aws-outlines-trust-in-depth-for-agent-autonomy-within-verifiable-boundaries
- Published: 2026-10-19
- Updated: 2026-10-19
- Category: Industry News
- Language: zh (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=pl, ?lang=ru)

> AWS提出以职责范围、身份识别、执行约束和运行观察共同管理智能体，并在规则能够精确定义时引入证明。其核心是让可验证的行动自主进行，把存在歧义的判断交给人，同时依据运行证据调整授权范围。

AWS在介绍Trust in Depth的文章中，将智能体治理划分为相互独立、又彼此加强的多个层次：执行前明确范围，部署时了解智能体，执行中约束行为，每次运行后观察结果。在能够精确表达规则的地方，还应加入证明。按照文章的论述，仅靠内容过滤、测试或监控，都无法保证智能体下一次运行仍然表现正确。

这一思路针对的是智能体执行路径的不确定性。同一个任务可能使用不同工具，也可能采取不同步骤。若要求人逐项批准所有操作，又可能形成审批瓶颈和审查疲劳。AWS因此主张，可验证的行动可以自主执行，存在歧义的决定则保留给人；自主权的扩大，应以规则执行、任务可靠性和故障处理方面积累的证据为依据。

### 先界定职责，再明确身份与权限

第一层关注智能体究竟负责什么。按照AWS的建议，组织需要明确其职责、可访问的工具、数据和服务、必须遵守的规则，以及哪些决定只能由人作出。权限应限于完成任务所必需的范围，同时检查工具或角色附带的授权。这样的范围定义既包括可以采取的行动，也包括必须留给人工判断的部分。

AWS将Kiro描述为把意图转化为结构化需求的工具：通过自动化推理查找需求中的矛盾、歧义和缺口，并据此生成基于属性的测试。文章同时介绍Strands，称其提供用于定义模型、指令和工具的开源工具包，以及托管运行环境。这些能力被放在明确任务和构建智能体的环节中讨论。

对于访问规则，AWS称Amazon Bedrock AgentCore中的Policies允许用户用自然语言描述获准使用的工具、API和数据，并在规则生效前，通过自动化推理检查是否存在过度授权或相互矛盾的要求。这里的检查发生在策略投入使用之前，对应的是预先审视授权边界，而不是只在运行结束后发现问题。

部署阶段还需要知道可使用哪些智能体和组件。AWS把Agent Registry介绍为一个经过批准的托管目录，收录智能体、MCP服务器、工具和技能。管理员通过审批流程控制条目的可发现性和移除，人和智能体都可以查找并复用目录内容。目录审批与运行时身份检查分别承担不同的管理职责。

按照AWS的说法，AgentCore为每个智能体分配独立身份，并在每次请求时检查该身份，从而把操作与发起操作的智能体及其权限联系起来。文章中的“了解智能体”，因此不仅涉及找到可复用的组件，也涉及在请求发生时识别行动主体和相应授权。

### 执行约束应位于智能体之外

文章强调，边界不能仅依赖智能体自身的指令来维持。检查也不应只看孤立操作，因为每一步分别获准，并不意味着组合后的结果仍然被允许。治理需要考虑完整行动序列，以及前面的步骤是否已经满足后续操作的条件。这是文章讨论执行阶段控制的重要原因。

AWS称，AgentCore中的Policy会对经过AgentCore Gateway路由的每次工具调用执行策略检查，而且独立于智能体自身的推理。文章还描述了考虑会话历史的时序策略：随着工作推进，系统可以依据已经发生的步骤调整权限。这里所述的网关执行范围，是实际通过该网关的工具调用。

输入与输出则由另一类措施处理。AWS介绍Amazon Bedrock Guardrails时称，它可以过滤有害或偏离主题的内容，并对敏感数据进行遮蔽。文章把Automated Reasoning checks描述为证明回答与指定策略一致的检查方式。内容过滤与策略一致性检查在这一框架中承担不同任务，不能单独替代全部治理层次。

对于文件、服务和凭据访问，AWS将Strands Box描述为开源沙箱。其边界在智能体指令之外执行，并从本地开发延续到生产环境。按照文章的安排，这类执行环境约束与工具调用策略、输入输出控制相互配合，共同限定智能体实际能够接触和操作的资源。

### 证明必须连同规则和假设一起理解

**自动化推理的结论具有明确适用范围。**文章称，这种方法会检查系统描述及其假设所涵盖的所有路径，看精确定义的规则是否成立；结果可以是一个证明，也可以是一个违反规则的案例。读者需要同时关注被证明的规则是什么，以及证明依赖哪些系统描述和前提。

因此，证明不等于对智能体所有行为作出安全保证。文章明确区分可精确定义的规则与依赖语境的期待，例如保持友好语气。后者并不自然包含在前者的证明范围内。对于无法用现有规则明确判断的情况，AWS仍然保留了人工判断的位置，而非把证明作为取消人工参与的理由。

### 离职流程展示顺序约束如何发挥作用

文章用员工离职流程作说明。在这个示例中，智能体获得六个工具，其中没有删除账户的工具。策略要求，在转换并共享Sam的邮箱之前，必须先阻止他登录；在更改其电子邮件许可证之前，必须先检查是否存在法律保全要求。这些条件把允许执行的操作与执行顺序联系起来。

当智能体过早尝试相关调用时，网关会阻止操作。随后，智能体先阻止Sam登录，再把邮箱访问权限交给Priya，检查并建立所需的法律保全，确认保护已经生效，最后改用支持该保护的许可证。示例中的控制重点，既包括不提供账户删除能力，也包括阻止尚未满足前提的操作。

整个流程记录每一步，而不要求人逐项批准。它说明了文章所倡导的自主执行方式：在外部规则约束下完成可以验证的步骤。这个流程是用于解释机制的示例；所提供材料并未证明它是实际客户部署，也没有给出由该流程产生的实测业务效果。

### 运行记录要能解释任务是否完成

观察层关注的不只是系统是否正常运行。AWS指出，健康的系统指标并不等同于智能体成功完成任务。为理解结果，文章建议重建智能体收到的上下文、发出的工具调用、策略作出的决定以及最终结果。这样，检查对象就从系统状态延伸到一次任务的具体执行过程。

AWS称，Amazon CloudWatch Omni能够捕获执行轨迹，并在用于调查的时间线上展示模型调用和工具调用；评估器则检查正确性、对上下文的忠实程度及工具选择。失败轨迹可以转化为修复工作的测试数据。生产环境观察因此与部署前测试形成补充关系，而不是使提前测试变得不再必要。

文章最后建议，从一个智能体、一个工作流程和一条可证明的边界开始。团队应明确列出哪些行动可以独立执行、哪些需要批准，以及智能体何时必须停止。随着证据积累，再扩大或缩小职责范围。这种调整并非一次性决定，而是与规则执行、任务表现及失败处理的实际证据相联系。

AWS同时把Amazon Bedrock AgentCore中的Policy，以及Amazon Bedrock Guardrails中的Automated Reasoning checks，列为落实可执行规则的相关能力。上述产品能力和治理建议均来自AWS的介绍；现有材料不提供独立有效性评估，也没有确立产品发布状态、地区可用性或价格。