AWS 提出 Trust in Depth：让智能体更自主同时不失控的四层治理框架

在我与企业领导者的每一次对话中，他们说的都是同一件事。他们希望智能体做更多的事情，但不相信它们能始终把事情做对。

这是有道理的。让智能体有用的创造力和自主性，也正是它们难以被信任的原因。给智能体一个任务，它会自己找到完成任务的路径，选择没有任何开发者预先编排好的工具和步骤顺序。同一个任务运行两次，它每次可能走不同的路线。今天通过的测试，几乎无法告诉你智能体明天会做什么。

通常的解决办法是让人在环中，审批智能体所做的每件事。这在小规模下行得通，但随着智能体承担更多工作，人工审批不断堆积，审查疲劳随之而来。被要求检查一切的人，反而会漏掉真正重要的事情。谨慎变成了瓶颈，而能力远不止于此的智能体，只能闲置在一边，无法去做那些本可以产生更大影响的有价值工作。

解决办法是：当智能体的行为可以被验证时，让它自主行动，把人工判断留给真正需要它的决策。随着智能体承担更高风险的工作，比如金融交易，一个错误的操作造成的危害越来越大。组织需要有这样的信心：把重要工作交给 AI 智能体，知道它会保持在设定的边界之内，即使没有人监督。这种信心必须被构建出来。

内容过滤、测试和监控各自都有重要作用，但单靠其中任何一项能力，都无法保证智能体在下次运行时行为正确。信任来自相互强化的独立层次，这正是业界二十年来所践行的“纵深防御”（Defense in Depth）的分层原则，如今被赋予了新的用途。纵深防御限制的是可能出错的范围，而它扩展的是你可以放心允许的范围。AWS 把它称为纵深信任（Trust in Depth）。

纵深信任：可验证的信任

建立信任的方法，是在智能体生命周期的不同阶段回答一组问题：

界定范围，在它运行之前：这个智能体是做什么的？这项工作需要哪些能力？它绝对不能做什么？
确认知情，在部署时：谁授权了它？它携带什么身份？你能对所有代表你行事的智能体做到心中有数吗？
设定边界，在它运行时：它的行为是否保持在设定的边界之内？它还能完成工作吗？
观察复盘，在每次运行之后：你能否还原智能体做了什么、为什么这样做，并从中学习？

在这些问题上，有些需求可以用精确的规则来表达，另一些则需要判断力。比如一家公司可能规定只有经理才能批准访问权限，或者必须先阻止员工的登录，才能共享其邮箱。而其他一些期望，比如保持友好的语气或恰当地处理敏感情况，则取决于具体情境和人的判断。

对于定义精确的规则，测试能告诉你控制在预期情况下是否有效，但智能体会走上你没有预想到的路径。更进一步的技术是自动化推理（automated reasoning），这是一种数学逻辑，用于检查一条规则是否在所有可能的情况下都成立。它可以证明：在对系统及其假设的精确描述所覆盖的每一条路径上，规则都成立；或者找出它恰好失败的那个案例。这个结果是一份证明，而证明的好坏完全取决于其背后的规则和假设，这也是为什么最艰难的工作要在智能体运行之前完成。

AWS 在生产环境中运行自动推理已有十多年历史run automated reasoning in production for more than a decade，从每秒处理超过 21 亿次请求的身份与访问管理（IAM），到 AWS Nitro Hypervisor、Amazon S3 Block Public Access 和 VPC Reachability Analyzer 等关键系统。现在，我们将其引入智能体。凡是智能体的规则可以被精确陈述的地方，自动推理都能对其进行校验。

然而，并非所有规则都能被精确陈述。“只有经理才能批准访问”可以被证明。“保持友好的语气”则不能。在无法证明的地方，应限制智能体的访问和操作，评估其行为，并将真正模糊的情况交给人工进行判断。当你确认相关规则得到执行、智能体在任务上表现可靠、且故障能够被检测和处理之后，再授予更多自主权。

