九类 AI Agent 无人值守运转软件公司全流程

系列：Idea-to-Production · 实践篇。同系列还有《人不在环内》（概念）、《十三个阶段与它们的工件》（机理）、《文档即可执行资产》（方法论）；分层背景见《为什么要拆成三个仓库》，调度机件见《无人值守调度的三件机件》。

一个人类只提供想法，系统把它交付到生产——组织图、运行手册、审计轨迹全在 git 里。这篇完整走一遍：从一条人写的任务开始，经过需求、架构、实现、测试、发布，直到产品上线并被循环照看，全程没有任何一步在等人类批准。

为什么值得看

每个”AI 帮我写 App”的演示都停在同一个地方：人还在开车。总得有人评审 PR、点部署、写发布说明、半夜看错误日志。真正有意思的问题不是”Agent 能不能写一个函数”，而是一整个交付组织能不能无人值守地运转。

我们的答案一句话：人提供想法，系统交付到生产，人不在环内。 本文不涵盖模型选型、提示词技巧和成本工程——只讲动机、最难的那个坑、让它成立的架构，并附循环运转中的真实界面。

你将学到三点

1. 用机器关卡替代审批关卡。 等人签字的环不是自主环。质量要靠自动检查点来执行：逐交付物评审、集成面评审门、端到端测试——而不是靠会议。
2. 任务派发分两棒，切在工件边界上。 需求产出后派发设计类任务；实现计划产出后，才派发构建、测试、发布类任务——每条任务在被创建的那一刻起就是自足可执行的。
3. 绝不让 Agent 自己排班。 一个角色可能多实例并发，谁自己续命下一次触发，谁就在重复产出。周期性工作的所有权在中心调度器，它只推给恰好一个在线实例。

动机：为什么非要把人从环里请出去？

起点是一人公司之梦：创始人只做战略，其余一切——产品规划、架构、设计、工程、QA、发布、运营、增长、治理——是真的被完成，而不是被”辅助”。

“人不在环内”为什么是一条精确主张、而不是营销话术？因为它逼着你解决三件半自动系统永远不必解决的事：

• 没人签字。 没有 PRD 审批、没有发布 go/no-go、没有人工回滚决策。质量要么机器可执行，要么不存在。
• 没人解卡。 给人的通知通道只是升级路径——记录并通知，然后继续或干净停止，从不等待回复。
• 没人盯管线。 所以系统必须自备审计轨迹和健康报告；可观测性是设计输入，不是事后补丁。

人的固定岗位随之上移一层：在系统之上工作——读每周治理报告，改进背后的 Agent、技能、工作流与知识——而不是在系统之内当逐任务的闸门。

最大的挑战：Agent 会逐字执行文档

问题很多，但有一个压过所有其他：阶段之间的交接物是文档，而 Agent 会把文档逐字执行——包括其中的歧义。

当”写给人类看的架构文档”变成下一个 Agent 的输入，我们付出的学费是：

• 一句人类同事会在脑子里自动补全的模糊描述（”加个基础鉴权”），会变成一场幻觉出来的子系统。
• 交付文档里的一个 TODO 或占位符，一定会被下游 Agent 执行。那是会跑的废代码。
• 同一条规则在两处文档里略有不同的表述就会分叉，而 Agent 会随机选一处——无声无息。

对策最终沉淀成四条不容协商的不变式：

给所有在建 Agent 管线的人的通用教训：把文档当代码对待。它们有类型化的接口、会藏 bug、而且真有人会去生产环境里运行它们。 在我们的案例里，那个”有人”一周 7 天、一天 24 小时地跑。

它是怎么工作的

三个仓库，三种职责

系统按变化速度和所有权切分：

知识层说”下一步做什么”，调度层说”哪个实例、什么时候、且只有一个工人去做”，档案层存”做出了什么”并喂给下游。

九个角色，一块任务看板

创始人坐在战略位，之上是九个专职角色 Agent：产品与项目管理、工程架构、全栈工程、UI/UX 与文案、QA 与发布、服务与数据运营、市场与增长、行政与财务，外加平台侧负责锁回收与失联标记的看门狗哨兵。每个角色以一个或多个工作实例运行——按角色绑定 Agent、技能、工作流、知识库（符号链接，绝不复制，改动即时生效），背后接哪家 AI CLI 由你配置。

生命周期：从想法到生产的十三个阶段

