智能体项目的预算表上，平台的采购与订阅费用通常写得清清楚楚。真正把项目拖出预算的，往往是另外几类支出：历史数据的清洗与标注、遗留系统的接口改造、业务流程的重新切分，以及上线后持续投入的权限维护与审计合规。这些钱不是没花，只是立项时没有被单独列出来，于是也没人跟踪它。
隐性成本之所以难量化，关键问题是“没有名字”，而非“不可知”。它有三个特征：发生位置分散，散落在数据、IT、业务和法务多个部门；显现时间滞后，多数在试点转向生产时才集中暴露；核算方式混杂，容易被当成一次性项目投入，忽略其持续性。三者叠加，最终就只能看到一句“总投入超预期”，却无法据此判断问题出在哪个环节。
要把它拉回可管理的范围，第一步是换核算方式：放弃只算总投入，改为按成本科目归集。数据侧是清洗、脱敏、分级标记与知识库整理的人工投入；集成侧是 ERP、CRM、ITSM 等系统的接口开发、联调与异常处理机制维护；组织侧是流程重设计、岗位职责调整与培训推广；运行侧则是审计日志留存、基于角色的访问控制维护、模型路由与降级策略调优，以及持续的 Token 消耗。把这些科目列齐，隐性成本才会从模糊感受变成可以逐项打勾的清单。
第二步是分阶段设基准。概念验证、试点运行、横向扩展三个阶段各自记录预算与实际支出，偏差本身就是信息：如果数据科目反复超支，说明问题在数据资产质量，而不在模型能力；如果集成科目超支，则要重新评估非侵入式对接的可行性。业内常被引用的一个量级是，数据准备、流程适配与变革管理这类支出可占到总投入的四成到六成，但这类比例只适合用作心理预期，不适合直接写进预算，因为企业间的数据基础和流程复杂度差异极大。
第三步是把成本分摊到业务线。平台若具备调用级计量与成本分摊能力，就可以按场景核算单位产出成本，避免所有开销沉淀在一个无法归属的技术中台账户里。成本侧算清楚之后，效益侧必须同口径对齐：工单自主解决率、跨系统人工录入时长、流程周期是可测的直接指标，续约率与协同效率属于间接价值，可以定性记录，但不应在没有基线的情况下折算成金额。
量化的真正目的不是精确到个位，而是让偏差可见。当某个科目连续超出基准，团队就能判断该修的是数据、是流程，还是选型本身，而不是等到项目结项才发现总账对不上。