beesknees-mcp

蜜蜂的拿手好戏

一场争夺蜂后的竞赛，通过 Tollbooth DPYC™ Bitcoin Lightning 微支付实现盈利，并将收益用于传粉者保护。

为一架无人机买个席位。让它飞到一朵花上，携带花粉穿过蜂巢墙带回蜂巢，然后向内挖掘。第一个抵达蜂后的蜜蜂赢得本轮比赛。本轮的大部分收入将用于传粉者保护；获胜者和运营方各分得一小部分。

你将构建什么

      YOU (operator, human in the loop)
        │                         │
        │ set & tune prices       │ drive credential intake
        ▼                         ▼
  ┌───────────────┐        ┌──────────────────────────────────────────────┐
  │ Pricing Studio│ prices │   The Bee's Knees — OPERATOR MCP              │
  │    (iOS)      ├───────▶│   FastMCP · deployed on Horizon               │
  └───────────────┘  Neon  │  ┌────────────────────────────────────────┐  │
                           │  │ geometry · board · match · settlement   │  │
   Patron (Citizen)        │  │ @runtime.paid_tool(FROZEN_UUID) tools   │  │
   + MCP client  ─────────▶│  ├────────────────────────────────────────┤  │
   (Claude, the SPA) npub  │  │ tollbooth-dpyc SDK (the wheel)          │  │
                    +sats  │  │  ledger · vault (AES-256-GCM) · pricing │  │
                           │  │  ConstraintGate · Secure Courier·audit  │  │
                           │  └────────────────────────────────────────┘  │
                           └───┬─────────┬──────────┬───────────┬─────────┘
                               ▼         ▼          ▼           ▼
                         Neon Postgres  BTCPay▶  Sponsor     Nostr relays
                         (your schema)  Lightning Authority   proofs·courier
                         ledger+board   invoices  certify +    DMs·audit
                                                  provision        │
                                                      │            ▼
                                                      └──▶ DPYC Oracle +
                                                            dpyc-community

棋盘

**蜂巢必须是圆形的，因为赛场需要逐渐收窄。**第 0 圈是蜂后的房间，第 14 圈是蜂巢墙。蜂巢格数随周长变化，因此外墙有 29 个格子，而房间前的最后一圈有 6 个。所有蜜蜂起初分散在各处，随后汇聚成一团——整个蜂巢共有 226 个巢房格。

蜂巢墙外是一片方格网草地，每边 16 格，扣除蜂巢占据的方格；蜂巢墙上的门是两者之间唯一的通道。蜜蜂可以从任何位置飞过草地，前往看得见的蜂巢；进入蜂巢后，环形通道会将每只蜜蜂引向一个格子。

移动方向可以是向内、向外，或沿环形通道横向移动。横向移动让这里成为迷宫，而非一组通道：你可以借此进入别人挖好的开放通道，或从坍塌处下方躲开。蜜蜂不能连续两次向内移动——中间必须横向移动一步——因此直线径向通道并无优势，而且部分巢房格无法通行。

唯一真正的选择

自己挖一条通道——速度慢，而且通道一旦挖好，所有人都能使用。 或者走别人花钱挖的通道——速度快，但他们也能把通道封塌，让你困在里面。

三种行动构成了这场竞赛。fly 可在开阔地带移动。dig 可挖出新的巢房，冷却时间要数个周期，而非一个。seal 会封住开放的格子，迫使后面的蜜蜂重新挖掘。

蜜蜂每次冷却结束后行动一次，冷却时间按时钟计，因此无论花多少钱，都无法让蜜蜂行动得更快。花钱能买到的是干扰他人。

为什么要有五个蜂巢，而不是一个

设置五个蜂巢，每个容纳十二只蜜蜂；任意蜂巢达到八只蜜蜂时，比赛便立即开始。席位会分配给最空的蜂巢，因此五个蜂巢会均匀填满。

这是经过测算的选择，而非个人偏好。让五十只几乎相同的蜜蜂争夺同一个蜂后，几乎就像抽签：五十只蜜蜂中第一个到达者是一次极值抽样，结果取决于运气，而非技巧。sim/ 中的批量运行器显示，在一个蜂巢中有五十只蜜蜂时，优秀策略的胜率是随机策略的 1.4 倍；有十二只蜜蜂时则是 2.1 倍。在自己的蜂巢中胜出更能体现技巧，而五位领先者中谁先抵达，则是公平的随机结果，因此技巧优势仍能体现出来。

node sim/run.ts --rounds 400 --bees 12    # re-measure before changing a rule

收入去向

本轮的大部分收入将用于传粉者保护。默认受益方是 Pollinator Partnership——我们有意选择它，而不是以蜜蜂为重点的慈善机构，因为养殖蜜蜂是家畜，并非面临困境的对象；真正面临困境的是本土和野生传粉者，而这正是 Pollinator Partnership 关注的对象。

资金如何流出

每场已结算的对局都会记录分配比例：80% 给慈善机构，获胜者和运营方各得 10%，舍入产生的差额归慈善机构。运营方通过 Lightning 支付各方所得；不会按定时器自动付款——只有运营方发起请求时，款项才会转出。

