概览
通过一个大型电商平台销售，意味着接受一份结算单：每一笔订单几十种费用类型，由平台按它自己的记录算出来，而卖家不重建整套计算就无法核实其中任何一行。
大部分时候它是对的。在规模之下，那些例外价值巨大，而且它们都朝一个方向走。
履约费按平台测量出来的尺寸和重量档位收取，而一件被测错的商品，会在卖出的每一件上、无限期地按更高的档位计费。佣金按一个类目的费率收取，而一件归错类目的商品会永远按错误的费率付费。库存会丢失、在仓库里损坏，或在没有指令的情况下被处置——赔付是存在的，但必须由你去申请。一位客户被退了款，而那件商品从来没有回来。一件退货被收到了，却从来没有重新上架。
每一项都有一个申请窗口，通常很短，而它们没有一项会在平台提供的任何报表里显示为一个问题。卖家看到的是一笔净入账，以及没有任何质疑的理由。
这个智能体把结算单对照你自己的商品目录和发货记录重建出来，并报告每一处差异，附上它的截止日期，以及一次申请所需要的证据。它不提交任何东西：申请要走平台自己的流程、在你的账号之下进行，而一次自动化的批量申请，正是一个卖家账号被标记的方式。
价值
拿回本来就属于你的钱
不用多卖什么，也不用去谈判什么。
把那些反复发生的错误修掉
一个错误的尺寸档位，不再让你在未来的每一件上继续付出代价。
赶得上截止日期
而这正是一条发现和一次追回之间的全部差别。
功能说明
核对尺寸与重量档位
一件被测错的商品，会在卖出的每一件上、无限期地高一个档位计费。任何报表里都没有任何东西显示它。
核实类目费率
一件归错类目的商品，会在每一笔订单上、永远按错误的佣金率付费。
找出在他们仓库里丢失或损坏的库存
赔付是存在的，而且必须去申请。没有人会主动给你。
把退款与收到的退货对上
客户被退了款，而商品从来没有回来。在有量的情况下，这是最大的一类。
每条发现都带申请截止日期
窗口很短。一处发现得太晚的差异，一分钱都不值。
不提交任何东西
申请走平台自己的流程、在你的账号之下进行，而一次自动化的批量申请，正是一个卖家账号被标记的方式。
这会改变什么
这会如何改变你的一周
- 它接手的工作
- 把平台结算单对照你自己的商品目录和发货记录重建出来。
- 目前由谁完成
- 没有人。卖家看到的是一笔净入账，以及没有质疑的理由。
- 多久一次
- 必须每月做——申请窗口很短。
- 通常的人工投入
- 每笔订单几十种费用类型，由平台按它自己的记录算出来。
为什么偏偏是电子商务。一件被测错的商品会在卖出的每一件上、无限期地高一个尺寸档位计费，而平台的任何报表里都没有任何东西显示它。赔付是存在的、必须去申请；没有人会主动给你。
无人值守运行
由你或某个事件启动，然后自行完成。没有什么需要等人坐到工位前。
每一次都是同一标准
第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。
它无法自行采取行动
平台费用对账代理 没有任何发送、支出或承诺的途径。正是这个限制，让依据它的输出行动是安全的。
运行方式
该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录，每次工具调用在执行前都会进行权限检查。
- 1输入按智能体的输入结构进行校验
- 2模型claude-sonnet-5，并自动回退
- 3工具extract_structured_data
- 4权限自动执行 READ 级操作；更高的等待你批准
- 5输出符合输出结构的结构化结果
- 6日志记录 token、耗时和每一个步骤
演示
演示数据Illustrative sample output, abridged.
输入
{
"period": "Q3 2026",
"currency": "USD",
"claimWindowDays": 60,
"settlementLines": []
}输出
{
"escalate": true,
"findings": [
{
"sku": "SKU-4412",
"type": "wrong-size-band",
"charged": 5.94,
"claimBy": "2026-10-14",
"daysLeft": 42,
"expected": 4.11,
"reference": "Fulfilment fee, all orders",
"unitsAffected": 3140,
"evidenceNeeded": "Your packed dimensions and weight, with a photograph of the item on a scale.",
"perUnitDifference": 1.83,
"annualisedIfUnfixed": 22980
},
{
"sku": "Various",
"type": "refund-without-return",
"charged": 0,
"claimBy": "2026-09-11",
"daysLeft": 9,
"expected": 0,
"reference": "88 orders",
"unitsAffected": 88,
"evidenceNeeded": "Order identifiers and the marketplace's own return-window dates for each.",
"perUnitDifference": 0,
"annualisedIfUnfixed": 0
}
],
"disclaimer": "A reconciliation of settlement reports against your own records. No claim has been filed, no seller account accessed, no marketplace or customer contacted, no listing changed, and discrepancies where your own record could equally be wrong are reported as unresolved rather than as overcharges.",
"stillAccruing": [
"SKU-4412 is still selling in the wrong size band. Every unit shipped from today costs 1.83 more than it should, and that continues until the measurement is corrected."
],
"totalIdentified": 41200,
"escalationReason": "9,400 of identified claims expire within 9 days, and a recurring size-band error is still accruing on a product that is still selling.",
"expiringWithin14Days": 9400,
"unresolvedDiscrepancies": [
"Two SKUs where your recorded weight and theirs differ by under 30g. Either record could be right, so these are reported as unresolved rather than as overcharges."
]
}使用条件
集成
无需集成。
开始之前
- 平台的结算与费用报表
- 你自己的商品目录，含尺寸、重量与预期类目
- 发货记录：你发出去了什么，被收到了什么
- 退款与退货记录
- 需要 全量访问 套餐或更高
使用场景
每月结算复核
每一份结算单都对照你自己的记录重建一遍。
一次费率变更之后
新费率有没有被正确地套用到你的商品目录上。
大批量履约
在那里，一个很小的单件误差就是一个很大的年度数字。
在一个周期关闭之前
趁申请窗口还开着的时候把它们找出来。
价格
常见问题
它会提交申请吗？
不会。申请要走平台自己的流程、在你的账号之下进行，而自动化提交申请是让一个卖家账号被标记的好办法。它给你的是理由和证据。
它需要平台的 API 权限吗？
不需要。它基于结算报表，以及你自己的商品目录和发货记录来工作——都是你本来就能下载的导出文件。
如果平台的测量是对的、而我们的是错的呢？
那它就不是一条发现，而它会这么说。当两边不一致、且哪一边都无法确认时，它会把这处差异报为未解决，而不是报为多收。
评价
客户运行过该智能体后，评价功能将开放。
需要这个智能体换一种做法？
告诉我们要改什么，我们的团队会为您的业务规划一个定制版本。
定制此智能体