我不想每次都 handoff,所以做了一个 Agent 集群助手
预计字数:约 3000 字 阅读时间:约 8 分钟 难度等级:⭐⭐(小白友好,用过 AI 工具更容易理解)
核心价值:看懂多个 AI Agent 为什么需要统一中枢,以及人应该在什么时候介入任务。你缺的可能不是更多 Agent,而是一个能让 Agent 真正分工、协作、交付的指挥系统。
我最近被一个 Markdown 文件折腾烦了。
文件名一般叫 HANDOFF.md
顺便提一句,什么事 handoff?
就是把当前任务的状态、改了什么、哪里没做完、下一步该检查什么
写成一份 Markdown,交给下一个 Agent 接着干。
我让 Codex 做完一轮,再交给 Claude Code 接着处理,它要写一份交接文件。
我让 Claude Code 检查 Codex 的方案,或者让二者互相挑刺,又要来一份。
任务背景是什么,改了哪些文件,哪里还没完成,下一步要检查什么……全部塞进去。
写一次不难。
麻烦的是它必须一直稳定。
少一段上下文,后面的 Agent 可能要重新调查。任
务已经走到下一步了,文件还停在上一个时间点。
两个 Agent 都能干活,但我夹在中间,负责搬文件、补背景、确认对方到底有没有看懂。
折腾几次之后我突然意识到:
我需要的不是一份更完整的交接文档。我需要的是,不要再靠我手工交接。
三个高手,不等于一支队伍
我现在会同时用 Codex、Claude Code 和 Hermes。
它们擅长的事不一样。
- Codex 做规划和编码验收
- Claude Code 擅长长任务和工程执行
- Hermes 更像我长期在用的助手,连着资料、记忆、定时任务和 Obsidian 知识库。
单独拿出来,都能做事。放到同一个复杂任务里,问题就来了。
- 谁先做?
- 谁来接着做?
- 谁负责挑刺?
前一个 Agent 做出的判断,后一个怎么稳定拿到?
执行到一半发现方向不对,在哪里叫停?
这不是 Agent 不够聪明。是它们缺一张共同的工作桌。
OpenAI 在 Agents SDK 的文档里
把 Agent 编排概括成几个很直接的问题:哪些 Agent 要运行,按什么顺序,下一步由谁决定。
Anthropic 介绍自己的多 Agent 研究系统时,用的也是“中枢负责策略,专业 Agent 分头执行”的结构。
所以这不是我一个人碰到的文件管理问题。它是一个协作问题。
不是第四个聊天框
有了这个判断,我开始做“智能中枢-Agent Central Brain”。
你也可以把它理解成一个 Agent 集群助手。
它不是把 Codex、Claude Code 和 Hermes 的聊天窗口拼在一起,然后让我同时和三个 AI 说话。那样只是窗口变多了。
我真正想做的是:
任务只讲一次,中枢负责保留任务状态、安排分工、传递前序结果、记录执行过程,产物放到同一个地方。
界面分成三块。左边是任务和协作成员。
中间是实时对话,Agent 的回复、命令执行、文件修改和工具调用都在这里持续滚动。
右边是产物,可以打开全文、滚动阅读、复制和继续处理。
原来散在聊天记录和交接文件里的东西,我把它重新放回一条可见的任务线上。
于是v1.1.0版本诞生了。
我做了一个中枢,一句话介绍:
智能中枢把 CLI Agent、模型 API 和本地网关接入同一个桌面工作台
由中枢负责路由、协作、过程记录和产物交付。
这里重点解释三层结构:
- 左侧:任务与协作成员。
- 中间:实时对话、处理进度和人工介入。
- 右侧:完整产物、审阅与 Obsidian 写回。
- 顶部设置:统一管理 Agent、API、路由规则和界面布局。
先判断要不要协作,再叫人
多 Agent 不应该变成一种仪式感。
不是每来一个任务就把所有 Agent 全叫过来开会。
一个边界清楚、风险低、只需要单一产物的任务,一个 Agent 往往就够了。
强行拆给三个人,交接成本可能比执行还高。
只有当任务跨越不同能力、存在可以并行的部分、或者需要独立检查时,多 Agent 才真正有价值。
所以我在智能中枢里做了三种模式:
- 单 Agent 独立完成
- 多 Agent 分阶段协作
- 以及让路由罗盘分析任务后给出建议。
重点不是系统替我选了谁。重点是它必须把理由摆出来。
我可以看到任务被拆成了哪些阶段,阶段之间有什么依赖,每一步准备交给哪个 Agent。
需要的话,我还能在开始前把某个阶段换给另一个连接器。
中枢可以给建议,但不能把分工变成黑箱。
🎯一次任务是怎么完成的
不要平铺功能,直接带大家走一遍完整流程。
这里选择一个真实任务,例如:
“调研 Kimi 和智谱的接入方式,完成配置迁移,并验证是否可用。”
流程如下:
- 输入任务目标。
- 路由罗盘判断适合单 Agent 还是多 Agent。
- 如果需要协作,生成任务阶段和依赖关系。
- 用户检查并修改每个阶段使用的 Agent。
- Agent 开始工作,中间实时显示回复、命令、文件和工具进度。
- 用户发现方向不对,可以直接补充要求。
- 中枢携带已有上下文继续执行。
- 最终产物进入右侧全文阅读器。
- 需要沉淀时,生成 Obsidian 写回提案。
- 用户预览并批准后才写入事实源。
人必须留在现场
这是我做这个工具时特别在意的一点。
很多 Agent 产品喜欢讲“全自动”。
你输入一句话,然后去喝杯咖啡,回来直接拿结果。
画面很好。
但不适合所有任务。
让 AI 整理一份内部资料,和让 AI 修改关键配置,不是同一个风险。
生成一个可以随时删除的草稿,和准备一篇要公开发布的文章,也不是同一个风险。
我的判断是:
实时介入还是完全放权,取决于任务对用户有多重要,也取决于用户和 AI 已经协作到了什么深度。
低风险、可逆、已经反复验证过的任务,可以多放一点权。
涉及公开发布、重要文件、关键判断和不可逆操作的任务,人就应该靠近一点。
这不是对 AI 没信心。
这是人在为自己的任务负责。
所以智能中枢的中间不是一块“运行日志”,而是一个真实对话框。
我可以在 Agent 执行时补充信息、纠正理解、改变方向。
系统会保留已经发生的事件,终止旧轮次,带着上下文继续运行。
我不是点完“开始”就被请出房间。
我始终坐在这张工作桌上。
Obsidian 不是 Agent 的垃圾桶
我一直把 Obsidian 当自己的大脑和长期事实源。
这也带来另一个问题:Agent 做完的内容,要不要自动写进去?
我的答案是,不要。
任务过程里会出现猜测、中间稿、失败结果和未经验证的判断。
如果所有内容都自动进入 Obsidian,知识库很快就会变成一个看起来很丰富、实际不敢相信的仓库。
所以智能中枢把运行过程先保存在本地 SQLite。
真正需要沉淀的产物,要先生成写回提案。
我能看到目标路径、已有文件状态、准备写入的正文,确认之后才进入 Obsidian。

