智能体项目不能用“回答得像不像人”来验证ROI，而应回答一个更严格的问题：在真实业务流程中，它是否以可审计、可复现的方式创造了超过全生命周期成本的增量价值。ROI验证的对象不是模型能力，而是业务结果。
先定义收益，再选择场景
企业应优先选择高频、规则相对清晰、容错可控的场景，例如智能客服、企业知识库问答、数据报表自动化和流程审批辅助。这类场景通常更容易建立上线前基线，包括人工处理时长、处理量、错误或返工情况、服务质量和资源投入。没有基线，项目上线后的“变快了”“省人了”都只能算印象，不能算证据。
收益也不能只看节省了多少人工时间。应区分三类结果：直接降本，如减少重复操作；效率增益，如缩短处理周期、提高单位时间处理量；质量与风险改善，如减少遗漏、增强审计留痕。只有真正被业务流程吸收的收益，才能纳入ROI，而不是把智能体生成过内容、调用过工具都当成价值。
用POC验证增量，而不是展示功能
POC的核心不是演示智能体能否完成一次任务，而是与原有流程进行可比验证。测试数据应尽量接近企业真实环境，并明确任务边界、人工介入条件、失败处理和回滚机制。尤其要记录智能体独立完成、需要人工复核以及最终失败的任务比例，避免只展示成功案例。
成本核算也要完整覆盖：模型与算力使用、系统集成、数据治理、权限和审计设计、人工复核、持续运营及迭代维护。智能体不是交付即结束的软件，若忽略上线后的运营成本，初期看似可观的收益可能无法转化为真实回报。
建立可审计的决策门槛
企业可以把ROI判断拆成三道门：第一道看业务价值是否达到预设目标；第二道看结果是否稳定，能否在不同数据和人员操作下复现；第三道看安全、权限、合规和人工兜底是否可接受。只有同时通过，才适合扩大自主执行范围。
更稳妥的路径是“先人审机做，再机做人审”：先让智能体承担辅助工作，持续记录结果与偏差，再逐步放权。最终，企业应以完整周期的净收益、风险成本和组织采纳度做决策，而不是以一次成功Demo或首期报价判断项目成败。