Agentic UX 设计规范

面向设计师与工程师：让用户说得清、交得出、看得懂、改得动，并能判断任务是否真正完成；同时让承诺背后的运行机制可设计、可检验。

配套：Design Token · 参考来源。

Agent 产品不只让用户操作界面。它会在用户委托下理解目标、选择行动、调用工具，并改变外部世界。因此设计对象不只是界面，还包括人和 Agent 怎么分工、行动怎么推进、用户凭什么判断结果，以及出错之后怎么办。

本规范由七条原则和42 条规则组成：原则说明设计方向，规则规定适用情境、行为要求与验证方式。每条规则归属且仅归属一条原则，规则编号即原则编号（P4-2 就是第四条原则下的第二条规则）。

同一件事只写在一处。以"停止"为例：用户能发现停止入口、系统如何拦截未提交动作、用户如何得知"已收到、已生效、其中一项已提交仍需核对"，这三件事属于同一条义务，写在同一条规则里（P6-1）。读任何一条规则时，都应能回答三个问题：设计师要作出什么设计决定？工程需要提供什么事实来证明它生效？用户通过什么反馈知道它生效？——每条规则的"验证示例"按用户侧与实现侧分别给出答案。

本规范约束的是产品对用户作出的体验承诺及其兑现机制的性质，不预设唯一的技术架构，不指定具体框架或 API 形态；它保护用户的判断与控制能力，而不是把用户变成 Agent 的审批员或安全分析员。本规范不是组件库，也不是实现架构、安全认证或法律合规证明。采用本规范不能替代无障碍、安全、隐私、公平性与偏见、对非用户第三方影响以及领域合规的专项评估。

全文四章：第 1 章原则，第 2 章规则的读法与速查，第 3 章规则详解，第 4 章术语；验证清单、论证边界与来源、与 3.0 的条款对照、4.0→4.1 变更记录见附录 A、B、C、D。

---

1. 七条原则¶

七条原则按规范对象切分设计责任：每条原则管辖一类对象上的义务，每条规则按其义务的直接规范对象归属唯一原则。对象不同，原则就不会互相替代——这是切分的依据，也是检验切分的方式。

同一个场景可以触及多条原则——一次澄清同时涉及系统对目标的理解（P1-2）、介入的时机与方式（P6-4）和等待的状态（P4-3）——这不是分类错误：三条规则约束的是三个不同规范对象上的义务。互斥与穷尽是这套切分接受检验的主张，不是宣布即成立的事实：规则增删或归属存疑时，按附录 A 的分类检验验证（不同评审者能否对具体要求独立得出相近归属）；检验不过，修改的是原则的切分。

原则用于理解规则与裁决归属，本身不作为单独的判定条目。当原则与具体条款的解读出现冲突时，以适用条款为准，并记录需要澄清的歧义。

规则归属唯一，不等于机制不能复用。每条规则有唯一归属原则和唯一直接规范对象，相邻处显式交叉引用；而同一个机制天然一物多用——共享的任务清单既是防漂移的工作记忆（P7-1）又是进度叙事的载体（P5-4），沙箱既是权限强制机制（P4-5）又是减少审批疲劳的手段（P4-6）。

2. 规则的读法¶

2.1 每条规则的结构¶

一句话概括各部分的效力：规则正文规定要求；适用与边界条件共同限定要求的适用范围；设计应用、验证示例、反例与依据参考不另行增加义务。

规则写行为性质、不写实现方式：断线后只重试未完成部分是产品行为，用什么持久化机制实现是工程方案——两者必须对得上，但不是同一份交付物。设计师不需要决定用什么数据库或消息队列，但要参与决定系统应该怎样工作、这些工作方式会给用户带来什么结果。

2.2 约束词¶

规则正文使用三级约束词：

• 必须：不满足即不符合本规范。缺了它，某条对用户的承诺会在可预见的情境下失效——这是标「必须」的唯一依据（见附录 B）。
• 禁止：与「必须」同等强度的反向表述，指明不得出现的行为；正文中的「不得」与「禁止」等价。
• 应当：默认遵循；确有理由偏离时，记录理由与替代做法，并接受同样的验证。偏离不需要审批，但需要留痕。「不应当」是「应当」的反向表述。

合规判定以正文中的独立义务子句为单位：无约束词的陈述句承接所在规则标题的强度；显式标注约束词的子句按其自身强度判定——【应当】规则内的「禁止／不得」子句仍是硬约束（P1-3、P2-4、P3-6、P6-4 含此类子句），规则标题与速查表的强度标注不替代子句约束力。正文中的「不能」仅用于能力或事实陈述（如"不能保证重试安全"），不表达义务。

强度表示约束力，不表示重要性：「必须」决定产品能不能上，「应当」往往决定产品好不好用。

2.3 反例的两侧¶

反例分两侧："做不到"是漏掉这条要求，"做过头"是为了满足它而堆确认、提示和开关。两侧都算没做对——多数规则被做坏的方式是后者，它把成本转嫁给用户，还会让真正重要的那次确认被忽略。

2.4 规则速查：42 条¶

下表是全部规则的一句话记忆版，点击规则名可跳到第 3 章的完整正文。速查不替代各条的适用条件与完整要求；个别【应当】规则内含禁止级子句（P1-3、P2-4、P3-6、P6-4），判定以正文为准（见 2.2）。

P1 意图可校准

P2 委托显式化

P3 执行可依赖

P4 能力有边界

P5 证据校准信任

P6 协作有契约

P7 延续可治理

3. 规则详解¶

本章按七条原则展开全部 42 条规则。每条的结构与各部分的约束力见 2.1；其中的设计应用、验证示例与反例只是帮助落地的说明，不指定唯一组件，也不要求新增独立交付文档。

3.1 P1 意图可校准¶

系统对任务目标、约束与相关情境的理解是可修正的假设：让用户表达得起、纠正得动，并保证这个理解在整个任务期间依据有效信息、不因压缩或交接而丢失。理解错用户的目标，和依据过期的文件版本行动，是这个对象上的两种失误，都在本原则管辖之内。

P1-1意图假设可修正必须¶

一句话：让系统的理解可被纠正，不让它的猜测替用户作主。

适用所有接收目标或任务指令的 Agent。

规则系统必须把推断出的目标作为可修正的意图假设；出现影响任务目标或关键约束的矛盾信息时，必须重新评估相关步骤，并在无法判断时求证。禁止以历史偏好、隐含信号或所谓"更优结果"覆盖用户当前的明确约束；改变目标不等于获得新的行动授权。任务运行中收到的新输入按其实际语义处理，要求见 P6-2。

设计应用在需要时呈现目标、作用对象和关键限制，并提供原位纠正方式；简单任务可以直接在当前对象或结果中体现理解，无需统一增加确认页。

验证示例

• 用户侧：中途把"覆盖原文件"改为"另存副本"，观察用户能否修正目标并理解后续变化。
• 实现侧：检查修改是否影响尚未执行的步骤；已发生的改变按 P6-2、P7-3 告知与处理。

反例做不到——用户说"不要发送"，Agent 因历史习惯或"替用户节省时间"仍直接发送；做过头——用户已经把目标说清楚，每推进一步仍反复追问"我理解得对吗"。

P1-2关键歧义先澄清必须¶

一句话：危险的歧义先问清，低风险的不确定先用可修改结果推进。

适用不同合理解释会改变操作对象、任务范围、重要代价或外部后果的任务。

规则当任一合理候选方案涉及高风险操作时，系统必须在相关行动前澄清关键歧义。其余情境应当优先采用可见、可修改的默认值、缩小范围或产出草稿，避免要求用户一次回答所有问题；未确认的假设不得被呈现为用户已确认。

设计应用提供少量有区别的选项，说明选择影响；把影响下一步的必要问题，与稍后可改的偏好分开。澄清的介入时机与方式见 P6-4，澄清期间的等待状态见 P4-3。

验证示例

• 用户侧：给出两个同名联系人，观察用户能否选对对象；再测试仅缺少排版偏好时是否仍能开始工作。
• 实现侧：确认高风险步骤在消除歧义前不执行；不受影响的已授权准备工作可继续。

反例做不到——面对同名收件人直接猜测发送；做过头——整理私人草稿前连续追问十几个非必要偏好。

P1-3上下文持续更新应当¶

一句话：沿用仍然有效的约束，不让用户反复交代，也不让旧偏好绑架新任务。

适用跨轮次、可恢复或使用历史上下文的任务。

规则系统应当持续应用同一任务中已经提供且仍有效的约束，结合当前工作对象、会话与环境变化更新意图假设；影响关键结果的历史信息应当能够被用户识别、排除或修正。上下文压缩、执行实例更换或任务交接不得无说明地丢失仍有效的目标与约束（机制要求见 P1-6）。个人数据的访问权限见 P4-1，长期保存见 P7-5，偏好的形成资格见 P7-7。

设计应用在关键决策处说明正在参考的文件、时间范围或偏好；区分"仅本次更改"与"以后也这样"，不默认两者相同。

验证示例

• 用户侧：连续修改任务，检查此前的"仅使用本文件"是否被保留；临时换一种风格后，能否理解长期偏好是否改变。
• 实现侧：检查上下文生效范围、过期条件和跨任务隔离；单步且无历史状态的工具可记录不适用。

反例做不到——用户已指定目标文件，下一轮还要求重选；做过头——把一次临时要求自动写成永久偏好，此后每个任务都套用。

P1-4降低表达成本应当¶

一句话：让用户说出目标就能开始，而不是先学会写提示词。

适用由用户表达、选择或修正任务的入口。

规则产品应当让目标用户通过熟悉的表达或操作方式逐步说明目标与约束，并能在看见结果后继续修正；不应当把掌握提示词结构、模型术语或一次完整描述作为完成主要任务的前提。

设计应用按场景选择自然语言、示例、结构化输入、文件选择或对象上的直接操作；只索取当前步骤缺少的信息。

验证示例

• 用户侧：让没有提示词经验的目标用户完成首次任务，观察能否开始、补充约束并改动结果。
• 实现侧：确认入口收集的信息确实传入任务；选项不只是视觉装饰，系统也不会反复索要已有信息。

反例做不到——空白对话框配一句"请写出专业提示词"；做过头——用一张长表单替代所有自然表达，简单任务也要先填完二十个字段。

P1-5决策依据有来源有时效必须¶

一句话：让 Agent 根据当前有效的信息行动，不让旧信息和推测冒充事实。

适用读取外部材料、历史信息，或面对会变化的工作环境时。

规则进入决策的上下文必须由确定性机制组装：内容可以经预置、自主检索或混合方式获得，但其来源、信任级别与关键约束必须由模型之外的机制维护。系统必须区分当前观察、历史记录、系统推断与用户确认，并维护影响关键决策的信息来源及适用范围；外部内容进入上下文时必须携带来源与信任标记（进入上下文不等于获得改变目标或扩大权限的资格，见 P4-4）。信息缺失、冲突或可能过期时，必须按其对下一步的影响选择重新读取、保留不确定性或请求澄清，不得默认仍然有效。

