人不在环内：一个 AI 自主交付组织的概念契约
系列：Idea-to-Production · 概念篇
它不是聊天机器人，不是代码生成器，也不是有人盯着的流水线。它是一个交付组织——组织图、运行手册、审计轨迹全部住在 git 里。这篇用合同级的精度说清楚：“人不在环内”到底主张了什么、禁止了什么。
关于 AI Agent 的讨论，最后都会塌缩成同一个模糊问题：“能自动化到什么程度？”而大家给的答案都是感觉——“基本自动”“关键处留个人把关”。这篇讲相反的事：把自动化写成一份精确到可以逐条检验的契约，然后拿它去审你系统里的每一个环节，看你的“自动”在哪里自欺欺人。
全文不看代码，只讲概念、概念逼出来的机理家族、以及让这一切不腐化的方法论——界面截图只作为“概念落到运行系统里长什么样”的示意。
为什么值得看
感觉没法验收。“基本自动化了”这句话既不能被证伪，也不能被审计；两方各持一个百分比，项目就在“全自动”与“不敢放手”之间摇摆。把自动化改写成明示主张之后，每一条都能单独检验：过了就是过了，没过就是没过。这份契约同时还是审计尺子——拿它逐段走你的工作流，哪一段还依赖人回消息，哪一段就还没兑现。
你将学到三点
- 自主性要用主张来定义，不用百分比。 “没有人工审批门”是可检验的，“基本自动化了”不是。先把你的环写成明示主张，再逐段审计。
- 每删掉一道人工关卡，就必须长出一道机器关卡。 质量检查点、集成面评审门、端到端测试不是可选项——它们是这份契约的价签。
- 人的岗位是换层级，不是降频率。 不是“少审几次”，而是永久地从“环内逐任务审批”移向“环外改进系统本身”。
契约：四条主张
“人提供一个想法，系统把它交付到生产”听起来像口号。只有拆解成可以被证伪的主张，它才有工程含义。我们的四条：
| 主张 | 表述 | 它逼着你建什么 |
|---|---|---|
| 一个动作启动一切 | 人只创建项目（或写一条初始想法）；此后每一条任务都由 Agent 撰写、派发、认领、执行、评审 | 一个会写任务而不只是会干任务的调度角色 |
| 没有审批门 | 全环之内没有 PRD 签字、没有发布 go/no-go、没有人工回滚决策 | 真的能拦住坏东西的机器质量门 |
| 不为人类阻塞 | 给人的通知通道只是升级路径——记录并通知，然后按文档分支继续或干净停止；它从不等待回复，也从不等于批准 | 每个升级点都写明的“继续/停止”分支 |
| 人在系统之上，不在系统之内 | 人的固定工作是元评审：读治理报告，改进 Agent、技能、工作流、知识 | 会自我汇报的循环：审计轨迹、健康报告、效率信号 |
第二条和第三条是绝大多数“自主”Agent 系统悄悄失败的地方。砍掉它们，你得到的是一个演示；兑现它们，你才被迫去解决真正的问题。
它不是什么
三种误读会当场杀死这个概念，值得写成明示的排除项：
- 不是聊天机器人。 系统的中心不是对话，是一块带依赖、带锁、带只追加审计日志的任务看板。
- 不是代码生成器。 代码只是众多工件之一：需求、架构、UI 设计、测试策略、计划、发布说明、报告。真正有意思的工程在交接里，不在打字里。
- 不是有人盯的流水线。 在固定工位上监督（每条 PR、每次发布）仍然是环里坐着人。在这里，人看到的是报告，不是请求。
一句话画像：一个自主交付组织——和人类公司同一套家具（角色、运行手册、升级路径、审计），只是每把椅子上坐的都是 Agent，而且没有一把椅子为你预留。
为什么要接受这么极端的契约？
因为这个约束是一个“逼迫器”：它逼出来的三样东西，恰好是你一直想要而半自动系统从来给不了的。
代价一：没人签字，所以质量要么机器可执行，要么不存在。 每一句“资深工程师扫一眼就会注意到”都必须变成一份规格：逐交付物的评审检查点（没有记录在案的评审 PASS，任务不算 Done）、实现与测试之间的集成面评审门（BLOCK 判定直接阻断转移）、对着真实 UI 跑的端到端测试。弱关卡加自主性 = 以机器速度放大错误；这份契约把“关卡设计”推成了核心工程课题。
代价二：没人来解卡，所以失败必须有确定语义。 卡住的任务不能变成“等人处理”——那是撒谎。取而代之：诊断 → 有限次重试 → 用新建一条任务的方式升级（Agent 对 Agent），或记录通知后按文档分支干净停止。失败处理从此是工作流定义的一部分，不是临场发挥。
代价三：没人盯管线，所以可观测性是设计输入，不是事后补丁。 每一次认领、释放、过期、作业运行都落进只追加的审计日志；每个常驻循环自发健康报告和治理报告。系统必须在无人值守的当下之后依然可追问。
概念的三块骨架
撑起整个架构的是三个想法，每一个在系列里各有一篇深潜：
1. 三层分离，按变化速度分家。 知识（每个角色怎么干活）、调度（谁在什么时候干哪条）、档案（产出了什么）。混层是让多数 Agent 框架无法演进的根本病：你肯定不想为了教会一个 Agent 更好的检查清单而重新部署一次调度器。→ 详见《为什么要拆成三个仓库：知识、调度、档案的分离法则》。
2. 一张固定的九角色组织图。 产品与项目管理、工程架构、全栈工程、UI/UX 与文案、QA 与发布、服务与数据运营、市场与增长、行政与财务，外加平台侧的看门狗哨兵。一套词汇、两种拼写：角色的内容文件夹和运行时 ID 严格 1:1，绝不许漂移。→ 详见《九个角色如何分掉一家公司：一张不会漂移的 Agent 组织图》。
3. 工作沿着具名文档工件流动。 想法 → 需求 → 方案 → 设计 → 计划 → 代码与测试 → E2E → 发布 → 报告，十三个阶段，每个阶段吃一种工件、吐一种工件。这些工件就是 Agent 之间的 API——有类型、可检视，而且（《文档即可执行资产》一篇会论证）在最严格的意义上可执行。→ 详见《十三个阶段与它们的工件：Agent 之间的类型系统》。
概念落到运行系统里长什么样
两张截图，只回答一个问题：“这份契约从外面看是什么样”。
“人只写一条任务，看板自己长满”——字面意义上就是下图：一条“想法转需求”的任务被创建之后，设计、实现、QA、发布的卡片由 Agent 派发而出，每张带着角色与依赖：
“九角色”落到运维层面，就是九类工作实例：一个角色可以同时开多个实例、分布在多台机器上，每个实例绑定该角色的 Agent、技能、工作流与知识：
保证“一单一工”“不准自排班”的机器细节（原子认领锁、中心推送作业、过期回收）属于机理层，自成一篇 → 见《无人值守调度的三件机件：认领锁、中心推送、幂等键》。
方法论护栏：五条禁令守住概念
概念被放行第一个例外的瞬间就开始腐化。我们视为不容协商的不变式（破坏任何一条都是框架缺陷，不是局部 bug）：
| 禁令 | 它在守卫概念的哪一面 |
|---|---|
| 别“为了保险”加一道人工审批 | 它会悄悄把系统改回有人盯的流水线——契约本身就是产品 |
| 别让 Agent 自己排班、自己续命下一次运行 | 角色可能多实例，自排班必然重复干活；周期性的所有权在中心 |
| 别在赢得原子认领之前开工 | 两个实例做同一任务 = 重复产出 + 写冲突 |
| 别在交付文档里留 TODO 或占位符 | 下游 Agent 逐字执行文档——你的 TODO 会变成它的指令 |
| 别把同一条原则写进第二份文档 | 两份拷贝必然分叉；要引用就链接真源 |
注意五条里有四条关于文档与调度，而不是模型或提示词。这才是“自主 Agent 组织”的诚实画像：把分布式系统的纪律应用到 paperwork 上。
范围护栏
本篇只定义概念。刻意不涵盖：锁协议与 API 细节、发布流水线与云拓扑（机理层，同系列机理篇）、模型选型与成本（系列之外）、以及“你的团队该不该砍掉所有关卡”——这是一个系统的契约，可迁移的是“把契约写下来”这个纪律，不是我们的具体条款。
总结
- “人不在环内”是一份契约，不是一个置信度——四条可证伪的主张（一个动作启动一切；无审批门；不为人类阻塞；人在系统之上），每条都逼着某些具体机理必须存在。
- 接受这个极端约束是划算的，因为它买到的正是半自动系统永远不给你的三样东西：机器执行的质量、确定的失败语义、内置的可观测性。
- 在你自己的项目上从本篇开始：把你那个环的自主契约写成主张，然后沿着工作流走一遍，诚实标记出哪一段现在正在等人回复——那一段，就是你的第一个真正的工程任务。
本篇是 Idea-to-Production 系列的概念篇；锁协议、调度机件、发布拓扑等机理细节在同系列机理篇展开。如果你也在搭自己的 Agent 组织，欢迎从“写下你的四条主张”开始，把审计结果带回评论区。