大聪明军团：Codex Team Harness 与 OpenClaw Task Bridge

两套独立的本地多 Agent 工程系统：Codex Team 用来复现和验证长周期 coding harness，OpenClaw Task Bridge 用来稳定编排 OpenClaw agent 团队。

本仓库当前包含两个相互独立的功能：

Codex Team harness：面向 Codex 的 Planner / Generator / Evaluator 长周期开发 harness。它有自己的 run store、artifact、runner、状态机和 dashboard。
OpenClaw Task Bridge：面向 OpenClaw agent 团队的任务桥。它负责 Job、Task、Worker 队列、终态通知、follow-up 和防假死调度。

两者共享 task-bridge 这个 Python 包、CLI 入口和本地数据目录基础设施，但产品语义不同。Codex Team 关注“一个 Codex 团队如何完成长任务并被评审”；OpenClaw Task Bridge 关注“多个 OpenClaw agent 如何被稳定派发、回写和收口”。

Codex Team：长周期开发 harness

task-bridge codex-team 是一个面向长周期开发的 Codex Team。它不是把一个任务拆成一串机械小工单，而是让三个 Codex 角色围绕同一个本地 run home 协作：Planner 先把高层需求变成可验收的产品/工程 spec，Generator 连续完成一轮完整 build，Evaluator 再独立审查并给出修复意见或 final pass。

这个设计复盘了 Anthropic 在 Harness design for long-running application development 中总结的几个关键点：长任务需要清晰角色、文件化交接、独立 evaluator，以及能把主观质量变成可评审标准的反馈回路。Codex Team 保留这些有效结构，但把实现压到 task-bridge 能承载的最小形态：本地文件、JSON envelope、可恢复 runner、只读 dashboard。

核心流程：

User input
  -> Planner    产出 plan.md：目标、范围、验收、风险和实现边界
  -> Generator  完成完整 build round，写 implementation.md 和验证证据
  -> Evaluator  独立审查代码、测试、交互和 artifact，写 evaluation.md
       | pass        -> completed
       | needs_fix   -> Generator 进入下一轮修复
       | needs_design -> Planner 重新收敛设计
       | ask_user    -> paused，等待用户补充

设计原则：

角色分离：Generator 不给自己的实现盖章，Evaluator 独立判断是否通过。
文件化交接：input.md、plan.md、attempts/<n>/implementation.md、attempts/<n>/evaluation.md 是跨 session 的事实源，不依赖聊天上下文。
轻量路由：agent 只输出结构化 action envelope，dispatcher 负责校验、记录、唤醒、暂停和恢复。
完整 build round：Generator 默认连续推进一个完整能力边界，不把 helper、小测试修复和普通 bug 修复拆成昂贵的外部 handoff。
可观察 replay：dashboard 把每个 agent 调用、状态、耗时、route decision、artifact 和日志串成可审查的运行轨迹。
设计质量可评审：做 UI 时，Evaluator 必须从 Design quality、Originality、Craft、Functionality 四个维度提出具体意见，推动多轮迭代，而不是只检查代码是否能跑。

Codex Team 快速开始

# 真实启动 Codex Team run
task-bridge codex-team start --repo-root "$PWD" --input "实现一个小功能" --json

# 查看状态、日志和详情
task-bridge codex-team status <run_id> --json
task-bridge codex-team logs <run_id> --tail 20 --json
task-bridge codex-team show <run_id> --json

# 只验证 run store 和 CLI，不启动真实 Codex
TASK_BRIDGE_HOME=/tmp/task-bridge-codex-smoke \
  task-bridge codex-team start --repo-root "$PWD" --input "smoke test" --no-run --json

Codex Team Dashboard：复现实验的结果

task-bridge dashboard
# 打开 /codex-team 查看 run 列表与详情

