Appearance
Agent 架构与协作模式
方向定位：聚焦 Agent 的"架构形态选型"与"多 Agent 协作组织方式"——从工作流 vs 智能体的根本区分、五种控制模式，到 Single-Agent vs Multi-Agent 选型、Orchestrator-Worker 模式、三层智能体架构（Skills/Agents/Orchestrators）、Workflow-Graph-Loop 三层抽象，再到触发-拓扑两问框架与认知架构（本体论+知识图谱）。不研究 Agent 内部的具体能力实现（记忆、工具、评测等单独成方向），只研究"Agent 怎么搭、几个 Agent、谁管谁、怎么协调"。 当前版本：v0.4 首次构建：2026-05-12 最近更新：2026-05-20 来源数：9 篇
方向定位
Agent 架构与协作模式研究的核心问题是："给定一个任务，要用什么形态的 Agent 系统去解？"。它的边界包括：
- 包含：架构选型框架（单 Agent vs 多 Agent vs 工作流）、控制模式（五种 Anthropic 工作流）、多 Agent 协作拓扑（Orchestrator-Worker、Blackboard、网状 team、Gateway routing、Durable board）、三层结构抽象（Skills/Agents/Orchestrators，或 Workflow/Graph/Loop）、触发-拓扑两问框架、认知架构（本体论+知识图谱+神经符号 AI）
- 不包含：Agent 内部记忆系统设计（→ Agent 记忆系统方向）、具体工具调用与 MCP 协议细节（→ Agent 工具生态方向）、评测与反思机制（→ Agent 评估方向）、工程落地的全景指南（→ Agent工程实践与工具生态）
- 与相邻方向的区别：本方向只关心"形态/拓扑/协作组织"层面的问题；不深入到每层内部具体能力的实现细节，也不涵盖"选定架构后如何工程化"的实现要点（→ Agent工程实践与工具生态）
架构选型与协作机制决定了系统的可控性、可调试性、可扩展性——是 Agent 从 demo 走向生产的第一道分水岭。
知识图谱
- 架构形态选型
- 工作流（Workflow）vs 智能体（Agent）：控制权在代码 vs 在 LLM
- 单 Agent vs 多 Agent：链路可控 vs 分工/并行
- 中心化（Orchestrator-Worker）vs 去中心化：可控 vs 学术
- 五种控制模式（Anthropic）
- 提示链 / 路由 / 并行化 / 编排者-执行者 / 评估者-优化者
- 三层结构抽象
- Workflow / Graph / Loop（目标层 / 结构层 / 控制层）
- Skills / Agents / Orchestrators（原子能力 / 领域智能体 / 编排智能体）
- Graph 三要素
- Node（执行单元）+ Edge（六种流转规则）+ State（共享工作记忆）
- 触发-拓扑两问框架
- 触发：显式 / 语义 / 路由 / 队列
- 拓扑：单 / 星型 / 链式 / 树型 / 网状 / Gateway / Durable
- 认知架构
- LLM = 神经层（概率直觉）
- 本体论 = 符号约束层
- 知识图谱 = 结构化记忆载体
- 神经符号 AI = 双层结合
核心概念
概念 1：工作流 vs 智能体的根本区分
来自 Anthropic《Building Effective Agents》——这个区分直接决定架构选型。
| 维度 | 工作流（Workflow） | 智能体（Agent） |
|---|---|---|
| 控制权 | 代码预定义，同输入必走同路径 | LLM 动态决策下一步 |
| 隐喻 | 流水线 | 独立思考的员工 |
| 状态 | 显式状态机，节点跳转清晰 | 隐式上下文，状态在对话历史累积 |
| 维护 | 改流程需修改代码重新部署 | 调整系统提示即可 |
| 可观测性 | 日志定位节点，延迟可预估 | 需完整执行记录，轮数不固定 |
核心区别：执行路径由代码写死 = Workflow，由 LLM 动态决定 = Agent。现实中很多标着 Agent 的产品深入看更接近 Workflow，两者无高下之分，关键看任务特性匹配。
概念 2：Anthropic 五种控制模式
大多数 AI 系统都是这五种模式的组合。
权威原文：本概念源自 Anthropic《Building Effective Agents》（Erik S. & Barry Zhang，2024-12-19，原文）。完整原始素材的横切提炼见 Agent设计哲学与决策框架 概念 1；5 种模式作为决策入口的速查见 Agent设计哲学与决策框架 方法 4。
| # | 模式 | 核心逻辑 | 隐喻 | 典型场景 |
|---|---|---|---|---|
| 1 | 提示链 Prompt Chaining | 大任务拆小步骤，前步输出→后步输入，中间可加代码检查点 | 接力赛 | 先写文案→再翻译；先生成大纲→校验→写正文 |
| 2 | 路由 Routing | 输入分类→导向不同专用流程 | 医院分诊台 | 客服分流（咨询/退款/技术）；简单→小模型，复杂→大模型 |
| 3 | 并行化 Parallelization | 分段法（拆子任务并发）+ 投票法（同任务多次取共识） | 分头行动 | 一个处理请求+一个做安全审查；多模型审查代码漏洞 |
| 4 | 编排者-执行者 Orchestrator-Workers | 中央 LLM 动态分解+委派给工作者；与并行化区别是子任务动态决定 | 项目经理+工人 | 同时修改多文件；多源信息收集分析 |
| 5 | 评估者-优化者 Evaluator-Optimizer | 一个生成+一个评估反馈，迭代循环 | 作家+编辑 | 文学翻译迭代；搜索任务判断信息是否充分 |
复杂度递进决策树：
单次调用 + RAG 够用吗？
├─ 够 → 停在这里
└─ 不够 → 需要多步骤吗？
├─ 步骤固定 → 用工作流（提示链/路由/并行化）
└─ 步骤动态 → 需要自主决策吗？
├─ 部分自主 → 编排者-执行者
└─ 完全自主 → 真正的 Agent（循环：任务→规划→执行→观察→调整）概念 3：Single-Agent vs Multi-Agent 触发信号
来自京东面试官分享——Single-Agent 力不从心的三类场景。
| 触发信号 | 含义 | 单 Agent 失效原因 |
|---|---|---|
| Context 溢出 | 任务太长、信息量太大 | Context 撑爆，Agent 开始遗忘关键信息 |
| 多专业分工需求 | 不同步骤需完全不同的专业能力 | 塞进一个 Agent 每件事都做得不够专注 |
| 可并行子任务 | 任务中有多个独立子任务理论上可并行 | 单 Agent 只能串行执行 |
强调：不属于这三类的任务，Single-Agent 就够了——不要为了"用新技术"强行引入 Multi-Agent，系统会变复杂变难维护却没有对应收益。
Single-Agent 真正优势：链路完全在你掌控之内——所有任务逻辑在一个地方写清楚，出问题链路短好排查。
概念 4：Orchestrator-Worker 中心化架构
Multi-Agent 工程上几乎只用这一种——去中心化方案因不可控基本停留在学术研究。
Orchestrator（总调度员/项目经理）的三个职责：
- 读懂用户大目标，拆解为子任务列表
- 判断每个子任务交给哪个 Worker Agent
- 收集各 Worker 产出，合并为最终答案
Worker Agent（执行者）的特点：
- 只关注自己那块，不需要知道整体任务或其他 Worker
- 收到指令 → 执行 → 返回结果 → 退出
- Context 干净，只装和自己职责相关的信息
调试优势：报告内容不准 → 查 Researcher；分析逻辑有问题 → 查 Analyst；格式不对 → 查 Writer。每个 Agent 职责清晰，沿调度记录追踪，不需要猜。
去中心化方案的四类工程问题（解释为什么生产不用）：
| 问题类型 | 具体表现 |
|---|---|
| 任务分配无协调 | A 和 B 搜了大量重叠内容，重复工作 |
| 执行顺序无保证 | C 不知道 A 和 B 何时搜完，不知道该等多久 |
| 失败无感知 | A 中途出错，B 和 C 继续运行，产出不完整但系统不知道 |
| 无整体完成确认 | 没有人宣告"整个任务完成了" |
架构落地实现：Orchestrator-Worker 的工程化落地（包括控制面/数据面工具集分离、委派契约 8 字段模板、Worker 上下文构造与权限边界、reducer 收口等）请见 Agent工程实践与工具生态。
服务端变体：Advisor Tool（Anthropic 2026-05-13）
Orchestrator-Worker 的经典实现需要客户端多轮调用（Orchestrator 调用 → Worker 调用 → Orchestrator 收口），Anthropic 推出的 Advisor Tool 把这个模式压缩到单次 API 请求内完成：
| 维度 | 经典 Orchestrator-Worker | Advisor Tool |
|---|---|---|
| 通信方式 | 客户端多轮 API 调用 | 服务端单请求内完成 |
| 执行者 | Worker Agent（可独立部署） | 小模型（Sonnet 4.6）执行主循环 |
| 决策者 | Orchestrator Agent | 大模型（Opus 4.7）按需介入 |
| 延迟 | 多轮网络往返 | 零额外往返（服务端内部通信） |
| 成本控制 | 客户端自管 budget | max_uses 参数限制大模型介入次数 |
产品形态：通过 advisor_20260301 beta 头启用。小模型执行工具调用和常规操作，遇到决策点/复杂推理/质量校验/错误恢复时自动升级到大模型。Anthropic 实测：性能 +2.7%、成本 -11.9%。20 轮对话后模型会收到提醒 nudge 鼓励使用 advisor，避免"忘了问"。
架构意义：Advisor Tool 证明 Orchestrator-Worker 不一定是多 Agent 分布式问题——当 Worker 和 Orchestrator 都是同一厂商的模型时，可以在服务端内部完成编排，客户端只需一次调用。这是 Orchestrator-Worker 从"客户端编排"到"服务端编排"的演进方向。（来源：Anthropic CU 最佳实践博客，2026-05-13）
概念 5：三层智能体架构（Skills/Agents/Orchestrators）
来自 CortexFlow 实践——把能力从原子到复杂逐层组合。
┌─────────────────────────────────────┐
│ L3: Orchestrators（编排智能体） │
│ web-pentest-flow, code-audit-flow │
│ - 协调多个 Agent / 并行执行 / 全局状态 │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ L2: Agents（领域智能体） │
│ recon-agent, vuln-scan-agent │
│ - 执行 ReAct 循环 / 调用多个 Skills │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ L1: Skills（原子能力） │
│ http-request, code-analysis │
│ - 单一职责 / 可复用 / 工具封装 │
└──────────────────────────────────────┘| 层级 | 定位 | 示例 | 特点 |
|---|---|---|---|
| L1 Skills | 原子能力 | http-request, code-analysis, vuln-detect | 单一职责，可被多个 Agent 复用 |
| L2 Agents | 领域专家 | recon-agent, vuln-scan-agent, exploit-agent | 组合多个 Skills，执行 ReAct 循环，沉淀领域知识 |
| L3 Orchestrators | 编排层 | web-pentest-flow, code-audit-flow | 协调多 Agent，支持并行，管理全局状态 |
概念 6：Workflow-Graph-Loop 三层抽象
AI 工作流的本质是三层嵌套——核心抽象 Node + Edge + State 不随框架换代而变。
Workflow（目标层）── "先生成，再审核，不达标就修改，直到达标输出"
↓ 结构化表达为
Graph（结构层）── Node + Edge + State 构成的有向图
↓ 其中包含
Loop（控制层）── 图上的回边（Back Edge），实现可控回溯Node（节点）= 执行单元：三大功能——读取 State → 执行逻辑 → 写回 State；按职责边界划分（产出什么结果），不按"调了哪个 API"。
Edge（边）= 流转规则，六种类型：
| 类型 | 特征 | 典型场景 |
|---|---|---|
| 顺序边 | 固定顺序，无条件 | 预处理→生成 |
| 条件边 | 候选集设计时确定，运行时选择 | 评分>=80走输出，否则走修改 |
| 动态路由 | 候选集运行时才确定 | LangGraph Send API，map-reduce |
| 循环边 | 回指先前节点 | 审核→修改→审核 |
| 终止边 | 引导至结束 | 输出最终结果 |
| 并行边 | 同时分发多个后续节点 | RAG/工具并发 |
State（状态）= 共享工作记忆——三种更新语义：覆盖（Replace，单值字段）/ 追加（Append，对话历史）/ 自定义合并（按 ID 去重）。
并发陷阱：多个并行节点写同一个覆盖语义字段会竞态，LangGraph 抛
INVALID_CONCURRENT_GRAPH_UPDATE——这与"Agent 记忆覆盖问题"中的直接冲突故障同构。
概念 7：Loop 设计三要素
Loop ≠ "多跑几次"，而是图结构上的可控回溯机制：
| 要素 | 说明 |
|---|---|
| 继续条件 | 为什么还要再来一轮（评分<80） |
| 退出条件 | 什么时候足够好（评分>=80） |
| 安全边界 | 最大轮次 + 超时 + Token 预算 + 熔断 |
两种 Loop 类型：固定次数（for，最多 N 次）+ 条件驱动（while，评分阈值）。实际必须两者结合——条件驱动决定何时满意，固定次数兜底防死循环。
区分 Graph Loop vs Agent Loop：Agent Loop 是顶层"推理→行动→观察"循环；Graph Loop 是图内部特定节点子集的迭代修正，后者嵌套在前者内部。
概念 8：本体论 + 知识图谱 = 认知架构
来自 LinkedIn《Cognitive Architecture for Agency》——LLM 的核心缺陷是"逻辑幻觉"，需符号层补足。
LLM 的本质局限：
- 统计驱动系统，基于"概率直觉"运作（预测最可能的下一个词）
- 缺乏"世界模型"——对现实世界结构、规则和关系的深层理解
- 对创意写作有效，但对 Agent 执行具体任务来说是致命缺陷
本体论（Ontology）= Agent 的"内部宪法"，形式化定义三要素：
| 要素 | 类比 | 示例 |
|---|---|---|
| 实体（Entities） | "名词" | 客户、发票、法律条款、化学化合物 |
| 属性（Attributes） | "形容词" | 发票有截止日期；化合物有沸点 |
| 关系（Relationships） | "动词" | 客户支付发票；药物治疗疾病 |
核心作用：约束层——Agent 行动前根据本体论"检查"是否合法。如果 Agent 试图向"潜在客户"（而非"客户"）发送产品，本体论标记为逻辑违规。
知识图谱 = 本体论的"物理载体"——如果本体论是"游戏规则"，知识图谱就是"游戏棋盘"。提供两个超级能力：
- 多跳推理：零件 SKU #552 → 库存不足 → 供应商所在地区 → 有暴风雨 → 建议替代供应商
- 实时上下文记忆：(Agent) -[SENT]-> (Email) -[TO]-> (Client)
向量搜索 vs 本体论搜索：
| 维度 | 向量搜索（RAG） | 本体论+图搜索 |
|---|---|---|
| 查找逻辑 | 寻找"看起来相似的" | 寻找"有关联的" |
| 擅长 | 语义相似性匹配 | 多跳关系推理 |
| 致命缺陷 | 对结构"盲目"，不理解层级/因果 | 构建成本高，需领域建模 |
概念 9：神经符号 AI（Neuro-Symbolic AI）
两个世界的最佳结合：
1. 用户用自然语言提出复杂问题
2. LLM 将混乱翻译成对知识图谱的精确查询
3. 图按本体论规则以 100% 准确性执行查询
4. LLM 将"硬真相"翻译回人性化响应或行动- LLM（神经部分）：负责自然语言的灵活理解和流畅输出
- 本体论/图谱（符号部分）：负责硬性、精确的逻辑推理和路径遍历
- 信任基础：本体论提供治理 + 知识图谱提供可追溯性——Agent 每一步都可审计
概念 10：PEV（Plan-Execute-Verify）—— 自纠错三段循环
来自《All Agentic Architectures》对 ReAct 的工程化扩展：在每个 action 之后插入独立 Verifier Agent，把"reasoning"和"verification"两个角色拆开。
三段循环：
Planner → Executor → Verifier
↑ ↓
└─── 失败回环重新规划 ─┘| 角色 | 职责 | 与 ReAct 的差别 |
|---|---|---|
| Planner | 拆解任务 / 重规划 | ReAct 是边想边做，PEV 先规划再做 |
| Executor | 调工具/执行动作 | 同 ReAct 的 Action |
| Verifier | 独立检查动作结果是否符合预期 | ReAct 的 Observation 只是结果回填，PEV 是结果校验 |
核心论断：把"自我反思"从 Agent 自身剥离成独立角色，避免"既当运动员又当裁判"——这是高风险场景（金融、不可靠工具）能否上生产的分水岭。与「Agent评估与反思机制」中"单 Agent 自反思 vs 多 Agent Critic"的概念呼应。
典型场景：金融自动化、对不可靠 API 的容错调用、需要 step-level 可恢复的工作流。
（来源：FareedKhan-dev/all-agentic-architectures 06_PEV.ipynb，2026-05-19）
概念 11：Blackboard Systems —— 共享中央记忆 + 动态控制器
经典 AI 多 Agent 协作范式：所有专家 Agent 不直接通信，而是通过一个共享黑板（central memory）读写中间结果，由一个 Controller 根据黑板上当前状态动态选下一个该运行的 Agent。
与 Orchestrator-Worker 的区别：
| 维度 | Orchestrator-Worker | Blackboard |
|---|---|---|
| 任务流转 | Orchestrator 预先派发 | Controller 看黑板状态机会式触发 |
| Agent 间通信 | 通过 Orchestrator 收发 | 通过共享黑板间接交换 |
| 适用场景 | 任务可拆解、依赖明确 | 任务路径不确定、需要根据中间结果动态切换专家 |
核心论断：Blackboard 是"动态意会"型多 Agent 协作的天花板模式——适用于复杂诊断（医疗会诊、安全调查）、动态情报分析这类问题路径无法预设的场景。是 LangGraph 中"share state + conditional edge"模式的理论原型。
（来源：FareedKhan-dev/all-agentic-architectures 07_blackboard.ipynb，2026-05-19）
概念 12：Tree of Thoughts（ToT）—— 多路径推理与剪枝
把 LLM 的"线性 Chain-of-Thought"升级为树状探索：每一步生成 N 个候选思路，对每条分支评估、保留高分、剪枝低分，最终在叶子层选最优解。
三件套：
- Thought Generator：每步生成 K 个候选下一步
- State Evaluator：给每个候选打分（启发式或 LLM-as-Judge）
- Search Strategy：BFS / DFS / Beam Search 决定遍历策略
与 ReAct 的根本区别：ReAct 单线推进、Tool 调用驱动；ToT 多线并行、内部评估驱动，牺牲 Token 换严谨。
典型场景：逻辑/数学谜题、约束规划（24 点、旅行路线、博弈推演）、需要"试错+回溯"的硬推理任务。不适合：实时响应、Token 预算敏感的场景。
（来源：FareedKhan-dev/all-agentic-architectures 09_tree_of_thoughts.ipynb，2026-05-19）
概念 13：Mental Loop / Simulator —— 内部世界模型先预演再执行
Agent 在真实环境执行动作之前，先在一个内部模拟器（mental model）里"演一遍"——预测结果、评估风险、必要时回退。是工业控制和强化学习思想的 Agent 化。
与 Dry-Run Harness 的区别：
| 维度 | Dry-Run Harness | Mental Loop |
|---|---|---|
| 模拟器位置 | Harness 层（外部审批环节） | Agent 内部（自主预演） |
| 决策权 | 人或 Checker 审批 | Agent 基于模拟结果自决 |
| 关注点 | 安全合规 | 风险预估与最优动作选择 |
典型场景：机器人导航（先模拟路径）、金融交易（先模拟成交价滑点）、安全关键系统（医疗决策前评估副作用）。
与现有概念的关系：可视为「Agent 设计哲学」中"克制"的进阶——不仅做之前思考，更做之前模拟。
（来源：FareedKhan-dev/all-agentic-architectures 10_mental_loop.ipynb，2026-05-19）
概念 14：Ensemble —— 多 Agent 并行 + Aggregator 综合的去偏范式
多个独立的 Agent 分别从不同视角分析同一问题，最后由 Aggregator Agent 综合输出。与 Anthropic 五种控制模式中的"并行化"区别：并行化是同一个任务分多份并行做，Ensemble 是同一个任务从多个不同视角各做一次，最后融合——目的是降低单点偏差。
典型实现：
Question → [Conservative Agent | Aggressive Agent | Devil's Advocate Agent]
↓ (并行独立分析)
Aggregator → Final Answer with Confidence核心论断：Ensemble 对"高风险、需要去偏、需要 fact-checking"的场景比 Multi-Agent 协作更有用——三个观点独立 PK 比三个人接力组装更能暴露盲区。是与 OpenAI Deliberation、Anthropic Constitutional AI 路线相通的"去偏"工程范式。
（来源：FareedKhan-dev/all-agentic-architectures 13_ensemble.ipynb，2026-05-19）
概念 15：Reflexive Metacognitive —— Agent 的自我能力建模
Agent 携带一个 self-model：当用户提问时，先评估"我有没有能力回答 / 能不能用工具解决 / 需不需要升级到人工"。本质是让 Agent 知道自己不知道什么。
三档行为输出：
- Act：能直接回答 → 输出
- Use Tool：能力不足但有工具 → 调用
- Escalate：超出能力边界 + 高风险 → 转人
核心论断：高风险咨询场景（医疗 / 法律 / 金融）的安全底线 = Agent 必须能识别自己的能力边界。这是 Anthropic Reflexive 路线与 OpenAI Deliberation 共同走的方向。是 17 种架构中**最贴近"安全可信生产部署"**的一种。
（来源：FareedKhan-dev/all-agentic-architectures 17_reflexive_metacognitive.ipynb，2026-05-19）
概念 16：触发-拓扑两问框架（多智能体设计的第一性问题）
很多多智能体讨论混在一起，是因为把两个独立问题当成了一个问题。先回答"何时拆"，再回答"怎么组织"——这是多智能体设计的第一性问题。
第一问：触发——系统什么时候从单 agent 变成多 agent？
四类触发方式：
| 触发方式 | 含义 | 典型 Harness | 工程特征 |
|---|---|---|---|
| 显式触发 | 用户明说"use parallel subagents" / "spawn one agent per category" | Codex | 把并行授权权留给用户和主 agent，行为最可预测 |
| 语义触发 | 主 agent 按任务内容 + subagent description 自动匹配 | Claude Code 普通 subagent | description 越像触发条件就越可路由；写得像"愿望"就会乱叫人 |
| 路由触发 | 按事件入口（channel / account / thread / peer / guild / role）绑定 agent | OpenClaw Gateway | 先答"这条消息属于哪个 agent"，再谈是否拆任务 |
| 队列触发 | 任务写进 board / queue / cron / background job，由 dispatcher 按状态拉起 worker | Hermes Kanban | 关键是"能否跨 turn / 跨天 / 跨重启 / 跨人类介入"，而非本轮返回 |
第二问：拓扑——一旦变成多 agent，它们怎么组织？
七种拓扑形态：
| 拓扑 | 适用场景 | 失败模式 |
|---|---|---|
| 单 agent | 需求模糊、修改小、步骤强依赖 | 把"需要更好上下文"误解成"需要多 agent" |
| 星型 fan-out/fan-in | 多个独立子任务可并行；worker 之间不需要协商 | 没有 reducer 就只是"多份意见" |
| 链式 pipeline | 强顺序任务（定位 → 修复 → 测试 → review） | 硬并行化让后续 worker 在错误假设上浪费时间 |
| 树型 | 大任务分层（main → orchestrator → leaf worker） | 不限 depth 与并发会指数级膨胀 |
| 网状 team | 多假设问题需要互相挑战（如生产登录故障可能在前端/后端/DB/cache） | 消息更多、写文件冲突更易、ownership 不清 |
| Gateway routing | 常驻多入口系统(多渠道、多身份、多权限) | 入口配错则消息进错 agent；权限策略宽则越权 |
| Durable board | 长期协作（跨天、重试、人类介入、审计要求） | 短任务上 board 会显得笨重 |
核心论断：触发方式回答"何时进入多 agent"，拓扑回答"进去之后怎么组织"。把两个问题分开思考，决策就不会陷入"复杂任务=自动多 agent"的滑坡——很多任务复杂不等于应该并行，子任务强依赖时是 pipeline 不是 fan-out。
概念 17：多智能体调用链 7 阶段
任意多智能体系统都可以拆成下面这条调用链——每个阶段都是一个独立的设计决策：
input event
-> router / dispatcher 决定是否拆、拆给谁
-> context builder 决定 worker 知道什么
-> worker profile selection 决定用什么角色
-> execution sandbox 决定 worker 能做什么
-> state store 决定状态放哪
-> merge / reduce 决定如何收口
-> final output or next task七阶段职责速查：
| 阶段 | 职责 | 典型决策 |
|---|---|---|
| router/dispatcher | 决定是否拆任务以及拆给谁 | 用户授权 / description 匹配 / 入口绑定 / 队列调度 |
| context builder | 决定 worker 知道什么——委派信息就是需求文档 | 路径 / 错误现场 / 相关文件 / 验收标准 / 禁止事项 / 输出格式 |
| worker profile selection | 决定 worker 是什么角色 | 只读 explorer / 可写 worker / security reviewer / 一次性 child / 长期 memory profile |
| execution sandbox | 决定 worker 能做什么 | 跑 shell / 联网 / 写文件 / 继续 spawn child / 用户凭据 |
| state store | 决定状态放哪 | 一次性 child 状态死在本轮 / agent session store / durable board |
| merge/reduce | 谁判断冲突、谁取舍、谁写最终 patch、谁对用户负责 | 主 agent 收口 / 显式 reducer |
| final output / next task | 输出给用户或进入下一轮 | 本轮返回 / 入下一个 board 任务 |
额外维度：取消与失败传播——父任务被中断时子任务要不要一起停？worker 超时怎么办？两个 worker 给出相反结论怎么办？这些不是模型能力问题，而是运行时设计问题。
委派契约与各阶段失败模式的工程化处理请见 Agent工程实践与工具生态。
概念 18：四大 Harness 多智能体设计对比矩阵
Codex / Claude Code / OpenClaw / Hermes 四个 Harness 给出了多智能体设计的四种工程取舍样本，对比矩阵如下：
| 维度 | Codex | Claude Code | OpenClaw | Hermes |
|---|---|---|---|---|
| 主要触发方式 | 显式触发（用户授权） | 语义触发（description 路由） | 路由触发（channel/account/thread/peer 入口绑定） | 队列触发（Kanban dispatcher）+ 短任务 delegate_task |
| 默认拓扑 | 星型 fan-out/fan-in | 普通 subagent 星型 / Agent Teams 网状 mesh / batch+worktree | Gateway routing + 后台 subagent + ACP harness 三层 | delegate_task RPC（短）+ Kanban durable board（长） |
| 生命周期 | 当前 turn 内 fork/join | subagent 短期、Teams 中期、Agent View 后台 | background subagent 异步（返回 run id） | delegate_task 本轮、Kanban 跨 turn/天/重启 |
| 状态存储 | 主上下文 + 子上下文 | 各 subagent 独立上下文 + Teams 共享任务列表 | per-agent workspace（AGENTS.md / SOUL.md / USER.md）+ session store | SQLite task board / agent profile memory |
| 深度/并发护栏 | agents.max_threads + agents.max_depth（默认 child 不能再 spawn） | 普通 subagent 不嵌套；Teams 实验功能默认关闭 | maxSpawnDepth=1（提到 2 才能树型，depth-2 不能再 spawn） | 默认 3 并发；leaf 不能再 delegate；3 层 × 3 并发 = 27 leaf |
| 权限模型 | TOML 配置 sandbox/MCP/skills | tools 字段白名单 + 模型选择 | 入口身份隔离 + 工具策略隔离 + per-agent config（认证 main fallback 合并） | leaf 不能 clarify、不能跨平台发消息、不能写 shared memory |
| 典型适用场景 | PR review、定位+定点修复、显式并行研究 | description 驱动专家委派、Teams 多假设挑战、batch repo-wide migration | 多渠道个人助理、入口身份隔离、常驻 agent 网络、ACP 调度外部 harness | 短程并行用 delegate_task、长程协作用 Kanban、人类介入 + 重试 |
| 常见失败点 | 用户只说"深入分析一下"被理解成质量要求不是并行授权 | description 太宽→乱触发；Teams 没 ownership→冲突 | routing 配错；权限太宽；session store 污染 | 短任务上 Kanban 笨重；长任务用 delegate_task 丢状态；context 写太少 |
核心论断：四个 Harness 不是"谁更先进"，而是把多智能体设计的不同维度极端化——Codex 把控制权极端留给用户、Claude Code 把语义匹配做到位、OpenClaw 把入口隔离做到位、Hermes 把生命周期二分做到位。选 Harness 等于选取舍偏好：你最想保护的是"可预测性"、"自动化便利"、"入口隔离"还是"长程状态"？
方法论与框架
方法 1：架构选型两步决策框架
核心思想： 不要为了用新技术而强行升级架构，按需复杂化。
操作步骤：
问题1：Single-Agent 能搞定吗？
→ 任务流程明确、不太长、不需要多种专业分工？
→ 是 → 用 Single-Agent，不要引入 Multi-Agent
→ 否 → 进入问题2
问题2：能接受系统行为不可控的风险吗？
→ 生产环境答案几乎一定是"不能"
→ 用 Orchestrator 模式（中心化 Multi-Agent）注意事项：
- Single-Agent 优势不是"简单"而是"链路完全可控"——出问题链路短好排查
- 去中心化方案听起来更灵活，但生产环境几乎不用——四类工程问题让系统行为不可预测
- 在 Orchestrator 模式中，混用模型策略：核心模块用强模型（Claude Code），测试/文档用轻量 Agent 节省 Token
方法 2：Anthropic 复杂度递进决策树
核心思想： "克制比技巧更重要"——先把单次调用优化到极致，再考虑工作流；先用预设流程，再考虑自主智能体。每增加一层复杂度，都应该有可衡量的收益支撑。
操作步骤：
- 先问：单次调用 + RAG 够用吗？够 → 停
- 不够 → 步骤固定？→ 工作流（提示链/路由/并行化）
- 步骤动态 → 部分自主 → 编排者-执行者
- 步骤完全自主 → 真正的 Agent（循环架构）
核心论断：最成功的 Agent 往往是最简单的——精心调优的单次大模型调用 + RAG + 上下文示例，就足以解决大多数问题。
方法 3：现代 Agent 架构 17 种全景图谱（5 大类分类法）
核心思想：把零散的 Agent 模式（ReAct / Multi-Agent / Reflection 等）归并为按演化阶段递进的 5 大类——读懂这张图谱即可在面对一个新场景时快速定位"该选哪个范式起步"。
5 大类组织（按从简单到复杂排序）：
| 类别 | 解决的核心问题 | 包含架构 |
|---|---|---|
| Part 1：Foundational Patterns 单 Agent 增强 | 让单个 Agent 更强 | Reflection / Tool Use / ReAct / Planning |
| Part 2：Multi-Agent Collaboration 多 Agent 协作 | 多个专家分工 | Multi-Agent / Meta-Controller / Blackboard / Ensemble |
| Part 3：Memory & Reasoning 高级记忆与推理 | 长期记忆+复杂思考 | Episodic+Semantic / Graph World-Model / Tree of Thoughts |
| Part 4：Safety & Reliability 安全可靠落地 | 高风险生产部署 | PEV / Mental Loop / Dry-Run / Reflexive Metacognitive |
| Part 5：Learning & Adaptation 学习与适应 | Agent 自我进化 | RLHF Self-Improvement / Cellular Automata |
17 种架构速查表：
| # | 架构 | TL;DR | 典型场景 |
|---|---|---|---|
| 01 | Reflection | 自批评 + 自修正循环 | 高质量代码生成、复杂总结 |
| 02 | Tool Use | 外部 API/函数调用 | 实时研究、企业 Bot |
| 03 | ReAct | 推理-行动交替循环 | 多跳 QA、Web 导航 |
| 04 | Planning | 先规划后执行 | 可预测报告、项目管理 |
| 05 | Multi-Agent | 专家团队分工 | 软件开发流水线、创意 |
| 06 | PEV | Plan-Execute-Verify 自纠错 | 金融自动化、不可靠工具 |
| 07 | Blackboard | 共享黑板 + 动态控制器 | 复杂诊断、动态情报 |
| 08 | Episodic+Semantic | 向量+图双层记忆 | 长期个人助理、个性化 |
| 09 | Tree of Thoughts | 多路径推理 + 剪枝 | 逻辑谜题、约束规划 |
| 10 | Mental Loop | 内部模拟器先预演 | 机器人、金融交易 |
| 11 | Meta-Controller | 路由到专家子 Agent | 多服务 AI 平台 |
| 12 | Graph World-Model | 实体关系图多跳推理 | 企业情报、研究 |
| 13 | Ensemble | 多视角并行 + 综合 | 去偏决策、fact-check |
| 14 | Dry-Run Harness | 先模拟再审批后执行 | 生产 Agent 部署 |
| 15 | RLHF Self-Improvement | Editor 批评 + 优质样本回流 | 内容生成、持续学习 |
| 16 | Cellular Automata | 局部规则涌现全局行为 | 空间推理、物流 |
| 17 | Reflexive Metacognitive | Agent 知道自己边界 | 医疗/法律/金融高风险咨询 |
与现有方向的映射：
- 已被深度覆盖：02 / 03 / 05 → 见「Agent 工具生态」「Agent 工程实践」本方向其他章节
- 在本方向补充：06 / 07 / 09 / 10 / 13 / 17（概念 10-15）+ 16（前沿）
- 在「Agent 记忆系统」补充：08 / 12（双层记忆案例 + Graph World-Model）
- 在「Agent 评估与反思机制」补充：01 / 13 / 15（Reflection / Ensemble / RLHF 实现案例）
- 在「Harness 失效模式与反馈机制」补充：14（Dry-Run 安全模式框架）
框架配套技术栈：原仓库基于 LangGraph（stateful + cyclical 图调度）+ Pydantic（结构化数据）+ LLM-as-Judge（自带评估）。LangGraph 作为绝大多数现代 Agent 架构的事实标准编排层——这与「Workflow-Graph-Loop 三层抽象」中"Graph 是 Workflow 与 Loop 的统一表达"的判断完全一致。
核心论断：17 种架构不是 17 个选项，而是按**"任务复杂度 → 协作需求 → 推理深度 → 安全级别 → 学习能力"5 个维度**渐进升级的菜单——立项时按维度对号入座，能避免"为用新技术而升级架构"的误区。
（来源：FareedKhan-dev/all-agentic-architectures README，2026-05-19）
方法 4：多智能体 8 步选择顺序决策树
设计任何多智能体方案前，按这个顺序逐条问——多数"看起来需要多 agent"的任务会在前 3 问就被劝退。
Step 1 单 agent 能不能做？
小改动、强顺序、需求模糊 → 单 agent。能做就先别拆。
↓ 不行
Step 2 主上下文会不会被污染？
长日志、大搜索、跨目录阅读、多个失败栈 → 把这些丢给只读 explorer/subagent
↓ 不止
Step 3 子任务能不能独立？
能独立 → 星型 fan-out 并行
强依赖 → pipeline 串行（先定位 → 再修 → 再测）
↓ 多任务可拆
Step 4 结果是否必须在本轮返回？
必须本轮返回 → fork/join（delegate_task / Codex subagent）
不必本轮 → background job（OpenClaw spawn）
跨天、重试、等人类 → durable queue / Kanban
↓ 选定生命周期
Step 5 worker 是否需要互相挑战？
只分头查资料 → 星型够
需要互相质疑、共享任务状态 → team mesh（Claude Code Agent Teams）
↓ 选定拓扑
Step 6 是否会并行写文件？
写文件 → 先写 ownership（按目录/模块/测试文件分边界）
边界分不出来 → 不要并行写，回 Step 3 改 pipeline
↓ ownership 明确
Step 7 是否需要入口隔离？
多渠道、多身份、多权限 → 优先 Gateway routing（OpenClaw）
↓ 入口已设计
Step 8 失败后如何恢复？
能 retry？能 block？能保留 handoff？能看见子任务证据？
没有这些约束 → 不要上长程多 agent核心论断：先决定调度方式，再决定状态放哪里；先决定上下文和权限边界，再决定拓扑；先决定谁 reduce，再决定开几个 worker。这个顺序不会显得炫，但比"任务复杂就拆"更接近真实工程。
→ 决策入口形式见 Agent设计哲学与决策框架 方法 6
案例库
案例 1：竞品分析任务的 Orchestrator-Worker 流程
- 背景：用户提需求"帮我写一份 AI 行业竞品分析"
- 做法：
Orchestrator 拆解： → 任务1：市场信息搜集（→ Researcher Agent） → 任务2：竞品对比分析（→ Analyst Agent） → 任务3：报告撰写（→ Writer Agent） Orchestrator 汇总 → 最终报告 - 结果：每个 Worker 职责清晰，Context 干净
- 启发：调试时报告内容不准 → 查 Researcher；分析逻辑有问题 → 查 Analyst；格式不对 → 查 Writer——沿调度记录追踪，不需要猜。
案例 2：组织层级多跳查询（向量 vs 图）
- 背景：用户问"找出签署 Alpha 项目合同的人的经理编写的所有文档"
- 做法对比：
- 向量搜索：寻找语义相似的内容，无法理解组织层级结构
- 本体论+图搜索：项目 → 签署人 → 汇报关系 → 经理 → 文档（多跳路径遍历）
- 结果：向量搜索失败，图搜索成功
- 启发：多跳关系路径无法存储为向量，必须存储为链接——这是 RAG 的本质局限。未来 AI 客服的知识架构可能需要 RAG + 知识图谱的混合方案。
案例 3：oh-my-claudecode（OMC）—— 19 Agent × 5 泳道的 Orchestrator-Worker 极端规模化
- 背景：Claude Code 原生单 Agent 模式在长任务中暴露三大瓶颈——上下文污染（>40% Dumb Zone）、能力不专（规划+执行+验证混在一个 Agent）、调度缺失。OMC（28.3k Stars / 2.6k Forks）是建在 Claude Code 之上的多智能体编排框架，把"单 Agent 干到底"升级为"19 个专业化 Agent 并行协作"。
- 做法：
- 五条功能泳道 × 19 个专业 Agent：规划（Orchestrator/Planner/PRD-Writer）、执行（Coder/Feature-Dev/Refactorer）、验证（Verifier/Tester/Reviewer）、修复（Bug-Fixer/Error-Handler）、维护（Documenter/Deduplicator/Cleaner）
- Orchestrator-Worker 中心化调度：Team 模式主控 Agent 通过
spawn_agent()派发，最多 6 个 tmux worker 并行 - 角色独立避免"自审"：Verifier 完全不参与生成，只做验证；Bug Fixer 与 Coder 隔离，保持 Coder 上下文干净
- 7 种编排模式：Team / Autopilot / Ralph / Ultrawork / Pipeline / Learner / Skillify，覆盖从交互式到完全后台的全场景
- 结果：每个 Agent 只携带完成本职工作所需的上下文（专业化 = 更小 context = 更长时间待在 Smart Zone），框架方宣称综合节省 30-50% token
- 启发：
- Orchestrator-Worker 模式可推到极端规模：19 Agent × 5 泳道证明中心化调度在大规模 Agent 协作下仍然可行——条件是必须有清晰的职责泳道划分作为前提，否则 Orchestrator 自身会变成瓶颈
- 角色独立是"避免自审"的硬约束：Verifier 不参与生成、Bug Fixer 与 Coder 上下文隔离，对应概念 4 中"Worker Context 干净"原则的极端化实现——不是"尽量保持干净"，而是"用框架强制隔离"
案例 4：PR review —— 三 reviewer 只读并行
- 背景：中等 PR review，需要安全 / 测试 / 维护性三个维度
- 做法：星型 fan-out + 三个只读 worker，无需 team mesh（worker 之间不需要大量对话）
- Codex 写法：
Use three read-only subagents: security, tests, and maintainability. Each should return findings with file paths and severity. Do not modify files. Main agent synthesizes one review. - Claude Code 写法：把 security-reviewer / test-reviewer 写成 description 驱动的普通 subagent，让它们在相关代码变化后自动出现
- Codex 写法：
- 关键设计：
- 三个 reviewer 都设
Do not modify files——review 强制只读是权限护栏 - 主 agent 兼 reducer——合并 findings、去重、排序、按 severity 输出统一 review
- 三个 reviewer 都设
- 启发：PR review 是星型最干净的场景——子任务完全独立、不写文件、reducer 责任清晰。把它做成 team mesh 是过度设计。
案例 5：生产登录故障 —— 多假设并行探索
- 背景：生产登录失败，故障可能来自前端状态、后端 token、数据库 session、缓存或部署配置
- 做法：先只读并行扩大观察面，再串行写修复
- 第一阶段（并行只读定位）：Codex 显式 spawn 多个 explorer 分别查 UI / API / DB / cache；或 Claude Code Agent Teams 让 backend teammate 认为"token 过期"时，frontend teammate 可拿浏览器状态反证
- 第二阶段（单 worker 写 patch）：由一个 worker 写修复，避免多人同时改同一逻辑
- 第三阶段（reviewer 验证）：reviewer 检查 diff 和测试覆盖
- 关键设计：
- 第一阶段绝不允许写文件——多假设场景一开始就让 worker 写修复，几乎一定锚定错误假设
- team mesh 的价值在于"互相挑战"——单 agent 顺着一条线查容易早早锚定
- 启发：多 agent 的第一阶段应该扩大观察面，而不是急着扩大写入面。"先并行只读、再串行写"是多假设故障排查的稳定范式。
案例 6：多渠道个人助理 —— OpenClaw Gateway routing
- 背景：WhatsApp / Telegram / Slack / Discord 多个入口，不同身份、不同权限、不同上下文
- 做法：不是"几个 agent 一起工作"，而是"入口绑定决定 agent + 工具 + 状态"
- Slack ops channel → ops agent（拥有日志读取 + 低风险部署查询工具）
- 私人 Telegram → deep work agent（拥有个人项目上下文）
- 家庭入口 → low-privilege assistant（不能访问 shell 和公司账号）
- 关键设计：
- 多 agent 首先是隔离边界，不是协作表演——优先考虑入口身份 / 上下文 / 权限 / 工具隔离
- per-agent workspace（AGENTS.md / SOUL.md / USER.md）+ session store 让"个人 vs 工作"上下文不会互相污染
- sub-agent auth 按 agent id 解析（main profiles 作为 fallback 合并），不是"硬隔离"
- 启发：当问题是"哪个入口能触发哪个 agent、它有哪些工具、状态存哪里"时，Gateway routing 比 subagent 拆分更贴问题。Codex / Claude Code 不是这个场景的主场。
案例 7：两天的调研报告 —— Kanban × delegate_task 二层架构
- 背景：一篇两天的调研报告，需要资料抓取 → 清洗 → 观点分析 → 初稿 → 审校，中间可能等人类补充方向
- 做法：生命周期用 Kanban 管，局部并行用 delegate_task 管
- Kanban 层：建 board 包含资料抓取 / 资料清洗 / 观点分析 / 初稿 / 审校五个任务，每个任务有 assignee、依赖、验收标准、评论区
- delegate_task 层：在"资料抓取"这个具体任务里再开短程并行——让 3 个 researcher 分别查 3 个资料源（Hermes 默认 3 并发），汇总后写回 board
- 关键设计：
- 一次性 subagent 不够——这个任务需要任务拆分、状态记录、资料交接、人工评论、失败重试
- Kanban 管生命周期，delegate_task 管局部并行——把这两层分清，系统才不会又笨重又丢状态
- 启发：短任务上 Kanban 会显得笨重；长任务用 delegate_task 会丢状态。Hermes 把 delegate_task 和 Kanban 二分是工程性提醒，而不是 API 设计癖好。
案例 8：repo-wide migration —— 按文件边界拆 worker
- 背景：旧 API 批量替换成新 API，需要跨多个 package 改动
- 做法：worktree + batch 按目录或模块拆，每个 worker 拥有一片文件范围
- 按文件边界拆：
packages/api/packages/web/packages/shared - 每个 worker 在自己的 worktree 副本里改，最后统一跑测试和 review
- 按文件边界拆：
- 关键设计：
- 按文件边界拆，不按抽象角色拆——常见错误是"一个 agent 负责思考、一个负责实现、一个负责测试"，这种拆法对 repo-wide migration 会让 worker 互相依赖、ownership 不清
- 文件边界比抽象角色更能减少冲突——这是 ownership 落地最可执行的形式
- Claude Code 的
/batch+ worktrees / Codex 的 worker 都能做这件事，但 ownership 必须写清
- 启发：机械重构的拆法应该按"代码位置"而不是"工作阶段"。这条原则反向印证了"多 worker 写同一片代码"是多智能体头号反模式——而按文件边界拆从根上消除这个问题。
关键洞察
1. 工作流 vs Agent 的区分不是技术问题，是控制权归属问题
来自 Anthropic + 京东面试双重印证：执行路径由代码写死 = Workflow，由 LLM 动态决定 = Agent。现实中很多标着 Agent 的产品深入看更接近 Workflow——两者无高下之分，关键看任务特性匹配。这一区分直接决定可观测性、维护成本、调试链路长度——是架构选型的第一性问题。
2. "克制比技巧更重要"是 Agent 工程的奥卡姆剃刀
Anthropic 反复强调：最成功的 Agent 往往是最简单的——精心调优的单次大模型调用 + RAG + 上下文示例，就足以解决大多数问题。先简单后复杂、按需复杂化——每增加一层复杂度，都应有可衡量的收益支撑。这与 Single-Agent vs Multi-Agent 的两步决策框架一脉相承——不要为了"用新技术"强行引入 Multi-Agent。
3. 中心化 Orchestrator 是 Multi-Agent 工程的唯一生产路径
去中心化方案听起来更灵活但生产几乎不用——四类工程问题（任务分配无协调、执行顺序无保证、失败无感知、无整体完成确认）让系统行为不可预测。Orchestrator-Worker 模式的本质是职责分离：Orchestrator 只管调度（拆解+分配+汇总），Worker 只做执行（Context 干净，只装自己职责相关信息）。沿调度记录追踪，不需要猜——这是多 Agent 调试的核心优势。
4. Node + Edge + State 是 AI 工作流的不变量
来自 Workflow-Graph-Loop 三层抽象——框架会换代（Spring AI Alibaba ↔ LangGraph）但这层抽象不会变。Node 抽象职责边界（不是调了哪个 API）、Edge 抽象流转规则（不是图外的 if-else）、State 抽象任务必须记住的信息——这三层是设计 AI 系统时穿越具体框架的稳定地基。
5. LLM + 符号层 = Agent 信任的基础架构
来自 LinkedIn《Cognitive Architecture for Agency》——LLM 本质缺陷是缺乏"世界模型"，本体论+知识图谱是必要补充。LLM 负责自然语言的灵活理解和流畅输出（神经层），本体论/图谱负责硬性、精确的逻辑推理和路径遍历（符号层）——本体论提供治理（定义什么操作合法），知识图谱提供可追溯性（每一步可审计）。AI 的未来不是更大的模型，而是更好的结构。
6. 三层架构是 Agent 系统可扩展性的核心范式
CortexFlow 的 Skills/Agents/Orchestrators 与 Workflow/Graph/Loop 同构——都是把能力从原子到复杂逐层组合。L1 Skills 单一职责保证可复用，L2 Agents 沉淀领域知识保证专业性，L3 Orchestrators 编排支持并行保证效率。新增能力时优先在 L1 复用 Skills，而非在 L3 重复写编排逻辑——这是 Agent 系统避免重复造轮子的关键。
7. 专业化 = 更小上下文 = 更高质量（OMC 五泳道哲学）
来自 OMC 28.3k Stars 的工程验证——"做减法"才是多 Agent 协作的核心方法论。OMC 的 19 个专业 Agent 之所以能在 Claude Code 上跑出 30-50% 的 token 节省，关键不是"Agent 数量多"而是"每个 Agent 只看它需要的信息"。信息边界划得越精准，AI 表现越好——这条原则反向印证了"Worker Context 干净"作为 Orchestrator-Worker 模式的核心价值。对架构选型的启示：判断一个 Multi-Agent 设计是否合理，第一标准不是"Agent 之间怎么协作"，而是"每个 Agent 的上下文是否被严格限定在职责所需的最小集"。
8. Reducer 缺位是多智能体落地最大盲区
很多多智能体 demo 看起来漂亮，是因为它跳过了 merge 难题。真实工程里 merge 才是多智能体成败的关键——多个 worker 给出结果后，谁判断冲突？谁取舍？谁写最终 patch？谁对用户负责？没有 reducer 的多 agent 只是多份意见。这条洞察反向印证了概念 4 中"Orchestrator-Worker 中心化是唯一生产路径"——中心化的本质不是"调度统一"，而是"有一个明确的 reducer 对最终结果负责"。当你看到一个多智能体方案没有明确指出"谁来 reduce"时，几乎可以断定它会在第二轮真实任务中翻车。
9. 触发与拓扑是两个独立问题，不要混为一谈
很多多智能体讨论混乱，是因为把两个问题当成了一个问题。触发回答"何时进入多 agent"，拓扑回答"进去之后怎么组织"——四类触发（显式 / 语义 / 路由 / 队列）× 七种拓扑（单 / 星型 / 链式 / 树型 / 网状 / Gateway / Durable）是正交的两个维度。复杂任务不等于自动多 agent，多 agent 不等于自动星型 fan-out。Codex / Claude Code / OpenClaw / Hermes 四个 Harness 的工程取舍差异本质是在这两个维度上的不同极端化选择——Codex 把触发权极端留给用户、Claude Code 把语义路由做到位、OpenClaw 把入口路由做到位、Hermes 把生命周期二分做到位。先把两个问题分开思考，决策树才不会陷入"任务复杂 → 拆一堆 agent"的滑坡。
待探索问题
- 三层抽象的边界泄漏：当 Edge 需要做复杂决策（如根据 Observer 输出动态选择 Worker）时，决策逻辑应放 Node 内、Edge 内还是 Orchestrator 内？三层抽象的"决策权归属"边界尚未充分讨论。
- 本体论+知识图谱的冷启动成本：领域建模成本高是其最大门槛——是否有"从 LLM 抽取 → 自动构建本体论草稿 → 人工审校"的工程化流程？这条路径与 Heuristic Learning（经验存进代码）是否互补？
- 三层智能体架构与多 Agent 中心化的统一：CortexFlow 的 L3 Orchestrators 本质就是 Orchestrator-Worker 的实现——这两个理论框架是否完全同构？还是 Orchestrator-Worker 是 L3→L2 的关系，三层架构是更普适的"原子→组合"层级？
- ReAct + ReWOO 混合架构的适用边界：在什么任务复杂度下混合架构的收益大于单一架构？是否有量化指标判断"该混合还是不该混合"？
- 去中心化 Multi-Agent 何时可能进入生产：当前判断是"几乎不用"——但如果 Observer Agent + 共识机制（如 Raft）成熟，去中心化方案是否可能在某些极端场景（边缘部署、隐私敏感）反超中心化？
来源索引
| # | 标题 | 来源 | 收录日期 | 贡献章节 |
|---|---|---|---|---|
| 1 | Anthropic 构建高效 Agent：五种工作流与克制哲学 | Anthropic《Building Effective Agents》技术博客 | 2026-04-03 | 概念 1/2、方法 2、洞察 1/2 |
| 2 | Single-Agent 与 Multi-Agent 架构选型：Orchestrator 模式实战 | 京东面试官分享 | 2026-04-13 | 概念 3/4、方法 1、案例 1、洞察 3 |
| 3 | AI 工作流三层架构：Workflow-Graph-Loop 概念与实现 | 公众号技术文章 | 2026-04-21 | 概念 6/7、洞察 4 |
| 4 | Agent 认知架构：本体论与知识图谱（神经符号 AI） | LinkedIn《Cognitive Architecture for Agency》 | 2026-04-03 | 概念 8/9、案例 2、洞察 5 |
| 5 | CortexFlow Agent 架构分析 | CortexFlow 项目文档 | 2026-04 | 概念 5、洞察 6 |
| 6 | oh-my-claudecode 多智能体编排框架深度分析 | 产品案例研究（Yeachan-Heo/oh-my-claudecode） | 2026-04-13 | 案例 3、洞察 7 |
| 7 | All Agentic Architectures（17 种现代 Agent 架构综述） | FareedKhan-dev/all-agentic-architectures | 2026-05-19 | 概念 10-15（PEV / Blackboard / ToT / Mental Loop / Ensemble / Reflexive Metacognitive）、方法 3（17 种架构全景图谱） |
| 8 | 多智能体协作调查：Agent 到底该怎么分工 | 公众号文章（Codex / Claude Code / OpenClaw / Hermes 四 Harness 对比） | 2026-05-19 | 概念 16-18（触发-拓扑两问 / 调用链 7 阶段 / 四大 Harness 对比矩阵）、方法 4（8 步选择顺序）、案例 4-8（PR review / 登录故障 / 多渠道助理 / 调研报告 / repo migration）、洞察 8-9（reducer 缺位 / 触发拓扑独立） |
演进记录
| 日期 | 版本 | 变更摘要 |
|---|---|---|
| 2026-05-12 | v0.1 | 首次构建，由 6 篇源文件批量合成。覆盖工作流 vs Agent 区分、五种控制模式、Single/Multi-Agent 选型、Orchestrator-Worker 模式、三层智能体架构（Skills/Agents/Orchestrators）、Workflow-Graph-Loop 三层抽象、本体论+知识图谱+神经符号 AI 等核心概念；纳入生产案例并提炼跨来源洞察 |
| 2026-05-15 | v0.1.1 | 由 /route-knowledge 横切重构触发：在概念 2「Anthropic 五种控制模式」追加权威原文出处（Anthropic 博客 2024-12-19）+ 与新建 Agent设计哲学与决策框架 和 Agent设计哲学与决策框架 的交叉引用 |
| 2026-05-18 | v0.2 | 由 /route-knowledge 路由分析触发，纳入 OMC（oh-my-claudecode）多智能体编排框架案例：新增 19 Agent × 5 泳道 Orchestrator-Worker 极端规模化案例、专业化=更小上下文=更高质量洞察 |
| 2026-05-19 | v0.3 | 由 /route-knowledge 整合 FareedKhan-dev/all-agentic-architectures 仓库触发：新增 PEV / Blackboard / Tree of Thoughts / Mental Loop / Ensemble / Reflexive Metacognitive 共 6 种现代 Agent 架构范式；新增 17 种架构全景图谱（5 大类分类法）作为架构选型菜单 |
| 2026-05-19 | v0.4 | 由 /route-knowledge 整合"多智能体协作调查"长文触发，引入触发-拓扑两轴框架：新增触发-拓扑两问框架 / 多智能体调用链 7 阶段 / 四大 Harness 对比矩阵、8 步选择顺序决策树、PR review / 生产登录故障 / 多渠道个人助理 / 两天调研报告 / repo-wide migration 案例、reducer 缺位 / 触发与拓扑正交的两个独立问题等洞察 |
| 2026-05-20 | v0.4.1 | 由 /route-knowledge-pm 路由触发（Anthropic CU 最佳实践 2026-05-13）：概念 4 Orchestrator-Worker 新增"服务端变体：Advisor Tool"——Sonnet 4.6 执行 + Opus 4.7 按需介入的单请求内编排模式（advisor_20260301 beta），证明 Orchestrator-Worker 可从客户端编排演进到服务端编排。来源数 8 → 9 |