Presentation: Building GenAI Platform at DoorDash

DoorDash 构建 GenAI 平台 - InfoQ

InfoQ 首页 演讲 Building GenAI Platform at DoorDash

AI、机器学习与数据工程

在线 InfoQ AI 安全与隐私工程认证（10月26日）：在受监管环境中部署 AI 的挑战？

DoorDash 构建 GenAI 平台

点赞

新建下拉阅读列表

• 阅读列表

查看演讲

• 垂直方向

• 水平方向

• 全屏

播放速度：

• 1x

• 1.25x

• 1.5x

• 2x

下载

• 演示文稿

50:53

概述

Swaroop Chitlur 和 Sidd Kodwani 分享了 DoorDash 构建内部 GenAI 平台的历程。他们讨论了核心架构决策、从以供应商为中心的设置转向开源权重模型的过渡、LLM 和代理网关的导航，以及为超过 5,000 名内部用户平衡准确性、延迟和成本的方法。

人物介绍

Siddharth Kodwani 是 DoorDash GenAI 平台团队的软件工程师，负责构建加速开发速度并提高生产可靠性的 AI 代理基础设施。Swaroop Chitlur 领导 DoorDash 的生成式 AI 平台团队，负责构建 LLM 推理、微调、评估和 AI 代理的基础设施。

关于会议

QCon AI 是一个由实践者主导的活动，专注于安全扩展这些工作负载所需的工程学科。它提供了直接访问同行组织在生产环境中使用的架构蓝图和失败指标的机会。

INFOQ 活动

• 2026年10月8日，美国东部时间下午12点：当 AI 加速开发时，您的 CI 管道能否跟上？演讲者：Eric Metaj - Datadog 公司软件交付产品营销经理，Rohin Chandra - Datadog 公司 CI/CD 优化产品经理

• 2026年10月29日，美国东部时间下午1点：从 Token 到功能：为 AI 辅助工程构建成本归属架构 演讲者：Martin Reynolds - Harness 公司首席技术官

演讲稿

Swaroop Chitlur：我的名字是 Swaroop，这是 Sidd。我们在 DoorDash 创建了一个名为 GenAI 平台的团队，今天我们将分享我们为打造成功平台所做的所有事情。我们将讨论原则、决策、调整以及我们所说的成功意味着什么。在座有多少人正在工作中部署基于 GenAI 的项目？有多少人处于平台职能中，支持其他团队实现这一目标？希望我们讨论的一些内容能引起大家的共鸣。我们的旅程实际上始于大约 2023 年 4 月。众所周知，2022 年 11 月是 ChatGPT 的突破时刻。几个月后，我们意识到需要开始使用 OpenAI。我被指派签署这份合同，我记得当时非常紧张，我们真的要花这么多钱吗？当然，现在回想起来，这个数字似乎微不足道。

这种感觉非常真实，因为在那一刻，我心想：如果这个项目真的成功了，我们如何在如此庞大的公司中支持它？如何让它变得高效？如何让它具有可问责性？这为我们接下来的规划定下了基调。本次演讲的核心观点非常简单。我们一开始就有了一些基本原则和方向判断。随着行业的发展和新事物的出现，我们也相应地进行了调整。我们之所以能够顺利应对这些变化，正是因为我们始终坚守着这些原则。当然，我们也经历了从模型到工作流再到代理的演变过程。接下来，我们将带您回顾我们的旅程，介绍我们做出的关键决策，并探讨其中一些技术项目的细节。您将看到我们的战略、技术验证和实际成果之间的平衡。希望这些内容能为您带来有价值的启示。

运营模式

当我们谈到原则时，具体指的是什么？在组建这个团队之初，我们获得了一张白纸。接下来该做什么？我也不知道。然后我们开始思考：首先，我们应该决定如何运作？我们需要做出哪些决策？这些原则并不是我们后来才想出来的，它们早已是我们基础架构或核心理念的一部分。要以客户为中心。聚焦于团队和使用场景。不要为了构建而构建产品。构建产品，而非系统。我们的客户是产品工程师。不要创造需要客户自行拼接不同工作流的方案。要尝试思考端到端的工作流。考虑入职流程，考虑支持体系。要像产品团队那样思考，而不仅仅是构建系统。让正确的事情变得简单。如果你只是说要遵循最佳实践，没人会真正去做。你需要将最佳实践融入平台的运作方式中。在整个过程中，我们既要证明对客户的价值，也要证明对利益相关者的价值。

第一章 - 客户发生了变化

