先把结论给你：单笔限额负责挡"大手笔"，累计额度负责挡"停不下来"。只设一个等于少装一道闸，代理出问题时损失会大得多。
此前有做链上套利的用户反馈，他的代理日限额设了100U，单笔限额设了20U，结果代理一小时内发了80笔0.5U的调用请求，每笔都在单笔限额内，但日限额很快被磨光，数据没拿到几条资金却损失了。本质原因是单笔限额拦截的是单笔金额，无法限制高频小额请求的累积消耗。
概念拆解：两道闸各管什么事
单笔限额（per-transaction limit）：代理一次支付最多能花多少，挡住单次异常大额支出。比如代理被注入转大额资金的异常指令，只要单笔限额设置得当，这笔交易就会直接被拒绝。
累计额度（daily/session limit）：代理在固定周期内（通常是24小时滚动窗口）总共能花多少，挡住高频小额累积支出。前面的套利场景就是仅设置单笔限额的典型漏洞，每笔小额请求合规，但累积起来会快速消耗全部日度预算。
两者缺一不可。只设单笔限额，高频小额能慢慢掏空账户资金；只设累计额度，一次大额异常指令就能直接清空当日预算，你甚至来不及反应。
对比选择：不同场景的搭配方案
| 使用场景 | 单笔限额 | 累计额度（日） | 理由 |
|---|---|---|---|
| 调用公开 API（数据抓取、天气查询） | 0.5 - 1 U | 5 - 10 U | 每笔费用固定，日预算控制总成本 |
| 链上数据查询（付费 RPC） | 1 - 5 U | 20 - 50 U | 单次查询可能因数据量差异较大 |
| 代理购物/支付 | 10 - 50 U | 100 - 500 U | 商品价格波动，需要预留弹性空间 |
| 高频交易/套利代理 | 视策略而定 | 视仓位而定 | 交易场景需要更复杂的风控，单靠限额不够 |
以上是通用参考值。如果你是新手，先选保守档（单笔 1 U，日 10 U），跑一周再看实际支出调整。
下一步动作：具体怎么设
步骤 1：确认你的工具支持哪些限制维度
不同平台入口不同：
Agorio SDK：在创建 spendingControls 插件时配置 perTransactionLimit 和 dailyLimit
PaySpawn：在 Dashboard 创建凭证时设置 daily limit + max per tx，上链后不可篡改
agent-pay-guard：在 guard.yaml 中写 per_transaction 和 daily 阈值，支持月度累计
Cronos Agent Wallet：limits: { daily: 10, perTx: 1 }，通过 AgentAdmin.setPolicy 上链生效
kova-sdk：Policy.create().spendingLimit({ perTransaction: "1", daily: "5" })，支持多层级规则组合
步骤 2：把"警告阈值"设上
别等到额度用完才报警。在累计额度用到 75%、90% 时触发通知，提前干预。如果代理在夜间跑异常高频请求，你收到预警通知还来得及手动停掉。
完成标准： 在 Dashboard 或配置文件中能看到两条独立的限制规则，不是只有一条"总限额"。
常见失败原因
1. 只设了单笔，没设累计——这就是前面套利用户踩的坑。高频小额在单笔限额面前畅通无阻，日额度形同虚设。
2. 日额度设得太大，等于没设。一天 1000 U 的上限对新手代理来说跟无限没什么区别。等你发现异常时已经损失惨重。
3. 把"滚动窗口"理解成"自然日"——有些工具按 24 小时滚动窗口算，有些按自然日 00:00 重置。如果代理在 23:59 和 00:01 各跑一笔，按自然日算跨了两天额度，但按滚动窗口可能还没超。使用前要确认工具的额度计算规则。
高危提醒：额度规则如果只存在代码里，代理被注入后可能直接修改自己的配置。可选择将限制上链写入智能合约，让代理权限无法篡改合约规则。如果你的工具不支持链上固化，至少把配置文件放在代理写权限之外的位置。
操作完成的校验方式
跑两笔测试：
让代理发起一笔超过单笔限额的支付——应该被拒绝，日志里出现类似 POLICY_REJECTED 或 Blocked: per-transaction limit exceeded 的提示
让代理发起多笔小额支付，总额超过日额度——应该在第 N 笔被拦住，日志里出现 daily limit exceeded 或 Budget exhausted
两笔都拦住了，说明两道闸都在工作。
