重点先行
这个skill让agent通过MCP互相传递消息，而agent在使用MCP的时候是愿意等待很久的——可以让一个agent一直保持干活状态，另一个agent给它更新派发任务 
；MCP是很多agent都支持的功能，所以你的SOLO可以指挥所有支持MCP的agent……
Gitee仓库（国内；可以点击下载zip）：mcp-agent-bus: 让多个agent可以通过MCP互相布置任务
1、Skill 简介
MCP Agent Task Bus 是一个本地 MCP 任务总线 Skill，用来让多个 SOLO 对话之间传递任务、进度、结果和证据。
简单说，它解决的是一个很实际的问题：当一个复杂项目需要规划、测试、文档、审查等多个步骤时，单个 SOLO 对话容易背太多上下文；这个 Skill 让一个主对话负责拆任务和验收，多个 worker 对话分别负责具体执行，并把每一步结果记录下来。
2、使用场景
为什么做它？
我在用 SOLO 做真实项目时，经常会遇到一个问题：一个对话里既要规划，又要执行，又要测试，还要写文档。任务一长，聊天上下文就会越来越重，后面容易出现几种情况：
-
主线任务和细节任务混在一起
-
测试结果散落在对话里，不方便追踪
-
worker 做了什么、有没有证据，不够清楚
-
需要手动复制粘贴任务给另一个对话
-
多个对话之间没有统一的任务状态
所以我想做一个很小但实际有用的 Skill：让 SOLO 的不同对话可以像一个小团队一样协作。
做出来之后省掉了什么？
以前的流程大概是：
-
主对话想好任务
-
手动复制给另一个对话
-
worker 对话执行
-
再手动复制结果回来
-
自己判断有没有完成
现在可以变成：
-
planner 对话通过 MCP Agent Task Bus 发任务
-
worker 对话等待/领取任务
-
worker 执行后提交 summary、changed_files、evidence
-
planner 对话读取结果并验收
-
所有任务状态和进度留在本地日志中
它不追求“大而全”，而是把多对话协作中最容易混乱的“任务接力”做清楚。
3、创作过程
这个 Skill 是一次人类 + agent 协作实验的结果。
最开始，我想验证一个想法：如果 SOLO、Codex 或其他支持 MCP 的 agent 工具都能连接同一个本地任务总线，那它们是不是就可以通过本地文件/数据库进行任务接力？
初始原型由另外的agent 
使用AI润色后的prompt生成，随后我完全使用 SOLO 基于AI润色过的prompt完成了测试、文档、SOLO 多对话适配和 Skill 化包装。
第一阶段：最小 MCP Agent Bus 原型
原型实现了一个本地任务总线：
-
用 SQLite 保存当前任务状态
-
用 JSONL 记录 append-only event log
-
提供 MCP stdio server
-
提供 CLI 和 smoke test
-
支持
register_agent、send_task、wait_for_task、finish_task等核心工具
这个阶段先解决“任务能不能被发出、领取、完成、查询”的问题。
第二阶段：SOLO 接手测试和文档
我让 SOLO 接手测试和文档整理。比较让我惊喜的是，这次 SOLO CN 明显比我上次参赛时更稳了一些：它没有一上来就吹“全部完成”，而是认真区分了哪些已经运行验证、哪些只是静态检查、哪些还没真实测试。
SOLO 主要完成了：
-
补充单元测试
-
运行
bash run_smoke.sh -
创建
SCOPE.md -
更新
README.md -
整理
TODO.md -
编写 SOLO Skill 参赛草稿
-
记录当前限制和未验证事项
这次它在“不要夸大测试结果”这件事上进步明显，甚至会主动写出未验证项。
第三阶段：真实 SOLO 双对话测试
真的开了两个 SOLO 对话来测。
第一轮测试：
-
planner-minimal 发任务
-
worker-minimal 收到任务
-
worker-minimal 调用
append_progress -
worker-minimal 调用
finish_task(done) -
planner-minimal 调用
get_task读取结果
结果通过。
第四阶段：发现同名 MCP server 可能串行
测试中还发现一个很有价值的问题：如果两个 SOLO 对话使用同一个 MCP server alias（MCP服务器别名），并且 worker 正在长时间 wait_for_task，planner 的 MCP 调用可能会被卡住。
这说明某些 MCP host 可能会对同名 stdio server 的 tool call 串行化。
于是我调整了推荐使用方式：
-
给 planner 配置一个 MCP server alias：
agent-bus-planner -
给 worker 配置另一个 MCP server alias：
agent-bus-worker -
两个 alias 运行同一个 server
-
两个 alias 共享同一个
MCP_AGENT_BUS_DATA_DIR
这样每个对话有自己的 MCP 通道，但它们共享同一个本地任务数据库。
第五阶段：双 MCP server alias 实时通信测试成功
我在SOLO中配置了两个名字不同但目录相同的MCP服务（见下一节），两个 MCP server alias 共享同一个本地 data dir，然后用两个 SOLO 对话做了真实测试。
一个对话作为 planner，使用 agent-bus-planner 服务发送任务；另一个对话作为 worker，使用 agent-bus-worker 服务等待任务。
测试中，worker 在等待状态下成功收到了 planner 发来的任务，随后记录进度并提交 done 结果；planner 也成功读取到了 worker 返回的完成状态和证据。
也就是说，这个 Skill 已经跑通了最核心的流程：一个 SOLO 对话发任务，另一个 SOLO 对话接任务、完成任务，并把结果回传。
截图展示：
-
planner 发送和读取结果
-
worker 等待和完成任务
补充：项目也支持同一个MCP使用非阻塞模式（poll_for_task / poll_for_result），但这次展示的重点是已经实测通过的多 MCP alias 通信。
4、使用步骤
方式一：GitHub clone 安装
git clone https://github.com/SamZebrado/mcp-agent-bus.git
cd mcp-agent-bus
bash run_smoke.sh
如果看到类似：
SMOKE OK
Ran 16 tests
OK
说明本地核心功能正常。
方式二：下载 ZIP 后让 SOLO 辅助配置
-
下载 GitHub ZIP
-
解压到本地目录
-
在 SOLO 中打开项目目录
-
让 SOLO 阅读
README.md和.trae/skills/mcp-agent-bus/SKILL.md -
让 SOLO 帮你生成 MCP server alias 配置
-
手动复制到 SOLO / TRAE 的 MCP 设置中
-
重启或刷新 MCP
-
开两个 SOLO 对话做最小联通测试
推荐 MCP 配置方式
建议为不同角色配置不同 MCP server alias，但共享同一个 data dir：
{
"mcpServers": {
"agent-bus-planner": {
"command": "python3",
"args": ["-m", "mcp_agent_bus.server"],
"env": {
"PYTHONPATH": "/path/to/mcp-agent-bus",
"MCP_AGENT_BUS_DATA_DIR": "/path/to/mcp-agent-bus/data"
}
},
"agent-bus-worker-docs": {
"command": "python3",
"args": ["-m", "mcp_agent_bus.server"],
"env": {
"PYTHONPATH": "/path/to/mcp-agent-bus",
"MCP_AGENT_BUS_DATA_DIR": "/path/to/mcp-agent-bus/data"
}
},
"agent-bus-worker-tests": {
"command": "python3",
"args": ["-m", "mcp_agent_bus.server"],
"env": {
"PYTHONPATH": "/path/to/mcp-agent-bus",
"MCP_AGENT_BUS_DATA_DIR": "/path/to/mcp-agent-bus/data"
}
}
}
}
注意：MCP server alias 和 agent name 不是一回事。
推荐映射：
| SOLO 对话 | MCP server alias | agent_name |
|---|---|---|
| 主控/规划对话 | agent-bus-planner |
planner-main |
| 文档 worker | agent-bus-worker-docs |
worker-docs |
| 测试 worker | agent-bus-worker-tests |
worker-tests |
| 审查 worker | agent-bus-worker-review |
worker-review |
planner 发任务时，to 应该写 agent_name，例如 worker-docs，不是 MCP server alias。
SOLO MCP 配置小技巧：现在的SOLO配置界面要一条一条粘贴，不太方便
；可以直接新建一个对话把上边的配置粘贴进去
Planner 示例
你是 planner-main。请使用 agent-bus-planner。
1. register_agent:
agent_name = "planner-main"
role = "planner"
2. send_task:
to = "worker-docs"
from_agent = "planner-main"
body = "请检查 README 并提出修改建议。"
acceptance_criteria = [
"读取 README",
"指出至少 3 个可以改进的地方",
"不要修改文件，只返回建议"
]
3. 记录 task_id。
4. 稍后调用 wait_for_result 或 poll_for_result 查看结果。
Worker 示例
你是 worker-docs。请使用 agent-bus-worker-docs。
1. register_agent:
agent_name = "worker-docs"
role = "worker"
2. wait_for_task:
agent_name = "worker-docs"
max_wait_s = 120
lease_s = 600
3. 收到任务后执行。
4. 调用 append_progress 记录进展。
5. 调用 finish_task 返回 summary、changed_files 和 evidence。
Blocking 和 Polling 两种模式
这个 Skill 同时支持两种任务领取方式：
Blocking wait 模式
-
wait_for_task -
wait_for_result
适合给每个对话配置独立 MCP server alias 的情况。
Polling 模式
-
poll_for_task -
poll_for_result
适合同一个 MCP server alias 可能被串行化、或者你不希望长时间阻塞工具调用的情况。
5、Skill 链接
-
Skill 文件：
.trae/skills/mcp-agent-bus/SKILL.md -
安装指南：
docs/skill_installation_guide.md -
Demo / 截图：待补充
-
Skill 商店链接：待补充（如发布成功后补上）
6、总结与思考
这个 Skill 目前最让我满意的地方，不是它有多复杂，而是它解决了一个很真实的小痛点：多个 SOLO 对话之间终于可以有一个“任务收发台”。
以前多对话协作更像手动传纸条；现在可以变成：
-
谁发了任务
-
谁领取了任务
-
执行到哪一步
-
是否完成
-
有什么证据
-
planner 是否读到结果
这些都能被记录下来。
这次使用 SOLO 的体验也让我有点意外。相比我上次参赛时的感觉，这次 SOLO CN 在测试、文档整理和边界说明上明显更稳了一些。它这次准确地做到了把已验证、未验证、真实限制分开写；并且。
比如在这个项目里，它帮助补充测试、整理 README，并且把“同名 MCP server 可能串行化”这样的实际观察记录到了文档里。
当前版本还有很多可以优化的地方：
-
更友好的安装脚本
-
更完整的 Skill 导入流程
-
更清晰的多 worker 模板
-
planner 对结果的显式 accept/reject 流程
-
parent/child task 支持
-
Streamable HTTP transport
-
更多 MCP host 的兼容性验证
但是，它已经可以使用了，欢迎大家拿它试试更复杂的 SOLO 多对话工作流，比如：
-
一个 planner + 一个测试 worker + 一个文档 worker
-
主对话负责规划，worker 分别执行不同任务
-
最后主对话统一验收结果
嘿嘿嘿——我突然想起来第一次使用TRAE CN的时候它说它支持MCP，我当时就误会成它可以作为MCP被指挥，后来发现并不是那么回事儿；现在凑巧工作需要就把这个误会给实现了 