工具与系统 | 协作的结构

本章回答：为什么需要工具，而不是规范？工具应该提供什么？最小可行系统是什么？

8.1 为什么需要工具，而不是规范

会议的结构，属于「边界类」问题：谁可以发起、谁可以参加、谁可以决策、什么必须记录、什么必须批准。这些必须由工具强制，而不是靠 Agent 自觉。

但「硬约束」需要前提：Agent 的所有副作用经过策略执行点（PEP）。如果 Agent 可以直接读写数据库/文件系统/API，硬约束就会被绕过。

工具需要覆盖五个能力域。它们不是「分层架构」，而是「横切关注点」：

为什么不是「五层」？

因为「授权」不是最底层，而是横切所有层；「组织层」的权限图与「授权层」重复。用「能力域」更准确。

会议载体不是「聊天窗口」，而是六个组件：

一句话：会议载体是一个「可编程的共享状态机」。

当前 Agent 的技术形态天然是「轮次对话」：

顺序偏差的四种机制：

工程解法：

阶段 1：独立提交（互不可见）
阶段 2：盲评（匿名）
阶段 3：讨论（公开，记录顺序）
阶段 4：决策（规则/人类裁决）

顺序偏差不能完全消除，但可以控制、审计、复现。

会议产物不是「纪要」，而是结构化对象：

产物	作用	关键字段
Decision	记录决定	context, options, rationale, delegation, decider, dissent, review_date
Task	跟踪执行	owner, due, acceptance, status, dependencies
Artifact	管理文档/产物	type, version, source, verification, status
Authorization	管理权限	subject, action, delegation, scope, expiry, conditions, audit
Context	共享上下文	layer, content, source, version, ttl
Role	定义角色	mission, inputs, outputs, permissions, escalation, lifecycle
Memory	组织记忆	type, content, source, related, status
Event	事件日志	meeting_id, actor, type, content, timestamp

重要修正：

这些对象构成一个「产物图」：

Meeting → Decision → Task → Artifact
Meeting → Authorization
Role → Authorization
Decision → Memory

产物载体不是「文件柜」，而是「可查询的组织记忆」。

不需要一上来做平台。一个最小可行的系统，需要六件事：

组件	MVP 实现
身份	Agent ID、凭证、角色
策略执行点	拦截工具调用/数据访问
三个对象	Decision、Task、Authorization
事件日志	append-only，带签名/哈希
人类审批	队列、SLA、超时默认
schema 校验	字段/状态/必填

注意：没有身份/PEP，授权只是文档；没有 schema，产物会腐烂；没有审批 SLA，人类会成为瓶颈。

真正的 MVP 是 2–4 周可交付的，不是「五层平台」。

级别	准入门槛（须有证据）	一票否决
L0 提示	无	—
L1 单 Agent 有工具边界	工具白名单、调用日志	无日志
L2 多 Agent 有人类 owner	每任务唯一人类责任人；事件日志可检索	决定无 owner
L3 角色与授权	capability 范围/期限；回收演练通过；越权拒绝率可测	无身份/无 PEP/回收未测
L4 协议与审计	阶段转换有权限校验；注入红队；重复副作用测试；审计抽样达标	盲评可泄露/重试重复执行
L5 校准委托	分决策类错误率与升级阈值；成本/延迟预算；人类理解度抽测	无错误率基线/批准为橡皮图章
L6 自演化	外部审计、回滚、角色变更独立复核	自改权限

说明：

本章结论：

工具不是「会议软件」，而是「承诺闭环的载体」。它需要身份、策略执行点、共享状态、结构化产物、审计。没有这些，会议只是聊天，纪要不是承诺。