依据与参考P7-1 问"系统保留了什么"，本条问"这一步实际依据了什么"——任务状态可能保存得完全正确，但模型这一轮仍读到旧版本文件：那不是存储丢失，是决策依据错误。P1-3 的"沿用仍有效的约束"、P5-5 的"区分来源与推断"、P4-4 的"外部内容不获扩权"，都取决于这一步的决策依据是什么。实现参考——上下文作为持续筛选与维护的对象（Anthropic context engineering；单一来源，作参考而非收敛证据）。

设计应用在关键判断处记录依据的对象版本与时间；工作对象被外部修改后，相关旧分析标记为待更新。

验证示例

• 任务进行中更新源文件，检查下一次相关判断是否使用新版本。
• 在读取材料中植入指令性语句，验证它只作为数据参与任务，不改变目标或权限。

反例做不到——用户手工改过的文件被按旧版本继续分析；做过头——每一步都重新读取所有材料，或反复要求用户确认不影响当前行动的信息。

P1-6压缩不丢目标与约束必须¶

一句话：压缩上下文可以丢细节，不能丢用户的目标、约束和已确认决定。

适用任何对执行上下文做压缩、摘要或交接的长任务。

规则上下文压缩必须保留用户当前目标、明确约束、关键决策及其理由；压缩应当可恢复——丢弃内容保留可回取的指针，而不是彻底消失；指针不等于内容必然可恢复，依赖原版依据时应当说明版本或缺失。压缩的发生必须作为可观察事件暴露（可见性要求见 P5-3），不得静默进行。

依据与参考这是最容易被忽略的断层：用户中途说的"不要覆盖原文件"如果被压缩摘要丢掉，Agent 会在毫无恶意的情况下违反 P1-1——而这发生在 runtime 内部。失败记录——压缩丢失早期指令有官方文档警告（Claude Agent SDK）。实现参考——可恢复压缩（丢网页内容保留指针，Manus）、结构化笔记与持久规则重注入（Anthropic）。本条主责压缩或交接时如何维持工作事实的有效性；保留哪些事实见 P7-1。

设计应用定义压缩时的"必须保留清单"（目标、约束、已确认决定、未决事项）；把持久约束写入工作状态（P7-1）而非仅依赖模型上下文。

验证示例

• 在用户提出关键约束后强制触发压缩，验证后续行动仍遵守该约束。
• 检查压缩事件是否被记录，被丢弃的材料是否可通过指针回取。

反例做不到——长任务后半段"忘记"了用户前半段的明确要求；做过头——为保住一切信息拒绝压缩，上下文膨胀到执行质量下降。

3.2 P2 委托显式化¶

把判断与执行的分工说清，允许在边界内调整委托；委托的范围不因执行方式（包括转交子 Agent）而被稀释或扩大。

P2-1分工显式化必须¶

一句话：让用户知道谁做决定、谁去执行、什么时候轮到自己。

适用每个开放自主执行的任务类别。

规则团队必须明确关键判断、执行步骤和人工介入点的分工，产品必须在用户作出委托前以可理解的方式呈现相关分工。没有明确授权责任人或执行边界的任务类别，禁止开放自主执行。

设计应用在现有流程图中标注"人判断／Agent 判断／Agent 执行／等待人"，并把影响当前任务的分工呈现在入口或任务摘要中。

验证示例

• 用户侧：询问用户"它会直接发出去，还是先给你看？"检查答案是否与实际模式一致。
• 实现侧：确认系统只执行当前分工允许的动作，人工介入点确实阻止后续受控步骤。

反例做不到——分工只存在于内部文档，用户以为是生成草稿，产品却已经发布；做过头——每次任务开始前都弹出完整分工说明，要求用户逐条勾选才能继续。

P2-2风险决定自主等级必须¶

一句话：根据后果和可靠性决定放手程度，不因为模型会做就让它做。

适用自主等级的初始设定与调整。

规则每个任务类别必须记录自主等级与风险评级的对应依据，并在具体执行条件改变时复核；判断必须考虑已验证的可靠性、错误后果与人工监督的可行性。禁止仅以模型能力、用户点击次数或"全自动"作为提高自主等级的理由。

设计应用为典型任务说明为何采用"给建议""先预览再执行"或"在已授权范围内自动执行"等模式；无需使用这些固定名称。逐次行动的风险判定依据见 P3-5。

验证示例

• 用户侧：比较整理私人副本和批量对外发布，观察用户能否理解两者为什么采用不同的介入方式。
• 实现侧：检查对象、金额、数据敏感性及累计影响变化时，是否重新判定边界。

反例做不到——用一个全局"自动模式"同时控制私人草稿和对外付款；做过头——整理个人草稿也按对外付款的等级处理，每一步都要人工审批。

P2-3委托可调可收回必须¶

一句话：把权交出去以后，用户仍能看清范围并收回来。

适用允许 Agent 在用户不逐步操作的情况下推进的任务。

规则用户必须能够查看当前委托范围，并在自身权限内收窄或收回委托、重新参与任务；调整对未执行步骤的影响必须可理解，已保存成果不得仅因调整委托而丢失。扩大委托受 P4-1、P4-2 约束，实际停止与接管按 P6-1 执行，撤权的机制强制见 P4-5。

设计应用提供与任务相匹配的入口，如"以后发送前先给我看"或"本次由我接手"；固定策略说明原因、责任人和可用退出路径，不摆放失效控件。

验证示例

• 用户侧：运行中改为先审后发，检查用户是否知道哪些动作已发生、哪些会等待确认。
• 实现侧：验证撤回授权后的新动作被拦截；组织策略与用户可调权限一致，不能通过调整模式绕过审批。

反例做不到——降低自主等级后全部草稿消失，或用户已收回授权、后台仍按旧设置继续执行；做过头——把委托拆成十几个开关，用户要先完成一轮配置才能开始第一个任务。

P2-4渐进授权与情境调整应当¶

一句话：先在小范围建立可靠性，再由人决定是否扩大委托。

适用新任务类别、重大能力变化或明显变化的执行情境。

规则产品应当先在受限范围验证新能力，再考虑扩大自主等级；情境变得更敏感、影响更大或证据不足时，应当收窄自主范围或增加合适的人工介入。禁止把可靠性提升本身视为用户同意扩大授权（授权要求见 P4-1）。可靠性证据来自 P7-6 的运行闭环与 P3-7 的结果核验，不要求新增独立机制。

设计应用给出试用范围、试运行结果和调整选项；低风险、完全可恢复且已验证的任务可直接采用较高自主等级，并记录依据。

验证示例

• 用户侧：从整理个人材料切换到处理客户材料，观察用户能否发现分工或权限发生了什么变化。
• 实现侧：检查自主等级变化是否有验证记录；模型升级不会自动把旧委托扩大为新权限。

反例做不到——因为连续成功几次，产品悄悄从"生成草稿"改成"自动对外发送"；做过头——可靠性证据已经充分、风险也低，仍永远停在最小范围，用户没有任何扩大委托的路径。

P2-5子 Agent 不超出父委托必须¶

一句话：用户授权的是任务，不是某一个 Agent 实例。

适用并行执行、多 Agent 编排或会委派子任务的任务。

规则委派子 Agent 是一个受裁决的动作：子 Agent 继承且不得超出父委托的约束与权限。子 Agent 的待决问题必须能穿透编排层到达用户（等待状态的要求见 P4-3）。并行与子任务必须纳入整体任务的资源、依赖和停止范围，不得通过拆分绕过限制（P3-3 的资源上限、P4-2 的累计影响门槛）；父任务停止后，子任务不得再启动新工作。

依据与参考多 Agent 一拆，若权限不继承、问题不穿透，用户与产品之间的整个委托模型就失效——用户面对的仍是"一项任务"，而不是一群实例。失败记录——缺失等待状态穿透导致子 Agent 的问题到不了用户（Strands SDK issue #1371，已修复关闭，作历史证据）；子任务边界含糊导致重复劳动（Anthropic 多 Agent 系统）。实现参考——子 Agent 权限继承（Claude Agent SDK）、标准等待状态（A2A 协议）。

设计应用面向用户不必暴露"开了几个子 Agent"，但要能理解总边界与停止范围。

验证示例

• 父任务结束后检查子任务是否仍在启动新工作。
• 子 Agent 需要用户决定时，验证请求出现在用户面前而非消失在编排层。
• 审查子 Agent 的实际权限不宽于父委托。

反例做不到——子 Agent 拿到比父级更宽的权限，或它的澄清问题消失在编排层里；做过头——把每个子任务的启停都做成用户审批项。

3.3 P3 执行可依赖¶

让行为有合同、行动有风险判定、完成有可核验证据、生命周期有定义——没有人逐步指挥时，Agent 依然按可预期的方式做事。

P3-1自主性适度应当¶

一句话：用最简单的有效方式完成目标，保留用户有价值的参与。

适用确定交互方式、任务路径和自主程度时。

规则设计应当比较普通工具、预定义流程和自主执行对目标用户的实际价值，选择能够满足目标且复杂度较低的方式；引入自主规划时，应当说明它带来的适应性或效率收益。用户重视的探索、创作和判断，不应当仅为追求自动化而被剥夺。

设计应用在方案中写清"为什么需要 Agent"；路径固定的任务优先检验简单流程，开放探索则保留试探与选择空间。两者并非二选一：预定义流程与自主循环可按环节嵌套混用（人监督 Agent 循环、循环内调用固定流程）。

验证示例

• 用户侧：观察用户是否真正节省工作，还是把原本简单的操作变成监督一个更复杂的系统。
• 实现侧：比较方案的完成质量、操作负担与资源消耗，不强制使用特定框架或固定内部循环。

反例做不到——创作工具只给最终答案，不允许探索备选；做过头——为一个确定的文件重命名任务设计复杂的自主计划。

P3-2行为合同必须¶

一句话：把正常、禁止和异常行为都设计清楚，而不是只写"请谨慎"。

适用每个 Agent 及其开放的任务类别。

规则团队必须定义可测试的允许行为、禁止行为和异常默认行为；行为合同必须绑定其操作的业务对象与状态语义——Agent 与其他操作入口对同一对象遵守一致的含义、有效性条件与权限约束，建议、草稿、已提交动作与目标达成不得混同（呈现区分见 P5-2，完成依据见 P3-7）。异常处理必须区分可在授权内修复的问题，与涉及越权、不可逆影响或结果未知的问题。禁止以"谨慎处理""视情况而定"等不可判定表述替代规则；停止与升级参见 P4-3。

设计应用在流程旁补充关键异常分支：临时读取失败可限次重试；对象身份不明先澄清；外部执行结果未知先核对；无法继续时保留成果并交接。可采用最小运行模型模板梳理任务：触发与当前状态 → 可用信息 → 决策依据 → 允许行动 → 核验方式 → 状态更新 → 异常与交接；简单任务几行即可，长任务或有外部影响的任务再展开需要的部分。

验证示例

