竞品对比与迁移指南
Myrm 被设计为完整的 AI Agent 工作空间。与仅面向终端的编程 Agent 不同,Myrm 提供 GUI 优先的体验、持久化沙箱、跨会话记忆与企业级安全——同时保留完整编程能力。迁移信心——数据与节奏在你手里:可选 SaaS、自托管或桌面三模;Hermes 技能可 GUI 拖拽 ZIP 导入;先对照下方能力表与分竞品章节再决定。对于插件中心化用户(如 Grok Build),Myrm 支持一键安装完整 Agent 能力包(模型 + 技能 + MCP + 子代理 + 安全策略),无需手工拼装多插件。文档与产品均支持 6 种语言(zh/en/ja/ko/de/zh-TW);首次访问自动识别浏览器语言(RFC 7231 Accept-Language 协商),三种部署模式(WebUI / 云托管 / Tauri 桌面端)均适用。
preflight/runtime_fallback 来源解释(含移动端非 hover 文案),并在云模式提供严格 fail-closed 入库(共享 envelope_id 幂等 + 共享去重后端不可用时禁止静默本地回退 + dedup_reject 原因指标)。最近一次定向回归(2026-07-19):server 28 passed、control-plane 55 passed、frontend 14 passed。
在单轮能力控制上,Myrm 已提供 一次性 Skill/MCP 覆写 Chips,并具备完整可观测闭环(提交/生效/noop/排队/busy/终态 + 失败原因)。2026-07-29 定向验证:frontend 29/29、server 10/10 全通过;聚焦覆盖率达到 frontend 核心文件 lines 62.47%,server 遥测模块 total 72%。迁移团队可直接基于证据做成本与稳定性调优,而非凭经验猜测。
最新验证快照(2026-07-30 · Chat Wiki Knowledge Quick Lane · Roadmap #30)
- Chat Wiki 知识快路径(vs Hermes llm-wiki / OpenClaw memory-wiki / deer-flow / LobsterAI / CoPaw / jiuwenclaw):intent + knowledge_query_service + wiki_knowledge_lane + API query = 16 pytest, 0 failures(约 6s、server lane、Chrome MCP E2E 待签收)。
- 已验证:
should_use_wiki_knowledge_lane闸门(Agent 模式 +enable_wiki+ vault ready + 问句 intent);execute_wiki_knowledge_querySSOT(SettingsPOST /wiki/query与 Lane 共用);wiki_knowledge_lane输出 STATUS → SOURCES → MESSAGE →execution_lane=wiki_knowledge;查询失败显式 failed STATUS(不 bare raise、不 silent fallback GeneralAgent);FE ProgressStepswiki_knowledge_lane/_clear+message_endlane 字段。 - 对用户可见的竞品优势:Settings 已可零 LLM 查 Wiki,Chat 短知识问句不再多轮 GeneralAgent tool call — GUI Chat 零 LLM wiki lane 独家;Hermes 为 SKILL/CLI 多步;OpenClaw 为 memory-wiki 工具链;六家均无 Settings+Chat 检索 parity + ProgressSteps + SOURCES Drawer 闭环。
- 诚实边界:无 lite 合成;闸门外仍走 GeneralAgent;Chrome MCP Chat E2E + FE vitest
completionEvents.wikiKnowledgeLane本地 bun 待签收。 - Material SSOT:
temp-docs/materials/WIKI_KNOWLEDGE_BASE_ADVANTAGE.md·USER_EXPERIENCE_ADVANTAGE.md§22 #30 小节 ·services/wiki/_ARCH.md·lanes/_ARCH.md
最新验证快照(2026-07-30 · ChatExecutionPrewarm Turn1 · Roadmap #29)
- Turn1 冷启动预热(vs Hermes CLI 并行 init / OpenClaw TUI 发送前 prewarm): coordinator 4/4 + prewarm API 3/3 + CDP log helper 2/2 = 9 pytest,0 失败(~10s,server lane)。Chrome E2E 另断言
Turn prewarm requested日志 ≥1,再接既有 2msg1build execution-cache 证明(test_execution_cache_chrome_e2e.py)。 - 已验证: EmptyChat 挂载 + MessageInput focus + AgentConfigPanel 切换 →
POST /agents/chats/{id}/prewarm;发送路径join_for_turn(0.3s)+coalesced_acquire;SSE ProgressStepsturn_prewarm_agent/turn_prewarm_memory+brief_pending时无条件turn_prewarm_memory_clear;FE 模块级 inflight 去重;autoOnMount 不在 unmount 时 DELETE(首条发送 EmptyChat→ChatWindow 安全)。 - 对用户可见的竞品优势: Hermes v0.19 并行 init 仅 CLI;OpenClaw prewarm 仅 TUI 首条发送前 — 均无 GUI EmptyChat/focus/换 Agent 触发 + ProgressSteps 等待 UX。Turn2+ 仍走 per-chat
execution_cache_reuse(Chrome E2E 2msg1build)。 - 诚实边界: join 窗口 0.3s — 极慢 memory 仍可能 Turn1 miss brief(与旧 250ms 串行同类);prewarm 失败无 GUI toast(send 冷路径 fallback)。前端 vitest 4 cases 未在 agent 环境跑(无 bun/node)— 本地签收:
bun run test src/hooks/chat/__tests__/useChatTurnPrewarm.test.ts。 - Material SSOT:
temp-docs/materials/COMPETITIVE_HERMES_ADVANTAGE.md§31 ·USER_EXPERIENCE_ADVANTAGE.md§22 Turn1 小节 ·prewarm/_ARCH.md
最新验证快照(2026-07-30 · Hermes 八篇系列 + OpenClaw 对比总结 · Article 13)
- 系列结论(庄码收官文 · 无评论):OpenClaw = 稳定工具 · Hermes = 成长搭档。Myrm = GUI-first 成长搭档 + OpenClaw 级 Channel/Skill/Tool 骨架,三端(Local/Tauri/云 CP)同构。
- 迁移用户实得(诚实):
- Myrm ≫:GUI 迁移向导(5 源 dry-run/confirm/rollback)vs
hermes claw migrateCLI;Onboarding 4 步 vs 纯终端;8 类记忆+Wiki vs Hermes 2200 字 MEMORY.md;HITL 写入审批 vs Hermes 直写。 - Myrm ≥:Cron+Nudge 类能力(Cron GUI+push+situation_report+HeartbeatEvaluator);FTS5 跨会话(
conversation_search);云 sleep/wake(CPsleep_sandbox);子代理(SubagentDashboard);国产模型 Provider GUI。 - 进行中(不隐瞒):Vision Fallback WebUI 已≥ · 飞书/渠道/cron 未注入 vision_fallback → roadmap
hermes_auxiliary_vision_*2 项 P1;/learn工作流 →hermes_learn_skill_*2 项 P0;Hermes sessions 导入 → memory #3 扩展。
- Myrm ≫:GUI 迁移向导(5 源 dry-run/confirm/rollback)vs
- WORTH:NO(系列提及但不立项):Python RPC 子代理模式(sandbox code-as-action ≥);Nous Portal 五合一 API;RL 批量轨迹研究管线(非 GUI 主用户)。
- 材料 SSOT:
temp-docs/materials/COMPETITIVE_HERMES_ADVANTAGE.md§30 ·temp-docs/roadmap/hermes_openclaw_series_summary_cross_reference_roadmap.md
最新验证快照(2026-07-30 · Wiki Evidence Closure v2 #4+#5)
- 证据引用 GUI(vs OpenClaw / Hermes / deer-flow / LobsterAI / CoPaw / jiuwenclaw):
test_query_closure_v24/4 +test_best_first5/5 +test_source_citations6/6 +test_wiki_recall_benchmark_gate1/1 = 16 tests, 0 failures(约 6s、2 批、harness-only、无 Chrome MCP — 本环境无 Node 未跑 vitest)。 - 已验证:Chat/Settings citation Drawer 展示 claim 状态 + 编译置信度 + raw 摘录;fresh supported claim 检索优先于 stale contested;Settings Query 检索路径 trace(index/seeds/concepts);citation score 非硬编码 1.0。
- 对比竞品:OpenClaw 有 CLI
raw-claim/source-evidence+ claim confidence rerank(query.test.ts:602)无 GUI Drawer;Hermes llm-wiki skill / deer-flow / LobsterAI / CoPaw / jiuwenclaw 无 claim-level citation GUI;6 家均无 Settings 检索 trace 卡片。 - 诚实边界:无 route-question 模式(OpenClaw 有 · frontmatter schema 待办);Chat 无 retrieval trace(Settings 调试面);无 Trust card/SSE lineage。
最新验证快照(2026-07-30 · Wiki ↔ Memory 边界 #27)
- Wiki 与 Memory 写入边界(vs Hermes / OpenClaw / Mem0 概念):
test_wiki_memory_boundary7/7 + save 护栏 3/3 + extract prompt 2/2 + agent 接线 1/1 = 25 tests, 0 failures(约 5s、3 批、harness-only、无 Chrome MCP — 后端护栏无浏览器交互路径)。 - 已验证:
memory_save_tool在 wiki 开启时硬拒 document-like knowledge/event(>800 字或 ≥3 markdown 标题 →wiki_ingest_tool);persist_extracted_memories硬滤 auto-extract semantic/episodic;提取 promptwiki_boundary_enabled;Settings 中英文分工文案。 - 对比竞品:Hermes 扁平 MEMORY.md 2200 字符上限 — 无编译 Wiki + 无双路径代码 enforcement;OpenClaw MEMORY.md 文件 — 无 vector auto-extract 滤;Mem0 Wiki≠MemCon 概念 — Myrm 增加写路径 enforcement + compile +
corpus=all。 - 诚实边界:拆条绕过未专门防;无独立 Boundary Card(终极扣问 WORTH:NO)。
最新验证快照(2026-07-30)
- Wiki 外部来源 GUI 同步 + Google Drive(vs OpenClaw / Hermes / deer-flow / LobsterAI / CoPaw / jiuwenclaw / OpenWiki):gdrive 3/3 + gmail/rss/status/oauth 12/12 + state/config/defaults/blueprint/hygiene/second_brain 15/15 + gmail_html 2/2 = 32 tests, 0 failures(约 45s、3 批、server lane、无 Chrome MCP)。
- 已验证:Settings 外部来源面板(Gmail 标签 + Google Drive 文件夹 + RSS + 集成镜像 → wiki
raw/·publish_raw);零 LLM pull;OAuth 自动开启 GmailReadLater;缺 Drive read scope 时google_drive_authorized重连提示;持久化同步状态 +syncIssue错误回显;Cron 蓝图read_it_laterrouter(__wiki_source_sync__· 空 tools)。 - 相对竞品的用户收益:GUI 完整 摄入→编译→检索 闭环(收藏邮件 + Drive 文档 + RSS)——OpenClaw 为 Gmail Pub/Sub 聊天 hook(非 wiki vault 管道);Hermes/OpenClaw google-workspace CLI 可读 Drive 但非编译 wiki raw 管道 + Settings GUI + cron;deer-flow / LobsterAI / CoPaw / jiuwenclaw 参考仓 无对等能力;OpenWiki Gmail 为 env 配置且无 Drive connector。
- 诚实边界:Gmail 标签与 Drive 文件夹 ID 手填——不做标签下拉 / Drive Picker(终极扣问 WORTH:NO);无 OneDrive(broken stub 已删);Integrations API
drive_read_enabled对称字段 WORTH:NO(OAuth scope 已暴露)。本轮未跑 Chrome MCP E2E;行为由 mock Gmail/Drive API 单测证明。
最新验证快照(2026-07-27)
- Office 文档管线(vs WPS 灵犀 / OpenClaw / Hermes / DeerFlow / LobsterAI / CoPaw / jiuwenclaw):file_parsers 213/213 + document_reader 26/26 + docx 读链 E2E 16/16 + 交付 Bundle 23/23 = 278 tests, 0 failures(2026-07-28 分批实测)。已验证:LegacyFormatParser OLE2 + soffice 自动转换、docx.py cell_map 结构元数据、Goal 全链路交付 ZIP 打包。写保真(in-place):Harness
OfficeBashAuditbash 后 OPC/公式 diff + baseline-missing honest warn + 损坏 Office 包 warn + 可选 LibreOffice recalc 错误扫描 + layout QA(18 pytest, 2026-07-28)——OSS 六竞品无同类 harness 级 post-bash audit。灵犀在政府固定模板填表上仍领先(闭源内核);Myrm 在 Legacy 格式、结构化解析、交付 Bundle、三端独立部署上已实测领先。 - 前端 Agent 状态管理架构(vs CopilotKit AG-UI useAgent/useAgentEvents Hooks):multiplexChunkBridge 16/16 + SSE handlers (gap+clarification+completion) 24/24 + messageStreamHandler core 27/27 + Zustand store (snapshot+navigation+subagent+model config) 30/30 + integration & event dispatch 39/39 + UI data model merge 6/6 + state recovery (budget+memory+reasoning) 40/40 + plan lifecycle 13/13 = 195 tests, 0 failures。修复预存在 bug 1 枚(日语 locale「必須」更新后测试断言未同步)。
- 为何 CopilotKit SDK Hooks 在此过时:CopilotKit 的
useAgent()/useAgentEvents()是面向 SDK 嵌入场景(将 Agent 嵌入第三方 App)的简化封装;Myrm 作为独立 AI 产品,前端团队直接使用 Zustand store + 13 专职 Handler 模块 +streamConsumer(含断线重连 / Last-Event-ID 续流 / chunk 缓冲 / capability_gap 延迟重发 / missed HITL 恢复 / 历史状态水合)——66 种 SSE 事件类型对比 CopilotKit ~10 种抽象事件,粒度 6.6x,精确 re-render 无额外 Hook 开销。 - 用户迁移收益:基于 CopilotKit AG-UI 构建的 Agent 前端迁移至 Myrm 后,无需编写任何 SDK hook、EventSource 管理、重连逻辑——开箱即用的实时流 + 断线自愈 + UI 状态机。
- 声明式 Agent UI 框架(vs CopilotKit Generative UI useRenderTool/A2UI):前端 interactive-ui 组件 65/65 + Harness render_ui_tool + update_ui_data_tool 30/30 = 95 tests, 0 failures。Myrm 23 种白名单组件注册表(表单10+布局5+展示6+基础3)+ 8 种内置表单验证 + 条件渲染(visible binding)+ UIComponentErrorBoundary 单组件容错 + validate_ui_adjacency 结构校验 + update_ui_data_tool 增量深合并——Agent 只需输出 JSON schema,零前端代码即可获得完整交互 UI。
- 为何 CopilotKit Generative UI 在此过时:CopilotKit 需要前端为每个 tool 手写 render callback,无内建验证/错误边界/增量更新。Myrm 的声明式注册表模式在安全性、一致性、开发效率上全面优于。
最新验证快照(2026-07-26)
- 任务导航 & AI 自动路由(vs mattpocock/skills
ask-matt):DiscoverCapability 57/57 + Clarification/ask_question 15/15 + capability_gap SSE 37/37 + StreamDispatcher 17/17 + Kanban API 361/361 + Kanban Service 102/102 + Kanban Integration 33/33 + Kanban Channels 89/89 = 711 tests, 0 failures。 - 验收接缝门(vs mattpocock/skills
/to-spec):Goal Engine(VerificationGatekeeper + ShellCriterion + SemanticCriterion + CompletionGuard + 熔断保护)209/209 + PlanConfirmMiddleware 13/13 + Kanban Verifier + Criteria Integration 47/47 = 269 tests, 0 failures。 - 修复预存在 bug:
kanban_command_handler.py:326—by_agent字典含Nonekey 导致排序TypeError;已安全处理。 - 为何 CLI 手动导航在此过时:Matt 的 ask-matt 需要用户从 17 个孤立 CLI 技能中手动选择工作流路径。Myrm 的 6 层自动路由让用户只需描述需求——Agent 自动规划并执行。
- 为何手动
/to-spec在此过时:Matt 的 to-spec 需要用户手动触发接缝定义。Myrm 拥有 5 层自动验收:GoalMode acceptance_criteria(用户定义)+ PlanConfirm HITL(计划审核)+ Kanban completion_criteria(结构化 shell+semantic)+ VerificationGatekeeper(任务完成后自动执行)+ CompletionGuard(反幻觉)。 - 用户迁移收益:使用 Matt skills 的开发者切换到 Myrm 后不丢失任何能力;他们获得的是 AI 自动任务路由和程序化验证,而非记忆斜杠命令。
- 实时任务监控(vs mattpocock/skills GTE 工作台概念):GoalStatusCard+GoalControlPlane+GoalPlanStepsList 27/27 + SubagentDashboard 2/2 + Kanban DnD+Markdown 48/48 + Goal Engine 164/164 + Subagent Engine 179/179 + Kanban API 250/250 + Kanban Integration 100/100 = 770 tests, 0 failures。Myrm 提供 9 层实时监控(GoalStatusCard fixed overlay + GoalPlanStepsList + GoalControlPlane + SubagentDashboard + ArtifactPortal + BrowserLiveView + DesktopLiveView + KanbanBoardView + MobileStatusBoard)——所有组件均可在 0-1 次点击内访问。Portal 支持三模式布局:overlay(快速预览)、side-by-side(宽屏 ≥1280px 自动并排,用户可手动切换)、fullscreen(沉浸式编辑),用户偏好通过 localStorage 持久化。
- 智能运行时 HITL vs 任务级 AFK/HITL 声明(vs mattpocock/skills
/to-tickets):Kanban task_runner 25/25 + unattended_mode 2/2 + approval_flow+yolo 111/111 + unattended_mode_guard 2/2 + approval_edge_cases+batch+ptc 38/38 + rate_limiter+denial+subagent_safety 22/22 + interception+correction+scheduler 104/104 + security_config+execution_policy+permission 169/169 + server approvals 67/67 + personality_yolo+payload 19/19 + HITL_resume+kanban_binding 11/11 + subagent_approval_integration 4/4 + batch_decisions+session 72/72 + workspace_boundary 12/12 = 658 tests, 0 failures。Myrm 的设计哲学:Kanban=天然 AFK(yolo+unattended)、Chat=天然 HITL、Cron=天然 AFK、GoalMode=智能切换。运行时 ToolApproval 按操作粒度触发(而非按任务),配合 4 级 Allow-Always 学习。Matt 的任务级 AFK/HITL 标记是 CLI 能力缺失的补丁——它制造了语义冲突(AFK 任务执行危险操作时怎么办?),而 Myrm 的操作级方案优雅解决了这一问题。 - 上下文管理 & 智能 Handoff(vs mattpocock/skills ask-matt Context Hygiene +
/handoff):ContextBudgetGuard 24/24 + ConversationForkManager 24/24 + ContextUsageIndicator 25/25 + Context pipeline 111/111 + Filter+cache_ttl_prune+resume 68/68 + Handoff API 24/24 + SummarizeProcessor 49/49 = 325 tests, 0 failures。Myrm 提供 6 层上下文管理:(1) ContextBudgetGuard 4 层溢出保护 (2) 50+ 文件自动压缩 pipeline (3) compactChat 手动压缩 API (4) ≥75% 时 checkpoint-based fork (5) ContextUsageIndicator 环形+CTA (6) HandoffDialog 跨渠道迁移。Matt 的/handoff是手动 CLI 命令,产生文本摘要会丢失上下文;Myrm 的 Fork 保留完整 LangGraph checkpoint 状态。修复预存在 bug:summarize_processor_NoOpMetricAttributeError。
最新验证快照(2026-07-23)
- Shell Pattern Allow-Always 全链路:Harness pattern 20 passed;Server SHPOIB + allowlist API 11 passed;前端 derive-pattern parity 13 passed;Chrome LIVE_AGENT E2E 1 passed(bash HITL → 始终允许此命令模式 → 设置页列表/删除 → 下次自动放行)。
- 相对竞品的用户收益:四级 Allow-Always(permission / tool / exact / 命令模式)+ 设置页 CRUD——Claude Code / OpenClaw 多止于工具名或 CLI 签名;复合 shell(
&&/管道)永不写入 pattern。 - 真实并行负载下的 Dev Gate 稳定性:执行
./myrm ready --chrome预检后,./myrm test定向套件全绿(ready/install 回归 54 项 + dev-gate 契约 32 项 + Chrome E2E 三条流程:READ spill / READ expired / LIVE marketplace 聊天)。共享栈短暂不可达时,attach 预检通过内置重试自动恢复,无需让用户手动停掉其他 pytest。 - 迁移收益(可落地):从 CLI-only 测试链路迁移到 Myrm 后,团队可统一使用“ready → test → 真实 Chrome 签收”闭环,并拿到
clientHot、runtimeId、lane 队列等显式健康证据,不再依赖经验式排障。
最新验证快照(2026-07-24)
- TTFT 启动路径实证(最小批次、低负载): Harness
test_backend_detector.py21 passed,定向模块覆盖 84%(backend_detector);Server 端 TTFT 链路测试(test_stream_loop_ttft.py、test_stream_collector_coverage.py、test_usage_aggregation_coverage.py)合计 18 passed,stream_loop/stream_collector/usage_aggregation定向覆盖 48%-72%。 - 资源边界(实测非估算): 通过
/usr/bin/time -l记录,以上批次峰值 RSS 约 90MB / 337MB / 144MB / 355MB,重复执行未出现持续爬升。 - 用户可感知收益: 在本机真实约束下,首字响应(TTFT)端到端可观测链路保持可验证,同时外部 Agent 探测启动路径稳定、无卡死回退。
- 诚实范围说明: 为避免高 CPU/高内存负载,本轮(2026-07-24)未追加重型浏览器 E2E;真实 Chrome MCP 证据仍以 2026-07-23 与 2026-07-20 快照为准。
最新验证快照(2026-07-20)
- 浏览器自动化基线(分批低负载):Harness 定向 109 项通过(
snapshot、事件分发链路、takeover)。 - 契约一致性校验:Server SSE 事件一致性 1 项通过;前端事件 schema 6 项通过。
- 快速交互稳定性(定向回归):前端
deep-link-listener+flow-pad-inline-mode+intent page套件 36/36 通过;服务端 gate/finish/integration 套件 43/43 通过。 - 覆盖率证据(定向文件):前端(
deep-link-listener.tsx、flow-pad-modal.tsx)定向覆盖 78.28%;服务端desktop_control/gate.py89%、background_job_finish_handler.py94%。 - 真实浏览器证据(非纸面):在真实 Chrome MCP 上对 WebUI 页面执行
take_snapshot+evaluate_script;已实测/intent/ask?text=...自动回首页并拉起预填文本 FlowPad。 - Chrome UI E2E:
test_background_tasks_panel_chrome_e2e.py3 项通过。 - 委派控制面 Chrome LIVE E2E:
test_subagent_dashboard_chrome_e2e.py3/3(340s);Session 级委派暂停 + Dashboard cancel/token/model 在真实 Chrome 签收。 - 验证过程中修复的预存缺陷:
mode=runningseed fixture 因UnboundLocalError导致 500,已修复 API fixture 路由并补齐集成回归测试。 - 资源安全边界:本轮验证期间系统可用内存保持在 36%-40%,未出现高压(已用 >80%)状态。
- 已知环境前提(诚实说明):captcha coordinator 测试仍依赖本机
patchright,但不影响本次浏览器语义快照/遥测基线结论。
一览
vs PilotDeck — 代理操作系统与多 Agent 协作平台
PilotDeck(清华 THUNLP 等联合开源)主打“Agent 操作系统”概念,提供 WorkSpace 工作空间隔离、白盒化记忆(Dream Mode)、智能路由降本以及 Always-on 后台驻留执行功能。Myrm 的领先之处
从 PilotDeck 迁移到 Myrm
从 PilotDeck 迁移过来,你将从一个“命令行偏向的操作系统”彻底升级为一个 “面向图形化交互的现代智能体工作站”。你不仅继承并超越了其引以为傲的多项目隔离、省钱路由、后台执行等高级能力,更将获得可视化、可拖拽、可回滚的安全体验,以及与主流 MCP 插件生态无缝打通的开放性。vs 360 Security OpenClaw(企业封装版)
360 Security OpenClaw 是基于 OpenClaw 核心的闭源企业封装,通过「Shrimp Coach」引导配置和手动「Token 成本模式」(轻量/经济/全功率)降低上手门槛。Myrm 的领先之处
结论:Myrm 提供更自动化、原生的 GUI 体验。无需「教练」问答,直接给可用模板;双阶段路由比竞品的纯 LLM Judge 方案更省 token 且更准确,并提供约 10 倍成本透明度。
vs OpenClacky — Token 优化本地 Agent
OpenClacky 主打低成本本地 AI Agent,宣称 Token 约为 Hermes 的 1/6。核心策略:16 个最小工具、空闲压缩、先插入后压缩、双缓存标记、BYOK 多模型路由。Myrm 的领先之处
关键架构差异
压缩成本:OpenClacky 调用 LLM 生成压缩摘要 — 每次压缩都产生 API 成本。Myrm 使用确定性规则引擎(Dedup → Truncate → Remove),零 LLM 开销。 缓存智能:OpenClacky 双缓存标记是静态模式(始终标记最后 2 条消息)。Myrm 的 ExplicitCacheProcessor 根据内容块、token 距离与压缩边界动态计算断点,并带完整校验流水线。 空闲利用:OpenClacky 空闲定时器仅压缩消息。Myrm 空闲流水线并行 3 项:认知记忆整合、会话证据挖掘(从失败中学习)、前缀缓存预热 — 由容量感知调度器协调,带熔断保护。此外,CacheKeepAliveManager 每 4 分钟发送轻量 probe,防止 Anthropic/Qwen 5 分钟缓存 TTL 过期,确保用户暂停后继续对话时 TTFT 一致(0.5-1s vs 冷启动 2-5s)。
从 OpenClacky 迁移到 Myrm
结论:8 项升级、0 项持平、0 项降级。OpenClacky 用户获得零成本压缩、智能缓存保护、跨会话持久记忆与完整 GUI 工作区,同时保留全部 Token 效率优势。
统一工具网关与弹性 BYOK(vs Hermes / OpenClaw)
竞品常迫使用户管理大量 API Key,或依赖僵硬、易出错的网关。Myrm 提供 四合一统一工具网关 与 弹性 BYOK 回退 机制。Myrm 的领先之处
- 四合一网关:一次订阅解锁 LLM、网页搜索、图像生成与 TTS,开箱零配置。
- 弹性 Try-Catch 回退:官方网关不可用或 Work Units (WU) 用尽时,Myrm 自动无缝降级到你本地配置的 API Key,业务不中断。
- 配额结转:与传统 SaaS 未用配额作废不同,Myrm 允许未用 WU 结转至下月。
- 可视化网关状态:专用 GUI 仪表盘展示各工具状态(网关托管 / 自定义 Key / 未配置),Pro 用户有智能提示启用网关能力。
- 金融级安全:PAT 经安全 POST 体传输,严格正则校验,防 SSRF,保证 token 不进 URL 日志。
- 极端网络韧性:命令式按需轮询 +
AbortController8 秒硬超时,消除竞品自动轮询仪表盘导致的 UI 卡死与 API 配额空耗。
竞品痛点
- Hermes:网关「非黑即白」硬切换;网关失败或额度用尽则 Agent 直接崩溃停工。
- OpenClaw:完全依赖用户通过扩展提供的 Key,无统一网关与计费。
- 云浏览器依赖:Hermes 网页任务依赖第三方云浏览器(如 Browser Use),高延迟与隐私风险。Myrm 坚持本地/自托管沙箱做浏览器自动化,零延迟、数据完全私有。
迁移收益
- 零 Key 管理:不再为 OpenAI、Firecrawl、FAL 等疲于切换 API Key。
- 安心:弹性回退 = 托管网关便利 + 自有备份 Key 可靠性。
WebUI 安全与本地/远程分离
多数竞品的 Web 界面要么在公网桥接时裸奔暴露(LAN/隧道无保护),要么对单人本地开发过于沉重(localhost 也强制数据库与登录)。
Myrm 以奥卡姆剃刀式 WebUI 安全方案,解决本地优先部署的「最后一公里」。
Myrm 的领先之处
- 本地零摩擦 vs 远程铁壁:WebUI 自动识别
localhost回环免登录;一经隧道或 LAN 暴露即强制密码保护。 - 零信任 WebSocket 网关:竞品常只保护 HTTP,WebSocket(实时日志/语音)裸奔。Myrm
WsAuthMiddleware在 session cookie 缺失或无效时物理拒绝握手(HTTP 403)。 - CORS 三层纵深防护:scheme+host 双层输入校验(通配符
*直接拒绝)+ WebSocket Origin Guard(复用 CORS 配置统一安全边界,4003 拒绝非法 origin)+ HostAllowlist DNS Rebinding 防护(动态 ingress/tunnel hostname 白名单)。Tauri 桌面端tauri://localhost原生 scheme 支持。云部署 default-deny。29 项 CORS 安全测试验证。 - 即时会话驱逐:改密码或切换保护时自动轮换全局 HMAC Session Signing Key,瞬间作废所有会话(类似失窃设备一键熔断);竞品旧 JWT 常仍有效。
- 单租户 Vault vs 重型 DB:本地模式用单一高加密
admin.json,非 SaaS 式 Postgres/MySQL + RBAC 膨胀;安全、可移植、零依赖。
数据防泄漏(DLP)与隐私感知路由
Agent 对话可能涉及敏感个人信息。竞品(如 ClawVault)仅在对话消息级别做简单的”检测→占位符替换→还原”,遗漏了工具参数、工具结果、流式输出等多个泄漏通道。Myrm 的领先之处
2033 项离线/隐私/安全测试全通过(2026-07-14 验证),覆盖 PrivacyRouting(44)+ Hardware API + 部署模式(48)+ LLM Fallback 降级(153)+ 安全全套(1766)+ OfflineGuardian 通知(22)。vs QoderWork「离线运行」仅绑定通义千问本地版,无隐私路由、无硬件推荐、无熔断降级——Myrm 9 项离线维度全面碾压。
多 Agent 编排:确定性调度(vs Hermes / OpenClaw / JiuwenSwarm)
竞品多依赖单一编排模式(如 Hermes Kanban Swarm、OpenClaw 基础线性 spawn、或 JiuwenSwarm 的静态 DAG 工作流脚本)。Myrm 提供 8 模式确定性编排引擎,辅以 5 层工具安全围栏 与 4 维预算控制。与 JiuwenSwarm 需要用户编写 Pythonworkflow.py 脚本来定义执行顺序不同,Myrm 的 Leader Agent 通过自然语言动态调度子 Agent,并支持运行时转向/取消 —— 这是静态 DAG 无法提供的能力。
Myrm 的领先之处
结论:Myrm 用确定性软件工程模式取代「提示并祈祷」式多 Agent。流水线每次可靠、安全、在预算内执行。1,680 项编排测试通过,0 失败(2026 年 7 月)。
:::tip vs AWS Codex Agent Team — 代码级编排
AWS 的 sample-codex-agent-team 通过 6 个纯 Prompt 的
SKILL.md 模板(头脑风暴→规格→协调→评审→文档→项目管理)指导多 Agent 协作——完全依赖 LLM 自律。Myrm 用代码级原语替代每一步:run_council 多专家交叉审查、execute_dag_plan 确定性 DAG、run_with_verification 对抗验证自动重试、31 组件看板 GUI 实时项目管理。LLM 无法绕过任何一环。
竞品的 12 字段 “Handoff Contract”(role、objective、file scope、acceptance criteria、verification command 等)同样是纯 Prompt 约定。Myrm 通过 DelegateTaskInput Pydantic schema + 8 项代码级强制检查(payload-hash 去重、深度/容量限制、类型白名单、暂停控制、验证模式)全部覆盖——还额外拥有 4 项竞品完全没有的独有机制。2,488 项测试通过,0 失败。
:::
智能并发路由 — 消除读写竞态(vs Hermes / OpenClaw)
高并发 Agent 沙箱中,LLM 常幻觉出破坏数据的操作,例如在同一并行工具批次中「同时读文件 X 又写文件 X」。竞品架构会导致脏读与灾难性写覆盖。 Myrm 引入 智能并发路由,在中间件层主动拦截并重路由冲突操作。Myrm 的领先之处
结论:Myrm 彻底消除 LLM 幻觉导致的文件级竞态。冲突批次优雅展开为顺序队列,无关并行任务零性能损失。
无头 Agent:零死锁后台任务(vs Hermes / OpenClaw)
SaaS 定时任务(Cron)、批处理或后台自动化等无头环境中,Agent 无人监督运行。若 LLM 幻觉调用人工介入(HITL)工具(如提问或渲染 UI 表单),竞品会无限等待永不到来的用户输入,灾难性死锁并烧穿算力。 Myrm 在框架最底层提供 基于标签的环境降级 架构。Myrm 的领先之处
结论:Myrm 保证无人值守工作流防弹可靠。后台任务物理剥离交互工具,在 LLM 犯错前根除 Cron 死锁根因。
此外,Myrm 的 Stuck Task Watchdog 可检测基础设施层面卡死的 Agent 任务(如 LLM API 半开连接、工具死锁),并在可配置超时(默认 600 秒)后自动取消。Watchdog 运行于现有 60 秒 janitor 周期内,零新增组件,向用户发送本地化超时通知(支持 5 种语言),并释放会话以便后续消息正常处理。竞品 OpenClaw 需容器级
killContainer(粗暴),Hermes 需手动 /stop — Myrm 全程透明处理。
极端场景防爆(vs Hermes / OpenClaw)
自主多模态场景(如 Computer Use)或超长会话中,Agent 必然撞上下文窗口上限;竞品频繁 OOM、断连或记忆全丢。 Myrm 实现 四层极端防爆护城河,确保 Agent 不崩溃、对话上下文不丢。Myrm 的领先之处
结论:极端负载下仍丝滑。剥离历史图片大幅省 Token,不必担心 Agent 突然崩溃抹掉劳动成果。
网页搜索 + 网页抓取 — 双引擎(vs Hermes / OpenClaw / Claude Code)
Myrm 将 web_search 与 web_fetch 作为一等内置工具。竞品要么缺失、要么透传原始 API 结果、要么按次向云 API 计费。你将获得
竞品痛点
:::note 诚实边界
Hermes
web_extract 看似「零配置」因用 LLM 摘要而非本地 embedding — 但每页消耗 token。Myrm web_fetch 开箱本地 DOM 修剪;配置后可 fetch_and_extract 向量+Reranker。SSRF 防护相当 — Myrm 优势在 过滤流水线,非基础安全。
:::
迁移收益
配置与用法见网页搜索与抓取指南。
引用溯源与来源展示
每条 AI 回复中引用的信息均可追溯到原始来源。支持 4 种来源类型(网页搜索、MCP 工具调用、知识库文档、历史对话),通过 hover 预览查看完整摘要、域名和 favicon,触屏设备自动切换为点击模式。文档解析引擎
Myrm 内置 11 模块专业文档解析引擎,提供从 PDF 到 Office 到 Jupyter Notebook 全格式的深度解析能力(184 项测试验证):vs Hermes Agent (v0.15 Velocity) — 多 Agent 平台
Hermes v0.15(Velocity,2026-05-28)将核心循环从 16k 行重构为 14 模块共 3.8k 行,新增 Kanban Swarm 编排(104 PR),session_search 重写为无 LLM(~20ms,原 ~30s),引入 Promptware 防御(3 卡口、~15 Brainworm/C2 模式)。显著「还技术债」版本。
Myrm 的领先之处
- 事件驱动看板 vs Hermes 轮询 — 即时分派 + 心跳 + 僵尸检测 + 三层防冲突(原子认领 + 所有权强制 + 分配审计,817 项测试)
- 6 条诊断规则 + 严重度自动升级(warning→error→critical)— 检测滞留 Ready、重复失败、长期 Blocked、死依赖、Triage 停滞、Block↔Unblock 循环(每卡 O(1) vs Hermes O(N) 事件扫描)
- 8 种编排模式(Spawn/Chain/Batch/DAG/Verified/Swarm Fission/Alternatives Race/Council Debate)vs v0.15 单一 Swarm
- CompletionGuard 物理证据验证 — Hermes 无完成验证器
- 流水线模板向导(发现问题 + 角色自动匹配)— Hermes
hermes kanban swarm为固定 CLI - 35+ 消息渠道(25 带输出提示)vs ~23(19 带平台提示)— Myrm 覆盖钉钉、Teams、Google Chat、LINE、IRC、iMessage、Voice、Webhook、Zalo 等 Hermes 缺失项
- 8 类记忆 + 知识图谱 vs 2,200 字符扁平记忆(MEMORY.md + USER.md § 分隔)
- 网页搜索 + 抓取双引擎 — 8 引擎 BM25/Reranker + 三层本地抓取 DOM 修剪($0/月)vs Hermes 云 API 透传 + Firecrawl/LLM web_extract
- FTS5 + Qdrant 混合搜索 + 作用域/谱系过滤 — Hermes v0.15 仅本地文本(~20ms,无语义检索)
- 108 模式安全扫描 vs Hermes threat_patterns.py(3 作用域 ~20 模式)
- 22+ 中间件流水线 vs 8 层固定栈 — Myrm 各组件可独立配置
- 四层模型纪律(CORE→ENFORCEMENT→FAMILY→ESCALATION)vs Hermes 模型门控文本块 — Myrm 含 ESCALATION_CONTRACT 自动模型自升级
- GUI 优先 + Tauri 桌面 vs 仅 CLI(v0.15 加 TUI 多会话,仍终端绑定)
- 4D 预算(Token + USD + 时间 + 最大子代)— Hermes v0.15 仅每任务超时(1 维)
- 三级智能模型路由 — Hermes v0.15 仅手动每任务选模型(无自动路由)
- 6 层 Prompt Cache vs Hermes
system_and_3(4 断点、仅 Anthropic)— Myrm 支持 5+ 提供商 + 缓存断裂检测 + 防抖动 - Cache 友好的记忆注入:Myrm 将记忆分为 Stable(SystemMessage,缓存安全)+ Learned(HumanMessage + UNTRUSTED_DATA 安全隔离,绝不污染 System Prompt)。Hermes 文章声称「以 User Message 形式注入」,但其真实代码(
system_prompt.py:424-486)将记忆合并到 System Prompt volatile 层——每次记忆更新都会导致缓存失效。175 项缓存专项测试已验证 - IP 人设保护零额外成本:用户配置的
system_prompt通过UserInstructionsMiddleware以priority="highest"+[ABSOLUTE OBEDIENCE OVERRIDE]最高优先级注入,确保 LLM 严格遵从 IP 身份事实。Hermes 仅依赖纯文本SOUL.md,无优先级强制执行机制。AI Builder 自动生成包含反捏造指令的人设定义——765 项中间件测试已验证 - 4 层工作区上下文注入:
workspace_rules_middleware自动发现 15 种格式(.myrm.md、AGENTS.md、CLAUDE.md、.cursorrules、.clinerules、.windsurfrules、SOUL.md、MEMORY.md、.cursor/rules/*.mdc、.claude/CLAUDE.md、.github/copilot-instructions.md等)的项目规则文件,注入为<workspace_context>。包含 prompt injection 检测(score≥0.8 阻断)、隐形 Unicode 清洗、YAML 前言清除、inode 去重、20K 字符总预算内 head/tail 截断。每层按作用域划分(跨用户/per-user/per-workspace)最大化 Prompt Cache 效率。Hermes/WorkBuddy 需要手动创建MEMORY.md+SOUL.md且无优先级控制——17 项集成测试已验证
技能进化 — 真·自进化 Agent
Myrm 技能进化(42 模块、原生内置)实现 Self-Improving Agent 研究可工程化概念。Hermes「自进化」是第三方 AGPLdarwinian_evolver 的外部 CLI 包装,非原生能力。
vs ECC (Everything Claude Code)
continuous-learning-v2: ECC 在后台蒸馏原子化「本能」YAML 习惯 — 对高级用户强大,但其 v2.1 项目隔离仅有 2 级(git remote hash → 项目/全局),且 “2+ 项目出现自动晋升全局” 存在误报风险。Myrm 提供相同 思路(空闲蒸馏 → 技能提案)+ 架构级更强隔离:5 级作用域层级(GLOBAL > AGENT > CHANNEL > CONVERSATION > TASK)+ 命名空间 + 每 Agent CoW 进化。Agent 设置中的 Insights Inbox 确保提案保持草稿直至你批准;驳回写入负例以防重复提案;内置 Agent 在 inbox 只读。3,519 项测试验证覆盖技能注入、模型纪律、进化、搜索、安全全链路。MCP 方面 Myrm 已提供 GUI 启用前扫描 + 验证 + 运行时 fail-closed(见下文 MCP 安全门)— 领先 Hermes 仅日志流;我们尚未提供 ECC 的 /aside 分叉聊天、/context-budget 树图或 102-hook 全量静态包(roadmap #6)。
技能模块架构 — 八维优势
除进化外,Myrm 技能系统架构在各维度上更成熟:技能生态发现与导入 — 7 源并行聚合 vs 单一来源
竞品仅扫描单一本地目录(.claude/skills/、.agents/skills/),Myrm 从 7 个并行发现源(含 ModelScope 80K+ / Aliyun AgentExplorer)聚合技能,配备完整 GUI 导入管线:
结论:9 项升级、0 项持平、0 项降级。Myrm 将技能发现打造为一流 GUI 体验,具备企业级安全保障与 preview/confirm 一致错误契约;竞品仍局限于本地目录扫描。
进化验证管线 — 5 层纵深 vs 零验证
竞品提案建议用户手写validator/*.md 测试用例——这对 SOP 提示词类型的技能来说是根本性的设计缺陷,且大幅增加使用摩擦。Myrm 的 5 层自动验证管线 提供全方位保护,用户零摩擦:
核心洞察:绝大多数技能是 Markdown SOP 提示词(如”审查代码时按以下步骤…”),无法为提示词编写确定性测试用例——我方 5 层管线通过互补验证类型优雅解决了这一问题。3,519 项测试验证。
进化透明化 — 6 个 GUI 面板 vs 平文本文件
竞品提案建议将 DB 记录同步到技能目录下的HISTORY.md 文件以实现”透明化”。Myrm 提供 6 个专用 GUI 面板,其丰富交互性让平文本文件显得过时:
负例记忆:3 张 DB 表(
evolution_constraints + evolution_rejections + execution_analyses)自动从失败中学习。引擎通过 get_evolution_constraints() 将历史约束注入变体生成提示词,防止重复犯错——完全自动的闭环系统,用户零维护。新增 332 项测试验证。
有界编辑控制 — 6 层软约束 vs 硬熔断
竞品提案强制实施”最多 1 个变更点”的硬熔断规则。这在根本上是有缺陷的:一个 bug 修复通常合理地涉及 2-3 个相关节,且 Markdown 没有可靠的 AST 来计数”变更点”。Myrm 使用 6 层软约束 在不设人为限制的情况下保证修复质量:
配合硬阈值拒绝(score < 0.6 或 accuracy < 0.7 自动拒绝),实现有界编辑同时不牺牲修复完整性。Monaco DiffEditor 提供行级红/绿变更高亮——比竞品的”高亮单个节”更精确。1783 项测试验证。
框架驱动引擎 — Python 框架 + 5 层定制 vs 纯 Prompt 文件
部分竞品完全通过可编辑的 Markdown 提示文件(如reflect.skill.md、edit.skill.md)驱动技能进化。表面灵活,实则脆弱——改错一行整条管线崩溃,SaaS 部署不可用,且存在双源真相冲突。
Myrm 使用 Python 框架引擎 搭配 7 个硬编码安全提示模块,结合 5 层结构化定制体系:
为用户提供结构化、安全的定制,无需冒险编辑原始提示文件。Local、Tauri、SaaS 三端体验完全一致——无文件系统依赖。1923 项测试验证。
进化可视化 — 9 面板全生命周期 vs 仅命令行
部分竞品完全依赖 Cron 和命令行输出监控技能进化。Myrm 提供 9 个独立可视化面板 覆盖进化全生命周期:
无需解析命令行输出,无需翻看日志文件。一切可视化、可交互、可操作。2062 项测试验证。
跨 Skill 全局规则 — 三层有机学习体系 vs 自动写入 AGENTS.md
部分竞品提案在检测到跨 Skill 共性失败模式时,自动向AGENTS.md 或系统 Prompt 注入全局规则。这种做法在架构层面十分危险:修改用户手动维护的工作区文件、制造双源冲突、破坏 Prompt Cache 效率。
Myrm 采用三层有机学习体系安全地实现同一目标:
相比自动写入方案的关键优势:
- 安全:不修改用户文件或系统 Prompt——Learned Rules 通过 MemoryContextMiddleware 流动
- 缓存友好:Learned Rules 放在 HumanMessage 位置,不破坏 System Prompt 的 KV Cache
- 精确作用域:规则可设为全局或工具级(
tool_name字段),不是一刀切的全局注入 - 安全防护:所有学习数据经过
sanitize()+wrap_untrusted()安全边界标记 - 三端通用:Local、Tauri、SaaS 体验完全一致——无文件系统依赖
从 Hermes 迁移(技能系统)
结论:7 项升级、1 项权衡、0 项降级。用户获得智能安全、安全配置管理与有序技能生命周期,零能力损失。
vs MiniMax Mavis — 多 Agent 团队平台
MiniMax Mavis 是闭源 SaaS 多 Agent 系统,采用 Leader-Worker-Verifier 架构,仅通过飞书(Lark)集成提供。Mavis 做得好的地方
- Leader-Worker-Verifier 模式 — 规划、执行、验证角色清晰分离
- IM 原生体验 — 飞书聊天内直接多 Agent 协作
- 「即时回复」+ 后台执行 — 立即确认用户,任务异步运行
- Worker 间上下文隔离 — 各 Worker 独立运行
Myrm 的领先之处
从 Mavis 迁移到 Myrm
结论:7 项升级、1 项持平、0 项降级。用户获得开源数据主权、模型自由与多平台接入,零能力损失。
vs Claude Code — Fork 子 Agent 与 Prompt Cache
Claude Code 采用「Fork 子 Agent」设计,字节级 prompt 前缀对齐以复用 KV Cache,子 Agent 成本最高可降 90%。Myrm 的领先之处
从 Claude Code 迁移到 Myrm
结论:6 项升级、0 项持平、0 项降级。Myrm 缓存经济性更强,具备 Claude Code 完全缺失的三项能力(断裂检测、防抖动、Resume 感知)。
Claude Code 2.1.154~2.1.157 Harness 升级
随 Opus 4.8,Claude Code 推出/effort(6 级推理预算)、Dynamic Workflows、精简 system prompt 与增强 --resume。Myrm 对比如下:
结论:10 项升级、0 项持平、0 项降级。
动态工作流 — 真实痛点
基于 Claude Code Dynamic Workflows 用户反馈(2026-05 数据):
关键架构差异:Claude Code DW 运行时生成带关键词触发的 JavaScript 编排脚本(非确定性,可失败或偏离)。Myrm 双路径:生产负载用声明式 DAG(确定性、执行前可验证);可选 Dynamic Workflow(手动开关、Python PTC 沙箱、确定性
workflow_id、SQLite 事件溯源实现子 Agent 幂等重放)用于临时并行脚本 — 均配 一等 HITL GUI。
置信度分级摘要:DW 汇总结果自动标注 4 级置信度 — ✅ 已验证(有执行证据)、⚠️ 未验证(仅 LLM 推理)、❌ 已反驳(被证据否定)、💥 失败(任务出错)。用户一眼区分可靠结论与 LLM 猜测。零竞品提供此能力。
vs Scrapling & BrowserUse — 全自主混合浏览器引擎
典型 AI Agent 用 Playwright/Selenium 包装(如 BrowserUse)在动态页频繁崩溃;传统抓取框架(如 Scrapling)需开发者手写反爬代码。Myrm Agent 提供 全自主混合浏览器引擎。Scrapling & BrowserUse 做得好的地方
- BrowserUse: Wraps Playwright for LLMs to click elements, but relies on slow LLM reasoning every time a locator fails.
- Scrapling: Provides powerful stealth tools (
camoufox/curl_cffiHTTP fetching) but requires developers to manually wire them into a crawler script.
Myrm 的领先之处
迁移收益
从原生 Playwright 或其他 Agent 框架迁移的用户获得:- Zero-Crash UI Navigation: End the frustration of “Element not found” errors ruining a 20-minute agent task.
- Blazing Fast Data Retrieval: Don’t burn memory on full Chromium instances for simple text extraction; Myrm degrades to HTTP seamlessly.
- Production Grade Reliability: Auto-detects 10 CAPTCHA providers and solves them via CapSolver API with FallbackSolver chain (manual HITL takeover when needed). Passes Cloudflare invisibly.
SubagentExecutor 可靠性(2026-07)
委派子 Agent 时,Myrm 专用 SubagentExecutor 处理用户可感知的边界情况:
回归覆盖: 10,838 项编排全链路测试通过、0 失败(2026-07-11):委派核心(97) + 锦标赛与验证(5) + spawn工具与安全注册(21) + sub_agents全套含manager/executor/event/checkpoint/orphan recovery(603) + 并行与resume compact(5) + Kanban引擎全套(429) + streaming与stream_recovery(637) + security全套含context_budget/隔离/权限(1,761) + LLM toolkit含credential_pool/路由/fallback(1,344) + context_budget专项(60) + credential_pool专项(36) + error_classifier专项(175) + Item #13~15 验证(2,431):sub_agents套件(603) + security套件(1,761) + multiplexer与thread_sharing(27) + 前端Vitest SubagentDashboard+SubagentStore(17) + EventForwarder(12) + TeammateMailbox(11) + Item #17 验证(105):consensus引擎(64) + council编排(25) + council集成(16) + consensus类型(8) + Item #18~19 验证(978):memory scope绑定(9) + ACP全套(386) + A2A resolver+SSRF(44) + MCP工具集全套(539) + Item #20+Token预算验证(847):budget_guard(59) + manager_core(186) + context_budget(71) + executor+delegation(165) + config+heartbeat(70) + stream+lifecycle(121) + token_control+memory+loop_guard(175) + Item #32+#36 验证(230):dynamic_workflow引擎(64) + DW_e2e(9) + pipeline+模板(47) + orchestrator+swarm(99) + swarm_fission+marketplace(11)。
核心 Preset 工具可用性 — SCIP Phase 0+1(2026-07)
修复 silent dead delegate:browser/analysis 子代理 preset 引用过期工具名 →filter_tools() 得 0 工具 → 父 Agent 误以为委派成功。
诚实竞品说明: OpenClaw、Hermes 已支持浏览器委派;Myrm 额外提供 preset SSOT fail-fast、cache-safe 外围 skill 绑定 与 L3 父工具集 session 合并,避免生产环境 silent no-op 与「开了 Browser 仍委派失败」。
SCIP 测试包: 65 passed, 1 skipped(harness preset/护栏 + server binding/spawn smoke + 前端 hint vitest,2026-07)· API Live E2E
example_domain_seen ~6.5s(mimo-v2.5-pro,2026-07-08)。
凭证库 — 密码与 2FA 永不进入 LLM
多数框架在自动化登录时的默认模式是灾难性的:模型生成密码字符串并通过type/fill 工具参数传递,该值残留在聊天历史、MCP 日志与重试缓冲区。
Myrm 表单凭证库 将「知道凭证」与「使用凭证」分离:
Myrm 的领先之处
与 FSB 的诚实对比
FSB 首创浏览器自动化的库边界模式(标签引用 → 扩展解密 → DOM 填充)。Myrm 采用 相同安全原则,并扩展到 桌面 Computer Use、原生 TOTP 与 统一产品 GUI — 无需独立 Chrome 扩展。FSB 在支付卡 API(use_payment_method)仍领先;Myrm 今日覆盖密码字段与 2FA。
迁移收益
- 从 Hermes / OpenClaw:别再往提示词里贴密码;在设置中配置一次即可。
- 从 FSB:相同心智模型(标签),外加桌面应用与 TOTP,同一工作区。
- 企业场景:凭证库 + 12 维权限 + 结构化审计(37 种决策类型 + Prometheus 指标)+ 无痕会话跑敏感任务。
MCP 安全门 — 启用前先知风险
第三方 MCP 服务器攻击面日益扩大:投毒工具描述、敏感路径访问、运行时工具注入可在对话中途危及 Agent。 Myrm 在 MCP 进入工作区之前 设门:
诚实范围:完整 102-hook 静态规则包在 roadmap — 本门控覆盖真实用户路径(设置 → 启用 → 聊天)。回归:harness + server API 测试(21+ 用例)。
迁移收益
- 从 Hermes:别只在日志里发现坏 MCP — 先在设置中拦截或确认。
- 从 OpenClaw:环境过滤不够;要启用前扫描 + 运行时断开。
MCP 协议架构 — 持久连接、事件驱动、缓存友好
Myrm 的 MCP 实现采用持久热连接与事件驱动的工具发现机制 — 而非竞品使用的冷启动重连模式。
成本影响:每次竞品重连 MCP 服务器,工具列表在 Prompt 中的 Token 位置变化,导致 LLM Prompt Cache 失效。启用 10+ MCP 服务器时,这可能带来每小时 2.00 的额外缓存未命中开销。Myrm 的冻结代理方案使工具区段在各轮对话中字节稳定。
迁移收益
- 从 Hermes:不再出现空闲超时后的「tool not found」错误 — 持久连接保持热状态。
- 从 OpenClaw:不再为每次重连造成的工具列表抖动而支付 Prompt Cache 失效的代价。
Shell 命令可视化审批 — 允许前看清每条管道
Agent 执行curl … | bash 时,单行等宽字体隐藏了哪段下载、哪段执行。
Myrm Shell 命令展示 将管道拆为带逐段风险着色的 span — 与 OpenClaw 用户心智模型一致,默认开启并接入六层安全栈。
诚实限制:超长命令在界面会提示截断。本地使用需同时启动前后端;只开界面时会看到明确启动指引,而不是难懂的报错。
迁移收益
- 从 OpenClaw:熟悉的分段 shell 视图 — 外加 12 维权限、泄漏检测与结构化审计追踪。
- 从 Hermes / Claude Code:别盲批单行命令 — 一键前看清管道段与风险。
vs MemPalace — AI 记忆系统(14.9K+ Stars)
MemPalace 是独立 AI 记忆系统,用 Wing/Room/Closet/Drawer 建筑隐喻,奉行「逐字存储一切」,LongMemEval 达 96.6% R@5。作为 MCP 工具供外部 AI 助手调用。MemPalace 做得好的地方
- Verbatim storage — stores raw conversations without lossy summarization
- Architectural organization — Wing/Room/Closet/Drawer hierarchy gives AI a “navigation map”
- 4-layer memory stack — L0 identity (~50 tokens) through L3 deep search, keeping wake-up cost under 900 tokens
- Multi-format ingestion — normalizes Claude, ChatGPT, Codex, Gemini, Slack exports into a unified format
- Local-first — runs entirely on your machine with ChromaDB, zero cloud API calls
Myrm 的领先之处
从 MemPalace 迁移到 Myrm
结论:10 项升级、0 项持平、0 项降级。MemPalace 用户获得记忆原生集成的完整 Agent 平台(非外挂),并多出 12 项 MemPalace 不具备的能力(智能遗忘、GUI 管理、安全扫描、偏好追踪、健康诊断等)。
双路径数据可视化 — 零代码图表 & 交互式表格
竞品(Codex、Claude Code)处理数据时只能输出纯 Markdown 表格。Myrm 提供 双路径架构,从简单数据展示到复杂交互仪表盘全覆盖:
路径 1 — Generative UI(零代码):Agent 通过 SSE 事件渲染 24 种内置组件(UIChart、UITable、UIProgress、UIBadge、UICard、UIGrid、UITabs 等),前后端双重白名单安全保障 + 8 种验证规则 + i18n 国际化 + 条件渲染,用户无需写代码即可看到丰富的交互式数据可视化。
路径 2 — React Artifact(全功能):复杂可视化场景,Agent 生成自定义 React 组件,使用 Recharts/Echarts/D3/Chart.js,在 Sandpack 实时预览中支持代码编辑、控制台输出和 Tailwind CSS。
697 项测试验证(2026-07-03) → render_ui 全链路 87 项(2026-07-04 新增):Harness A2UI spec 24 ✅ | Interactive UI 59 ✅ | Artifact 渲染器 47 ✅ | ArtifactPortalStore + SSE 15 ✅ | Chat 导出+Schema 39 ✅ | 后端 Artifact 系统 61 ✅ | 后端 API(Artifact + Share + UI Stream)57 ✅ | CSP 安全头 41 ✅ | Harness Core Artifacts 27 ✅ | Harness Agent Artifacts 114 ✅ | Inline Artifact Events 9 ✅ | Artifact Judge 9 ✅ | Inline Artifact Push 7 ✅ | Mermaid Theme 18 ✅ | Render UI Tool 9 ✅ | Core file_id chain + listener 4 ✅ | Artifact Services 13 ✅ | UI Artifact Stream 7 ✅ | DocumentSelectionToolbar + useSelectionAction 12 ✅ | VersionHistory + VersionHistoryBanner 20 ✅ | reactCodeProcessor 35 ✅ | reactPreviewConstants 21 ✅ | Artifact 导航体系全量验证 105 ✅ | 图片标注编辑器 54 ✅ | render_ui SSE wiring 14 ✅ | run_bind + fail-closed 集成 13 ✅ | 真实 LLM E2E + Chrome DOM 联调 1 ✅
vs 豆包专业版 — 「AI→办公交付」全流程闭环
豆包专业版内置飞书 Office 套件(文档/表格/PPT),依托字节跳动内部生态实现「AI 生成→排版输出」全流程。Myrm 以更轻量的 Artifact 架构达到同等甚至更优的办公交付体验:
52 项测试验证(2026.6.30):DataGrid 11/11 ✅ + CsvParser 19/19 ✅ + SelectionToolbar 17/17 ✅ + LocaleKeys 5/5 ✅
结论:豆包的优势在于飞书 Office 生态壁垒(数千人年产品),非技术可复制。Myrm 以 Artifact 系统(Monaco + DataGrid + HTML Preview + SelectionToolbar + 一键部署)构建了完整的「AI→交付」闭环,在 AI Agent 场景下更轻量、更高效、更易维护。
vs Trae/WorkBuddy/deer-flow — 报告排版与 PDF 导出
用户评判 AI 办公产出的第一标准:「成品能否直接发给老板」。Trae 被夸赞的是排版清爽,WorkBuddy 的 stock-advisor 能生成杂志风 PDF 报告。Myrm 在报告生成全链路上全面领先:
Myrm 独有优势:沙箱预装 PDF 工具链(pdfkit + reportlab + pdfplumber + pdf2image + img2pdf + Pillow),Agent 无需安装任何依赖即可生成专业 PDF;8 个报告 Skill 覆盖从日报简报到深度研究到竞品分析到数据可视化的全场景;daily-briefing + cron 实现全自动定时简报推送到 26+ IM 渠道。
4,612 项报告+Artifact 全栈测试通过(2026-07-14):Artifact 系统 159 + Skill 系统 398 + 文件/PDF/简报/Cron 492 + 代码执行 1,272 + 前端 2,291。
vs 豆包专业版 — 「防假死 & 细粒度进度」体验对比
豆包专业版的真实用户痛点:(1) 处理 50 页 PDF 时进度条卡在 87%;(2) 生成长文档时页面无响应约 30 秒。Myrm 已在架构层面彻底解决:
169 项测试验证(2026.7.11):ProgressSteps 25/25 ✅(含语义工具标签 + workflowStage)+ LiveTerminal 27/27 ✅ + PetDispatch 8/8 ✅ + ArchiveRestore 2/2 ✅ + MessageStream handlers 29/29 ✅(toolLifecycle/gapEvents/statusStream/tasksSteps/petDispatch/clarification/completion)+ structured_clarify E2E(SSE 解包 + option.id + live API interrupt/resume 1/1 ✅)+ Harness step_builder 38/38 ✅ + scrubbing 5/5 ✅ + event_handlers 47/47 ✅(reason 提取 + 敏感信息脱敏)
结论:豆包的卡死问题源于「没做好」(主线程阻塞 + 无细粒度反馈),而非「未做」。Myrm 的架构(SSE + WebWorker + PTC notify + 树形进度步骤 + Live Terminal)构建了完整的防假死与进度反馈体系,远超简单进度条方案。
vs Marvis(腾讯) — 「分屏流媒体工作台」对比
Marvis 的核心卖点:「左侧是 Mac mini 的实时桌面画面,右侧是对话框,操作感和坐在电脑前没什么差别。」Myrm 已具备完整的分屏实时监看能力:
验证数据(2026.7.14 更新):454 项 VNC+ArtifactPortal 全栈测试全通过——前端 ArtifactPortal Store 4 + Portal 交互 49 + VisualApproval 4 + Entitlements 3 + ChatWindow 5;后端 VNC Routes 7 + Desktop Snapshot 5 + Takeover Integration 7 + Permissions 5 + Deploy 11 + Artifact System 22 + Stream+DeepLinks 29 + Share 54;Harness VNC 63 + Artifacts 168;Control Plane VNC Proxy 18。
结论:Myrm 的分屏流媒体能力全面超越 Marvis。实时视频流方面(noVNC),两者持平;但 Myrm 额外提供 DOM 元素级检查器(BrowserLiveView + DesktopLiveView)、Browser Takeover 人机协作(Agent 暂停让用户操作,完成后自动恢复并学习)、云沙箱+本地双模式、macOS 权限自动引导等独有能力。
vs Claude Office Visualizer — CLI 状态仪表盘
Claude Office Visualizer 用像素风办公室动画渲染 Claude Code CLI 状态,通过独立 Next.js + PixiJS 应用展示 Agent 状态、上下文用量与任务进度。解决 CLI 用户不盯终端就看不见 Agent 在干啥的痛点。Claude Office 做得好的地方
- Visual agent metaphor — pixel characters that walk, think, and interact based on real CLI state
- 12 whiteboard modes — multiple visualization layouts for different data views
- Tour overlay — 7-step interactive guide for new users
- Attention system — screen flash notifications when the agent needs user input
- Docker deployment — easy self-hosted setup
为何 Myrm 不需要这个
Myrm 是 GUI 优先 应用。Claude Office Visualizer 要解决的「看不见 Agent 状态」「CLI 输出无聊」— 在 Myrm 架构中 不存在。从 Claude Office Visualizer 迁移
结论:5 项升级、1 项持平、0 项降级。用户从独立观察窗口进入数据精准、可交互、完整 Agent 平台的一体化 GUI。
vs Coze / 工作流平台 — 批量 LLM fan-out vs SubAgent 批量(2026-07)
工作流产品(含 Coze)常见 批量 LLM / fan-out 节点:同一 Prompt 模板 × N 条输入,Lite 调用,工作流级计费。 Myrm 刻意不提供 in-agentllm_map 原语。同质或异质批量任务统一走 delegate_task_tool(mode=batch|parallel) — 每一项启动 完整 SubAgent,自带沙箱、工具策略、预算守卫、批量预执行 GUI 成本审批(≥$0.50)、subagent_control_tool(cancel/steer/list)与审计链。
迁移收益:从 Coze 批量节点迁出、要做 真实运维级批量 的团队,获得可追踪、可审批、可恢复的作业,而非一张无法逐行排查的 fan-out 账单。
vs Coze 3.0 / Lobster / Vercel v0 — 产物部署与只读链接(Sites 2.0)
Coze 将项目锁在生态内;Lobster 擅长公开静态链但非从 Agent 工作区部署 Vercel;v0 面向用 AI 开发的开发者。Myrm 面向 希望从聊天产物获得可分享结果的 GUI 用户,非独立建站工具。
你将获得:聊天产物 → 落地页/报告/迷你应用 → ~30s 部署 URL 或 即时只读 Link 供审阅。
双路径发布 — GUI 零 Token + Agent 对话式:在 设置 → 托管目标 配置 Vercel、Cloudflare Pages、Netlify 或 Webhook,然后在 HTML 工件卡片点 Globe → 发布(零 LLM Token,服务端直发)或让 Agent 在对话中通过
artifact_publish tool 自动发布(说”给我链接”即可)。Agent tool 按需加载——未配置 hosting 时零 prompt-token 开销。Preflight 在出站前拦截不合格工件;每个 target 独立 publication 历史与过期重部署提示。Clawith 仍走 5 个 Agent 部署工具(永久 Token 开销);Myrm 仅在需要时加载(104+5 项 hosting pytest,3 项条件加载集成场景)。
测试覆盖(2026-07-29):109 项 hosting pytest(104 项模块测试 + 5 项新 artifact_publish 测试含 3 项条件加载集成场景),覆盖多 target CRUD、webhook 全链、SSRF、redeploy upsert、WebSocket 状态、凭证边界及 Agent tool factory;真实 DB/vault/preflight/orchestrator,仅在外部 provider HTTP egress 边界 mock。
不止部署——完整的产物编辑生命周期:Myrm 的 Artifact Portal 不只是查看器。代码产物在 Monaco Editor(VS Code 内核)中直接编辑。SelectionToolbar 支持选中代码后一键 修改 / 解释 / 优化 / 加注释——精准 AI 编辑无需离开预览面板。你的编辑会静默跟踪并自动注入到下条消息,Agent 从你修改后的版本继续工作。React 产物通过 Sandpack 实时渲染并热重载。版本 Diff 对比、SHA-256 完整性校验和快照回滚完善了整个生命周期。竞品如 WorkBuddy 依赖外部文档集成(如腾讯文档)而非自建编辑系统。
诚实限制:尚无分享撤销/分享码 UI;长期公开站点应用 Deploy + 自有域名;纯 code 产物须先导出为 html(预检 + UI 门控一致)。
vs Codex — MCP 生态、Agent 模板与多渠道自动化
Codex 近期展示了 Linear MCP 连接与自动化 PM 工作流。MyrmAgent 的架构在每个维度均已全面碾压——经 543 项测试验证。
关键结论:Codex 的 “Linear MCP” 只是连接了一个外部 MCP 服务器——MyrmAgent 早已支持且有完整 GUI、安全扫描和 27 个预置服务集成。“PM Agent” 工作流无需新的平台功能;MyrmAgent 现有的模板系统 + 渠道监听 + Kanban 管道已可一键实现。
vs Codex (OpenAI) — Appshots 与 /goal GA
Codex 近期发布两大旗舰功能:Appshots(⌘⌘ 窗口捕获 + 文本提取)与 /goal mode GA(长时间自主任务)。Myrm 对比如下:Appshots(窗口捕获 + 文本提取)
你将获得:Agent 要点桌面时,你能看到 位置 — 不仅是文字「批准?」。Tauri 上 系统级红框 在聊天窗口被挡时仍可见。macOS 和 Windows 用户均获得完整 Appshot 能力——所有竞品均无 Windows 窗口截屏 + 文本提取实现。
诚实限制:OS 叠加层冒烟需 Tauri 桌面端;仅浏览器 WebUI 有内联 + AttentionBar,无 OS 框。
/goal 模式
锁屏与远程
用户痛点(评论反馈)Myrm 已解决
结论:Codex 的 Appshots 与 /goal 是 Myrm 现有能力的简化子集。Myrm 覆盖 3 平台(vs 仅 Mac)、DAG 执行(vs 线性),并提供 Codex 完全缺失的企业级预算控制与完成验证。
Vibe Canvas — “指哪改哪”工件交互
你将获得:在工件预览中点击任意元素,Myrm 自动捕获精确 HTML 结构并附带你的指令发送给 Agent。无需截图、无需猜坐标——DOM 级精确”指哪改哪”。
浏览器扩展桥接 — 带身份认证的会话接管
你将获得:让 Agent 使用你真实的 Chrome 会话(Gmail、SaaS 应用、内部工具),精细的域名级控制,每个操作需要你的审批。实时状态显示扩展正在做什么。Myrm 不会批量读取 OS 级 Chrome/Edge
History.db 或书签数据库——已登录访问仅通过 Extension Bridge + 加密 Session Vault。
为什么 Myrm 不需要 Chrome Cookie 导入:OpenClaw 导入 Chrome 系统 cookie 是因为它没有持久化会话存储——每次启动浏览器都是全新的上下文。Myrm 的 SessionVault(AES-256-GCM)+ auto_restore_domains 从架构层面解决了这个问题:通过 takeover 认证一次 → 会话加密保存 → 之后每次访问自动恢复。支持所有认证方式(密码/2FA/扫码/OAuth),保存 cookies + localStorage(不仅仅是 cookies),全平台全部署模式可用(包括云托管),Chrome 更新 cookie 格式也无需维护。196 项相关测试通过。
vs 360 LobsterAI — 消费级 Agent 平台
360 LobsterAI 是消费级 Agent 产品(周鸿祎背书),主打手动模型档位、100+ 预设「专家龙虾」与「教练式」上手流程。成本智能
Agent 模板
多渠道接入
从 360 LobsterAI 迁移到 Myrm
从 360 LobsterAI 迁移的用户获得:- Automatic cost optimization — no need to manually select “lite” vs “full” mode
- Smarter routing — system learns preferences and improves over time
- 35+ channels vs 3-4, with per-channel agent binding
- Enterprise security — 6-layer defense vs consumer-grade
- Unlimited extensibility — Skill Marketplace + custom agents vs fixed presets
- Full data ownership — self-hosted option, no vendor lock-in
智能多平台分发与桌面下载(vs Hermes / OpenClaw / Cursor)
分发桌面 Agent 时,竞品常让用户去 GitHub Releases 自助找包,或逼用户分辨 CPU 架构;CI 竞态还会导致更新清单损坏。 Myrm(v0.1.39 生产验证)提供 消费级下载 + 生产 OTA + 诚实发版契约:
结论:迁移用户首日安装从「懂 GitHub」变成「点下载」——这是普通用户愿不愿意试用的分水岭。
本地迁移向导(v1.4)
Myrm 在 Local 与 Tauri 部署提供 GUI 优先竞品迁移向导,支持 14 种竞品适配器(12 种 ready),自动发现 + MCP 配置自动转换 + 模型自动映射 + 完整 dry-run/confirm/rollback 生命周期。八个发现源(Local / Tauri)
四条预览通道
- Persona → Agent — SOUL-style instructions attach to a target agent profile.
- 事实 → 全局记忆 — 结构化记忆行,支持批量 回滚。
- Skills → Review queue — imported skills require approval before activation; optional Agent binding.
- API keys → Opt-in — never silently copied; user confirms each secret.
工作流
Scan → Preview (dry-run) → Confirm → Result in Settings → Migration. Server-side resolve_competitor_import_source() forces the correct adapter (fixes OpenClaw source=auto mis-routing to Hermes).
GUI 优先无缝技能迁移与原子持久化
用户导入第三方生态技能包(如 Hermes ZIP)时,竞品常依赖基础文件覆盖(os.replace)与顺序数据库写入。SaaS 高并发下会导致灾难性「分裂脑」(DB 有记录但文件缺失)或 API 冻结。
Myrm 提供 零成本热迁移与原子持久化引擎:
结论:50 用户同时上传技能 ZIP 时竞品服务易崩溃或泄漏线程。Myrm 大规模并发导入 0ms 阻塞主线程、零脏写风险。
vs Hermes claw migrate
诚实评分:本地八源 GUI 迁移 9.7/10 — 非「覆盖每个竞品工件」。SaaS 云沙箱不可用(无法访问用户主机文件系统);请用 Local WebUI 或 Tauri 桌面端。
实跑验证(2026-06-08)
开发机最小批量回归(合计约 7 秒):
迁移系统专项测试合计:276 项全部通过(2026-07-25,含 14 种竞品适配器/dry-run 会话/导入适配器/MCP 配置转换器/模型迁移/架构守门/多竞品发现/E2E/API/技能批量导入全链路)。竞品(OpenClaw、Hermes、DeerFlow、CodePilot、LobsterAI、CoPaw、jiuwenclaw、PilotDeck、Grok Build):无 GUI 14 源迁移向导 + MCP 自动转换;Hermes 仅有 CLI
claw migrate;Grok Build 仅支持 2 种源(Claude + Cursor)的 TUI modal。
迁移后你将获得(面向用户)
- 保留人格与习惯 — SOUL 式指令落在你选的 Agent 配置,非一刀切默认。
- 保留结构化记忆 — 事实与会话导入支持批量回滚。
- 技能可控 — 导入技能进审核队列,你批准并绑定到正确 Agent。
- 保留技能使用历史 — 调用次数、最后使用时间、Pin 状态、生命周期状态自动从 Hermes
.usage.json导入。常用技能保持高优先级,Pin 技能保持固定,无冷启动重新积累期。 - 迁移前看清账单 — 预览阶段自动展示 Token 经济学对比卡:竞品全量注入 vs Myrm 按需加载,典型节省 94%(如 15 个技能:7,500 → 450 tokens/轮)。
- 无静默偷 Key — API Key 仅在你逐通道 opt-in 时导入。
- 诚实后续 — MCP 与消息渠道在设置中引导(不宣称与 Hermes CLI 提示一键渠道对等)。
选择 Myrm 你将获得
永不丢上下文
42+ 模块记忆系统 — 业内最完整的 AMO 实现。8 类记忆、7 信号检索融合、7 层陈旧防御、跨会话整合与一键回滚。Anthropic Dreaming 与 Mem0 部分覆盖的能力,Myrm 端到端交付。
随处工作
通过 35+ 消息渠道,在任何设备上审批任务、引导 Agent、监控进度。
智能工具使用
三层工具分层 + 按需加载 + 三维健康监控 + 14 类错误诊断与专家修复建议。工具精准选用、高效执行、失败自愈。
企业级安全
六层纵深防御:预算控制、PII 保护、污点追踪与审计追踪。
零厂商锁定
100+ 模型,自托管或云端。数据始终归你。
vs WeSight — 桌面 AI Agent 控制台
WeSight 是一款近期开源的桌面端 Agent 管理台,主打聚合本地不同的 Agent 引擎(Claude Code, Codex, Hermes 等)及飞书集成。但由于其强依赖 macOS 终端特性和较重的可视化噱头(如 3D 办公室宠物),在实际重度生产环境下面临极大的瓶颈。 Myrm 从底层架构上彻底碾压了这些痛点,让用户能毫无顾虑地迁移:Myrm 的领先之处
一句话总结:从 WeSight 迁移,你将获得一个全平台支持的专业级 AI 工作站,同时所有历史 Agent 的配置文件、设定的模型 API Key,均可通过 Myrm 的“八源导入向导”秒级恢复,真正的“带资入驻”。
vs OpenClaw 2026.6.1 — 跨越”能用”到”好用”的终极形态
OpenClaw 2026.6.1 是其重磅更新,主打 Windows 原生节点、技能工坊、工作看板以及稳定性修复。然而,从其官方发布和大量用户社区反馈来看,其依然面临着”更新即崩”(如飞书/QQ断连)、任务缺乏直观可视化干预、以及”缝合感”较强的痛点。 Myrm 在架构和体验设计上实现了降维打击:Myrm 的领先之处
一句话总结:从 OpenClaw 迁移到 Myrm,你将告别”修一天跑一小时”的极客折腾期,获得一个拥有全天候健壮队列、极致 UI/UX 细节以及跨端原生体验的企业级 AI 工作站。
实时语音对讲(Realtime Voice & Multimodal Talk)
OpenClaw 拥有成熟的语音架构(多传输层、插件化提供商、电话集成),但 Myrm 在用户实际体验和成本维度实现了超越:
关键数据:1,176 项语音相关测试全部通过(语音核心 632 + Discord Voice 全栈 485 + Channel Security 59),覆盖 Realtime API / TTS 5 提供商 / STT 5 提供商 / WebSocket 全双工 / Barge-in / Agent Bridge / Vision 融合 / Discord Wake Word / VoiceReceiver DAVE 加密 / VoiceFollowManager 自动跟随。
vs DeerFlow — 彻底告别大模型崩溃死循环
DeerFlow 作为一个优秀的开源智能体框架,在健壮性处理上遇到了典型的业界难题:大模型极易因为长日志和异常输出引发死循环崩溃。Myrm 将 DeerFlow 暴露出的核心痛点转化为原生中间件级别的降维打击解决方案。工具调用安全网(Tool Calling Safety Net)
无论是使用 LangChain 还是原生 API,执行长线任务时极易遭遇致命的崩溃死循环。Myrm 实现了免人工干预的 100% 自动容错:
用户感知收益:当别的 Agent 跑到一半因为“日志太长”或“JSON 残缺”而崩溃挂起时,Myrm 会自动截取超长日志存入本地文件,并用一段礼貌的提示语告诉大模型:“输出过长已落盘,请使用读文件工具查看某某路径”。它永远能优雅地处理各种边界崩溃。
智能记忆检索(Context-Aware TF-IDF Memory Retrieval)
在注入长期记忆时,普通框架会盲目按时间或事实置信度排序,导致上下文被大量“高置信度但与当前任务完全无关”的噪音记忆占满,反而忘记了核心指令。 Myrm 引入了 TF-IDF 与置信度双重加权检索:在注水前,先利用tiktoken 提取当前对话最近几轮作为 current_context,计算所有记忆与该上下文的余弦相似度,并结合事实的置信度进行双端加权评分(similarity*0.6 + confidence*0.4)。
用户感知收益:如果你积累了数百条记忆,迁移到 Myrm 后绝不会体验到因为“记得太多而变笨”的痛点。我们在极低的 Token 预算内提供“最精准”的记忆召回。
智能防泄漏与零卡顿的标题生成 (O(1) Anti-Blocking Title Generation)
当用户粘贴超大日志或代码块时,后台生成标题的正则清洗往往会卡死整个服务器(Event Loop Blocking);此外,廉价模型生成的标题经常带有Title: 等废话前缀,且容易暴露 API Key 等敏感信息。
Myrm 在底层实现了 O(1) 早期截断与军工级脱敏管线:
用户感知收益:哪怕你粘贴了 1MB 的错误日志,Myrm 也能瞬间为你生成一个安全、精准、无废话前缀的标题,且整个过程对服务器性能零冲击。细节体验 100% 碾压竞品。
深度研究与长程任务挂机(Deep Research & Offline Guardian)
DeerFlow 1.x 作为专业 Deep Research 框架广受好评,但 2.0 已完全重写为通用 Agent Harness(README 明确说”shares no code with v1”),原深度研究能力仅在 1.x 分支维护。Myrm 提供了完整的深度研究引擎与军工级长任务挂机保障:
用户感知收益:你可以发起一个数小时的深度研究任务后安心关闭浏览器甚至合上笔记本——Myrm 会自动阻止系统休眠、将任务状态持久化到数据库。即使服务器意外重启,Myrm 也会自动恢复中断的任务并在完成后推送系统通知。研究开始前,你的 Wiki 知识库会被自动检索,已有知识不再重复搜索,直接节省 token 费用;旧报告会自动入库并在后续研究中复用和验证,确保知识不断迭代更新。研究成果通过三层机制确保不丢失:同会话内直接可见,跨会话通过 Wiki 自动归档并被后续研究召回,普通对话中 AI 也能通过记忆检索工具访问历史研究。对比类查询(如”React vs Vue”)自动按统一维度规划研究步骤并在报告中生成汇总对比表。研究过程中,每轮研究的实时成本和预算使用情况都在 UI 上清晰可见。这种级别的深度研究能力与长任务可靠性,在所有竞品中独一无二。(9,487 项相关测试全部通过)
长文阅读(自动目录)
当 Agent 回复含多个标题时,Myrm 会在消息旁 自动生成目录 — 点击章节跳转,滚动时高亮跟随。ChatGPT、Hermes、OpenClaw 均无等价的聊天内多章节导航;用户通常需复制到 Notion 或 Word 才能获得大纲。多 Agent 编排与零信任验证(vs Hermes Agent / Claude Code)
在多 Agent 架构领域,多数框架依赖盲信与非确定性 LLM 即兴发挥。Myrm 打破串行瓶颈,彻底消除 Hermes、Claude Code 等竞品中的「幻觉式成功」与「预算烧穿」痛点。Myrm 的领先之处
迁移收益
从 Hermes 或 Claude Code Dynamic Workflows 迁移,你将获得:- 绝对成本可预测:Agent 死循环不会让你醒来面对巨额 API 账单。
- 真实执行证据:Myrm 称任务完成时,有 OS 级执行日志支撑,非 LLM 想象。
- 无瑕 UI 体验:后台 Agent 严格留后台;人工介入可注入纠正语境,非二元是/否。
视觉审批、Artifact 全链路与智能模板复用(vs Codex)
Codex 仅提供基础截图审批,无 Artifact 管理。Myrm 提供跨 Web、桌面、移动端的完整视觉审批系统,以及从生成到部署的完整 Artifact 生命周期管理——经 347 项成果物交付专项测试验证(harness 注册/Vault 137 + server 处理 105 + 前端 Portal 105)。零点击交付链路:Agent 生成文件 → ArtifactRegistry 自动注册去重 → SSE 事件 → Portal 自动弹出预览(竞品仅调用 OS Open 打开文件,无版本管理、无发布、仅限桌面端)。Myrm 更强在哪
迁移收益
从 Codex 切换到 Myrm Agent 后:- 多端视觉审批:从基础截图升级为 Web 内联高亮、Tauri OS 覆盖层和移动端手势交互
- Artifact 成为永久资产:完整版本管理 + SHA256 防篡改验证 + 一键 Vercel 部署
- Agent 学习你的风格:无需手动保存模板,Agent 自动学习你偏好的报表格式和编码模式
- 精准协作:在 Artifact Portal 中选中任意代码,直接触发修改/解释/优化/注释与 Agent 协作
顶级智能体架构拆解对比(“Agent Harness 解析”)
在最近的业界深度解析中,Agent Harness(包裹 LLM 的完整软件基础设施)被确认为 Agent 性能的决定性因素。通过与前沿理论和竞品实现对比,Myrm 的架构在以下关键领域展现出降维打击的优势:Myrm 的领先之处
迁移收益
从依赖简单 ReAct 循环和基础记忆的竞品迁移,你将获得:- 永远不会迷失在长文档中间:智能预览和按需挂载机制保证了模型始终关注高信号 Token。
- 不再为空转烧钱买单:一旦 AI 迷路卡死,立即挂起执行,在用户终端弹窗“请求指示或代填参数”。
- 工程级别的可靠交付:代码没跑过 lint 就不准“声称已完成”,告别“幻觉式成功”。
长程任务自动化编排 (vs Codex 等半人工工作流)
许多开发者在使用大模型处理包含数十个文件、需要多天迭代的长程重构任务时,往往求助于类似 Codex 的“人工约束工作流”——手工拆解子任务,手工建.codex-work/tasks/*.md 文件夹,甚至手写交接文档 handoff.md。
这种半人工模式虽然能在一定程度上防止大模型的上下文污染(Context Pollution),但这绝不应该是终端用户的负担。Myrm 将这种“极客的手工作坊”彻底升级为了自动化的基础设施:
Myrm 的领先之处
结论:迁移到 Myrm,你将彻底解放双手,告别为了“防模型变傻”而强加给自己的人为流程。让机器去做机器该做的编排。
准备开始?
快速开始
2 分钟内完成上手。
本地部署
在你自己的基础设施上自托管 Myrm。
记忆系统:告别臃肿与幻觉,真正“懂你”的 AI
许多竞品(如 Mem0、Hermes 或 Supermemory)在记忆系统上存在显著痛点:要么提取过多导致记忆库臃肿、检索准确率下降;要么只存摘要导致精确信息丢失;要么必须依赖云端服务。Myrm 的记忆系统在架构上实现了全面超越:- 严格精度门控 (No-Op Default):我们拒绝像竞品那样“宁滥勿缺”地提取日常闲聊。Myrm 默认静默,仅在检测到高杠杆业务价值(如代码规范、架构偏好)时才提取入库,彻底解决记忆臃肿与 AI 幻觉问题。
- 原文无损保留 (Verbatim Storage):采用双轨存储,不仅保留用于语义检索的摘要,更 100% 无损保留原始对话和代码片段。当你需要精确数字或代码时,Myrm 绝不含糊。
- 异步画像投影 (Cognitive Deriver):无需你刻意调教,Agent 会在后台静默分析你的沟通风格、决策逻辑,并实时投影到下一次对话中,实现“零延迟”的默契。
- 物理级无痕模式 (Incognito Mode):独家支持阅后即焚,底层记忆引擎彻底卸载,确保敏感项目数据绝对零泄漏。
- 全景可视化与零配置:提供豪华的记忆指挥中心 GUI,打破黑盒;且内置 SQLite+Qdrant,无需配置 Docker 或 API Key,断网 100% 可用。
- 记忆冲突自动裁决 (Conflict Arbitration):当 AI 学到的新知识与已有记忆矛盾时,自动检测并路由至用户裁决(保留旧值 / 采用新值 / 自由编辑合并 / 双弃),72h 未处理安全降级保留旧值。竞品 Cognee/Mem0 静默覆盖导致用户无感知——56 项验证测试确认
🆚 Tokeny 等「桌面化零配置」Agent 对比
Tokeny 等产品针对 OpenClaw/Hermes 的痛点,主打“免部署、免配置、自备 Key”。但这种“套壳应用”在灵活性与安全性上依然存在明显短板。Myrm 实现了降维打击:从 Tokeny 迁移的 5 个理由
- 更极致的开箱即用:Tokeny 依然要求用户具备申请 API Key 的认知。Myrm 提供开箱即用的 Cloud Work Units 额度,点开即用。
- 安全与自动化的兼得:桌面 Agent 缺乏底层沙箱,导致高阶用户不敢放手让 AI 写文件、跑脚本。Myrm 独立的环境隔离让你真正拥有安全的赛博员工。
- 更智能的防 Token 刺客:Myrm 的 ComplexityRouter 能根据单次对话复杂度智能分配大小模型,配合六层缓存,成本降低一个数量级。
- 全端在线的无缝流转:从家里的 Tauri 桌面端,无缝流转到手机浏览器的 PWA,工作不因离开电脑而中断。
- 统一生态网关:内置四合一网关,避免因单个第三方插件不可用而导致整个工作流停滞。
🆚 Ryan Agent Work Kit — 文本约束 vs 架构级全栈碾压
《Ryan Agent Work Kit》是一个倡导通过纯文本文件(如AGENTS.md)和 bash 脚本拼接来构建 AI Agent 工作流的“套件”。其本质是为了填补纯文本、无界面(CLI)工具的架构缺陷而打的“补丁”。
MyrmAgent 作为一个拥有完整 GUI、底层支持多层安全/调度协议、采用 Agent-in-Sandbox 架构的现代化工作空间,对其形成了降维碾压。
MyrmAgent 的领先之处
从 Ryan Work Kit 迁移的 5 个理由
- 从“拼凑脚本”到“开箱即用”:无需熟悉 Bash 和繁杂的文件结构树,Web/Tauri 桌面双端加持,真正做到安装即用。
- 从“文本约束”到“代码强制”:用底层的确定性代码逻辑替代不可靠的大模型 Prompt 文本约束(如危险命令拦截、死循环熔断等),100% 确保资产安全。
- 从“手动打点”到“全景可视化”:自动追踪所有 Token、开销与工作流节点(DAG),直接生成数据面板,让 Agent 动作完全透明化。
- 内置化、内生化的企业级记忆:抛弃繁琐的外挂 Obsidian 同步脚本,内置的 Qdrant 向量库加上双层智能遗忘(5维保留分 + LLM语义过期审查),让你拥有最流畅的认知记忆体验。
- 生态开放自由:不仅不受限于单一 Github 仓库的更新,更能连接包含 ClawHub 在内的多个插件市场,且支持完全无外网离线安装。
长程任务极限UX与工程深度 (vs Claude Code / OpenClaw)
在长时间运行的重型任务(重构、数据爬取等)中,竞品往往存在报告刷屏、卡验证码死锁、虚拟隔离导致写冲突等痛点。Myrm 提供了碾压级的基础设施:
迁移体验: 告别对着黑框狂闪日志的担惊受怕。你将获得所见即所得的状态大盘与防破产保护,让长程任务安全放在后台运行,体验降维打击。
vs. DeerFlow 2.0: 从 Framework 到真正的 Industrial Harness
DeerFlow 2.0 提出了 14 层中间件链和 Docker 沙箱,但其架构严重依赖云原生微服务(强制要求独立的 LangGraph Server 集群),在本地和桌面端部署时极为臃肿。 为什么从 DeerFlow 2.0 迁移到 MyrmAgent?- 17+ 层超细粒度 Middleware 内核:我们实现了更细粒度的 17+ 层严格有序中间件链,并引入静态依赖注入图(DI Graph)校验,彻底杜绝隐式依赖导致的 Bug,稳定性降维打击。
- 真正的 Agent-in-Sandbox:DeerFlow 在 Agent 内部创建沙箱属于架构越界。我们采用多态沙箱驱动,由外部调度层(Server/Tauri)提供隔离。在 Local 和 Tauri 桌面端,你无需启动沉重的 Docker 即可获得极致的安全与性能。
- ArtifactVault 零拷贝共享:面对海量并发的子 Agent 协作,我们独创
vault://指针协议,大文件落盘后仅交换指针,实现“零拷贝”,彻底解决大模型上下文爆炸和数据越权问题。 - 安全纵深的 Markdown 技能生态:同样是零代码的 Markdown 技能定义,我们额外内置了三层防御体系(信任衰减 + 安全扫描 + 内容转义),确保你运行任何社区第三方技能时,宿主机和敏感数据绝对安全。
vs Hermes / DeerFlow / OpenClaw / Cursor — 三平面任务进度(TSM v1.5)
多数 Agent 把 todo/plan 工具默认挂进 Turn 1,既膨胀 prompt,又无法在模型想早退时真正拦住。Myrm 将进度收敛为 Planning(todo_write)+ Kanban 两个 opt-in 平面,且默认全关(Turn1 近似零 Token 税):
用户收益:只在 3+ 步任务时打开 Planning——聊天里实时看 todo 树,Goal 长任务自动启用,断线重连后沙箱与 Guard 仍对齐,且不为没用到的工具每轮多付 Token。
验证(2026-07-03):harness progress + todo 条件加载 38/38 + server planning 集成 24/24(1 skipped) + live LLM E2E 3/3(含 resume 续聊更新 todo)+ frontend
tasksStepsMerge 5/5;修复 task_workspace_root 传递与 workspace_todos_exist 误判两个生产 Bug。产品 WebUI 已移除 @playwright/test 无头 CI,UI 集成走 真实 Chrome MCP + API prepare 脚本。
2026 最新核心优势总结 (对标 Hermes, OpenClaw, DeerFlow 等)
在众多开源 AI Agent 框架和产品中,Myrm Agent 凭借其底层架构的鲁棒性、极致的用户体验以及企业级的安全隔离脱颖而出:1. 永不崩溃的底层自愈机制
在使用兼容 OpenAI 格式的 API 时,网络抖动或用户频繁取消往往会导致工具调用中断,历史记录残留无效的tool_call_id,进而引发模型严格校验报错崩溃。
我们的优势:Myrm Agent 在框架最底层实现了透明的自愈机制(SafetyWrappedChatModel)。在每次向大模型发起请求前,系统会自动扫描并清理孤儿/无效的工具调用。无论网络如何抖动,对话历史永远保持纯净。彻底告别因格式错误导致的崩溃,鲁棒性远超竞品。
2. 独创的四级渐进式技能加载
为 Agent 配置大量技能通常会导致上下文窗口急剧膨胀,增加 Token 消耗并降低模型遵循指令的能力。 我们的优势:独创的四级渐进式加载策略,仅在真正需要时才将技能正文加载到上下文中,实现极低的 Token 消耗。支持/slash 斜杠命令精确激活特定技能,将 Agent 的自主性与用户的精确控制完美结合。
3. Serverless 级沙箱休眠与秒级唤醒
传统的云端部署如果为每个用户保持一个常驻的沙箱实例,成本将极其高昂。 我们的优势:控制平面原生支持沙箱环境的空闲挂起与按需唤醒。用户离线时,100% 物理隔离的专属沙箱状态会被持久化并休眠;当收到新消息或定时任务触发时,瞬间唤醒。在保证隐私绝对安全的同时,极大降低了云端闲置成本。4. 图表能力不臃肿
多数竞品内置沉重白板或只能手动排版;Myrm 把图表留在对话内,白板走 MCP 扩展。 我们的优势:Mermaid 工件 + render_ui(A2UI v3.1) 覆盖大多数场景。可编辑白板通过 Excalidraw/tldraw MCP 接入(与 Goose/Codex 插件同路线),核心零维护。5. 极致的全渠道 IM 覆盖
许多竞品仅支持少数几个主流渠道,且不同渠道间的消息格式、媒体处理能力参差不齐。 我们的优势:原生支持 15+ 种渠道(Slack, Discord, Feishu, iMessage, WeChat, Telegram 等),真正做到“无处不在”。底层统一的媒体处理管道,确保无论在哪个平台,都能获得一致的 Markdown 渲染与交互体验。6. 自然语言驱动的无人值守调度
绝大多数 Agent 只能作为“被动响应工具”,必须由用户主动触发才能工作。 我们的优势:内置强大的无人值守调度引擎。只需自然语言一句话(如“每天早上8点发简报”),Agent 即可化身主动工作的数字员工。支持 Webhook 推送和全渠道触达,从被动工具进化为主动服务。7. 记忆去重与永远精简的大脑
在长期的多轮对话中,Agent 容易积累大量重复的事实,导致记忆库臃肿,检索精度断崖式下降。 我们的优势:底层的dedup_semantics 机制在写入时严格过滤重复事实(相似度 ≥0.95 自动去重)。保持记忆库永远精简高效,确保 Agent “越用越懂你”的同时,绝不臃肿。
8. 拒绝静默失败的全链路反馈
批量操作无进度条、网络异常静默失败、文件“零引用”直接删除……这些都是竞品中常见的导致用户极度焦虑的设计。 我们的优势:全链路的 UI 进度反馈、明确的异常 Toast 提示与重试机制,任何跳出当前上下文的操作都有强视觉反馈。同时内置文件系统的“回收站”软删除机制,彻底消除数据丢失焦虑,提供真正的企业级安全感。9. 行级并行文件冲突防护
当多个子代理同时编辑同一代码库时,文件冲突可能悄无声息地损坏代码。AWS 使用粗粒度的文件路径级互斥波次;OpenAI Codex 完全没有应用层保护。 我们的优势:三层纵深防御——L1 行级冲突检测(check_conflict_pre_write)精确阻断重叠行编辑并给出行范围信息;L2 FileActivityTracker 记录每个代理的写入行范围;L3 apply_parallel_write_isolation 检测到多写者时自动切换 ISOLATED_COPY 工作空间 + 延迟合并。同文件非重叠区域可并发写入(吞吐量比 AWS 方案翻倍)。任务完成时自动清理——零内存泄漏。1,199 项测试验证通过,0 失败。