模式矩阵/模式白皮书/Governance
ADPS Agent 设计模式白皮书 · 模块总纲
治理模块 · 把 Agent 的自主权变成可管理的工程对象
授权、问责、限界；双轴矩阵、横切工程面、治理生命周期与控制平面。
当 Agent 只能给建议时，治理主要表现为内容审核。它开始调用工具、修改业务状态、委派子 Agent 以后，治理转为运行时工程：谁代表谁，凭什么执行当前动作，防线失效后最大影响停在哪里，事后能否还原责任与结果。
单步合规也不能证明长程任务没有漂移。治理既检查当前动作，又持续比较原始目标、当前状态和真实结果。
三个治理目标
| 目标 | 需要回答的问题 | 工程对象 |
|---|---|---|
| 授权 Authorization | 谁代表谁，可以对什么资源执行什么动作 | 身份、委托链、策略、工具、参数与资源 |
| 问责 Accountability | 谁在什么版本和策略下做了什么，结果如何 | run、trace、审批、版本、状态差异与外部回执 |
| 限界 Containment | 控制失效时，最大损失停在哪里 | 沙箱、租户边界、配额、预算、熔断与补偿 |
G1 决定一次意图是否获准，G2 限制获准动作出错后的最大影响，G3 管理某项能力长期可以放到什么程度。G4 保存三者需要的事实；G5 把确定性裁决落到运行节点。
v0.4 的三层结构
双轴矩阵
“认知功能 × 执行拓扑”仍是 ADPS 的主结构。七类认知功能与六种执行拓扑保持不变，矩阵包含 27 个占格核心模式。治理行保留 G1 审批门、G2 爆炸半径控制和 G3 渐进承诺。
横切工程面
| 工程面 | 范围 | 主要产物 |
|---|---|---|
| 观测与证据 | 全部模式和生命周期阶段 | 事件、因果、版本、状态差异与回执 |
| Evals 与测试 | 产物、轨迹和业务结果 | 回归、grader、确定性测试与业务验收 |
| 身份、策略与安全 | 主体、委托、权限和边界 | allow、deny、ask、限额与执行条件 |
| 人机交互 | 澄清、审批、暂停、接管和恢复 | 结构化事件、审批上下文与恢复坐标 |
G4 从“治理 × 编排”移出，成为第 28 个核心规范，分类为“横切核心 · 观测与证据平面”。核心总数仍为 28：27 个矩阵模式，加 1 个横切核心规范。
生命周期
ReAct 位于受控运行内部，是一次任务的感知、推理、行动微循环。Evals 在离线评测、灰度、运行监控和修改复验中反复出现。它们都不需要新的矩阵坐标。
贯穿实例：一批薪酬付款怎样走完生命周期
下面的实例用于解释模式组合，不代表具名企业案例。
| 阶段 | 薪酬 Agent 的工程动作 | 留下的证据 |
|---|---|---|
| 登记与归属 | 登记 Agent、所有者、用途、生产环境、两项能力和退役条件 | Agent ID、owner、能力清单、凭证引用 |
| 设计与版本 | 固定模型、提示词、工资规则、付款工具、审批策略与数据依赖 | workload digest 与依赖清单 |
| 离线评测 | 覆盖常规批次、新入职、跨地区税务、重复请求与恶意参数 | 回归结果、失败类型、成本与边界测试 |
| 影子与灰度 | 先与人工结果对照，再让少量常规批次进入建议模式 | 人工差异、采纳率、长尾分布 |
| 受控运行 | G1 固定付款意图并审批；G2 限定租户、金额和批量；G5 在提交前复验 | Intent、Approval、配额、hook 裁决 |
| 观测与归因 | G4 连接来源账本、参数、付款回执、状态差异和后续对账 | 跨系统 trace、外部回执、业务结果 |
| 修改与复验 | 付款 API 升级后冻结旧权限，对受影响能力重新跑回归和影子验证 | 版本差异、复验结果、变更审批 |
| 权限处置 | 校验能力可进入受限自动执行；提交付款继续保留人审；试点结束则回收入口 | 能力级授权证书、降级或退役记录 |
治理控制平面
一个 Agent 可以在本地拦截工具调用。多个 Agent、多个业务域和跨 Agent 委派出现后，组织需要共同的注册、策略、执行和证据服务。中央平台维护身份、策略格式、遥测与跨域审计；业务域继续定义风险、验收、审批人与事故响应。
治理合同
intent_id: int_01K3...
principal: user://finance/108
agent: agent://payroll/prod-v7
run_id: run_8842
tool:
name: create_payment_batch
digest: sha256:4ef...
resource_scope:
tenant: tenant_42
max_records: 20
policy:
version: payroll-policy-v12
decision: ask
preconditions:
source_ledger_version: 417
approval:
expires_at: 2026-08-19T09:30:00Z
max_uses: 1
execution:
idempotency_key: payrun-2026-08-batch-17
工具名不足以支持治理裁决。工具版本、规范化参数、资源范围、委托身份、环境、累计预算和业务前置条件都会改变风险。
治理模式的职责
| 规范 | 控制对象 | 关键边界 |
|---|---|---|
| G1 审批门 | 当前高风险意图 | 恢复前验证意图与前置条件；批准只消费一次 |
| G2 爆炸半径控制 | 动作、run 与 Agent 群体的最大影响 | 硬边界不能由 Agent 自评或历史成功率改写 |
| G3 渐进承诺 | 能力与场景的自治档位 | 权限可以晋级、维持、降级、冻结和退役 |
| G4 可观测性 | 横切证据链 | 观测事实与评测判断分开保存 |
| G5 钩子流水线 | 确定性执行节点 | hook 是执行位置，不是策略来源或业务裁判 |
公开工程实践与研讨记录
DeerFlow Guardrail 与双层授权按五个公开 PR 展示工具调用前拦截、身份传播、RunJournal、RBAC Provider，以及装配时过滤与运行时复核的演进。
治理模块第一次研讨会保留了沙箱与业务授权、审批恢复、Agent 注册、证据归因、能力级放权和离线评测等具体讨论，并说明这些讨论如何进入 v0.4。
仍在验证的机制
- 委托身份链：用户、Agent、workload、run 与下游工具之间怎样保持身份和权限收敛。
- 持久化意图：审批等待后，哪些前置条件变化必须让旧批准失效。
- Agent 注册与退役：试点、凭证、版本、队列和责任人怎样进入统一生命周期。
- 联邦治理：中央规则与业务域责任怎样组合，例外和事故由谁裁决。