AI 智能体的单位经济学
大多数"代理式AI"内容跳过了一个决定任何东西能否落地的关键问题：
当这个系统每天运行时，成本是多少？
不是"演示的成本"。不是"测试提示词的成本"。我说的是生产成本：处理的发票、起草的邮件、解决的工单、执行的工作流。这就是大多数团队感到意外的地方。
我在Kloudedge Apex运营着一个14代理的AI工作团队，同时也为客户构建代理系统。这篇文章是我如何思考LLM驱动工作流的单位经济学的实用拆解。这不是理论。这是一个你可以直接使用的预算模型。
1、思维模型：成本主要在输出，不在输入
大多数团队忽略的第一个定价细节很简单：
输出token通常比输入token贵3到10倍。
所以如果你运行一个生成长解释、长摘要、长邮件或冗长JSON的工作流，你就是在为这种冗长付费。
这就是为什么"让它有用且详细"不是一个中性的产品选择。它是一个成本选择。
对于大多数生产系统，你应该假设：
- 输入相对便宜
- 输出主导账单
- 你的利润率取决于：输出长度、重试次数、以及你调用大型模型的频率
2、你应该预算的单位：每份工作的成本
Token定价很有用，但它不能清晰地映射到业务现实。
你的CFO不想听到"我们上个月花了9000万个token"。他们想听到：
- 每处理一张发票的成本
- 每解决一个支持工单的成本
- 每起草一封销售邮件的成本
- 每月结账清单的成本
所以你预算的单位是每份工作的成本。
"工作"是业务关心的完整端到端工作流结果。
例子：
- "提取一张发票，验证它，建议总账编码"
- "起草一封合规的外联邮件，进行个性化处理，生成简短的跟进"
- "总结一次会议，提取行动项，更新CRM备注"
当你这样定义你的系统时，你可以为产品定价、设置使用限制并衡量利润率。
3、真实的锚点：发票处理实际上花费人类大量金钱
在应付账款中，基准很重要，因为它告诉你你可以收取多少费用。
手动发票处理通常被引用在每张发票$10到$15的范围内，许多来源在完全手动环境中将这个数字定得更高。自动化产品通常将其降低到每张发票低个位数。
这个差距就是你的产品楔子：
- 如果手动处理是每张发票$10到$15
- 而你能将AI工作流控制在每张发票几美分到几美元
- 即使在中小企业定价下，你的毛利率也能非常出色
这就是为什么AP发票处理是如此好的"代理式"用例：它有一个清晰的单位（发票）、高数量和痛苦的劳动成本。
4、我的成本拆解：实际驱动支出的因素
在实践中，LLM支出来自五个方面：
- 上下文大小：你向模型发送了多少内容
- 输出大小：模型生成了多少文本或JSON
- 调用次数：每份工作你调用LLM多少次
- 重试和回退：因为解析失败或置信度低而重新运行的频率
- 模型层级选择：你调用高端模型还是廉价模型的频率
如果你控制了这五件事，你就控制了你的利润率。
4、三层模型策略（廉价、优质、高端）
我见到的错误：团队选择一个前沿模型并用它做所有事情。
这就像花钱请高级工程师来重命名文件和格式化JSON。
对于生产环境，你需要一个三层策略：
第一层：用于高数量、低风险任务的廉价模型
用于：
- 格式化
- OCR干净时的轻量提取
- 有严格长度限制的摘要
- 分类
目标：保持大部分流量的单位成本较低。
第二层：用于大部分实际工作的中端模型
用于：
- 核心提取
- 合理的推理任务
- 起草简短的面向客户的文本
目标："默认引擎"。
第三层：用于异常和困难案例的高端模型
用于：
- 奇怪的发票
- 边缘情况
- 高价值客户
- 任何失败代价高昂的情况
目标：高端模型的使用应该只占总调用的一小部分。
如果你做对了，高端质量是可用的，但它不会整天烧掉你的利润率。
5、预算工作表：估算每份工作的成本
这是数学的最简单版本。
你需要四个输入：
- 每次调用的平均输入token
- 每次调用的平均输出token
- 每份工作的调用次数
- 每百万token的价格（输入和输出）
然后：
- 每次调用的输入成本 = (input_tokens / 1,000,000) × input_price
- 每次调用的输出成本 = (output_tokens / 1,000,000) × output_price
- 每份工作的成本 = (input_cost + output_cost) × calls_per_job
这就是整个模型。
现在大多数团队忘记的部分：加上开销。
6、添加重试的"浪费因子"
在生产中，你会有：
- OCR故障
- 破坏提取的供应商模板
- JSON解析失败
- 低置信度输出
如果你不为重试做预算，你的实际支出会让你意外。
一个实用的方法：
- 早期阶段：假设1.2倍浪费因子
- 加固后：目标1.05倍
所以：
每份工作的实际成本 = 估算的每份工作成本 × 浪费因子
7、示例1：发票提取和编码
让我们建模一个典型的发票工作：
- OCR在LLM之外处理（仍然有成本，但分开算）
- LLM进行结构化JSON提取
- LLM使用候选账户的短列表进行编码建议
一个保守模型：
- 每张发票2次LLM调用
- 每次调用：2,000个输入token，500个输出token
每张发票总计：
- 输入token：4,000
- 输出token：1,000
现在代入你的模型定价。
重点不是精确的费率。重点是什么会影响这个数字。
如果你将输出长度翻倍，你的成本可能会翻倍。
如果你从中端模型转向高端模型，你的成本可能会跳一个数量级。
真正的教训
如果你想要可预测的利润率，工作流应该设计为：
- 保持输出紧凑
- 使用严格的JSON模式
- 避免在核心路径中生成长解释
- 仅在异常情况下路由到高端模型
8、示例2：起草销售邮件的AI代理
销售邮件起草看起来便宜，直到你扩大规模。
如果你的代理：
- 从CRM拉取上下文
- 总结公司信息
- 生成一封邮件
- 生成两个跟进
那可以轻松达到4到6次LLM调用。
如果你不加控制，输出量是巨大的。
这就是成本纪律重要的地方：
- 限制输出长度
- 生成一封邮件，而不是三个变体
- 使用模板填充变量，不要"自由写作"一切
一个好的代理系统感觉个性化而不冗长。
9、示例3：以每天$8运行一个14代理的AI工作团队
这是我们在Kloudedge Apex的真实设置。14个代理在定时cron上运行，每个处理特定功能：销售研究、外联、内容写作、基础设施监控、管道管理。
成本数学：
- 大多数代理每天运行1-3次
- 平均会话：30k-180k token（输入为主，输出精简）
- 我们使用中端模型作为默认，仅在复杂推理时使用高端模型
- 每日LLM总支出：约$8
这是一个完整自主工作团队每月$240。与一个每月$5,000只能做这些工作中一项的初级SDR相比。
关键的成本杠杆：
- 严格的输出模式（代理返回结构化JSON，不是文章）
- 共享状态文件（代理读取彼此的工作而不是重新研究）
- 基于cron的调度（没有空闲计算，代理只在需要时运行）
- 分层模型路由（分类任务使用廉价模型，方案写作使用高端模型）
10、隐藏的账单：长上下文不是免费的
代理工作流喜欢上下文。
它们想要：
- 整个PDF
- 整个邮件线程
- 整个工单历史
- 整个政策文档
- 整个代码库
这通常是不必要的。
在生产中，你通过严格控制上下文来获胜：
- 总结一次，重复使用总结
- 只检索top-k相关块
- 使用嵌入进行召回，而不是巨大的提示
- 缓存中间产物
换句话说：你不为智能付费，你为token付费。
11、RAG实际上在哪里省钱
人们把RAG说成是准确性工具。
它也是一个成本工具。
如果你检索你需要的10个段落而不是粘贴40页，你节省了token并使模型更可靠。
这就是为什么我们依赖：
- PostgreSQL + pgvector嵌入
- 编码建议的短候选列表
- 结构化输出而不是开放式散文
RAG不仅仅是"更好的答案"。它是"更便宜的答案"。
12、可靠性规则：确定性检查比重试更便宜
每次重试都是成本。
所以你需要在模型周围设置确定性检查：
- 根据模式验证JSON
- 验证总额（小计 + 税 = 总计）
- 验证日期
- 根据已知供应商验证供应商名称
当检查失败时，不要盲目重试。
路由它：
- 请求缺失的字段
- 升级到人工审核
- 或回退到更强的模型
这既省钱又改善用户体验。
13、一个实用的KPI：LLM成本占收入的比例
对于大多数SaaS产品，计算不是最大的费用项。
问题是：随着你的增长，它是否保持合理？
我喜欢的一个简单KPI：
LLM成本 / 收入
如果你按发票收费，你可以干净地计算这个。
示例逻辑：
- 如果你每月收费$2,000
- 客户每月处理2,000张发票
- 你的AI成本是$0.15/张发票
- 那就是每月$300的LLM成本
那是收入的15%。
然后加上OCR、存储和基础设施。如果你的总销售成本保持在30%到40%以下，你有一个非常健康的SaaS。
如果你的LLM成本开始攀升，杠杆是清晰的：
- 减少输出
- 减少调用
- 提高首次通过准确率
- 将更多工作推给廉价模型
14、结束语
代理式AI是一个利润率纪律游戏。
"代理"不是魔法。它们是调用模型的软件系统。
如果你想要持久的生产系统，你需要两件事：
- 工程纪律：路由、验证、缓存、检索
- 经济纪律：每份工作的成本、分层策略、浪费因子
如果你做了这两件事，你可以构建既强大又盈利的系统。
这就是真正的解锁。
原文链接：The Unit Economics of AI Agents: How I Budget LLM Costs in Production (With Real Numbers)
汇智网翻译整理，转载请标明出处