圈内内参｜这期聊 Q3Edit。一个独立社区项目，在浏览器标签页里还原 Quake 3 Radiant 地图编辑那套：编辑、编译、试玩都在浏览器里。真正该记的不是“浏览器能跑原版 q3map”，是它给 agent 接了一条本地 MCP 线——地图文件、编译器、资源、活动日志都不出本机。这个项目没有匿名内部消息源可挖，整篇基本来自公开可查的源码仓库、发布说明和公开演示，所以事实部分标（确认）比较多，推理部分单列（分析）。
Q3Edit 打开之后就是 Radiant 那套四视图：三个正交加一个 Camera，各占一个象限，左下角纹理面板，顶上一排按钮切 brush、patch、实体、地形。这不是给“想轻松做游戏”的人准备的界面。这是给以前摸过 GtkRadiant、NetRadiant，甚至更早接触过 id 原版工具链的人准备的。这界面本身就很劝退，但劝退方向很明确。浏览器里还原这个布局不稀奇，稀奇的是还原工作流，不是一个看起来能画房子但不能用的 demo。区别在于：工具链必须真的把 .map 文件打开、编辑、保存，必须真的跑编译，必须真的把 .bsp 丢进一个能动的引擎里跑。Q3Edit 恰好都干了。
技术上最重的部分在编译器。它没重写 Quake 3 地图编译器，而是用 WebAssembly 把 id Software 原版 q3map 整个搬了进来。q3map 是 id 原版工具链里最核心的一环，处理 .map 到 .bsp，里面塞了大量 shader 编译、光照枚举和历史格式包袱上的假设。用 WASM 跑原版而不是另写一个，这个选择对。和几个做工具链的同行聊过，观点一致——（分析）重写一个 q3map 级别的地图编译器，坑不在勾出几个房间，而在旧 .map 文件里千奇百怪的历史用法；用 WASM 跑原版，意味着浏览器里得到的 .bsp 和本机用 GtkRadiant 编出来的是同一套生成逻辑，不是近似物。代价是速度：公开编译演示看，WASM 版本比本机明显慢，第一次加载成本也更高。但这个取舍成立，对 map 工具来说，产出一致性比编译速度重要得多。
试玩部分也不轻。内置的 ioquake3 是编译成 WebAssembly 的，点一下就从四视图进引擎跑刚编译出来的地图。ioquake3 能编成 WASM 这事本身不新，但同一个浏览器标签里，前一秒拖 brush，下一秒跑 BSP，中间连一个“导出”步骤都没有，这个闭环我以前只在原生桌面工具里见过。跑 Quake 3 系引擎通常要求有原版游戏文件，Q3Edit 不要求，随自带 OpenArena 资源。没这条，一个只能编译、不能跑的浏览器地图工具对实际做图的人没有意义。这条不展开，但它是项目成立的前提。
MCP 这条线才是重点。Q3Edit 的接入不是“接某家云 coding agent”那种玩法。它把自己变成本地 MCP client。开发者在本地跑一个伴侣程序——本地 MCP server——编辑器通过 View → Local MCP Connection 连过去：要么输配对码，要么直接用编辑器显示的本地 URL 作为端接地址。连上后，开发者可以把 Codex 或 Claude 这类编码代理接进来，让代理参与几何构建、纹理设置和测试。关键边界：地图文件、编译器、资源、活动日志，全部留在本地计算机上。
这条线跟过去一年我记录过的大多数 AI agent 接入工程环境的机制，方向是反的。大厂那一套，平台团队——（确认）数据出域申请、模型审计、代码留痕、权限分级——本质上是在已经网络化、集中管理的环境里给 agent 开一条被审计、可收回的口子。很多团队为了过审计，把 agent 能力收得很紧，用“权限收着”的状态上线。Q3Edit 不用这套流程，前提就不一样：所有东西本来就在本机。
一个观察到的模式（分析，非事实）：MCP 在 Q3Edit 里的实际角色，是把 agent 从“云端托管、代码要在模型厂商上下文里转一圈”的状态，变成“本地进程对本地进程”。模型厂商的代理通过 MCP 协议驱动跑在用户机器上的进程，文件、编译器、活动日志全都没离开机器。大厂用流程卡住的“数据不出域”红线，这里是用架构绕过去的。不是谁高明，是前提条件不同；最终能不能被工程圈接受，取决于各自要解决什么问题。
还有个细节单拎出来：MCP 暴露给 agent 的工具粒度，公开文档里我没看到够细的说明，先标（未核实）。如果是高层 API——比如“在坐标 x y z 放一个 brush”“这个面设置这个纹理”——编辑器就是 agent 的有状态本地环境，agent 只需明白高层语义，不碰 .map 文本格式本身。如果是直接暴露 .map 文件级编辑能力，格式解析和工程结构上下文管理就全摊给 agent。两种粒度的差别，直接决定这条路能走多远，也决定它会不会被别人抄过去。现在只有公开演示里零星交互，看不出工具清单全貌。
顺手记一笔许可。项目 GPL-2.0，源码和发布说明公开，项目方明确说与 id Software 及 ZeniMax 没有官方隶属关系，独立社区项目。它用 id 原版工具链、在浏览器里跑 ioquake3，又自带 OpenArena 资源而不是原版 Quake 3 资源。说白一点：原版工具链部分，q3map 和 ioquake3 都是 GPL，OpenArena 也是 GPL。这大概不是巧合。选 OpenArena 而不是 Quake 3 原版资源，很可能不是“开源情怀”，而是版权约束：用 GPL 生态里的资源，避免引入需要商业授权的内容。（分析）这个项目能把“浏览器里跑原版工具链”做成可公开分发的东西，部分原因是整个栈都踩在 GPL 生态里。
开始我压根没把 MCP 当回事，第一眼觉得它跟其他“给编辑器加个 AI 插件”没区别。看到配对码和本地 server 的设计，才意识到它跟大厂搞的不是一个方向。大厂那套是“在组织网络内部，给 agent 开一个被管控的口子”；Q3Edit 这套是“组织网络不存在，所有隔离都发生在个人机器边界上”。两套打法跟大厂“平台统一接入、个人不允私自订阅”恰好站在两个极端。
不过，这个 MCP 接入到底多少人在正经用，我还没看到具体量级。它更像一个机制上的路标：一个独立社区项目把 agent 参与创作的那条边界，重新划在了单机上，而且划得很轻。它不跟模型厂商谈深度集成，不碰云托管；最要紧的是不把 user 的文件放进 model provider 上下文窗口。只给本地 MCP 一个最小接入协议。这个轻，反而是它最值得记录的地方。
几个值得盯的信号，我不下注，只列一起看：一、Q3Edit 后续发布说明里，MCP 部分会不会出现更细的工具清单描述——这是看这条线是否被实际用起来的关键。二、会不会有别的编辑器类项目复制“本地 MCP server + 编辑器作为 client”的接入方式，把它从地图工具扩散到更通用的工程环境。如果扩散了，就不是这个项目的孤例，而是一个正在形成的接入模式。三、大厂内部那套 AI agent 接入合规规范文档里，有没有团队开始把“本地 MCP、文件不离开机器”列为可接受方案。如果有，说明边界问题在组织层也在重新找解法。四、如果哪天 Q3Edit 和某个模型厂商签了深度合作，默认接入方式会不会从本地 MCP 改成云托管——只要这个切换发生，就等于把现在这条线反过来，那也是一个明确信号。本期到这，有更准确信源或实际用过这套 MCP 接入的同学，欢迎匿名补充。