企业智能体落地最常见的误判，是把“能对话”当成“能干活”。一个智能体可以流畅地解释采购流程，却不代表它有权读取审批状态、核对供应商信息，更不代表它能把结果写回财务系统。旧系统恰恰是这条链路上最容易断裂的一环。
旧系统难接，难在接口缺失只是表象。真正的阻力来自三个层面：身份、动作与可追溯性。智能体以什么身份登录、能访问哪些数据、执行写操作时是否需要人工确认，这些问题在传统系统设计里从未被考虑过。许多旧系统只面向真人操作，权限模型粗放，登录状态易失效，一旦由程序驱动，页面结构变动或会话中断都会让任务停在中途。界面自动化看似绕开了接口限制，代价却是持续的维护成本。
更深一层的问题在于，跨系统任务天然具有事务性。一笔采购申请涉及读取、核对、写入多个环节，任何一个环节失败，都需要明确的回退与异常处理机制。智能体若缺少这种编排能力，所谓“完成任务”就退化为一次性演示。企业在评估时，应当把接入条件拆成三类来问：新系统是否有稳定接口；旧系统能否通过既有集成方式或界面路径完成操作；涉及数据写入、审批、支付的动作是否设置了确认与兜底。这三类条件的分野，比功能清单更能反映真实可行性。
接入之后是复用。一次性任务往往依赖临时提示和个人账号，换一个部门就跑不通。要让能力沉淀下来，业务目标、输入数据、执行步骤、判断规则和预期结果都必须被显式定义并可验证。以发票核对为例，除了识别票面内容，还要明确与哪些订单或合同字段比对、差异达到什么条件转人工、结果保存到哪里。流程或模型一旦变更，还需重新测试，否则旧规则失效却无人察觉。采购方由此可以重点考察流程配置、模板复用、版本管理与测试能力，而非只看单点效果。
当智能体数量增长，管理对象就从人扩展到“智能体可访问的数据、可调用的工具、可执行的动作”。权限配置过宽，会让一个本应只做查询的智能体获得修改能力；缺少日志，则事后无从排查。企业至少要明确谁可以创建、发布和使用智能体，智能体以何种身份访问系统，高风险操作是否具备确认与回退机制，任务发起人、执行时间、关键调用与异常是否留有记录，以及配置变更、权限回收和停用流程由谁负责。
回到现实判断：关于具体平台的能力边界，现有公开信息往往不足以支撑结论。更稳妥的路径是先取得可核验的产品文档与部署说明，再由业务与 IT 共同选取一项规则清晰、风险可控的任务做试点，分别验证系统接入、流程复用与权限审计，并如实记录异常处理与人工接管的工作量。企业智能体的价值，最终不取决于演示时有多顺畅，而取决于它能否在既有业务环境中稳定承担被授权的任务。