Stripe 如何基于 Deep Agents 在一周内构建企业知识 AI 平台 Kai

全球有数百万家企业依托 Stripe 的支付与金融基础设施平台运转。为了支撑大规模的产品持续交付与迭代，Stripe 打造了一套 AI 工具体系，助力全员提升工作效率。Stripe 的 AI 平台团队负责统筹支撑公司所有 AI 应用的技术底座。他们打造的最具代表性的产品是 Stripe 知识 AI 平台（Stripe’s Knowledge AI Platform，简称为 Kai）。这是一款全员普及的生产力智能体，基于 LangChain/LangGraph 技术栈及 Deep Agents 智能体框架构建而成。

下方这段两分钟的视频介绍了 Stripe 如何基于 Deep Agents 在短短一周内构建出 Kai。

自研智能体框架

随着智能体 AI 的应用步伐加快，Stripe 内部的各工程团队开始在现有的 Ruby 和 Java 技术栈之上搭建编排层。将这些系统与 Stripe 的内部基础设施对接相对容易，但要打造一个稳定可靠、达到生产级水准的智能体框架，却带来了不少新挑战。

高效的智能体系统不仅需要实现接口连通，还要具备出色的性能、严密的评估体系以及稳定处理复杂任务的能力。团队经常发现，早期的实现方案应付简单场景尚可，但若想在大规模应用中持续输出可靠的结果，仍需投入更多精力进行优化。

2024 年底 Claude Code 发布后，Stripe 员工几乎人人都在跃跃欲试想要打造自己的智能体。然而对非技术人员而言，终端命令行、数据权限和安全配置成了难以逾越的高门槛。Agent Foundation 团队的工程经理 Sharadh Krishnamurthy 与主任软件工程师 Anupam Upadhyay 提出了一个截然相反的思路：与其强推非技术员工去适应开发者工具，为什么不主动迎合他们的工作习惯，量身定制一款工具？换言之，“要是每个人都能拥有一个全天候在线、达到生产级水准的助手会怎样？”这一思考最终孕育出了 Stripe 知识 AI 平台。

面向每位 Stripe 员工的上下文感知型 AI 协作者

Stripe 知识 AI 平台面向全体员工开放。它专为大多数 Stripe 员工的日常核心工作量身定制——涵盖数据综合、头脑风暴、文档起草、趋势分析和跨部门协作。用户只需通过一个基于会话的单一交互界面，即可打通 Stripe 的内部数据仓库、Slack 和 Google Suite。

用户开启会话后通过聊天进行交互，Kai 随之生成各类产物、报告、数据看板或文档，与对话界面并列展示。随着对话持续，这些产物也会随之迭代演变。它的运作方式就如同面向非工程师的代码智能体。

与通用 AI 助手不同，Kai 预先整合了丰富的工具与技能，天然具备 Stripe 的背景上下文。它深谙 Stripe 的运转机制，熟悉公司的内部系统、数据源和业务规范。每次下达任务前，用户根本无需向 Kai 额外解释自己的职责角色或公司背景。此外，来自全公司各领域的业务专家还通过技能库贡献自己的专业知识，目前该库已汇集了 100 多个团队沉淀的 1000 多项技能。

Deep Agents 为 Stripe 奠定了智能体底层底座，让团队得以专注于特定领域的业务工作流

Kai 的技术底座是 LangChain 推出的开源智能体框架 Deep Agents。它提供了现成的底层架构，将工具调用循环、中间件组合、流式传输和状态管理等关键模块无缝串联在一起；如果从零开始构建并将其打磨稳健，往往需要耗费数月时间。

Stripe 的分层架构包括：

底层是 Deep Agents：基础层负责处理所有大模型交互原语，包括请求管理、智能体执行以及中间件编排。
基于 Deep Agents 构建的 Stripe 专属 Harness 层：该中间层将 Kai 接入 Stripe 的安全体系、基础设施和内部服务，构建出一套定制化的运行环境。
配置层：团队可以在 Harness 之上配置定制的 Kai 智能体，打造具备不同技能集、行为和人设的专用智能体实例，无需改动底层的 Harness。
Kai 用户界面：大多数 Stripe 员工日常交互的产品界面，自上而下串联起所有三个层级。

