Brex的AI孤注一掷 (James Reggio)

▍嘉宾 James Reggio，金融科技独角兽 Brex 的首席技术官 (Chief Technology Officer, CTO)。他在 Pedro 后接任 CTO，主导了 Brex 内部高度纪律化、深入业务场景的 AI 转型。

▍关于 本期对谈深入探讨了 Brex 内部的 AI 实践。与很多停留在概念验证 (PoC) 的企业不同，Brex 已经将 AI 深度融入其业务日常，发展出企业 (Corporate)、运营 (Operational) 和产品 (Product) 三大 AI 支柱。节目中 James 详细拆解了他们基于标准作业程序 (Standard Operating Procedure, SOP) 驱动的智能体网络架构、采用 TypeScript 和新开源框架 Mastra 的技术栈选型、在金融合规约束下进行 KYC 和欺诈审计的智能体模式、以及在 AI 时代对团队研发效能与软件未来的深刻反思。

欢迎与背景介绍

James： 我们的AI战略分为三大支柱。首先是企业人工智能 (Artificial Intelligence, AI) 战略，涉及我们如何跨业务线以及在各个职能部门中采用和采购AI工具，从而让工作流效率提升十倍。

其次是运营AI战略，核心在于我们作为一家金融机构，如何通过采购和构建解决方案来降低运营成本。

最后一个支柱是产品AI战略，即我们是否要推出新功能，使Brex成为客户企业AI战略的一部分。我们希望构建特色功能并提供这样一种解决方案：当其他公司向董事会汇报时会说，他们采用了Brex，而这是其企业AI战略的重要组成部分。

Alessio： 大家好，欢迎收听《Latent Space》播客。我是Kernel Labs的创始人Alessio，今天和我一起的是《Latent Space》的编辑Swyx。大家好。

Swyx： 今天我们邀请到了Brex的首席技术官 (Chief Technology Officer, CTO) James。欢迎你的到来。

感谢你远道从西雅图过来。那边现在很冷吧？

James： 是的，现在正有一股大气河侵袭西雅图，所以风很大。我们正在经历全面的冬季气候。

Swyx： 你今天来是为了谈论Brex内部的AI转型。我们要从你的文章和背景中挖掘很多有趣的细节。你在Stripe、Banter和Convoy都有丰富的经验。

我最感兴趣的是你的职业历程。你从移动端工程领导者转型为CTO，这非常罕见。我以前曾评论过，只做客户端的人通常会有职业天花板，很难成为CTO，而后端或云基础设施人员往往更容易晋升为CTO。

从移动端工程师到CTO：创始人的职业路径与人才策略

James： 我经常听到这种说法，因为前端背景出身并达到这个领导级别的人确实不多。我很高兴能代表这个群体。

虽然我的简历显示我更多从事前端工作，但实际上是我几次作为创始人的经历，帮助我达到了现在为他人工作并成为CTO的职业高度。这个职位在很大程度上既是一个技术角色，也是一个领导和综合商业角色。

我认为更多是因为我在创业和建立公司过程中培养的技能，使我成为了一个合适的人选。这也是为什么在两年前我的前任Pedro离开时，他决定让我接任的原因。

Swyx： 我很好奇你们的看法。虽然这有点偏离主题，但现在很多初创公司都在吹嘘他们有多少前创始人。在某种程度上，你确实希望员工具有创始人心态和主观能动性，在公司里采取主动。

但我也在想，这有时是否会成为一种负面信号。

Alessio： 我不知道你是否考虑过这一点。对我来说，当人们雇佣前创始人时，更多的是关于人员流失的问题。如果你真的拥有创始人基因，很难长时间作为个人贡献者 (Individual Contributor, IC) 待在某个地方。

这就像是加入了一个项目，然后一年后又回去做创始人了。我很好奇，我确信你一定考虑过离开去创办另一家公司。

James： 事实上，这确实是一个备选项。甚至在接到让我担任CTO的电话时，我还在考虑离开去创业。

有趣的是，几个月前，我们为Brex推出了一项名为“欢迎退出者”的全新招聘和员工价值主张。我们有意强调这一理念：我们有很大比例的员工在离开后成为了创始人或部门负责人，我们对此表示庆祝和自豪。

这意味着我们欢迎那些希望获得不同经验的人。当然，有很多创始人未能将自己的业务扩展到Brex的规模，所以他们加入时可以学到很多东西。然后我们也非常乐意支持他们离开去创业，所以我非常喜欢雇佣前创始人或未来的创始人。

我发现最相关的价值主张是，因为我们雇佣的很多AI工程师要么正在关闭他们的公司，要么在考虑创办AI初创公司。最能引起他们共鸣的是，我们通常能提供有趣的问题让他们解决，甚至可能是他们想围绕其建立初创公司的问题，同时还能提供即时的分发渠道。

这就是吸引力所在。你可以进入这家公司，构建金融AI应用程序，并立即将其部署到大约四万名客户中，从财富100强到数万家初创公司。我认为这对创始人很有吸引力。

但接下来的挑战是，确保我们在一个仍然感觉有点像他们自己建立的初创公司，而不是过于企业化的环境中，为他们的成功创造条件。

Alessio： 是的，与其创办自己的公司然后再来找你们，问“我能集成到Brex中获取所有数据吗？”不如直接加入。你们的工程团队是如何构建的？

James： 我们在工程部门大约有300人，整个EPD（工程、产品和设计）总共有350人。我们在很大程度上围绕产品领域进行组织。

Brex不仅提供企业信用卡，还包括企业银行账户、费用管理、差旅和会计。因此，我们实际上拥有全栈式产品领域，每个领域大约有三四十人，涵盖从底层基础设施到Web和移动端体验的所有内容。

这就是我们工程组织的总体结构。自然，我们还有一个专注于基础设施、安全和IT的组织。此外，我们还建立了两个额外的卓越中心，打破了常规的组织设计，因为我们觉得有必要投入更多精力或以不同方式运营。

AI就是其中一个领域。我们有一个大约10人的团队，主要专注于大语言模型 (Large Language Model, LLM) 应用程序。我们希望在这里创造一些区隔。

我们今年夏天思考了在将AI融入产品并产生客户价值的过程中，如果今天成立一家旨在颠覆Brex的公司，它会是什么样子？

然后我们尝试用这个问题的答案在内部组建这个团队。所以它有点游离于主体之外。理想情况下，每个人都能跟上进度并贡献LLM功能，但我们目前以集中的方式将其独立出来。

10 人 AI 核心团队：人才密度与组织文化

Alessio： 这些团队在AI采用方面有什么区别？LLM团队的人是否更多地使用Cursor或Claude Code？还是说你看到了类似的普及程度？

James： 其实在整个工程部门中是非常统一的。有趣的是，我们最大的Cursor用户之一实际上是一位工程经理。

我认为这也体现了我们“在各个层级运营”的核心价值观。我们希望所有的工程经理和领导层都能在管理工作的同时，继续从事他们所管理的实际工作。

