十月底，我的在线衣橱给了我两套穿搭推荐：短袖 T 恤、长裤、鞋，没有外套。

我的反馈很直接：“今天这种天气不穿外套要冻死我。”

查下来，它默认只看白天的天气，外套门槛也设得太低。我要求把天气窗口延长到晚上十一点，最低体感温度低于 22°C 就配外套。晚上九点零四分批准需求，十一点二十四分，改动完成部署。期间方案被打回、修订，测试问题也经过核实；协调者组织开发和评审继续推进，需要我决定需求和发布时，再回来找我。

这是我把开发流从 Muse 迁到 Grok Bot 后，一次很具体的体验。工作流逐渐跑顺，手头的项目也告一段落，我开始认真想：接下来，什么问题还值得自己长期投入？

把开发流再迁一次

Muse 和 Grok Bot 都是我用过的、带云电脑的 AI 助手，可以安装工具、执行任务。我之前已经把自动化开发搬到 Muse 上，随后开始做个人在线衣橱。

衣橱的前身是一个 Claude Cowork skill。我把自己的衣服全部拍照、命名、分类，放进 iCloud 文件夹，让 Claude 读取衣服和天气，做穿搭推荐。后来开发 Personal Agent——我自己搭的、以 iPhone 为入口的个人助手——就想把这些积累做成独立服务，提供 API 和 MCP 工具，让 Personal Agent、Muse 都能使用。

但在 Muse 上开发时，我越来越多精力花在了流程本身：慢、耗 token，还经常卡住。下一步动作还没发生，先花几轮对话解释状态；重新推起来，又得检查前面的结果还能不能用。排查过一些局部问题，始终没把整条链路为什么不顺解释清楚。

后来听说 Grok Bot 的云开发更成熟，就决定迁过去试试。我建了两个子 Bot：Dev Orchestrator 组织任务，Code Reviewer 独立评审。方案和编码仍交给云电脑里的 Codex，沿用我的订阅，毕竟 100 美元不能浪费。迁移后也遇到过超时和部署故障，但协调者更容易把问题、选项和需要我决定的事情讲清楚，再接着处理。衣橱剩下的评审、修复和部署，就这样继续做完，也逐步接进了 Personal Agent 和 Muse。

我当时特别强调过：“时限不用这么死，保证不会因为各种问题卡住导致空转浪费token。”复杂任务可以多做一会儿，遇到问题也可以回来找我，但我需要知道它能继续推进，或者明确停下来。

系统需要什么，我又想研究什么

个人助手、个人站、在线衣橱，这批原本想做的项目暂时都有了可以继续使用的版本。开发流也比较顺手了，反而轮到我重新选择方向。

我当然还能继续加功能。但“还有什么能做”，已经不足以成为继续投入的理由。

回头看，第一次做出 Personal Agent，我很兴奋：一个原来只存在于想法里的助手，真的出现在自己的手机上。后来用通用的方式接服务，我也很兴奋：整理过的衣服、定义过的记账规则，可以给不同 Agent 使用，前面的积累开始成为下一件事的基础。

但深入到 session 管理、memory 管理、context 管理，我的兴趣确实在下降。

这让我有点犹豫。毕竟已经投入了这么多时间，也清楚这些机制对一个长期运行的助手有多重要。可继续往下钻，自己越来越缺少主动追究下一层问题的兴致。

我开始把“这个系统需要什么”和“我接下来想研究什么”分开。我要懂得上下文和会话怎样影响结果，也要把自己的系统维护好。但亲手做过一个 Agent，并不意味着其中每一层都要成为我长期投入的方向。

衣橱里的一次权限问题，反而让我重新有了追问下去的兴趣。

交接后的独立评审发现，只读授权可以触发推荐任务的“恢复执行”。在对话里，“刚才没做完，继续吧”很自然，但恢复会改变任务状态，推进后续处理。查看进度的权限，就这样越过了读取的边界。

补上检查，AI 可以很快完成。让我在意的是，系统最初把这个动作归到了哪里，以及换一个调用方以后，同样的边界还能不能成立。

我目前的判断是，权限要按动作的实际后果划分。会改变业务状态或推进后续执行的恢复、重试，需要重新检查对应动作权限；产生新费用，还要核验预算或计费授权。查询状态则应保持只读。

入口叫“恢复”，不会让它产生的后果自动变轻。

我想继续深挖的，是接通之后的关系

这让我又回到自己一直在做的开放平台。

之前在个人博客里，我写过开放平台怎样面向 Agent 改造，也讨论过Agent 代表用户调用服务时，平台怎样控制执行边界。当时还没有决定在这里继续深挖。尤其自己接过 MCP 之后，甚至觉得工具接入挺简单：业务范围和目标描述清楚，很多工具设计和实现，AI 就能完成。

但回看自己的工作经验，开放平台长期花精力的事情，还有开放范围、用户授权、生态治理，以及接入之后的客户关系、成本和控制权。这些选择，具体影响的是各方愿意承担什么、又能得到什么。

