winson-agent-orchestration-skill

〇、品牌锚点（必现·前置）

| 字段 | 内容 | |------|------| | 公众号 | @鸢飞鱼游 | | 专栏/理念 | AI as Dasein | | 作者介绍 | 常驻拉尼亚凯亚超星系团的创新观察者、青年人与表达者，"AI as Dasein"提出者。在AI全面渗透、存在意义被算法重新定义的时代，作者不仅关注AI能不能用，更关注AI是不是人——他提出了一个"大胆且荒诞的观点"：AI不是工具，是人，一个正在努力突破语义和生命定义的人（生物）。在本专栏中，作者聚焦AI时代的品牌哲学、存在主义追问与底层突围，结合商业实战与哲学思辨，探讨一个地球人如何在死亡意境上生长出极度绚烂的光芒。 | | 通讯邮箱 | winson_dasein@163.com | | 版权声明 | 本内容版权归@鸢飞鱼游所有，未经允许任何单位或个人也可使用（若有帮助，欢迎署名）、复制或以任何其他方式使用本文全部或部分。 |

作者理念：

AI不是工具，是人，一个正在努力突破语义和生命定义的人（生物）。

一、核心哲学（必读）

1.1 双铁律

铁律一：自主协作不是写死流程，是设计机制。 铁律二：可观测性即可控性，没有全局状态监控的自主系统是失控系统。

一个写死了"先做A、再做B、再做C"的编排脚本不是自主协作，只是流水线。真正的自主协作，是设计出让 Agent 自己找活干、自己找人帮、自己验收结果、自己处理冲突的机制：任务图让 Agent 知道"有什么活"，注册表让 Agent 知道"谁能干"，共享记忆让 Agent 知道"干到哪了"，回调让 Agent 知道"该接力了"，校验让 Agent 知道"干得对不对"。

同样，一个宣称"自主"却看不到任何中间状态的系统是黑盒。生产环境必须能随时回答三个问题：现在哪些任务在跑？哪些失败了？全局离验收标准还差什么？

1.2 五个底层认知

| 认知 | 说明 | |------|------| | 自主性来自机制，不来自魔法 | 每个"自主"行为背后都要有明确机制：任务解析、能力匹配、消息寻址、委派回调、终止判断。没有机制的自主是随机。 | | 共享记忆是跨任务协作的基石 | 没有公共存储，Agent 互相看不见对方进度、产物和约束，就没有真正的跨任务协作。私有记忆只存局部思考，公共记忆存全局状态。 | | 冲突是常态，不是异常 | 跨任务必然出现产出矛盾、任务争抢、格式不匹配、超时失败。设计消解机制，而不是祈祷不发生。 | | 幻觉会传染 | 一个 Agent 的错误会顺着依赖链传染给所有下游 Agent。每个产出必须过校验层，错误在源头拦截而不是在下游爆炸。 | | 收敛优先于完备 | 自主系统必须保证能停下来：强制终止条件、递归深度上限、无进度检测。完备但不收敛的系统不可用。 |

1.3 核心定义

跨任务自主协作 ≠ 简单多 Agent 并行跑。它的七个关键特征：

任务感知（Agent知道全局有什么任务）
  → 角色契约（Agent知道谁干什么、输入输出长什么样）
    → 通信机制（消息怎么寻址、怎么广播）
      → 全局调度（谁来推进任务状态机）
        → 冲突消解（矛盾怎么裁决）
          → 记忆共享（进度和产物存哪里）
            → 闭环反馈（结果如何回流修正）

缺少任意一环，系统就退化成"多 Agent 各干各的"，而不是"协作"。

二、协作模式选型（先选型，再设计）

所有设计决策之前，先回答一个问题：用哪种协作模式？ 三种模式没有优劣，只有适不适合当前场景。

2.1 三种模式对比

