本篇进入日常使用阶段，重点不再是把系统启动起来，而是把任务真正跑顺。内容围绕下旨、流转、审议、派发、回奏这一条主线展开，把看板操作、任务干预、模板写法、模型切换、技能接入和真实案例串成一套完整流程。完成后，可以独立完成发任务、看进度、做干预、验收结果，并整理出适合团队长期执行的标准操作方式。

目前已整理为一组连续教程，分别对应部署启动、使用实战、二开扩展和封装版本使用四个方向。若希望完整了解该项目的源码运行方式、实际操作流程以及封装版本的使用方法，建议结合以下文章按需阅读。

文章	说明
【OpenClaw】Edict 三省六部制部署与启动	介绍 Edict 三省六部制的基础部署方式、运行环境准备和启动流程
【OpenClaw】Edict 三省六部制使用与实战流程	介绍系统启动后的主要使用方式、核心流程和实战操作思路
【OpenClaw】Edict 三省六部制二开与扩展	介绍项目在源码层面的二次开发、扩展思路和能力接入方式
AIGC工具平台-Edict 三省六部制 OpenClaw 集成封装版	介绍封装后的本地程序获取、启动配置、WebUI 访问和标准使用流程

核心概念

下旨、分拣、审议、派发、回奏

Edict 的日常使用可以理解成一条固定任务链。任务进入系统后，先由入口接收，再进入分拣与规划，然后进入审议节点，之后才会派发执行，最终形成回奏结果。真正的使用重点不是记住名词，而是理解每个阶段分别在解决什么问题。下旨解决输入质量，分拣解决任务归类，审议解决方向把关，派发解决执行落地，回奏解决结果沉淀。

正式任务通常会生成 JJC-* 类型的任务编号，会话类小任务通常是 OC-* 或 MC-*。在实际使用中，可以把 JJC-* 理解为主线任务，把其他编号理解为过程中的会话或子动作。典型流转状态通常会经过下面这条路径：

Taizi -> Zhongshu -> Menxia -> Assigned -> Doing -> Review -> Done

如果只想快速理解阶段含义，可以直接记住下面这组映射关系：

下旨：创建任务，明确目标与要求
分拣：判断任务归属与处理路径
审议：检查方案是否合理，必要时退回
派发：把任务交给具体执行单元
回奏：输出结果，进入验收与归档

一条“为 FastAPI 用户系统做安全审查与修复方案”的任务进入系统后，不会直接开始写代码。系统会先判断这是不是正式旨意，再由中书省拆解为审查项和输出要求，门下省检查方向是否合理，确认无误后才会派发执行，最后把修复建议、代码片段和检查结果汇总成回奏内容。

看板核心功能

看板不是只用来看结果，而是整个日常操作的主入口。任务创建、进度追踪、过程观察、模型调整、技能接入和结果查看，基本都围绕几个核心面板完成。把这些面板用顺，任务流转会清晰很多。

旨意看板

旨意看板是整套系统的主操作入口，主要承担任务创建、状态查看和过程干预三类工作。日常使用中，大多数正式任务都会从这里进入系统，也会在这里查看当前所处阶段、流转路径和处理结果。需要快速掌握任务全局情况时，通常先看这一页。

省部调度

省部调度用于展示各部门当前的运行状态，重点反映负载、活跃度、处理进度和异常情况。这一页更适合做调度层面的观察，便于判断任务积压是否发生在中书省、门下省，还是执行部门。遇到任务长时间停滞时，这里通常是排查的第一入口。

官员总览

官员总览更偏向执行单元的运行画像，主要用来查看不同 Agent 的活跃情况、资源消耗和调用表现。通过这一页可以快速判断哪些角色工作频繁，哪些角色当前空闲，哪些角色可能存在调用异常或成本偏高的问题。适合用于分析系统整体运行效率。

模型配置

模型配置用于管理不同 Agent 所绑定的模型。这里决定了各角色在实际处理任务时调用哪一种模型能力，因此会直接影响输出质量、响应速度和成本表现。需要针对不同任务类型做能力调整时，通常会在这一页完成切换和应用。

