Stripe Kai：企业 Agent 真正难的不是模型，而是 1000 个技能怎么管

LangChain 8 月 3 日发了 Stripe Kai 的案例，这篇比普通框架更新更值得看。因为它第一次比较具体地展示了一个大型公司内部 Agent 进入生产后，真正的复杂度在哪里。

Kai 是 Stripe 的公司级 Knowledge AI Platform，面向所有员工，而不只是工程师。它连接 Stripe 的内部数据仓库、Slack、Google Suite，可以产出报告、dashboard、文档和分析结果。按照 LangChain 的披露，Kai 在 4 周左右增长到 5000 多名用户，周活覆盖 83% 的 Stripe 员工。

这说明一件事：企业 Agent 的入口不一定是 IDE。工程师已经有 Claude Code、Codex、Cursor，但销售、财务、运营、市场这些岗位需要的是“会用公司上下文做事的工作台”。Kai 的定位很准确：像 coding agent 一样能持续产出 artifact，但服务的是非工程岗位。

技术上，Kai 基于 Deep Agents / LangGraph。它的架构分四层：Deep Agents 处理通用 LLM primitives；Stripe 自己的 harness 接安全、基础设施和内部服务；配置层让团队创建不同 Agent；最上层是员工实际使用的 Kai UI。

这套分层非常有启发。企业不应该从零手写每一个 Agent loop，也不应该把通用框架直接暴露给业务用户。合理做法是：通用 harness 解决工具调用、streaming、状态和 middleware，公司 harness 解决权限、数据、审计和内部规范，业务团队在更高一层配置自己的技能。

Kai 最值得写的是三个生产化组件。

第一是虚拟文件系统。Kai 跑在云服务里，不是本地进程。Stripe 用 S3-backed virtual filesystem，让 Agent 在一个会话里持续读写文件、引用上下文、演进 artifact。每次 sandbox 执行前同步文件进去，执行后同步产物出来。对 LLM 来说，文件系统是非常自然的长期上下文组织方式。

第二是 sandbox middleware。Kai 会执行 Python 做数据分析、图表和文件处理，但 Agent 本身不在 sandbox 里跑。它把 sandbox 当工具调用。这能把“模型生成代码”和“代码真实执行”隔开，边界更清楚，也更容易做权限和审计。

第三是 summarization middleware。长会话会吞掉上下文，尤其企业任务常常不是一次问答，而是反复改报告、补数据、查证据、更新图表。Kai 通过总结阈值、总结模型、输出长度等旋钮管理成本和性能。

最难的是技能和工具规模。Stripe 有 500+ 内部 MCP 工具、1000+ 技能。没有任何模型适合一次性把这些全塞进上下文。Kai 用技能选择来动态加载工具，先让模型判断该加载哪些技能，再由技能的 allowedTools 控制工具上下文。这是企业 Agent 的关键设计：不是工具越多越好，而是每一步只让模型看见该看的工具。

这篇案例也暴露了下一阶段问题。LangChain 提到，当技能数量超过 150 且叠加系统提示时，模型质量会下降。Stripe 正在探索 RAG 或分类器预筛，再让 LLM 做最终选择。这说明 Agent 规模化之后，技能路由本身会成为一个新系统。

我的判断是，Kai 代表企业 Agent 的一个清晰方向：不是“一个超级聊天框接所有系统”，而是“内部技能市场 + 权限边界 + 工具路由 + 文件化上下文 + 可审计沙箱”。模型很重要，但企业里真正难的是把公司的隐性知识和操作规范变成 Agent 能可靠调用的结构。

参考来源：LangChain：How Stripe Built Kai, its Company-Wide AI Agent, on Deep Agents。