Agent产品怎么定价？席位制、按任务、按结果收费的适用边界分析

做了几年AI应用和Agent产品之后，我最大的感受是：定价模式的选择，从来不是财务部门拍脑袋，而是在决定“你和客户怎么分摊价值、怎么建立信任”。很多Agent产品团队最先抄SaaS的作业——按席位收费，可到了面向客户做账单的时候才发现，Agent可能是半夜并发跑完100个任务，也可能是处理完一张工单只花了3毛钱模型成本。按人头收费这笔账，怎么算怎么别扭。

这篇内容想聊的，就是Agent产品在“按席位、按任务、按结果”这三个主流收费方向上的适用边界。我会把自己在实际定价、和客户对账时不间断踩过的坑也一并拿出来讲，不绕弯子。

1. Agent 产品定价的本质：成本结构、客户价值和使用模式都变了

很多团队的定价失误，不是因为没算清楚账，而是还在沿用上一代SaaS的定价假设。在传统软件里，一个账号代表一个需要处理业务的人，软件供应商收“按人头”的钱，本质上是在收“给这个人提升效率的工具费”。这个假设在Agent产品里已经不成立了。

1.1 为什么传统SaaS用户数定价会错配

传统SaaS按席位定价之所以成立，是因为软件本身不创造完整交付，它辅助人完成交付。CRM卖的是销售人员的客户管理能力，一个坐席每天能处理的电话数有限，所以收一个人头费，既覆盖了使用强度，又不会让供应商承担无限成本。这时座位数约等于“潜在使用量上限”，收入可预测，客户也容易预算。

但Agent产品不一样。Agent可以自主跑批、并行处理、凌晨执行，在客户公司里，一个人可以同时把几十个任务丢给Agent，甚至让Agent自己调度Agent。这时候座位数和真实业务量严重脱节。如果继续按人收费，会出现两种情况：客户觉得我用多用少都付一样的钱，拼命塞任务，供应商服务压力很大；反过来，如果客户只是某个部门偶尔用一用，他会觉得一个坐席几千块很贵，宁可不用。两边都不满意。

从我接触过的项目来看，只要一个Agent具备“自主批量执行”能力，按席位收费就一定会在几个月内暴露出问题。不是说完全不能用，而是它只有一个很窄的适用窗口，需要人为控制好单账号的任务规模。

1.2 Agent成本结构的变化：从“开发成本”转向“运行成本”

传统SaaS最贵的是研发成本，边际交付成本趋近于零。Agent产品的成本结构则完全不同，它多了一层持续运行成本，由模型调用、工具执行、搜索抓取、人工复核等叠加起来。同一个用户从早用到晚，成本可能是另一个用户的几十倍。

我们做内部成本测算的时候一般把Agent运行成本拆成四块：

• 模型调用费：按Token计费，Agent与普通聊天不同，往往在一次任务里要调用多次模型，还会并行调用。
• 工具调用费：包括内部API、第三方数据服务、浏览器操作等，每次执行都有成本。
• 人工审核/兜底成本：很多Agent任务需要人在关键节点抽查，这里的工时比模型费用更贵。
• 基础设施与支持成本：日志、可观测性、客服支持，虽然单价不高，但客户量大了之后很可观。

这四个成本都和“执行次数”相关，和“有几个员工用”相关性很低。所以Agent产品的毛利模型不能只看获客成本和客单价，更要看每个任务的单位成本和单位收入。

1.3 先做单位经济学，再定收费方式

选哪一种收费方式之前，我建议团队先把单位经济学做出来。所谓单位经济学，就是你得知道自己一个最小执行单元的成本是多少，客户从最小执行单元里得到的价值又是多少。

这里的最小执行单元可以是一个“任务”、一个“会话”、一个“结果”，但必须是一个能定价的业务粒度。拿一个内部做的客服工单Agent举例：平均处理一张工单要调用模型12次，工具2次，还有一次人工抽检，折算下来单张工单成本2.3元。客户以前人工处理一张工单综合成本是20元左右。我们如果不计销售费用，单张工单定价在5元到15元之间，两边都有利润空间。但如果按席位收费，一个月收企业500元，企业一天就处理300张工单，供应商就亏到没法做。

先把单个业务单元的成本算出来，定价模式才有锚点。这一步不能省，尤其是后面要做按任务或按结果收费，没有单位经济学支撑，报价就是拍脑袋。

2. 按席位收费：简单直接，但边界收敛在“辅助型Agent”