技能配置

技能配置用于统一管理系统中的本地 Skill 和远程 Skill。它的作用是为不同 Agent 提供额外能力，让任务处理不只依赖基础模型，而是能够调用更明确的专业能力。常见场景包括代码审查、文档处理、信息检索和特定流程能力接入。

小任务

小任务页面主要追踪 OC-* 和 MC-* 这类会话型或辅助型任务。与正式旨意任务相比，这些任务通常更轻量，更偏向过程中的子动作、补充处理或短链路交互。查看正式任务之外的细节过程时，这一页会更直观。

奏折阁

奏折阁用于查看任务完成后的最终产出与历史沉淀内容。无论是阶段性结果、最终总结，还是已经完成的任务记录，通常都会在这里集中展示。它更像结果归档区，适合用于验收、复盘和历史查询。

旨库

旨库是模板化下旨的管理区域，用来沉淀和复用高质量任务模板。对于重复性较高的任务类型，这里可以显著减少手动编写成本，也能让任务输入更规范，减少因描述不清导致的拆解偏差。适合长期沉淀团队常用任务范式。

天下要闻

天下要闻主要承担资讯订阅、消息聚合和推送管理相关功能。它更偏向外部信息输入层，用来把系统之外的动态内容纳入任务或通知链路中。涉及资讯观察、自动推送或事件驱动类场景时，这一页会比较常用。

日常使用中，最常驻的通常是 旨意看板、省部调度、模型配置 和 奏折阁。前者负责主流程操作，中间两个负责运行态管理，最后一个负责看交付结果。

需要查看一条任务为什么迟迟没有完成时，不应只停留在主看板。更有效的做法是先在 旨意看板 看当前状态，再到 省部调度 看对应部门是否拥堵，然后在任务详情中查看活动流和调度状态，最后到 奏折阁 检查是否已经生成了部分结果但尚未归档。

标准操作流

发任务 -> 追踪进度 -> 干预 -> 验收

日常使用最重要的不是单个按钮怎么点，而是形成稳定流程。高质量的使用方式通常都围绕四步展开，也就是发任务、追踪进度、人工干预和结果验收。只要这四步顺了，系统就不只是“能用”，而是进入“可控”的状态。

创建任务前，先确认系统已正常运行：

curl -s http://127.0.0.1:7891/healthz
curl -s http://127.0.0.1:7891/api/live-status

如果准备从接口创建任务，可以直接执行：

curl -X POST http://127.0.0.1:7891/api/create-task \
  -H "Content-Type: application/json" \
  -d '{
    "title":"审查支付模块安全风险并给出修复方案",
    "org":"丞相",
    "priority":"normal",
    "params":{"detail":"重点看鉴权、注入、日志脱敏"}
  }'

创建成功后，可以持续查询任务状态：

curl -s http://127.0.0.1:7891/api/live-status

如果要查看某一条任务的活动过程与调度情况，可以执行：

curl -s http://127.0.0.1:7891/api/task-activity/JJC-20260310-001
curl -s http://127.0.0.1:7891/api/scheduler-state/JJC-20260310-001

验收阶段通常需要同时检查三部分内容，也就是任务状态是否完成、回奏产物是否可用、日志中是否存在异常重试。只看最终页面而不看活动过程，很难判断任务到底是顺利完成，还是靠人工推进硬推过去的。

创建“审查支付模块安全风险并给出修复方案”后，先在主看板确认任务进入 JJC-* 主线，再观察是否从 Taizi 正常流向 Zhongshu。如果进入 Menxia 后被退回，说明方案需要修订而不是系统失败。任务进入 Doing 后，可以打开详情页看是否已有工具调用或分析结果。状态变成 Done 后，再到 奏折阁 核对最终输出是否真的满足最初要求。

模板下旨与高质量提示词写法

任务能不能跑顺，输入质量影响很大。很多任务卡住并不是模型能力不足，而是下旨内容过于模糊，导致中书省拆解不完整，门下省难以审议，执行阶段也没有明确交付标准。模板化写法的价值，就在于把输入变得稳定、可复用、可验收。

