AI·快讯
💰 基础设施 · 成本透视

Agent 成本失控背后:上下文、人工审核与维护成本正在被低估

WAIC 2026 上,优刻得 CTO 王凯与焱融科技 CTO 张文涛拆解了企业 AI 账单里那些"看不见的支出"——模型单价在降,但任务链、上下文膨胀和人工干预正在推高总成本。

WAIC 2026 现场讨论 2026-07-22 全文约 4 分钟读完
#Agent 成本 #AI 基础设施 #WAIC 2026 #企业 AI 治理
任务成功率 > Token 单价 企业应先关注任务能否完成,而非每百万 Token 的价格
3 笔隐性成本 人工审核、上下文膨胀、代码维护——不在账单上
1 套治理体系 用量可见、日志审计、多 Key 管理——基础设施必备

⚡ 30 秒速览

  • 核心矛盾:模型单价持续下降,但 Agent 任务链涉及目标理解、拆解、检索、调用、验证等多个环节,一次失败可能从头执行——总成本不降反升。
  • 漏算的三笔账:人的时间(代码审查、结果验收)、上下文膨胀(记忆与状态持续累积推动计算资源增长)、后续维护(AI 生成的代码仍需 AI 维护,形成循环)。
  • AI Coding 两条路:渐进路线——用 AI 改造传统软件工程的各环节;激进路线——只定义输入输出,让 Agent 自主完成。传统企业更适合前者。
  • 多模型不是目的:企业真正需要的是可替换架构——将模型、搜索、存储、支付等能力服务化,任一环节被替换时其他部分仍能正常运行。
  • 核心判断:Token 单价下降不必然带来总成本下降。只有当任务目标被定义清楚、流程可评价、模型可替换、成本可见,且 AI 真正替代了原有环节,降价才有意义。

01账单陷阱 为什么 Agent 越智能,成本越难控?

一次普通对话只调用一次模型。但一次 Agent 任务背后,往往包含目标理解、任务拆解、信息检索、工具调用、上下文读取、记忆存储和结果验证——任何一个环节出现偏差,Agent 都可能重新规划、重新调用,甚至从头执行。

传统聊天

一问一答,单次调用,成本可预测。上下文短,失败后重试成本低。

用户提问模型回答

Agent 任务

整条任务链:理解目标 → 拆解步骤 → 调用工具 → 检索数据 → 生成内容 → 验证结果。失败可能从头再来。

目标理解拆解检索调用生成验证

注:Agent 任务链每增加一个环节,失败重试的概率和上下文长度都会叠加,导致单次有效任务的资源消耗远高于传统对话。图中展示了两种模式的结构差异。

"很多时候我们说 AI 贵,贵在我们为了一个自己没有定义清楚的问题,让 AI 不断地尝试,给出无数个答案。" —— 王凯,优刻得 CTO

王凯提出,企业不应只问"Token 贵不贵",而应先问"这些 Token 花得值不值得"。如果目标、受众、结构和评价标准足够明确,模型可能在少量尝试后完成任务;但如果企业只是让模型先生成数百个版本再从中挑选,又没有明确的筛选标准,成本自然会迅速上升。

先定义任务,再计算成本——这是控制账单的第一步。

但账单上的数字,只是冰山一角。

02三笔隐形账 企业最容易漏算的人、时间与维护

Token 账单至少是可见的。更难处理的是那些没有直接出现在云平台账单里的隐性成本。张文涛认为,企业最容易忽略三部分:

👤 人的时间 AI 生成代码后,工程师仍需审查、测试、安全检查与结果验收
📈 上下文膨胀 记忆与状态持续累积,每次调用携带的上下文越来越长,推高计算资源
🔧 后续维护 AI 生成的代码如果只能由 AI 维护,企业还需建立评价、更新与纠错体系

注:三种隐性成本往往相互叠加——上下文膨胀导致推理成本上升,人工审核占用工程师时间,维护体系又需要持续投入。它们不会出现在模型厂商的账单上,却可能数倍于 Token 费用。

张文涛以代码单元测试为例:企业不能只统计调用了多少 Token,而应该比较过去一名工程师一天可以完成多少测试,引入 AI 后又能完成多少——新增的产出是否足以覆盖模型费用和后续人工审核成本。

王凯进一步指出,Agent 在运行过程中需要反复重构上下文,而上下文叠加会推动计算资源快速增加。这也是 KV Cache、上下文压缩和信息提取逐渐成为推理基础设施关键环节的原因。

那么,AI Coding 的情况又如何?

03AI Coding 不是生成代码,而是重构软件工程流程

