深度 · 小互解读

Stripe 公司内部 Agent 开发实践：一个工程师一周开发出来的公司内部 AI 助手，几乎人人都在用

文件、沙盒、上下文压缩三样是买来的现成件，安全边界得自己造；技能装到 150 个，模型开始挑错
一分钟速览
  • 一句话下去，11 秒后 Kai 交出一份能打开、能导出、还在实时倒计时的活动邀请网页。
  • 第一版一个工程师一周做出来，因为最难的那层是买来的现成件：文件、沙盒、上下文压缩三样。
  • 技能不是越多越好。Stripe 实测过了 150 个，前沿模型挑技能就开始挑错。
  • 还有一处，它自己的图和自己的正文对不上，正文说会话大多是多轮，图上中位数只有 2 轮。
⚑ 立场提示：这篇的主线材料是 LangChain 官方博客写自家客户的实践复盘，补充材料是 Stripe 自己发在 stripe.dev 的博文，两边都是当事人。文中的采纳率、业务收益（成交提升、节省工时）全部是 Stripe 自评口径，没有第三方核验。机制细节我另外读了 deepagents 的开源仓库源码来对照，出处逐处标注。
开场

Kai：一个人一周开发出来的企业 AI 助手

LangChain 官方博客 7 月底发了一篇拆得很细的实践复盘，讲 Stripe 怎么用他们开源的 Deep Agents 做出了给全公司非工程师用的 AI 助手 Kai，今天 83% 的 Stripe 员工每周都在用它，而第一个能跑的版本，是一个工程师花一周做出来的。这篇真正值得读的地方，是它把「哪几层可以买、哪几层必须自己造、造大了会在哪撞墙」全写了出来，其中还有一个反直觉的实测结论：技能给 Agent 装多了，它反而会变笨。

先用三句话说清 Kai 是什么

痛点Claude Code、Codex 这类 AI 工具是给工程师做的，门槛卡在终端、环境配置和数据安全审批上，销售、财务、运营这些人过不去。但公司又在要求所有人用 AI 提效。
思路不把非工程师往开发工具那边推，而是照他们的干活方式重做一个：开箱即用、不用配任何东西、出厂就懂 Stripe 内部怎么运作的「AI 同事」。
结果开放预览一周就完成了原定的季度采纳目标；4 周用户从 296 涨到 5000 多，16 倍；今天 83% 的员工每周在用，市场（95%）和 GTM（87%）的采纳率比工程团队还高。

它具体能干什么：

开一个会话，把活派给它你在聊天框里说要什么，它产出的报告、看板、文档就挂在对话旁边；接着聊，那些产物跟着改。跟编程 Agent 是同一种用法，只是换给不写代码的人用。
出厂就懂 Stripe公司内部的系统、数据源、行事规矩都预装好了。用它之前不用先解释「我是干什么的」「我们公司怎么运作」。
连着 1000 多个技能和工具数据仓库、商业智能看板、项目管理工具，外加 Zoom、Google Workspace 这类外部服务，都在它手边。
会跑代码写 Python 查数据、画图，拆 PDF 和演示文稿，这些都在一个隔离的沙盒里跑。
人在哪它在哪网页版、Slack、Chrome 扩展塞进第三方网页工具，任何内部应用还能用 API 把它嵌进自己界面里。
各部门有各自的版本销售运营的 Kai 和财务的 Kai 默认装的技能不一样，个人还能在部门默认之上再加。

先看它干活的样子。Stripe 放出的那段 11 秒演示里，工程师 Anupam 在 Kai 首页打了这么一段话：

演示里的真实提问 · 译文
给一场在旧金山办的 Stripe Press 公开活动做逐周上线计划和一份可交互的活动邀请函，面向早期创业者，主题是「在 AI 时代建立能扛住时间的公司」。挑出过去 90 天网站流量最高的 3 本书，研究这几位作者最近公开发表的东西，推荐一个主题、一份书单、两位可能的讲者，每个选择都要给出出处。
这一句话里其实塞了五件不同的活，而且彼此有先后依赖，后面的活得等前面的结果出来才能开始。
一句话提问 查内部数据 90 天流量榜 研究人 作者近期动态 做判断 选主题和讲者 给出处 每条都要引用 排计划 逐周上线表 event_invite.html 一个能打开、能改、能导出的网页 底下的倒计时还在实时走 11 秒
本站示意图：那一句提问在 Kai 里被拆成五件互相依赖的活，最后收拢成一个文件。