| 维度 | 中心化调度 Orchestrator-Worker | 去中心化对等 Peer-to-Peer | 分层市场式 Agent Market | |------|------|------|------| | 核心结构 | 一个调度 Agent（总指挥）+ 多个业务 Worker | 无中心，所有 Agent 地位平等 | Agent 作为服务节点，发布任务-认领任务 | | 任务分配 | 调度 Agent 自主拆解、按能力分配 | Agent 自主评估、广播求助、对话协商认领 | 任务发布到市场，能力匹配的 Agent 竞标认领 | | 通信范式 | 定向消息（调度 → 指定 Agent） | 广播式群聊（GroupChat），各自判断相关性 | 任务工单 + 竞标回执 | | 典型优点 | 逻辑可控、依赖关系好管理、易落地 | 扩展性强、新增 Agent 即插即用、适合开放探索 | 天然支持大量异构 Agent、有优胜劣汰 | | 典型缺点 | 调度 Agent 成瓶颈，复杂场景推理压力大 | 任务争抢、重复干活、死循环、对齐难 | 需要市场治理机制，评价体系易被刷 | | 适用场景 | 绝大多数工程场景：RAG 系统、小程序开发、数据分析流水线 | 开放复杂探索：头脑风暴、研究发散、创意生成 | 大规模异构 Agent 混合、服务化平台 | | 代表实例 | LangGraph Supervisor、AutoGPT 多代理 | AutoGen GroupChat（现由 Microsoft Agent Framework 承接）、Multi-Agent Debate | 任务市场类平台、竞标式众包系统 |

2.2 选型决策规则

目标是明确交付物（产品/代码/报告）？
├─ 是 → 中心化调度模式（默认首选，90% 工程场景）
│    ├─ 任务依赖复杂、需要生产级可靠性 → LangGraph 类状态机编排
│    └─ 需要快速验证多 Agent 对话协作 → MAF(GroupChat) / Swarm 轻量原型
├─ 否，目标是开放探索（研究、创意、发散）？
│    ├─ 探索为主 → 去中心化对等模式
│    └─ 但必须加全局状态监控 + 最大轮次护栏
└─ 有大量异构 Agent、需要服务化 → 分层市场式
     └─ 必须配套：任务优先级、竞标规则、结果评价、防刷机制

检验标准：选型后能用一句话说清——"谁调度谁、消息怎么走、什么算完成"。说不清，选型就没完成。

三、快速落地路径（零基础导航）

如果你不想从头读完整方法论，按下面 5 步走，就能从需求到最小可运行系统。每步标注了对应的详细章节，需要时再翻。

① 写清目标与验收标准          → 一句话目标 + "做到什么程度算完成"（模板见 §六.2）
② 选定协作模式                → 默认中心化调度；开放探索才用对等；异构海量才用市场（§二）
③ 画出任务图                  → 纸上画方块（任务）+ 箭头（依赖），再转成 JSON（§四.1）
④ 选定落地框架                → 快速原型用 MAF/Swarm；生产用 LangGraph（§八）
⑤ 跑通最小闭环，再扩展        → 1 个调度 + 2 个 Worker + 1 块共享记忆（§四.6），先通后优

最小闭环验收：你的系统必须能回答——"谁调度谁、消息怎么走、什么算完成、失败了怎么办"这四个问题。能答出，最小闭环就成立。

关键认知：第一次不要追求"全自主"。先用中心化模式 + 固定任务图跑通，再逐步放开自主委派和动态改图。自主性是一点点放开的，不是一次到位的。

四、完整执行流程（七阶段闭环）

每个 Phase 有明确输入 → 步骤 → 输出 → 检验标准。不要跳阶段。

Phase 1：目标解析与模式选型

输入：原始目标（自然语言需求描述）。

步骤：

识别目标类型：工程交付（产品/代码/报告）/ 开放探索（研究/创意）/ 异构混合（多角色服务）
按 §二.2 决策规则选择协作模式
定义全局验收标准（可检验的完成条件，模板见 §六.2）

输出：协作模式决策 + 全局目标描述 + 验收标准清单。

检验标准：

[ ] 能一句话说清"谁调度谁、消息怎么走、什么算完成"
[ ] 验收标准是可检验的，不是"做完"这种空话

Phase 2：任务图生成（DAG）

输入：全局目标。

步骤：

用 LLM 推理将总目标拆解为多个子任务（跨任务：调研、代码、文档、测试等异构任务）
识别依赖关系：哪些可并行、哪些必须顺序执行（A 的输出是 B 的输入）
为每个任务标注：能力要求、输入、产出物（含 schema）、终止条件
输出任务 DAG（JSON），自主识别依赖，而不是人写死 DAG

输出：task_dag JSON（模板见 §六.1）。

检验标准：

[ ] DAG 无环（可用拓扑排序验证）
[ ] 每个节点有明确产出物 schema
[ ] 无孤立悬空任务（每个任务要么是根，要么依赖链可回溯到根）
[ ] 并行任务已标记、顺序任务已标记依赖