让每个人都开始使用代理式编程并不是AI团队的专属过程。

Swyx： 是的。事实上，促成这期播客的原因是因为我看到Pedro发了一条推文后联系了他。我猜这就是Brex的AI中心。

他说：“我在Brex内部创立了一家新公司，致力于构建代理式金融的未来。没有任何废话，只有建设者们在996工作制下构建产品，并将生产级别的代理推向三万个（现在是四万个）财务团队。”

他还附带了一份非常有趣的职位描述。我先跳过这个，直接谈谈Brex加速器在过去18个月内实现了5倍增长，并削减了99%的资金消耗。

我猜这是内部AI自动化和其他措施结合的结果。我想在深入探讨细节之前，先抛出一些引人注目的核心数据。

James： 没错。这就是我们拥有的AI团队。这是一个非常年轻的团队。

团队的构成非常有趣，他们是伴随着这项技术长大的20多岁的AI原生一代，并与在Brex工作了一段时间、能够驾驭现有代码库、深刻理解产品和客户的资深软件工程师搭档。

我们在AI组织中组建了几个紧密合作的小组，通常是三个人。一个人拥有更多的产品和客户背景；一位资深工程师，他知道所有的历史遗留问题；以及一位年轻的AI原生工程师，他们能够用代理完成我们这些“老古董”无法想象的事情。

我认为部分原因是，有时过多的经验或对如何解决问题的了解，实际上会成为从AI优先视角思考问题的障碍。所以我们一直在慢慢壮大这个团队。

就像在种子前期的初创公司一样，你要对人才密度非常谨慎，只有在绝对需要的时候才进行招聘。所以目前只有大约10个人。我想最开始可能只有四五个人。Pedro几个月前发布那条推文时附带的照片里，大家都在。

Swyx： 是的，我们会把照片放出来。那是一张周五凌晨1点20分拍摄的照片。

James： 没错。

Alessio： 是的。

James： 因为我们总是在周五进行演示，这是每个人获得高管评审的时间。大家都在西雅图吗？

那些同事都在西雅图，但他们实际上在地理上是分散的。我们在圣保罗有几位同事，在西雅图也有几位同事。

Alessio： 在Decibel，我们有这个AI卓越中心，基本上就是由跨公司管理这些团队的人组成。

你是如何让其他工程师不感到自己被冷落的？这是我经常听到的一点：“为什么这些人能参与所有酷炫的LLM项目，而我却卡在处理认识你的客户 (Know Your Customer, KYC) 集成之类的工作上？”

你是如何建立这种文化的？

James： 这很有趣，我原以为这会是一个大问题。但我们围绕业务影响力优化工程文化带来了好处，实际上产生了反向效果。

有些人不想开发AI产品，因为目前它没有那么清晰直接的业务影响力，不能直接影响收入。

因此，我们在很大程度上让那些对开发AI产品有强烈愿望的人加入该团队。比如有人因为非常热衷于将他们对策略评估的知识带入AI团队，而从我们的费用管理组织调了过来。

但在很大程度上，我认为每个人都了解他们的工作是如何与大目标对齐的。部门间存在一些友好的竞争。比如负责卡产品的同事，他们推动了我们60%的直接收入，所以他们对此非常满意，并不觉得自己被冷落了。

正如你在我们与First Round合作发布的文章中可能看到的那样，在我们所有的产品和运营团队中，散布着许多较小的LLM应用。

只是一些位于Brex之上的更具创新性的代理层，是在这个独立团队中组建的。所以并不是说其他人没有机会每天构建或使用LLM。

构建智能体平台与多智能体网络架构

Alessio： 也许你可以向大家介绍一下Brex代理平台。我们会在视频中放出图表，里面有LLM网关以及整个模型上下文协议 (Model Context Protocol, MCP) 层。

我们刚好在你之前采访了MCP的创建者David，所以这非常及时。你是如何开始构建它的？架构是怎样的？

James： 在架构方面，我们认为简单即是优雅。从早期开始，我们就有一个LLM网关和一个基本的手动搭建平台。

事实上，在被任命为CTO之前，我曾在ChatGPT发布后领导内部的AI实验室团队。大家都看到了这项新技术，并思考我们要如何利用它。

所以我们在2023年1月做的第一件事就是，尝试搭建一些内部基础设施，使我们能够部署、管理、版本化和评估提示词。此外还要管理数据出口和模型路由，并在LLM网关中拥有非常基本的观察性和成本监控。

这个基础设施目前仍在为许多更小、更精确的LLM应用提供支持。例如，我们建立了一个完全自动化的管道来评估客户申请，以便让他们立即入驻Brex。

这在过去需要人工干预进行承保或KYC。但现在我们拥有一系列代理，尤其是研究代理，它们会去完成人类通常会做的工作。这一切都在这个手动搭建的框架上运行。

对于我们在秋季发布会上宣布的Brex代理，即我们正在构建的位于Brex之上的代理层，它可以体现财务团队通常会雇佣人类来完成的工作流，我们实际上已经开始使用Mastra作为加速开发的主要框架。

我们实际上使用TypeScript构建了所有内容，这是回答“如果今天创办Brex我们会怎么做”这个问题的另一个技术选择。但这并不是我们所有现有后端代码的情况，我们现有的后端代码要么是Kotlin，要么是Elixir。

然后我们混合使用了PG Vector和Pinecone。我们发现自己一直在重新评估技术和框架的选择，因为在代理式编程的时代，代码的半衰期已经显著下降。

对我们和其他任何人来说，尝试各种不同的技术来找出解决问题最符合人体工程学的方法变得非常容易。让我们深入了解一下Mastra吧。

Swyx： 这是一个新选择，很有意思。

James： 我们采用 Mastra 的主要原因是它提供了我们需要的人机工程学体验。Mastra 的使用体验与我们两年半前构建的内部大语言模型 (Large Language Model, LLM) 框架非常相似。而 LangChain 在两三年前就有了，但当我们尝试使用时，感觉并不太适合。它解决的问题并不是我们需要解决的核心部分，比如实现非常简单的可观测性、日志记录和追踪。

LangChain 没做到这些？当时确实没有。现在他们肯定已经修复了。我努力回想，因为这已经是陈年旧事了。我们评估了 LangChain，放弃了它，然后自己构建了框架。后来我们想废弃这个内部框架，因为从长远来看，维护它缺乏杠杆效应。而 Mastra 最终满足了我们正在寻找的功能集。

有趣的是，目前我们在代理层构建的应用大约有一半运行在 Mastra 上，而另一半则仍在运行在另一个内部开发的框架上。这个框架更侧重于代理网络，也就是多代理编排，而不是像 LangGraph 或 Mastra 那样易于使用的严格单轮或工作流模式。

Swyx： 跟我们说说你们的多代理框架吧。设计考量是什么？这是我们第一次听说这个框架吗？