Codex Team Dashboard 是一个针对 Codex Team harness 的测试任务：我们让 Codex Team 自己开发“查看一次任务中 agent 调用流程、运行时间、产出和 artifact 的 dashboard”，并要求 Evaluator 按 Anthropic 文章中强调的设计评审方式做多轮 UI 迭代。下面的截图展示的是这次复现 Harness design for long-running application development 后得到的结果。

这个 dashboard 更像一个 run replay console：列表页看 run 状态，detail 页优先展示 agent 调用链路、当前 route 和耗时，artifact 阅读器再承载大块 Markdown/日志内容。它本身就是 harness 是否有效的证据：Planner 定义 scope，Generator 连续实现，Evaluator 从 Design quality、Originality、Craft、Functionality 出发反复指出 UI 问题，最终产出更清晰的 run detail 和 artifact 阅读体验。

第一版分离后的 run 列表	迭代后的 run 列表

第一版已经能浏览 Codex Team run。	最新版改成更清晰的 run tape，强调状态、耗时、owner、attempt 和 route 信号。

第一版 run detail	迭代版 run detail

调用链路可见，但 route、当前步骤和 evidence 入口分散。	当前步骤、route decision、agent call flow、耗时和 evidence map 放到首屏，先看流程，再进详情。

第一版 artifact 阅读	迭代版 artifact 阅读

大 artifact 以预览文本为主，长文档阅读和跳转负担较重。	新版提供 artifact sidebar、section chips、metadata 和 rendered Markdown，更适合审查长产物。

OpenClaw Task Bridge：任务编排与终态通知

OpenClaw Task Bridge 是另一套功能。它面向 OpenClaw 的 Team Leader、Planning Agent、Code Agent、Quality Agent 和 Release Agent，目标是解决 IM / agent 协作里的派发、状态回写、终态通知和防假死问题。

Task Bridge Dashboard 预览

只需一条命令，即可将本地的 Job、Tasks、Worker Queue、Alerts 和 Health 状态转化为可视化看板：

task-bridge dashboard

作为人类协作者或 Team Leader，你可以通过 Dashboard 实时监控团队运作。以下为总览页与 Job 详情页示例：

Dashboard 总览	Dashboard Job 详情

上帝视角：查看任务状态分布、Agent 队列情况及系统健康度。	聚焦执行：集中查看特定 Job 的派发时间线、任务拆解与当前卡点。

Task 详情	跨语言支持

执行证据：直接审查事件时间线、最新结果摘要，及随任务附带的 Markdown 执行细节。	全面掌控：快速判断哪些 Job 正在推进、是否已收口。支持中英双语与本地字体切换。

为什么现有的方案行不通？

尝试使用 OpenClaw 组建 Agent 团队时，最核心的痛点往往不是缺少 Agent，而是 Agent 极难稳定地把控长周期的开发任务。

在构建 OpenClaw 多 Agent 工程团队时，业界通常会尝试以下两种主流方案。但在真实工程落地中，它们极易引发灾难性的工作流断裂：

1. 把“启动执行”误当成“完成执行”

做法：Team Leader 拆解任务后，让某个 Agent 再去启动外部长会话或异步执行通道。
痛点分析：在对接飞书等不支持长时间 Stream 的 IM 平台时，外部执行通道通常只能异步触发。这会引发严重的逻辑错位：Agent 刚发出启动指令，就立刻误以为自身工作结束，转头向 Leader 汇报“任务已完成”。这种将“任务启动”直接等同于“任务完成”的机制，会导致 Leader 过早进入验收或派发下一步任务，让多 Agent 工作流在起步阶段就彻底崩溃。

2. 让 Worker 只做转发而不拥有任务

做法：Worker 收到任务后，不直接执行，而是把任务再交给另一层执行流程。
痛点分析：真实工程中的需求开发，动辄需要几十分钟的深度上下文检索、代码生成与多轮纠错。如果 worker 只是转交任务而不负责状态回写，编排层就无法可靠知道任务是未开始、执行中、已完成还是失败。最终无人验证代码结果、无人回写终态、更无人通知 Leader，整个协作系统陷入“执行已完工，编排却永久停滞”的假死状态。

