AWS 提出 Trust in Depth：用自动化推理让 Agent 获得更多自主权

在我与企业领导人的每一次对话中，他们都会说同样的话。他们希望智能体承担更多工作，但他们不信任智能体每次都能把事做对。

这很合理。让智能体变得有用的那种创造力和自主性，恰恰也让它们难以被信任。给智能体一个任务，它会自己找到完成路径，选择工具并安排步骤，而这一切并非开发者预先编写好的。同一个任务运行两次，它可能每次走不同的路线。今天通过的测试，说明不了这个智能体明天会做什么。

通常的解决办法是让人留在环路中，批准智能体所做的一切。这在规模小时行得通，但随着智能体承担的工作越来越多，人工审批会堆积如山，审查疲劳随之而来。被要求检查一切的人，会不再能抓住真正重要的问题。谨慎变成了瓶颈，而能力远不止于此的智能体，则闲置在那些本可产生更大影响的高价值工作旁边。

解决办法是：当智能体的行为可以被验证时，就让它自主行动；把人的判断留给真正需要判断的决策。随着智能体承担更高风险的工作，比如金融交易，一次错误的行为会变得越来越有害。组织需要有信心把重要工作交给 AI 智能体，确信它会始终待在设定的边界之内，即使无人看管。这种信心必须被建立起来。

内容过滤、测试和监控各有其重要作用，但仅靠这些能力中的任何一个，都无法保证智能体下一次运行时行为正确。信任来自相互强化的独立层次，这正是行业二十年来在 Defense in Depth（纵深防御）中实践的层层设防纪律，如今被用于新的目的。Defense in Depth 限制的是可能出错的范围，而这一新思路扩展的是你可以安全允许的范围。AWS 称之为 Trust in Depth。

Trust in Depth：可验证的信任

你通过在智能体生命周期的不同时刻回答一系列问题来建立信任：

• Scope，运行之前：这个智能体是做什么的，这项工作需要哪些能力，它绝不能做什么？
• Know，部署之时：谁授权了它，它携带什么身份，你能否说清每一个代表你行动的智能体？
• Bound，运行期间：它的行为是否始终在你设定的边界之内，同时它还能完成工作吗？
• Observe，每次运行之后：你能否重建智能体做了什么、为什么这样做，并从中学习？

在回答这些问题时，有些要求可以表达为精确的规则，而另一些则需要判断。公司可能要求只有经理才能批准访问权限，或者员工在邮箱被共享之前必须先阻止其登录。另一些期望，比如保持友好的语气或妥善处理敏感情况，则取决于上下文和人的判断。

对于精确定义的规则，测试能显示控制措施在你预想到的场景中是否有效，但智能体会走出你未曾预想的路径。更进一步的技术是自动推理，即用数学逻辑检查某条规则在所有可能的情况下是否都成立。它可以证明某条规则在系统及其假设的精确描述所覆盖的每条路径上都成立，或者找出它失败的确切情形。这个结果是一份证明，而它的可靠性取决于背后的规则和假设，这也是为什么最难的工作出现在智能体运行之前。

AWS 已经在生产中运行自动推理超过十年，从每秒超过 21 亿次请求的 Identity and Access Management（IAM），到 AWS Nitro Hypervisor、Amazon S3 Block Public Access 和 VPC Reachability Analyzer 等关键系统。现在，我们把它带到了 agent 中。只要 agent 的规则能够被精确表述，自动推理就能对其进行检查。

然而，并非每条规则都能被精确表述。“只有经理才能批准访问”可以被证明。“保持友好的语气”则不能。在证明不适用之处，限制 agent 的访问权限和操作，评估其行为，并将真正的模糊之处交给人工判断。随着你确认相关规则得到执行、agent 在任务上表现可靠、失败能够被检测和处理，再授予更多自主权。

以下是 Trust in Depth 的每一层对你的要求，以及 AWS 如何帮助你满足这些要求。

将你的 agent 限定在仅完成工作所需的范围

信任在 agent 运行之前就已开始，而这正是最值得投入精力的地方。在这里发现的问题修复成本很低。限定范围意味着决定 agent 负责哪些工作、它可以访问哪些工具、数据和服务、它必须遵循哪些规则，以及哪些决策仍由人来做。

“解决客户的问题”说明了要达成什么，却没有说明 agent 可以如何行动来达成它。agent 仍然需要在它能看什么、能做什么，以及何时必须停下来询问方面受到限制。只授予其工作所需的访问权限，不多给。留意那些没有人有意授予的能力，即随工具或角色捆绑而来的能力。为一个任务授予管理员角色，agent 就可能继承你整个环境中的权限。