说到以客户为中心，当我们开始践行这些原则时，我们意识到自己并不知道该构建什么。我们不清楚未来会遇到什么。那我们为什么不直接与客户沟通，了解他们正在构建什么，看看我们如何能融入其中呢？我们就是从这里开始的。首先我们发现客户发生了变化。我记得当时我们属于一个机器学习平台团队，后来生成式AI平台成为机器学习平台组织下的一个团队。我们过去习惯于与机器学习工程师交流。我记得在一次对话中，我说："我们想尝试一下？用个笔记本就行。"他们问："什么是笔记本？"这时我们突然意识到，我们的受众已经不再是机器学习工程师，而是所有工程师。现在回想起来，这似乎显而易见。请记住，我们讨论的是2023年和2024年发生的事情。

就在那时，我们意识到，必须优先转向API。我们需要以SDK的思维方式进行思考。我们不应以笔记本电脑、GPU或获取计算资源的方式思考，而应更多地以API的思维方式进行思考。在这一过程中，我们做出的另一个决定是专注于业务影响。我们不想再开发另一个聊天机器人。当然，当时还没有编码代理。如果你应用同样的原则，我们明确决定这个团队将专注于业务影响和产品，而不是编码代理或聊天机器人。这是一个我们有意识做出的决定。我们希望加倍关注产品工程师正在构建的用例类型。当我们与他们交流时，我们开始看到一些趋势，开始看到一些广泛的分类：自动化、推荐和个性化。再次强调，这发生在2024年。我们注意到自动化正在降低底线。

而推荐和个性化正在提升收入。我们在整体上对能够提供的价值方向有清晰的认识。我们希望进一步细化这一点。例如，我们提供的价值是什么？就在那时，我们决定我们的独特卖点将是帮助产品团队在准确性、延迟和成本之间进行优化。在那之后我们承担的所有项目中，你都会看到这一主题的出现。什么是证明？为什么我说这是成功的？目前，我们内部平台已上线超过5000名用户。内部每天有45名新用户加入。令人惊讶的是，我没想到的是，40%的用户是非工程师。从法律到销售、运营和战略，所有这些部门的人都在使用API。

第二章 - 采用带来问责制

Siddharth Kodwani：我将更深入地从技术角度探讨我们采取了哪些步骤以及从中学到了什么。正如上一张幻灯片中提到的，最终我们构建的受众群体，我们最初是为机器学习平台和机器学习工程师构建的。然后我们扩展到为所有工程师构建。最终我们达到了一个阶段，即平台的40%用户是非工程师。我们花了些时间才意识到，这种新技术的采用将涉及更多非工程师用户。这不仅是工程师，利益相关者的数量也将增加。我们必须从平台的角度思考，要让所有人能够使用。我们在构建此类解决方案时通常秉持的理念是：我希望为用户的速度构建解决方案，我希望构建可靠的解决方案。当覆盖范围变得广泛时，你也需要建立问责机制。我将更深入地探讨这些场景。

随着我们开始思考这些场景，我们需要一个全公司都能使用的统一平台。当时我们提出了LLM Gateway的概念。从工程角度来看，我们与用户进行了沟通，了解他们面临的问题。目前还处于早期阶段，市场上存在大量不同提供商。有OpenAI模型，随后出现了Claude模型，接着是Gemini模型，再后来是开源模型。现在几乎所有产品团队都在尝试使用这些模型，他们希望快速推进。如果每个团队都必须为每种不同提供商、不同类型的模型单独搭建基础设施，就会变得非常缓慢。从效率角度来看，我们很快意识到需要一种统一的API和SDK方案，由我们来处理底层实现。你只需要一个API即可。如果你想尝试OpenAI模型。

当时新模型的发布频率也非常高。每隔几个月就会出现一个声称性能优于现有模型的新模型。任何进行实验的团队都希望快速尝试这些模型，以评估新开源模型与Anthropic模型或OpenAI模型相比在应用中的表现。通过一个API和一个SDK，只需进行一次修改，就可以尝试新模型。在这一阶段，与用户保持紧密联系非常重要。我们持续与他们沟通，了解他们遇到的问题。很快我们意识到，容量仍然是一个关键问题。即使你希望使用Claude模型或OpenAI模型，也会遇到限速问题。你需要良好的降级方案。团队在构建生产服务时，不能出现OpenAI因配额或资源不足而无法使用的情况。

我们实际上必须深入理解降级方案应该是什么样的，需要什么样的路由策略。我记得曾有一个阶段，我们使用OpenAI端点，但同时在Azure端点设置了降级方案。或者，我们使用Claude模型API端点，同时在Bedrock设置了降级方案，这样服务可以从可靠性角度依赖我们。我们朝着这个方向发展。很快我们意识到，随着使用量的增加，我们需要一种跟踪方式，因为财务部门开始介入。比如，你们用一个API密钥为多个团队服务，我该如何追踪谁在使用什么？我们很快意识到需要引入工作区概念，实现成本归属。我们实际上可以追踪到具体是谁在使用多少资源，并将成本归因到相应部门。这就是我们通过LLM Gateway实现的基本功能。

