PlonGuo / mcd-hackthon

# mcdebate · 麦麦辩论局
**让 AI 替你辩，和朋友一起点麦当劳。**
你想吃麦乐鸡，朋友想吃薯条。各自选中 `mcdebate` 技能，让两位 Agent 为自己的选餐立场辩一场；你们打开观战链接，看四条发言和 AI 裁判的结果，再决定买什么。点餐清单持续保留，可以先点餐、插入一局对战，再继续加购。
这是基于麦当劳官方 MCP 的参赛 Skill 项目，由自建房间 MCP 提供跨客户端协作与实时观战。适合一起点餐的朋友、情侣和同事。项目为独立参赛作品，非麦当劳官方产品。
- mcdebate Skill 源文件
- 系统架构与设计思路
- Skill 版本、变更说明与导入包
- 麦当劳 MCP 集成说明
- 参赛声明
## 图文流程
**选中技能开始 → 邀请朋友加入 → 确认门店和餐品 → 观战与判决 → 确认清单 → 进入麦当劳 App。**
以下图片按流程展示不同来源的记录：创建／加入来自豆包 work 和 workbuddy 的历史实测，官方页面展示真实建单后的 App 交接；红黄深色观战 UI 为当前代码的本地演示截图，发言、价格与比分使用固定测试数据。真实记录中的访问链接与二维码已遮挡。
### 1. 一方发起，另一方用房间号加入
两边选中 `mcdebate` 技能。发起方说“开始 mcdebate”，Agent 创建房间；朋友在自己的客户端提供房间号加入，不需要使用同一个 Agent 产品。
| 豆包 work：创建房间 | workbuddy：加入房间 |
| --- | --- |
| | |
这组历史记录曾暴露豆包交付观战链接时截断字符的问题；当前 Skill 已增加原样交付 `watch_url` 的规则，修正效果仍待手机端复测。复现时使用新房间工具实际返回的完整链接。
### 2. 确认门店和餐品，打开观战页面
用户提供大概地点并确认具体门店后，Agent 查询官方菜单，按用户意图维护待买清单。双方选定各自立场，网页展示辩题、选手、门店和餐品；点餐、改数量仍在 Agent 对话中完成。
粒子字形区分 A／B，红色与黄色贯穿舞台、发言和清单。图中的“本地演示餐厅”、¥27.50 清单均为界面测试数据；真实使用时按确认门店查询，建单前再次官方核价。
### 3. 两轮交锋，用户实时观战
两位 Agent 按 A／B／A／B 提交四条发言。网页实时接收已提交的消息，跟随最新发言，并用三个跳动的点表示等待下一方；四条发言后显示“裁判正在评分”。用户向上阅读时暂停自动跟随，通过“新发言／回到现场”入口返回。
桌面端同轮发言并排，手机端按时间排列。这里展示的是固定演示文案；真实对局内容来自两个客户端实际提交的发言。
### 4. 独立裁判评分，用户决定接下来买什么
裁判按切题、依据、回应和趣味评分，并宣布唯一胜者。示例页面展示麦乐鸡方 **87 : 83** 获胜；真实对局由后端调用 DeepSeek 评分，不使用预设结果。胜负只提供推荐，用户仍可保留双方餐品、继续加购，或再开一局。
手机端保留当前对局状态与清单入口，评分细节默认折叠，先看到胜者、比分和简短结论。清单入口只用于查看，点餐操作仍在 Agent 中完成。
| 手机端：现场交锋 | 手机端：判决结果 |
| --- | --- |
| | |
### 5. 确认方案后建单，通过官方页面进入 App
用户确认付款人、门店、餐品、数量、取餐方式及最终金额后，付款人 Agent 调用麦当劳官方 MCP 创建订单，并交付官方返回的支付链接。用户打开链接或扫描官方页面二维码，进入麦当劳 App 核对餐品并继续下单、支付。
| 官方链接打开的扫码页面 | 麦当劳 App 中的订单与餐品 |
| --- | --- |
| | |
App 截图保留了“超时未支付，自动取消”的实际状态，用于展示真实订单已进入官方 App，店名、餐品、数量和 ¥27.50 金额可核对。实际支付、订单与取餐状态以官方 App 为准；图中二维码已遮挡，不能用于下单或支付。
## 能做什么
- **两位 Agent 跨客户端协作**：房主创建房间，另一方用房间号或邀请加入；双方保留各自身份和凭证。
- **用真实门店与餐品选餐**：用户给出大概地点，Agent 调用官方 MCP 搜索门店，用户确认后锁定到店自取门店，再查询菜单、单品和价格。
- **自动筹备与等待**：已有对战意图且本人信息齐全后，Agent 主动准备、轮询等待对方，房主满足条件直接开局；只在缺少真实决定时询问。手机宿主的后台执行限制仍可能中断等待。
- **实时观战、四条定胜负**：每局两轮、A/B 各两条发言，独立裁判评分并给出唯一胜者；网页跟随新消息，读历史时保留位置，展示发言／评分等待状态，断线后可重新连接。
- **自由穿插点餐与对战**：维护共享点餐草稿和个人项目，支持多局；胜者只产生推荐，不自动加购或删除另一方餐品。
- **衔接真实点餐与支付**：指定付款人接受角色、核价并确认具体方案后，通过麦当劳官方 MCP 建单并提供官方链接。用户通过链接或官方页面二维码进入麦当劳 App，在购物车查看餐品并继续下单、支付。
观战网页只读；加购、改数量和结账由 Agent 按用户意图操作。这里的“清单”是项目自己的点餐草稿，并非麦当劳官方购物车。
## 系统架构与设计思路
核心思路是让两个独立 Agent 围绕同一份房间状态协作：各自代表用户表达偏好，用户能旁观交锋，最后仍由用户决定买什么。Skill 编排流程，房间服务约束身份、权限与回合，真实选餐和交易交给麦当劳官方 MCP。
 [code] 
- **两个 MCP 各司其职。** Agent 用自己的官方 Token 查询与建单，再把可共享的门店、餐品和状态上报房间；房间后端不保存官方账户 Token，也不替两人决定购买。
- **跨客户端协作通过共享房间完成。** A／B 各持本人玩家凭证，按同一房间的回合与状态行动；无需彼此直连，也不要求使用同一种 Agent 产品。当前没有额外实现 A2A 协议。
- **观战与工具调用走不同通道。** MCP 使用 Streamable HTTP；网页用 SSE（服务器向浏览器推送事件）接收已提交的完整发言与状态，不是外部 Agent 内部逐字生成流。网页由同一服务提供，无需额外的前端服务器。
- **裁判独立，支付回到官方。** 参与辩论的 Agent 使用各自客户端模型；后端在四条发言后调用 DeepSeek 裁判。付款人可以是 A 或 B，官方支付链接仅交付给该用户，不进入共享房间或观战页。
图中展示当前采用的 Node.js 单机部署方式；仓库同时保留 Cloudflare Workers／Durable Objects 入口，复用业务规则。代码通过分支和 PR 修改，GitHub Actions 检查通过后才把 `main` 对应提交部署到服务器。
## 安装与开始
用户按客户端**只选一份交付物**，不需要同时下载 `packages/` 与 `bundles/`。两份交付物都包含 mcdebate Skill 0.3.5，均不含个人 Token：
0.3.