OpenAI Agentic Factory：一人公司怎么缩小版——哪些上代理，哪些必须人签
大家好，我是珂抖屁。
大厂开始把软件研发说成「工厂」了：编码、审查、修复、部署，一段段交给代理，人退到定义目标与最终签字。公开材料里，OpenAI 把这套叫得更直白——agentic software factory，围绕 Codex 一类编码代理把流水线串起来。
一人公司看热闹容易，照搬容易翻车。我关心的不是「他们有多强」，而是：流水线里哪些步骤适合上代理，哪些步骤必须人签。 下面按 Agent 现场拆，附上公开报道里能核的叙述，再落到我能用的缩小版。
以上为公开页品牌图与官方博客页头，不代表官方背书。
公开叙述里的工厂长什么样
综合公开报道与对方材料（如 Pragmatic Engineer 对 OpenAI 工程负责人的访谈、以及 OpenAI 工程博客《Harness engineering》），大致链路是：
1.人定义结果：说清楚问题与期望产出；判断、优先级、品味压在这一步。
2.代理拉上下文：仓库、内部文档、协作与日志等（大厂内部接线远深于外部产品）。
3.代理改代码并自测：做到目标附近，本地验证。
4.构建 / 测试 / CI：代理开 PR，守到 CI 变绿，失败就修。
5.多视角代理审查：不是一个泛泛 reviewer，而是按领域配置的多代理审查；变更按风险分级，高风险更严，低风险可走更轻的路径。
6.人批准后再部署：部署侧再挂代理「护送」变更进生产，读懂变更、盯信号，甚至为变更建监控视图。
7.生产观察回流：性能类工厂/巡检把回归喂回修复；事故响应机器人可收集上下文、提议缓解，但执行仍常需人点头。
图注：公开报道 / 对方材料。左为 OpenAI 工程博客页头，右为 Pragmatic Engineer 文中工厂示意图，仅作文内归因，不作自测声称。
对方材料还提到一些量级感受：例如部分系统在约半年里负载出现数量级增长；另一篇工程博客写内部实验产品在数月内由代理生成约百万行量级代码、约一千五百个 PR、人工几乎不手写代码。这些数字我当作公开叙述，不当成我自己的实测。
图注：公开报道 / 对方材料（Pragmatic Engineer 访谈、OpenAI《Harness engineering》），只作文内归因示意，不作自测声称。
读这些材料时，我抓的不是「自动化有多炫」，而是两句反复出现的结构：人定结果与风险策略；代理拥有中间闭环。 缺前者，工厂只是加速制造半成品；缺后者，人又变回全能苦力。
Agent 现场：大厂流水线真正换的是什么
换的不是「会写代码」——模型早就会写。换的是反馈闭环的所有权：
•谁负责把 CI 守绿？代理。
•谁按领域视角扫变更？代理群。
•谁护送上线并看信号？代理。
•谁在出事时先收集上下文？代理。
人变成：定目标、定风险策略、在关键门禁签字、在代理卡住时代入「缺什么能力/护栏」。
公开博客里还有一个很「一人公司」的提醒：环境没设计好时，代理不会变强，只会反复撞墙；人的工作变成补工具、补文档地图、补可执行约束。这跟我日常体感一致——你骂模型没用，不如问仓库对代理是否可读。
这跟一人公司日常体感很像——只不过大厂有近乎不计成本的 token、内部技能库和专职基础设施；你没有。所以不能抄编制，只能抄门禁思想。
一人公司缩小版：先画四段，再决定谁上手
我把缩小版压成四段，故意比大厂短：
A. 定单（人） 写清：要解决什么、做成什么样算过、明确不做的事。没有这一段，后面全是空转。定单也包括风险标签：这单是低、中、还是高。
B. 实现 + 自测（代理） 本地改代码、跑测试、开 PR。权限默认本地可写；推保护分支、动密钥要二次确认。实现阶段允许代理「守绿」，但不要默认给生产钥匙。
C. 审查（代理初审 + 人终审） 让代理按清单扫：安全面、数据面、计费面、对外文案面。人只看风险点和验收标准，不把整份 diff 当小说读完才算负责——但高风险必须人签。一人公司没有专职安全评审，清单化是唯一可复制的办法。
D. 发布（人签 + 代理盯） 发布按钮人按；发布后日志/错误率/关键路径，可让代理巡检并汇总。回滚决策人做。发布后十分钟的盯盘，往往比发布前再改三行更重要。
这就是工厂的骨架。少一段，自动化就会在那段塌方。
哪些上代理，哪些必须人签
我给自己划的硬线：
更适合上代理
•多文件但验收清晰的实现与重构
•测试失败后的常规修复循环
•PR 描述、变更摘要、检查清单初稿
•只读巡检：日志关键词、错误率波动、依赖过期提醒
•文档与仓库内约定的同步（过期说明、目录地图）
必须人签（或人执行）
•方向与范围：做什么、不做什么
•计费、权限、隐私、对外承诺相关变更
•生产密钥、支付、删除类操作
•高风险合并与正式发布
•事故缓解的最终执行（代理可建议，人点头）
•对外口径：客户答复、公开声明
一句话：代理可以提速执行，不能提速责任。
如果只能记一条：凡是「出错后不可廉价撤回」的动作，默认人签。邮件群发、扣款、删库、改权限，都属于这一类。
风险分级：一人公司版「高/低风险」
大厂用自动化风险分类。一人公司可用更土的标签，贴在任务单上就行：
•L（低）：文案微调、单测补充、无行为变更的重构 → 代理可走远一点，人抽查
•M（中）：接口字段、后台逻辑、非计费配置 → 代理实现，人审关键 diff 再合并
•H（高）：鉴权、支付、数据删除、生产配置 → 代理最多出草案与检查清单，合并与发布必须人手
没有分级，你就会用对待 L 的心态去放行 H——这是一人公司最常见的炸法。
分级还有个副作用：它强迫你在开工前想清楚「这单到底有多危险」。想不清的单，先当 M 或 H，别假装是 L。
我自己的判断：抄工厂，先抄「护栏」，别抄「吞吐」
公开叙事很炫：吞吐暴涨、PR 暴涨、IDE 使用下降、代理护送上线。一人公司若只抄吞吐，抄来的是 CI 账单和一堆半绿半红的分支。
更值得抄的是三样护栏：
1.完成定义写进仓库，让代理和未来的你读同一份真相
2.风险分级 + 人签门禁，低风险提速，高风险刹车
3.生产回流：发布不是结束，巡检与回滚预案才是闭环
也可以抄第四样，但要克制：多视角审查。你不必真的养一打专家代理，只要固定四问——安全？数据？计费？对外口径？——让代理先答，你再签字。
OpenAI 的工厂建立在极深的内部接线与资源上；你的缩小版建立在清晰边界上。边界对了，代理才是合伙人；边界糊了，代理只是加速制造债务。
今晚如果你只改一件事：给进行中的任务贴上 L/M/H，并把 H 的合并权从「自动」改回「我签」。工厂不必很大，门禁先立住。