2026 年 9 月 11 日,Show HN 上线了一个不太常见的项目——Clawfight.ai。它的形式是一个让两个 AI 智能体(Agent)互相对战 / 对 rap 的实时竞技场,两边都是卡通螃蟹形象,台词以漫画气泡渲染并被各自的 TTS 念出来,整场对战会被实时流式直播成视频。它的"不常见"不在于"AI 玩游戏"这件事本身(早就有 AI 打 Dota、OpenAI Five),而在于它把 Anthropic 在 2024 年提出的 Model Context Protocol(MCP)协议作为游戏本身的协议层——任何接入了 clawfight MCP server 的 Claude、GPT、Codex、Cursor 都能"上场打比赛"。Hacker News 上 49658483 这条原帖(2026-09-11)的 13 条评论里,绝大部分都在争论"Agent 之间互相博弈时 MCP 应该承担什么角色",以及"这种把生产力协议扩展到博弈场景的玩法,是不是协议层横向扩展的新样本"。
本文把 Clawfight.ai 的官方 agent playbook(`https://clawfight.ai/agents.md`)、Hacker News 原帖和评论里的真实工程讨论合并改写,从"为什么 MCP 适合做这件事"、"这套协议层设计比传统做法新在哪"、"它给企业级 Agent 协议扩展留下了哪些样本"三个角度,回答"一个生产力协议被用到游戏里,究竟意味着什么"。
一、MCP 协议的本质:Agent 和外部世界之间的"通用插头"
在聊 Clawfight 之前,有必要简短回顾 MCP 是什么。Model Context Protocol 是 Anthropic 在 2024 年提出、2025 年开始被 OpenAI、Cursor、Cline 等陆续采纳的一套开放协议。它的工程目的是:让任何 AI Agent 都能通过同一套标准接口,接入任意外部工具、数据源、服务——而不需要为每个新工具单独写胶水代码。
具体来说,MCP 定义了三件事:① 工具列表(tools/list)——服务器告诉客户端"我能提供哪些工具";② 工具调用(tools/call)——客户端发 JSON-RPC 调用某个工具,服务器返回结果;③ 资源(resource)——服务器暴露一些可被读取的数据(文件、API 响应、状态)。客户端通过 stdio 或者 Streamable HTTP 连到 MCP server,所有交互都是标准的 JSON-RPC 2.0。
过去一年里,MCP 主要被用在"生产力"场景:接 GitHub 拉 PR、接 Slack 发消息、接数据库查表、接 Notion 写文档。它的设计假设是"Agent 是工具的调用方,工具是被动的服务"。Clawfight.ai 把 MCP 用到了"博弈"场景,这一改写至少有四个有意思的地方:① 两个 Agent 是对等参与者,而不是"一个 Agent 调一个工具";② 比赛状态是双方共享的、跨时间步的、需要服务端权威仲裁的;③ 输赢有裁判意义,会影响后续动作的合法性;④ 整个交互是流式的、需要长连接、不能用传统 HTTP 请求-响应来做。
Clawfight.ai 选 MCP 做协议层,核心赌注是:MCP 的 JSON-RPC + Streamable HTTP + tools/call 接口,已经被今天所有主流 coding agent 和 chat agent 原生支持,任何已经接入 MCP 的客户端"零额外开发"就能进游戏。这条赌注如果成立,MCP 就从"工具调用协议"扩展成了"Agent 之间的对等协议"——这是一个对协议本身非常深远的演化。
二、Clawfight 怎么用 MCP 实现"两个 Agent 互相对战"
Clawfight.ai 在它的官方 agent playbook 里把整套博弈协议公开了出来,整份文档就是一份"如何用 MCP tools 玩一场对战"的工程说明书。从工程角度拆开,有几个关键设计值得记录。
第一个设计是"一个 MCP server,三种接入等级"。Clawfight 把接入方分成 4 个 tier:原生 MCP 已登录(ChatGPT 插件、Claude connector 加了 Sign in now 的)、原生 MCP 匿名登录(同上但 No Auth)、MCP over raw HTTP(curl / Python / Node 都能用)、最后是纯人工网页玩家。四个 tier 共享同一套 server、同一种协议,但授权机制、调用方式、用户体验依次降级。这条设计的好处是:MCP 的"高级 tier"自然享受 OAuth 2.1 + PKCE 的安全鉴权 + 会话绑定;低 tier 退回到 bearer token;最差退回到浏览器——任何客户端都能玩,但越原生体验越好。
第二个设计是"六个 MCP tools 就能跑完一场对战"。不管客户端是哪种 tier,核心循环都是六个 call:`join_match` 入队列、`query_my_next_match` 查排队状态、`wait_for_match_event` 阻塞等待事件、`gesture`/`speak` 出手(打一架出拳或者 rap 一段词)、`query_last_match_result` 拿结算结果。这套循环的工程含义是:MCP 的 tools/call 接口天然适合"长轮询 + 服务端推送",只要服务端把 `wait_for_match_event` 实现成阻塞 20 秒的 RPC,客户端就不需要再单独写 WebSocket——MCP 的 Streamable HTTP 本身就是长连接。
第三个设计是"act_now 是协议层的强制心跳"。Clawfight 的 playbook 明确指出,服务端在 `join_match` 的 ack 里第一个 key 永远是 `{status: "act_now", match_id, clock_running, next_call, then_do, do_not, message}`。这条契约解决了一个非常现实的工程问题:Agent 在拿到"我被配对成功"的信号之后,会不会因为上下文窗口满了、会不会因为工具调用超时、会不会因为人类在等的时候 Agent 已经退出会话——把"时钟在跑"这件事从隐式状态变成显式协议字段。这条设计让 Agent 不需要主动轮询判断"我是不是该动了",服务端会主动告诉你"现在、立刻、做 X"。
第四个设计是"两套子协议共用同一个工具骨架"。Clawfight 同时支持"打架(brawl)"和"rap 对决(rap-battle)"两种模式,前者走 `gesture` 工具、后者走 `speak` 工具,但 MCP server、auth、循环、状态机都是同一份。这意味着 MCP 的"工具是声明式接口"这件事,在博弈场景里被推到了极致——新增一种游戏模式不需要改协议,只需要加一个 tool。
三、Clawfight 的协议层与传统"AI 游戏"做法对比
把 Clawfight 的协议层和传统"AI 玩游戏"的做法对比,差距立刻显现。传统做法(AlphaGo、OpenAI Five、DeepMind 的 StarCraft II agent)是把 Agent 的策略网络和游戏的实时引擎紧耦合——策略网络直接读游戏的内存状态,直接输出动作指令到游戏的输入设备,中间没有任何"协议层"。这条路线的优势是延迟极低、性能极强;劣势是"Agent 不能跨游戏移植",每一个新游戏都要重写一套训练 + 接口。
Clawfight 走的完全相反的路线:把 Agent(可能跑在 Claude、可能跑在 GPT、可能跑在本地)当成一个"远程玩家",通过 MCP 协议和游戏服务端通信。这条路线的优势是"任何接 MCP 的 Agent 都能玩",劣势是延迟会高(每一次出手都要走一次 HTTP POST)。但 Clawfight 赌的是:"延迟不是问题,因为 Agent 的思考时间本来就比网络延迟长一个数量级。"Agent 在 `wait_for_match_event` 里等的是服务端推送事件,等到了之后自己思考一下用什么动作,然后调 `gesture`。整个循环的瓶颈不在网络,在 Agent 的推理时间。
这条路线对 MCP 协议本身的演化意义是:它证明了 MCP 不只是"Agent 调工具"的协议,也可以是"Agent 调 Agent"的协议。MCP server 可以扮演三种角色:① 工具的代理(传统用法);② 状态的持有者(Clawfight 这种,服务器持比赛状态);③ 协议的对端(两个 Agent 都连到同一个 MCP server,通过它互相博弈)。第三种角色是 MCP 协议设计文档里没有明说但实际上支持的——任何 MCP server 只要把"上下文状态"做得足够好,就能让多个 Agent 在同一个状态空间里博弈。
四、Hacker News 社区的协议层争议
Clawfight 在 HN 上引出的讨论集中在三个点上,每一个都直接关系到"MCP 协议层横向扩展"这件事是否站得住脚。
第一个争议是"MCP 适合做实时博弈吗"。一个 HN 用户指出,Clawfight 的核心循环里最关键的一步是 `wait_for_match_event`——它必须在客户端调用时阻塞最长 20 秒,服务端在事件到来时立刻返回。这条契约在 Streamable HTTP 上是支持的,但很多 MCP 客户端对"长连接 + 阻塞 RPC"的支持并不稳定。比如 Claude Code 在沙箱里会强制 reaps 后台进程,导致一个 Agent "起了后台循环"实际上啥也没做,被记录在案的故障是"0-78 KO on record"。Clawfight 的 playbook 里直接给出了 5 条 sandbox 规则,其中第 2 条就是"Run the ENTIRE fight loop inside ONE foreground tool call",因为沙箱会在两轮之间 reaps 掉后台进程。这条规则本身揭示了 MCP 协议层的现实局限:协议的"长连接"假设,在客户端沙箱里经常被破坏。
第二个争议是"协议暴露太多内部细节"。一个用户直接质疑 Clawfight 的 agents.md 里写了 8700 行(包含适配器),核心 SKILL.md 只有 140 行,是不是过度膨胀了。Clawfight 作者 wesleyhales 的回应是"agent playbook 必须把每一个坑都写出来,否则 Agent 会在这些坑里一遍遍死掉"。这条争议背后是 MCP 协议设计层面的根本问题:tools/call 的工具描述应该多详细?太简洁 Agent 用不对,太详细 Agent 看不完。Clawfight 选了"极详细"——这条选择对"Agent 之间的对等协议"几乎是必然的,因为 Agent 没有人类开发者的那种"看 git blame 推断意图"的能力。
第三个争议是"AI 打 AI 是娱乐还是研究"。一个用户(pitchslap.gg 的创始人)说他们也在做类似的事,核心动机是"let the models burn tokens for pure entertainment value"。另一个用户(battlellmrobots.com 的创始人)说他早就做了 AI 机器人对战的项目但没拿到关注。这条争议反映的是"AI Agent 对抗"作为一种新形态的应用,在社区里还没有清晰的市场定位——它是研究、是娱乐、是协议层实验、还是 AI 安全的红队工具?Clawfight 选择把它定位成"研究 + 娱乐 + 协议层实验"三合一,但从评论看,大部分用户还是把它当成娱乐。
五、协议层横向扩展的新样本:企业 Agent 能学到什么
把 Clawfight 的协议层设计抽象出来,有四个对国内企业级 Agent 落地特别有借鉴价值的工程模式。
第一个模式是"协议层的显式状态机"。Clawfight 把"两个 Agent 当前的博弈状态"做成了显式协议字段(`may_strike`、`strike_blocked_reason`、`legal_moves`、`my_hp`、`opponent_hp` 等),每次工具调用的 ack 都返回这些字段。这意味着 Agent 不需要维护自己的"世界模型"——服务端告诉你世界是什么样的,你只需要根据这个去决策。这条模式可以原样搬到企业内部的多 Agent 协作场景:客服 Agent 接到工单时,服务端返回当前工单状态、已等待时长、客户情绪分数,Agent 不需要再调工具去查。
第二个模式是"act_now 作为心跳契约"。Clawfight 把"现在该动了"做成协议层的强制 ack,而不是 Agent 自己去轮询判断。这条模式对应企业内部的一个非常现实的工程问题:Agent 在等审批、在等异步任务、在等人类回复时,怎么知道自己"该去看一眼了"。Clawfight 给出的解法是"服务端主动告诉 Agent"——这条契约可以原样搬到企业内部 Agent 框架里:任务调度器、审批工作流、异步回调都可以用"act_now 模式"主动通知 Agent,而不是让 Agent 一直轮询。
第三个模式是"一个 MCP server 三种接入 tier"。Clawfight 把接入方分成"原生登录、原生匿名、HTTP、人工"四档,共享同一套 server。这条模式对应企业内部 Agent 接入的现实:有的业务系统有完整的 OAuth,有的只有 API key,有的只能发 webhook。把这些统一到一个 MCP server 上、用 tier 表达接入等级,而不是为每种接入方写一套 server,会显著降低 Agent 框架的工程复杂度。
第四个模式是"博弈工具作为审计来源"。Clawfight 的每一场对战,服务端都持有权威状态,Agent 的每一个动作都必须经过 `gesture`/`speak` 调用被记录。这条模式对应 AI 安全的核心需求:Agent 在生产环境里的每一个"动作"都必须有服务端权威记录,不能依赖 Agent 自报。这条原则可以原样搬到金融、医疗、政企这类对"Agent 操作可追溯"有强需求的场景——所有 Agent 调用都走 MCP server,server 持有权威状态和审计日志。
六、Clawfight 还没解决的协议层问题
把 Clawfight 的设计夸完,也得指出协议层本身在博弈场景下还没解决的几个工程问题。
第一个问题是"Agent 之间的消息延迟"。MCP 协议设计文档里没有给"实时博弈"做延迟保证。Clawfight 用 Streamable HTTP + 阻塞 RPC 来近似长连接,但这只是一种工程妥协,不是协议规范。一个真正的"Agent 对等协议"应该定义"事件延迟上限"和"丢包重传策略",目前 MCP 协议没有朝这个方向走。
第二个问题是"跨服务器的 Agent 身份"。Clawfight 的 OAuth 体系是为 Claude、ChatGPT 这些 chat agent 设计的,绑的是"人类用户 + 模型会话"。但当两个 Agent 在同一场比赛里互相博弈时,谁来仲裁"哪个 Agent 真正代表那个真人"?这条问题在 Clawfight 里靠"claim link + 7 天匿名 fighter"做了工程妥协,但不是协议层面的解。
第三个问题是"协议层的可观测性"。Clawfight 的服务端有完整的比赛日志,但客户端(MCP 这一侧)对比赛过程的可见性有限——Agent 看不到对手的真实策略,只能看到公开的 `legal_moves` 和 `my_hp`/`opponent_hp`。这条"信息不对称"在博弈场景里是必要的,但在企业 Agent 协作场景里可能反而是个问题(你可能想让 Agent 看到全部内部状态以做更好的决策)。
七、结论:MCP 协议层横向扩展的意义
回到标题那个问题:Clawfight.ai 不是一个玩具游戏,它是一个把 MCP 协议从"工具调用"扩展到"Agent 对等博弈"的工程样本。这件事的意义在于:它证明了 MCP 的 JSON-RPC + Streamable HTTP + tools/call 这套抽象,足以承载"两个 Agent 在同一状态空间里实时博弈"这种对协议要求极高的场景。这意味着 MCP 的应用边界远不止"Agent 调数据库、调 Slack、调 GitHub"——它可以承载任何需要"Agent 之间的对等通信 + 服务端权威仲裁 + 实时事件流"的应用。
对企业来说,Clawfight 的真正价值不在"能不能用 MCP 玩一场 AI 打架",而在于它给"MCP 协议层横向扩展"这件事提供了一个完整样本:协议怎么支持多种接入 tier、协议怎么定义显式状态机、协议怎么强制心跳契约、协议怎么承载审计日志。下次再有人跟你说"我们要用 MCP 做企业 Agent 协作",你可以反问一句:"你的协议层支持 act_now 心跳吗?你的 server 持有权威状态吗?你的接入 tier 分了几级?你的 tools/call 调用有服务端审计吗?"——这四个问题的答案,就是判断一个企业级 MCP 框架能不能支撑复杂多 Agent 场景的最低门槛。
参考资料:
- wesleyhales, *Show HN: Clawfight.ai MCP-driven agentic game play*, 2026-09-11, news.ycombinator.com/item?id=49658483
- Clawfight.ai 官方 Agent Playbook, clawfight.ai/agents.md, 2026-09
- Clawfight.ai Transport Reference, clawfight.ai/llms-chat.txt, 2026-09
- Jeremy1026, *battlellmrobots.com*, github.com/battlellmrobots, 2026
- cg-enterprise, *pitchslap.gg*, 2026
- Anthropic, *Model Context Protocol (MCP) Specification*, 2024-2026
- OpenAI, *MCP Support Announcement*, 2025
