办公Agent与人工审核的“握手协议”：关键操作二次确认的设计模式
先讲一个差点出事的真实案例。
去年，某公司上线了一款办公Agent，能自动处理报销审批。员工上传发票，Agent自动校验、自动通过、自动打款。上线第一周，一切正常。第二周，一名员工上传了一张PS过的发票，金额从3000改成了30000。Agent校验了发票号码和公司抬头，都没问题——它没有图像真伪识别能力。于是自动通过了。
三天后财务对账发现这笔异常，但钱已经打了。虽然最后追回来了，但公司紧急下线了Agent的“自动通过”功能。
复盘时，技术负责人说了一句让我印象很深的话：“我们忘了问一个问题——这件事，真的应该让Agent自己做决定吗？”
后来他们重新设计了“握手协议”：Agent可以填单、校验、打标，但“批准”这个按钮，必须由真人点。从此再也没出过类似事故。
这篇文章，我就跟你聊聊这个“握手协议”——当Agent想做一件关键操作时，怎么跟人类“握一下手”，确认后再执行。不聊复杂理论，只说我们在哪些场景需要握手、怎么设计握手、以及握手的三个核心模式。
一、什么操作需要“握手”？——关键操作的三个特征
不是所有操作都需要人工确认。让用户每件事都点确认，Agent就失去了意义。所以我们定义了一个判断标准：一个操作是否需要握手，取决于它的“不可逆性”和“影响范围”。
操作类型 示例 是否需要握手
低风险、可逆 发送普通消息、创建草稿、读取公开文档 不需要，Agent直接执行
中风险、可逆但麻烦 创建任务、更新日程、发审批提醒 不需要握手，但需记录日志，用户可事后撤销
高风险、不可逆 删除文件、批准报销、发送对外邮件、修改权限 必须握手，人工确认后才能执行
极高风险 转账、删除数据库、批量修改全员数据 握手 + 双人确认
简单说：Agent可以当秘书，但不能当老板。 凡是涉及“钱、权限、对外发声、不可逆删除”的操作，都应该是Agent建议、人类批准。
二、握手的三种模式：从轻到重
我们根据风险等级和业务场景，设计了三种握手模式。
模式1：一键确认（轻量握手）
适用于：操作本身可逆，但影响面较大，需要用户知情。
流程：
Agent识别到需要执行某项操作
生成一条确认消息，包含操作摘要和“确认/取消”按钮
用户点击确认后执行
操作记录写入审计日志
真实场景：Agent想帮你把一封邮件移动到“归档”文件夹。移动后可恢复，但万一移错了，找回来要花时间。所以Agent发一条：“是否将3封邮件移至归档？[确认] [取消]”
用户体验：点一下，0.5秒完成。比手动操作快得多。
模式2：二次确认（标准握手）
适用于：操作不可逆，或影响多人。
流程：
Agent识别关键操作
发送确认消息，包含操作详情、影响范围、风险提示
用户点“确认”后，Agent再次发送一条“请再次确认”消息（或弹出输入框，要求用户输入“确认执行”四个字）
二次确认后执行
真实场景：Agent想删除一个共享文件夹。第一次确认时用户可能误点，二次确认能有效拦截误操作。我们的数据表明，二次确认能减少98%以上的误触发。
为什么不用弹窗？ 因为办公场景主要在IM里。弹窗需要浏览器环境，而飞书/钉钉的消息按钮已经够用。二次确认的消息，我们设计成不同的按钮颜色（第一次蓝色，第二次红色），让用户有明显的心理切换。
模式3：双人握手（高安全握手）
适用于：极高风险操作，单人确认不足以防范风险。
流程：
Agent识别到极高风险操作
向两个不同的审批人（如申请人的直属上级+财务负责人）分别发送确认请求
两人都点击“确认”后，Agent才执行
任何一人点“拒绝”，操作终止并通知申请人
真实场景：员工申请一笔超过1万元的报销。Agent可以填单、验票、计算金额，但最终批准需要部门经理和财务经理双人确认。任何一人都不能单独放行。
设计要点：双人握手必须是“与”逻辑，不是“或”。同时，两个确认请求应该通过不同渠道发送（比如一个人发飞书，一个人发短信），防止同一人冒充两人。
三、握手的时机：什么时候问，什么时候不问？
握手机制最大的陷阱不是“怎么问”，而是“问太多”。
一个用户如果每次操作都要点确认，很快就会厌烦，然后开始闭着眼点“确认”——那就失去了握手的安全意义。
我们设计了智能降级机制：
规则1：高频低风险操作，首次握手后记住偏好
用户第一次让Agent“删除临时文件”时，会收到确认请求。如果用户选择“确认并记住”，以后同类型的操作（删除同目录下的临时文件）不再确认，直接执行。
但“记住”不是永久的。我们设置了一个有效期：30天内有效。超过30天，再次触发相同操作时，重新询问一次。因为用户的习惯可能改变，规则也需要刷新。
规则2：会话内信任
同一个会话中，如果用户已经确认过一次高风险操作（比如发送对外邮件），在该会话结束前，再次执行类似操作不再重复确认。因为连续多次确认会让用户麻木。
会话结束的判断标准：用户连续10分钟没有新消息，或者用户说“结束”“拜拜”。
规则3：紧急通道
有些场景下，用户明确表示“不要问我，直接做”。比如：“现在立刻给全员发紧急通知，不要确认。”
我们支持用户添加--force或直接执行后缀来跳过握手。但这个权限不是所有人都有的，只有管理员或特定角色（如安全负责人）可以使用。而且跳过握手的操作会生成高优先级审计日志，事后必须复核。
四、握手的可视化设计：让用户一秒看懂要确认什么
很多Agent的确认消息写得像技术文档：
“确认执行操作：delete_file，参数：path=/shared/docs/2024/，recursive=true”
用户看了头大，根本不知道删的是什么。
我们的确认消息遵循三行原则：
这是什么操作（一句话，用人话）
影响是什么（谁会受影响、哪些数据会被改）
如何撤销（如果操作可逆，告诉用户怎么撤销）
示例：
确认删除文件夹？
将删除“/shared/docs/2024/”文件夹及其所有内容（共47个文件）。
删除后30天内可在回收站恢复。
[确认删除] [取消]
用户看到这个，不需要技术背景也能做出判断。
对于更复杂的操作，我们还会附上“查看详情”链接，点开后展示完整的操作参数和影响分析（供技术型用户复核）。
五、握手失败怎么办？——降级与兜底
用户可能拒绝确认，也可能超时不确认。Agent需要有兜底逻辑。
场景1：用户拒绝确认
Agent收到“取消”后，不应直接放弃。可以问：“是否需要我提供一个替代方案？”或者“是否需要把这次操作请求转给其他人处理？”
比如用户拒绝了“删除旧日志”的请求，Agent可以问：“是否改为压缩归档，而不是删除？”
场景2：用户超时不确认
Agent发送确认消息后，用户一直没点。我们设置了超时策略：
5分钟内未确认 → Agent发一条提醒：“操作等待确认中，如无响应将自动取消。”
10分钟内未确认 → 操作自动取消，并通知用户：“因超时未确认，操作已取消。如需执行，请重新发起。”
自动取消比“永远等下去”要安全。因为用户可能已经离开工位，不应该让操作悬而未决。
场景3：Agent与人工意见冲突
双人握手场景中，可能出现一人确认、一人拒绝。Agent应该执行“拒绝优先”原则：只要有一人拒绝，操作就不执行。同时通知申请人：“你的操作请求未被批准（原因：xxx拒绝）。”
六、一个完整的握手示例：从发起到执行
把上面的设计串起来，看一个实际案例。
场景：销售小李想让Agent给客户发一封合同邮件（包含附件）。这是对外发送邮件，属于高风险操作。
交互过程：
小李：Agent，帮我给客户ABC发合同邮件，附件是合同.pdf。
Agent：即将发送邮件至 client@abc.com，附件“合同.pdf”。邮件内容将使用标准合同模板。
请注意：对外发送合同邮件不可撤销，请确认内容无误。
[确认发送] [取消] [预览邮件]
（轻量握手，一键确认）
小李点[预览邮件]。
Agent弹出邮件预览窗口。小李检查后发现附件错了，说“换一个附件”。
Agent更新附件，再次发送确认。
小李点[确认发送]。
Agent：邮件已发送。已记录至审计日志（操作ID: op_12345）。如需撤回（若对方未读），请在5分钟内联系IT。
整个过程，小李只点了两下（预览+确认），Agent替他完成了所有操作。而关键决策——确认发送——仍然掌握在小李手里。
如果小李不在线，或者这个操作需要更高权限，Agent会升级为二次确认或双人握手，流程类似，只是确认层级更多。
七、总结：握手协议的本质是责任边界
办公Agent越强大，能做的事越多，就越需要明确责任边界。
Agent负责：执行、记录、提醒、建议
人类负责：批准、否决、担责
握手协议不是给Agent“上锁”，而是给人类“留一个闸门”。当Agent出错时，这个闸门能把损失降到最低；当Agent被滥用时，这个闸门能阻断恶意操作。
回到开头的报销事故。如果当时有握手协议，Agent可以填单、验票、打标，但“批准”需要财务人工点一下。那张PS过的发票，大概率会被财务发现，30000元也就不会打出去。
让Agent多跑腿，让人类多把关——这不是不信任AI，恰恰是对AI最大的保护。因为一旦出了事故，被问责的不是Agent，而是设计Agent的人。
下次你给Agent加新功能时，不妨先问自己一个问题：这个操作，我敢让Agent自己做主吗？
如果答案是“不敢”，那就给它加一个握手。