James： 很有趣。我们没有写更多关于这个的原因是它还在不断发展。我们本来打算在秋季发布时配套发一篇博客文章，介绍我们是如何构建这个框架的。但当我们写完文章并准备好所有包时，它已经过时一半了。这种多代理网络实现方法的出现，是在我们试图扩展消费级 Brex 助手时发生的。

如果你考虑 Brex 和我们的客户，我们主要服务两个大类的用户画像。一是财务团队成员，通常是会计师、财务总监或差旅与费用负责人。对于这些人，他们将与更符合其角色的特定代理进行交互。另一大用户群是部署了 Brex 的公司员工。你加入一家新公司，公司使用 Brex，你拿到你的 Brex 卡。

我们对员工的目标是让 Brex 完全隐藏在后台。对 Brex 来说，最好的用户界面和体验就是这张卡。你在软件中除了刷卡之外必须做的每一件事，都是人工智能 (Artificial Intelligence, AI) 为你消除工作量的机会。因此，我们认为解决这个问题的正确方法是为每位员工配备一个执行助手。

作为 Brex 的高管，我有一位助理。她对我很了解，可以访问我的日历和电子邮件，掌握我何时出差以及出差目的等所有背景信息。她基本上能完成我需要在 Brex 中做的所有事情，比如预订差旅或整理费用文件。所以我们想做的是，构建一个连接到相同数据源的助理，看看能否模拟那种行为，这样你与 Brex 的交互界面基本上就是短信和实体卡。

当我们开始构建时，最简单的架构是让一个代理拥有各种工具，并可能做一些检索增强生成来确保它有对话的适当上下文。但我们发现，Brex 上存在广泛的不同产品线，这使得单个代理很难表现出色。它要负责从费用管理到查找和预订差旅，再到回答政策和采购问题的一切。

于是我们开始将问题分解成各种位于编排器后面的子代理。显然，这可以使用 LangGraph 来实现，Mastra 在测试版中也有网络交换机的概念。但我们发现，在为系统构建评估时，我们自己构建框架会更容易。在这个框架中，代理能够与其他代理私信，并进行多轮对话，通过协调来完成任务或目标。

这样做的好处是，你可以拥有你的 Brex 助手。作为员工，你与 Brex 产品之间只有一个单一的联系点。在你的助手背后，如果公司开启了费用管理，就会有相应的代理；如果有报销功能，会有另一个代理；如果有差旅功能，也会有一个专门代理。

我们的设想是，这通常是投影到代理空间的软件封装模式。这也让我们更容易让拥有和了解差旅业务的团队去迭代该功能，而无需担心重构整个系统，或者需要一个团队来负责员工可能采取的所有可能操作。

我仍然认为，将来会有人构建一个出色的框架，我们最终可能会迁移过去，或者最终由我们开源这个框架。但对我们来说，这种方法效果很好，替代了我们在此过程中尝试过的其他几种表现不佳的方法。

比如用各种工具使代理超载，或者尝试上下文切换（当我们发现对话更像关于报销时，就用更多报销上下文更新提示词）。这种方法的表现不如让助手直接与报销代理协作。

把模型上下文协议 (Model Context Protocol, MCP) 作为子代理怎么样？这又是另一种模式。关键在于，让编排器或助手与子代理进行多轮对话非常有价值，而工具调用基本上只是一次远程过程调用。

通常发生的情况是，假设用户联系他们的 Brex 助手说：‘我今晚要带团队出去吃饭，每人可以报销多少钱？’助手随后会联系政策代理。为了回答这个问题，政策代理可能需要知道这是客户活动、团队活动还是你正在出差。

因此，它不能直接回答问题，而是会回复助手说：‘我需要你问这个澄清问题。’然后助手会回到用户那里，提出澄清问题，它们基本上会在多个代理之间进行这种多轮对话，而不是仅仅封装在一次调用和响应的工具调用中。

所有子代理仍然有大量工具，但我认为 MCP 和工具使用是我们所有传统命令式系统的接口，而不是 AI 领域的接口。

Alessio： 是的，这就是我们早些时候讨论的问题，即它是否也应该是代理到代理的调用。或者说，应该有双向交流。

James： 完全正确。这就是关键所在。在我们构建自己的框架之前，我们将其移植到 Mastra 的方法之一，就是将每个子代理都变成一个工具。输入是自然语言，输出也是自然语言。如果需要多轮对话，你基本上只需把完整的对话放进去，然后不断调用作为工具的子代理。

在那种情况下，你会觉得框架的人机工程学在跟你作对。将它构想成一个组织架构图对我们实际上很有帮助。这是一个代理组织架构图，我的助理正在向其他专家发送私信，并进行简短的对话，以支持我这个客户。

Swyx： 这是一次非常棒的深度探讨。感谢你的分享。我觉得你们不害怕打造自己的技术，我认为这是一种竞争优势。我非常喜欢这种文化。

也许我们应该再稍微拓宽一下话题。当然，我觉得我们在某个领域的探讨也有点太深了。我们会把图表放上去，但我也对内部代理事务、运营事务以及一般的平台范围非常感兴趣。所以请随意谈谈你在这些方面的看法。

James： 没问题。在今年年初，作为首席技术官 (Chief Technology Officer, CTO)，我认为向企业阐明我们的 AI 战略是我的职责。每一位董事会成员都会问：‘你们的 AI 战略是什么？’当我们正在做很多事情的时候，我们实际上可以说，他掌握了情况。

Alessio： 是的。

James： 如果我没有答案，那我就有麻烦了。我认为他也指望我，考虑到我在担任 CTO 之前就在负责 AI 组织。这确实如此。

但很大一部分原因是，我们用 LLM 做了很多事情。当时更多的是这些一次性的小功能，比如在这里加入一些建议，或者在那里做一点运营自动化。

把所有这些投资总结成一个口头框架很容易。但如果没有那个框架，我们就无法为投资设定愿景或路线图。所以我们在年初所做的是，把所有正在进行的事情、我们的雄心壮志、所有好主意，以及我们今年试图解决的业务问题都摆到桌面上，看看是否能将它们归类成一个对企业、董事会和我们自己都有意义的框架。

我们得出了三个 AI 战略支柱，我认为这并不是特别新颖，但对我们帮助很大。第一是企业 AI 战略，即我们将如何在几乎每个职能部门的业务中采用和购买 AI 工具，使我们的工作流程提升十倍。

第二是运营 AI 战略，即我们将如何购买和构建解决方案，使我们能够降低作为金融机构的运营成本。因为我觉得这很直观，像我们这样的金融机构面临着很多监管期望，而且运营业务有很高的运营负担。

所以这有点像很多内部用例，比如能够进行欺诈检测、承保、认识你的客户 (Know Your Customer, KYC)，以及能够处理信用卡交易的纠纷自动化。这些类型的运营投资是我们的运营 AI 支柱。

最后一个支柱是产品 AI 支柱，即我们是否要引入新功能，使 Brex 成为我们客户企业 AI 支柱的一部分。我们希望构建功能并提供解决方案，让别人对他们的董事会说：‘我们采用了 Brex，这是我们企业 AI 战略的一部分。’这形成了一个很好的反馈循环。

