设想一个内部设备报修流程：员工在表单里写下故障描述，系统识别设备编号、位置和紧急程度，自动创建工单并通知值班人员。流程跑到“确认”按钮前停住：信息是否准确，要不要升级，是否通知外部维护方。这些判断看起来简单，却牵涉权限和责任。智能体在这里可以做什么？它能把散落在聊天记录、表单和知识库里的信息收拢，提出下一步动作，甚至调用工具完成查询。但它是否应该直接按下确认，是另一个问题。
任务拆解之后，停顿仍有意义
智能体的常见叙事是“给定目标，自动拆解并执行”。听上去顺畅，落到企业流程里，拆解只是前半段。一个任务被拆成查询、比对、填写、通知几个动作，每个动作都可能遇到例外：设备编号对不上，位置描述模糊，值班人员临时调整。它可按规则处理一部分例外，遇到规则外的情况仍要交回人。停顿不是失败，它把责任边界显影出来。确认按钮前的那几秒，正好是系统展示依据、人做判断的窗口。
工具调用越多，权限越要收着
智能体要做事，通常需要调用工具：查数据库、发消息、改状态、生成文档。工具越多，能力边界越宽，权限设计越不能含糊。哪些操作可以自动执行，哪些需要二次确认，哪些只能生成建议，应该在流程设计时写清楚。审计也类似。一次调用留下了什么记录，输入是什么，输出是什么，谁批准了关键动作，这些信息能帮助复核，而“执行成功”四个字说明不了过程。企业引入这类系统时，容易先看它能做多少事，随后才发现权限和审计决定了它能不能稳定做事。
人机协作不是一句口号
把智能体放在流程里，人的角色会变化。原来人负责搬运信息，后来人负责设定规则、处理异常、检查结果。这个变化不自动带来效率，也不自动带来风险，它取决于流程有没有给人留出合适的介入点。介入点太密，自动化变成频繁打扰；介入点太疏，异常可能被掩盖。一种稳妥做法是先从可回退、影响范围有限的环节开始，让系统提出建议，人确认后再执行，等规则和记录都稳定了，再讨论扩大自动执行范围。
边界感来自可解释
它给出的下一步动作，如果只显示结论，人很难判断。它需要说明依据：读取了哪些字段，匹配了哪条规则，调用了哪个工具，为什么给出这个建议。解释不必长篇，但要能让人复核。可解释性不是装饰，它决定了异常出现时能否追溯。流程里的自动化加深后，解释和记录也要跟上。对企业来说，它的价值可能不在替人做完所有事，而在把重复的信息搬运和初步判断收拢起来，让人把注意力放在例外和责任上。
回到那个确认按钮。问题不是要不要让它按下去，而是按下去之前，系统能不能把依据摆清楚，按下去之后，记录能不能让人放心。这个问题的答案，往往决定了自动化是停在演示里，还是进入日常流程。