别把那一周当起点

Stripe 的 Kai 细节公开以后，圈里转得最多的不是什么四层架构、沙盒设计，是那句话：“一个工程师，一周完成初始版本。”提气，确实提气。但这句提气话正在喂养一个典型误会——以为代理框架已经成熟到拿来即用，以为底下那层基建真的可以跳过去了。

先补一个被“一周”这个数字遮住的事实：Stripe 为采用 Python 原生栈，重建过内部服务支持。那层改造跟 agent 半毛钱关系没有，是早几年就干完的。Kai 要连数据仓库、连 Slack、连 Google Suite，全靠这层服务托着。没有这层统一过的底座，每个连接都得跟历史遗留接口做手术——那种状态下别说一周，四周能跑通第一个版本都算运气。

所以那一周到底买的是什么？Deep Agents 确实把工具调用循环、中间件组合、流式处理、状态管理这些通用骨架做完了，这几块原本够干几个月的。但“通用”和“Stripe 自己的安全边界、权限体系、服务注册”之间的那道定制层，没有任何开源框架能替你写完。初始版本能一周出来，是因为定制层的胶水早就铺好了，剩下的只是拼装。地基在前，工具是尾声——这道理我讲了多少遍了，今天又多一个案例证据。

看他们的四层架构：基础层，接内部服务和安全的定制层，配置层，UI 层。规矩，没什么花活。最让我舒服的是沙盒：代理本体在沙盒外跑，执行分析代码、解析 PDF、处理演示文稿的工具全关在沙盒里；跨会话持久化走基于 S3 的虚拟文件系统，同步进、同步出。这套设计不是在演示模型多聪明，是在回答一个更工程的问题：模型万一错了，伤害半径是多少。

有个数据让我愣了一会儿：技能超过 150 个时，前沿模型跟系统提示组合的质量开始下降。这个数不算高，但它说明一件很硬的事——技能不是索引里躺着的一堆名词，每一条都要占上下文空间。多到一定程度，模型开始分不清工具跟工具的边界，选择器选错，参数文档串味，下限就从那儿漏。团队的回应也清楚：动态工具加载，用技能选择去门控上下文，再保留一组固定基础技能守住策略一致性。模型层的容量是模型的，工具层怎么取舍是工程的事，谁也别想替谁。

用户数字里最戳叙事的是最后一条：预览后一周达到季度目标，四周内从 296 涨到 5000 多人，每周会话超 6 万次，83% 的员工每周都在用——而且市场部和 GTM 团队的采用率，比工程部门还高。

外边天天喊 AI 替代程序员，Kai 吃到的最大增量反而是那些被开发工具挡在门外的非工程师：综合数据、头脑风暴、起草文档、跨职能对齐。这些活儿过去要么卡在数据权限上，要么靠人拉群反复翻译需求。现在只需要一个始终在线、生产就绪的界面，把问题讲清楚就行。它不是在取代程序员，是去补那条过去没人愿意补的沟——工程和业务之间的沟通成本，这次接了一根管子过去。

再看他下一步列的是什么：改进技能选择、加强治理与护栏、做行为层面的个性化。没有一条是“换更强的模型”。模型一年换几茬，去年火的今年已经没人提，但安全边界和工程素养，三年后还是这些词。具体方案会过时，工程价值观不会。

我的态度很明确：别把那一周当起点。框架把通用骨架做完了，安全边界、上下文取舍、跟内部服务的对齐，框架替你干不了。先把地基铺好，再谈工具带来的效率。Kai 的这一周，是 Stripe 把地基填平之后结出来的果实——不是那套框架从天上掉给它的种子。顺序反了，就是沙子上盖楼；楼越高，塌得越响。