AI Agent 系统的真实挑战：治理、安全与供应链

Ryan 首先与 Dataiku 联合创始人兼 CEO Florian Douettea 叙旧，探讨真正严肃的智能体系统，以及为什么这类系统需要经过精心设计的框架、编排、治理机制，以及可复用且有完整文档的数据产品。随后，1Password CTO Nancy Wang 再次做客节目，讨论为什么现有的身份标准无法适应智能体的新世界——尤其是当短暂存在的智能体集群让操作难以归因到某个具体用户时。

Dataiku 可以编排数据技术栈，并支持创建分析应用、模型和智能体。

Florian 此前曾参加过本节目，那一期是在上一届 HumanX 大会上录制的。

1Password 通过端到端加密、零知识架构等技术保护你的凭据安全。你可以前往他们的博客，进一步了解如何构建安全的智能体集群。

Nancy Wang 此前曾于 2026 年 3 月做客本播客。

在 LinkedIn 上与 Florian 联系。

在 LinkedIn 上与 Nancy 联系。

Ryan Donovan：我现在正在 HumanX 大会现场，与 Dataiku CEO Florian Duarteau 叙旧。上次我们交谈时，主题还是数据。如今我们已经转向智能体了，对吧？昨天的开场视频谈到，AI 正在进入相对乏味的阶段，重点转向智能体、安全和治理。你如何看待智能体领域目前的发展方向？

Florian Duarteau：我认为，与去年相比，智能体领域已经真正落地了。去年，我们才刚刚在 Dataiku 中推出智能体框架；而现在，我们的大多数客户都已经开始构建智能体。对他们来说，这是新鲜事物。但还有一点，智能体并不仅仅意味着构建那些花哨的智能体，也不只是把 OpenClaw 解包到笔记本电脑上玩一玩。我们看到的是，智能体正在取代更加专业的后台工作：用于供应链的智能体、用于优化制造生产的智能体、用于加速银行信贷风险评估的智能体，以及用于加速临床试验的智能体。它涵盖了所有这些以提高后台效率为目标的工作——可以说，真正能创造经济价值的地方就在这里。我认为，这正是智能体技术目前影响最大的领域。它确实是智能体技术中乏味但高风险、高影响力的那一部分。

RD：没错。虽然这些工作往往不是人们愿意亲自做的，但它们也是非常依赖数据的应用，对吧？智能体会对数据和数据处理产生什么影响？

FD：智能体对数据和数据处理的影响在于，数据转换、数据质量，以及将结构化数据统一纳入一个体系的能力，正变成真正需要解决的问题。这不再只是为了做 BI，而是要构建真正有文档记录、可供智能体实际利用的可复用数据产品。你还需要处理非结构化数据，并在非结构化数据之上建立语义层。因此，现在我们的大多数客户在构建新数据产品时，都会同步构建语义层，例如对数据集进行描述。这是一种新做法，而且正在成为数据构建和处理生命周期的一部分。

RD：你所说的“生命周期”，是指数据本身的生命周期，还是一般意义上的软件开发生命周期？

FD：它是智能体生命周期的一部分，涉及以人工方式实际构建数据等工作。我认为，挑战的一部分——或者说我们认为市场正在发生的转变——在于，就在几个月前，人们对智能体的一种理解还是：“让我们构建一个智能体，再到处连接一些 MCP，它就能神奇地把各种东西联合起来并正常工作。”问题在于，在许多用例中，它的效果并不足够好。因此，你需要回归到一种更受控、以项目用例为基础的环境中：针对某个具体用例构建数据基础，再构建运行于其上的智能体系统。你必须保证这种一致性，才能真正获得想要的结果。

RD：智能体与数据之间的这些交互，是否正在改变人们存储和管理数据的方式？

FD：有一些改变，也就是说，大家对新系统的兴趣明显增强了。我认为，我们的客户也在考虑许多不同的数据存储方式，例如使用 Iceberg 和更开放的格式，确保所使用的数据可以复用；同时，他们也开始更多地思考数据之上的安全层，以及如何在智能体世界中将这些安全层实例化。这些附加层现在成了大家首要关注的问题，而过去并没有受到这么多关注。