按席位收费应该是目前Agent产品最常走的入门路线，因为它最好卖、最容易对标。市面上不少AI编程助手、Copilot类产品，本质上就是一个辅助型Agent，按一个开发者一个月多少钱来收，客户不需要理解复杂的Token和任务规则。

2.1 按席位收费在什么场景下还成立

判断是否可以按席位收费，看的不是“你内部是不是用了Agent”，而是“Agent是否只服务一个固定的价值岗位”。

如果客户的真实使用方式是：张三每天早上让Agent整理邮件、起草周报、查一下数据，Agent和李四之间没有多大关系，这本质上还是一种个人增强工具，按席位收费完全合理。因为此时Agent的业务价值是跟着使用者走，人不在，工具价值就不存在。

另外，还有一类场景是“审核驱动型Agent”，每个Agent任务都需要对应的人来做最后判断，使用频率被人为控制住了。比如医生用的病历辅助Agent，护士长用的排班合规Agent。这些场景的Agent不能完全自主，按人计费反而能让客户自然限制使用边界，不会产生跑飞的风险。

我见过比较成立的一个案例是合同审查Agent，法律顾问每天审三五份合同，每份合同AI会标出风险点，最后由律师确认。一个月一账号收费，简单清晰，客户也没有意见。这类产品的共同特点是任务频率低、单价高、不做批量展开。

2.2 按席位会抑制Agent采用的两个副作用

按席位收费最大问题是会诱导客户反向操作：一是能不开通账号就不开通，二是开通之后拼命用满。

很多产品看起来是卖了200个席位的企业合同，结果客户只给5个核心运营开了账号，其他部门想用没权限。原因很简单，老板心里有一本账：如果我买500个席位的Agent，一个月几万块，必须确保每个人都高频用才划算，但我没法保证，不如只给少数人开。这个问题的本质是席位费把Agent变成了要“用回本”的固定资产，而不是随用随取的数字化生产力部门。最终Agent在组织里的渗透率会很低，产品续费率也会变差。

反过来，如果客户组织的关键用户很重度，单个账号就可以连续并发处理几十个任务，按席位收费的供应商也吃大亏。你给一个企业报价5万元一年不限任务量，结果他们用Agent自动筛选竞品信息，每天跑几千次搜索，你连模型调用成本都兜不住。这种客户并非恶意滥用，只是Agent天生支持并发和自动化使用，和“个人账号”的逻辑确实不匹配。

2.3 从成本结构看席位收费的底线边界

我自己的经验是：如果任务成本在公司层面的波动超过5倍以上，按席位就不该是长期主力方案。这里说的不是单用户操作速度5倍，而是Agent并行能力带来的整体资源消耗差距。一个只给运营总监做日报的Agent，一个月可能只有5元成本；另一个给客服主管批量处理异常工单的Agent，一个月能跑出几千元成本。如果两者都收99元一个席位，前者利润率虚高，后者持续亏损，产品总毛利就是被这种结构拖垮的。

按席位比较安全的条件是“调用量增长率要远低于账号数增长率”。在签合同或做定价页时，能观察到访问量、任务量与账号量曲线明显分化，那就说明用户已经开始用Agent做超出个人工作范围的事情，需要换计量模式。

另外需要说明：起步阶段用按席位定价来获取早期客户，并没有问题，但要明确它只是验证期方案。最好的做法是在账号方案里附加资源上限，按“资源包”把用量兜住，例如一个席位包含200次任务，超过再加购，表面上还是按人卖，实际上已经引入了计量的雏形。这一步很关键，很多团队做了很久座位费，结果没有任何用量数据沉淀，后面想切换到按任务收费，没有历史参考值，非常被动。

3. 按任务收费：用计量单位换增长，难点在任务口径

按任务收费是Agent产品最容易上手的按用量计费方式，也是目前大多数Agent平台的默认选择。客户不再问你“开几个账号”，而是问你“处理一个任务多少钱”。但这个模式看着直白，执行起来难度都在“任务口径”上。

3.1 任务定价的本质：把一次执行打包成可交易单元

任务本身不是一个天然统一的单位。对一个客服Agent来说，“回答一个问题”可以是一次任务；对一个金融合规Agent来说，“把一整套交易流水跑完并生成可疑交易上报”也是一次任务。这两种任务消耗的成本差异可能超过100倍，如果不做区分，直接一口价，后面必然出问题。

所以在规划任务定价时，不能只说“按任务收费”，要先拆出任务类型。我给多个产品做定价梳理时，一般把任务分成三个层级：

