Clive Notes
Stripe · Kai · Knowledge AI Platform

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

Stripe 工程师已有每周合并上千 PR 的编程 Agent（Minions）， 但销售、财务、TAM 却被终端、数据权限和安全审批挡在门外。 本文整理 Stripe 如何从两条失败路径走到公司级知识工作 Agent —— Kai。

综合整理 · 2026-08 Stripe 原文 LangChain 案例 小互解读

1. 背景：工程师有 Minions，其他人没有

Stripe 自研的编程 Agent 叫 Minions：无人值守、端到端一次成型， 每周合并一千多个 PR；代码仍由人 review，但几乎没有人类手写的代码。 （背景来自 stripe.dev 上两篇 Minions 文章；LangChain 那篇几乎没提。）

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

三道门槛

  • 终端：CLI / 开发环境对非工程师不友好
  • 数据权限：仓库、CRM、财务数据不能随便接
  • 安全审批：企业合规拦下了“自己乱接工具”

真正缺的东西

  • 查数仓、会前研究客户账户
  • 事故分流、营收情景建模
  • 合规审查准备
  • 能打开、能改、能发出去的产物
一句话痛点 公司在要求所有人用 AI 提效，但现成工具要么是工程师玩具，要么扛不住 Stripe 的数据安全与工作流形状。

2. Kai 之前的两条死路

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

第一条路 · 无代码搭建器

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

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

第二条路 · 直接用编程 Agent

有人真这么干了：为了迁就编程工具，把自己的工作流改掉。 安全问题很快冒出来；同时，代码质量团队突然要开始支持一群从来没服务过的非工程师用户，凭空多了一大摊活。

路径 A

NoCode Agent Builder

人人可搭、挂工具、专事专用

  • 扩散太快（4000+）
  • 提示词质量参差
  • 难监控、难维护
路径 B

Coding Agents 硬上

用 Claude Code / Codex 干知识工作

  • 安全风险外溢
  • 非工程师改工作流迁就工具
  • 代码质量团队背锅支持

3. 核心判断：写代码 vs 知识工作

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

写代码

形状统一

具体改什么每次都不一样，但流程和工具基本不变：

改文件→ 跑测试→ 提交

语言可以是 Ruby 或 Java，活的形状还是那个形状。所以一套 Agent 架构就能通吃。

知识工作

光谱另一头

研究客户账户 vs 准备合规审查：

  • 工具不一样
  • 数据不一样
  • 产出不一样
  • 连「什么算干完了」都不一样

你没法拿一套“编码环”硬套上去。

因此的产品方向 不把非工程师往开发工具那边推，而是照他们的干活方式重做一个：开箱即用、不用配旋钮、出厂就懂 Stripe 内部怎么运作的「AI 同事」。

4. 做成平台要抓准的三件事

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

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

二、Agent 必须会“到处跑”

Agent 出现在哪里，和它知道什么一样重要。不是所有人都在浏览器标签页干活，更少人在终端。 所以知识 Agent 不能只是一个产品，必须是一个平台：能嵌进财务预算建模工具、BI、Slack、Chrome 扩展…… 把人拽出原工作流塞进新 App，会失败；为每个界面各做一套 Agent，也会维护爆炸。

三、护栏得从零造

编程 Agent 坐在几十年积累的可验证护栏上：编译器拒语法错、测试抓回归、git 让错误可回滚。 知识工作几乎没有这些构造。

Stripe 的核心不变量例子 「你不应该在同一次分析里合并两个无关客户上下文的数据。」 用户可能各自有权访问两边，但它们永远不能出现在同一会话里。 隔离边界不是「这个人的 token 能看什么」，而是「给定这次任务上下文，允许看见什么」。

5. Kai 是什么、怎么用

Kai（Knowledge AI Platform）是给每位 Stripe 员工的公司级生产力 Agent。 用法像编程 Agent，只是服务不写代码的人：开会话、聊天派活，旁边挂着报告、看板、文档等产物； 接着聊，产物跟着改。

演示印象（11 秒） 一句长提问：给 Stripe Press 公开活动做逐周上线计划 + 可交互邀请函，并基于过去 90 天流量最高的 3 本书推荐主题、书单与讲者（每条给出处）。 Kai 拆成查数据 → 研究人 → 做判断 → 排计划 → 写出 event_invite.html，产物可打开、可导出，倒计时还在走。

6. 怎么建：四层架构 + 三个中间件

单体 Agent 编码不了全部约束；让每个业务团队各自搭安全、托管、高性能的 Agent 基础设施也不现实。 Stripe 把 Kai 拆成可共享的层。

UI / Surfaces

大多数人用的网页与 Slack；任意内部工具可通过 API / Chrome 扩展嵌入同一 Agent 服务。

配置层

AgentStudio：领域负责人构建、测试、监控自己的 skills、自定义 Kai Agent 与工具选择；看用量与质量信号。

Stripe Harness

接安全姿态、基础设施与内部服务，做成有主张的运行环境（“Stripey” 的问题在这里解决）。

Deep Agents

LangChain 开源 harness：工具调用环、中间件组合、流式与状态管理——买来的地基，一个工程师一周做出初版。

让生产可用的三个中间件

中间件 解决什么 关键细节
Filesystem 云端会话里持久读写产物与上下文 S3 支撑的虚拟文件系统；sandbox 执行前 sync in、执行后 sync out
Sandbox 安全跑分析代码与文件处理 Agent 在沙盒外运行，把沙盒当工具调用，边界清楚
Summarization 长多轮会话不爆上下文、不烧死成本 阈值 / 摘要模型 / 输出长度可调；有会话到过 932 轮
执行环境的飞轮 Agent harness、沙盒、工作流编排、访问控制，刻意与面向产品的 Agent 共享同一套底座。 内部知识工作碰的是同样敏感的数据，必须同一安全合规条。改进一次，内外两边一起受益。

7. 技能爆炸：1000+ skills 怎么管

编程 Agent 有天然优势：文件夹本身就是技能与上下文的组织方式。 Kai 没有这套现成结构，却要面对 500+ 内部 MCP 工具 与 1000+ skills（100+ 团队贡献）。

下一阶段难题 纯 LLM 选型在当前规模还行，但目录再大就需要 RAG / 分类器预筛，再让 LLM 做最终选择。 「技能路由」本身正在变成一个新系统。

8. 效果与仍未解决的问题

83%
员工周活；开放预览一周打完季度目标
16×
约 4 周从 296 → 5000+ 用户
+39%
AE 使用周 vs 未使用周：成交更多

还没赢

9. 可带走的结论

对企业做 Agent 的启示

  • 编码 Agent ≠ 全员 AI；知识工作要另建平台
  • 别让人人乱搭小 Agent，也别硬推终端
  • 通用 harness 买/开源；公司层做权限、审计、数据边界
  • 技能联邦给领域专家，平台管路由与治理
  • 产物要能打开、能改、能发出去——否则只是聊天

一句话收束

编程 Agent 让工程师先摸到 AI 的杠杆； Kai 的意义是把同一种「能持续产出」的杠杆，接到销售与财务真实的工作方式上—— 难的不是再聪明一点的模型，而是把公司隐性知识与操作规范，变成 Agent 能可靠调用的结构。