ai agent 和传统软件有什么多少钱：钱主要不在模型那一栏

很多人第一次给 Agent 项目做预算，是拿传统软件的报价单照抄一遍，再在后面加一栏「模型调用费」。跑起来才发现超支的地方根本不在那一栏。这篇不报具体数字，只讲成本由哪几块构成、哪些会随用量涨、哪些是一次性沉没，以及到站内哪些页面去取当期的数字。

第一次给 Agent 项目做预算的人，很容易犯一个动作上的错：把传统软件的报价单找出来，照着原来的栏目誊一遍，末尾自己加一行「模型调用费」，觉得这样就齐了。真跑起来才发现，超支的那一栏根本不在模型上。不是模型不花钱，是它只占账单里显眼的那一小块，剩下那些不显眼的地方才慢慢把预算吃掉。

这篇不讲具体数字，也不替谁算账。只把两类系统的成本拆成可判断的几块，告诉你拿到一份报价该先问什么、估算按什么顺序走、算到哪一步就该停下来别签长约。当期单价一律去站内页面取，别用记忆里的旧数。

先把「多少钱」问对：一次性钱、按月钱、按次钱

传统软件的钱大头压在许可、实施、运维人力这三块，买断也好年付也好，本质是固定周期支出。你今天一百个人用，明天两百个人用，只要没加席位，账单基本不动。Agent 反过来，固定部分很薄，真正的大头是推理调用，请求量、上下文长度、重试次数任何一个翻倍，账就跟着翻。

所以这两类成本不能直接比总和。先问清对方报的口径：是首年、是单次、还是满负荷跑一年。混在一起报的报价，先别急着横向比，比了也是错的。

• 拿到报价先让对方把每一行标上「一次性 / 固定周期 / 按量」三类之一，标不出来的先放一边
• 传统软件重点问实施人天和后续升级测试算不算在里面，很多报价只给许可价
• Agent 项目重点问调用费是按什么口径估的，有没有把重试和工具多轮算进去
• 两边都要问清楚续费怎么涨、涨之前有没有提前告知，这一条比首年价格更影响长期账

单次请求的钱花在哪：输入、输出、重试、工具回环

很多人以为一次 Agent 请求就是调一次模型。实际用下来，一次用户提问背后常常是好几次模型调用：先判断意图，再检索，再把检索结果和历史对话一起塞进去生成，中间可能还要调工具、看返回、再生成。每一轮都要重新带上上下文，输入部分就重复计费了。

输出通常比输入贵，这是常见口径，所以长回答、长代码、大段 JSON 都会明显推高单次成本。更隐蔽的是失败重试和工具调用的多轮回环，日志里能数出次数，账单上只有一个总数。

拿自己场景的实际对话去算，别套别人的平均值。站内有 模型成本计算器（/tools/model-cost-calculator） 和 Token 单价换算（/tools/token-price-calculator），输入、输出、轮次填进去，用当期单价跑一遍，比拍脑袋靠谱。

传统软件那些不写在价目表上的钱

传统软件的价目表往往只写了许可。真正掏钱的时候，实施、定制、数据迁移、对接老系统这几项经常比许可本身还贵，而且很难砍。这类钱不写在明面上，但躲不掉。

还有一类是周期性的：版本升级带来的回归测试和重新培训。它不是意外，是固定要发生的支出，只是没被列进第一年的预算。供应商锁定之后议价空间变小，续费涨幅也要提前问。

• 只给许可价、不给实施人天的报价，等于没报完整
• 问清定制部分后续维护算谁的，改一次收一次还是包在年费里
• 数据迁移和接口对接单独列出来，别指望供应商顺手做
• 续费涨幅、提前告知期、退出时数据怎么导出，都写进合同再签

Agent 这边同样有隐性账单

Agent 不是买完就完事。开发调试期就是一笔实实在在的消耗：提示词改一版跑一遍，成本按次数叠，很多人发现开发阶段花得比上线后还多。这部分不算进预算，第一个月就超。

并发上来之后，限流和排队会逼你做缓存、做降级、做配额管理，这些是工程量，不是调用费，但同样要人力。人工审核环节更容易失控，低频高价值的任务尤其如此，审一个人工单的成本可能比模型调用还高。

复盘用量的时候，先把对话记录整理清楚。站内的 Session 转换器（/tools/session-converter） 这类工具能把会话结构理出来，按会话看用量分布，比只看月度总额有用得多，能定位到是哪类请求在吃预算。

估算顺序：先定用量模型，再套单价

顺序反了就会一直算不准。先估用量，再套单价，最后加冗余。用量模型只需要三个数：每天多少会话、每会话多少轮、每轮大概多少上下文。这三个数定下量级，剩下的才是乘法。

1. 定用量假设写下每天会话数、每会话轮次、每轮上下文长度，标注这三个数是实测还是猜的，猜的要写出来源。
2. 套当期单价去 AI 官方 API 价格（/official-api） 和 模型价格变动（/price-watch） 取当期数字，别用记忆里的旧数。
3. 加重试与峰值冗余按自己日志里的实际重试比例和峰值倍率预留，倍数用实测值，不要拍一个整数。
4. 做敏感性检查把三个用量假设各放大一档重算，看结果波动多大。波动越大说明方案越没定稳，先别签长约。

两类方案放一起比，比的是单位产出的钱

传统软件按席位计价，Agent 按任务计价，单位不一样，直接比总额没意义。要换算成同一个单位：每个工单多少钱、每份报告多少钱、每次查询多少钱。换算完再比，结论才站得住。

低频任务

用 Agent 往往更划算，因为不用为闲置的席位付费

高频稳定流程

传统软件或规则脚本通常更省，调用费会随量线性堆上去

半结构化任务

两边都行，关键看人工审核占比，审核重就偏向传统方案

强合规场景

先算人力和流程，技术成本往往不是决定项

估用量的时候容易低估一个数量级。去 真实用量榜（/usage） 看看同类场景的实际调用量级，再回头校准自己的假设。这一眼比多算三遍公式都值。

这套算法什么时候不适用

强合规、强审计的场景下，人力和流程成本压过技术成本。这时候单看调用费会得出完全错误的结论，得先把审核、留痕、复核的人力折算进去，再谈值不值。

一次性项目、内部试验、纯学习用途，也没必要做完整测算。直接小额充值试跑，看真实账单长什么样，比纸上推演快得多，也准得多。

还有一种情况：供应商给的是额度包、套餐或者折扣，单价结构和按量计价不一样。这时候要拿套餐口径重新算，而不是把按量单价硬乘上去。算错口径的预算，比不写预算更容易误导决策。

最后补一句判断经验。如果一份方案的成本里，模型调用那一栏占比很高，那这方案对单价波动很敏感，议价和备选供应商要提前准备；如果模型调用占比很低，钱主要花在工程和人力上，那该盯的是交付节奏和人员排期，而不是去比谁的单价便宜几分。