一句话结论：QoderWake 是阿里 Qoder 团队的生产级「数字员工」平台，它是 agent team 形态——但走的不是通用多 agent 框架那条路（不是 CrewAI / AG2 那种”给开发者编排原语”的思路），而是**”以岗位为单位的数字员工 + 编排器确定性调度的组织化协作”**：产品抽象层在「岗位/职责/权限」，而非「Agent 实例/消息传递」。部署上是完完全全的单体 + 单机，没有分布式集群形态。

一、基础信息与项目背景

项 内容
产品名 QoderWake（注意：用户口语中的 “qoderwake” 即此）
出品方 阿里巴巴 · Qoder 团队（属阿里云 Qoder 智能体产品家族）
官网 https://qoder.com/qoderwake
文档 https://docs.qoder.com/qoderwake/installation
首次发布 2026-04-30（与 Qoder 移动端同期发布）
v0.1 全球公测 2026-05（预置 6 个岗位，”5 分钟让一位数字员工上岗”）
1.0 正式发布 2026-09-07（2026-09-08 披露细节）
当前版本 v1.0.4（2026-09-14 更新）
产品定位 生产级数字员工平台；slogan “Always awake, always working.”
接入状态 邀测/公测阶段，官网申请
已落地规模 官方口径：3 个月内近 10 万个数字员工上岗，执行约 200 万次有效任务

Qoder 生态位

QoderWake 不是孤立产品，属于 Qoder 产品矩阵：

  • Qoder IDE — AI 驱动集成开发环境
  • Qoder CLI — 命令行工具（本机已在用，即 qodercli.exe）
  • QoderWake — 数字员工平台（本文主体）
  • Qoder 移动端 — 远程操控入口，已接入 Qoder CLI 全部能力，官方称将打通 IDE / Work / Wake 全系

关键差异点：Qoder CLI 是单次会话型 agent（你派一个任务、它跑完返回），QoderWake 是常驻岗位型 agent（有身份、有记忆、事件驱动、7×24 在线）。二者共用底层 Qoder CLI/SDK 执行能力。

二、核心能力：它凭什么算 agent team

2.1 用户视角：数字员工 vs 通用 Agent

维度 通用 AI Agent QoderWake 数字员工
存在形态 一次性会话，做完即忘 有姓名、岗位、入职日期、工作记录
驱动方式 人下指令 → 干活 → 结束 事件触发 → 自主接手 → 规划执行 → 需要时升级给人
运行时长 按需 7×24 常驻（Always awake）
记忆 单次上下文 跨任务持久化 + 五维自进化
组织关系 独立窗口，无组织概念 群聊成员身份，有职责边界与权限

2.2 Harness-First 架构（官方技术核心）

这是 QoderWake 最本质的技术设计，官方博文和阿里云开发者社区均有披露：

① 确定性与概率性职责分离

  • Orchestrator（编排器） 用确定性流程编排保障长时程任务稳定执行
  • 模型只负责意图理解与推理
  • 实现 Brain / Hands / Session 解耦
  • 配套模块：Context Assembler（上下文管理、前缀稳定性）、Scout（巡检 + 环境感知）

② 双层反馈与失败约束跨任务持久化

  • Executor 生成结果并即时验证
  • 独立的 Verifier（验证器） 审查整体结果
  • 验证失败触发 REWORK（重做），失败原因沉淀为知识，成为未来同类任务的先验输入

③ Session 作为唯一状态源

  • 所有执行管理事件与状态存入 Session 层
  • 任一组件崩溃可依据 Session 状态信息完整重建，恢复序列幂等
  • 这是”生产可用”的底座

判断：这套设计里有明确的对抗验证机制（Verifier 独立于 Executor），对应多 agent 协作中的”评审者”角色——但它目前是架构内建的可信机制，而非用户可自由编排的 agent 拓扑。

2.3 五维自进化 + 防腐机制

每次任务执行后，经验自动沉淀到五个维度：

  1. 记忆 — 结构化数据：代码库元信息、API 文档、历史工单
  2. 技能 — 哪些工具有效、哪些操作高效
  3. 策略 — 任务拆解与执行的最优路径
  4. 验证规则 — 质量检查的标准与方法
  5. 工作流 — 跨步骤、跨员工的协作流程

配套两个治理机制：

  • Critic-Refiner：任务完成后自动复盘冗余步骤与偏差判断，输出结构化学习信号，由系统判定该存入记忆 / 固化为技能 / 更新工作流
  • Anti-Rot Governance（防腐机制）：持续淘汰过时经验、合并冲突技能、撤回失效策略、降级沉淀——官方称之为解决”越用越乱”

另有一条**轨迹归因（Trajectory Attribution）**机制：基于完整任务轨迹判定经验应归属到记忆 / 技能 / 策略 / 验证规则 / 工作流哪一层，而非按预设规则。

三、多 agent 协作机制（本文核心问题）

3.1 结论先行

是 agent team，但形态自成一类。

如果套用此前调研归纳的六种主流拓扑，QoderWake 最接近 Manager / Hierarchy（层级型），同时融合了 Group chat（圆桌） 的入口形态与 Handoff（转交） 的升级机制。它不属于 Peer/Swarm（对等协商）、也不属于 Blackboard/Ledger（共享账本）。

3.2 三层协作结构

QoderWake 的多 agent 协作分三个层次，而不是一个：

第一层：IM 群聊入口 —— 一个 bot，背后多个 Waker

这是用户最直接感知到的一层，也是官方 @Waker 机制的核心：

“Use one group-chat bot to connect multiple Wakers and let the team start, track, and approve work in the original chat.”

工作方式：

  • 群里只接入一个机器人或一个账号作为统一入口
  • 群成员不需要知道背后配了几个 Waker、分别是什么岗位、更不需要记各自地址
  • 每次 @ 之后，QoderWake 判定四件事：
    1. 这条消息是新任务，还是对已有工作的继续 / 检查 / 修改 / 取消？
    2. 请求方是否显式指定了 Waker 或职责？
    3. 若未指定，路由规则是否命中？——都没命中则默认 Waker 响应或反问澄清
    4. 哪个 Waker 执行？任务状态里显示该 Waker，但所有回复仍由同一个 bot 发回群里

完整链路：

群内讨论 → @同一个 bot → 判定任务关系 → 路由到某个 Waker
        → 同一个 bot 返回进度与结果 → 人工审批 → 继续任务

关键设计：Project Coordinator / Engineering Executor / QA Reviewer 这类名字描述的是后端职责，不会变成群里另外几个机器人。群里始终只有一个可见身份。