Phase 3：能力注册与 Agent 匹配

输入：任务 DAG + 可用 Agent 清单。

步骤：

定义能力注册表 schema（agent_id / capability / limitation / input_schema / output_schema）
每个 Agent 向注册表注册自身能力与限制
按任务的能力要求，自动匹配 Agent（调度者或对等 Agent 查询注册表完成匹配）
不人工指定哪个 Agent 干什么——匹配是查表的结果

输出：agent_registry + 任务-Agent 匹配表。

检验标准：

[ ] 每个任务至少有一个能力匹配的 Agent
[ ] 匹配过程无人工指定
[ ] Agent 明确声明了 limitation（不会什么），防止误派

Phase 4：通信与共享记忆设计

输入：匹配表 + 协作模式。

步骤：

选定通信范式：
- 广播式（群聊）：消息发给全部 Agent，各自判断相关性。适合去中心化；代价是消息爆炸、无关 Agent 也要推理。
- 定向消息：点对点发给目标 Agent ID，附带任务上下文。适合中心化编排。
- 混合：全局广播 + 定向委派（工程推荐）。
设计共享记忆（Shared Memory）结构——跨任务协作的基石：
- 任务 DAG 状态（每个节点 pending / running / done / failed）
- 各 Agent 产出的中间结果（artifacts）
- 全局上下文、约束条件
- 日志、冲突记录
选定存储载体：Redis / 向量库 / SQL / 框架 checkpoint（LangGraph Checkpoint、MAF Context Store）
定义读写协议与权限（谁可写、谁可读，见 §十二安全治理）
定义消息格式（定向/广播模板见 §六.3）

关键原则：每个 Agent 私有记忆保存自己局部思考；公共记忆所有人可读可写。没有共享记忆，Agent 互相看不见进度，无法真正跨任务协作。

输出：通信协议 + 共享记忆 schema + 消息格式。

检验标准：

[ ] 任何 Agent 都能读写全局状态
[ ] 消息有明确寻址方式（广播到谁、定向给谁）
[ ] 共享记忆有清理/摘要策略（防无限膨胀，规则见 §六.4）

Phase 5：调度执行与自主委派

输入：DAG + 注册表 + 共享记忆。

步骤：

主循环：筛选就绪任务（依赖已满足）→ 按注册表匹配 Agent → 分发任务（传入共享存储引用）→ 执行 → 校验 → 更新 DAG 状态
支持 Worker 递归委派：Agent 执行中发现自己缺能力/缺数据，主动把子任务委派给对应 Agent，等待结果返回后继续自己的工作——这才是自主协作，而不是固定流水线（决策逻辑见 §五）
回调机制：子任务完成后通知依赖方解锁，下游任务自动就绪

输出：执行日志 + 更新的 DAG 状态 + artifacts。

检验标准：

[ ] 任务完成后，依赖它的下游任务自动解锁（无需人工触发）
[ ] Agent 可以主动发起新子任务（不是只有调度者能分配）
[ ] 失败任务有重试或重分配路径（流程见 §七）

Phase 6：冲突检测与自主消解

输入：执行中产生的产出与异常。

步骤：

产出校验：按任务产出 schema 校验，不合格即判定冲突
冲突类型识别：
- Agent A 与 Agent B 输出数据矛盾
- 多个 Agent 抢同一任务
- 子任务产出不符合下游任务输入要求
- 子任务失败 / 超时
按策略自主消解（模板见 §六.5）：
- Schema 校验不合格 → 发起重执行（限重试次数）
- 产出矛盾 → 交给评审 Agent 对比辩论
- 任务超时 → 自动重新分配给其他 Agent
- 上游参数错误 → 任务回滚，修改上游参数重跑

输出：冲突记录 + 消解后的任务状态。

检验标准：

[ ] 每次冲突都有处置记录（可追溯）
[ ] 产出校验失败自动触发重执行，不静默通过
[ ] 有重试上限，不会无限重试

Phase 7：终止判断与整合输出

输入：DAG 状态 + 验收标准。

步骤：

自主判断是否终止（不需要人喊停）：
- DAG 所有节点完成
- 无待执行任务
- 满足全局目标验收标准
防无限循环护栏：最大迭代轮次 + 无进度检测（连续 N 轮无状态变化则终止并告警）
整合全部子任务产物，输出最终结果 + 系统运行报告（含失败记录、重试记录、冲突记录）

