https://jiajia.fun/qa/a94bb8ad-%E7%9C%8B%E7%9C%8B%E8%BF%99%E4%B8%AA-x-com-2115862731610107965

# 看看这个https://x.com/bholmesdev/status/2115862731610107965

回复 群友 1： 这是 Ben Holmes 在 Warp 写的长文《So you want to build a software factory?》，昨天下午发的。这基本上就是 Warp Factories 的产品宣言，顺手也把团队 agent 基建该长什么样讲了一遍。 他给 software factory 的定义是：把团队零散在各人机器上的 agent 配置收拢成一处的“一套系统”。类比 CI——CI 不是每人自己写脚本，agent 也不该是每人自己调 prompt。动机他明说了三条：安全统管、ROI 可计、以及团队效率只靠复制粘贴传播。 七件必需品，按顺序看其实是一条数据流水线： factories as code。用类似 Terraform 的思路，把模型选择、secrets、MCP、workflow 写成版本化配置，走 code owner review、可回滚。有个细节值得注意：这份配置对 agent 也是可读写的，agent 能自己提 diff、跑 benchmark、然后自我改进。这就从“人配置 agent”转成“agent 参与配置自己”，是个不小的跳跃。 统一会话历史。他专门骂了把本地 Claude/Codex session 打包传 S3 的做法，要求 session 默认过同一处。隐含前提是 agent 要跑在云上，才能做 AFK 自动化和 cu 验证。同时保留个人 inbox 做过滤，这个设计是对的——数据共享但注意力不共享。 benchmark。拿团队自己过去的会话在固定 repo state 上重放，换模型比较，用 LLM judge 打分，看性价比曲线。他自己都开玩笑说这是 “Me Bench”（对应 SWE-bench）。上线后还要盯 cost per PR、总 cycle time 这些生产指标。 chat from anywhere。Slack/Teams 多人 prompt、Linear/Jira 打标、web 视图。多人 prompt 是关键，agent 变成团队里一个可被 @ 的成员。 artifacts。不只活动，要有产出物：关联 issue、PR、计划、录屏，跟 trace 放一起，挂到 PR 上。 cu。他直接把端到端验证称作当前 agent 的头号瓶颈。所有 agent 带 cu 工具，PR 时给前后截图和录屏，还自动剪辑、标注点击、剪掉空等，三四分钟压到 15 秒。移动端那段最实在——不用本地配 Xcode，agent 起原生模拟器录屏给你看。 agent debugger。完整 trace 加时间线视图，能点进 subagent 看交接，也能看到每次工具调用。 我的看法： 这篇最有价值的是把“验证”放在了产品核心，而不是把“生成”放在核心。cu 那条和 debugger 那条合起来看，Warp 卖的不是更会写代码的 agent，而是“让 reviewer 敢点 merge”的信任基础设施。这跟前面聊过的 Addy 那篇其实是一条线——reduction of supervision cost，任务自带可读的验收信号。 第二个观察是它和个人的工作方式正好相反。个人用户这边主流方向（skills、本地 harness、自己的配置）是分散的、可随意改的；软件工厂是集中的、要走 review 的。这两件事不冲突，但边界要划清：团队该统一的其实是模型选择、secrets、MCP、权限这层“事实性配置”，而上层的工作流习惯、prompt 风格留给个人。把 prompt 也强行统一，往往变成一个所有人都绕过去的大文件。 第三个是风险。这七条里真正难的不是工具，是会话数据的归属和留存——统一历史意味着团队所有人的 agent trace 都进同一个池子，权限怎么切、敏感内容怎么脱敏、离职和审计怎么处理，文章基本没碰。另外配置对 agent 可写这条，等于把自我改进放进生产链路，得有很强的 gate，否则 agent 会朝着“让自己更容易跑过”的方向改 benchmark 和验收标准。 对我们这种规模的实践来说，可以先做最小版：一份进 repo 的 agent 配置、一套带验收条件的任务模板、cu 录屏挂在 PR 上。这三件做完，收益已经出大半，benchmark 和 debugger 是等数据攒够才有意义的东西。 顺便，你刚才那张图我没取到，要我一起看的话重发一下。