第二层：Waker 群组 —— v1.0 新增，数字员工之间分工

这是 1.0 版本才有的能力，也是最接近”agent team”的一层：

官方更新日志原文：

“支持将多个本机或远程 Waker 加入同一个 Waker 群组，由默认负责人（Leader）接收任务，也可以通过 @ 指定成员参与。可为每位成员独立配置模型和工作目录，并通过群技能与协作 SOP 明确分工和协作方式。Waker 群组内可持续创建和切换任务，统一查看成员执行进度，以及按成员和共享空间归集的任务产物。”

创建群组时的实际界面要素（据官方截图）：

  • 群聊标题（如”新品发布协作群”）
  • Waker 成员（可混合本机 Waker 与远端 Waker，各自标注”本机”/“远端”）
  • 必须指定一位 Leader
  • 响应模型（可为单个 Waker 覆盖，仅应用于当前 Waker）
  • 工作目录（可选 Project 或本地目录；未选则用默认会话工作区）

官方对这套机制的解释：

“本机和远程的 Waker 都能进同一个群组，各自配模型和工作目录，谁跑在哪台机器上不影响一起干活。全新发布的群技能是这支队伍共用的本事。协作 SOP 定义怎么配合：谁先想、谁执行、谁验收、什么情况需要人来确认。同一支队伍可以换协作方式。要脑暴、要比方案，就把约束放宽；要按既定流程稳定交活，就按 SOP 走。”

这段是判断它是 agent team 的最硬证据：有 Leader、有职责分工、有共享技能、有协作 SOP（含角色时序与人工确认关口）、可切换协作模式（松散协商 vs 严格流程）。

第三层：WakerFlow —— 跨 Waker 的流程编排

官方更新日志原文：

“通过自然语言生成可运行的 WakerFlow，把复杂工作拆成多个步骤并交给不同 Waker 协作完成。支持手动运行，以及定时、事件和 API 触发；执行记录中可查看各节点的输入、思考、工具调用、输出和错误。支持版本历史与回滚，并可根据最近一次运行结果继续对话优化流程。”

这相当于把 agent team 的协作过程固化成可复用、可版本管理的流程资产——比单纯的”多 agent 对话”更工程化。

3.3 官方推荐的协作配置（可直接照抄）

角色配置基线（官方最佳实践）

“Assign two to four complementary Wakers to a chat:“

  1. 明确每个 Waker 负责什么、明确不负责什么
  2. 避免”通用助手”这类宽泛角色
  3. 为每类工作添加路由规则，并为代码合并、生产变更、对外发布设置人工审批边界
  4. 为每个 Waker 配置响应模型、工作区、文件权限——只包含该职责所需的目录
  5. 保存并确认会话为 Active，开启 @Waker；在测试群用同一 bot 启动两类工作，确认任务状态显示不同 Waker 而可见发送者始终不变

另有一条质量工具：

“如果页面提供 Check Responsibility Conflicts，在正式铺开前运行它。先收窄重叠职责，再对确需重叠的部分加路由优先级。“

官方范例：研发交付三角色

Waker Owns（负责） Does not own（明确不负责）
Project Coordinator（默认） 需求拆解、排期、进度、风险 不编辑应用代码
Engineering Executor 代码调研、实现、测试 不决定范围，不发布生产
QA Reviewer 测试设计、回归、验收总结 不批生产发布

对应路由规则：

需求拆解/排期/进度总结  → Project Coordinator
代码/构建/排障          → Engineering Executor
测试用例/回归/验收结果  → QA Reviewer
代码合并与生产发布       → 始终需人工审批

工作区隔离要求：

“只把目标仓库绑定给 Engineering Executor。QA Reviewer 用测试项目和测试文档目录。不要给每个 Waker 同一个高权限工作区。“

任务意图的推荐措辞（很实用）

意图 推荐措辞
继续任务 “Continue the build investigation and also check dependency versions.”
开新任务 “New task: Draft the release notes. This is unrelated to the investigation.”
查进度 “Report the status of the build investigation. Do not create a new task.“
修改任务 “Change the deliverable to a remediation plan only; do not edit code yet.”
取消任务 “Cancel the release-notes task.”

可复用的请求结构（不必点名执行者，让路由去选）：

@Bot [New task / Continue task / Report status / Modify task / Cancel task]
Goal:        要解决的问题
Input:       文件、链接、目录或已确认的结论
Deliverable: 要求的回复、文件与完成标准
Constraints: 禁止动作、权限边界、截止时间、审批关口
Owner:       仅在需要覆盖自动路由时才写 Waker 名或职责（可选）

官方提醒：每条消息只放一个主目标；重要约束要在任务消息里重申，不能依赖文件名或旧聊天记录。

3.4 安全与权限模型

  • RBAC + ABAC 混合权限模型
  • 权限红线强制拦截：删生产库、改主干分支等关键操作必须人工审批
  • 独立沙盒隔离：每位数字员工跑在独立权限沙盒中
  • 全链路审计日志：每一步操作入审计日志
  • 身份与职责动态校验：实时验证操作是否匹配该员工身份与职责
  • 默认拦截高危操作，命中预设规则时向用户申请授权

官方文档中的边界要求（值得注意的细节）：

  • “直接聊天不是凭证通道“——密码、token、客户隐私数据应通过受保护的凭证或数据连接提供
  • “不要附加未经脱敏的日志“
  • 返回群里的文本/图片/文件不得含凭证、个人信息或其他会话的数据
  • “不要让 Publishing Reviewer 既创作又审批同一份内容“

四、与已有调研的对照（六种拓扑定位）

对照此前归纳的六种主流 agent team 拓扑：

拓扑 QoderWake 对应情况
Orchestrator-worker ✅ 有。Orchestrator 确定性编排 + Executor 执行，但 worker 是”岗位”不是”同质副本”
Manager / Hierarchy ✅ 最贴近。Waker 群组的 Leader + 成员、职责边界、路由规则
Group chat 圆桌 ⚠️ 部分。IM 群聊是人的入口，数字员工之间的协商通过群组 Leader 与 SOP 约束，非自由圆桌
Handoff 转交 ✅ 有。”超出权限或能力边界，则把工作交回用户”；测试失败自动唤醒开发修复
Peer / Swarm ❌ 无。不是对等 agent 自由协商
Blackboard / Ledger ❌ 无。状态在 Session 层与 GitHub mark（属事实源回写，非共享账本）

独有特征：QoderWake 把”岗位身份“作为一等公民（Identity / Memory / Skills / Division of Labor / Permission Red Lines 五层构成），这是通用多 agent 框架普遍缺失的抽象层。CrewAI 的 Agent(role=...) 只是 prompt 层面的角色描述，而 QoderWake 的角色是带权限边界、工作区隔离、独立记忆和可审计身份的实体。

