Agent 产品和聊天机器人最大的区别，是它替用户把事办完了。既然办完了一整件事，按 token 收费就显得荒谬——用户不关心你烧了多少 token，只关心事有没有成。业界已经开始出现「按任务/按结果收费」的模式，Manus 这类通用 Agent 本质就在往这个方向走。但按结果收费听起来性感，落到合同里全是坑。本文把必须写死的三件事讲清楚。
第一件事：到底什么才算任务「完成」？
按结果收费的死穴，是双方对「成了」的理解不一致。用户说「帮我订一张去上海的机票」，Agent 订了一张早班机——这算成了吗？用户想要下午的，Agent 说任务状态是成功。如果合同里不定义完成标准，这种纠纷每天都会发生。
正确做法是把完成标准写成可机器判定的条件：是否出票成功、航班时间窗、是否满足预算上限。满足全部条件才算计费，缺一条都退单重跑。VulcanBench 那类按任务统计成本的方法，本质就是在做这件事——把「成没成」量化。
第二件事：任务失败的成本算谁的？
Agent 跑失败是常态，不是意外。问题是：跑失败烧掉的 token 成本，算谁的？如果算用户的，用户跑十次失败九次，账单比成了还贵，立刻弃用；如果算你的，一个死循环任务能把你烧穿。
合同里必须写：失败任务不计费，但设一个重试上限（比如三次）。超过三次还没成，双方一起排查，不再单方面烧钱。这个上限就是你成本的保险丝。
第三件事：什么事不归 Agent 管，边界在哪？
按结果收费最大的风险是「结果范围无限大」。用户说「帮我把这个季度的报表搞定」，Agent 到底是只拉数据，还是要写分析、要发邮件、要通知领导？范围不清，你就是在签一份开口合同。
合同里要列清楚：包含哪几步、不包含哪几步、需要用户人工确认的节点在哪。每多做一步，单独计价。Manus 这种通用 Agent 之所以贵，就是因为它边界模糊——你以为它会自己搞定，结果它卡在每个需要确认的地方等你。
按结果付费到底能不能走通？
按结果收费是 Agent 商业化的终局方向，但它不是改个价格表那么简单，而是把你的产品重新变成一份可定义、可审计、可限定范围的服务。合同写不清楚的 Agent，定价模式再新潮也会被退款和纠纷拖垮。