从记账到云端开发，我把自己的工作流接进了 Meta Muse

Meta Muse 发布后，我第一时间就开始用了，一直用到现在。

我把 Muse 当作一个能调用工具、实际办事的 AI 助手来用。它有手机入口，可以通过连接器访问我的数据，也有一台云端虚拟机——一台可以登录网站、安装开发工具、执行任务的远程电脑。连接器、浏览器和自动化任务，让它能持续参与我的生活和工作。

我自己也一直在做一个叫 Personal Agent 的个人助手：iPhone 上是对话入口，后端部署在阿里云云服务器（ECS）上，包括对话服务、连接账本等数据的工具服务，以及独立的自动化开发服务。它是只供我自己使用的一套系统，部分开发工作原来依赖家里的 Mac。

所以拿到 Muse 后，我很自然地想试一件事：把自己的数据、工具和工作流程逐个接进去，看看它能接住多少真实需求。

这段时间，飞书记账、知识库、日程、健康、邮件、旅行都陆续接上了。最近两天，我又把自动化开发工具链和 ECS 部署链路搬进了 Muse 的虚拟机。

前面的接入，让 Muse 越来越了解我的生活；后面的迁移，则改变了我做开发的方式。以后大部分开发工作都可以在云端自动推进，我用手机提出需求、查看进展、作出关键决定，不用一直坐在电脑前。这篇文章重点记录的，就是这次变化。

先把自己的数据和工具接进来

最先接的是飞书。

我的账本在飞书里，Personal Agent 已经有一套记账和读取账单的规则。我通过自定义连接器把飞书接到 Muse，再把原来 Agent 的规则复制过去，让它沿用我已经打磨过的方式做事。

这条路能跑通。它可以帮我记账，也可以读取账单、回答相关问题。不过，实际使用时，它比我自己的 Agent 慢很多。同样一件记账或查询任务，在我自己的系统里更利落，在 Muse 里会等得久一些。

专门为自己的业务写一条窄流程，仍然有价值。这也是我会继续做 Personal Agent 的原因之一。

接下来是 GitHub，我先接入了自己的知识库。

这里用的是我自己的 GitHub key，通过自定义连接器接入，并没有走官方 GitHub 连接器。

这相当于把我的“外挂记忆”交给了 Muse。我已经积累下来的资料，可以成为它处理问题时按需读取的上下文，不用每次都从头解释。知识库跟着我走，也可以给不同的 Agent 使用。

这一段接入体验，值得专门夸一下 Muse。

我非常喜欢它的自定义连接器和凭据管理设计。对我这种已经有自己的工具、数据源和访问凭据的人来说，可以把现有能力接进去，实在太重要了。飞书如此，GitHub 也是如此：我可以带着自己的规则、自己的 key 和自己的知识库来用它。

凭据管理这一点，我尤其想夸。让 AI 帮忙操作账号，最容易图省事的做法，就是把账号密码或者 API key 直接明文发给它。但这些内容一旦进入聊天记录，就多了被保存、转发，或者意外带进后续输出的风险。

我很喜欢这种把凭据配置和 AI 对话分开的隔离方案：我在专门的位置配置认证信息，对话里告诉它要做什么，工具执行时再使用相应的凭据。能调用一个工具，不应该意味着我先得把密码和 key 粘贴进聊天框。这一点做得很赞。

它让我想到自己以前做项目时的 .env 文件：各种服务的 key 放在环境配置里，程序运行时读取，业务代码通过配置使用它们。在 Agent 场景里，我对标的也是这个思路——让执行环境拿到需要的凭据，尽量减少明文秘密在对话里的流转。Muse 把这件事做成了接入体验的一部分，很符合我对个人 Agent 的期待。

它给了我继续扩展的空间。今天接账本，明天接知识库，之后再把自建服务接进来，原来系统里的积累都能继续用。

我还接入了 iOS 日历、提醒事项、健康数据和 Gmail，延续自己原来做日程、健康和邮件管理的需求；在虚拟机浏览器里登录 Google、Booking、小红书等网站，也让它可以参与账号内的事务。最有感的一次，发生在国庆旅行中。

国庆旅行，Muse 救我狗命

真正让我感受到它价值的，是这次国庆旅行。

说得直白一点，Muse 救了我狗命。

旅行住宿里的事情，比“订好一个房间”复杂得多。这次 Booking 上的民宿自动扣款失败，我需要另外完成付款；还要登记个人信息，房东才会给入住密码；当地有可以申请的免费旅行通票；房东也会发消息，确认我什么时候入住、什么时候离开。

