Stripe是一个全球支付和金融基础设施平台，被数百万企业使用。为了支持产品在规模化下的持续发布和迭代，他们构建了 AI 工具，帮助 Stripe 各部门员工提升工作效率。Stripe 的 AI 平台团队负责支撑公司所有 AI 应用的技术栈。他们最引人注目的产品是Stripe 的知识 AI 平台，也称为 Kai，这是一个基于 LangChain/LangGraph 技术栈和Deep Agents智能体框架构建的全公司生产力智能体。
下面这段两分钟的视频介绍了 Stripe 如何在一周内基于 Deep Agents 构建出 Kai。
构建自研智能体框架
随着智能体 AI 的采用加速，Stripe 各工程团队开始在他们现有的 Ruby 和 Java 技术栈之上构建编排层。将这些系统与 Stripe 的内部基础设施集成相对直接，但构建一个可靠、生产级的智能体框架带来了额外的挑战。
有效的智能体系统需要的不仅仅是连通性。它们还需要强大的性能、稳健的评估，以及稳定处理复杂任务的能力。团队常常发现，他们最初的实现能应对较简单的用例，但要在规模化下交付可靠结果还需要进一步投入。
随着 Claude Code 在 2024 年底发布，突然每个 Stripe 员工都想构建智能体。但对非工程师来说，终端、数据访问和安全组件是显著的障碍。智能体基础团队的工程经理 Sharadh Krishnamurthy 和资深软件工程师 Anupam Upadhyay 看到了一个反向的思路：与其把非技术员工推向开发者工具，不如在他们所在的地方，用专门为他们打造的东西来满足他们？换句话说，“如果每个人都有个始终在线、生产就绪的助手会怎样？”答案就是 Stripe 的知识 AI 平台。
为每位 Stripe 员工打造的上下文感知 AI 同事
Stripe 的 Knowledge AI Platform 面向每一位员工开放。它专为大多数 Stripes 实际从事的工作而打造——综合数据、头脑风暴、起草文档、分析趋势以及跨职能协作——全部在一个基于会话的单一界面中完成，并连接 Stripe 的内部数据仓库、Slack 和 Google Suite。
用户开启一个会话，通过聊天进行交互，Kai 会生成与对话并存的产物、报告、仪表盘或文档。随着对话继续，这些产物不断演进。它的运作方式就像一个面向非工程师的编码智能体。
与通用 AI 助手不同，Kai 通过工具和技能预装了 Stripe 的上下文。它了解 Stripe 的运作方式，理解公司的内部系统、数据来源和规范。用户无需在每项任务前向 Kai 解释自己的职能或公司情况。公司各部门的专家通过一个技能库贡献各自的领域知识，该库包含来自 100 多个团队的 1000 多项技能。
Deep Agents 为 Stripe 提供了智能体基础，使团队能够专注于其领域特定的工作流
Kai 的基础是 Deep Agents，即 LangChain 的开源智能体框架。Deep Agents 提供了基础能力，将工具调用循环、中间件组合、流式传输和状态管理串联起来——这些若从零构建并加固，原本需要数月时间。
Stripe 的分层架构包括：
- 以 Deep Agents 作为基础层：基础层处理所有 LLM 交互原语，包括请求管理、智能体执行和中间件组合。
- 构建于 Deep Agents 之上的 Stripe 专用框架：中间层将 Kai 集成到 Stripe 的安全体系、基础设施和内部服务中，从而创建一个有明确取向的环境。
- 配置层：在框架之上，团队可以配置自己的自定义 Kai 智能体——具有不同技能集、行为和角色的专用智能体实例——而无需改动底层框架。
- Kai UI：大多数 Stripes 所交互的产品体验，向下连接全部三层。
Deep Agents 层解决了所有非 Stripe 特有的问题，这样我们就能专注于解决 Stripe 特有的智能体问题，Sharadh 解释道。“你可以直接拿来一堆现成的中间件。可组合的技能模式、复合后端，它提供了正确的结构，同时又保留了足够的灵活性。”
是什么让 Kai 达到生产就绪
Anupam 在一周内构建了 Kai 的初始版本。让这一速度得以实现的 Deep Agents 中间件包括：
- 文件系统中间件：Kai 是运行在云端的生产服务，而不是本地进程。Stripe 构建了一个由 S3 支持的虚拟文件系统，使智能体能够跨轮次读取、写入和引用文件作为上下文。文件系统非常适合 LLM 上下文，因为它把上下文变成了模型可以随时间检查、更新和组织的内容。Stripe 为每次沙箱
execute调用都套用了“同步进 / 同步出”模式：执行前，所有相关文件都会被物化到沙箱中；执行后，任何新增或修改的文件都会被同步回虚拟文件系统。因此，智能体以及驱动它的 LLM，在整个会话生命周期内都能体验到一致、持久的文件环境。 - 沙箱中间件：Kai 通过沙箱环境运行两类工作的代码执行：分析（编写并运行 Python 来查询数据、生成图表）以及处理任意文件格式（PDF、演示文稿、结构化文档）。沙箱以工具的形式暴露给智能体，而不是作为智能体本身的执行环境。智能体在沙箱之外运行并调用沙箱，从而保持执行边界清晰，并防止一类安全问题涉及 LLM 生成的代码。
- 摘要中间件：对于管理长时间运行、多轮会话中的上下文至关重要，否则累积的上下文会降低性能或触及模型限制。Kai 尤其擅长多轮长会话。为了在平衡成本的同时充分利用可用的 LLM 上下文，Kai 利用了通过以下方式提供的各种调优参数
deepagents库，比如摘要阈值、摘要模型和输出大小等。大多数用户间歇性地运行 Kai 会话，因此避免大上下文窗口的缓存未命中有助于控制成本。
技能：Kai 如何导航数百个内部工具和技能
Kai 使用技能在数百个内部工具和工作流中运行。Deep Agents 中的技能是结构化的、智能体可执行的模块。每个技能封装了如何完成特定任务、加载哪些工具，以及如何处理某一类工作。
Stripe 采用联邦式方法，由各个团队拥有并维护自己的技能。基础 Kai 智能体附带一组基础技能，涵盖广泛的 Stripe 导航，并根据用户画像和所使用的具体 Kai 智能体配置加载额外的分层技能。例如，销售运营部门的用户获得的技能集与财务部门的用户不同；用户级画像层允许个人在其职能默认技能之上添加更多技能。
面对 500+ 个可用的内部 MCP 工具和不断增长的技能库，Kai 无法将所有内容都加载到上下文中。智能体技能’allowedTools列表驱动动态工具加载，形成一个两遍系统，其中技能选择决定工具上下文的加载，而不是预先加载所有工具。选择依赖于已经拥有相关上下文的 LLM。“LLM 花费精力来确定要加载哪些技能，因此我们随后也依赖它来加载相关工具，”Anupam 解释道。某些基础技能被固定，无论模型决定加载或卸载什么，它们都会持续存在。这确保了一致的 Stripe 上下文和政策行为始终存在。
由于 frontmatter 有 1024 个字符的限制，团队发现当技能数量超过 150 个并与系统提示结合时，前沿模型的质量会下降。技能数量仍然是一个挑战，团队正在积极寻求未来更好的解决方案。
1 名工程师，1 周：Stripe 的 Python 押注如何立即获得回报
Stripe 花了十多年时间围绕 Ruby 和 Java 构建内部工具、安全层和部署支持。采用 Python 原生技术栈意味着要围绕一门新语言重建 Stripe 的内部服务脚手架，这是一项巨大的投入。
Kai 通过实际演示证明了投资回报率。一名工程师在一周内就构建出了 Kai。Deep Agents 提供的原语意味着困难的智能体基础设施已经得到解决。 这样的速度证明了为 Python 构建 Stripe 内部支持所花的时间立即得到了回报。“Kai 彻底巩固了人们的信念，即 Deep Agents 就是正确的方向，”AI 平台负责人 Chrissie 强调说。
一周内达成 Kai 的季度采用目标
当 Kai 进入公开预览阶段时，它在一周内就达到了团队的季度采用目标，并在大约 4 周内从 296 名用户增长超过 16 倍，达到 5,000 多名用户。“它一下子就火了起来。人们用了它，然后一切就都通了，”Sharadh 说。
大部分新用户正是团队当初设计所面向的角色：销售人员、财务分析师、业务运营人员，以及那些被告知要“使用 AI”却从未找到一款契合自己实际工作方式的工具的員工。“有很多人说，‘我觉得之前那个东西难以接近。我得调一堆参数。但我被要求使用 AI，我也真的努力试过了。’然后他们说：‘这个太棒了，我完全不用做那些事了，’”Sharadh 解释道。
如今，Stripe 有 83% 的人每周使用 Kai，会话数超过 6 万次。Kai 在营销（95%）和 GTM 团队（87%）等业务职能中的采用率百分比甚至高于工程团队；他们称 Kai 对交易准备具有变革性，它能从多个内部来源提取数据、进行综合，并产出可用的成果物。财务团队发现它在数据分析和仪表盘生成方面同样有用。
一些最生动的早期反馈：
- “Kai 对销售人员来说绝对难以置信。将节省数万小时。”
- “我的 Stripe 职业生涯可以分为有 Kai 之前和有 Kai 之后。”
新员工开始使用 Kai 来加速入职流程。工程团队虽然是为非工程师构建了 Kai，却发现自己把它当作日常工作的副驾驶：用 Kai 回答关于自己系统的问题，并让它对照自己的追踪记录和使用数据来识别技能缺口、提升覆盖率。
下一步：实现产品市场契合之后
团队现在面临一个幸福的烦恼，在快速普及之后……有上千个用例需要修复和构建。
扩展技能选择。Stripe 内部已经拥有超过 500 个 MCP 工具和 1000 多项技能。没有任何 LLM 能在如此规模的技能目录中可靠地完成选择，除非有辅助。团队正在构建一个混合选择系统。纯 LLM 选择在当前规模下效果良好，并且在完整上下文可用时比 RAG 效果更好，但在规模化场景下需要 RAG 或分类器层来预筛选，之后再由 LLM 做出最终决策。
治理与护栏。随着普及范围扩展到数千名员工，团队正在投入安全与合规护栏，以确保 Kai 的触达范围不会超出企业环境所需的监督结构。
行为层面的个性化。不同团队希望智能体有不同的行为。有些希望 Kai 总是先规划再行动，并提出澄清性问题；另一些则希望快速、直接的答案，用于快速头脑风暴。“这个产品的全部承诺就是，你不需要调旋钮，”Sharadh 反复说道。“所以现在我们把责任揽到自己身上，去构建智能，替人们弄清楚这一切。”团队正在评估 ML 分类器和 AI 驱动的机制，以自动让行为适应用户上下文。
跨会话协作。当前模式是单用户会话。路线图将扩展到共享技能、共享产物，并最终实现协作会话，让多名员工可以一起迭代同一份 AI 输出。
Kai 构建于Deep Agents之上，这是 LangChain 的开源智能体框架。如果你正在构建生产级智能体，Deep Agents 文档是一个不错的起点。