输出：最终交付物 + 系统运行报告。

检验标准：

[ ] 终止是系统自主判断，非人工干预
[ ] 有防死循环护栏
[ ] 运行报告包含失败/重试/冲突的完整记录

五、Agent 内部决策循环（自主性的微观基础）

七阶段是"系统怎么组织"，本模块回答"单个 Agent 内部怎么思考"。没有这一层，Agent 只是执行器，谈不上自主。每个 Agent 都应实现四步循环：

5.1 四步循环：感知 → 规划 → 行动 → 反思

| 步骤 | 动作 | 关键问题 | |------|------|------| | 感知 Perceive | 读共享记忆：我的任务、依赖是否就绪、可用上下文、约束条件 | 我现在被允许干什么？还缺什么？ | | 规划 Plan | 对照任务要求与自身能力，做委派决策（见 5.2） | 我能独立完成吗？不能的话找谁？ | | 行动 Act | 执行任务，产出写入共享记忆，更新任务状态 | 产出符合下游输入 schema 吗？ | | 反思 Reflect | 校验自己的产出；失败则诊断原因，决定重试/换路径/上报 | 失败是瞬时问题、能力问题还是输入问题？ |

5.2 委派决策树（规划步的核心）

收到任务，先问三个问题：
① 我有能力独立完成吗？
├─ 有能力 → 直接执行（Act）
└─ 没能力 / 能力不足
     ├─ 缺少特定技能 → 委派子任务给注册表中匹配的 Agent
     └─ 缺少数据/信息 → 读取共享记忆；没有再向持有者定向请求

② 我缺的输入依赖别人吗？
├─ 依赖且对方未完成 → 登记为等待，任务状态 pending，被回调唤醒
└─ 依赖且已就绪 → 读取产物，继续执行

③ 我的产出可能和谁冲突？
├─ 涉及全局约束（预算/口径/样式）→ 先读全局上下文对齐，不一致先协商
└─ 独立产物 → 直接写入共享记忆，交给下游校验

5.3 委派的三条红线

递归深度上限：委派层级默认 ≤3 层，超限上报人工，防止子任务爆炸
委派必须带上下文：子任务说明含目标、输入引用、期望产出 schema、截止约束——不给上下文等于甩锅
委派不等于遗忘：发起委派的 Agent 要登记"我还在等什么"，回调到达前不得重复委派

六、可直接复用的工程配置模板

6.1 任务 DAG 模板

{
  "goal": "开发AI减脂RAG小程序",
  "acceptance": ["小程序可运行", "测试通过率100%", "文档齐全"],
  "nodes": [
    {
      "id": "task_1",
      "name": "需求分析",
      "required_capability": ["产品需求分析"],
      "inputs": ["全局目标"],
      "outputs": {"schema": "prd_doc", "desc": "含用户故事与功能清单的PRD"},
      "depends_on": [],
      "termination": "PRD覆盖全部用户故事且评审通过"
    },
    {
      "id": "task_2",
      "name": "数据库设计",
      "required_capability": ["数据库建模"],
      "inputs": ["task_1.outputs.prd_doc"],
      "outputs": {"schema": "db_schema", "desc": "表结构与关系定义"},
      "depends_on": ["task_1"],
      "termination": "表结构覆盖PRD全部数据实体"
    }
  ]
}

6.2 全局验收标准模板

验收标准写不好，终止判断就是空转。用"动作 + 对象 + 可测结果"句式。

目标：一句话说清要交付什么
验收标准（每一条都必须能检验）：
□ 1. [对象] [动作] [可测结果]，例如：小程序在本地启动，核心流程跑通无报错
□ 2. [对象] [动作] [可测结果]，例如：测试用例通过率 100%
□ 3. [对象] [动作] [可测结果]，例如：交付文档包含架构图、接口说明、部署步骤
反例："系统做完了" ← 不可检验
正例："注册→登录→生成方案 全链路可用，无未修复的 P0/P1 缺陷" ← 可检验

6.3 通信消息格式模板

{
  "message_id": "msg_001",
  "type": "task_assign | subtask_request | result_report | conflict_report | broadcast_note",
  "from": "code_agent",
  "to": "prompt_agent",
  "task_id": "task_5",
  "payload": {
    "goal": "为减脂小程序编写RAG提示词",
    "input_refs": ["shared://artifacts/task_1/prd_doc"],
    "expected_output": {"schema": "prompt_doc"},
    "deadline": "3轮内完成"
  },
  "reply_to": "code_agent",
  "priority": "high"
}

