Stripe 如何基于 Deep Agents 在 1 周内构建公司级 AI 智能体 Kai

Stripe 是数百万企业使用的全球支付与金融基础设施平台。为了支持大规模的产品持续迭代与发布，他们构建了 AI 工具，帮助全公司员工提升生产力。Stripe 的 AI 平台团队负责构建支撑公司所有 AI 应用的底层技术栈。他们最瞩目的产品是 Stripe 的知识 AI 平台（Knowledge AI Platform），又名 Kai——这是一个基于 LangChain/LangGraph 技术栈及 Deep Agents 框架构建的全公司级生产力智能体。

打造内部智能体开发框架

随着 AI 智能体（Agent）应用的加速普及，Stripe 内部的各工程团队开始基于现有的 Ruby 和 Java 技术栈构建编排层。将这些系统与 Stripe 的内部基础设施对接相对简单，但构建一个可靠、达到生产级标准的智能体开发框架（Agent Harness）却带来了新的挑战。

高效的智能体系统不仅需要实现连接，还需要强劲的性能、完善的评估机制，以及稳定处理复杂任务的能力。各团队经常发现，初始实现方案在简单场景下表现尚可，但若想在大规模应用中提供稳定可靠的结果，则需要进一步的投入。

随着 Claude Code 在 2024 年底推出，几乎每位 Stripe 员工都渴望构建智能体。但对于非工程人员来说，命令行终端、数据访问权限和安全合规等成了巨大的门槛。Agent Foundation 团队工程经理 Sharadh Krishnamurthy 与资深软件工程师 Anupam Upadhyay 提出了一个逆向思路：与其把非技术员工推向开发者工具，不如投其所好，为他们量身打造一款产品？换句话说，“如果人人都能拥有一个全天候在线、生产就绪的助手，会怎样？” 答案就是 Stripe 的 Knowledge AI Platform。

属于每位 Stripe 员工的上下文感知 AI 同事

Stripe 的 Knowledge AI Platform 面向全员开放。它专为大多数 Stripe 员工的日常工作而设计——涵盖数据汇总、头脑风暴、撰写文档、分析趋势以及跨部门协作。这一切都在一个单会话界面中完成，并已深度接入 Stripe 的内部数据仓库、Slack 和 Google Workspace。

用户开启会话后通过聊天互动，Kai 会随之生成产物、报告、仪表盘或文档，并展示在对话旁。随着聊天的深入，这些产物也会持续演进。它的工作模式就像是专门面向非工程师的“代码智能体”。

与通用 AI 助手不同，Kai 通过工具和技能（Skills）预载了丰富的 Stripe 上下文。它深谙 Stripe 的运转逻辑，理解公司的内部系统、数据源和工作规范。用户在执行具体任务前，无需每次都向 Kai 解释自己的职位职责或公司背景。此外，来自各个领域的专家也通过技能库贡献着各自的专业知识，该技能库汇集了来自 100 多个团队的 1000 多项技能。

Deep Agents 为 Stripe 提供智能体底座，让团队专注于特定领域的业务工作流

Kai 的底层是 Deep Agents——LangChain 开源的智能体开发框架。Deep Agents 提供了核心基础设施，集成了工具调用循环、中间件组合、流式传输和状态管理，如果从零开始构建并打磨这些功能，往往需要耗费数月时间。

Stripe 的分层架构包括：

1. 以 Deep Agents 作为底层：基础层负责处理所有 LLM 交互原语，包括请求管理、智能体执行和中间件组合。
2. 基于 Deep Agents 构建的 Stripe 专属框架：中间层将 Kai 无缝融入 Stripe 的安全体系、基础设施和内部服务，打造定制化的运行环境。
3. 配置层：在框架之上，各团队无需修改底层代码，即可自由配置专属的 Kai 智能体，包括具备不同技能集、行为特征和人设的定制化智能体实例。
4. Kai UI：大多数 Stripe 员工直接交互的产品界面，贯穿向下连接所有三个层级。