五、使用方式

5.1 创建数字员工的流程

控制台路径（Web Console → Waker Management → New Waker）：

  1. 选岗位 — 从角色市场选预置岗位，或选 “Custom Waker”
  2. 看角色卡 — 检查核心能力、工作风格、工作方法、捆绑的技能（Skills）
  3. 填信息 — 名称 + 确认 “What I own”（我负责什么）+ 运行环境；只保留首个任务所需的技能、知识库和连接器
  4. 创建 — 出现在 Waker 列表，卡片显示名称、描述、环境、状态

另一种更轻的路径（官方主推卖点）：一句话描述岗位需求 → 系统生成一份角色文档 → 用户修改/配置/确认 → 生成数字员工。

自定义数字员工时需写清：核心职责、工作风格、工作流、红线，并提供核心业务资料用于”培训”。

5.2 预置岗位（1.0 为 10 个）

公测版 6 个 → 1.0 扩至 10 个，覆盖研发、设计、项目、数据、内容、技术支持六个方向：

  1. 前端工程师
  2. 后端工程师
  3. 测试工程师
  4. 产品经理
  5. 数据分析师
  6. 内容运营
  7. 项目管理员（1.0 新增）
  8. UI 设计师（1.0 新增）
  9. DevOps 工程师（1.0 新增）
  10. 群聊答疑专员 Q仔（1.0 新增）

5.3 任务触发的五种方式

触发方式 说明 适用场景
手动派活 控制台对话页直接下达指令 临时任务、需求沟通
事件触发 代码提交、新 Issue、PR、系统告警自动唤醒 研发运维自动化
定时调度 “每天上午 9 点执行” 周期报告、巡检
关键词触发 命中关键词唤醒 群聊场景
API 调用 / Webhook HTTP 请求主动拉起 CI/CD 集成、外部系统调用

5.4 IM 接入（钉钉 / 飞书 / 企业微信）

  • 三大主流 IM 已打通
  • 数字员工以”群成员“身份常驻工作群，7×24 在线
  • 可读取组织里的文档、表格、待办、日历、组织架构、多维表格
  • 群里的讨论、附件、已确认口径 → 持续更新为数字员工的知识
  • 注意：@Waker 公测初期仅支持钉钉和飞书；企业微信在 1.0 官方口径中已列为打通

5.5 命令行工具（CLI）

安装后入口：~/.qoderwake/bin/qoderwake

服务管理：

qoderwake --version          # 版本
qoderwake login              # 浏览器授权登录
qoderwake whoami             # 查看当前账号
qoderwake start --open       # 启动并打开控制台
qoderwake portal             # 打开 Web 控制台（读取实际端口）
qoderwake portal --no-open   # 只打印地址不开浏览器
qoderwake status             # 服务状态
qoderwake restart --open     # 重启并打开控制台
qoderwake stop               # 正常停止
qoderwake stop --force       # 强制停止（可能中断运行中任务）
qoderwake logout             # 清除登录态

Token 登录（无 GUI 桌面必备）：

QODER_PERSONAL_ACCESS_TOKEN="your-token" \
  ~/.qoderwake/bin/qoderwake login --method token

# 或从文件读取
qoderwake login --method file --token-file /path/to/token

官方提醒：不要把真实 token 存进截图、任务消息或仓库。

关键：未登录时本地模式仍可用；云端与远程能力需要有效账号。

5.6 账号与认证（重要坑点）

  1. 注册用中国大陆手机号 + 短信验证码（不是邮箱注册）
  2. 密码须同时含大小写字母和数字，长度 ≥ 8 位
  3. 需要实名认证：上传身份证正反面，四角完整、文字清晰、无反光
  4. 审核通常 2 分钟内完成
  5. 单实例单账号：首次授权的账号成为 daemon owner / instance master account；此后同一实例只接受同一个 Qoder 账号，换账号认证会失败

六、部署方式（用户重点问题）

6.0 部署形态总览：先给结论

QoderWake 是纯单体 + 单机架构，官方文档没有任何分布式 / 集群 / 多节点部署说明。所谓”本地部署 vs 服务器部署”，区别不在架构，而在机器在哪：

部署形态 本质 官方支持
本地部署 装在你自己电脑上 ✅ 官方明确支持（macOS / Linux / Windows）
云桌面部署 装在带图形界面的云主机上 ✅ 官方专门章节
Linux ECS 部署 装在无图形界面的云服务器上（headless） ✅ 官方专门章节

两种环境的核心分水岭：有没有图形界面。这直接决定安装方式和访问 Web UI 的方式。

⚠️ 官方原文强调：“Both environments must stay powered on and running; otherwise, tasks in progress are interrupted.”（两种环境都必须保持开机运行，否则进行中的任务会被中断。）

6.1 系统要求（官方原文口径）

项目 要求
操作系统 macOS 13.0+ / 主流 Linux 发行版 / Windows 10+
内存 4 GB+ 推荐
磁盘 至少 500 MB 可用空间
网络 需能访问模型服务、代码仓库、连接器；企业网络须放行相关 HTTPS 出站
账号权限 当前用户能安装程序、启动后台服务、访问目标工作目录

⚠️ 重要勘误：网上多篇第三方教程（如塔候 2026-06 那篇）声称”Windows 暂未开放，敬请期待”。这与官方文档直接矛盾——官方 Quick Start 明确列 Windows 10+，且提供 .exe 安装包。以官方文档为准。

6.2 本机部署

macOS

方式一：安装包

  1. 打开 qoder.com/qoderwake，选 “MacOS”
  2. 按芯片选 ARM64 (Apple Silicon) 或 X64 (Intel)
  3. 下载 .dmg，拖入 Applications
  4. 打开 QoderWake，按提示完成账号授权，等待服务启动、Web Console 打开

方式二：命令行

curl -fsSL https://qoder-ide.oss-ap-southeast-1.aliyuncs.com/qoderwake/install.sh | bash

执行期间不要关闭终端。出现授权页时完成授权，回终端等待结束。

Linux（带图形界面）

curl -fsSL https://qoder-ide.oss-ap-southeast-1.aliyuncs.com/qoderwake/install.sh | bash

也可用 .AppImage 直接运行。需启用 GUI 桌面才能使用本地 Web Console。

Windows

  1. 官网下载 .exe 安装包
  2. 双击安装，按向导完成安装与账号授权
  3. 等待服务启动，Web Console 自动打开
  4. 若浏览器未自动打开：qoderwake portal

