多Agent协作不可见？开发者用像素办公室监控Claude Code

同时运行多个AI编程Agent，却不知道谁在干活、谁在等你——这是许多开发者的真实困境。一位韩国独立开发者为此打造了Refmade：一款读取Claude Code与Codex本地日志、将Agent团队绘制成像素办公室的桌面应用。

问题：看得见的代码，看不见的团队

据开发者自述，问题始于2026年9月20日。他为Codex搭建了一套个人协作系统：11个子Agent定义，覆盖PM、产品、商业、市场、设计、Figma、工程、实现、研究、数据分析和审查等角色，主对话充当团队负责人。Agent团队是有了，但他无法判断它们各自在做什么。

当多个Agent分散在不同终端里运行时，“谁在处理什么任务、谁在等我回复”几乎没有可靠答案。于是他让Codex构建了一个“办公室”仪表盘：每个任务一层楼，显示每个人的当前工作、下一步、等待事项、会议与记录。这成为Refmade的前身。

多 Agent 协作通常采用“主从”或“编排者—工人”模式：一个主对话（或主管 Agent）负责分解任务、分派角色并汇总结果，若干子 Agent 各自承担 PM、设计、工程等职能。这种模式能并行推进多项工作，但也带来一个可观测性缺口：每个子 Agent 往往独立运行在自己的会话或终端中，彼此之间没有共享的实时状态总线。当任务跨越多个 Agent 时，人类负责人很难从代码提交或聊天记录中判断整体进度，更无法区分“正在思考”“正在等待工具返回”和“正在等待我输入”这三种截然不同的停顿。

第一版：像素艺术成功，数据模型失败

9月21日上线的v1办公室运行在Mac本地127.0.0.1:4318，通过quick tunnel提供密码保护的只读远程视图，每5秒刷新一次。像素美术包含楼层、货架和12个坐姿角色，用GPT Image绘制；通过了25个Python测试和16个Node认证/部署测试。

问题出在数据来源上。第一版要求每个Agent主动记录自身状态：一个记录脚本把状态报告写入文件，仪表盘再据此绘制。但一个正在执行长任务的Agent，没有理由停下来写状态备注。一旦跳过报告，工位上就空无一人——而空楼层看起来就像整个团队在闲置。仪表盘无法区分“没人在工作”和“没人上报”。

开发者总结的教训很明确：依赖被观察系统自我描述的仪表盘，恰恰会在你最需要它准确的时刻出错。 任何无需Agent配合就能读取的信息，都比Agent主动汇报的更可信。

这里涉及的“数据模型”指的是仪表盘用来描述 Agent 状态的抽象结构：谁在工作、在做什么、在等谁。第一版采用“推送式”模型，即由被监控的 Agent 主动写入状态文件，仪表盘只负责渲染。这种模型的问题在于状态更新频率完全取决于 Agent 的配合度，而非真实工作节奏。更稳健的做法是“拉取式”或“观察式”模型：监控端定期读取不依赖被监控方主动写出的痕迹，如日志、进程、文件锁或 API 调用记录。两者的关键区别在于，推送式模型在系统繁忙时最容易丢失状态，而拉取式模型只会延迟，不会凭空消失。

转向：直接读取本地日志

9月25日，他判定这一思路本身有误。后续版本改为从Claude Code和Codex已经写入本地磁盘的会话日志中读取状态，而非等待Agent上报。

当前版本（Mac为0.3.9）按会话从本地日志绘制团队。公开演示数据显示三个团队卡片：Claude负责的“社区工坊”区域在推进首页预约界面改进，带2名美术成员；Codex的“春光咖啡馆”区域则有两个团队，分别处理新菜单推广和客户咨询回复，后者标记为“等待你的回答”——这类等待状态正是原方案难以捕捉的。

Claude Code 与 Codex 作为终端式 AI 编程 Agent，通常会把完整会话以结构化格式（多为 JSONL）写入本地磁盘，例如 ~/.claude/projects/ 或 ~/.codex/sessions/ 之类的路径。这些日志原本只用于会话恢复和上下文重建，包含每条消息、工具调用、执行结果与时间戳，因此可以被动地推断出某个 Agent 当前是在生成代码、等待工具返回，还是已经停在某处等待用户输入。相比让 Agent 自己汇报，读取这类日志的好处是零侵入：不改变 Agent 行为，不增加它的负担，也不依赖它“记得”上报。当然，代价是日志格式可能随版本变化，解析逻辑需要跟着维护，且跨平台路径差异较大。

名字来自一个废弃项目

Refmade这个名字比应用本身更早。2026年3月至7月间，Refmade是一个网页设计参考目录产品：Next.js应用、约83条参考、131次提交，还接入了支付。8月7日清理托管账户时，他将29个项目砍到12个，旧Refmade因绑定了自定义域名而幸免。9月21日，该域名被指向新的办公室仪表盘。画廊代码一行未留，留下的只是名字和一个因意外而保留的域名。

现状与后续

Refmade目前运行于Mac（Apple Silicon）和Windows，免费使用，前提是本机已安装并登录Claude Code或Codex。开发者表示，这一系列共16篇文章，每两天一篇，按真实事件顺序展开，失败与发布占同样篇幅，后续将覆盖失控的产品计划、无公证发布Mac应用、迟到的首次Git提交等。应用链接放在系列最后一篇。

对于在多终端运行Agent的开发者，一个值得自问的问题是：你现在靠什么知道哪个Agent正卡在等你？

文中提到的 Apple Silicon 指苹果自研的 ARM 架构芯片（M 系列），它与传统 Intel Mac 在运行环境、二进制兼容性和部分系统 API 上存在差异，因此桌面应用通常需要分别适配。无公证发布则指 macOS 的 Gatekeeper 机制：未经 Apple 公证（notarization）的应用在用户首次打开时会被系统拦截，需要手动绕过。对独立开发者而言，公证流程涉及开发者账号、签名和上传审核，是一道不小的门槛，这也是该系列把“无公证发布 Mac 应用”单独列为一篇的原因。