改造：接口缺口
自带连接器通常只覆盖标准系统，自建系统与老旧接口需要写适配层，工作量最容易被低估。怎么估：把要接的系统按接口形态分类，逐个确认字段、鉴权与限流，再乘以往返调试次数。接口无人维护的系统，改造费常超过平台年费。
放大：重试反思
Agent 失败会重试、反思、再规划，单次任务的实际调用量可能是演示时的数倍。为什么重要：预算按演示估算，上线后很快超支。做法是给每次任务设调用上限与超时，按周统计单任务平均调用次数，并对异常放大设告警。
值班：日志与响应
生产环境要追踪每次任务的输入、工具调用与输出，日志存储与检索本身有成本。谁来看、多久看一次、异常怎么升级，都要有人负责。边界在于没有值班安排的系统，故障只能等业务反馈，恢复时间不可控。
锁定：升级与迁移
平台升级可能改变节点行为，流程要重新回归；换平台时，流程、提示词与工具配置能否导出决定迁移代价。怎么降低：采购阶段约定导出格式与版本兼容策略，把关键流程在自己的代码仓库留一份可运行的等价实现。
适用与不适用
适合谁
- 已上线一个 Agent 场景、准备扩面的中大型企业
- 需要向财务解释第二年预算的项目负责人
不适合谁
- 只做一次性演示、不打算长期运行的项目
- 尚无真实任务样本、无法计量调用量的团队
典型场景
某集团财务共享中心上线报销单据初审 Agent。运行两个月后发现，重试与人工复核回退使调用量高于预估，日志检索与值班也占用 IT 人力；财务负责人与 IT 运维一起把六类成本逐项记账，才把第二年预算做平，并把结论写进续约评估。
可执行步骤
- 把要接的系统按接口形态分类，逐个确认字段、鉴权、限流与责任人，列入改造清单
- 用真实任务连跑一周，统计单任务平均调用次数、重试比例与超时占比，形成基线
- 确认日志留存期限、检索方式，以及异常由谁在多长时间内处理并升级到哪个层级
- 要求供应商演示配置导出与版本兼容说明，并在内部仓库留一份等价实现
常见坑
- 按演示用量做预算，忽略重试与人工回退带来的调用放大，上线两个月就被迫追加预算，采购流程要重走一遍。
- 只买许可、不安排值班与告警，故障靠业务群反馈，恢复时间取决于谁先看到消息，责任也难以界定，整改也会滞后。
- 平台升级不做回归，节点行为变化后流程悄悄失效，等业务发现时已错处理几批单据，只能人工逐单追溯。
自检与验收清单
- 六类成本是否各有负责人、估算依据与复核人签字
- 单任务调用上限、超时与告警阈值是否已配置并演练
- 日志留存期限、检索权限与导出方式是否明确可查
- 配置导出能力与版本兼容策略是否有书面承诺，由业务方确认
常见问题
平台报价很低，是不是就划算？
要看三年口径。许可低但连接器要定制、日志要自建、升级要回归，合计往往超过报价本身。做法是把六类成本列成同一张表，让供应商与内部运维分别填写，再比较合计与不确定性。
调用量怎么估才不离谱？
先用真实任务跑一周，记录单任务平均调用次数与重试比例，再乘上预计任务量。演示环境数据干净、重试少，直接按演示估算通常偏低，建议留出余量并设月度告警阈值，避免预算再次失真。
升级能不能不做回归？
不建议。节点行为、工具协议与模型版本都可能变化，回归范围至少覆盖主路径与前三个高频异常。若平台不提供变更说明，应要求其提前告知版本差异，否则视为运维风险，交接时也说不清。