这些事情分散在 Booking 私信和 Gmail 邮箱里，时间上也不整齐。订房之后，仍然有一串需要跟进的事项。

人在旅行中，很难一直盯着每一个入口。我得安排路上的事情、看行程，也想好好玩。住宿信息如果漏掉一条，却可能直接影响后面的安排。

Muse 自动化监控 Booking 的私信和我的 Gmail，然后主动给我发消息，提醒我接下来要做什么：这笔款需要单独付，个人信息还要登记，这条房东消息需要回复，入住和离开的时间要确认，还有当地通票这件事可以处理。

这次其他 Agent 没能帮我接住的，恰恰是这条需要持续跟进的完整流程。Muse 的虚拟机和手机入口，在这里发挥了很大的价值。

虚拟机给了它一个实际办事的地方。我在里面的浏览器登录 Booking 等网站后，它就能进入我自己的预订和私信页面，结合 Gmail 里的邮件跟进住宿事项。这些信息藏在登录后的账号里，还会随着房东发消息、付款状态变化不断更新。单靠回答旅行问题或检索公开网页，很难处理到这一步。

有了云端的执行环境，这件事也不用依赖我随身带着一台电脑、不断把页面内容复制给它。我可以把跟进任务交给 Muse，让它按自动化安排检查这些入口，把新的待办带回来。对旅行来说，这种跨网站、跨时间的跟进能力太实用了。

手机入口则把这套能力带到了我身边。人在路上，随时掏出手机就能交代事情、查看进展、收到它的提醒，再处理需要自己完成的动作。我不需要为了跟进一条房东消息，专门打开电脑，重新进入一套工作环境。

对我而言，这两个部分缺一不可：虚拟机承接网站访问和执行，手机让我随时参与。其他 Agent 即使能分析我贴过去的一封邮件，如果后续还得我自己盯着网站、搬运消息、再次发起询问，就很难替我接住这次旅行里的负担。Muse 这次把它们连起来了。

付款、登记、确认这些需要我做的动作，它及时递到了我面前。

这就是我一直想要的个人 Agent 体验：持续跟进一件正在发生的事，理解新消息和当前任务的关系，在需要我行动的时候主动提醒。

预订、付款、入住登记、密码、通票、入住和离开时间，整个旅行住宿流程都连起来了。这次经历之后，我开始愿意把更复杂的工作交给它。

把自动化开发工具链搬进 Muse 虚拟机

最近两天，我开始迁移自己的开发工作流。

这次迁移，很大程度上直接沿用了我自己做的自动化开发流程设计方案。规划、编码、独立审阅如何分工，评审意见怎样进入修改和复审，哪些动作需要我批准，这些规则都来自此前的方案。我把这套设计交给 Muse，作为它组织和执行开发任务的依据。

原来，我的自动化开发体系有一部分依赖家里的 Mac。现在这条新路径里，Muse 在云端虚拟机上组织任务，开发工具也在那里执行，我从手机上给需求、查看进展、作出批准。

我把流程拆成了几个角色：

• Muse 负责组织任务、准备上下文、调度工具，并跟进执行结果。
• Codex 的命令行工具（CLI）负责规划和写代码。
• 独立模型负责审阅，这次用的是 GLM，通过配置了模型转接的 Claude Code 命令行工具调用。
• 我负责确定需求，以及合并、部署这些关键动作的批准。

这里我很看重的一件事，是把写代码和审阅分开。审阅者拿到代码差异（diff）、验收标准和测试证据，提出问题，交回修改，再重新审阅。

第一次实操，我拿自己个人助手里的一组旅行查询修复来验证流程。独立审阅提出问题后，Muse 组织补充证据、修改代码，再交回复审。阻塞问题解决、离线测试通过后，代码经过 GitHub 审查与合并，进入后面的部署环节。

中间也遇到过代码工具因权限限制无法写文件的情况，Muse 按它给出的方案接着完成了修改。我开始看到这套流程的价值：评审意见、修复和验证可以在云端持续推进，减少我在不同工具之间来回搬运的工作。

开发凭据也要搬，但不能直接贴进聊天

开发工具链还需要模型服务等更多凭据，光有知识库连接器里的 GitHub key 不够。我也不希望为了配置这些工具，把新的 key 明文贴进聊天。

所以，我让 Muse 配合搭了一条一次性凭据注入路径：浏览器先加密，虚拟机再接收、解密，并写入所需配置。具体使用浏览器自带的 WebCrypto 加密能力，以 ECDH 协商密钥、AES-GCM 加密内容；虚拟机上的一次性接收进程完成配置后退出。

