编程智能体改变了斯特赖普（Stripe）的工程，但销售、财务分析师、技术客户经理等非工程师在Claude Code和Codex的AI浪潮中落后。没有工具能满足斯特赖普的数据安全与特定工作流，如查数据仓库、售前调研、事故分诊、收入建模或合规审查。发布斯特赖普（Stripe）知识AI平台（Knowledge AI Platform，亦称凯（Kai））后情况改变。4月发布两周内多数员工使用，如今83%为周活跃用户。

编程智能体改变了 Stripe 的工程方式，但销售代表、财务分析师、技术客户经理等非工程人员感觉被 Claude Code 和 Codex 的 AI 浪潮落下了。当时没有工具能满足 Stripe 的数据安全要求和特定工作流——比如查询数据仓库、在销售通话前调研客户、分流事故、建模收入场景或准备合规审查。这一切在我们推出 Stripe 知识 AI 平台后改变了。

今年 4 月上线后两周内，Stripe 大多数员工就用上了这个又名 Kai 的知识 AI 平台。如今 83% 的人每周活跃使用，包括几乎所有 GTM（市场、销售、客户成功经理和技术客户经理）团队。多数 Kai 会话需要多轮交互，用户进行深度调研、创建特定产物或打磨素材后再对内对外分享。现在每位 Stripe 员工都有一个专为他们日常工作打造的智能体。

我们为何打造知识 AI 平台

编程任务的具体内容千差万别，但执行所需的工作流和工具基本不变：改文件、跑测试、提交。语言虽不同，工作形态却相当统一，所以单一智能体架构就很有效。知识工作则完全相反。像调研客户或准备合规审查这类任务，需要不同的工具、数据、产出，以及对“完成”的不同定义。

Kai 之前，知识工作只有两种 AI 选项：

• 无代码智能体构建器：任何人都能构建并部署可使用工具的特定工作流智能体。用这个系统建了超 4000 个智能体。但我们很快发现，各团队写的提示词概念相似却质量参差，这些微型智能体激增后越来越难监控维护。
• 编程智能体：它们很强，却带来另一类风险。为了让全员提升效率，有些用户改变工作流选了编程智能体，但安全问题随之浮现，代码质量团队本不支持非工程师，如今平添支持负担。

从这些经验我们意识到，打造知识 AI 平台须做好三件事：分散化地扩展专业能力、在用户工作的地方触达他们、落实代码世界里不存在的护栏。

分散化扩展专业能力而不集中

服务 Stripe 用户所需的专业范围大得惊人。懂如何分流账单升级或建模收入场景的人并不集中，肯定也不在构建智能体基础设施的团队里。他们分散在 GTM、财务、市场、法务、数据科学等几十个专业领域，各有工具、数据源、工作流和对“好”的判断。再乘上 Stripe 运营的所有产品和国家，复杂度令人咋舌。Kai 必须把这种复杂度建模得无影无踪，让任务顺手就能完成。

智能体必须随处可达

智能体出现在哪里和它本身懂什么同样重要。不是人人都在浏览器标签页里工作，用终端的更少。所以知识智能体不能只是单一产品，必须是平台，灵活嵌入到工作发生的地方。

比如财务团队用来建模 Stripe 运营预算复杂变动的内部应用：智能体需读懂上下文、调研相关文档、提出有效改动并总结差异，全程不把用户拽出应用。

做独立智能体产品行不通，那会逼用户脱离自然工作流去用新应用。为每个界面单独做产品也不行：难维护，跨多工具的用户体验会割裂。平台必须在用户所在之处迎接他们。

从零构建护栏

编程智能体运行的环境有数十年来快速可验证的护栏：编译器拒掉非法语法，测试捕获回归，git 让每个错误可回退。知识工作几乎没这些支撑。