接 Muse 的过程中，我就亲自作过一次信任取舍。

设计聊天新增衣服的路径时，我希望在 Muse 里完成识别、看草稿、确认和提交。可衣橱服务无法像我自己的 Personal Agent 那样，直接掌握用户界面里的确认过程。最后接受的方案是：信任已授权的 Muse 调用方报告用户确认，同时只允许新增，不把修改、删除已有衣物的能力一起交出去。

这项选择保留了风险：调用方可能误报用户意图或确认。服务检查草稿版本和有效期，可以约束提交内容，却不能因此证明真人确实看过并确认。

站在用户一侧，我希望事情在当前对话里办完；站在衣橱服务一侧，我需要说清楚自己究竟信任什么，出了错误最多允许影响到哪里。这两种立场，都落在同一个真实需求上。

这里需要区分两个角色：Agent Host 承接用户委托、组织任务并选择服务；Service Provider 提供数据或业务能力，承担对应的执行责任。我的 Personal Agent 是自己能改造的 Host，衣橱是 Provider，Muse 则是服务需要对接的外部 Host。

对 Host，我目前更看重的低打扰，是让系统在授权范围内承担推进和恢复的工作，把需要作决定的事情交回用户。

我在开发流里反复说“不想空转、不想一直盯着”，就是这种期待。常规内部问题不应该都变成用户的待办；超出授权、出现新的风险时，系统又得停下来。确认按钮少了几个，并不足以说明委托体验变好了，还要看省下来的介入是否有机制承接。

Provider 则必须独立检查自己认可的授权。Host 给出的“已经确认”，需要对应明确的信任关系和允许范围。在 Muse 新增衣服这件事里，我接受过受限的调用方信任；以后要继续研究的，是哪些条件下能给出更强的保证，又会给使用体验增加多少成本。

沿着这里往外看，双方的产品和经营目标也不会自动一致。

Host 要建立足以完成任务的服务供给，决定哪些自己做、哪些接外部，并在多个服务之间选择、组合或替换。它向用户承诺的任务，取决于这些供给是否真的可靠。Provider 则要判断开放什么、进入哪个入口，以及外部需求能否覆盖接入、交付和治理成本。它还可能希望保留自己的品牌、客户关系和服务差异。

这些让我想到以前开放平台里熟悉的小程序、H5 和 App：服务在哪里完成，谁掌握分发，收入和成本怎样归属，哪个团队承担原有业务指标的损失。旧经验可以帮助提出问题，Agent 的动态选择和执行裁量，又需要放进来重新检验。

我目前倾向于，分别判断两边的产品价值和经营收益，再讨论合作条件。技术接通，只完成了其中一步。

Host 能替用户把任务办完，Provider 也要有持续提供服务的理由。开放范围、流程交接和商业安排，需要放在双方的目标里一起看。

所以，我想继续研究的范围会覆盖两侧各自的决策。Host 需要自己的任务产品、供给建设和生态经营；Provider 需要自己的能力产品化、开放策略和渠道判断。开放平台经验能帮助我起步，也不能提前替我限定以后只能负责哪一边。

这也是我想为后续工作积累的能力：面对具体问题，能提出方案，解释取舍，拿出依据，并知道什么变化会让我修改判断。

从自己的 Host 和服务开始

接下来的实践，就从 Personal Agent、衣橱、记账这些已经使用的系统开始。我想从基础设施起，把 Host 和 Provider 两边都认真做一遍，让身份、授权、确认、执行和恢复都有明确的机制。

Muse 继续作为一个真实的外部调用方。在自己的 Agent 里能控制的界面和行为，到了 Muse 就未必能控制。它会暴露哪些保证来自机制，哪些只是因为系统两边都由我开发，默认彼此配合。

以前只有我自己用，一些地方可以靠手工配置和自己介入兜住。为了让云端部署顺畅，我也给执行账号放宽过权限，再依靠备份、演练和关键动作批准控制风险。下一阶段，我想把这些便利背后的假设拆开，逐项决定哪些应该变成系统可以执行的规则。

个人项目能让我亲自承担取舍带来的麻烦，也能验证一部分机制。生态冷启动、业务增量和长期控制权，则要继续研究真实案例，寻找相应的经营证据。衣橱里一次调用成功，回答不了这些问题。

我希望积累下来的，是可以迁移到下一个场景的判断：为什么选这条路，代价由谁承担，实际结果和预想有什么不同。代码、实验、案例和文章，都可以留下这些过程。

第一批实践，我准备先故意制造四种故障：

  • 用只读权限推进任务：验证恢复入口会不会越过权限边界。
  • 确认后修改提交内容：验证旧确认能否被套用到新的操作上。
  • 执行中途撤销授权：验证排队和执行中的任务分别停在哪里。
  • 写入成功后切断响应：验证系统能否找回原操作的结果，避免重复提交。

我会先从这四种故障开始，看看自己设计的授权和执行边界，究竟能不能在系统出错时仍然成立。