RD：最近围绕智能体的很多讨论都集中在一个问题上：应该允许它们访问什么？尤其是那些高度敏感、极其重要且很有价值的内部专有数据，特别是在涉及医疗试验时。现在出现了哪些范式来确保这些数据受到保护？

FD：是的，我认为这是目前市场尚未完全解决的问题之一：如何建立端到端的信任层，在智能体、人类和在线数据访问之间实现统一的身份管理。这基本上仍然是一个开放问题。为什么？因为当智能体执行任务时，你究竟希望授予它什么类型的数据访问权限，目前并不明确。这就是尚未解决的问题。我们现在看到的做法是，客户复用现有的数据访问机制，同时构建信任层，从而打造可实际应用的系统。

例如，我们的一些客户使用我们的平台来加速销售自动化：根据通话记录自动更新 CRM，这样销售人员就不需要亲自执行 CRM 更新操作，而是由系统自动完成。这是一个简单、可复用的用例。在这种情况下，安全层非常明确，因为参与通话的人有权访问通话内容；CRM 更新也可以代表销售人员本人执行。因此，这里的安全映射相当简单。但与此同时，有时也会遇到更加复杂的情况，尤其是在受监管的行业和制药行业，其中包含大量个人信息，也会涉及哪些事情应该做、哪些事情不应该做的问题。在这种情况下，你确实必须更加谨慎地判断安全映射应该如何设计。

RD：能否直接沿用智能体所有者的那种用户访问控制来完成安全映射？还是说你们发现需要更加细粒度的安全机制？

FD：需要更加细粒度的安全机制，尤其是当智能体不一定只有一个所有者，或者能够根据系统中发生的事件自行运行、拥有某种独立身份时。因为到了这个阶段，有时你希望智能体能够访问所有数据，以便构建聚合结果等；但在另一些情况下，你又希望同一个智能体或同一套智能体系统的访问范围更加狭窄，并明确它们应该模拟谁的身份，尤其是在回答某个特定用户提出的具体问题时。因此，你实际上需要在智能体应用本身之上，重新构建一个经过精心设计的安全层。

RD：我听说有些人正在把智能体直接构建到数据源中。你们是否也观察到了这种做法？你会推荐这样做吗？

FD：现在我们越来越清楚地认识到，不能真正把智能体直接构建在数据源之上，或者至少不能只构建在数据源之上。因为大多数智能体最终既要处理来自应用系统本身的实时数据，也要处理来自数据湖或数据仓库的离线数据；为了提供有意义的结果，它们必须将两者结合起来。你无法通过实时系统获得足够的性能或数据全局视图；但如果只使用数据仓库，也无法执行实时分析或检查。因此，为了兼得两者的优势，你需要对数据进行联合访问。

RD：那么，你认为应该把联合访问权限授予单个智能体，还是说你更认同那种由较小智能体组成集群的方式？

FD：你肯定会发展到使用智能体和子智能体的阶段，以此封装子行为，并以某种方式组织代码和系统。实际上，当你最终希望构建完整的学习系统时，往往会把一个完整用例封装成多个智能体。这些智能体都可以独立测试，也可以串联起来执行更广泛的任务。因此，你必须把这一整套系统共同构建起来。

RD：我听说，面向数据的智能体应用是人们大力宣传的智能体主要应用场景之一。但我也听过一些令人不安的案例：智能体在数据分析阶段产生了幻觉。有没有办法防范这种情况？

FD：是的，我知道。我认为，我们看到的是，那些想要构建严肃应用的客户确实会认真对待这件事。我们的一位客户是 Rush，他们为自己的专利申请流程构建了一套智能体系统。因为这对他们而言是一个重要问题，所以他们非常认真地对待它。也就是说，如果面对的是一个严肃的问题，那么幻觉就是必须处理的隐患，你不能只是写一个提示词，把它放到云端，然后听天由命。事情不是这么运作的。

