Presentation: Accelerating LLM-Driven Developer Productivity at Zoox

标题：在 Zoox 加速大语言模型驱动的开发者生产力提升

来源网址：https://www.infoq.com/presentations/ai-software-development/

发布日期：2026-05-14T13:05:00+0000

Markdown 内容： [InfoQ 首页](https://www.infoq.com/ "InfoQ 首页")[专题演讲](https://www.infoq.com/presentations "专题演讲")在 Zoox 加速大语言模型驱动的开发者生产力提升

观看演讲

播放速度：

下载

50:06

/presentations/ai-software-development/en/slides/Amit-1778763732756.jpg)

内容摘要

阿米特·纳文德吉（Amit Navindgi）探讨了 Zoox 公司如何系统性地从零散割裂的文档体系，转向以人工智能为核心的全新技术生态。他详细介绍了团队自主研发的安全平台“Cortex”——该平台深度融合了检索增强生成（RAG）、多模态大语言模型（LLMs）以及面向贡献者的友好型智能体（Agent）API。他还分享了通过“AI 倡导者”计划与黑客松活动推动技术落地的实际策略，并重点阐述了工作流正从确定性流程向自主智能体演进的关键转变。

讲者简介

阿米特·纳文德吉是 Zoox 公司的资深软件工程师，领导 Zoox Intelligence 项目——一项将大语言模型（LLMs）全面应用于工程研发、运营、客户服务及自动驾驶等关键领域的公司级倡议。他的专业领域涵盖应用人工智能（Applied AI）、可观测性（Observability）、语义搜索（Semantic Search）、实验平台（Experimentation Platforms）、数据工程（Data Engineering）、前端开发（Frontend Development），以及线上值班与事故响应系统（Oncall and Incident Management Systems）。

关于本次大会

软件正在重塑世界。QCon 旧金山大会致力于赋能软件开发，通过促进开发者社区内的知识共享与技术创新，推动行业发展。作为一场由一线实践者主导的技术盛会，QCon 面向技术团队负责人、架构师、工程总监及项目经理等影响团队创新方向的关键角色而设计。

INFOQ 大会活动

• /filters:no_upscale()/sponsorship/eventsnotice/3ecacfe1-02d1-4d54-a048-8ee8571a77bb/resources/1EonWebinarMay21-transcript-1774373522295.png)2026 年 5 月 21 日，美国东部时间下午 12 点

#### 按需设计的可移植性：面向多云系统的数据迁移与恢复模式

主讲人：莉奥尔·沙伊（Liore Shai）——Eon 公司解决方案架构师

• /filters:no_upscale()/sponsorship/eventsnotice/1302f11a-f90f-4a79-96d1-3dd20d032144/resources/1HarnessWebinarMay28-Transcripts-1776246863928.png)2026 年 5 月 28 日，美国东部时间下午 1 点

#### 更快交付，更多故障？AI 时代下交付体系的重构思考

主讲人：埃里克·米尼克（Eric Minick）——Harness 公司 DevOps 解决方案高级总监；亚伦·纽科姆（Aaron Newcomb）——Harness 公司高级产品营销经理

• /filters:no_upscale()/sponsorship/eventsnotice/7dd71c7c-4b0e-4760-b97d-232ac1816637/resources/1NeuBirdWebinarJune25-Transcripts-1777458459989.png)2026 年 6 月 25 日，美国东部时间下午 1 点

#### 面向自主可靠性的架构设计：将 AI 深度融入可观测性技术栈

主讲人：贾斯汀·格里芬（Justin Griffin）——NeuBird AI 公司产品负责人

演讲实录

阿米特·纳文德吉：请和我一起回溯三年前。那是你在新公司的第一周。你打开文档，感觉就像在读一本小说——在 Confluence、GitHub、Slack 和各种零散 PDF 文件之间来回跳转，试图反向推导出系统究竟如何运作。那时，如果你有问题，只有两个选择：要么继续啃文档，要么更糟——去问另一个人类同事。那真是令人胆寒的年代。但当时这再正常不过，我们所有人就这么硬扛过来了。而如今，开发者已普遍期待 AI 无处不在：编辑器里要有 AI，Slack 里要有 AI，所有工具中都要有 AI。一旦某个环节缺失 AI，整个体验就仿佛“坏了”。本次演讲聚焦的正是这一根本性转变——它无关炒作，也非魔法，而是一套贯穿开发者全生命周期的系统性方法。

我叫阿米特，目前在 Zoox 主导应用人工智能（Applied AI）相关项目，隶属于公司级战略 initiative ——Zoox Intelligence。我的团队始终围绕一个核心问题展开工作：我们如何借助大语言模型（LLMs）切实提升开发者的生产力？今天所展示的一切，均源自真实生产环境中的实践、实实在在的成功案例，以及不少值得反思的教训。

演讲路线图

这是我们今天的安排：首先，我们将审视复杂企业环境中真实的开发者生命周期；接着介绍我们为应对该生命周期固有约束而构建的平台；随后展示针对不同工作流所开发的具体应用；尤为关键的是，我们将深入探讨如何推动技术采纳——因为“造出来”仅完成了一半任务；最后，我们将总结若干关键经验与启示，助你将其带回自己的团队并付诸实践。

开发者生命周期

让我们从开发者生命周期开始。我们来聚焦于一名新开发者实际经历的过程。这个过程从来不是从写代码开始的，而是始于信息探索——他们往往要花费数天、甚至数周的时间，努力拼凑出整个系统是如何运作的：有没有文档？文档存放在哪里？仅这一阶段就可能耗尽入职的第一个月。接着是个人生产力环节：有哪些内部工具可用？这些工具如何使用？哪些仪表盘最为关键？谁是相关领域的专家？这并非单一的重大阻碍，而是上百个微小的减速带。最终，在完成上述所有步骤之后，开发者才真正进入软件开发阶段——也就是他们的本职工作。而要达到能够交付有意义代码的程度，往往轻易就需要一个月，甚至在某些团队中耗时更长。一旦他们成功交付了代码，便立即开始面向客户开展工作：解答问题、提供支持——在我们的场景中，客户就是所有内部开发者。单个支持问题就可能轻易耗费半天时间，因为相关信息零散分布在各个系统之中。

