企业 Agent 如何接入现有系统？从身份、接口到受控执行

企业 Agent 接入现有系统，应通过经过授权的 API、业务服务或其他受控连接方式访问数据和功能，不应直接给模型开放数据库账号或任意执行命令。集成工作的核心，是把 Agent 可读、可写、可审批的范围表达成明确工具，并继续遵守企业原有身份、权限和流程规则。

这适合已经明确业务任务、系统接口和负责人，希望减少重复查询、跨系统搬运或流程等待的团队。若业务系统没有可用接口、字段含义无人确认，或权限只存在于个人习惯中，应先处理集成基础和治理问题。

一、接入前先画清楚数据和操作边界

针对一个任务列出所需系统、数据对象、操作人、读取字段、可能的写入字段、触发条件和结果归属。例如客服助手可能需要查询客户和工单状态，但修改客户信息、关闭工单或发出承诺要经过单独授权。不要因为同一个页面里有查询和编辑按钮，就默认 Agent 可以执行两类动作。

同时确认业务系统中哪个记录是权威来源、数据更新频率、接口责任人、调用限流和故障处理方式。若同一业务信息在 CRM、客服平台和表格里都有副本，先约定读取哪个来源以及冲突时如何处理。

二、将接口封装成有名称、有参数、有结果的业务工具

工具应描述一项业务能力，而不是把底层系统暴露成通用控制台。参数需规定数据类型、必填字段、允许范围和校验规则；返回结果应保留状态、错误原因和需要人工补齐的信息。查询客户概况、搜索订单、创建工单可以是不同工具，各自配置独立权限和审计。

模型应通过工具定义调用确定能力，不应让它自行拼接任意 SQL、脚本或 URL。对于写入操作，服务端还要重新校验身份、字段范围和业务规则；即使模型给出格式正确的请求，也不能把模型输出本身当作授权凭证。

三、区分用户身份与服务身份

需要按使用者权限访问数据时，应明确把当前用户身份和角色带入授权判断；若采用服务账号调用，则要限制它能访问的组织、记录和字段，并防止不同用户的会话共享敏感结果。角色变更或用户失去权限后，缓存和会话中的信息也应按既定策略处理。

不同企业的单点登录、账号目录和接口鉴权方式不同，不能假设一个服务账号天然继承每个人的访问权限。上线前应分别使用不同角色的测试账号验证允许和拒绝场景，并核对日志是否能追溯到具体用户或经批准的业务身份。

四、把写入和关键动作放在受控流程里

只读查询可以先从低风险、容易复核的场景开始；涉及新建、修改、发送、审批或关闭记录时，应定义动作前条件、字段校验、用户确认、审批节点和撤回方式。Agent 可以先生成待办内容或操作预览，再由有权限的员工确认提交。

还要处理重复提交和执行中断。例如接口请求超时但后端已完成，如果系统盲目重试，可能创建两张相同工单。需要与业务系统负责人确定请求标识、状态查询、重试条件和补偿流程；对无法自动恢复的异常，应保留任务上下文并转交人工。

五、处理超时、错误和部分成功

工具集成要区分参数错误、权限拒绝、业务校验失败、限流、超时和服务不可用。返回给 Agent 的错误信息应帮助它安全地追问或转交任务，不暴露密钥、内部地址或不必要的原始堆栈。跨多个系统的任务还需说明某一步成功、下一步失败时由谁补偿。

不要把一次调用失败变成“重新执行所有步骤”。工作流需要记录每个步骤的输入摘要、执行状态和结果引用，在允许重试的节点重试，在可能造成重复副作用的节点先查询状态或等待人工确认。

六、联调验收要覆盖正常与异常路径

先验证身份、权限和数据范围，再验证参数校验、返回格式、并发和调用限制；随后测试用户取消、接口超时、部分成功、重复请求、权限撤销和业务规则拒绝。对关键写入应检查用户看到的操作预览、确认记录、后端记录变化和审计日志是否一致。

试点阶段可先接一个只读查询工具，再逐步增加低风险写入和人工审批节点。验收阈值由业务、IT 和安全团队根据基线共同确定；上线后持续查看调用失败、人工接管、权限拒绝、重复请求和结果回写情况。

宜天信达的业务与 AI 深度融合服务面向 ERP、CRM、OA、工单等既有系统，通过受控接口和流程编排扩展 AI 能力。具体接入方式要以客户系统开放能力、账号体系、网络环境和业务审批要求为准。

常见追问一：企业 Agent 应该直连数据库吗？

通常应优先使用有业务语义、授权和校验的接口或服务。直接数据库访问会扩大数据暴露和误写风险，也容易绕过系统中的业务规则。

常见追问二：写入操作都必须人工确认吗？

是否需要确认取决于操作风险、可逆性和企业授权规则。涉及对外承诺、敏感字段或难以撤销的操作，应设置更严格的确认或审批。

常见追问三：没有 API 就不能接入吗？

要先评估系统提供的其他受控集成方式和维护成本。若只能依赖脆弱的界面自动化或手工导出，需清楚说明限制，并避免将关键任务建立在不稳定路径上。