Backpack Grid 已用于 Backpack 永续合约网格的实盘巡检。项目 README 明确说明它使用真实资金运行；公开仪表盘则持续展示账户权益、各网格盈亏、交易量活动进度和风控状态。你可以直接打开网站，查看这套程序最近一轮记录了什么。
以上为 2026 年 10 月 1 日访问公开网站时截取的真实页面，数据快照时间为北京时间 18:10:40。截图中的数值会随行情和后续巡检变化。
实盘里，4 个中性网格在运行
截图时，PENGU、HYPE、PUMP 和 SUI 四个永续市场的网格都显示为“运行”。它们使用不同的价格区间和网格数量，巡检程序统一检查盈亏、账户风险和保护设置，再根据规则决定是否退出或补仓。
| 网格 | 方向 / 格数 | 页面显示投入（USD） | 页面显示盈亏（USD） |
|---|---|---|---|
| PENGU-PERP | 中性 / 60 格 | 1,800 | +33.00 |
| HYPE-PERP | 中性 / 20 格 | 1,500 | +7.43 |
| PUMP-PERP | 中性 / 28 格 | 1,500 | +20.78 |
| SUI-PERP | 中性 / 33 格 | 2,500 | +20.43 |
同一快照中，账户总权益为 581.50 USD，可用权益为 216.56 USD，网格总盈亏为 +81.64 USD，页面显示回撤 1.4%。投入栏沿用仪表盘的网格配置口径，不能把四项相加当作账户本金；合约网格的配置金额与账户权益是不同指标。
页面下方还有按巡检轮次记录的权益曲线，以及“风控正常”“无待清理”“近期无动作”等状态。看这张图，可以同时了解资金变化、哪些网格仍在运行，以及程序有没有尚未处理完的退出任务。交易量活动栏当时显示 23,335 / 50,000 USD（46.7%），方便观察活动进度。
这些数据来自项目公开展示的实盘快照，本次没有登录交易所独立核对完整账单。+81.64 USD 是该时点页面展示的网格盈亏，不应据此推算完整账户收益率或长期表现。
自动巡检，具体替人处理什么
开一个网格机器人，通常只需要填几项参数。真正需要花时间的是后续管理：价格走出区间怎么办，止损设置是否还在，旧仓位有没有平掉，这轮出错后下一轮该从哪里继续？
Backpack Grid 围绕交易所原生合约网格，加入选币、账户观察、规则判断、退出与补仓，以及上面这套公开仪表盘。README 描述的部署方式是由 macOS 的 launchd 每 15 分钟执行一轮，最多管理 4 个中性网格。
原创概念插图，用来说明巡检与网格之间的关系；实盘页面见文章开头。
下面结合源码介绍它如何管理状态和处理失败。本文运行了离线回归测试，但没有测试真实下单；文中的策略参数是项目配置，不是投资建议。
网格在交易所运行，本机负责巡检
理解这个项目，可以先分清两件事。交易所的原生网格负责按照配置运行；本机脚本负责检查它是否还符合规则，并在需要时修改配置。
observe.mjs 通过 ego-browser 复用已经登录的 Backpack 网页会话，用 page.fetch() 读取网格、持仓、账户和权益数据。它读取接口返回的结构化数据，不靠页面上的盈亏文字判断状态。交易相关写操作也使用这套会话鉴权机制。
因此，“不使用 API Key”只是在说明鉴权方式。浏览器会话依然带有账户权限，登录态失效、接口变化和本机停机，都会影响巡检。交易所已经接收的原生网格配置与本机巡检，也有各自的运行边界。
项目附带一个运维 Skill，整理启动、停止、部署、测试和故障处理方法，方便 AI 助手协助操作。不过，在当前公开代码里，选币评分和退出条件都由脚本计算，没有让大模型临场决定买卖方向。
一轮检查，先处理退出，再考虑补仓
入口 run_round.sh 把流程分成观察、判断、执行和复核。decide.cjs 根据账户快照生成动作计划，act.mjs 执行动作，再读取结果。
这里有一个影响行为的先后顺序：如果发现需要退出的网格，先处理退出，补仓分析放到后一个阶段。这样，重新扫描市场所花的时间不会排在风险退出前面。没有退出任务时，则可以直接规划补仓。
流程图依据当前源码绘制。清理未完成或保护修复未确认时，新建网格会被阻止；仪表盘上传失败不阻塞主流程。
这也意味着“最多 4 格”是容量上限。候选评分不够、资金不足或仍有未处理状态时，程序允许留空，不会为了凑满数量而强行开新格。
选币看震荡路径，也看成交量和趋势
analyze.cjs 扫描符合条件的 USDC 永续市场，读取最多 168 根小时 K 线，综合比较短期震荡、振幅、成交量、方向性漂移和资金费率。
其中一个指标是价格路径与净位移的比值。假设价格在一段时间里反复上下波动，最后又接近起点，累计走过的路径会比较长，起终点之间的净位移却很小。代码用这个关系描述震荡程度，并结合 24 小时和 72 小时两个窗口，避免只盯着单日走势。
评分还加入了几项约束：震荡指标在计分时设上限，流动性参与加权，明显的单向漂移与较高的绝对资金费率会扣分。低成交量市场、美股类合约，以及本轮排除的市场不会进入候选。网格区间和格数再根据近期振幅、价格精度、最小下单量等条件调整。
这是一套可以阅读和修改的启发式筛选规则。它表达了“什么样的市场更符合这套网格设想”，但并没有证明高分候选在未来会赚钱。代码另外输出方向性候选，当前用途是纸上跟踪。
退出失败，要留下能继续处理的记录
相比评分公式，我更关注 act_core.cjs 对退出流程的处理。
在第一次修改交易所配置之前，程序先把停止意图写入 pending_stops.json。然后停用网格，并要求停止时平仓；接下来轮询持仓，确认归零后，才删除网格配置。删除请求被接收之后，还要再次读取配置，确认它确实消失。
为什么要在动手前记一笔？因为请求发出去以后，本机可能断网，响应可能丢失。此时程序不能仅凭“没收到成功”推断交易所什么都没做。事先保存意图，下一轮就能知道还有一件事需要核实。
持仓查询超时、返回结构异常或删除未确认，都会让清理保持未完成状态。新建网格之前还会重新检查待处理账本，以及停止、保护修复和紧急清理是否完成。这样，退出过程中的不确定状态就不会被轻易当作可用空位。
这类处理对交易之外的自动化也有参考价值：涉及外部系统的写操作，应保存意图、核实结果，并为下一次执行留下恢复依据。
原生保护与账户预算，各管一部分风险
创建网格时，程序会写入交易所侧的止盈、止损和停止时平仓配置，再读回来核对。巡检也会检查已有网格的保护设置，发现不一致时尝试修复。原生保护的意义，是减少对本机下一轮巡检的依赖；它并不保证极端行情下能按设定价格成交。
账户层则检查存量网格的止损额度、计划新开的额度和退出成本缓冲，并限制同一生态的集中度。下表是本文核对的版本中已有的配置，不是推荐参数。
| 配置项 | 当前值 | 程序中的用途 |
|---|---|---|
maxGrids |
4 | 同时管理的网格数量上限 |
gridValueUsd |
2,500 USD | 单格计划金额；保证金约束下可能缩小 |
takeProfitPct / stopLossPct |
10 / 6 | 网格止盈、止损阈值 |
minQvol24h |
800,000 | 24 小时报价成交量门槛 |
minScore |
5 | 候选评分门槛 |
maxPerEcosystem |
2 | 同一生态的网格数量上限 |
warnDrawdownPct / riskBudgetPct |
40 / 80 | 账户回撤预警与熔断阈值 |
本地逐格盈亏判断使用网格账本盈亏加累计资金费，再除以配置分配金额；不要将它直接等同于整个账户的收益率。另一个需要读代码才能看清的细节是，riskBudgetPct 同时参与前瞻止损额度预算和账户回撤熔断判断。
40% 的预警和 80% 的熔断阈值容许相当大的账户回撤。有风控代码不代表风险很低，名为“中性”的合约网格也仍然暴露于行情、杠杆、资金费和执行风险。
仪表盘让运行过程可以被查看
项目的展示层由 Cloudflare Worker 和 KV 组成。本机把账户观察、网格状态、待清理任务、最近动作和权益曲线整理成快照；Worker 接收快照后保存到 KV，前端再读取并展示。
公开仪表盘 提供账户与网格状态查看入口。首页和快照读取公开，快照上传使用独立写入凭证。巡检结束时会尝试上传，上传失败不会让主要巡检流程因此失败。
页面每 60 秒刷新，与账户数据每 15 分钟左右更新，是两件不同的事。阅读仪表盘时要看快照时间，不能把页面刷新误认为交易所数据已经重新采集。
代码还记录一项限时交易量活动的进度，按网格账本增量累计，并在账本重置时重新建立比较基线。这部分属于项目内的进度估计；活动资格、奖励和最终有效交易量仍需以平台认定为准。
当前更适合怎样阅读和使用
我在公开仓库提交 3084485 的独立副本里运行了 node tests/regression.cjs，结果为 107 passed，0 failed。测试既有纯逻辑和源码检查，也有通过隔离数据执行真实决策脚本、使用模拟 I/O 执行停止流程的用例。
这能说明测试所覆盖的决策与故障场景在该版本下通过了检查，不能替代交易所联调，更不能证明策略收益。
准备自己适配时，还应留意项目目前的个人环境假设。浏览器脚本里写有固定的本机根目录，配置里保存了任务空间编号，子账户也有默认值。克隆仓库后，需要先处理这些路径、账户与会话配置。
另外，完整巡检脚本默认会进入执行阶段。DRYRUN=1 会跳过交易动作，但观察、判断、本地状态记录和退出时的仪表盘上传仍可能发生。若只是理解代码，先读配置和离线测试，比直接运行巡检更合适。
Backpack Grid 值得参考的地方，是它把自动化运行中的具体问题写进了程序：已有仓位怎么退出、请求失败后怎么继续、什么情况下禁止新开、结果怎样供人查看。即便不使用这套交易规则，这些关于状态、顺序和恢复的处理，也值得在自己的自动化项目里逐一考虑。
来源与核验：本文于 2026 年 10 月 1 日依据 terryso/backpack-grid 的公开提交 3084485 撰写。主要核对 配置、选币分析、巡检编排、退出与创建门禁、决策逻辑、仪表盘服务和回归测试。关于设计取舍的评价为本文分析。配图包括 2026 年 10 月 1 日通过 ego-browser 截取的公开实盘仪表盘、原创概念插图，以及依据源码绘制的流程示意。实盘数字来自仪表盘北京时间 18:10:40 的数据快照。