Task Bridge 的解决方案

task-bridge 放弃了用“瞬时聊天状态”承载长程任务的做法，将其重构成一个极简的本地任务状态机：

本地落盘的事实源：抛弃脆弱的聊天记录，所有的 Job、Task、State 全部以 JSON 格式落盘本地。
串行执行与异步转可控：同一 Worker 同时只执行一个任务，强制持续回写执行记录，把异步动作转化为可追踪的稳定任务流。
Skill-first 的直接执行：Worker 收到任务后先查看当前会话可用 skills；有匹配 skill 时优先使用该 skill 组织执行，没有匹配 skill 时再直接读仓库、跑命令并整理证据。
周期性防假死推进：Daemon 守护进程会定期提醒 Worker 推进任务，防止执行挂起。
精准的终态通知与自动化 Follow-up：仅在任务真正达到终态（done/blocked/failed）时主动唤醒 Leader，并对无人处理的终态任务自动催办，防止流水线停转。

完善的 Agent 团队阵容

引入了覆盖软件工程全生命周期的专业 Agent 团队。在 task-bridge 的编排下，团队职责分明：

Team Leader (协调者)：面向用户做高层决策、建单、证据回收和最终收口，不直接承担设计、实现、测试或发布执行。
Planning Agent (规划者)：负责需求澄清、高层 spec 收敛、验收口径与验证要求。
Code Agent (工程执行者)：负责实现级设计、代码阅读、根因调查、实现、修复、重构、测试与提交。
Quality Agent (质量评估者)：负责 plan evaluation、implementation evaluation、独立评审、QA、风险分级和必要的小范围修复。
Release Agent (交付执行者)：负责发布准备、PR/部署/上线验证、回滚口径和文档同步。
Task Bridge (任务中枢)：确定性的任务账本，负责存储状态、串行派发、终态通知。

运转机制

User ──> [Team Leader] ──规划──> [Planning Agent] 
             │                          │
      (建立/拆解 Job & Tasks)            │
             │                          │
             ▼                          ▼
     ================ [Task Bridge Daemon] ================
     | (核心中枢：在后台监督队列，将任务分发给空闲 Worker)  |
     ======================================================
             │                          │
        (派发任务)                 (派发任务)
             ▼                          ▼
       [Code Agent]  <──协同──>  [Quality Agent] ──> [Release Agent]
        (实现与修复)             (测试与代码审查)        (文档与发布)
             │                          │
             └──────(回写进度与终态通知) ──┘

快速开始（人类视角）

对人类用户而言，你不需要手动敲击繁琐的命令行来管理任务。只需配置好环境并启动 Daemon，剩下的只需和 Team Leader 聊天即可。

1. 配置与安装

你需要将本仓库提供的 Agent Prompt 配置到 OpenClaw，并安装 task-bridge 到 Agent 环境。本项目只负责 agent 定义、任务编排、状态流转、证据回收和收口，不负责配置或验证底层执行环境：

# 在仓库根目录执行最小安装
python -m pip install -e .

(注：若修改了 pyproject.toml 或入口，请重新执行此命令。)

planning-agent、code-agent、quality-agent、release-agent 都被视为可直接执行任务的 Agent。Worker 收到 task 后先查看当前会话可用 skills；有匹配 skill 时优先使用该 skill，没有匹配 skill 时再直接阅读仓库、运行命令并整理证据。

最佳实践：让 AI 帮你配置 将文档提供给 OpenClaw 的 default-agent 或 Claude Code 代劳：

中文保姆级教程：docs/zh/openclaw-agent-setup.md
English Setup Guide：docs/en/openclaw-agent-setup.md

2. 启动 Task Bridge Daemon (后台守护)

配置完成后，让任务中枢在后台运行：

task-bridge daemon --poll-seconds 10 --worker-reminder-seconds 900 --leader-reminder-seconds 3600

