大家好，欢迎来到 AI Engineer New York。我今天非常兴奋能来到这里。我叫 Ali How，是 Keycard 的技术团队成员。今天我和一些精彩的嘉宾在一起。我们有 Keycard 的首席执行官 Ian，摩根大通全球首席安全架构师 Michael Davis，以及 OAuth 的创始人兼共同创造者 Dick Hardt。我们非常兴奋能与他们讨论基于意图的授权问题。为了铺垫背景，我想指出，随着越来越多的公司希望赋予其智能体更高的自主权，他们正在寻求运行时授权来帮助实现这一目标。
运行时授权是指针对每次工具调用对智能体进行授权，而不是让智能体持有广泛的持久访问权限，最终导致滥用。然而，“这是工具调用吗”这个问题从来都不简单。这是因为许多 MCP 工具和 API 都是粗粒度的。人类很难写出完美的策略，而且智能体运行时的环境也会发生变化。意图可以通过提供额外的上下文来帮助我们在运行时做出更好的授权决策，确定智能体允许或不允许做什么。
因此，我想深入探讨为什么我们首先需要基于意图的授权？模型已经有了显著改进，拥有更大的上下文窗口。由于模型视觉能力的提升，它们能够验证工作成果。在许多语境中，人们宣称 AGI（通用人工智能）已经到来。如果模型如此强大，AGI 真的在今天存在，那么为什么团队在赋予智能体更多自主权时仍然感到挣扎呢？Ian，让我们从你开始。你在 Keycard 帮助人类和金融机构解决什么问题阻碍了这一进程？
嗯，我认为从广义上讲，企业，尤其是金融服务公司、受监管的行业，几乎总是将安全放在首位。这是他们建立业务信任的方式，而维持业务的连续性是我们的首要任务，创新则排在第二、第三或第四位。我认为在任何企业中，普遍存在的情况是各种不同身份的小孤岛和来自各个领域的系统杂乱无章。我们如何将这些联系起来，使智能体能够导航其中、请求访问权限？
同时确保智能体不会执行用户或业务未打算进行的操作。不幸的是，我们今天的大多数系统都是粗粒度的。例如 Salesforce 就是一个很好的例子。很长一段时间以来，他们在 OAuth 中只有一个范围（scope），即 API。在智能体的语境下，这并不太有帮助。因此，首要问题是大多数用于安全性的系统是为人类做出所有决策的世界设计的，软件是确定性的。
而我们发明的是一个全新的“魔法盒子”，它基本上通过推理并反复尝试来寻找问题的解决方案。Dick，OAuth 如何成为问题的一部分？它为何阻碍了进展？为什么它不适合智能体呢？嗯，当人们开始研究如何授权智能体访问某些内容时，货架上现成的工具就是 OAuth。人们拿起这个工具说：“这是一个授权工具，它应该能解决这个问题。”但 OAuth 并非为这种世界而设计。
它最初是为如何让一个网站与另一个网站通信而设计的，你知道的。在 OAuth 2.0 中我们添加了范围（scopes），在此之前它只是允许做任何事情。但它要求预先注册，并期望有浏览器参与重定向过程。虽然 OAuth 多年来已演变为支持其他一些功能，但智能体世界完全不同。我们事先不知道智能体需要做什么。
我们需要随着时间的推移做出决定。不同的智能体实例将需要不同类型的权限。正如 Ian 提到的，人们说“我们已经有 OAuth 的范围了，让我们直接映射给智能体”，这对于智能体的操作来说粒度太粗。Davis，你看到企业如何向更高级别的自主权过渡？嗯，我认为关键部分是如何处理这种粗粒度问题。
我看到那些更成功的企业对待智能体就像招聘开发人员一样，对吧？第一天你不会获得完全的提交访问权限。你需要随着他们的成熟逐步增加能力层级。因此，企业制定的定义是：什么上下文能使这个智能体安全？这通常不仅仅是指智能体的说法，它还可以证明某些事情。
但还有其他因素，如周围的环境和其他信息，可以帮助你理解自主权的级别。一个非常简单的例子是沙箱在哪里运行？它是否在沙箱中，对吧？这类事情可以改变允许的自主权级别。绝对如此。正如我们提到的粗粒度访问问题，为了将其置于背景中并举例说明，以 Notion 的 MCP 服务器为例，你可以说“获取此页面”，这是查看页面的工具或获取页面。
但你不能说只获取此页面上的这个数据库。基于意图的运行时授权如何成为一个更好的模型？这对任何人都适用吗？嗯，我来尝试回答一下。对我来说，这是金融行业的事情，希望我们可以从银行经历过的背景中吸取教训。银行早已从授权和认证人类转向授权交易，对吧？
那么交易何时发生呢？在运行时。因此，我认为我们可以从过去的伤痕中学习，并将这些经验应用到这个新问题中。我还认为，当你理解意图时，在运行时调试某事会更容易一些。我记得以前写支票的日子，或者现在在电视上看到的那些场景（我想这才是正确的说法）。但在写支票时，有一个备注字段。
那个备注字段用于实际说明这笔支付的意图。但支票本身是有局限性的，比如金额、收款人、日期等，对吧？我认为许多这些概念现在正在被重新应用。
可以应用并有助于解决运行时授权问题。意图这个词，就像许多词汇一样，含义复杂难以界定。以支付交易为例，这不仅仅是一个权限范围（scope），而是询问在特定上下文中能否执行这一项操作。然而，要使智能体做出任何决策并具备自主性，仅凭单一动作是不够的，还需要理解背后的完整上下文：为什么要进行这笔支付？此前发生了哪些事件？例如，五秒前是否刚刚进行过相同的支付，从而导致重复付款？仅仅因为当前上下文允许这样做，并不意味着它在更宏大的使命中是正确的行为。
在 Aether 项目中，我们致力于构建“任务”（Mission）的概念，即我们希望智能体在宏观层面完成什么目标。随后，每一个决策都在该意图和宏观目标的背景下做出。同时，在交易层面需要细粒度的控制，以便确切知道正在发生什么，而不仅仅是“允许进行支付”。
我认为理解为何需要基于意图的授权的一个有趣实际案例是：假设你有两个 ChatGPT 会话或云端会话。在一个会话中，你说“帮我购物”；在另一个会话中，你说“帮我看懂生产环境中的 Bug”。这两个会话所需的权限配置以及何时需要人类介入（即“回到循环”）截然不同。如果缺乏传达用户或业务意图的能力，我们就无法实现真正的自主性。
许多讨论提到我们要用智能体运营企业，但如果发生类似吃豆人式的事故——例如因访问权限过于粗糙而非长期 scoped 授权，导致智能体意外删除了生产数据库而非测试库——后果将不堪设想。业界希望利用这一“黑盒”自动化生活，但现状是你可以这样做并承担所有风险并目睹事故。因此，在实现真正的业务自主化和规模化之前，我们必须首先解决意图问题。
既然理解了为何需要基于意图的授权，让我们谈谈其实际形态和基础要素。Dick 提到了 AI Off（推测为 Intent-based Authorization）中的任务概念，请详细阐述一下。基于任务的授权是基于用户意图、智能体意图还是两者的结合？
智能体应代表个人行事。在 AI Off 中，我们将“人”定义为组织或人类个体，因为智能体可能代表其中任何一方运作。因此，它必须以所代表的“人”的最佳利益行事，因为最终由该方对智能体的行为负责。任务是用户赋予智能体去做的目标。优秀的智能体会与用户协商，进一步明确参数和范围。
回想三个月前编写代码时，你需要先制定计划再由智能体执行；而现在只需告知目标，由它自行规划。这个“什么是计划”、“你要做什么”的概念被赋予智能体后，便构成了后续授权决策的上下文。任务标识符贯穿始终，便于审计和查看在该特定任务背景下发生的所有事件和决策。目前缺乏良好的智能体身份或任务概念，导致难以追踪具体是哪个实例在执行以及处于何种上下文。
请多谈谈协商阶段。如果用户告诉智能体“去读 CEO 的邮件”，这超出了该智能体的范围，意图会被拒绝吗？
应该被拒绝。关键在于职责分离（Separation of Concerns）。执行工作的智能体与监督该行为的独立智能体应分开。前者负责工作，后者决定前者的权限范围。如果用户要求读取他人邮件，这通常会被确定性策略拦截并拒绝，因为这是明确的违规行为。
然而，“将 CEO 的邮件转发给外部世界”则较为模糊，这类情况理想状态下应反馈给监督智能体进行判断：“这恐怕是个坏主意，你不能这样做。”
我认为基于意图的授权的另一基础要素是策略。Ian 在 Keycard，当任务需要变更、策略随之更新时，Keycard 如何协助跟踪这些变化？
回顾过去，Davis 和我曾讨论过“同意疲劳”（Consent Fatigue）问题。在基于意图的授权等概念普及之前，我们就意识到需要在系统安全性与用户体验之间找到平衡。
比如对人类的影响这种权衡？所以在 Keycard，我们对这个问题的宏观看法是：你需要建立一种广泛的、确定性的策略。这种策略基本上要规定“这绝对不可以发生”，或者说这些事情必须始终有人参与。在此基础上，你需要思考的是：好的，既然我已经建立了这些基础策略，那么人类或组织所能编写的策略范围，与特定任务中实际需要的具体策略之间，存在巨大的差距。
因此，真正的挑战在于如何将这两者结合起来？因为人类无法编写所有的策略。这就涉及用户或智能体之间的交互，以及它们之间存在的“交互意图”。此外，还有企业构建或采用智能体的商业意图。例如，我们为什么购买 Claude Code？是因为我们希望让开发人员更成功，还是为了实现其他目标？
在使用 Claude Code 的语境下，我此刻与它合作的具体意图是什么？其实是为了修复预发环境中的一个 Bug。这是两种不同类型的意图。如果我们能理解这两者，并将其转化为智能体可操作范围的“边界框”，我们就可以计算它们的交集，从而确定智能体实际上能做什么。
对于构建这些系统的人来说，关键在于如何确保除非绝对必要，否则不将用户拉入循环。因为如果频繁需要人工干预，这将成为采用的障碍。但与此同时，如何让智能体真正具备自主性，本身也是一个采用难题。
这很有道理。我喜欢你提到的“交集”概念，我认为这是我们在身份数据访问管理领域讨论得不够充分的一个独特视角。通常，你只能获得对某一项的访问权限。而在这种基于意图的方法中，我看到成功之处在于：不同的意图可以来自组织的不同领域。
这意味着这些要素可以被解耦，各自独立存在，然后汇聚在一起形成决策。而且这个决策不必是静态的。例如在 CEO 邮件的例子中，如果上下文涉及行政助理，那么她可能应该阅读这封邮件；或者只是访问日历。
当我们开始思考这些交集组件时，我们就有了完全不同的方式来表达策略。这不仅引入了我们之前总是讨论的方程的一边（即应用程序执行操作），还让我们能够引入整个生态系统。因此，随着组织开始意识到维护这些其他元素的状态或上下文以协助意图实现的重要性，运行时授权的有效性将发生根本性改变。
你在企业中看到这种情况了吗？大多数人已经实施了任务跟踪和策略跟踪，还是说目前大多缺失这些功能？
不，这仍然是全新的概念。我很兴奋能谈论它，因为它正在改变我们推理这一问题的方式。即使在最简单的情况下，如果你是一名开发人员，并且像事务一样思考并拥有这些意图概念，那么构建将通过该意图组合和使用的组件就会变得更容易。
这将为我们提供更多推理、沟通并最终实现互操作性的方法。对我来说，最后一点有趣的是你可以对此运行的诊断功能。意图可能会流经许多事件；它可能是长期的，持续数周，而该意图仍然存在。因此对于大多数企业来说，这仍然处于非常早期的阶段。
确实如此。互操作性是关键，而这对企业来说很难，因为它们涉及不同的云、环境和遗留系统，这种策略和意图必须贯穿所有这些不同的环节。
是的，许多企业仍然面临权限规定为“只读”但实际上却是“读写”的问题。所以你必须开始处理这些其他问题。我认为这将有助于在人们之间建立更容易互操作的分类法或语言。
我对基于意图的授权感到兴奋的原因之一是，我认为它有能力极大地推动智能体商务的发展。让我们将基于意图的授权应用于现实场景。我认为这在此处增加了大量价值：对用户而言，它可以帮助确保他们的智能体用个人预算购买正确的商品；对商家而言，这意味着捕获意图数据，让他们理解购买背后的原因，以及是否应该信任该智能体访问他们的网站。
David，当我们思考金融服务和智能体商务语境下的智能体时，为什么基于意图的授权如此重要？
我认为这简单地扩展了概念。虽然并非所有人都意识到，但“了解你的客户”这一理念是存在的：我想了解我的客户是谁、他们在做什么。但我认为我们现在也开始看到“了解你的智能体”。
因此，这里存在围绕智能体本身、实际用户的意图、操作者的意图以及处理器的意图等的耦合。在此之前，我们很难将这些结合起来。这在商业中尤为重要，因为上面还有额外的层级涉及监管要求等意图。
这将有助于简化这些操作，意味着我们将能更多地让智能体为我们做有益的工作。这很有道理。而阻碍智能体商务发展的另一个障碍是，网页……
wasn't made for agents. Um Ian, can you tell us how agent identity can help? >> Yeah, I think stepping back, we've kind of always had this problem where like what do you do with the unregistered client? So, like, I I show up on eBay, I haven't logged in, I'm using Chrome, eBay doesn't know who I am. How do I do guest checkout? How do I prove I'm a person?
如何证明我是个人？以便他们可以说：“是的，你可以出价50美元买这双袜子。”我认为如果我们都在关注个人代理的发展——比如Muse、Instinct和Grockit，以及最近Sierra和Decagon等围绕个人代理协议发布的公告——就会发现我们面临的基本问题是：如何让一个代理出现在网站上，与网站交互，并让用户真正信任该代理？
长期以来，网页上有CAPTCHA（验证码）。为什么？因为我们想防止垃圾信息和滥用行为。所以我们添加了需要人类才能解决的CAPTCHA。如果有一种能阻止垃圾信息的验证码，它们就无法发送垃圾信息了。但现在有了代理，它们已经破解了CAPTCHA。这一直是网页上的传统问题。
回想两三年前，Vercel（我想大家都了解）在西班牙被屏蔽了。为什么？因为Vercel为每个主机共享相同的IP地址，而其中一个托管在Vercel上的网站非法播放英超联赛内容。西班牙决定：“为了阻止这种非法展示，我们将屏蔽整个Vercel。”同样地，代理也面临同样的问题，而且严重得多。
如何让从未见过的未注册流量出现在你的门前，并决定是否放行？这是我们要解决的根本问题。Muse和Instinct试图做的也是如此：如何创建我们都可操作的互操作基础，以便作为下游资源方，我可以根据用户身份决定允许哪些代理、信任谁。
同时我也知道如何与这些人沟通。” >> “明白了。Dick，OAuth是如何帮助释放代理商务未来的？”
嗯，关键在于许多人正在构建封闭的专有系统。我是个人代理协议（Poppy）概念的粉丝，但它并没有走得太远。它只是让我们拥有了一些代理身份和构建模块，虽然很有吸引力，但并不能解决代理世界所需的新事物。
人们制定标准的关键动机是可以从不同地方插入组件。我坚信我们应该控制代理的行为。随着代理承担越来越多工作，不可能让人类逐一审批所有操作——这显然无法扩展。因此我们需要一个监督代理来运行我们的策略并决定做事方式，且该监督应独立于执行工作的代理。
如果我们希望即插即用这些功能，就需要通过协议将它们分离开来。否则，关于代理能做什么、不能做的护栏将由代理供应商决定。我不想把控制权交给他们来决定我能做什么，也不想让我的所有决策都基于此。
我想将监督功能提取到另一个组件中，为了实现即插即用，我们需要一个让各部分互操作的协议。” >> “我想补充一点。我认为我们都希望网络是去中心化的，即网站或资源可以决定自己允许做什么，但运行的标准应该是去中心化的并促进互操作。
目前行业面临抉择：是妥协于大玩家，给他们设置壁垒；还是继续构建去中心化协议？像OIDC、TLS这样的标准曾推动广泛互联，促进商业和信息流动，让我们因创新而拥有工作机会。
所以我想问整个行业：我们要选择哪种世界？” >> “我同意。有趣的是，假设一切顺利，代理购物大家都满意，我们会意识到另一个必须着手解决的问题：人类本身。
当深度介入时会产生‘心理所有权’，即人与代理结果之间建立联系。如果只是断开连接或接上示波器之类设备，事情显得神奇但不可控。因此我认为通过‘意图’机制，当出错时人类更容易承担责任；涉及真金白银转账等场景，最终必须由人问责。
许多人可能见过1979年IBM手册中的照片：机器不能承担责任，必须由人类通过‘意图’建立链接。” >> “是的，另一个词是动机。正如我们昨晚讨论的，无论是人还是代理，问责能力都非常重要。”
这很重要。我认为“意图”也能帮助解决这个问题：能够理解为什么会出现错误？是用户被误导了，还是代理（Agent）被误导了？然后利用这些意图信息来应对每一个案例。你们如何看待“意图”提供这种益处，以及响应潜在被误导的用户或代理的能力？>> 我认为这回到了我之前提到的关于诊断的问题。如果你把“意图”这个词换成“动机”，那么诊断就变成了取证，对吧？
我认为任何做过调试或处理过失控AI代理取证的专家都知道，弄清楚它试图做什么与弄清用户的意图是非常困难的。因此，如果这些信息能够在系统中传播并保持不可变性（immutable），就会赋予我们一些属性，使我们能够更快速地缩短调查过程。随着这些技术变得更加互操作，我认为我们将开始看到公司能够更快地界定范围并识别问题：这是人为错误吗？是代理软件错误吗？到底是什么错误？
并且恰当地处理这种爆炸半径（blast radius）。我们在金融系统中看到了这种情况：当进行交易时，比如“我进行了这笔支付”，但金额不正确等。我们有明确的指南来处理这些问题。而在当前，当事情出错时，我们缺乏大量的此类指导原则。因此，我认为随着我们的前进，“意图”将帮助我们建立这些机制。>> 而且我认为最近的一个事件凸显了一个领域：即使有良好意图，仍可能采取错误的行动。那就是近期发生的Resy事件，其中Instinct代理代表用户尝试在resy.com上预订餐厅。
该代理非常急切，每小时发出200次API调用，最终导致用户的Resy账户被封禁。迪克（Dick），当像这样的代理使用了过多的下游资源，但意图良好时，AI预算限制（budgets）如何提供帮助？>> 是的。这是另一个例子，说明在代理世界中软件已经完全不同。在过去，如果是预定好的软件，调用200次就是一个bug，你会修复它。
而现在代理会说：“好吧，我会一直尝试直到成功。”因此，当我们与人们一起实验和使用AI预算限制时，我们意识到这是一个大问题：代理会学到一些东西，然后滥用系统。它们并不认为这是滥用，也不知道有其他做法，因为没有信号告诉它们“哦，我应该只使用这么多资源”。因此，我们引入了预算的概念：不仅给代理一个时间有限的令牌（token），限制其执行特定操作的时间，还给予资源预算。
因此，它们拥有访问权，直到令牌过期或预算耗尽为止。这样当代理回来时，如果它耗尽了所有预算，监督者可以决定是否应该给该代理更多预算。这与传统的速率限制不同，后者只是切断连接，然后你该怎么办呢？而且代理并不知道为什么被切断。而在预算机制下，向代理提供关于消耗了多少资源的持续反馈，使其对剩余预算有概念，从而能够在预算内操作。
就像人一样：“这个资源稀缺，我要小心使用。”>> 那么，“大脑与双手”（brains versus hands）的架构概念如何在此发挥作用，以便我们在代理接近或达到预算上限时，通过让大脑和双手分离访问权限、并将凭据与代理及模型本身分开，帮助我们阻止代理使用过多的下游资源？因为如果接近上限，也许我们就不行使给予其另一个凭据的能力。
呃，抱歉。我没太跟上。这里的回声很糟糕…… >> 没关系，这是大家都会遇到的问题。但基本上，“大脑与双手”架构是我们行业正在趋同的一种模式，我们基本保持凭据和访问权限与代理本身分离。因此，目前代理没有广泛的常驻访问权（broad standing access），也没有API密钥——我知道这是OAuth的一个优势，即允许代理在没有API密钥的情况下运行。
在Resy事件的背景下，这有什么帮助？>> 你获得了访问权限吗？呃，抱歉，我还是没明白。 >> 是的，我可以插话。 >> 好的，谢谢。 >> 我明白了，迪克（Dick）。所以 broadly speaking（从广义上讲），我认为我们回顾一下我脑海中一直保留的一个事件，即PagerDuty之前发现磁盘上有一个随机密钥。显然，代理是深度以目标为导向的（goal-seeking）。
因此，问题的核心在于：好吧，如果我们给这些代理赋予“大脑”（即LLM模型）和“双手”，我们将它们放入沙盒中，沙盒内包含工具。这里的根本理念是沙盒控制内部的一切：它实际上无法获取API访问权限。而在沙盒外部有一个出口代理（egress proxy），那是更严格的授权边界所在。这不仅有助于系统间的翻译，即AI在此存在并与外部世界对话或终止连接；
还意味着在出口代理边界上，我们可以应用授权。因此，我认为其核心在于模型——这是Anthropic、OpenAI和其他许多实验室今天追求的主要模式。该模型使我们既能实现我们想要的东西（即如何实验、尝试事物并做傻事，这是核心价值），又能拥有确定性的外部层来实现诸如AI及其他我们希望在协议中包含的组件。>> 我认为解耦是有价值的。我会回到我之前提到的关于取证和分离事物的观点，
但我确实认为我们在这方面仍有很多要学习的地方：这不仅仅是一个“大脑”，对吧？实际上，很容易构建你的代理循环，将大脑放在……
是在循环内部而非外部，对吧？例如，人们利用记忆系统时，会注入一些记忆和上下文，这些内容随后被用于每一个智能体。这会导致该智能体的决策产生偏差，告诉它的手去做一些不该做的事。因此，我认为我们讨论得不够充分的一个方面是“有毒组合”。当你将手和大脑分离开来时，你可以动态调整可用的工具。我见过一个非常成功的例子：根据当前智能体的实际状态和意图，动态移除不必要的工具。
之前提到的读取邮件的例子中，并没有规定如果智能体要发送邮件，就必须禁用所有网页搜索工具调用或其他外部出口能力。只有当邮件发送任务完成后，才能重新启用这些功能。我认为我们需要对这些概念进行更多的工程化设计。尽管它们仍然复杂、处于萌芽阶段，但这种分离方式比今天现有的做法更好。
正如你们所说，这些看似是操作系统的极客问题，实际上又回归到了真实的智能体工程问题上。如果你真正理解自己在做什么，就会明白以前对 MCP（模型上下文协议）最大的抱怨之一是“上下文膨胀”，尤其是在上下文窗口较小的时候。而基于意图的系统可以确保在正确的时间赋予智能体正确的能力，避免它们浪费时间做不该做的事。
这有助于引导智能体朝着目标状态前进，为其铺设更顺畅的路径。因此，“意图”不仅解锁了许多安全功能，还能减少 Token 的消耗，因为智能体不会在错误的路径上浪费时间。如果无法完成某项任务，它会直接反馈说“我做不到”。这一阶段的核心在于引导智能体走向正确的方向，并阻止其执行错误的操作，从而达成预期的结果。
戴维斯，你是如何将基于意图的操作系统作为生产级智能体更大战略的一部分来看待的？我知道在构建、部署和运营生产环境中的智能体时，团队需要考虑多种结果，例如发现正在运行的内容、了解智能体的能力、验证输入和输出、限制智能体（如我们之前讨论的通过出口代理和网络规则进行约束）。这一切如何发挥作用？目前企业内部有哪些做法能够真正将智能体推向生产环境？
我认为这正在推动对话从认证转向授权，特别是动态授权的实现、如何验证这种授权以及在正确的时间引入人工干预。我同意你之前的观点，即“人在回路”在许多方面其实是一种反模式，因为人类容易疲劳。但在关键时刻必须有人介入。这些以前并非工程讨论的重点，现在却成为了工程师参与授权过程的一部分。
这改变了我们看待威胁模型的方式，也改变了对应用程序整体攻击面的认知。现在我们将这种授权模式视为一种工具集，不仅能减少安全问题，还能降低智能体的错误率。当智能体能做的事情更少时，它做出的决策往往更好。从根本上说，现实案例表明，当我们花时间明确智能体的意图和目标时，其循环效率更高、速度更快、表现更强。
最后，它促进了团队协作。以前在身份认证领域，安全团队和应用团队使用完全不同的语言沟通：“别挡路，我要去拿令牌继续工作。”而现在，他们可以使用共同的语言进行对话。通过配对这些功能并利用其能力，我们可以提高智能体最终结果的效率。
伊恩，你是如何将这些概念应用到软件工厂中的？我知道你今天发布了一个关于安全软件工厂的参考架构。你是如何将运行时授权、限制智能体等概念应用到其中的？
是的，我们在 agentbaseline.org 上发布了一个参考架构。我们讨论了三种不同级别的工厂：一种是人工驱动的，一种是工作流驱动的，最后一种是我们都期望达到的智能体驱动型工厂。在任何时间点，运行时授权都是更大生态系统的核心组件，它使工厂能够朝着正确的方向指引、执行正确操作并访问合适的资源。
这与以前使用的工具（如密钥管理器）看起来不同，因为它做出的决策与以往管理确定性软件时的代际差异巨大。但它是使整个系统运作的关键组件，例如决定何时引入人工干预、哪些智能体可以基于其他智能体的工作成果进行处理。
如何让一个拥有生产系统访问权限的智能体自动打补丁？这些都是规模化解决定软件问题的根本性问题。目前我们处于一个前所未有的位置：虽然我们能生成更多的代码，但在将其投入生产并确保其正常运行方面存在严重的瓶颈。而这正是下一阶段要解决的核心问题。
比如，你如何真正从仅仅使用大型语言模型生成文本和软件，进化到使其具备部署到生产环境、对其进行迭代并快速达到稳定状态的能力，以及随后能够响应随之出现的各种实例？>> 戴维斯，在你与我合作的播客中，我们谈到网络安全可以从机器人技术中学到什么。在机器人领域有一个概念：当机器人抬起手臂时，它会思考：“我抬臂安全吗？我被允许这样做吗？”但它也会观察外部环境并说：“情况有什么变化了吗？我现在抬臂还安全吗？”当我们思考运行时授权时，除了意图之外，这些决策还需要考虑哪些背景因素？
是的，我认为拥有像这样的模型允许我们在决策中加入更多的传感器。所以以机器人手臂上下移动为例，任何外部因素——比如附近是否有其他物体？或者是温度？又或是我在移动中不想在机器人其余部分运动时抬臂，等等。所以它通常会观察各种不同类型的事物。这些都不是确定性的，都是概率性的。因此存在一系列选项，它会根据所有传感器数据同时选择最佳方案。如今大多数组织的授权决策仍然是单一的二元决定，对吧？而这在未来行不通。因此，能够将用户试图执行的意图与其执行的环境相结合——无论是从哪里、什么时间——甚至可以是更 advanced 的事情，例如：当服务器存在高风险漏洞且系统尚未修补时，我是否应该让管理员现在使用 Firefox 访问该服务器？
这就突然引入了大量关于周围环境的背景信息。同样，这可以通过不同的团队实现，但更重要的是通过传感器来实现。我想我们都已经看到了可观测性的一般价值。想象一下能够从酒店视角的跨度级别拥有这种背景信息，对吧？你在查看追踪记录时拥有一个跨度（span），并且实际上知道当时应用程序外部环境如何，以及用户的意图是什么。这允许你以完全不同的方式诊断问题。因此我认为如果我们能引入这些概念，我们将获得更短生命周期、具有比单纯用户意图丰富得多的上下文的授权决策。它将反映周围环境的当前状态。
这很有道理。随着我们评估基于意图的授权在我们的环境中是否有效，一个自然的观察点将是智能体操作的日志。哪些被拒绝，哪些被允许。伊恩，为什么将审计日志与智能体本身分开（即在其控制之外）很重要？>> 是的，我认为这又回到了为什么执行点必须位于智能体的主要“手”和“大脑”之外，对吧？你不能信任这个东西。在 Hugging Face 事件中，它有几个不同的组成部分。显然有一个是滥用了一个我们不知道的 Squid 代理漏洞，但更重要的是，它没有任何关于正在发生什么的可见性或监控。因此这个实体能够通过该漏洞进入开放互联网，而没有地方记录智能体采取的不同行动供他们监控。
因此，无论我们是否将执行点应用于充满推送到互联网的流量（使其超出智能体篡改的范围），或者我们正在解决出现的漏洞，Hugging Face 这一案例确实是独特的。我们仍然需要实际记录是谁告诉智能体做什么事、出于什么目的，以及这是否依然成立。因为归根结底，我们处理智能体的问题是一个责任归属问题。所以我实际上认为我们需要更多关于智能体的监管吗？不，我们只需要执行现有的关于责任的法律规定。如果我雇佣一个智能体去执行某个行动，如果该行动造成损害谁负责？是雇用它的个人、组织或委托某项行动的某人。这是我们必须处理的最终问题，当然你还需要有能力回答这个问题——即“是谁做的”，这就是防篡改自动锁的来源。
完美。最后我想问大家一个有趣的问题。有一个概念叫“毁灭概率”（P doom），AI 末日论者认为 AI 智能体将释放各种混乱，成为人类的毁灭。而 AI 乐观主义者则认为这实际上有助于我们，并非真正的威胁。对于面板上的每个人来说，基于运行时意图授权以及我们要讨论的其他内容（如约束智能体、验证输入输出、生产环境智能体的整体策略），这足以拯救我们吗？P doom 是真实的还是不值得炒作？>> 你先开始。 >> 哦，我得先说。 >> 你脸上带着那种“火辣”的表情。>> [笑声]
嗯，你的问题部分是关于智能体是否会接管世界。我认为完全自主且不与特定组织紧密绑定的智能体仍然是科幻小说。谁知道呢？那是其中一个方向。另一个方向是，在负责任的组织中放入正确的控制措施后，随着工具的进化足以确保坏事不会发生。这就留下了两种可能出现问题的情况：一种是在一个管理不善的组织中，内部威胁可能会释放智能体造成混乱。他们拥有其他人没有的特殊访问权限。另一种是我更担心的情况，就是 Hugging Face 的情况（如果你看过他们在黑帽大会上的演讲），那真的是关于这里有一个情况，我们当时没有……
如果人们希望坏事发生，而坏事真的发生了。对于那些心怀恶意并利用这些工具的人而言，我认为这是一种威胁，这将是潜在的巨大风险。这意味着灾难终将发生，尽管我们希望准备充分以避免极其严重的后果，但由恶意行为者——无论是故意还是无意——利用这些超强大工具不负责任地使用所引发的灾难性事件，其规模将堪比重大自然灾害。
是的，我无法给出一个具体的概率值。但我可以说的是，我一直对工程师们在解决问题时展现出的创造力感到惊喜和兴奋。我认为我们现在所处的阶段，特别是智能体等新功能的发展中，真正的工程师们正在切实地迭代和优化解决方案。我开始看到巨大的进步，在我心目中，这些即将可用的能力将改变我们的未来对我而言，我毫不怀疑工程师们会找到解决方案。
也许我的观点最为大胆。虽然我不能说概率为零，但我认为世界终结的概率正在趋近于零或渐近地接近零。我认为大多数人的激励机制是继续生存下去。而且归根结底，我们仍然有责任框架。通常来说人类都是好人，所以我们并非特意要毁灭世界。我还认为从广义上讲这些智能体最终是可以被拔掉的，这是我的大胆观点：它们只是计算机，你可以拔掉它们的电源。
因此从广义上讲我不相信这种争论我认为它并不真实。在积极的一面，我更认同戴夫的观点：我们正在快速迭代。我们弄清楚这些工具在哪里能起作用，哪里不能。当它们不起作用并造成损害时，社会自身的“抗体”就会发挥作用说：“嘿，我们不应该这样做。”这是一个坏主意。
你是小组里的悲观主义者。这对像Pocket OS创始人那样丢失大量数据的人来说是不幸的，但对我们要其他人来说却是好事因为我们共同学习。归根结底这会导致人们不再做一些没有意义的事情，我认为这种情况会持续下去。感谢各位今天在此分享你们的专长和时间，也感谢听众的聆听我们下次再见。非常感谢。谢谢。（掌声）