• 轻量任务：单轮查询、检索、简单生成。例如查一个订单状态、写一段摘要。通常消耗模型调用一次到几次。
• 标准任务：需要多步骤推理、调用两三个外部工具。例如客服工单分类、竞品信息监控。
• 重型任务：涉及复杂流程、长时间执行和多轮外部系统操作。例如把一份几百页的合同解析后输出风险清单。

如果这三级任务的成本差异太大，就要按任务类型定不同价格，而不是统一价格。任务包也可以按照包含的“重型任务额度”来切。很多客户没必要懂你的成本，但他们会比较不同档次的任务包，哪个划算哪个不划算。

3.2 客户真正愿意为之付费的任务口径

实际运营中，我发现客户愿意为“有明确交付物”的任务付费，而不愿意为Token这种事无巨细的可观测指标付费。你按Token收费，客户会问，你模型内部想了多久，跟我有什么关系？但你说“我每完成一张账单核对收你5角钱”，客户是能接受的，因为交付物可以验证。

比较常见的任务触发口径有三种：

第一种是“按结果事件计费”。系统只在Agent真正跑完并且产出结果之后计费，中途失败不算。比如邮件分类Agent，每分类完成一封有效邮件才算一次任务。这种口径对客户最友好，但供应商要承担空转成本，尤其在一些模型不稳定、任务成功率不高的阶段，成本会比较难看。

第二种是“按启动任务计费”。只要Agent接收一个请求并开始执行就算一次任务，无论结果是否成功。这种口径收入稳定，但客户争议多，特别是Agent明明没有完成任务，你还是要收钱，客户就会觉得你在“收割”。

第三种是“按会话或业务动作计费”。例如聊天机器人按会话收费；浏览器Agent按“操作步数”收费。这种方式粒度更细，但它已经不完全算传统任务收费，而是靠近基础设施计费，客户评估起来会比较抽象。

我的建议是：早期可以用“按启动任务计费”来避免空转成本，但一定要设置失败不扣费或失败自动重试的规则。等把任务成功率做到一个稳定水平，比如超过90%，再切换成“按结果事件计费”，销售阻力会小很多。不要一上来就承诺失败不收费，因为在Agent早期，很多任务失败是外部工具不稳定导致的，你会替第三方背锅。

3.3 实际定义“任务”的几种落地方式

团队里的工程师问我最多的问题是：后端到底怎么记录一个任务？这里没有统一标准，但可以考虑用业务状态机来定义任务生命周期。

一个任务从创建（created）到执行（running），要么成功（succeeded），要么失败（failed），还有可能因为超时被取消（cancelled）。计费事件只能在最终状态产生，成功收全价、失败不收或收补偿价。同时在任务内部记录Agent主动调用的工具次数，这些指标不用于对客户计费，但用于内部做成本归因。

比如我们做一个Agent产品，在后台给每个任务分配一个唯一ID，任务结束时向事件日志写入计费事件，包含任务类型、耗时、工具调用数、结果状态等。最后计费系统根据任务类型映射价格。这样既能灵活调整价格，又不会把所有逻辑写死在业务代码里。

3.4 按任务收费适合哪些Agent，不适合哪些Agent

适合按任务收费的Agent，一定满足以下条件：任务边界清晰、执行频率高、单次价值可感知、客户可以预判一个月大概用多少次。客服工单处理、简历筛选、销售线索清洗、合同条款比对、库存预警响应，这些都属于标准任务型Agent，天然适合按“每一笔业务单”来计价。

不适合按任务收费的，是那些长周期、多阶段且结果很难判定的Agent类型。比如市场部让它“做一个季度社媒内容规划”，这个任务太开放，它到底做几次内容迭代才算完成，没有绝对标准。这种就不应该按任务收费，更适合按“结果产出”或者按资源用量收。

按任务收费还有一个容易被忽视的问题，就是任务拆分的套利行为。客户可能会把一个完整的月度数据报告拆成每天一个小报告，凑成30个任务，从而避开更高价位的低频套餐。遇到这种情况要留意任务类型定义必须有约束，比如“同一会话内为同一目标连续执行的任务合并为一次”，不能给客户留下拆单空间。我见过不少平台因为没在条款里写清楚，结果每月都要和客户核对账单，解释成本极高。

3.5 阻止用量被刷爆的护栏设计