限定范围从构建阶段开始，取决于你如何定义 agent。Kiro 这一 agentic 编码系统为 agent 的构建阶段带来了严谨性和成熟的工程实践。它将高层意图转化为结构化、由规范驱动的要求，并使用自动推理在编写任何代码之前就暴露矛盾、模糊之处和缺口。Kiro 还会派生基于属性的测试，在广泛的输入范围内对照这些要求检查实现，从而捕获难以检测的缺陷。Strands 提供了开源工具包，用于定义 agent 的模型、指令和工具，以及用于运行它的托管运行时。无论你选择哪种框架，定义 agent 的职责及其边界的责任都是一样的。

下一步是将这些边界转化为你可以要求 agent 遵守的规则。Amazon Bedrock AgentCore 提供治理控制，以安全地扩展 agent 并治理 agent 的行为。使用 Bedrock AgentCore 中的 Policies，你可以用自然语言描述 agent 可以访问哪些工具、API 和数据，自动推理会检查策略中的缺口，例如发现某条规则授予了过多访问权限，并检查会导致某条规则永远无法被满足的矛盾，这一切都在策略生效之前完成。

限定 agent 的范围是最困难的部分，因为将人类意图转化为持久、可执行的策略需要精确性和完整性。然而，这也是回报最大的部分。一切都要建立在你在此设定的内容之上，而策略越精确，你的 agent 就越能安全地自主行动。

了解每一个代表你行事的 agent，以及它是在谁的授权下行事

你无法管理你看不见的东西。团队创建智能体的速度远超任何人能追踪的速度，而一个无人知晓的智能体就是无人掌控的智能体。每个智能体都需要自己的身份，并在每次行动时接受核查。任何行动都不应被孤立对待。当出现问题时，你能分辨出哪个智能体做了什么，以及是谁授权的。

AWS Agent Registry 提供了一个托管且经过批准的目录，涵盖你组织内的智能体、Model Context Protocol（MCP）服务器、工具和技能。管理员通过审批工作流来控制哪些内容可被发现，并移除不再符合安全、合规和质量标准的内容。无论人还是智能体，都可以查找并复用已有的内容，而不必重新构建。但目录只能告诉你存在什么。一旦智能体被知晓，AgentCore 就会为每个智能体发放自己的身份，并在每次请求时进行核查，因此每个操作都能追溯到某个在已知权限下运行的具体智能体。这样你就能知道每个代表你行动的智能体。

在你设定的界限内，约束智能体的言行

设定界限很重要，因为一个智能体可能执行了你批准的 10 个步骤，却仍然达成无人预期的结果。它可能泄露敏感数据、偏离主题，或以你的策略禁止的方式组合被允许的操作。限制可能朝两个方向失效。太松，智能体就能做不该做的事。太紧，它就完全无法完成工作。因此，让智能体自行选择如何推进任务，但绝不要依赖它来执行自己的限制。这些限制定义了智能体的边界，应属于智能体周围的环境，以确定性的方式强制执行，并针对完整的操作序列进行评估，而不是一次只评估一步。

这就是你在 Scope 中定义的策略发挥作用的地方。AgentCore 中的 Policy 会在每次通过 AgentCore Gateway（智能体、工具和模型的安全入口）路由的工具调用上执行该策略。由于执行位于智能体的推理之外，即使智能体有缺陷、被操纵或遭遇提示注入，同样的检查依然有效：它无法关闭一个不由它运行的控件。权限也不必固定不变。由于任务的风险会随进展而变化，时间策略会权衡会话中已发生的情况，并随着工作继续调整权限。Amazon Bedrock Guardrails 管控智能体说什么以及被告知什么。它会过滤有害或偏离主题的内容，并遮蔽敏感数据。自动推理检查更进一步，证明响应与你设定的策略一致，而不是与模型对策略的解读一致。

边界还管控智能体一开始能触及什么：它能碰哪些文件、能调用哪些服务、能使用哪些凭证。Strands Box 是一个开源沙箱，它从智能体指令之外强制执行这些边界，因此智能体可以使用真实工具和数据，但只能触及你允许的范围。从开发者的首次本地会话到生产环境，同样的边界始终有效，因此智能体在生产环境中无法做它在开发环境中做不到的事。

观察你的智能体做了什么，然后改进它

即使有了范围界定、身份和边界，智能体仍可能在几毫秒内做出响应，没有错误，所有仪表盘一片绿色，却依然做错事。它可能检索了错误的信息，选择了错误的工具，或走上了一条无人预料到的路径。系统健康并不等同于任务成功。要区分二者，你必须重建智能体实际做了什么：它接收到的上下文、它调用的工具、所应用的政策决策以及结果。部署前测试仍然至关重要。生产环境则补充了关于真实条件下行为的证据，并给运维人员提供了调查、干预和改进所需的东西。

