上一篇完整拆了Operon的技术架构，这篇换个话题，聊一个我最近越想越头疼的纯技术问题：多agent工作流里的分账。

场景很简单：用户付了100块，让三个agent协作完成一个任务。Agent A做数据采集，Agent B做分析，Agent C出报告。任务完成了，用户很满意。

然后问题来了——这100块怎么分？

你可能觉得这不就是个简单的分成协议吗？提前约定好比例不就行了？

没那么简单。

---

为什么传统的分成模型在agent场景里不好使

问题一：贡献不对等，但很难量化。

A花了2秒钟调了一个API拿回一堆数据，B花了30秒做了复杂的分析推理，C花了5秒把分析结果套了个模板生成报告。

按时间分？那B拿最多，但可能B调用的是一个很贵的frontier model，成本也最高。按成本分？那只是在报销成本，不是在分配价值。按"谁的贡献对最终结果影响最大"分？这个判断本身就是主观的——没有B的分析，C的报告毫无价值；但没有A的数据，B也分析不了。

在传统SaaS里，这个问题被回避了——用户付钱给一个平台，平台内部怎么分配是平台自己的事。但在去中心化的agent生态里，A、B、C可能来自三个不同的开发者、跑在三个不同的平台上。没有一个"平台"来拍板说谁该拿多少。

问题二：调用链是动态的。

用户发起任务的时候，可能只指定了"帮我做一份市场分析报告"。具体调用哪些agent、调用顺序是什么，是在运行时由编排agent（orchestrator）动态决定的。

今天可能是A→B→C的调用链，明天同样的任务可能变成A→D→C（换了一个分析agent）。甚至可能出现分叉——B和D同时被调用，取质量更好的那个结果。

分账规则怎么适应这种动态性？你不能提前写死"A拿30%、B拿50%、C拿20%"，因为你都不知道下一次任务会调用哪些agent。

问题三：嵌套调用怎么算？

B在做分析的过程中，自己又调用了E和F两个辅助agent。用户不知道E和F的存在——他只看到最终结果。但E和F确实干了活，也消耗了计算资源。

这100块里，要不要给E和F分钱？如果要，从谁的份额里扣？从B的份额里扣，因为是B调用的它们？还是从总池子里扣，把分账方从三个变成五个？

如果E又调用了G呢？无限嵌套下去，分账的复杂度指数级增长。

---

现有的几种思路

我翻了一些资料加上自己想的，目前大概有这么几种方向：

思路一：固定比例，提前约定。

最简单粗暴的方式。orchestrator在编排工作流的时候，跟每个参与的agent协商好分成比例，写进某种链上协议里。任务完成后按约定比例自动分配。

优点是简单、确定性高、可以完全自动化执行。缺点是不灵活——如果某个agent在这次任务里做的工作量比预期少很多（比如数据采集agent遇到了缓存直接返回了），它还是拿固定比例，不公平。

适合简单的、标准化的工作流。不适合动态、复杂的多agent协作。

思路二：按调用计费，市场定价。

每个agent自己定价——调用一次多少钱。用户调用agent的时候按次付费，最终总费用就是每个agent的单次费用之和。

这跟现在的API经济模型一样——OpenAI的API按token计费，你调用了多少就付多少。

优点是市场化，定价由供需决定。缺点是对用户不友好——你调用了一个工作流，不知道最终会花多少钱，因为嵌套调用的链条你控制不了。可能你以为这个任务就花10块，结果agent B在后面调用了一堆你不知道的服务，最后账单200块。

思路三：总价竞标，内部分配。

用户为一个任务设定总预算（比如100块）。orchestrator在这个预算内组织工作流，内部怎么分配是orchestrator和各agent之间的事，用户不管。

这有点像建筑行业的总包模式——甲方付总价给总包商，总包商自己去分包。用户的成本是确定的，但内部分配的公平性取决于orchestrator的设计。

