Stripe 造了个知识助手，83% 员工每周用

写代码的人有了 Claude Code 和 Codex，做销售、财务、合规的人没有。Stripe 碰到的就是这个问题。

最后的答案不是一个聊天框，而是一套平台。

一、发生了什么

7 月 30 日，Stripe 开发者博客公开了内部知识平台 Kai。它 4 月上线，两周内覆盖公司大部分员工；到发文时，83% 的人每周使用，销售、市场、客户成功这些前台岗位几乎全员在用。

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

一条是低代码 agent 搭建器，员工自己建了四千多个。问题是大家写的提示词概念相似但质量参差，几千个小 agent 没人监控得过来。

另一条是让非工程师直接用编码 agent。能力强，但安全风险随之而来，写代码的质量团队突然要支持一批从来没支持过的人。

Kai 被拆成三层：与界面无关的接口层，让网页、Slack、内部工具、浏览器插件都能调同一个 agent；Agent Studio，让各业务域自己建、自己测、自己监控技能和工具；执行环境，提供会话级沙箱、虚拟文件系统和权限框架。调度骨架基于 LangChain 的 deepagents，跑在 Kubernetes 上。

它接了 1000 多个技能和工具，从 BI 看板到项目管理，再到 Zoom、Google Workspace。最长的一次会话跑到 932 轮，每天有 5000 多场会话围绕数据分析。

有一条约束写得很具体：两个不相关客户的数据，不能出现在同一次分析里。即使操作者本人对这两个客户分别都有权限，也不行。边界从"这个人能看什么"变成"这个任务该看什么"。

效果数字都来自 Stripe 自己：销售新人上手最快，使用量高出 2.7 倍；客户经理在用 Kai 的周，销售活动翻倍、商机多 17%、收入类商机多 26%、成交多 39%；一年约 2.5 万小时从行政事务转到创收事务。

二、跟你有什么关系

做内部工具的。 知识工作和写代码的差别不在难度，在"做完"的定义。代码有编译器、测试和版本回滚，知识工作三样都没有，所以平台必须先造出验收标准。

管数据权限的。 账号级权限不够用。真正的泄漏常常发生在同一个人把两块合法数据拼在一起的时候。

要采购或自建的。 别只看回答准不准，看它能不能嵌进员工已经在用的界面。让人为了用 AI 换一个软件，采用率就死在这一步。合同里还要写清数据留在哪、模型能不能换。

三、可以照着做的三步

1. 先定"谁有权判定合格"。 每个业务域指定一个负责人，由他决定这个领域的答案什么算对、什么算过期。没有这个人，知识库只会越积越旧。
2. 把权限做成任务级。 在数据访问层加一条规则：单次会话只能落在一个客户上下文里。技术上不难，难的是承认账号权限不等于任务权限。
3. 底座统一，资产分散。 平台团队只维护沙箱、调度、审计和接口；技能、模板、工具选择交给业务域。反过来的做法——平台团队替所有部门建 agent——一定跟不上。

四、三个别信的说法

"83% 周活，说明员工真的需要 AI。" 周活只证明它被打开。更硬的信号是 932 轮的会话、每天 5000 场数据分析，以及大多数会话需要多轮才能结束。这些说明它在承担真活，不是玩具。

"知识助手就是把文档接进检索。" 检索只是入口。Stripe 花力气的是两件别的事：在一千多个工具里选对技能，以及在知识工作里补上代码世界天然存在的隔离和回滚。

"这些效率数字可以套到自己公司。" 全是厂商口径，比较的还是同一批销售"用 Kai 的周"和"不用的周"。这种对比排除了人的差异，但没有排除业务节奏的差异——旺季那几周本来成交就多。

五、一句话结论

知识工作的 agent 难在没人给它写编译器，所以先造验收标准，再谈模型。

信息来源

• Meet Stripe's Knowledge AI Platform，Stripe Dot Dev Blog，2026-07-30

功能与价格以官方公告为准。本文写于 2026 年 10 月 19 日。