整理一篇学习笔记，把看到的一些要点和自己的理解都记下来。
文章目录
- 1 -> 引言
- 2 -> 为什么只看 Token，会把账算错
- 3 -> Agent 的六类成本
- 1. 模型推理成本
- 2. 工具与数据成本
- 3. 基础设施成本
- 4. 人工要注意力成本
- 5. 失败与返工成本
- 6. 风险预期损失
1 -> 引言
Agent 项目最容易算清的是 Token，最容易漏掉的是人工要注意力、失败返工和风险成本。真正值得优化的，不是“每次调用有多便宜”，而是“每个通过验收的结果要付出多少总成本”。
2 -> 为什么只看 Token，会把账算错
传统软件的边际运行成本通常比较稳定：一次请求消耗多少计算、存储和带宽，大致可以预估。Agent 不同。它会自主决定调用多少次模型、读取多少上下文、使用哪些工具、是否重试，也可能在错误方向上持续推进。因此，同一个任务在不同提示、工具权限和验收机制下，成本可能相差数倍。
更重要的是，模型账单只是显性成本。一个看似便宜的 Agent，如果输出要员工逐句核验、经常返工，或者把错误结果推入下游系统，它的总成本可能远高于直接让人搞定。
可以用下面这个口径替代“每次调用多少钱”：
单位有效结果成本
=（模型成本 + 工具与数据成本 + 基础设施成本
+ 人工准备与审校成本 + 失败返工成本 + 风险预期损失）
÷ 通过验收的结果数量
这里的关键词是“通过验收”。生成一百份报告不等于获得一百个结果；如果只有二十份可以直接使用，那么其他八十份只是过程产物。
3 -> Agent 的六类成本
1. 模型推理成本
包含输入、输出、缓存读写、推理强度以及多轮调用。长上下文会反复进入请求，工具返回的大段网页或日志也可能被多次携带。复杂 Agent 还会有规划、执行、反思和复核等多个模型角色。
2. 工具与数据成本
搜索 API、商业数据库、浏览器执行、代码沙箱、地图、语音、OCR、邮件验证等都可能单独计费。数据质量差时，Agent 还会花更多模型调用清洗和交叉验证。
3. 基础设施成本
包含队列、容器、向量库、日志、监控、文件存储、网络出口和安全隔离。开发演示阶段常把这些成本藏在本地环境里，上生产后才集中显现。
4. 人工要注意力成本
人要定义任务、补背景、处理中断、审批高风险动作、核验结果并收口。若 Agent 每隔几分钟就来追问一次，它实际上没有释放人，而是在制造一种新的值班开发。
5. 失败与返工成本
失败不只是“再跑一次”。错误可能污染 CRM、重复联系客户、提交不可合并的代码，或者让后续 Agent 基于错误前提继续开发。越晚发现，返工成本越高。
6. 风险预期损失
它可以粗略表示为：
风险预期损失 = 事故发生概率 × 事故影响
低概率但不可逆的动作，例如对外承诺、付款、删除数据、批量发送消息，不能因为平均调用成本很低就自动执行。它们要权限边界、确认门和审计记录。
4 -> 先分工作组合，再谈模型预算
OpenAI 在关于 Agent 投资管理的文章中提出，应把 AI 投资看成组合，而不是孤立项目。落到团队执行，可以把任务分成三类：
工作类型典型任务预算策略主要评价指标广覆盖型摘要、分类、格式转换、初筛低单位成本、高吞吐覆盖率、人工节省时间流程改造型客户研究、工单处理、测试生成允许多步调用，但必须稳定任务成功率、周期缩短战略探索型新产品原型、复杂研究、重大方案小规模高质量投入学速度、决策价值
如果不做区分，团队通常会犯两种相反的错误：要么所有任务都调用最强模型，成本迅速上升；要么为了压低单价，强迫小模型处理它不擅长的复杂推理，结果靠人工返工补回来。
5 -> 模型路由不是“大小模型二选一”
合理的路由至少有四层：
1. 不用模型：固定规则、数据库查询、去重、格式校验和权限判断优先使用确定性程序。
2. 小模型或低推理档：分类、抽取、改写、结构化、简单工具选择。
3. 中等模型：需要结合上下文判断，但成功标准清楚的常规任务。
4. 前沿模型或高推理档：复杂规划、跨来源推理、疑难调试、高风险复核。
路由依据不能只看用户输入长度。更有效的信号包含：
- 任务是否需要多步规划；
- 错误是否容易被程序检测；
- 输入是否存在冲突或歧义；
- 是否涉及不可逆动作；
- 首次尝试的置信度和验证结果；
- 失败后升级模型能否显著提高成功率。
6 -> 上下文成本常比回答本身更大
Agent 每次都加载完整项目资料，表面上最稳妥，实际上会同时伤害成本和质量：无关材料占用窗口，旧信息与新信息冲突，关键规则反而被淹没。
降低上下文成本可以从五件事开始：
1. 分层存储：长期规则、项目事实、当前任务状态和临时证据分开管理。
2. 按需召回：先识别任务类型，再检索最小充分上下文。
3. 稳定前缀缓存：将不频繁变化的系统规则和公共资料放在可缓存部分。
4. 工具输出裁剪：网页、日志和数据库结果先结构化，再交给模型。
5. 阶段性压缩：长任务在检查点生成可追溯摘要，不无限累积原始对话。
压缩不能只追求短。好的压缩必须保留决策、证据、未解决问题、下一步和来源位置，否则只是把可验证信息压成一段无法追责的文字。
7 -> 成功率决定重试经济学
假设每次尝试独立、成功率为 p，获得一次成功平均需要约 1/p 次尝试。成功率 50% 时平均两次，20% 时平均五次。但现实失败往往高度相关：如果任务定义错了，重复运行同一配置不会自动变好。
因此应区分三类重试：
- 瞬时重试：网络、限流或工具偶发故障，可以按退避策略自动重试；
- 策略重试：更换检索、模型或工具路径，并记录变化；
- 需求返工：成功标准或输入本身有问题，应暂停并回到任务定义。
8 -> 什么时候多花算力是划算的
增加推理预算通常在以下条件下成立：
1. 任务价值高，质量提升能直接影响收入、风险或关键决策；
2. 更强模型确实能提高通过率，而不是只写得更长；
3. 人工审校很昂贵，模型多做一次复核可以明显减少人工时间；
4. 任务处在探索阶段，更快获得证据能缩短产品验证周期；
5. 产出可以被自动验证，额外并发不会淹没人的注意力。
反过来，如果任务没有明确成功标准、数据入口不稳定，或最终仍需人逐项重做，增加算力只会更快地产生待审材料。
可以比较两个方案的“质量调整后成本”：
方案单次成本一次通过率平均人工审校单位有效结果成本小模型直出145%12 分钟可能较高强模型 + 自动验证485%3 分钟可能反而较低
这里不填写统一结论，因为人工成本、结果价值和任务风险因团队而异。正确做法是用自己的真实样本测量。
9 -> 一个 AI 获客任务的算账示例
假设系统要研究 1,000 家潜在客户，并生成可供销售确认的触达草稿。
方案 A：全量使用强模型
每家公司都执行网页研究、公司判断、联系人推断和长文本生成。优点是流程简单，缺点是大量明显不符合条件的公司也消耗完整预算。
方案 B：分层漏斗
1. 用规则和轻量模型搞定地区、行业、规模、网站可用性筛选；
2. 只对高潜公司进行多来源研究；
3. 通过证据完整性检查后才生成草稿；
4. 高价值客户由更强模型做个性化和事实复核；
5. 对外发送前由销售确认。
方案 B 的价值不只是省 Token。它减少了无效研究、降低了销售审校量，也让“为什么选中这家公司”变得可追溯。真正应比较的指标是：
- 每个合格线索的总成本；
- 每个可用触达草稿的人工分钟数；
- 从输入公司到销售可行动结果的周期；
- 错误事实率和重复触达率；
- 最终回复或商机转化，而不是生成数量。
10 -> 建立一张 Agent 经济仪表盘
建议至少跟踪以下指标：
维度指标示例质量任务成功率、一次通过率、事实错误率成本单任务模型成本、单位有效结果成本、工具成本人力人工准备时间、审校时间、中途介入次数速度端到端周期、P50/P95 延迟、队列等待时间稳定性工具失败率、重试次数、超时率风险越权拦截、敏感操作确认、事故与近失事件业务收入影响、转化率、工单解决率、开发交付周期
这些指标必须按任务类型分组。把“摘要”和“付款审批”的成功率混在一起取平均，没有管理意义。
11 -> 最常见的五个误区
误区 1：Token 越少，系统越高效
如果省下的 Token 变成更多人工返工，总成本反而上升。
误区 2：最强模型一定最贵
单次调用更贵不代表单位有效结果更贵。高一次通过率、少重试和少人工可能抵消差价。
误区 3：并发越多，产能越高
没有自动验收和优先级控制时，并发只是把人的审核队列堆得更长。
误区 4：演示成功就证明 ROI
演示通常忽略异常输入、人工准备、维护、权限和长期漂移。ROI 要在真实流程和足够样本上测。
误区 5：所有 Agent 都应该常驻运行
低频、低价值、难验收的任务，按需调用甚至人工搞定可能更划算。
12 -> 上线前检查清单
- 已定义“有效结果”，不是只统计生成量；
- 已记录模型、工具、基础设施和人工总成本；
- 有任务分级与模型路由，而不是全量调用同一模型；
- 有自动验收、升级和停止条件；
- 重试能区分瞬时故障、策略失败和需求错误；
- 高风险动作有权限、确认和审计；
- 已用真实样本比较质量调整后成本；
- 仪表盘能按任务类型查看质量、成本和业务结果；
- 增加预算前，能说明它要解除的具体瓶颈。
13 -> 结语
Agent 的经济性不是“模型单价 × Token 数量”这么简单。它是一套关于任务设计、模型路由、上下文、验证、人机分工和风险控制的系统工程。
真正健康的目标不是让每个调用都最便宜，而是让高价值任务以可接受的总成本稳定通过验收。只有当团队能看见单位有效结果成本，才知道应该压缩上下文、升级模型、增加算力，还是先把流程重新设计。
感谢各位大佬支持！！！
互三啦！！！
这篇笔记就先到这里，后面用到新的思路或者发现有问题再补充。
评论 (0)
暂无评论