背景与问题
把实现任务交给 AI agent 时最大的风险不是”写不出来”，而是”状态不可控”：任务到底进行到哪一步？验证是 agent 自己说的还是机器确认的？“完成了”是谁的定义？如果委托方进程重启，被委托的任务是死是活？
约束
- agent 输出不可信为验证结论：agent 可能宣称完成而实际未通过验证
- 委托方与被委托方进程必须解耦：委托方崩溃不能带走任务
- 生命周期每个状态必须可复现、可审计，不允许”隐式成功”
- 运行环境零第三方 Python 依赖（纯标准库），保证在任何机器上可跑
方案与权衡
task-delegation 定义四阶段生命周期：prepare → start → verify → review。关键设计是两条分离的通过线：
- 确定性验证（verify）：测试、命令、退出码——机器说了算；
- 语义评审（review）：需求是否真的被满足——人显式 accept，agent 无权代行。
任务进入 accepted 必须同时满足两者。pi_delegate 在进程层补齐：start 返回句柄，worker 独立进程续跑，支持查询 / 取消 / 续跑 / 取回证据。
被否掉的替代方案：
- 让 agent 自报完成状态——等于让被执行者给自己的作业打分；
- 单进程内嵌 agent——委托方崩溃即任务丢失，无法审计。
验证
测试规程覆盖 T0–T40；验证记录含两次 macOS 环境复跑（2026-10-02、2026-10-10）与 Gate 3B 报告。生命周期每个状态迁移在规程中有对应用例。
结果
两个工具构成日常可用的委托工作流：确定性部分全部由机器判定，人只在语义层出场。委托任务规模的量化数字未度量，不提供编造值。
局限与后续
无图形界面，上手成本在 CLI 一侧；语义评审目前依赖人读证据，尚无结构化的评审辅助；验证记录产生于 macOS 环境，其他平台复跑情况未记录。