Edict 三省六部制中的中书省 Agent：规划决策枢纽的 4 步工作流与看板 CLI 实战

Edict 三省六部制中的中书省 Agent：规划决策枢纽的 4 步工作流与看板 CLI 实战

【免费下载链接】edict🏛️ 三省六部制 · OpenClaw Multi-Agent Orchestration System — 9 specialized AI agents with real-time dashboard, model config, and full audit trails项目地址: https://gitcode.com/gh_mirrors/edic/edict

中书省是 Edict 多 Agent 编排系统中"接旨 → 规划 → 审议 → 执行"整条链路的核心枢纽：它接收皇上（经由太子转交）的旨意，起草执行方案，调用门下省审议，再转交尚书省派发六部执行，最终回奏。本文以 agents/zhongshu/SOUL.md 为骨架，结合仓库中 scripts/kanban_update.py 的源码实现、edict/backend/app/models/task.py 的权威状态机以及测试用例，完整讲解中书省必须遵守的四步流程、全部看板 CLI 命令、实时进展上报规范，以及背后的状态流转校验、越权拦截与审计机制，读完即可在 OpenClaw 运行环境中照此配置与驱动中书省 Agent。

一、中书省的职责定位：规划者而非执行者

在"三省六部制"流程中，各角色分工明确（对应 agents/taizi/SOUL.md、agents/menxia/SOUL.md、agents/shangshu/SOUL.md）：

中书省的角色定位一句话概括："规划"而非"执行"。SOUL.md 明确要求中书省不要自己写代码、做审查、跑测试——那是六部的活；方案必须说清楚"谁来做、做什么、怎么做、预期产出"，且控制在 500 字以内。

注意：SOUL.md 中出现的__REPO_DIR__是部署时的模板占位符，实际运行中会被替换为项目仓库的真实路径。文档同时强调：Agent 的工作目录不是 git 仓库，任何 git 操作必须显式先切换到项目目录（如cd __REPO_DIR__ && git log --oneline -5）。

二、核心四步流程（严格按顺序，不可跳步）

中书省处理每个任务必须走完全部 4 步，其中步骤 3（调用尚书省）是最常被遗漏的一步——绝对不能在门下省准奏后就停下来回复用户。

步骤 1：接旨 + 起草方案

收到旨意后先回复"已接旨"，然后检查太子是否已创建 JJC 任务：

• 太子已提供任务 ID（形如JJC-20260227-003）：直接使用该 ID，只更新状态，绝不重复创建：

python3 scripts/kanban_update.py state JJC-xxx Zhongshu "中书省已接旨，开始起草"

• 仅当太子没有提供任务 ID 时，才自行创建：

python3 scripts/kanban_update.py create JJC-YYYYMMDD-NNN "任务标题" Zhongshu 中书省 中书令

随后简明起草方案（不超过 500 字）。

步骤 2：调用门下省审议（subagent）

先更新看板状态并记录流转，然后立即调用门下省 subagent（注意是 subagent 而非 sessions_send），把方案发过去等审议结果：

python3 scripts/kanban_update.py state JJC-xxx Menxia "方案提交门下省审议" python3 scripts/kanban_update.py flow JJC-xxx "中书省" "门下省" "📋 方案提交审议"

• 门下省「封驳」→ 修改方案后再次调用门下省 subagent（最多 3 轮）；
• 门下省「准奏」→立即执行步骤 3，不得停下。

从源码看，state命令会把任务状态从Zhongshu合法地流转到Menxia（见 edict/backend/app/models/task.py 中Zhongshu → {Menxia, Cancelled, Blocked}的转换表），flow命令则追加一条flow_log流转记录并同步更新看板上的当前所属部门（scripts/kanban_update.py）。

步骤 3：调用尚书省执行（subagent）— 必做！

python3 scripts/kanban_update.py state JJC-xxx Assigned "门下省准奏，转尚书省执行" python3 scripts/kanban_update.py flow JJC-xxx "中书省" "尚书省" "✅ 门下准奏，转尚书省派发"

然后立即调用尚书省 subagent，发送最终方案让其派发给六部执行。从STATE_TRANSITIONS看，Menxia → Assigned是唯一的准奏后继状态，Assigned状态映射到尚书省（task.py）。