这样，明文 key 就不用作为聊天内容传递。这里的加密注入，是这次为开发工具另外搭的方案；前面提到的 Muse 自定义连接器和凭据管理，是产品本身的接入体验。

开发环境最终仍然需要使用凭据。凭据放在哪里、对应什么权限、什么时候可以撤销，这些事情都要明确。一个 Agent 能执行更多工具之后，凭据管理的重要性也会跟着上升。

先用 RAM 和云助手接通 ECS

要让 Muse 帮我管理阿里云 ECS，首先得把远程操作通道接起来。

我一开始让 Muse 尝试通过 SSH 远程登录服务器。公钥、服务器用户、访问配置都准备好了，最后发现 Muse 的运行时禁止出站 SSH。连接返回的是平台的拒绝信息，SSH 握手没有开始。

随后，我通过阿里云访问控制（RAM）创建了专用用户和访问密钥（AccessKey），配置云助手所需的接口权限。云助手是阿里云提供的服务器命令执行通道，Muse 可以通过 HTTPS 调用它，在 ECS 上执行命令、查询结果。

RAM 用户、AccessKey 和云助手这套方案，解决了 Muse 与 ECS 的连接和远程执行问题。 Muse 实际跑通了身份查询、服务状态检查，也验证了部署所需的 root 管理员执行权限。

到这里，Muse 已经能操作 ECS。开始改造部署流程时，才碰到了下一道问题：构建好的部署文件怎么送过去？

把部署拆成命令通道和文件通道

远程命令已经能执行，部署还需要文件传输。把这两部分配齐后，最终的链路是：

GitHub 中的目标代码
        ↓
Muse VM 构建 wheel、锁定依赖、生成发布信息
        ↓
私有 OSS 保存部署产物
        ↓ 短期签名下载链接
ECS 下载并校验，构建新环境，切换并重启
        ↑
Muse 通过阿里云云助手提交命令、查询结果

云助手负责执行命令

Muse 通过阿里云云助手的 HTTPS 接口，在 ECS 上执行 shell 脚本。虚拟机不需要建立 SSH 会话。

RAM 权限最终覆盖四个动作：检查云助手状态、提交命令、读取结果、查询执行历史。

最开始用专门的运维用户跑 whoami，确认执行身份；之后再验证 root 身份，给安装、切换环境和重启服务准备权限。root 测试本身只查询身份，正式发布才执行获准的部署动作。

私有 OSS 负责传部署包

原来的部署脚本默认有一台 Mac：在 Mac 上构建 Python 安装包（wheel），导出依赖，再用文件复制工具 SCP 经 SSH 直接把文件送到 ECS，安装进 Python 虚拟环境。那条路径既能执行远程命令，也能传输部署文件。

但在 Muse 这条路径里，构建发生在虚拟机里，Mac 不参与。前面接通的云助手命令接口 RunCommand 可以提交脚本、执行命令，却没有 SCP 那样直接上传大文件的能力。

命令内容有大小限制，不能把几 MB 的 wheel 直接塞进一次请求。把文件编码后拆成很多段、反复提交命令再拼回来，虽然可以另做一套方案，却会增加重试、顺序和完整性校验的复杂度。部署需要的是一条适合传文件的通道。

所以，连接 ECS 的问题已经解决，接下来要补的是部署包传输。这也是后来引入 OSS 的原因：云助手继续负责执行，文件交给对象存储传递。

一种选择是在 ECS 上放 GitHub 凭据，让它直接拉私有仓库。但我希望服务器接收构建产物，不需要拿到访问源码仓库的 key。

于是，我新建了一个专门用于部署包的私有对象存储（OSS）空间。这个存储空间叫 Bucket，也就是存储桶。

我特意要求按长期部署仓库设计：Bucket 长期保留，里面的文件按每次发布组织，根据需要保留和清理。

每次发布使用独立路径：

releases/<commit-sha>/<build-id>/

commit-sha 是 Git 提交标识，对应具体的源码版本；build-id 区分同一源码的不同构建。wheel、依赖清单和构建信息都放在这个发布目录下。

Muse 使用限定在部署前缀内的 OSS 权限上传、列举和读取产物。ECS 通过短期签名 GET 链接下载文件，不需要保存 Muse 的 AccessKey，也不需要 GitHub key。wheel、依赖文件、构建信息各有自己的完整签名链接，有效期设为 15 分钟。

这也意味着，签名链接本身要按临时凭据处理，不能随意打印到聊天或日志里。

私有访问解决的是谁能读写。相同对象名仍然可能被覆盖，所以发布路径唯一、文件摘要校验、发布记录这几件事也要一起做。