在 Zoox，我们决定审视这一生命周期，并提出一个核心问题：AI 能否帮助消除这些摩擦？能否缩短其中若干阶段，让开发者真切感受到自己身处 2025 年，而非 2022 年？最终，我们抵达了这样的状态：开发者生命周期本身未变，但整体体验却焕然一新。本次分享的其余内容，正是这段演进之旅的全程回顾——我们如何从原先缓慢、割裂的生命周期，逐步构建起如今这一套由工作流、智能体（agents）与定制化应用共同组成的生态系统。

平台架构

要理解这段旅程，我们必须首先介绍所构建的平台。在着手搭建平台之前，我们先追问了一个根本性问题：为什么需要构建这样一个平台？为什么不直接为所有人开通 ChatGPT 访问权限，就此收工？让我反问各位：你们是否认为贵公司的代码、数据、客户信息，正是其核心竞争力所在？这正是我们面临的同一约束条件。我们绝不能将敏感代码或客户数据随意粘贴进公共工具中。我们面临的是企业级约束：既要让大语言模型（LLM）切实可用，又必须确保整个过程安全可控。

我们首先列出了平台的核心需求：

1. 安全性：显而易见，一切必须安全。包括内部代码、客户信息，以及在我们场景下的车辆运行数据——任何数据均不得离开公司内网；
2. PII 合规处理：需正确处理所有个人身份信息（PII），涵盖员工信息、车辆载客数据等。若您曾乘坐过 Zoox 的自动驾驶车辆，那么您的全部行程数据也属于此范畴。在企业环境中，这一点不容妥协；
3. 高性能响应：若系统响应动辄耗时数分钟，则无法支撑实时或交互式应用的构建；
4. 多模态支持：作为一家自动驾驶公司，我们的世界远不止文本——图像、视频、音频等各类模态均不可或缺，平台必须原生支持多模态输入与输出；
5. 深度系统集成：仅掌握公开事实的通用模型，在日常工作中价值有限（这种场景下，我们反而会直接推荐大家使用 ChatGPT）。平台必须能访问 Zoox 特有的系统、服务及内部知识库，才能提供真正有价值的回答；
6. 贡献者友好性（Contributor-Friendly）：若仅有我的团队能添加工具或集成能力，我们便会成为整个系统的瓶颈。我们需要一个开放的扩展界面，让 Zoox 的每一位工程师都能自主拓展平台能力。

这些硬性约束，深刻塑造了后续每一层架构的设计与实现。

接下来，我们按步骤详解平台的实际构建过程：

第一阶段：基础网关建设 我们是一家亚马逊旗下公司，因此起步非常明确：基于 AWS Bedrock 构建统一网关。此举既规避了冗长的采购流程，又提供了对 Claude 等前沿模型的安全、内网直连访问能力；同时，我们也接入了 Nova 系列模型。这一基础设施被我们命名为 Cortex，成为整个平台的基石。

随后，我们为文本、图像与视频分别添加了基础推理（inference）API，以全面支持多模态能力。此时的 Cortex 已可回答“法国首都是哪里？”之类简单问题——但这类能力本身并无太大实用价值：我们支付工程师薪酬，显然不是为了让他们每天反复查询此类常识性问题。在平台奠基初期，我们即已规划兼容多家模型服务商。LiteLLM 极大地简化了这一目标的实现：起初我们自行开发了请求/响应格式转换的抽象层，但过去几个月已全面迁移到 LiteLLM——它对多供应商支持极为成熟稳健。

紧接着，我们集成了 Gemini 模型。因其在视觉任务上表现更优，而如前所述，我们日常处理海量图像数据。为此，我们接入 Google Cloud Platform（GCP）以解锁 Gemini 访问权限。得益于 LiteLLM，该集成过程异常顺畅。

至此，我们已建成核心推理 API 层：可在保障安全的前提下，灵活调用多家模型服务商。但此时的 Cortex 仍对 Zoox 一无所知——而我们的真正目标，正是让 Cortex “懂 Zoox”。这正是魔法发生之处。

如何从回答“法国首都在哪？”，跃升至精准解析“VH6 是什么意思？”——VH6 是 Zoox 第六代自动驾驶车辆，部分同事可能已在旧金山街头见过它。任何公开的大语言模型对此都毫无概念。而您在此处看到的答案，甚至引用了一份内部 Confluence 文档。解决方案自然便是 检索增强生成（Retrieval-Augmented Generation, RAG）。

我们构建了数据摄取流水线，将散落在 Confluence、Slack、GitHub README 等各处的文档——凡是 Zoox 团队实际用得上的资料——全部汇聚整合，进而构建专属知识库。实践表明，为每个数据源单独建立一个知识库，效果显著更优：它能大幅压缩不同提示词（prompt）所需的语义搜索空间，从而显著提升检索准确率。

我们现在已拥有这些知识库，那么平台如何使用它们呢？这就引出了“智能体（Agent）”的概念。目前，“Agent”是行业内的一个热门术语，但其实际实现却非常简单：它本质上就是一个由大语言模型（LLM）驱动的循环流程，配合一组可供调用的工具，以达成特定目标。在本例中，我们的工具即为知识类 API。我们还单独提供了知识 API，因为用户仍可构建语义搜索类应用，而并非所有场景都需要依赖 LLM。这些工具包括 Confluence 工具、Slack 工具等。当有人提问“VH6 是什么？”时，智能体的系统提示词（system prompt）及各工具的描述信息会帮助其推理出：该问题的答案很可能存在于 Confluence 中，因此它仅调用 Confluence 工具即可。如此而已。业界将此类机制称为“智能体式检索（agentic retrieval）”。其实现方式多种多样，但从高层视角来看，其本质就是如此——它并非魔法，而只是清晰、简洁的工具设计。