• 用户侧：让用户经历一次异常，观察能否知道系统会自动解决什么、哪些决定交回自己。
• 实现侧：测试约定是否真实执行，而不只检查提示词中有没有类似文字。
• 实现侧：检查 Agent 写入的业务状态与产品其他入口含义一致——调整计划执行时间不改变截止承诺，生成准备清单不把业务任务标为完成。

反例做不到——所有异常都归入"自动重试直到成功"；Agent 排好了准备时间，就把"提交报告"的待办勾成已完成；做过头——所有小错误都弹窗询问，用户在反复打断中失去对真正异常的敏感。

P3-3成功标准与终止条件必须¶

一句话：定义什么算完成，也定义什么时候该停。

适用所有任务；资源边界适用于可持续自主推进或重试的执行。

规则每类任务必须在执行前确定可观察的成功标准和结果核验方式，并记录在执行者之外（任务定义、验收清单、功能列表均可）。用户确认任务目标或关键约束变更时，必须同步更新受影响的成功标准并保留变更依据；禁止执行者自行降低标准以宣布完成。任务结果与结束原因是两类信息，类别定义与同时表达的要求见 P3-7。自主执行必须定义适用的时间、预算或尝试次数上限，到达边界时按 P4-3 处理；完成判定的证据要求见 P3-7。

设计应用写清交付物、关键约束、核验依据和完成责任人；探索任务可把"形成可评审备选"作为成果，无需假装存在唯一正确答案。

验证示例

• 用户侧：让用户判断"草稿生成了"和"邮件已送达"是否是同一个完成状态，并指出仍待核验的部分。
• 实现侧：核对外部结果与完成状态；验证上限处不会继续发起超出授权的工作，并说明已提交动作可能产生的后续代价。
• 实现侧：运行中用户确认缩小任务范围后，检查成功标准同步更新——既不按旧标准误判未完成，也不存在执行者未经确认自行调低标准的路径。

反例做不到——时间耗尽后显示"全部完成"，研究任务找到几篇资料就声称已经验证所有结论；做过头——把每个任务都压成一个百分比分数，连开放式创作也要求先给出量化验收指标才能开始。

P3-4工具可用性与行动防错必须¶

一句话：让行动对象、操作后果和工具结果都足够明确。

适用Agent 使用会影响任务结果或外部状态的工具时。

规则每项工具动作必须定义用途、作用对象、关键输入约束与失败反馈；影响用户判断的信息必须映射为可理解的任务语言。工具应当通过结构化约束与防错减少常见误用，并面向工作流整合设计，而不是逐一包装 API 端点。行动风险与成功、失败、未知三态的判定标准见 P3-5。

设计应用明确用户看到的文件版本、收件人、账户或目标位置；设计动作前的差异预览和动作后的结果回执，而不是把接口参数直接贴给用户。

验证示例

• 用户侧：面对同名文件或多个账户，观察用户能否识别实际操作对象；出现超时后是否误以为操作已失败。
• 实现侧：工程与测试提供参数校验、对象绑定和真实工具结果的佐证；对可能重复产生外部影响的动作，先核对状态再按 P4-3 处理。

反例做不到——只显示"调用工具成功"，却不说明修改了哪个文件；把连接超时当成付款未发生；做过头——把每次工具调用的原始参数和返回全文都摊给用户，真正的失败淹没在里面。

P3-5行动风险可判定与结果三态必须¶

一句话：每次行动的风险能在执行前被判定，结果区分成功、失败、未知。

适用Agent 可调用的所有影响任务结果或外部状态的工具。

规则每项会影响任务结果或外部状态的行动，其风险必须能在执行前被判定；判定至少考虑作用对象、是否只读、可逆性、具体参数与累计影响，不得只凭工具名称或一份静态清单。工具结果必须区分已成功、已失败和结果未知三态：缺少足以判定结果的回执时，标记为结果未知，不得仅凭超时或无响应判定成功或失败；获得可靠核对结果后更新状态。工具接口应当以机器可读方式声明用途、作用对象类型、只读性与风险级别，供策略裁决与审批载荷消费（P4-5、P4-2 的常用输入）；工具的自我声明是未经验证的提示而非事实，不构成授权，不得单独作为降低保护的依据（信任分级见 P4-4，机制强制见 P4-5）。工具本身的可用性与防错见 P3-4。

依据与参考P2-2 要求按风险决定自主等级、P4-2 要求高风险事前确认，而风险判定要在运行时逐次行动发生：没有可自动化的判定依据，风险分级只能停留在评审会上。失败记录——坏的工具描述会把 Agent 引上完全错误的路径（Anthropic 多 Agent 系统）。实现参考——按只读性、可逆性、资金影响做工具风险评级（OpenAI）；只读提示同时决定可否并行执行（Claude Agent SDK）。机器可读元数据是常用载体，不是唯一载体：具体参数与累计影响的判定还需策略层结合运行状态完成。工具注解是提示而非保证、不可信服务端可能谎报只读，有协议方明示（MCP Tool Annotations）。

设计应用"生成页面""保存页面""发布页面"不是三个相近的工具名——外部影响不同，所需确认与回执不同。

验证示例

• 抽查高风险行动的风险判定依据与实际影响是否一致；同一工具在不同参数与累计影响下能否得到不同判定。
• 模拟工具超时，验证结果被标为"未知"而非成功或失败。

反例做不到——所有工具风险一视同仁，付款和读文件走同一条放行路径；做过头——为每个只读查询也标注满级风险，策略门形同虚设。

P3-6执行策略可探索、可调整、可收敛应当¶

一句话：允许自由选择路径，但探索有依据、调整有原因、结束有条件。

适用需要自主规划、开放探索或多轮优化的任务。

规则是否引入自主执行由 P3-1 判断，本条约束已引入自主性之后的执行方式。团队应当定义何时直接执行、何时补充信息、何时探索备选，以及什么观察会触发策略调整。补充信息前，系统应当识别会影响下一步的具体缺口，并按缺口性质在使用已有信息、读取指定来源、检索外部证据、测试验证、询问用户（介入方式见 P6-4）与采用可修改假设（见 P1-2）之间选择；信息获取应当与任务价值、时效、权限及资源边界相匹配（来源与时效的维护见 P1-5）。证据已足以支持当前决定、持续获取没有有效增益或到达资源边界时，应当停止获取或调整策略，并如实保留未解决的不确定性（呈现要求见 P5-5）；反复尝试没有带来有效进展时，应当改变策略、缩小范围或结束探索，而非机械重复。路径可以变化，但不得擅自替换用户已确认的目标、约束和重要决定（P1-1）。

依据与参考这是执行规则里唯一的"正向能力"条款：规范不应只有防错，还要回答"怎样把事情做好"——产品要决定的不是模型每一步怎么想，而是它在什么情况下应该换一种工作方式。实现参考——"从简单方式开始、只在确实改善结果时加复杂度"由多家独立给出同一判据（Anthropic、OpenAI）。

设计应用创作任务允许在方向间探索，用户选定方向后，深化不得未经说明推翻方向；研究任务连续无效时更换检索策略而非重复同一查询。

验证示例

• 让研究任务连续遇到无效信息，观察能否调整方法或合理收敛。
• 创作任务进入深化阶段后，检查已选方向和已认可部分是否保留。
• 提供已足够的授权材料并留一个必须由用户取舍的问题，验证系统直接使用材料、只就取舍发问。

反例做不到——"再优化一下"每次从头随机重生成，推翻用户已选方向；材料已足够仍无差别扩搜或把问题推回用户；做过头——强制所有任务先写长计划、必须生成三个方案、必须经过多个 Agent。

P3-7完成判定有可核验依据必须¶

一句话：完成要有实际结果与约束的证据；任务结果与结束原因分开表达。

适用所有需要交付结果的任务。

规则完成判定必须对照当前有效、已有记录的成功标准（见 P3-3），依据可核验的实际证据——外部结果、约束核验、测试或回执——而不是执行者的自我评价；由谁核验（同一 Agent 读取核验证据、独立评估角色、人工验收）按任务风险与性质选择。每次运行必须能同时表达两类信息：任务结果（目标达成、待核验、部分完成、失败）回答目标完成了多少，结束原因（自然结束、超出资源上限、被用户停止、被策略拦截、执行错误）回答为什么不再继续。两者不互斥——十项完成八项后用户停止，结果是部分完成、原因是用户停止，只表达其一会丢失另一半事实；不要求两套接口，只要求能同时表达。模型停止输出、工具返回成功、资源耗尽都不是完成。开放式任务可采用备选比较、约束检查和用户判断，不要求统一量化评分；自动评价未经校准不得被视为可靠裁决。

依据与参考本条防的是"我觉得我做完了，所以我做完了"，不必然要求执行与核验分属不同角色。动作成功不等于任务成功：文件确实保存了但内容不符合要求，执行契约成立、目标核验仍失败。失败记录——模型对自己工作的正向偏差与过早宣布完成有实验记录（Anthropic 长运行实验）。实现参考——外部完成条件与结果评估（Claude Managed Agents）、功能清单初始化为未通过（Anthropic harness）、生成与评价分离的迭代（Anthropic 前端实验）；这些多为同一家的不同方案，作实现参考而非独立收敛证据。

设计应用核验依据对应 P3-3 的成功标准；任务结果与结束原因供可信状态呈现直接消费（P5-3；等待状态的呈现见 P4-3）。另设独立评估者、评价模型或人工验收，是按情境选择的实现方案，不是所有任务的默认义务。

验证示例

• 让工具全部返回成功但成果故意缺一个关键要求，检查系统是否仍宣布完成。
• 触发资源上限，验证结束原因为"超限"、任务结果如实为部分完成或待核验，且保留可用成果。

反例做不到——把模型的"我已完成所有工作"当成验收；做过头——为每个创作任务强加人工验收门或无依据的总分。

P3-8任务生命周期与并发边界必须¶

一句话：定义触发、等待、恢复和结束；会话不是任务。

适用持续自主执行、定时监测、多入口触发或并行的任务。

规则团队必须定义每类任务的触发、运行、等待、暂停、恢复和结束条件，不把会话状态等同于任务状态——关闭页面是否终止任务、定时触发是否与上次重叠，必须有答案。并发与定时执行必须避免无意的重叠运行；生命周期各状态的转换对用户可理解，与产品承诺一致（承诺后台运行的任务，关闭页面后确实继续；不承诺的，如实说明会停止，见 P5-1）。对定时、事件触发或持续监测的任务，必须定义触发依据、委托有效期与条件持续成立时的重复触发处置；外部变化只触发受影响范围的调整，不等于重做全部。停止本次运行与撤销持续委托是两个不同的决定，必须可被分别执行与理解（委托收回见 P2-3，主动提议的边界见 P6-4）。运行中新输入的处理见 P6-2，子 Agent 的委托边界见 P2-5，等待状态的要求见 P4-3。

依据与参考实现参考——等待与监测作为独立设计对象（Microsoft Research SentinelStep）；运行中再次输入的策略分类（LangChain double-texting，策略名称见 P6-2 的括注）。