先传一个小文件，再跑正式发布

我先让 Muse 用一个 51B 的测试文件验证链路：虚拟机上传，再从 OSS 下载，ECS 也通过云助手执行下载。

三份文件的 SHA256 校验摘要一致，才说明这个小文件确实完整走过了“虚拟机 → 私有 OSS → ECS”，传输后内容没有改变。

后面正式发布时，传输的是约 2.5MB 的 wheel，以及约 46KB 的依赖清单。小文件通过只是起点，正式包传输、安装和服务切换，还得分别跑过。

上传和生成签名链接使用了 Python 的 oss2 开发库，安装在专门为传输工具创建的虚拟环境里，避免混入其他工具的依赖。

真正花时间的，是把发布和回滚做对

文件能送到服务器，还不能算部署流程已经完成。

旧脚本是在现有 Python 虚拟环境（venv）里安装新 wheel。venv 把应用使用的 Python 和依赖包集中在一个独立环境里；原地更新安装包时，依赖也可能跟着变化。如果回滚时只装回旧 wheel，旧依赖未必能恢复，环境已经和原来不一样了。

新方案为每次发布创建独立的 venv，保留旧环境，用符号链接选择当前版本。这个链接相当于一个固定入口：服务启动时沿着它找到要运行的环境，需要切换版本时就修改入口的指向。

/opt/personal-agent/
├── .venv → releases/<commit>/<build-id>/.venv
└── releases/
    ├── <旧版本>/<旧构建>/.venv
    └── <新版本>/<新构建>/.venv

这套方案有几个细节，真正执行时都很要命。

venv 必须在最终位置构建

一开始想的是，在临时目录里建好环境，再把目录移动到发布位置。后来通过真实 venv 复现，发现这样会让入口脚本失效。

Python venv 里的 pip 等入口脚本，第一行的解释器声明（shebang）会写入绝对路径。目录移动了，脚本还指着原来的位置。

所以最终做法是：先确定唯一的发布目录，在最终位置创建 venv，安装完成后不再移动。服务通过固定的 .venv 链接使用它。

切换时，我让 Muse 核对 ECS 上 GNU coreutils 命令工具的实际版本，再使用对应版本支持的链接替换行为。发布链接的替换和服务重启是两个动作；这次仍然需要重启服务，我没有把它当作零停机发布。

root 安装成功，还要证明服务用户能使用

新环境是 root 构建的，但应用有自己的服务用户。

如果父目录是 0700，即使 venv 里面的文件可以读，服务用户也走不到那里。只修最下面的 build 目录权限同样不够，路径上每一层都要允许服务用户进入。

我因此让 Muse 检查了发布路径上每层父目录的权限，并以对话后端和数据工具服务的实际运行用户执行基本启动检查。

root 能运行，不代表服务用户能运行。这是发布前必须跨过去的一道边界。

构建身份要绑定产物，不能只看包版本号

构建侧使用 uv build --wheel，从锁文件导出依赖，在新环境里用带 hash 校验的依赖清单安装。

每次发布还生成构建信息，记录 commit、build-id、文件大小和 SHA256。下载后逐项核对预期文件，确认没有遗漏或多余对象，再安装。

这里又踩了两个坑。

第一个是 wheel 文件名。不能为了脚本方便，把带完整包名、版本和兼容性标签的 wheel 随手改成一个简短名字，pip 会按 wheel 命名规则处理它。下载、校验和安装要使用同一个真实文件名。

第二个是构建信息文件的“自我校验”。最初想把它自己的 SHA256 也写进文件，但写入这个摘要之后，文件内容又变了，摘要自然就失效了。

最后改成：构建信息记录 wheel 和依赖文件的摘要；构建信息自身在写定后计算摘要，保存在独立的发布记录里。

同样，服务器显示 personal-agent 0.1.0，也不能证明它就是这次要发的 commit。多个构建可以共享同一个包版本号，必须把源码版本、产物摘要和实际 release 路径对应起来。

回滚恢复的是旧环境的真实指向

切换之前，Muse 用 readlink 读取当前 .venv 链接的实际指向，并保存下来，作为这次发布的恢复目标。

这个记录只建一次。重复执行切换脚本时，不能把已经切到的新环境重新记成“旧环境”。

恢复时也不能自己拼一个猜测的路径。原链接可能是相对路径，也可能是绝对路径：验证旧目录存在时需要分别解析，恢复链接时则保留原始指向的语义。

正常流程是，新环境准备好并通过发布前检查，记录旧指向，切换链接，重启服务，再验收。需要恢复时，就换回保留的旧环境，重新启动并检查。