Swaroop Chitlur：现在成本管理再次成为焦点，我们可以讨论这个问题。我们必须从一开始就考虑这一点。因为如果你向所有人开放并启用所有功能，就必须有人来负责支付费用。

Siddharth Kodwani：谈到基础设施建设，LLM网关位于所有调用者之间，位于所有希望使用基础模型和开源模型的团队之间。这个LLM网关实际上显著提升了大量用户团队和服务的开发速度。我们建立了问责机制，任何人均可查看自身及所在组织的使用情况、预算额度以及所使用的模型类型等信息。我们构建LLM网关所遵循的原则，以及我们选择为整个公司而非特定用户群体建设的决策，带来了巨大价值。最初它帮助了DoorDash，随后随着DoorDash收购了Wolt、Deliveroo、SevenRooms等多家公司，我们能够快速完成这些公司的接入，为它们提供一致的体验，使它们都能享受到我们LLM网关中内置的速度、可靠性和问责机制带来的优势。

Swaroop Chitlur：这一设计带来的积极影响之一是，由于我们拥有这个网关，可以记录每一条请求和响应。现在如果工程师想要回顾自己的性能表现或查看生产环境中的情况，可以直接通过这个界面查看所有日志。每个团队无需自行构建此类系统，中央平台已统一提供该功能。

Siddharth Kodwani：正如我们所说，让正确的事情变得简单。我们希望从中央控制平面的角度实现这一目标，这里可以实现可视化、归因分析和明确的责任归属，同时我们并未牺牲开发速度。这一决策最终证明非常成功。数据本身就能说明问题。如今许多产品团队都能以极短的接入时间在其产品中使用LLM。他们可以重新审视自己的权衡取舍：如果使用不同模型，延迟是多少？相关成本是多少？这些实验可以轻松开展，这些场景也可以轻松调试。这种采用率不仅在DoorDash表现良好，正如我们提到的Wolt、Deliveroo和SevenRooms也是如此。

第三章 - 以供应商为先教会我们该拥有什么

Swaroop Chitlur：我们的一项关键决策是构建LLM网关，这一决策取得了显著成效。另一项决策是采取以供应商为先的策略，这看似有些矛盾，因为我们是平台团队，本应专注于构建能力，但同时我们选择优先对接供应商。这是经过深思熟虑的决定，因为这个领域发展速度极快。我们可能需要说"我们将实现这个功能，但需要6个月时间"，但当然这在Claude Code和Codex出现之前。我们采取以供应商为先的策略，就是为了快速推进、实现功能，我们的速度最终转化为产品团队和客户的速度。这一策略长期有效，但后来开始出现问题。并非所有场景都失效，但有少数特定场景的失败值得讨论。请记住，我们曾提到过准确性、延迟和成本是团队的独特价值所在。

如何帮助团队提高准确性？这就是评估工具（evals）发挥作用的地方。评估工具曾引发争议，因为每个团队都有自己偏好的工作方式。尽管如此，我们还是对评估工具进行了评估并引入了供应商。几个月后，我们意识到这种方法并不理想，因为各团队有非常独特的自定义追踪需求，而该供应商的产品虽然不错，但无法满足我们所需的灵活性。团队还有非常定制化的注释需求。例如，我们现在有这张图片，需要有人能够标注出他们关注的内容。这类人工注释流程对我们来说至关重要，以便我们了解什么是真实情况、预期结果是什么，以及从大语言模型中实际获得了什么价值。团队开始将该供应商当作OTel追踪存储使用，并在其基础上构建自己的工作流程，这至少可以说是次优的。

随后我们意识到，虽然我们走在正确的道路上，但目前的解决方案可能并不合适。最终，我们不得不调整了优先选择供应商的立场，意识到我们需要掌控工作流程的表层。我们的产品工程师到底想做什么？我们掌控这一表层，但如何实现这一目标可以是通过供应商或自主研发。我们调整了策略，表示如果供应商方案有效，就扩大使用；如果无效，就吸取经验教训，然后自主研发更合适的解决方案。

在模型方面，我们同样优先选择了供应商。让我们使用OpenAI、Anthropic和Gemini模型。员工们开始变得高效，学会了如何进行提示工程。他们能够实现规模化应用。在DoorDash的规模下，随着业务发展，成本问题最终成为关键挑战。其他一些问题也开始显现。例如，模型的弃用周期问题。你们中有多少人知道Gemini模型的生命周期只有1年？一年后，模型会被关闭，这适用于所有新模型。在一年期满后，无论新模型是否满足业务需求，都必须切换到更新的模型。如果我是单一产品团队，专注于自己的产品，我可能可以接受这一点。但作为平台团队，我必须考虑数百种使用场景，并思考如何在不提供明确商业利益论证的情况下，推动数百个团队迁移至最新模型。

