Coding agents transformed engineering at Stripe, but non-engineers like sales reps, finance analysts, technical account managers, and others felt left behind by the AI wave of Claude Code and Codex. No existing tool could handle the data security requirements and specific workflows Stripe needed: querying data warehouses, researching accounts before sales calls, triaging incidents, modeling revenue scenarios, or preparing compliance reviews. That all changed when we shipped Stripe’s knowledge AI platform.编码智能体（Coding agents）彻底改变了 Stripe 的工程实践，但销售代表、财务分析师、技术客户经理等非工程人员却在 Claude Code 和 Codex 引领的 AI 浪潮中感到被遗忘。当时没有任何现有工具能够满足 Stripe 所需的数据安全要求和特定工作流，例如查询数据仓库、在销售电话前进行账户调研、分类处理事件、模拟收入情景或准备合规性审查。而当我们推出 Stripe 的知识 AI 平台后，这一切都改变了。
Within two weeks of our April launch, most of Stripe was using Stripe's Knowledge AI Platform, also known as Kai. Today, 83% are weekly active users, including nearly all of GTM (marketing, sales, customer success managers, and technical account managers). Most Kai sessions require many turns, with users doing deep research, creating specific artifacts, or refining assets before sharing internally or externally. With Kai, everyone at Stripe has an agent built specifically to help them with their day-to-day work.在 4 月份发布后的两周内，Stripe 大部分员工都开始使用 Stripe 的知识 AI 平台，即 Kai。如今，83% 的员工是每周活跃用户，其中包括几乎所有的 GTM（市场、销售、客户成功经理和技术客户经理）团队。大多数 Kai 会话都需要多轮交互，用户在进行深度调研、创建特定工件或在内部或外部共享资产前进行完善。有了 Kai，Stripe 的每位员工都拥有了一个专门协助他们完成日常工作的智能体。
Why we built a Knowledge AI Platform我们为何要构建知识 AI 平台
For coding tasks, the specific change varies, but the workflow and tools needed to perform the task stay about the same. You edit files, run tests, commit. The programming languages vary, but the shape of the work is rather uniform, which is why a single agent architecture works well. Knowledge work is the opposite side of that spectrum. Tasks like researching an account or preparing a compliance review require different tools, different data, different outputs, and different definitions of "done".对于编码任务，具体的变更内容虽有不同，但执行任务所需的工作流和工具基本保持不变。你需要编辑文件、运行测试、提交代码。编程语言或许不同，但工作形态相当统一，这就是单一智能体架构能够有效运作的原因。知识型工作则处于这一光谱的另一端。调研账户或准备合规性审查等任务需要不同的工具、不同的数据、不同的输出，以及对“完成”的不同定义。
Before Kai, we had two AI options for knowledge work:在 Kai 出现之前，我们在知识型工作方面有两种 AI 选择：
- NoCode Agent Builder: Anyone could build and deploy workflow-specific agents that could use tools. Over 4,000 agents were built using this system. However, we quickly noticed that teams were writing conceptually similar prompts but with varying levels of quality, and found the proliferation of these micro-agents increasingly hard to monitor and maintain.无代码智能体构建器（NoCode Agent Builder）：任何人都可以构建并部署能够使用工具的特定工作流智能体。使用该系统构建的智能体超过 4,000 个。然而，我们很快注意到，各团队编写的提示词在概念上相似，但质量参差不齐，且这些微型智能体的激增使得监控和维护变得越来越困难。
- Coding agents: Coding agents were powerful, but they introduced a different set of risks. Since our goal is to enable improved productivity for all of Stripe, some users altered their workflows and chose coding agents. However, security concerns quickly emerged, along with a new support burden for code quality teams that had never supported non-engineers before.编码智能体：编码智能体功能强大，但引入了另一系列风险。由于我们的目标是提高 Stripe 全员的生产力，一些用户改变了他们的工作流并选择了编码智能体。然而，安全隐患随之而来，代码质量团队也面临着前所未有的新支持负担，因为他们此前从未支持过非工程人员。
From these experiences, we realized that building a knowledge AI platform required getting three things right: scaling expertise without centralizing it, meeting users wherever they work, and enforcing guardrails that don't exist in code.基于这些经验，我们意识到构建知识 AI 平台需要做好三件事：在不进行中心化管理的前提下扩展专业知识、在用户工作的地方提供服务，以及强制执行代码中不存在的护栏。
Scaling expertise without centralizing it在不中心化管理的前提下扩展专业知识
The range of expertise required to serve Stripe’s users is staggering. The people who know how to triage a billing escalation or model a revenue scenario are not centralized and certainly aren't on the team building the agent infrastructure. They're distributed across dozens of specialized domains – GTM, Finance, Marketing, Legal, Data Science, and more – each with its own tools, data sources, workflows, and judgment about what "good" looks like. Multiply this across all the products and countries Stripe operates in, and the result is astonishingly complex. Kai has to model that complexity in a way that makes it invisible, so that the task just works.服务 Stripe 用户所需的专业知识范围极其惊人。那些知道如何分类处理计费升级或模拟收入情景的人员并非集中在一起，当然也不在构建智能体基础设施的团队中。他们分布在数十个专业领域——GTM、财务、市场、法务、数据科学等——每个领域都有自己的工具、数据源、工作流以及对什么是“好”的判断。将此扩展到 Stripe 运营的所有产品和国家，结果极其复杂。Kai 必须以一种使这种复杂性隐形的方式进行建模，从而让任务能够顺畅执行。
The agent has to roam智能体必须能够“漫游”
Where the agent surfaces matters as much as what it knows. Not everyone works in a browser tab, and fewer still in a terminal. So a knowledge agent can't just be a single product; it has to be a platform, flexible enough to embed itself wherever work happens.智能体出现在哪里，与它知道什么同样重要。并非每个人都在浏览器标签页中工作，在终端中工作的人就更少了。因此，知识智能体不能仅仅是一个单一的产品；它必须是一个平台，足够灵活，能够嵌入到工作发生的任何地方。
For example, consider an internal application our Finance team uses to model complex changes in Stripe's operating budget: the agent needs to read the context, research related documents, propose valid changes, and summarize the differences, all without pulling them out of the app.例如，考虑我们财务团队用于模拟 Stripe 运营预算复杂变更的内部应用程序：智能体需要读取上下文、研究相关文档、提出有效变更并总结差异，所有这些都无需让用户离开该应用程序。
Building a standalone agent product wouldn't work. Instead, it would force users out of their natural workflows and into a new app. Building a separate agent product for each surface wouldn’t work either; it’d be hard to maintain, and users who span multiple tools would have a fractured experience. The platform has to meet the user where they are.构建独立的智能体产品行不通。这会迫使用户离开他们的自然工作流进入一个新应用。为每个界面构建单独的智能体产品也行不通；维护难度大，且跨越多个工具的用户体验会支离破碎。平台必须在用户所在的地方提供服务。
Building guardrails from scratch从零开始构建护栏
Coding agents operate in an environment with decades of fast, verifiable guardrails: compilers reject invalid syntax, tests catch regressions, and git makes every mistake reversible. Knowledge work has very little support for these constructs.编码智能体运行在一个拥有数十年快速、可验证护栏的环境中：编译器拒绝无效语法，测试捕获回归问题，而 git 使每一个错误都可以撤销。知识型工作对这些架构的支持很少。
Consider a core invariant at Stripe: “you shouldn't combine data from two unrelated customer contexts in a single analysis.” A user may have legitimate access to both contexts independently, but they can never appear in the same session. The isolation boundary isn't "what can this person access based on their authorization token?", but instead "what should this task be allowed to view given this context?" The platform has to enforce these implicit guardrails that users rely upon.考虑 Stripe 的一个核心不变性原则：“你不应该在单一分析中合并两个不相关的客户上下文的数据。”用户可能独立拥有对这两个上下文的合法访问权限，但它们绝不能出现在同一个会话中。隔离边界不是“此人根据其授权令牌可以访问什么？”，而是“鉴于此上下文，此任务应该被允许查看什么？”平台必须强制执行用户所依赖的这些隐含护栏。
How we built Kai我们是如何构建 Kai 的
A single monolithic agent simply cannot encode all of these constraints effectively. And, asking every domain team to independently build secure, hosted, performant agent infrastructure doesn't scale either. To manage this challenge, we built Kai in three layers:单一的单体智能体根本无法有效地编码所有这些约束。而且，要求每个领域团队独立构建安全、托管且高性能的智能体基础设施也无法扩展。为了应对这一挑战，我们分三层构建了 Kai：
- Surface-agnostic APIs that give multiple interfaces into the same agent与界面无关的 API，为同一智能体提供多个接口
- AgentStudio where domain owners build and govern their own Kai agents, andAgentStudio，领域所有者在此构建和管理他们自己的 Kai 智能体
- Execution environments to deliver security in seconds without anyone thinking about infrastructure.执行环境，无需任何人考虑基础设施即可在几秒钟内提供安全保障。
Surface-agnostic APIs与界面无关的 API
Kai ships with an opinionated web application and a Slack integration, but the main primitive is the underlying API that powers them both. The agent is a service, not an application, and surfaces are simply customized views into it.Kai 自带一个特定设计的 Web 应用程序和 Slack 集成，但主要原语是驱动两者的底层 API。智能体是一项服务，而不是一个应用程序，界面只是对其的自定义视图。
Most Stripes interact with Kai through the internally hosted web application. There's no infrastructure to set up – it's available to every employee on Day 0.大多数 Stripe 员工通过内部托管的 Web 应用程序与 Kai 交互。无需设置基础设施——每位员工从第一天起即可使用。
Any internal tool can also embed Kai, and many have chosen to do so. For example an employee working in our business intelligence platform can ask Kai a question from within their existing application because our Chrome extensions surface Kai capabilities inside web-based third-party tools.任何内部工具也可以嵌入 Kai，许多团队已经选择了这样做。例如，在我们的商业智能平台工作的员工可以在现有应用程序内向 Kai 提问，因为我们的 Chrome 扩展程序在基于 Web 的第三方工具中呈现了 Kai 的功能。
Custom applications embed Kai via APIs to bring agentic experiences to all workflows自定义应用程序通过 API 嵌入 Kai，为所有工作流带来智能体体验
AgentStudioAgentStudio
AgentStudio is the control plane for domain owners. Teams use it to build, test, and monitor their skills, custom Kai agents, and tool selections. A GTM team, for example, owns a Kai agent tuned to their workflows. It loads their skills by default, connects to their data sources, and presents outputs in the format their users expect. AgentStudio surfaces usage data and quality signals alongside each asset, so domain owners can see what's working without asking the platform team.AgentStudio 是领域所有者的控制平面。各团队使用它来构建、测试和监控他们的技能、自定义 Kai 智能体以及工具选择。例如，GTM 团队拥有一个针对其工作流调整的 Kai 智能体。它默认加载他们的技能，连接到他们的数据源，并以用户期望的格式呈现输出。AgentStudio 在每个资产旁边显示使用数据和质量信号，因此领域所有者无需询问平台团队即可了解哪些功能有效。
Skills are organized into areas across Stripe that are managed by domain experts技能被组织到 Stripe 各个领域中，由领域专家进行管理
The execution environment执行环境
This is the layer that makes the platform's promises real. The core primitives, including the agent harness, sandbox, workflow orchestration, and access control framework, are deliberately shared with Stripe's product-facing agents. Internal knowledge work operates on the same sensitive data and serves the same users as our external products, so it requires the same security and compliance bar. Sharing the substrate forces discipline and creates a flywheel: improvements to the execution environment benefit both internal and product agents simultaneously.这是实现平台承诺的层级。核心原语，包括智能体工具包、沙盒、工作流编排和访问控制框架，有意与 Stripe 面向产品的智能体共享。内部知识型工作在相同敏感数据上运行，并服务于与我们外部产品相同的用户，因此它需要相同的安全和合规标准。共享底层架构强制执行纪律并创造了飞轮效应：对执行环境的改进同时造福内部和产品智能体。
The agent harness, built using LangChain’s deepagents, runs on Kubernetes with a secure per-session sandbox and a multi-tenant virtual filesystem. Within a session, the agent works with a virtual filesystem where it creates and iterates on artifacts, while a secure code execution sandbox is used for analytics and data processing.使用 LangChain 的 deepagents 构建的智能体工具包在 Kubernetes 上运行，具有安全的每会话沙盒和多租户虚拟文件系统。在会话中，智能体使用虚拟文件系统创建和迭代工件，而安全的代码执行沙盒则用于分析和数据处理。
It's built to hold state across long, complex sessions — one recently reached 932 turns. With Kai’s deep task management capabilities, a single conversation can consist of hundreds of turns, and hundreds of tool and LLM calls without timing out or overloading the context window. This matters because knowledge work is rarely a single question. It's iterative reasoning that builds on itself, and the session has to hold that state without degrading.它旨在跨越漫长、复杂的会话保持状态——最近一个会话达到了 932 轮。凭借 Kai 的深度任务管理功能，单个对话可以包含数百轮交互，以及数百次工具和 LLM 调用，而不会超时或耗尽上下文窗口。这一点很重要，因为知识型工作很少是单一问题。它是建立在自身基础上的迭代推理，会话必须在不降级的情况下保持该状态。
User behaviors are changing, and sessions are increasingly used for deep multi-turn collaboration用户行为正在发生变化，会话越来越多地用于深度的多轮协作
One of the most interesting parts of the harness is how it chooses the correct skill to use. Kai is connected to 1,000+ skills and tools spanning various internal systems – from business intelligence dashboards that track key metrics, to project management tools that organize internal execution, and third-party services like Zoom and Google Workspace. Anyone can ask it a question and trust it will load the right context and use the right tools to get the job done. Coding agents have a natural advantage here: the folders they work provide a natural organization for skills and context. In a follow-up post, we’ll go into how we solved this without that pre-existing structure by utilizing a hybrid RAG/LLM approach, among other techniques.工具包中最有趣的部分之一是它如何选择使用的正确技能。Kai 连接到 1,000 多种技能和工具，涵盖各种内部系统——从跟踪关键指标的商业智能仪表板，到组织内部执行的项目管理工具，再到 Zoom 和 Google Workspace 等第三方服务。任何人都可以向它提问，并确信它会加载正确的上下文并使用正确的工具来完成工作。编码智能体在这里有天然优势：它们工作的文件夹为技能和上下文提供了自然的组织方式。在后续文章中，我们将介绍如何利用混合 RAG/LLM 方法等技术，在没有这种预先存在结构的情况下解决这个问题。
Impact影响
The results have been striking. New hires on GTM are Kai-native: they use it 2.7x more, and power users close 80% more value than low users within the same cohort. When Account Executives use Kai, they produce 2x the sales activity, create 17% more opportunities, generate 26% more revenue opportunities, and close 39% more deals when compared to the same sellers in weeks they don't use it. In aggregate, Kai has helped shift 25,000 hours per year from administrative work, to revenue generating work.结果非常显著。GTM 的新员工是 Kai 的原生用户：他们的使用频率高出 2.7 倍，且在同一群体中，高频用户创造的价值比低频用户高出 80%。当客户主管（Account Executives）使用 Kai 时，与他们不使用 Kai 的周次相比，他们的销售活动产出增加 2 倍，创造的机会增加 17%，产生的收入机会增加 26%，成交量增加 39%。总体而言，Kai 每年已帮助将 25,000 小时的行政工作转移为创收工作。
In finance and operations, Kai is helping Stripes analyze messy data, generate recurring digests, and turn fragmented context into usable artifacts.在财务和运营领域，Kai 正在帮助 Stripe 员工分析杂乱的数据、生成定期摘要，并将碎片化的上下文转化为可用的工件。
In engineering, Kai is now a natural place to ask system questions, research for run requests, analyze logs, draft plans, and invoke more specialized agents and skills.在工程领域，Kai 现在是询问系统问题、研究运行请求、分析日志、起草计划以及调用更专业智能体和技能的自然场所。
And across Stripe, more than 5,000 sessions everyday center on data analysis. This makes Kai a unique leverage point: by plugging in the right context about data quality and our analytics layer, we can ensure correct responses by default for most questions.在整个 Stripe，每天有超过 5,000 个会话以数据分析为中心。这使得 Kai 成为一个独特的杠杆点：通过插入关于数据质量和我们分析层的正确上下文，我们可以确保大多数问题默认得到正确的回答。
Stripes’ direct feedback backs up these aggregates: they report feeling “empowered to embrace AI” and “astounded at what Kai just does precisely correct”. But our favorite anecdote is a non-engineer who left a Kai intro session and immediately collaborated on a digest that pulls together Asana, Slack, and Jira into a single automated process.Stripe 员工的直接反馈支持了这些汇总数据：他们报告称感到“有能力拥抱 AI”，并对“Kai 能够如此精准地完成任务”感到震惊。但我们最喜欢的轶事是一位非工程人员，他在参加完 Kai 入门课程后，立即合作完成了一份摘要，将 Asana、Slack 和 Jira 整合到一个自动化的流程中。
We haven’t won yet我们尚未获胜
At Stripe, one of our favorite catchphrases is “we haven’t won yet”, and that’s apt for Kai. We’re in the earliest stages of this journey, and have a lot more we want to do:在 Stripe，我们最喜欢的口号之一是“我们尚未获胜”，这对 Kai 来说非常贴切。我们正处于这段旅程的最早阶段，还有很多想做的事情：
- Better state management: General-purpose agents like Kai generate a lot of state as they iteratively make tool calls, pull down large documents, and more. We are continuously tuning both the “active” context being sent to the LLM and the “extended” context sitting in state stores like S3 or the virtual file system.更好的状态管理：像 Kai 这样的通用智能体在迭代进行工具调用、下载大型文档等操作时会产生大量状态。我们正在不断调整发送给 LLM 的“活动”上下文以及存储在 S3 或虚拟文件系统等状态存储中的“扩展”上下文。
- Reflection and self-improvement: We are working on a quality improvement loop that lets Kai reflect on traces involving a skill, propose improvements, test them, and submit changes for the skill owner to review.反思与自我提升：我们正在研究一个质量改进循环，让 Kai 能够反思涉及某项技能的跟踪记录，提出改进建议，对其进行测试，并提交更改供技能所有者审查。
- Better collaboration primitives: Users generate a lot of context in their Kai sessions that is currently “locked in”, but that’s not how work gets done. We want to let people share what Kai surfaces across sessions, and let multiple people (and agents!) collaborate on the same artifacts.更好的协作原语：用户在 Kai 会话中生成了大量上下文，目前这些上下文是“锁定”的，但工作并不是这样完成的。我们希望让人们能够跨会话共享 Kai 提供的信息，并让多个人（和智能体！）能够协作处理相同的工件。
Coding agents made AI feel concrete for software engineers first. Kai has helped bring that same sense of leverage to knowledge workers across Stripe. It’s interesting because while we have improved productivity considerably, we don't know the ceiling yet - and we’re excited to keep pushing the envelope here. If building agentic systems that power internal productivity and external agents sounds like your kind of challenge, we’re hiring.编码智能体首先让软件工程师感受到了 AI 的具体作用。Kai 帮助将同样的杠杆效应带给了 Stripe 的知识工作者。有趣的是，虽然我们已经显著提高了生产力，但我们还不知道上限在哪里——我们很高兴能继续在这里突破界限。如果构建驱动内部生产力和外部智能体的智能体系统听起来是你喜欢的挑战，我们正在招聘。