演讲：驱动未来：构建你的GenAI基础设施栈
TL;DR · AI 摘要
Intuit通过GenOS平台和"固定-灵活-自由"框架支撑8000多名开发者完成3500多个生产实验，实现AI Agent规模化落地，关键实践包括LLM-as-a-judge评估策略和面向Agent的API设计原则。
核心要点
- Intuit采用"固定-灵活-自由"三层框架设计GenOS平台，固定层提供标准化基础设施，灵活层支持业务定制，自由层鼓励创新实验
- LLM-as-a-judge作为核心评估策略，通过大模型自动评估Agent输出质量，解决人工评估的规模化瓶颈
- 构建面向Agent的API需遵循Agent友好设计原则，包括清晰的函数契约、状态管理和错误恢复机制
结构提纲
按章节快速跳转。
Intuit已在产品组合中部署AI Agent，并分享了规模化GenAI开发的架构蓝图。
GenOS（生成式AI操作系统）是Intuit的中央平台，支持8000多名开发者运行3500多个生产实验。
三层框架明确分离：固定层提供稳定基础设施，灵活层支持业务配置，自由层用于实验创新。
理解AI Agent的常见失败模式有助于团队构建更稳健的生产系统。
使用LLM评估Agent输出实现了可扩展的质量评估，无需按比例增加人工审核工作量。
面向Agent的未来API需要明确的函数契约、状态管理和优雅的错误处理机制。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- Building GenAI Infrastructure Stack
- GenOS Platform
- 8000+ developers
- 3500+ production experiments
- Fixed/Flexible/Free framework
- Agent Development
- Failure modes analysis
- LLM-as-a-judge evaluation
- Tool-ready API design
- Organizational Process
- AI transformation at Intuit
- Platform engineering approach
金句 / Highlights
值得收藏与分享的关键句。
GenOS（生成式AI操作系统）是Intuit的平台，帮助8000多名开发者扩展和加速GenAI开发，支持3500多个生产实验。
"固定-灵活-自由"框架提供架构清晰性：固定层用于稳定基础设施，灵活层用于业务配置，自由层用于实验创新。
LLM-as-a-judge评估策略通过使用大模型自动评估Agent输出质量，解决了人工评估的规模化瓶颈。
面向Agent的工具ready API必须包含清晰的函数契约、适当的状态管理和稳健的错误恢复机制。
[InfoQ 首页](https://www.infoq.com/ "InfoQ 首页")[演讲](https://www.infoq.com/presentations "演讲")赋能未来：构建您的 GenAI 基础设施栈
查看演讲
时长：
50:39
/presentations/infrastructure-ai-agent-development/en/slides/Mer-1779194236111.jpg)
摘要
Merrin Kurian 分享了 Intuit AI 转型的架构蓝图和组织流程。她解释了用于在 8,000 名开发者中扩展 GenOS 的“固定、灵活、自由”框架，该框架支持了超过 3,500 个生产实验。她讨论了关键的智能体失败模式、“LLM 即评判者”评估策略，以及如何为未来构建“工具就绪”的 API。
个人简介
Merrin Kurian 是 Intuit 的杰出工程师，负责领导 AI 基础能力，为 Intuit 产品组合中的经典 AI、生成式 AI 和智能体 AI 体验提供支持。她的当前角色正好契合她的两个兴趣领域：AI 和平台工程。她曾领导 QuickBooks 的平台工程工作。
关于会议
软件正在改变世界。QCon 旧金山通过促进知识传播和开发者社区创新来赋能软件开发。QCon 是由从业者驱动的会议，专为技术团队负责人、架构师、工程总监和影响团队创新的项目经理而设计。
INFOQ 活动
/filters:no_upscale()/sponsorship/eventsnotice/3ecacfe1-02d1-4d54-a048-8ee8571a77bb/resources/1EonWebinarMay21-transcript-1774373522295.png)2026 年 5 月 21 日，美国东部时间下午 12 点
#### 设计即实现：多云系统的数据迁移与恢复模式
演讲者：Eric Minick - Harness DevOps 解决方案高级总监，Aaron Newcomb - Harness 高级产品营销经理
#### 重新思考应用安全：为什么编译器级安全改变了架构对话
演讲者：Anton Baranenko - Guardsquare 产品经理
演讲者：Justin Griffin - NeuBird AI 产品负责人
#### 重新思考 AI 分析时代的日志
演讲者：Nicolas Jung - Datadog 日志产品经理
演讲记录
Merrin Kurian：我们今天要探讨的是 Intuit 在产品体验中部署的 AI 智能体。我们将了解 AI 智能体开发的关键方面。然后我们将深入了解 GenOS，这是生成式 AI 操作系统的缩写，是我们帮助扩展和加速所有跨产品 AI 体验的平台。我还将介绍其他两个支柱，即帮助该平台取得成功的人员和流程。我还将涵盖一些方面的内容，即使您今天对 AI 智能体什么都不做，您也应该考虑未来 AI 智能体将成为主流的情况。
让我问问你们，有多少人已经在生产环境中部署了代理？有多少人想要这样做？我希望我不是在对牛弹琴。希望你们能学到一些东西，最后我们可以交流一下。在介绍 Intuit 的 AI 代理之前，我想先介绍一下 Intuit。Intuit 的使命是推动全球繁荣。我们的战略是成为一个 AI 驱动的专家平台，服务于我们的 1 亿消费者、小型企业和中端市场客户。我们帮助他们赚更多的钱，节省时间，消除他们的工作，并帮助他们充满信心地做出财务决策。以下是一些数字，帮助说明我们平台的规模。我只是突出 ML 方面。我们每天生成 600 亿次机器学习预测。我们每个小型企业有大约 625,000 个属性，每个消费者有近 70,000 个属性，我们有权利用这些属性来为客户个性化产品体验。
在业务方面，我们的平台处理近 2 万亿美元的发票。1800 万美国工人通过我们的工资单平台获得报酬。大约 1000 亿美元的退税通过我们的平台处理。Intuit 最大的赌注之一，这被称为"为您服务"的体验。这是我们所有的 AI 和代理都在为产品体验提供动力的地方。再说几个指标，来突出我们取得的进展。我们 QuickBrains 系列 AI 代理的重复参与率达到 80%。回到节省时间这个指标，我们的会计代理每月为客户节省 12 小时。税务产品每年节省 170 万小时，节省数据录入时间。我们的一个代理——支付代理，效率很高。它帮助小型企业更快地收到发票，平均快 5 天。
最后，我们的自助服务有所改善，每年回答 1.1 亿个问题，这比前几年大了一个数量级。这是我们 Intuit 企业套件产品的视图。在顶部，你们看到的是为 QuickBooks 企业客户提供的代理。这是我刚才说的支付代理。它扫描我们企业及其客户的电子邮件。它理解对话，甚至查看附件以帮助创建发票。企业主需要做的就是审核并发送。这就是它帮助企业更快收到款项的方式。
另一个代理，这是一个财务代理。我可以要求代理查看我的数据，与行业同行进行比较。在这种情况下，我从事零售业务。我的净利润率是多少？与同行相比如何？它可以告诉你，你的利润率较低，如图所示，查看你的数据，主要有两个原因：材料成本和劳动力成本。你是一个勤奋的企业主，找到了一些供应商名单。然后你问代理，鉴于这个代理列表，我接下来应该做什么？它可以根据供应商和定价及其在确定利润率时识别的因素推荐下一步行动。在这个具体案例中，它再次建议，考虑这些供应商来降低材料成本。我们还相信，AI 必须与人类智能相结合。专家随时待命，供你进一步咨询。
代理开发：从试点到生产
现在让我们进入代理开发的基础知识。工作流。工作流是预定义的代码路径集合。您有一个预定义的步骤执行顺序。这些非常适合为复杂任务提供可预测性，为明确定义的任务提供一致性。可预测性和一致性是关键。代理是做出自动化决策的地方。模型驱动的决策正在大规模运行。它非常灵活。当您没有预定义的步骤集时，它非常有用。您甚至不知道步骤的数量。代理根据其当前掌握的信息和可用的工具来做出决策。这对于开放性问题非常有用。
在 Intuit，我们发现代理在非结构化数据上效果最好。这是文本、文档、图像、音频、语音等等。再说一遍，权衡是，为了让代理准确运行，您可能希望让代理考虑多个选项，让它更好地思考。这所有都会消耗更多 token，成本更高，而且延迟也会更高。如果您想要代理的超快速响应，同时让它思考和推理，这就是您需要做出的权衡。有些问题，就像我说的那样，无法手动编码，这就是代理非常有帮助的地方。再说一遍，这些定义不是我想出来的。它来自 Anthropic，这是一个非常好的资源，您可以从中了解更多关于代理和工作流的知识。
再说一遍，另一个定义，不是来自我，而是来自 Google。这是代理的四个关键组件。代理显然使用大型语言模型来推理目标，确定执行计划，并最终生成响应。它们可以访问一系列工具。这些工具可以是 API、数据、服务。它们可以执行操作或获取数据。然后是编排组件，这是大脑。它管理状态，有记忆。它完成整个编排工作，在模型和工具之间进行协调，以完成任务。最后，这些托管在运行时上，当在这个示例中，用户发出请求或其他触发时，就会调用它。
在 Intuit，我们一直在与智能体合作。我们的第一代智能体被我称为对话助手。这些是聊天助手。你可以提问，它们会获取一些数据并为你找到答案。我们现在的这代智能体，我称之为"为你代劳"体验。这是智能体实际上可以代表你采取行动的地方。发生了什么变化？在我说发生了什么之前，早期时候，我说的是 2023 年，也就是大约两年半前，我们开始了这段旅程。当时要完成任何事情都非常困难。GPU 短缺，LLM 容量受限，而且我们雄心勃勃，想要一个能回答客户各种问题的智能体。愿景是宏大的。我们有巨大的野心，但技术环境还没有完全就绪。我们构建了一个完整的框架来支持多轮聊天和集中式规划器。
当时的模型上下文窗口最多只有 4000 个 token，所以我们完全依赖 RAG 来取得任何进展。我们构建了自己的框架，正如我所说。它必须支持多轮对话，子智能体会提出后续问题。所有这些都需要与内存协调编排，还需要持续测试和评估的故障排除。这是一场 struggle，但好消息是，在过去两年里，情况已经大幅改善。LLM 能力强大得多，当 LLM 开始支持函数调用时，发生了根本性的转变。现在它们可以进行查询分解、帮助规划，你可以直接使用 LLM 将传入的请求分割成尽可能多的子智能体，而无需做大量工作。
人们一遍又一遍地告诉我，现在可以删除更多代码了，因为这些功能正在融入 LLM API 本身。这是一个例子。它们可以进行结构化输出，这就是现在你能够将多个 LLM 操作链接在一起的方式。它们变得多模态了，所以现在不仅仅是文本。你可以对图像、文档、音频、视频内容进行推理。过去有一种模型尺寸适合所有场景。现在有了一个模型系列。你可以选择 superior reasoning model 来进行规划，然后选择一个 workhorse model 来完成所有工具选择，最后选择一个轻量级、快速、廉价的模型来完成所有自然语言任务，比如摘要。框架确实已经进化了。
过去，我一直在说，我们有 LangChain 0.030 这样的版本。我从未见过有东西用 0.0.x 这样的版本号投入生产，但这就是我们当时拥有的。情况已经改善了很多。有很多选择。你有各种各样的框架，从完全声明式到你想要完全控制图形执行，各种框架都有。这些有助于状态管理、检查点、多智能体系统，所有我之前描述的挑战。这些在今天的框架中很容易解决。智能体通信协议正在标准化，或者至少在智能体到工具、智能体到智能体方面有一些共识。这些 again 是极其难解决的问题。我们必须让所有人聚在一起，为公司内的每一次互动定义标准。
Again，最大的挑战是，是的，你构建了所有这些，你如何持续进行故障排除？你如何持续评估？你如何收集所有 traces，并符合所有安全标准？这是一个超级困难的问题。again，工具已经大幅改善。如果你是今天开始这段旅程，好消息是，你不必像我们过去那样 struggle。
我们的策略一直是随着标准的成熟而采用它们。我们不相信我们能够解决所有问题并永远坚持下去。例如，我们采用的第一个标准是 OpenAI 聊天补全 API。我们看到每个智能体框架都支持那个标准。如果我们的 API 与该标准兼容，那么任何智能体框架自然可供我们的智能体开发者进行实验。直到标准进化，这花费了两年的旅程和我们支持的三个版本的 API。在这类标准进化之前，我们将继续进行实验。有时我想，如果你等六个月，也许事情会解决。你不必这么努力。
然后我们希望保持在技术前沿，并随着事物的发展继续学习。我们始终为 ourselves 和我们的内部客户提供实验性解决方案以供学习。这是我们遵循的做法。对于任何技术选择，我们采用固定的、灵活的、自由的框架。有一些 concerns 对任何 Intuit 工程师来说都是标准化的和固定的。这些是平台 concerns，人们不应该为了开发他们的智能体而一遍又一遍地重复这些。我们提供的灵活选项，它们灵活是有原因的。它们不是无限制的。它们是灵活的，所以我们对哪些是选项有自己的看法。你会有选项。这些将与我们选择的固定技术集兼容。
现在说一个关于，我称它们为传统应用程序的词，我们的应用程序不使用 LLM 与使用 LLM 的应用程序。我的一个队友能够用 AI 生成这张漫画。我非常感激他。我无法这么有创意。我们的传统应用程序有确定性结果。为什么？因为有人手写了所有代码。很容易定义什么是成功，什么是失败。你可以为传统应用程序定义良好的测试和良好的测试标准以及验收标准。它们相对容易调试。当然，会有竞态条件和其他所有问题。与简单的基于 LLM 的应用程序相比，它们感觉像是在走康庄大道。
另一方面就是我们基于 LLM 的应用。你写的代码很少。很多事情都发生在 LLM 内部，你不知道那是什么，你没有写相关代码，也没有影响它。通过/失败的标准变得非常困难和非常主观。事实上，它接受自然语言输入并输出自然语言，换句话说，英语输入，英语输出，这使其极其主观。是的，我问了 LLM 或代理一些问题。它工作了。但这不意味着它会在任何地方都能工作。测试标准现在变得非常模糊。你需要领域专家来覆盖代理应该处理的所有场景。它在不断演变，因为当你开始使用 LLM 时，你不知道 LLM 会做什么。它们是通用模型。因此，它们极难调试，仅仅是因为我们不知道代码在哪里，断点会打在什么地方。
这一点现在已经得到充分研究和文档化。在多代理系统中，有如此多的故障模式。通常，你不会为一个小应用做故障模式分析，但这就是现在的现实。如果你构建一个代理，你必须知道代理可能会服从或违抗任务。它们可能会忘记自己的角色。它们可能会在处理完任务后继续重复步骤。它们可能会忘记过去发生了什么。它们可能会继续对话，而且可能无法再次停止，无法识别。它们可能无法提出澄清问题。它们可能会偏离原始目标。例如，它们可能向子代理隐瞒信息，或者可能忽略来自监督者的输入。各种情况都可能发生。它们可能会提前停止。它们可能不会停止。它们可能会验证。它们可能会错误地验证。同样，这些都有明确的定义和完整的文档记录。现在取决于我们是否理解这些故障模式并加以解决。
会出什么问题？我想预订一张去旧金山的机票。代理给我订了一张去圣迭戈的机票。如果你只测试最终输出，你所知道的就是它失败了。你不知道下一步能做什么。在这种情况下，第一步是找出应该调用哪个工具。一个故障模式或故障点是，它调用了错误的工具。接下来是，它需要调用搜索 API。它以错误的参数或错误的值调用。它需要使用 RAG，但可能要么没有正确使用 RAG，要么提供了错误的上下文。
最后，当它响应时，也许语气不合适。最后，整体正确性也失败了，因为机票订到了圣迭戈。不满意的客户，大量 token 被消耗，资源被浪费。如果你不知道要做什么，代理就会是这个样子。我们该怎么办？并非一切都已经失去。只是现在的软件工程师正在努力成为 AI 开发者。这是所有 AI 科学工作者一直在做的事情——评估。你需要有系统化的结构化评估。有一个简单的技巧。让我们用 LLM 作为评判者。现在，一切都取决于评判者的质量。评判者是否像人类一样知道做出正确的判断？事情没有到此为止。
在编写代理代码之后你需要做的事情，才是真正决定你的代理是成功还是失败的关键。正如我所说的，评估最终响应是不够的。现在你有了一条轨迹。你需要捕获 LLM 做出所有决策的所有轨迹。你需要在每个决策点使用正确的基准真相和正确的评判者进行评估，如果你想超越人工规模来扩展的话。这将成为关键。正如我提到的，如果你不是领域专家，这些基准真相的客观性将是一个巨大的挑战。同样，这些都不是新问题，但这被放大了，因为开发者无法控制很多事情。评估不是固定不变的。
也许你最初几次运行代理时，这种行为没有被观察到，但当你部署到生产环境时，出现了你没有预料到的新兴行为。或者客户需求已经改变。现在你必须不断更新你的评估数据集以匹配预期。你需要有这个回归测试套件，它必须不断更新。这不像我写了某个单元测试，它通过了，因此它将永远通过。这是使用 LLM 时最大的挑战。
GenOS：实现加速和扩展
我们如何在 Intuit 解决其中一些挑战？我们构建了一个名为 GenOS 的平台，同样是生成式 AI 操作系统的缩写。这就是我们如何在 Intuit 帮助加速和扩展 AI 代理开发。关键组件是，我们称之为 AI Workbench，那是我们的开发环境。我们有 GenRuntime、GenUX，那是用户体验方面。当然，我们有大型语言模型。凡是我们无法用技术解决的问题，我们就用正确的流程来补充。我们有责任和治理流程来监督整个事情。为什么要构建 GenOS 应该很清楚了，但我会再说一遍。我们希望团队能够快速行动并构建东西。他们不想被所有这些我们想要抽象到平台中的合规性、数据处理、安全性所困扰。我们也不想让他们各自尝试用 100 种不同的方式去解决它。这有助于提高速度。
当我们于 2023 年开始起步时，甚至直到今天，市面上都没有一个企业级的端到端 AI 平台能够解决 Intuit 所面临的这类业务问题。我们一直在持续评估：现在是否有可用的方案，可以让我们进行混合搭配，或者用外部方案替换某些内部开发的组件？我们一直在进行这种评估，但仍然没有一个端到端系统能够解决所有问题。我们继续投资于 GenOS。我们并非从零开始。很长时间以来，我们一直在 Intuit 投资于平台数据和 AI。我们的目标是统一已经有效的功能，并增强现有能力，例如授权。如何让现有系统适用于 Agent？这就是身份系统所做的增强。我们还希望帮助我们的组织跟上快速发展的技术格局，而不是让 Intuit 的每个人都试图自己去做。
作为中央平台，我们负责这些工作，并提供所有这些功能，以便他们能够依赖我们来帮助他们使用最新的技术。拥有一条非常精简的端到端应用开发大道，确实帮助我们服务了广泛的客户。我们解决了负责任的 AI 开发、私有 LLM 安全访问、开箱即用的安全、安全、隐私、合规防护机制，并通过正确处理数据以及通过工具实现的端到端可观测性分析，实现了大规模快速实验。同样，我们无法解决所有问题，因此需要让平台具有可扩展性。我们为业务或产品团队提供插件机制，让他们能够将领域能力和知识系统接入 GenRuntime，从而使平台保持可扩展性，并随着越来越多的用例接入他们的能力而不断丰富。此外，防护机制、评估指标和所有这些组件都可以基于这些用例团队继续扩展。
我们目前托管着 15 个以上的模型，涵盖 70 多个版本。我们还为特定任务的用例进行微调。我们进行微调的原因是帮助管理准确性、成本和延迟。一个例子是 QuickBooks 交易分类。我们为每个小型企业提供了个性化模型来分类他们的交易。为什么？因为景观业务和房地产业务的交易分类方式不同。即使在同一景观业务中，您的会计人员的处理方式也可能与其他人的会计人员不同。存在巨大的差异。
过去，我们通常会获取所有历史交易并开发个性化模型。随着 LLM 的出现，我们有机会微调特定上下文，因为 LLM 已经了解会计、了解所有企业、了解所有行业类型。我们现在拥有了运营简单性，因为数百万个个性化模型可以被少数几个微调模型所取代。此外，过去我们必须定期获取数百万个数据点来训练这些个性化模型。现在我们只需要少得多的样本，即数千个样本。这就是它在 QuickBooks 中的应用方式。交易可以根据其所属的特定业务进行分类。
这是 GenOS 架构的高层概述。我们将深入探讨具体部分。右上角是 GenUX 组件，它为 AI Agent 需要的所有用户体验元素提供支持。在此下方，您可以看到 GenRuntime，它有自己的组件集。然后在左侧，我们有人工智能工作台（AI Workbench）和 Agent 入门套件（Agent Starter Kit）这些开发者工具。颜色编码的含义是：所有绿色的东西都是我们自主构建的，但它建立在底层灰色的基础上。这表明我们之前已经有很多积累，我们并非从零开始一切。蓝色是产品开发团队开发自己的 Agent 或开发可接入的能力的地方。让我们从人工智能工作台的开发者体验开始。我们将提示管理、评估、优化作为一类体验。这些是自助式的。我们提供所有管道。他们在人工智能工作台的开发者体验中所做的所有工作都保存在注册表中。
对于 RAG，我们同样有一个在后台工作的管道。您只需要引入您的内容。我们支持所有内容的分块、嵌入和索引，并为您提供检索 API。我们有标签。我们有评估框架、评估跟踪、端到端跟踪和防护机制测试。正如我所说，GenUX 由嵌入在产品体验中的 UX 功能组成。我们有所有的小部件。我们还有交互管理，用于捕获所有交互数据，然后可用于评估性能、分析、KPI 管理，以及所有这些。我们有多 Agent 系统和单 Agent 系统。相对而言，多 Agent 系统可以说它们正在使用 A2A 协同工作，这些 Agent 来自 Agent 注册表。同样，工具可以来自工具注册表，通过 MCP 激活。这就是 GenRuntime。我刚才提到了注册表。
您在开发者体验中所做的所有工作都存储在注册表中，在运行时被激活。我们有用例注册表，提供端到端的仪表化和自动化。这正是我们能够提供端到端可观测性和分析的方式。正如我之前提到的，我们有提示词注册表、代理注册表和工具注册表。领域能力团队将其 API 作为工具提供，这些工具会注册到我们的工具注册表中。同样，他们的数据源会注册到我们的数据存储中。他们的知识系统会注册到我们的 RAG 系统中。我们还为所有这些代理提供一定程度的上下文工程支持。我们拥有支持多种模态和多种交互模式的 LLM 服务，所有控制措施和防护机制都内置其中，因此它们与我们的 LLM API 保持一致，不会被绕过。
最后，我们当然还提供评估、监控、追踪和日志支持。所有现有策略都适用，我们会根据需要继续添加。Agent Starter Kit 是我们最新推出的产品。它提供了开发代理的 CI/CD 流程。是的，我们之前具备所有这些独立能力。我们意识到人们很难理解所有这些构建块，然后还要从互联网上阅读各种代理框架并将其整合在一起。我们决定将所有内容打包在一起，并配置好默认设置，指向所有现有功能。我们还提供入门代码、各种模式和参考实现。这样每个人都能非常轻松地开始使用。在我们的第一次全员黑客马拉松中（我们每半年举办一次为期一周的黑客马拉松），Agent Starter Kit 被下载了 900 多次，到周末结束时完成了 100 多个演示。
这就是我们帮助人们快速上手的速度。它还包含调试、追踪、离线评估、注册和集成功能。这就是所有功能被整合在一起的方式。他们无需阅读文档或咨询他人来弄清楚该做什么。这就是我们的 AI Workbench 开发者体验。同样，您可以看到所有需要的工具都在那里。中间有引导步骤。右侧有一些元数据。我们将端到端开发者工具放在一个地方，并提供自助式入职引导和工作流程，这正是加速大规模实验的原因。
我确实想谈谈我们支持的三个主要体验。在 Intuit，我们将提示词视为具有自己生命周期的第一类实体。在很多情况下，我们看到跨职能团队可能使用或不使用 Git。有营销人员编写提示词的第一个版本（非技术人员），然后有科学家想要优化提示词，还有工程师将其集成到应用程序中。对于这些用例，需要跨团队协作。您需要将提示词外部化。我们还想治理和管理这些提示词，并提供适当的可观测性。这就是我们提示词管理解决方案的目的。它还帮助人们进行工程设计、评估和优化。同样，提示词的可移植性仍然是一个挑战。从一个 LLM 迁移到另一个 LLM，您仍然需要重写所有提示词。您仍然需要重新优化所有之前的优化工作。
我们的一些工作是在提示词管理解决方案中完成的。当然，它还提供版本控制、模板和其他支持。我们提供的另一个开箱即用的能力是 RAG，一个用于索引的管道，您可以在其中引入自己的内容。我们提供多种分块策略供您选择。我们提供嵌入模型，并将它们索引到我们的向量存储中。在检索过程中，嵌入模型再次进行嵌入，根据各种算法检索正确的块。然后您可以提供自定义提示词来最终生成所需的响应。我提到这一点是因为这是一个开箱即用的自助服务能力。我们并不期望每个团队都一直手动完成这项工作。
最后是评估。我们有管道帮助人们定义指标、收集数据、计算指标并生成报告，以便他们知道何时是推出的好时机。再说一句，这是以开发者友好或领导者友好的方式，而不是 AI 科学家的方式。这是我们在 Intuit 必须做大量的工作，因为这是再次推出到生产环境的基础。我们还想在生产环境中对 GenAI 应用或代理的性能进行持续监控。
技术之外：人与流程
我谈了很多关于技术层面的内容。每次我展示 GenOS 时，人们都会问需要多少人。我的简单答案是数百人，因为这是由技术之外的许多人和流程推动的。我们获得了从 CTO 开始的领导层支持。CTO 决定整个 Intuit 只有一个 GenOS（除了某些能力之外），这是一件新鲜事。通常，业务部门会开发自己的平台能力。正是这种承诺帮助我们实现了所取得的规模。他们还建立了非常清晰的决策、升级流程和讨论审查论坛。考虑到形势也在快速发展，所有这些都帮助我们非常快速地前进。我们还一直采用我之前谈到的固定、灵活、自由框架。为固定部分提供opinionated的铺平道路是我们能够快速前进的另一种方式。
正如我所说，多个副总裁的部门联合起来，完成了统一的使命。这就是我们能够专注并完成工作的原因。总是有一个核心团队。其他团队不断加入使命，完成各自的任务，然后离开使命。核心团队确保我们保持尽可能敏捷，尽可能快速地转向，因为技术在不断变化，客户需求也在不断演进。正如我所说，我们整合了许多能力，但我们的流程也与这些能力保持一致。流程、技术、框架，所有这些都协调一致。我们使用同一种语言。这是法律、安全、隐私、合规和工程等部门之间的合作，可能还包括其他部门。我们很幸运地获得了贡献。例如，有些编程语言我们没有客户端库，这些都是由团队贡献的。
并不是所有事情都按想象的那样发展。我们一开始制定了非常严格的规则，非常严格的隔离解决方案。当然，我们收到了反馈。我们是一个内部平台，能够获得即时反馈。我们必须为平台提供的内容之外开辟实验渠道。这实际上效果很好。因为作为一个平台，我们无法投资于每一个可能的方向。这些早期采用者发现了一些有趣的东西，去探索，然后把学到的经验反馈回来。然后我们才能对方向做出明智的决定。我们不仅向内看，也向外看。我们时不时地邀请行业领导者或供应商合作伙伴来给我们做技术讲座和工作坊。在可能的情况下，我们也会尝试影响他们的路线图，以便他们能提供我们需要的解决方案。
正如我提到的，公司每半年举办一次黑客松。我们充分利用它，为这些活动制定发布计划，并专门为此创建工作坊。那是我们吸引公司注意力的时候。我们有示例应用、参考实现、最佳实践，所有这些都在黑客松周之前以工作坊形式分享。这就是大多数人想要利用的方式，利用我们在黑客松最后演示日展示和演示的所有能力。当然，我们必须不断地沟通我们正在做的事情。我们充分利用所有可能的形式。我们做播客。我们做短视频，就像TikTok风格的视频。我们尝试过多种方式。
我们并不总是做对。正如我所说，我们一开始提供了非常僵化的API，这并没有帮助，因为人们总是想探索最新最好的东西。我们随着标准的演进和采用而发展。我们可以帮助我们的社区尽可能多地尝试开源的一切。我们的隔离解决方案用于实验并不奏效。我们必须改变我们的思维，定义某些护栏，基于某些参数实现快速实验。我们的审查过程非常全面和僵化。人们经过数周的审查，最终却发现客户不喜欢这个想法。我们退回了。我们定义了审查流程，以符合实验或解决方案开发的生命周期。
如果是早期实验，就不需要经过所有审查。如果你要扩展规模，绝对需要所有审查。正如我说的，这不是Intuit一直都在做的事情。人们总是对集中化平台持怀疑态度。普遍的观念是它会拖慢所有人的脚步。随着时间的推移，我们通过提供人们要求的所有灵活性来交付并赢得了信誉。我们能够将我们大多数固执己见的客户转变为现在期待我们指导的客户。这是一场胜利，在我看来，因为他们不会再偏离正题，左右为难。他们知道我们已经掌握了。这就是我们取得的成就。Intuit大约有8000名开发者，其中1300人正在平台之上构建。目前我们已经推出了3500个生产实验。我们每天处理45万次请求。仅在8月份，就消耗了4万亿以上的token。
如何为智能体的未来做准备
我只想说三件事。如果你刚接触AI领域，关键在于持续实验。我曾问过一个人，什么是真正的AI公司的标志？我预期会是模型的复杂性、深度学习、Transformer。不，他说，是你能多快地实验。是你一直在生产环境中运行的实验数量。你如何实现这一点？这对于刚接触AI的人来说可能是新概念，因为一切都依赖于数据管道，这些管道需要良好连接，不断地将数据从产品往返于评估、离线分析以及你需要重新训练和监控的系统中。再次强调，这是每个从事AI工作的人都知道的，但刚入行的软件工程师可能无法理解。这就是每个人都卡住和挣扎的地方。我只想指出，你的智能体和与客户交互的仪器化越多，评估越多，迭代就越容易。棘手的问题，什么才是优秀的AI工程师？你有在听吗？没有标准答案，但这张幻灯片讲的就是这个。
以前，我们常说"它在我的机器上能运行"。现在我看到的等价情况是"它能回答我的问题"、"它能处理我的数据"。我们开展了大量实验。客户问了一个不同的问题，然后整个系统就崩溃了。我还认为，这也是我们应该与产品经理紧密合作的地方，帮助他们，并要求他们站出来定义明确的验收标准。不要只写产品需求文档。要创建评估指标。告诉我们你真正关心的东西。然后给我们数据来进行评估。这就是我认为这个领域的发展方向。这也是我看到最成功的地方，因为工程师可能无法考虑到所有可能的场景。
正如我所说，领域专家或产品经理代理可以带来工程团队没有覆盖或考虑到的内容。我们非常重视评估，这就是为什么我谈到了我们提供的所有平台能力。我们还提供培训、教程、工作坊和多次重复课程，以便信息能够被记住。当我们认为人们做得不够时，我们也会向领导层寻求帮助以获得支持。我还提到，我们还提供了代理开发生命周期各个阶段的入门代码。他们必须做的正确评估。这是一个旅程，但我们正在提供帮助。希望随着更多代理的产生，我们会做更多类似的事情。同样，我们还通过持续评估和监控管道提供基础设施支持。
即使你今天对代理什么都不做，基础也不会改变。我唯一要说的是要继续投资于基础，因为这是帮助未来代理取得成功的方法。在任何企业中，如果你看一下API、GraphQL，你会有复杂的JSON，多层嵌套。这些都是为人类手动集成而构建的。在当前状态下，大语言模型并不擅长处理这些。我们需要重新思考如何定义我们的API，使它们为代理操作做好准备，而不是为人类集成做好准备。
同样对于数据，我们有数据湖仓，里面有大量数据。我们有多少关于这些数据的元数据，以便我们能够理解这些数据？代理可以理解这些数据，并实际注入正确的上下文到代理中，以便它能够自主运行用户体验。在Intuit工作时，我曾经认为我们是一家金融服务公司，我们所有的数据都是数字。我们能用大语言模型做什么？它们是语言模型。
后来我意识到，我们让人们填写很多表单，而所有这些表单填写都是为了收集信息。如果他们可以直接说话呢？如果他们可以直接上传呢？如果他们可以直接截图呢？多模态原生用户体验将非常有用。所有这些都需要强大的基础设施。如果你不是社交媒体公司，也许你只有非常简单的请求-响应格式API，所有处理可能在200毫秒内完成。大语言模型改变了这一切。现在你有这些小型模型可以提供相当快的响应。推理模型可能需要任何数量的分钟，还有介于两者之间的模型。你的基础设施如何处理？在那个新世界里，什么是失败的客户交互？你如何定义什么是事故？所有这些都需要在基础设施管理方面重新思考。此外，如果你现在有双向WebSockets进行通信，因为你突然想要在任何地方启用语音。那是什么样子？正如我所说，如果代理将来会成为主流，即使你与代理无关，这些也是你可以做的事情来为未来做好准备。
结论
我们的旅程是一场变革。我在Intuit工作了17年。在最初的15年里，我从未见过这样的事。我曾领导过多次向AWS、公共云、事件驱动微服务的转型，但没有什么像这次这样来得如此快速和激烈。这不仅仅是我们的转型。正是因为Intuit公司决定进行转型，我们才能完成这件事。紧密合作、伙伴关系，同时提供统一的平台及其周围的流程。我们始终在构建现成没有的东西，因为我们必须满足监管标准。我们也向外看，看看它们是否满足监管标准。我们总是在不断评估什么能达到我们的标准。
识别固定的、灵活的、免费的，并提出观点，不仅仅是观点，而是对固定的实际可行解决方案。然后你可以为灵活的提供选项。这是我们必须做的事情。我们必须在内部公开构建。领导层的赞助并不意味着我们可以离开一个季度，在我们的筒仓中工作，然后回来展示。不。每个星期我们都要展示我们的设计和决策，供整个公司审查。这就像暴露自己。必须这样做，因为事情发展得很快。这就是我们能够快速获取反馈并快速适应的原因。软件工程师向AI工程师的转型正在各处发生。不仅仅是平台，我还谈到了所有培训和工作坊的帮助。我们希望通过我们的开发者体验，真正降低所有人的入门门槛。
问答
参与者1：你能评论一下真正代理流与工作流的比例吗？真正代理流会更自主，类似于Waymo和自动驾驶汽车。
Merrin Kurian：是的，我们提供的服务范围从纯工作流（注入LLM）到某种程度的智能体。我不想说我们实现了完全无需人工干预的真正智能体体验。我们还没有达到那个水平。目前我们总是有人工在环的步骤。是的，智能体可以在人工批准后执行很多操作，这些是它可以采取的后续步骤。中间会有干预。智能体做出决定后，人工总是可以取消。这就是目前的情况。
Participant 2：我有一个问题，虽然不是直接针对这个主题，而是关于支持这个流程的基础设施。在推进这个过程中，你是否遇到过应用程序传统使用方式与向智能体暴露API之间的阻抗不匹配？智能体更加话痨，可能需要底层提供不同级别的缓存或SLO？
Merrin Kurian：缓存是在达到一定规模时才会发挥作用。很多团队并没有达到那个程度。我们构建了语义缓存，认为这是每个人都需要的东西。花了好长时间才找到实际的应用场景。有些团队来找我，询问我们如何定义失败的客户交互，如何为LLM定义它？我说，我也不知道。这些供应商一直在变化。今天慢的东西以后可能会变快。基于简单的请求-响应延迟来定义SLO是没有意义的，这是我们学到的第一件事。如何将其整合到你现有的监控可观测性系统中？这是一个相当的挑战。同样，这是合作关系，我们必须与那些团队合作。有时候你的仪表盘总是红色的，因为你比其他人都慢。
Participant 2：我的意思是说，当你没有智能体时，你的API可能每秒收到10个请求。现在有了智能体，你突然需要处理每秒100个请求。
Merrin Kurian：这是一个不同的问题。
Participant 2：是的，就是这些扩大现有基础设施规模的事情。
Merrin Kurian：这些智能体并不是突然失控扩张的。不，这些都是计划好的逐步推出。今天你达到5%的推广。你了解所有的依赖关系。你与所有相关团队合作来扩大规模。尽管如此，我们还是有盲点。护栏监控器，它们依赖于很多ML模型。那些也需要扩大规模，而不仅仅是其他所有东西。最终，我们解决了这些问题。这并不是说智能体突然失控。从来没有这种情况。我们将所有智能体部署在现有的服务运行时上。所有那些护栏和保护措施都适用。
Participant 3：你在开头和结尾都稍微提到了AI治理。也许你可以分享两三个关于这方面的经验教训，以及你定义了什么是有效的，什么是无效的。
Merrin Kurian：你是在问AI治理吗？
Participant 3：是的。
Merrin Kurian：你具体想了解什么？
Participant 3：一般来说，你应用了什么？有一些国际标准并不是那么普及？
Merrin Kurian：我们的团队正在积极参与NIST等标准组织。很多这些标准机构也在推动需求。他们也积极贡献。我不知道你是否会相信，我们一直在与安全团队积极合作。我们的安全研究人员实际上是构建护栏的人。他们不是说，不，不要做这个。他们实际上构建护栏来保护系统。他们都以成为行业领导者而感到自豪。我们的安全研究人员，我们的治理人员。这是一个合作关系。有时候他们过于积极。然后我们必须满足业务需求。这是我们需要找到的平衡。
查看更多带文字记录的演讲
录制于：
2026年5月19日