类似地，配额限制问题。在我们当前的规模和内部使用率下，我们根本无法从这些供应商那里获得足够的带宽。随着规模扩大，成本会急剧上升。回到生成式AI网关或大语言模型网关，我们始终牢记可移植性原则。你能够轻松切换模型。现在，这不再是锦上添花的功能，而是成为必不可少的核心需求。

第四章 - 可移植性成为现实

我们意识到，必须找到一种削减成本的方法。我们长期押注的一个方向是：通过微调和使用开源权重模型，重新将服务部署内部化。作为机器学习平台团队，我们热爱构建。这一直是我们的长期战略。随后我们发现成本问题日益突出，于是果断转向了开源权重模型这一长期押注。由于我们拥有网关，产品工程师无需进行重大改动，只需调整一个配置即可使用新模型。当然，要真正实现这一点仍需要大量工作。最终我们优先选择了开源权重模型，评估了供应商和选项后，最终选择了Modal——一个以Python为核心的GPU云平台。我们通过LLM网关进行部署，现在正在托管自己的模型。这套基础设施的优势在于，我们可以押注于开源引擎，如vLLM、SGLang用于服务，以及Hugging Face TRL、Unsloth或Axolotl等开源库用于微调。

我们从去年下半年开始投入这一方向。今年，随着基础架构的建立，采用率呈指数级增长，因为现在的模型表现非常出色。例如，Qwen、GLM、Kimi、DeepSeek等模型开箱即用的效果已经非常优秀。去年我很难想象会有这样的进展。现在团队能够从前沿的专有模型切换到Qwen3或Qwen3 Embeddings，实际看到准确率提升，成本下降了20倍。团队纷纷反馈：这太棒了，我们应该继续推进，因为在这个规模下，成本问题变得尤为关键。最终，仅在上半年部署的几个用例中，我们就实现了显著的降本增效，已实现年化数百万美元的节省。供应商主导的模式有所弱化，但可移植性优势得以保持。

第5章 - 代理再次改变了基础

Siddharth Kodwani：代理，我们怎能不谈？我认为现在正是时候。代理的探索也始于2024年，当时我们正从LLM网关的角度解决大量用户问题。我们很快意识到，通过特定工具调用和特定框架，可以构建出远超单纯LLM调用的更多应用场景。我将简要说明背景、我们的初始方向以及后续的演进过程。稍微补充一点背景：作为平台团队，有时不率先成为标杆反而是件好事。我们需要从平台视角明确我们正在构建的内容，因为我们要真正理解用户实际在做什么，尤其是在生成式AI领域，我们始终与产品团队协作，了解阻碍因素，并找到介入帮助的切入点。

有时你只需后退一步，让他们自行发展，才能真正看清平台为你带来的机会。代理（Agents）在2024年初出现时，团队只是在进行初步尝试和构建。我认为关键转折点发生在MCP（多云平台）出现之后，那时大量人员开始参与进来。他们表示：“我们想构建这个系统，让我们连接一些MCP，看看能从这里实现什么。” 2025年，我们已有25多个代理项目，每台笔记本电脑都运行着代理，比如Claude Code、Codex、Cursor等。我们最初从MCP入手，拥有第三方MCP服务器，并开始内部构建MCP服务器。我们从LLM网关的经验中吸取了所有教训，再次聚焦于用户速度、可靠性和责任性。我们专注于MCP，但很快显而易见的是，如果你在构建代理，仅仅连接MCP是不够的，因为MCP更像是将数据呈现给代理的接口层。

构建代理远不止连接MCP那么简单。从代理的角度来看，我们想解锁什么样的体验？我们开始从这个角度思考。我们意识到平台用户包括：一些团队在构建代理，一些团队在构建MCP服务器，还有希望使用MCP服务器或我们网关上任何其他资源的用户。此外还有以服务形式运行的代理，以及代表用户运行的代理。许多不同的模式逐渐浮现。我们很快意识到，必须从MCP网关进化到代理网关。我将简要谈谈代理网关。目前代理包括Claude、Codex、Cursor，现在我们内部运行的代理数量也大幅增加。我们最初从MCP工具入手，例如你可以连接Slack、GitHub、Jira的内部MCP服务器。如今，代理网关上运行或已接入的MCP服务器已超过50个。我们从LLM网关的经验中吸取教训，构建了非常强大的底层架构，让用户专注于构建代理和MCP，而我们则想办法以更有意义的方式将它们暴露出来。

Swaroop Chitlur：你不想让每个MCP作者都必须考虑授权问题。

