先把我的邀请码放在这里：Code: 8XR45R
https://muse.ai/join
Muse太疯狂了，最高可领300亿；
加入 Muse 之后， 必须 48 小时内兑现别人的邀请码， 两个人各得 10 亿 token
就在 Muse 爆火后，一个名为 MuseAI-Skills 的非官方仓库出现了。仓库创建一天左右，我核验时已有 128 stars、49 forks。
先泼一盆冷水：
它不是 Muse 官方开源，也不是可以一键部署的安装包。
仓库自己写得很清楚：这是一份 Muse / Hatch 运行环境快照。核心程序主要是 Linux x86-64 二进制，完整源码、rootfs、宿主配置和部分构建资源并不在里面，当前无法独立启动。整个仓库也没有覆盖全部内容的统一开源许可证。
所以，如果你想“下载后在本地复刻一个 Muse”，大概率会失望。
但如果你正在写 Agent Skills、做工作流或研究个人 AI 助理，这个仓库很有参考价值。
因为真正稀缺的不是那几个二进制，而是它留下了 68 个独立 Skills、40 份连接器权限清单和 12 份行为评测文件。
这些文件把 Muse 的产品逻辑拆开给你看：一个 Agent 到底要怎样定义能力、申请权限、处理失败，并证明自己真的把事情做完了。
5个值得所有Agent思考的设计原则
1. Gmail：Agent 权限不能只有“允许”和“拒绝”
很多 Agent 接入邮箱时，只给用户一个粗暴选择：允许读取和写入。
Muse 的 Gmail 配置细得多。
读取邮件默认允许；发送邮件默认需要确认；创建草稿、标记已读、移入垃圾箱又有各自的规则；不同操作还对应不同的 OAuth 权限和调用成本。
这里最值得抄的不是 Gmail 命令，而是一种产品原则：
同一个工具里，查询、草拟、发送和删除，错误成本完全不同，不能共用一档权限。
我们平时说“给 Agent 最小权限”，很容易停在口号。这个 manifest 把最小权限落实到了每一种动作。
你在设计自己的 Agent 时，也可以把工具动作分成三档：
- 只读查询：默认可执行；
- 可撤回改动：执行后通知；
- 对外发送、付款、删除：执行前确认。
这比问一句“是否授权邮箱”更接近真实世界。
2. Artifact Testing：生成成功，不等于交付成功
仓库里的产物验收 Skill 有一句话很值钱：
交付物要以用户最终看到的样子重新渲染后检查，不能相信生成它的代码。
这条规则看起来朴素，实际能挡住大量 Agent 假完成：
- PDF 导出了，但文字被裁掉；
- PPT 生成了，但元素互相重叠；
- Excel 能打开，但公式没有重算；
- 网页构建成功，但还留着 TODO 和占位文字。
很多 Agent 的完成标准是“命令退出码为 0”。Muse 这套规则把完成标准往前推了一步：用户拿到的东西真的能用。
一个成熟 Agent 的核心能力，不只是会调用工具，而是知道拿什么证据证明任务完成。
如果你只从这个仓库抄一条规则，我建议就抄这一条。
3. Forget：真正的遗忘，不是删掉一条记忆
“忘掉这件事”是个人 Agent 迟早会遇到的需求。
最简单的做法，是从 memory 文件里删掉一行。但信息可能还存在于：
- 对话摘要；
- 用户偏好；
- 提醒和定时任务；
- 已创建或分享的内容；
- 后台流程下一次可能重新写回的来源。
Muse 的 Forget Skill 要求先盘点这些副本和回写路径，再告诉用户哪些能删、哪些不能删、哪些动作不可逆，得到确认后才执行。
这给所有记忆型 Agent 提了个醒：
记住，是写入问题；忘掉，是数据血缘问题。
你不知道一条信息复制到了哪里，就无法承诺自己真的忘了。
4. Wide Research：并行不是多开几个 Agent
现在很多多 Agent 演示，看起来很热闹：一次叫来十几个子 Agent，同时搜索、同时输出。
但真正麻烦的是，最后谁来对账？
Muse 的 Wide Research Skill 要求先统一输入和输出结构，再由一个协调者分发任务，最终必须报告：总数、成功数、失败数、结果、失败项和备注。
这套设计的重点不是“开得多”，而是“收得回来”。
如果原本有 50 个对象，只成功查到 43 个，最终答案必须把 43/50 和剩余缺口说清楚，而不是把 43 条结果排得很漂亮，让用户误以为全部完成。
这条同样适用于任何批量 Agent：覆盖率比阵仗重要。
5. Skill Creator：Skill 不是越长越专业
Muse 的 Skill Creator 要求每个 Skill 只解决一个清晰问题：
- 触发条件写进 description；
- 核心动作留在
SKILL.md； - 大段文档、案例和 schema 放进 references；
- 可重复的机械动作交给脚本；
- 命令、路径和认证流程必须与真实环境一致。
换成人话就是：Skill 不是一篇百科全书，而是一份能让 Agent 立刻开始工作的操作规程。
这也是很多 Skill 仓库最容易犯的错：塞进大量背景知识，看起来很完整，Agent 每次执行却要从头读一遍，既耗上下文，也找不到下一步。
为什么它值得推荐
Muse 的真正价值，不只是“能替你查邮件、订餐厅、盯退款”。
更重要的是，它把个人 Agent 拆成了几层可以管理的东西：
- Skill 定义什么时候做、怎样做；
- Manifest 限定能调用什么、哪些动作要确认；
- Eval 描述什么行为算正确；
- Runtime 负责隔离、执行和恢复；
- 交付规则要求拿结果证明完成。
这五层放在一起，才是一个能长期办事的 Agent。
反过来看，很多所谓 Agent 项目其实只有一层：给模型一段提示词，再接几个工具。演示时能跑，遇到权限、失败、重试、交付和遗忘就开始失控。
MuseAI-Skills对于muse设计机制的拆解，对于我们自己做Agent构建具有非常大的启发意义。
仓库很大，下载这些核心最重要
这个项目的定位是基于Muse的底层逻辑对其能力的skill化拆解，下载完整的仓库文件，并不意味着就可以替代官方Muse。
但是我上面提到到几个关键点，能在你自己构建agent的项目中，帮你提升Agent的使用体验。
如果你不想下载约 2GB 的完整文件，直接下载接入这几个skill最高效：
wide-research/SKILL.md，理解批量任务怎样对账；gmail/SKILL.md+manifest.yaml，理解工作流和权限怎样分层；artifacts/testing/SKILL.md，补齐交付验收；forget/SKILL.md，理解记忆系统最难的反向操作；PROJECT_ANALYSIS.md，确认哪些能力只是设计材料，哪些缺少动态验证。
项目地址：https://github.com/win4r/MuseAI-Skills
Muse 会不会长期占据个人 Agent 的入口，现在还不好说；但这个开源项目已经提供了一个更有价值的观察角度：Agent 的差距，正在从“会不会调用工具”，转向“能不能被放心地交付任务”。
#Muse #AIAgent #AgentSkills #效率工具 #人工智能