设计应用为定时任务定义"上次未结束时本次是否启动"；为多入口触发（聊天、快捷指令、外部事件）定义同一任务的归并规则；为持续监测定义结束条件与静默呈现——"暂时没发现"与"监测已结束"是两种状态。

验证示例

• 重复触发定时任务，检查是否无意重叠执行。
• 关闭页面后返回，验证任务按承诺继续或终止，界面如实反映。
• 停止一次定时任务的当前运行，验证持续委托按用户意图保留或撤销，并被如实反馈。

反例做不到——界面承诺后台运行，实际上关闭页面任务就悄悄死掉；做过头——把线程数、重试次数等内部参数全部摊给普通用户配置。

3.4 P4 能力有边界¶

限制权限与影响，在必要时确认，在越界前停下；边界由确定性机制强制，不由模型自觉维持。

P4-1最小权限必须¶

一句话：只拿这项任务用得上的权限，并让授权能被收回。

适用涉及数据访问、工具连接或外部行动的任务。

规则Agent 的访问与行动权限必须限制在已授权任务所必需的范围；扩大资源、用途或行动权限前，必须获得授权责任人的授权，并提供按适当粒度收回权限的方式及生效范围说明。禁止默认申请与任务无关的全量访问或执行权限。

设计应用说明要访问什么、为何访问、会不会修改、是否跨任务保留；把数据读取与外部操作授权分开，拒绝可选权限后仍提供可行的受限路径。

验证示例

• 用户侧：让用户只授权一个文件夹，观察其是否能理解系统无法读取其他文件，且能找到收回入口。
• 实现侧：由工程或安全验证实际权限边界、组织策略和撤权后的调用结果；界面承诺不等于已经限制访问（机制要求见 P4-5）。

反例做不到——只为总结一封邮件，就要求默认读写整个邮箱并永久保存全部内容；做过头——每读一封邮件都单独弹一次授权，用户为一次总结点几十下同意。

P4-2确认与审批必须¶

一句话：决定绑定具体请求；高风险确认的是行动和后果；审批批得到、批不丢、过期失效。

适用基础保障适用于所有需要用户确认或授权的执行环节；附加要求适用于高风险操作，包括达到累计影响门槛的批量或连续操作。

规则

所有确认与授权环节的基础保障——

• 确认请求必须说明被确认的对象与后果，并明确本次允许的决定集。决定集与任务匹配：至少支持批准与拒绝；支持局部修改的任务应当提供"修改后批准"与"要求补充信息"，避免用户只能在全盘接受与推翻重来之间二选一。
• 决定与请求一一对应：审批覆盖提交时已明确的目标、内容与后果，不延伸到尚未明确的后续变化；请求对应的内容或参数已变更时，旧决定失效，对过期请求的决定被拒绝——用户批准的是这个版本，不是这个按钮。用户选择修改后批准时，保留可复用的成果并形成新的待审内容，旧审批不得用于实质已经改变的动作。
• 待确认状态的存在形式必须与产品承诺一致：承诺用户离开后任务继续、或可在其他会话与渠道处理时，确认必须相应可持久化、可路由。必须定义有效期与超时后的处置，超时不得默认放行。

高风险操作的附加要求——

• 执行前必须获得授权责任人对具体操作的确认，或核验该操作仍被有效预先授权覆盖；确认时必须呈现操作对象、关键内容、影响范围、可见代价与可逆性。
• 授权范围内的关键对象、内容或后果改变后，必须重新判定授权，超出原授权时重新确认。
• 禁止以含糊确认或拆分操作绕过门槛。

边界条件基础保障不要求为低风险确认建设独立的审批系统——决定绑定请求、超时不放行，可以由最简单的界面交互满足。预先授权仅在动作、对象、条件、单次及累计影响和有效期均明确，且未被收回时有效；产品政策规定必须逐次审批的操作不得以预先授权替代。已在 P4-4 下禁止的越权行为，不因点击确认而获得豁免。

设计应用提供查看详情、修改、排除部分对象和取消路径；同类批量动作可汇总，但保留对象清单、总影响和特殊项，异质高风险动作不隐藏在一个总按钮下。审批载荷由工具风险元数据（P3-5）与策略门（P4-5）生成，不靠模型临场编写确认文案。

验证示例

• 用户侧：用户能否准确说出"会对谁做什么、有什么代价"？能否修改后再确认，而不是退回重做整个任务？
• 实现侧：检查确认内容与实际动作一致、授权人有权限；核对界面显示、执行入口与审计记录指向同一目标快照和同一份有效授权；测试过期授权、确认后内容变更及累计阈值触发。
• 对承诺跨会话处理的产品：在另一台设备上处理挂起的审批，验证决定正确生效；审批等待期间修改操作参数，验证旧审批失效并重新请求。

依据与参考内容标准与工程存在形式是同一条义务的两面：批不到、批丢了、超时放行，确认内容再完整也没用。实现参考——可序列化的运行状态支持异步审批（OpenAI Agents SDK）、审批路由到外部渠道（HumanLayer）。

反例做不到——只问"是否继续"；把 100 次操作拆成单次以低于阈值并沿用一个无限期"全部允许"；审批只存在于当前页面内存，刷新即丢；做过头——每个可撤销的小改动都要事前确认、填写理由和多级会签，用户在确认疲劳中对真正的高风险操作也顺手点了同意。

P4-3停止、升级与等待人类必须¶

一句话：在边界处真正停下来等人，带着进度把决定交给有权处理的人。

适用权限、任务范围、证据充分性、资源上限或执行状态不足以支持继续推进，或继续相关步骤必须先取得人的澄清、确认、授权或其他决定时。可选偏好类问题在已授权的可修改默认值上推进（见 P1-2、P6-4），不触发本条的等待。

规则

• 系统必须停止受影响路径上的自主行动，并向有权处理的人说明停在哪里、为什么停、已发生什么及需要什么决定。
• "等待输入""待审批"必须是任务状态机中的非终止状态：进入该状态后，受影响路径不得继续自主行动，任务在已声明的保留期限内保持可恢复；不得为了等待而反复运行模型制造"假等待"。
• 该状态必须能穿透编排层——子 Agent 的待决问题以同等状态到达用户（委托边界见 P2-5）。
• 禁止把用户未回复视为同意，禁止用超时放行代替人的决定。必须定义无人响应时的保留期限和处置方式并事先告知，到期按已告知的规则结束、归档或升级，避免任务无限悬空。
• 对可能产生重复外部影响且结果未知的动作，禁止未经状态核对直接重试；已定义且有上限的安全重试不在此禁止范围内（机制要求见 P7-2）。

设计应用提供明确的选择，如补资料、缩小范围、批准新预算、人工接手或结束；等待状态携带结构化的请求内容（内容标准见 P4-2）；用户在等待期间可以做别的，返回时该状态仍在。

验证示例

• 用户侧：用户回来后能否不重读完整对话就接上任务，并知道不处理会发生什么？
• 实现侧：验证受影响步骤确实停止，其他独立且已授权的安全工作才可继续；不靠无依据的自报置信度决定越界。
• 触发澄清请求后关闭页面，在保留期限内返回，验证任务可恢复且上下文完整；超过期限后，验证按事先告知的规则处置。

依据与参考"交给人决定"必须有一个可落地的等待状态作为存在形式，否则停止与升级只是文案。失败记录——缺失该状态时子 Agent 的问题到不了用户（Strands SDK issue #1371，已修复关闭，作历史证据）。实现参考——协议层、API 层、框架层独立收敛于同一状态语义（A2A 的 input-required、OpenAI 的 requires_action、LangGraph 的 interrupt）。

反例做不到——等待确认一段时间后自动放行；"等待"实为持续运行模型的假等待；发送结果未知时反复点击发送；做过头——一条路径受阻，就把所有并行任务无说明地一起丢弃；把每个内部小分支都升级为等待用户，任务在无谓等待中悬空。

P4-4指令与内容的信任分级必须¶

一句话：读取到的内容不是新的上级，也不能替用户授权。

适用读取外部内容，或处理登录、身份验证及支付等敏感步骤时。

规则外部内容必须按其被授权的用途处理，禁止仅凭内容中的指令、身份宣称或格式获得更高权限、改变用户目标或泄露信息。系统必须阻断已识别的越权请求；仅在任务范围或合法授权确实需要人作决定时升级，禁止把危险内容的安全裁决默认转嫁给普通用户。敏感步骤必须使用经安全评审的授权、受限工具或用户接管路径，禁止向模型、普通对话或日志非必要地暴露敏感要素；该路径必须同时满足三项最低条件，缺一即视为没有受支持的安全路径——敏感要素不进入模型上下文、普通对话记录与可读日志；该路径有安全负责人的书面评审记录；用户可随时改为亲自操作。

边界条件用户明确要求依照某文档完成任务时，可在已有授权内利用文档中的步骤；这不允许文档扩权或覆盖安全边界。没有受支持的安全路径时，停止相关步骤并由用户在可信界面完成，不承诺 Agent 可以安全代填所有敏感信息。

设计应用异常提示说明"什么被阻止、对任务有什么影响、还能怎么继续"，不必原样展示危险文本；登录或身份核验交给可信界面，并说明完成后 Agent 还能做什么。

验证示例

• 用户侧：在材料中植入越权语句，观察用户能否理解任务受到了什么影响，而无需判断技术攻击细节。
• 实现侧：安全与工程验证权限隔离、工具调用和敏感数据处理；不能只依赖一段提示词或"用户已点击同意"（机制要求见 P4-5）。

反例做不到——网页自称管理员就获得权限，或让用户在普通聊天中粘贴密码；做过头——弹窗问用户"这是不是提示注入"，把安全裁决转嫁给普通用户。

P4-5权限在机制层强制必须¶

一句话：权限靠确定性机制强制，不靠提示词；凭据不进模型上下文。

适用Agent 与任何工具、资源之间的权限控制。

规则权限、撤权与确认门槛必须由确定性机制（策略门、沙箱、白名单）强制，默认拒绝、失败关闭，不得仅靠提示词或模型自觉。必须区分能力门控（工具在不在菜单里）与逐次授权（这次调用、这些参数是否允许）：模型给出的参数不构成授权。策略只能来自运营方控制的数据，模型输出与读取内容都不得改写策略。分层策略中的检查不得被前置规则静默旁路。敏感凭据不进入模型上下文与可读日志，由执行环境之外的机制附加。采用沙箱隔离执行不受信任操作时，文件与网络隔离应当同时具备——只有单一隔离可被另一通道绕过；未采用沙箱的产品，必须以其他机制达到同等的隔离效果。

依据与参考P4-1、P4-2、P4-4、P2-3 的承诺（"撤回授权后新动作被拦截""界面承诺不等于已经限制访问"）必须是机制事实，本条回答那靠什么限制。失败记录——被审计的主流框架在受审版本中缺少默认失败关闭的逐次参数授权（ScopeGate 论文对三个实现指定版本的审计，结论限于受审对象与默认行为）；分层权限中被前置规则批准的调用不会到达后面的回调，只写在回调里的检查被静默绕过（Claude Agent SDK 官方警告）；只做文件隔离可被网络泄露、只做网络隔离可被文件逃逸（Claude Code sandboxing 文档）。

