Stripe 的知识型 AI 平台 Kai
文章摘要
这是 Stripe 开发者博客 2026 年 7 月 30 日发布的一篇工程文章，作者是技术写作者 Anna Mason、Agent Foundation 团队工程经理 Sharadh Krishnamurthy 和 AI Platform 团队工程师 Anupam Upadhyay。文章介绍了 Stripe 内部面向「非编程类知识工作」的 AI 智能体平台，内部简称 Kai（Knowledge AI）。
缘起：编程智能体之外的人被落下了。 文章开头说，编程智能体改变了 Stripe 的工程工作，但销售、财务分析师、技术客户经理等非工程岗位在 Claude Code 和 Codex 这波浪潮中”感觉被落下了”。市面上没有任何现成工具能满足 Stripe 的数据安全要求和特定工作流：查询数据仓库、销售电话前调研客户、分诊事故、建模收入情景、准备合规审查。
采用数据相当激进。 4 月上线后两周内，Stripe 大部分员工都在用 Kai；如今周活跃用户占 83%，GTM（市场、销售、客户成功经理、技术客户经理）几乎全员在用。大多数会话都是多轮的：深度调研、生成特定产出物、在内外部分享前反复打磨。
为什么要单独做一个平台。 作者的论点是：编程任务的具体改动千差万别，但工作流和工具基本一样——改文件、跑测试、提交——所以单一智能体架构就够用。知识工作正好相反：调研一个客户和准备一份合规审查，需要的工具、数据、产出和”完成”的定义都不一样。在 Kai 之前，Stripe 有两条路：一是 NoCode Agent Builder，任何人都能搭带工具的工作流智能体，一共造出了 4000 多个，但团队们在写概念上相似、质量参差的提示词，这些微型智能体的泛滥越来越难监控和维护；二是让非工程师直接用编程智能体，结果很快冒出安全问题，还给从未支持过非工程师的代码质量团队带来了新的支持负担。
由此他们总结出三件必须做对的事：
- 规模化专业知识而不集中化：懂得如何分诊计费升级或建模收入情景的人分散在 GTM、财务、市场、法务、数据科学等几十个领域，而不是在做智能体基础设施的团队里。再乘以 Stripe 运营的所有产品和国家，复杂度惊人，Kai 要把这种复杂度建模到用户感觉不到的程度。
- 智能体必须”漫游”：不是每个人都在浏览器标签页里工作，更少人在终端里。例如财务团队有个内部应用用来建模运营预算的复杂变更，智能体需要在不把人拽出应用的前提下读上下文、查相关文档、提出有效改动并总结差异。做一个独立产品会逼用户离开自然工作流；给每个界面各做一个产品又难维护、体验割裂。
- 从零搭建护栏：编程智能体身处几十年积累的快速、可验证的护栏中——编译器拒绝非法语法、测试捕捉回归、git 让一切可回滚——知识工作几乎没有这些。文章举了一条 Stripe 的核心不变量：”不应在单次分析中合并两个不相关客户上下文的数据”。用户可能分别对两者都有合法权限，但它们绝不能出现在同一会话里。隔离边界不是”这个人的授权令牌能访问什么”，而是”在这个上下文里，这个任务应该被允许看到什么”。
架构分三层。
- 与界面无关的 API：Kai 自带一个有主见的 Web 应用和 Slack 集成，但核心原语是背后的 API——”智能体是一个服务，而不是一个应用，各种界面只是它的定制视图”。任何内部工具都可以嵌入 Kai；借助 Chrome 扩展，员工还能在第三方的 Web 工具（例如商业智能平台）里直接调用 Kai。
- Agent Studio：面向领域负责人的控制平面，用来构建、测试和监控技能（skills）、定制 Kai 智能体和工具选择。例如 GTM 团队拥有一个按自己工作流调好的 Kai 智能体，默认加载他们的技能、连接他们的数据源、按用户期望的格式输出。每个资产旁都显示使用数据和质量信号，领域负责人不用问平台团队就能知道什么有效。
- 执行环境：智能体 harness、沙箱、工作流编排和访问控制框架这些核心原语，刻意与 Stripe 面向产品的外部智能体共享——内部知识工作处理的是同样敏感的数据、服务的是同样的用户，所以要达到同样的安全合规标准，共享底座也形成飞轮。harness 基于 LangChain 的 deepagents 构建，跑在 Kubernetes 上，每个会话有安全沙箱和多租户虚拟文件系统：智能体在虚拟文件系统里创建和迭代产出物，数据分析则在安全的代码执行沙箱里完成。它能在漫长复杂的会话里保持状态——最近有一个会话达到了 932 轮，单次对话可以包含数百轮、数百次工具和 LLM 调用，不超时也不撑爆上下文窗口。
技能选择是 harness 里最有意思的部分之一：Kai 连接了 1000 多个技能和工具，从追踪关键指标的 BI 仪表盘、项目管理工具，到 Zoom 和 Google Workspace 等第三方服务。编程智能体有天然优势——代码仓库的目录结构本身就是技能和上下文的组织方式；Kai 没有这种结构，文章说后续会专文介绍他们如何用”RAG/LLM 混合”等手段解决。
影响数据。 GTM 新员工是”Kai 原住民”，使用量是其他人的 2.7 倍，同批次中的重度用户比轻度用户多成交 80% 的价值。客户经理在使用 Kai 的那些周，比自己不用 Kai 的周多产生 2 倍的销售活动、多创建 17% 的商机、多产生 26% 的收入机会、多成交 39% 的交易。总计每年约 25000 小时从行政工作转移到了创收工作。全公司每天有 5000 多个会话以数据分析为中心，因此 Kai 成了一个独特的杠杆点：只要接入关于数据质量和分析层的正确上下文，大多数问题默认就能答对。他们最喜欢的轶事是：一位非工程师刚参加完 Kai 入门课，就立刻搭出一个把 Asana、Slack 和 Jira 汇总成自动化流程的摘要。
“我们还没赢”。 文章最后列出了下一步：更好的状态管理（持续调整发给 LLM 的”活跃”上下文和存放在 S3 或虚拟文件系统中的”扩展”上下文）；反思与自我改进（让 Kai 回看涉及某个技能的执行轨迹、提出改进、测试后提交给技能负责人审核）；更好的协作原语（会话中产生的大量上下文目前被”锁”在里面，他们希望支持跨会话共享，并让多人乃至多个智能体协作同一份产出物）。
HN 评论精华
117 条评论，讨论几乎没有围绕 Kai 的技术细节展开，而是分成三股：对 LangChain 的集体吐槽、对这篇文章和 Stripe 近来”不够精致”的批评，以及对效果数据的质疑。
LangChain 成了第一个靶子。 置顶的 anonzzzies 一上来就说：”今天才知道还有人会上当，呃，我是说还有人在用 LangChain……它从第一天起就是垃圾，而且奇怪的是一直没改进。”被追问理由时，ramraj07 给了一个更具体的批评：它和大多数框架一样”抽象错了概念”，推广的是一些可能从来就不是好策略、或者几个月前才算好主意的做法；他的建议是”直接用 pydantic 自己把一切写出来”。mdrxy 反问具体哪些策略过时了，指出文章用的是同一生态里单独的 deepagents 包。ramraj07 的回答是：”不显式给深度研究多智能体系统一个文件系统是个糟糕主意。我们发现在多智能体间可靠交接上下文的唯一成功办法就是文件系统，而 LangChain 至今都不把它设为默认甚至不鼓励。”persedes 则从调试体验吐槽：单步调试极慢，要跳很多层才到你关心的地方，代码里还能看到 “if langchain_v2 … elif langchain_v3 …” 这样的分支，他现在用 pydantic ai。dansquizsoft 讽刺了”这是旧版本的问题”这种辩护：”我当然很开心 SDK 作者在版本间不停改 API。明明可以基于稳定了四年的 chat completions API 自己写，为什么不花时间一遍遍更新代码回到基线功能呢？”也有人唱反调：weego 认为 Stripe 在生产中拿出了对业务有明显收益的产品，说明”垃圾”是主观的，在新兴领域过度坚持己见可能反而是阻碍；owebmaster 则回呛”也可能只是说明他们采纳了 LLM 的第一个推荐”。
“这篇文章读起来像 AI 写的”是第二条主线，而且 Stripe 博客编辑亲自下场回应。 quadrifoliate 的评论最有代表性：他一向把 Stripe 视为内部工具精致度的标杆，但这次在界面和演示里看到明显的粗糙——”Browse, discover, and manage skills for your agents”这类一眼 AI 的文案、界面里混杂的字体、一张会话指标幻灯片在单元格里重复写了 360,014 个会话、标题里又写 360K。他对照了 Stripe 当年介绍内部工具 Stripe Home 的文章。SoftTalker 摘出一句”共享底座迫使纪律并形成飞轮：执行环境的改进同时惠及内部和产品智能体”，说”没有人类会这么写”。chrisvls 说自己对这个话题很感兴趣，但太多段落”字很多却没有可用细节”，只好放弃。quadrifoliate 随后拆解了”与界面无关的 API”那段，指出它把一个简单的意思说得很模糊，而且配图里根本没画出这个 API。自称 Stripe 新任工程博客编辑 Drew 的 moograms 在多条评论下回复，说这篇不是他编辑的，但反馈会用于以后的文章，并且”庄严发誓以后避免 AI slop”。
这条线还引出了一段关于行业风气的讨论。reticulates 认为 AI 之后出现了一种”面具脱落”的时刻：很多公司过去细致的产出并非出于对手艺的尊重，而是因为资源稀缺时”做好和做了”的边际成本差不多；现在可以快速大量产出，于是”我们把手工雕花家具时代的软件工程视为理所当然，现在进入了宜家时代”。hax0ron3 不同意这个比喻，认为更像从”准时制生产”（敏捷、Scrum、Sprint）转向把生产外包到另一个国家，”而这个国家就是 AI”。几位前 Stripe 员工给出了截然相反的印象：edlebert 说内部工具”惊人地精致，从未见过”，aleqs 说”作为同样在那里工作过的人，这让我觉得好笑”。hibikir 的解释比较中肯：Stripe 经历过起起落落，有过为了客户体验把内部系统做得很糙的时期，也有过内部工具可以打磨到和外部网站一样亮的时期，人员流动又大，”不同任期的人对 Stripe 的印象可能完全不同，而且都对”。nojvek 回忆 Sail 设计系统曾经很出色，公司在 Ruby 上自研 JIT、格式化器和类型检查器，”但 AI 之后标准不一样了”。
效果数据遭到质疑。 eis 指出”同一批销售在用 Kai 的周比不用的周多成交 39%”这种说法混淆了相关与因果：销售休假、病假时活动少，自然也不会用这个工具。nitwit005 发现数字本身对不上：”成交数的增幅怎么会远大于商机的增幅？两倍的销售活动为什么只多产生 17% 的商机？”docheinestages 问”大部分人在用”是被迫还是自愿，自称现任 Stripe 员工的 vaughnegut 回答”自愿，它真的有用，这解释了普及率”。
其他角度。 ianpurton 问为什么不用现成开源方案，sceptic123 指出第一段就说了”没有现成工具能满足数据安全要求”，matrix87 则更刻薄：”帝国建设，还能是什么？他们原来有两个内部工具，现在有三个。”hek2sch 认为”知识 AI 平台”只是个流行词，文中没有任何面向知识管理的特性（比如验证或透明度），更像一个通用的智能体构建器；ofjcihen 说这类文章都不过是”我把智能体这样编排了”，和”看看我的 CloudFormation 模板”一样没什么可惊艳的。bob1029 给出了与文章相反的一线经验：他的一个客户明确想要一个新渠道，聊天式界面远比维护糟糕的内部工具受欢迎，他们即将用一个应用 JSON patch 的智能体工具替换数百个风格混乱的 cshtml 视图和控制器。不少人把 Kai 和 Cloudflare OS、AWS QuickSuite、windmill 等类比，也有人借机推荐自己的开源项目。最后是几条轻松的：atonse 说自己给公司（Kaizen）做的内部智能体也叫 Kai；olliebrkr 哀叹”我刚给新生的儿子取名 Kai”，beachy 安慰他 Kai 在毛利语里是”食物”的意思，比如 Kaimoana 就是海鲜。