FD：可以这样思考：每个智能体系统都需要围绕三个维度进行评估。而在我看来，这三个维度可以说构成了智能体成功的公式：人员维度、编排维度和治理维度。人员维度关注的是，智能体应该具备哪些人类技能，以取代相应的人类工作，以及这些智能体应该与哪些人协作。你能理解吗？编排维度关注的是，智能体应该通过哪些不同的技术或方式来编排自身决策，以及它应该操作哪些系统。治理维度关注的是，智能体做出正确决策究竟有多重要，做错决策又会怎样？其中有哪些受监管的风险？智能体所处领域涉及哪些公司风险和监管风险？根据这些问题的答案，你应该以截然不同的方式来思考智能体系统。如果你构建的智能体只是在业务中不受监管的部分执行相当重复、但层级较低的任务，那么即使它失败了也没关系，因为归根结底，它可能只是用某种特定方式呈现信息。如果它也不需要编排任何复杂流程，或与任何复杂系统集成，那么你运行的就是一个低风险智能体。实现这种智能体有很多很多种方式。也许你只需要在企业版 ChatGPT 上自己做一个，就可以收工了。

RD：是的，说得很好。很多企业的风险容忍度非常低，甚至供应链方面也是如此。我认识一些人，因为接手了风险容忍度很低的银行业客户，连自己工作电脑上的本地管理员权限都被取消了。这类低风险容忍度的组织是如何看待智能体的？正如你所说，智能体毕竟存在潜在风险。

FD：是的。他们会有意识地构建自己的智能体，并谨慎选择智能体框架。为什么？因为从人员角度来看，他们构建的智能体封装了技能水平极高的专业人员所具备的能力。比如，我们有一位客户正在构建智能体，以替代一部分银行中台工作，处理信用风险和抵押品流转。这涉及一些复杂规则，你必须应用这些规则，才能理解为什么风险质量规则发生了某些变化——究竟是因为发生了某笔交易，还是因为通货膨胀率出现了变化，诸如此类。都是复杂规则。

FD：它的编排也很复杂，因为需要执行大量不同步骤，而且必须按照特定顺序完成。同时，它所处的是高度监管的行业、流程和领域，也就是说，一旦出错，你就会被罚款，金额可能高达数亿美元。所以，这是高风险场景。在这种情况下，采用与其他任何智能体相同的方式来构建它毫无意义。你需要这种面向智能体的专家级框架，这也正是我们关注的方向，因为我们认为，大型企业要构建某些类型的智能体，就需要与自身数据紧密连接、并具备高度治理能力的平台。

RD：是的。人们似乎一直在讨论这些框架。很多组织一旦遇到数字、财务之类的事情，就会说这不是适合智能体的工作。

FD：如果你真正以正确的方式应用它，那就是适合智能体的工作，而且未来也必然如此。也就是说，如果你试图自己在 blockchain 和 Pidentic 上做这件事，甚至都不知道自己使用的是 Opus 还是 Sone，就只能听天由命，那么这当然不是适合智能体的工作。

RD：你所说的“适合智能体的工作”，指的是适合完整的框架，而不是适合处于核心位置的 LLM，对吧？

FD：是的，核心位置的 LLM 归根结底只是一种将会商品化的工具。

RD：所以，它会成为另一种工具，作为智能体工作流的一部分。对于开源 LLM 与闭源 LLM，你有什么看法吗？

FD：我认为开源 LLM 正在迎头赶上。我的意思是，就高质量框架而言，它们一直稳定落后九到十二个月。我认为这种状况可能还会维持一年左右，但两者肯定都有各自的空间，具体取决于你要处理的任务类型、你的部署能力，或者你是否确实需要在本地部署。越来越多的客户开始采用混合基础设施，同时为其数据和 LLM 工作负载结合使用云端与本地部署。我认为这有充分的理由。如果你是一家制造商，就会拥有工厂。理想情况下，你希望工厂在没有互联网的情况下也能运转，因为停产的代价非常高。如果你所处的是重视知识产权和研发的行业，比如制药、化工或 [听不清]，那么你的网络安全风险会更高，因为国家级行为者可能会试图窃取你的工艺或配方。因此，你的大量研发工作都需要在高度安全的环境中进行。确实，再举个例子，你可能会使用开源模型，因为你希望所有东西都封闭在一个物理边界之内。

