Stripe 公司内部 Agent 开发实践：一个工程师一周开发出来的公司内部 AI 助手，几乎人人都在用
- 一句话下去，11 秒后 Kai 交出一份能打开、能导出、还在实时倒计时的活动邀请网页。
- 第一版一个工程师一周做出来，因为最难的那层是买来的现成件：文件、沙盒、上下文压缩三样。
- 技能不是越多越好。Stripe 实测过了 150 个，前沿模型挑技能就开始挑错。
- 还有一处，它自己的图和自己的正文对不上，正文说会话大多是多轮，图上中位数只有 2 轮。
Kai：一个人一周开发出来的企业 AI 助手
LangChain 官方博客 7 月底发了一篇拆得很细的实践复盘，讲 Stripe 怎么用他们开源的 Deep Agents 做出了给全公司非工程师用的 AI 助手 Kai，今天 83% 的 Stripe 员工每周都在用它，而第一个能跑的版本，是一个工程师花一周做出来的。这篇真正值得读的地方，是它把「哪几层可以买、哪几层必须自己造、造大了会在哪撞墙」全写了出来，其中还有一个反直觉的实测结论：技能给 Agent 装多了，它反而会变笨。
先用三句话说清 Kai 是什么
它具体能干什么：
先看它干活的样子。Stripe 放出的那段 11 秒演示里，工程师 Anupam 在 Kai 首页打了这么一段话：
给一场在旧金山办的 Stripe Press 公开活动做逐周上线计划和一份可交互的活动邀请函，面向早期创业者，主题是「在 AI 时代建立能扛住时间的公司」。挑出过去 90 天网站流量最高的 3 本书，研究这几位作者最近公开发表的东西，推荐一个主题、一份书单、两位可能的讲者，每个选择都要给出出处。
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 散在各处，监控和维护根本跟不上。
有人真这么干了，为了迁就编程工具，把自己的工作流改掉。
安全问题很快冒出来。同时，代码质量团队突然要开始支持一群从来没服务过的非工程师用户，凭空多了一大摊活。
踩完这两条路，他们提炼出一个判断，后面所有的设计都从这个判断长出来：
写代码这件事，形状是统一的。具体改什么每次都不一样，但流程和工具基本不变，改文件、跑测试、提交。语言可以是 Ruby 可以是 Java，活的形状还是那个形状。所以一套 Agent 架构就能通吃。
知识工作正好在光谱的另一头。研究一个客户账户和准备一次合规审查，用的工具不一样、数据不一样、产出不一样，连「什么算干完了」的定义都不一样。你没法拿一套架构套上去。
从这个判断往下推，他们认定要做成得抓准三件事。
一、专家知识要散着放，不能收到中央
知道怎么处理一笔计费升级、怎么建一个营收模型的人，分布在 GTM、财务、市场、法务、数据科学几十个领域里，肯定不在建 Agent 基础设施的那个团队。再乘上 Stripe 做的所有产品和覆盖的所有国家，复杂度大到没边。Kai 要做的是把这份复杂度建模进去，然后让用户感觉不到它存在，让任务「就这么成了」。
二、Agent 得会跑到人待的地方去
不是所有人都在浏览器里干活，在终端里干活的更少。所以它不能是一个独立产品，得是个平台，能嵌进任何一个内部工具里。
财务团队有个内部应用，专门用来推演公司运营预算的复杂变动。Agent 得能读懂当前上下文、去查相关文档、提出合法的改动、把差异总结出来，全程不能把人赶出那个应用。要是做成一个独立产品，就等于逼着用户离开自己顺手的工作流，跑到一个新 App 里去；而给每个入口各做一个 Agent 又维护不动，横跨多个工具的人还会体验割裂。
三、护栏得从零造
编程 Agent 泡在一个有几十年积累的护栏环境里：编译器会拒绝语法错误、测试会抓回归、git 让任何错误都能撤回。这些又快又能验证的东西，知识工作几乎一样都没有。
Stripe 举了条自家的硬规矩：不能把两个不相关客户的数据放进同一份分析里。这里的边界很微妙，一个人可能确实有权分别看这两份数据，但它们就是不能出现在同一个会话里。
所以判断的问法变了：不再问「这个人的授权令牌能访问什么」，而是问「这个任务，在当前这个上下文里，应该被允许看什么」。前一个问题查一下权限系统就有答案，后一个问题得平台自己在运行时替你守住。
Deep Agents 替他们做好的三件事：文件、沙盒、上下文
Kai 的地基是 Deep Agents，LangChain 开源的 Agent harness。
可以理解成 Agent 的骨架加传动系统：模型调用循环、中间件拼装、流式输出、状态管理，这些谁做 Agent 都得从头做一遍的通用件，被打包好了。像造车时买来的底盘和变速箱，车身和内饰你自己设计，但没人再造一遍传动轴。
Deep Agents 那一层解决了所有跟 Stripe 无关的问题，这样我们就能专心解决 Stripe 自己的问题。你可以从货架上直接拿一堆中间件下来。可组合的技能模式、复合后端，它给了对的结构，同时还留够了灵活度。
Sharadh Krishnamurthy · Stripe Agent Foundation 团队工程经理
真正让一周出活的，是三个开箱即用的中间件（中间件指夹在模型和你的业务之间的一层可插拔零件，每个负责一件通用的事，要哪个装哪个）。下面逐个拆。
一、虚拟文件系统：给 Agent 一块能反复涂改的桌面
Kai 是跑在云上的生产服务，不是你本地开的一个进程，所以它压根没有硬盘可用。Stripe 的做法是用 S3 在后面撑起一个虚拟文件系统，让 Agent 能跨轮次地读、写、引用文件。
为什么文件系统这个形式特别适合装 Agent 的上下文？因为它把上下文变成了一个模型能翻看、能改、能自己整理的东西，而不是一条只能往后堆、越堆越长的聊天记录。
Deep Agents 给模型的文件工具一共八个（这张表是我从 LangChain 官方文档整理的，原文没列）：
| 工具 | 干什么 |
|---|---|
ls | 列目录，带文件大小和修改时间 |
read_file | 读文件，支持按行偏移读大文件；图片、视频、音频和 PDF、PPT 也能读 |
write_file | 新建，或整个覆盖 |
edit_file | 精确替换字符串，可以全局替换 |
delete | 删文件，或递归删整个目录 |
glob | 按通配符找文件，比如 **/*.py |
grep | 搜文件内容，可以只出文件名、出带上下文的内容，或只出计数 |
execute | 跑 shell 命令。只有配了沙盒后端时这个工具才出现在模型面前 |
Stripe 在这套东西上加了一层自己的包装，叫「同步进 / 同步出」：每次要在沙盒里执行东西之前，先把相关文件都实体化到沙盒里；执行完，把新增和改动过的文件再同步回虚拟文件系统。
效果是：Agent 和驱动它的模型，在整个会话生命周期里感受到的是一个连贯、持续存在的文件环境，尽管底下的沙盒可能已经起了又销毁了好几轮。
二、沙盒：关键在于 Agent 站在沙盒外面
Kai 有两类活要跑代码：一是做分析（写 Python 查数据、画图），二是处理各种奇形怪状的文件格式（PDF、演示文稿、结构化文档）。
这里有个容易读漏但要紧的设计：沙盒是以「工具」的身份暴露给 Agent 的，不是 Agent 自己跑在沙盒里。Agent 在沙盒外面运行，需要跑代码时调进去。
为什么这么摆？答案在一个叫「致命三件套」（lethal trifecta）的安全模型里，Simon Willison 2025 年 6 月提出，Stripe 在这里直接引了它：
只要一个 AI 系统同时具备这三个能力，攻击者就能骗它把你的数据打包送出去。根子在于模型分不清哪条指令来自主人、哪条来自它正在读的那份文档，所有东西最后都被拼成一串字喂进模型。更要命的是，这个问题目前没有 100% 可靠的防法：你可以在自己的提示词里叮嘱它别听，但没法保证每次都管用。
所以 Stripe 的摆法是给「模型生成的代码」画一条明确的执行边界：Agent 在外面，代码在里面跑，里面炸了，炸不到外面的凭据和数据通道。
三、自动摘要：上下文快满了就自己收拾
多轮长会话有个物理上限：聊得越多，塞进模型的历史越长，又贵又会顶到上下文窗口的天花板。
Deep Agents 的摘要中间件默认这么干（这几个默认值是我从 deepagents 仓库源码里读到的，Stripe 实际用的数值没公开）：上下文用到 85% 就触发压缩，原样保留最近 10%，中间那段交给一个模型总结成摘要。被压掉的原始消息还留着，搬进虚拟文件系统里一个叫 /conversation_history/ 的文件存起来，需要时能翻回来。
middleware/summarization.py），Stripe 会自行调整这些参数。Stripe 在这上面调的旋钮包括：什么时候触发摘要、用哪个模型来摘要、摘要输出多长。他们还提到一个成本上的考量：大多数人用 Kai 是断断续续用的，不是一口气跑到底，所以要尽量避免大块上下文的缓存失效。缓存没命中，这些字就得按全价重算一遍。
一个工程师一周做出第一版：Kai 的三层架构
Stripe 花了十几年时间，围绕 Ruby 和 Java 建内部工具、安全层和部署支持。要用一套 Python 原生的技术栈，意味着得围绕一门新语言把内部服务的脚手架重建一遍，这是笔大投资，做之前谁也不敢打包票值不值。
Kai 是用结果把这笔账证明了的：Anupam 一个人，一周，做出了 Kai 的第一版，因为 Agent 基础设施里最难的那部分，Deep Agents 已经解决了。
Kai 彻底坐实了大家的判断，Deep Agents 就是该走的路。
Chrissie · Stripe AI 平台负责人
Kai 的架构分三层。
最上层：和界面无关的 API
Kai 出厂自带一个网页应用和一个 Slack 集成，但真正的核心是底下那个 API：Agent 在这里是一个服务，上面那些界面只是它的定制视图。网页版对全体员工第 0 天就可用，不需要谁去配什么基础设施。
任何内部工具都能把 Kai 嵌进去，很多团队真这么干了。比如有人在商业智能平台里干活，可以直接在那个界面里问 Kai，Stripe 做了 Chrome 扩展，把 Kai 的能力塞进了基于网页的第三方工具里。
Kai 嵌在内部 BI 工具（Insights and Forecasting Studio）右侧栏里。用户说「给我看按地区的收入趋势」，Kai 直接在左边建出图表，并列出它干了什么：按月净收入、按地区拆线、筛掉非当前版本、金额格式化。往下还能看到它折叠起来的「36 tools」调用记录，以及一段自己写的趋势判断。图上的地区名是 Atlantis、Mordor、Westeros 这类，说明这是脱敏演示数据。来源：stripe.dev。
中间层：AgentStudio，各领域自己的控制台
各个领域负责人在这里建、测、监控自己的技能、定制 Kai 和工具选择。比如 GTM 团队有一个专门为他们的工作流调过的 Kai：默认加载他们的技能、连他们的数据源、按他们习惯的格式出结果。控制台还会把使用数据和质量信号摆在每个资产旁边，领域负责人不用去问平台团队就知道哪个技能好使。
Agent Studio 的技能页。右上角写着 34 个区（area），能看到 ABP（行政商务伙伴）区有 2 个技能、Bridge 区 6 个技能 5 个子区、Data & AI 区 2 个技能 32 个子区、Finance & Workplace 区自己 0 个技能但底下挂了 35 个子区，这一千项技能是按部门分层挂上去的，父区自己可以一个技能都不装。每张卡右下角的「Editor」是当前用户的权限。建技能有两个入口：「Create with AI」和「Create in Editor」。（正文里 Stripe 把它连写成 AgentStudio，产品界面上是分开的 Agent Studio，这里按截图写。）来源：stripe.dev。
最底层：共享的执行环境
Agent harness、沙盒、工作流编排、访问控制框架这几个核心零件，是故意跟 Stripe 对外产品里的 Agent 共用的。理由是：内部知识工作处理的是同样敏感的数据、服务的是同样的用户，所以安全和合规的标准不该降。共用一套底子既逼着大家守纪律，也形成一个飞轮，执行环境改好一点，内部 Agent 和产品 Agent 同时受益。
这一层跑在 Kubernetes 上，每个会话一个独立沙盒，外加一个多租户的虚拟文件系统。
Stripe 官方架构图。上面两个方块是消费方，内部知识 Agent（Kai）和对外产品 Agent，两条线汇进同一个「安全共享执行环境」。中间深紫那条是 Agent harness（跑在 Kubernetes 上），职责写着「跨长会话维持上下文和状态」。底下四个零件：工作流编排（规划和协调）、每会话沙盒（隔离代码执行）、会话工作区（虚拟文件与产物、扩展状态）、上下文路由（选对技能和工具）。最下面接的是 1000+ 技能和工具，通向 Stripe 数据、各团队自持的领域工作流、以及 Google Workspace、Zoom 这类外部服务。来源：stripe.dev。
1000 个技能，模型怎么知道该用哪个
先说技能是什么。在 Deep Agents 里，技能是一个个结构化的、Agent 能直接执行的模块，装的是「怎么完成某一类具体任务」，包括该加载哪些工具、该用什么路子。它遵循 Agent Skills 标准，落到磁盘上就是一个目录，里面必须有一个 SKILL.md：开头是 YAML 元信息（名字、一句话描述、允许用哪些工具），下面是给 Agent 看的说明书，还能带脚本、模板、参考文档。
Stripe 的做法是联邦制：技能由各个团队自己拥有和维护。基础版 Kai 出厂带一套打底技能（覆盖 Stripe 内部的基本导航），额外的技能按用户画像和当前用的是哪个定制 Kai 分层加载，销售运营的人拿到的技能包和财务的人不一样；再往上还有一个用户级的画像层，个人可以在部门默认之上自己加技能。
1000+
技能与工具总数，来自 100 多个团队的贡献
500+
内部 MCP 工具，还在继续长
34
技能被分成的「区」，区下面还有子区
矛盾就在这儿：全都塞进上下文是不可能的，那等于每次提问都先让模型读一本电话簿。
解法：先选技能，技能再带出工具
Agent Skills 规范里，每个技能可以声明 allowedTools，也就是这个技能允许用哪些工具。Deep Agents 启动时只把每个技能的名字、一句话描述、允许的工具清单、文件路径注入系统提示词，技能正文一个字都不读（这套做法叫渐进披露，progressive disclosure：像一本书先只给目录，翻到哪章才展开哪章）。模型自己判断这次任务该用哪个技能，选定之后，那个技能的 allowedTools 才决定要把哪些工具的完整定义加载进来。
middleware/skills.py 的实现绘制。模型本来就在花力气判断该加载哪些技能，那我们就顺势用这个判断，把相关的工具也一起加载了。
Anupam Upadhyay · Stripe AI 平台团队工程师
有一批打底技能是钉死的，不管模型决定加载或卸载什么，它们一直在，这样 Stripe 的基本上下文和政策行为在任何时候都保持一致。
然后是那个坎：150 个
技能的描述字段有 1024 个字符的上限。这是 Agent Skills 标准定的，Deep Agents 的源码里写死成一个常量（MAX_SKILL_DESCRIPTION_LENGTH = 1024，在 middleware/skills.py 里）。
Stripe 团队实测发现：当技能数量超过 150 个、再加上他们自己的系统提示词，前沿模型的质量就开始下降。
150 个技能，每个描述最多 1024 字符，光是这张技能目录就能占到十几万字符，还没算系统提示词本身、没算工具定义、没算用户真正问的那句话。
模型记得住这么多字。失准的是在这么长一张清单里做选择这件事本身。挑错技能，后面加载的工具跟着错，整条链就歪了。
技能数量仍然是个没解决的挑战，Stripe 团队还在找更好的方案。方向是混合选择系统，其中有个观察挺反直觉：在当前这个规模下，纯粹让模型来选，效果比 RAG 更好，RAG 是先用搜索捞出最相关的几条再喂给模型。原因是上下文完整时模型的判断更准。但规模再往上走，就必须加一层 RAG 或者分类器先做粗筛，再让模型做最终决定。这套混合方案的细节，Stripe 留给了一篇后续文章。
使用数据：83% 的人每周在用，一半的会话只有 2 轮
先说增长。Kai 开放预览后，一周内就完成了团队原定的季度采纳目标；大约 4 周里用户从 296 人涨到 5000 多，16 倍。
它就这么着起来了。人们用了它，然后就通了。
Sharadh Krishnamurthy · Stripe Agent Foundation 团队工程经理
涨上来的主要就是他们本来设计给的那批人：销售、财务分析师、业务运营。这些人一直被要求「去用 AI」，但没找到过一个符合他们干活方式的工具。Sharadh 转述过一段用户的原话：「我觉得之前那个东西没法上手，得调一堆旋钮。但公司要求我用 AI，我是真的努力过。」然后是：「这个好，我什么都不用调。」
今天的数字：83% 的 Stripe 员工每周都在用 Kai。按百分比算，市场（95%）和 GTM 团队（87%）的采纳率比工程团队还高。
2×
客户经理用 Kai 的那几周，销售活动量是自己不用的周的两倍
+39%
同一批人、用与不用相比，成交数的差距（机会 +17%、营收机会 +26%）
2.5 万
小时/年，从行政杂事挪到创收工作上
正文说会话大多是多轮，图上中位数只有 2 轮
关于「一次会话有多长」，同一篇材料里的文字和图表给出了两个答案。
文字给的印象是长：「大多数 Kai 会话需要很多轮」，配的例子是一个跑到 932 轮的会话。
图表给的是 35.9 万个会话的真实分布。
Stripe 官方统计图，基于 35.9 万个会话、134 万轮。左：每会话轮数，中位数 2、平均 3.7、p99 是 34。中：每会话模型调用，中位数 8、平均 15.8、p99 是 131。右：每会话工具调用，中位数 9、平均 19.1、p99 是 154。阴影带是 p25–p75，虚线是平均值。来源：stripe.dev。
一半的会话只聊了 2 轮。要到前 1% 才够得上 34 轮。图注写的是「用户行为正在改变，会话越来越多地用于深度多轮协作」，这句话讲的是趋势，而不是当下的多数。932 轮那个会话属于极端个例。
会话总量也有两个对不上的口径：文字部分给的是「每天超过 5000 个会话围绕数据分析」和全公司「超过 6 万个会话」，图上标的是 35.9 万个会话。统计范围的差异没有交代，所以这里分开标，不混算。
中位数 2 轮的会话，背后跑了 8 次模型调用
把三张图放在一起看：中位数只有 2 轮的会话，背后跑了 8 次模型调用和 9 次工具调用。
轮数少不代表任务简单。用户说一句，它在后面自己走了好几步，查了数据、拆了文件、写了草稿、又回头改。这也解释了为什么前面那三个中间件缺一不可：就算是一个只有两轮的短会话，底下也已经跑了十七八次调用，文件要有地方放，代码要有地方跑，上下文要有人收拾。
还没解决的四件事，和框架自己承认的边界
Stripe 有句常挂嘴边的话叫「我们还没赢」（we haven't won yet）。眼下还在啃的有四件事。
Kai 这种通用 Agent 会产生大量状态，反复调工具、拉大文档。他们在持续调两件事的平衡：真正发给模型的「活跃」上下文，和存在 S3、虚拟文件系统这类地方的「扩展」上下文。
500+ 工具、1000+ 技能，没有哪个模型能在这个量级的目录上做可靠选择。得加一层预筛，但预筛本身又会牺牲当前那个「上下文完整时模型更准」的优势。
用的人到了几千，得投入安全和合规护栏，别让 Kai 的触达范围跑到监管结构前面去。
有的团队要 Kai 先出计划再动手、多问几个澄清问题；有的要快速直给的答案。现在还是单人会话，路线图里有共享技能、共享产物，最后是多人（还有多个 Agent）在同一份产出上一起改。
这个产品的全部承诺就是你不需要调旋钮。所以现在这个责任落到我们自己头上，我们得造出那份智能，替所有人把这些都判断出来。
Sharadh Krishnamurthy · 谈为什么不把参数丢给用户
还有一处细节也说明这套东西还在路上：Kai 的地基 Deep Agents 当前版本是 0.7.4（2026 年 8 月 4 日发布），还没到 1.0，而且迭代非常快，0.7.1 是 7 月 30 日，0.7.2 和 0.7.3 是 8 月 3 日，0.7.4 是 8 月 4 日，五天四个版本。
治理这条为什么会进待办：两条写在框架仓库里的事实
上面四件事里，「治理和护栏」的分量得读 Deep Agents 的仓库才看得出来。下面这两条两篇文章都没提，出处是 LangChain 自己写在仓库里的威胁模型文档（libs/deepagents/THREAT_MODEL.md，文档开头标明是自动生成、实验性质）。
文档的前提假设里写着：需要隔离不可信工作负载的用户，应当自己扩展 BaseSandbox，或者用容器、虚拟机级别的沙盒，这个库不提供操作系统级的进程隔离。
这正好解释了 Kubernetes 上那层「每会话一个独立沙盒」为什么必须 Stripe 自己造。买来的是骨架，安全边界还得自己焊。
威胁模型里编号 T1 的条目写着：技能和记忆文件的内容原样注入系统提示词，没有任何过滤、转义或内容检查；技能名字校验不通过也只是警告，不会拒绝。
也就是说，谁能往技能目录里写文件，谁就能改这个 Agent 的行为。把这条和「100 多个团队各自维护 1000 多个技能」放在一起看，就明白「治理和护栏」为什么会进待办清单。
Agent 的骨架能买现成的，护栏还得自己造
Stripe 用一个开源框架搭出了全公司 83% 员工每周在用的 AI 助手 Kai，第一版一个工程师做了一周，一页带图讲完它买了什么、造了什么、在哪撞了墙。
↓ 一页读完 · 有一张会动的图
Kai 是 Stripe 给全公司非工程师做的 AI 助手：销售、财务、运营在聊天框里派活，它交出来的是能打开、能改、能发给别人的东西。LangChain 官方博客 7 月底发了一篇复盘，把这套系统怎么搭的拆到了零件级。
Stripe 的工程师早有自己的编程 Agent，一周能合掉一千多个代码改动。销售、财务分析师、运营这些人过不去终端、数据权限、安全审批这三道门槛。Stripe 的判断是：写代码的活形状统一，改文件、跑测试、提交，一套架构通吃；知识工作每个任务的工具、数据、产出，连「算干完了」的标准都不一样。
谁都能拖出一个专干某件事的小 Agent，最后搭出 4000 多个。麻烦不在数量：很多人写的是意思差不多、质量却参差的提示词，这么多小 Agent 散在各处，监控和维护跟不上。另一条路是让非工程师直接用编程工具，安全问题很快冒出来，代码团队还得去支持一群从没服务过的用户。
1000 多个技能来自 100 多个团队，挂在同一个平台上分层加载：销售运营和财务拿到的技能包不一样，个人还能在部门默认之上自己加。每个技能旁边摆着使用数据和质量信号，领域负责人不用问平台团队就知道哪个好使。
Kai 的地基是 LangChain 开源的 Deep Agents，相当于 Agent 的骨架加传动系统：模型调用循环、状态管理这些谁做 Agent 都得做一遍的通用件，被打包好了。一个工程师一周做出第一版，靠的就是这层，这个「一周」指的是第一个能跑起来的版本，它到今天这套全员在用的系统之间隔了多久、又投了多少人，两篇官方材料都没交代。
✔ 沙盒接口：沙盒是一间封死的隔离屋，模型现写的代码只在里面跑。关键是 Agent 站在屋外面把它当工具调，里面炸了，炸不到外面的凭据和数据通道
✔ 上下文自动压缩：一次对话塞给模型的内容用到 85% 就自动收拾一遍，被压掉的原文存进文件，需要时还能翻回来
✘ 技能内容的检查：技能文件原样注入系统提示词，零过滤零转义，谁能往技能目录里写文件，谁就能改这个 Agent 的行为
✘ 知识工作的护栏：编程有编译器、测试、git 兜底，知识工作一样都没有。Stripe 的硬规矩是「两个不相关客户的数据不能进同一个会话」，哪怕这个人分别有权看这两份
技能就是一个目录，里面放一份 SKILL.md 说明书：开头几行元信息（名字、一句话描述、允许用哪些工具），下面是给 Agent 看的干活步骤。Stripe 有 1000 多个技能、500 多个内部工具，全塞进去等于每次提问都先让模型读一本电话簿。
技能的一句话描述最多 1024 个字符。150 个技能，光这张目录就能占到十几万字符，模型记得住这么多字，失准的是在这么长一张清单里挑一个这件事。Stripe 说这道坎还没跨过去，方向是先用搜索或分类器粗筛一遍再让模型定；不过在眼下这个规模，让模型看完整目录来挑，比先搜索捞几条再喂给它更准。
Kai 开放预览一周就完成了原定的季度采纳目标，4 周里用户从 296 涨到 5000 多。涨上来的主要就是本来设计给的那批人：销售、财务分析师、业务运营。
83%
Stripe 员工每周使用 Kai 的比例；市场部 95%、面向客户的 GTM 团队 87%，都高于工程团队
2 轮
把 35.9 万个会话按轮数排队，站中间那个只有 2 轮；要到前 1% 才够得上 34 轮
8 和 9
那种只有 2 轮的会话，背后跑了 8 次模型调用、9 次工具调用，你说一句，它自己走了四步左右
- × 得会用终端
- × 拿不到数据权限
- × 安全审批过不了
→ 提交
· 过合规
一间封死的隔离屋
话说满了自动收拾