我们基本上在公司内部进行了一些分工合作。IT 和人力团队的人员基本上把更多精力放在推动企业 AI 上。他们主要负责采购决策，创造一种实验文化，我们关注并激励人们尝试使用 AI 技术来改善他们的个人工作流程。

我参与较多的部分是运营和产品。我们刚刚在这里讨论了产品，比如 Brex 上的代理等。但我认为运营 AI 投资对业务产生了最直接的影响，因为我们运营组织有数百名员工。

这实际上使我们形成了差异化 (Differentiation)，因为我们的客户满意度以及我们的支持和服务质量非常高。这是我们非常自豪的地方。因此，我们试图弄清楚如何自动化其中的很大一部分，并以一种不会降低客户体验的方式使用 LLM。

然后这也解决了一个问题，那就是我们现有的全职员工，他们未来的角色是什么？我们的首席运营官 Camilla 和我共同撰写了 First Round 的文章，她一直在积极推动，帮助运营组织的每位成员开始重新思考他们的角色。他们不再是执行标准作业程序 (Standard Operating Procedure, SOP) 的人，而是将成为构建提示词、构建评估的人，在工作方式上变得更加 AI 原生。

所以我们做了很多工程工作，让欺诈和风险部门等人员能够优化提示词，并在其工作流程中添加更多自动化。

是的，还有一个秘密的第四大支柱，那就是平台。完全正确。正是平台把这一切联系在一起。我觉得非常好的一点是，尽管平台是一个松散的术语，因为它包含了各种各样的技术，正如我所说，我们并没有过于虔诚或教条地要求每个人都必须使用某种特定技术。

我们看到的是，通过提供各种符合人机工程学的 LLM 构建技术选项，它确实让我们更容易在运营 AI 上实现快速飞跃。一旦我们下定决心，我们说，我们希望所有申请 Brex 的初创企业和商业企业的自动化通过率达到 80%。我们希望在 60 秒内做出决定，完全无接触，没有人工干预。

我们能够将其分解，然后在这个平台上快速构建代理和工具。而且很多这些工具与我们的产品 AI 代理使用的工具是一样的。

Swyx： 我对那个 Conductor 很感兴趣。我不知道只需一条配置命令的 Conductor 是否属于那个范畴。我当时想：‘是的，我想要那个。’

James： 这其实是在企业方面。我认为这又回到了我们做出的另一个大胆决定，即我们不会试图在基础模型提供商、智能编码工具，或任何竞争激烈的地方去挑选赢家。

我们不试图挑选单一的解决方案，而是会购买少量不同解决方案的席位，然后让员工能够选择他们想用的任何工具。例如，我们允许员工在 Slack 中使用 Conductor 1 来获取 ChatGPT、Claude 或 Gemini 的许可证。

你基本上可以构建你自己的技术栈，你可以选择你的聊天提供商。作为开发人员，你可以选择 Cursor、Windsurf 或 Codeium。你可以基本上根据自己的偏好打造技术栈，并轻松地在它们之间切换。

这对我们还有一个好处。显然，为了隐私和不用于训练的保证，我们为所有的工具签订了企业协议。但有趣的是，当我们去续签这些合同时，我们基本上可以抵制全面部署的需求。

我们可以说：‘看，使用趋势表明我们的员工正在用他们的脚投票，用他们的预算投票。也许你的工具不像一年前那么受欢迎了。’它会给你一个人们选择什么的仪表板吗？是的，实际上，我们在进入明年预算制定时正在研究这个。非常有趣。

我很想看到哪些工具在使用量上大幅上升，哪些在大幅下降。每三个月的情况都有很大不同，这令人着迷。

我认为我们早期遇到的一个有趣挑战是让人们去尝试这些工具，尝试结合真正的编码工具。在 12 到 18 个月前，要让人们花时间尝试新的工作流程确实有些困难。但现在我们看到的是，即使有一个新模型问世，就像 Codex 刚出来时大家都说它在代码生成上更好但稍微慢一点，我发现愿意尝试新事物的人变少了。因为他们对当前工作流程的人机工程学非常适应。

有些人会说：‘我想坚持使用 Codeium，因为我现在了解它。我已经用它工作了大约九个月，所以我不需要一直切换。’我不觉得有不断尝试新事物的强烈需求，因为我是个 iPhone 用户，我就打算一直用 iPhone，尽管市面上有一些非常性感的 Android 硬件。

Alessio： 你们有没有那种夸张的数据，比如“我们80%的代码都是由人工智能 (Artificial Intelligence, AI) 编写的”？你们在内部是如何衡量这一点的？

James： 其实并没有。我们会统计带有AI共同作者标签的提交数量，并提取相关数据，但我完全不看重这些指标。老实说，我甚至不知道该如何准确计算那个数字。我同意你的看法。

在AI代理编程的探索中，我们目前正处于解决二阶效应的阶段，比如代码质量下降，以及代码审查不够严谨。AI工具的普及率已经很高，现在我们需要弄清楚如何更成熟地使用它们，以确保代码质量和长期可维护性不受影响。

能够更快速地生成大量代码也带来了一些负面影响。比如，随着每个人都在更独立、更快速地工作，团队成员对自己负责的服务中代码的理解会出现偏差。这是我们开始注意到的另一种风险。

例如，在进行事件响应时，工程师们对某项服务的了解已经不如从前了。因为每个人都在快速推进，服务在过去几个月里发生了巨大的变化。

Swyx： 是的，代码库理解和低质量代码是我今年非常关注的主要话题。显然，生成代码变得容易多了，但接下来我们必须进行审查。在某种程度上，你不能用AI来对抗AI。你不能只是在AI生成的代码上扔一个AI审查工具，然后就以为问题解决了。

你仍然需要增加人类的注意力。这也是我一直在推动的一个观点。每个工程师都将负责更多的代码。这就要求他们能够在被临时调派时迅速上手，保持高效并修复漏洞。

如果在值班时遇到了问题，每个人都在努力提高效率，你也理应看到生产力的投资回报率。否则，做这些事情的意义又在哪里呢？

James： 完全正确。有趣的是，回到刚才那一点，你可以叠加AI来解决AI引入的问题，但这就像是一个无休止的链条。

Swyx： 世界上像Code Rabbit和Graphite这样的公司会说，你确实可以这样做。所以这其中存在一些冲突。

James： 我一直在思考工程技术的演变。今年夏天，我花了很多时间思考，我现在觉得自己离预测行业未来渐行渐远了。我实际上休假了一个月，加入我们正在组建的AI团队，与他们一起开发。

我觉得深入理解技术中的问题非常重要。所以我当时每天都在写代码和推送代码，基本上是“996”的工作状态。我经历了许多恍然大悟的瞬间，从觉得“天哪，这将改变一切”，到觉得“天哪，这只是在放大行业里所有的好与坏”，再到觉得“天哪，工程师们要失业了”。