AI Coding 被普遍认为是当前落地最快的 Agent 场景之一。但从生成代码到真正投入生产,中间仍然存在很长的距离。张文涛提出,企业需要的不只是一个代码模型,而是一整套完整体系:如何拆解需求、如何定义 Agent 角色、如何设计测试、如何评价结果。

两条路线,两种风险 渐进 vs 激进

  • 路线一(渐进):沿用传统软件工程的基本结构,用 AI 分别改造需求分析、编码、测试、审查和运维等环节。人仍然负责流程设计,AI 逐步替代其中可以被明确评价的工作。
  • 路线二(激进):企业只定义输入和最终输出,让 Agent 自主完成中间的规划、编码、测试和迭代,人主要负责评价最终结果。适合 AI Native 公司。
  • 传统企业的风险:现有生产流程是长期经验、制度和组织协作形成的结果。如果突然将整个流程交给 Agent,相当于一次性击穿原有的信息化和管理体系。
王凯判断:对大多数企业而言,更稳妥的办法是逐环节拆解——先找到可以被清晰评价和稳定替代的任务,再逐步引入 AI,而不是一开始就将全部生产流程交给模型。

对于真正从零开始的 AI Native 公司,第二种路径可能带来更高效率——一名工程师借助多个 Agent,理论上可以完成过去一个团队的工作。但对于传统企业,渐进改造仍是最低风险的选择。

如何避免被单一供应商锁定?

04多模型策略 可替换才是真正的能力

随着模型数量不断增加,企业往往希望同时接入多个模型、平台和 Agent 框架,以降低被单一供应商锁定的风险。但多技术栈本身也会增加学习、适配和运维成本。

王凯认为,企业真正需要的不是为了"多模型"而多模型,而是一套清晰的编排架构:

模型 搜索 存储 网络 支付

注:可替换架构要求每一层都通过标准化接口连接,任一组件被替换时其他部分仍能正常运行。图中展示的是企业 AI 基础设施中需要具备可替换性的关键能力层。

在这种架构下,模型、搜索、存储、网络、支付等能力都可以被服务化调用。企业选择多个供应商,不是为了形式上的分散,而是为了在价格、能力或供应发生变化时,能够以较低成本完成替换。

张文涛补充称,与传统云计算相比,公开模型 API 已经具备一定程度的标准化。真正容易产生绑定的是私有化部署——不同 GPU、推理框架、模型和存储系统之间仍然存在大量适配工作。一旦企业围绕特定供应商进行了深度开发,后续迁移可能涉及模型格式、硬件环境和工程工具链的整体调整。

"企业应将自身积累的工作流程、提示词、规则和操作经验沉淀为可迁移的 Skill,而不是将核心能力完全绑定在某一款工具中。" —— 张文涛,焱融科技 CTO
最后,谁来为这一切买单?

05治理之困 不能只发一个 Key,然后对使用情况一无所知

当 AI 从个别员工的实验变成企业级工具,成本问题也会逐渐转化为治理问题:谁来承担费用,如何分配预算,是否限制 Token,以及怎样判断一个团队用得过多还是过少。

王凯认为,企业至少需要具备以下基础能力:

📊

用量可见与日志审计

企业不能只向所有员工发放同一个 Key,之后既不知道谁在使用,也无法在成本异常时关闭"水龙头"。多 Key 管理、限速和限流是底线。

🎯

按团队类型差异化管理

传统企业转型初期应鼓励使用以降低学习门槛;AI 制药等创新研发采用项目预算管理,允许试错但设置上限;稳定生产流程则需持续计算单位产出和单位成本。

🚗

无人驾驶汽车类比

如果一辆无人车价格为 50 万元,但仍然需要一名司机全程坐在车内,企业同时承担了车辆和人员两份成本。当前许多企业使用 AI 的状态,正类似于"车里的人还没有离开"——AI 已经产生了成本,但原有人员和流程并未减少。

注:三类治理场景对应不同阶段的企业需求。底线是"看得见、管得住";进阶是"按任务类型差异化分配预算";终极目标是"AI 真正替代原有环节,实现单位产出成本下降"。

王凯用这个类比点明核心:要判断 AI 是否真正降本,企业必须明确它替代了哪部分工作,以及单位产出是否因此增加。否则,企业购买的可能不是生产力,而是一场不断追加预算的试验。

编辑核心判断

Token 单价下降不必然带来总成本下降。只有当任务目标被定义清楚、工作流程可以被评价、模型能够被替换、使用成本可以被看见,并且 AI 真正替代了原有环节,降价才有实际意义。

Agent 时代,企业真正需要控制的不是每百万 Token 的价格,而是完成一次有效任务所消耗的全部资源。谁先建立这套评价体系,谁就能从"不断追加预算的试验"走向"可计算、可治理、可优化"的生产系统。