“Deep Agents 帮我们解决了所有非 Stripe 专属的技术难题，使我们能够专注于解决 Stripe 本身的业务问题。” Sharadh 解释道。“你可以直接使用现成的中间件。可组合的技能模式和复合后端既提供了合理的结构，又保留了足够的灵活性。”

让 Kai 达到生产就绪的关键因素

Anupam 在一周内就完成了 Kai 的初始版本开发。其中，Deep Agents 的以下中间件功不可没：

1. 文件系统中间件（Filesystem Middleware）：Kai 是运行在云端的生产级服务，而非本地进程。Stripe 构建了一个基于 S3 的虚拟文件系统，使智能体可以在多轮对话中将文件作为上下文进行读取、写入和引用。文件系统非常适合 LLM 上下文管理，因为它能将上下文转化为大模型可以随时间检查、更新和组织的实体。Stripe 在每次沙盒 execute 调用时都包裹了“入同步 / 出同步”模式：在执行前，所有相关文件都会实例化到沙盒中；执行后，任何新建或修改的文件都会同步回虚拟文件系统。因此，智能体及驱动它的 LLM 能在整个会话周期内获得连贯、持久的文件环境。
2. 沙盒中间件（Sandbox Middleware）：Kai 在隔离的沙盒环境中运行代码，主要处理两类工作：数据分析（撰写并运行 Python 以查询数据、生成图表）和处理任意文件格式（PDF、演示文稿、结构化文档）。沙盒作为一种工具暴露给智能体，而非智能体自身的执行环境。智能体在沙盒外部运行并调用沙盒，保持了清晰的执行边界，有效防止了 LLM 生成代码引发的一类安全隐患。
3. 总结中间件（Summarization Middleware）：对于管理长周期、多轮对话的上下文至关重要，否则积累的上下文会导致性能下降或超出模型限制。Kai 尤其擅长处理长周期多轮会话。为了在优化 LLM 上下文利用率的同时控制成本，Kai 充分利用了 deepagents 库提供的各种调节选项，例如总结阈值、总结模型以及输出大小等。大多数用户的使用习惯是间歇性运行 Kai 会话，因此避免大上下文尺寸导致的缓存未命中（Cache Miss）有助于有效控制成本。

技能：Kai 如何调度数百种内部工具与技能

Kai 借由“技能（Skills）”在数百种内部工具和工作流中游刃有余。Deep Agents 中的技能是结构化、可由智能体执行的模块。每项技能封装了如何完成特定任务、需要加载哪些工具以及如何应对某类工作。

Stripe 采取了联邦化管理模式，由各个团队各自维护和管理所属的技能。基础版 Kai 智能体自带涵盖 Stripe 通用导航的基础技能集，并会根据用户画像及具体的 Kai 智能体配置动态加载更多层级的技能。例如，销售运营人员获取的技能集与财务人员不同；而用户级别的个人画像层，又允许员工在部门默认设置的基础上叠加个性化技能。

面对 500 多个内部 MCP 工具和不断膨胀的技能库，Kai 无法将所有内容一次性加载至上下文。智能体技能（Agent Skills）的 allowedTools 列表驱动了动态工具加载，形成了一个“两阶段”系统：先通过技能选择来门控工具上下文，而非预先加载所有工具。这一选择过程依赖 LLM 本身已具备的相关上下文来进行判定。Anupam 解释道：“LLM 投入精力去判断需要加载哪些技能，而我们正是依赖这一判断来决定同步加载哪些相关工具。” 此外，某些基础技能会被“钉住”（Pinned），无论模型如何选择加载或卸载，这些技能都会始终保持存在，从而保障一致的 Stripe 上下文与策略行为。

由于 Frontmatter 存在 1024 字符的限制，团队发现当技能数量超过 150 个并与系统提示词（System Prompt）组合时，前沿模型的表现会出现质量下降。技能数量的管理目前仍是一个挑战，团队正积极寻找未来更好的解决方案。

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

十多年来，Stripe 围绕 Ruby 和 Java 构建了大量的内部工具、安全层和部署支持。拥抱原生 Python 技术栈意味着要围绕新语言重建 Stripe 的内部服务脚手架，这是一笔不小的投入。

