卖的是基础设施，不是又一个 agent
Factories 没有自带模型。它把软件开发拆成分诊、写规格、实现、评审、验证五个常规环节，每一环都可以交给 agent，也可以留给人；模型和 harness 用户自己挑，Warp 明确说接 Codex 和 Claude Code 效果一样。往上接的是 Linear、Jira 这类工单系统和 Slack、Teams 这类消息系统——也就是说触发器是工单和消息，不是终端里的一句提示词。 真正的设计选择在于：每条流水线由版本受控的配置文件定义。改一条流程和改一段代码走同样的评审路径，这让「我们的 agent 流程是怎么跑的」变成可 diff、可回滚的东西，而不是散在各人机器上的脚本和习惯。所有 agent 跑在同一个环境里，还带来一个副作用：不同配置的效果可以横向比，token 花销可以统一看。
目标客户是自建不起这套东西的公司
Lloyd 给的市场判断很直接——大公司已经在自己造了。Stripe 公开讲过内部用于自动化开发的 minions 系统，Ramp 做了在部署后持续盯自家代码的后台 agent。Factories 面向的是没有资源从零搭一套的中小团队，用他的话说，把这件事做对「是一项巨大的基础设施工程」。 值得记下的是他给的一个数字：自家团队每周的自动化比例约在 30–35%，并预期随模型和 harness 变强而上升。这个坦率的量级比「AI 写完所有代码」的宣传更有参考价值——它说明当前工程化水平下，流水线接管的是有限但确定的一段，剩下的仍要人做。
值得留意的地方
目前是封闭测试，没有公开定价和开放时间。另外这类产品的成败通常不在编排本身，而在评审与验证环节的可靠性——一条能把十个 agent 排好队的流水线，如果验证不过关，产出的只是更快堆积的待审 PR。想评估它的团队，与其看能接多少模型，不如先量一件事：你们现在每周有多少工单是能被清晰写成规格的。
via: TechCrunch、Warp 官网