先说一个我最近复盘的真实项目。某电商团队上线了一个订单查询与退换货的客服 Agent第一周看账单推理费一天几百块负责人很高兴觉得这玩意儿比招人划算多了。三个月后做财务复盘把所有配套成本拉出来一算总成本比预算高出将近一倍。问题不是 API 涨价也不是模型选错了而是从一开始就漏算了一大堆“把 Agent 当同事养”的隐性成本——调试它的人、喂它的数据、盯着它不出错的系统、它闯祸之后的兜底。这篇文章想聊的就是这件事当 AI Agent 从一个临时调用的小工具变成团队里一个拿工号、有职责、被考核的“同事”成本结构会发生哪些本质变化。哪些传统科目会消失哪些新科目会冒出来哪些最容易被低估。如果你正准备把 Agent 从 PoC 推到正式业务线上或者要给老板写一份“我们该不该把客服/运营/审核交给 Agent”的成本测算报告这篇内容应该能直接用上。1. 先算一笔账API 调用费只占 Agent 总成本的四成不到大多数人理解的大模型成本是打开模型服务商的账单看 token 费用。这个数字在 Agent 正式部署之后真的只是局部。我复盘的那个客服 Agent三个月总成本里推理费用占比大约 37%剩下的全是和“让它像一个正式员工那样工作”相关的配套成本。1.1 一个客服 Agent 的三个月成本复盘当时团队的做法是把 Agent 嵌入订单系统的售后流程负责解释物流状态、处理退换货申请、生成退款工单。上线前做了知识库清洗接入了订单查询接口搭了一套人工抽检规则还配了监控大盘。三个月后的成本拆解长这样成本科目占比明细模型推理费用37%主模型调用、工具调用、重试产生的额外 token工程人力29%工作流设计、调试、接口联调、Bug 修复数据建设12%知识库清洗、标注样本、评估集维护质检与兜底10%人工抽检标注、转人工后客服重新处理基础设施8%日志存储、向量库、监控告警、灰度环境项目管理与沟通4%评审、需求梳理、跨部门协调这里最扎眼的是工程人力。很多人以为 Agent 是“买来即用”的 SaaS输入一段 Prompt 就能跑。实际上当一个 Agent 要同时读订单状态、判断退换货政策、调用售后接口、还要在答错时优雅地转人工它背后是一个需要持续迭代的业务系统。每次政策调整、每次商品类目变化、每次新渠道接入都要有人去改工作流、跑回归、上线验证。1.2 成本模型的变化从“按用量付费”变成“按绑定关系付费”传统 API 调用是典型的用量驱动成本——调用多了钱多调用少了钱少和人没关系。Agent 作为同事部署之后成本结构变成了“绑定驱动”。什么叫绑定驱动就是你把 Agent 绑定到一条业务链路上它就和这条链路形成了深度耦合。订单系统改接口Agent 要跟着改客服话术规范更新Agent 的 Prompt 库要跟着更新出现新的商品促销玩法Agent 的知识库要重新同步。只要业务还在变Agent 就不会停止“学习”和“被维护”。所以真正合适的成本口径不是“单次调用多少钱”而是“完成单次任务要花多少钱”。单次任务成本 推理费 工程人力摊销 知识更新摊销 质检兜底摊销。任务量越大推理费越线性增长但工程人力摊销可以摊薄反过来任务量不够大时工程人力摊销会让单次成本高得吓人。这个逻辑决定了后面讲 ROI 时的基本判断。2. 为什么“工程师时间”成了最大的成本科目我在不同场合反复说过一句话Agent 不是交上去跑一遍就完事的模型它是一套需要人持续伺候的软件系统。伺候它的人成本一点都不比伺候旧系统的工程师低有时候还更高因为它多了一层不确定性。2.1 调一个 Prompt 的背后是三轮 Agent 工作流设计我以前带过一个应届生第一次写 Agent 工作流以为重点是“Prompt 写得漂不漂亮”。实际上把需求拆成多步任务、每个步骤决定是调模型还是调工具、每个分支设好兜底条件、每个判断节点想清楚误判代价这些才是大头。以退换货 Agent 为例核心工作流看起来就十几行伪代码但每一步都要调试。判断用户意图要试不同阈值决定要不要调订单接口要看返回字段的兼容性生成退款金额后又得设计一道复核逻辑防止出现超权限操作。每一步试错背后是看日志、看 trace、比对预期输出。一个五分钟能说清楚的业务规则落到 Agent 工作流里往往要调一个下午。这不是某一家团队能力不行而是 Agent 应用开发的天然形态业务逻辑被“埋”在模型推理和工具调用之间诡异错误全靠人肉排查。修一个对话状态串号的问题可能要翻几十条 trace 才能定位。这部分成本不会出现在模型服务商的账单上但会每个月真实地出现在人力成本里。2.2 幻觉不是 Bug是常态所以必须有人盯模型幻觉这件事很多人讨论过但我想从成本角度说因为幻觉无法根除你只能靠评估体系把它压到可接受阈值再靠人工抽检兜住剩余风险。而这个“评估体系”和“人工抽检”都是纯人力投入。我的经验是可以把它类比成带实习生。实习生上手快、态度好、成本相对低但你不能完全信任他——他的每份对外输出都要有人 review否则出了事算谁的Agent 也一样。它生成的每一单退款说明、每一条政策解释理论上都可能有“自信满满的胡说八道”。团队必须设计抽查比例低风险问题抽 5%涉及退款和赔偿的高风险操作抽 100%。抽检本身就是人力而且是那种最容易被低估的琐碎人力。2.3 月成本估算公式和一个小脚本给团队做预算时我建议用这个公式估算 Agent 的月度总成本月度总成本 推理费用 工程人力月摊 数据标注质检成本 基础设施成本具体拆开推理费用 日均任务量 × 单任务平均 token 数 × token 单价 × 30工程人力月摊 参与工程师人数 × 人月成本 × 投入比例数据标注质检成本 抽检比例 × 任务量 × 单条标注时间 × 标注单价基础设施成本 日志存储 向量库 监控告警 CI/CD 环境我习惯用一个小脚本先跑出量级再细调参数。# agent_monthly_cost.py # 输入业务参数快速估算 Agent 月度总成本 def estimate_monthly_cost( daily_tasks10000, tokens_per_task3000, token_price_per_million2.0, # 按输入输出平均计 engineers1, monthly_per_engineer50000, # 工程师折算月成本到项目 engineer_ratio0.5, # 工程师投入到该项目的时间占比 sample_ratio0.1, # 人工抽检比例 annotate_minutes2, # 单条抽检耗时 annotate_hourly_cost30, # 标注人力时薪 infra_monthly3000 ): inference daily_tasks * tokens_per_task * token_price_per_million / 1_000_000 * 30 labor engineers * monthly_per_engineer * engineer_ratio quality daily_tasks * sample_ratio * annotate_minutes / 60 * annotate_hourly_cost * 30 total inference labor quality infra_monthly return { inference: inference, labor: labor, quality: quality, infra: infra_monthly, total: total } print(estimate_monthly_cost())这个脚本的价值不在精确而在让团队对规模有体感。很多项目一跑就能发现推理费用看起来不高乘以任务量再乘以天数加上人工质检预算瞬间就上去了。3. 一次性建设成本给 Agent 搭“工位”比招人贵在哪招一个正式员工要配工位、电脑、账号权限、入职培训。Agent 作为同事上岗同样需要一套“入职流程”。很多团队只算了之后的运行费用把上线的准备工作完全漏掉了结果项目启动第一周就发现预算不够。3.1 知识库与检索基建一次性的“入职培训”人入职看文档然后靠记忆和判断工作。Agent 不能靠记忆——它靠的是被结构化之后便于检索和引用的知识。所以要把客服政策、商品手册、售后规则全部清洗、拆分、向量化可能还要搭一套 RAG 管道。这一步听上去像“把文档塞进向量数据库”实际干起来非常费时间。原始文档里的表格、流程图、FAQ、历史工单格式五花八门很多旧文档本身已经过时。清洗的时候必须和业务方一条条确认口径否则 Agent 引用的就是过期规则。我做过的项目里这个环节至少占掉整个上线周期三分之一的时间。它的成本是一次性的但绝对不是“免费午餐”。3.2 工牌与门禁权限和数据隔离的成本新人入职要开账号、配权限。Agent 也一样而且要求更严格。它要查订单、要调用售后退款接口、要读 CRM 客户信息每一步都是敏感操作。这就带来权限设计成本和审计审计成本。这里要做的并不简单给 Agent 单独建服务账号配最小权限只能读该读的字段所有敏感操作写审计日志接口调用加白名单还要定期轮换密钥。更麻烦的是当 Agent 需要跨系统协作时API Key 的传递和存储会引出一堆安全设计。你不想让一个模型提出“把全网用户信息导出”的请求所以还需要加一层请求侧的数据安全过滤。这套体系对传统 IT 团队来说技术栈很成熟但对第一次部署 Agent 的团队往往要临时补课时间成本极易被低估。3.3 评估基线没有 KPI 的 Agent 不能上岗人试用期有考核Agent 更需要。你不可能在它上岗当天直接说“你看着办”。需要一套评估集50 到 100 条有标准答案的典型问题覆盖高频场景跑回归算出准确率和拒答率再决定上线阈值。搭建这套评估集成本比想象中高。每条评估样本不只是“问题 答案”还要标注等级、覆盖场景、边界情况、预期转人工条件。标注过程需要业务专家的判断工程师不能闭门造车。更麻烦的是业务规则变化后评估集要跟着更新否则你越优化越跑偏。这个成本虽然列在“一次性建设”里实际上它会像一个慢性的维护项目长期存在——只不过第一阶段投入最集中。4. 运行期成本监控、兜底和人审是甩不掉的三座山Agent 上线之后很多人以为成本只剩推理费了但真正跑起来会发现推理费之外还有“运维税”。这笔税有三个大头任何一个处理不好都可能让整个项目的经济账翻脸。4.1 日志、追踪和告警被低估的“运维税”Agent 是一个多步骤系统每一步都可能出错。要排查问题必须有日志、有 trace、有版本记录。给运行中的 Agent 加全链路追踪之后日志量会猛增。我们那个项目上线第一周日志存储每天新增几个 GB一个月下来存储成本接近推理费的二分之一。这还没算监控告警、持续集成、灰度发布这套工程基础设施的硬件和人力摊销。更隐形的是“告警疲劳”。Agent 系统里模型偶尔抽风很正常如果告警规则设得太敏感工程师一天收几十条很快就没人看了。最后重要故障反而被淹没。我现在的做法是把告警分级低危的汇总成日报高危的才实时推到群里。这套规则也要人维护都是成本。4.2 置信度分级别把低成本自动化做成高成本半自动化这是我觉得最值钱的实操经验。有个阶段 Agent 接入了 80% 工单但剩下的 20% 自动转给了人工。团队本想着 20% 不多结果客服抱怨处理时间比以前更长。排查后发现问题出在“转交质量”Agent 把答得含糊不清的对话原封不动转过来人工接手时要把整个上下文重新理一遍耗时比直接接一个新工单还长。解决方式是加一道置信度分级Agent 在生成答案时给自己打一个“确定程度”低于阈值就直接走简洁转人工不再输出冗长答案。不是说 Agent 答得越完整越好——在不确定的时候越早让人接手综合成本越低。这套分级逻辑的调优同样是一场持续的工程投入它不会出现在推理账单上但直接决定总成本会不会失控。4.3 7×24 在线Agent 的工作时间越长身后的人越贵有的团队会把 Agent 部署成 7×24 小时在线理由是“人做不到但 Agent 可以”这句话在成本上是双刃剑。Agent 在线本身不贵但它在线期间出故障需要有工程师响应这就贵了。夜间调用量少时也许可以忍受故障延迟到白天处理一旦业务方要求“夜间也得保证可用性”你就得排值班、订告警策略、留现场处置通道。本质上7×24 的 SLA 意味着你要用“更贵的工程师时间”去兑付“省下来的人工成本”。如果凌晨的订单量撑不起一个值班工程师的时薪那不如直接把夜间业务关掉或者明确告诉用户“夜间转人工到白天处理”。把 Agent 当成一个 5×8 的同事在很多场景下经济性反而更好。5. 从 ROI 角度看什么样的业务适合“雇”Agent成本聊完该聊收益了。很多团队喜欢盯着“省了多少人力”算账但我觉得要先把业务分成两类替代型与增量型。5.1 替代型还是增量型两类业务的 ROI 逻辑完全不同替代型业务的典型特征是有明确的人工操作路径可以对照。比如客服退换货、发票信息录入、工单分类。它的 ROI 很好算替代前每天这些人要做多少小时时薪多少Agent 上线后能替代多少比例。这种业务适合快速试点算账清楚出了问题也好定位。增量型业务则是“人本来做不了或不想做”的事。比如用 Agent 对历史工单做全量质检、对存量客户做个性化回访、对商品描述做合规扫描。这类业务的收益很难直接折算成人力节省但天花板高因为它创造的可能是质量提升和营收增量。判断增量型业务是否值得做不能只看成本还要看它能带来多少之前拿不到的价值。我的建议是刚起步的团队优先做替代型因为成本结构透明、试错成本低成熟之后再往增量型走因为增量型的“收益无上限”才能消化前面提到的工程人力摊销。5.2 单月回本测算用数字说服自己而不是说服老板给一个简化但可用的测算方法月度净收益 节省人力成本 新增业务收益 - 推理费用 - 质检与兜底成本 - 工程人力月摊 - 基础设施成本如果月度净收益为正说明 Agent 上线后每个月都在帮你赚钱如果为负但接近零说明长期优化后有机会转正如果负得很多就要认真看看是业务选错了还是工程配置有问题。举个例子客服团队原先日均 2000 通在线咨询人均日处理 60 通需要 33 人。如果 Agent 能承接 70%节省不到一半的人力因为高峰期和兜底还要人约节省 10 人按人均月成本 1 万计节省 10 万。Agent 的推理费用假设日均任务 1400 通、每单 token 成本 0.1 元一个月约 4200 元。质检兜底人力约 1.5 人月成本 1.5 万。工程人力月摊 2 个人月成本 4 万。基础设施 3000 元。净收益大约 10万 - 4200 - 1.5万 - 4万 - 0.3万 3.78 万元。这类项目值得做。5.3 三种不适合“同事化”的场景有些业务硬上 Agent 会让成本结构非常难看我总结了三类一是需要极高解释成本的黑盒决策比如拒绝用户贷款、判定交易风险。模型答错一句引发的客诉和合规成本可能远超它省下的成本。二是出错代价呈指数放大的场景比如自动执行支付、自动删库、自动发公开内容。一旦幻觉发生恢复成本极高。这类场景不是不能上 Agent而是必须加多重人工审批审批成本会让收益空间被压缩得很小。三是低频且上下文不稳定的场景。Agent 特别依赖稳定的上下文和评估集来迭代如果一个场景一个月才出现几百次模型每次面对的上下文都差异很大你连评估集都攒不出来工程人力摊销又摊不薄性价比极低。6. 我在三种团队形态下实测出的成本配置经验写到最后分享一点落地层面的经验。不同规模的团队处理“Agent 同事化”成本的方式完全不一样。我分别经历过小团队、中台化团队和产品线独立部署踩了不少坑把结论直接列出来供参考。6.1 小团队不要自建工作流编排平台团队规模 5 到 10 人时最怕的是“看了几篇文章就想自研编排平台”。自研大概率要消耗两三个工程师数周时间第一版还不好用。我的经验是用托管平台或者低代码编排把这个环节的维护成本压到最低。宁可让一部分定制化能力受限于平台也要先把项目跑起来看数据。预算上我给自己定了一条线每个 Agent 项目每月的工程维护时间不能超过 1 个人天。如果超过要么是复杂度远超预期要么是平台选错了要么是项目根本不值得用 Agent 来做。这条线小团队可以当红线使。6.2 中台化团队把评估平台和日志系统做成共享资产团队到了几十人时往往同时跑着五六个 Agent 项目。如果每个项目各搭一套评估集、各存一份日志成本会重复膨胀。这时候最划算的做法是抽象出共享资产统一的评估平台、统一的日志追踪、统一的权限中心、统一的 Prompt 版本管理。这套统一层建设本身要投入也会让单个项目变得“更重”。但从整体成本结构看它能把工程人力从各项目中释放出来。我们做完共享评估平台之后新 Agent 上线前的回归成本下降了至少六成。共享资产真正做到位的时候新增 Agent 的边际工程成本会明显降低。6.3 产品线独立部署先想清楚它是长期资产还是临时工产品线自己拿预算、自己配工程师的团队最需要做的一个判断是这个 Agent 是要长期养还是只干一票。长期养意味着要配产品负责人、定期复盘评估指标、纳入技术债管理甚至在架构上预留它的升级空间。临时干则应该设时间盒——比如一两个月内必须跑通一条主链路并上线到期复盘数据不行就下线。我见过太多“临时干”的 Agent 因为没人舍得关掉变成了没人负责也没有指标的长青苔项目工程师不得不每个月花固定时间给它“擦屁股”。这比正式项目还贵因为它没有明确的成本责任主体。我的建议是临时的就定死退休日期到点就下线长期的从第一天就按正式员工管理指定负责人、指定预算、指定考核口径。最怕的就是既不想管又舍不得关最后变成一个谁也算不清成本的黑洞。回到开头那句话把 AI Agent 当同事部署真正改变的不只是“账上多了哪一行”而是整个团队的预算结构、工程组织方式和责任分配。Agent 不是一台便宜的机器它是一个需要工位、需要培训、需要考核、需要有人兜底的新加入者。算不清这一点省下来的钱迟早会在别的地方加倍花出去。我自己的体验是成本结构这件事想通之后很多决策反而简单了。遇到新项目先别问“Agent 能不能做”先问“如果它是一个拿工资的新同事你愿不愿意招”。愿意招你再评估薪资给多少、绩效怎么定、谁来做导师不愿意招那它大概率不适合上线。