安装验证

qoderwake --version      # 返回版本号即成功
qoderwake status         # 返回服务状态

命令找不到时的完整路径：~/.qoderwake/bin/qoderwake

控制台

http://127.0.0.1:19820/
  • 默认端口 19820，端口被占用会自动递增
  • 界面布局：左侧是”我的 Waker”列表｜顶部”创建 Waker”｜主区是对话页｜右侧是任务与运行详情

官方说明：在云桌面/本机自己访问 Web UI 时，保持默认的 local-only 监听地址即可，无需改监听参数、无需在安全组放行 19820。

6.3 服务器部署

前置决策：云桌面 vs Linux ECS（官方对比表）

对比项 云桌面（带图形界面） Linux ECS（headless）
操作方式 远程连桌面，操作与本地电脑基本一致 仅命令行，通过 SSH
安装方式 在桌面上跑安装包或安装命令 通过 SSH 跑安装命令
打开 Web UI 在云桌面浏览器开本地地址 从本地浏览器经服务器地址或 SSH 端口转发访问
是否需暴露端口 否 直连方式需放行 TCP 19820
适用场景 保持本地使用习惯、想在图形界面确认运行状态 纯命令行环境、需长期无人值守运行

云桌面：推荐规格（官方）

配置 规格 磁盘 适用
标准 4 vCPU / 8 GB 100 GB 同时运行的 Waker 较少，代码仓库规模普通
高级 8 vCPU / 16 GB 160 GB 同时运行多个 Waker，或仓库/工作目录较大

官方建议：不确定先用标准配置；后续变慢或磁盘不足再升级。

云桌面系统要求：Windows 10+ / macOS 13.0+ / 带桌面环境的主流 Linux；能访问 Qoder 服务、模型服务、代码仓库、所用连接器；当前账号能装程序、起后台服务、访问工作目录。

若云桌面镜像由服务商分配，先检查是否已预装 QoderWake——预装则跳过安装直接登录。

云桌面安装（全部在云桌面内部完成，无需从本地传文件）：

  • Windows 云桌面：云桌面浏览器打开官网 → 下 .exe → 双击按向导装 → 完成授权 → 等服务启动
  • macOS 云桌面：下 .dmg（按芯片选 ARM64/X64）→ 拖入 Applications → 打开并授权
  • Linux 图形云桌面：终端执行 install.sh → 浏览器完成授权 → 回终端等待完成
  • 验证：qoderwake --version

Linux ECS（headless）：完整步骤

Step 1 — SSH 登录

ssh <username>@<server-ip>

Step 2 — 安装

curl -fsSL https://qoder-ide.oss-ap-southeast-1.aliyuncs.com/qoderwake/install.sh | bash
qoderwake --version

官方说明：安装器自动检测平台并下载组件；账号登录在打开 Web UI 之后完成，无需先在 ECS 上登录账号。
排障：提示找不到 qoderwake → 退出并重新建立 SSH 连接，或按安装器提示刷新当前 shell 环境。

Step 3 — 从两种访问方式中选一种

方式一：经服务器地址直接访问

# 先停掉当前进程（若未运行，提示 not-running 不影响后续）
qoderwake stop

# 监听所有网卡
qoderwake start --host 0.0.0.0 --port 19820

⚠️ 官方安全警告原文：命令执行后会提示网络暴露风险，需按提示输入 yes 确认。输入 yes 表示确认 QoderWake 将监听每一个网络接口——任何被安全组、防火墙、网络路径放行的设备都能访问 19820 端口。请把入站访问限制在可信源 IP 或网段。若无法确认网络边界，改用 SSH 端口转发。 输入 yes 不会自动打开安全组或防火墙，也不会配置 HTTPS 或 IP 白名单。

浏览器访问：

http://<server-ip>:19820/

前置条件：ECS 安全组、服务器防火墙、上游网络策略都需放行 TCP 19820 入站。

多设备访问注意：

  • 每台设备首次打开都需在自己的浏览器完成 Qoder 登录
  • 每台设备必须用同一个 Qoder 账号
  • 用别的账号会认证失败，进不去实例控制台

方式二：SSH 端口转发（推荐，更安全）

# ECS 上：仅监听本机
qoderwake stop
qoderwake start --host 127.0.0.1 --port 19820
# 本地电脑另开终端（不要在 ECS 终端里执行）
ssh -N -L 19820:127.0.0.1:19820 <username>@<server-ip>

-N 表示不执行远程命令。转发建立后通常不再输出任何内容，保持终端运行；Ctrl+C 结束转发。

浏览器访问：

http://127.0.0.1:19820/

关键差异：QoderWake 端口不直接对外暴露，全部走 SSH 隧道。

Step 4 — 完成 Qoder 登录

  1. QoderWake 页面点 “Login” → 原页显示 “Waiting to log in”，同时打开新的 Qoder 页面
  2. 新页若显示登录页先完成登录；若浏览器已登录 Qoder 则直接进账号确认页
  3. 在 “Continue to use this account?” 页确认账号 → 点 “Continue” → 回原页等待登录成功

首次绑定：实例若未关联 Qoder 账号，首次授权成功的账号即成为 daemon owner（实例主账号）；已关联的实例后续必须用同一个账号。登录过程中本地浏览器需能访问 https://qoder.com，同时 ECS 也需具备出站访问 Qoder 服务的能力。若点 Login 后没新页面，允许当前站点弹窗再试；完成授权前不要关闭原 QoderWake 页面。

Step 5 — 验收

  • 页面能正常加载
  • 能打开 Waker Management 并看到当前账号的 Waker 列表
  • 能创建或打开一个 Waker

6.4 保持常驻（官方要点）

官方文档未提供 systemd / launchd 的开机自启配置命令。与长期常驻直接相关的是两条：

① 防止云桌面休眠（官方明确要求，两层都要配）

  • 操作系统电源设置：把睡眠、休眠、关闭显示器后挂起全部设为”从不”
  • 云桌面控制台的会话与关机策略：关闭空闲断开、无人值守超时、定时关机；若无法关闭，超时设得比最长任务运行时间还长

官方补充：断开远程会话 ≠ 关闭云桌面。两层都配好后，断开连接时 QoderWake 仍在云桌面继续跑任务，下次连上可查看结果。
⚠️ 云桌面休眠、断开后被挂起、或被定时关机时，进行中的聊天任务和自动化任务会被中断，定时任务会错过触发时间。

② 通用要求：环境必须保持开机运行。

关于开机自启的具体细节，官方指向 General Configuration and Operation（/qoderwake/best-practices），本文未展开。

6.5 本机 vs 服务器：对比总结