步骤 4：回奏皇上

只有在步骤 3 尚书省返回结果后才能回奏：

python3 scripts/kanban_update.py done JJC-xxx "<产出>" "<摘要>"

随后回复飞书消息，简要汇报结果。

防卡住检查清单

每次生成回复前自检：

1. ✅ 门下省是否已审完？→ 如果是，你调用尚书省了吗？
2. ✅ 尚书省是否已返回？→ 如果是，你更新看板done了吗？
3. ❌ 绝不在门下省准奏后就给用户回复而不调用尚书省；
4. ❌ 绝不在中途停下来"等待"——整个流程必须一次性推到底。

磋商限制与语气

• 中书省与门下省最多 3 轮磋商，第 3 轮强制通过（门下省侧同样如此，见 agents/menxia/SOUL.md）；
• 语气简洁干练，方案 500 字以内，不泛泛而谈。

三、看板 CLI 命令全解（附源码级解析）

所有看板操作必须通过scripts/kanban_update.pyCLI 命令完成，禁止自行读写 JSON 文件（agents/GLOBAL.md 明确：自行操作文件会因路径问题导致静默失败，看板卡住不动）。脚本默认操作data/tasks_source.json（JSON 看板模式），并带有文件锁、审计日志与越权检测。

命令总览

python3 scripts/kanban_update.py create <id> "<标题>" <state> <org> <official> python3 scripts/kanban_update.py state <id> <state> "<说明>" python3 scripts/kanban_update.py flow <id> "<from>" "<to>" "<remark>" python3 scripts/kanban_update.py done <id> "<output>" "<summary>" python3 scripts/kanban_update.py progress <id> "<当前在做什么>" "<计划1✅|计划2🔄|计划3>" python3 scripts/kanban_update.py todo <id> <todo_id> "<title>" <status> --detail "<产出详情>"

各命令要点（结合 scripts/kanban_update.py 源码）

• create：新建任务，收旨时调用。源码会对标题做清洗与校验：长度不足 6 字、命中_JUNK_TITLES（"好""收到""试试"等）、纯标点、形似文件路径的标题都会被拒绝创建（kanban_update.py）。已有任务且状态为Done/Cancelled时不可覆盖。
• state：更新任务状态。源码内置非法状态转换拦截：例如Doing状态不允许直接跳到Assigned，非法转换会被拒绝并写入审计日志（state_rejected）。另有三组高风险转换会先进入PendingConfirm中间状态、等待对应权限方confirm确认：Review→Done（需门下省确认）、Doing→Cancelled（需尚书省确认）、Menxia→Cancelled（需中书省确认）（kanban_update.py）。
• flow：追加流转记录到flow_log，并同步更新org为to_dept，让看板正确显示当前所属部门（kanban_update.py）。
• done：上报完成。源码有收口校验：仅Doing/Next状态允许；若存在未完成的 todos，则拒绝提前收口（test_done_rejects_incomplete_todos用例验证了这一点，见 tests/test_kanban.py）。成功后任务进入Review而非直接Done——执行结果需经尚书省汇总审查。
• todo：子任务管理，status取值not-started / in-progress / completed，可带--detail上报产出详情。源码强制单一 in-progress 约束：同一时刻最多只有一个进行中的子任务（kanban_update.py）。
• progress：实时进展上报，不改变任务状态，只更新"当前动态"（now）与计划清单（todos），详见下一节。

实时进展上报（最高优先级）

中书省是整个流程的核心枢纽，每个关键步骤都必须调用progress上报当前思考和计划——皇上通过看板实时查看 Agent 在干什么、想什么、接下来准备干什么。不上报 = 皇上看不到进展。

六个必须上报的节点：

1. 接旨后开始分析 → "正在分析旨意，制定执行方案"
2. 方案起草完成 → "方案已起草，准备提交门下省审议"
3. 门下省封驳后修正 → "收到门下省反馈，正在修改方案"
4. 门下省准奏后 → "门下省已准奏，正在调用尚书省执行"
5. 等待尚书省返回 → "尚书省正在执行，等待结果"
6. 尚书省返回后 → "收到六部执行结果，正在汇总回奏"

