业务人员请 AI 整理客户续约资料，看起来只是一句简单指令。背后却可能读取 CRM、查阅合同，再创建报价草稿。如果每一步都使用同一组管理员账号，系统虽然知道“有程序来过”，却很难回答：这次是替哪位同事办事？客户资料原本是否在他的权限内？他调岗后，尚未完成的任务还能继续吗？
近期信号：代理也需要自己的身份
HashiCorp 在 2026 年 9 月 1 日宣布 Vault Enterprise 的代理身份管理能力正式推出；Oracle 9 月 10 日介绍的 Integration MCP Gateway，则将身份与策略控制列为 26.10 版本规划的一部分。两则公告反映出相近方向：企业开始把代理接入既有权限制度。以下是米亚科技的集成设计建议，并非所有平台都已具备的功能清单。
先分清楚三个角色
发起工作的人、执行工作的代理，以及真正访问 ERP 或 CRM 的系统账号，可能是三个不同角色。不能因为代理能登录，就推定它能代替任何人操作。每次执行都应关联发起者与任务；无人值守的计划任务，则要有明确的服务身份、负责人和适用范围，不宜借用某位员工的永久登录状态。
授权要跟着任务走
一个实用起点，是把授权写成具体范围：替哪个部门、处理哪些客户、可以读取哪些字段、能创建草稿还是能正式提交，以及何时到期。后端应取用户权限、代理权限与本次任务范围的交集。把“只处理这个客户”写在提示词中有助于理解，但真正的限制仍须由查询与写入接口执行。
用续约准备看懂差别
假设设备服务商请代理准备甲客户的续约资料，这是示意情境，不是米亚科技已交付的案例。代理可读取该客户合同与授权范围内的设备记录，依既有计价程序取得金额，再整理续约草稿。它不因此获得乙客户资料，也不能自行变更折扣或发出承诺。主管批准时，应看到实际草稿、对象与金额；若批准后内容改变，就需重新检查，而不是沿用一个笼统的“同意”。
能给权限，也要能收回
人员离职、案件取消或批准过期时，正在排队的代理工作也需要停止。短期凭证可缩短暴露时间，却不等于立即撤权：系统仍应在重要操作前重新检查授权，并处理已排程工作、缓存与下游连接。若资料已发出或正式写入，撤权不会自动还原结果，必须另有取消、补正或人工处理流程。
让记录说得出前因后果
日志至少要串起任务编号、发起者、代理身份、使用工具、授权范围、批准版本与执行结果。凭证与密码不应进入模型对话或普通日志。这些记录的价值不只是事后追责，也能让客服或主管知道工作停在哪一步、由谁接手，避免只看到一段“执行失败”。
第一个验收，不妨测试它何时不能做
先挑一条查询加草稿流程，测试跨客户查询、权限撤销、批准后改价与排程途中停用账号。检查是否真的阻止操作、是否留下原因，以及人工能否接手。除了草稿准备时间，也记录错误授权拦截与撤权生效时间，才能看出便利背后是否仍保有控制。
米亚科技的观点：把委托关系接完整
企业引入代理时，网站、APP、知识库与 ERP 的连接数只是起点。更值得先做好的，是让每个动作都能回答“谁委托、做到哪里、何时失效”。从一条可验证的授权链开始，企业才能逐步扩大 AI 的工作范围，同时保留原有管理制度的判断与责任。