Agent 可以替员工操作系统，但哪些动作必须先确认？

“让 Agent 自动办事”听起来很顺，但企业一旦把问题放到真实系统里，马上会遇到边界：查询可以自动做，提交单据可以吗？发消息可以自动发吗？付款、删除、发布这类动作怎么办？

这不是产品体验的小问题，而是企业能不能放心使用 Agent 的前提。

一、读数据和改数据，风险不在同一层

员工让 Agent 查询订单、合同、库存或工单，通常属于读取信息。系统需要确认员工能看什么，Agent只能在这个范围内查询。

如果 Agent要创建、修改或提交业务单据，情况就不同了。写入动作可能触发审批、扣减库存、通知供应商，甚至影响财务结果。

所以，工具目录里不宜只标注“可调用”或“不可调用”。还要区分读取、草稿、更新、提交和高风险操作。

二、人工确认不是多余的一步

假设销售说：“帮我给客户发一封延期说明。”

Agent可以先读取客户和合同信息，生成邮件草稿，列出事实来源和建议内容。真正发送前，员工可以核对收件人、金额、日期和承诺事项。

这一步看起来降低了自动化程度，实际是在保护业务判断。尤其是对外发送、提交审批、变更主数据、修改合同和触发财务动作，人工确认往往比追求全自动更稳妥。

三、权限要跟着人、岗位和数据走

Agent代员工执行，并不意味着它可以使用一个全能账号。它需要在用户身份、组织范围、岗位职责和数据权限内调用工具。

例如，区域销售可以查看自己负责的客户，管理者可以查看更大范围的经营数据；财务人员可以处理费用信息，但不代表所有业务 Agent都能访问财务数据。

权限关系要在平台和系统侧校验，不能只写在提示词里。提示词可以告诉 Agent应该怎么做，不能替代真正的权限控制。

四、审批流程仍然有自己的责任边界

有些企业流程本身就规定了审批人、审批条件和留痕要求。Agent可以帮助整理材料、生成申请、提醒待办，也可以在授权范围内发起流程，但不应绕过既有审批制度。

MCP调用流程服务时，需要把流程名称、申请人、审批条件和当前状态说清楚。用户看到的结果也要明确是“已提交”“待审批”还是“已完成”，不能把流程发起说成业务已经结束。

五、权限、审计和人工确认要一起设计

只做权限，可能知道谁能调用，却不知道具体做了什么；只做人工确认，可能每次都弹确认，却无法回看完整过程；只做日志，出了问题才能查，却没有在事前拦截风险。

得小帆的企业级智能体能力，包含角色与权限、工具和 MCP、业务流程、运行监控和操作审计。MCP平台负责把外部能力标准化接入，权限和治理能力负责限制调用边界。

写在最后

Agent可以代员工处理大量重复工作，但自动化的边界不能靠一句“相信模型”来决定。

一个更稳妥的判断方法是：读数据可以按权限自动完成，生成草稿可以让 Agent先做，改变业务状态的动作要看风险决定是否确认，关键流程仍然保留审批和审计。

企业真正需要的，是可控的执行速度。