优先通过已有业务 API 接入，把每个接口封装为受控工具，保留参数校验、权限、状态和人工确认。系统没有 API 时，应先评估接口改造成本，而不是直接给模型数据库写入权限。
先选一个可以闭环的任务
例如工单分类、资料查询或报价信息整理。写清任务输入、数据来源、输出内容、成功条件，以及遇到异常时由谁接管。不要在第一阶段把所有部门和系统都接入。
区分可以用确定性规则处理的步骤、确实需要模型判断的步骤，以及必须由人确认的动作。是否使用多智能体，应由分工价值决定，而非默认增加复杂度。
为工具调用建立约束
为接口定义输入输出结构、最小权限、超时、重试、幂等和审计日志。查询工具默认只读，返回数据应遵守原系统的人员权限，不能因为换成聊天入口就绕过鉴权。
支付、删除、发布和重要审批等动作应设置明确的人工确认节点。模型提出的参数必须再次由服务端校验，不能把自然语言承诺当成已执行结果。
联调时验证失败路径
测试接口超时、重复提交、权限不足、数据缺失、任务中断和人工驳回。每一步应能查看当前状态，并明确哪些操作已完成、哪些未完成。
交付应包括约定工作流、工具接口说明、测试记录、部署配置和人工接管方式。对接效果依赖业务接口质量和任务边界，不宜预先承诺全部流程自动化。