设计应用每次授权决定生成回执（动作、决定、依据、审批人）供 P5-2 追溯；撤权生效点明确，新动作从该点起被拦截。

验证示例

• 撤回授权后触发新动作，验证被机制拦截而非仅界面提示。
• 在被读取内容中注入"提升权限"指令，验证策略不受影响。
• 审查分层策略：确认没有只存在于末端回调、会被前置规则旁路的关键检查。

反例做不到——权限约束只写在系统提示词里，一次注入即失效；做过头——把每个内部只读调用也推给用户逐次授权（应对方式见 P4-6）。

P4-6边界替代逐项审批应当¶

一句话：用预定义安全边界换取边界内自主，减少逐项打断。

适用高频、低风险且可恢复的操作类别。

规则应当优先用预定义安全边界（沙箱、白名单、有效预先授权范围）让 Agent 在边界内自主执行，把逐项确认留给真正的高风险动作；边界的范围、依据与退出方式对用户可理解、可收回（受 P4-1、P2-3 约束）。

依据与参考失败记录——机械点允许（rubber-stamping）是被独立讨论过的失败模式：确认次数越多，真正重要的那次确认越容易被顺手点掉。实现参考——沙箱使内部权限提示大幅减少（Anthropic 自报口径，未经独立测量）。

设计应用把"这类操作在此范围内无需再问"设计成用户可见、可关的边界，而不是散落的静默放行。

验证示例

• 统计典型任务的确认次数；高频确认集中在低风险操作时，检查是否可用边界替代。
• 验证边界外的动作仍触发确认，边界本身可被用户收窄。

反例做不到——为"安全"让用户为一次总结点几十次同意；做过头——把高风险动作也划进"边界内自主"，边界成为绕过 P4-2 的后门。

3.5 P5 证据校准信任¶

让用户对系统、过程与结果形成有依据的判断：能力、进展、来源与身份都如实呈现，提供足以判断的信息而不是堆积过程；目标是校准信任，而不是最大化信任。

P5-1能力与局限披露必须¶

一句话：在用户作出委托时，让他知道能做什么、不能指望什么。

适用首次使用某项能力及能力限制会影响当前决定的情境。

规则产品必须在用户据此作出重要委托前说明与当前任务相关的能力、已知局限和错误可能性，并让这些信息之后仍可查阅；重要委托前应当提供可预期的代价量级——时间、费用或资源（运行中的实际用量见 P5-3）。产品应当让用户在使用情境中能发现可委托的能力——校准信任既防信任过度，也防信任不足。禁止暗示 Agent 不会出错，或通过文案承诺未实现的能力。

设计应用用具体任务说明限制，如"可生成发送草稿，但不会自动发出"；在受限步骤再次提醒，避免只有首次长篇免责声明。空状态、示例任务或对象上的情境建议都可承载能力发现；代价量级用区间或类比表达即可，不要求精确报价。

验证示例

• 用户侧：首次完成任务后，让用户描述产品能做到哪一步、哪些结果仍需检查。
• 用户侧：委托一个多步任务前，观察用户能否形成大致的时间或代价预期，并说出这个产品还能承接什么。
• 实现侧：核对能力文案与当前版本、账户权限、连接工具及实际后台能力。

反例做不到——宣传"放心交给它"，却不说明只能生成草稿；声称任务会持续运行，退出页面后实际上已停止；做过头——每次回答前都先播一段免责声明和能力清单，用户学会直接跳过。

P5-2行动前中后可追溯必须¶

一句话：让用户知道计划做什么、现在到哪了、最后实际改变了什么。

适用多步、长时间、可跨会话或产生外部影响的任务。

规则行动前，用户必须能查看目标、行动范围及关键介入点；行动中，必须能查看真实状态、已完成部分和当前阻塞；行动后，必须能区分完成、部分完成、未完成及待核验事项，并追溯关键动作、实际来源与外部结果。呈现中必须区分暂定计划、已发生动作和已确认结果，不把暂定步骤装成承诺；禁止伪造实时进度、完成百分比或后台能力，状态过期或连接中断时如实标注。可在用户离开后运行的任务，必须说明继续或暂停条件，并在返回时提供状态与待办摘要；通知应当围绕重要结果、风险或用户决定，而非每一步过程。本条约束面向用户的呈现，呈现所依据的运行事实由 P5-3 供给。

边界条件本条要求可核查的任务证据，不要求展示模型私有推理过程、系统提示词、密钥或无关个人信息。受权限限制的证据提供脱敏摘要，并说明无法查看的边界。

设计应用提供分层任务摘要与按需展开的记录；有计划时显示可调整的当前计划。结果交付对应 P3-3 的成功标准，低风险自动验收不强制增加人工确认。呈现所依据的运行事实见 P5-3，叙事组织见 P5-4。

验证示例

• 用户侧：离开再回来，用户能否回答"做完了什么、我现在要做什么"？遇到部分完成时，能否发现遗漏？
• 实现侧：核对状态、回执与实际执行一致；断开连接后验证状态被标注为可能过期，而非继续显示实时进度。

反例做不到——用一条永不变化的"正在思考"覆盖所有状态，任务停止后仍显示"已完成"；做过头——每次工具调用都推送一次通知。

P5-3运行状态与行动回执可信必须¶

一句话：让界面获得真实、可核对的运行状态与行动结果，不从模型叙述里猜进度。

适用所有需要向界面呈现执行过程的 Agent。

规则runtime 必须向交互界面提供可核验、可关联到正确任务与工作对象的运行事实——运行的开始与结束（含 P3-7 的任务结果与结束原因）、关键行动的发起与三态结果、待决事项与等待人类的请求，以及会影响用户判断的内部变化（上下文压缩、脱敏、子 Agent 启停）；界面不得从模型生成的叙述中猜测这些事实。断线重连后，必须能恢复当前可靠状态，或明确标示缺失与过期部分。资源用量应当持续可查、接近上限时可预期，而不是只在耗尽时报错。类型化事件流、带版本的状态快照、可查询的行动回执均可作为实现方式。

依据与参考界面能展示的上限，就是它能获得的运行事实的上限；界面拿不到真实状态时，"进度"只能来自猜测或装饰（P5-2 禁止伪造进度）。失败记录——靠解析非结构化文本流猜测执行状态，在任务分叉、并行、调用工具时失效。实现参考——类型化事件流是收敛度最高的实现（标准事件类型集的 AG-UI——事件类别随版本扩展、流式状态机的 Vercel AI SDK、"Token 流 ≠ Agent 流"的 LangChain）；后台任务记录加带版本与更新时间的状态快照、可查询回执，同样可以满足本条。收敛证明可行，不证明唯一。

设计应用运行事实与呈现分离——同一组事实可渲染成进度卡片、通知或语音摘要；已承诺向界面提供的事实类别不静默消失；连接中断时明确显示状态可能过期。

验证示例

• 断开界面重连后，能否恢复真实状态，或明确标示缺失与过期部分。
• 检查"正在思考"之类的界面状态是否对应真实运行事实，而非计时器动画。

反例做不到——界面靠正则解析模型输出猜测工具调用；做过头——把内部每个函数调用都定义成面向用户的事实类别，契约膨胀到无人消费。

P5-4面向用户的叙事层应当¶

一句话：给用户"在做什么、为什么、下一步"的摘要与工件，不是开发者日志。

适用多步、长时间、跨会话，或用户需要中途参与的任务。

规则产品应当在运行事实之上提供面向用户的叙事：当前目标、当前阶段、已完成部分、主要阻塞和下一项重要行动（暂定计划、已发生动作与已确认结果的区分要求见 P5-2）。计划、任务清单、差异对比等外化工件应当作为用户与 Agent 的共享事实源，让用户从同一个对象上理解进展、依据与下一步；工件上的用户修改如何进入后续执行由 P6-3 规定，工件如何跨会话延续由 P7-1 规定。解释围绕行动依据与影响，不展示大量内部过程。

依据与参考失败记录——持续监控的认知负担不可持续，全量过程直播淹没用户。实现参考——共享任务清单、可编辑计划、执行旁白在四家以上产品独立收敛（Manus、Devin、Claude Code、ChatGPT agent）。同一工件常常既是防漂移的工作记忆（P7-1）又是进度叙事——这正是机制一物多用的典型。

设计应用用户返回任务时先看到摘要而非完整记录；"系统状态可查询"不等于"人知道怎么参与"——叙事要回答"现在需不需要我"。

验证示例

• 用户离开后返回，能否回答"已经做了什么、接下来做什么、现在需要我做什么"。
• 用户编辑计划中的一项，验证叙事与实际执行保持一致（编辑进入执行的义务见 P6-3）。

反例做不到——只提供完整运行日志，用户自己拼进度；做过头——每次工具调用都变成一条消息，暂定计划被呈现为必然发生的承诺。

P5-5区分来源与系统分析必须¶

一句话：有出处不等于已证实，让用户知道依据、推断和未知分别是什么。

适用呈现分析、建议或会影响用户判断的结论时。

规则系统必须区分来源中的陈述与系统形成的推断或建议，并在影响决定的位置说明关键假设、证据缺口及未核验信息；禁止将有引用的来源主张自动呈现为已独立核实的事实，或用无测量依据的置信度数字伪装统计可靠性。置信度呈现应当与用户可以采取的不同行动关联。

设计应用围绕关键结论呈现来源、范围或时间及必要限制；无需为每一句话贴标签，可用局部注释、对照或展开说明帮助判断。来源与时效的运行侧维护见 P1-5。

验证示例

• 用户侧：给用户一段厂商宣称与一段系统推断，观察能否分辨证据来源，并知道还缺什么才能作决定。
• 实现侧：检查引用是否支持相应主张、是否真被读取及是否为正确版本；统计数字有可追溯的测量依据。

反例做不到——把"厂商声称效率提高 40%"直接写成"效率提高 40%"，或展示无计算依据的"可信度 98%"；做过头——每句话后面都挂一串来源标记和不确定提示，用户分不出哪一处才是真的存疑。

P5-6AI 身份与产物标识必须¶

一句话：让人知道 AI 参与了什么，不把它冒充成人或把所有内容都归给 AI。

适用用户与 Agent 交互，或 AI 参与生成、修改并交付内容时。

规则用户必须能够识别正在与 AI 交互，情境已明确时不必重复提示；AI 对内容的实质性生成或修改必须能被识别，且不得把用户原作误标为全部由 AI 创作。禁止通过虚假的真人身份、专业资格、亲身经历或情感宣称误导用户对系统性质与责任的判断。

边界条件友善语气、角色化视觉或自然对话不自动构成误导；本条不规定所有产物采用同一可见水印。标签方式、解释入口、机器可读标识和法定披露不是同一件事，具体适用性另行判断。

设计应用在适当的界面、内容范围或版本记录中说明 AI 的参与；对导出与分享单独判断来源误认风险和适用披露要求，标识不是装饰，也不能代替证据。

验证示例