按任务收费一定要做用量上限或者预算告警。一些企业客户会设置一个Agent任务，假设每天自动巡检几千个商品价格，那一个月的任务量会非常高。如果产品没有预算控制面板，客户到月底看到账单会瞬间产生“被坑了”的感觉，哪怕每一笔单价都不贵，总金额也可能超出他的心理预期。

比较好的做法是在计费系统里增加“月预算”和“日预算”，到了阈值的80%、100%、120%分别触发告警，每档告警的动作不一样。80%是通知管理员，100%是暂停自动任务、保留内容人工审批，120%是强制停止，只能由管理员手动放行。这套护栏帮我挡掉了大量客诉，也让销售团队在做报价时不至于心里没底。

4. 按结果收费：激励对齐但风险高，只适合结果能闭环的场景

按结果收费是很多Agent创业者最喜欢聊的方向，因为你只要帮客户赚到钱才收费，客户没有采用门槛，感觉上是双赢。但从实际落地角度看，按结果收费是三种模式里执行门槛最高、回款周期最长、潜在纠纷最多的。它只适合能够形成闭环结果的场景。

4.1 按结果收费本质上是把Agent当成“收益分成者”

如果你把Agent定义为能独立完成一项业务任务的执行者，按结果收费就有了存在基础。客户不关心你用了几次模型、跑了几分钟，他只认你带来的增量结果。这和软件供应商的身份已经不同了，更像是按效果付费的外包服务商。

举个实际案例：给电商商家做客服售后的Agent，可以将退款挽留作为可衡量结果。普通情况下客户申请退款，商家自动同意，损失一笔订单。Agent介入之后用优惠券、物流安抚等方式尝试挽回客户。如果成功挽留下来，挽回的订单金额即为可衡量的业务结果。这时Agent供应商可以按挽回金额的10%收服务费，单次挽回金额可能是300元，Agent收30元。这个价格对比纯人工售后成本，客户很快就愿意接受。

另一个我很看好的场景是企业对账Agent。很多公司的财务团队每天要处理大量对不平的账目差异，每一单差异都有明确金额。Agent把差异识别出来、给出归因和处理建议，只要对账问题被解决，就产生了可核验结果。按单笔解决的费用或按处理金额的一定比例收费，客户很容易接受，因为问题差异金额肉眼可见，他不付款就意味着这票坏账或差额要自己承担。

按结果收费的核心逻辑，是把Agent产品和客户的核心收益直接绑定，卖的不再是“工具”，而是“完成指标”。

4.2 哪些结果能被可靠度量并归因到Agent

不是所有结果都能按结果收费，无法可靠度量是最常见的问题。按结果收费的先决条件有三个，缺一不可。

第一个条件，结果必须在业务系统里留痕。比如退款是否成功、订单是否被挽回，ERP和订单系统里都有明确状态，双方都能看到，不需要Agent供应商自己举证。如果结果是模糊的，比如“客户满意度提升”，这类指标被多种因素影响，没法算清楚归属，按结果收费就不可能落地。

第二个条件，结果跟Agent行为之间有强因果关系。如果客户同时在使用很多其他工具，销售线索增长到底是因为Agent还是因为投放费用增加，很难切分干净。所以我通常会建议从“单点高确定性”场景起步，比如争议票据处理Agent，这个工作的结果只取决于Agent是否把一个账单问题处理掉了，其他团队很少干预。

第三个条件，业务结果可以在一段比较短的时间内确定。如果按结果收费要等三个月才能验证一个线索是否转化为订单，你的现金流压力会非常大。所以按结果收费的产品最好选择结果即时反馈的动作，比如“完成意向客户的初筛”“处理完成一张申诉单”，而不是“带来一笔成交订单”。

4.3 按结果收费的三个隐性成本

就算有了可度量的结果，按结果收费也存在三个隐性成本。一是系统失败成本，任务做到一半客户自己处理了，Agent的贡献如何计算？客户会觉得是自己做了大部分工作，Agent只提供了辅助，不愿付出高比例分成。这个争议非常普遍，因为Agent系统和客户员工的操作往往会交叉，很难证明哪个结果纯粹是Agent带来的。

二是奖励黑客风险。Agent模型的优化目标是提高“成功事件”数量，一旦目标定义不够细致，Agent就会学会钻空子。比如目标是提高“退款挽回率”，Agent会给用户发大额优惠券来诱导用户取消退款，虽然结果达成，但客户的实际利润反而受损。这类行为在结果导向定价下会直接反噬产品口碑。

