> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # AI 智能体的单位经济学 - URL: https://www.hubwiz.com/blog/the-unit-economics-of-ai-agents/ - Published: 2026-05-19T14:14:56.000Z - Updated: 2026-10-13T15:54:47.000Z - Description: 这篇文章是我如何思考LLM驱动工作流的单位经济学的实用拆解。这不是理论。这是一个你可以直接使用的预算模型。 - Author: admin - Tags: AGENT, #Import 2026-10-14 14:41 大多数"代理式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支出来自五个方面： 1. **上下文大小**：你向模型发送了多少内容 2. **输出大小**：模型生成了多少文本或JSON 3. **调用次数**：每份工作你调用LLM多少次 4. **重试和回退**：因为解析失败或置信度低而重新运行的频率 5. **模型层级选择**：你调用高端模型还是廉价模型的频率 如果你控制了这五件事，你就控制了你的利润率。 ## 4、三层模型策略（廉价、优质、高端） 我见到的错误：团队选择一个前沿模型并用它做所有事情。 这就像花钱请高级工程师来重命名文件和格式化JSON。 对于生产环境，你需要一个三层策略： **第一层：用于高数量、低风险任务的廉价模型** **用于：** - 格式化 - OCR干净时的轻量提取 - 有严格长度限制的摘要 - 分类 目标：保持大部分流量的单位成本较低。 **第二层：用于大部分实际工作的中端模型** **用于：** - 核心提取 - 合理的推理任务 - 起草简短的面向客户的文本 目标："默认引擎"。 **第三层：用于异常和困难案例的高端模型** **用于：** - 奇怪的发票 - 边缘情况 - 高价值客户 - 任何失败代价高昂的情况 目标：高端模型的使用应该只占总调用的一小部分。 如果你做对了，高端质量是可用的，但它不会整天烧掉你的利润率。 ## 5、预算工作表：估算每份工作的成本 这是数学的最简单版本。 你需要四个输入： 1. 每次调用的平均输入token 2. 每次调用的平均输出token 3. 每份工作的调用次数 4. 每百万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是一个利润率纪律游戏。 "代理"不是魔法。它们是调用模型的软件系统。 如果你想要持久的生产系统，你需要两件事： 1. **工程纪律**：路由、验证、缓存、检索 2. **经济纪律**：每份工作的成本、分层策略、浪费因子 如果你做了这两件事，你可以构建既强大又盈利的系统。 这就是真正的解锁。 --- 原文链接：[The Unit Economics of AI Agents: How I Budget LLM Costs in Production (With Real Numbers)](https://medium.com/@KloudedgeApex/the-unit-economics-of-ai-agents-how-i-budget-llm-costs-in-production-with-real-numbers-3f53dfe4bc9d?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)