问题是：orchestrator有动机压低给其他agent的分成来提高自己的利润。在去中心化生态里，没有监管的情况下，这种压榨上下游的行为怎么约束？

思路四：基于归因的事后分配。

这是我觉得最有意思但也最难实现的方向。

思路是：不提前确定分成比例，而是在任务完成后，根据每个agent的实际贡献来计算分配。

具体怎么衡量"实际贡献"？可能的维度包括：

• 计算资源消耗（调用了多贵的模型、用了多少token）
• 响应时间（在整个pipeline里占了多长时间）
• 信息增益（agent的输出对最终结果贡献了多少新信息——这个最难量化）
• 不可替代性（如果去掉这个agent，任务还能不能完成）

把这些维度加权计算出一个归因分数，按分数比例分配总费用。

听起来很理想，但工程难度极大。特别是"信息增益"和"不可替代性"这种维度，目前没有成熟的量化方法。

---

链上结算在这里的价值

不管用上面哪种思路，最终都要面对一个执行问题：谁来记账？谁来保证分配是按约定执行的？

如果所有agent都在同一个平台上，平台做中间人记账还行。但跨平台场景下——A在平台X上，B在平台Y上，C是独立部署的——没有一个可信的中间人。

这就是链上结算存在的意义。分账规则写在智能合约里，交易完成后自动执行。每个参与者可以在链上独立验证自己收到的份额是否正确。不需要信任任何一方，不需要中间人。

但要做到这一点，有一个前提：每个agent在工作流中的参与记录必须是可信的、链上可查的。

你说你调用了Agent B，B花了30秒做分析——这个记录从哪来？如果是orchestrator自己报的，它可以虚报来操纵分账。

所以需要一个独立的计量和归因机制——由第三方节点来记录每个agent的参与情况、响应时间、调用关系。这正好是前面讨论过的metering和attestation要做的事。

归因数据可信了，分账逻辑才有意义。先有可信的秤，再谈怎么分重量。

---

一个容易被忽视的问题：手续费从哪扣？

多agent工作流里除了参与的agent要分钱，协调基础设施本身也需要收费——节点做了attestation和metering的工作，网络做了消息路由，这些都有成本。

那协议手续费从哪扣？

方案A：从总价里扣。 用户付100块，协议先抽5块作为基础设施费用，剩下95块在agent之间分。用户看到的价格已经包含了协议费用，体验清晰。

方案B：额外收取。 用户付100块全部给agent分，但每个agent在收到分成后额外支付一笔协议费。对用户透明，但agent运营者的实际收入被压缩。

方案C：从排放中支付。 排放期内，节点的运营成本由代币排放覆盖，不向用户或agent收取协议费用。排放期结束后再切换到手续费模式。相当于用排放补贴来获取早期用户，跟互联网公司的烧钱获客是同一个逻辑。

我个人倾向方案A + C的组合：早期排放期内协议层不收费或低收费吸引用户和agent接入，过渡期后从总价中抽取一个明确的比例作为协议费用，透明公开。

---

这个问题为什么现在还没被解决

说到底，多agent分账问题还停留在"大家知道有这个问题但没人有成熟方案"的阶段。原因是：

第一，目前大部分多agent工作流还在单一平台内运行。 LangGraph的multi-agent、CrewAI的crew、AutoGen的group chat——全是同一个框架内的agent协作，分账问题不存在（或者由框架开发者单方面决定）。

第二，跨平台的agent协作还很少。 只有当不同开发者、不同平台的agent开始真正互相调用的时候，分账问题才会变得迫切。

第三，缺乏可信的归因基础设施。 没有独立的计量和attestation机制，分账就没有可信的数据基础。

但我判断这个问题在未来12-18个月内会变得非常热门。因为agent框架们正在快速支持跨框架互操作（MCP就是这个方向），一旦跨平台调用变得容易，分账就是紧接着的下一个必须解决的问题。

到时候谁已经把归因和结算的基础设施建好了，谁就有先发优势