正文 · AI 翻译
每次与企业领导者交谈，他们说的都是同一件事：他们希望智能体承担更多工作，却不相信智能体每次都能把事情做对。这种顾虑合情合理。让智能体发挥作用的创造力和自主性，也使它们难以获得信任。给智能体一项任务，它会自行寻找完成任务的路径，选择工具并安排步骤顺序，而这些都不是开发者预先写好的。把同一项任务运行两次，它每次可能走不同的路线。今天通过的一项测试，几乎不能说明智能体明天会做什么。通常的解决办法是让人参与每个环节，审批智能体所做的一切。这在小规模应用时行得通，但随着智能体承担更多工作，人工审批会不断积压，审核疲劳也随之出现。被要求检查一切的人，最终会漏掉真正重要的事。谨慎变成了瓶颈，而本有能力做得更多的智能体，却在原本能够产生更大影响的重要工作上闲置。解决办法是：当智能体的行动可以验证时，让它自主行动，把需要人类判断的决定留给人。随着智能体承担风险更高的工作，例如金融交易，错误行动造成的危害也越来越大。组织需要有信心把重要工作交给 AI 智能体，确信即使无人监督，它也会遵守设定的限制。这种信心必须通过实际工作建立起来。内容过滤、测试和监控各有重要作用，但单靠其中任何一种能力，都无法保证智能体下次运行时会正确行事。信任来自相互强化的独立防护层。这是业界 20 年来践行的“纵深防御”分层原则，如今被用于新的目的。“纵深防御”限制可能出错的范围，而这种做法扩大了可以安全授权智能体开展的工作范围。AWS 称之为“纵深信任”。纵深信任：可以验证的信任。要建立信任，你需要在智能体生命周期的不同阶段回答一组问题：界定范围，在运行前：这个智能体的用途是什么，工作需要哪些能力，以及绝不能做什么？明确身份，在部署时：谁授权了它，它具有什么身份，你能否对每个代表你行动的智能体作出交代？设定边界，在运行期间：它的行动是否始终处于你设定的限制之内，同时仍能完成工作？观察，在每次运行后：你能否重现智能体做了什么、为什么这样做，并从中学习？对于这些问题，有些要求可以表述为精确的规则，另一些则需要判断。公司可能要求只有经理才能批准访问权限，或者必须先阻止员工登录，才能共享其邮箱。其他期望，例如保持友好的语气或妥善处理敏感情况，则取决于具体情境和人的判断。对于定义精确的规则，测试可以表明控制措施在你预想到的情形下是否有效，但智能体可能走上你没有预想到的路径。能够更进一步的技术是自动推理：它运用数学逻辑，检查一条规则在所有可能情况下是否成立。它可以证明，在对系统及其假设作出精确描述所涵盖的每一条路径上，规则都成立；或者找出规则失效的确切情形。这样的结果就是证明，而证明的可靠程度取决于其依据的规则和假设。这也是为什么最难的工作发生在智能体运行之前。AWS 已将自动推理用于生产环境超过 10 年，应用范围从每秒处理超过 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 提供一个经过管理和审批的目录，收录组织中的智能体、模型上下文协议（MCP）服务器、工具和技能。管理员通过审批工作流把关哪些内容可以被发现，并移除不再符合安全、合规和质量标准的内容。人和智能体都可以查找并复用已有内容，而不必重新构建。但目录只能告诉你有哪些内容。明确有哪些智能体之后，AgentCore 会为每个智能体分配独立身份，并在每次请求时核验，使每项行动都能追溯到一个在已知授权下运行的具体智能体。这样，你就能知道每个代表你行动的智能体是谁。将智能体的言行限制在你设定的边界内。设定边界很重要，因为智能体即使连续执行了 10 个你批准的步骤，最终仍可能产生没人预期的结果。它可能泄露敏感数据、偏离主题，或者以违反策略的方式组合原本允许的行动。限制可能在两个方向上失效：过于宽松，智能体就能做不该做的事；过于严格，它就根本无法完成工作。因此，可以让智能体自行选择完成任务的方式，但绝不能依赖它自行执行对自身的限制。这些限制定义了智能体的边界，应由智能体所处的外部环境以确定性的方式执行，并根据完整的行动序列进行评估，而不是一次只看一个步骤。你在“界定范围”阶段定义的策略就在这里生效。AgentCore 中的 Policy 会对通过 AgentCore Gateway 发起的每次工具调用执行该策略。AgentCore Gateway 是智能体、工具和模型的安全入口。由于策略执行位于智能体的推理过程之外，即使智能体存在错误、受到操纵或遭遇提示词注入，同样的检查仍然有效：智能体无法关闭不由它运行的控制措施。授权也不必始终固定不变。由于任务的风险会随着进展而变化，时序策略会考虑会话中已发生的事，并在工作继续进行时调整权限。Amazon Bedrock Guardrails 管理智能体说的话以及它接收到的内容。它会过滤有害或偏离主题的内容，并对敏感数据作脱敏处理。Automated Reasoning 检查更进一步，可以证明回复与设定的策略一致，而不是仅仅符合模型对策略的理解。边界还决定智能体最初可以接触什么：它可以操作哪些文件、调用哪些服务、使用哪些凭证。开源沙盒 Strands Box 在智能体指令之外执行这些边界，使智能体能够使用真实工具和数据开展工作，同时只能访问你允许的内容。从开发者的首次本地会话到生产环境，同样的边界始终有效，因此智能体在生产环境中也不能做开发环境中不允许它做的事。观察智能体做了什么，然后改进它。即使已经界定范围、确立身份并设置边界，智能体仍可能在几毫秒内给出回复，系统没有报错，所有仪表板都显示正常，但它做的事仍然可能是错的。它可能检索了错误的信息、选用了错误的工具，或走上了没人预料到的路径。系统运行正常，不等于任务完成成功。要区分两者，你必须能够重现智能体实际做了什么：它接收的上下文、调用的工具、所应用的策略决定，以及结果。部署前测试仍然必不可少。生产环境会提供智能体在真实条件下行为的证据，让运营人员有依据调查、干预和改进。Amazon CloudWatch Omni 专为持续观察而设计。它捕获每条追踪记录，并按时间线展示智能体采取的每一步，从模型调用到工具调用，供团队调查。其内置评估器会评估智能体回复中标准监控容易遗漏的质量，例如正确性、忠实性，以及智能体是否选对了工具。而智能体出错时的追踪记录会成为检验修复效果的数据集，使智能体的运行和改进都基于同一批证据。纵深信任在实践中是什么样子？一位经理要求服务台智能体为即将离职的客户经理 Sam 办理离职手续。智能体需要移除 Sam 的访问权限，将他的邮箱移交给继任者，并释放公司不再需要的许可证。但 Sam 的电子邮件也可能包含客户纠纷所需的证据。错误的操作顺序可能让 Sam 在离职后仍有访问权限，或者使这些证据面临风险。安全、消息服务、法务和财务部门各有智能体必须遵守的要求，尽管没人预先编写完整的工作流程。有两条规则规定了操作顺序。必须先阻止 Sam 登录，才能将他的邮箱转换为共享邮箱并与继任者共享。在更改他的电子邮件许可证之前，智能体必须检查是否有法律保全要求，即为纠纷保存记录的要求，并确认更改后这些记录仍受到保护。界定范围。在智能体运行前，团队将这些规则写成 AgentCore 中的策略。每项策略都要求，针对 Sam 的账户，前置步骤已经成功完成，才能执行下一步。智能体恰好获得 6 个工具：阻止登录、检查法律保全要求、实施保全、转换邮箱、授予继任者访问权限，以及更改许可证。它没有删除账户的工具，因为共享邮箱需要该账户继续存在。明确身份。智能体具有自己的身份，因此对 Sam 账户所做的每项更改都能追溯到它。设定边界。智能体试图把 Sam 的邮箱转换成共享邮箱，供继任者 Priya 使用。在 AgentCore Gateway 执行的 AgentCore Policy 阻止了这次调用：Sam 仍可登录，而转换邮箱不会更改他的密码，所以他原来的凭证仍可打开邮箱。智能体先阻止 Sam 登录，然后转换邮箱并授予 Priya 访问权限。接着，它开始处理经理实际提出的请求：释放许可证。但网关也阻止了这一步，因为还没人核查法务部门的保全清单。智能体核查后发现，法务部门要求为一起客户纠纷保存 Sam 的电子邮件。它实施保全，确认保全已生效，然后将 Sam 的许可证更改为支持这种保护的许可证。公司可以收回原先权限范围更广的许可证，同时保证证据完整。观察。每一步都有记录：智能体尝试做什么、规则作出了什么决定、保全措施以及最终结果。智能体完成了任务，无需由人批准每一步。它的权限限制了它可以更改的内容，它的身份使这些更改可追溯，策略则阻止它在必要的保障措施到位前采取行动。记录下来的步骤让团队能够核实：Sam 的访问权限已被阻止，继任者可以使用邮箱，所需证据仍受到保护。智能体获得信任后，可以实现什么？AWS 将这些层结合起来，让你能够根据工作界定智能体的范围，知道哪些智能体在代表你行动，约束它们的言行，查看它们做了什么并持续改进，还能在规则可以精确表述时证明规则得到遵守。任何单独一层都无法建立这种信任。这些层共同构成“纵深信任”，让有能力的智能体成为可以信任其承担重要工作的智能体。界线由你划定：哪些事智能体可以自行完成，哪些事需要人批准，以及它何时必须停下。这使员工能够专注于只有人才能做的事：权衡艰难的抉择，处理模糊地带，并为你决定保留由人作出的决定负责。随着证据不断表明智能体始终遵守这些界线，你可以扩大或缩小它的职责。在 AWS，我们相信，在任何平台上部署智能体的每个组织，都应能够用证据回答这 4 个问题，并在适用时提供证明。这是 AWS 正在为客户建立的标准，也是我们邀请整个行业共同遵循的标准。纵深防御让系统能够安全地连接世界。纵深信任让智能体能够安全地在其中自主行动。从 1 个智能体、1 项工作流程和 1 条可以证明有效的边界开始。然后随着信任的建立逐步扩展。要开始实施可执行的规则，请了解 Amazon Bedrock AgentCore 中的 Policy 和 Amazon Bedrock Guardrails 中的 Automated Reasoning 检查。关于作者：Shawn Bice。Shawn 是 Amazon Web Services（AWS）AI 服务副总裁，领导自动推理团队。该团队的核心使命是推动 AI 智能体安全发展。Shawn 带领科研和产品团队，将结合大型语言模型与形式化验证的神经符号 AI 引入开发者工具，使每位开发者都能创建关键行为经过数学证明的可信 AI 智能体。在近 30 年的职业生涯中，Shawn 曾在 AWS、Microsoft 和 Splunk 领导安全、数据和产品组织。他的职业生涯始于担任美国陆军第 25 步兵师军官。