【免费下载链接】hermes-workspaceNative web workspace for Hermes Agent — chat, terminal, memory, skills, inspector.项目地址https://gitcode.com/gh_mirrors/he/hermes-workspace点击查看免费下载导读本文基于 Hermes Workspace 仓库中的 Swarm2 Autopilot Orchestration Spec 展开讲解 Swarm2 如何从多聊天窗口 UI进化为持久化自动驾驶团队用户只需向 orchestrator 描述一个任务例如四个 Agent 分别处理 PR、研究、构建、评审运行这个任务系统便会自动完成 roster 的创建与更新、角色/技能/任务的分配、把工作路由到常驻 tmux 会话中的 Hermes worker、收集 checkpoint 证据、驱动继续执行、评审产出最终在/swarm2界面呈现整个闭环。读完本文你将掌握 Swarm2 的 roster、runtime、assignment、dispatch 四层契约理解 checkpoint 证明机制与 orchestrator 循环的工作原理并对照仓库源码验证每一层的实际实现。设计目标自动驾驶团队而非美化版多聊窗口原规范的 Goal 一节给出了非常明确的定性Swarm2 should behave like a persistent autopilot team, not a prettier multi-chat UI。用户只需向 orchestrator 下达一句指令Set up four agents: one handles PRs, one does research, one builds features, one reviews. Run this mission.Swarm2 就必须完成以下 8 步闭环创建或更新 swarm roster编队花名册为各 worker 分配角色、技能与 mission把工作路由到正确的常驻 Hermes worker 会话让每个 worker 运行在独立的 profile / tmux 会话中在 worker 完成子任务时收集 checkpoint检查点在仍有剩余工作时自动提示 worker 继续在宣告工作流完成之前先评审产出在/swarm2界面呈现整个循环无需人工看守。支撑这一目标的是 6 条产品原则Product principles它们是整个规范的设计底色Persistent agents, not disposable helpers.每个 worker 都有身份、profile 记忆、运行时状态和活跃会话Roster is source of truth.路由必须读取 swarm.yaml基于 worker 编号的启发式规则只作为兜底Proof beats vibes.worker 必须 checkpoint 自己改动的文件、执行的命令、结果、阻塞项和下一步动作Orchestrator drives the loop.worker 只负责执行分解、排序、监控、重新提示、评审、升级全部由 orchestrator 完成Autopilot is staged.系统按 manual手动→ semi-auto半自动→ full-auto全自动三档渐进开放tmux/Claude native.worker 会话就是swarm-workerIdtmux 会话中的 Hermes profile。当前基础规范发布时已具备的设施规范 Date 为 2026-04-28Status 为 implementation spec, staged rollout并列出当时已经存在的设施这些在仓库中都有对应实现设施说明仓库对应实现swarm.yaml权威 roster 配置swarm.yaml/api/swarm-roster读写 roster 条目src/routes/api/swarm-roster.ts/api/swarm-decompose把 mission 分解为 assignmentsrc/routes/api/swarm-decompose.ts/api/swarm-dispatch向常驻 tmux/Claude 会话发提示失败时回退到一次性 Claudesrc/routes/api/swarm-dispatch.ts/api/swarm-runtime读取 workerruntime.json、tmux 状态、任务、制品、预览src/routes/api/swarm-runtime.ts/api/swarm-chat从 profile 的state.db读取 worker 聊天历史src/routes/api/swarm-chat.ts/api/swarm-tmux-start/stop/scroll控制常驻会话src/routes/api/swarm-tmux-*.ts规范列出的 Swarm skillsswarm-worker-core、swarm-orchestrator、swarm-dev-runtime、swarm-ui-worker、swarm-pr-worker、swarm-bench-worker对应 agents 目录下各 Agent 的 SKILL.md以及 skills 中的workspace-dispatch技能。值得注意的是仓库 swarm.yaml 中的 worker 已经发展为语义化 profileorchestrator、builder、reviewer、researcher、qa、ops-watch、maintainer、strategist、inbox-triage等每个 worker 都带有profile、wrapper、modes、tools、greenlightRequiredFor等字段——这正是规范中Roster is source of truth的具象化。目标架构从用户任务到完成评审的端到端数据流规范给出了完整的架构数据流逐层串联起全部组件User mission ↓ Orchestrator ↓ reads/writes swarm.yaml roster runtime state ↓ Decomposer/router ↓ produces Assignment plan ↓ Dispatcher ↓ per-worker prompt into tmux/Claude Persistent worker sessions ↓ workers checkpoint runtime.json state.db artifacts/previews ↓ Orchestrator loop ↓ continue / reroute / review / complete / escalate从仓库源码看这条链路中的每一步都有真实路由支撑/api/swarm-decompose产生 Assignment plan/api/swarm-dispatch负责 per-worker 投递worker 通过runtime.json与聊天记录落 checkpoint/api/swarm-orchestrator-loop执行 continue / reroute / review 循环mission 的完成与升级则由 src/server/swarm-missions.ts 的状态机负责。Roster 契约swarm.yaml 的字段与校验规范定义的 worker 条目swarm.yaml保持人类可读、可移植。规范给出每个 worker 条目应支持的字段结构workers: - id: swarm5 name: Swarm5 role: Builder specialty: full-stack implementation and UI/system integration model: GPT-5.5 mission: Ship focused product slices in Hermes Workspace with tests. skills: [swarm-ui-worker, swarm-worker-core] capabilities: - code-editing - ui-implementation - build-verification defaultCwd: /Users/aurora/hermes-workspace preferredTaskTypes: [implementation, refactor, ui] maxConcurrentTasks: 1 acceptsBroadcast: true reviewRequired: true必填字段与待新增字段规范把字段分成两档Required fields nowid、name、role、specialty、model、mission、skillsNext fields to addcapabilities、defaultCwd、preferredTaskTypes、maxConcurrentTasks、acceptsBroadcast、reviewRequired源码中的 Schema 校验与兜底从源码结构看id的合法形式在 src/server/swarm-roster.ts 中被正则WORKER_ID_PATTERN /^(swarm\d|[a-z][a-z0-9]*(?:-[a-z0-9])*)$/i约束即要么形如swarm13要么是语义化 profile id如builder、ops-watch。SwarmRosterWorkerSchema是一个完整的 zod schema除规范字段外还支持profile、modes、tools、plugins、pluginToolsets、mcpServers、wrapper、greenlightRequiredFor等扩展字段并为maxConcurrentTasks正整数默认 1、acceptsBroadcast默认 true、reviewRequired默认 false提供了默认值。两个重要实现细节值得注意兜底 rosterfallback当swarm.yaml不存在或解析失败时readSwarmRoster会退回到fallbackRoster——它根据 worker id 中的数字推断角色例如 1/12 → PR/Issues、4 → Research、5/10 → Builder、6/11 → Reviewer、8 → Ops。这正是规范所说Worker number heuristics are fallback only的代码落地启发式推断永远不是路由的主要依据。写入路径writeSwarmRoster/upsertSwarmRosterWorker通过 zod 校验后以 YAML 形式回写swarm.yaml新增条目按 id 数字排序保证文件保持稳定、可读。仓库真实的 swarm.yaml 已经完整采用了规范规划的字段体系每个 worker 都声明了capabilities、preferredTaskTypes、maxConcurrentTasks、acceptsBroadcast并且更进一步补充了greenlightRequiredFor如 builder 的merge/push/destructive/external-write与wrapper如builder:task、reviewer:gate将人类绿灯控制纳入编队契约。Runtime 契约runtime.json 的运行时状态模型每个 worker profile 可能暴露~/.hermes/profiles/workerId/runtime.json。orchestrator 与 worker 应保持以下字段实时更新workerId、rolestateidle | executing | thinking | writing | waiting | blocked | syncing | reviewing | offlinephase、currentTask、activeTool、cwdlastCheckIn、lastSummary、lastResult、nextAction、blockedReasoncheckpointStatusnone | in_progress | done | blocked | handoff | needs_inputneedsHuman、lastDispatchAt、lastDispatchMode、lastDispatchResulttasks[]、artifacts[]、previews[]这些枚举值在源码中有严格定义src/server/swarm-foundation.ts 的SwarmWorkerStateSchema与SwarmCheckpointStatusSchema分别用 zod 枚举锁定了state和checkpointStatus的全部合法取值与规范逐一对应。/api/swarm-runtime读取并聚合runtime.json返回每个 worker 的displayName、humanLabel、state、phase、checkpointStatus、lastCheckIn、currentTask、tmuxSession、tmuxAttachable等字段供/swarm2界面渲染。runtime.json的写入采用读-改-写补丁模式writeRuntimePatch先读现有 JSON、合并 patch 后原子写回并在/api/swarm-checkpoint中使用writeJsonAtomic临时文件 renameSync保证并发写安全——这正是规范 Stage 2 所规划的结构化 checkpoint 写入接口的落地实现。Assignment 契约/api/swarm-decompose 的分解输出规范的响应结构/api/swarm-decompose应返回如下形状的 assignments{ assignments: [ { workerId: swarm4, task: Research the options and produce a concise recommendation with sources., rationale: Research lane owns technical synthesis., expectedOutput: Recommendation with tradeoffs and next action., dependsOn: [], reviewRequired: false } ], unassigned: [] }Stage 1 仅要求workerId、task、rationale三个字段。源码实现LLM 分解 确定性兜底从 src/routes/api/swarm-decompose.ts 的实现看分解过程分两条路径模型路径callOrchestrator把 roster 中每个 worker 的role、model、specialty、mission、skills、capabilities拼接为提示词通过 gateway 的POST /v1/chat/completions让编排模型返回严格 JSON。系统提示词明确要求只输出合法 minified JSON、只使用 roster 中真实存在的 worker id、不编造 id、按任务类型路由到对应 lane实现→builder/UI/backend研究→research评审/质量门→reviewerPR/issue→PR laneops/runtime→ops/backend。返回内容经过容错 JSON 提取截取首个{到末个}与逐字段校验非法 id 会被过滤。启发式兜底heuristicAssignments当模型调用失败或未产生可用匹配时scoreWorker用关键词正则给每个 worker 打分如research|investigate|options|tradeoff|source|synth→ research lanebuild|implement|code|patch|ui|frontend|backend|api|fix→ builder lanereview|test|verify|quality|regression|gate→ reviewer lane取最高分 worker 生成Handle your lane任务并在响应中标注fallback: true与 warning。这再次印证了Roster 是唯一真相、启发式仅作兜底的原则。另外该路由的鉴权与授权逻辑有对应测试 src/routes/api/-swarm-decompose.test.ts验证其使用运行时 bearer token 辅助函数调用 gateway chat completions。Dispatch 契约/api/swarm-dispatch 的两种投递形态兼容旧广播形态{ workerIds: [swarm1], prompt: ... }新增 assignment 形态{ assignments: [ { workerId: swarm4, task: ..., rationale: ... }, { workerId: swarm5, task: ..., rationale: ... } ] }规范要求assignment dispatch 必须只给每个 worker 发送它自己的任务外加精简的编排上下文send each worker only its own task, plus compact orchestration context。源码实现要点src/routes/api/swarm-dispatch.ts 完整实现了这一契约并提供了大量工程细节两种输入归一化dispatchSwarmAssignments先尝试解析assignments[]若为空则回退到workerIds[] prompt的广播形态把每个 worker 的任务统一为同一 promptrationale 标注为Legacy broadcast dispatch.。边界校验单次 dispatch 最多 12 个 worker任务长度不超过MAX_PROMPT_CHARS 32_000timeoutSeconds被钳制在 10600 秒默认 240 秒checkpointPollSeconds被钳制在 5300 秒默认 90 秒。mission 联动每次 dispatch 都会调用createOrUpdateMission创建或更新 mission任务标题默认取单任务前 120 字符或n assigned tasks并为每个 assignment 绑定assignmentId随后调用markMissionAssignmentDispatched、追加 swarm memory 事件。投递双通道优先通过sendPromptToLiveSession投递到常驻 tmux 会话delivery: tmux若 tmux 不可用或会话无法建立则回退到一次性hermes chat -q命令delivery: oneshot。tmux 投递的可靠性细节ensureLiveTmuxSession会自动创建swarm-workerId会话用load-bufferpaste-buffer而不是逐行send-keys -l投递多行提示投递前先发送C-u清空可能残留的半截输入Enter 之后 2 秒再补一个确认 Enter避免 prompt_toolkit 尚未就绪导致任务悬在输入框。启动失败时会捕获 pane 输出、脱敏 tokensk-...、gh[pousr]_...后写入logs/swarm-dispatch-startup.log。checkpoint 轮询与新鲜度判定waitForFreshCheckpoint在投递后按轮询间隔默认 90 秒同时检查两个证据源runtime.json的 checkpoint 快照以及 worker 聊天记录中的最新结构化 checkpoint。新鲜度判定由runtimeSnapshotIsFresh实现——要求快照与投递前基线相比有变化且lastOutputAt或lastCheckIn晚于投递时刻。这套逻辑在 src/routes/api/-swarm-dispatch.test.ts 中有对应测试覆盖验证了 runtime 生命周期字段到结构化 checkpoint 的映射、阻塞原因生成以及新鲜度判定规则。Worker Prompt 信封每个任务的六层包装规范要求每次派发的任务都必须包裹以下内容orchestrator context编排上下文worker identity来自swarm.yaml的 worker 身份skill stack names技能栈名current task当前任务checkpoint/reporting contractcheckpoint/汇报契约continuation instruction继续执行指令。规范给出的示例信封## Swarm Orchestrator Dispatch Worker: swarm5 — Builder Mission: Ship focused product slices in Hermes Workspace with tests. Skills: swarm-ui-worker, swarm-worker-core ## Assigned Task ... ## Required Checkpoint Format Reply/check in with: STATE: DONE | BLOCKED | NEEDS_INPUT | HANDOFF | IN_PROGRESS FILES_CHANGED: ... COMMANDS_RUN: ... RESULT: ... BLOCKER: ... NEXT_ACTION: ... If this is one task in a larger workflow, stop after the checkpoint and wait for orchestrator continuation.源码中的 buildWorkerPrompt从 src/routes/api/swarm-dispatch.ts 的buildWorkerPrompt看实际生成的信封比规范示例更完整依次包含## Swarm Orchestrator Dispatch头部Worker: name — role、Machine ID、Specialty、Mission、Skills、Capabilities、Routing rationaleWorker Startup Memory Snapshot通过buildSwarmStartupSnapshot生成启动记忆快照作为权威起始上下文若 worker 有文件系统工具还会提示其读取~/.hermes/profiles/workerId/MEMORY.md、SOUL.md、USER.md与memory/IDENTITY.md## Assigned Task当前任务## Operating Rules包含在常驻会话中工作并保留 profile 上下文不要甩锅给沙箱精确报告失败的命令与缺失的 token/工具/env被阻塞时说明缺什么以及最小解锁动作若属更大工作流的一部分checkpoint 后停下等待 orchestrator 继续上下文压力高时先写结构化 handoff 再 /new等操作性规则## Required Checkpoint Format完整的六字段 checkpoint 模板。Checkpoint 证明机制从聊天文本到结构化状态规范的核心主张是 Proof beats vibes。仓库 src/server/swarm-checkpoints.ts 给出了解析层的完整实现parseSwarmCheckpoint接受自由文本要求必须出现STATE:标记逐行识别STATE/FILES_CHANGED/COMMANDS_RUN/RESULT/BLOCKER/NEXT_ACTION六个标签兼容**STATE:**这类加粗 Markdown 格式随后把STATE映射为三层状态stateLabelDONE | BLOCKED | NEEDS_INPUT | HANDOFF | IN_PROGRESSruntimeStateidle | blocked | waiting | executingcheckpointStatusdone | blocked | needs_input | handoff | in_progressnewestCheckpointFromMessages逆序遍历聊天消息仅 assistant 消息返回最新可解析的 checkpointcheckpointFromRuntimeSnapshot则把runtime.json的生命周期字段state、checkpointStatus、lastSummary、lastResult、nextAction、blockedReason、checkpointRaw反向组合成同一结构的 checkpoint实现聊天文本与runtime 文件两个证据源的统一。worker 完成 checkpoint 后markCheckpointResult会把runtime.json更新为对应状态BLOCKED/NEEDS_INPUT时写入blockedReason并置needsHuman: true终态时清空currentTask同时recordMissionCheckpoint更新 mission 与 assignment 状态、追加事件流。也就是说一个任务是否完成靠的是 worker 回传的、带文件的证明性状态而不是看起来干完了。Orchestrator 循环监控、续派、评审与升级规范定义的循环步骤orchestrator loop 基于运行时状态运行从/api/swarm-runtime收集 worker 状态从/api/swarm-chat检查近期聊天若lastCheckIn过旧则将 worker 标记为 stale检测阻塞检测完成 checkpoint若仍有剩余工作则分配下一个任务把评审任务路由到 reviewer lane仅在需要人工输入时升级escalate。循环状态机规范定义了 8 个 loop statesplanning正在构建 mission 分解、dispatching初始 assignment 正在发出、executingworker 活跃、checkpointingworker 正在回传证明、reviewingreviewer/orchestrator 校验产出、continuing发送下一个任务、blocked需要人工或环境干预、complete最终交接就绪。源码实现/api/swarm-orchestrator-loopsrc/routes/api/swarm-orchestrator-loop.ts 完整实现了该循环可逐条对照规范步骤状态收集与去重对每个 worker 读取聊天记录并newestCheckpointFromMessages若 checkpoint 的 raw 与orchestratorProcessedRaw相同则返回already_processed保证同一条证明不会被重复处理。checkpoint 落地新 checkpoint 写入runtime.jsonruntimePatchFromCheckpoint映射全部字段并recordCheckpoint同步 mission 状态、追加 swarm memory 事件、发布publishSwarmCheckpointNotification。stale 检测以lastOutputAt/lastCheckIn/lastDispatchAt中最新的时间戳与staleMinutes默认 10 分钟可配置 1240比较超时且无可解析 checkpoint 的 worker 会被打上state: waiting、checkpointStatus: needs_input并在下一次循环收到立即只回传 checkpoint 格式的强制重提示buildStaleAssignments。自动继续auto-continue对状态为DONE且带nextAction的 workerbuildNextActionAssignments根据 next action 的关键词路由到 builder/backend 或 research 或 reviewer lane实现类任务builder|implement|patch|code|ship|execute|run|real execution只有在allowExecution打开时才会被自动续派。评审门reviewer lanebuildReviewAssignment汇总所有DONE的 worker checkpoint结果、改动文件、命令、下一步生成一条只评审不改文件、决定工作流是否继续、指出回归风险的 review 任务路由到reviewWorkerId指定者或按review|qa|critic正则从 roster 中选出 reviewer若已存在 reviewer 的 DONE checkpoint 则不再重复评审。人工升级escalatebuildMainSessionPrompt把需要关注的 workerNEEDS_INPUT/BLOCKED汇总为主编排会话的提示文本通过publishSwarmActionPrompt推给主会话让主 orchestrator 先尝试作答否则转给用户规范中称为 Eric。manual/auto 模式开关循环读取 src/server/swarm-mode.ts 中的.runtime/swarm-mode.json当模式为manual时applySwarmModeToLoopFlags强制关闭autoContinue与allowExecution——这正是规范Autopilot is staged中 manual → semi-auto → full-auto 三档的运行时表达。dryRun: true可安全预览循环将要采取的动作而不写任何文件。自动驾驶分阶段落地Stage 14规范把自动驾驶能力切成四个阶段仓库源码的现状可以逐阶段对照Stage 1landing now规范发布时正在落地Router 使用真实 roster 元数据而非硬编码的 worker 编号角色 —— 由 src/server/swarm-roster.ts 的readSwarmRosterfallbackRoster承担Decomposer 接收完整 roster 上下文 ——/api/swarm-decompose将 role/specialty/mission/skills/capabilities 全部注入提示词Dispatch 接受 per-worker assignments ——parseAssignments已支持workerId/task/rationale/dependsOn/reviewRequired/directDispatch 写入初始 runtime checkpoint ——markDispatchStarted在派发瞬间写入state: executing、checkpointStatus: in_progress、lastDispatchAt等字段Worker 提示包含 skill/checkpoint 契约 ——buildWorkerPrompt完整实现。Stage 2新增/api/swarm-checkpoint安全写入结构化 checkpoint —— 已实现于 src/routes/api/swarm-checkpoint.ts用 zod 校验state/checkpointStatus/currentTask等字段后原子写回runtime.json并联动 mission 与通知解析聊天中的 checkpoint 消息并更新 runtime 状态 ——newestCheckpointFromMessages已实现增加 assignment id 与 parent mission id —— src/server/swarm-missions.ts 中 mission 由shortId(mission)生成、assignment 由shortId(assign)生成currentMissionId/currentAssignmentId写入runtime.json。Stage 3新增/api/swarm-orchestrator-loop—— 已实现见上文循环详解Loop 监控 runtime/chat 并自动继续 worker ——autoContinuebuildNextActionAssignments增加 stale/drift 检测 ——staleMinutes阈值与orchestratorProcessedRaw去重增加 reviewer lane 路由 ——chooseReviewer/buildReviewAssignment。Stage 4用户可见的 mission 历史 —— src/server/swarm-missions.ts 的listSwarmMissions提供按更新时间排序的 mission 列表含完整事件流已保存的工作流/模板多用户引导fresh install 无缝创建 agents 与 roles。Stage 1 冒烟测试验收标准与预期路由规范给出了一个可直接执行的冒烟测试任务Test Swarm2 autopilot. Research one improvement, implement one tiny safe artifact, review the result.预期路由Research worker 接收 research/checkpoint 任务Builder 接收 implementation/checkpoint 任务Reviewer 接收 review/checkpoint 任务。通过标准Pass criteria/api/swarm-decompose返回使用 roster 角色的 assignment JSON/api/swarm-dispatch对在线 worker 返回delivery: tmux每个目标 worker 的runtime.json显示state: executing、当前任务、checkpointStatus: in_progressworker 卡片聊天最终出现已派发的消息至少一个 worker 回传带证明的状态proof-bearing state。对照仓库这套验收标准的每一步都有代码抓手decompose的 JSON 形状由 src/routes/api/swarm-decompose.ts 保证delivery: tmux由sendPromptToLiveSession返回runtime.json的初始写入由markDispatchStarted完成聊天投递由 tmux paste 流程保证proof-bearing checkpoint 由 src/server/swarm-checkpoints.ts 解析并回写。开发者可以直接调用/api/swarm-decompose与/api/swarm-dispatch或在/swarm2界面手动走完这一流程来验证 Stage 1。环境与运行前提规范的 worker 条目中defaultCwd指向仓库根目录这与 src/server/swarm-environment.ts 的约束一致SWARM_CANONICAL_REPO resolve(process.cwd())Swarm 的代码、git、构建与测试只能在 canonical repo 中进行。默认命令也由此派生构建cd canonicalRepo npm run build测试cd canonicalRepo npm test -- src/screens/swarm2开发cd canonicalRepo PORT3002 npm run dev运行前提还包括worker profiles 位于~/.hermes/profiles/workerIdwrappers 位于~/.local/bin/wrappertmux 会话命名为swarm-workerIdswarm.yaml之外的运行时状态mission 存储、swarm mode落在canonicalRepo/.runtime/下swarm-missions.json、swarm-mode.json。tmux 二进制可通过HERMES_TMUX_BIN/CLAUDE_TMUX_BIN环境变量覆盖支持 Docker、NixOS 等非标准安装Hermes CLI 可通过HERMES_CLI_BIN覆盖候选列表含~/.hermes/hermes-agent/venv/bin/hermes、~/.local/bin/hermes、PATH 中的hermes。未决问题与推荐实施顺序规范列出的开放问题仅存在于 roster 的新 agent 应自动创建 Hermes profile 与 wrapper还是 Add Swarm 在首次启动前保持纯配置orchestrator loop 应运行在浏览器会话、服务器定时任务、cron 还是常驻 Claude orchestrator workerauto-continue 在询问用户之前应多激进评审应仅对改代码的任务强制还是对所有工作流强制从源码结构可以推断仓库目前的取舍是loop 以显式 POST/api/swarm-orchestrator-loop触发可被外部定时器调用评审门对含code|patch(es|ed|ing)?|implement(ation|ed|ing)?|pr|benchmarks?意图的任务自动推断reviewRequired见 src/server/swarm-missions.ts 的inferReviewRequiredauto-continue 的激进程度由swarm-mode与请求参数联合控制。推荐的下一步实施顺序Stage 1 routing/dispatch/checkpoint patch通过直接 API 与 UI 做冒烟测试新增/api/swarm-checkpoint仓库中已存在增加 mission id 与 assignment id仓库中已存在增加 orchestrator loop endpoint仓库中已存在为用户创建的 swarm 增加引导bootstrapping。总结Swarm2 Autopilot Orchestration Spec 定义了一整套持久化自动驾驶编队的工程契约swarm.yaml是路由的唯一真相runtime.json是 worker 的运行时证明checkpoint 是证据胜过感觉的载体orchestrator loop 是驱动整个闭环的大脑manual → semi-auto → full-auto 的分阶段策略保证了系统在逐步放开自主权的同时保留人类绿灯控制。仓库源码已经按规范落地了绝大部分 Stage 13 的能力——分解、按 worker 派发、checkpoint 解析与轮询、mission 状态机、循环续派与评审门——开发者和研究者可以直接对照 swarm.yaml、src/routes/api/swarm-decompose.ts、src/routes/api/swarm-dispatch.ts、src/routes/api/swarm-orchestrator-loop.ts 与配套测试逐层验证这套系统的行为。赞分享【免费下载链接】hermes-workspaceNative web workspace for Hermes Agent — chat, terminal, memory, skills, inspector.项目地址https://gitcode.com/gh_mirrors/he/hermes-workspace点击查看免费下载相关推荐Swarm2 Agent IDE 规格与实践在 Hermes Workspace 中把克隆 Agent 变成持久化协作团队的控制平面Swarm2 Agent IDE 规格与实践在 Hermes Workspace 中把克隆 Agent 变成持久化协作团队的控制平面 本文基于 docs/swInsightFace 人脸检测识别快速上手指南从装包到跑通 1:N 检索InsightFace 人脸检测识别快速上手指南从装包到跑通 1:N 检索 InsightFace 是目前被引用最多的开源 2D/3D 人脸分析工具箱检测、人工智能计算机视觉深度学习OmX Team Skill 实战指南基于 tmux 的持久化多 Agent 团队编排OmX Team Skill 实战指南基于 tmux 的持久化多 Agent 团队编排 本文以 OmXOh My codeX仓库中的 Team Skill人工智能AI AgentAgent 编排Agent 工作流CLI开发工具AI 技能上一篇GOAD 扩展开发指南extension.json、多 Provider 虚拟机定义与 Ansible 配置的完整开发流程下一篇FlycoDialog 开源项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考