WorkOS工程师Ryan Cooke：软件工厂的解锁不是基础设施，而是把工程流程变成可执行的自动化

WorkOS最初搭建的软件工厂，把代码放进Cloudflare沙箱，接入模型路由，喂入提示词，生成PR——结果和工程师在笔记本上跑Claude Code几乎没有区别。产品工程师Ryan Cooke在2026年AI Engineer世界博览会上描述了这个令人失望的发现，并由此提出一个论点：沙箱、模型和仓库是必要条件，但不是充分条件；真正的软件工厂必须把组织自身的工程流程编码进自动化。

Cooke认为行业正在优化错误的变量。Ramp报告超过50%的合并PR来自AI，Spotify报告1500多个AI生成的PR被合并，Stripe每周合并超过1000个PR——这些数字描述的是生产速率，不是价值交付速率。当构建工厂本身消耗工程时间甚至需要专职团队时，仅凭PR数量判断成败会掩盖一个更难回答的问题：功能是否更快到达了客户手中？他提出的替代衡量方向是功能交付时间、交付时缺陷率和问题解决时间。

WorkOS的回应是把工程流程拆成可执行的自动化单元。他们构建了两层系统：TARS是面向用户的界面，嵌入Slack、Linear和GitHub，通过webhook订阅项目事件；Horizon是基础设施编排层，管理沙箱池和事件循环。关键设计在于TARS不只是生成代码，它参与工程流程本身。

具体机制是：Linear中的工单有依赖关系，一张工单阻塞另一张。当TARS收到工单完成的webhook，它自动拾取下一张被解锁的工单继续执行。工程师可以在步骤之间要求TARS重新评估项目计划，发现实施过程中暴露的遗漏。这种自主性来自对项目状态的响应，而不是把每次编码会话当作孤立任务。

规划层面，WorkOS使用Hilltop文档——一种产品需求文档，汇集项目目的、客户需求、竞品分析、早期设计和里程碑。PM agent读取Hilltop文档，将其分解为带依赖链的工单。人类审阅并补充上下文，合并后Horizon自动解锁下一张工单。Cooke以他负责的Vaults API项目为例：在Slack中用几句话描述目标，TARS创建Linear项目、Notion草稿和决策日志，他再补充规格、填补模糊区域，然后交回执行。Cooke报告团队因此做了更多项目简报和Hilltop工作，因为agent解决了空白页问题；但草稿经常严重高估项目范围，需要工程师大幅削减。

Cooke把内部MCP网关称为上下文引擎，认为这是任何团队起步时最值得投资的部分。它不只是连接工具，还在工具描述中编码组织知识：告诉agent Snowflake里有哪些语义表、描述什么内容、回答哪类问题应该查哪些表。WorkOS后来把这个网关开放给Slack查询做数据和客户分析，发现它同样适用于非编码场景。Cooke的原话是：agent可以用最少的上下文自己搞清楚，但很慢，它们花token重新发现约定，我们不断收紧那个循环。

但Cooke没有给出数字化的交付或可靠性结果。他提出的三个衡量方向是交付与客户影响、可靠性（缺陷率和恢复时间）、自愿采用（工程师是否主动选择TARS和云端沙箱而非本地工具），并明确说自愿采用大量是轶事性的。两个未解决的边界值得注意：WorkOS尚未确定这个工厂的授权模型——谁可以授权agent在其连接的系统上执行操作；公司级记忆层是计划中的下一步，尚无完成实现。Cooke在演讲结束时直接向同行提出授权问题，表示希望了解其他团队如何处理。