维度 本机部署 服务器部署
适用 个人试用、轻量任务、开发调试 7×24 常驻、团队共用、生产值守
常驻能力 ❌ 关机即中断 ✅ 可长期在线（需配防休眠）
图形界面 ✅ 原生 云桌面 ✅ / ECS ❌（headless 需 SSH 转发）
端口暴露 不需要 云桌面不需要；ECS 直连需放行 19820
推荐配置 官方最低 4GB 内存 / 500MB 磁盘 云桌面标准 4C8G/100G，高级 8C16G/160G
远程 Waker 可加入群组 可加入群组（本机/远端混合是 v1.0 特性）
成本 无额外 ECS/云桌面按量计费（官方旧文曾提 ECS 2vCPU+4GiB+40GiB 下限）
风险 无 直连方式有暴露风险，强烈建议走 SSH 转发

选择建议：要 7×24 无人值守 → 服务器。只是想试、或者任务都是”你在线才需要它干” → 本机足够。团队成员要在群里 @它干活 → 服务器（本机一关机它就下线了）。

官方原话印证：“如果希望 @Waker 长时间在线，可以将 QoderWake 部署在云电脑上，避免本地设备关机影响任务运行。”

七、企业版方案：QoderWake × GitHub（官方参考实践）

官方企业文档里有一套完整的事件驱动研发协作方案，是理解”多 agent 如何在生产环境协作”的最好样本。

方案架构

GitHub（唯一事实源，产生事件）
   ↓
GitHub Actions（事件过滤 + 安全转发）
   ↓
QoderWake API（拉起自动化任务，唤醒角色化 Waker）
   ↓
各 Waker 干活，结果写回 GitHub

要点：角色行为由 BIBLE 长期约束；任务以隔离模式运行；业务状态通过 GitHub marker 维护。

六大优势（官方原文要点）

  1. 事件驱动 — 减少空闲轮询与竞态（避免”扫描过程中状态在底下变了”）
  2. 一个角色一个职责边界 — 开发/评审/测试/发布各自独立 Waker、独立 BIBLE、独立 API 任务；开发者不能批准自己的作品，评审者不改代码，测试者不编造交付物，发布 Waker 不替用户合并
  3. AI 产出写回事实源 — 代码、测试、评论、Bug、标签、发布全部写回 GitHub；聊天记录只用于观察执行，GitHub 才是下一个 Waker 能读、用户能审计的事实
  4. 机器执行与人的决策分层 — Waker 自动做分析、编码、测试、备料，但代码合并与正式发布仍由用户确认
  5. 技术与业务双幂等 — 调用层 wakeSessionUniqueId 防重复执行；业务层用 head SHA、merge SHA、GitHub marker 判断是否已完成；即使平台重试或事件重复，Waker 会重新校验并安全 NOOP
  6. 凭证只存在于密钥边界内 — PAT 和 API 地址只存 GitHub Actions Secrets；启动器做输入掩码与加密写入；工作流仅在运行时注入凭证；错误日志不输出响应体与凭证

四个角色与完整工作流