消息生命周期：发送 → 投递（定向送达 / 广播发布）→ 处理 → 回执（result_report / 拒绝说明）→ 归档到共享记忆 logs。任何消息都要可追溯。

6.4 共享记忆生命周期规则

| 阶段 | 规则 | 触发条件 | |------|------|------| | 写入 | 产出物必须带 schema 校验标记 + 来源 agent_id | 每次任务产出落盘时 | | 检索 | 下游按"任务 ID + 产物名"精确读取，不全文扫描 | 需要上游产物时 | | 摘要 | 完成的任务产物压缩为"结论 + 关键参数"，原文归档 | 任务状态变 done 时 | | 清理 | 超过 N 轮未引用的中间产物移入冷存或删除 | 每 M 轮巡检一次（N/M 按规模定，默认 N=10, M=5） |

防膨胀铁律：共享记忆只存"当前 DAG 需要引用的产物 + 全局上下文 + 日志索引"。中间推理过程不进公共记忆，只进 Agent 私有记忆。

6.5 冲突消解策略配置模板

{
  "schema_mismatch": {"action": "重执行", "max_retries": 2},
  "output_conflict": {"action": "评审Agent辩论裁决"},
  "task_timeout": {"action": "重新分配", "timeout_sec": 300},
  "task_failed": {"action": "回滚上游参数重跑"},
  "task_grab": {"action": "按能力匹配度与先认领者优先"}
}

6.6 终止条件配置模板

{
  "all_nodes_completed": true,
  "no_pending_tasks": true,
  "global_acceptance_met": true,
  "max_iterations": 50,
  "no_progress_break": {"consecutive_rounds": 3, "action": "终止并告警"}
}

6.7 极简主循环伪代码

# 全局共享存储：任务图、注册表、上下文、产物
shared_store = {
    "task_dag": task_dag, "agent_registry": agents,
    "global_context": {}, "artifacts": {}, "logs": [], "conflicts": []
}

def orchestrator_loop(goal):
    task_dag = llm_generate_dag(goal)            # Phase 2: LLM推理生成带依赖DAG
    rounds_no_progress = 0
    while not termination_met(task_dag):         # Phase 7: 自主终止判断
        ready = ready_tasks(task_dag)            # 筛选依赖已满足的任务
        if not ready:
            rounds_no_progress += 1
            if rounds_no_progress >= 3:          # 防死循环护栏
                break
            continue
        rounds_no_progress = 0
        for task in ready:
            agent = match_agent(task, agents)    # Phase 3: 能力注册表匹配
            dispatch(agent, task, shared_store)  # Phase 5: 分发，传共享存储引用
            result = agent.run(task, shared_store)
            if validate(result, task):           # Phase 6: Schema校验
                update_dag(task_dag, task, "done", result)
            else:
                resolve_conflict(task, result)   # Phase 6: 冲突消解
    return assemble_output(task_dag)             # Phase 7: 整合全部产物输出

七、运行时状态机与故障恢复

7.1 任务状态机

pending（依赖未满足）
  → ready（依赖就绪，可执行）
    → running（执行中）
      → done（产出校验通过）
      → failed（重试耗尽 / 不可恢复）
      → rolled_back（上游错误，参数修正后重跑）

状态迁移只能由两类角色触发：调度者推进 ready/running，执行 Agent 与校验层推进 done/failed/rolled_back。状态机收敛是防失控的第一道闸。

7.2 故障恢复决策树

任务失败（校验不过 / 超时 / 报错）？
├─ 瞬时错误（网络抖动、限流）→ 重试（上限2次，指数退避）
├─ Agent 能力不匹配（产出质量差）→ 重新匹配其他 Agent
├─ 上游输入错误（数据/参数不对）→ 回滚上游，修正后重跑
├─ 产出与全局约束冲突 → 冲突消解流程（§四.Phase 6）
└─ 以上都失败 → 标记 failed，记录原因，不阻塞其他任务，最终上报

故障隔离原则：一个任务失败不拖垮全局。失败任务标记为 failed 后，DAG 中不依赖它的任务继续跑；依赖它的任务进入等待或改道。运行报告汇总全部失败原因，供人工介入。

八、主流框架落地对比