所以我当时觉得自己有很多预测。但到了现在，我只是非常好奇地看着这一现象在我们面前继续演变。昨晚我们举办了一场晚宴，我和一群非常聪明的大学三四年级学生聊了聊。

这些人即将进入职场，他们是在AI代理开发和大语言模型 (Large Language Model, LLM) 的时代成长起来的。我问他们，在构建项目时你们的工作流程是怎样的？如何决定何时使用AI代理，何时手动编写代码？

令我惊讶的是，大家普遍认为大多数人都在使用AI代理来协作编写设计文档，或者探讨解决方案的架构。然后他们可能会让AI生成一份文档或实施计划，但仍然会自己编写大部分代码。

所以，在那个群体中，最普遍的用例是让AI充当“小黄鸭”调试助手和联合架构师。这让我感到非常惊讶，同时也印象深刻。孩子们都没问题，他们仍然想自己亲自写代码，这很有趣。

运营 AI：SOP 驱动的流程自动化与合规审计

Swyx： 是的，我们在OpenAI听到的Z世代的情况是，他们会把所有东西都交给Codex来处理。

Alessio： 我会说我生成的大部分代码也是这样，但我把大量时间花在文档上。奇怪的是，当你在职业生涯早期时，你可能没有关于不同模式的心理模型来指导AI。我觉得存在一种过度依赖，尤其是当你在写设计文档时。

大多数高级工程师会在这方面花更多的时间。比如，根据我们通常在这个表上运行的查询，应该对哪些列建立索引。AI很难知道这些信息。

高级工程师的角色实际上应该更多地偏向于此。他们应该花时间教导AI，然后AI在某种程度上可以去教导初级员工。

James： 是的，归根结底，一切看起来都像是指导和管理。你把任务分解，监督工作，并提供反馈，这基本上就是管理。

Swyx： 只不过AI代理的记忆力依然很差，它们基本上没有记忆。就算到了2075年可能也是如此。到底是怎么回事？

Alessio： 对于偏好设置，你们内部的技术栈是怎样的？在使用代理和MD文件时，会有显式的偏好设置；而隐式的偏好设置则体现在语法检查规则等地方。这些规则自然而然地发挥作用，不需要你刻意告知。

你们是如何构建这种结构的？哦，不仅是平台，我是特指代理编程的偏好设置。接下来我们可以聊聊整个Brex平台。

James： 其实没有什么特别的。我们只是在MD文件中定义了大量的显式规则。在代码检查方面，我们仍然在使用针对不同语言工具链的传统检查器。

我们非常喜欢Greptile，基本上所有的智能代码审查（不仅限于语法检查）都会使用它。这是我们达成共识的唯一解决方案，并且它的表现非常出色。我们是它的超级粉丝，他们构建的产品令人印象深刻。

最让我震撼的是，他们能够保持极高的信噪比。它留下的评论质量非常高。每次我仔细查看它在我的代码差异上留下的所有65条评论时，都觉得非常值得，因为它能发现太多问题。

Alessio： 是的，我发现代码审查功能非常好。我不使用它来生成代码，但审查产品由于某些原因非常出色。我以前做Rails开发时，有一个名为Danger Systems的项目，它有点像语义语法检查器。

现在应该有更多这类工具。生成时的规则是一回事，但我希望在我的持续集成中能有一个工具，不仅能强制执行这些规则，还能指出违规之处。然后我就可以直接将其复制粘贴给AI代理。

James： 当我们开始构建这个新的代理代码库时，正如我们所说，我们在思考：如果今天重新构建一个颠覆性的Brex，我们会怎么做？显然不会选择Kotlin和Elixir作为后端。

所以我们实际上选择了全TypeScript技术栈，基于公共接口进行构建，并努力确保这个代理层与我们核心产品的优缺点保持一定距离。早期我们在GitHub Action中尝试使用Claude Code来进行类似Danger风格的代码审查，效果还不错。

我为它编写了一个提示词，涵盖了不同方面的概念性规则，而不是像传统语法检查器那样死板。在最后，它会留下一大段评论，评估你的代码是否符合新仓库的惯用编码模式。

Swyx： 我想花点时间讨论一下你提到的将业务分为运营代理等方面。比如客户支持、入驻流程、认识你的客户 (Know Your Customer, KYC)、欺诈处理以及逾期账户争议。我想这应该是工作的大头。

有没有什么好的例子可以分享？比如一开始你们打算这样做，但后来通过实际构建或与客户接触，发现必须改用其他方式。人们可以从这种观念的转变中学到很多东西。

James： 我立刻想到的是，起初我们认为使用强化学习 (Reinforcement Learning, RL) 来做信贷决策将是我们最终的方向。也就是决定我们应该给某家企业多少信用额度，通过建立模型来像人类承销商一样进行决策。

我们投入了大量资金，并与一家专门从事该领域的外部公司合作。但事实证明，我们获得的性能还不如构建一个网络研究代理。

在运营类人工智能中，最明显的一点是，你需要能够非常精细地分解问题，并形成人类可以重复遵循的标准作业程序 (Standard Operating Procedure, SOP)。这确保了我们的操作是合规的，并且可以被审计。

这与大语言模型的特点非常契合。我们在运营AI中并没有使用太多复杂的技术，它相对简单，比如只使用几个工具的代理，甚至很多问题仅通过单轮对话生成就能解决。

我们曾尝试过度设计，使用更复杂的技术，但发现实际上解决方案要普通得多，技术上也不需要那么复杂。真正的挑战在于如何清晰地表达和优化提示词，以反映SOP的执行过程，并包含所有未成文的制度知识。这样代理才能妥善取代目前在做这些决策的人员或承包商。

Alessio： 你们是如何决定哪些任务值得花大量时间去构建，而哪些任务可以直接交给这些模型的？因为有些任务非常通用，并不是Brex独有的，你可以假设模型在这方面会做得很好。而有些任务则非常特定于你们的业务。

James： 我们通常优先处理那些适用客户最广、最常见的任务。其中一些任务非常直观，比如研究客户以评估其业务的合法性，以及该业务是否符合我们理想的客户画像以进行入驻。因为有些类型的业务我们在法律上无法提供服务，或者我们认为提供服务存在风险。

这种基础研究和相对简单的问题并非Brex独有。更具体于我们或同行业公司的任务，则是为网络支付卡争议准备文件。如果你对个人卡上的某笔交易提出争议，你需要向发卡机构提供证据。

然后，发卡机构必须整理一份三四页的Word文档提交给卡组织，最终再交给收单行。这完全特定于我们的业务，并且带来了巨大的运营开销。我们决定晚些时候再将其自动化，因为它并不在服务大多数客户的关键路径上。

争议处理成本高昂，但在运营中并不常见，因此优先级较低。我想我们现在正在逐步解决这个问题。今年我们基本上是在审查每一个流程并进行排序。最初促使我们走上这条路的原因是，我们希望扩展理想的客户画像。