“Deep Agents 层解决了所有与 Stripe 业务无关的通用难题，让我们能专心处理 Stripe 特有的智能体需求，”Sharadh 解释道。“你可以直接开箱即用各种中间件。可组合的技能模式与复合后端既搭建了合理的骨架，又保留了充足的灵活性。”

Kai 具备生产级可用性的秘诀

Anupam 仅用一周就搭建出了 Kai 的初代版本。让这种高速度成为可能的 Deep Agents 中间件包括：

文件系统中间件：Kai 是一项运行在云端的生产级服务，而非本地进程。Stripe 构建了基于 S3 的虚拟文件系统，让智能体可以在多轮交互中读写并引用文件作为上下文。文件系统非常适合充当大模型的上下文，因为它可以把上下文转化为模型能够随时查看、更新和归纳整理的对象。Stripe 在调用沙箱 execute 时引入了“同步入 / 同步出”（sync in / sync out）模式：执行前，所有相关文件都会实例化到沙箱中；执行后，新增或修改的文件会同步写回虚拟文件系统。这样一来，无论智能体还是驱动它的大模型，在整个会话生命周期内都能拥有连贯一致且持久存在的文件环境。
沙箱中间件：Kai 借助沙箱环境来执行两类代码任务：数据分析（编写并运行 Python 代码以查询数据、生成图表）和处理各类文件格式（PDF、演示文稿、结构化文档）。沙箱作为工具提供给智能体调用，而非智能体本身的运行环境。智能体在沙箱之外运行，仅在需要时调用沙箱，从而保持清晰的执行边界，有效防范了大模型生成代码带来的一系列安全风险。
摘要中间件：对于多轮长时间运行的会话来说，这是管理上下文的关键；若不加以控制，累积的上下文不仅会降低性能，还会触发模型的长度上限。Kai 尤其擅长处理长期的多轮会话。为了在控制成本的同时充分利用大模型的有效上下文，Kai 利用了 deepagents 库提供的各种调节参数，例如摘要阈值、摘要模型选择及输出长度等。由于大多数用户使用 Kai 的会话都是断断续续的，避免超大上下文导致的缓存未命中，有助于更好地控制成本。

技能体系：Kai 如何驾驭数百种内部工具与工作流

Kai 借助“技能”（Skills）贯通了数百种内部工具与工作流。在 Deep Agents 中，技能是结构化、可供智能体执行的模块。每项技能都封装了如何完成特定任务、需要加载哪些工具以及如何应对某类工作的方法流程。

Stripe 采用联邦式架构，由各个团队自主拥有并维护各自的技能。基础版 Kai 智能体自带一组基础技能，涵盖 Stripe 的通用导航功能；系统还会根据用户画像以及当前使用的特定 Kai 智能体配置，动态加载不同层级的附加技能。例如，销售运营人员获取的技能集就与财务人员不同；此外，用户画像层还允许个人在岗位默认技能的基础上，自行添加更多技能。

面对 500 多个内部 MCP 工具和不断扩充的技能库，Kai 无法把所有内容一股脑塞进上下文。Agent Skills 的 allowedTools 列表驱动了工具的动态加载，形成了一套双轮机制：先由技能筛选来控制工具上下文的准入，而不是预先加载所有工具。技能筛选直接交由已掌握相关上下文的大模型完成。Anupam 解释道：“大模型会花精力判断该加载哪些技能，我们正好顺水推舟，依据它的判断来加载对应的工具。”同时，某些基础技能会被常驻置顶，无论模型决定加载或卸载什么都不会受影响，从而确保 Stripe 的上下文背景和策略规范始终保持一致。

由于 frontmatter 有 1024 个字符的限制，团队发现，当技能数量超过 150 个并与系统提示词结合时，顶尖前沿模型的表现会出现下滑。技能数量的管理目前仍是一大挑战，团队正在积极探索更好的应对方案。

1 名工程师，1 周时间：Stripe 押注 Python 为何立竿见影