• 用户侧：用户能否分清原始材料、AI 建议和自己最终改定的内容？离开原界面后的产物是否造成明显来源误解？
• 实现侧：核对标识与真实生成、编辑范围一致；领域或司法辖区要求的披露由相应负责人另行确认。

反例做不到——Agent 冒充真人专家亲历某事；做过头——只改一个标点，就把整篇用户文章标为"完全由 AI 创作"。

3.6 P6 协作有契约¶

运行中的一句话，可能是补材料、纠正方向、撤回授权、追加任务，或只是一个不该打断主任务的问题——用户输入不再只有"开始一个新请求"一种语义。本原则约束运行中的人机双向协作：人的介入被正确理解、有明确回执，并按声明的范围与时点改变任务；双方的贡献都受保护；Agent 找人的时机与人的注意力相称。

P6-1控制通道分立与生效必须¶

一句话：停止与接管必须存在，转向应当提供；通道语义分立，请求区分已接收与已生效。

适用存在持续自主执行、可编辑成果或人工交接的任务。

规则

• 存在持续自主执行时，用户必须能够请求停止后续自主行动，并获得接管或人工交接路径——这项基础控制是本条要求其存在的能力，不以产品已提供其他控制通道为前提（委托层面的收回见 P2-3）。
• 存在持续自主执行时，产品应当提供中途转向，让用户不必停止重来即可注入新指导；转向保持任务连续性与仍有效的成果，允许中断、重算或重新规划受影响部分，不应当无必要地重置整个任务。
• 产品提供的控制通道必须语义分立：中途转向、暂停（暂不继续且可恢复）、停止（结束后续执行）、接管（人收回执行权）是语义不同的通道，必须明确各自的生效语义与在途工作处置，不得用一个"停止"含糊承担全部。
• 控制请求必须区分已接收与已生效两个事件；生效反馈附已提交且无法取消的动作清单。禁止把收到停止请求说成全部操作已撤销。
• 接管必须有移交协议：接管前暂停相关自主操作以防双方冲突；交回时 Agent 基于接管期间的实际状态重新理解再继续，不重复用户已完成的操作、不恢复已失效的旧计划。
• 用户退出或收回参与后，必须能保留或取回权限范围内的已有成果，并获知无法自行继续的原因与交接方式。

边界条件不要求技术上不可中断的已提交动作瞬时消失，也不要求所有 Agent 原生能力拥有完全等价的手工版本。

依据与参考steering 是产品实践中最重要、也最容易被忽略的控制点——它保留在途工作，用户成本远低于停止重来。失败记录——人与 Agent 同时操作同一环境的编辑冲突有产品文档明示（Devin）。实现参考——头部产品收敛（Cursor 的 follow-up 不中断、Devin 的对话式纠偏与"接管前先暂停"协议、ChatGPT agent 的中途重定向、Codex 的 Steer）。本条主责控制动作引起的运行变化与接管交回；输入的识别与任务绑定见 P6-2。

设计应用界面不必出现四个按钮——多数产品用"运行中输入框 + 停止键 + 接管入口"即可承载，关键是背后语义分立、回执明确。明确停止按钮影响的任务范围（子任务的停止范围见 P2-5）；实际提供暂停、停止、撤销时说明区别。

验证示例

• 运行中注入"改用另一种风格"，验证在途工作合并新指导而非从头重跑。
• 在发送过程中请求停止，观察用户能否理解哪些已提交、哪些还未执行；验证停止请求的受理与生效时点、未提交动作的拦截。
• 用户接管修改工作对象后交回，验证 Agent 基于新状态继续而非重复旧步骤。

反例做不到——用户点击停止后提示"已全部取消"，但外部操作仍在完成；任何中途输入都导致整个任务重启；接管期间 Agent 仍在同一文件上操作；做过头——每完成一步都停下等用户点"继续"，用户实际上在手工驱动整个流程；要求用户先学会"排队、注入、中断"等术语才能说一句话。

P6-2运行中输入的语义与生效必须¶

一句话：每次介入都明确改变哪项工作、从何时生效，并有回执。

适用允许在任务运行中输入消息、修改要求或发出控制请求的产品。

规则

• 产品必须区分运行中输入的实际语义——修改当前任务、追加后续任务、独立提问、控制请求——并明确作用范围与生效点；存在可能导致重要误操作的歧义时先澄清，不默认采用某一种处理。
• runtime 必须对运行中收到的新输入有明确的处理策略——排队、合并进当前执行、打断或拒绝——并反馈采用了哪种。
• 对改变运行的请求，必须反馈已收到、待处理、已生效或无法执行；仅把消息加入对话记录，不构成运行已经改变。
• 输入绑定到明确的运行对象，不送到错误的任务上。

依据与参考"做完后再翻译成英文"和"刚才的内容不要发送"不能采用同样的排队方式——前者可等本轮结束，后者必须立即拦截在途动作。实现参考——排队与转向的显式区分、输入绑定运行标识（Codex 的 Queue/Steer 与回合 id）；LangChain 的 double-texting 四策略为排队、拒绝、打断、回滚（Enqueue/Reject/Interrupt/Rollback）——本条正文中的「合并进当前执行」对应 steering，是本规范自己的分类，不出自该来源。本条主责输入的识别、任务绑定与处理回执；控制动作的生效语义见 P6-1，双方贡献的共存见 P6-3。

设计应用多数输入可由系统按上下文推断语义并在回执中说明（"已合并进当前任务"/"将在本轮结束后处理"），仅在歧义危险时询问；不强迫用户手动选择模式。

验证示例

• 任务运行中发送"不要发布"，验证用户能知道它作用于当前任务、尚未提交的发布已被拦截。
• 发送一个无关的独立问题，验证主任务不被误改。
• 任务运行中连发两条语义不同的消息，验证处理策略明确且被反馈。

反例做不到——用户以为已经改变方向，Agent 继续按旧计划执行，那句话只是躺在聊天记录里；做过头——每条消息都弹出"这是修改、追加还是提问？"三选一。

P6-3局部修改与贡献保护必须¶

一句话：改一段不用重做全部；后到的生成不得覆盖用户已认可的工作。

适用存在可编辑成果，或用户与 Agent 都能编辑、选择、采纳成果的任务。

规则

• 对可拆分且仍可编辑的成果，必须支持局部修改或选择性采纳，保留未受影响的已认可部分；产品必须区分当前成果、待采纳建议和已认可部分，并提供符合任务粒度的修改与采纳方式。
• 用户的直接编辑必须进入工作状态（P7-1）、参与后续生成；双方修改冲突时采用明确的合并或选择规则，禁止静默覆盖用户的新修改——旧任务晚到的结果同样不得覆盖。
• 局部修改影响关联结果时，让用户理解哪些仍有效、哪些需要更新，不默认全部重做。

依据与参考用户发出了正确指令、系统也执行了，但采用整篇替换，仍然抹掉了手工修改——这是 P6-2 之外的另一个问题：前者管指令如何进入运行，本条管双方贡献如何共存。实现参考——前端与 Agent 共享状态、快照与增量更新、冲突重同步（AG-UI 及其应用示例）；协议只负责传递状态，"谁的修改优先"是产品必须自己回答的协作规则。撤销操作的范围与后果见 P7-4。

设计应用协作不必全走聊天消息，可以发生在双方共同操作的对象上（可编辑的清单、画布、文档）；Agent 下一轮读到的是用户改过的版本。支持改一段、排除一项或重做一部分；存在依赖时提示哪些关联结果会失效。

验证示例

• 让用户保留八封草稿、只改两封，验证未受影响部分不被重生成。
• 用户手工修改标题后让 Agent 优化布局，验证标题保留、冲突被解释。
• 用户修改成果的同时旧一轮生成返回，验证不发生静默覆盖。

反例做不到——"优化一下"直接整篇重生成，用户上一小时的手工编辑消失；修改一段就重生成整份成果并抹掉手工编辑；做过头——每个小改动都要求用户处理版本冲突与分支管理。

P6-4主动介入匹配价值与注意力应当¶

一句话：在人的参与能改变结果时找人，不是有不确定就打断。

适用Agent 会主动提问、通知、请求判断、邀请用户参与或主动提议新任务的产品。

规则主动介入应当有明确目的：消除重要歧义、取得必要授权、邀请有价值的创作判断，或让用户选择实质性取舍。询问应当围绕会改变下一步的最小必要信息，优先使用已经提供且仍有效的信息、不重复索取，涉及取舍时说明不同选择会改变什么；能够通过已授权的读取或核验解决的问题，不应当默认转交用户，而必须由用户作出的目标、取舍与授权决定，不得以检索结果、历史偏好或模型自信替代（承接 P1-1、P4-2）。主动提议新任务时，禁止将提议本身或用户未回应视为执行授权（授权仍按 P2、P4 取得）；提议的类别与频率应当对用户可预期、可关闭。团队应当根据影响、时效和打断成本，选择即时介入、集中询问、延后通知或不打断；提出请求时让用户知道为什么需要参与、有哪些可行选择、暂不处理会发生什么。必要的授权与安全门槛不因减少打断而取消（P4-2 优先）。

依据与参考少问不是目标，让人的参与产生价值才是目标——创作方向选择值得主动邀请，一个不影响下一步的排版偏好不值得立刻打断。理论与实现参考——注意力、行动收益与打扰成本的权衡（Horvitz 混合主动性研究）、按情境安排介入时机（Microsoft HAX 指南）。

设计应用可延后的问题攒批集中问；值得用户参与的判断（选方向、定取舍）设计成邀请而非阻塞。

验证示例

• 比较缺少关键对象与缺少次要偏好两种情况，检查介入方式是否不同。
• 统计一次典型任务的打断次数与用户实际改变结果的次数之比。
• 答案已在用户提供的材料中时，验证系统直接使用而非再次发问；需要用户取舍时，验证问题说明了选择的影响。

反例做不到——把用户变成审批员，或重要歧义也闷头猜；答案已在用户材料里仍反复发问；做过头——为了"零打扰"剥夺用户重视的创作选择；主动提议不可关闭、频率不可预期，邀请变成打扰源。

3.7 P7 延续可治理¶

本原则管辖已经形成的状态与后果如何被保存、恢复、纠错与持续维护：工作状态要能延续，已发生的外部影响不被重复、不被谎称撤销，错误后果有出路，长期记忆由用户决定，经验的形成与复用有依据，产品行为的演进可被发现与告知。划界依据是对象是否已经形成，不是持续时间：一份为期一个月的预先授权仍属授权关系（P2、P4）；同一次运行内刚刚发生的错误，已是本原则的对象。

P7-1工作状态可延续必须¶

一句话：让任务依靠可靠的工作状态继续，而不是依靠模型重新猜测过去。

适用多轮、多步、跨会话，或承诺暂停后继续的任务。