Siddharth Kodwani：我想谈谈我们开始开发的一些核心组件。我们与正在构建MCP服务器的团队沟通时，他们表示：“我想为使用我MCP服务器的用户进行身份验证，我需要有适当的可见性，因为可能会暴露一些不应被无权限用户访问的数据。” 我们制定了授权策略，使MCP服务器能够轻松接入代理网关。你可以选择授权策略，为用户启用所需的工具级访问权限。我们将为你进行用户身份验证，也将为你验证希望使用你工具的服务。我们建立了完善的可观测性体系，不仅对我们自己，也对所有接入我们平台的用户，让他们无需担心可观测性问题。

我们还启用了部分用户提出的功能需求，例如我的工具对写操作非常敏感，我希望设置特定的访问权限策略。我们将对用户进行限速处理。我们构建了非常强大的基础设施，使得任何想要暴露工具的人都能放心地联系到我们。他们应该能够查看现有工具的情况。我们拥有一个非常完善的自助注册中心，您可以查询并了解现有工具和缺失的工具。如果您是代理，可以与我们沟通。我们很快意识到代理之间也需要相互沟通。我们在协议支持上保持中立，不仅支持MCP协议，还将启用代理体验功能。我们开始从这个角度进行思考。我们在代理网关上启用了多种协议，您可以利用这些协议。

Swaroop Chitlur：您能谈谈AG-UI吗？

Siddharth Kodwani：要实现这一点，我们再次遵循了从过去经验中学到的原则，尽管基础技术发生了变化，但我们很快意识到对于LLM应用或服务来说，生成式AI领域大多以Python为主。我们在公司内部倡导Python，以获得强大的基础设施支持，并将其作为与其它语言支持同等重要的核心公民。这帮助我们实现了目标，因为所有允许用户快速构建代理并开始实验的代理框架都优先使用Python。我们为用户构建的是产品，而不仅仅是系统。如果您正在构建代理，如果您正在构建MCP服务器，请不必担心身份验证、授权、限速以及与不同界面（如Claude、ChatGPT）的集成，我们从用户角度处理了所有这些问题，这样您就可以专注于构建代理和创建代理体验。

从安全性和安全性的角度来看，身份验证成为必须非常谨慎解决的问题。如何代表您启用代理，以及您授予该代理哪些权限来代表您工作？如果您在笔记本电脑上使用Claude，您可以授予更多权限，因为您拥有更多控制权，但内部我们有更多代理可以直接调用以触发特定操作，但您不希望这些代理拥有与Claude Code相同的全部访问权限。解决代理身份和工具访问问题成为我们为用户解决的一个更大问题。

我们采取了一个有控制的赌注，一个我们知道这不仅仅是关于MCPs的赌注。我们希望朝着能够实现代理体验的方向发展，而不仅仅是为代理提供数据工具访问权限。从第一天起我们就保持协议无关性。我们最初重点放在MCP上，因为那里有很多用例。随着团队开始构建，代理们很快意识到他们可以利用我们构建的基础设施。他们希望支持不同的协议。我们成功整合了AG-UI，目前正在开发A2A。我们预计未来会有更多代理协议，我们可以轻松地将其纳入并为用户提供体验。由于我们采取的这些赌注，我们很快实现了每日30万次工具调用。我们成功引入了AG-UI等新协议，通过我们构建的网关，代理可以直接在UI上进行流式传输。我们对Python的推广使用户能够快速构建代理。这些结果让我们感到非常惊喜，同时也令人印象深刻。

成绩单

Swaroop Chitlur：我们讨论了原则、一些赌注和调整，以及取得的成功。这些数字是我们成功的故事，加上我们实现的所有用例，比如5000名用户、节省的成本以及我们内部的采用率。希望这些数字能说明我们所说的成功是什么。这是我们自己的评分表。这些是我们采取的赌注。产品影响的首次赌注成功实施。Sudeep团队交付的许多内容都是基于平台构建的。API优先的赌注成功实施。这使得人们可以选择他们需要的部分。他们不会被平台锁定，因此我们现在收到的投诉少得多。你可以选择你需要的部分。LLM网关在帮助团队提高速度方面非常成功。可移植性是我们的一项赌注，在开源权重模型的情况下取得了成功。以供应商优先，我们不得不稍微软化立场。我们仍然认为这是正确的第一步，但我们不再认为这是必须的。我们只在必要时进行构建。出现了我们最初没有考虑的新事物，比如评估、代理和身份。

未来方向

我们接下来的计划是什么？我们这样看待它。从自上而下的角度来看，我们仍然专注于让代理运行业务的部分。我知道很多讨论都集中在像Claude Code和Codex这样的编码代理上。作为平台团队，我们希望启用能够运行业务的工具，这需要不同的思维方式和关注点。也许在未来的QCon上，我们会讨论我们如何实现智能代理商业。我们不知道。这是一个赌注。我不知道它是否能成功，或者世界是否已经准备好接受智能代理商业。我们拭目以待。这是自上而下的观点。自下而上的观点是，我们知道我们有哪些产品。我们内部有客户在积极使用它们。他们会告诉我们，存在这个缺口，或者存在这个漏洞，或者能否添加这个功能？我们将继续扩展这些方面。这些都是方向性赌注，但我们继续关注信号。行业正在发生什么？产品工程师在构建什么？他们遇到了哪些阻碍？他们告诉我们什么？他们没有告诉我们什么？我们从那里开始。

