会议室里，演示者对着屏幕说：帮我订下周三下午去上海的票，再查一下附近酒店，到了之后给同事发邮件。屏幕上，步骤一条条展开。有人忽然问，发邮件之前，它要不要先问一声？演示者愣了下，说可以设置。这个停顿值得单独看。
智能体的价值常被描述成“自动完成多步任务”。这句话没错，但漏掉了关键：多步之间，谁来决定下一步能不能走。订票要调用外部服务，查酒店会碰到个人信息，发邮件则直接对外表达。企业里的任务往往更像调取内部资料、生成文档、发起审批、通知相关人。每一步都不是孤立按钮，而是权限、数据和责任链。演示时看流程顺不顺，上线时看边界清不清。我倾向于把它当成一个会使用工具的流程参与者，而不是一个只会对话的聊天框。它需要知道能碰什么、碰到什么程度、出问题找谁。
权限不是开关，而是分层
工具调用一旦接入真实系统，权限就不能只剩“允许”或“禁止”。读资料、写草稿、改状态、对外发送、发起审批，是不同层级的动作。能读不等于能写，能写不等于能发，能发也不等于能替人做决定。稳妥的做法，是先把动作拆细，再给每一层配上人工确认点。确认点不必多，但要放在不可逆或影响面大的地方。
记忆也要分层。会话里的临时信息、长期偏好、组织知识，写入和读取的权限并不相同。哪些内容可以记住，哪些只能当次使用，哪些到期删除，需要在设计时写清楚。否则，一个看似顺手的功能，可能把不该长期保留的信息留了下来。
审计不是事后加一张日志表。它要能回答：当时想做什么、用了什么参数、调用了哪个工具、返回了什么、谁确认过、失败后怎么处理。记录不必事无巨细，但关键动作要能复盘。没有这层记录，人工接管会变成凭印象判断。
人工接管要设计成流程的一部分
接管不是失败后的补丁，而是正常分支。超时、返回为空、权限被拒、工具接口变更，都会让流程停住。停住之后，界面要说明原因、影响范围和可选项。人确认后继续，拒绝后如何关闭，修改后如何记录，这些细节决定了接管是帮忙还是添乱。
对智能体的期待，不该是永远不出错，而是出错时能停下、能解释、能把决定交回人。企业可以关注任务完成情况、人工介入频率、拒绝原因和异常类型，用这些信息调整确认点。它们不是用来贴标签，而是用来发现流程里哪一段还不适合放手。
回到会议室的问题。发邮件前要不要请示，没有统一答案。它取决于邮件对象、内容敏感度、是否可撤回、组织习惯。可以先用草稿模式，让人确认再发送；等流程稳定，再调整确认点。这个调整不是追求无人化，而是找到责任可落地的位置。它越像流程参与者，越需要把权限、审计和接管写进设计，而不是等上线后补。