企业验证智能体能否安全完成跨系统任务，不能只看它是否“接入了浏览器、数据库或 API”。工具接入只能证明存在连接能力，不能证明智能体能够正确理解目标、选择工具、传递参数，并在异常发生后交付可复核的业务结果。真正的验证对象，应是一个完整、可审计、可接管的任务闭环。
先定义“完成”，再设计测试
一次跨系统任务至少应拆解为目标理解、任务规划、工具调用、结果校验、结果交付和人工接管六个环节。企业要先明确业务验收标准：哪些步骤允许智能体独立执行，哪些动作必须人工确认，什么结果才算任务完成。
测试不应只使用供应商准备的理想流程，还要加入权限不足、数据缺失、接口超时、返回格式变化、身份认证失效和系统数据不一致等情况。尤其要区分“调用成功”和“业务成功”：接口返回结果，不代表库存、报价、审批或回写已经符合业务规则。
重点检查三个安全边界
第一是权限边界。智能体应使用完成任务所需的最小权限，并区分查询、修改、删除和提交权限。涉及客户信息、合同、资金或生产系统的操作，应具备字段限制、二次确认和人工接管机制。权限不能只依赖提示词约束，而要落实到工具、数据和操作层。
第二是过程边界。企业应检查智能体能否保存关键参数，识别空值和重复值，避免重复提交，并记录每次调用的时间、工具、参数、结果及人工介入。只展示最终输出，无法证明中间步骤没有发生错误。
第三是失败边界。出现异常时，系统应停止高风险动作，保留现场信息，说明失败节点和待补充内容，而不是反复尝试或自行猜测。能够在不确定时暂停，往往比生成一个看似完整但未经验证的结果更安全。
把验证写入验收条款
企业可要求供应商将能力标注为“已支持”“需配置”“需定制”或“尚在验证”，并分别记录测试条件、样本范围和失败情况。对于 API，要核验重复调用和回滚机制；对于数据库，要明确写入权限和审批要求；对于浏览器自动化，要测试页面变化和登录失效。
最终判断不应是“智能体调用了多少工具”，而应回答三个问题：它是否完成了约定的业务结果？失败时能否及时止损并留下证据？长期运行的维护、复核和责任成本是否可控？只有这三点明确，跨系统智能体才具备进入真实企业流程的基础。