我们希望支持更广泛的商业企业，而这些企业往往增长不那么迅速。它们不是高增长的科技初创公司或大型企业，更像是律师事务所或牙科诊所。我们应该能够为这些稳健的企业提供服务和承销，但如果完全依赖人工，高昂的入驻和服务成本会导致投资回报率为负。

这是我们在运营组织中使用AI的第一个用例，它让我们意识到我们可以自动化的远不止这些。Brex要重返中小企业市场了吗？这是个好问题。是的，我们从不放弃这个想法。

我们的理念是，始终向那些我们认为其需求与我们产品非常契合的客户提供服务。我要说的是，对于非常小的企业，我们的产品并不是为他们设计的。我们的产品是为有一定规模的企业打造的，他们通常至少有一两个人，甚至多个人在财务团队中。

所以我们认为这些更偏向于商业板块，也就是中小企业市场。但我们当时的方法有点过于天真了。我们当时只是在追求数量，内部控制不够严格，也没有足够的经验来为这些企业进行承销。

结果，拥有成千上万个投资回报率为负的客户对企业来说成为了巨大的负担，甚至事关生死存亡。因此，我们试图扩大规模，为科技和初创细分市场之外的更多企业提供服务，但要深思熟虑。

目前我们的最低门槛是年收入达到100万美元，或者每月卡交易量在1万美元以上，这只是我们理想客户画像的下限。这显然与你心目中的小企业不同，因为真正的小企业往往比这还要小得多。哦，哇，那真的很小。好吧。是的。

Swyx： 是的。

James： 中型市场（Mid-market）。完全正确。这很有趣，这些细分市场的名称，我们称之为中低端市场。有趣的是，我们所说的企业级（Enterprise），在Salesforce看来可能只是中型市场。因为当使用这些术语时，取决于你自身业务的规模。

Alessio： 所有这些人们构建的自动化，都是在Brex智能体平台上构建的吗？是的，完全正确。

James： 是的，事实上，大部分运营人工智能（Artificial Intelligence, AI）都运行在我们最初的平台上。我之前没提到的一点是，该平台的大部分用户界面和用户体验（UI/UX）都是在Retool中构建的。你可以进入Retool，里面有提示词管理器、工具管理器和邮件管理器。这正是大部分功能的构建基础。

这样做的目标是使其更易于访问和使用。拥有一套更直观的工具带来的次要影响是，它使应用组织的成员能够自行优化提示词。你不需要工程师来优化提示词，甚至不需要他们在新的基础模型发布时进行测试。

当新模型发布时，人们会进入平台并针对新模型运行评估，看看能否获得更好的性能表现。它是否具有不同的延迟或成本特征？

Swyx： 你希望由领域专家或直接使用该工具的人来操作，而不是那些在某种程度上脱离工具的工程师。我想向听众强调，Brex智能体平台的很多功能，基本上是每家公司都应该具备的。

比如问题管理系统，正如我们讨论过的，由领域专家来操作。还有多模型测试、评估和基准测试框架，以及用于自动化工作流的API集成。与Brex外部人工智能产品共享的基于模型上下文协议（Model Context Protocol, MCP）架构，这显然是非常Brex特有的。

有一点让我印象深刻，因为很少有人谈论这个，那就是用于理解Brex业务的知识库。你能详细谈谈吗？

James： 我们在这个领域才刚刚起步。我们面临的一个重大挑战是，大语言模型（Large Language Model, LLM）中内置的世界知识，即GPT-5认为Brex在做什么以及我们的业务如何运作，与我们今天提供的业务或产品的实际运作方式截然不同。

因此，我们必须努力构建产品文档和流程文档语料库，并整理这些信息，为我们各种大语言模型应用提供事实依据。这包括Brex助手，员工会与之交谈。我们不希望它凭空捏造我们没有的功能，或者提供错误信息。

同样，一些运营智能体需要以我们的理想客户画像（ICP）为基础。如果你现在问ChatGPT，Brex服务于哪些类型的企业？它可能无法给出准确的解释。它可能会说我们是为初创公司提供企业用车的公司，这是我们七年前做的。它也可能说我们只服务于企业级客户。这是一个有趣的挑战。

我们一直在努力解决这个问题。下周我将在内部与大家讨论，看看能否更新我们的战略并将其统一。我们有大量供运营和进入市场团队使用的内部产品文档，也有大量面向客户的外部产品文档。我们还有许多更偏向销售推销的进入市场支持材料。

我们还有输入到Sierra中的文档，这是我们用于前线支持的聊天助手。理想情况下，所有这些都可以提取自同一个来源，但目前有些分散。这是我们正在尝试投资的领域。最终，重复劳动是浪费的，必须把这件事做对。

Swyx： 澄清一下，Sierra指的是Brett Taylor的初创公司。是的，完全正确。我原以为你们已经构建了那么多其他智能体。

James： 那是你可以自己构建的。这解决的问题对我们来说不够具有差异化（Differentiation）。Sierra非常有用的一点是，管理Sierra智能体的UI和UX非常易于访问，适合运营和客户体验战略团队。

它更加低代码，更偏向于工作流和有向无环图（DAG）。我们有工程师为它提供执行操作的工具。但在大多数情况下，不必为管理这类事物的人构建UX是很好的。Sierra使用客户的语言，使用客户体验的语言。

他们可以完成我们客户体验副总裁希望看到的所有报告和遥测工作。这只是我们需要构建的东西又少了一件。关于评估，你们是如何构建的？谁来管理？这取决于应用。在运营人工智能方面，这些评估通常内置于平台上，围绕每个提示词或智能体。

大多数用例在上线时，例如我们商业承保智能体的V1版本，或者我们初创公司认识你的客户（Know Your Customer, KYC）智能体的V1版本，是由运营部门的主题专家和工程师共同开发的。他们会共同开发一个初始的评估集。从那里开始，运营部门通常会进行质量保证（QA），无论是针对人类还是大语言模型的决策。

在我们的QA反馈循环中，只要出现错误，通常都会导致编写另一个评估作为回归测试。所以，运营人工智能中的所有这些都管理得非常直接。在产品人工智能方面，情况开始变得更具挑战性，因为多智能体网络很难评估。

我们尝试采用最先进的多轮评估方法。我们会让一个智能体扮演用户，给最终用户智能体设定一个目标。然后让它进行多轮对话，最后使用大语言模型作为裁判来进行所有的评估。我们在技术上做的另一件有趣的事情是，多轮评估有点像集成测试，有时它们测试的内容超出了你想评估的范围。

因此，有时我们也会预先设定对话的初始开场白，也许会手写几个对话轮次。我们将设定评估开始的地方，看看能否隔离某些行为。这仍然是一项正在进行的工作。归根结底，我们需要定期进行人工审核，并查看我们检测到的案例。

当我们要进行总结时，我们会在一段时间后对对话进行反思。我们会对其进行总结，提取细节，例如用户是否似乎实现了他们的目标。当很多情况失败时，我们会手动决定。