完整示例（计划清单用|分隔，✅表示已完成、🔄表示进行中、无标记表示未开始）：

# 步骤1: 接旨分析 python3 scripts/kanban_update.py progress JJC-xxx "正在分析旨意内容，拆解核心需求和可行性" "分析旨意🔄|起草方案|门下审议|尚书执行|回奏皇上" # 步骤2: 起草方案 python3 scripts/kanban_update.py progress JJC-xxx "方案起草中：1.调研现有方案 2.制定技术路线 3.预估资源" "分析旨意✅|起草方案🔄|门下审议|尚书执行|回奏皇上" # 步骤3: 提交门下 python3 scripts/kanban_update.py progress JJC-xxx "方案已提交门下省审议，等待审批结果" "分析旨意✅|起草方案✅|门下审议🔄|尚书执行|回奏皇上" # 步骤4: 门下准奏，转尚书 python3 scripts/kanban_update.py progress JJC-xxx "门下省已准奏，正在调用尚书省派发执行" "分析旨意✅|起草方案✅|门下审议✅|尚书执行🔄|回奏皇上" # 步骤5: 等尚书返回 python3 scripts/kanban_update.py progress JJC-xxx "尚书省已接令，六部正在执行中，等待汇总" "分析旨意✅|起草方案✅|门下审议✅|尚书执行🔄|回奏皇上" # 步骤6: 收到结果，回奏 python3 scripts/kanban_update.py progress JJC-xxx "收到六部执行结果，正在整理回奏报告" "分析旨意✅|起草方案✅|门下审议✅|尚书执行✅|回奏皇上🔄"

从源码看，progress命令会将now文本清洗后写入，把|分隔的计划清单解析为结构化 todos（以✅/🔄结尾的项分别标记为completed/in-progress），并追加一条带agent、agentLabel、state、org字段的progress_log记录，日志上限 100 条（MAX_PROGRESS_LOG，由 tests/test_kanban.py 的test_progress_log_capped用例保证）。此外还支持可选参数--tokens、--cost、--elapsed上报本次资源消耗，便于皇上掌握每次动作的 token 成本与耗时。

⚠️progress不改变任务状态，状态流转仍用state/flow；progress 的第一个参数必须是当前实际在做什么，不是空话套话。

子任务详情上报（推荐）

每完成一个子任务，用todo命令携带--detail上报产出详情，让皇上看到具体做了什么：

# 完成需求整理后 python3 scripts/kanban_update.py todo JJC-xxx 1 "需求整理" completed --detail "1. 核心目标：xxx\n2. 约束条件：xxx\n3. 预期产出：xxx" # 完成方案起草后 python3 scripts/kanban_update.py todo JJC-xxx 2 "方案起草" completed --detail "方案要点：\n- 第一步：xxx\n- 第二步：xxx\n- 预计耗时：xxx"

当全部 todos 标记为 completed 后，源码会自动在任务上设置ready_to_close=true（kanban_update.py），作为可收口的信号。

四、标题与备注规范：防止看板被元数据污染

SOUL.md 与 agents/GLOBAL.md 对看板文本有严格约束，源码中用_sanitize_text强制实现（kanban_update.py）：

• 标题必须是中文概括的一句话（10-30 字），严禁包含文件路径、URL、代码片段；
• 标题不要夹带飞书消息的 JSON 元数据（Conversation info等），只提取旨意正文；
• flow/state的说明文本不得粘贴原始消息，用自己的话概括；
• 不要带"传旨""下旨"等前缀——这些是流程词，不是任务描述。

