编码 Agent 为 Stripe 的工程工作带来了变革，但销售代表、财务分析师、技术客户经理等非工程师群体，却觉得自己被 Claude Code 和 Codex 掀起的 AI 浪潮抛在了后面。现有工具都无法满足 Stripe 在数据安全要求和具体工作流上的需求：查询数据仓库、销售电话前研究客户、处理事件、建模收入场景，或准备合规审查。当我们推出 Stripe 的知识 AI Agent 时，一切都改变了。
GIF
在我们四月份上线后的两周内，Stripe 的大部分员工就已经在使用 Stripe 的知识 AI 平台，也就是 Kai。如今，83% 的员工是周活跃用户，其中包括几乎整个 GTM（市场、销售、客户成功经理和技术客户经理）团队。大多数 Kai 会话需要多轮交互，用户会进行深度研究、创建特定成果物，或是在内部或外部共享前不断打磨。有了 Kai，Stripe 的每个人都拥有一个专门帮助他们处理日常工作的 Agent。
为什么我们要构建知识 AI 平台
对于编码任务来说，具体改动各不相同，但完成任务所需的工作流和工具基本保持不变。你编辑文件、运行测试、提交代码。编程语言千差万别，但工作形态相当统一，这也是单一 Agent 架构能够奏效的原因。知识工作则处于这个光谱的另一端。研究客户或准备合规审查等任务，需要不同的工具、不同的数据、不同的输出，以及不同的"完成"定义。
在 Kai 之前，我们有两条知识工作的 AI 路径：
- 无代码 Agent 构建器： 任何人都可以构建和部署针对特定工作流且能够使用工具的 Agent。该系统共构建了 4,000 多个 Agent。然而，我们很快发现，团队编写的提示词概念上相似，但质量参差不齐，而且这些微 Agent 的激增越来越难以监控和维护。
- 编码 Agent： 编码 Agent 功能强大，但也带来了一系列不同的风险。由于我们的目标是提升整个 Stripe 的生产力，一些用户改变了工作流并选择使用编码 Agent。然而，安全问题很快浮现，同时也给代码质量团队带来了新的支持负担，而这个团队此前从未支持过非工程师用户。
从这些经验中，我们认识到构建一个知识 AI 平台需要做好三件事：在不集中化的情况下扩展专业知识、无论用户在何处工作都能满足他们的需求，以及落实代码领域不存在的安全护栏。
在不集中化的情况下扩展专业知识
服务 Stripe 用户所需的专业知识范围惊人地广泛。懂得如何处理计费升级事件或建模收入场景的人并不集中在一个部门，当然也不在构建 Agent 基础设施的团队里。他们分布在数十个专业领域中——GTM、财务、市场、法务、数据科学等等——每个领域都有自己的工具、数据源、工作流，以及各自对"好"的评判标准。再乘以 Stripe 运营的所有产品和国家和地区，结果复杂得惊人。Kai 必须以不可见的方式建模这种复杂性，让任务顺畅完成。
Agent 必须能够自由游走
Agent 出现在哪里，与它知道什么同样重要。不是每个人都在浏览器标签页里工作，更少有人在终端里工作。因此，知识 Agent 不能只是一个单一产品；它必须是一个平台，足够灵活，能够嵌入到任何工作发生的地方。
例如，我们的财务团队使用一个内部应用来对 Stripe 运营预算的复杂变化进行建模：Agent 需要读取上下文、研究相关文档、提出有效变更并总结差异，全程都不会把用户从应用中拉出来。
构建一个独立的 Agent 产品行不通。相反，这会迫使用户离开他们的自然工作流，进入一个新应用。为每个界面单独构建一个 Agent 产品同样行不通；这样既难以维护，而且跨多个工具工作的用户会获得割裂的体验。平台必须在用户所在之处满足他们的需求。
从零构建安全护栏
编码 Agent 运行在一个拥有数十年快速、可验证护栏的环境中：编译器拒绝无效语法，测试捕获回归，git 让每个错误都可撤销。而知识工作几乎不具备这些保障机制。
以 Stripe 的一个核心不变原则为例："你不应该在单一分析中合并来自两个互不相关的客户上下文的数据。"用户可能对两个上下文都有合法的独立访问权限，但它们绝不能出现在同一个会话中。隔离边界并不是"这个人根据其授权令牌可以访问什么"，而是"在这个上下文中，这个任务应该被允许查看什么"。平台必须落实这些用户依赖的隐性护栏。
我们如何构建 Kai
单一的整体式 Agent 根本不可能有效地编码所有这些约束。而且，要求每个领域团队独立构建安全、托管、高性能的 Agent 基础设施也无法规模化。为了应对这一挑战，我们用三层架构构建了 Kai：
- 与界面无关的 API，为同一个 Agent 提供多种界面
- AgentStudio，领域负责人在这里构建和管理他们自己的 Kai Agent，以及
- 执行环境，在几秒内交付安全性，无需任何人操心基础设施。
与界面无关的 API
Kai 附带一个设计精良的 Web 应用和一个 Slack 集成，但主要的原语是支撑这两者的底层 API。Agent 是一项服务，而不是一个应用，界面只是进入它的定制化视图。
大多数 Stripe 员工通过内部托管的 Web 应用与 Kai 交互。无需设置任何基础设施——每位员工在入职第一天就可以使用。
任何内部工具也都可以嵌入 Kai，而且许多工具已经这样做了。例如，在我们的商业智能平台中工作的员工，可以直接在现有应用中向 Kai 提问，因为我们的 Chrome 扩展会在基于 Web 的第三方工具中呈现 Kai 的功能。
自定义应用通过 API 嵌入 Kai，将 Agent 体验带入所有工作流
AgentStudio
AgentStudio 是领域负责人的控制平面。团队使用它来构建、测试和监控他们的技能、自定义 Kai Agent 和工具选择。例如，一个 GTM 团队拥有一个针对其工作流调优的 Kai Agent。它默认加载他们的技能，连接他们的数据源，并以用户期望的格式呈现输出。AgentStudio 将使用数据和质量信号与每项资产一同呈现，因此领域负责人无需询问平台团队就能了解什么在起作用。
技能按 Stripe 的各个领域进行组织，由领域专家管理
执行环境
这一层让平台的承诺变为现实。核心原语，包括 Agent 框架、沙箱、工作流编排和访问控制框架，都与 Stripe 面向产品的 Agent 有意共享。内部知识工作处理的是同样的敏感数据，服务的是与外部产品相同的用户，因此它需要同样的安全和合规标准。共享底层基础设施会带来纪律约束，并形成飞轮效应：执行环境的改进会同时惠及内部和产品 Agent。
Agent 框架基于 LangChain 的 deepagents 构建，运行在 Kubernetes 上，配备安全的每会话沙箱和多租户虚拟文件系统。在会话中，Agent 使用虚拟文件系统创建和迭代成果物，同时使用安全的代码执行沙箱进行分析和数据处理。
它的设计目标是在长时间、复杂的会话中保持状态——最近有一次会话达到了 932 轮。凭借 Kai 的深度任务管理能力，单个对话可以包含数百轮，以及数百次工具和 LLM 调用，而不会超时或压垮上下文窗口。这很重要，因为知识工作很少是单个问题。它是建立在自身之上的迭代推理，会话必须在不退化的情况下保持这种状态。
用户行为正在改变，会话越来越多地用于深度多轮协作
框架中最有趣的部分之一是它如何选择要使用的正确技能。Kai 连接了 1,000 多个技能和工具，涵盖各种内部系统——从跟踪关键指标的商业智能仪表板，到组织内部执行的项目管理工具，再到 Zoom 和 Google Workspace 等第三方服务。任何人都可以向它提问，并相信它会加载正确的上下文、使用正确的工具来完成任务。编码 Agent 在这里有天然优势：它们工作的文件夹为技能和上下文提供了自然的组织方式。在后续文章中，我们将介绍我们如何在没有这种既有结构的情况下，利用混合 RAG/LLM 方法等技术来解决这个问题。
影响
结果令人瞩目。GTM 团队的新员工是 Kai 原生用户，使用频率高出 2.7 倍，而且同一批用户中，重度用户比轻度用户多创造了 80% 的价值。当客户经理使用 Kai 时，与同一批销售在不使用 Kai 的周次相比，他们的销售活动量是原来的 2 倍，创造的商机多 17%，带来的营收机会多 26%，成交的订单多 39%。总的来说，Kai 每年帮助将 25,000 小时从行政工作中转移到创收工作中。
在财务和运营领域，Kai 帮助 Stripe 员工分析混乱的数据、生成定期摘要，并将零散的上下文转化为可用的成果物。
在工程领域，Kai 现在已成为提出系统问题、研究运行请求、分析日志、起草计划，以及调用更专业的 Agent 和技能的自然之选。
在整个 Stripe，每天有超过 5,000 个会话围绕数据分析展开。这使 Kai 成为一个独特的杠杆点：通过接入关于数据质量和分析层的正确上下文，我们可以确保大多数问题默认就能得到正确回答。
Stripe 员工的直接反馈印证了这些汇总数据：他们表示"感到被赋能去拥抱 AI"，并且"对 Kai 精准完成的事情感到惊叹"。但我们最喜欢的轶事是一位非工程师，他在离开 Kai 入门介绍会后，立刻开始协作制作一份将 Asana、Slack 和 Jira 整合到单一自动化流程中的摘要。
我们还没有赢
在 Stripe，我们最喜欢的一句口号是"我们还没有赢"，这对 Kai 来说恰如其分。我们仍处于这段旅程的最早期，还有很多想做的事：
- 更好的状态管理： 像 Kai 这样的通用 Agent 在迭代调用工具、拉取大型文档等过程中会生成大量状态。我们正在持续调优发送给 LLM 的"活动"上下文，以及存储在 S3 或虚拟文件系统等状态存储中的"扩展"上下文。
- 反思与自我改进： 我们正在构建一个质量改进循环，让 Kai 能够反思涉及某项技能的追踪记录、提出改进建议、进行测试，并提交变更供技能所有者审阅。
- 更好的协作原语： 用户在他们的 Kai 会话中产生了大量目前"被困住"的上下文，但工作并不是这样完成的。我们希望让人们跨会话共享 Kai 呈现的内容，并让多人（以及多个 Agent！）在同一个成果物上协作。
编码 Agent 首先让 AI 对软件工程师来说变得具体可感。Kai 帮助将同样的杠杆感带给了 Stripe 的知识工作者。有趣的是，虽然我们已经显著提升了生产力，但我们还不知道上限在哪里——我们很兴奋能继续突破界限。如果你觉得构建驱动内部生产力和外部 Agent 的 Agent 系统正是你想要的挑战，我们正在招聘。