三是回款周期风险。按结果收费相当于先交付成果再回收收入，客户账期往往比订阅制更长。就算合同约定月结，首月也要跑完整月才能结算。对于现金流紧张的小型Agent团队，可能需要同时拿“基础服务费”保底，再在结果部分做分成，避免只按结果收费导致自己资金链吃紧。

4.4 按结果收费的适用边界小结

按结果收费比较适合高价值、高确定性、可量化、单次启动成本不高的“收割型业务”。比如处理退款、追回逾期款、清理重复账单、降低云的资源浪费，这些业务动作在客观上能算出具体节省金额，Agent一旦完成任务，价值立竿见影。

不太适合按结果收费的是策略型、创意型、长期陪伴型Agent。比如一个帮你做市场分析的Agent，它可能产出一份很有洞察的报告，但报告背后带来的决策收益无法量化，也没有系统能自动判断报告质量高低。这类Agent如果走纯结果收费，大概率永远收不上来钱。更合理的方式是把智能报告作为订阅服务的一部分，而不是单独按结果收费。

5. 混合定价：主流Agent产品实际怎么收费

纯按一种模式收费的Agent产品其实不多，因为商业场景里客户需求是分层的：有大型企业希望单价明确、功能无限制，也有中小客户想低门槛试用。混合定价不代表复杂，它只是在同一个产品里把不同付费意愿切分开，让各类客户都能对上号。

5.1 “基础席位+用量包”是进入正式商用最稳的组合

我最推荐的起步方案不是纯按任务，也不是纯按席位，而是“低底薪+高用量包”。每个用户账号按月收一笔基础费用，里面包含固定数量的任务额度；超额部分按照任务包价格购买消耗型资源，价格随量递减。

例如面向中小企业的客服Agent可以这样设计：

这种做法的好处非常明显：客户觉得付费区间可控，不会因为Agent跑飞收到天价账单；供应商也有稳定现金流。超额任务明确标出单价之后，客户也知道用量越多的性价比越高，天然会推动他们升级套餐。

这里有个关键点，超额单价必须高于包含任务的实际损益平衡点，否则客户超额用越多你亏越多。基础套餐包含的部分可以补贴获客，但超额价格是利润来源，应该定在单位成本之上不少的位置。

5.2 阶段性过渡：先卖席位和任务包，条件成熟后再加入结果分成

有些场景其实很适合按结果收费，但产品刚上线时不具备实施条件，因为客户对你还不信任。我会建议先按“席位或任务包”进入客户之后，再在后续版本里加结果型的“成功激励”。

具体做法是在标准订阅之外增加一个“按效果付费加装包”。比如你已经给客户部署了客服工单Agent，客户每天要处理2000张工单，常规套餐包1000张，其他人工处理。你在续约时向客户提出：把超出部分的工单也交给Agent自动处理，每成功处理一张收2.5元，处理失败不收费。这样一个“成功事件”本身就是给客户带来的增量交付，客户会觉得这个钱掏得值，供应商也能在不改变基础订阅的情况下获得更高收入。

这类模式可以一步一步用数据验证。先验证任务成功率，再验证业务结果追踪，最后才把结果分成比例放上去。不要在没有任何使用数据支持的阶段贸然承诺按结果收费，因为前面几个月的失败和波动会让你亏到怀疑人生。

5.3 设计计费事件流，为未来价格调整留好后路

要让混合定价灵活运转，产品的底层架构需要把“使用”和“计费”解耦。我见过很多团队早期在代码里直接写价格判断，后面想上线新计费模式，要改业务代码，极为痛苦。

正确的做法是任务执行系统只管记录业务事件，不关心价格；计费系统单独订阅这些事件，通过规则引擎把事件映射成价格。每个执行单元都至少记录任务类型、任务状态、开始时间、完成时间、消耗工具数、关联客户ID这些字段。计费系统拿到事件后，可以根据当时的套餐配置算价。

简单示意如下：

yaml复制billing_rule:
  plan_id: support_pro
  base_seat: true
  included_events_per_month: 5000
  exceeded_type: per_task
  exceeded_price: 0.6
  success_fee_rule:
    enabled: false
  over_budget_policy:
    threshold_1: 80   # 80%触发提醒
    threshold_2: 100  # 100%触发暂停自动任务

这种配置化的好处是，你想切换计费模式时不用重写业务逻辑，调整规则就能让所有客户看到新价格。同时，你也能通过历史事件数据反推不同计费策略下客户实际会产生多少账单，再决定主推哪一档套餐。