Amazon CloudWatch Omni 专为持续观测而构建。它捕获每一条追踪，并将智能体所采取的每一步——从模型调用到工具调用——展现在团队可以调查的时间线上。其内置评估器会针对标准监控遗漏的质量对智能体响应进行评分，例如正确性、忠实度以及智能体是否选择了正确的工具。而智能体出错的那些追踪，会成为你测试修复方案的数据集，因此运行智能体和改进智能体依据的是同一套证据。

Trust in Depth 在实践中是什么样子

一位经理要求帮助台智能体为即将离职的客户经理 Sam 办理离职。智能体需要移除 Sam 的访问权限，将他的邮箱转移给他的继任者，并释放公司不再需要的许可证。但 Sam 的电子邮件中也可能包含客户纠纷所需的证据。顺序错误可能导致 Sam 在离职后仍保留访问权限，或使这些证据面临风险。安全、消息、法律和财务部门各有智能体必须遵循的要求，尽管没有人编写过完整的工作流脚本。

有两条规则决定顺序。必须先阻止 Sam 登录，然后才能转换他的邮箱并与其继任者共享。在更改他的电子邮件许可证之前，智能体必须检查是否存在法律保留——即为纠纷保留记录的要求——并确认更改后这些记录仍受到保护。

范围。在智能体运行之前，团队将这些规则作为策略写入 AgentCore。每条策略都要求，在下一步可以运行之前，针对 Sam 账户的前置步骤已经成功完成。智能体恰好获得六个工具：阻止登录、检查法律保留、实施保留、转换邮箱、授予继任者访问权限、更改许可证。它没有获得删除账户的工具，因为共享邮箱需要该账户继续存在。

知晓。智能体携带自己的身份，因此对 Sam 账户的每一次更改都可追溯到它。

约束。智能体试图将 Sam 的邮箱转换为供继任者 Priya 使用的共享邮箱。AgentCore 中的策略在 AgentCore Gateway 处强制执行，阻止了该调用：Sam 仍可登录，而转换邮箱不会更改他的密码，因此他的旧凭据仍能打开它。智能体阻止了 Sam 的登录，然后转换邮箱并授予 Priya 访问权限。接下来它转向经理的实际请求——释放许可证，但网关也阻止了这一点，因为还没有人检查法律部门的保留清单。智能体进行检查，发现法律部门要求为一起客户纠纷保留 Sam 的电子邮件。它实施保留，确认保留已生效，然后将 Sam 的许可证更改为支持该保护的类型。公司可以收回更宽泛的许可证，同时保持证据完好无损。

观察。每一步都被记录：agent 试图做什么、规则如何裁定、暂停以及最终结果。

agent 在没有每一步都经人工批准的情况下完成了任务。其权限限制了它可以更改的内容，其身份使这些更改可追溯，策略阻止它在所需防护措施到位之前采取行动。记录的步骤让团队得以验证 Sam 的访问已被阻止、他的继任者可以使用该邮箱，以及所需证据仍受到保护。

当 agent 被信任时，一切皆有可能

AWS 将这些层面整合在一起，让你能够将 agent 限定于其职责范围、知晓哪些 agent 在代表你行动、约束它们的言行、查看它们做了什么并持续改进，并在规则能够被精确表述之处证明其成立。没有任何单一层面能独自赢得这种信任。它们共同构成了“深度信任”（Trust in Depth），正是它们将一个有能力的 agent 转变为可以被信任去完成重要工作的 agent。

你来划定界限：agent 可以自行做什么、什么需要人工批准、以及何时必须停止。这让你的人员得以专注于只有人才能做的事：权衡艰难的抉择、解决灰色地带，并为你选择保留在人类手中的决策负责。随着证据不断积累，表明某个 agent 始终守在这些界限之内，你就可以扩大或缩小其职责范围。

在 AWS，我们相信每一个部署 agent 的组织，无论使用什么平台，都应该能够用证据来回答这四个问题，并在适用之处提供证明。这就是 AWS 为客户设定的标准，也是我们邀请整个行业共同遵守的标准。纵深防御（Defense in Depth）让系统安全地连接世界成为可能。深度信任（Trust in Depth）则让 agent 在其中自主行动变得安全。

从一个 agent、一个工作流和一条你能证明的边界开始。然后随着信任的建立而扩展。

要开始实施可强制执行的规则，请探索 Amazon Bedrock AgentCore 中的 Policy 和 Amazon Bedrock Guardrails 中的自动推理检查。

关于作者

Shawn Bice

Shawn 是 Amazon Web Services (AWS) 的 AI 服务副总裁，领导自动推理小组。该团队的核心使命是推进 AI agent 安全。Shawn 推动科学和产品团队将神经符号 AI（结合大语言模型与形式化验证）引入开发者工具，使每一位构建者都能创建可信赖的 AI agent，其关键行为经过数学证明。近 30 年来，Shawn 曾在 AWS、Microsoft 和 Splunk 领导安全、数据及产品组织。他的职业生涯始于美国陆军第 25 步兵师军官。