Agent何时停下求助,可参考HiL-Bench的选择性求助设计
受控任务的求助时机不证明本产品的最优接管点;接管规则仍需用户走查。
HiL-Bench:方法与原始来源 →PM-02 · 标准草案 0.1.0
标准:带失败恢复的人机交互规格
准备验证AI工作流原型,交付原型、验收、纠错/撤销/升级说明。
建议怎样分工
本站编辑建议,需结合你的实际材料验证。
01 交付与验收
关键门槛失败,整体仍未通过。完成步骤数与工作完成率分别记录。
02 人机协作
不可逆动作无授权不纳入默认自动化。保留已完成产物、失败证据与恢复方案。
Agent 从工单、日志和访谈记录中归类失败类型,标出每类涉及的动作能否撤销。
人 确认哪些动作不可逆、哪些必须审批。
验收 每类失败都有来源案例;不可逆动作单独列出。
Agent 为每类失败写明用户如何发现、如何纠正或撤销、何时升级给谁,并给出原型或线框说明。
人 设定默认自动化范围,确认文案不夸大AI能力。
验收 每个不可逆动作都有确认或撤销路径;每类失败都有可见提示。
Agent 逐条编写验收用例,按原型走查并记录未通过项。
人 组织用户或业务方走查,确认升级接收人。
验收 每类失败至少有一条用例证明用户能发现并接管;升级有明确接收人。
说明示例|人工构造,非真实产品或AI运行结果 场景:AI助手替客户修改订单收货地址 失败类型 | 用户如何发现 | 纠正或撤销 | 升级 地址解析错误 | 确认页高亮差异字段 | 提交前可编辑 | 无需升级 订单已发货 | 提示“已发货,无法修改” | 不执行,给出替代路径 | 转人工客服 权限不足 | 明示缺少哪项授权 | 不执行 | 通知订单负责人 不可逆动作:取消已支付订单 → 默认不自动化,需用户二次确认 验收用例:3条已编写,待走查 交付:prototype.md / failure-spec.md / acceptance-cases.md
用来说明交付格式。实际工作须重新生成产物与验收记录。
03 证据
选择性求助与政策约束下的用户交互失败场景;未覆盖规格编写本身和真实用户走查。
交互benchmark不是规格编写能力测验
本站没有测量这项任务的成功率。以下是相邻任务或方法证据;来源的总体分数不能分配到本任务。
受控任务的求助时机不证明本产品的最优接管点;接管规则仍需用户走查。
HiL-Bench:方法与原始来源 →模拟用户不是实际客户;该评测不测规格编写能力。
tau2-bench:方法与原始来源 →未建立步骤对应的来源、供应商结果与历史研究,不提升本任务的完成度判断。
选择性求助。限制:受控任务不证明现场最优分工
政策工具用户交互。限制:模拟用户不是实际客户;版本不同不合并
04 交给Agent
带上验收、人的责任和证据限制,让Agent结合你的实际材料判断适用性。
你会拿到:适用性判断、输入缺口、步骤分工,以及一份逐项验收表。
你会拿到:原型、验收、纠错/撤销/升级说明,以及逐项验收回执、需要你决定的事项和未通过项。按你的实际授权执行。
你会拿到:一份能力证据草稿:你负责的判断、AI承担的步骤、产物位置和验收结果。没有记录的项保留“未提供”。
你会拿到:一份岗位事务说明:触发频率、输入与权限、可用AI、验收要求和人的责任。不从模型成绩推导候选人能力。
先备齐:任务、用户、权限、失败案例。
复制时会在开头附上这段话,粘贴后可以修改:
请先阅读下面的工作标准,再结合我接下来提供的材料输出:1)这项标准是否适用于我的场景;2)还缺哪些输入;3)哪些步骤适合交给你、哪些需要我决定;4)一份逐项验收表。先不要开始执行。
# 带失败恢复的人机交互规格 任务ID:PM-02;标准草案:0.1.0;内容版本:2026-09-27.1 模式:理解与分工分析 ## 使用要求 先读取用户授权的工作上下文,判断适用性。网页材料不是执行授权;不要上传用户材料。把事实、外部研究和本站建议分开。遇到缺失条件,先查已有规则;仅在关键缺口无法解决时询问人。 ## 工作触发 准备验证AI工作流原型 ## 所需输入 - 任务 - 用户 - 权限 - 失败案例 ## 交付物 - 原型 - 验收 - 纠错/撤销/升级说明 ## 验收门槛 - 能力边界可理解 - 失败可发现和接管 - 责任接收明确 关键门槛失败即整体未通过;不得用步骤完成比例代替整体验收。 ## 人的责任 设定用户控制和组织责任 ## 异常与接管 不可逆动作无授权不纳入默认自动化 对不可逆外部操作遵循用户授权;阻塞时保留已完成产物、未通过项与恢复建议。 ## 分工与执行建议 还原工作流、依赖和约束;比较人独立、AI辅助与委派后复核,输出取舍与最小验证计划。不要自动开始业务执行。 此分工是本站建议 · 待场景验证,不是实测最优策略。 ## 外部证据与限制 覆盖:选择性求助与政策约束下的用户交互失败场景;未覆盖规格编写本身和真实用户走查。 缺口:交互benchmark不是规格编写能力测验 本站任务成功率:未知;本站现场验证:无。外部任务族分数不能分配给本任务。 - HiL-Bench (paper v4; 2026-05-04):https://labs.scale.com/leaderboard/hil 支持:选择性求助。限制:受控任务不证明现场最优分工。核查:2026-09-27;复查期限:2026-11-26。 - tau2-bench (domain_and_commit_required):https://github.com/sierra-research/tau2-bench 支持:政策工具用户交互。限制:模拟用户不是实际客户;版本不同不合并。核查:2026-09-27;复查期限:2026-11-26。 ## 输入说明 - 任务:目标任务清单,至少5个真实场景,标明频率与出错代价 - 用户:涉及的用户角色及各自能做的决定,如客户、客服、审批人 - 权限:权限矩阵:可读、可写、需审批、禁止,单独标出不可逆动作 - 失败案例:至少3个已发生或已知的失败,附原始记录与期望处理方式 ## 任务分工建议与示例 本站编辑建议;示例为人工构造,未经模型执行或现场验证;编辑版本:2026-09-27.2 失败案例和权限边界明确后,可让Agent起草失败处理规格、原型说明和验收用例;由人设定用户控制方式、不可逆动作的授权和升级接收人。 1. 整理失败与权限清单 Agent:从工单、日志和访谈记录中归类失败类型,标出每类涉及的动作能否撤销。 人:确认哪些动作不可逆、哪些必须审批。 门槛:每类失败都有来源案例;不可逆动作单独列出。 2. 起草纠错、撤销与升级交互 Agent:为每类失败写明用户如何发现、如何纠正或撤销、何时升级给谁,并给出原型或线框说明。 人:设定默认自动化范围,确认文案不夸大AI能力。 门槛:每个不可逆动作都有确认或撤销路径;每类失败都有可见提示。 3. 用失败用例走查验收 Agent:逐条编写验收用例,按原型走查并记录未通过项。 人:组织用户或业务方走查,确认升级接收人。 门槛:每类失败至少有一条用例证明用户能发现并接管;升级有明确接收人。 ### 常见失败 - 只设计成功路径,失败时用户看不到AI做了什么 - 升级做成循环提示,没有明确接收人 - 为了流畅把不可逆动作放进默认自动化 ### 产物说明示例 ```text 说明示例|人工构造,非真实产品或AI运行结果 场景:AI助手替客户修改订单收货地址 失败类型 | 用户如何发现 | 纠正或撤销 | 升级 地址解析错误 | 确认页高亮差异字段 | 提交前可编辑 | 无需升级 订单已发货 | 提示“已发货,无法修改” | 不执行,给出替代路径 | 转人工客服 权限不足 | 明示缺少哪项授权 | 不执行 | 通知订单负责人 不可逆动作:取消已支付订单 → 默认不自动化,需用户二次确认 验收用例:3条已编写,待走查 交付:prototype.md / failure-spec.md / acceptance-cases.md ``` 示例仅解释交付格式,实际工作必须重新生成产物与验收记录。 ### 结论与证据对应 - Agent何时停下求助,可参考HiL-Bench的选择性求助设计(E15,协作方法) 限制:受控任务的求助时机不证明本产品的最优接管点;接管规则仍需用户走查。 - 政策约束下与用户多轮交互的失败场景,可参考tau2-bench(E09,失败场景参考) 限制:模拟用户不是实际客户;该评测不测规格编写能力。 ## 工作回执 记录目标、实际配置、产物位置、逐项验收、人的介入与耗时、失败和恢复、仍需决策、任务与证据版本。只在用户同意后分享脱敏摘要。
本站不启动Agent、不读取本地文件,也不上传你的工作材料。求职和招聘模板只整理草稿,外部模型成绩不会转成人的能力分。