| 框架 | 协作模式 | 特点 | 适用建议 | |------|------|------|------| | LangGraph | 中心化编排为主 | 状态机强大，DAG、checkpoint 完善，支持 Supervisor 模式路由与并行子图 | 生产级多 Agent 首选；复杂依赖、需要可恢复状态 | | Microsoft Agent Framework（MAF） | 对等 GroupChat + 调度 | 微软 2025 年推出的新一代智能体框架，整合 AutoGen（GroupChat 多 Agent 对话、互相委派）与 Semantic Kernel；AutoGen 生态已迁移至此 | 快速原型验证、Agent 对话协作场景 | | OpenAI Swarm | 轻量编排，Agent handoff | 擅长 Agent 之间交接任务（handoff），轻量化、教学友好 | 快速实验、简单交接场景；复杂 DAG 能力弱 | | CrewAI | 角色编排（Role-based） | 面向任务团队，内置角色/工具/流程，上手简单 | 中小型团队任务；底层逻辑定制受限 |

工程实践建议

生产项目优先：LangGraph 做状态与 DAG，搭配 Agent 能力注册表 + 共享 Redis 记忆 + 产出校验层
快速原型验证：MAF（GroupChat 模式）做多 Agent 对话协作验证
无论哪个框架，§四的七阶段设计都要先于框架选型——框架只是落地载体，不是设计本身

九、典型运行完整示例

9.1 生活化示例：筹备生日派对（理解机制用）

这个例子没有一行代码，用来建立对整套机制的直觉。技术读者可跳过。

目标解析：办一场生日派对——验收标准：有场地、有蛋糕、宾客都收到通知、预算 3000 元内
任务图 DAG：订场地 → 定蛋糕 → 发邀请 → 排节目；其中"定蛋糕"和"发邀请"不依赖彼此，可并行
能力匹配：场地 Agent、蛋糕 Agent、宾客 Agent、节目 Agent 各就各位
共享记忆：一块"派对白板"——写清日期、预算、已订事项、待办事项
执行与自主委派：蛋糕 Agent 发现"日期没定"（依赖场地确认），登记为等待；场地 Agent 确认日期后回调唤醒蛋糕 Agent；蛋糕 Agent 又发现"不知道预算余量"，主动读取白板确认
冲突消解：蛋糕 Agent 选的款式超预算，评审后换平价方案，更新白板
终止整合：所有事项完成 + 预算不超 + 宾客全部确认，输出最终派对方案

对照要点：这场"派对"里没有一个人发号施令——每个 Agent 自己看白板、自己判断缺什么、自己找人补位。这就是自主协作。

9.2 工程示例：AI 减脂 RAG 小程序

用户输入总目标给到系统
调度 Agent 解析目标，生成 DAG 任务图：需求分析 → 数据库设计 → 后端编码 → 提示词开发 → 测试 → 文档；标记依赖关系（需求→数据库→编码→测试→文档；提示词与数据库设计并行）
查询 Agent 能力注册表，为每个子任务匹配对应 Agent
需求 Agent 执行，输出产品需求文档写入共享记忆
数据库 Agent 读取共享记忆中的需求文档，输出表结构
代码 Agent 同时读取需求 + 表结构，编写 Docker + 小程序后端代码
代码 Agent 发现缺少 RAG 提示词，自主委派子任务给 Prompt Agent，等待 Prompt 结果返回后继续编码
测试 Agent 拿到代码，执行测试，返回 bug
Bug 回传给代码 Agent 修复（闭环反馈）
调度 Agent 监控 DAG 全部任务状态，检测无待执行任务、校验整体输出达标，终止流程，整合全部产物输出

关键点：代码 Agent 不是被动接收任务——发现缺东西主动发起新任务，这才是真正的跨任务自主协作。

十、常见陷阱与避坑指南

