企业开始尝试 AI Agent 后，很快会遇到一个现实问题：聊天框里的答案没有太大风险，但一旦 Agent 要查询客户资料、创建工单、修改订单、读取库存、生成审批或调用内部接口，风险就会进入后端系统。对老系统较多的企业来说，难点不是让模型会说话，而是让它在可授权、可审计、可回滚的范围内执行动作。
不要让 Agent 直接连接数据库
很多企业内部系统年代较久，接口文档不完整，数据库表结构直接承载了大量业务规则。为了快速验证效果，有些团队会让 Agent 通过脚本或查询工具直接读写数据库，这种做法短期看起来方便，长期风险很高。数据库字段含义、状态流转、并发控制、权限过滤和数据脱敏都可能被绕开，一旦写入错误，很难判断责任来源。
更稳妥的方式是建设后端工具网关。Agent 只能调用被封装好的工具，每个工具对应一个明确动作，例如查询客户摘要、创建待确认工单、生成报价草稿、读取设备告警列表、检索合同条款。工具内部再去调用老系统接口或数据库视图，并且统一做参数校验、权限检查、日志记录和异常处理。
工具颗粒度要小，动作语义要明确
Agent 工具不是传统后台接口的简单暴露。传统接口可能为了页面方便，把查询、修改、状态变更和关联数据一起返回；而 Agent 工具应该更接近业务动作。动作越清楚，越容易控制权限和审计。比如“查询客户最近工单”比“客户管理接口”更安全，“生成采购建议草稿”比“提交采购单”更适合第一阶段上线。
优易云在设计这类后端能力时，会把工具分成只读、草稿、待确认执行和自动执行四类。只读工具可以覆盖知识检索和信息查询；草稿工具负责生成内容但不改变业务状态；待确认执行工具需要人工确认后写入系统；自动执行工具只用于低风险、高频、可回滚的场景。这样的分层能让业务部门理解每个 Agent 能做什么，也能让技术团队控制上线边界。
权限网关要绑定真实用户身份
Agent 不能拥有一个无限权限的系统账号。它执行任何动作，都应该绑定当前用户、角色、部门、数据范围和业务场景。用户自己没有权限看的客户、合同、成本和审批记录，Agent 也不能替他读取。用户不能直接执行的操作，Agent 也不能绕过流程完成。
后端权限网关要完成两层校验：第一层校验用户是否有权限调用某个工具；第二层校验工具参数对应的数据范围是否属于该用户。例如销售人员可以查询自己负责客户的工单，但不能查询全部客户；项目经理可以生成项目周报，但不能修改财务付款状态。权限判断不应该写在提示词里，而应该写在后端服务里。
审批确认要成为产品流程的一部分
只要 Agent 的动作会改变业务数据，就要考虑确认流程。确认不是简单弹一个“是否继续”，而是把即将执行的动作、影响对象、关键参数、依据来源和风险提示展示给人。确认记录也应该写入日志，说明是谁确认、确认了什么、最终执行结果如何。
对于老系统改造，优易云更建议先让 Agent 生成草稿和建议，再由业务人员确认后写入系统。比如售后场景中，Agent 可以根据历史工单生成处理建议和客户回复草稿，但关闭工单、退款、换货和升级投诉仍然需要负责人确认。这样既能提升效率，又不会把关键责任交给黑盒。
审计日志要能还原完整链路
企业级 AI 应用上线后，审计日志不是附加项，而是基础能力。一次 Agent 动作至少要记录用户身份、会话编号、调用工具、输入参数摘要、引用资料、模型输出、人工确认状态、接口返回结果、错误信息和耗时。对敏感数据要记录脱敏摘要，避免日志本身成为泄露源。
日志还要能被业务人员看懂。只记录一串技术参数，对排障有帮助，但对管理者说明不了责任。更好的方式是同时保留技术日志和业务事件日志：技术日志用于工程排障，业务事件日志用于审计、复盘和客户沟通。这样出现错误时，可以快速判断是资料来源错误、模型判断错误、权限配置错误，还是老系统接口返回异常。
异常回滚要提前设计
老系统通常没有完整的事务边界，Agent 一旦跨多个系统执行动作，更要提前设计失败处理。一个流程可能先创建工单，再写入客户备注，再通知负责人，再更新看板。中途失败时，哪些动作需要回滚，哪些动作只能追加修正记录，哪些动作需要人工介入，都要在方案阶段明确。
对于不能回滚的业务动作，建议采用待确认和补偿机制。先创建待处理记录，不直接改变最终状态；执行失败时进入异常队列，由人工确认后处理。对外部系统调用，也要设置幂等键，避免重复提交。后端服务要比提示词更可靠，所有关键动作都应通过程序规则兜底。
结论
AI Agent 接入老系统，核心是后端治理问题。模型负责理解和生成，后端负责授权、封装、确认、执行、审计和回滚。企业不应该追求一开始就让 Agent 自动处理所有业务，而是从只读查询、草稿生成和待确认执行开始，逐步扩大范围。优易云可以协助企业梳理老系统接口、建设工具网关、改造权限体系、设计审计链路，并把 AI 能力稳定接入已有业务流程。