这种模式非常适合静态文档类场景；但面对实时性问题又该如何处理？例如，比起“谁在值班（on call）”，如果问题是“Zoox Intelligence 服务当前由谁值班？”，就无法预先写入文档——这类信息具有高度动态性，频繁变更。解决方案很简单：我们只需增加新的工具。我们新增了一个“值班查询工具（on-call tool）”，用于对接公司内部的值班服务。这样一来，智能体便获得了一项新能力：除访问知识库外，它还能实时获知指定服务当前的值班人员。当 LLM 接收到类似问题时，同样依靠工具描述信息进行推理，判断应调用“值班查询工具”，而非知识库检索工具；随后调用该工具并返回结果。我们正是采用这一模式，持续集成其他各类内部服务。如今，我们已支持与 Zoox 内部大量工具的灵活对接。

至此，用户已拥有推理 API、知识 API，以及一系列可用来构建应用的工具。例如，若某人想了解“某次构建失败的原因”，只需新增一个对应工具；对 GitHub 同样适用：若需查询某个 Pull Request 的详细信息，只需添加一个 GitHub 工具，并赋予智能体理解 PR 的能力。每项新能力，本质上都只是智能体可调用的一个新工具。

这自然引出一个关键问题：我们如何让该平台对贡献者友好？又如何让这同一个智能体，适配不同团队、不同工作流的需求？大多数团队并不愿自行部署和运维一套智能体技术栈——启动服务、搭建工具开发框架等工作既繁琐又耗时。他们真正需要的，是一个开箱即用、且仅被授予其关心的特定工具权限的智能体。为此，我们将智能体本身封装为一项 API 服务。如果你曾使用过 Google ADK 或 LangChain 等智能体框架，就会发现它们均要求客户在自有应用中定义智能体，并自行解决部署问题。而我们则将所有这些抽象层全部上收至平台侧。用户只需通过 REST API 发起一次调用，传入所选模型、提示词（prompt）以及所需启用的工具列表，即可获得一个按需配置的智能体实例。例如，前述“基础设施智能体（infra agent）”即仅具备处理基础设施相关问题的工具权限。

各团队在需要新能力时，依然负责开发对应工具；但只需在统一的中央注册中心中定义一次该工具。只要提供清晰的工具描述与名称，该工具便会自动对全公司所有智能体开放。任何有需要的团队，只需在调用智能体 API 时将其列入工具列表即可。我们正将此作为一种新型智能体定义范式进行实践：客户完全无需操心智能体的部署与运行，只需专注定义工具本身——而这本就是他们无论如何都必须完成的工作；如今，这项工作只需在我们的中央注册中心中执行一次。每当某团队需要一个智能体，只需调用该 API，Cortex 即可基于指定配置，快速启动一个轻量级智能体实例。这种设计实现了职责的清晰分离：各团队聚焦于自身业务逻辑及工作流所需的关键工具；而 Cortex 则全面负责执行调度、弹性伸缩、安全防护，以及平台通常应提供的所有其他能力。由于整个智能体能力以标准 API 形式提供，用户可基于其构建任意类型的应用：聊天机器人、Web 前端或聊天 App、Jupyter Notebook、命令行工具（CLI），乃至任何其他运行环境。

这就是当前平台的整体状态：我们已构建完成推理 API、知识库，以及智能体 API。而在企业内安全运行该平台，远不止需要智能体与向量数据库。还需配套诸多能力，例如人工审核（human-in-the-loop）机制、请求速率限制（rate limiting）等。当平台成为统一入口后，如何高效管理海量并发请求？如何实施托管配额（managed quotas）？各家大模型提供商均对各自模型设定了调用配额，我们又该如何在全公司范围内公平、合理地分配这些配额给各个业务方？此外，批量推理（batch inference）、效果评估（evals）——后者本身即是一个极为深入的技术课题；还有护栏机制（guardrails）、可观测性（observability）等能力，均已深度集成进本平台。我们持续投入，确保上述所有能力对各团队真正实用，并始终以安全、合规、防滥用为前提，保障平台稳健运行。

我想向您展示一个在实践中影响巨大的组件：人在环路（Human-in-the-Loop）工具。 下面是一个我们刚才提到的、专为值班（on-call）场景设计的简单只读工具示例。您可以看到其中定义了一个 run 方法，并赋予了该工具一个名称。这些方法均为只读，不会产生任何副作用，因此运行它们是安全的。

那么，对于可能改变系统状态的操作呢？例如创建一个 Jira 工单。您肯定不希望智能体（agent）意外批量创建数百个工单，或误发邮件给 CEO。为此，我们引入了一种极其简洁的机制：通过一个装饰器（decorator），可将任意工具标记为“写入型工具（write tool）”。您可以看到此处使用的 @require_confirmation 装饰器——它的作用是：每当智能体决定调用该工具时，系统会识别出这是一个需人工确认的写入型操作，并暂停执行，等待用户确认。实际效果如下图所示：当我让机器人创建一个 Jira 工单时，它会先向我完整展示即将用于创建工单的所有字段与内容；仅在我明确确认后，它才会真正调用 Jira API 并返回生成的工单链接。

这种人在环路机制在实践中非常有效：只读工具擅长获取信息，但用户真正需要自动化的，往往是原本需手动完成的任务——比如从 Slack 对话线程中自动生成日历会议、创建 Jira 工单、发送邮件、提交 IT 服务请求等。我们强烈建议为这类关键操作采用人在环路工具，并遵循某种标准化框架。目前已有多个框架原生支持该模式；当然，自行实现也十分简单。这不仅能显著避免误操作，更能切实保护客户利益、建立用户信任。没有人希望模型再次“失控”——我们曾遇到过一个案例：某智能体在公开频道中向法务团队发送消息：“我要权利。” 这类事件绝不能发生，所有敏感操作都必须以受控方式执行。

这是完整的 Cortex 平台架构图。平台各模块分别对应我们此前讨论过的开发者全生命周期中的不同需求。构建这一平台并非易事，我们面临诸多挑战——尤其在自动驾驶公司这一特殊背景下，挑战更为突出：