Daemon 会自动写入 ~/.openclaw/task-bridge/daemon.pid、daemon_heartbeat.json 和 daemon_errors.jsonl。它还会持有本地 lock，避免同一个数据目录启动多个 daemon。

参数说明：

--poll-seconds 10: 轮询队列间隔（默认 10 秒）。
--worker-reminder-seconds 900: Worker 防挂起提醒间隔（默认 15 分钟）。超时未更新则提醒 Worker 推进。
--leader-reminder-seconds 3600: Leader 长程任务关注提醒间隔（默认 60 分钟）。防止 Leader 失去对执行状态的感知。
--leader-followup 300: 终态任务催办窗口（默认 5 分钟，0 表示禁用）。若收到终态后迟迟未下发新任务，主动合并成一条提醒催促 Leader。

查看后台状态：

task-bridge daemon-status --json

持久化运行 (nohup):

mkdir -p .task-bridge
nohup task-bridge daemon \
  --poll-seconds 60 \
  --worker-reminder-seconds 2700 \
  --leader-reminder-seconds 7200 \
  --leader-followup 1800 \
  > .task-bridge/daemon.log 2>&1 &

(停止时优先用 task-bridge daemon-status --json 查看真实 pid，再执行 kill <pid>。)

3. 开启 Dashboard (只读，可选)

# 默认监听 127.0.0.1:8000
task-bridge dashboard

# 或指定监听地址与端口
task-bridge dashboard --host 127.0.0.1 --port 8000

注：Dashboard 仅读取本地数据，不提供写操作，适合用于审计、定位卡点与日常检查。

4. 给 Team Leader 下发需求

在你的 IM（如飞书）或终端中，直接对 Team Leader 对话：

"我们需要开发一个包含用户认证的 Python CLI 工具，覆盖率要求 80%，让 Planning Agent 先出方案，然后安排 Code Agent 动工。"

接下来，Team Leader 会自动拆解任务，Daemon 会按队列向各路 Agent 派发任务，完成最终交付。

补充材料：CLI 工具箱 (面向 Agent / 调试)

注意：以下命令主要供 Agent 在后台调用（如回写进度），人类平时无需执行，仅用于 Debug 或强制干预。

常用调试命令

# 查看队列与状态
task-bridge list-tasks --json
task-bridge worker-status --json
task-bridge queue code-agent --json
task-bridge daemon-status --json

# 单次派发测试 (不启动 Daemon 时)
task-bridge dispatch-once --json

# 历史终态任务补标，不向真实 agent 发送消息
task-bridge notify-backfill --mark-only --json

# 查看 Codex Team harness 命令
task-bridge codex-team -h

本地数据模型

任务结构清晰透明，方便人工随时审查 ~/.openclaw/task-bridge/：

current_job
daemon.pid              # 当前 daemon 进程信息；daemon 正常退出时自动清理
daemon_heartbeat.json   # 最近一轮 daemon 心跳、pid 和 phase_errors
daemon_errors.jsonl     # daemon phase 错误与 daemon_state 损坏记录
daemon_state.json       # reminder / notify / heartbeat 的持久状态
jobs/<job_id>/
  ├── job.json            # 完整工作主题
  ├── tasks/
  │   └── <task_id>.json  # 最小执行单元
  └── artifacts/
      └── <task_id>/
          └── detail.md   # (可选) 完整的执行细节。终态通知时将自动附带。
codex-team/
  └── runs/
      └── <run_id>/
          ├── metadata.json
          ├── events.jsonl
          ├── next_action.json
          ├── input.md
          ├── plan.md
          ├── plan_evaluation.md
          └── attempts/
              └── 001/
                  ├── implementation.md
                  └── evaluation.md

核心命令清单