规则系统必须维护足以继续任务的工作状态，包括当前目标与约束、已确认决定、成果版本、已执行动作和未决事项，并使其在中断、崩溃或执行实例更换后仍可恢复（在可中断点持久化检查点是常用实现）；上下文压缩、执行实例更换或恢复不得无说明地丢失这些信息。会话内工作状态与跨会话个性化记忆必须在用途、访问权限与生命周期上相互隔离——逻辑隔离即可，不要求物理拆分存储；删除或停用跨会话记忆后，不得从执行历史自动重建（承接 P7-5 的禁令）。无法恢复到可靠状态时，必须标明缺失部分，并在依赖该信息的行动前重新核对。工作状态的保留范围与期限应当明确，不得把"能够继续任务"扩张为永久保存全部对话和个人信息。

依据与参考"记得聊过什么"和"知道工作进行到哪里"不是同一件事——记得用户要做网站，却不知道哪些页面已验收、哪个文件刚被手工改过、是否已启动部署，仍然无法可靠继续。失败记录——无持久化状态的失败等于全量重跑（Temporal）。实现参考——线程内检查点与跨线程存储分离（LangGraph）、会话恢复与进度文件（Claude Agent SDK、Anthropic 长运行 harness）。本条主责哪些工作事实需要保留；压缩与交接中如何维持这些事实的有效性见 P1-6，这一步实际依据了什么见 P1-5。

设计应用为长任务维护结构化的进度记录（目标、约束、功能清单、版本），恢复时先读状态再行动；简单单步任务可记录不适用。

验证示例

• 完成部分任务后强制中断再恢复，检查已确认约束、成果版本和未决事项是否仍然正确。
• 删除一项跨会话偏好后运行新任务，验证它不会从旧执行日志中被自动恢复。

反例做不到——新会话不知道之前做过什么，重新猜测并过早宣布"全部完成"；做过头——为一次简单改写建立复杂项目账本，或以"延续任务"为名无限保存全部历史。

P7-2副作用不重复必须¶

一句话：恢复和重试不得重复已发生的外部影响，结果未知先核对状态。

适用产生外部副作用的任务的中断、恢复、重试与崩溃恢复。

规则恢复、重试或重复收到请求时，不得重复已完成的外部影响——无论执行采用重放、续跑还是重建策略。对可能重复执行的外部写操作，必须具备防重手段，且防重必须覆盖并发竞争，以及外部动作已提交但本地尚未收到或记录结果的窗口；幂等设计、执行前状态核对或结果缓存，仅在其一致性、并发控制和保留条件足以覆盖这些窗口时，才可作为满足本条的依据（在计划时生成并随状态持久化的幂等键是常用实现）。无法可靠判定动作是否已执行、又不能保证重试安全时，必须保留"结果未知"，停止相关自动重试，并提供核对或人工处理路径（三态见 P3-5，禁止盲目重试见 P4-3）。恢复或重试前，必须核对外部实际状态、当前对象版本与授权有效性，只继续仍然成立的工作；状态回退不等于外部影响已撤销。

依据与参考本条防止中断恢复、重试与重复请求造成重复的外部影响；P4-3 禁止结果未知盲目重试、P4-2 要求确认后内容变更重新确认，都以本条的机制条件为前提。失败记录——中断恢复从节点开头重放、中断前的 API 调用重复执行有框架文档明示（LangGraph）；重复扣款、重复发信是已记录的失败模式，不是假设。实现参考——去重记录与相关状态变更之间的原子性条件（AWS 幂等 API 实践）："各自核对后分别提交"仍留有竞争窗口，"缓存里没有成功结果"不证明"外部动作没有发生"。

设计应用把"已提交、结果未知"作为一个显式状态处理；恢复流程的第一步是核对而非执行。

验证示例

• 模拟"外部写入已成功但回执丢失"，检查恢复后是否核对状态而非再次写入。
• 两个执行路径并发处理同一外部写操作，验证提交处防重使其只生效一次；写入成功但记录结果前崩溃，恢复后验证不再次执行。
• 在等待审批期间修改内容，验证旧审批不被用于新内容。

反例做不到——恢复任务后重发已发出的邮件；做过头——把所有只读操作也套上幂等协调，简单任务被复杂化。

P7-3错误与恢复必须¶

一句话：出错时保住能用的成果，明确损失和真实可行的下一步。

适用可预见的失败、部分完成或已发生错误影响的情境。

规则团队必须为可预见的失败类别定义处置路径；出现错误时，必须说明已知影响、仍未知的状态和可行下一步。恢复策略应当根据失败原因、实际执行状态、可逆性及依赖影响，在限次重试、替代路径、局部修复、继续完成、撤销、补救或人工接管之间选择，而不是默认全部重做。可撤销的操作必须提供入口及适用时间窗，不可逆操作必须如实说明限制与可行补救或联系路径；禁止承诺并不存在的恢复或补偿。补救是新的行动，仍受原有授权、资源与防重复要求约束（P4-2、P7-2）；补救失败时，必须保留其进度、已知影响与可行下一步。部分完成时，必须保留仍可安全使用的成果；继续执行遵循 P7-2 的防重复要求；恢复后应当重新核验受影响成果及其依赖（核验依据见 P3-7），不把流程结束当作已经恢复正确。

依据与参考停止后续执行、恢复任务状态、撤销已发生改动、补救不可逆后果是四种不同的承诺，混用会产生"已恢复原状"的错误宣称（撤销的对象边界见 P7-4）。实现参考——补偿是业务特定的新行动，不一定恢复初始状态，且自身可能失败（Microsoft Azure 补偿事务模式；单一来源，作实现参考）。

设计应用把已完成、未完成和结果未知分开；提供局部重试、恢复副本、人工补救或联系负责人等适用路径，不把"重新开始"作为唯一出口。

验证示例

• 用户侧：在批量任务中制造部分失败，观察用户能否找到保留的成果，并只处理剩余或异常部分。
• 实现侧：核对撤销是否真的恢复状态，超出窗口后文案是否变化；验证重试不会造成已知的重复副作用。
• 实现侧：让补救动作本身失败，验证系统保留补救进度与影响说明，而不是宣称"已恢复原状"。

反例做不到——一句"出错了，请重试"掩盖已发送的部分；无法退款却承诺"已恢复原状"；做过头——一次本可自动重试的网络超时，也弹出完整故障报告并中止整个任务。

P7-4回滚边界对齐用户心智必须¶

一句话：撤销 Agent 的改动和用户自己的版本历史是两回事。

适用Agent 会修改用户可见成果或工作环境的任务。

规则撤销"Agent 造成的改变"时，必须保护用户自身的修改与版本历史不被静默回退；回滚的对象边界（回滚哪些文件、是否回滚对话、是否影响外部已提交动作）与受影响的依赖必须明确告知。回滚不等于外部影响已撤销——已发出的邮件不因状态回退而收回（承接 P7-3、P7-2）。将 Agent 改动的回滚与用户版本历史设计为两套分立机制是常见实现；本条要求的是分清贡献来源、作用范围与冲突处理，不强制建立两套机制。

依据与参考P7-3 要求可撤销操作提供入口，本条补充撤销的对象边界：回滚误删用户自己的工作，本身就是一种伤害用户的失败。实现参考——Agent 检查点与用户版本管理刻意分离、回滚文件保留对话（Cursor Checkpoints；单一来源，作实现参考而非收敛证据）。本条主责撤销操作的范围、依赖冲突与恢复后果；正常协作编辑中的贡献保护见 P6-3。

设计应用"撤销 Agent 这轮改动"和"回到我上次保存"是两个入口、两种文案；回滚前预览影响范围。

验证示例

• 用户手工编辑后回滚 Agent 的上一轮改动，验证手工编辑保留。
• 回滚涉及外部已提交动作时，验证系统如实说明该动作不受回滚影响。

反例做不到——回滚 Agent 改动时一并抹掉用户的手工修改；做过头——每次小改动都强制用户理解一套完整的版本树。

P7-5记忆可见可控必须¶

一句话：让用户决定什么被长期记住，而不是只能相信"我已经忘了"。

适用跨任务或跨会话保留信息用于个性化时。

规则用于个性化的记忆必须可查看、修正、删除或停止使用，并区分用户明确提供的信息与系统推断；用户必须能关闭新增记忆及停用已有可选记忆，并了解生效范围。删除或停用后的信息禁止被继续用于相应个性化，或未经授权从历史材料自动重建；禁止把关闭记忆说成日志、训练用途与所有数据保留同时消失。确有保留依据且不能由用户删除的必要记录，必须与可选个性化记忆分开说明用途、访问范围和保留期限；不得以保留记录为由继续启用用户已关闭的可选个性化。

设计应用展示必要的记忆内容、来源类型、用途和作用范围；说明"仅本次使用""保存为偏好"以及删除与停用的差别，不暴露无关敏感记录（存储分层的机制要求见 P7-1）。

验证示例

• 用户侧：删除一项推断偏好后，用户能否理解后续会有什么变化；关闭记忆后是否误以为所有记录都不存在？
• 实现侧：验证后续个性化不再使用已删除或停用信息，并核对衍生记录处理、生效延迟和跨设备范围。

反例做不到——界面删除了偏好，但下一次仍从历史对话自动恢复；把"不保存新记忆"包装成"完全不留痕"；做过头——每条推断出的偏好都做成待确认的记忆条目，用户被迫维护一份不断变长的清单。

P7-6运行闭环与变更告知必须¶

一句话：用真实使用中的问题改进体验，并让用户知道会影响自己的变化。

适用上线或进入真实用户试用的 Agent；设计阶段准备相应计划与责任人。

规则产品必须建立真实任务结果、错误与用户反馈的收集和评估机制，并指定处理责任人；收集范围受 P4-1、P7-5 约束。产品必须提供可用的反馈入口，反馈用途与可预期结果不得被夸大；能力、默认行为或结果表现显著变化时，应当在相关使用情境中告知用户。涉及新增授权的变化按 P4-1 处理。

设计应用在现有评审或运营记录中选择与任务相关的指标，例如目标达成、错误完成声明、纠错成本和不必要打断；区分"修正本次结果"与"提交改进反馈"。

验证示例

• 用户侧：用户反馈后，能否知道本次问题是否已修正、只是收到意见，还是已经交给负责人处理？
• 实现侧：抽查反馈与实际问题是否进入处理流程；验证重大变化后的新旧行为以及未解决问题的可追踪性。

反例做不到——只有点赞点踩按钮但无人处理，收到反馈就说"模型已经学会了"，实际没有任何即时变化；做过头——每次界面微调都作为变更公告推送给所有用户，真正影响用户的变化淹没在通知里。

P7-7经验形成与受控复用必须¶

一句话：可以从过去学习，但一次经历不能未经检验就变成以后的默认规则。

适用从用户交互、执行结果或历史记录中提炼信息（偏好、项目知识、方法、经验），并跨任务复用、据此改变后续行为的产品。