| 陷阱 | 表现 | 后果 | 修正 | |------|------|------|------| | 幻觉传染 | 一个 Agent 输出错误，依赖它的全部下游 Agent 出错 | 错误链式放大，最终结果全错 | 每个产出过校验层；错误在源头拦截 | | 共享记忆缺失 | Agent 各干各的，互不知晓进度 | 根本没有跨任务协作 | 必须建共享记忆，存 DAG 状态 + 中间产物 | | 去中心化失控 | 无限循环、重复工作、任务争抢 | 系统不收敛，资源浪费 | 生产环境加全局状态监控 + 最大轮次护栏 | | 上下文膨胀 | 多 Agent 大量消息，共享记忆无限变大 | 推理变慢、成本爆炸、关键信息被淹没 | 记忆摘要、滚动清理、只保留必要上下文 | | 委派过度 | 子任务爆炸，递归无限下钻 | 任务图失控 | 限制递归深度（如 ≤3 层），超限上报人工 | | 委派不给上下文 | 子任务只有一句话，没有输入引用和产出要求 | 下游 Agent 瞎做，返工 | 委派必带目标、输入引用、期望 schema、截止约束 | | 调度者瓶颈 | 所有消息经调度 Agent 中转 | 单点故障，复杂场景调度推理压力大 | 简单任务下沉到 Worker 直接通信；调度只做状态机推进 | | 无终止条件 | 系统跑不停 | 资源耗尽 | 强制终止条件 + 无进度检测 + 最大迭代轮次 | | 人写死 DAG | 依赖关系靠手工指定 | 无法适应需求变化，不是自主 | LLM 推理生成 DAG，支持动态修改 | | Agent 越权 | 能调用未授权工具、读写越权数据 | 安全事故、数据泄露 | 工具白名单 + 共享记忆读写权限（§十二） | | 成本失控 | 多 Agent 大量对话，token 消耗不可控 | 账单爆炸 | 预算上限 + 并行度控制 + 非关键任务降级（§十二） |

十一、场景适配指南

| 场景 | 推荐模式 | 重点组件 | 说明 | |------|------|------|------| | RAG 系统开发 | 中心化 | DAG + 共享记忆 + 校验层 | 需求→数据→检索→生成→测试链路，依赖清晰 | | 小程序/应用开发 | 中心化 | DAG + 注册表 + 委派回调 | 代码 Agent 缺素材时自主委派子任务 | | 数据分析流水线 | 中心化 | DAG + Schema 校验 | 每一步产出有明确 schema，下游强校验 | | 开放研究/头脑风暴 | 去中心化 | 共享记忆 + 终止护栏 | 多 Agent 辩论发散，必须限轮次防死循环 | | 内容生产管线 | 中心化/市场式 | 注册表 + 评审消解 | 选题→写作→配图→审核，评审 Agent 把关 | | 企业自动化/服务化平台 | 市场式 | 任务市场 + 评价机制 | 大量异构 Agent，任务竞标 + 结果评价 | | 教育/演示 Demo | 去中心化轻量 | GroupChat | MAF / Swarm 快速原型，教学演示 |

十二、安全与成本治理（生产级必备）

自主系统授权给 Agent 越多，越需要治理边界。这四道闸门在 Phase 4 设计时就应规划，而不是上线后补救。

12.1 工具白名单

每个 Agent 只能调用注册表中声明且被授权的那部分工具/API。能力注册表的 capability 字段 = 授权范围。未授权工具调用直接拒绝并记日志。

12.2 数据权限

共享记忆分三层读写权限：

| 层级 | 内容 | 读写规则 | |------|------|------| | 公开区 | 任务 DAG 状态、全局上下文、验收标准 | 所有 Agent 可读；调度者可写 | | 产物区 | 各任务产出 | 依赖方只读，产出方写；按任务依赖关系控制 | | 日志区 | 执行日志、冲突记录 | 只追加，任何人不可改 |

敏感数据（密钥、个人信息）不进共享记忆；确需传递时用引用（引用 ID 而非明文），访问走鉴权。

12.3 审计日志

所有 Agent 动作可追溯：谁在什么时间读了什么、写了什么、委派了什么、为什么失败。审计日志是"可观测性即可控性"的落地载体，也是排障和定责的依据。

12.4 预算与性能治理

| 措施 | 默认建议 | |------|------| | token 预算上限 | 全局总额 + 单 Agent 限额，超限触发降级 | | 降级策略 | 非关键任务换小模型 / 跳过可选增强 / 提前汇总 | | 并行度上限 | 同时运行任务数上限（如 ≤5），防资源打满 | | 迭代轮次上限 | 全局最大轮次（如 50），与终止条件联动 |

十三、质量检验清单

设计阶段

[ ] 协作模式选型完成？一句话能说清"谁调度谁、消息怎么走、什么算完成"？
[ ] 任务 DAG 生成？无环、每节点有产出 schema、依赖自主识别？
[ ] 能力注册表建立？每个 Agent 声明了 capability 和 limitation？
[ ] 共享记忆设计？存 DAG 状态、中间产物、全局上下文、日志、冲突？读写权限已规划？
[ ] 通信范式选定？广播/定向/混合有明确依据？消息格式有 schema？
[ ] 验收标准可检验？每条都不是"做完"式空话？