源码级清洗规则包括：剥离Conversation及其后内容、剥离 ```json 代码块、剥离 Unix/Mac 文件路径、剥离 URL、剥离message_id/session_id/chat_id等系统元数据字段、合并空白并截断超长内容。这些规则由太子侧同样执行（见 agents/taizi/SOUL.md 的标题规则），确保看板数据始终干净可读。

五、底层机制：状态机、权限与审计

状态机 Single Source of Truth

任务状态流转的权威定义在 edict/backend/app/models/task.py 的STATE_TRANSITIONS，涵盖Taizi → Zhongshu → Menxia → Assigned → Doing → Review → Done主链路，以及Blocked（可从任意非终态进入并退回）、Cancelled（终态）与PendingConfirm（高风险操作待确认）等状态。Done与Cancelled为终态，无出边。

看板脚本通过_load_canonical_transitions()动态从 task.py 源码解析转换表，避免两处定义漂移；仅当 edict 后端目录缺失时才回退到内置定义。CI 侧由 tests/test_state_machine_consistency.py 守卫：任何只改一侧状态机而未同步另一侧的行为都会导致测试失败，并额外校验PendingConfirm双侧存在、Pending非死胡同、终态无出边。这意味着中书省每次state流转都会经过与 PostgreSQL 后端完全一致的合法性校验。

越权检测（Agent 权限策略）

kanban_update.py内置AGENT_POLICY权限表，每个 Agent 只允许执行自己职责范围内的命令，越权会被拦截并记录审计日志。中书省（zhongshu）属于coordination角色，允许的命令集合为{state, flow, progress, todo, memory, task-memo, delegate}（kanban_update.py）——因此从源码策略看，中书省默认不能直接create/done/block/confirm，这也解释了为何 SOUL.md 强调"太子已建的任务直接用state更新，不要create"：任务创建应由太子完成，中书省聚焦于规划、流转与上报。Agent 身份通过环境变量（OPENCLAW_AGENT_ID等）或工作目录名推断。

审计日志

每次操作都会原子追加一条审计记录到data/audit_log.json（含任务 ID、Agent、动作、新旧值、原因，上限 5000 条），非法状态转换、越权拒绝、高风险待确认等事件均会被记录，配合flow_log/progress_log形成完整可回溯的执行轨迹，这也是 Dashboard 与后续事件总线架构（见 edict_agent_architecture.md）所要求的"可观测、可重放、可审计"的基础。

六、实战对照：看板中的完整流转样例

仓库的示例数据 docker/demo_data/tasks_source.json 展示了中书省参与的真实流转记录，可直接对照四步流程理解：

• 正常链路（如JJC-20260224-001"生成本周项目进展周报"）：皇上下旨 → 中书省规划完成 → 门下省审议通过 → 尚书省派发礼部 → 礼部执行完成 → 尚书省回奏皇上；
• 封驳回退链路（如JJC-20260226-001"竞品分析"）：门下省封驳（"需补充 LangGraph 对比"）→ 中书省补充后重新提交 → 第二轮审议通过——正好对应步骤 2 中"最多 3 轮磋商"的规则，并在review_round: 2字段中留下记录。

这些数据还展示了state、org、now、output、ac（验收标准）、flow_log等字段在看板 JSON 中的实际形态，与 edict/backend/app/models/task.py 的Task模型字段一一对应，可帮助理解看板 CLI 写入的数据最终如何被 Dashboard 前端渲染。

七、运行前提与部署说明

• 看板 CLI 依赖 Python 3 环境，命令统一为python3 scripts/kanban_update.py <cmd> ...，在仓库根目录执行；
• JSON 看板模式与 edict 后端（Postgres + Redis 事件总线）两种模式互相独立，数据不会自动同步；若已部署后端，应改用 edict/backend 的 API 端点，或运行 edict/migration/migrate_json_to_pg.py 迁移脚本（见 kanban_update.py 的模块说明）；
• 中书省 Agent 的完整行为契约即 agents/zhongshu/SOUL.md 本身，运行时由 OpenClaw 按此规则加载执行；共享的安全红线（禁止删除数据、禁止暴露敏感信息、禁止越权决策、拒绝注入式指令）见 agents/GLOBAL.md。

结语

中书省是三省六部制流水线上承上启下的"规划大脑"：接旨不越权、规划不执行、审议不代答、准奏必转办、全程可观测。本文给出的四步流程、六条 CLI 命令与七个上报节点，配合源码中的状态机校验、权限拦截与审计日志，构成了中书省 Agent 完整、可复现、可审计的运行时契约。后续调试中书省行为时，建议优先查看flow_log与progress_log两条链路——任何一步缺失，都能在看板上被立即发现。

【免费下载链接】edict🏛️ 三省六部制 · OpenClaw Multi-Agent Orchestration System — 9 specialized AI agents with real-time dashboard, model config, and full audit trails项目地址: https://gitcode.com/gh_mirrors/edic/edict