Agent 接 CRM、ERP 或旧系统前，要准备哪些接口与授权？

Agent 接 CRM、ERP 或工单系统前，应把目标对象、允许字段、读写动作、调用身份、授权依据与业务回执逐项确认，再在允许的测试环境联调。能看到接口文档，不等于已有接入权限；请求返回成功，也不等于目标业务已正确完成。没有 API 时，可以比较获授权的文件交换、中间服务或受控界面操作，但必须另外验收更新、重复、失败与维护。

这篇文章适合已经选定业务任务、准备连接实际系统的团队。这里的交付是接口与授权清单、联调结果和异常处置；是否值得建设，应在前期决策中先明确，不能把没有验证的连接条件写成既成事实。

先把“接 CRM”改写成具体对象和动作

“接 CRM”可能只是读取分配给当前销售的客户名称，也可能包含创建跟进、修改状态、合并客户或外发邮件。范围差别决定身份、字段与失败后果。逐项写明业务标识和结束状态，避免以一个系统名称包住不断扩张的动作。

业务、IT 与系统供应商分别交什么

材料要区分官方文档、供应商书面确认和实际联调结果。某个接口只对特定套餐、环境或账号开放时，应把这些条件列为依赖。跨部门或跨供应商协作的费用、时间与责任，也不能默认包含在原系统合同里。

凭据由合适的系统机制管理，不写进模型提示、公开文档或普通业务日志。模型提出某个工具动作，应经过执行层对身份、对象和字段的检查；不能把“模型认为有权”当作授权。

Microsoft 的 AI 应用设计将知识层与业务工具层分开，并要求工具执行自身安全策略、传递用户上下文。这里只借鉴分层原则，不表示已接入某个 CRM 或采用 Azure 就自动满足目标系统要求。参阅：AI 应用的工具、身份与边界设计。

先只读还是允许写入，由目标与后果决定

如果先验证依据查询或建议质量，只读范围通常已经能取得部分证据，可先把身份、字段和对象范围核对清楚。若价值本来就依赖写入或流程推进，不能用只读演示代替写入验收；应把新增、修改、删除、提交和外发拆开批准。

写入前至少确认：目标记录怎样定位，是否有并发版本变化，哪些字段不得更改，同一动作重复提交怎样识别，系统返回什么才算受理、什么才算完成，以及结果未知时如何查询。人工审批还要对应实际执行的内容；审批后参数改变不能继续沿用原批准。

没有 API 的旧系统，按替代路径分别验收

界面路径不能只按坐标点一次成功就验收。应证明每一步能辨认目标对象、关键字段和结束状态；页面或登录状态偏离时停止并交给人。无法可靠确认是否已提交的高影响动作，不宜靠再点一次消除疑问。对文件路径，也要承认快照与实时系统不同，不能继续承诺同样的时效。

公开的Data Index Engine 工程说明当前已核验支持 CSV、XLS、XLSX 文件的一类治理路径，不证明任意旧系统的界面自动化或实时连接已交付。另一个AI Sales Agent 工程说明仍有 Mock 集成边界，真实 CRM、正式邮箱与生产 RAG 需要另行实施；讨论连接方式时应分别核对。

联调覆盖正常、拒绝、超时与版本变化

每条记录关联环境、接口/规则版本、测试身份、目标业务标识、输入摘要、预期、实际回执和目标状态。测试材料在授权范围内保存，不能把密钥和完整令牌留在截图或日志。演练后还要核对测试产生的记录，确认清理或保留方式，防止它们混入真实业务。

接通以后，交付还包括谁处理下一次断开

移交时说明运行账号和授权到期、字段或接口变更通知、故障联系人、停止与恢复条件、日志取得方式及未覆盖范围。只有成功演示，没有拒绝、部分失败和超时回执，尚不足以说明连接可以长期承担业务。

超时与部分执行的细节，可继续看Agent 怎样重试、续跑并避免重复执行；不同岗位的查询与动作边界，可看权限隔离和撤权验收。需要连接实际系统时，可以按企业 Agent 与 AI 项目落地范围确认目标任务、授权与联调证据。