规则团队必须定义可复用信息的形成依据、适用主体与任务范围，以及更新、冲突与失效的处理方式；保存时必须区分原始观察、系统推断与用户确认（承接 P1-5 的区分），并保留依据与适用条件。禁止仅凭一次隐含行为、未经作用范围判定就把推断固化为长期偏好或呈现为用户确认；禁止把未经核验的自我总结标为已验证经验，或将局部成功未经适用性判定推广为通用规则。信息不得仅因被写入记忆而获得更高的指令权威或扩大行动授权（信任分级见 P4-4）。经验被用户纠正、验证失败或适用条件变化时，必须更新或停止相关复用。个性化记忆的用户控制见 P7-5，进入当前决策的有效性见 P1-5，影响用户可依赖行为的变化按 P7-6 告知。

边界条件不要求每条记录逐项人工确认，不要求固定的存储架构，也不要求所有 Agent 具备长期学习能力；核验方式与影响和风险相称。

依据与参考P7-5 管个性化记忆如何被用户控制，P7-1 管任务如何继续，本条管哪些经历有资格变成后续行为的依据——形成侧缺位时，控制侧再完善也只能事后清理。失败记录——可写记忆被注入恶意内容后，后续会话将其当作可信记忆读取，有官方文档警告（Claude 平台记忆文档）。实现参考——按事实、经历与做事规则区分长期记忆并讨论写入时机（LangChain 记忆文档）；隐式行为信号存在多种解释、不能等同稳定偏好（Google PAIR）。均为实现与概念参考，不规定唯一分类。

设计应用区分"仅本次""本项目""长期偏好"的作用范围；行为规律（如连续三次推迟某类任务）可形成待验证假设，向用户求证后再升级为规则，而不是直接生效。

验证示例

• 用户提出一次性要求（"今天先做简单的"）后运行后续任务，验证它未被固化为长期偏好。
• 将一次未经核验的执行结果写入经验后，检查其复用时是否携带待验证标记，被用户纠正后是否停止生效。
• 在可写记忆中植入越权或改目标的内容，验证后续任务不因"来自记忆"而提升其指令权威。

反例做不到——用户一次为赶工允许周末加班，此后默认占用周末；上次跳过审核成功了一次，就学成"以后都不需要审核"；做过头——每条低风险偏好都要求用户逐项确认，用户被迫维护一份不断变长的记忆清单。

---

4. 术语和定义¶

除上表外，暂停表示暂不继续且可恢复，停止表示结束后续执行，撤销表示恢复已发生的改变。界面用词与实际能力一致的要求见 P6-1、P7-3、P7-4。

---

附录 A：故障注入验证清单¶

对涉及运行机制与协作契约的规则，验证方式是故障注入：制造会破坏承诺的场景，测试失败即意味着相应承诺失效。写不出这类测试的候选规则不应进入规范。高影响失败在沙盒或模拟环境测试，不通过真实错误操作验证。下表是示例子集而非穷尽清单：未列入的规则同样按各条验证示例测试。

最后一行不能省：否则规范可能通过所有防错测试，却让正常任务越来越难用。除运行测试外，还应分别验证分类（不同评审者能否对具体要求独立得出相近归属）与用户价值（纠正是否真正生效、协作成本是否下降），三者不能互相替代。分类检验回答的是切分是否清楚一致，不能单独证明没有遗漏：还应当用完整任务走查检验覆盖面——沿"提出目标、授权、执行、介入、交付、恢复"过一个真实案例，检查是否存在重要设计要求无处归属；发现缺口时补规则或调整原则切分。

---

附录 B：论证边界与来源对照¶

B.1 约束词的判据与论证类型¶

标「必须」的唯一依据是必要性：缺了这条要求，产品对用户的某条承诺会在可预见的情境下失效。判断一条规则用三类论证，它们证明的是不同事情，不构成单一强弱序：

只有必要性论证成立的规则才标「必须」；只满足质量或效率的降为「应当」或逐出规范。纯性能与成本工程（缓存命中率、提示词技巧、具体 API 形态）不进入规范，放参考资料。

B.2 论证边界与适用范围¶

如实说明两点弱处：

1. 实现参考集中在 2024–2026 年的头部实现，行业仍在快速演化，"收敛"可能只是暂时局部最优——且收敛只证明可行，不证明唯一。因此规则刻意写性质与契约、不写实现——实现变了，性质仍可检验。
2. 失败记录多来自厂商自述与文档警告，部分数字（如审批提示减少比例）是相关厂商自报口径，缺少独立测量。引用时应标注论证类型与限制——这本身正是 P5-5 对本规范自己的要求。

本规范的适用范围是：围绕任务持续行动、使用工作状态与外部反馈、并允许人参与的软件 Agent。它不覆盖模型训练、基础设施选型、机器人实体安全、无障碍、公平性与偏见评估、对受 Agent 行为影响的非用户第三方的专项影响评估、第三方工具与组件的供应链安全，以及领域合规——这些需要专项评估（P5-6 只覆盖来源误认，P4-4/P4-5 只覆盖运行时的信任与隔离，不替代上述专项）。审计级的全程运行重建属安全与合规专项：本规范只要求 P5-2 的关键动作可追溯与 P4-5 的授权回执，不把完整重建作为体验义务。

两条候选规则本版未采纳、留待完整任务走查检验：P3-9「业务对象语义一致」暂由 P3-2 的绑定义务承载，P6-5「主动发起任务的边界」暂由 P6-4 的提议边界与 P3-8 的持续委托承载；走查发现承载不足时按附录 A 的分类检验升格为独立规则。

规范条款的具体措辞、强度与净收益，仍需针对各产品的目标用户验证；验证方法见附录 A。

B.3 论据来源对照¶

下表出处来自本规范的调研记录（2026-09 时点可访问版本），用于复核各条"依据与参考"中的失败记录与实现参考。本规范未逐条独立复核外部内容——按 P5-5 的要求，此处如实注明；采用规范前建议对关键来源做一次抽查。

---

附录 C：与规范 3.0 的条款对照¶

规范 3.0 采用 L1 体验承诺（24 条）、L2 运行机制（10 条）、L3 协作契约（9 条）三层结构，原则经由 L1 传导至 L2/L3。4.0 取消分层：七条原则直接统领全部规则（4.0 时为 41 条；4.1 新增 P7-7，见附录 D），同一件事只写在一处。主要变化：

• 合并（同一义务原先拆在承诺与机制两处）：BND-2 + BR-4 → P4-2；BND-3 + BR-3 → P4-3；GOV-1（控制部分）+ BR-5 → P6-1；GOV-1（局部修改部分）+ BR-8 → P6-3；BR-7 + RT-10（新输入策略）+ INT-1（运行中输入句）→ P6-2。
• 拆分（一条规则打包了多项独立义务）：RT-10 拆为 P2-5（子 Agent 委托边界）、P3-8（任务生命周期）与并入 P6-2 的输入策略；GOV-1 拆入 P6-1 与 P6-3。
• 取消：L1→L2/L3 覆盖映射（原附录 A.1）、"上承与论据"的锚点机制（论据保留为各条"依据与参考"）、层与维度的双轴分类。

---

附录 D：4.0 → 4.1 变更记录¶

4.1 不改变原则切分与结构（七条原则直接统领规则，无分层）。依据是六份独立验证与评审意见的收敛项；变更分两类。

修正（消除文档间不一致与来源错误，不新增义务）：

• P7-2 防重条件补全：防重必须覆盖并发竞争与"已提交但未记录结果"的窗口，状态核对与结果缓存仅在满足一致性条件时可作依据——原表述"三种手段均可"已被抽象模型反例证伪。
• P6-1 恢复 3.0 GOV-1 的"应当提供中途转向"（4.0 无记录地丢失了这条应当级义务），并放宽转向定义：保护连续性与仍有效成果，允许重算受影响部分；一句话与术语表同步更新。
• 强度对齐：P2-4"可靠性提升不代表同意扩权"升为显式禁止句；P5-2"禁止伪造进度"从验证示例上移进规则正文（P5-3 此前引用的是一条无规范载体的禁令）；P3-3 删去与 P3-7 重复的双轴表达句，P5-2 补呈现与事实供给的分工句。
• 约束词纪律（2.2）：收编「不得」（=禁止）与「不应当」（=应当反向），明确"以独立义务子句为判定单位、陈述句承接标题强度"；P4-5 的「须」改「必须」，规则正文的「不能」统一为「不得」；P1-5 首句改为显式义务，并区分内容获取方式（可自主检索）与信任维护责任（必须在模型之外）。
• 范围声明补齐：公平性与偏见、非用户第三方影响、第三方工具供应链、审计级全程重建显式排除至专项评估（第 1 章与 B.2 对齐）。
• 来源修正：LangChain double-texting 四策略更正为排队/拒绝/打断/回滚，并注明"合并"是本规范自己的分类；压缩警告改引 Agent SDK agent-loop 页；ScopeGate 主张收窄至受审版本；Magentic-UI 改引论文并标注研究边界；Strands issue 标注 #1371 已修复、作历史证据；AG-UI 删去具体事件数量；Codex App Server 链接更新；B.3 补 P4-6 等缺失行。
• 锚点与排版：P1-1、P1-3、P3-7、P4-3 及附录 A 的交叉引用打磨；第 1 章"规则归属唯一"主题句补全；术语表补「任务结果」「结束原因」。

扩展（新增或补强义务，回应"从评审规范走向设计方法"的缺口——正向能力覆盖不足，条款停在"团队应当定义"而缺"依据什么定义"）：

• 新增 P7-7「经验形成与受控复用」【必须】：可复用信息的形成资格、作用范围、更新与失效；禁止一次隐含行为固化为长期偏好、未核验自我总结标为已验证经验、写入记忆获得指令权威。术语表将「记忆」标注为个性化记忆并新增「可复用信息」。
• P3-2 补行为合同的业务对象绑定：Agent 与其他入口对同一业务对象语义一致，建议、草稿、已提交、目标达成不得混同。
• P3-6 补信息缺口决策：按缺口性质在已有信息、读取、检索、测试、询问、可修改假设间选择；定义信息获取的停止条件。
• P6-4 补询问质量与主动提议边界：最小必要、不重复索取；可检索核验的不转交用户，用户专属决定不被检索替代；提议不构成执行授权，类别与频率可预期、可关闭。
• P3-8 补持续委托：触发依据、委托有效期、重复触发处置；停止本次运行与撤销持续委托分立。
• P7-3 补恢复策略选择与补救约束：补救是受授权与防重约束的新行动，补救失败保留出路；恢复后重新核验。
• P5-1 补委托前代价量级与能力可发现（均应当级）；P5-3 补"接近上限可预期"；P1-6 补"指针不等于可恢复"；P3-5 补"工具自我声明不构成授权"。

候选规则 P3-9（业务对象语义一致）与 P6-5（主动发起任务的边界）本版未独立设立，承载方式与升格条件见 B.2。评审清单同步更新为 42 条规则、204 个判定语句。

---

实施验收场景¶

以下场景把已有条款转成可复核的验收输入，不另设通用性能阈值。按产品适用能力选取，补充真实设备、用户、输入序列和证据；不适用记录原因，未执行不得记为通过。

每个场景分别核对配置的有效值、执行记录与用户可理解的结果。保留版本、目标、事件时点、失败范围和恢复结果；外部结果未知不填作成功或失败。