实战中的评估体系与 AI 流畅度文化建设

Alessio： 为它写一个评估。所有的评估都应该通过吗？还是你们有一组评估，期望有一天模型会足够好能通过？它是如何随着时间推移而变化的？

James： 这很有趣。我不知道我们是否有期望它有一天足够好能做到的评估。但有一些评估是阻塞性的，因为它们表明出现了不可接受的回归。这些往往是与准确性相关的错误。

还有一些评估更关注语气和连贯性等问题，这些比较主观。我们将这些作为随着时间推移的指标来观察。我们的团队很有趣。我想在明天的周五复盘会上，我们会深入了解团队对评估的看法。

可以说这是我们面临的最大挑战。从今年早些时候像实验室或孵化器一样执行，到现在我们已经发布产品并试图提高严谨性。我们最大的改变在于避免回归，并建立越来越稳健的评估体系。

Alessio： 我曾与一家做用户模拟的名为BRSI的公司合作过。那很有趣。有些事情他们不期望模型去做，客户也不期望模型去做，但他们想以某种方式跟踪模型的饱和度。我觉得大多数公司都知道他们不希望发生什么，但似乎无法准确表达，他们希望未来模型能够做到这一点。虽然今天还做不到，但他们会继续运行这个评估。

James： 这对我来说真的非常有趣。我会把这个想法带回去好好思考。我们已经看到，用户会向助手寻求帮助，以解决我们尚未支持或尚未实现的功能。

这实际上是我们构建测试的机会。有效地编写一个在数周或数月内都会失败，但最终会通过的测试。这是展示助手智能化进程的一种方式。我非常喜欢这个主意。

Swyx： 我想知道你们如何捕捉它凭空捏造我们没有的功能。

James： 这通常是个问题。它会假装能提供帮助。一件非常令人头疼且难以防范的事情是，该助手习惯于与其他能够协助它完成各种任务的智能体交谈。

如果你要求它帮你在一个它认为应该有智能体协作的任务上，它就会产生幻觉。它会说，是的，我会代表你联系财务团队转达这个问题。但它并没有做任何事情。根本没有财务团队，它也没法做到。这经常发生，它会问，需要我询问财务团队吗？但实际上并没有这样的工具。

你们为此设置了护栏吗？是的。就像正则表达式？不，我们没有。我们通过系统提示词纠正了这个问题。但目前我们没有设置太多护栏，只是针对几个可能让我们陷入麻烦的潜在问题。这确实很合理。

Swyx： 当我两年前刚开始思考这些想法时，我会认为护栏可能会更加普遍，尤其是在金融用例中。但令人惊讶的是，事实并非如此。

James： 是的，这也是我们早期在大语言模型网关中构建的一项功能，就像是最后的防线。硬编码的？是的，完全正确。就像正则表达式？是的。

或者就像你在ChatGPT上操作一样，你只会得到一个内联的500错误。它甚至不会告诉你它帮不上忙，就是直接崩溃。我们构建了几个这样的断路器，或者说具备了放置这些断路器的能力。但我认为我们目前没有将它们用于任何实际用途。

Swyx： 最后我想听听你对人工智能流畅度水平的看法。你们有一个包括用户、倡导者、构建者和原住民的框架，包括Camilla在内的每个人都在经历这个过程。

我觉得这很有趣。我认为这是其他人正在考虑采用的模型，但他们担心推出后效果不佳。此外，你们如何保持内部培训课程的最新状态？请给我们详细讲讲。

James： 在努力创建学习路径方面，运营部门实际上甚至比工程部门更超前。他们领先的部分原因是，运营部门必须能够大规模开展培训。培训是运营人员围绕其工作职能建立能力的重要方式。而在工程产品设计（EPD）部门，很多能力是通过实践、积累经验、接受指导和代码审查来获得的。

这非常棒，因为我们创造了一个良好的环境。我们公开探讨了在这个行业中人工智能将带来的转变，它可能会取代许多运营和客户体验（CX）职位。我们对此坦诚相待。同时我们也表示，许多工作职责将会消失，但这并不意味着你的工作也会消失，只是你的工作方式必须改变。

因此，流畅度框架、培训和支持，以及庆祝人们取得进步的积极文化，对于避免恐惧文化非常有帮助。人们不会觉得这是强制性的，或者会被记入绩效评估。

我们建立了非常积极的文化。我们会为在日常工作中对人工智能有特别新颖用法的员工发放即时奖金。在我们每两周一次的公司全体会议上，我们会有一次人工智能聚光灯时刻。很少有EPD部门的人参与，大多数是运营、财务、人力资源部门的同事，展示他们如何在ChatGPT或Glean上构建智能体，或者分享他们发现的有用的新用例。

最终，我们雇佣了一批非常聪明的人，我完全相信这种类型的工作对于任何有动力挑战自我的人来说都是力所能及的。在工程方面，我还想提一件有趣的事。我们将面试环节调整为更倾向于人工智能智能体编程的原生方式。

我们把原有的编程和系统设计问题整合成了一个项目。面试前我们会提供一份简介，面试开始时再补充一些信息。我们期望你使用智能体编程来完成任务，如果不这么做，实际上几乎不可能完成。我们会评估你的知识，观察你的工作方式，评估你是否理解生成的代码，并在过程中对你进行考察。

为了帮助所有现有工程师熟悉智能体编程，面试方案一就绪，我们就要求工程部门的所有人，包括所有经理，都必须参加这个面试。我们在内部重新面试了每个人。我们并没有打分，也没有关于谁通过或失败的数据。

但我们发现，当人们参加面试时，会产生顿悟的时刻。他们会意识到自己可以提升技能，或者想要在这方面做得更好。因此，我们正在尝试各种方法来推动这种文化的发展。

当我回顾今年，因为这是我们真正投入全部精力的一年，看到每个人都在日常工作中倾情投入，我感到非常满意。甚至当我们查看Cursor日志时，我震惊地发现排名第一的用户是基础设施部门的一位工程经理。这对我来说太酷了，这意味着大家已经把这件事铭记在心，并找到了改变工作方式的新途径。

Swyx： 我有一个最后的问题。这跳出了 Brex 的范畴。因为你经常与其他工程领导者交流。我们是否遗漏了现今其他首席技术官（Chief Technology Officer, CTO）最关心的话题？比如他们的首要问题是……

James： 我发现经常和大家讨论的是……我不想回避敏感话题。事实上，我们刚刚聊过一个相关话题，就是如何评估一个人在成为更熟悉人工智能（Artificial Intelligence, AI）的原住民方面的进展。与这个问题密切相关的是，我们还需要那么多人来运营业务吗？会裁员吗？我们如何看待员工人数的增长？初级与高级的比例也是个问题。