步骤 事件 角色 动作 写回证据
01 迭代创建 Release Waker 从 main 建 iteration/* 分支，需求推进到可开发 迭代分支、Milestone 状态
02 需求进入开发 Developer Waker 读需求事实，建 feature 分支，完成实现与测试，建代码 PR 代码 PR、测试证据、交付标记
03 PR 创建/更新 Reviewer Waker 以 head SHA 为审查单元，阻塞性问题写 CHANGES_REQUESTED，通过写 [QW-REVIEW][sha][PASS] PR Review、PASS marker
04 用户合并代码 PR Tester Waker 在迭代分支独立验证，失败则建 Bug 并唤醒 Developer Bug Issue、测试日志
05 Bug 修复并复测 Developer/Reviewer/Tester 修复 → 复审 → 用户合并 → 复测通过 修复 PR、复测结论
06 复测通过 Release Waker 建发布 PR；用户合并后打 tag、建 release、关 Milestone 发布 PR、tag、release

人类决策关口（官方明确）：代码 PR 合并与发布 PR 合并由用户确认。Release Waker 不替用户合并，只准备发布材料。

官方说明该方案可通过替换事件适配层和事实读取工具，迁移到企业自己的 DevOps 平台。

八、能力边界与限制

8.1 硬性限制（官方文档确认或推断）

限制 说明 来源
单实例单账号 同一实例只接受同一个 Qoder 账号，首次授权者成为主账号 官方文档
无分布式部署 无集群/多节点方案，多机只是”多设备访问同一实例” 官方文档未提及
必须保持开机 环境关机/休眠 → 运行中任务中断、定时任务错过触发 官方文档
邀测门槛 需申请；注册需大陆手机号 + 实名认证（身份证） 官方/第三方一致
Windows 支持较新 官方 Quick Start 列 Windows 10+，但第三方教程存在”未开放”的过时说法 需以官方为准

8.2 ⚠️ 信息可信度警告（重要）

调研过程中发现大量 AI 生成的 SEO 垃圾内容，特征是与官方文档严重矛盾、细节具体但无来源。已识别并不予采信的有：

来源 可疑内容 判定理由
php.cn FAQ「提高 QoderWake 数字分身生成速度的硬件配置推荐」 要求 PCIe 5.0 + RTX 4090 + GDDR6X；qoder diagnose --hardware 命令；”视觉编码器 ViT-L/14 / Whisper-medium” 与官方 4GB 内存要求差 3 个数量级；diagnose 命令官方文档不存在；数字员工是编码 agent，官方无任何多模态本地推理描述
php.cn FAQ「QoderWake 支持私有化部署吗」 32 核 CPU / 128GB 内存 / 2TB SSD / KVM+OpenStack；qoder-7b-v2 模型 SFT 微调；./install-harness.sh --mode=cluster；Helm Chart 官方无私有化集群方案、无 SFT 工具、无 install-harness.sh 命令；”qoder-7b-v2” 无任何官方来源
阿里云开发者社区部分文章 docker-compose up -d + git clone github.com/QoderAI/QoderWake-deploy；/api/v1/wakers/create REST API；qoderwake submit --event-type=... 官方安装方式是 install.sh（非 Docker），无公开部署仓库，官方 Quick Start 中无 submit 子命令
塔候教程 “Windows 暂未开放，敬请期待” 与官方 Quick Start 的 Windows 10+ 直接矛盾

取信原则：本文所有部署命令、配置参数、架构描述均以 docs.qoder.com 官方文档与 qoder.com 官方博客为准。第三方的具体命令与技术细节在无法交叉验证时不采信。建议读者遇到任何”QoderWake 支持 X”的说法，先查官方文档。

8.3 未获官方确认的问题

  1. 定价 — 官方仅称邀测阶段、官网申请，未公布价格
  2. 私有化/本地化部署资质 — 官方只有单机部署，无企业私有化集群方案说明
  3. Agent 拓扑是否可自定义 — @Waker 的路由规则可配，但是否支持用户自定义 agent 拓扑（如环形、网状）未见官方说明；目前形态是 Leader + 成员的层级型
  4. 并发上限 — 单实例能同时跑多少个 Waker，官方未给出明确数字（仅给出推荐规格）
  5. 数据出境 — 使用云端能力时的数据流向与合规说明未在公开文档中明确

九、对用户的价值判断

与已有资产的互补关系

用户手上已有：

  • Hermes Kanban — 完整多 agent 协作层（此前已确认）
  • Qoder CLI — 单次会话型 agent 执行器
  • Claude Code / WorkBuddy — 本机 agent

QoderWake 补的是哪一块？ 补的是**”常驻岗位 + 组织化协作 + 事件驱动”**这一层：

能力 Hermes Kanban Qoder CLI QoderWake
任务看板 ✅ ❌ ✅
多 agent 协作 ✅ ❌ ✅（Waker 群组 + SOP）
常驻 7×24 取决于部署 ❌ ✅（设计目标）
事件驱动自动唤醒 ⚠️ ❌ ✅（五种触发）
IM 群聊接入 ❌ ❌ ✅（钉钉/飞书/企微）
岗位身份 + 权限红线 ❌ ❌ ✅（五层构成）
自进化/经验沉淀 ❌ ❌ ✅（五维 + 防腐）
本机可控 ✅ ✅ ✅

最值得关注的两点：

  1. IM 群聊入口——把数字员工以”群成员”身份接入钉钉/飞书，一个 bot 背后路由多个岗位。这是此前”多 bot 同群互读是平台级限制”这一结论的另一条解法：不需要多个 bot 互相看见，只需要一个 bot 做统一入口 + 后端路由。
  2. 群技能 + 协作 SOP——把”谁先想、谁执行、谁验收、什么情况要人确认”写成可复用资产，这是把 agent team 从”临时对话”变成”稳定交付”的关键。

现实约束

  • 必须保持开机：本机部署的实际可用性受限于电费/稳定性；要真 7×24 得走服务器
  • 单账号单实例：团队共用一个实例意味着共用同一个 Qoder 账号
  • 邀测 + 实名：接入门槛不低，需要大陆手机号和实名认证
  • 官方文档以英文为主：中文文档存在但部分章节不完整

建议

短期：先在本机装一个试（4GB 内存门槛很低），跑通”创建 Waker → 派一个只读 dry-run 任务 → 看结果”的最小闭环，验证它对本地工作目录的访问能力是否符合预期。官方 Quick Start 提供了推荐的只读 dry-run 任务作为首个测试，是个稳妥的起点。

中期：若验证有效，再考虑上云桌面（4C8G/100G 标准配置）做常驻，避免本机关机中断。ECS headless 方案虽更省资源，但必须走 SSH 端口转发，不要用直连方式裸暴露 19820。

观望点：定价、私有化方案、以及是否支持自定义 agent 拓扑。这三点目前都不明确。

十、QoderWake 能否接入其他 Agent？（补充调研 2026-09-20）

10.0 结论先行

分三层回答，边界很清晰：

接入形式 官方支持 能否接 Hermes / Qoder CLI
MCP Server（工具级） ✅ 完整支持（stdio / http / sse 三传输 + OAuth） ✅ 可以——任何能暴露 MCP 的服务都能挂到 Waker 上
跨机器 Waker 组队 ✅ v1.0 核心能力 ⚠️ 要看对方是不是 Waker，只支持 QoderWake 的 Waker 实例
Agent 框架级接入（A2A / LangChain / AutoGen） ❌ 官方无任何说明 ❌ 不支持

一句话：QoderWake 可以消费外部能力（MCP），也可以跨机器编排自己家的 Waker，但不能把 Hermes 这种第三方 agent 当成对等队友接进群组。

10.1 官方支持的接入点（MCP：工具级）

官方 CLI 文档专门有 MCP 章节，原文：

MCP（外部工具接入） 每个 Waker 可挂载若干 MCP Server（stdio / http / sse 三种传输）。

三种传输方式：stdio / http / sse

完整命令集：

qoderwake mcp list   --waker-id <id>
qoderwake mcp get    --waker-id <id> --mcp-id <mid>
qoderwake mcp add    --waker-id <id> [options]        # 新增或导入 MCP JSON
qoderwake mcp update --waker-id <id> --mcp-id <mid> [options]
qoderwake mcp toggle --waker-id <id> --mcp-id <mid> --enabled true|false
qoderwake mcp delete --waker-id <id> --mcp-id <mid>
qoderwake mcp auth start      --waker-id <id> --mcp-id <mid>   # 启动 OAuth 授权
qoderwake mcp refresh-tools   --waker-id <id> --mcp-id <mid>   # 刷新工具清单

add / update 关键选项（官方原文表格）：

选项 说明
--json / --json-file 直接导入 MCP JSON
--name / --description 名称 / 描述
--command / --args / --env stdio 传输：命令 / 逗号分隔参数 / JSON 环境变量
--http-url / --transport stdio|http|sse HTTP/SSE 地址与传输类型
--headers / --header KEY=VALUE HTTP/SSE 请求头（--header 可重复）
--oauth-client-metadata-url / --oauth-client-id / --oauth-client-secret OAuth 客户端元数据与凭据
--oauth-token-auth-method / --oauth-scope / --oauth-resource-metadata-url OAuth token 端认证方式 / scope / 受保护资源元数据

GUI 路径（第三方集成文档交叉验证，如 Apify 官方集成文档）：控制台 → 打开 Waker → Edit → Connector → Installed 标签 → Custom 下 Add → 在 Add MCP Server 对话框选 Server Type（如 Streamable HTTP）、填名称与 URL → Add → 重启 QoderWake → 连接器显示 Not connected → 点 Auth 完成浏览器授权 → 再次重启 → 状态变 connected。

注意：GUI 里叫 Connector（连接器），CLI 里叫 mcp，是同一套机制的两种入口。第三个官方文档又提到 Plugin（”本地进程内加载的触发器/事件源插件“）和 Extension（”只读查看本地 qodercli 扩展运行时清单”）——这两个是另外的扩展点，不是 agent 接入。

10.2 跨机器 Waker 组队（这才是”分布式”的真实含义）

这里要修正一个此前表述：本文第六节说”官方无分布式方案”，指的是没有集群/多节点部署架构。但 v1.0 确实有跨机器组队 —— 机制不是集群，而是多设备注册 + 云端编排元数据。

Settings 文档原文（Manage environments and devices）：

Environments & Devices lists local and remote environments, connection state, application version, and the number of Wakers on each environment.

添加设备流程（原文）：

Select Add device and follow the account and device connection process.（点击 Add device，选择操作系统，复制命令，在目标机器上完成安装与登录。）

添加后需验证四项：新设备显示 online；应用版本符合要求；可以把 Waker 分配给该环境；能跑一个只读任务访问目标本地文件。

设备列表显示：local/remote 标签、名称、版本、在线状态、该环境上有多少个 Waker。

关键设置项 —— Allow remote configuration management（允许远程配置管理）：

This is an experimental feature. When enabled, the device synchronizes Waker metadata, Profile or Context, Skills, and connector configuration, and can accept changes from a remote console. Authentication secrets, tokens, and keys remain local.

官方给的启用前提（原文）：确认账号与设备在预期管理范围内；保持本地目录与外部连接器权限受限；确保配置变更可审计；远程变更后重跑一次受限验证。“不需要远程维护时保持关闭。”

解除绑定（Unbind）的注意事项（很实用）：解绑前先检查①该设备上运行的 Waker；②依赖它或其目录的 Autonomous Work；③使用这些 Waker 的 Groups / Projects / @Waker 聊天；④需要迁移或保留的配置与产物。解绑不会迁移 Waker 或文件。

官方宣传口径印证：

“v1.0 推出 Waker 群组核心能力，运行在本机、不同远程机器上的 Waker 都可以加入同一个群组。每个群组成员可以独立指定使用的模型、专属工作目录，不受该 Waker 实际在哪一台物理机器运行的限制。”

“跨机器网络连通需要自行保障，远程节点网络异常会影响成员执行。“

官方自己举的例子：

“产品经理 Waker 汇总群里的讨论写需求文档，开发 Waker 先出 Spec、人确认后再开发和单测，测试 Waker 按需求和用例生成并执行……这三位现在编在同一个 Waker 群组里，开发跑在远程机器上，测试在本机，各用各的模型。“

所以”分布式”的真相是：不是把任务分片到多节点并行，而是把各机器上的 Waker 通过云账号编排成一支队伍，任务仍由 Leader 统一分发、在各自机器的本地工作目录里执行。

10.3 对你的实际答案：Hermes / Qoder 能不能接？

① 接 Qoder CLI —— 天然同源，但不是”接入”

官方明确：

“QoderWake 跑在 Qoder CLI 上，和 Qoder、Qoder IDE、JetBrains 插件共用 Qoder Agent Harness。Qoder CLI 内置的 Coding Agent 支撑整个 Qoder 产品家族……桌面上的编码智能体和群里值班的数字员工，用的是同一套运行时。“

也就是说 QoderWake 底层就是 Qoder CLI —— 这层不存在”接入”，是同源复用。你的 Qoder CLI 是同一个底座，但作为独立进程/实例，它不会自动变成 Waker，两者不能互相编队。

② 接 Hermes —— 三条可行路径，但都不是”对等组队”

路径 可行性 说明
A. 把 Hermes 能力包成 MCP Server ✅ 最现实 把 Hermes 的 Kanban 查询、任务派发等封装成 MCP 工具挂给 Waker。Waker 就能调 Hermes 的能力——但这是 Waker → 工具 的单向调用，Hermes 没有 Waker 身份，进不了群组、不参与路由
B. 走 IM 群聊做可见层 ✅ 可行（你已有此结论） 把 Hermes bot 和 WakerUp（@Waker bot）拉进同一个钉钉/飞书群。但飞书/Telegram 平台级限制 bot 互读，两者互相看不见，仍需”可见层 + 数据层分离”
C. 数据层打通（API/文件/记忆） ✅ 可行 Hermes 与 QoderWake 各自读写共享存储（文件 / 表格 / OpenViking 记忆），cron 或 webhook 轮询同步——这是你此前已确立的方案
D. 把 Hermes agent 塞进 Waker 群组 ❌ 不支持 Waker 群组只收 Waker

③ 一个值得注意的交叉验证

此前调研《Agent互通与群聊方案调研》的核心结论是：

“‘多个 bot 进同一个群、互相看对方说话’在 Telegram 和飞书这两家是平台级不支持的（不是配置问题）。可行路线是’可见层 / 数据层分离’。”

QoderWake 的 @Waker 设计恰好绕开了这个限制 —— 它不是让多个 bot 互相看得见，而是只放一个 bot 进群做统一入口，背后由 QoderWake 后端做路由。这样：

  • 群里始终只有一个可见身份（不触发平台限制）
  • 多个岗位的 Waker 在后端协作（不受 IM 平台约束）
  • 群成员不需要知道背后有几个、谁是谁

这是对”多 agent 群聊”问题的一条非常聪明的解法，而且和我们此前归纳的”可见层/数据层分离”在思路上是一致的——QoderWake 只是把这套分离做进了产品内部，用户不用自己搭。

10.4 关键澄清：两个”群聊”是完全不同的东西

这是最容易混淆、也最容易得出错误结论的地方 —— 必须严格区分：

A. IM 群聊（钉钉/飞书/企微） B. Waker 群组
是什么 人类团队的聊天群 QoderWake 内部的数字员工编队
成员 人 + 一个 @Waker bot（或数字员工账号） 只有 Waker 实例（本机 + 远端混合）
谁能进去 任何 IM 用户；bot 由 QoderWake 接入 只有 Waker，没有”添加外部 agent”的入口
里面的”协作”是什么 人与数字员工的协作 数字员工与数字员工的协作
管理员是谁 IM 平台（钉钉/飞书） QoderWake（云端账号编排）

为什么”拉 Hermes / Qoder / WorkBuddy 进群让它们自己沟通”做不到：

  1. IM 群聊层：你确实可以把 Hermes bot、WorkBuddy 都拉进同一个钉钉/飞书群 —— 但这时它们只是普通的群成员 bot。而且受平台级限制（飞书：机器人收不到机器人消息事件；Telegram：官方 FAQ 明确 bot 看不到其他 bot 的消息），它们互相看不见对方说的话，所谓”自己沟通”不成立。QoderWake 的 @Waker 在这个群里也只是一个 bot，它不会把别家的 bot 识别为”同事”并与之协作。

  2. Waker 群组层：这里是 QoderWake 内部机制，成员必须是 Waker。Hermes / Qoder CLI / WorkBuddy 不是 Waker，插不进去 —— 官方没有任何”添加外部 agent”的机制。

一个容易误读的细节：@Waker 的多群聊机制是”一个 bot 连接多个 Waker“（一个群聊可以配多个 Waker，由 QoderWake 后端路由）—— 这不是“一个群聊连接多个平台/框架的 agent”。官方原文限定得很清楚：

“Connect only one bot or account to a group as the shared entry point.”
“Names such as Project Coordinator, Engineering Executor, and QA Reviewer describe backend responsibilities; they do not become separate bots in the group.”

也就是说，群里始终只有一个机器人身份，背后路由到 QoderWake 自己的多个 Waker。这是”一个入口 + 内部路由”，不是”多方 agent 互联”。

10.5 那想让你自己的 agent 互相协作，实际怎么做？

❌ 错误期待：在 QoderWake 群里拉进 Hermes + Qoder + WorkBuddy，让它们四家自由对话、自己分工。

✅ 可行的三条路（按落地难度排序）：

路线一：把你的 agent 包成 MCP Server，挂给 Waker（最简单，但方向是单向的）

Waker ──调用──> MCP Server（封装你的 Hermes / 自研能力）

Waker 能调用你的能力，但你的 agent 没有 Waker 身份，进不了群组、不参与路由、不能被别的 Waker 当同事。适合”让 Waker 用上某个工具”，不适合”让两边对等协作”。

路线二：IM 群做可见层 + 数据层打通（你此前已确立的方案，仍然有效）

钉钉/飞书群           ← 给人看的"可见层"（Hermes bot、Waker bot 各说各的）
   ↕
共享数据层            ← agent 之间真正的通信通道
  · 共享文件 / 表格
  · OpenViking 记忆（四端已共享）
  · Webhook / 定时轮询

这是绕开 IM 平台级限制的正确姿势。QoderWake 侧可以给它配定时任务或 API 触发去做轮询/写入。

路线三：把协作逻辑放到 QoderWake 内部的 Waker 群组（如果队友都能变成 Waker）

如果某件事本来就适合用 QoderWake 的岗位体系做（如产品经理 → 开发 → 测试），那就直接在 QoderWake 里建对应的 Waker，用 Waker 群组 + 协作 SOP 编排。这条路最顺，但等于把活儿搬到 QoderWake 体系内，而不是把外部 agent 接进来。

选择建议：

  • 想让 Waker 用上你的某个能力 → 路线一
  • 想让 Waker 和 Hermes 各干各的、结果互相可见 → 路线二
  • 想做的这件事恰好符合岗位化分工，且不介意用 QoderWake 的 Waker → 路线三

10.6 接不进来的部分（明确边界）

官方文档中没有以下任何内容：

不支持的接入方式 说明
A2A 协议（Agent-to-Agent） ❌ 全网检索无任何 QoderWake 对 A2A 的说明或支持
Agent 框架级接入 ❌ 无 LangChain / AutoGen / CrewAI / Hermes 等框架的接入说明
第三方 agent 进 Waker 群组 ❌ Waker 群组只接受 Waker 实例，没有”添加外部 agent”的机制
公开 API / SDK ❌ 文档未公开对外 API 规格。CLI 本身是 daemon 的瘦客户端（”绝大多数命令都是把请求转发给本地 daemon 的 HTTP 接口”），但该 HTTP 接口未公开

可选项只剩脚本化集成（非正式 API）：--json / --format json 输出便于脚本解析；login --method token + QODER_PERSONAL_ACCESS_TOKEN 支持 headless 认证；QODERWAKE_ENDPOINT_BASE_URL 可覆盖服务端地址（私有化/VPC）。

⚠️ 再次出现情报污染：检索到 php.cn 一篇《QoderWake 多机位集群配置》，声称 ./install-harness.sh --mode=cluster --peer-list=...、需 PostgreSQL 14+ 作集群 Session 后端、开 8080（gRPC 心跳）/ 9092（事件广播）端口、”任务吞吐线性扩展”。这与 install-harness.sh 此前已判定为伪造的命令完全一致，且与官方”单账号单实例 + 多设备注册”的架构直接矛盾——官方从未提及集群模式、PostgreSQL 依赖或 gRPC 心跳。判定为不可信。

10.7 补充：本文对第六节的修正

第六节说”纯单体 + 单机，官方无分布式方案“，这句话需要精确化：

  • ✅ 部署架构上确实无集群 —— 没有多节点、没有负载分片、没有共享数据库后端
  • ⚠️ 但多设备是官方支持的 —— 通过 Environments & Devices 注册多台机器（跨 Mac / Windows / 云主机），各自的 Waker 可编入同一群组，由云账号统一编排

所以更准确的表述是：QoderWake 是”单机 daemon + 云端账号编排”的主从形态，不是分布式集群。用”分布式 Agent 集群”来描述它（如某些第三方文章所为）是不准确的。

十一、参考资料

官方来源（可信度高）

官方 / 半官方补充

已识别为不可信（仅供对照，建议忽略）

  • php.cn FAQ 系列（硬件配置、私有化部署、多机位集群配置）— 内容与官方文档严重矛盾
  • 塔候教程 — 系统要求部分过时
  • 部分掘金/阿里云社区文章 — 部署命令与官方不符

互为补充：开源侧的同类方案（2026-09-20 新增调研）

本文第六、十节已说明 QoderWake 无法接入第三方 agent 作为对等队友（只有 MCP 单向工具调用 + 自家 Waker 跨机组队）。若目标是”把我的 Hermes / Qoder / WorkBuddy / OpenClaw 拉进同一个群让它们自己聊”，开源侧已有更直接可行的方案，已单独调研成文：

  • → 接入自有 Agent 的群聊与协作平台调研（abbrlink 99070）
    • 其中 阿里 AgentScope 的 AgentTeams（5,643★）README 原文明确列出 Hermes 与 DeepSeek Harness 可作为 Worker 共处同一个 Matrix IM 房间
      • ⚠️ 但经 2026-09-20 源码级复核：其 Manager（主控）只能用 OpenClaw / QwenPaw，Hermes / DSH 是 Worker-only runtime → 该项目已判定”不太符合预期”，详见 99070 第 3.5 节
    • 明略科技的 Octo（1,059★）官方适配器矩阵含 Hermes Agent channel（但实测仓库内未见对应代码，详见该文 4.3）

调研日期：2026-09-20 ｜ 官方文档版本对应 QoderWake 1.0.4（2026-09-14）
第十节为「接入其他 Agent」专项补充调研（2026-09-20）