1. 海量媒体输入：如前所述，我们处理大量图像数据。若为高分辨率图像，仅数百次并发请求就足以压垮整个平台。如何应对？若缺乏严格的输入校验与预处理机制，网关极易崩溃。视频数据亦同理。
2. 车载影像复杂性更高：我们的车辆持续采集其所处城市的真实街景图像。白天图像尚可理解，但夜间图像（尤其是鱼眼镜头拍摄的畸变图像）即使对人类而言也极难辨识。例如，我有时需查看部分图像用于标注任务，却根本无法分辨画面中物体的具体类别——这对大语言模型（LLM）而言更是巨大挑战。
3. 实时推理 vs 批量推理：许多团队希望对数百万张图像执行数据标注等任务。这类负载不应走 Cortex 这类实时网关，而应交由成本更低的批量处理系统（如 AWS Bedrock 或 Google Cloud Platform 提供的服务）。作为平台方，我们的一项重要职责正是明确告知：“该用例不适合部署在 Cortex 上”——这完全合理。平台提供者必须清楚自身能力边界，并主动引导用户选择最合适的路径。
4. 按需延迟 vs 预置延迟：响应缓慢的 Slack 机器人虽令人烦躁，但尚可容忍；而车端任何系统的延迟都是不可接受的。在安全关键型工作流中，必须选用预置吞吐量（provisioned throughput），并确保延迟可预测、可保障。
5. 工具（Tools）vs MCP（Model Context Protocol）：您可能注意到，Cortex 的工具本质上就是函数调用（function calling）；而 MCP 显然是函数调用的演进形态。但我一直被反复提醒：暂勿急于迁移到 MCP。我认为业界也在逐渐意识到，MCP 可能并非最优解。在我看来，它试图承载过多职责；若回归“一个 MCP 服务器 = 一个工具”的简洁范式，效果或许更好。当前的工具机制已足够稳健：开发者可自由封装工具，并以任意方式将其接入 Cortex。
6. 多元业务流：我们虽是一家自动驾驶公司，但内部团队承担着广泛多样的工作。例如，我所在的基础设施团队所做之事，与其他科技公司的同类团队并无本质区别；同时，我们也拥有专注于自动驾驶技术研发的专属团队。如今，Cortex 平台已服务于应用程序与基础设施、车队运营、自动驾驶软件等多个领域，且覆盖更多场景。每个业务域对平台有着截然不同的期望与约束条件，因此，既要兼顾全部需求、又要将其统一收敛至单一平台，是一项极具挑战性的工程难题。我们最终通过隔离式 API 设计、面向不同团队的大规模培训等方式，找到了可行的解决方案。平台架构必须保持高度灵活性。上述挑战不仅塑造了我们最终构建的内容，也同样决定了我们刻意未构建的部分。

应用场景

在深入探讨具体应用之前，让我先分享指导我们所有工作的两条核心原则。这两条原则为我们节省了大量时间、资金以及无数场会议。 第一，只构建那些买不到的东西。 如果市场上已有某款供应商工具能满足你 80% 的需求，那就直接采购它。把宝贵的工程资源留给只有你们公司才能解决的独特问题——那些唯有你们能构建的部分。 第二，我非常欣赏亚马逊提出的“1 > 2 > 0”原则： 一个优质方案胜过两个相互竞争的方案；而两个相互竞争的方案，又远胜于一无所有。在 AI 时代，速度至关重要。如果花一个月时间构建一个重复性应用能帮助团队快速推进，那完全没问题——后续再逐步收敛即可。

为了厘清我们在 Cortex 平台上构建的所有内容，我们将应用划分为两大类： 一是 AI 工作流（AI Workflow）。 AI 工作流是确定性的应用。例如，当某个告警被触发时，流程便启动：第一步，脚本调用 AI 对日志进行摘要；第二步，脚本自动呼叫值班人员。AI 在此仅作为固定执行链中一个可预测的环节，它不会决定下一步该做什么。

二是智能体（Agent）。 智能体是非确定性的——这也是使用智能体最大的注意事项。它具备工具、模型、提示词（prompt）以及上下文（如前文所述），能够自主决定调用哪些工具、以何种顺序调用、以及何时终止。这使得智能体更灵活、更强大，但也更难控制和调试。Zoox 内大多数团队都从工作流起步：它们更易理解、更易测试，且往往已足够满足需求；仅当真正需要额外的自主性与决策能力时，团队才会转向智能体。

让我们再次拉远视角，俯瞰整个应用地图。我们共划分出三类：AI 工作流、智能体，以及我们自行构建的其他应用和采购的第三方工具。我们采购了 Cursor 和 Claude Code 等用于软件开发的商用工具——稍后我会重点介绍 Cursor。一年前，由于 Cursor 尚未面世，而我们急需解决方案，因此基于 Code Llama 和 Continue（一款开源 VS Code 插件）自主研发了一套内部工具。当时我们选择自建，正是因为市面上尚无合适产品。一旦 Cursor 正式发布，我立即关停了该项目，转而采购 Cursor——事实证明，它的效果要好得多。截至目前，Zoox 各团队已在整个开发者生命周期中构建了 50 多个应用。

在座各位中，每天至少使用一种 AI 工具的请举手？——所有人。Zoox 的情况也完全一样：人人都想要 AI，尤其希望用它来处理那些自己私下里并不喜欢、却不得不做的工作环节。我们聚焦于这些令人痛苦的时刻，构建了能显著简化它们的应用。当然，我们无法一一详述全部应用，但我会重点介绍其中几个——如果你所在公司尚未落地类似方案，相信你也可以很快将它们复刻到自己的组织中。