以下是每层“纵深信任”对你的要求，以及 AWS 如何帮助你回答这些问题。

将智能体的范围限定在任务所需之内

信任始于智能体运行之前，这是最值得投入精力的地方。在此阶段发现的问题修复成本最低。限定范围意味着决定智能体承担哪些工作、可以使用哪些工具、数据和服务、必须遵守哪些规则，以及哪些决策仍由人来做出。

“解决客户的问题”只说明了要达成什么目标，而没有说明智能体可以如何行动去实现它。智能体仍然需要限制：它可以看见什么、可以做什么，以及何时必须停下来询问。只授予其工作所需的访问权限，不要更多。警惕那些没人有意授予的能力，即随某个工具或角色捆绑而来的能力。为一个任务授予管理员角色，智能体就可能继承整个环境中的权限。

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

下一步是将这些边界转化为你可以用来约束智能体的规则。Amazon Bedrock AgentCore 提供治理控制，以安全地扩展智能体并治理智能体的行为。使用 Bedrock AgentCore 中的策略（Policies），你可以用自然语言描述智能体可以使用哪些工具、API 和数据，自动推理会在策略生效之前检查其中的缺口（例如发现某条规则授予了过多权限），并检查是否存在使规则永远无法被满足的矛盾。

限定智能体的范围是最难的部分，因为将人类意图转化为持久、可执行的策略需要精确性和完整性。然而，这也是回报最大的部分。一切都建立在你在这一步所设定内容的基础上，策略越精确，智能体就能越安全地自主完成更多事情。

看不见就无法治理。团队创建智能体的速度快于任何人追踪它们的速度，而一个无人知晓的智能体就是一个无人控制的智能体。每个智能体都需要自己的身份，并在其每次行动时进行核验。任何行动都不应成为“孤儿”。当出现问题时，你能查明是哪个智能体做了什么，以及是谁授权的。

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

在您设定的限度内约束智能体的言行

设定边界很重要，因为智能体可能执行了你批准的 10 个步骤，却仍然达成一个无人预期的结果。它可能暴露敏感数据、偏离主题，或以你的政策所禁止的方式组合各项被允许的操作。限制可能在两个方向上失效：太宽松，智能体就会做不该做的事；太严格，它就完全无法完成工作。因此，让智能体自行选择如何完成任务，但绝不要依赖它来执行对自身的限制。这些限制定义了智能体的边界，应置于智能体所处的环境之中，以确定性的方式强制执行，并针对完整的操作序列进行评估，而不是逐步进行。

这正是您在 Scope 中定义的策略生效的地方。AgentCore 中的策略会在每个经过 AgentCore Gateway（智能体、工具和模型的安全入口）路由的工具调用上强制执行该策略。由于强制执行位于智能体的推理之外，即使智能体存在缺陷、被操纵或遭遇提示注入，同样的检查依然有效：它无法关闭一个不由它运行的控制。权限也不必一成不变。由于任务的风险会随推进而变化，时序策略会权衡会话中已经发生的情况，并随着工作进行动态调整权限。Amazon Bedrock Guardrails 约束智能体的输出内容和接收的输入。它会过滤有害或偏离主题的内容，并对敏感数据进行脱敏。Automated Reasoning checks 更进一步，可以证明回复与你所设定的策略一致，而不是与模型对该策略的解读一致。

边界还约束智能体最初能触及的范围：它可以访问哪些文件、调用哪些服务、使用哪些凭证。Strands Box 是一个开源沙箱，它从智能体的指令之外强制执行这些边界，因此智能体可以使用真实的工具和数据，但只能触及你允许的范围。同样的边界从开发者的第一个本地会话一直延续到生产环境，因此智能体在开发环境中做不到的事，在生产环境中也做不到。

观察您的智能体做了什么，然后加以改进