十多年来，Stripe 内部的工具链、安全层和部署支持体系都是围绕 Ruby 和 Java 搭建的。转向原生 Python 技术栈，意味着要围绕一门新语言彻底重构 Stripe 的内部服务脚手架，这无疑是一笔巨大的投入。

Kai 用实际成果证明了这笔投入的投资回报率。仅凭一名工程师，用时短短一周就搭建起了 Kai。得益于 Deep Agents 提供的底层原语，棘手的智能体基础设施问题早已迎刃而解。这种惊人的开发速度表明，Stripe 在内部构建 Python 支持所投入的时间立刻得到了回报。AI 平台负责人 Chrissie 强调：“Kai 彻底坚定了大家的信念：选择 Deep Agents 是完全正确的道路。”

一周达成 Kai 的季度推广目标

Kai 开启公开预览后，仅用一周时间就达成了团队设定的季度使用量目标；随后约 4 周内，用户数更是从 296 人暴增至 5000 多人，增长超 16 倍。Sharadh 表示：“它一下子就火了。大家一上手，立刻就明白了它的价值。”

这批新用户绝大多数正是团队的目标受众：销售人员、财务分析师、业务运营人员——这些员工一直被要求“拥抱 AI”，却从未找到真正契合自身工作流的工具。Sharadh 解释说：“很多人反馈：‘之前的工具让人望而却步，得调一堆参数。但公司又让我用 AI，我也确实认真试过了。’接着他们发现：‘这个太棒了，完全不用折腾那些复杂的设置。’ ”

如今，Stripe 全公司有 83% 的员工每周都会使用 Kai，周会话量超过 6 万次。在市场（95%）和 GTM（87%）等业务职能部门，Kai 的普及率甚至超过了工程部门；他们认为 Kai 彻底改变了交易筹备流程，能够从多个内部数据源抓取数据、完成汇总，并直接生成可用的交付成果。财务团队也同样发现，它在数据分析和仪表板生成方面大有裨益。

一些极具代表性的早期用户反馈如下：

“Kai 对销售人员来说简直不可思议，能省下几万个小时的时间。”
“我在 Stripe 的职业生涯，可以分为有了 Kai 之前和有了 Kai 之后。”

新员工开始用 Kai 来加速熟悉工作流程。工程团队虽然最初是为非技术人员打造的 Kai，后来却发现自己也把它当作日常工作的辅助工具：不仅用 Kai 解答关于自有系统的问题，还拿它分析自身的链路追踪与使用数据，以找出技能盲区并扩大覆盖范围。

下一步规划：找到 PMF 之后

在经历了迅猛普及之后，团队现在迎来了一个“甜蜜的烦恼”：需要优化和支持的使用场景实在太多了。

大规模技能筛选。Stripe 内部已经拥有超过 500 个 MCP 工具和 1000 多项技能。面对如此庞大的技能目录，任何大语言模型在没有辅助机制的情况下都无法做出可靠筛选。团队目前正在开发一套混合筛选系统：在现有规模下，单纯依靠大模型筛选效果很好，且在上下文完整时的表现优于 RAG；但随着规模持续扩大，未来需要引入 RAG 或分类器层进行前置初筛，再交由大模型做最终决策。

治理与安全防护栏。随着使用人群扩展到数千名员工，团队正大力投入安全与合规防护机制建设，确保 Kai 的应用范围不会超出企业级环境所需的监管架构。

行为层面的个性化。不同团队对智能体的行为期望大相径庭：有的希望 Kai 凡事先规划并主动追问细节；有的则想要直截了当的快速回答，方便快速头脑风暴。Sharadh 重申道：“这款产品的核心承诺就是让用户根本不用手动调参。因此，我们必须承担起责任，打造出足够智能的系统来替大家处理好这些差异。”团队目前正在评估机器学习分类器与 AI 驱动机制，从而根据用户上下文自动调整智能体的行为模式。

跨会话协同。目前的模式仍是单人独立会话。未来的规划将延伸至技能共享、成果共享，并最终实现支持多名员工就同一项 AI 产出协同迭代的协作会话。

Kai 基于 LangChain 的开源智能体框架 Deep Agents 构建。如果你正着手打造面向生产环境的智能体，不妨从 Deep Agents 文档开始了解。

‍