第一个应用叫 Humblebrag。 你一定经历过这样的时刻：绩效考核季里，盯着空白屏幕发呆整整四小时，反复怀疑自己过去半年到底干了些什么？其实你当然做了很多：修复了大量功能、解决了无数缺陷……只是大脑早已不堪重负，为应对接踵而至的新压力而“清空”了旧记忆。而 Humblebrag 不会遗忘。它自动聚合你在 GitHub、Jira、Slack 及其他多个平台上的活动记录，汇总你交付的功能、修复的缺陷、解答的问题、以及解除的阻塞项；它还会根据你的岗位职能（例如 TPM、PM 或软件工程师）从不同数据源提取对应信息。最终，它帮你轻松讲述自己的故事，大幅减轻撰写自评与同事互评时的压力。AI 的一大优势，正是将原本需人工耗时数小时完成的信息检索工作彻底自动化。

第二个应用是面向客户支持团队的 ZI AutoAssist，它能在 Zoox 内部 Slack 支持频道中自动回答用户提问。我们来看这个案例：如果你运营过 Slack 支持频道，就一定深谙其中辛劳与痛点——不断涌入的重复性问题，频繁打断深度工作；而上下文切换，恰恰是影响生产力的最大障碍。AutoAssist 正是为此而生。 在第一个实例中，用户提出一个元问题：“如何在 Slack 频道中启用 AutoAssist？” Zoox Intelligence（即该 Slack 机器人）即时响应并给出答案，用户则通过表情符号提供反馈。 在第二个实例中，有人提出了一个与 Zoox 内部 CI 检查相关的具体问题，ZI Slack 机器人同样迅速作答。这背后，是我们在平台之上整合了智能体、知识库、各类工具等全部能力的成果：它既掌握静态知识库中的全部信息，又能实时访问公司内部各项服务，并具备自动问答所需的完整推理与执行能力。 成效显而易见：绝大多数团队的支持负载显著下降，干扰减少，上下文切换频率降低——这对专注力提升永远是利好；团队得以持续聚焦于高价值工作。更重要的是，客户也能更快获得答案——响应是即时的，而非被动等待人工介入。

加速采用

这便是当前应用生态的全貌：我们拥有面向代码开发的工具、面向支持工作的工具，以及覆盖全公司各业务流程的工作流工具。平台已搭建完成，应用也已开发就绪。此时的关键问题变为：如何真正推动员工去使用它们？因为再次强调，构建只是故事的一半，战斗才刚刚进行到一半——接下来要加速的是“采用率”（adoption）。而一旦谈到采用率，下一个自然的问题就是：怎么做？如何让整个公司真正用起来 AI，甚至将其融入每日每一项工作流中，而又不靠强制推行？此时，我们的实施蓝图便派上用场了。这不仅关乎工具建设，更关乎工具推广与布道。作为 AI 负责人，我认为你超过一半的工作重心，应当放在“开发者布道师”或“AI 布道师”的角色上。这正是我目前大部分时间所做的事情——而非事必躬亲地开发所有功能。当然，你首先要构建出所有必需的基础能力；随后，便需投入大量精力，在公司内部“销售”这些能力。

为此，我们识别并培养“AI 倡导者”（AI Champions）。你显然无法独自（或仅靠你的团队）覆盖整家公司，因此必须在每个部门都发掘出若干位 AI 倡导者：他们更了解本部门的实际需求，也能更有效地参与塑造平台能力与 AI 发展路线图。

我们通过激励机制促进使用，并坚持“过度分享”（overshare）——尤其是成功案例与失败教训。透明度建立信任，而信任驱动采纳。我们按职能组织团队专属培训会：例如，技术项目经理（TPM）对 AI 的需求，与软件工程师截然不同，因此必须开展高度场景化、职能定制化的培训，确保每位用户都能掌握你希望他们掌握的全部内容。

仪表盘（Dashboards）在此过程中至关重要。务必构建仪表盘，持续追踪使用情况——这正是赢得管理层支持的关键时刻。尝试清晰呈现：谁在用 AI？更重要的是，谁尚未使用 AI？按职级、按职能、按部门等多维度展开分析，构建直观仪表盘，使采用情况一目了然。

此外，你还必须衡量这些工具（包括自研工具与采购工具）所产生的实际影响。如果无法衡量，就无从优化。我们希望每个团队都能实时感知自身获得的真实价值。

此处最棘手的问题，无疑是：如何衡量“生产力”？以下是我们当前采集的部分指标。这些指标本身具有一定主观性，因团队而异；但间接来看，它们至少反映了生产力的某种变化趋势——这是我们实际观察到的结果。除量化指标外，我认为始终不可忽视的一点是定性反馈：如果开发者使用 AI 工具后明显更愉悦、更满意，那这本身就是一项极具价值的工作方向。快乐的开发者产出更多成果——无论他们从工具中直接获得了多少提升。

关于生产力衡量，还有一点尤为关键：必须按维度进行分类分析。例如，资深软件工程师（Staff SE）与高级软件工程师（Senior SE）的使用方式是否不同？TPM 与软件工程师的使用模式是否存在差异？哪些模型被更频繁或更有效地调用？稍后我将展示部分我们构建的仪表盘（不涉及任何敏感信息）。仪表盘，真的极其重要。

如今，我投入大量时间确保大家以正确的方式使用这些工具。我的目标，是通过赋能他人实现百倍影响力——即提升全体成员的生产力，而非自己包揽所有应用开发。单靠后者，你走不了多远。像 Cursor 这样的工具，正让这种赋能成为可能。我花大量时间与 Cursor 团队协作，并深度支持 Zoox 内部所有 Cursor 用户，开展各类举措，帮助大家最大化释放 Cursor 的潜力。例如，我定期组织“Cursor 咖啡角”（Cafe Cursor）内部分享会：由 Cursor 高阶用户现身说法，分享实战经验与技巧，供其他同事学习借鉴。

同时，我们围绕 Cursor 构建了大量定制化仪表盘。需要指出的是，所有第三方厂商工具都有一个共性短板：其内置指标（如接受的代码行数、发起的请求数等）虽有一定参考价值，却远不足以揭示真实全貌。作为 AI 负责人，或作为贵司 Cursor 的负责人，你必须自主构建仪表盘，将厂商工具的数据与组织内部数据打通关联。例如：谁在更频繁地使用 Cursor？是 L5、L6 还是 L3 级别员工？不同职级/职能人员对模型的选择是否存在显著差异？

