Muse / M.U.S.E 源码分析¶
名称说明：
Muse不是唯一项目。本页主分析 A-C-I-SOFTWARE-AND-DEVELOPMENT/M.U.S.E 这一开源、自我改进 Agent；Meta 的 Muse 产品或其他muse-agent仓库不与此页面混同。研究快照：2026-09-26。
它是什么¶
M.U.S.E 的定位不是普通终端 coding CLI，而是一个“任务图 + specialist worker + peer reviewer + 多渠道发布”的长任务 Agent。官方文档描述的目标从收件箱摘要到审计仓库并开 draft PR，最终产物可以是 PR、报告、Telegram 消息或手机通知。
源码和文档入口¶
| 入口 | 内容 | 阅读重点 |
|---|---|---|
docs/README.md |
人类操作手册 | 运行方式、任务类型和交付渠道 |
AGENTS.md |
给 coding agent 的开发约束 | 项目如何约束自身迭代 |
profile/ |
用户画像和历史模式 | 记忆如何影响任务执行 |
skills/ 或 skill docs |
按需加载的工作方法 | skill 是 prompt 还是可执行代码 |
| task/graph worker | 任务拆解与调度 | 重试、依赖、并发、停止条件 |
| reviewer/publisher | 评审与外部发布 | 谁能批准、哪些结果能出系统 |
由于 Muse 项目和同名产品较多，每次研究必须保存仓库 URL、commit 和所属组织；不要只写“muse vX”。
运行时模型¶
自然语言目标
-> 任务图 / 小任务拆分
-> specialist worker（模型 + 工具 + 环境）
-> worker 结果校验
-> peer reviewer
-> 汇总 / 发布器
-> PR、报告、消息或通知
这类系统把“单次回答”转成“可交付结果”。难点不在于多叫几个 Agent，而在于任务依赖、证据、审批、失败恢复和输出渠道的一致性。
自我改进循环¶
官方手册强调 skills 可以按需加载，复杂任务完成后 Agent 还可以创建新 skill。这是强能力，也是风险：
| 能力 | 价值 | 风险控制 |
|---|---|---|
| 从任务中归纳 skill | 把一次成功经验复用 | 新 skill 先进入 review/staging，不直接全局生效 |
| 用户画像 | 减少重复沟通，调整输出风格 | 明确来源、纠错、删除和租户隔离 |
| specialist 分工 | 对研究、代码、审核使用不同模型/工具 | 固定角色权限，防止 worker 获得超出目标的能力 |
| peer review | 在发布前增加第二道检查 | reviewer 与执行者不能共享全部盲区，需校准集 |
适用条件、代价、验证¶
适用条件¶
任务跨越多个步骤、需要研究与执行结合、最终结果要发布到 PR/报告/通知，并且组织愿意管理长任务状态。
代价¶
任务图、worker、reviewer 和 publisher 会放大 token、工具调用、存储和失败恢复成本。没有预算和停止条件时，长任务可能在错误方向上持续消耗。
验证方式¶
- 选择一个 30 分钟内可完成的真实任务，记录每个节点输入、输出、工具和 reviewer 结论。
- 注入一个 worker 失败、一个 reviewer 拒绝和一个外部发布失败。
- 验证任务是否从失败节点恢复，而不是重复所有副作用。
- 把最终成果与人工流程比较：完成时间、返工、严重错误、成本和采用率。
FDE 结论¶
Muse 类系统的研究价值在于 长任务控制面，而不是“多 Agent 越多越好”。建议借鉴其任务图、review gate 和 publisher 思路，但把自我改进限定为候选 skill，所有写入和外部发布都经过 policy engine。对高风险业务，planner -> executor -> reviewer -> publisher 比完全自治更容易验收和回滚。