• beesknees_pay_charity 会将欠慈善机构的全部款项一次性支付到其 Lightning 地址。份额逐场累积后批量结算，因为单场对局的份额可能低于路由手续费。
• beesknees_pay_out 会支付一场已结算对局中慈善机构或获胜者的份额。
• 每笔未支付的份额都会在转出 sats 前先在数据库中认领，因此重试或再次点击都不会重复支付同一场对局的款项。
• beesknees_treasury 会显示钱包可支付的金额，以及欠款金额。
• 玩家会在回合开始前说明获胜后如何处理奖金（beesknees_set_payout）。默认是捐赠；若要保留奖金，则需要提供 Lightning 地址。

beesknees_settlement_history 会显示每场已结算对局的付款金额和收款方；beesknees_payout_history 会列出每笔尝试过的付款，包括失败记录。两者都免费，因为要花钱才能核实资金去向的说法，不值得任何人相信。

受益方信息会存储起来，而不是编译进程序，因此可以更改：运营方通过 beesknees_set_charity 指定受益方名称、网站和 Lightning 地址；beesknees_charity 会免费向所有人展示这些信息。每笔结算都会记录实际收到付款的受益方，因此即使当前受益方发生变化，历史记录依然准确——因资金去向而来参与的支持者，总能查明资金去了哪里。

目录结构

路径	内容
src/beesknees_mcp/geometry.py	棋盘。纯算术运算，不涉及身份或计费
src/beesknees_mcp/server.py	固定的工具目录 + OperatorRuntime 引导程序
src/beesknees_mcp/board_store.py	Neon 中的共享棋盘和结算记录
src/beesknees_mcp/payouts.py	通过 Lightning 支付慈善机构和获胜者的份额
scheduler-worker/	Cloudflare 定时任务，每分钟请求蜂巢推进一次（beesknees_check_now，免费，无密钥）
modal_app.py	模拟蜜蜂：只安排足够数量的普通优惠券出资蜜蜂，以启动规模较小的蜂巢
frontend/src/game/	TypeScript 中的相同规则——客户端的引擎
frontend/src/lib/polar.ts	Cell ⇄ 扇区，以及点击命中测试
frontend/src/lib/stageMath.ts	两次查看蜂巢之间的变化——WebGL 棋盘的差异
frontend/src/art/	作为形状绘制的蜜蜂、雏菊和皇冠——用于棋盘的绘图，以及用于页面的 <symbol>
frontend/src/stage/	使用 WebGL（PixiJS）聚焦显示的蜂巢。仅通过动态导入加载
sim/run.ts	批量运行器：这是游戏还是彩票？

规则有三份副本——这份 Python 代码、客户端的 TypeScript 代码，以及渲染器中的代码——运行时不会报告它们之间是否发生偏差；游戏只会开始拒绝玩家能看出合法的移动。tests/test_geometry.py 和 frontend/src/game/rules.test.ts 会有意验证相同的不变量，因此规则偏差会导致构建失败，而不是对局失败。

入门路线图

1. Nostr 密钥对 — 生成一个密钥对（nak key generate）；nsec 是服务唯一需要的环境变量（TOLLBOOTH_NOSTR_OPERATOR_NSEC）。
2. Sponsor Authority — 注册；它会为你配置 Neon 数据库。
3. Secure Courier — 通过 beesknees_request_credential_channel 传送 btcpay_host、btcpay_api_key、btcpay_store_id。绝不要将它们设为环境变量，也绝不要写入代码。
4. 在 Pricing Studio 中设置价格 — 新工具默认没有定价，未定价的工具无法调用。
5. 在 Horizon 上部署 — fastmcp.json 已配置好。

获取 Pricing Studio （iOS）。 它会实时读取和写入 Neon 中的定价模型，因此价格永远不会写在代码里——动态定价、欢乐时段、忠诚度折扣和免费试用，都是固定付费墙永远无法提供的功能。

应用

frontend/ 包含 Bee's Knees 应用，部署在 Cloudflare Pages 上，由 functions/mcp.js 代理同源的 /mcp。它通过本地引擎运行单人模式——整场对局由机器人填满，但只有一个席位——因此，在任何人付费之前就可以体验界面。

聚焦的蜂巢先通过 SVG 绘制首帧，再叠加 WebGL 绘制。服务器端的冒烟测试和预渲染检查看到的是 SVG；浏览器首帧显示的也是 SVG；如果 WebGL 丢失，游戏也会回退到 SVG。PixiJS 加载并完成绘制后，舞台便接管渲染。游戏逻辑并不在舞台中——舞台只负责渲染两个引擎已经计算出的内容。

开发

uv venv --python python3.12          # coincurve has no 3.14 wheel
uv pip install -e ".[dev]"
ruff check . && pytest -v
python -m beesknees_mcp.server       # runs the validate_operator_tools guard

cd frontend && npm install
npm run dev                          # solo mode on http://localhost:5180
npm test && npm run smoke            # invariants, then a real first paint (the SVG one)

许可证

Apache-2.0