而 Kai 用实际成果证明了这笔投入的高回报。仅靠一位工程师就在一周内完成了 Kai 的构建。 Deep Agents 提供的原语意味着最棘手的智能体基础设施问题已经迎刃而解。这种惊人的开发效率证明，为支持 Python 所付出的内部努力瞬间获得了回报。“Kai 彻底巩固了大家对 Deep Agents 是正确方向的信念，” AI 平台负责人 Chrissie 强调道。

在 1 周内达成季度用户增长目标

当 Kai 开启公开预览后，仅用一周时间就达到了团队预定的季度用户增长目标，并在大约 4 周内增长了 16 倍以上——活跃用户从 296 人飙升至 5,000 多人。Sharadh 表示：“它就像野火一样蔓延开来。大家一试用，立刻就爱不释手了。”

绝大多数新用户正是团队最初设计所面向的岗位：销售、财务分析师、业务运营人员——这些曾被要求“使用 AI”却始终没找到契合实际工作流程工具的员工。Sharadh 解释道：“很多人反馈说：‘我以前觉得那些工具门槛太高，需要手动调一堆参数。但我被要求去用 AI，我也确实试过了。’ 然后接着说：‘这个太棒了，我再也不用去折腾那些繁琐的设置了。’”

如今，83% 的 Stripe 员工每周都在使用 Kai，累计会话数突破 60,000 次。从使用率百分比来看，市场部（95%）和 Go-To-Market 团队（87%）等业务部门对 Kai 的采纳率甚至超过了工程部门。他们称 Kai 彻底改变了销售准备工作，能自动从多个内部数据源提取数据、进行综合分析并直接生成可用的产物。财务团队也同样发现它在数据分析和仪表盘生成方面极为实用。

一些最令人印象深刻的早期反馈包括：

• “Kai 对于销售人员来说简直不可思议，它将节省成千上万个小时。”
• “我的 Stripe 职业生涯可以划分为 Kai 出现之前和 Kai 出现之后。”

新员工开始借助 Kai 加速入职熟悉过程。而工程团队尽管最初是为非工程师打造的 Kai，却发现自己也在用它作为日常工作的 Copilot：利用 Kai 来解答有关自家系统的疑问，并在他们自己的 Trace 跟踪和使用数据上运行 Kai，以识别技能短板并提升覆盖率。

未来展望：迈向产品与市场契合（PMF）之后

在经历爆发式增长后，团队迎来了“幸福的烦恼”……眼前有上千个使用场景等待去优化和构建。

• 扩展技能选择机制：Stripe 内部已拥有 500 多个 MCP 工具和 1000 多项技能。如果不借助辅助手段，没有任何 LLM 能在此等规模的技能目录中做出稳定可靠的选择。团队目前正在构建一种混合选择系统。纯 LLM 选择在当前规模下表现良好，且在具备完整上下文时效果优于 RAG，但在更大规模下，需要引入 RAG 或分类器层进行预筛选，再由 LLM 做出最终决策。
• 治理与安全护栏：随着数千名员工的深入使用，团队正加大对安全和合规护栏的投入，确保 Kai 的能力扩张不会超出企业级环境所需的监管框架。
• 行为层面的个性化：不同的团队希望智能体具备不同的行为模式。有些团队希望 Kai 始终“先规划后行动”并提出澄清问题；而另一些团队则偏好快速、直接的回答以进行高效的头脑风暴。“这款产品的核心承诺就是‘无需用户手动调参’，” Sharadh 重申，“因此，我们承担起了构建智能化机制的责任，由系统自动为用户搞定这一切。” 团队目前正在评估 ML 分类器和 AI 驱动机制，以根据用户上下文自动调整行为。
• 跨会话协作：当前的模式是单用户会话。未来的路线图将扩展到共享技能、共享产物，并最终实现多名员工可以共同迭代同一 AI 输出的协作会话。

原文：https://www.langchain.com/blog/how-stripe-built-their-knowledge-ai-platform-on-deep-agents