一条高质量旨意，建议至少包含背景、目标、范围、约束、输出格式和验收标准这几部分。可以直接使用下面这段模板：

请处理任务：{任务名}
背景：{业务背景}
目标：{明确产物}
范围：{包含}/{排除}
约束：技术栈={...}；时限={...}；质量标准={...}
输出：请按 {格式} 输出，并给出 {检查清单}
验收：满足以下条件才算完成：
1) ...
2) ...
3) ...

如果通过界面操作，可以在 旨库 中选择现成模板，再把变量替换成实际内容。如果通过接口创建任务，也可以把这段结构化内容直接放到 params.detail 中。

例如创建一条更完整的代码审查任务，可以写成这样：

curl -X POST http://127.0.0.1:7891/api/create-task \
  -H "Content-Type: application/json" \
  -d '{
    "title":"为 FastAPI 用户系统做安全审查与修复方案",
    "org":"丞相",
    "priority":"normal",
    "params":{
      "detail":"背景：用户系统即将上线；目标：输出风险清单与修复代码；范围：鉴权、SQL 注入、输入校验、敏感信息泄露；约束：技术栈为 FastAPI + PostgreSQL；输出：Markdown 报告 + 修复代码片段；验收：至少列出风险点、修复建议和示例代码"
    }
  }'

同样是“帮忙看下用户系统安全问题”，如果只写这一句，系统能拆解的信息非常少。改成“为 FastAPI 用户系统做安全审查与修复方案，重点检查鉴权、SQL 注入、输入校验、敏感信息泄露，并输出可直接落地的修复代码”，任务路径会稳定很多，回奏内容也更容易直接验收。

模型切换与任务管控

日常使用中，任务并不会永远一次成功。有的任务需要换模型重新处理，有的任务需要人工暂停，有的任务因为需求变更需要取消，有的任务则需要恢复继续执行。模型切换和任务管控的意义，就是让任务不只是自动流转，还能被运营和管理。

如果要切换 Agent 使用的模型，可以在看板中的 模型配置 页面操作，也可以在变更后重新应用配置。常见命令如下：

python scripts/apply_model_changes.py
openclaw gateway restart

如果任务已经创建，常见干预动作包括暂停、恢复和取消。接口调用示例如下：

暂停任务：

curl -X POST http://127.0.0.1:7891/api/task-action \
  -H "Content-Type: application/json" \
  -d '{"taskId":"JJC-20260310-001","action":"stop","reason":"等待新需求确认"}'

恢复任务：

curl -X POST http://127.0.0.1:7891/api/task-action \
  -H "Content-Type: application/json" \
  -d '{"taskId":"JJC-20260310-001","action":"resume","reason":"需求已确认"}'

取消任务：

curl -X POST http://127.0.0.1:7891/api/task-action \
  -H "Content-Type: application/json" \
  -d '{"taskId":"JJC-20260310-001","action":"cancel","reason":"需求已废弃"}'

如果任务卡在某一阶段，也可以尝试手动推进：

curl -X POST http://127.0.0.1:7891/api/advance-state \
  -H "Content-Type: application/json" \
  -d '{"taskId":"JJC-20260310-001","comment":"人工推进到下一阶段"}'

一条代码审查任务进行到 Doing 阶段时，产品需求发生变化，这时不适合让系统继续执行原方案。更稳妥的做法是先调用 stop 暂停任务，补充新要求后再 resume 恢复。如果需求已经完全失效，直接 cancel 比让任务继续跑到完成状态更合理。

Skills 使用（本地 + 远程）

Skills 的作用，是让系统在固定流程之外具备可扩展能力。本地 Skills 适合放稳定、常用、可控的能力，远程 Skills 适合快速接入共享能力或临时能力。日常使用阶段不需要一下子扩很多 Skill，关键是先把常用能力接入稳定。

查看已有渠道与技能配置后，可以按需接入新的远程 Skill。常见命令示例如下：

