0.1 三句话
- 人类协作的有效性，不取决于「开了多少会」，而取决于「承诺是否闭环」。 一个承诺闭环包含八环：差异 → 决定 → 证据 → 委托 → 授权 → 记录 → 责任 → 复查/撤回。
- Agent Native 组织不能复制人类会议的「形式」，只能迁移它的「功能」。 可迁移的是「承诺—验证—追责」；不能迁移的是社会性（信任/声誉/文化/仪式）与责任（法律/道德）。能否迁移，取决于能否把对应功能重建为可验证、可授权、可审计的硬约束。
- 工具不是会议软件，而是承诺闭环的载体。 它需要三件东西：共享状态（会议载体）、结构化产物（组织记忆）、硬约束（权限/状态机/可见性/审计）。
0.2 该做 / 不该做
| 该做 | 不该做 |
|---|---|
| 先建承诺闭环：谁决定、凭什么证据、授权到哪里、如何记录、谁承担后果 | 先买 Agent 平台，再想协作 |
| 选一个高价值、可验证的决策流做 90 天试点 | 一次改全公司所有会议 |
| 把纪要改成「稳定机制」：签发、核对、编号、时限、执行 | 只换纪要模板 |
| 用硬约束替代软规范：权限、状态机、可见性、审计 | 把规则写进 prompt/skill 就以为会执行 |
| 保留人类兜底：不可委托清单、checkpoint、决策日志 | 假设 Agent 会「自觉负责」 |
| 接受反例条件：如果等价物不能在三个以上流程中降低协调成本/错误率，命题不成立 | 把「功能等价」当公理 |
0.3 三类读者路径
| 读者 | 先读 | 再读 | 带走 |
|---|---|---|---|
| CEO / 管理者 | 0、1.1–1.3 | 5、9.2–9.4、10 | 一个决策流试点、一套承诺闭环指标 |
| 产品 / 技术负责人 | 0、3、5 | 8、9、10 | 会议载体、产物模型、MVP 边界 |
| Agent 开发者 | 0、6.2–6.4 | 7、8、10 | 四个限制、硬约束、失败模式 |
0.4 证据强度说明
本白皮书的核心命题是设计假设，不是已被证明的规律：
- 强证据：法规/标准/公开记录（A 级）支持「机制存在」，不支持「机制有效」；
- 中证据：学术理论（B 级）支持「结构解释」，不支持「迁移可行」；
- 弱证据：行业实践/作者推断（C 级）支持「设计方向」，不支持「因果结论」。
因此，白皮书的建议应被当作「可检验的设计命题」，而不是「最佳实践」。