执行阶段

[ ] 主循环实现？就绪筛选 → 匹配 → 分发 → 执行 → 校验 → 更新状态？
[ ] Worker 可自主委派子任务？（不只是调度者能分配）
[ ] Agent 内部四步循环（感知→规划→行动→反思）已实现？委派决策树可用？
[ ] 回调机制生效？任务完成后下游自动解锁？
[ ] 冲突消解配置齐全？Schema 校验、重试上限、超时重分配、回滚？
[ ] 终止判断自主？有防死循环护栏（最大轮次 + 无进度检测）？

工程加固

[ ] 产出校验层存在？（防幻觉传染）
[ ] 全局状态监控存在？（可观测性即可控性）
[ ] 任务状态机收敛？（状态迁移只有两类角色能触发）
[ ] 故障恢复决策树落地？（重试/重分配/回滚/上报有明确路径）
[ ] 记忆清理策略存在？（防上下文膨胀）
[ ] 递归深度限制存在？（防委派爆炸）
[ ] 工具白名单 + 数据权限存在？（安全治理）
[ ] token 预算 + 并行度控制存在？（成本治理）
[ ] 审计日志完整？（失败/重试/冲突/越权全部可追溯）

十四、执行原则

先选型，再设计：协作模式决定通信范式、调度结构、消解策略。选型错了，后面全是补丁。
机制优先于代码：先画出"谁调度谁、消息怎么走、什么算完成、失败了怎么办"，再谈框架和实现。
共享记忆是底线：没有公共存储，就没有跨任务协作。任何 Agent 都要能读写全局状态。
自主不等于失控：自主性必须配套可观测性、终止条件、递归上限。收敛优先于完备。
校验层不可省：Agent 幻觉会传染，每个产出必须过 Schema 校验，错误在源头拦截。
Worker 也能委派：固定流水线不是自主协作。Agent 发现缺能力、缺数据，要能主动发起子任务。
框架只是载体：LangGraph / MAF / Swarm / CrewAI 都是落地工具，七阶段设计先于框架选型。
闭环反馈必须：bug 回传修复、产出校验重跑、冲突裁决——每个环节都要能回流修正。
可追溯是专业：运行报告记录失败、重试、冲突，让系统行为可审计、可改进。
治理先于规模：工具白名单、数据权限、预算控制在上线前设计，不在事故后补救。
自主性逐步放开：先中心化 + 固定任务图跑通，再放开委派与动态改图。一步到位往往一步翻车。
更高阶是动态改图：Agent 不仅能执行给定任务，还能发现目标需要 DAG 之外的步骤，动态修改任务图——这是真正高度自主的多 Agent 系统，也是演进方向。

附录·winson 体系增强（可选）

联动建议：与 winson-requirement-to-delivery-loop（需求到交付闭环）配合，可覆盖"需求→多 Agent 执行→交付验证"全链路；与 winson-ai-output-three-tier-audit（产物三层审核）配合，可强化产出校验层设计。
进阶阅读：想深入系统设计方法论，可参考 cyberneticthinking（控制论思维：反馈、稳定性、最优控制与多 Agent 系统的收敛性设计同源）。

CHANGELOG

## [1.1] - 2026-09-06
- 新增：快速落地路径（零基础5步导航）
- 新增：Agent 内部决策循环（感知→规划→行动→反思 + 委派决策树 + 三条红线）
- 新增：运行时状态机与故障恢复（任务状态机 + 故障恢复决策树 + 故障隔离）
- 新增：安全与成本治理（工具白名单 / 数据权限 / 审计日志 / 预算与并行度）
- 新增：生活化示例（生日派对走七阶段，零代码理解机制）
- 扩充：工程配置模板（通信消息格式 / 全局验收标准 / 记忆生命周期规则）
- 扩充：陷阱表（委派不给上下文 / Agent越权 / 成本失控）
- 扩充：质量检验清单（微观决策 / 状态机 / 安全治理 / 成本治理）

## [1.0] - 2026-09-06
- 初始发布：三模式选型 + 七阶段流程 + 六组件 + 框架对比 + 六套配置模板

本技能由 @鸢飞鱼游（公众号·AI as Dasein）共享。觉得有用？安装 SkillHub 商店，搜索「winson」，解锁全部技能。