关键学习点

我们希望给你留下三个要点或经验教训。第一，尽早制定策略。这有助于明确你的重点和决策方向。从某种意义上说，要经常回顾你的决策，因为这样你才能清楚地知道什么在起作用，什么没有起作用，从而有意识地调整方向并继续前进。现在最糟糕的事情就是做出一个决定后不再重新评估它。我们推荐的第二件事是围绕客户构建产品。如今构建产品变得非常容易。每个人都有自己的Claude Code和Codex随时待命。但并非总是显而易见到底需要什么。所有事情的本质依然如故。请与你的客户交流。第三，掌握公司契合的表面。认证是一个永恒的话题。成本是一个永恒的话题。准确性是一个永恒的话题。可观测性是一个永恒的话题。治理、开发者体验和速度。我们拥有这些方面，但如何提供它们取决于解决方案的细节。无论是通过供应商还是内部构建，这些都属于后续考虑的范畴，但这些表面我们始终拥有。

问答环节

参与者1：我有关于LLM网关的问题。如果你们仍在使用，是否在LLM网关本身实现了LLM的安全性和安全性？如果是，是如何实现的？

Siddharth Kodwani：当你说安全和安全性时，你是指防护措施吗？

参与者1：是的，比如提示注入、输出验证、幻觉控制等。

Siddharth Kodwani：是的。我认为我们无法在LLM网关层面控制幻觉，但我们确实有防护措施的概念，你可以来定义这些防护措施。你可以定义应该使用的提示，包括系统提示等。从安全角度来看，产品团队需要确保我们为你提供所有必要的工具，以便你能够观察你所进行的LLM调用的情况。你可以制定相关政策，例如启用特定类型的防护措施。LLM网关为你提供了了解情况和进一步调试的界面区域。我们不会强制规定用户视角下必须如何操作，这些责任交给构建解决方案的产品团队。

Swaroop Chitlur：补充一下，LLM网关是添加前置钩子和后置钩子的正确位置。例如，前置钩子用于执行PII脱敏，这是在中心位置进行处理的，我们会为你运行。后置钩子可能涉及确保LLM不会贬低你的客户或推荐竞争对手。这些功能正是在此处实现的。对于幻觉问题，我们认为这更多属于评估环节的范畴。我们有LLM作为裁判和确定性裁判作为解决方案。总体而言，我们专注于防护措施的这两个方面。目前，客户需要主动选择启用这些功能，我们不会强制执行。这更多属于公司政策层面的考量。

参与者2：我的问题涉及运行时或计算方面，是否考虑过支持这些功能时的挑战？我们目前面临的一个挑战是尝试在代理会话和用户之间维持稳定的WebSocket连接，如果代理运行在Lambda或其他类似环境中，这种连接会变得非常复杂，因为需要进行上下扩展。我想知道这是否被考虑过？最终你们的代理运行时选择了什么方案？

Swaroop Chitlur：你们如何处理流式传输和扩展？

参与者2：是的。流媒体处理会影响您的代理运行时。如果用户第一次对话的实例或回答第一个问题的实例与捕捉第二个问题的实例不一致，那么您就无法保持流媒体连接。我想知道，这是否是您考虑过的问题，或者您是否遇到过这种情况？

Siddharth Kodwani：至少在我们公司，这是一个正在发展的领域。从协议角度来看，我们的代理网关目前是无状态的。我们允许正在构建代理的用户团队将我们视为无状态。如果您想与某个特定工具进行交互，他们需要请求特定的会话ID，由他们自行处理。总体而言，在运行时，这些是需要面对的挑战。正如我们之前提到的，我们与产品团队合作，正在观察一个趋势，即需要研究代理编排如何运作，以及实现这一目标所需的运行时环境。目前我们还没有所有答案。我们正在深入研究这个问题。我们正在与用户沟通，了解在哪些场景下您希望代理能够长时间运行？当Pod实例崩溃时会发生什么？我们如何重新建立连接？所有这些问题目前仍未解决。

参与者2：会话管理、对话历史记录的所有权仍然属于产品团队。

Swaroop Chitlur：是的。

参与者3：在构建代理网关的身份和访问管理时，您有哪些关键的学习经验或挑战？传统的人类身份或工作负载身份在构建代理身份时有哪些不足？

