Muse 出来以后，我用着用着，心情变得有点复杂。
它想做的事情，和我过去两个月一直在搭的 Personal Agent 很像：围绕一个人长期工作，了解他的生活，连接他使用的数据和工具，再把事情真正做下去。
这种相似不只在“个人助理”四个字上。Meta 的公开介绍里，Muse 有自己的专属云端虚拟机和浏览器，可以在用户离开聊天窗口后继续工作。这让我很自然地想到自己的 ECS：Agent 需要一个持续运行的地方，存放状态、连接工具、等待任务，不必把所有事情挤在手机上的一轮对话里。Muse 官方介绍
当然，专属 VM 和我自己管理的 ECS 不是相同的产品，也不意味着有了服务器就能连接一切。真正接一个服务，仍然要处理接口、认证、权限和运行限制。但它们给我的感觉很接近：个人 Agent 有了一个可以持续工作的环境，能力就有机会随着使用慢慢长出来。
区别在于，我可以非常偏心。我需要什么，就先搭什么。自己的账本不顺手，就先接账本；开发一个新能力太费劲，就开始研究怎样把开发过程也交给 Agent。Muse 面向广泛用户，需要先把更多人都能用起来的能力和体验做好。这是我对两种产品路径的理解。
我的项目在 7 月已经开始，原仓库第一条提交是 7 月 23 日。8 月，我写过为什么决定把业余时间投入 Personal Agent，也写过一期交付的复盘。Muse 在 9 月 8 日公开发布。这只能说明我的探索早于它的公开发布，我不知道 Meta 的内部研发是怎样推进的，也不想拿自己的 Git 日期证明谁先想到这件事。
但即使理性上知道这些，看到一个大厂把相似方向做成产品，我还是很挫败。
最让我挫败的，是觉得自己提前看到、一直在投入的方向，最后还是由大厂的产品来定义了。
此前我已经写了几篇文章，试着讲清楚自己想要怎样的 Personal Agent，也在一个模块一个模块地把它做出来。等 Muse 出现，我却要反过来借它向别人解释：我一直在做的，大概就是这个方向。
自己的探索还在慢慢成形，一个大厂产品已经有机会成为大家理解这类产品的参照。那种难过，并不会因为一句“说明方向是对的”就消失。
于是，我决定把已有的工作尽快整理出来，开源。
Personal Agent 的公开仓库在这里，采用 MIT 许可证。
我其实并不了解开源社区，也没有预期社区会反过来帮我完成什么。我只是希望，把这套产品设计和架构放出来，能为“Agent 怎样真正服务一个人”提供一个具体案例，对这个方向的发展有一点帮助。
这次具体公开了什么
先把范围讲清楚，免得大家点进仓库，期待下载一个马上能用的 App。
这次公开的是项目代码和架构参考，主要有两条链路。
第一条是日常使用的 Personal Agent。iPhone 是交互入口，服务端运行 Agent，通过策略检查和 MCP 工具访问个人业务数据。聊天、Finance、会话与上下文管理已有实现，也有我原来单用户环境里的使用或验收记录。
第二条是自动化开发流程。它尝试把一个开发需求串成需求确认、PRD、技术方案、编码、验证、独立审查和交付。ECS 管理任务状态与授权，家里的 Mac mini 执行已经获准的开发步骤。它已有代码和局部实测，但完整的“手机提需求到开发交付”流程仍待验收。
仓库也包括架构说明、代码阅读入口、合成评测数据和验证说明。我保留了经过脱敏改写的 Git 历史，方便读者看它怎样逐步形成。清理历史后，提交标识会变化；真正希望留下的是开发过程，而不是做一个只有最终代码、看不到来路的新目录。
它还不是一个能直接部署的公开发行版。 我的个人数据、凭据、生产配置和完整运行环境不会一起公开；原来环境里跑通过的事情，也不能自动变成别人克隆仓库就能复现的承诺。哪些已实现、哪些有历史证据、哪些仍待验证，都放在验证说明里。
我主要借助 AI 编程工具完成这个项目。我负责需求、取舍、评审和验收，但不会因为仓库开源了，就把其中所有代码包装成最佳实践。里面仍然有冗长的实现、重复的抽象和可以简化的地方。欢迎具体指出来。
Muse 出来了，我为什么还会继续做
Personal Agent 本身就是我在 AI 上长期投入的 side project。我希望通过它提升对 AI、对 Agent 的理解，而亲手搭建，是这个目标里很重要的一部分。
不自己做，很多工程难题都只是听过的知识。你可以知道 Agent 需要上下文、需要工具、需要记忆，也可以在文章里谈权限、恢复和评测。但这些概念到了自己的系统里，到底在哪里出问题，要付出多少成本，又该怎样取舍，只有做下去才会变得具体。
例如，“外部调用可能失败”是一句话；账本可能已经写入、服务端却没有收到响应时，究竟该不该重试，是我必须面对的决定。“模型之间可以交叉审查”也是一句话；怎样让审查者重新检查需求，而不是沿着实现者的假设再走一遍，要在实际协作里一点点学。
Muse 可以给我一个已经做好的产品，却不能替我经历这些过程。即使它越来越好用，我继续做这个项目的理由仍然成立。
而且，我自己的需求还会继续往下挖。一个只服务我的系统，可以围绕我的账本、数据组织方式和使用习惯反复调整。我不用先证明这些需求适合很多人，才决定值不值得做。
我已经开始在 Muse 上做同样的事情。目前，账单、日历和知识库都已经联通了，而且非常快。对比自己之前哼哧哼哧写代码、接服务的过程，那种速度差距非常直观。
这让我更清楚地看到，单论把这些工具接起来，Muse 已经替我省掉了很多工作。我很乐意用上这种便利，也会继续把自己的其他工具逐一搭过去，让两边面对同样的个人需求，比较实际使用的效果。
但我还是会继续做自己的 Personal Agent。接通工具的速度差距是真实的；亲手搭建时遇到的问题、形成的理解，以及继续深挖自己需求的空间，对我也同样有价值。接下来，这两套系统都会成为我的实践对象。
开源有一张清单，做项目却不断改变我的判断
单看发布动作，开源是一组相对明确的工程任务：脱敏，整理许可证和说明，创建公开仓库，检查历史和打包产物，再考虑以后私有开发怎样同步到公开版本。
这不代表随手删掉几个配置文件就够了。这次我们确实又在历史和合成案例里发现过需要继续清理的残留。以后也不能把私人仓库直接推过来，当作公开版更新。后续同步需要持续经过脱敏与检查，我不想在这里把它说成已经完成的一套自动流水线。
不过，这些事情的目标相对清楚。真正让我想写下来的，是做项目时那些原先没有、后来不得不形成的判断。
从第一天起，我就打算真的用它
我一开始就没打算把 Personal Agent 做成演示完可以关掉的项目。
它会接触自己的数据，会写入账本，也会在我不盯着的时候运行。既然我准备依赖它，就要提前考虑：电脑关了怎么办，服务重启了怎么办，数据坏了怎么办，一次操作没有收到结果又该怎么办。
所以我从一开始就决定用一台持续在线的 ECS，把服务端放在那里。手机负责交互，高权限凭据、运行状态和业务工具留在服务端。接下来，服务身份、基本安全、备份和恢复演练也成了项目的一部分。
这些东西不太容易出现在一张漂亮的产品截图里，却决定了我敢不敢真的用它。
备份就是一个很具体的例子。最初一版验证脚本能列出备份目录，于是报告通过；实际负责备份的用户却没有权限打开里面的文件。检查证明了“目录存在”，没有证明“备份能读到数据”。后来还要在另一台 Mac 上拉回备份、解密、检查数据库，并通过专用只读入口验证恢复结果。
这段经历在一期复盘里写得更细。现在回头看，它改变的是我问问题的方式：从“有没有做备份”，变成“机器真的没了以后，我拿什么恢复，恢复出来又怎么知道是对的”。
我并不懂其中所有工程细节。很多时候，AI 比我更熟悉具体工具和配置。我能负责的，是坚持要求它把结果证明到我准备依赖的那一步。
所谓尽可能精简，也开始有了更明确的尺度：可以少做一个暂时用不上的功能，但不能因为只服务我一个人，就跳过数据丢了以后怎么办。
我开始要求，写代码的人不能自己宣布过关
最开始，我就是用 Claude Code 订阅写代码。描述需求，等它修改，运行，看看结果，再继续聊下一轮。
后来引入 Codex，让它和 Claude Code 互相检查。我逐渐发现，换一个模型、换一份上下文重新看，确实能找出不少原来的实现者没有注意到的问题。
原因也不神秘。写代码的 Agent 已经接受了一套理解，测试可能也是按这套理解写的。实现和测试彼此一致，并不说明它们符合我的需求。让另一个 Agent 从需求、代码差异和验收证据重新开始，至少有机会打破这套共同假设。
后来 Claude Code 的订阅账号被封，我开始继续用 Claude Code CLI 接入不同的国产模型。模型在换，额度、稳定性和协议兼容问题也一直存在，但我给自己保留了一条工作规则：A 模型写的代码，交给另一家公司的 B 模型 review。
不同公司不意味着错误一定独立，更不意味着两家同意就正确。我把它当作增加审查视角的办法。审查最终仍然得指出具体问题：哪条需求没有满足，什么情况下会失败，证据在哪里。
这个过程中，我也逐渐把三件事拆开了：模型是否够聪明，工具是否能稳定执行，以及我有没有给出足够明确的完成标准。它们任何一项出问题，任务都可能停下来；换一个更强的模型，不会自动解决后两项。
从一个模块等到下一个模块，到学会并行
再后来，一个模块一个模块地串行开发，开始让我觉得太慢。
有些任务明明可以独立推进，却因为都挤在同一个工作目录和同一段对话里，只能等前一个结束。于是我开始学习分支和 worktree，让不同任务在各自的工作目录里做，最后再审查和合并。
对我的实际开发节奏来说，这一步提速很明显。
但新学到的也不只是几条 Git 命令。开几个 Agent 很容易，把工作拆成能并行的几块更难。哪些模块可以各自推进，哪些共享接口必须先确定，最后以哪个版本做集成验证，都需要有人决定。
worktree 给了我隔离工作目录的能力，没有替我消除模块之间的依赖。随着并行任务变多，我需要更认真地管理每一项工作的范围、交付物和合并顺序。
这也让我重新认识了自己在 AI 开发里的角色。代码敲得更快以后，需求和接口没想清楚的代价反而更明显了。
自动化开发那次“已经完成”，让我把流程写死了
搭建自动化开发流程时，我得到了一次很强烈的教训。
Agent 告诉我已经开发完成。我去检查，发现它交出来的东西，距离我以为正在建设的那套系统还差得很远。
这比一个编译错误更麻烦。编译错误至少明确告诉你哪里停了；一份看起来完整的实现，加上一份“测试通过”的报告，很容易让人以为双方已经对完成达成了共识。
其实没有。
我在早期开发里就已经使用 PRD 和技术方案。这次经历让我发现，“项目里有这两份文档”和“这一轮的实现真的得到过批准”，是两回事。旧设计可能讨论过类似能力，却不一定覆盖这一轮新增的范围和取舍。如果这些变化没有经过我确认，Agent 仍可能一路做完一个它认为合理、我却不接受的结果。
后来，我把流程收紧，并写进项目的 AGENTS.md：
这一轮的 PRD 审批 → 这一轮的技术方案审批 → 开发 → 独立 code review → 验收与上线授权。
不能先做完再补文档，不能拿更早的一份大方案充当本轮批准，也不能因为我随口说了句“开始做”，就把尚未解决的范围问题悄悄跳过去。如果确实要走例外，也需要明确说出来，记录原因。
对我来说，这套流程最重要的作用，是让我能在实现还没有堆起来之前，看到自己究竟批准了什么。
它会慢一点，也增加了我需要阅读和判断的东西。但相比最后面对一整套偏离预期的代码，我更愿意在前面付这个成本。
我想交给开源社区的，也包括这些过程
这几个月里，我学到的工程化，很多都来自这种很不舒服的时刻：服务器真的要用，备份真的要恢复，模型真的会失效，审查真的会漏问题，而“开发完成”真的可能和我的预期相差很远。
如果只做一个范围很小、用完就放下的练习，这些问题可以暂时不出现。Personal Agent 让我必须继续往后走，因为我还想在明天、下个月继续使用它。
它比我想象中困难，也更痛苦，但有意思得多。
所以这次开源，我希望留下的不只是最后一份代码。还包括一个产品经理借助 AI 编程，把自己的需求一点点变成系统，过程中怎样学会拆任务、要求证据、修正流程，以及承认哪些事情还没做完。
接下来，我会优先补 Memory。这是我对当前产品阶段的一个判断：Memory 是让这个 Agent 从“能用”走向“好用”的升级，自动化开发流程则主要提升工具开发的效率。
能完成一次请求，和长期相处时好不好用，是不同的问题。如果每次开始一件事，我都要重新交代背景、偏好和已经确认过的信息，那么它虽然能执行任务，我仍然要不断替它补上下文。我希望 Memory 改善的，就是这种日常使用体验：该记住的能延续，记错的能纠正，不该再保留的能忘掉。
自动化开发流程仍然值得继续做，它能帮助我更高效地开发和维护工具。但工具开发得更快，不会自动让 Agent 更理解我。对这个阶段的 Personal Agent 来说，自动化开发流程带来的是提效，Memory 才是我期待的体验质变。因此，我把 Memory 放在更前面。
Muse 出来时的挫败感是真实的，这个项目带给我的变化也是真实的。
现在，我先把已经做过的这一部分拿出来。如果其中一段代码、一条失败经验，或者一个设计取舍能帮到你，欢迎来讨论。