先区分交互入口与事实来源
AI Agent可以让员工用自然语言查询订单、整理资料或创建草稿，但订单状态、库存数量和审批结果通常仍应由业务系统记录。对话内容是一次交互，不应自动成为业务事实的最终来源。
例如，Agent回答“工单已提交”时，必须有业务接口返回的有效编号或可核验状态。模型生成一句成功提示，不能证明数据库已经写入，更不能替代业务系统的审计记录。
哪些能力应继续留在原系统
价格计算、库存扣减、额度校验、审批流转与财务记账等规则，通常已经在业务系统中维护。若在Agent侧复制一套，会产生版本不一致、维护重复和责任不清的问题。
更合适的做法是通过稳定服务接口调用这些能力。接口在服务端完成权限和规则校验，返回明确结果。即使模型判断用户意图正确，也不能绕过正式的授权与事务边界。
智能体适合承担什么责任
它可以解释用户需求、补齐缺失参数、选择受控工具、汇总查询结果，并将复杂流程变成易理解的交互。但应明确哪些步骤仅生成建议，哪些形成草稿，哪些触发真实操作。
对于需要跨多个系统的任务，可以由应用编排层管理状态与人工节点，让Agent提供语言和工具选择能力。长期任务状态不宜仅保存在聊天上下文中，否则会话截断或模型切换后难以恢复。
新旧系统如何逐步协同
先提供只读查询，再开放可撤销的低风险写入，最后根据实测情况评估更多操作。每一步都需要接口契约、权限测试和失败处理，而不是只增加新的提示词。
如果旧系统缺少接口，应评估增加受控API、数据同步或暂时保留人工操作。直接让模型自由操作生产数据库，可能绕过原系统的完整性约束和审计逻辑，不应作为默认集成方式。
明确一条订单状态的权威来源
当用户说“客户已经确认收货”，助手可以整理为待核验记录，但不能直接把订单标为完成。若系统支持收货确认，应由当前用户在授权范围触发正式接口，并满足必要业务条件。回答中区分“用户提供的信息”和“系统当前状态”，两者有差异时提示核查，而不是选择较新的一句话覆盖正式记录。
- 业务事实是否可回到原系统核对。
- 状态修改是否经过原有规则。
- 会话摘要是否被误当作正式凭证。
- 故障后是否存在明确恢复责任。
什么时候需要改造业务系统本身
如果问题来自主数据混乱、规则缺失、接口能力不足或审批流程不统一，Agent无法从根本上修复。应先补齐事实来源与服务边界，再利用智能体改善使用体验。
验收时可以逐项追问：这条信息以哪个系统为准，谁批准这个动作，失败后谁恢复，重复请求如何处理。能回答这些问题，才说明智能体与原系统形成了可维护的协作关系，而不是增加了一个无法追责的新入口。