大家好，我是埃文·科莫斯。我从事软件交付、设计和构建工作已有20年，其中过去15年在企业金融服务领域。我是Coinbase的“球员兼教练”（即既参与管理又亲自执行）。今天我们在这里讨论如何在政策驱动的工作流中建立对智能体（Agent）的信任。
让我们从策略开始，这听起来可能有点枯燥。我会参考一下笔记。我们的核心围绕“政策”展开，它设定了组织内工作完成的方式，特别是涉及风险和合规性方面。可以将政策视为原始的机构意图或原始的系统提示词。理想情况下，这些内容是书面记录的。虽然有点枯燥，但请继续听下去。使用“必须”、“可以”和“应该”等语言有助于定义规则和关于系统如何在组织内运行的决策。
与政策分开的是实际运行的系统。我们要做的第一件事是将这两种状态——构建状态和运行状态，在时间上区分开来。通常我们要么是在定义或改变策略，但系统却在不断运行、移动和变化。因此，我们可以想象一个编译事件……抱歉，我跳得太快了。系统在不断快速演变，伴随着这些以产品为导向的变化。
虽然一切预期仍大致受政策约束，但我们最终将运行状态与构建状态区分开来。在系统内部看起来是什么样呢？如果这里有企业界的朋友，我们会看到一个熟悉的模型：人员、流程和技术。但智能体究竟在这个模型的哪里呢？我将它们视为一种贯穿这三者的运营模式。它们与人员协作，自行执行部分流程，并使用由技术构成的工具。
因此，今天的讨论我们将聚焦于智能体与流程交汇的地方：我们赋予它们什么工作，设定什么样的边界，以及如何建立对其输出的信任。让我们深入探讨您的工作流程。虽然这很宏观且看似基础，但如果您还没有这样做，是有充分理由去梳理它的。
也许在上线前需要批准变更，或者客户在开户前必须通过验证。我们期望工作以特定的、有门槛的方向流动。因此，我认为重新审视我们可以并行完成的工作是值得的。以前，某些工作因为成本过高或协调过于复杂而无法以这种方式进行。但现在我们可以并行运行独立的审查，汇总结果，同时保持必要的检查到位。
这就是有向无环图（DAG）。它是一种表示工作流或流程的方式，展示了步骤和依赖关系，使流动向前推进而不会自我循环。如果您熟悉Apache Airflow，它是一个开源软件示例，用Python代码将工作流及其依赖关系表示为DAG。
这些由Python代码定义的DAG可用于定义和管理许多政策驱动的流程，例如商业贷款。如果您对此感兴趣，我们也可以使用DAG来表示在特定地区上市代币的工作流。或者我们可以用DAG来代表受监管的软件交付流程，这是一个热门话题，也是我们打算花一点时间讨论的话题。
我们在软件交付领域看到了大量的智能体采用率，最终我们希望在业务的其他领域利用同样的效率和规模，缩小采纳差距。让我们暂时坚持使用软件交付的例子。在这个过程中一个节点内部会发生什么？我给你们一点提示，这是一个循环。
我简化了，但我们有正在发生的事情的基本版本。让我们假设这是代码审查流程。我们将执行一系列步骤，一旦我们意识到工作足够好，我们就允许它进入下一步。这基本上就是代码审查节点的功能。然而，工作并不总是顺利结束。有时我们必须从代码审查中获取反馈并进行迭代，直到工作足够好以通过为止。
因此，这是对Directed Cyclic Graph（DCG）即有向循环图的表示。就开源软件而言，像LangChain或LangGraph这样的工具将有助于管理DCG的状态。这是一个过度简化；这些图可能非常复杂。因此，退一步看节点的内部流程，我们有人员与智能体协同工作。在外部流程中，我们有一个政策边界。
但并非一切都会按计划进行。我们必须处理异常流。我们不希望工作陷入停滞，也不想为每个边缘情况设计流程。异常流将监控并观察如果发送的代码被取消或不符合安全标准会发生什么，这是您应该关注的事情。
一旦我们将智能体引入混合流程中，流量就会在整个过程中发生转移。我们在软件交付中看到了这一点，随着我们将智能体引入其他流程，我们也会在其他过程中看到这种情况。现在突然之间，如果您更快地审查代码，就需要更快速地设计或进行更快的安全扫描。因此我们看到流量在整个流程中发生转移。
正是在这里，从指标的角度对整体流程拥有可见性变得非常重要。因为当我们开始加强、并行化并为流程增加更多效率时，我们会产生越来越多的瓶颈。因此，对流程的运营可见性极其重要，比编写和构建您的工作流工具本身更重要得多。
我们要可视化流程。因此，我们希望通过保持控制来增加并行容量，这就是我们将添加更多额外容量的地方。
好的。我们正在做一些工作，检查它，再次使用反馈来完善它，直到工作足够好以继续前进。但这为什么很难呢？哦，这看起来似乎是一件很容易做到的事情。但正如我之前提到的，这些图实际上相当复杂，我们将更深入地探讨为什么这很困难。如果您熟悉AI工程的一个挑战是输入和输出的可变性，我相信更高质量的输入将以较低的计算成本产生更好的输出。但什么是高质量输入？
因此，我们通常将其称为上下文模型。我们可以对此进行细微的推敲，但这并非我们今天关注的重点。我们将更多地关注输出结果。然而，如果不谈论输入的质量，我们就无法真正讨论输出的质量。因此，理想情况下，我们已经为智能体建立了一个可信的上下文环境。虽然有一些相关的参考资料，但在这种模型中我们可以做的一件事是将有向无环图（DAG）的状态注入到智能体中，让它知道自己在大局中的位置。
现在我们已经加入了长期目标，这更加强调了优化该循环的成本和效率的必要性。检查环节是我们决定工作是否足够好以继续推进的地方。我们需要定义什么是“好”，这是最难的部分，并且我们需要一种可靠的方法来评估它。否则，更多的迭代并不一定意味着更好的结果。循环的信任度完全取决于检查环节的可信度。因此，如果我们想谈论质量，让我们谈谈检查和高质量的标准。
我认为利用人工智能构建产品是提升整体产品质量的机会。我喜欢关于耐用软件的讨论，我是质量的坚定信仰者。在传统软件中，我们建立了信心机制来确保我们对软件的高质量有信心。这是通过多种机制完成的，但主要是系统地使用测试用例和单元测试，作为交付流程的一部分进行检查，以确保在进行代码更改时不会犯破坏其他功能的错误。这是我们在传统软件中建立的信心机制。
智能体是概率性的，因此相同的请求可能会产生不同的答案。可能有多个可接受的答案。我们仍然需要证据，但仅凭精确的输出比较是不够的。我们需要构建代表性数据集并进行评估，定义什么是“好”。我们需要运行这些评估的重复系列，这是一种统计分析。我们实际上要看的是输出的数量和整体情况，而不仅仅是直接比较。
结合评估结果的是运行时的日志或追踪记录（traces），它们记录了运行时发生的情况。我们建立了这种信心机制来补充传统软件。最终，我们将更多地讨论如何通过不仅建立此机制，还要开始启用它来提高对输出的信心。
智能体应该属于哪里？回到贷款示例中，我们可以并行和顺序执行KYC、财务分析等步骤，如信用备忘录、风险评估、文档整理、决策等，所有这些都在我们的DAG中。查看每个节点时，我们需要问一些特定的问题：让智能体驱动这个节点与让人类驱动相比价值有多大？我们可以看一些基本问题，例如：是否容易根据政策进行检查？它是否在受限循环中运行？是否可以追踪？如果我们可以回答“是”，并且事先对此节点更适合自动化有一个很好的想法，那么就可以进行。
但在整个DAG中，我们应该致力于推动智能体辅助作用。因此，我们真正谈论的不是AI是否参与，而是我们期望AI在某个时刻接管工作。对于决策环节，你可能同意我们需要由人类驱动，这本质上是对政策的检查。我认为这将更难通过“爬山”算法逐步优化。“爬山”是什么意思？我们如何启用它？
第一天，我们从监督开始。随着智能体和人类作为流程的一部分共同工作，我们可以手动验证输出以确保其高质量。这是我们完善数据集并确保持有正确信心机制的地方。我们与领域专家定义了什么是“好”，并且他们开始进行验证。当测量的置信度达到政策阈值时，我们可以转向抽样模式。这意味着人类只查看输出的一部分，而不是全部。
我们通过追踪记录开始更系统的评估，以确保人类未看到的部分仍符合质量标准。最后，一旦越过置信度阈值，人类处理更多的流程异常，但仍作为参与者参与数据集中 refinement 和确保输出质量。
以下是几点总结：DAG和DCG基于基本图论，但最终我们如何构建现有的流程并引入智能体？秘诀确实是外部保持确定性，内部使其自适应。其次是质量通过评估确立，这实际上是建立互补的信心机制。这不是对模型的直觉感受，我们可以提供关于智能体质量的研究和统计数据。这建立了信心并内在信任输出。
质量是团队运动。AI工程师拥有从各个方向获取产品信号并将其转化为构建良好应用程序的管道，并在幕后利用机器学习运维。最后，智能体加速了运营模式的发展。我在最后一张幻灯片中包含了一些关于我今天所讲内容的参考资料。我的演讲到此结束，非常感谢大家。（掌声）