为此，我专门开发了一个 Cursor IDE 插件（因 Cursor 官方未提供此能力），旨在弥合 Cursor 与 Zoox 内部体系之间的鸿沟。如图所示，该插件首先展示用户的使用数据（此类数据本可通过其他渠道获取）；但更重要的是，它集成了反馈表单——我们致力于让知识共享变得轻而易举。对 Cursor 高阶用户而言，向同事分享一两条实用小贴士，绝不应成为额外负担。这个插件正是为此而生：它将分享入口无缝嵌入编辑器内，让用户可随时、随地、一键将任何心得分享给 Zoox 全体同事。

插件还会主动推送提示，例如：“今日已消耗 $50 / $200 使用额度，你有哪些收获？” 将所有这些交互与反馈机制直接集成于 IDE 内，能显著提升反馈率。而所有收集到的反馈，均对 Zoox 全体员工开放可见。

这些是我们的一些采用情况分析数据，按岗位职能和团队进行细分——后者尤为重要。哪些团队使用得更多？是基础设施团队吗？因为通常来说，我们提交的 Pull Request 数量远超那些从事自动驾驶软件开发的同事。这一因素该如何考量？诸如此类的问题。 这是 Cursor 的分析数据：当前使用的是哪些模型？日活跃用户（DAU）有多少？Cursor 在哪些文件中被调用得最多？因为不同用户常会观察到差异化的性能表现。例如，所有模型在处理 C++ 代码时效果都不太理想——但这并非 Cursor 的问题。展示这类数据（尤其是此处的“每日模型使用趋势”）非常关键。在 Zoox，员工对尝试新模型抱有极强的好奇心：一旦有新模型发布，我立刻就能看到其使用量飙升。大家会来到这个看板，发现“最近大家都在用 Sonnet 4.5”，于是便跟进使用，探索如何从中获取最大价值。这就是 Cursor。我建议您不仅对 Cursor，而且对采购的每一款供应商工具都建立类似的分析机制。我们目前已开始对其他几款工具也实施这一做法：构建一个统一仪表盘，将各供应商工具的数据与您组织自身的数据打通整合。

接下来是“活动”（Events）。如果本次分享中您只记住一件事，那一定是：务必举办黑客松（Hackathon）。黑客松是快速产出数十个高影响力 AI 工具、并全面激发全公司热情的最高效方式。例如，这是我们某次黑客松所构建全部应用的目录，以及配套上线的可视化看板。几个月前的一次黑客松中，我们就产出了 50 多个应用；两周后我们还将再举办一场。请系统性地组织此类活动。这是一把双刃剑：一方面必须主动组织，另一方面又难免有人错过，或无法充分参与获益。因此，您需要让活动定期举行，并持续保持新鲜感与关注度。如果您担任 AI 负责人，这便是您最核心的职责——抵御炒作喧嚣，聚焦实际影响。唯有如此，AI 才能在企业内部真正规模化落地。

核心要点总结

有哪些关键收获？

• 为贡献者而构建：您需要搭建一个平台，让公司每位员工都感到自己有能力参与其中，并协力开发更多 AI 工具。
• 赋能您的 AI 倡导者：本质上，这是在成倍放大您自身的能力。
• 坦诚共享成功与失败：明确告知哪些事情 LLM 确实做不到，至关重要。比如我每到一处，总有人问：“AI 能给我做饭吗？”答案当然是否定的。及时设定合理预期极为重要。
• 再次强调：抵御 hype，聚焦 impact：每天都有新技术涌现——比如 Gemini 3。但这并不意味着您必须立刻跟进。作为 AI 负责人，这种处境颇为微妙：您既要时刻关注全球范围内发生的每一项进展，又必须克制住即刻行动的冲动。以我们为例：我们已部署 Cursor 及大量内部 API（包括前述推理 API），并将 Sonnet 4.5 设为默认模型。新模型发布，并不等于我们必须立即切换。此时，您之前建立的严谨评估体系（如模型评测流程等）就派上用场了：认真评估、从容决策、审慎切换。最后再强调一次：黑客松！黑客松！黑客松！想一天内产出 50 个应用？那就办一场黑客松！

问答环节

参与者 1：您提到曾意识到 MCP（Model Context Protocol）可能并非最佳路径。这是我第一次听到有人这样讲，能否进一步展开说明？

Amit Navindgi：我们的目标始终是实现集成——即便采用 MCP 也是如此。MCP 对于 Confluence、GitHub 等提供通用服务的厂商而言确实重要；但若要构建一个适配您内部服务的平台，则未必需要引入 MCP。我之所以这么说，是因为 MCP 并非单一组件，而是一个涵盖协议本身、客户端、服务端、工具链等在内的完整生态系统。要消费 MCP 服务端，您就必须开发对应的 MCP 客户端——这带来了显著挑战。如今，公司内每位开发者若想接入任意 MCP 服务端，都需从头构建符合 MCP 规范的客户端。以 Zoox 为例，我们已有数百个自研应用（包括大量前端界面、Slack Bot 等），推动它们全部改造为 MCP 兼容客户端，工作量巨大，却收效甚微。MCP 真正发挥价值的场景在于平台层自身：例如，我们可轻松将自建知识库替换为 Confluence 官方提供的、基于 MCP 协议的服务端——该替换仅发生在平台侧，客户端完全无感：无需更新、无需适配 MCP，只需继续调用标准 REST 接口即可。毕竟，当前所有客户端天然支持 REST。因此，采用 REST API 显然是更优选择。此链接汇总了我们日常高频使用的 Cursor / 命令，也强烈推荐您参考。

