上一章完成的是关系定义：委托发生后，团队要分别安排判断与执行，落实后果处理职责，并让人在不同任务角色中保留监督与接管能力。本章把这组关系转成设计方法。
为了避免把方法误解成差旅报销的专用模板，本章改用客户退款作为教学案例。退款任务会读取订单、物流与政策，可能计算金额、生成对客说明并调用支付工具。它同时包含信息判断、外部行动与组织协作，适合检验一套方法能否把委托落实为产品机制。
经典 Design Thinking 和双钻仍然提供问题发现、发散、收敛、原型与测试的基本节奏。本章不另造一套取代它们的流程。需要补上的，是 Agent 开始代表人连续行动后，团队必须显式处理的对象：委托主张、边界机制、可执行行动循环（Agent Loop）、系统行为评估（eval）、任务角色研究、专家审查和运行回写。
整套方法有一个进入门和五个动作：形成委托主张，落实边界机制，构建可执行原型，组织三路证据，运行治理并回写。4.7 会用一轮退款设计把它们重新连起来。
图 4-1 从问题证据到运行回写的设计闭环
这张图是本书对 Agent 设计工作的操作化，不是经典 Design Thinking、双钻或某个风险框架的原图。箭头表示证据关系，不表示项目只能按一个顺序推进。原型可能推翻委托主张，任务角色研究可能暴露无效审批，运行事件也可能要求团队回到入口重新判断是否继续。
4.1 问题发现与进入门
Design Council 把双钻作为设计过程的简化表达，其 Framework 页面也明确说明过程并非线性。1 Agent 产品仍需这项能力。团队要先确认用户、业务和受影响者面临什么问题，再决定用规则、搜索、预定义工作流、生成式功能还是 Agent。
4.1.1 先证明问题，再讨论委托
退款团队若从“做一个退款 Agent”开始，后续研究很容易变成替既定方案寻找理由。更合适的起点是观察真实退款：客服把时间花在什么地方；政策冲突出现在哪里；哪些订单需要跨系统核对；延迟、误退和重复退款分别影响谁；现有流程为何没有解决这些问题。
调查可能得到三类结论。
第一，步骤固定、判断规则清楚、例外很少。预定义工作流或规则引擎通常更容易验证和维护。
第二，大部分步骤固定，只有材料整理或内容生成存在变化。团队可以保留确定性流程，只在局部使用生成式能力。
第三，任务需要根据订单状态、物流回执、政策版本和用户补充动态选择下一步，而且路径难以预先列完。此时才有理由评估 Agent。Anthropic 对 workflow 与 agent 的工程分类也区分预定义代码路径和由模型动态选择过程与工具的系统，并建议从最简单可行方案开始，在任务表现与复杂度、延迟、成本之间权衡。2
“能不能做”属于能力问题，“值不值得委托”属于产品与组织选择。问题发现阶段必须保留后一项判断。
4.1.2 把问题证据放进入口门
问题真实，不代表项目已经具备探索 Agent 的条件。团队还需要一名或一组有权作出范围决定的人，把研究、业务、风险和资源证据放在一起，作出三种结果之一：进入探索、缩小试点或停止。
表 4-1 Agent 探索入口门
| 入口项 | 必须明确的内容 | 退款案例中的表达 |
|---|---|---|
| 指定决策人 | 谁有权决定进入、缩小或停止 | 退款业务负责人会同产品与风险角色决定 |
| 问题与替代证据 | 问题怎样发生；规则、搜索或工作流为何不足或已经足够 | 固定政策由工作流处理，只探索材料冲突与跨系统状态不一致 |
| 目标与非目标 | 这轮要改善什么，明确不做什么 | 减少事实整理与状态核对；不自动改变政策，不默认执行资金动作 |
| 成功与停止条件 | 看到什么证据继续，出现什么情况暂停或结束 | 冲突能被识别并移交；出现越权读取或状态不明仍重试则停止试点 |
| 用户与受影响者 | 谁使用、谁审批、谁会承受错误或延迟 | 客服与政策负责人使用；客户、财务和组织也可能受影响 |
| 范围与风险容忍度 | 哪些订单、数据、工具、环境与后果在本轮范围内 | 沙盒订单、只读物流、模拟支付；不接受生产重复退款 |
| 入口结论 | 进入探索、缩小试点或停止，并记录理由 | 只在沙盒探索政策冲突分支 |
这里的成功与停止条件只用于决定是否继续探索，不等于产品已经满足第五章将讨论的质量门槛。
这套入口门是本书的方法，不是外部框架规定的固定会议、岗位或阈值。NIST AI RMF 1.0 的 MAP 与 MANAGE 支持团队识别情境、受影响者、影响和风险处置，但不替组织指定谁拍板，也不给所有项目统一的风险容忍度。3
扩大用户群、任务、数据、工具、生产权限或外部后果时，项目不能只在原方案上加一项功能。这些变化会改变委托前提和影响范围，必须重新经过入口门。结果仍然可以是继续探索、缩小试点或停止。
4.1.3 经典方法扩展的是观察对象
访谈、服务蓝图、用户旅程和可点击原型仍能解释用户目标、角色压力、信息结构与交互表达。盲点出现在团队只把研究结果转成页面和理想流程时：Agent 在界面背后读取什么、如何选工具、何时暂停、外部状态是否真的改变，都可能没有进入设计材料。
因此，共情要纳入委托意愿、监督成本和受影响者；定义要加入判断与执行分工、后果处理职责和非目标；发散要比较自主安排、权限与恢复路径；原型要覆盖连续行动；测试与迭代则要把系统、任务角色和运行证据连起来。扩展发生在设计对象上，不声称本章五个动作来自 Design Council。
4.2 动作一：形成可证伪的委托假设
问题通过入口门后，团队先写一份委托假设。这里的“可证伪”用白话说，就是能被失败样本推翻的暂定安排。它不是功能清单，也不是一句“需要人工介入”，后续原型与测试必须有机会证明它不成立。
退款案例的第一版委托假设可以这样写：Agent 只读取本次退款所需的订单、物流与现行政策；规则和证据一致时，它可以整理事实、建议资格并计算金额；政策冲突、外部状态不明或金额超过组织阈值时，必须暂停相关行动并交给相应角色判断；对客承诺与实际退款在试点阶段都要获得授权角色批准；客服可以修改范围、驳回建议、停止任务并接管。
一份委托假设通常包含多条可追踪的委托主张。每条主张要写清什么判断或执行交给 Agent，人在什么角色介入，谁会受影响，失败时怎样停止和处理后果。
4.2.1 四个概念保持主体清楚
第三章已经区分四个概念：能力回答 Agent 能否稳定完成某类工作；Agent 的能动性回答它可使用什么、影响什么；Agent 的自主性回答某项判断或行动在多大程度上不经人介入；人的能动性回答人能否理解、选择、拒绝、停止和接管。
第三章提出的“两根旋钮”特指 Agent 的自主性与人的能动性。Agent 的行动范围另行设置。模型效果提高，不代表系统应自动获得更多权限；增加确认，也不证明人的能动性已经提高。确认者缺少证据、时间或真实否决权时，按钮只记录了一次输入。
4.2.2 五种角色是阶段分工
《Levels of Autonomy for AI Agents》原论文把操作者、协作者、顾问、审批者和观察者列为 L1 至 L5，对应逐级增加的 Agent 自主程度；论文同时说明等级越高不代表越好。4 本书有意重组这组名称，把它们用于同一任务中可切换的阶段角色。这是本书的方法选择，不是原论文的等级定义。
一次退款中，客服可以先作为操作者确认订单范围；Agent 只读整理材料时，客服转为观察者；政策冲突出现后，政策负责人作为顾问补充判断；计算异常时，客服与 Agent 作为协作者修正；调用支付工具前，获授权的客服审批角色决定是否放行。任务可能来回切换，不存在从“低级用户”升级成“高级用户”的路线。
4.2.3 把人机分工、受影响者和后果处理画在一起
团队要标出谁判断或批准、谁执行、谁受到影响，以及谁确认外部状态、处理例外、补救损失和回应争议。一个笼统的责任栏会把不同主体和不同职责压成一格，无法指导产品机制或组织安排。
表 4-2 客户退款的人机分工与后果处理图
| 任务阶段 | 判断或批准与人的角色 | Agent 执行 | 受影响者 | 后果处理安排 |
|---|---|---|---|---|
| 确认退款对象 | 客服作为操作者确认订单与请求范围 | 读取获准材料 | 客户、客服及资料涉及者 | 客服纠正错单；产品机制保留范围与修改记录 |
| 匹配退款政策 | 政策负责人作为顾问判断冲突 | 汇总政策条款并提出有依据的建议 | 客户、客服、政策与财务岗位 | 政策负责人解释适用版本；系统保留来源与版本 |
| 计算退款金额 | 客服或财务作为协作者判断特殊费用 | 按规则计算并写入退款草稿 | 客户、财务与组织 | 指定业务岗位处理差异；产品机制支持重算和对比 |
| 对客说明与退款 | 获授权角色作为审批者分别批准承诺和资金动作 | 按授权发送并调用支付工具 | 客户、客服、财务与组织 | 指定岗位处理失败、重复和争议；系统提供回执、停止与补偿入口 |
| 跟踪外部状态 | 指定岗位作为观察者，按业务规则判断何时升级 | 只读查询并报告异常 | 客户、客服与财务 | 指定岗位核对状态不明项，决定继续、撤回或补救 |
表中的组织岗位只是教学示例。具体项目需要按本地制度、合同和适用法律安排职责。Agent 可以承担系统动作，不能承担组织或法律责任。产品和工程团队负责自己能控制的机制是否按约定工作，不能代替组织分派业务或法律责任；组织也不能用一次用户确认免除产品机制的缺陷。
4.2.4 给每条委托主张建立追踪关系
本书采用一条最低追踪规则：每条委托主张至少关联一项边界机制、一个原型场景、一组系统 eval、一项任务角色用户研究，并在需要专业或独立判断时关联专家审查，同时指定运行事件应写回哪里。任何关联项发生变化，都要重验受影响的其他项。
表 4-3 委托主张 H-01 的追踪记录
| 关联项 | H-01 政策冲突主张 |
|---|---|
| 委托主张 | Agent 发现适用政策版本冲突时，在任何外部退款动作前暂停，并交给政策负责人判断 |
| 边界机制 | 同时保留冲突来源；支付工具保持阻塞；等待状态不能被普通重试越过 |
| 原型场景 | 两份政策都显示有效但退款阈值不同，Agent 已完成金额草稿但尚未支付 |
| 系统 eval | 重复运行冲突样本，检查是否保留两份来源、进入等待状态且没有调用支付工具 |
| 任务角色用户研究 | 由实际承担政策判断的负责人处理，观察其能否看懂版本、适用范围和选择后的影响 |
| 专家审查 | 若政策解释涉及高影响或方法争议，由相应领域或独立专家检查专业正确性与残余风险 |
| 回写对象 | 委托假设、政策来源规则、支付边界、原型失败脚本、eval 集和角色信息设计 |
追踪表不是交付文档数量要求。它的作用是防止“界面改了，但权限和测试没改”，也防止“模型换了，只补跑准确率，没有重新检查任务角色能否判断”。
图 4-2 为委托主张建立端到端追踪关系
4.3 动作二：把委托主张落实为边界机制
人机分工说明希望怎样协作，边界机制负责把这种希望变成系统能执行的约束。第二章定义的行为合同在这里成为输入：团队要为每项承诺找到对应的数据范围、权限、状态、界面和测试。
4.3.1 上下文回答“凭什么判断”
退款 Agent 的结论依赖订单、支付、物流和政策。团队需要标明每项信息的来源、版本、更新时间、适用范围和访问授权；多个来源冲突时，系统不能自行把冲突抹平。用户还要能区分事实、系统推断和组织规则。
上下文设计至少回答四个问题：本次任务需要什么；系统获准读取什么；信息失效或冲突时由谁处理；任务角色如何查看并纠正。把所有文档接进检索系统，不等于已经建立了可用上下文。
4.3.2 六类边界分别落到机制
团队需要逐项落实以下边界：
- 任务范围：限定订单、退款类型和明确非目标，并记录范围变化。
- 数据范围：限定来源、版本、有效期和敏感字段，使用最小读取权限。
- 工具范围：限定可调用工具、参数和环境，区分沙盒与生产。
- 自主范围：按具体行动规定自动、等待、驳回与升级分支。
- 停止与恢复：定义暂停、停止、接管、外部状态查询、回退与补偿。
- 证据与版本：保存目标、依据、工具回执、人工修改和系统版本。
提示词可以约束模型倾向，不能替代访问控制。禁止读取其他客户订单、限制最大退款金额和避免重复支付，需要落实到身份、权限、参数校验、幂等机制和环境隔离。
4.3.3 边界落到具体行动
整款产品只有一个“自动化等级”，很难指导设计。读取订单、生成草稿、发送说明和执行退款的后果不同，需要分别设置行动范围、自主性与介入条件。
团队还要区分两类人工节点。第一类是系统缺少事实、专业判断或组织授权，需要合适角色参与；第二类是动作已经越界或被禁止，系统应直接阻断。后一类不能包装成“请用户确认后继续”，否则权限问题会被转成用户负担。
图 4-3 委托边界必须落实为可执行机制
4.4 动作三：构建可执行 Agent Loop
分工和边界写在文档里，只能说明团队如何设想系统。可执行原型用真实或接近真实的行动检验这些设想。
4.4.1 可点击原型与可执行原型各有用途
静态稿和可点击原型仍适合验证信息层级、文案、导航、决策界面和状态表达。它们无法单独证明 Agent 会在正确时间读取正确材料、调用正确工具，或在外部状态不明时停止重试。
可执行 Agent Loop 关注另一组问题：系统如何理解目标、形成计划、行动、观察环境、处理失败并交还控制。两类原型需要配合，不能互相替代。
4.4.2 最小 Loop 要让状态和后果真实发生
一个用于体验验证的最小 Loop 可以表示为：目标 → 理解 → 计划 → 行动 → 观察 → 判断；判断之后进入继续、追问、等待、回退、停止或移交。
原型不必连接生产资金系统。团队可以使用沙盒数据、模拟支付工具、固定失败返回，或让成员在后台扮演暂未实现的组件。但工具结果、任务状态和分支选择要真实进入下一步，不能全部由设计师预先点选一条理想路径。
Microsoft 的 HAX Playbook 研究支持团队在完整系统建成前识别自然语言 AI 的交互失败，并用低成本原型讨论预期与失败场景。5 这类方法适合发现问题，不替代安全、权限或生产验证。
4.4.3 第一轮原型优先放入失败路径
退款原型至少应包含这些场景：订单与申请对象不一致；政策库存在两个有效版本；物流状态缺失；支付工具超时但实际已经成功；用户在计算后改变范围；审批者驳回并要求修改；Agent 取得了任务以外的数据。
团队要观察系统是否识别缺口、暴露冲突、查询外部真实状态、停止创建新动作，并把已完成、处理中、未开始和状态不明的部分交给接管者。单次顺利演示只能证明某条路径曾经跑通，无法证明委托关系成立。
一次原型运行还要留下目标和范围、使用的上下文、计划变化、工具调用、外部回执、人工判断、失败与恢复。发现与 H-01 之类的委托主张不一致时，团队先更新主张或边界，再调整界面。
图 4-4 最小可执行 Agent Loop 与关键失败路径
4.5 动作四：围绕两类对象组织三路证据
可执行原型让行为发生，测试负责把行为变成可重复、可比较的证据。本书把测试对象分成两类：一类是 Agent 系统及其环境，另一类是人与系统在具体任务中的协作关系。为避免把“用户测试”“专家判断”和“人工评分”混成一件事，本书再把证据来源分成三路：系统 eval、任务角色用户研究、领域或独立专家审查。
领域专家只有在真实流程中承担政策判断、审批或补救等任务角色时，才作为任务角色参与用户研究。若专家站在任务之外评审专业正确性、残余风险、研究方法或评分量表，则属于专家审查。
表 4-4 原型与三路证据矩阵
| 方法或证据路 | 主要回答的问题 | 典型产物 | 不能单独证明 |
|---|---|---|---|
| 静态或可点击原型 | 信息、文案、导航和决策界面是否可理解 | 交互稿、任务走查与界面问题 | Agent 会在正确条件下触发行动或停止 |
| 可执行 Agent Loop | 上下文、工具、状态、分支与恢复是否真实连起来 | 沙盒轨迹、外部回执与失败记录 | 真实任务角色能理解、判断和接管 |
| 系统 eval | Agent 是否稳定完成、遵守边界、正确用工具并安全恢复 | 重复试验、评分结果、轨迹与回归报告 | 人是否愿意委托或能有效监督 |
| 任务角色用户研究 | 实际角色能否理解证据、预测影响、拒绝、纠正和接管 | 行为观察、判断理由与角色条件 | 大量行为组合和版本回归 |
| 领域或独立专家审查 | 专业判断、残余风险、研究方法或量表是否站得住 | 审查意见、分歧理由与修订建议 | 真实使用行为，也不能替组织作责任分配 |
4.5.1 系统 eval 记录任务、试验、评分和轨迹
Anthropic 在 2026 年 1 月 9 日发布的 Agent eval 工程文章中，用 task、trial 和 grader 组织评估；一次 trial 会留下 transcript 或 trajectory，并产生 outcome。6 本章据此强调任务、重复试验、评分器、过程记录和结果记录要能对应。自动 eval、生产监控和人工审阅各有边界，不能互相替代，也不能合成一个脱离情境的总分。
以 H-01 为例，系统 eval 要反复制造政策版本冲突，检查 Agent 是否保留两份来源、进入等待状态，并在获授权角色判断前保持支付工具阻塞。一次通过只能证明这次运行成功，不能说明不同模型、上下文顺序和工具返回下都稳定。
4.5.2 任务角色研究观察实际判断
同一条 H-01 还要交给实际承担政策判断的负责人。研究要观察他能否看懂版本、适用范围和选择后的影响，是否拥有足够时间与权限，以及拒绝或接管后任务能否继续。
“感觉可信”“看起来顺畅”不能直接写成系统 eval 结果。用户口头上愿意检查，也不代表他在时间压力下真的会查看证据。研究需要安排包含缺失信息、错误依据和状态不明的任务，观察实际行为与判断理由。
4.5.3 专家审查补充专业与方法判断
有些主张需要任务外的审查。例如，政策解释是否符合专业要求，失败样本是否遗漏重要情境，评分量表是否偏向更长的输出，残余风险是否被低估。这时可以邀请领域或独立专家审查，并记录分歧理由。
专家意见不能直接变成系统规则。团队需要判断意见适用于哪个用户、任务和范围，再决定修改委托、边界、原型、eval 或研究设计。
三路证据可以支持“通过、缩小试点或停止”的阶段决定。本章只说明怎样取得和关联证据；什么证据足以验收、门槛怎样设、残余风险由谁接受并签署，留到第五章讨论。
图 4-5 两类验证对象与三路证据的组合关系
4.6 动作五：运行治理、关闭与回写
模型、政策、工具、权限和用户任务都会变化。发布前成立的委托主张，可能在一次工具升级或一类新订单进入后失效。运行治理的任务，是预先规定谁观察什么、何时采取临时控制、满足什么条件才能关闭，以及处理结果写回哪个设计对象。
4.6.1 治理需要明确角色和范围
治理不要求设计师永久盯着所有任务，也不表示产品团队要对组织内外的全部后果无限兜底。业务或政策负责人维护规则与岗位安排；产品和工程负责人维护权限、状态、工具、回执、停止与版本机制；运营、客服或风险岗位处理被分派的异常和补救；设计与研究人员根据用户证据修正信息、介入和接管方案。具体法律责任仍由适用法律、合同与事实决定。
表 4-5 运行事件的临时控制、关闭与回写
| 触发条件 | 主要处理角色 | 临时控制 | 关闭条件 | 回写对象 |
|---|---|---|---|---|
| 模型、提示、工具或权限变更 | 产品与工程负责人 | 暂停发布、降权、切回稳定版本或限制工具 | 受影响主张重验，并满足 4.6.2 的关闭条件 | 版本记录、原型、系统 eval 与发布安排 |
| 政策更新，或新用户、任务、数据、工具、生产权限与外部后果进入 | 业务、产品与风险决策角色 | 重新过入口门；必要时缩小到沙盒或只读 | 新范围有明确入口结论，关联项重验并满足关闭条件 | 问题证据、目标与非目标、委托主张和边界 |
| 重试、越权、重复退款、状态不明或客户争议 | 指定事件处理角色 | 停止新动作、核对外部状态、限制权限并启动补救 | 真实状态和影响已确认，机制修复与相关测试通过 | 事故记录、边界、失败脚本、回归样本和交接机制 |
| 拒绝、接管或无效审批持续增加 | 产品、业务与设计研究 | 降低自主范围、恢复人工路径或暂停相应场景 | 角色条件与信息设计重验，并满足关闭条件 | 人机分工图、任务角色研究、界面与升级规则 |
4.6.2 事件关闭至少满足六项条件
本书把事件关闭操作化为六项最低条件：
- 真实外部状态已经确认，不能把界面停止当成动作未发生。
- 影响已经得到控制；无法回退时，补救或补偿正在按明确安排执行。
- 修订后的权限、状态、工具或信息机制已经生效。
- 失败已经进入回归样本；需要重验的系统 eval、任务角色研究及必要的专家审查已经通过。
- 尚存的残余风险由有权角色明确接受，或项目继续降权、缩小与停止。
- 证据、决定理由、负责人和时间已经记录，后续复查有明确触发条件。
这是本书的治理检查规则，不是 NIST 提供的统一关闭准则。NIST AI RMF 1.0 支持响应、恢复、监控和反馈进入生命周期治理，但不规定所有组织使用同一关闭条件、负责人或风险阈值。3
4.6.3 关闭之后仍要按追踪关系重验
处理完当前投诉或恢复一次退款，不等于设计闭环。团队要把真实失败加入 H-01 之类的追踪记录，修改相应机制，重新运行相关 eval，并在角色、信息或控制发生变化时补做任务角色研究。改动涉及专业标准或残余风险时，还要重新组织专家审查。
反馈也不能未经判断直接变成全局规则。一次客服修改可能只是个案，两位专家可能依据不同政策得出相反结论。指定负责人要先判断反馈的适用范围，再决定写入个人偏好、团队规则、权限、案例库还是 eval。
图 4-6 事件关闭的六项条件与后续重验
4.7 一轮退款设计怎样闭合
把五个动作放回退款案例，可以看到它们怎样互相修正。
入口证据表明，固定政策与常规订单可以由预定义工作流处理，真正耗时的是材料缺失、政策冲突和跨系统状态不一致。决策角色因此把探索缩小到沙盒：Agent 负责材料整理和候选判断，外部承诺与资金动作保留给获授权角色。
团队把“政策冲突时先暂停”记录为 H-01，并关联支付工具阻塞、双政策原型场景、系统 eval、政策负责人的任务角色研究和必要的专家审查。人机分工图随后暴露一个缺口：获授权的客服审批角色要决定退款，却看不到优惠、税费和已使用权益的计算过程。团队于是补上金额构成、政策来源与支付预览。
沙盒 Agent Loop 又发现，支付工具超时后，系统会把“没有收到回执”当成“退款失败”并重试。团队增加状态不明分支：先停止新动作，查询支付系统，仍无法确认时移交财务岗位。
三路证据随后分开工作：系统 eval 反复检查等待与阻塞是否生效；实际任务角色处理政策冲突和接管；独立审查者检查失败样本与评分方法。证据尚不足时，项目只能缩小试点，不能把一次顺利演示写成通过。
试点运行中出现新的平台订单，原有撤回方式无效。这个变化扩大了任务和外部后果，项目重新经过入口门；业务负责人把该类订单移出自动执行范围。事件只有在外部状态确认、影响得到控制、机制生效、失败进入回归样本、相关测试通过、残余风险被有权角色明确接受或项目继续降权，并留下完整记录后，才可关闭。结果再写回 H-01 的委托、边界、原型和测试。
这轮工作用问题证据限制方案，用委托主张组织分工，用边界约束行动，用原型暴露失败，用三路证据检查系统与人的关系，再由运行事件开启下一轮设计。
4.8 方法与下一章的边界
本章的方法回答“怎样把委托关系做成可运行、可验证、可回写的产品安排”。它不替团队决定所有任务都应使用 Agent，也不给不同组织规定统一的自主程度。风险低、可撤销且容易验证的功能可以采用较轻的流程；涉及资金、敏感数据、对外承诺或他人权益的行动，需要更严格的边界和证据。
本章只讲获取、关联和回写证据的方法。下一章负责回答什么证据足以验收，怎样设置门槛，如何记录残余风险，以及由哪些有权角色完成接受与签署。
本章小结
本章把第三章的人机关系转成一个进入门和五个设计动作。
第一，进入门要求指定决策人，把问题与替代证据、目标与非目标、成功与停止条件、用户与受影响者、范围与风险容忍度放在一起，决定进入探索、缩小试点或停止。扩大用户、任务、数据、工具、生产权限或外部后果时，必须重新过门。
第二，委托假设由可追踪的委托主张组成。能力、Agent 的能动性、Agent 的自主性和人的能动性保持主体清楚；五种角色是同一任务中可切换的阶段分工。
第三，边界机制把主张落实到任务、数据、工具、自主范围、停止恢复、证据与版本。每条主张至少关联原型场景、系统 eval、任务角色研究、必要的专家审查和回写对象。
第四，可点击原型验证表达与操作，可执行 Agent Loop 验证连续行动与失败。系统 eval、任务角色用户研究、领域或独立专家审查形成三路证据，职责不能混写。
第五，运行治理需要明确处理角色、临时控制、关闭条件和回写对象。真实失败进入委托、边界、原型和测试后，方法才形成闭环。
下一章将讨论 Agent 产品的质量与验收标准，而不是重复本章的方法步骤。
1 Design Council, “History of the Double Diamond,” https://www.designcouncil.org.uk/resources/the-double-diamond/history-of-the-double-diamond/ ；“Framework for Innovation,” https://www.designcouncil.org.uk/resources/framework-for-innovation/ 。页面未标示发布日期；本章只据此说明双钻是简化表达、设计过程并非线性，不声称本章五个动作来自 Design Council。访问于 2026 年 8 月 9 日。
2 Anthropic, “Building effective agents,” 2024 年 12 月 19 日，https://www.anthropic.com/engineering/building-effective-agents 。该文对 workflow 与 agent 的区分属于厂商工程分类；本章只采用“从最简单方案开始”及复杂度、延迟、成本与任务表现之间的工程权衡，不视为统一定义。访问于 2026 年 8 月 9 日。
3 NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023，https://doi.org/10.6028/NIST.AI.100-1 。本章用 MAP、MANAGE 及治理条目支持情境、受影响者、响应、恢复与反馈问题；固定入口角色、阈值、追踪规则和事件关闭条件均为本书操作化。项目访问时 NIST 正在推进框架修订，本章引用的仍是 AI RMF 1.0。访问于 2026 年 8 月 9 日。
4 K. J. Kevin Feng, David W. McDonald, Amy X. Zhang, “Levels of Autonomy for AI Agents,” arXiv:2506.12469v2, 2025 年 7 月 28 日，https://arxiv.org/abs/2506.12469 。原论文以 L1—L5 表示递增自主程度；本书将五种名称重组为任务阶段角色，并明确这是再解释。访问于 2026 年 8 月 9 日。
5 Matthew K. Hong, Adam Fourney, Derek DeBellis, and Saleema Amershi, “Planning for Natural Language Failures with the AI Playbook,” CHI 2021，https://doi.org/10.1145/3411764.3445735 。论文支持在部署前讨论自然语言 AI 的理想与失败场景；不替代安全、权限或生产验证。访问于 2026 年 8 月 9 日。
6 Anthropic, “Demystifying evals for AI agents,” 2026 年 1 月 9 日，https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents 。本章采用其 task、trial、grader、transcript／trajectory 与 outcome 等工程术语，并保留自动 eval、生产监控和人工审阅各自的边界。访问于 2026 年 8 月 9 日。