python3 scripts/skill_manager.py add-remote \
  --agent zhongshu \
  --name code_review \
  --source https://raw.githubusercontent.com/openclaw-ai/skills-hub/main/code_review/SKILL.md \
  --description "代码审查能力"

如果已经有本地 Skill，则更适合通过本地目录统一管理，让版本和内容都可追踪。远程 Skill 的优势是接入快，但日常使用中更需要关注版本稳定性，否则同一条任务在不同时间可能得到不同结果。

接入完成后，可以重新下发一条明确依赖该 Skill 的任务，观察执行链路是否有所变化。例如让中书省或执行部门显式调用代码审查能力，通常比只用通用提示词更稳定。

需要让系统稳定完成代码审查任务时，可以给 zhongshu 或相关执行单元增加 code_review 远程 Skill。完成接入后，再创建“审查支付模块安全风险并给出修复方案”这一类任务，活动流中通常会更容易看到围绕代码审查展开的处理过程。

完整一条任务链

真正掌握日常使用方式，最有效的办法不是只看单个命令，而是跟着跑完一条完整任务链。下面这条案例把创建、观察、干预、审议和验收串起来，更接近日常工作场景。

先创建任务：

curl -X POST http://127.0.0.1:7891/api/create-task \
  -H "Content-Type: application/json" \
  -d '{
    "title":"为 FastAPI 用户系统做安全审查与修复方案",
    "org":"丞相",
    "priority":"normal",
    "params":{
      "detail":"重点检查鉴权、SQL 注入、输入校验、敏感信息泄露，并输出修复代码"
    }
  }'

创建成功后，持续查询状态：

curl -s http://127.0.0.1:7891/api/live-status

如果任务进入审议节点，需要人工准奏或封驳，可以执行：

准奏：

curl -X POST http://127.0.0.1:7891/api/review-action \
  -H "Content-Type: application/json" \
  -d '{"taskId":"JJC-20260310-001","action":"approve","comment":"方案可执行，准奏"}'

封驳：

curl -X POST http://127.0.0.1:7891/api/review-action \
  -H "Content-Type: application/json" \
  -d '{"taskId":"JJC-20260310-001","action":"reject","comment":"修复范围不完整，退回补充"}'

如果执行阶段卡住，可以触发调度巡检：

curl -X POST http://127.0.0.1:7891/api/scheduler-scan \
  -H "Content-Type: application/json" \
  -d '{"thresholdSec":180}'

最后查看任务活动与调度状态：

curl -s http://127.0.0.1:7891/api/task-activity/JJC-20260310-001
curl -s http://127.0.0.1:7891/api/scheduler-state/JJC-20260310-001

这条链路跑完后，再去 奏折阁 核对最终报告、修复建议和代码片段是否完整。如果结果缺少关键部分，不应简单记为“完成”，而应回头检查下旨模板是否写得过于宽泛，或审议阶段是否放得过松。

一条“为 FastAPI 用户系统做安全审查与修复方案”的任务创建后，先在看板看到它进入 Zhongshu，说明拆解开始进行。进入 Menxia 后如果发现方案没有覆盖敏感信息泄露问题，可以直接封驳，让任务退回修订。修订后再次准奏，任务进入 Doing。如果执行过程中发现长时间无进展，可以触发巡检或人工暂停。最终在 奏折阁 看到修复建议、代码示例和验收说明，这条任务链才算真正闭环。

总结

本篇的重点是把“会用”升级成“用好”。真正稳定的日常使用方式，通常不是依赖个人经验，而是沉淀成可执行的团队 SOP。任务输入要模板化，过程追踪要常态化，人工干预要有标准动作，模型与技能变更要留记录，最终交付要能复盘。做到这些，Edict 才会从一个可运行的系统，变成一个可运营、可协作、可积累的多 Agent 工作台。

适合团队落地的日常做法，可以直接整理成下面这一组：

每日：巡检省部调度，检查 Blocked 与停滞任务，处理高优先级任务
每周：归档已完成任务，复盘封驳原因，优化下旨模板
持续：维护模型基线，管理 Skills 版本，沉淀高质量任务模板