AI 可以负责整理,但什么能成为长期事实,最后应该由人决定。
它现在能接入什么
| 类型 | 适合对象 | 能力边界 |
| CLI Agent | Codex、Claude Code、Hermes、OpenClaw、自定义 CLI | 可继承对应 CLI 的文件和工具能力,输出可实时流式展示 |
| OpenAI 兼容 API | Kimi、智谱、其他兼容服务 | 当前提供文本推理;不会直接获得本地文件和工具权限 |
| 统管网关 | CC Switch、自建路由层、兼容网关 | 统一模型、账号与故障切换;网关本身不是任务 Agent |
最早的想法来自 Codex 和 Claude Code 之间的交接。
做到 1.1 版本之后,我不再把它限制为固定的三个 Agent。
现在可以接入三类东西:
- Codex、Claude Code、Hermes、OpenClaw 这类 CLI Agent。
- Kimi、智谱或其他 OpenAI 兼容 API。
- CC Switch 或自建服务这类本地统管网关。
用户也可以添加自己的 CLI 或 API,不需要等我为每个新工具单独写一个入口。
这里有一个边界必须讲清楚:
CLI Agent 能不能操作本地文件、调用什么工具,取决于它自身已经拥有的权限。
API 连接器目前主要返回文本,不会因为接入中枢就自动获得本地文件能力。
API Key 保存到 macOS Keychain,本地数据库只保留引用名,不保存明文。
谁真的需要它
如果你平时只和一个网页聊天模型对话,任务也不涉及本地文件,这个工具可能会让事情变复杂。
但如果你已经在同时用两个以上 Agent,经常需要把研究、编码、审查、内容生产和知识沉淀串在一起,你大概率遇到过和我一样的问题。
- 不是没有工具。
- 是工具之间没有共同的任务状态。
- 不是没有结果。
- 是结果散落在不同窗口,最后还得由人重新拼起来。
智能中枢目前已发布 v1.1.0,提供 macOS Apple Silicon 版本
项目代码和体验版放到了 GitHub:https://github.com/daxiangnaoyang/agent-hub-desktop
它现在还不完美。
安装包没有经过 Apple Developer ID 签名和公证;API 连接器还是非流式文本响应;CLI 运行也不是原生长连接。Kimi、智谱、CC Switch 和 OpenClaw 的真实能力,仍然取决于用户自己的配置与权限。
这些限制我宁愿直接写出来。
因为我做这个项目,就是从“不稳定的交接”开始的。
如果最后靠模糊能力边界来推荐它,那就又回到了原来的问题。
🎯适合:
- 已经同时使用两个以上 AI Agent 的人。
- 使用 Obsidian 管理长期知识和项目的人。
- 经常执行研究、开发、内容生产等复杂任务的人。
- 想参与 AI 执行过程,而不是只接收最终答案的人。
- 一人公司和小团队。
暂时不适合:
- 只需要偶尔和 ChatGPT 聊天的人。
- 不使用本地 CLI 或 API 的纯网页用户。
- Intel Mac 用户。
- 期待开箱即用、完全自动授权的用户。
方向盘不能消失
我现在越来越确定一件事。
下一阶段的 AI 工具,不只是更聪明的聊天框。
它应该知道什么时候独立完成,什么时候需要协作;
知道谁来执行,谁来检查;
也应该允许人在关键节点重新拿回方向盘。
完全放权不是技术终点。
知道什么时候把方向盘交出去,才是人和 AI 真正开始协作。

既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果可以给我个星标⭐,将不胜感激~谢谢你看我的文章,我们,下次再见。
#AI-Agent #多Agent协作 #Codex #ClaudeCode #Hermes #Obsidian #智能中枢
作者:大象-推动 AI 共学,让普通人轻松上手AI
相关链接
- GitHub 项目:GitHub - daxiangnaoyang/agent-hub-desktop: Codex、Hermes 与 Claude Code 的本地桌面协作中枢 · GitHub
- v1.1.0 下载:Release 智能中枢-Agent Central Brain v1.1.0 · daxiangnaoyang/agent-hub-desktop · GitHub
- OpenAI Agent 编排说明:Agent orchestration - OpenAI Agents SDK
- Anthropic 多 Agent Research 系统:How we built our multi-agent research system \ Anthropic
- 社群站:https://daxiangnaoyang.github.io/daxiang-ai-gongxue/?motion=on
更多推荐



所有评论(0)