开源的桌面端多 Agent 工作台，用流程图看见 AI 如何完成任务（Windows / Ubuntu Linux）。
Zhumora 可以连接 OpenAI 兼容模型，并操作你的文件、终端、浏览器和桌面。程序本体以本地运行为主，同时支持 MCP、Skills、长期记忆和权限控制。
主 Agent 负责理解需求、设计方案、协调与验收，子 Agent 负责边界明确的小任务，编码任务默认按单个文件分工。你可以分别配置主、子 Agent 的模型，并在同一张流程图里查看派工、执行与结果汇合。
English · 技术文档 · bilibili视频
每次 LLM 发言是一个主节点，思考和工具调用作为内部小节点展开。子 Agent 从具体派工步骤分叉，主 Agent 取回子任务的终态结果后，连线汇合到对应的等待步骤。点击节点可以查看正文、模型实际返回的思考、工具参数与结果。
历史按用户轮次折叠，最新一轮保持展开，旧轮次可单独展开。折叠只改变展示，不删除完整消息历史。
对话流程、节点详情、输入区都是可移动面板，支持停靠、浮动或打开为独立窗口，并沿用深色 / 浅色主题。移动输入区时，未发送的文字和附件会保留。
画布滚轮控制缩放；开启“自动跟随”后，单 Agent 的当前节点越出视野时才轻移镜头，多 Agent 并发时尽量展示主流程与各分支的当前工作节点，节点已经可见就不反复居中。自定义缩放比例保持不变；放不下的活跃节点会显示数量，点击“显示活跃节点”可主动重新调整缩放。已打开的详情继续跟随最新主节点及其当前内部步骤：工具执行时显示参数，返回后显示结果，接续 LLM 时切到内容/思考；不在子 Agent 之间来回切换。手动选择旧步骤或 tab 后暂停自动切换。发言正文与详情在运行中滚动到最新输出，手动向上阅读时暂停内容跟随，回到底部后恢复。点击旧节点会暂停运行跟随，方便检查历史。
主 Agent 优先把可独立执行的修改派给子 Agent，负责接口约定、依赖顺序、实际改动审查及最终测试。子 Agent 默认聚焦一个文件或一个只读问题。同一父任务会拒绝把仍由活动子任务负责的文件再次派给另一个子任务。
并发上限来自各 LLM provider 的配置，留空不限制。同一 provider 的主 Agent、子 Agent、其他会话及辅助补全共享请求额度，超过上限时排队。没有额外写死的子 Agent 并发数量或累计启动次数限制。
- 以 LLM 发言组织对话流程图，内嵌思考 / 工具步骤，显示子 Agent 分叉与结果汇合
- 对话、详情、输入面板可停靠、浮动或独立成窗，支持自定义缩放下的运行跟随
- 主 / 子 Agent 模型独立配置，按 provider 统一控制 LLM 请求并发
- 支持 OpenAI 兼容 API，也可接入 Ollama、llama.cpp、vLLM 等本地端点
- 在指定工作目录内读取、编辑、搜索和管理文件
- 通过按格式划分的内置工具读写 Word、Excel、PowerPoint 和 PDF 文件
- 执行终端命令，长输出保留首尾并限制行数和长度；文件与目录支持分页读取，搜索和网页正文也有预览上限
- 使用 Playwright 自动化 Chromium
- 通过无障碍元素、截图、鼠标和键盘观察并控制 Windows 应用（Linux 上桌面控制仅保留截图观察）
- 通过 MCP 扩展工具
- 自身也是 MCP 服务器，可供 Claude Code、Codex 等外部编排器接入并委托任务
- 从 Markdown 文件加载 Skills
- 本地保存会话、长期记忆和 Token 用量
- 自动压缩只改变模型工作上下文，保留完整历史；发送前复检完整请求预算，对最近的超大工具结果生成有界预览
- 接入 Telegram Bot 或 QQ Bot，用手机和同一个本地 Agent 对话，实时显示进度
- 可导入 VRM 角色并按会话手动开启独立透明 Avatar 窗口，由 Agent 调用已配置的动作和表情
- 对高风险操作进行权限确认
- 支持深色 / 浅色主题与多语言界面
在 设置 → 聊天机器人 里接入 Telegram Bot 或 QQ Bot，就能用手机和同一个本地 Agent 对话，不必守在电脑前。
- 双平台接入 — Telegram 填 BotFather Token，QQ 填开放平台的 AppID / AppSecret，两端跑的是同一个 Agent、同一套工具和权限
- 看得见进度 — 思考过程实时流出（
💭 …），每个工具调用都即时可见（🔧 bash: npm test），完成后变成✅ 1.2s，长时间任务不会让人以为卡死 - 随时随地审批 — 高风险操作会在聊天里请求确认：Telegram 发「允许 / 拒绝」内联按钮，QQ 回复
y/n - 始终可控 — Bot 只响应白名单用户（先发
/id拿到自己的 ID / OpenID），随时/stop中止当前任务
Zhumora 可以直接操作 Windows 桌面：
- 观察 — 列出运行中的应用、截取屏幕、读取任意窗口的 UI 无障碍树（含短期有效的语义元素引用）
- 操作 — 点击、双击、右键、输入、按键、滚动、拖拽、聚焦、切换控件，可基于无障碍元素引用或截图坐标定位
- 验证 — 改变应用状态的操作默认附带截图；单纯移动指针仅在明确请求时截图
这让 Zhumora 能够驱动没有 API 或命令行的原生 Windows 应用，而不仅仅是文件、终端和浏览器。
Linux 版本：无障碍树和输入注入依赖 Windows 专有的 Terminator 库，因此桌面控制仅保留截图观察（
desktop_observe的screen模式）；文件、终端、浏览器等其余能力不受影响。
Zhumora 本身也是一个 MCP 服务器。Claude Code、Codex 等外部编排器可以把它当作协作者，把成块的任务委托进来，由同一个本地 Agent 执行。
在 设置 → MCP 对外服务 打开开关即可，页面会显示运行状态、端点地址，并生成可直接粘贴的客户端配置（给 Claude Desktop、Cursor、Cline 等的是 JSON，给 Codex 的是 TOML）。
- 仅本机回环 + Bearer 令牌 — 服务器只监听
127.0.0.1，客户端用Authorization: Bearer <令牌>鉴权。令牌在首次启用时生成并落库固定，不会随应用重启自动轮换；换令牌或端口后重新复制一份配置即可。 - 一次委托就是一个会话 — 每个委托任务都是侧边栏里的一个 Zhumora 会话，和你在桌面手动发起的会话一样实时显示进度、写入历史，也可以随时中止。
- 跟进到终态 — 外部编排器用
zhumora_chat投递任务，用zhumora_wait等待完成（有界长等待 + 进度通知），拿到的是自包含的最终答复，而不是被误当成完成的running；断线重连后仍可取回结果。 - 权限仍在你手里 — 默认「仅桌面确认（推荐）」：外部编排器只能看到任务在等待权限，批准或拒绝由你在 Zhumora 桌面里完成。开启「允许客户端裁决普通级操作」后，它才能在你授予的权限范围内用
zhumora_respond批准普通级工具；危险操作始终等你确认。 - 诊断而非轮询 —
zhumora_status只提供任务的瞬时状态快照，不用于定时轮询。
- Windows 10 / 11，或 Ubuntu Linux（x64）
- Node.js 22.12+（推荐 Node.js 24 LTS）
- npm
npm installnpm run devnpm run buildnpm run build:winnpm run build:linux安装包输出到 release/。
在 设置 中添加 OpenAI 兼容 Provider：
- Base URL
- API Key（如需要）
- 模型名称
- Temperature
- Reasoning Effort
- Context Window
- 并发上限（正整数，留空不限制）
本地和远程模型端点均可使用。
并发上限在 设置 → LLM 提供商 的单个 provider 中配置并保存。它限制该 provider 同时进行的 LLM 请求，流式回复直到结束才释放额度；超额请求排队，取消任务时仍可取消等待。不同 provider 分别计数，同一 provider 下不同模型共享额度。该值是你配置的客户端限制，不代表 Zhumora 自动探测到了服务商的真实容量。
在 设置 → Avatar 导入 .vrm 角色，并可为角色填写内嵌动画名称或导入 .vrma 动画（一次可多选多个文件）。新会话默认关闭 Avatar；需要时在会话输入栏的 Avatar 上拉菜单选择角色。启用后，角色运行在可拖动的独立透明窗口中，Agent 只能调用该角色已报告或已配置的动作与表情。
Avatar 自带程序生成的待机、说话、点头、摇头、打招呼、挥手、耸肩、鞠躬、鼓掌、庆祝、伤心等动作（适配 VRM 0/1），并有呼吸、重心微移、手臂随动和手指微曲的常驻生命感动画。
项目不附带角色模型。@pixiv/three-vrm 代码采用 MIT 许可证，但每个 VRM 模型拥有独立许可；导入和分发模型前请自行确认模型作者的授权范围。
在 设置 → 通用 → Agent 行为 → 启用子 Agent 打开或关闭（点击“保存设置”后生效）。关闭会阻止新建和继续子任务，已启动任务仍可完成、等待或取消。
开启时，主 Agent 默认先明确接口与验收标准，主动把可独立执行的小任务交给子 Agent，无需在每次提问中提醒。通常每个子 Agent 负责一个文件，主 Agent 协调依赖、审查修改并完成最终验证；简单修改可以直接处理。
在 设置 → LLM 提供商 → 允许子 Agent 使用 可逐个限制 provider（默认允许），例如保留昂贵模型给主 Agent。关闭后禁止该 provider 新建或继续子任务，已有任务可完成、等待或取消；主会话不受影响。显式指定模型也不能绕过此开关。
在通用设置的 子模型优先序列 中添加供应商与模型，通过拖拽或上移/下移调整顺序，也可一键添加各供应商默认模型。保存后用于新子任务；旧的单子模型配置升级为单项序列，空列表继承主模型。失效条目保留展示，新任务跳过停用或禁止子 Agent 的供应商；序列没有任何可用项时明确报错。
优先使用 尽量使用靠前供应商，已占用时选择后续可用项；靠前供应商不限制并发时，后续项可能不会被使用。分散并发 按序列在可用供应商间轮转。同一供应商多个模型共享额度和轮转位置，优先使用其首个模型。分配同时参考实际请求占用和正在准备/执行的子任务；工具或审批等待可能使分配较保守，实际请求上限仍由 provider 队列保证，全部繁忙时排队且可取消。没有额外固定子任务数量上限。
个别任务仍可在聊天中明确指定提供商与模型，覆盖序列。调整顺序不改变主模型或已有子任务；继续已有子任务保留原会话、历史和模型，原供应商不可用时明确失败。
Zhumora 可以在工作时主动创建多个子 Agent；每个子 Agent 有独立会话历史，并可选择设置中已启用的 LLM provider 和模型。可直接提出：“把这项任务拆成独立子任务并行处理，分别用不同 provider，等结果后汇总。”
主 Agent 使用 spawn_subagent 创建、wait_subagents 等待、continue_subagent 继续已有子会话、cancel_subagent 停止自己的子任务，list_subagent_providers 查看可选 provider。默认省略模型参数，由应用按序列分配；显式指定 provider 时，未指定模型则使用该 provider 的首个序列模型、匹配的主模型或供应商默认模型。
子任务失败时，主 Agent 能从任务列表、等待结果和终态通知查看失败类别、当前阶段、工具执行进度及续跑建议。断网、限流或没有最终交付就停止的任务，待运行释放且问题消除后，可用 continue_subagent 拉起原来的子会话，保留历史、模型、角色、文件和已有改动，返回新的 task ID。启动准备失败时也会补回原工作目标，不会只向空会话发送一句“继续”。
重试中或等待权限不视为失败，用户取消不会自动重启；连续同类失败会提示先排查，配置或上下文问题要先修复。系统不在后台无限重启，也不按静默时长猜测任务已死。非空回复只表示该轮结束，主 Agent 仍需检查实际改动和验收结果，未完成的工作继续原任务。
输入区的 并行协作 要求主 Agent 优先拆分并行小任务，适合“执行已有计划”。开启后在当前会话工作区持续保持，发送后不会熄灭，可手动关闭；切换会话后恢复默认。关闭表示恢复默认自动委托策略，不是禁止子 Agent。它不改变模型、批准模式或 provider 并发限制。
画布上方的 展开子任务 只显示或隐藏流程图分支，与派工偏好独立；隐藏不会停止子任务。真正禁用子 Agent 请使用设置中的“启用子 Agent”。画布的"展开历史 / 展开子任务"显示开关会记住你的选择（本地存储，跨会话切换与重启保留）；"自动跟随"与镜头缩放不记忆，每次恢复为运行时默认。
子任务支持探查（explorer）、单文件实现（implementer）、审查（reviewer）、验证（verifier）四种职责，并可提供上下文、验收标准、验证命令和返回格式。dependsOn 要求前置任务完成并释放后才允许创建；依赖未就绪时由主 Agent 等待、审查后再派发。list_subagents 查看当前任务清单，send_subagent_message 给运行中的子任务补充小段上下文，消息在下一安全轮次交付，不能中断工具或绕过审批。完成通知提示取回结果，完整结果仍由 wait_subagents 返回并接受主 Agent 审查。
编码任务建议直接说明分工，例如：
先确认接口和验收标准，再把独立修改按文件交给子 Agent 并行完成。每个子 Agent 只负责一个文件，遇到额外依赖先向你报告。你负责协调、审查实际 diff、运行最终测试与构建，全部完成后汇总。
主 Agent 能读取启用 provider 的 maxConcurrency 来安排派工；额度只约束实际 LLM 请求，排队中的子任务仍然是活动任务。未填写上限时不限制并发，系统不再另设固定的子任务数量或累计启动次数预算。
左侧列表只显示主会话，子 Agent 不单独列出。可在流程图查看子任务分叉与汇合，并通过节点详情的“打开所属会话”查看子历史、创建模型和所属主会话。当前支持一层子 Agent，不支持子 Agent 再次派工。主任务停止或结束时取消未结束子任务，完整子历史保留；重启后不自动恢复任务。文件分工是协作契约与同一父任务内的防冲突检查，不是文件系统沙箱。文件、浏览器和物理桌面仍是共享资源，所有工具继续受统一权限控制。
我们希望每个人都能在自己的电脑上组织一支看得见、能干预的 AI 工作团队。用户提出目标，主 Agent 负责计划与验收，子 Agent 处理清晰的小任务；整个过程保留可检查的执行记录。
Zhumora 将持续围绕可视化协作、模型选择权和用户控制权发展。执行过程可以更自主，授权边界仍由人决定。详细愿景与未来方向见 VISION.md，其中未来目标不代表已经实现。
会话/消息系统的权威架构与开发约束见 ARCHITECTURE.md 和 AGENTS.md；工具系统、上下文管理、长期记忆、MCP 和构建细节见 TECHNICAL.md。
产品愿景见 VISION.md；对外介绍、演示脚本与宣传 PPT 见 PROMOTION.md。反馈和复现信息可提交到 GitHub Issues。
Zhumora 采用 AGPL-v3.0
此前已经按 MIT 许可证发布的版本继续适用当时授予的条款。第三方组件仍采用各自 的许可证，详见 THIRD_PARTY_NOTICES.md。