Stripe 如何在 Deep Agents 上造出全公司通用的 AI Agent —— Kai
Stripe 如何在 Deep Agents 上造出全公司通用的 AI Agent —— Kai
原文：*How Stripe Built Kai, its Company-Wide AI Agent, on Deep Agents*
作者：Sofia Sulikowski（LangChain 官方博客 · Case Studies）
发布时间：2026-08-03 · 阅读时长约 10 分钟
原文链接：https://www.langchain.com/blog/how-stripe-built-their-knowledge-ai-platform-on-deep-agents
---
Stripe 是全球支付与金融基础设施平台，服务着数百万家企业。为了支撑大规模、持续不断的产品迭代，Stripe 内部搭了一整套 AI 工具，帮全公司的员工提效。Stripe 的 AI 平台团队负责的，就是撑起公司里所有 AI 应用的那套技术栈。他们最显眼的产品是 *Stripe 的知识 AI 平台*（Stripe's Knowledge AI Platform），也就是 Kai——一个面向全公司的生产力 agent，建在 LangChain/LangGraph 技术栈和 Deep Agents 这套 agent harness 之上。
自建一套 agent harness
随着 agentic AI 的采用速度加快，Stripe 各个工程团队开始在既有的 Ruby 和 Java 技术栈上搭编排层。把这些系统接进 Stripe 的内部基础设施相对简单，但要做出一套可靠的、生产级质量的 agent harness，就是另一回事了。
有效的 agent 系统需要的不只是连通性。它还需要过硬的性能、扎实的评估体系，以及稳定处理复杂任务的能力。团队们常常发现：最初的实现应付简单场景没问题，但要规模化地稳定交付结果，还得继续往里投。
2024 年底 Claude Code 发布，突然之间，Stripe 每个员工都想做 agent。但对非工程师来说，终端、数据访问、安全这几块都是不小的门槛。Agent Foundation 团队的工程经理 Sharadh Krishnamurthy 和资深软件工程师（Staff Software Engineer）Anupam Upadhyay 想到了一条反过来的路：与其把非技术员工往开发者工具那边推，不如就在他们本来干活的地方去接住他们，给他们一个专门为此打造的东西。换句话说，*"如果每个人都有一个常开的、生产级的助手，会是什么样？"* 这个问题的答案，就是 Stripe 的知识 AI 平台。
给每个 Stripe 员工一位懂上下文的 AI 同事
Stripe 的知识 AI 平台对每位员工开放。它是专门为大多数 Stripe 员工每天真正在做的事打造的——综合数据、头脑风暴、起草文档、分析趋势、跨职能协作——全都在一个基于会话（session）的界面里完成，而这个界面连着 Stripe 的内部数据仓库、Slack 和 Google Suite。
用户开一个会话，通过聊天交互，Kai 产出各种产出物（artifact）：报告、看板、文档，它们就存放在对话旁边。随着对话继续，这些产出物也跟着演进。它用起来就像一个给非工程师用的 coding agent。
和通用 AI 助手不一样的地方在于，Kai 通过工具和 skills 预装了 Stripe 的上下文。它知道 Stripe 是怎么运转的，理解公司内部的系统、数据源和习惯做法。用户不需要在每次任务前先跟 Kai 解释自己的岗位职能和公司情况。而公司各个部分的专家，会通过一个 skills 库把自己的领域知识贡献进来——目前已有来自 100 多个团队的 1000 多个 skill。
Deep Agents 给了 Stripe agent 底座，团队才能专心做自己领域的工作流
Kai 的底座是 Deep Agents，LangChain 的开源 agent harness。Deep Agents 提供的底层能力，把工具调用循环、中间件组合、流式输出和状态管理这些东西都接好了——这些如果从零开始搭并打磨到可用，得花上好几个月。
Stripe 的分层架构包括：
- Deep Agents 作为底层：这一层处理所有与 LLM 交互的原语，包括请求管理、agent 执行和中间件组合。
- 建在 Deep Agents 之上的 Stripe 专属 harness：中间这一层把 Kai 接进 Stripe 的安全体系、基础设施和内部服务，形成一个有明确主张的运行环境。
- 配置层：在 harness 之上，各团队可以配置自己的定制 Kai agent——具备不同 skill 集、行为和人格的专属 agent 实例——完全不用碰底下的 harness。
- Kai UI：大多数 Stripe 员工实际打交道的产品界面，它向下贯穿了前面三层。
*"Deep Agents 这一层把所有不属于 Stripe 特有（non-Stripey）的问题都解决了，这样我们就能专心解决 Stripe 特有（Stripey）的那些 agent 问题，"* Sharadh 解释说，*"你可以直接拿一堆现成的中间件来用。可组合的 skill 模式、组合式后端，它给出了合适的结构，同时又留了足够的灵活性。"*
让 Kai 达到生产可用的几件事
Anupam 只用一周就做出了 Kai 的第一版。让这个速度成为可能的 Deep Agents 中间件有：
- Filesystem 中间件：Kai 是跑在云上的生产服务，不是本地进程。Stripe 用 S3 撑起了一套虚拟文件系统，让 agent 能跨轮次读、写、引用文件作为上下文。文件系统之所以特别适合承载 LLM 上下文，是因为它把上下文变成了模型可以检视、更新、并随时间组织起来的东西。Stripe 给每一次沙箱执行调用都包了一层 "sync in / sync out"：执行前，把所有相关文件落地进沙箱；执行后，把新增或修改过的文件同步回虚拟文件系统。这样一来，agent 以及驱动它的 LLM，在整个会话生命周期里体验到的都是一个连贯、持久的文件环境。
- Sandbox 中间件：Kai 把代码执行放在沙箱环境里跑，主要用于两类工作：*分析类*（写并运行 Python 来查数据、出图表）和*处理各种文件格式*（PDF、演示文稿、结构化文档）。注意，沙箱是作为一个工具暴露给 agent 的，而不是 agent 本身的执行环境。agent 跑在沙箱外面，调用进去，这样执行边界很干净，也避开了 LLM 生成代码带来的一类安全风险（即 Simon Willison 说的"致命三要素"）。
- Summarization 中间件：这个对管理长时间、多轮会话的上下文至关重要，否则累积的上下文会拖垮性能或者直接撞上模型上限。Kai 特别擅长多轮长会话。为了在成本和 LLM 上下文利用率之间取得平衡，Kai 用上了 deepagents 库提供的各种调节旋钮，比如摘要触发阈值、摘要模型、输出长度等等。大多数用户是断断续续地用 Kai，所以避免大体积上下文的缓存未命中，对控制成本很有帮助。
Skills：Kai 是怎么在几百个内部工具和 skill 里找路的
Kai 靠 skills 在几百个内部工具和工作流之间穿行。Deep Agents 里的 skill 是结构化的、可被 agent 执行的模块。每个 skill 都封装了三件事：怎么完成某项具体任务、要加载哪些工具、以及面对某一类工作该用什么思路。
Stripe 采用的是联邦式做法：各团队自己拥有并维护自己的 skill。基础版 Kai agent 自带一组基础 skill，覆盖 Stripe 通用导航；再根据用户画像和当前使用的具体 Kai agent 配置，分层加载额外的 skill。比如销售运营岗的用户和财务岗的用户，拿到的 skill 集就不一样；此外还有一个用户级的画像层，允许个人在职能默认之上再加自己的 skill。
面对 500 多个可用的内部 MCP 工具和一个还在长大的 skill 库，Kai 不可能把所有东西都塞进上下文。Agent Skills 的 allowedTools 列表驱动着动态工具加载，形成了一套两段式机制：由 skill 的选择来决定放哪些工具进上下文，而不是一开始就把所有工具全加载进来。这个选择动作依赖的是 LLM——因为它手上已经有相关上下文了。*"LLM 本来就在花力气判断该加载哪些 skill，所以我们就顺着这个判断，把对应的相关工具也一并加载进来，"* Anupam 解释道。有一部分基础 skill 是固定常驻的，不管模型决定加载还是卸载什么，它们都留着。这保证了 Stripe 上下文和策略行为始终一致。
由于 frontmatter 有 1024 字符的上限，团队发现：当 skill 数量超过 150 个、再叠上他们的系统提示词时，前沿模型的质量会开始下降。skill 数量至今仍是个挑战，团队正在积极寻找更好的解法。
1 名工程师，1 周：Stripe 押注 Python 立刻见了效
Stripe 花了十多年，围绕 Ruby 和 Java 建起内部工具、安全层和部署支持。改用 Python 原生技术栈，意味着要围绕一门新语言重建 Stripe 的内部服务脚手架，这是一笔很大的投入。
Kai 用一次实打实的演示证明了 ROI：一名工程师，一周做出了 Kai。Deep Agents 提供的那些原语，意味着 agent 基础设施里最难的部分早已被解决。这个速度证明，为 Python 建内部支持所花的时间立刻就回本了。*"Kai 彻底坐实了大家的判断：Deep Agents 就是该走的路，"* AI 平台负责人 Chrissie 强调。
一周就完成了整个季度的采用目标
Kai 进入开放预览后，一周就达成了团队原定的季度采用目标，并在大约 4 周内从 296 名用户涨到 5000 多人，增长超过 16 倍。*"它一下就火了。大家用起来，一下就对上了，"* Sharadh 说。
新增用户主要正是团队当初设计时瞄准的那些角色：销售、财务分析师、业务运营人员——这些人一直被要求"去用 AI"，却始终没找到一个真正贴合自己工作方式的工具。*"很多人跟我们说：'之前那个东西我觉得上手门槛太高，得调一堆旋钮。但公司要求我用 AI，我也真的试过。'然后就是：'这个太好了，那些事我都不用干了。'"* Sharadh 解释道。
今天，83% 的 Stripe 员工每周都在用 Kai，会话数超过 6 万次。按比例算，市场（95%）和 GTM 团队（87%）这类业务职能的使用率，甚至比工程团队还高；他们形容 Kai 对备单（deal preparation）这件事是变革性的——从多个内部数据源拉数据、综合、再产出能直接用的产出物。财务团队则发现它在数据分析和看板生成上同样好用。
一些最生动的早期反馈：
- *"Kai 对销售来说简直难以置信。这能省下数万小时。"*
- *"我在 Stripe 的职业生涯，可以分成 Kai 之前和 Kai 之后。"*
新人开始用 Kai 来加速入职。工程团队呢——尽管 Kai 是为非工程师做的——却发现自己也把它当成了工作副驾：用 Kai 回答关于自己系统的问题，还拿它跑自家的 trace 和使用数据，找出 skill 的覆盖缺口并补齐。
下一步：跑通 PMF 之后
快速普及之后，现在团队摊上的是个幸福的烦恼——有上千个使用场景等着修、等着建。
让 skill 选择规模化。 Stripe 已经超过 500 个内部 MCP 工具、1000 多个 skill。面对这个量级的 skill 目录，没有哪个 LLM 能在没有辅助的情况下可靠地做出选择。团队正在搭一套混合选择系统。在当前规模下，纯 LLM 选择效果不错，而且在完整上下文可用时比 RAG 结果更好；但规模再上去，就需要一层 RAG 或分类器先做预筛，再让 LLM 做最终决定。
治理与护栏。 随着采用扩散到几千名员工，团队正在安全与合规护栏上加大投入，确保 Kai 的能力边界不会跑到企业环境所需的监督机制前面去。
行为层面的个性化。 不同团队想要的 agent 行为不一样。有的希望 Kai 永远先规划再动手、并主动提澄清问题；有的做快速头脑风暴时，只想要又快又直接的答案。*"这个产品的整个承诺就是：你不需要调旋钮，"* Sharadh 重复道，*"所以现在我们把责任接了过来——去构建这份智能，替用户把这些都判断好。"* 团队正在评估 ML 分类器和 AI 驱动的机制，让行为能自动适配用户的上下文。
跨会话协作。 当前模式是单用户会话。路线图会延伸到共享 skill、共享产出物，最终做到协作式会话——多名员工可以一起在同一份 AI 产出上迭代。
---
*Kai 建在 Deep Agents 之上，那是 LangChain 的开源 agent harness。如果你正在做生产级 agent，Deep Agents 文档 是个不错的起点。*