Stripe 放出的 Kai 演示（无声）。从空白首页输入那段提问，到画面里出现一份深色的活动邀请页，整段 11 秒。中途能看见它调的工具 write_file · file_path: event_invite.html，以及一个叫 ask-data 的技能标签。来源：stripe.dev《Meet Stripe's Knowledge AI Platform》。

最后画面上那份网页是一个真做出来的文件：深色底、标题《Built to Last: Founding Durable Companies in the AI Era》，写着 2026 年 9 月 24 日周四晚 6:00–8:30、地点 Stripe 旧金山湾区办公室、受众「早期创业者（pre-seed 到 A 轮）」，两个按钮「申请邀请」和「看书单」，底下还挂着一个正在跑的倒计时。右上角是「退出演示」和「导出」。

还有几个一闪而过的细节值得记下来：首页底部的小字写着这东西是 Agent Foundations 团队做的，上手指南在内部短链 go/kai-getting-started，反馈发到 #kai-pilot 频道；右上角有个「Incognito」（无痕）开关；输入框的占位符是「Ask anything, # for skills」，打一个井号就能点技能。

产出物上的差别

知识工作 Agent 和聊天机器人的差别，在产出物上一眼就能看出来：你要的东西得能打开、能改、能发给别人。一段读完就完的回答顶不上。这个差别决定了它底下必须有一套完全不同的地基。

来龙去脉

为什么编程 Agent 帮不了销售和财务

Stripe 的工程师早就有自己的 AI 帮手。他们自研的编程 Agent 叫 Minions，一周能合掉一千多个 PR，代码还是人来 review（这个背景来自 stripe.dev 上另外两篇讲 Minions 的文章，LangChain 那篇没提）。

问题是公司里更多的人不写代码：销售、财务分析师、技术客户经理。Claude Code、Codex 这波浪潮起来的时候，这些人被甩在了后面。他们想用，挡在前面的是终端、数据权限、安全审批这三道门槛。

在 Kai 之前，Stripe 试过两条路，都不太行。

第一条路 · 无代码搭建器

谁都能拖拽出一个专干某件事的小 Agent，还能挂工具。结果搭出来 4000 多个。

问题不在数量，在于很多人写的是意思差不多、质量却参差不齐的提示词；这么多小 Agent 散在各处，监控和维护根本跟不上。

第二条路 · 直接用编程 Agent

有人真这么干了，为了迁就编程工具，把自己的工作流改掉。

安全问题很快冒出来。同时，代码质量团队突然要开始支持一群从来没服务过的非工程师用户，凭空多了一大摊活。

踩完这两条路，他们提炼出一个判断，后面所有的设计都从这个判断长出来：

核心判断

写代码这件事，形状是统一的。具体改什么每次都不一样，但流程和工具基本不变，改文件、跑测试、提交。语言可以是 Ruby 可以是 Java，活的形状还是那个形状。所以一套 Agent 架构就能通吃。

知识工作正好在光谱的另一头。研究一个客户账户和准备一次合规审查，用的工具不一样、数据不一样、产出不一样，连「什么算干完了」的定义都不一样。你没法拿一套架构套上去。

写代码 每次都是同一个环 改文件 跑测试 提交 流程固定 → 一套架构通吃 知识工作 每个任务都长成另一个样子 查仓库 跨源交叉核对 写简报 研究客户 拉三个季度的账 建模型 推演营收 调条款 比政策 列缺口 合规审查 工具、数据、产出、连「算干完了」的标准都不同
本站示意图：右边三行的任务名是原文举过的例子，具体步骤是我按常识补的示意，不是 Stripe 的真实流程。

从这个判断往下推，他们认定要做成得抓准三件事。

一、专家知识要散着放，不能收到中央

知道怎么处理一笔计费升级、怎么建一个营收模型的人，分布在 GTM、财务、市场、法务、数据科学几十个领域里，肯定不在建 Agent 基础设施的那个团队。再乘上 Stripe 做的所有产品和覆盖的所有国家，复杂度大到没边。Kai 要做的是把这份复杂度建模进去，然后让用户感觉不到它存在，让任务「就这么成了」。