Siddharth Kodwani：我先谈谈学习经验部分。我们很快意识到的一个重要学习经验是，我们正在为用户快速构建许多新功能以访问工具。有很多团队在构建代理，但可能并未从用户角度全面考虑安全性。假设我是正在构建代理的团队，我希望代理网关来判断用户是否有权限访问某个工具。这类似于三方系统，其中某人构建了MCP服务器，它可以具有某些写入级别的访问权限，也可以具有某些保密的读取级别访问权限。当这些MCP服务器被引入时，我们首先会告诉他们，您需要声明哪些用户有权访问哪些资源。假设现在这个问题已经解决。现在，用户想要访问某个资源。

归根结底，我们为代理构建团队简化的是：您只需告诉我用户的标识，我会判断该代理操作是否可以在特定工具上执行。关键的学习经验是，让我们帮助代理更轻松地处理用户是否可以访问该工具，以及该工具可能返回给用户的任何资源的复杂性。关键学习经验是，让代理更轻松地处理这些复杂性。因此，我们投入了很多时间思考如何识别代理。我们开始思考的方向是：我们有一个代理网关控制平面，用户可以在这里查看今天可用的所有代理以及这些工具，因此存在交叉组合的情况，例如对于某个MCP服务器，这个工具无法访问这些特定工具，但另一个工具可以。

我们启用了这一功能，并将这一权限交还给用户，让他们也能做出选择。对此有两种思考方式。MCP服务器会决定他们所拥有的工具需要采用何种授权策略。然后，用户会决定哪些代理可以访问他们已有权限访问的工具。这部分内容位于代理网关的控制平面中。

参与者4：你们拥有代理网关这一功能非常酷。我想知道你们如何看待系统其他方面的平台化，比如，假设在持久执行方面，是否使用了某种工作流编排器，并针对LLM或代理使用场景进行演进，以及从评估视角来看。我也很好奇，如果40%的用户是非技术人员或非工程师，你们如何看待教育过程，以及如何向他们介绍何时使用评估、何时使用技能等概念。

第一部分是代理构建过程中所有其他要素的平台化。具体来说，包括评估套件、评估的CI/CD流程、工作流编排、上下文存储等，都需要考虑这些方面。

Swaroop Chitlur：关于评估，我们正在构建自己的评估平台。我们团队的Nachiket负责领导这项工作。评估是今天没有提到的另一个重要部分。这部分我们专注于准确性方面，帮助团队构建基于代码的确定性判断器、LLM作为判断器，并完成整个产品迭代的闭环。这部分内容已经在我们的评估平台中实现平台化。关于教育方面，我需要说明，这仍然是一个具有挑战性的领域。我们有几种应对方式。其中一种是，我们有一个开发者平台组织，与之合作并协同工作。例如，人们需要提升对如何使用我们所有MCP工具的理解，或者如何连接Slack等系统。

我们的开发者平台团队有一个代理技能市场。大多数用户只需安装该插件，即可直接使用，例如Claude Code、Codex或Cursor等工具会自动知道如何处理我们所有的其他系统。只需安装该插件，然后说“搜索这些日志”，它就知道该怎么做。这是教育的一部分。另一部分是我们有一个活跃的Slack频道，人们可以在其中提问，希望未来有一天也能有代理在那里回答问题。这些是我们关注的组合措施。我们在入职培训和文档方面投入了大量资源。但事实是，并非所有人都会阅读这些文档。我们采用多种方式来应对。

Siddharth Kodwani：我们在确定合适的技能方面投入了大量时间，因为最终很多非技术人员也在使用这些代理。如果你拥有正确的仓库、正确的技能，并将其放置在合适的位置，代理就能快速判断出需要执行的操作。你不需要理解所有细节。在大多数情况下，只要在合适的位置拥有正确的技能，你的代理就能自行判断。这就是我们与代理技能团队合作的地方。例如，如果代理控制平面是今天调用任何工具或代理的正确方式，那么如何让任何人都能轻松完成？核心思想是确保在合适的位置拥有正确的技能，让代理为你处理这些细节。

Swaroop Chitlur：最终，我们必须考虑三个受众群体。第一类是用户，包括人类用户、平台上的用户、代表人类用户的代理以及作为服务的代理。我们将这些视为三个受众群体，并在构建系统时为所有三类群体进行设计。

参与者5：关于开源权重模型，你们在成本旅程的哪个阶段开始考虑脱离OpenAI或Anthropic，转向自托管和小型模型？