类别	命令	说明
任务编排	`create-job`, `list-jobs`, `show-job`, `use-job`, `current-job`	管理宏观工作主题 (Leader 使用)
任务管理	`create-task`, `list-tasks`, `show-task`, `update-task`, `delete-task`	管理具体执行步骤
Worker 状态	`claim`, `start`, `update-result`, `complete`, `block`, `fail`	Worker 回写进度与终态 (各路 Agent 使用)
Bridge 调度	`worker-status`, `queue`, `dispatch-once`, `notify`, `notify-backfill`, `daemon`, `daemon-status`	派发、通知补标、系统守护与后台健康检查
Codex Team harness	`codex-team start/status/show/logs/answer/resume/cancel`	创建、查看、恢复与取消 Codex Team run

Codex Team harness（实验性）

codex-team 是一个面向 Codex 团队开发的 harness 子系统。它复用 TASK_BRIDGE_HOME、CLI、原子 JSON 写入和测试基建，保存自己的 run metadata、events、next action、plan、implementation 和 evaluation artifacts。

Codex Team 采用 round harness：Planner 产出完整高层 spec，Generator 连续完成完整 build round 后用 ready_for_review -> evaluator 交给 Evaluator，Evaluator 做 round-level review 并给出聚合修复意见或 final pass。局部 helper、schema、测试或小修复不再作为外部评审点。

常用命令：

task-bridge codex-team start --repo-root /path/to/repo --input "实现一个小功能" --json
task-bridge codex-team status <run_id> --json
task-bridge codex-team show <run_id> --json
task-bridge codex-team logs <run_id> --tail 20 --json
task-bridge codex-team answer <run_id> --text "缩小到 CLI 路径" --json
task-bridge codex-team resume <run_id> --json
task-bridge codex-team cancel <run_id> --reason "用户取消" --json

resume 仅用于恢复 failed run 中可重试的 runner 级失败，例如 Codex 认证中断、runner 超时、runner lock 或缺失最终 envelope。它会优先从失败 stdout 日志中的 thread_id 执行 codex exec resume <thread_id>；没有可用 thread 时，回退为重跑当前 owner。paused run 仍使用 answer，协议或固定 artifact 错误默认不会 resume。

如果只想验证 run store 和 CLI，不启动真实 Codex，可使用：

TASK_BRIDGE_HOME=/tmp/task-bridge-codex-smoke \
  task-bridge codex-team start --repo-root "$PWD" --input "smoke test" --no-run --json

调度可靠性机制

派发前会检查 worker 是否已有 running task、是否还在等待 claim、是否处于 cooldown、是否已被真实派发失败阻断。
真实 /reset 或发送失败不会杀掉 daemon；Bridge 会记录 last_dispatch_error、递增 dispatch_failure_count，并按退避窗口稍后重试。
连续真实失败达到阈值后，task 会进入 dispatch_blocked，避免无限重启同一个 worker 会话。修改 queued task 的 requirement 或 assigned_agent 会清理这组失败字段。
OpenClaw 进程预算满时会返回 process_budget 并进入短暂 deferred，不算真实失败，不会触发 dispatch_blocked，也不会在 /reset 前打断活跃会话。
notify_updates() 默认只处理 current job，历史终态任务需要显式执行 notify-backfill --mark-only 或 notify-backfill --summary，避免旧任务批量打扰 team-leader。
TASK_BRIDGE_CAPTURE_FILE 模式会绕过真实 OpenClaw 投递和进程预算检查，只把 /reset、dispatch、notify 消息写入 JSONL，适合安全 E2E 测试。

环境变量与进阶配置

系统会自动从当前工作目录 .env 或 ~/.openclaw/.env 读取变量：

TASK_BRIDGE_USER_CHAT_ID：注入通知 Prompt 的用户 chat_id（通知链路强依赖）。

以下变量需要通过 Shell 或前缀显式注入：