想想 Stripe 的一个核心不变量：“不应在单次分析里合并两个无关客户上下文的数据。”用户可能分别合法访问这两个上下文，但它们绝不能出现在同一会话。隔离边界不是“凭授权令牌这人能访问啥？”，而是“给定上下文该任务允许看啥？”。平台必须落实这些用户依赖的隐式护栏。

我们如何构建 Kai

单一整体智能体根本无法有效编码所有这些约束。让每个领域团队独立构建安全、托管、高性能的智能体基础设施也扩不开。为应对，我们把 Kai 分成三层：

• 与界面无关的 API：为同一智能体提供多种接口
• AgentStudio：领域负责人在此构建并管理自己的 Kai 智能体
• 执行环境：无需任何人操心基础设施，数秒内交付安全

与界面无关的 API

Kai 附带一个主张明确的网页应用和 Slack 集成，但核心原语是驱动两者的底层 API。智能体是服务而非应用，界面只是它的定制视图。

多数 Stripe 员工通过内部托管网页应用使用 Kai。无需搭建基础设施——入职第一天就能用。

任何内部工具也能嵌入 Kai，许多已经这么做了。比如在我们的商业智能平台工作的员工，因为 Chrome 扩展把 Kai 能力带进基于网页的第三方工具，能在现有应用里直接问 Kai 问题。

自定义应用通过 API 嵌入 Kai，为所有工作流带来智能体体验。

AgentStudio

AgentStudio 是领域负责人的控制平面。团队用它构建、测试、监控自己的技能、定制 Kai 智能体和工具选择。比如 GTM 团队拥有一个按他们工作流调优的 Kai 智能体，默认加载其技能、连接数据源，按用户期望格式呈现输出。AgentStudio 在每个资产旁展示使用数据和质量信号，领域负责人无需问平台团队就能看清什么管用。

技能按 Stripe 内由领域专家管理的领域来组织。

执行环境

这一层让平台承诺成真。核心原语（含智能体框架、沙箱、工作流编排和访问控制框架）刻意与 Stripe 面向产品的智能体共享。内部知识工作处理与外部产品相同敏感数据、服务相同用户，故需同样安全合规标准。共享基座倒逼纪律并形成飞轮：执行环境的改进同时惠及内部和产品智能体。

智能体框架基于 LangChain’s deepagents 构建，运行在 Kubernetes 上，带每会话安全沙箱和多租户虚拟文件系统。会话内，智能体在虚拟文件系统上创建并迭代产物，安全代码执行沙箱则用于分析数据处理。

它专为在漫长复杂会话中保持状态而建——最近有个会话达到 932 轮。凭借 Kai 深度任务管理能力，单次对话可含数百轮、数百次工具和 LLM 调用而不超时或撑爆上下文窗口。这很关键，因为知识工作极少是单一问题，而是自我堆叠的迭代推理，会话必须保持状态不退化。

用户行为在变，会话正越来越多用于深度多轮协作。

框架最有趣的部分之一是如何选对技能。Kai 连接了 1000+ 跨越各内部系统的技能和工具——从追踪关键指标的商业智能看板，到组织内部执行的项目管理工具，以及 Zoom、Google Workspace 等第三方服务。任何人问个问题，都可信它加载正确上下文并用对工具搞定。编程智能体在这有天然优势：工作文件夹为技能和上下文提供自然组织。后续文章我们会讲如何在无此预设结构下，用混合 RAG/LLM 等方法解决。

影响

成果惊人。GTM 新员工是 Kai 原住民：使用率高 2.7 倍，重度用户比同批轻度用户多闭环 80% 价值。客户主管用 Kai 时，相比不用那几周，销售活动翻倍、多建 17% 商机、多生 26% 收入机会、多签 39% 单。总计，Kai 每年把 25000 小时从行政工作转移到创收工作。

财务和运营中，Kai 帮员工分析杂乱数据、生成定期摘要，把碎片上下文变成可用产物。

工程上，Kai 成了问系统问题、调研运行请求、分析日志、起草方案、调用更专业智能体和技能的自然去处。

