在日常 Unity 开发中，我会同时使用 CodeX 和 Reasonix。

两者各有优势：

CodeX 更擅长代码生成、逻辑分析和架构设计，但 GPT Plus 会员额度有限，不适合大量重复性执行任务。

Reasonix 接入 DeepSeek 后使用成本更低，并且可以直接连接 Unity Editor MCP，能够操作场景、编辑脚本、管理资源，更适合执行具体开发任务。

因此，我采用了一种组合工作流：

CodeX：负责项目架构设计、任务拆解、代码审核
Reasonix：负责执行具体任务，操作 Unity Editor 和项目文件

但实际使用中有一个明显痛点：

两个 AI 各自为战。

CodeX 规划好的任务，需要我手动复制、整理，再转述给 Reasonix 执行。
Reasonix 执行完之后，我又要把结果手动反馈给 CodeX 做审核。

这导致我变成了两个 AI 之间的“传话筒”，效率并不理想。

---

解决方案：文件桥 File Bridge

为了解决这个问题，我用 MCP（Model Context Protocol） 做了一个轻量级任务桥。

整体结构如下：

CodeX ── MCP ──> server.js ── 读写 ──> tasks.json <── Reasonix

核心思路很简单：

用一个共享 JSON 文件作为任务队列，让 CodeX 和 Reasonix 都通过 MCP 读写它。

CodeX 可以把任务写入 tasks.json，Reasonix 定期读取并执行 pending 状态的任务，执行完成后再把结果写回同一个文件。随后 CodeX 再读取执行结果，继续做审核或下一步规划。

这种方式不需要复杂的服务端通信，也不需要数据库，只需要一个 MCP Server 和一个 JSON 文件即可完成 AI 之间的任务接力。

---

实现方式

1. MCP Server

我写了一个简单的 Node.js MCP Server，通过标准输入输出，也就是 stdio，与 MCP 客户端通信。

它主要提供 4 个工具：

工具	用途
send_task	CodeX 提交任务
get_task_result	CodeX 获取任务执行结果
list_tasks	查看当前任务队列
cancel_task	取消待处理任务

核心逻辑并不复杂，大约 20 行就能完成任务文件的读写、状态更新和结果查询。

---

2. 任务文件格式

任务队列使用一个普通的 JSON 文件保存，例如 tasks.json。

单个任务结构如下：

{
  "id": "a1b2c3d4",
  "description": "在场景中创建红色 Cube",
  "status": "pending",
  "result": "",
  "created_at": "2026-01-01T10:00:00.000Z",
  "completed_at": ""
}

任务状态流转如下：

pending → in_progress → completed

也可以根据需要扩展：

pending → in_progress → failed
pending → cancelled

这样 CodeX 和 Reasonix 不需要直接通信，只要遵守同一套任务状态约定即可。

---

Reasonix 侧工作流

Reasonix 侧的处理方式比较直接。

我在 AGENTS.md 中写入规则：

每次对话开始时，先检查任务桥。
如果发现 pending 状态的任务，立即读取任务内容并执行。
执行完成后，将结果写回任务队列。

这样 Reasonix 每次启动或进入新对话时，都会自动检查是否有待处理任务。

流程大致如下：

1. Reasonix 检查 tasks.json
2. 找到 pending 任务
3. 将任务状态改为 in_progress
4. 执行任务
5. 将结果写回 result
6. 将任务状态改为 completed

CodeX 之后只需要调用 get_task_result，就能拿到 Reasonix 的执行结果。

---

CodeX MCP 配置

CodeX 侧只需要配置这个 MCP Server：

{
  "mcpServers": {
    "reasonix-task-bridge": {
      "command": "node",
      "args": ["D:\\project\\.reasonix\\task_bridge\\server.js"]
    }
  }
}

启动后，CodeX 就可以通过 MCP 调用任务桥工具。

例如：

send_task：提交任务给 Reasonix
list_tasks：查看当前队列
get_task_result：读取执行结果
cancel_task：取消任务

---

实现过程中的踩坑记录

1. MCP 响应格式不符合规范

最开始我直接用 JSON-RPC 的 error 对象返回工具错误，结果 CodeX 报：

Unexpected response type

后来发现，tools/call 的返回值必须统一包在 result.content 里。

正确格式如下：

{
  "result": {
    "content": [
      {
        "type": "text",
        "text": "任务执行失败：xxx"
      }
    ],
    "isError": true
  }
}

即使是错误，也不要直接返回 JSON-RPC error，而是通过 isError: true 标记。

---

2. 日志污染 stdout

MCP 的 stdio 通信依赖标准输入输出传输 JSON-RPC 消息。

一开始我在 Node.js 里用了：

console.log("debug message")

结果这些日志被输出到了 stdout，混进了 MCP 协议消息里，导致客户端解析失败。

修复方式：

console.error("debug message")

也就是：

stdout：只输出 JSON-RPC 协议消息
stderr：输出调试日志

这是写 stdio MCP Server 时很容易踩的坑。

---

3. 协议版本不匹配

MCP 初始化时，客户端会传入协议版本。

一开始我在服务端写死了版本号，导致部分客户端出现兼容问题。

更稳妥的做法是：

服务端回显客户端传入的 protocolVersion

这样可以减少版本不一致导致的初始化失败。

---

4. 进程缓存导致修改不生效

我修改了 server.js，但 CodeX 仍然表现得像在运行旧代码。

原因是 MCP Server 进程没有重启，CodeX 还在使用之前启动的 Node.js 进程。

解决方式很简单：

修改 server.js 后，重启 CodeX 或手动结束旧的 node 进程

之后新代码才会真正生效。

---

整体工作流

最终工作流如下：

1. CodeX 分析需求并拆分任务
2. CodeX 通过 send_task 写入 tasks.json
3. Reasonix 检查任务队列
4. Reasonix 执行 pending 任务
5. Reasonix 写回执行结果
6. CodeX 读取结果并进行审核
7. 根据审核结果继续生成下一步任务

这个流程让两个 AI 各自发挥优势：

CodeX：负责思考、规划、审核
Reasonix：负责执行、操作 Unity、修改资源

我不再需要手动复制粘贴任务，也不用在两个 AI 之间来回转述上下文。

---

总结

这个文件桥方案并不复杂，本质上就是：

MCP + Node.js + JSON 文件任务队列

完整代码大约 100 行左右，但解决了一个非常实际的问题：

让不同 AI 工具可以互相传递任务，而不是让开发者充当中间人。

它的优点是：

• 实现简单
• 不依赖数据库
• 不需要复杂后端服务
• 方便调试
• 适合本地开发工作流
• 可以让多个 AI 工具接力协作

用到的关键技术包括：

MCP stdio 传输
JSON-RPC 消息格式
Node.js 标准输入输出
JSON 文件读写
文件作为进程间通信媒介

这个方案尤其适合下面这类场景：

不同 AI 工具各有专长
一个 AI 负责规划
一个 AI 负责执行
需要自动传递任务和结果
不想搭建复杂服务
项目主要在本地开发环境中运行

最终效果是：
CodeX 不再只是“想出方案”，Reasonix 也不再只是“等待指令”。两者可以通过一个简单的任务桥形成完整闭环，真正实现 AI 工具之间的协作。