RD：他们想要本地部署所带来的额外安全性，对吧？你知道，我们去年交谈时，我想那还是我第一次隐约听说智能体，也是我第一次听说 MCP。如今，每个人都在谈论这些东西。如果让你看一看水晶球，你认为明年我们会讨论什么？

FD：我认为，我们会越来越多地讨论智能体的某些子类型，并开始形成诸如前台智能体与专家型后台智能体这样的概念。我认为，这些会发展成不同的专业方向。这就像在 1997 年到 1999 年间，我们不再只讨论网站和 HTML，而是开始讨论博客、电子商务和 Ajax。智能体也会经历这样的过程。你会看到前端、后端，以及类似异步任务这样的专业划分和概念，它们会成为人们关注的核心。因为当你真正展望未来时，会有越来越多的专家型智能体在后台持续运行，并与人类进行异步交互。比如，你早上醒来时，智能体已经在那里了，它在夜间完成了大量工作，你修改了日期；你的工作方式也会发生变化，因为你上午 9 点到 11 点的工作将是检查智能体夜间完成的任务，对它们提出质疑，然后把任务交还给智能体。这是一种不同的工作方式，也是一种不同的工作日。

RD：我们不会只是跑去海滩喝 Mai Tai，或者……等待轮到自己进入那个，你知道的，太阳能绿色机器。

FD：希望不会。我不确定自己是否喜欢 Mai Tai，而且晒太阳对身体也不好。更重要的是，我认为届时仍然会有更多富有创造性且重要的工作需要完成，只是完成方式会截然不同，因为确实会有智能体为你工作，甚至在夜间工作。上午 9 点到 11 点，你检查它们的工作，并提出质疑。然后你去……也许人们的午餐时间会变得更长，让智能体在 11 点半到 1 点半之间工作。在这方面，法国人或许会占些优势。

RD：你们确实有优势，是的。

FD：是的，是的，因为我们热爱午餐时间。在午餐期间，我们会让智能体进行迭代，然后回来继续处理。

RD：我现在正在 HumanX 的录制现场。我们正在讨论智能体的身份和用户访问

控制。今天与我讨论这个话题的嘉宾是一位再次做客的老朋友，1Password 的 CTO

Nancy Wang。Nancy，欢迎再次来到节目。

Nancy Wang：非常感谢，Ryan。很高兴来到旧金山。

RD：是的。我们之前稍微讨论过这个问题，但随着智能体、后台智能体和智能体集群大量涌现，限定范围的访问控制正变得愈发重要。你在这个领域看到了哪些情况？

NW：好的。那让我们回到最基础的原理和基础知识。所以现在，我确信你在各种在线论坛上都听说过这些，无论是Reddit、X还是LinkedIn，对吧？我认为业界正在达成共识，即现有的身份标准对于表现得像人类、以机器速度行动的AI智能体来说已不再足够。这意味着，如果你想一想传统的人类身份供应方式，它们通常存储在某个记录系统中，比如人力资源信息系统（HRIS）或身份提供者（IDP）。供应和启动它们需要很长时间，对吧？它们通常在组织范围内进行管理。但是AI智能体呢，它们是短暂的，对吧？现在可以在毫秒级别内快速生成它们，对吧？特别是当我们考虑智能体沙箱、如你所提到的智能体群集时，数百个智能体。实际上，1Password最近进行了内部练习：我们是否可以快速生成一组智能体来调试生产数据库，供我们的事件响应团队使用。所以在那个世界里，当你有数百个智能体为某个目的或工作流一起行动时，你如何知道哪个智能体做了什么呢？特别是当你要给这些智能体提供敏感凭证时。是100个中的1个吗？是100个中的3个吗？现在你如何将该行动归属于特定的智能体，就像你会将其归属于某个开发人员一样呢？