这和项目里原有一个叫 rollback.sh 的脚本也不同。那个脚本做的是停用和移除 systemd 服务配置，属于卸载路径，不能因为名字叫 rollback 就拿它做版本恢复。

这次旧环境和恢复记录已经保留，本地也演练过相关模板；生产环境的完整回滚演练，还需要单独验证。

先审部署指引，再做第一次发布

我让 Muse 为这条路径单独写了 MUSE_DEPLOY.md，保留原来的 Mac 部署入口，两条路径并存。

指引覆盖部署前检查、构建、OSS 传输、云助手操作、安装切换、验收、回滚、日志和清理，并给出可填写参数的执行模板。

这份文档经过了多轮审阅。上面提到的 venv 不可移动、父目录权限、真实 wheel 文件名、独立签名链接、回滚目标只记录一次，以及相对和绝对路径的处理，都是在这过程中逐项收紧的。

批准方式也写进去了：一次部署批准列清目标 commit、服务范围、是否重启、验收动作，以及失败后的恢复范围。范围内持续执行，超出范围才重新确认。

这是我希望 Agent 做到的工作方式。前面把事情讲清楚，后面就把获准的工作持续做完。

第一次正式发布最终完成了，但也没有因为文档经过审阅就一路无事。生产执行又遇到了 shell 兼容性问题：实际运行的 shell 不支持模板里的 pipefail，需要改成兼容的写法。构建信息的自引用问题也在正式构建时暴露出来，修正后重新上传。

所以写好操作指引很有帮助，真正的环境仍然需要执行验证。

这次发布更新的是我自建个人助手的对话后端和数据工具两个服务。自动化开发服务仍然在 ECS 上的独立环境里运行，没有随这次发布迁走或更新。

部署完成后，Codex 从我已有的 Mac 运维通道做了独立只读检查：服务在运行，对话后端和数据工具服务的环境链接指向新发布目录，个人站可以访问，应用端点也返回了预期的未认证响应。

这些证明了服务运行和访问边界的基础状态。旅行查询的真实业务验收，以及生产回滚演练，还需要继续补上。

截至现在，已经跑通的是 Muse 虚拟机上的开发工具链、评审修复循环、构建和发布通道。自建自动化开发系统原有的手机审批、操作记录和失败恢复机制，如何与这条新路径接续，还有后续工作要做。

但后续自动化开发，已经有了可以继续在 Muse 里推进的基础。我从手机提出需求，Muse 在虚拟机里组织开发，再把获准的产物送到服务器。这正是我这两天想打通的事情。

Muse 给了我一个很具体的迭代方向

从目前的使用体验看，Muse 是最符合我个人 Agent 需求的产品。

自定义连接器和凭据管理，让我的工具、数据和规则能接进来；旅行中的持续跟进和主动提醒，让它参与了真实生活；虚拟机又给了开发工具一个实际运行的地方。

我的 Personal Agent 也会继续做，并且持续向这些体验靠拢。记账这种专门流程，我自己的系统还有速度和业务适配上的优势。Muse 则给了我一个具体的参照：当数据、工具、浏览器和执行环境都接起来，一个个人 Agent 可以怎样参与我的生活和工作。

我最想学的，是单 timeline 的上下文管理

现在，我最想搞清楚的，是 Muse 怎么管理单 timeline 的上下文。这里的 timeline，就是我使用 Muse 时持续对话的一条时间线：记账、旅行、开发这些不同任务，可以在同一条时间线里先后展开。

我自己的机制比较明确：超时后自动切到新的会话（session），再通过短期、中期、长期记忆，把需要保留的信息接续下来。这套机制能工作，但用了 Muse 之后，我感觉它在连续性上的体验更好。

记账、旅行、邮件、开发，这些事情可以在同一条 timeline 里不断切换。尤其开发和部署会持续很久，期间还有评审、修复、失败重试和人工批准，我很在意它怎样把任务接下去。

它什么时候压缩上下文？怎么区分当前任务和长期信息？已经完成的任务留下什么？跨任务的记忆怎样被重新取出来？又如何避免之前的事情干扰当前工作？

我还不知道背后的实现。也可能有一部分体验来自模型能力，或者工具执行过程中对上下文的处理。仅凭使用体感，无法判断是哪种机制起了作用。

但这正是我最想向它学习的地方。

这两天，我把开发工具和部署通道接到了 Muse。接下来，我希望自己的 Personal Agent 也能更好地理解一件事的进展，在需要行动的时候找到合适的工具，把工作持续做下去。