TASK_BRIDGE_HOME：自定义数据目录（默认 ~/.openclaw/task-bridge）。
TASK_BRIDGE_CAPTURE_FILE：拦截发送动作并写入文件，适合做隔离的 E2E 测试。
TASK_BRIDGE_OPENCLAW_MAX_GLOBAL：允许同时存在的全局 openclaw agent 进程数（默认 2，0 表示不限制）。
TASK_BRIDGE_OPENCLAW_MAX_PER_AGENT：允许同一 agent 同时存在的 openclaw agent 进程数（默认 1，0 表示不限制）。
TASK_BRIDGE_OPENCLAW_RESET_TIMEOUT_SECONDS：/reset 命令最大等待秒数（默认 60）。
TASK_BRIDGE_DASHBOARD_SSH_TARGET：覆盖 dashboard 启动提示中的 SSH 目标地址，不影响实际监听。

参考指南

想要将这套工作流完美融入你的环境，请查阅：

设计与实现参考：

开发与测试指引

# 1. 源码运行 (不依赖 PATH)
PYTHONPATH=src python -m task_bridge create-job --title "Dev task"

# 2. 运行 Python 测试
python -m pip install -e .[test] pytest
python -m pytest -q

# 3. 运行 Dashboard Playwright 测试
npm install
npm run playwright:install
npm run test:playwright

Task Bridge 哲学：它不是一个大而全的平台，而是一个极简的任务桥梁。它的核心价值在于让你的 Agent 团队不再失联，让 AI 协作真正落地跑通！至于具体 Prompt 如何设计、如何接入传统脚本 Worker，完全由你自由扩展。

Name		Name	Last commit message	Last commit date
Latest commit History 109 Commits
agents		agents
artifacts/ui-polish-20260321		artifacts/ui-polish-20260321
docs		docs
specs		specs
src/task_bridge		src/task_bridge
tests		tests
.env.example		.env.example
.gitignore		.gitignore
AGENTS.md		AGENTS.md
README.en.md		README.en.md
README.md		README.md
package-lock.json		package-lock.json
package.json		package.json
playwright.config.js		playwright.config.js
pyproject.toml		pyproject.toml

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

大聪明军团：Codex Team Harness 与 OpenClaw Task Bridge

Codex Team：长周期开发 harness

Codex Team 快速开始

Codex Team Dashboard：复现实验的结果

OpenClaw Task Bridge：任务编排与终态通知

Task Bridge Dashboard 预览

为什么现有的方案行不通？

1. 把“启动执行”误当成“完成执行”

2. 让 Worker 只做转发而不拥有任务

Task Bridge 的解决方案

完善的 Agent 团队阵容

运转机制

快速开始（人类视角）

1. 配置与安装

2. 启动 Task Bridge Daemon (后台守护)

3. 开启 Dashboard (只读，可选)

4. 给 Team Leader 下发需求

补充材料：CLI 工具箱 (面向 Agent / 调试)

常用调试命令

本地数据模型

核心命令清单

Codex Team harness（实验性）

调度可靠性机制

环境变量与进阶配置

参考指南

开发与测试指引

About

Uh oh!

Releases

Packages

Uh oh!

Contributors

Uh oh!

Languages

Folders and files

Latest commit

History

Repository files navigation

大聪明军团：Codex Team Harness 与 OpenClaw Task Bridge

Codex Team：长周期开发 harness

Codex Team 快速开始

Codex Team Dashboard：复现实验的结果

OpenClaw Task Bridge：任务编排与终态通知

Task Bridge Dashboard 预览

为什么现有的方案行不通？

1. 把“启动执行”误当成“完成执行”

2. 让 Worker 只做转发而不拥有任务

Task Bridge 的解决方案

完善的 Agent 团队阵容

运转机制

快速开始（人类视角）

1. 配置与安装

2. 启动 Task Bridge Daemon (后台守护)

3. 开启 Dashboard (只读，可选)

4. 给 Team Leader 下发需求

补充材料：CLI 工具箱 (面向 Agent / 调试)

常用调试命令

本地数据模型

核心命令清单

Codex Team harness（实验性）

调度可靠性机制

环境变量与进阶配置

参考指南

开发与测试指引

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Packages