这个春节，我让 Agent 完成了 https://aimo.plus/ 的设计和开发。AIMO 是一款跨平台应用，包含 Web、Android、iOS、Windows、Mac 和 Linux 客户端。
我从 2023 年起就想开发这个应用。当时我开始使用 memos，它支持 Web 和移动端，我至今仍在使用。项目延后了 3 年，主要有两个原因：我没有确定满意的 UI 方案，工作和节假日安排也限制了可投入的时间。直接用 Antd 搭建界面不符合我对产品的使用预期。研究 AI Coding 后，我将此前积累的方法用于这个项目，用各类 AI 工具开发约 5 天，完成了应用建设，过程中基本没有直接编写代码。
这个项目也用于验证一种 Agent 开发方式。此前的 AI Coding 实践以 vibe coding 为主，人会查看 Agent 每一轮输出，并完成运行和验证。AIMO 将整个应用作为长程任务交给 Agent 开发、测试和运行，人只在关键节点确认方向。要实现这种方式，Agent 需要能操作应用、读取应用内部状态，并判断结果是否符合预期，不能依赖人工截图反馈。为此，我配套开发了两个开源项目：CSI 和 RabJS。
多 Agent 的编排方式
流程参考 SDD 组织：每一步都有明确产物和验收标准，产物由 Agent 生成。协调者负责任务编排，并管理四类下游 Agent。
流程从需求开始。PM Agent 将功能意图整理为 PRD，定义需求和范围；架构 Agent 随后产出技术方案，并在方案中给出测试用例和验收标准。这两个上游产物都经过 Agent Review，确认没有问题后再流转。开发 Agent 获得 PRD、方案和用例，以 Ralph 循环开发，逐条将 story 的 passes 置为 true。开发完成后，测试 Agent 使用 CSI 和 RabJS 做 e2e 验证：在真实浏览器中操作界面、读取 Service 状态，并按用例断言。发现问题后，测试 Agent 将问题和状态快照交给开发 Agent 修复；修复后重新验证，全部用例通过后再合并。后文分别说明开发和验证环节。
每个角色只读取完成当前职责所需的上下文：PM 查看需求，架构查看方案，开发查看当前 story，测试查看用例。角色分工本身构成了第一层上下文控制。
开发 Agent：Ralph 循环与上下文控制
驱动方式沿用我在 Ralph 工作流 中实践的循环。每个功能先由我和 PM Agent 共同形成一份 PRD，再转成机器可读的 tasks/prd.json。需求被拆为独立的 user story，每条都带有验收标准和优先级。外层 shell 循环每轮启动一个新的 Agent 会话，从 prd.json 取出一条未完成的 story，完成实现和自验后将 passes 置为 true，然后退出；下一轮再处理下一条，直到清单清零。这个过程持续 5 天。归档的功能包括分类过滤、日历热力图、Electron 客户端、AI 探索和定时通知等，每个功能都经过若干轮迭代。进入存量维护阶段后，驱动方式切换到 superpowers，区别见 Ralph 那篇。
上下文控制使循环能够持续运行。长程任务受上下文窗口限制：历史对话逐渐累积后，Agent 可能遗漏已有约定或重复出现同类错误。每轮使用新会话，不将对话历史带入下一轮；跨迭代记忆保存在磁盘文件中：
prd.json记录目标和完成状态，Agent 每轮据此确定要完成的工作；progress.txt记录每轮产出和留给后续迭代的经验。顶部的 Codebase Patterns 段落保存已经确认的约定，例如“controller 必须在index.ts显式注册”。新会话先读取这一段，无需重新浏览整个仓库；CLAUDE.md和skills/目录保存稳定的仓库说明和 API 参考，按需加载，不占用常驻上下文。
因此，每轮会话只加载当前 story 所需的信息。
交付通过两层验证。需求层为每条 story 写入可执行的验收条件，包括 typecheck、build、lint 和 test；Agent 完成后需要逐条检查。运行时验证由下一节的机制完成：Agent 启动应用、操作界面并读取 Service 状态，再断言结果。
测试 Agent 如何验证真实应用
验证需要向浏览器和 RN 应用暴露可操作的全局对象，使 Agent 能直接操作和断言 Service 层。UI 截图可以反映页面外观，Service 状态可用于确认数据是否符合预期。
AIMO 各端的状态都由 RabJS 组织。RabJS 将应用逻辑建模为可观察的 Service 实例。devtools 将整个 Service 容器挂载为全局对象，浏览器中为 window.__RS_ROOT_CONTAINER__。外部可以列出全部 Service 实例、调用方法、读取属性，并对状态执行链式断言。这套接口不依赖前端框架，Web 和 RN 的行为一致。
Web 端的验证链路较短。Agent 通过 CSI 操作我日常使用的真实 Chrome，执行 JS 脚本访问全局容器：找到目标 Service 实例，调用创建笔记、搜索等方法，再断言状态变化。真实浏览器保留了登录态和线上环境，因此验证面向用户实际使用的环境。
RN 端没有类似 CDP 的调试通道。这里使用 Supabase Realtime 中转指令：Agent 侧 SDK 向频道发送指令，App 内嵌的客户端 SDK 订阅同一频道。App 收到指令后，在应用内对 Service 执行操作，并回传状态快照和断言结果。指令和结果均为 JSON，Agent 可以用同一套方法验证 Web 和 RN，无需为移动端另行准备方案。
开发 AIMO 的 5 天中，大部分功能由 Agent 完成实现后启动应用、操作界面并读取状态确认结果，再处理下一个任务。
长程任务需要的工程能力
这些机制共同支持 Agent 持续执行数天的开发任务。模型负责生成，还需要处理任务拆分、上下文、状态、环境访问、编排和验证等问题。目前没有统一的名称或可直接套用的框架，我根据项目中的具体问题逐步补齐了以下部分：
- 循环与工作流：任务拆成带验收标准的清单，外层循环逐条交付，完成状态保存在
prd.json； - 上下文与记忆：每轮启动新会话，跨迭代记忆保存在磁盘，包括
progress.txt和 Codebase Patterns；仓库资料以按需加载的说明和技能提供； - 工具：CSI 用于操作真实浏览器，RabJS 将应用状态提供为可读写、可断言的接口，RN 通过 Supabase 接入同一套接口；
- 编排：协调者拆分和分派任务，PM、架构、开发、测试四类 Agent 分别处理各自的产物，并按验收标准流转；
- 验证：可执行验收标准和运行时状态断言作为交付依据。模型自评仅作参考，每轮交付前仍需通过构建和测试门禁。
这些部分需要分别回答任务如何拆分、上下文加载哪些信息、状态保存在哪里、Agent 如何访问真实环境、人何时介入，以及如何确认结果。模型能力的变化会影响各部分的实现，但不会消除这些问题。基于 AIMO 的开发过程，我认为这类工程设施承担了 Agent 开发中的主要可靠性工作：模型提供生成能力，交付结果还需要依赖流程、工具和验证。
PC 与 Web 客户端
首页
笔记详情与相似笔记
AI 探索
回顾
AI 回顾
画廊
移动客户端
首页
热力图
笔记详情与相似笔记
当前限制与后续改进
目前有三个限制。
视觉验证的上下文成本较高。功能正确性可以通过 Service 状态断言检查，但样式和布局调整仍需依赖截图。截图占用的上下文多于文本，视觉任务反复截图对比后，会占用大量上下文。实际处理方式是将视觉任务拆得更细，或由人完成这部分工作。
验证耗时也会延长迭代周期。在真实浏览器中执行一遍核心路径需要数分钟，5 天开发周期中有一部分时间用于等待验证完成；RN 端通过 Supabase 中转还会增加网络往返时间。
循环还不能自动处理所有中断。模型 API 不稳定或会话中途断开时，循环会停在中断点，需要人发现后手动重启。prd.json 的完成状态可以避免续跑时重复已完成的工作，但发现中断和重启执行仍由人完成，5 天中发生过多次。
针对前两个限制，可以将验证分层：先执行 Service 状态断言，拦截大部分逻辑回归；e2e 只覆盖关键路径；已经验证的流程固化为不依赖模型的确定性回放脚本，回归时直接执行脚本，模型只参与新增或变更流程。视觉验证也可以采用类似方式，先以结构化快照，例如无障碍树，进行判断；只有需要确认像素级效果时才使用截图。对于中断问题，可以将循环封装为具备恢复能力的守护进程：监控会话状态，断开后自动重试，必要时启动新会话并根据磁盘状态恢复。任务状态已经保存在磁盘中，恢复机制可以据此续跑。完成这一部分后，多天运行时不再需要人工发现并重启中断的循环。
后续演进可以参考任务时长的增长曲线。METR 的测量显示，前沿模型能独立完成的任务时长，以人类专家耗时计，大约每 7 个月翻一倍。若这一趋势延续，上述五部分的实现会随模型能力变化。上下文管理可能部分由模型完成，例如由模型决定保留和丢弃的信息，从而减少每轮新会话和将记忆保存到磁盘的需要。验证仍然需要外部证据：当模型更快地完成交付时，验收标准和运行时断言仍用于确认结果。将目标、记忆和验证保存为工程制品，仍适用于这一变化。
