先区分读取信息与改变业务
查询订单状态、汇总某周工单、生成一份报告草稿，通常只是帮助用户理解现有信息。修改收货地址、取消订单或发送正式通知，则会改变业务结果。接入 Agent 时可以先按这两类任务整理接口清单，并明确每个工具允许的角色、输入参数和返回范围。不要把一个拥有全部后台权限的账号直接作为所有人的公共助手身份。
确认页面展示即将发生的动作
需要用户确认时，页面应说明操作对象、原值、新值以及可能影响的关联事项。例如批量调整预约，不能只弹出“是否继续”，而应列出日期、资源、受影响记录数与通知方式。用户确认的应当是这组具体参数；如果 Agent 随后改变了对象或内容，就需要重新确认，不能拿第一次确认去覆盖一个不同的操作。
重复请求不能产生重复结果
对话重试、网络超时和用户重复点击，都可能让同一工具调用多次到达业务服务。需要为有副作用的操作设置请求标识，并在业务端核对是否已经完成。用户看到超时提示时，界面应允许查询执行结果，而不是直接再次提交。对于批量操作，还应区分全部失败和部分成功，让后续重试只处理尚未完成的记录。
让异常可以交给工作人员处理
接口可能返回权限不足、数据已变化或依赖服务暂时不可用。Agent 应保留清楚的失败说明，并提供查看原始记录或转人工处理的路径。记录执行人、工具名称、关键参数与结果，有助于排查问题；日志中不需要保存完整密码或其他秘密。业务侧也应有停止任务、撤销允许撤销的操作以及人工接管的入口。
从一个小范围的工作流开始
第一版可以先做工单查询和回复草稿，验证权限、上下文与输出质量，再逐步接入受控写入。验收时除了正常成功，还要测试重复提交、确认后数据变化、越权请求和处理中断。每新增一种工具，都需要重新明确其权限和确认边界。这样开发团队能逐项积累可信的操作能力，而不是仅凭对话看起来顺畅就开放全部业务功能。