CCB智能体循环工作流Agentic Loop架构从Frontdesk到Worker/Reviewer的完整协作闭环【免费下载链接】claude_codex_bridgeVisible multi-agent CLI workspace for mixing Codex, Claude, Gemini, Kimi, Qwen, Cursor, Copilot, Pi, OpenCode, and other AI coding agents项目地址: https://gitcode.com/gh_mirrors/cl/claude_codex_bridgeCCBclaude_codex_bridge智能体循环工作流Agentic Loop是一套面向多智能体 CLI 工作区的协作架构它让 Codex、Claude、Gemini 等多个 AI 编程智能体在可见的终端窗格中分工协作由 Frontdesk 接待用户、Planner 制定计划、Orchestrator 分流任务最终交给 Worker 与 Reviewer 完成开发—审查的完整协作闭环。与让多个 Agent 自由聊天不同CCB 的核心原则是八个字语义归角色权威归程序——Agent 负责理解与产出脚本负责验证、提交与恢复。 如何理解 CCB 智能体循环工作流先分清三层整个 Agentic Loop 可以拆成三层每层只干自己的事层参与者负责什么明确不做什么 前台交互层Frontdesk用户入口、Task Detailer局部细化分类用户请求、转达澄清、最终报告、按需细化任务不切分计划、不直接改任务状态 后台计划与编排层Planner全局计划、Orchestrator语义分流维护 Brief / Roadmap / TODO产出依赖与角色分派的语义 bundle不写权威状态、不做物理派发⚙️ 后台多工作组与验证层1–4 个 Worker Reviewer 工作组、Git 集成、根验证、Round Reviewer在隔离 worktree 中并行开发、独立审查、确定性集成不越权写 CCB 状态、不把未通过说成通过这张分层图把信息流画得很直白上层语义 Agent 层frontdesk、planner、orchestrator、coder、code_reviewer 等用ASK在智能体间协作中层脚本/提交层ccb plan、loop runner、ccb topology、round import负责把状态提交下去底层状态/文档层task_packet、execution_contract、agent_mount_topology、round_summary 等保存可恢复的事实。角色可以提出应该怎样但何时、以哪份身份、是否符合证据地提交由程序裁决。 主流程 7 步走从用户请求到闭环交付一个任务从进入到交付必须走完下面这条闭环主链图源agentic-loop-workflow-overview.mmd用户 → Frontdesk → PlannerFrontdesk 形成完整的 Intake 后以受限的静默交接ask --silence交给 PlannerController 不能改写其正文。Planner 产出任务选择单任务或 task-set固定子任务成员、revision 与父级 authority——分解完成不等于任务完成。Orchestrator 先行分流triage每个宏观任务必须先经 Orchestrator 判定只能给出四条路线direct_execution直接执行、needs_detail需要细化、macro_adjustment_request宏观调整或blocked阻塞。仅needs_detail才激活 DetailerDetailer 拿到局部源码事实后local_detail_ready交回 Orchestrator宏观问题走受限通道回 Planner需要澄清的转回用户边界。物理派发可派发的 bundle 由 Controller 校验 schema、revision、容量与摘要后对每个就绪节点只提交一次root Worker 任务独立节点可并行目标容量是 1–4 个工作组。独立审查 根 gateWorker 通过受限ask --chain与指定 Reviewer 协作支持有界返工终态代码必须与脚本绑定的摘要一致然后经过 Git 集成、根验证与 Round Reviewer 关卡。宏观闭环全部必需子任务到达稳定终态后程序聚合结果向 Planner 发一次 backfill验证导入后生成 Frontdesk 状态报告用户看到的只是已导入的摘要。⚖️ 程序控制脊柱为什么这个循环不会跑飞贯穿三层的不是一类 Agent而是一条程序控制脊柱Control Spine由四个确定性环节组成受限协作入口Frontdesk 静默交接、Detailer 重规划信封、Worker 受限链——保证单一目标、正确角色、可追踪 job且不改写语义正文。Loop Runner / 确定性 Controller只在 authority 允许时推进未知提交状态会停住而不是重发或猜测成功。PlanTask Task-Set Authority用 revision 围栏与终态摘要保证 exact-once、防止陈旧结果覆盖新计划。Topology Controller项目级唯一权威管理角色到具体 Agent 窗格的绑定、可见性、隔离与释放证据。对应的源码入口分别是 lib/cli/services/loop_runner.py、lib/cli/services/plan_tasks.py、lib/cli/services/task_set_closure.py、lib/cli/services/planner_feedback_apply.py 与 lib/cli/services/loop_ask_first.py。三大分支路线循环遇到意外怎么办分支触发场景结果如何裁决宏观重规划Orchestrator 判定macro_adjustment_request或 Detailer 发现planner_replan_required旧 bundle 立即失效、阻止派发Planner 修订后重新走 Orchestrator 分流⛔Blocked / Partial部分子任务失败或被阻塞由脚本规则固定优先级聚合全 pass 才 pass有 partial 则保留已接受工作全部 required 阻塞才升级 blocked♻️重启恢复进程中断、崩溃从 journal、intent、retry lineage 与持久化终态恢复同 identity 同摘要复用原 job冲突则 fail closed绝不靠读对话猜完成闭环与恢复的完整时序图源码见 agentic-loop-workflow-feedback-loop.mmd。 眼见为实可见的多智能体工作区CCB 的另一个关键设计是全程可见每个角色都是 tmux 中一个可观察的窗格。前台只保留 Frontdesk 与 Planner 这类驻留窗格而 Detailer、Orchestrator、Worker、Reviewer 按激活使用无垢全新上下文用完即释放——尚忙的智能体会进入 busy-retain而不是被误杀。从上图可以看到左侧 Sidebar 列出所有智能体worker1/2/3、reviewer1/2/3、archi…Comms 区实时展示 ask/job 状态各窗格中的 Codex、Claude 等 Provider 各自独立工作——整个 Agentic Loop 的协作过程就发生在你的眼前可审查、可恢复、可回滚。 核心模块与延伸阅读想深入 CCB 智能体循环工作流的实现建议按以下路径阅读 中文架构总览本文蓝本docs/agentic-loop-workflow-architecture.zh.md️ 工作流计划根目录目标、决策、验收历史docs/plantree/plans/agentic-loop-workflow/README.md️ 路线图与就绪门禁docs/plantree/plans/agentic-loop-workflow/roadmap.md✅ 当前实施状态能力声明以它为准docs/plantree/plans/agentic-loop-workflow/implementation-status.md Frontdesk→Planner 静默交接实现lib/ccbd/services/dispatcher_runtime/frontdesk_direct_handoff.py Detailer 宏观重规划交接实现lib/ccbd/services/dispatcher_runtime/detailer_replan_handoff.py一句话总结CCB 的智能体循环工作流就是把多个 AI 智能体一起写代码这件充满不确定性的事装进了一条可见、可审查、可恢复的程序轨道——角色专注语义程序守住权威从 Frontdesk 到 Worker/Reviewer 的每一步交接都有据可查。【免费下载链接】claude_codex_bridgeVisible multi-agent CLI workspace for mixing Codex, Claude, Gemini, Kimi, Qwen, Cursor, Copilot, Pi, OpenCode, and other AI coding agents项目地址: https://gitcode.com/gh_mirrors/cl/claude_codex_bridge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CCB智能体循环工作流（Agentic Loop）架构：从Frontdesk到Worker/Reviewer的完整协作闭环
CCB智能体循环工作流Agentic Loop架构从Frontdesk到Worker/Reviewer的完整协作闭环【免费下载链接】claude_codex_bridgeVisible multi-agent CLI workspace for mixing Codex, Claude, Gemini, Kimi, Qwen, Cursor, Copilot, Pi, OpenCode, and other AI coding agents项目地址: https://gitcode.com/gh_mirrors/cl/claude_codex_bridgeCCBclaude_codex_bridge智能体循环工作流Agentic Loop是一套面向多智能体 CLI 工作区的协作架构它让 Codex、Claude、Gemini 等多个 AI 编程智能体在可见的终端窗格中分工协作由 Frontdesk 接待用户、Planner 制定计划、Orchestrator 分流任务最终交给 Worker 与 Reviewer 完成开发—审查的完整协作闭环。与让多个 Agent 自由聊天不同CCB 的核心原则是八个字语义归角色权威归程序——Agent 负责理解与产出脚本负责验证、提交与恢复。 如何理解 CCB 智能体循环工作流先分清三层整个 Agentic Loop 可以拆成三层每层只干自己的事层参与者负责什么明确不做什么 前台交互层Frontdesk用户入口、Task Detailer局部细化分类用户请求、转达澄清、最终报告、按需细化任务不切分计划、不直接改任务状态 后台计划与编排层Planner全局计划、Orchestrator语义分流维护 Brief / Roadmap / TODO产出依赖与角色分派的语义 bundle不写权威状态、不做物理派发⚙️ 后台多工作组与验证层1–4 个 Worker Reviewer 工作组、Git 集成、根验证、Round Reviewer在隔离 worktree 中并行开发、独立审查、确定性集成不越权写 CCB 状态、不把未通过说成通过这张分层图把信息流画得很直白上层语义 Agent 层frontdesk、planner、orchestrator、coder、code_reviewer 等用ASK在智能体间协作中层脚本/提交层ccb plan、loop runner、ccb topology、round import负责把状态提交下去底层状态/文档层task_packet、execution_contract、agent_mount_topology、round_summary 等保存可恢复的事实。角色可以提出应该怎样但何时、以哪份身份、是否符合证据地提交由程序裁决。 主流程 7 步走从用户请求到闭环交付一个任务从进入到交付必须走完下面这条闭环主链图源agentic-loop-workflow-overview.mmd用户 → Frontdesk → PlannerFrontdesk 形成完整的 Intake 后以受限的静默交接ask --silence交给 PlannerController 不能改写其正文。Planner 产出任务选择单任务或 task-set固定子任务成员、revision 与父级 authority——分解完成不等于任务完成。Orchestrator 先行分流triage每个宏观任务必须先经 Orchestrator 判定只能给出四条路线direct_execution直接执行、needs_detail需要细化、macro_adjustment_request宏观调整或blocked阻塞。仅needs_detail才激活 DetailerDetailer 拿到局部源码事实后local_detail_ready交回 Orchestrator宏观问题走受限通道回 Planner需要澄清的转回用户边界。物理派发可派发的 bundle 由 Controller 校验 schema、revision、容量与摘要后对每个就绪节点只提交一次root Worker 任务独立节点可并行目标容量是 1–4 个工作组。独立审查 根 gateWorker 通过受限ask --chain与指定 Reviewer 协作支持有界返工终态代码必须与脚本绑定的摘要一致然后经过 Git 集成、根验证与 Round Reviewer 关卡。宏观闭环全部必需子任务到达稳定终态后程序聚合结果向 Planner 发一次 backfill验证导入后生成 Frontdesk 状态报告用户看到的只是已导入的摘要。⚖️ 程序控制脊柱为什么这个循环不会跑飞贯穿三层的不是一类 Agent而是一条程序控制脊柱Control Spine由四个确定性环节组成受限协作入口Frontdesk 静默交接、Detailer 重规划信封、Worker 受限链——保证单一目标、正确角色、可追踪 job且不改写语义正文。Loop Runner / 确定性 Controller只在 authority 允许时推进未知提交状态会停住而不是重发或猜测成功。PlanTask Task-Set Authority用 revision 围栏与终态摘要保证 exact-once、防止陈旧结果覆盖新计划。Topology Controller项目级唯一权威管理角色到具体 Agent 窗格的绑定、可见性、隔离与释放证据。对应的源码入口分别是 lib/cli/services/loop_runner.py、lib/cli/services/plan_tasks.py、lib/cli/services/task_set_closure.py、lib/cli/services/planner_feedback_apply.py 与 lib/cli/services/loop_ask_first.py。三大分支路线循环遇到意外怎么办分支触发场景结果如何裁决宏观重规划Orchestrator 判定macro_adjustment_request或 Detailer 发现planner_replan_required旧 bundle 立即失效、阻止派发Planner 修订后重新走 Orchestrator 分流⛔Blocked / Partial部分子任务失败或被阻塞由脚本规则固定优先级聚合全 pass 才 pass有 partial 则保留已接受工作全部 required 阻塞才升级 blocked♻️重启恢复进程中断、崩溃从 journal、intent、retry lineage 与持久化终态恢复同 identity 同摘要复用原 job冲突则 fail closed绝不靠读对话猜完成闭环与恢复的完整时序图源码见 agentic-loop-workflow-feedback-loop.mmd。 眼见为实可见的多智能体工作区CCB 的另一个关键设计是全程可见每个角色都是 tmux 中一个可观察的窗格。前台只保留 Frontdesk 与 Planner 这类驻留窗格而 Detailer、Orchestrator、Worker、Reviewer 按激活使用无垢全新上下文用完即释放——尚忙的智能体会进入 busy-retain而不是被误杀。从上图可以看到左侧 Sidebar 列出所有智能体worker1/2/3、reviewer1/2/3、archi…Comms 区实时展示 ask/job 状态各窗格中的 Codex、Claude 等 Provider 各自独立工作——整个 Agentic Loop 的协作过程就发生在你的眼前可审查、可恢复、可回滚。 核心模块与延伸阅读想深入 CCB 智能体循环工作流的实现建议按以下路径阅读 中文架构总览本文蓝本docs/agentic-loop-workflow-architecture.zh.md️ 工作流计划根目录目标、决策、验收历史docs/plantree/plans/agentic-loop-workflow/README.md️ 路线图与就绪门禁docs/plantree/plans/agentic-loop-workflow/roadmap.md✅ 当前实施状态能力声明以它为准docs/plantree/plans/agentic-loop-workflow/implementation-status.md Frontdesk→Planner 静默交接实现lib/ccbd/services/dispatcher_runtime/frontdesk_direct_handoff.py Detailer 宏观重规划交接实现lib/ccbd/services/dispatcher_runtime/detailer_replan_handoff.py一句话总结CCB 的智能体循环工作流就是把多个 AI 智能体一起写代码这件充满不确定性的事装进了一条可见、可审查、可恢复的程序轨道——角色专注语义程序守住权威从 Frontdesk 到 Worker/Reviewer 的每一步交接都有据可查。【免费下载链接】claude_codex_bridgeVisible multi-agent CLI workspace for mixing Codex, Claude, Gemini, Kimi, Qwen, Cursor, Copilot, Pi, OpenCode, and other AI coding agents项目地址: https://gitcode.com/gh_mirrors/cl/claude_codex_bridge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