全 Stripe 每天超 5000 个会话围绕数据分析。这让 Kai 成为独特杠杆点：接入关于数据质量和分析层的正确上下文，就能默认对多数问题确保正确回答。

Stripe 员工的直接反馈佐证了这些聚合数据：他们说感到“被赋能拥抱 AI”、“惊叹 Kai 精准做对的事”。最爱轶事是一位非工程师离开 Kai 入门会话后，立刻协作了一份把 Asana、Slack、Jira 统进单一自动化流程的摘要。

我们尚未取胜

Stripe 流行语“我们尚未取胜”用在 Kai 上很贴切。我们处在最早阶段，还想做很多：

• 更好的状态管理：像 Kai 这样的通用智能体迭代调工具、拉大文档会产生大量状态。我们持续调优发给 LLM 的“活跃”上下文和存在 S3 或虚拟文件系统等状态存的“扩展”上下文。
• 反思与自我改进：正打造质量改进环，让 Kai 反思涉及某技能的轨迹、提议改进、测试并提交给技能主审。
• 更好的协作原语：用户在 Kai 会话生成大量当前“锁定”的上下文，但工作不是这么干的。我们想让人们跨会话分享 Kai 浮现的内容，并允许多人（和智能体！）在同一产物上协作。

编程智能体先让 AI 对软件工程师变实在。Kai 把同样杠杆感带给 Stripe 全体知识工作者。有趣的是，尽管生产力已大幅提升，我们不知上限在哪——兴奋继续突破。

社区对 Stripe 内部 AI 平台 Kai 普遍质疑其营销空洞与界面粗糙，少数人则认可企业内部自建受治理代理平台的方向。

认为其只是通用 Agent 构建器而非真正的知识平台

• 多名开发者指出该产品缺乏知识管理需要的验证与透明度等特性，更像是普通的代理搭建工具，甚至质疑为何不直接用开源方案或只是大厂工程资源过剩的产物（较多人） > 所谓知识平台名不副实，缺乏验证与透明，更像是通用代理构建器，或许只为证明内部造轮子的合理性。（@hek2sch）

批评界面与文案充满 AI 生成感且缺乏打磨

• 用户集中吐槽页面背景渐变晃眼、排版行高不适、内置贪吃蛇与音效等多余元素，且满屏 AI 腔调文案与不一致字体，与其昔日设计标杆形象落差明显（高赞） > 界面充斥无用 AI 文案且观感草率，这种不一致性让我对它的热情瞬间降温。（@quadrifoliate）

质疑销售提升数据的因果性与文章对外价值

• 不少人认为文章声称使用平台带来销售翻倍等收益混淆了相关与因果，且全文对自身业务外的人缺乏可复用的经验干货，还有人问全员使用究竟是强制还是自愿（较多人） > 更积极的销售员本来就更爱用新工具，不能把业绩增幅全归功于平台本身。（@eis）

认可企业内部自建受治理代理平台的趋势

• 部分从业者表示自己也构建了类似内部代理系统，认为提供带权限管控、本地部署的代理运行平台是很多企业未来的合理演进路线（少数人） > 很多公司会走向本地平台，让团队用上受管控且强大的代理，而非裸用编码代理。（@lukebuehler）

认为独立聊天式代理比嵌入工作流更受欢迎

• 有开发者基于客户经验提出相反看法，认为老旧内部工具体验糟糕，客户反而明确要求独立的聊天界面作为新通道，以此取代繁杂视图（少数人） > 客户明确想要新聊天渠道，比他们那维护糟糕的内部工具体验好太多了。（@bob1029）

有价值的补充

• 一名用户调侃自己刚给新生儿起名 Kai，折射出开发者社区对这一命名巧合的轻松情绪。（@olliebrkr）
• 有观察指出 Stripe 过去是网页设计典范，如今页面却像大模型乱改，疑似训练数据对 Stripe 风格过拟合。（@nozzlegear）