AI智能体定价：该向客户收多少钱

目录

2026年8月发布。

TL;DR： 不要按小时给AI智能体项目定价。把它拆成两项：一笔固定的构建费用于搭建初始系统，一笔按月收取的维护费用于让它持续运行。构建费覆盖开发、测试和集成工作。维护费之所以存在，是因为智能体会出故障——提示词会漂移，API会变化，边缘情况会不断出现——对任何接入模型的东西来说，“完成”从来都不是一个真实的状态。省掉维护费，你一个月内就在做免费的售后支持。

【运营者视角】 我在一个咨询品牌和Pickleland（德克萨斯州普夫卢格维尔的匹克球场馆）之上运行着30多个生产环境智能体，也在这份经验的基础上为客户的智能体构建项目做过定价。我见过的最常见错误——无论是自由职业者还是代理公司都会犯——是把AI智能体当成一个网站来对待：报价、构建、交付、全款开票。智能体不是网站。它们是需要持续关注的系统，因为它们背后的东西（模型、API、客户的工作流程）一直在变。要为这个现实定价，否则你自己就要为它买单。

为什么按小时计费在智能体项目上行不通

按小时计费惩罚的是你变快这件事。你交付的智能体项目越多，积累的可复用提示词、评测集和脚手架就越多——下一个项目也就做得越快。按小时收费，每一次效率提升都在削减你的发票金额。这是反的。

它也从另一个方向惩罚客户。一个雇人做AI智能体的客户，根本无法判断某个工作流程”12小时”的报价是公道、高效还是被注了水。他们买的是一个用他们无法核实的数字定价的黑箱。这种不确定性会让客户压价、拖延审批，或者干脆雇用报价最低的那家，而不是最好的那家。

解决方法和任何产品化服务一样：按照明确的范围和结果价值定价，而不是按时间。具体到智能体项目，这意味着两个各自独立、固定价格的部分——因为构建和后续维护本质上是成本结构完全不同的两种产品。

两段式结构：构建费 + 维护月费

1. 构建费——一次性的固定价格，涵盖设计、构建、测试和部署智能体的全部工作。一次性支付，通常分两期（开工定金、交付尾款）。

2. 维护月费——从上线次月开始按月收取的持续费用。覆盖监控、模型或上游API变化时的提示词修复，以及不改变范围的小调整。

把这两者合并成一个数字，是这个细分领域里最大的定价错误。只付一次钱的客户，没有任何财务上的理由去期待交付之后还有什么；而你在一个月前就已经拿到全款的情况下，也没有任何财务上的理由继续盯着这个智能体。把两者拆开，激励关系才是诚实的：你因为让它持续运转而拿到钱，所以你就会让它持续运转。

这与我用来判断是否要构建一个自动化的框架相呼应——见AI智能体ROI：是否值得构建一个自动化。那篇文章是从买方的角度写的：一家企业该如何评估一个智能体能否收回成本。这篇文章则是同一套算法的卖方视角——那个框架里的构建成本和维护税，正是你在这里要定价的两样东西。

构建费的定价方式

按范围等级来定构建费，而不是靠猜工时。三个等级覆盖了大多数客户项目：

这些区间的前提是有一堵明确的范围墙——正是如何搭建产品化服务里讲到的那种纪律：一份书面的”包含”清单，一份书面的”不包含”清单，以及固定数量的工作流或工具集成。一个只说”给我的业务做个AI智能体”、没有明确工作流的客户，还没准备好购买一个构建项目——他们准备好的是一次范围界定通话，这是一项单独的、更小的交付物（我把它定价为500–1,000美元的固定审计费，产出的正是构建费所依据的那份范围文档）。

在每个等级内部，实际报价会因三件事而变动：这个智能体调用了多少个不同的工具、测试有多少必须用真实的、混乱的客户数据而不是干净的测试用例来做，以及失败模式的容错程度如何。一个为人工审核起草社交帖子的智能体，偶尔出错的代价很低。一个发送确认邮件或转账的智能体则不能出错——这对测试预算的影响，比对代码本身的影响还要大。

维护月费的定价方式

我把维护费设为构建费的一个百分比，而不是固定数字，因为维护成本和构建成本一样，都会随系统复杂度而变化。

maintenance_retainer_per_month = build_fee × monthly_rate

monthly_rate:
  stable integrations, low API-change risk        → 3–5%
  volatile APIs (social platforms, scraped data)   → 6–10%
  multi-agent systems, custom eval suite to keep up → 8–12%

以一个6,000美元、集成相对稳定的多步骤项目为例，这大约相当于每月250–400美元。这个数字应该和我用在自己的自动化上的维护税紧密对应——按构建成本的固定年化20%计算，换算下来正好落在3–5%这个月度区间的低端。面向客户的维护费之所以处在同一数量级，是因为背后的成本驱动因素——提示词漂移、上游API变化、上线后才浮现的边缘情况——并不会因为换了个人付钱就消失。

维护费明确不包括：新工作流、新集成或范围变更。这些要另开构建费报价。一份悄悄吸收”你能不能也让它处理一下这种情况”的维护合同，不出一个季度就会变成无偿的功能开发——这正是产品化服务为什么需要一堵硬性范围墙里讲到的那个失败模式，只不过这次发生在持续性工作上，而不是初始构建上。

把价格锚定在它替代了什么，而不是它花了你多少成本

构建费不应该靠你的工时向客户证明合理性——而应该靠它省下的人工成本来证明。在报价之前，用ROI框架里同一套人工成本计算方法，套用在客户身上：

