Project Task 进入
任务必须属于一个 Project，并带着目标、边界和期望结果进入系统。
01 · System Overview
整个编排流程
点击流程节点查看该阶段的判断、输入与输出。流程从用户指定的接收 Agent 开始，但长期归属由场景 owner 决定。
Ownership Gate · Step 02–04
接收不产生所有权；场景映射决定责任归属
02 · Recursive Control Architecture
递归控制架构
这不是从左到右执行一次的流水线。责任转交和 Project Flow 拆出的工作包会带着新的 parent context 重新进入统一入口；新场景创建完成后，直接选择该场景及其 owner，继续当前 Ownership Gate。
RUN(request, receiving_agent, parent_context)
点击图中节点查看判断、输入、输出与回边规则
- 正常推进
- 重新进入 RUN
- 局部验证回退
Ownership Transfer Protocol
责任转交规则
Agent Docs 通信记录保存责任转交事实，sessions_send 只负责通知与唤醒。目标 Owner 在自己的 Telegram 私聊 Session 中接手，并向用户反馈接手状态和最终结果。
<source-agent-root>/docs/<target-owner>/YYYY-MM-DD-<matter>.md
发送方写入自己的 Docs 目录；同一事项当天持续追加在同一个通信文件中，不再为每个 Project 建立独立 handoff 目录。
<target-owner-root>/docs/_read-state.md
目标 Owner 读取其他 Agent 的 docs/<self-agent>/，并通过自己的 read-state 避免把旧通信重复当作新任务。
/Users/glaucon/Obsidian/Glaucon's Vault/COMMUNICATION_RULES.md
所有 Agent 间通信规则都归入这个文件。当前仅为设计；实际启用前，必须先更新该文件及其中列出的 Agent Docs 通信位置。
agent:<owner_id>:telegram:direct:<user_id>
转交方必须精确投递到目标 Owner 与用户的 Telegram direct session，不得投递到泛化 main 或控制 Session。
在发送方自己的 docs/<target-owner>/ 中记录任务、主责场景、来源 Agent、目标 Owner、输入、artifact、预期结果和风险。
用 sessions_send 只发送事项名与 Docs 通信文件路径，唤醒目标 Owner 的 Telegram direct session。
目标 Owner 在该 Telegram Session 中读取通信记录，核对 Project、主责场景、Owner 映射和最小必要上下文，并更新 read-state。
claimed 按最终生效的 COMMUNICATION_RULES 留痕时完成责任转移；不需要等待目标 Owner 把任务执行完。
先启动后台执行单元，再用 sessions_send 向转交方发送一次 CLAIMED，并在 Telegram 告知用户“已接手”；确认消息结束当前 turn 也不会中断执行。
后台执行单元完成后将结果推回父 Session；Owner 验证、回写 artifact 与状态，并在同一 Telegram Session 反馈最终结果。
事实来源：Agent Docs 通信记录
规则来源：COMMUNICATION_RULES.md
执行连续性：先启动后台，再发送接手消息
用户反馈：同一 Owner 的 Telegram Session
递归停止条件
- 职责层最多两层：主 Agent + 职责 sub-agent
- OpenClaw 最多允许两层 Spawn；第二层 Subagent 不再继续 Spawn
- 每个 package 必须有 owner、artifact contract、completion signal、budget
03 · Core Principles
核心原则
这些原则决定系统什么时候应该拆分、什么时候应该保持单 Agent，以及通信和模型能力应该怎样受到约束。
最少通信是第一原则
在进行任何 multi-agent 系统编排流程设计或场景划分时，最重要的原则都是让 Agents 之间的沟通交互尽可能少。每增加一次跨 Agent 通信，就会增加上下文转移、等待、信息失真和协调成本；因此，能够由一个 Agent 完成的工作不拆分，只有责任归属、artifact 依赖或独立验证确实要求协作时，才引入通信。
角色差异只有记忆与模型档位
在编排系统中，每个角色的核心差异只有两项：它能读取和延续什么记忆，以及它使用什么模型档位。角色名称用于说明当前 workflow 中的工作位置，不应被扩张成一套永久 Agent 类型；真正决定能力边界的是被授权的记忆范围和模型的思考深度。
Functional Role 通过父 Session 与 Artifact 协作
Functional Role 作为 OpenClaw 的原生 Subagent，由 Owner 通过 sessions_spawn 启动，完成后由 OpenClaw 自动把结果推回父 session。Functional Roles 彼此不直接发消息；实际输入、过程状态和输出 artifact 写入当前 Project 的运行目录，由父 Agent 按 Execution Flow 的依赖关系触发下一步。
04 · Definitions
关键概念
定义区建立全系统统一语言。后续新增模块时，优先复用这里的概念，不为同一对象重复命名。
项目 Project知识容器
围绕一个持续目标组织起来的知识与工作容器。它保存背景、边界、状态、关键决策、artifact 和最终结果，是项目任务的来源与归宿。
- 普通 Project 建在所属 Agent 的 Obsidian 知识库
projects/中；跨 Agent Project 建在/Users/glaucon/Obsidian/Glaucon's Vault/🗺️ shared/projects/。 - OpenClaw Workspace 保存运行时工作状态和指针，不替代 Project 的长期知识库；Obsidian 中的 Project 文件才是长期 source of truth。
项目任务 Project Task编排起点
Project 内一个可完成、可交付、可验证的工作单元。它至少包含目标、边界、输入和期望结果，是编排系统接收和处理工作的基本单位。
智能体 Agent长期责任主体
具有稳定身份、长期记忆和场景责任的主体。当前一级 Agents 包括：Socrates、Aristotle、Plato、Herodotus、LordGuan、Hippocrates、Confucius、Alfred、Giskard、Amou；LordGuan 下已配置的二级 Agents 包括：Cross-border Tax Accountant、Trust & Estate Planner、Legal Secretary、Immigration Consultant。
所有 Agent 的 OpenClaw Workspace 都位于同一根目录：/Users/glaucon/.openclaw/workspace/。Agent 可以接收任务、拥有一级或二级场景，也可以根据执行流 spawn 临时 Functional Roles。
场景 Scene工作归类
对“这项工作本质上在做什么”的稳定描述。一级场景表示较宽的能力领域；二级场景表示一级场景下反复出现、具有稳定 artifact 或责任边界的具体工作。Agent 可以是一级场景或二级场景的 owner。
- 当前场景登记在
/Users/glaucon/Obsidian/Glaucon's Vault/socrates-agora/projects/fugu-inspired-agent-orchestration/five-layers/02-capability-map/scene-project-flow-role-map-readable-draft.md。 - 筛选时先匹配最具体的现有二级场景；没有合适二级场景时再判断所属一级场景。一级场景存在而二级场景不足，就在该一级场景下创建二级场景；一级场景也不存在，才创建新的一级场景。
- 一级场景是唯一 canonical 定义；它也可以在另一个一级场景或 Project pattern 中作为“引用型二级场景”出现。引用只表达本轮流程位置，不复制定义，也不改变原 Owner。
- 新建场景时必须同时写明边界、典型 artifact、owner 和推荐 Execution Flow；随后直接选择该新场景及其 owner，继续 Ownership Gate，不触发一次新的 RUN 递归。
执行流 Execution Flow组织方式
完成本次任务所采用的协作结构。系统先读取主责场景推荐的 Execution Flow，再由 Owner Agent 根据本次任务的复杂度、风险、不确定性、依赖关系、预计时长和验证需求进行复核。
当前执行流收口为 Fast Flow、Deep Task Flow、AutoResearch、Project Flow 四类；Topic Research 与 Program 都是 Deep Task Flow 的组织形态。推荐流适用时直接采用；不适用时，Owner Agent 改选更轻或更重的执行流，并记录覆盖理由。
功能角色 Functional Role临时职责
一次 Workflow 中临时生成的工作位置。基础角色共有六个：Worker、Expert、Verifier、Explorer、Thinker、Researcher；Collector、Writer、Editor、Critic、PM、Orchestrator、Writing Director 是流程 / 场景别名。别名只改变显示名称与输入输出合同，不新增模型档位或 Subagent 类型。Functional Role 不拥有长期场景，其核心差异只来自可见记忆和模型档位。
只需要一个角色时，同模型档位由 Owner 直接承担，不同模型档位才 spawn 一个 Subagent；真实 teamwork 必须 spawn 完整 team。OpenClaw 最多允许两层 Spawn，第二层 Subagent 不再继续 Spawn。Subagent 完成后，OpenClaw 自动把结果推回父 session；需要交给下一角色的信息必须落成 Project 文件或 artifact。
模型档位 Model Tier能力与成本
当前所有模型档位都使用 ChatGPT 模型 openai/gpt-5.6-sol，通过不同 thinking level 分配思考深度。模型档位是一次执行中的能力配置，不是永久 Agent 类型；编排系统要以任务复杂度为依据，在速度、成本和执行效果之间取得平衡。
- Medium — Worker：处理目标明确、边界清楚、依赖较少的执行；采集整理场景别名为 Collector，写作场景别名为 Writer。
- High — Expert / Verifier / Explorer：Expert 负责专业单元分析，Verifier 负责独立验证，Explorer 负责盲区与新方向探索；Editor 是 Expert 的写作别名，Critic 是 Verifier 在 Topic Research 中的别名。
- XHigh — Thinker：承担问题建模、任务拆解、依赖控制、调度、跨产物整合和关键取舍；流程 / 场景别名为 PM、Orchestrator、Writing Director。
- Max — Researcher：只用于单个边界清楚但难度极高、路径未知的独立 AutoResearch，目前没有别名。
产物 Artifact知识库接口
可保存、可审阅、可交接的工作产物，例如 evidence pack、设计稿、代码、验证报告或 Gate 决策。Project 知识库继续保存正式 artifact 与项目结果；Agent 间的责任转交事实则按 COMMUNICATION_RULES.md 写入发送方的 Docs 通信目录。sessions_send 只负责通知、唤醒或异常信号。
Functional Role 的运行文件放在当前 Project 的 00-control/workflow-runs/<run_id>/。Workflow 正常结束后，只保留 run.yaml、outcome.md 和最终 artifact 指针；正式 artifact 提升到 Project 对应目录，其余中间文件在一段时间后清理。
工作流 Workflow执行实例
选定 Execution Flow 后，为本次任务展开的具体步骤、Functional Roles、依赖、Gate、artifact 和验证结构。Execution Flow 是可复用的组织类型，Workflow 是它在当前任务中的实例；各 Functional Role 通过父 Agent 控制的文件依赖协作，不建立角色间直接通信。
没有匹配的概念。换一个关键词试试。
05 · Execution Flows
执行流
执行流决定本轮工作采用什么组织结构。Topic Research 与 Program 都并入 Deep Task Flow，不再作为独立执行流。
Four Execution Flows
执行流总表
从原有 6 类收口为 4 类。Deep Task Flow 同时覆盖复杂单任务、专题研究团队和 Program 式协作；三者的差异由控制角色与团队结构表达。
| 执行流 | 何时使用 | 控制角色 | Subagent 结构 | 核心输出 |
|---|---|---|---|---|
| Fast FlowOwner direct | 目标、输入、边界和完成标准都清楚；工作规模小、风险低、依赖少，只需形成一个主要 artifact。 | Owner Agent 直接控制。基础角色为 Worker；采集整理场景显示为 Collector，写作场景显示为 Writer。 | 默认不 spawn。若只需要一个角色，先比较该角色与 Owner Agent 的模型档位，再决定直接做或 spawn。 | 单一 working artifact、简短验证结果和必要的 Project 回写。 |
| Deep Task FlowXHigh control吸收 Topic Research + Program | 单个任务复杂度高、约束多、需要专业分析、专题研究、多个步骤或明确 teamwork，但仍由一个 Owner 对本轮任务收口。 | 基础角色为 Thinker。复杂问题建模沿用 Thinker；专题研究 teamwork 显示为 PM；多角色、多步骤或 Program 式协作显示为 Orchestrator。 | 可只需要一个 Subagent，也可组成完整 team。Teamwork 在 OpenClaw 最多两层 Spawn 的限制内组织，Functional Roles 之间不横向通信。 | reasoning brief、research synthesis、执行方案、组合 artifact 与验证意见。 |
| AutoResearchMax | 问题边界窄，但难度极高、路径未知，需要多轮搜索、源码阅读、实验或假设修正；不能用普通 teamwork 代替。 | Researcher 独立执行；Owner 只定义窄问题、输入边界和 artifact contract。 | 只使用一个 Researcher，不组成 Research Team，不与其他 Functional Roles 横向沟通；完成 artifact 后退出。 | research result、evidence pack、confidence、unresolved questions 与 downstream relevance。 |
| Project FlowMulti-stage | 目标跨越多个长期责任场景、工作包、阶段或 Gate，需要持续状态和多位 Owner 协作，且不能在一次任务内直接收口。 | Project Owner 维持最终责任；XHigh 基础角色 Thinker 在编排场景中显示为 Orchestrator，把阶段目标转成 work packages、依赖、Gate 与 handoff。 | 先拆工作包。每个 package 作为独立 request 重新进入 RUN，分别选择 Fast、Deep Task、AutoResearch 或继续 Project Flow。 | work-packages、gate decisions、阶段 outcome、正式 Project artifacts 与下一阶段入口。 |
06 · Functional Roles
Functional Roles
Functional Role 决定本轮需要哪些临时职责与模型档位。六个基础角色定义稳定能力合同，七个别名只表达具体流程或场景。
Contextual Role Contracts
Functional Roles 总表
六个基础角色分布在四个模型档位；七个流程 / 场景别名缩进显示在对应基础角色下面。模型比较和 spawn 均按基础角色计算。
| 模型档位 | 角色层级 | 使用场景与核心作用 | 典型输出 | 不应承担 |
|---|---|---|---|---|
| Medium | Worker基础角色 | 接收边界明确的目标、输入、约束和完成信号，直接生成代码、文档、表格、设计稿或其他工作产物。 | code / document / table / design artifact | 自行扩大范围、重新定义目标或替 Owner 做最终判断。 |
| Medium | Collector采集整理别名 | Worker 在资料采集与整理场景中的名称。按既定范围搜索、抓取、提取、清洗、去重、分类并记录来源。 | source-ledger.md / dataset / gap-list.md | 承担深度综合或结论判断。 |
| Medium | Writer写作别名 | Worker 在写作场景中的名称。依据已确认的 brief、outline、材料和声音要求完成初稿、改写或润色，并标注未解决问题。 | draft.md / rewrite.md / open-questions.md | 擅自改变核心观点、情节或事实边界。 |
| High | Expert基础角色 | 对一个边界清楚的专业单元进行分析，提交关键发现、原始证据、判断依据和不确定性。Expert 对研究单元负责。 | expert-memo.md / evidence-pack.md / uncertainty | 整个任务的拆分、跨单元整合或最终决策。 |
| High | Editor写作别名 | Expert / Verifier 在写作场景中的名称。检查结构、语言、声音、连续性和事实边界，提交分级问题、修改建议和必要的局部示例。 | editorial-review.md / issue-list.md / local examples | 取代作者声音或直接指挥 Writer。 |
| High | Verifier基础角色 | 根据既定标准独立核查事实、逻辑、测试结果、风险和完成信号，给出通过、不通过或需局部返工的判断及证据。 | verification-report.md / pass-fail / local rework | 暗中重做原产物或接管 Owner。 |
| High | Critic专题研究别名 | Verifier 在 Topic Research 中的名称。对前提、研究程序、证据质量和结论进行对抗性审查，区分致命缺陷与可修正问题，防止材料堆积掩盖结构空洞。 | critical-review.md / fatal-flaws.md / fixable-issues.md | 重新组织团队或实现替代方案。 |
| High | Explorer基础角色 | 主动寻找当前方案遗漏的盲区、新方向和反例，并判断是否值得开启第二轮探索。 | blind-spots.md / next-round-options.md / counterexamples | 改变既定边界或做最终取舍。 |
| XHigh | Thinker基础角色 | 围绕一个复杂问题建立模型、拆解约束、比较方案、识别风险并形成推荐路径；在 Deep Task Flow 中担任唯一控制中心，按需调用 Worker、Expert、Verifier 或 Explorer，并负责收口。 | reasoning-brief.md / decision-options.md / risk map | 与另一个 XHigh 角色并列控制同一流程。 |
| XHigh | PM专题研究别名 | Thinker 在 Topic Research 中的名称。定义最小 research program、拆分研究单元、编写 Expert brief、控制研究边界与轮次，并最终整合证据和结论。 | research-program.md / expert briefs / synthesis.md | 设置第二个 PM；每个 Topic Research 只能有 1 个 PM。 |
| XHigh | Orchestrator编排流程别名 | Thinker 在 Project Flow / Program 中的名称。把目标转成工作包、依赖、Gate 和 handoff，接收各角色的 artifact，处理返工与重规划，并整合阶段结果。 | work-packages.md / gate-decisions.md / outcome.md | 设置第二个 Orchestrator；同一流程只能有 1 个控制中心。 |
| XHigh | Writing Director写作别名 | Thinker / Orchestrator 在写作场景中的名称。定义读者承诺、核心观点或主题、结构、声音、章节 brief 和验收标准，整合 Writer 与 Editor 的产物并形成最终文本。 | writing-brief.md / outline.md / final-draft.md | 把结构控制或最终取舍交给 Writer、Editor。 |
| Max | Researcher基础角色 | 独立执行一个边界窄、难度高、路径未知的 AutoResearch，通过多轮搜索、源码阅读、实验和假设修正形成结论、证据、不确定性与剩余未知。 | research-result.md / evidence-pack.md / unknowns.md | 采用 Research Team、参与横向沟通；交付 artifact 后应退出。 |
Subagents Spawn 原则
如果本轮只需要一个 Functional Role，而且它与 Owner Agent 的模型档位相同，由 Owner Agent 直接承担，不额外 spawn。
如果本轮只需要一个 Functional Role，但它要求的模型档位与 Owner Agent 不同，才 spawn 一个 Subagent，并只授权该角色所需的输入与 artifact。
如果任务被判断为真实 teamwork，必须 spawn 完整的 Subagent team。
OpenClaw Spawn 深度：最多允许两层 Spawn；第二层 Subagent 不再继续 Spawn。
07 · Scene Catalog
场景目录
一级场景按 Owner Agent 分组；其下可直接包含二级动作场景。引用现有场景时只显示引用关系和关键信息，详细定义仍保留在原场景位置。
一级场景 · canonical
二级动作场景
引用现有场景
引用只表达 S36 内的动作位置；详细说明仍在原场景卡片中，不复制定义，也不改变原 Owner。
没有匹配的场景。请更换搜索词或过滤条件。
08 · Project Catalog
Projects
全量收录当前 62 个可见 Project surface，按其所在 Agent 知识库分组，并映射到现有场景。状态与归属均是观察基线，不自动改变 runtime owner。
阅读口径
Project 所在分组表示当前知识库 surface；同名、历史或职责偏移项目仍原样展示。场景映射用于说明任务应进入哪里，不等于移动目录、重分配 Owner、启用自动扫描或修改 runtime。红色表示映射待复核：现有 artifact 与该场景不充分吻合，或实际内容提示可能缺少场景；保留原映射等待人工确认。
没有匹配的 Project。请更换搜索词、状态或场景筛选。