从人类闭环到 Agent 闭环

目的

这套文档的目的不是先把团队变得“规范”，而是先让人能闭环。人类工作能闭环以后，后续 Agent 才能进入同一套闭环。

如果人类流程本身不闭环，Agent 只会把混乱加速：

口头需求
-> 无 Driver / Approver
-> scope 不清
-> 直接改代码
-> 没有验证证据
-> 上线没人记录
-> 出事靠群聊记忆

目标是把任何工作都变成可关闭的链路：

任务
-> Driver / Approver
-> scope
-> 验收标准
-> 执行记录
-> 验证证据
-> review / approval
-> 发布或关闭
-> 反馈回流

Agent 只能接入这个链路中的明确槽位。

五个闭环

1. 工作入口闭环

有人提出
-> 被记录
-> 被 triage
-> 有 Driver / Approver
-> 有验收标准
-> 进入 backlog / planned / rejected

最小字段：

字段 为什么必须有
目标 防止做错问题
Driver 防止多人都以为别人负责
Approver 防止没人拍板或多人拍板
Scope 防止无限扩散
验收标准 防止做完没人能判断
风险 防止上线时才发现敏感点

2. 交付闭环

开始做
-> 产生 patch / PR
-> 跑检查
-> review
-> merge / close / retry

PR 模板、测试命令、review 规则不是流程装饰，而是让“能不能合并”有证据。

3. 发布闭环

确认 release scope
-> 部署
-> smoke
-> 观察
-> 回滚或确认
-> 发布记录

发布 checklist 的作用不是增加仪式感，而是让上线和回滚可追踪。

4. 反馈闭环

线上反馈 / 事故
-> 记录
-> 分级
-> 修复任务
-> 验证
-> 关闭
-> 复盘 action

如果反馈只留在群聊里，团队会不断重复同类事故。

5. 后续 Agent 闭环

Task
-> Context
-> Agent Run
-> Artifact
-> Test Evidence
-> Human Review
-> Merge / Retry / Close

这一步放在人类闭环稳定之后。Agent 不能只说“完成了”，它必须留下 artifact、测试证据、风险说明和下一步建议。

草台团队的 L0 版本

如果团队还比较混乱，不要先推完整工程体系。先只推 5 条硬规则：

  1. 没有 Driver / Approver 的任务不排期。
  2. 没有 Scope / 验收标准 的任务不进入开发。
  3. 没有测试或验证证据的 PR / patch 不合并。
  4. 没有 rollback 的发布不上线。
  5. 没有业务验收或关闭结论的任务不算完成。

这 5 条能执行，团队就开始有闭环；执行不了，更多文档只会变成摆设。

一页纸版本见 02-L0最小闭环-l0-minimum-closure.md。

Agent 接入原则

Agent 不是来替代闭环的。Agent 是进入已经存在的闭环，承担明确环节：

人类闭环环节 Agent 可以做 Agent 不应该做
工作入口 整理群消息、生成任务草稿 替业务决定优先级
交付 修改代码、补测试、生成 PR 草稿 绕过 review 合并
Review 找风险、查测试缺口、解释 diff 充当最终 approval
发布 检查 checklist、生成 release note 直接部署生产
反馈 总结日志、起草 action items 单独判定最终根因

判断是否闭环

问 8 个问题：

  1. 这件事在哪里被记录？
  2. 谁负责推进到关闭？
  3. 怎么判断做完？
  4. 改动证据在哪里？
  5. 验证证据在哪里？
  6. 谁拍板进入下一步？
  7. 失败后怎么 retry 或 rollback？
  8. 结果怎么回流到任务或文档？

如果回答不了，人还没有闭环，Agent 也不应该接手。

下一步阅读

读完或填完这份文档后，通常继续看：