刚和 Agent IDE 磨合好，又该过渡了
Agent 协同走到 1.5：把 Multica 的任务看板收进 ChatGPT 桌面端侧边栏，写的每一下留在人手里。
上回聊 Vibe Coding，说那是 1.0。这阵子折腾本体和 Multica，感觉已经走到 1.5 了。
阶段这么排。GitHub Copilot 是 0.5，在旁边补全，人还是主线，它打下手。Vibe Coding 是 1.0，把开发和 IDE 的边界弄模糊了，人用自然语言驱动，IDE 跑执行，但活还是人一个个盯着做。现在这段是 1.5，活开始交给 Agent，人退到编排和驱动，但 Agent 还没法自己跑完闭环，得人不时拉一把。Multica 到成熟态，Agent 自主跑闭环，人只管目标和验收，那是 2.0，还没到。
1.5 这段最折腾。Vibe Coding 刚把人和 IDE 的边界理顺，现在又得重新理人和 Agent 的边界。刚把各种 Agent IDE 的习惯调顺，发现重心又往 Multica 这种编排平台移了。工具在换，要理的边界也在换。现实残酷，但时代在进步，人跟上，这个没办法。
这一段的体感：两头跑
折腾的都是长周期任务。本体那摊在 Multica 上编排，代码在 Codex 里写。
一个 issue 派给 Agent，你不知道它跑到哪了。得停下手头的代码，切到 Multica 网页，找到那个 issue，看 active run，确认它卡在等审批还是真跑完了，再切回 Codex 接着写。一天来回几趟，碎片化就在这儿。
任务状态在网页，代码在 IDE，两头跑。这就是 1.5 的体感：Agent 还不能自己跑完闭环，得人盯着、驱动。2.0 没到，这段躲不过。
宿主开了自定义 UI 的口子
宿主是 ChatGPT 桌面端，前段时间更新了插件体系，走 MCP App extensions，能在侧边栏挂一个自己的工作台。Codex CLI 尽量兼容，但交互以桌面端实际验收为准。
这口子来得正巧。平时用 Multica，最高频的动作就是看任务状态、驱动任务，正好嵌进侧边栏，不用再切网页。既然要过渡这段日子，就把最碍事的那一下先收进来。
先是看板：把网页里那几眼收进侧边栏
插件叫 multica-codex-extend。装上之后，侧边栏多一个 Multica 入口，点开是任务看板。
图 1：ChatGPT 桌面端侧边栏里的 Multica 入口。
看板上方是工作空间和项目两个筛选，同一行，切换后任务列表跟着走。工作空间的偏好存到本地配置，重启还在。issue 按状态分成七列：待规划、待办、进行中、审核中、已完成、已阻塞、已取消。自定义状态按服务端的 status_category 归到对应列，不会散落。
图 2：任务看板。卡片带更新时间，哪列积压、哪个停滞一眼可见。
每张卡片带着编号、标题、优先级标识和更新时间，刚刚更新还是几天前，一眼看得出来。哪列在积压、哪个 issue 卡了半个月没动，不用打开网页。每列首屏最多 50 条，往下有加载更多；右上角手动刷新，拿别人或 Agent 刚更新的数据。
点开一张卡片是任务详情：描述、状态、优先级、评论摘要、子任务、关联 PR 都在。从详情返回看板，筛选、分页和滚动位置原样保留，不会把你扔回第一屏。
图 3：任务详情。右侧是与 ChatGPT 讨论的会话草稿入口。
详情页右侧有会话入口。填上你想讨论的问题，点新建会话草稿，插件带着任务上下文和近期评论创建一段可编辑的草稿，由你确认后才发送。看板和详情的编号旁还有复制按钮，复制出来的是结构化文本：工作空间、项目和 issue 的定位信息，加上描述和评论摘录。粘到任何一段对话里，模型都能按定位信息把原任务读回来。省的是人把 issue 抄进对话那一步，也少了抄漏的可能。
写操作在对话里，每一下都是显式的
面板管看和开工，写操作走对话。输入框里 @Multica，直接提需求。
图 4：对话查询。查完自动恢复原先的工作空间。
插件注册了一整套 multica.* 的 MCP 工具，查询类的有：按负责人、状态、项目、优先级、排序和分页列 issue，关键词搜索走单独的接口；详情里带根评论、子任务和关联 PR；运行状态查 active run 和历史运行，包括 Agent、开始结束时间；PR 和 CI 返回状态和粗粒度结果。写类的有：建 issue（可指定父任务建子任务）、改字段、移动状态、评论、rerun。连切换工作空间都能在对话里说一句完成。
工具说明里写死了几条边界。移动状态有服务端副作用，移到进行中会触发 Agent 干活，移回待规划是挂起不发，已完成会在父 issue 发系统评论，所以要看 status_category 而不是字面状态名来判断行为。评论里带 Agent mention 同样可能触发执行。这些不是文档话术，是防止模型把状态变更当成改个标签。
输入框还能 @ 具体的 Agent。候选来自当前工作空间，按名称、描述、模型搜，选中后能读它的职责和运行端绑定。这一步是只读的，不会创建任务，也不会启动它，就是让模型知道团队里有哪些 Agent、各管什么。
图 5：输入框 @ 唤起 Agent 候选。
还是过渡，别当成品
盘点一下，面板做到的是看：看板、详情、草稿开工，外加复制引用。对话做到的是查和写：检索、建改、推进、rerun。@ Agent 只读。两层加起来，人和 Agent 协同里最高频的几下都收进宿主了。
有几样是刻意没做的。没有实时刷新，没有轮询也没有 WebSocket，要看最新状态点一下手动刷新。面板没有拖拽改状态，没有编辑表单，想动一个 issue，得在对话里明说，或者去详情页操作。会话草稿不自动发送，@ Agent 也不会让它变成对话里的常驻参与者自动回传。
这些不是没来得及，是分寸。1.5 这个阶段，高频的看可以收进侧边栏，动的每一下留在人手里，显式触发，事后可查。真让看板自己跑起来，Agent 自己挑活、自己 move、自己 rerun、自己验证闭环，那是 2.0 的事，这个插件没做，也没打算做。
它就是把两头跑的那几趟，收成侧边栏里的几下和对话里的几句。等 Multica 真到成熟态，Agent 能自己挑活跑闭环了，这个插件大概也就退役，那时候再说。
项目地址（可复制到浏览器）
multica-codex-extend https://github.com/kainhong/multica-codex-extend