https://caozuohua.github.io/tags/openclaw/Recent content in OpenClaw on CAO ZUOHUAHugozh-cnThu, 01 Oct 2026 08:10:00 +0800https://caozuohua.github.io/posts/2026-10-01-meta-muse-agent-teardown/Thu, 01 Oct 2026 08:10:00 +0800https://caozuohua.github.io/posts/2026-10-01-meta-muse-agent-teardown/<h1 id="meta-muse-拆解消费级-agent-的玩法全解与上线六周暴露的七个问题">Meta Muse 拆解：消费级 Agent 的玩法全解，与上线六周暴露的七个问题</h1> <blockquote> <p>2026 年 9 月 8 日，Meta 发布 Muse，自称「世界首个为所有人打造的个人 AI Agent」。六周之后，它交出的成绩单是双面的：美国日活约 60 万、专用硬件 Muse Charm 定档 12 月发货；同时它也比任何一个同类产品更快地踩中了地址外泄、零日漏洞、被电商平台封禁、被指抄袭开源框架这一整串问题。</p> <p>这篇文章不站队，只做一件事：把 Muse 的产品设计、技术架构和商业模式拆开，让你看清<strong>一个消费级 Agent 到底是怎么运转的</strong>，以及这套设计在哪里漏了风。</p> </blockquote> <h2 id="一30-秒结论">一、30 秒结论</h2> <ol> <li><strong>它是什么</strong>：一个「执行型」而非「对话型」的个人 Agent。用户告诉它要完成什么，它自己去开浏览器、填表单、发邮件、谈价格、下单付款；关掉 App 也继续跑，只在敏感动作前回来找你要授权。</li> <li><strong>最有价值的设计</strong>：<strong>Muse Secure VM + Sentinel 双 Agent 架构</strong>。每个用户独占一台云端虚拟机，另有一个系统级隔离的守门 Agent，Muse 的任何出网动作都要经它批准。这是目前消费级产品里对「Agent 越权」最认真的一次工程回应。</li> <li><strong>最有商业含义的动作</strong>：支付走 Stripe Link，且是<strong>第一个被 Link 购买保护覆盖的 AI Agent</strong>——虚拟一次性卡号、丢件/降价/退货有保。Meta 明确说长期变现靠<strong>交易抽佣</strong>，不是订阅费。</li> <li><strong>最能说明问题的部分</strong>：六周内的七个事故。它们不是孤立的运维失误，而是指向同一个结构性矛盾——<strong>给 Agent 的权限越大，可被诱导的路径就越多</strong>。</li> <li><strong>一个关键背景</strong>：Muse 的文件体系（<code>SOUL.md</code>、<code>memory</code>、<code>tools</code>）与开源 Agent 框架 OpenClaw 高度同源。理解这一点，才能理解它的安全边界是从哪来的。</li> </ol> <h2 id="二它到底能替用户做什么">二、它到底能替用户做什么</h2> <p>先交代一个容易被忽略的前提：Muse 由 Meta <strong>自研模型 Muse Spark 1.3</strong> 驱动（该版本 9 月 2 日发布，官方称其主打真实世界的 agentic 工作）。产品和模型共用「Muse」这一系列名，意味着 Meta 走的是<strong>自研模型 + 自研 Agent 的垂直整合</strong>路线——这一点与后文要对照的 Manus 恰好相反。</p>https://caozuohua.github.io/posts/2026-08-25-minimal-personal-agent-framework-evaluation/Tue, 25 Aug 2026 11:35:00 +0800https://caozuohua.github.io/posts/2026-08-25-minimal-personal-agent-framework-evaluation/<p>我曾经把个人助理的每一层都自己实现：Lark WebSocket、卡片、Agent Loop、Goal Runtime、记忆、定时任务、多模型 fallback、工具审批和多云 VPS 运维。</p> <p>这样做最大的收益是理解了边界，最大的代价也是边界——一旦通用 Agent 能力持续扩张，维护一个个人助手就会逐渐变成维护一个框架。</p> <p>更合理的方向是：</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>成熟 Agent 负责通用助理能力 </span></span><span style="display:flex;"><span>标准 MCP 负责专业工具 </span></span><span style="display:flex;"><span>服务端策略负责最终安全边界 </span></span></code></pre></div><p>但“成熟”和“轻量”不能只看项目介绍。这篇文章使用同一组需求评估 2026 年几类主流选择。</p> <h2 id="我的真实需求">我的真实需求</h2> <p>这不是通用 Agent 排行榜。目标环境是一台低资源 VPS，主要服务一个人：</p> <ul> <li>通过 Lark 私聊和群聊使用；</li> <li>处理问答、翻译、摘要、Idea、纪要和博客；</li> <li>保存少量长期偏好与会话历史；</li> <li>支持定时提醒和主动推送；</li> <li>通过 MCP 接入 GitHub、知识库和多云运维；</li> <li>模型不可用时，核心运维控制面仍然可查询；</li> <li>重启、备份、恢复和发布等动作必须人工批准；</li> <li>使用远程模型，不在小 VPS 上运行本地大模型。</li> </ul> <p>基于这些约束，我把候选分成两类：</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>成品助理：Hermes Agent / OpenClaw / nanobot </span></span><span style="display:flex;"><span>开发框架：OpenAI Agents SDK / PydanticAI / Agno / LangGraph </span></span></code></pre></div><p>成品助理的优势是少造渠道、记忆和调度；框架的优势是运行时可控，但应用外壳仍要自己写。</p> <h2 id="先定义成熟">先定义“成熟”</h2> <p>一个仓库更新频繁、Star 很多，不等于适合长期运行。我更关心：</p> <ol> <li>配置和升级有没有稳定入口；</li> <li>会话和任务能否在重启后恢复；</li> <li>渠道是否处理去重、重连和用户隔离；</li> <li>MCP 是否支持过滤、超时和失败降级；</li> <li>高风险工具是否有确定性权限边界；</li> <li>日志、健康检查、备份和回滚是否可操作；</li> <li>安全修复是否持续发布；</li> <li>能否关闭不需要的工具，而不是默认把整台主机交给模型。</li> </ol> <p>个人助理生态仍然变化很快。这里的“成熟”是相对成熟，不等于 systemd、SQLite 或 Ansible 那样经过多年稳定周期。</p>