本文内容
AI 智能体工时加人工工时：客户为什么应该追问账单
软件公司说，AI 能让开发更快。但报价单上却多了几行：开发人员工时、AI 智能体工时，以及额外的人工审核费用。
这样更透明吗？可能。对客户更划算吗？未必。
多一个计费时钟，不代表账单更公平。如果你购买的是能正常使用的软件，不设上限地叠加 AI 运行时间和人工工时，就不是合理的默认选择。你的支出取决于供应商如何工作，而不是最终交付了什么。
Wavect 的观点是：先约定成果、质量标准和费用边界，再由交付团队选择工具。客户不应该为了确认价格合理，还得审计供应商的内部工作记录。
资料核查日期：。定价评价属于 Wavect 的分析。公开案例能证明有人采用或推广这种收费方式，不能证明它有多普遍。下文计算是示例，不是客户实绩或供应商报价。
真的有人同时收取 AI 工时和人工工时费用吗？
LeoTech Services 公开列出两种开发费率：工程师每小时 120 美元，AI 智能体每小时 10 美元。它包含工程师验证，并将这种模式解释为向客户传递 AI 带来的节省。
另一个案例来自顾问 EJ Bantz 在一篇介绍自身计费方式的帖子中表示，AI 运行时间和会议时间均按每小时 65 美元收费，客户可查看自动生成的记录。
Keito 的专业服务指南也明确介绍了把不同费率的人工工时与 AI 工时放在同一张账单上的方式，同时将按成果计费列为另一种选择。
这些证据是当事人的自述和计费工具供应商的建议，不是独立的行业采用率调查，也不能证明某家供应商收费过高或交付质量差。
AI 智能体工时计费，是指按照自动化智能体的运行时间收费，单独计费或与人工费用叠加。合同必须说明，一小时究竟指实际经过的时间、有效计算时间、预留资源时间，还是估算的人类等效工时。这些不是同一种商品。
为什么 AI 工时计费不适合作为软件采购的默认模式？
1. 账单可能上涨，成果却没有改善
智能体多运行一小时，可能发现严重的安全漏洞，非常值得。也可能只是反复尝试一个已经失败的方法。运行计时器对两者一视同仁。
问题不是所有额外运行都有浪费，而是运行时间本身无法说明，这项额外工作是否值得客户购买。没有验收标准、重试限制和预算上限，客户就承担了过多的执行风险。
在 2025 年 6 月发布的研究系统说明中，Anthropic 报告其多智能体系统的 token 用量约为普通聊天的 15 倍。这是特定系统的历史数据，不是所有智能体的成本倍数，更不是软件公司的合理加价标准。
我们的商业判断是：既然供应商选择架构，就应当对增加的复杂性是否创造了价值负责。
2. 并行智能体可能让计费时间成倍增加
如果合同累加每个智能体的运行时间，十个智能体同时运行两小时，就可能产生二十个可计费的智能体工时。对客户而言只过去了两小时。无论哪个数字，都不能证明功能通过了测试。
并行工作可能很有价值。但供应商不应该仅仅因为启动了更多执行单元，就能收取更多费用。应当事先明确谁批准并发数量，以及重复或最终被放弃的工作是否计费。
在 Anthropic 于 2026 年 8 月发布的协作实验中，多个智能体连续执行了 12 小时的游戏开发任务。即便较新的模型更成功地整合了代码，该测试中的最终产品仍然表现不佳。更多活动得到整合，不等于产生了可用成果。
3. 客户可能既支付生成费用，又支付返工费用
人工审核是必要工作，并非天然不合理的额外收费。关键在于责任：约定范围内的缺陷由软件公司负责修复，还是每次失败生成和后续修改都由客户继续付费？
薄弱的安排会把初次生成、审核、修复和再次尝试全部计费，却没有停止规则。更合理的安排会把达到约定验收标准所需的测试和修复包含在交付承诺内。
新增需求则是另一回事。改变期望的软件行为，可以重新报价。但原有要求没有达标，应按事先约定的缺陷处理规则解决，不应该自动变成额外范围。
4. 一个智能体工时不等于一个人工工时
工程师可能在审核一个任务时，让智能体执行另一个任务。繁忙的日志不能证明发生了两小时的人工劳动，也不能证明两小时的运行时间都是有效计算。
METR 在 2026 年 2 月发布的研究设计更新指出，并发使用智能体会使任务耗时更难测量。样本选择问题也使其后续研究无法可靠估计当时的生产率。这意味着应当测量自身工作流程，而不是重复引用过时的提速或减速结论。
因此，两家供应商即使报出相同的智能体小时费率，卖的也可能是完全不同的能力。应比较验收范围、质量、总费用风险和交接内容，而不只是小时单价。
5. 成本可见，不代表所有成本都应该转嫁给客户
记录 token、运行时间和人工投入，有助于软件公司管理业务。但不是每一条内部记录都应该成为客户账单上的收费项目。
要区分实际支付给模型供应商的费用、共享订阅的内部成本分摊，以及供应商收取的托管服务费。明确约定后，这些都可能合理，但不能混为一谈。按 API 标价估算的使用价值，也不自动意味着在已付订阅费之外又产生了一笔真实支出。
关于这些区别，可以阅读我们的AI 实际账单与内部成本分摊指南。本文讨论的则是采购问题：客户究竟应该同意购买其中哪些投入？
算一笔账：同一个功能，两套时钟，不同的费用
假设需要开发一个范围明确的客户数据导出功能，包括实现、访问控制、测试和交接。以下是虚构的商业场景，以欧元计价且不含增值税，不是市场行情或 Wavect 报价。三种情形的功能范围和验收标准相同。
| 情形 | 人工投入 | 智能体运行 | 总额 |
|---|---|---|---|
| 最初的按时计费估算 | 20 小时 × €150 = €3,000 | 40 小时 × €15 = €600 | €3,600 |
| 范围不变，但增加重试和修复 | 28 小时 × €150 = €4,200 | 120 小时 × €15 = €1,800 | €6,000 |
| 预先约定的验收交付价 | 范围内已包含 | 范围内已包含 | €4,500 |
第二种按时计费情形，比最初估算多出 €2,400，增长 66.7%。固定交付价比顺利完成的第一种情形贵 €900，但比出现重试的第二种情形便宜 €1,500。
这才是应当说明的取舍。为成果负责，不保证账单永远最低。客户可能需要为明确的结果和更清晰的风险边界支付一定溢价。
固定价格仅在约定前提和范围内成立。需求变更或明确排除的第三方费用，需要单独批准。设有真实费用上限的工时合同也可以限制支出。只有固定价格，却没有验收失败后的补救安排，并不保证项目能完成。
软件开发中的按成果定价，到底应该是什么意思？
对于范围明确的软件交付，按成果定价应把约定费用与清晰、可验证的结果挂钩，并明确验收失败后的处理方式。本文所说的是按通过验收的交付物定价，不是承诺软件公司能保证你的收入、产品市场匹配度或所有后续商业收益。
| 模式 | 客户购买什么 | 必须明确什么 |
|---|---|---|
| 人工工时 + 智能体工时 | 特定投入或资源能力。 | 计量定义、费率、上限、时间重叠以及可计费的重试。 |
| 固定价格的验收交付 | 满足约定测试的明确功能。 | 验收、包含的质量检查、依赖条件、补救措施和变更。 |
| 商业绩效收费 | 与测得的商业改善挂钩的付费安排。 | 基线、归因、测量周期、排除事项和争议处理。 |
固定月费并不自动等于按成果计费。按生成的代码合并请求、关闭的工单或输出的文档收费，也未必算。没有质量标准，只是把运行时钟换成了另一种活动计数器。
Intercom 的 Fin 文档列出，在 Intercom 中使用时，聊天和邮件问题解决每次收费 0.99 美元，包括系统推定已解决的情况；配置好的流程转交也可能计费。如果客户回到同一对话继续求助，之前的问题解决费用会被撤销。
这并不说明这种模式有错，而是说明“成果”这个词本身没有定义成功。要看清成果如何认定，以及什么情况下撤销收费。
关于按工时、固定价格与分阶段交付的全面比较，请阅读现有的软件项目定价指南。
按成果报价，客户应该要求写清哪些内容？
先从可以演示和验收的小成果开始。以前面的数据导出功能为例，采购要求可以这样组织：
| 边界 | 开工前应当约定的内容 |
|---|---|
| 可用成果 | 获得授权的用户能够以指定格式导出约定的客户字段。 |
| 功能验收 | 列明测试用例，覆盖空数据、约定数据量、特殊字符和导出失败。 |
| 安全与性能 | 未经授权的用户不能导出数据；明确响应时间目标、数据集和测试环境。 |
| 证据与审核人 | 提供可运行演示和测试结果，指定客户审核人并约定审核期限。 |
| 价格与付款 | 约定里程碑价格、付款日期、包含的审核和重试，以及需另行批准且有上限的费用。 |
| 失败与变更 | 明确修复、复测、缺陷未解决时的补救方式，以及真正新增需求的审批流程。 |
| 交接与依赖条件 | 明确代码仓库访问、代码权利、文档和部署资料；列出需要客户提供的权限、数据及决策。 |
不能因为智能体说“完成了”，就认定成果通过验收。客户也不应以没有边界的“继续改好一点”无限推迟验收。双方都需要可测试的标准，以及处理分歧的办法。
大型项目可以逐个为范围明确的里程碑定价。未知问题应通过需求梳理、有预算上限的实验或范围清楚的持续服务处理，而不是藏进一个看似保证成功的整体转型承诺。
如果购买的是持续运行的智能体服务，而非开发里程碑，可以参考我们的 AI 智能体 SLA 模板，了解服务水平测量和补救安排。
什么时候分别收取 AI 使用费和人工费用是合理的？
当你明确购买两项不同的服务、理解计量规则，并且能够控制预算时。支付基础设施费用，同时支付管理它的人员费用，本身没有问题。
例如，AWS AgentCore Runtime 定价区分活跃 CPU 消耗与内存消耗。等待输入输出时不收取活跃 CPU 费用，但内存仍可能计费。这里出售的是定义清晰的基础设施资源，而不是承诺的软件交付成果。
客户自有的生产环境智能体，按实际业务需求产生的模型费用，可以合理地排除在开发费之外。另行约定的人工支持也一样。但应设置支出限制、明确费用归属、审批超额支出，并避免同一成本重复回收。
面对研究或突发故障，有预算上限的人工工时服务，可能比假装事先知道最终答案更诚实。有时你真正需要的就是预留产能。采购错误在于：实际上购买了投入，却以为自己买到了保证通过验收的成果。
我们的 AI 智能体单次操作成本指南解释运行账单。本文重点讨论的是软件公司的合同将哪些费用转给客户。
Wavect 如何为交付成果负责？
对于 Wavect 范围明确的软件交付，起点是清晰的成果、固定价格和签署确认的范围。人工判断、实现以及约定的质量检查，都属于交付承诺。客户应当评估成果，而不是重新核算我们的内部工时表。
如果优先级仍在变化，我们也提供可按周取消的持续服务。这是要求持续交付进展的服务安排，不是纯粹按单个结果付款的合同。退款条件与办理流程，以所选方案和协议为准。
这里必须说明一个不能被口号掩盖的例外：我们的公开定价也包含预付开发人员工时。购买明确数量的人工能力，与接受没有上限的智能体运行附加费不同。本文并不声称 Wavect 从不按时间提供服务。
我们的立场更具体：当你委托我们交付约定的软件成果时，商业模式应该奖励成果交付，而不是奖励可计费投入的增加。
AI 提高效率，可以改善我们的利润。这是合理的。客户应得到有竞争力的价格、约定质量、明确的交付责任和可用的交接资料。供应商不必通过增加机器工时账单，才能获得合理利润。
批准 AI 费用之前，先问五个问题
- 我究竟在购买什么？通过验收的软件、人工产能、预留基础设施，还是运行时间？
- 什么会让账单上涨？确认并发、等待、重试、审核、失败和超额费用。
- 没有达到约定结果，谁付钱？区分缺陷修复与真正新增的需求。
- 我的最大费用风险是多少？要求固定里程碑价格或具有约束力的上限，额外支出必须审批。
- 如何验证成果并接手软件？在开工前明确测试、证据、访问权限、交接内容和补救安排。
购买通过验收的进展，而不是更长的工时表
AI 智能体不是免费的，人工审核也不应该被忽略。真正的问题在于：供应商同时控制运行方式和不断增长的计费时钟，而客户却没有得到明确的交付承诺。
对于范围明确的软件工作，更好的默认安排是：先约定什么算完成、如何证明完成，以及结果不合格时怎么办，然后给这项交付定价。
AI 应当让供应商更高效地兑现承诺，而不是创造一种新的方式，让客户承担执行不力的费用。