这就是我们所说的设备信号发挥作用的地方，这些信号反映了智能体的来源。这正是1Password认为有助于解决这个问题的地方。鉴于我们目前在设备层面的位置，所以我们可以提供设备信号，对吧？设备态势信号，即：这个智能体来自哪个设备？或者，这个智能体在哪个浏览器会话中行动？现在我们可以开始提供关于哪个人类向哪个智能体委派了权限、谁生成了这个智能体、在哪里生成的，最重要的是，这个智能体是在什么背景、权限或目的下创建的等信息。这一切都涉及来源追踪，以及智能体的本质"出生权"。有了这些知识，就可以确定这个智能体应该根据其创建目的获得什么访问权限。这就进入了我们的无常驻权限哲学。这在很多方面类似于零信任世界的形成过程。现在我们将零信任原则应用于智能体。但这不是传统的零信任形式，即通过网络可以访问什么，资源与资源之间的访问，对吧？现在是任何东西对任何东西。因为如果你想一想MCP客户端的扩散，比如Claude、Cursor，这里的强大之处不再仅仅在于编排。而在于系统记录，因为如果你是一个MCP客户端，你现在可以简单地进行自己的工具调用，对吧？基于模型认为正确的内容与系统集成。

RD：也可以创建你自己的工具。

NW：是的，完全正确。所以现在的问题是，你可以在什么时候授予什么访问权限？这将是即时的、特定于任务的，这一切都与来源追踪和上下文相关联。

RD：我看到过一些讨论，关于你是要一个获得所有访问权限的单个智能体，还是多个各自具有特定访问任务的智能体。你对此有什么看法吗？

NW：好吧，我们实际上会看到两种情况，对吧？因为单个智能体执行端到端工作流的情况肯定会有用例。这完全取决于这些单一类型智能体的客户驱动型用例。例如，对于Romina和我致力于的写博客或发表观点等工作，通常这些是我在后台运行的单个智能体工作流。现在，对于更复杂的工作流，想想ERP、采购，特别是在工程领域。一个智能体可能提交合并请求。一个智能体可能进行安全审查。一个智能体可能构建并部署。所有这些，就像你会有独立的微服务一样，你会有独立的智能体来独立扩展、并行化任务，同时还要本地化影响范围。例如，提示注入问题对于智能体来说仍然是非常真实的。

RD：我的意思是，你在谈论它们访问ERP，这是企业业务的运行基础。有没有你想限制智能体不执行任何操作的地方？比如，你想阻止智能体花钱或移动可能对业务造成严重伤害的资源吗？

NW：是的。实际上，我刚才在和一位朋友交谈，他是一家处理FinOps敏感任务的上市前公司的产品负责人。就这样称呼它吧。他们发现，其中一个在后台运行的、管理投资公司大笔资金的智能体几乎把钱发送到了一个与预期不同的账户。它在多个步骤中进行了自我推理。它被阻止了，不是由人类阻止的，而是因为多因素身份验证。因为它没有MFA，所以它无法将钱转账到未知账户。但如果我们想一想这一点，这是FinOps领域最具声誉的公司之一，我会说，这就是我们目前所处的局面。因为AI智能体带来的巨大生产力收益，你想利用这个机会，这个10倍的生产力提升。与此同时，我们的安全护栏还没有跟上。这就是我们回到零信任访问原则的地方——访问控制在这里确实有助于为最后一公里问题提供护栏。也就是说，如果你无法访问银行账户凭证，如果你无法在这种情况下进行MFA，你的智能体实际上会被阻止执行可能与你原意相悖的敏感任务。

RD：所以我们讨论了很多即时访问、临时访问。这是如何工作的？因为我认为很多访问是基于时间的令牌，可以刷新或其他方式。你如何将其限制为仅仅一个调用或类似的东西？

NW：是的，这就是安全护栏跟不上的地方。实际上，我们很多的，我会