Delivery Harness Framework / DHF 治理判定流程
工具真正跑起来之前发生了什么。
生命周期流程图和 Skill 路由图回答的是一个任务走哪条路线。这张图回答的是另一个问题：对任意一次工具调用，什么条件成立它才被放行，不成立又会怎样。拒绝边和验证失败回边都画了出来，因为只有成功路径的 agent 就是个 demo。
治理判定流程
每一次工具调用都要过这道门。
把它当成强制路径读，不是当工作流读。守卫跑在 PreToolUse，所以拒绝发生在副作用之前，不是之后。注意图的结构本身编码了两条性质：阶段解析不出来时退回只读而不是退回信任；自行声明的阶段依然碰不到受保护目录。
flowchart TD
Req(["agent 发起一次工具调用"])
Lane{"执行 lane 是哪一类"}
HITL["高影响动作
需要单独的人工授权
上线 / 推送 / 部署"]
Phase{"工作阶段能否解析"}
ReadOnly["关闭式失败
退回只读"]
Declare["agent 自行声明阶段
codex-task declare"]
Cap{"该阶段是否允许这项能力
写仓库 / 联网 / 远端 / 子 agent"}
Scope{"这次调用会碰到哪里"}
Protected["受保护目录或持久化写入
shell 配置 / 开机项 / 定时任务"]
Tier{"工具类别的风险分层"}
Block["PreToolUse 返回真实阻断
原因 + 风险分层"]
Run["工具执行"]
Evidence["追加 guardrail_decision
经 schema 校验的 JSONL"]
Verify{"新鲜验证是否通过"}
Compact{"是否发生了上下文压缩"}
Successor["转移记录先到者胜
后继有且只有一个"]
Handoff(["checkpoint + 下一项安全任务"])
Req --> Lane
Lane -- "本地开发" --> Phase
Lane -- "操作员演示" --> Phase
Lane -- "客户 / 生产" --> HITL
HITL -- "已批准" --> Phase
HITL -- "未批准" --> Block
Phase -- "解析不出" --> ReadOnly --> Declare
Declare -- "只放行低 / 中风险" --> Cap
Phase -- "可解析" --> Cap
Cap -- "不允许" --> Block
Cap -- "允许" --> Scope
Scope -- "受保护目录或持久化" --> Protected --> Block
Scope -- "在治理根目录内" --> Tier
Tier -- "高: 远端 / 密钥 / 破坏性 / 动态执行" --> Block
Tier -- "低 / 中" --> Run
Block --> Evidence
Run --> Evidence
Evidence --> Verify
Verify -- "失败: 退回 agent" --> Req
Verify -- "通过" --> Compact
Compact -- "是" --> Successor --> Handoff
Compact -- "否" --> Handoff
classDef decision fill:#f0eaff,stroke:#8a4fff,color:#17241f;
classDef deny fill:#faeaf1,stroke:#d13574,color:#17241f;
classDef runtime fill:#e9f7f5,stroke:#0f9b8e,color:#17241f;
classDef build fill:#fbf0dc,stroke:#b26a00,color:#17241f;
classDef verify fill:#eaf6f0,stroke:#12805c,color:#17241f;
class Lane,Phase,Cap,Scope,Tier,Verify,Compact decision;
class Block,Protected,ReadOnly deny;
class HITL,Declare build;
class Evidence,Successor runtime;
class Run verify;
怎么读这张图
这张图在主张的四件事。
1. 权限按阶段收紧八个生命周期阶段各自声明是否允许写仓库、联网、访问远端、派发子 agent。能力检查是一道门，不是提示词里的一句建议。
2. agent 扩不了自己的影响范围自行声明阶段能放行普通的低风险和中风险动作，但永远打不开受保护目录，持久化写入在任何阶段都被拒。
3. 被拦下的也留痕，不只留成功的阻断边和执行边最后汇到同一次证据追加，所以审计轨迹既能看到跑了什么，也能看到拦了什么。
4. 失败有地方可去验证失败退回 agent，而不是一路滑到交接；发生压缩时走先到者胜的转移记录，重试不会分裂出两个后继。
边界
这张图没有主张的事。
这是源码里实现、并且已经上线到一台机器运行时的强制路径。生产强制、客户采用和商业验证是分开判定的，目前仍未验证——以架构状态页为准。图里还有一处已知限制我没有藏：宿主的 ask 响应会 fail open，所以高风险类别走的是硬阻断而不是审批弹窗，Plan Governor 保持 shadow，production_status = no_go。
下一步