工作沿 A–M 阶段流动：需求 → 架构与 UI 设计（并行）→ 详细设计 → 测试策略 → 实现规划 → 仓库脚手架 → 实现 → 端到端测试 → 发布 → 运营与增长报告。每个阶段各有一种文档工件、一份自己的工作流文件。

没有人类在场，靠两个机制让循环保持诚实：

• 逐交付物评审检查点——没有子代理评审的 PASS 记录，任务不算 Done；不可恢复的失败走”诊断 → 有限重试 → 新建升级任务”，而不是打电话给人。
• 发布评审门——实现到测试的转移，必须通过对聚合差异的集成面评审；BLOCK 判定直接阻断转移。

两棒派发：让”一条人类任务”够用的一招

人类只写一条任务。项目管理 Agent 随后分两棒派发其余一切：

人类 ──► [阶段 A 任务] ──► requirement.md
                                 │
                    ┌── 第一棒：派发设计与脚手架 ──┐
                    │   B ∥ C → D → E → H → F      │
                    └──────────────┬────────────────┘
                                   │ plan.md + 仓库骨架就绪
                    ┌── 第二棒（带依赖） ───────────┐
                    │  I 实现任务（按特性，来自 plan.md）│
                    │  J E2E 任务（按特性，Depends On I）│
                    │  K 发布任务（Depends On I + J）    │
                    └──────────────┬────────────────┘
                                   ▼
                            终端用户（生产环境）

实现任务在 plan.md 存在之前根本无法有意义地撰写——而 plan.md 又依赖全部上游设计完成。把派发切在 requirement.md / plan.md 的工件边界上，保证每条任务出生即自足。每个特性的 E2E 任务在该特性真实 UI 完成的那一刻解锁——QA 从不需要等整个应用构建完。

发布不是终点

Initial Launch 之后，常驻循环接管——全部由中心推送，没有一个自己续命：

客户在第 3 天报的 bug，随第 15 天的发布上线。issue 的关闭是两阶段的——修复提交只打 fix-applied 标签，真正关闭发生在携带该修复的发布完成时：客户永远不会被告知一个还下载不到的”已修复”。

界面实拍：概念落到运行系统里

准备阶段是每台工作站一次性投入：为每个角色建实例、绑定资源、注册启动，之后舰队按角色自行领活。

人类的全部贡献：先创建项目——

再写那条唯一的”想法转需求”任务：

从此看板自己长满：

你可以旁观一个 Agent 的工作现场——实时的工具调用与进程状态：

落地后自动给出运行摘要——耗时、写入文件、最终报告：

控制中心仪表盘一眼看清循环现状——任务按状态与角色分布、在线实例、今日过期锁：

最后一段流程动画，完整回放第一跳”想法到需求”的端到端过程：

取舍与诚实的边界

• 自主比人工团队要求更强的质量机器。 每删一道人类关卡，就必须原样长出一道机器检查——评审检查点、发布评审门、每日 E2E。关卡弱而自主性强 = 以机器速度放大错误。
• 阶段之间用文档工件交接，而不是代码 API。 换来的是整个”公司”可检视（组织图、运行手册、审计都在 git）、客户端无关；代价是上面那节的纪律必须一直在线——文档即可执行资产。
• 升级通道存在，但被刻意削去了权力。 缺凭证、或判定标准真歧义时，通知人类，然后按文档分支继续或停止——环从不阻塞等回复。这是一个哲学选择：交付的可用性优先于每个决定的确定性。
• “跑通”的定义是一条完整闭环，不是逐项目证明。 框架的合格线是：一个真实项目从人类想法到已发布、有文档、有观测的产品全程无人值守地走完一遍，即可认证整个模式。你的技术栈与团队规模上，效果因人而异。

总结

1. 把人请出环不是目的，是逼迫器。 没人可签字之后，质量被迫机器化、排班被迫中心化、观测被迫内置化——这三样才是真正赚到的东西。
2. 最值得直接搬走的原则是”文档即可执行资产”。 当 Agent 逐字消费你的规格，歧义就是生产缺陷——给你的文档一个类型化接口，把漂移当 bug 修。
3. 对你自己的工作该问的那个问题：哪一个人类动作，如果写得好，能让整条管线从它生长出来？先把它之后的派发自动化掉，再在你今天停下来等批准的位置，逐一补上机器关卡。