四项成本分开算
一、多模型接入与稳定性
接入几个模型的 API 不难，难的是渠道故障切换、重试策略、不同厂商计费单位的换算，以及新模型上线后的适配。这一项是一次性开发加持续小修。
真正上线后，调用入口还要面对版本变更、限流、超时和返回格式差异。研发通常先把正常路径跑通，业务开始依赖之后才发现：同一个任务切换模型会不会改变结果，失败后能不能安全重试，旧版接口停用前由谁完成迁移。采购产品时这些工作包含在服务中；自建时，它们会持续占用平台团队的排期。
二、权限与审计
这一项的工作量通常被低估。要做的是执行身份、按项目和动作收敛的权限、敏感动作的执行前确认、凭据托管、日志脱敏和保留期限。写出来是几行需求，做成能过审计的系统是另一回事。
比如一个 Agent 可以读取项目文档，但不能因此获得全部共享盘权限；它可以生成代码修改，却不能直接合并到生产分支。管理员还要区分是谁发起、哪项任务获得授权、批准了什么动作，以及项目结束后哪些权限已经收回。这不是在后台加几个角色选项，而是一套要和现有身份、审批及日志系统长期配合的规则。
三、用量归集与对账
把每次调用关联到人、项目、模型和任务，设置分层额度与预警，再和月度账单对上。口径一旦定错，后面每个月都要手工修。
供应商账单只能说明某个账号用了多少资源，业务负责人关心的是哪项工作产生了这笔费用、结果有没有通过验收。自建系统需要把模型、检索、执行环境和外部工具的消耗放回任务里，再处理退款、重试和跨月结算。没有统一口径，财务看到的是总额，项目经理看到的是另一套数字。
四、长期跟进
模型、Agent、CLI 工具和它们的接口每个月都在变。自建意味着这些变化由你的团队跟。没有固定的人负责，系统会停在某个版本，然后慢慢没人用。
所以评估时不要只问首版需要几个人月，还要问上线一年后谁接告警、谁处理安全更新、谁验证新版本没有破坏现有任务。把这些工作列进年度预算，再和采购费比较，结果通常比“自己做一个后台要多少钱”更接近真实成本。
什么情况下自建成立
- 已有平台团队，并且能长期分出人力负责上面第二到第四项；
- 权限或合规要求特殊到现成产品确实满足不了，并且这个判断是逐条核对过的，不是印象；
- AI 能力本身是你们的产品一部分，控制权必须在自己手里。
这三个条件里，最重要的是“长期有人负责”。特殊需求可以通过开发解决，持续维护却不能靠项目上线前临时抽调。决定自建前，可以要求负责人列出未来十二个月的维护清单、值班方式和替补人员；如果这张表写不出来，自建方案还没有进入可执行阶段。
什么情况下采购更划算
- 目标是让业务团队尽快用上 AI，不是建一套内部基础设施；
- 最急的是权限、审计和对账，而不是模型路由；
- 没有人能长期维护，自建会变成「上线即遗留系统」；
- 需要私有化部署——这不等于必须自建，采购同样可以部署在你们自己的环境里。
采购也不是把管理责任交给供应商。企业仍要确认数据边界、接入范围和验收标准，只是把通用平台能力的研发与升级交给专门团队。选型时应让候选产品跑同一项真实任务，检查权限、失败记录、对账和交接，而不是只看演示里的功能数量。
中间路线
常见的做法是：模型路由自建或沿用已有网关，项目、权限、审批、交接和执行记录用现成平台。已有的模型、知识库和代码助手都保留，接入之后由平台统一管理。
也可以反过来保留企业已经做好的身份、审批或日志系统，只采购缺少的工作区和执行管理能力。关键是先定清接口边界：哪一层负责模型请求，哪一层保存任务记录，故障时由谁告警。边界越清楚，后续替换其中一块的成本越低。
先用一项真实任务把成本算清楚，方法见企业 AI 试点的四步清单。
常见问题
自建成本到底高在哪？
高在权限与审计、用量对账和长期跟进这三项持续投入上，不在一开始接 API 的那几周。模型和 Agent 的接口每个月都在变，没有固定人力跟进，系统很快停在旧版本。
要求数据不出域，是不是只能自建？
不是。私有化部署和自建是两件事，采购来的平台同样可以部署在你们自己的环境里，由你们决定数据边界。
已经自建了一部分，还能接入吗？
可以。常见做法是模型路由沿用已有的网关或自建部分，项目、权限、审批、交接和执行记录用现成平台，接入范围在试点中逐项确认。
怎么判断我们这边属于哪一类？
看有没有人能长期负责权限审计、对账口径和模型跟进这三件事。有，并且需求确实特殊，自建成立；没有，自建通常会变成上线即遗留的系统。