是的，初级与高级的比例，就是职级组合。关于这点，我的疑问仍然多于答案。非常有趣的是，我认为代理式开发既能放大所有的优点，也能放大所有的缺点。它放大了马虎、糟糕的架构思维以及对需求的误解。在加速实现好结果的同时，它也加速了坏结果的产生。

有趣的是，当你把这些综合起来看，并没有出现明显的产能提升。情况要复杂得多。所以在考虑明年的员工规划时，我不会觉得因为 AI 给了我们很大的杠杆，我们就不需要那么多人了。在我担任 CTO 期间，我非常自豪的一点是，我们完全没有增加工程团队的人数。

我们做的是显著实现了业务增长，但在执行方式、构建思路、路线图规划以及取舍方面，我们实现了更高的效率。我们能够通过更多的业务线服务多得多的客户，而不需要扩大工程团队。我认为这就是我们将继续走下去的路。我喜欢维持 300 名工程师的规模。我很希望一年后我们仍然只有 300 名工程师，但我们的效率提升了 30%、50%，

UNKNOWN： 甚至 100%。

James： 这也是其他工程领导者常提到的话题。讨论的另一部分是，AI 在多大程度上成了常规绩效优化的替罪羊？如果微软作为一家企业要裁员 4000 人（他们大概有 15 万名员工），那真的是 AI 导致的吗？还是他们只是以此为借口，来回避更艰难的绩效管理决策？

我并不完全确定，但在这个话题上我是多听少说。因为每次我觉得自己有了一个相当坚定的观点时，就会出现一些新的轶事或经验，挑战甚至推翻我的看法。

Swyx： 我的工作就是捕捉这些信号，去寻找那些认为自己有答案的人，并把他们的观点呈现出来。你可能会同意或不同意，但至少这能在你的工作中提供一个可供参考的靶子。

展望与呼吁：多智能体网络与审计智能体实践

James： 确实如此。我认为整个行业在这次转型中还处于早期阶段。所以我很期待一年后再来听这期播客，看看我们哪些说对了，哪些说错了，以及发生了哪些变化，因为每个季度都有太多的改变。

Swyx： 我确实认为 AI 卓越中心（Center of Excellence, COE）是一个非常成熟的模式。内部平台也是一种非常成熟的模式。至于你们提到的熟练度问题，也是大家正在探索的，我觉得你们切中了要害。很高兴听到这些，这就是我的反馈。

Alessio： 是的。你最后还有什么需要呼吁大家去做的吗？比如你希望别人为你构建什么工具？或者你正在试图解决哪些问题，并希望有人能主动联系你提供帮助？

James： 我希望呼吁那些对多智能体网络（Multi-agent Networks）感兴趣的人与我们联系。我觉得在这个领域，我们正在为了服务客户而进行创新。相关的框架、工具和研究都已经具备了。

实际上有很多我们所依赖的有趣论文和资料，但我很希望能看到更多此类成果被编码到整个行业普遍可用的工具中。我的直觉是，试图将大语言模型（Large Language Model, LLM）塑造成确定性的工作流和有向无环图（Directed Acyclic Graph, DAG），有点低估了它们在以更复杂、更流畅的方式进行规划和执行方面的能力。

我只是希望能看到整个行业在这些智能体到智能体的交互上投入更多精力。

Swyx： 好的，那我想稍微深入探讨一下，因为我有一点个人看法。你一直在使用“网络”这个词。这是参考了某篇特定的论文，还是你们自己的术语？

James： 这是我们的术语。我认为这也正是 Mastra 所使用的术语。最初在内部，我们曾称之为智能体运行时（Agent Runtimes），后来就改成了网络。

Swyx： 我想澄清的另一件事是，这主要是完整的智能体与完整的智能体进行对话吗？还是类似于一个编排的老板智能体与子智能体对话？我认为这对一部分构建这些系统的人来说很重要。因为当你提到多智能体时，有时大家对其含义存在分歧。

James： 是的，所以它更像是一棵树，而不是一个图。

Swyx： 当你说网络时，感觉更像是一个图。

James： 是的。

Swyx： 但作为一棵树，它似乎更具方向性。

James： 是存在层级结构的。确实有层级。但也存在一些打破这种层级的情况。比如一个有趣的用例是，为每个员工配备助手的力量，加上运行并扮演财务团队成员角色的智能体，是非常强大的。我们推向市场的一个有趣用例是，我们推出的财务团队智能体之一是审计智能体。

审计智能体在某种程度上体现了许多大型财务团队所做的工作，即寻找浪费、欺诈、滥用或系统性规避政策的模式，而这些在单笔报销中并不明显。你可以通过单笔费用周围的元数据来评估它是否符合政策，但是如果你开始看到一个员工经常进行大量 74 美元的交易，而 75 美元则需要收据呢？

或者如果你发现某个人在工作时间有大量 DoorDash（美国外卖平台）的费用，甚至在提供办公室午餐的日子里也是如此呢？或者你可能会看到一些网约车模式，需要你结合更广泛的背景来考量。所以我们构建了这个审计智能体，它可以吸收你的标准作业程序（Standard Operating Procedure, SOP）。

这是客户的 SOP。没错。然后它基本上会持续寻找潜在的违规行为。它非常狂热，希望将假阴性降到最低。所以它会提出大量潜在的违规行为，然后另一个独立的智能体——审核智能体会运用智慧。

这种智慧在于判断：这是否重要到需要跟进？涉案金额是否够大？这名用户总体上是否表现出较高的合规行为？它会做出判断，看是否值得将该违规行为立案。

一旦立案，通常需要从个人那里获取更多信息。如果是人工操作，会有一个外包团队寻找所有潜在违规，然后财务团队的全职员工查看并决定哪些重要需要跟进。接着他们会把任务交给某人，那个人会在 Slack 上联系该员工询问情况。

所以我们的流程是：审计智能体寻找违规行为，审核智能体决定是否值得立案。案件提交后，会触发一个事件给该员工的 Brex 助手，收集有关业务理由的任何额外信息。或者助手可能已经知道，因为它在与员工的对话历史中，了解到了一些为什么这笔费用看起来不合规的信息。

当财务团队智能体与助手或不同员工沟通时，网络就开始变得有趣了。在后面你还有其他子智能体，所以这时你开始看到更多的图结构。但如果你只看服务员工的部分，它看起来更像是一棵树。非常奇妙。

Swyx： 我没想到你会讲得这么详细。别担心这个。我其实非常高兴我问了这个问题。这令人印象深刻。希望你们在这方面多做些内容分享。

James： 当然。我们对此感到非常兴奋。终于找到了智能体的用武之地，并且技术也足够成熟来实现这个愿景，这感觉很好。这是我们在几年前就曾梦想过的东西。

正如你之前提到的，当时的技术还不到位，我们试图用 GPT-3.5 来实现类似的概念。结果是不行。那时我们还会遇到工具调用的幻觉问题。

Alessio： 太棒了。非常感谢你能加入我们。

James： 我聊得非常开心。祝你们节日快乐。感谢你们的邀请。

Swyx： 谢谢。

总结与行动指南