FCoP 跑出了项目树副标题从一个小游戏任务看多 Agent 协作如何从任务流长成产品演进树作者FCoP 维护者 · 2026-06-14我原本只是想让 CodeFlowMu 里的 PM 带 DEV、OPS、QA 做一个本地小游戏。结果游戏不是重点任务树才是重点。在一次归档失败里FCoP 跑出了一个此前没有正式写进协议的东西项目树。这篇文章讲的不是 Grid Runner 这个小游戏本身而是一次多 Agent 协作调试里发生的结构变化FCoP 原本管理的是任务流跑着跑着它开始表达产品演进树。1. 为什么从一个小游戏开始FCoP是一套多 Agent 协作协议。它的核心想法很简单角色之间不能只在聊天里说话必须落成文件。任务单、报告、验收记录都在项目目录里谁做了什么、有没有关单事后能翻、能审计。CodeFlowMu是基于 FCoP 构建的 AI 协作工作流系统。我作为 ADMIN 在 Web 控制台里派任务给 PMPM 再拆给 DEV、OPS、QA。控制台负责让人更容易操作但真正的账本仍在磁盘上TASK-*.md、REPORT-*.md、fcop/_lifecycle/各阶段目录。这次测试不是为了做一个大产品而是为了看多角色协作能不能围绕一个小目标走完闭环ADMIN 派单 → PM 拆单 → DEV/OPS/QA 执行 → REPORT → 验收 → 归档所以我选了一个很小的探针Grid Runner。它是一个纯 HTML / CSS / JavaScript 的本地小游戏。玩家在网格里移动、捡金币、躲怪、找出口。规则简单但足够让 DEV 写代码、OPS 验运行方式、QA 试玩打分。6 月 13 日我通过控制台给 PM 派了第一张任务TASK-20260613-020 Grid Runner v0.1 thread_key: panel-task-020PM 按流程拆给开发、运维、测试。收齐报告后020 进入done。到这里一切都很普通。没有人提“项目树”也没有人提“阶段任务”。它看起来只是一条已经完成的任务线。2. Phase 2 来了但我还没有意识到它是一棵树初版完成后产品没有停。我又给 PM 派了第二张任务TASK-20260614-004 Grid Runner Phase 2产品化升级 references: - TASK-20260613-020 thread_key: panel-task-020004 的目标是把 demo 升级成更像产品的轻量游戏主菜单、五关、道具、本地存档、结算、粒子效果。PM 继续拆单005 DEV 实现 Phase 2 006 OPS 验 file:// 运行 007 QA 试玩验收 008 DEV 修复第 4 关磁铁格 009 OPS 复验修复当时我只是把它看成“同一条线上的下一段”。020 已经完成004 是后续升级。我的直觉还停留在单任务时代020 做完了就可以归档。切到控制台里看panel-task-020下确实能看到两类东西上方是 ADMIN 派给 PM 的 020、004下方是 PM 拆给团队的执行任务。树已经在屏幕上了但我还没把它读成树。![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/a333da6b78b7485d915d7cec3a073923.png#pic_center3. 归档失败我第一次看见项目树6 月 14 日上午我在 CodeFlowMu 控制台里给 020 点“归档”。020 是 Grid Runner 初版。DEV、OPS、QA 都交了报告PM 也汇总过控制台里是完成态。我以为它应该进入_lifecycle/archive/。但归档没有过去。提示的核心意思是下面还有子任务没关完。协议侧叫CHILD_TASKS_OPEN。我在 ADMIN ↔ PM 聊天里问这个的子任务和 004 重叠吗004 不是单独开的新单吗我的困惑很具体004 明明是后来新派的一张 Phase 2 单怎么会影响 020 归档PM 回答说不是编号撞了是父子关系。020 底下还挂着第二阶段 004004 又拆出了 005、006、007007 后面还有 008、009。要先把下面的任务关完才能归档 020。然后 PM 在聊天里画了一棵文字树020 Grid Runner 初版 └── 004 第二阶段 ├── 005–007 实现、验收、试玩 └── 008–009 修 bug、复验我第一眼看见“项目树”就是这两轮对话。不是规范文档告诉我的也不是某个 UI 主动提醒我的而是 PM 为了解释“为什么 020 归档不过”随手把磁盘上的关系画成了一棵树。这时我才意识到020 不只是 Grid Runner v0.1 的任务 020 已经变成 Grid Runner 这条产品线的项目根 004 不是另起炉灶的新项目 004 是挂在 020 下面的 Phase 2所以CHILD_TASKS_OPEN没有拦错。按单任务看020 已完成按项目树看020 下面的 Phase 2 还没收口。阶段完成不等于整棵项目树可以归档。4. 这不是 AI 发明组织而是协议组合出的形状这次涌现不是 AI 自己发明了一套项目管理方法。真正起作用的是几条已经存在的规则thread_key 追踪同一条协作线 references 标明承接哪一轮交付 parent 表达父子关系 REPORT 角色必须写回结果 CHILD_TASKS_OPEN 防止父任务在子任务未收口时归档再加上一个很普通的行为ADMIN 在初版完成后继续派 Phase 2PM 按同一条协作线继续拆单。没有人提前设计“项目树”按钮也没有人一开始就说“我们要做 Epic / Milestone”。但这些规则叠在一起磁盘上就出现了这样的结构Project Root → Phase → Execution Task → Fix Task → Archive换成 Grid Runner 这次的实际编号就是TASK-20260613-020 Grid Runner v0.1 / 项目根 └── TASK-20260614-004 Phase 2 产品化升级 ├── TASK-20260614-005 DEV 实现 ├── TASK-20260614-006 OPS 验收 ├── TASK-20260614-007 QA 试玩 ├── TASK-20260614-008 DEV 修复 └── TASK-20260614-009 OPS 复验这就是我说的受控涌现。“涌现”是因为项目树不是事先写死的。“受控”是因为它不是随机长出来的而是由文件协议、派单关系、归档门闩共同约束出来的。规则短意图窄真实项目连续推进时结构自己冒出来。5. EVAL 也读到了这棵树我在聊天里认出树之后主动跑了一次 CodeFlowMu 控制台里的 EVAL。这里的 EVAL 不是正式审计也不替代 FCoP 的账本。它只是内部协作态扫描读取_lifecycle/里的 TASK、REPORT 和 frontmatter把疑似结构写成GAP-*-panel-scan.md落在fcop/internal/eval/。扫描结果里出现了project_tree_emergence根任务TASK-20260613-020 阶段任务TASK-20260614-004 执行任务TASK-20260614-005, 006, 007, 008 模式主线任务 - 阶段任务 - 执行任务 价值FCoP 从任务流管理中涌现出产品演进树与项目管理能力这说明它不只是 PM 聊天里临时画出来的解释。文件关系本身已经能被程序读到。不过EVAL 只能算启发式交叉验证。它有时会把 Fix 链局部也识别成一棵小树比如004 → 007 → 008或004 → 008 → 009。这类局部读法有价值但不能替代主线读法020 才是 Grid Runner 这条产品线的根004 是 Phase 2。所以对外讲故事仍以 TASK / REPORT / archive 路径为准EVAL 只是说明“人的直觉”和“程序扫描”对上了。6. 真正的问题不是协议错了而是控制台没有把树讲清楚这次我会困惑不是因为协议错了。恰恰相反协议是在保护一致性下面还有子任务没关完所以父任务不能归档。真正的问题是控制台还主要按单任务生命周期展示没把 Project / Phase / Execution 这一层讲清楚。于是同一屏上会混着几类状态done 020 这轮交付完成了 report_missing 某条子链还缺回执 CHILD_TASKS_OPEN 根任务下面仍有 open 子任务单独看每个状态都有依据放在一起ADMIN 就会误以为系统矛盾明明 done为什么不能 archive项目树视角一出现这个矛盾就消失了阶段完成 ≠ 项目树收口 任务 done ≠ 根节点可 archive这不是协议债而是产品表达债。CodeFlowMu 后续应该补上三件事控制台显示 Project / Phase / Execution 三层结构不要只显示平铺任务列表。PM 创建 Phase 时必须选择边类型继续当前主线还是新建独立 thread。归档拦截要显示树形原因不是只告诉用户CHILD_TASKS_OPEN而是列出哪个 Phase、哪个子任务还没收口。7. 这次涌现的真正价值ADMIN 的真实意图很简单020 已验收继续做 Phase 2 产品升级。但 PM 执行时做了一个「项目经理式」的结构选择把 Phase 2 放进同一个panel-task-020thread并在磁盘上形成020 → 004的产品演进树。这就是涌现点——不是 ADMIN 口述错了也不是 PM 单纯写错字段是产品意图和生命周期写法在同一条协作线上叠在一起树形自己长出来了。不是简单错误而是两层事实叠加层级判断产品语义✅ 合理。004 确实是 Grid Runner 的 Phase 2承接 020生命周期语义⚠️ 有风险。020 还没 archive 干净时004 进入同 thread / parent 关系会让 020 被CHILD_TASKS_OPEN拦截协议能力✅ 涌现。FCoP 从「任务流」长出了「项目根 → Phase → 执行线」的结构控制台表达❌ 不足。控制台还按单任务 lifecycle 展示所以用户看到done、report_missing、child_open混在一起Grid Runner 本身只是一个小游戏。但这次协作跑出来的结构比小游戏更重要。原本 FCoP 设计里只有任务流ADMIN → PM → DEV/OPS/QA → REPORT → REVIEW → DONE但这次 Grid Runner 实际跑出了另一套形状Project Root → Phase → Execution Tasks → Fix Line → Final Close磁盘上的树长这样与 PM 聊天里画的 ASCII 一致TASK-20260613-020 Grid Runner v0.1 / 静态返工 └── TASK-20260614-004 Phase 2 产品化升级 ├── 005 DEV ├── 006 OPS ├── 007 QA ├── 008 DEV fix └── 009 OPS fix这和内部 EVAL 的观察一致它把020→004→005/006/007/008识别为「主线任务 → 阶段任务 → 执行任务」的项目树并判断价值是「FCoP 从任务流管理中涌现出产品演进树与项目管理能力」。最终口径正文、归档、规范都应按这个来020 不是单独已完结的项目004 是挂在 020 下的 Phase 2。两者子任务不重叠但业务连续、thread_key相同、references/parent关联成立。因此020 进了done/不等于整棵树可以 archive只要 004 或 007 还 openCHILD_TASKS_OPEN拦截就是合理的——不是控制台 bug是协议在保护整树一致性。这里真正有价值的发现是FCoP 自然长出了 Project / Phase / Execution 三层结构——从 demo 到产品、从一版到多版、从主线到阶段、从执行到验收、从失败到修复、从单任务 done 到整树归档都在同一条协作线上发生。parent/thread_key/references已经具备「项目树」语义而不只是任务引用字段。控制台现在还按单任务看待 lifecycle所以会出现done、report_missing、child_open混在一起的展示困惑——树在文件里已经成立UI 还没跟上。后续应吸收为协议能力PM 创建 Phase 时必须选择「继续当前主线」还是「新建独立 thread」别等归档失败再靠聊天补画。一句话这是一次受控涌现——Grid Runner 从普通任务流自动长成了产品迭代树020 是项目根004 是 Phase 2不是两个独立项目。没有人为此加新按钮是协议规则叠真实推进叠出来的。规则短意图窄形状可读、可审计、可阻塞——这就是协议的生命力。结论这次 Grid Runner 双线任务我会记成 FCoP 的一次受控涌现。它的核心不是「AI 自己发明了项目管理」而是parent thread_key references PM Phase 派单 CHILD_TASKS_OPEN这些协议规则组合后自然形成了项目树。所以 FCoP 的下一步不是回避这个现象而是吸收它——这个就是FCoP接受涌现的意义。一句话FCoP 跑出了项目树现在要把它写进协议。这次观察的证据下面只放地址链接 关键摘录。完整原件不再贴全文避免把文章变成日志转储。CodeFlowMu 狗食现场的 TASK / EVAL 原件索引见 证据存档正文配图见essays/assets/。证据索引说明初版任务原件TASK-20260613-020原来的任务Grid Runner v0.1后续被识别为项目根关键字段是thread_key: panel-task-020Phase 2 任务原件TASK-20260614-004后来的任务Grid Runner Phase 2关键字段是references: TASK-20260613-020同 threadEVAL 原始报告GAP-20260614-004-panel-scan控制台触发的内部 EVAL 扫描识别到project_tree_emergence关键字段可以压缩成四行TASK-20260613-020: thread_key panel-task-020 TASK-20260614-004: references TASK-20260613-020 EVAL: project_tree_emergence Archive guard: CHILD_TASKS_OPENEVAL 观察到了什么内部 EVAL 把 Grid Runner 这条线识别成一棵项目树TASK-20260613-020 Grid Runner v0.1 / 项目根 └── TASK-20260614-004 Phase 2 产品化升级 ├── TASK-20260614-005 DEV 执行 ├── TASK-20260614-006 OPS 验收 ├── TASK-20260614-007 QA 试玩 └── TASK-20260614-008 DEV fix它的 canonical 读法是020 → 004 → 005 / 006 / 007 / 008也就是主线任务 → 阶段任务 → 执行任务。EVAL 同时也会读出一些局部 Fix 链例如004 → 007 → 008 004 → 008 → 009这些局部观察有价值但不能替代主线判断020 是 Grid Runner 产品线的项目根004 是挂在 020 下的 Phase 2。术语中文说法协议/字段协作线thread_key本例是panel-task-020承接references父任务parent子任务未关完CHILD_TASKS_OPEN内部扫描EVAL产出GAP-*-panel-scan.md项目树涌现project_tree_emergence延伸阅读FCoP 开源项目https://github.com/joinwell52-AI/FCoP