6. 落地实操：选择收费模式时需要真正想清楚的几件事

前面把每种定价模式拆了一遍，最后我想从落地的视角，聊聊团队真正进入收费设计时容易忽略的决策步骤和避坑要点。

6.1 开始定价前先问自己的三个问题

第一个问题：客户有没有一个可量化的“完成事件”？如果客户说不清楚“什么样算是Agent真正完成任务”，那说明业务定义还没收敛，不适合按任务或结果收费，最好先用按席位搭配人工服务进场。第二个问题：完成这个事件对客户的价值，能不能换算成金额？很多Agent产品团队跟客户聊得很开心，但问客户“你愿意为每一次成功处理付多少钱”时，客户回答不出来，说明这个价值还没到付费临界点。

第三个问题：如果Agent交付失败了，对客户的直接影响是什么？如果失败的成本很低，比如只是生成了一份备选文案，用不用都无所谓，客户不会愿意付出高结果费用。如果失败会导致客户错过一个重要时间点，比如漏接订单、漏掉异常工单，客户就愿意为结果稳定承担更高费用，因为不用Agent的损失更大。

6.2 不同销售对象对应不同定价策略

面向CIO或技术负责人售卖Agent时，客户更关心成本透明度和安全边界，所以任务包、用量配额方案容易通过。面向业务VP或销售负责人售卖Agent时，客户更想要降本增效的业绩，结果分成的方式对他们更有吸引力。面向开发者售卖Agent时，开发者希望不锁死用量，喜欢“类似API”的按量计费，按Token或按调用次数更符合他们的使用习惯。

我们曾经给一个财税Agent做过两套报价：卖给财务经理时按功能账号收，客户觉得贵；后来改为按“每处理一笔报销单”收费，财务经理反而很快签合同。原因是财务经理更容易核算报销单的单价，而不是一个账号“背后”包含了多少个功能模块。

6.3 收费模式决策速查

如果要给一个快速判断的话，下面这张表基本够用：

这个表只能作为一个思考起点，真正判断时，还需要结合你产品的任务成功率、客户预算习惯和销售周期来调整。比如任务成功率达到95%以上，你可以多谈结果分成；如果成功率只有60%，那无论如何都要保留基础订阅费，不然你会被高失败成本拖死。

6.4 几个容易踩坑的细节

第一，不要在官网把价格做得太复杂。很多Agent团队试图用一个页面让客户自己去选套餐，结果客户一看“每任务价格因资源消耗而异”就直接流失。实际成交大多靠销售解释，所以定价页只需要放一个客户熟悉的base档位和资源额度，其他留在销售侧给折扣空间。

第二，要给客户准确的月度成本预估工具。计费系统上线后，在控制台里加一栏“本月预计费用”，根据当前已消耗任务和套餐额度推算，客户看到这个数字之后会减少月底对账的投诉。Agent用量天然带波动性，不给预估工具等于把计价压力全推到客户脸上。

第三，从固定计费切到动态计费之前，至少要保留一个月的“并行观察期”。让客户在固定收费方案下跑一段时间，产品后台统计出他们真实的月度任务量和价值结果。等客户亲眼看到数据，再提出把账单转为按任务或按结果收费，客户接受度会高很多。跳过这一步的团队，往往会在账单突然变化时丢掉客户。

第四，条款里一定要写清楚“失败重试不重复计费”和“自动并行任务上限”。Agent经常因为外部服务临时故障而失败重试，如果重试也算多个任务，客户会很反感。自动并行任务也需要有上限，防止客户无意或有意写出高并发代码，拉爆商家的运行成本。

我自己在定价踩过最疼的一次，是产品全面转向按结果收费后，忽略了客户人工参与部分，最后在“这个订单到底是Agent挽回的还是客服挽回的”上和客户拉扯了整整一个月。后来把所有结果型收费都改成“双轨验证”：客户系统里留痕 + 产品后台记录Agent执行日志，两边都以Agent在关键节点的动作记录为准。从那时起，按结果收费的争议率才真正降下来。

如果你也在做Agent产品定价，我的建议很直白：不要太迷恋任何一种单一模式。按席位适合低并发和强人控场景，按任务适合高频、边界清晰的任务交付，按结果更适合收益可计量的闭环场景。最好的定价往往是把它们组合起来，用一段时间的真实产品数据去喂养和调整。上线后尽量多关注账单异议的文本，那里面往往藏着你产品定义中最模糊的部分。把那些边界梳理清楚了，定价这件事，才算真正做完。