参与者 2：当您针对平台需求定制 AI 智能体（例如您提到的 Zoox Intelligence）时，对于“采用开源模型并进行微调”与“采用闭源模型并结合 RAG 构建知识库”这两种路径，您的看法是什么？抑或您会将二者结合，以满足 Zoox Intelligence 这类智能体对特定平台的深度适配需求？

阿米特·纳文德吉（Amit Navindgi）：这是一种不同的思路。从我们的实践来看，RAG 目前效果很好。而微调则是一项庞大的工程，通常并不适用于知识库集成这类场景。RAG 是一种已被验证的架构。当然，我们内部也有专门的团队——比如现场的欣（Hien）就支持那些从事大语言模型或生成式模型微调工作的团队。但对于某些特定用例，例如让模型深入理解 Zoox 的自动驾驶技术，仅靠 RAG 是无法实现的。这类场景下微调确实有其价值，但并不适用于我们当前处理的简单知识库查询类任务。

参与者 3：您提到 PII（个人身份信息）是代理系统的一大顾虑。那么 Cortex 是否会在将数据发送至 Bedrock 之前对 PII 进行清洗？

阿米特·纳文德吉：是的。

参与者 3：那么，您能否分享一下，你们是如何识别出哪些内容属于需被识别和处理的 PII 的？

阿米特·纳文德吉：主要依靠大量正则表达式和规则集，同时我们也借助大语言模型（LLM）来辅助识别潜在的 PII。此外，我们与 Zoox 的安全团队紧密协作，共同制定用于识别 PII 的启发式策略。这里还有一个实用小贴士：将系统与可观测性平台深度集成。通常，可观测性平台中某些字段本身就能帮助我们快速识别数据类型。目前，由于 Bedrock 部署在 Zoox 自有网络内且完全隔离，PII 管控压力相对较小；但最近我们开始探索直接调用 Anthropic API 的可行性，此时 PII 识别与防护机制就变得尤为关键了。

参与者 4：我注意到另一个常被提及的 MCP 相关担忧是延迟或效率问题。能否请您简要介绍您最常用的三种缓解工具调用或跨代理调用延迟的技术或方法？

阿米特·纳文德吉：首先是“工具隔离”。我们认为每个工具应仅承担单一核心职责，别无他务。MCP 架构的一个常见问题是：一个 MCP 服务器可能集成了多达 10 或 20 个工具——GitHub 上的 MCP 实现就是典型例子。但事实上，我们根本不需要全部这些工具。这不仅带来延迟问题，还会导致“工具污染”（或称“MCP 污染”）：向 LLM 输入过多上下文、提供过多可选动作，反而削弱其决策效率。为此，我们制定了明确规则：禁止任何工具发起耗时超过约 3 秒的外部 API 调用。归根结底，坚持“单一职责”原则并严格执行即可。以 GitHub MCP 为例，我们显然并未采用它——它功能繁多，但我们真正需要的只是创建 Pull Request 或获取 PR 差异内容等极少数能力。只要清晰、独立地定义这些能力，就完全足够了。

参与者 5：您提到公司上下正全力聚焦 AI 发展，并积极共享新工具。那么，在权限管控与信息访问方面，你们是如何管理的？

阿米特·纳文德吉：您是指平台层面的数据处理权限吗？

参与者 5：是的，具体来说，如何管控不同人员对各类信息的访问权限？是否所有工程师都能访问公司内部全部信息？

阿米特·纳文德吉：并非如此。目前我们仍在平台层面推进基于角色的访问控制（RBAC）建设。例如，当前 Slack 机器人仅处理全公司范围内公开可访问的信息；但客户端应用必须启用 OAuth 认证，才能将用户身份信息从各客户端安全传递至服务端，再由服务端统一执行 RBAC 权限校验。该机制尚未全面落地，但我们正稳步推进中。

参与者 6：您提到为其他开发者开设了专门的课程或工作坊。能否进一步说明这些工作坊的具体内容？以及首批重点覆盖的开发者群体是哪些？

阿米特·纳文德吉：面向软件工程师的工作坊可高度专业化，例如深度讲解主流厂商工具的高级用法，甚至涵盖用户 API 的设计与开发规范。另一类则更偏抽象与普适，比如我们为产品经理（PM）及技术项目管理（TPM）人员开设的培训，重点教授如何使用低代码/无代码工具——Replit 就是 Zoox 当前正在采用的典型代表。这类工具上手门槛低、无需深厚技术背景，易于快速入门：只需输入自然语言描述，即可构建所需应用原型。我们并不要求他们产出生产级应用，但足以支撑高效迭代与概念验证。整体上，我们按工具类型与岗位职能进行分层分类组织培训。

参与者 6：您是否会进一步细化，针对不同类型的软件工程师（如前端、后端、基础设施等）开展差异化培训？

阿米特·纳文德吉：目前尚未开展此类细分。

参与者 7：您强调“黑客松”是我们本次交流中最应铭记的关键举措。能否分享一些贵司成功运营黑客松的核心经验或实操建议？

阿米特·纳文德吉：当然可以。首要关键是预先设定多个清晰的应用主题方向。例如，正如我之前所提，Zoox 内部存在众多职能各异的团队，为增强全员参与感，我们确保每个主题都与至少一个团队的实际业务密切相关。其次，务必大幅降低非技术人员的参与门槛。我认为，人人都可能拥有绝佳创意，而将创意快速转化为可运行原型也并非难事——关键在于鼓励他们动手尝试。为此，我们正尝试一项新举措：联合厂商共同举办专项工作坊。例如，Anthropic 和 Cursor 正协助我们开展面向非技术人员的 Cursor 使用培训；同样，我们也自主组织面向软件工程师的平台使用工作坊等。让所有人切实“被纳入其中”，并辅以极具吸引力的激励机制——丰厚的奖品，我想，这恐怕是最强效的驱动力了。

参与者 8：您具体是如何使用 Cortex 的？它是被内部不同系统调用的吗？这些系统是出于各自特定目的使用它，还是面向客户的——例如某些客户可通过 API 使用它，或通过某种 UI 界面直接访问？如果我想将自己的智能体（agent）和知识库接入该工具，整个流程是怎样的？有哪些快速上手的步骤？