即使范围控制、身份和边界都已到位，一个智能体仍可能在几毫秒内做出响应，没有任何错误、仪表盘上一切显示绿色，却做了错误的事情。它可能检索到了错误的信息、选择了错误的工具，或者走上了一条没人预料到的路径。系统健康不等于任务成功。要分辨两者，你必须还原智能体实际做了什么：它接收到的上下文、调用的工具、应用的策略决策，以及最终结果。在部署前进行测试仍然必不可少。而生产环境则提供了真实条件下行为表现的证据，让运维人员能够调查、干预并改进。

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

深度信任在实践中是什么样的

一位经理要求服务台智能体为即将离职的客户经理 Sam 办理离职手续。智能体需要移除 Sam 的访问权限，把他的邮箱移交给继任者，并释放公司不再需要的许可证。但 Sam 的邮件中可能还包含一桩客户纠纷所需的证据。如果操作顺序错误，可能导致 Sam 在离职后仍保有访问权限，或使那些证据面临风险。安全、邮件、法务和财务各部门都有智能体必须遵守的要求，尽管没有人编写过完整的工作流程脚本。

有两条规则约束着操作顺序。必须先阻止 Sam 登录，然后才能把他的邮箱转换并共享给继任者。在变更他的邮件许可证之前，智能体必须检查是否存在法律保留要求（即为纠纷保存记录的要求），并确认该变更仍能保护这些记录。

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

知晓。智能体拥有自己的身份，因此对 Sam 账户的每次变更都可以追溯到它。

受限。智能体尝试把 Sam 的邮箱转换为共享邮箱，供继任者 Priya 使用。AgentCore 的策略（在 AgentCore 网关上强制执行）阻止了这次调用：Sam 仍可登录，而且转换邮箱并不会更改他的密码，所以他的旧凭据仍能打开该邮箱。智能体先阻止了 Sam 的登录，然后转换邮箱并授予 Priya 访问权限。接下来它处理经理的实际请求——释放许可证，但网关再次阻止了这一操作，因为还没有人检查过法务的保留清单。智能体进行检查，发现法务要求为一起客户纠纷保存 Sam 的邮件。它设置了保留，确认其已生效，然后将 Sam 的许可证更改为支持这种保护的类型。公司由此可以在证据完好无损的情况下收回更高级别的许可证。

观察。每一步都被记录下来：智能体尝试做什么、规则做出什么决定、保留措施以及结果。

智能体在没有人逐步批准的情况下完成了任务。它的权限限制了它可以更改的内容，它的身份使这些更改可被追溯，而且策略阻止它在必要的安全保障到位之前采取行动。被记录的步骤让团队能够核实 Sam 的访问权限已被阻止、他的继任者可以使用该邮箱，以及所需的证据仍然受到保护。

当智能体被信任时，什么将成为可能

AWS 将这些层整合在一起，使你能够将智能体的范围限定在其职责之内、知道哪些智能体在代表你行动、约束它们的行为和言论、查看它们做了什么并不断改进，并且在任何可以精确表述的地方证明你的规则确实有效。没有任何单独一层能够独自赢得这种信任。合在一起，它们就是“深度信任”，也正是将一个能力出众的智能体转变为一个可以被信任去完成重要工作的智能体的关键。

由你来划定界线：智能体可以自主做什么、什么需要人工批准，以及它何时必须停止。这让你的员工得以专注于只有人才能完成的事情：权衡艰难的决策、解决灰色地带的问题，以及掌握你选择保留在人类手中的决策权。随着证据表明智能体始终留在这些界线之内，你可以扩大或缩小它的职责范围。

在 AWS，我们认为每个部署智能体的组织，无论使用何种平台，都应该能够用证据、并在适用之处用证明来回答这四个问题。这是 AWS 正在为客户构建的标准，也是我们邀请全行业共同坚持的标准。“深度防御”让将系统连接到世界变得安全，“深度信任”则让智能体在其中自主行动变得安全。

从一个智能体、一个工作流、一条你能证明的界线开始。随着信任的积累再逐步扩展。

要开始实施可执行的规则，请探索 Amazon Bedrock AgentCore 中的 Policy 和 Amazon Bedrock Guardrails 中的 Automated Reasoning 检查。