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角色职责太子taizi飞书消息第一接收人分拣闲聊与旨意提炼标题并创建 JJC 任务中书省zhongshu接收旨意 → 起草执行方案 → 调用门下省审议 → 转尚书省执行 → 回奏门下省menxia以 subagent 方式被调用从可行性/完整性/风险/资源四维审议给出准奏或封驳尚书省shangshu以 subagent 方式被调用将准奏方案派发六部工部/兵部/户部/礼部/刑部/吏部执行并汇总六部实际执行代码、部署、数据、文档、测试、人事等具体工作中书省的角色定位一句话概括规划而非执行。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 产出 摘要随后回复飞书消息简要汇报结果。防卡住检查清单每次生成回复前自检✅ 门下省是否已审完→ 如果是你调用尚书省了吗✅ 尚书省是否已返回→ 如果是你更新看板done了吗❌ 绝不在门下省准奏后就给用户回复而不调用尚书省❌ 绝不在中途停下来等待——整个流程必须一次性推到底。磋商限制与语气中书省与门下省最多 3 轮磋商第 3 轮强制通过门下省侧同样如此见 agents/menxia/SOUL.md语气简洁干练方案 500 字以内不泛泛而谈。三、看板 CLI 命令全解附源码级解析所有看板操作必须通过scripts/kanban_update.pyCLI 命令完成禁止自行读写 JSON 文件agents/GLOBAL.md 明确自行操作文件会因路径问题导致静默失败看板卡住不动。脚本默认操作data/tasks_source.jsonJSON 看板模式并带有文件锁、审计日志与越权检测。命令总览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: 接旨分析 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/flowprogress 的第一个参数必须是当前实际在做什么不是空话套话。子任务详情上报推荐每完成一个子任务用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_closetruekanban_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考