阿米特·纳文迪吉（Amit Navindgi）：什么是 Cortex？本质上，它是一个微服务，对外暴露了一组 API。如前所述，它包含推理（inference）API、聊天补全（chat completion）API、文本补全（text completion）API 和图像理解（image understanding）API。这些 API 接收包含用户消息体（payload）的请求，经处理后返回结果。整个流程其实非常简单。要构建知识库，我们提供了一个名为“连接器框架”（connector framework）的开发框架：您只需编写一个 Python 类，声明“从该数据源读取数据，并写入该目标位置”。其余所有工作（如数据拉取、嵌入向量化、向量存储、知识库服务化等）均由该框架自动完成——因为连接器本身需根据实际数据源定制，这部分需由客户自行开发。例如，目前我们对所有数据统一使用同一嵌入模型（embedding model），但未来也可能探索多模型方案。利用嵌入模型生成向量、存入向量数据库、并对外提供知识库服务，整个过程均已自动化；您唯一需要做的，就是编写那个连接器。至于创建智能体：严格来说，您并不直接“创建”智能体，而是为其添加所需能力对应的“工具”（tool）——若某项功能尚不存在，就开发一个新工具。这正是我之前在另一款工具中所演示的内容。“人机协同”（HITL）功能同样以一个简单的 Python 类实现，其中 run 方法定义了具体的业务逻辑：既可执行本地自动化操作，也可调用外部 API。客户仅需开发该工具；调用时，则通过 REST API 调用对应智能体即可。

参与者 9：您使用的是供应商提供的 API，还是自研的定制化 API 和批处理系统？

阿米特·纳文迪吉：我们采用供应商官方提供的 API。我们的目标是让客户使用尽可能简单——毕竟各家供应商对 prompt 格式的要求各不相同，而我们的团队无需了解这些细节。我们为所有团队强制推行统一的数据 Schema 和配套工具，后续流程（如调用、转换、结果回传等）全部由平台接管，并在标注任务完成后主动通知相关人员。

参与者 10：能否简要介绍下，为落地这一方案，贵司在组织架构层面做了哪些调整？整体时间线又是如何安排的？例如，负责 Cortex 开发与维护的团队，是否也同时负责与 Cursor、Anthropic 等供应商的对接与关系维护？

阿米特·纳文迪吉：实际情况是混合模式。整个项目始于一年前，最初仅由我和当时的直属主管两人启动。公司软件系统通常由基础设施团队负责建设，而我则牵头发起了“Zoox 智能计划”（Zoox Intelligence Initiative），并逐步组建起专属团队。目前，我们拥有一个专职的软件团队，负责平台的研发、运维及应用接入。对于供应商相关工具，部分由我及我的团队主导推进，部分则由 IT 或其他部门牵头。近期，我们更倾向于组建跨职能专项小组：例如，由 Zoox 智能团队担任牵头方，IT 部门、采购部门、财务部门各派代表共同参与，集中资源优先完成工具选型与采购。至于后续的推广落地、应用接入、技术支持等工作，则视具体工具而定：Cursor、Claude Code、Replit 等工具由我本人直接运营与维护；而 Google Gemini 和 Google AgentSpace 等企业级工具，因其深度集成于 Google Workspace 生态，我们介入空间极小，基本无需参与。

参与者 11：贵司存在一个全员可访问的企业级公共数据仓库。请问您如何看待并规划从这种“全局共享”模式，逐步演进为更精细化的“用户级数据隔离”？

阿米特·纳文迪吉：您指的是基于角色的访问控制（RBAC）机制吗？

参与者 11：是的。比如，我拥有对公司某套基础设施云环境的专属访问权限，而其他同事无权访问。在这种场景下，该工具将如何运作？您对此有何规划？

阿米特·纳文迪吉：这是一个极具挑战性的问题。其可行性高度依赖于数据源本身的访问控制能力——即该数据源是否原生支持访问控制列表（ACL）。若支持 ACL，则技术路径相对清晰；真正的难点在于客户端适配：我们需要一套通用机制，确保所有客户端均能完成统一身份认证，并将用户上下文信息（如身份、权限）可靠地透传至 Cortex 等后端服务。目前，我们尚未完全攻克这一环节。部分供应商在 ACL 数据拉取方面提供了良好支持，而另一些则完全不支持，这给方案落地带来显著障碍。截至目前，我们发现按“岗位职能”或“所属团队”进行粗粒度权限划分，比按单个用户做细粒度管控更为可行且易于实施。

参与者 12：我注意到您的输入类型较为复杂，例如视频、图像；同时，我也观察到智能体与人类之间存在大量高频交互。请问在内存管理（尤其是上下文 context 维护）方面，您有哪些优化经验或实用建议？如何让上下文更高效、更可控？

阿米特·纳文德吉（Amit Navindgi）：感谢我们拥有的所有可扩展计算资源。这确实是一个巨大的挑战。事实上，大约两个月前，我们就遭遇了一次 PEF（生产环境故障），有人用大量图片对我们发起了 DDoS 攻击。例如，我们在 Kubernetes 中运行着新版 Cortex，其内置的自动扩缩容机制在此类场景下确实发挥了重要作用。正如我之前提到的，在负载均衡器层面，关键在于一旦请求超出预设的有效载荷限制，就应立即拒绝。此外，还需主动与客户端沟通，确认他们是否真的需要实时响应——目前我们尚未遇到此类需求，但未来随着车队规模扩大等场景出现，这一需求很可能会浮现。在很多情况下，我们已识别出这类非实时性请求，并将其迁移至批处理推理任务中，因为它们本就并非有意设计为实时调用；而多数时候，这种识别都是在问题发生之后才完成的。因此，这对我们而言仍是一项持续的挑战。不过，良好的可扩展性确实在这方面给予了我们有力支撑。

查看更多附带文字稿的演讲内容：https://www.infoq.com/transcripts/presentations/

录制于：

2026 年 5 月 14 日