Swaroop Chitlur：对于大多数团队，我们始终建议他们从前沿专有模型入手。原因之一是它们更容易上手，网上有更多可用信息，而且如果不知道如何继续，还可以找到可以交流的人。我认为关键点在于准确率、延迟和成本。我认为在准确率方面，这些前沿商业模型仍然是最佳选择。问题通常集中在延迟或成本上。如果团队向我们表示，他们有非常具体的延迟要求，该怎么办？产品是否运行良好？我们是否已经实现了产品市场契合度，无论是自动化还是对外服务，但成本是一个顾虑。我认为这时我们会引导对话，询问他们是否尝试过开源权重模型？因为你可以通过缩小模型规模，考虑蒸馏或其他微调技术来实现所需延迟，或者从成本角度转向更小的模型。并不是所有场景都需要使用最大的模型。大多数团队只有在我们引导他们了解流程后才会意识到这一点。我认为这就是我们通常鼓励人们开始关注开源权重模型的两个场景。除非团队对领域非常熟悉，否则我们不会建议所有团队都从这里开始。

参与者6：能否更详细地解释一下你们的评估工作流程？我看到你们有一个平台，这非常棒。根据我们的经验，当创建评估变得容易时，也很容易产生噪声。要获取有效信号非常困难。你们如何帮助产品团队正确使用评估，以获取信号而非噪声？具体来说，我对CI集成感兴趣，你们是否将其与CI集成？是否有相关框架？

Swaroop Chitlur：如何让产品团队有效使用评估？我们目前仍处于早期阶段，这并不是一个已解决的问题。在帮助团队入门时，我认为第一个障碍是追踪。我们尝试让这个过程变得简单。一些相关工作包括提供代理模板。例如，如果团队想要入门，如何构建一个代理？我们有Google ADK，还有如何将追踪集成到我们OTel存储中的示例。我们首先让追踪变得容易。一旦这个障碍被克服，就相当于完成了一半的战斗。因为现在你可以查看这些追踪数据，了解时间消耗在何处。人们会逐渐理解系统实际运行方式，代理实际运行方式，瓶颈是LLM还是工具？

瓶颈是工具的结果吗？是网络搜索速度慢吗？还是工具本身运行缓慢？一旦你能够可视化这个可观测性树的结构，他们就会更清楚当前发生了什么。这时你会开始向他们提问，比如：你们关注哪些产品指标？你无法在所有方面都进行优化，必须有所取舍。作为产品，你最关心的是哪两三个事情？然后，如何将这些目标转化为实际的评估或评估器？我们会引导他们完成这个过程。此时这仍需要一定的人工协助，但希望随着时间推移，我们能积累足够的经验，最终形成可复用的流程或实现自助服务。当你能够将目标转化为评估器后，有时可能需要使用LLM-as-a-judge。有时只需编写一些代码即可。当你开始构建这些评估器时，它们会输出相应的指标。

现在你需要可视化这些指标。为此你需要自定义仪表板。我们已经支持产品团队自行编写代码构建专属的用户界面，我们会在平台上托管这些界面。包括标注工作流程。例如，当代理在餐厅推荐菜品时，如何判断这是否是一个好的推荐？过去你可能需要将整个菜单导出到Google表格中，然后需要人工查看每个单元格并判断推荐是否合理。这是我们之前遇到的瓶颈之一，即无法有效可视化这些信息。我们现已支持人工标注界面和自定义标注界面。这会以完整的菜单形式呈现，你可以看到图片、标签，并通过自定义的界面回答你设定的标注问题。

我们必须循序渐进，先引导他们开始追踪，明确他们的产品指标，为这些指标设置评估，设置人工标注流程，搭建仪表板。当他们能够完整经历这个过程后，所有环节就会逐渐清晰，你就能知道如何进行产品迭代。你将逐步通过准确性的提升不断优化。

更多带文字稿的演讲

录制时间：

2026年10月3日

演讲者：

• Siddharth Kodwani

• Swaroop Chitlur

#### 相关赞助商

#### 相关赞助

• 2026年10月8日 12:00 EDT 当AI加速开发时，你的CI流水线能跟上吗？演讲者：Eric Metaj - Datadog软件交付产品经理，Rohin Chandra - Datadog CI/CD优化产品负责人

#### 本内容属于AI、机器学习与数据工程主题

##### 相关主题：

• 开发

• 架构与设计

• AI、机器学习与数据工程

• 生成式AI

• QCon AI波士顿2026

• 平台工程

• 大型语言模型

• QCon软件开发大会

• 开发者体验

• 文字稿

• 人工智能

• DevOps

• 敏捷开发

• 机器学习

• 基础设施

• 架构

• InfoQ

• 相关编辑

• InfoQ热门文章：Cloudflare详细介绍了其迁移到“WordPress继任者”EmDash的过程 Google利用AI和差分模糊测试将关键C依赖项重写为Rust AI革命在缺乏开发者心理安全的情况下将失败：与Erin Doyle的对话 Uber在Kubernetes平台上将扩展意图与执行过程分离 Atlassian在超大规模场景下基于OpenTelemetry重建指标管道 如何在AI时代培养软件工程技能