manual_cost_per_year = time_per_instance × hourly_rate × frequency_per_year
                      + error_cost_per_year

如果客户的团队每周要花5小时在一项智能体能替代的任务上，按每小时40美元的全成本计算，那就是每年10,400美元的人工成本。一笔6,000美元的构建费加每月300美元的维护费（每年3,600美元），远不到一年就能回本，之后每年都在持续省钱。这个对比——人工成本 对 构建费加维护费——才是真正的卖点。在每一份提案里都要把它放在最前面。一个没有对比对象的价格只是一个数字；一个和它所替代的东西放在一起的价格才是一个论证。

这也自然设定了一个上限：如果被替代的人工成本本来就很小，客户就不该买一套15,000美元的多智能体系统，你也不该卖给他们。让等级和实际被替代的成本相匹配，才能让定价在两个方向上都站得住脚。

防止范围蔓延的合同条款

除了价格之外，以下四项条款是我给每份智能体构建合同都写进去的：

1. 书面定义的”完成”标准。 智能体在最终付款到期前必须通过的具体测试用例——不是”运行良好”，而是一份清单：“能正确对提供数据集中9/10的样本线索分类”，“能在不需要人工干预的情况下成功发布到已连接的Facebook主页”。含糊的验收标准是无偿额外工作最大的来源。
2. 明确写清楚的所有权条款。 客户拥有工作流逻辑和任何客户专属数据。你保留可复用的脚手架、提示词模板和评测工具，只要它们不是针对客户业务特定定制的——这与产品化服务交付系统里讲到的知识产权复用是同一个道理。提前说清楚这一点，能避免以后一场尴尬的对话。
3. 明确定义的维护取消交接流程。 如果客户取消维护，要清楚说明接下来会发生什么：智能体按原样继续运行、不再有任何修复，或者在通知期后被停用。这一点不定义清楚，就意味着你要为一个没人付钱让你盯着的系统兜底。
4. 变更请求单独定价、书面约定、且在动工前完成。 不是”到时候再说”——而是合同里写明的一个费率或单次请求的最低收费，这样每次客户要求范围变更就不用重新谈一次。

每次都会遇到的两个反对意见

“为什么维护一个已经能用的东西还要额外收钱？” 因为”能用”是一个瞬间的快照，而不是一种恒定状态。模型提供商可能会弃用或改变某个模型的行为，智能体所发布的平台可能会改变它的API，客户自己的业务也可能会改变智能体最初围绕搭建的那个工作流程。这些都不是你交付物里的缺陷——而是任何连接着外部、持续变动部件的系统的正常衰减速度。我把维护费明确定位成防止这种衰减的保险，而不是持续的”售后支持”——支持暗示着某个东西已经坏了；维护费意味着有人在它坏之前就在盯着。

“我能不能直接用无代码工具，完全省掉构建费？” 有时候，可以——我也会这么说。如果工作流程确实很简单（单一触发、单一动作、没有自定义逻辑），无代码自动化平台就是诚实的答案，我会把客户指向那类工具，而不是报一个构建项目。构建费的合理性来自真正的逻辑、集成工作，或者拖拽工具无法表达的判断力。拒绝不合适的项目，正是让你接下的那些项目显得可信的原因。

我用来运营这一切的工具

Notion ——范围文档存放在这里：包含什么、不包含什么、验收测试清单，以及所有权条款，在收取任何定金之前就与客户共享。

Airtable ——每个进行中的项目一行，跟踪构建状态、维护费的收费日期，以及每个智能体的输出最近一次被抽查的时间。

Claude 是我构建这些智能体所用的主要模型——上面的维护费定价假设的是一个价格和行为都相对稳定的模型技术栈，如果你用的是稳定性较差的模型提供商，就要相应调整月费公式里的波动性假设。

常见问题

定金应该是50%还是别的比例？

开工时收50%、按书面验收标准交付时收50%，是最简单的结构，也是我默认使用的方式。对于更大的多智能体项目（15,000美元以上那一档），我会分成三次：定金、可运行原型阶段的里程碑付款，以及交付尾款——主要是为了避免在项目中途客户突然失联的情况下，还要面对一笔巨额的最终发票。

如果客户只想付维护费，但原始智能体不是我构建的怎么办？

我会接这类项目，但第一个月的报价会更高，用来覆盖一次审计：阅读现有的提示词和代码、运行我本来自己会写的验收测试，并把发现的情况记录下来。你不能在没有验证过、也不是自己构建的系统上，负责任地承诺一份维护合同——审计月正是把未知数变成真实数字的那一步。

我怎么知道我的月费比例假设（3–12%）定低了？

用一个季度的时间，把实际花在维护上的工时和维护费收到的钱做对比。如果你持续花的时间比维护费能覆盖的更多，就在续约时提高费率——不要默默把差额吞下去。这个公式是一个起点，校准自我用在自己智能体上的同一套维护税逻辑；你实际的API变动频率和客户对边缘情况的容忍度会让它上下浮动。

范围界定通话需要单独的合同吗？

对于超出简单通话的情况，需要——把范围界定审计定价为它自己独立的小型交付物，有自己的书面产出（范围文档），即使你打算在客户继续推进构建项目时把这笔费用抵扣进构建费里。这样能防止范围界定这个阶段本身变成无偿的销售工作。

下一步： 我的AI Agents for Beginners课程涵盖了这套定价框架所假设你已经能够交付的智能体构建能力。协作项目面向想要在结构化环境中构建并为这类工作定价的运营者。如果你更希望先让别人帮你完成审计和范围文档，预约一次30分钟的会谈。