OpenClaw 与多 Agent 编排
OpenClaw 这条线现在不只是一堆公众号文章，而是已经出现了橙皮书、完整教程、安全指南和快入门手册，说明它从”爆火项目”变成了有文档、有部署规范、有安全叙事的完整平台。 [[raw/PDFs/OpenClaw橙皮书-从入门到精通.pdf|来源: OpenClaw橙皮书-从入门到精通.pdf]] [[raw/PDFs/OpenClaw完整教程_终极版.pdf|来源: OpenClaw完整教程_终极版.pdf]] [[raw/PDFs/《OpenClaw 安全部署与实践指南（360 护航版）》.pdf|来源: 《OpenClaw 安全部署与实践指南（360 护航版）》.pdf]]
平台定位
- OpenClaw 依然被描述成”接入万物、指挥一切”的通用 agent 平台，重点不在模型本身，而在网关、渠道接入、长时任务、记忆和多 agent 编排。 [[raw/2026-04-02/腾讯程序员/玩转OpenClaw，你需要了解的：核心架构、运作原理、Agent部署步骤.md|来源: 玩转OpenClaw，你需要了解的：核心架构、运作原理、Agent部署步骤.md]] [[raw/PDFs/OpenClaw橙皮书-从入门到精通.pdf|来源: OpenClaw橙皮书-从入门到精通.pdf]]
- 快速入门手册甚至直接把 OpenClaw 当成”全民 Agent 时代”的引爆案例，用它来解释为什么通用型智能体会迅速吞掉传统聊天产品的边界。 [[raw/PDFs/Claude Code快速入门实战指南.pdf|来源: Claude Code快速入门实战指南.pdf]]
教程体系已经成型
- 橙皮书偏全景：架构原理、部署方案、渠道接入、Skills、模型配置、安全与成本。 [[raw/PDFs/OpenClaw橙皮书-从入门到精通.pdf|来源: OpenClaw橙皮书-从入门到精通.pdf]]
- 完整教程偏中高级：AGENTS.md、记忆优化、子 agent、Cron 自动化、Skill 开发和多渠道部署。 [[raw/PDFs/OpenClaw完整教程_终极版.pdf|来源: OpenClaw完整教程_终极版.pdf]]
- 安全部署指南则把权限过大、暴露面过宽、企业零信任等问题单独拉出来，提醒”能干很多事”的另一面就是很容易把坑也放大。 [[raw/PDFs/《OpenClaw 安全部署与实践指南（360 护航版）》.pdf|来源: 《OpenClaw 安全部署与实践指南（360 护航版）》.pdf]]
多 agent 编排与治理
- 旧资料强调 OpenClaw 对模型能力正交、能承接 OAuth、Stripe、Replicate 等实战链路；新资料则把这条线补到治理、文档、教程和安全层，使它更像真正的”运行平台”。 [[raw/2026-04-06/孟健的AI编程认知/我用 OpenClaw 做后端开发：从 Stripe 支付到 AI 生成，全程不写一行代码.md|来源: 我用 OpenClaw 做后端开发：从 Stripe 支付到 AI 生成，全程不写一行代码.md]] [[raw/2026-04-24/秋芝2046/Openclaw养龙虾秘籍大公开！【安全+省钱】.md|来源: Openclaw养龙虾秘籍大公开！【安全+省钱】.md]]
- 从记忆优化、Cron、子 agent 到 Skills，OpenClaw 跟 Claude Code 正在朝相似方向进化：都在把长期执行与治理能力抬到工作流中心。 [[raw/PDFs/OpenClaw完整教程_终极版.pdf|来源: OpenClaw完整教程_终极版.pdf]] [[raw/2026-04-02/方圆yo/claude code 中 .claude 文件夹详解.md|来源: claude code 中 .claude 文件夹详解.md]]
Claude Code SubAgent 源码级机制
以下内容来自对 Claude Code 源码的逆向分析，揭示了 SubAgent 在实现层面的关键设计决策。[[raw/2026-05-09/小林coding/面试官皱眉：“你知道 Claude Code 多Agent实现机制吗？” 我：“何止知道？我还看过源码”，他愣了….md|来源: 小林coding CC源码分析]]
三种 SubAgent 形态
- Regular Subagent：标准隔离上下文执行，最通用的形式。
- Fork Subagent：字节级 prompt cache 复用。核心技巧是让子 agent 的 API 请求前缀与父 agent 字节一致，从而命中 Anthropic 的 prompt cache，token 开销降至 10%。system prompt 不会重新生成。
- Coordinator 模式：真正的多 agent 并行协作。采用扁平两层架构——主 agent 退化为纯协调器（不执行实际工作），worker 之间不允许相互派遣（防止递归嵌套），协调器必须亲自整合各 worker 的发现。
上下文隔离：逐字段决策，非一刀切
createSubagentContext() 并非简单地”复制或清空”，而是对每个字段做独立决策：文件读取缓存克隆、全局写入禁用、任务注册保留、深度计数器递增。这是目前最具工业级严谨性的做法。
异步消息队列通信
- 父→子：写入子 agent 的
pendingMessages数组（邮箱），子在循环边界读取。 - 子→父：完成通知格式化为 XML，作为伪造的用户消息注入父 agent 对话流。
- 天然异步、天然并发。
工具权限：三道闸门
- 全局黑名单：防止递归派遣、防止抢夺对话权
- 自定义 agent 附加收紧：可在 agent 定义中进一步裁剪权限
- 异步白名单：默认拒绝，仅明确列出的工具可用
多 Agent 协调拓扑与设计原则
四种协调拓扑
来自 Chilia 的归纳：[[raw/2026-05-09/魔法学院的Chilia/Multi-Agent框架，其实可以很简单~.md|来源: Chilia 多Agent框架]]
- Orchestrator-Worker（星型）：最常见，中央协调器分配任务给 worker。
- Hierarchical（树型）：层层委托，适合复杂任务的逐级分解。
- Mesh（对等网络）：无单一 agent 掌握全局视图，节点间直连通信。
- Swarm（共享黑板）：通过共享空间间接通信，松耦合。
Agent Teams 是 Mesh + Orchestrator 的混合体，目前仍处于实验阶段。协调税（coordination tax）：当 agent 数量超过 4 个时，如果拓扑选择不当，准确率提升会趋于饱和。
核心设计原则：围绕上下文边界设计，而非角色
若飞、Chilia、小林等多位作者独立强调这一点。[[raw/2026-05-08/若飞/Sub-Agent VS Agent Team：多智能体架构和上下文边界.md|来源: 若飞 Sub-Agent vs Agent Team]] 大多数多 agent 失败源于架构师按人类组织架构拆分 agent（规划者→开发者→测试者），导致每次交接都产生信息衰减。正确的问题是：“这些子任务需要共享同一份上下文吗？“
VSCode Multi-Agent 三层架构
鲁工揭示了 VSCode 中的三层 agent 架构：[[raw/2026-05-09/鲁工/VSCode Multi-Agent指南：适合IDE选手的AI开发团队搭建.md|来源: 鲁工 VSCode Multi-Agent]]
- Local 层：实时对话，低延迟交互
- Background 层：git worktree 隔离执行，适合长时任务
- Cloud 层：GitHub 远程 PR 生成
传递机制是单向的（Local→Background 可行，反向不通）。.claude/agents/ 下的 agent 定义可被 VSCode 自动识别。
Anthropic Managed Agents 平台化
Anthropic 已推出云端托管 Managed Agents，采用 meta-harness 设计（Session / Harness / Sandbox 三层解耦）。[[raw/2026-05-07/金色传说大聪明/Anthropic 官方 Harness 发布：全面解读 Managed Agents.md|来源: Anthropic Managed Agents]]
- Notion、Rakuten、Asana、Sentry、Atlassian 等企业已在接入。
- 定价：$0.08/session-hour。
- 这意味着 SubAgent 机制正在从 IDE 内嵌能力向云端平台化方向演进，与 OpenClaw 的”网关+部署”路线形成对照。
OpenClaw 源码级架构深度分析（2026-05 新增）
腾讯程序员基于 3699 行源码提供了目前最详尽的 OpenClaw 实现级分析：
Gateway 微内核与 Channel 25+ Adapter 契约
OpenClaw 的核心拓扑不是传统的”一对多”分发，而是 Gateway 微内核——所有渠道统一接入 Gateway（非直连模型），Channel 接口包含 25+ 方法（init/send/receive/process 等），每种 IM（微信/钉钉/飞书/Telegram 等）实现同一契约。
Auth Profile 凭证管理（全新细节）
- 凭证冷却队列：API 调用失败时触发冷却，而非直接丢弃
- 磁盘持久化：重启后凭证不丢失
- OAuth/token 类型支持
- 探针机制：定时检查凭证有效性
Agent 执行引擎三层架构
System Prompt（分层拼接 → Context Engine 插件 → 注入前）→ Agent 运行循环（Perception→Planning→Action→Feedback in real loop）→ Skill 加载流水线（6 步：发现→资格过滤→路径压缩→截断限制→快照生成→注入）
记忆系统：双层存储 + Dreaming 三阶段
- 双层存储：短期（会话级上下文）+ 长期（跨会话持久化）
- Dreaming 三阶段：Light（快速摘要）→ REM（关联重组）→ Deep（6 信号加权评分 + 3 重门禁，深度记忆沉淀）
- Deep 阶段算法细节：对每个候选记忆分配 6 维信号分（使用频率、时效衰减、任务关联度等），加权总分超过阈值且通过 3 重门禁才晋升持久化
双向连接设计（全新概念）
“OpenClaw 不只是一个被调用的后端”——它既能用 CLI 当自己的 backend（下游模型），也能作为 MCP/ACP/HTTP 暴露给其他 agent 调用（上游暴露）。这种双向角色使 OpenClaw 可嵌入任何 agent 编排图谱中的任意节点。
Lane 分车道并发
按用户/任务维度分车道（Lane）处理并发请求，避免多用户 session 互相污染。车道内顺序执行、车道间并行。
三种 PromptMode（full/minimal/none）
子 Agent 用 minimal 模式节省上下文——只注入必要的 role 定义和核心工具，不加载全局规则。
[[raw/2026-05-29/OpenClaw与Hermes：源码里的 AI Agent 架构知识大复盘.md|来源: OpenClaw源码分析]]
Skill 体系的工业级自进化 Infra（2026-06 新增）
来自尼恩（技术自由圈）的工业级 Skill Infra 设计，为 OpenClaw/Hermes 类平台的技能系统提供了完整的四层自进化架构，将 Skill 从”文件加载”扩展为全生命周期闭环。[[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？ 一个工业级 技能 Infra 底座如何设计？.md|来源: 尼恩 Skill 自进化 Infra]]
四层自进化架构
| 层级 | 核心定位 | 解决了什么问题 |
|---|---|---|
| 轨迹感知层 | 全链路数据采集 | 没有进化原材料：采集交互、工具调用、修正记录、失败案例 |
| 技能蒸馏层 | 从经验提炼能力 | 有数据但提炼不出 Skill：聚类相似轨迹，自动生成初版 Skill |
| 技能进化层（GEPA） | 闭环持续优化 | Skill 写完就死：评估偏差→打补丁→回归验证 |
| 技能治理层 | 全局管控运维 | 系统乱成一锅粥：生命周期、权限、冲突裁决、质量监控 |
轨迹感知层三大设计
- 脏计数器（Dirty Counter）：按有效工具调用次数而非对话轮数触发复盘。复杂部署（15 次工具迭代）与简单对话（2 次工具调用）的经验沉淀价值差 7x，用工具迭代次数比对话轮数精确得多。
- 影子 Agent 舱壁隔离（Bulkhead Pattern）：fork 复盘 Agent 在严格隔离沙盒运行，六个维度——记忆隔离（防止复盘内容泄漏）、递归防护（禁止再产生影子 Agent）、工具白名单（仅开放记忆和技能管理工具）、危险命令自动拒绝（无用户交互渠道直接拦截）、前端输出隔离（仅展示最终结果）、日志隔离（吞掉冗余控制台输出）。
- 缓存继承：影子 Agent 继承父 Agent 系统提示词缓存（固定时间戳+会话 ID 确保字节级匹配），约降低 26% 端到端 API 成本。
GEPA 自进化闭环
Generate-Evaluate-Patch-Audit 四阶段循环：采集完整执行轨迹 → 五维指标量化评估定位根因 → 增量补丁而非全量重写 → 回归用例验证+安全扫描+灰度后上线。由 Curator 后台异步调度，不阻塞主会话。核心哲学：自进化不是自由进化，而是可审计状态机 + LLM 智能建议 + 刚性规则保护。
Skill 注册与加载机制
三层注册校验：① Schema 校验（九要素齐全）→ ② 安全扫描（正则+LLM 双重拦截恶意指令/数据外泄/破坏性命令）→ ③ 冲突检测（相似度 > 0.85 拒绝注册提示合并）。
四层召回机制：任务类型粗筛 → 风险等级过滤（高危显式授权）→ 向量相似度置信度（>0.85 自动加载，0.6-0.85 询问用户，<0.6 不加载）→ Harness 统一管控注入。
三层渐进式加载：L0 目录索引（常驻 ~500 Token）→ L1 摘要（命中后加载 ~300 Token）→ L2 全文（确认使用后加载 ~1000 Token）。200 个 Skill 的系统常驻上下文仅 500 Token。
边车文件模式（Sidecar Pattern）：Skill 内容与使用统计分离存储——Skill 文件专注执行逻辑面向用户可编辑，独立统计文件存储运营数据（使用次数、状态、是否置顶），写入安全由原子替换+跨进程文件锁保证。
四状态双向可逆状态机：active → stale（超 30 天无活动）→ archived（超 90 天归档）/ pinned（用户手动置顶跳过自动变更）。stale 一旦被重新使用即自动复活回 active，解决”低频有用 Skill 被误归档”问题。
六组件概念边界
| 组件 | 核心理念 | 解决问题 | 生命周期 |
|---|---|---|---|
| Tool | 能做（Can do） | 扩展 Agent 执行能力 | 相对稳定 |
| Skill | 会做（Knows how to do） | 跨任务可复用的程序性记忆 | 长期存在，持续迭代 |
| Harness | 不出事（Keeps safe） | 全局运行时治理与护栏 | 系统级稳定 |
| MCP | 远程工具互联 | 跨进程工具发现与标准化调用 | 协议级稳定 |
| Memory | 笔记本 | 事实性知识和经验持久化 | 长期存储 |
| Prompt | 临时便签 | 单次指令或一次性上下文 | 任务结束失效 |
Skill 与 Prompt 的本质区分：Skill 是”程序性记忆”（跨任务可复用、持续进化），沉淀适用边界、分步流程、工具调用范式、入参校验、输出规范、异常兜底、安全约束七条完整规范；Prompt 是”单次指令”（一次性、静态、无进化）。
质量评估体系
五类 24+ 细分指标群覆盖任务达成率、工具调用健康度、输出规范稳定性、人工干预修正率、Token 成本效率，每项含标准化计算公式、优秀阈值、告警阈值、处置策略。例如全局任务成功率 > 90% 优秀、< 70% 触发全量复盘；Token 节省增益率 > 15% 优秀、< 0 判定负收益下线重构。
四级技能迭代优先级链：① 优先迭代当前会话已加载的 Skill → ② 迭代已有伞状 Skill → ③ 新增支撑文件 → ④ 新建品类级伞状 Skill（禁止单次任务碎片化命名）。
矛盾：Matt Pocock 主张用户手动触发 Skill、AI 保持最小自主性，认为全自动流程剥夺控制权难以排查错误 vs 尼恩主张工业级 Skill 系统应四层召回+Harness 统一管控注入，通过置信度分层实现自动化（>0.85 自动加载 <0.6 不加载），追求自进化闭环减少人工干预。前者偏重个体控制力与可排查性，后者偏重规模化效率与持续进化。[[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？ 一个工业级 技能 Infra 底座如何设计？.md|来源: 尼恩 Skill 自进化 Infra]] [[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: Matt Pocock Skill 工作流]]
Agent 集群四种设计模式（2026-05 新增）
看山在自研集群”枢衡”上的实践+Accio 集群升级经验，总结四种模式（按”控制→放手”演进）：
| 模式 | 拓扑 | 特点 | 适合场景 |
|---|---|---|---|
| 路由模式 | 星型网络 | 路由器按能力匹配分发，最基础最易起步 | 明确分工的任务集 |
| 委托模式 | 有向树 | 经理 Agent 递归分解+分发/归约+中断机制 | 执行深度重要的任务 |
| 辩论模式 | 三方架构 | 正方/反方/法官在对抗中暴露盲区 | 高 stakes 决策 |
| 群体模式 | 网状/场状 | 去中心化，通过留痕/动态交接/涌现协作 | 多视角验证/创造性任务 |
辩论模式的关键工程细节：法官的模型必须比正反方强——如果法官能力不够，辩论会越辩越歪。
组合策略：高 stakes 决策时先调度分组，组内群体模式出子结论，调度器再汇总（Accio 双模式设计的启发）。
[[raw/2026-05-26/什么是Agent集群的四种设计模式？一文讲清.md|来源: 集群四模式]] [[raw/2026-05-26/Accio 集群模式升级：这一次，集群终于”各司其职”.md|来源: Accio 集群升级]]
双 Agent 协作架构：Claude Code + Codex 并行（2026-05 新增）
三层分离的实践：.claude/ + .codex/ 各自私有层 + ~/.agents/ 共享契约层（“投影层不做合成”——每个共享文件只有一个写入方）。
Codex 在 review Claude 的设计文档时三次独立发现设计漏洞（Source Drift、幂等假象、deadline 字段歧义），验证了双 Agent 独立审查的价值——两个 Agent 的审查视角完全不同，这才是真正收益。
最终分工模型：Claude 负责深度判断/方案设计/知识沉淀，Codex 负责独立审查/代码实现。
[[raw/2026-05-27/如何用 Codex 强兼 Claude Code 生态（并被它教做人）.md|来源: 双Agent协作]]
Ruflo 联邦编排平台（2026-05 新增）
5 万 GitHub Star 的第三方多 Agent 编排平台（原名 Claude Flow），填补了 OpenClaw/Claude Code 之外的生态位。核心架构：
- Hive-Mind Swarm：Queen + Workers 并行执行
- SPARC 方法论：Spec→Pseudo→Arch→Refine→Complete（94.6% SWE-bench）
- Federation 联邦：跨机器 Agent 协作 + mTLS + Ed25519 + 行为信任评分
- AgentDB：HNSW 向量数据库实现跨会话记忆
- SONA（自优化神经适配层）+ ReasoningBank：成功路径自动捕获复用，任务路由准确率 89%
两个 Web 入口：flo.ruv.io（多模型聊天）和 goal.ruv.io（Goal-Oriented Action Planning）。需要留意：信息来自自媒体，可能有夸大宣传成分。
[[raw/2026-05-27/GitHub 5 万 Star 的「Claude 外挂」强得离谱！.md|来源: Ruflo]]
Agent 异步架构（2026-05 新增）
叶小钗完整的 Agent 异步架构指南填补了 wiki 的系统空白：
- 两套状态机：Agent Run 状态（9 种）+ Job 状态（9 种），精细管理长任务的每个阶段
- 七组件参考架构：API/Session → Planner → Orchestrator → Job Store → Queue/Event Bus → Worker/Tool Runtime → Result/Context Store
- 五种完成通知机制：状态存储（事实） + 事件通知（触发） + 轮询（兜底） + 回调（实时）互补
核心原则：“状态存储负责事实、事件通知负责触发、调度器负责决策、模型和工具负责执行”。[[raw/2026-05-27/Agent 异步架构原理.md|来源: Agent异步架构]]
Agent 集群审计角色与信誉治理（2026-06 新增）
看山Agent架构的枢衡 V2 系统为多 Agent 集群提供了一个完整的审计治理参考。核心洞察：没有制衡机制的多 Agent 集群，可能比单 Agent 更容易陷入集体幻觉——错误信息在跨智能体交换过程中会发生”幻觉级联”。[[raw/2026-06-05/看山Agent架构/集群中的审计角色：多智能体系统的免疫机制、容灭机制与信誉治理.md|来源: 集群审计角色]]
审计角色的双重职能
| 职能 | 运行机制 | 核心目标 |
|---|---|---|
| 免疫系统 | 常态化运行，持续监控 | 降低风险发生概率 |
| 熔断器 | 阈值触发，重大异常自动中断 | 限制风险扩散范围 |
四类实质性测试：来源测试（核查占位引用/虚假引用）、交叉测试（要求第二信源或证伪数据）、逻辑链测试（审查因果关系跳跃和隐含假设）、边界测试（监测角色越权）。
职责隔离的四项红线
审计角色禁止参与生产被审计对象——否则审查不可避免地带有自我保护倾向：
- 禁止生产原始数据（防止”自编自导自审”的数据闭环）
- 禁止替代战略裁决（输出仅限 PASS 或 ISSUE REPORT）
- 禁止参与格式成稿（保持职业怀疑的冷酷性）
- 禁止表演式反对（异议必须基于明确的证据缺陷或逻辑断点）
五维信誉评分 + 动态半衰期
| 维度 | 评估内容 | 权重场景 |
|---|---|---|
| Truth（事实） | 输出的事实准确性、引用可靠性 | 所有涉及数据引用的任务 |
| Logic（逻辑） | 推导过程严密性、因果链完整性 | 战略分析、方案推导 |
| Role（边界） | 是否在职责范围内行动 | 全流程监控 |
| Delivery（交付） | 输出质量、格式规范、时效性 | 最终交付物 |
| Recovery（修复） | 被发现错误后的修正速度和态度 | 错误后的恢复能力 |
动态半衰期：所有溢出分值按周期指数衰减——Agent 必须持续证明自己的价值，而非躺在历史功劳簿上。三段熔断：60-80 分警告区（增加审计频次）→ 40-60 分降级区（移至沙箱仅执行基础任务）→ <40 分隔离区（暂停所有任务分配进入人工审查）。
ContextBucket：OpenClaw 专用记忆/工作区底座
火山引擎为 OpenClaw 提供的 ContextBucket 插件（见 [[Agent 原理、记忆与上下文工程#ContextBucket：Agent 记忆与工作区统一底座]]）实测将记忆回答正确率从 16.45% 提升到 64.14%。适合 OpenClaw 从单机 Demo 走向长期服务、多端协作、多租户运营的场景。
Hermes Agent → Codex Desktop
Nous Research 的 Hermes Agent 发布了桌面端 Hermes Desktop（变身 Codex），保留所有历史 session/channel/model 配置。标志开源 Agent 框架正在向商业产品对齐。[[raw/2026-06-03/DracoVibeCoding/Hermes Agent正式变身Codex，Hermes Desktop发布！.md|来源: Hermes Desktop]]
Hermes Agent 选择：单 Agent + 能力模块路线
Hermes Agent（Codex 的前身）代表了一种与 OpenClaw 根本不同的设计哲学。得物数仓团队的选型决策提供了宝贵的反面视角。[[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: Hermes Agent 得物数仓]] [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes]]
矛盾：OpenClaw is the dominant multi-agent platform for enterprise workflow automation（wiki 将 OpenClaw 定位为领先） vs Hermes was chosen over OpenClaw specifically because OpenClaw lacks persistent memory — “close the window and it forgets” was unacceptable for data warehouse scenarios requiring repeated historical recall。来自 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: Hermes Agent 得物数仓]]
选择依据：决定性因素是持久化记忆——OpenClaw 的记忆是会话级的，对需要反复回溯历史的数据仓库场景不可接受。Hermes 提供三层记忆架构（短期上下文/中期交互记录/长期知识结构）+ Skill 库（可执行技能模板），底层 SQLite+FTS5，外加多平台网关和丰富工具生态。这一选择揭示重要选型原则：Agent 框架的记忆持久化能力在数据密集型场景中可能比编排能力更优先。
刻意不选择多 Agent：Hermes 的设计是单 Agent + 能力模块 + 看板确认点，刻意不采用多 Agent Swarm。原因：多 Agent 协调开销和上下文衰减在数据治理场景中收益不明确，单 Agent + 标准化工具接口更可控。这是对 wiki 多 Agent 热情的重要制衡视角——多 Agent 不是默认选项。
规则资产化：核心工程模式是”决定什么该记住”——临时信息留当前会话、可重复模式沉淀为规则包（标准化/可审计/可回滚）、治理内容进入长期记忆成为运行约束。遇到相似请求时自动收集证据并给出风险提醒。
三道生产闸门：(1) 事实来源门——校验证据可信度；(2) 预演门——系统模拟通过；(3) 责任门——人工确认。任何一道门未通过则阻止生产写入——这是目前 wiki 中最具体的生产级 HITL 实现。
看板确认点：审批流程状态机（录入→设计→预演→审核→交付），每阶段定义明确人工责任。与 AgentTeams 的 L1/L2/L3 权限模型形成对照——都在解决”人类如何有效参与”的问题，但实现路径不同（看板 vs 权限）。
Agent 集群四模式：从控制到放手的演进路径（2026-06 新增）
看山 Agent 架构提出了 Agent 集群四种模式的深度分析——四种模式不是横向并列的按钮，而是一条控制权逐步下放的路径。核心转变：从”控制 Agent”走向”设计环境”。低阶系统要求中心安排每一步，成熟系统要求中心设计规则、状态、边界和反馈，让 Agent 在局部互动中形成更高层次的协作秩序。中心不是消失，而是改变位置——从台前指挥者变成后台环境设计者。 [[raw/2026-06-12/看山Agent架构/从路由到群体：Agent 集群的四种模式，是一条从-控制-到-放手-的演进之路.md|来源: Agent 集群四模式深度]]
四种模式的核心问题与控制权分布
| 模式 | 核心问题 | 中心控制什么 | 中心下放什么 |
|---|---|---|---|
| 路由 | 谁来做 | 入口分配权 | 无 |
| 委托 | 怎么做完 | 目标、边界、验收标准 | 过程控制权 |
| 辩论 | 做得对不对 | 规则、裁决权 | 判断权 |
| 群体 | 答案如何涌现 | 环境、规则、反馈 | 执行顺序、具体答案 |
辩论模式的退化陷阱
Johns Hopkins 与 Vector Institute 研究揭示：辩论在某些条件下不仅不能提升准确性，反而系统性降低性能。异构设置中（1 强 + 2 弱 Agent），CommonSense QA 准确率从 44.4% 降到 39.4%，MMLU 从 33.6% 降到 24.4%。退化由三种机制强化：① 谄媚（Sycophancy）——Agent 倾向同意他人即使与初始判断矛盾；② 社会从众——多数意见影响强 Agent；③ 推理表面化——修辞包装凌驾于实质逻辑。有效辩论需要证据锚点、轮数上限、裁决者和退出机制。
模式栈：不是选一个，而是按层叠加
真实系统是模式栈——路由层（解决效率问题/物理层）→ 委托层（解决深度问题/传输层）→ 辩论层（解决可靠性问题/校验层）→ 群体层（解决涌现问题/应用层），治理层贯穿全栈。一个 L4 长文任务同时使用路由、委托、辩论和治理四种机制——路由确保任务到达正确节点，委托确保节点深入执行，辩论确保产出质量可靠，治理确保整个过程可控。
七道治理护栏
越是把控制权下放给 Agent 和环境，越需要更强的治理护栏：① 角色边界（硬约束非建议）；② 信誉分与能力画像（高分降抽样率但关键事实永不免检）；③ Source Sync 与 SSoT（旧事实比未知更危险——“半记得”状态会自信犯错）；④ 上下文治理（聊天是过程，文件是状态）；⑤ 分段审议（将大任务拆为子层避免沉默失灵）；⑥ 中心恢复能力（SDC 接管关键任务）；⑦ Skill 自进化治理（分级授权+可审计+可回滚）。
核心洞察：真正成熟的集群，不是找到一个最强控制中心，也不是让所有 Agent 完全自由——而是能根据任务自动选择模式，有分工、有反论、有记忆、有信誉、有治理、有修复能力的协作环境。Agent 集群的成长不是配置越来越多，而是环境越来越会自我修复。 [[raw/2026-06-12/看山Agent架构/从路由到群体：Agent 集群的四种模式，是一条从-控制-到-放手-的演进之路.md|来源: 集群成长规律]]
AgentTeams/HiClaw：编排层与运行层分离（2026-06 新增）
AgentTeams（HiClaw）提出了一种根本性的架构分离：它不是另一个 Agent 运行时，而是运行于运行时之上的编排平面。类比云原生领域——Kubernetes 不替代容器运行时（Docker/containerd）而是在其上做编排——AgentTeams 对 Agent 运行时（OpenClaw/CoPaw）做同样的事。 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟]]
矛盾：多 Agent 协调应由共享运行时处理（OpenClaw/CoPaw）— wiki 将 Agent 运行时视为协调层 vs Agent 编排与 Agent 运行时应分离——AgentTeams 是在任意运行时之上的编排平面，类比 Kubernetes 在任意容器运行时之上。来自 [[raw/2026-06-17/承吉/工单闭环从半天到 6 分钟：我们把 AI Agent 编进了组织架构.md|来源: 工单闭环从半天到 6 分钟]]
AI Native 的结构同构
AgentTeams 主张 AI Native = Agent 作为一等公民设计的系统，与 Cloud Native = 容器作为一等公民设计的系统完全同构：
| Cloud Native | AI Native |
|---|---|
| Container（容器） | Agent |
| Pod（调度单元） | Worker |
| Service Mesh（服务通信） | Matrix（即时通讯空间） |
| Ingress（入口网关） | AI Gateway（Higress） |
| kube-controller（控制器） | hiclaw-controller |
| CRD（资源定义） | Team/Worker/Human 资源 |
组织架构即 CRD
核心 CRD 定义：
- Manager：平台运营，仅做平台操作，不进入业务房间
- Team：业务单元，对应一个 Matrix 房间
- Worker：执行单元，实际干活
- Human：真实人类
组织层级映射：TeamAdmin（真实人类老板）→ TeamLeader（编排 Agent）→ Workers（执行 Agent）。团队模板化使得新团队可一键复制标准化 Agent 群组。
Human 作为一等公民
AgentTeams 最独特的贡献是将 Human 作为一等公民嵌入多 Agent 系统：
- Agent 和 Human 共享同一 Matrix 房间——自然实现 HITL，不需要额外渠道
- 三级权限直接映射 Matrix 房间访问权限：L1 Admin / L2 Team / L3 Worker
- Agent 不再需要”假装有人”或”额外接入人工审批通道”
凭证收敛
AI Gateway（Higress）持有所有真实凭证，每个 Worker 获得一个可撤销的 Consumer Token，接口层面通过 per-route allowedConsumers 细粒度控制授权范围。
生产验证
生产环境部署 15 个 Agent，覆盖 4 个 AI Native 场景（产品研发、应急响应、开源治理、商业智能）。告警到闭环时间从半天缩短到 6 分钟——这是 wiki 中目前最强的生产验证数据点。
AI Native 解决的三个问题
- 可复制性（Replicability）：团队模板化，标准化 Agent 群组可一键部署
- 可治理性（Governability）：权限策略驱动，而非约定驱动
- 可演进性（Evolvability）：运行时无关——切换 OpenClaw 到 CoPaw 无需改动编排层
Simon Willison《Agentic Engineering Patterns》：写代码已不值钱（2026-06 新增）
Django 联合创始人、“prompt injection”提出者 Simon Willison 从 2026 年 2 月开始写在线指南《Agentic Engineering Patterns》，每周新增 1-2 章。全书核心目标：如何用好 Claude Code、Codex 这类既能写代码也能执行代码的 coding agent，拿到可靠、可维护的结果。 [[raw/2026-06-12/ChallengeHub/帮大家啃完了 Simon Willison 的《Agentic Engineering Patterns》,全部 15 章精华都在这。.md|来源: Agentic Engineering Patterns 精华]] [[raw/2026-06-12/邵猛/再次强烈推荐「Agentic Engineering Patterns」：写代码免费了，人人都可以开发，工程师该干什么？.md|来源: 邵猛推荐 Agentic Patterns]]
Agent 定义与 Vibe Coding 边界
Simon 给出的 agent 定义极其简洁：在循环中调用工具以达成目标（Agents run tools in a loop to achieve a goal）。coding agent 的关键差异在于工具箱里有能执行代码的工具。Vibe Coding 应保留原始定义——未经审查的、原型质量的 LLM 生成代码，需要这个词恰恰是为了把它和生产级代码区分开。
全书最重要判断：写代码便宜了，写好代码并没有
过去几十年代码一直昂贵，工程习惯建立在”编码时间花在刀刃上”这个约束上。Coding agent 把”往电脑里敲代码”的成本打到地板。但交付好代码依然贵——代码能跑且确认过、解决对的问题、优雅处理错误路径、简洁最小化、有测试保护、文档与系统同步、留出演进空间。Agent 能帮上大忙，但确保产出是”好代码”的责任依然压在驾驶 agent 的那个人身上。
囤积你会做的事：存货就是 agent 的弹药
做软件的一大本事是知道什么可行、什么不可行。最可靠的答案不是”理论可行”而是你亲眼见过它在跑的代码里成立。有了 coding agent，任何有用的技巧只需要被搞明白一次——只要它被记录在某个带可运行示例的地方，你的 agent 以后就能随时调取它。Simon 最喜欢的 prompt 套路：让 agent 把两三个现成的已验证可行的例子组合成新东西。
认知债（Cognitive Debt）
agent 写的代码你自己看不懂了怎么办？Simon 给这个状态起了名字——认知债。还债方式只有一个：重建对代码的理解。两个模式：① Linear walkthroughs——让 agent 用 shell 命令摘录代码（强制用 sed/grep/cat 而非手抄，掐死幻觉）；② Interactive explanations——让 agent 做成动画演示（词云螺旋布局算法做成可暂停调速逐帧步进的页面）。
唯一被点名的反模式：提交没审查的 PR
不要提交你自己都没审查过的 PR。如果你甩出一个几百上千行全是 agent 生成、你自己都没验证过的 PR，你实际上是在把活儿转嫁给别人。“他们自己也会 prompt，要你何用？“第一遍审查是你自己的责任，不能外包给同事。
四条元模式
- 一切围绕验证闭环：Red/green TDD、first run the tests、curl explore、rodney 截图、showboat exec 防作弊——全书一半以上技巧本质是给 agent 装上验证手段
- 上下文是第一稀缺资源：子代理保根上下文、git log 开局喂上下文、
--help输出设计成 agent 说明书、克隆参考仓库到 /tmp - 经验要沉淀成系统资产：LLM 不长记性但你的 harness 可以——TIL 笔记、上千个 PoC 仓库、compound step 复盘、CLAUDE.md
- 人的标准一寸不让：自己没审过的 PR 不准发，带自己名字的文字不让 AI 写，好代码清单一条不减
Loop Engineering 与多 Agent 编排的交集（2026-06 新增）
Loop Engineering 被定位为 Agent 编程的第四次抽象跃迁（Prompt Eng → Context Eng → Harness Eng → Loop Eng），其核心判断是 Harness Engineering 停留在”脚本思维”层面——CLAUDE.md 是静态描述、Rules 是局部约束、Subagents 是固定流程——而 Loop Engineering 把 Agent 工作流变成系统化的、可组合的、自我进化的闭环结构。 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: Loop Engineering 万字长文]]
矛盾：Harness Engineering 是 Agent 编程的最终范式（wiki 将 Harness 定位为第三次跃迁的终点） vs Loop Engineering 是 Harness 之后的第四次跃迁——Harness 是脚本思维，Loop 是系统思维。来自 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: Loop Engineering 万字长文]]
五要素模型与 Loop 解剖
Loop Engineering 的五要素模型（Automations 启动机制、Worktrees 隔离、Skills 知识固化、Connectors 行动能力、Sub-agents 质检）+ 第六要素 Memory，与 OpenClaw/Claude Code 的 Agent 架构高度对应——但核心差异在于 Loop Engineering 将这些要素视为可组合的闭环组件，而非独立功能。六组件解剖（Goal 目标定义、Tools 工具集、Context 上下文管理、Termination 终止逻辑、Error Recovery 错误恢复、Guardrails 护栏）构成了任何 Agent Loop 的通用骨架。
辩论对抗拓扑的失效模式
多 Agent 辩论不但可能不提升准确性，反而系统性降低性能——两个 Agent 互相说服对方接受错误结论（双重确认偏误）。这是对 wiki 现有”辩论模式”讨论的重要补充：辩论有效的前提是裁决者能力足够，且存在证据锚点、轮数上限和退出机制。Loop Engineering 将这一问题归入更一般的规律：所有 Loop 陷阱的根源是 “Loop 在没有人类判断的情况下做了不该做的事”。
资源类护栏 vs 认知类护栏
Loop Engineering 提出了一个实用的工程分类：资源类护栏（文件系统访问/网络/执行权限）应焊死在系统中不可逾越；认知类护栏（判断什么是对的事）应可插拔——这与 AgentTeams 的 L1/L2/L3 权限分级和 Hermes 的三道门本质上是同一问题的不同表达。
四种常见 Loop 模式
Retry Loop、Plan-Execute-Verify、Explore-Narrow、Human-in-the-Loop——这四种模式均可用于多 Agent 协作场景，且各有核心陷阱。三种配套风险：Comprehension Debt（理解债务——Agent 产出超出人类理解能力）、Cognitive Surrender（认知投降——人类放弃判断）、Verification Gap（验证缺口——无法确信系统输出正确）。
Loop 成本公式
实际月成本 = 基础成本 × Thrashing 系数（因 Loop 循环浪费的额外请求）。开源模型 + 自建 Loop 的首月成本优势约 80-90%，但需要投入基建成本。这一分析框架可用于评估多 Agent 编排的投入产出比。
AI 工具采纳的批判性视角（2026-06 新增）
以上所有内容（从 OpenClaw 到 AgentTeams 到 Loop Engineering）隐含一个前提：采纳新 AI 工具会渐进式提升工程效率。以下是一个直接挑战这一前提的批判性视角。 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes 这几个月]]
矛盾：采纳新 AI 工具（Hermes/Claude Code/Codex/OpenClaw）会渐进式提升工程效率（wiki 的 Agent 架构部分隐含此前提） vs 追逐工具适得其反——公司”所有新工具都用了，哪个都没用好”，每个工具在产生产出前就被替换，形成恶性循环。真正的解药是停止追逐工具，聚焦具体业务问题。来自 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes 这几个月]]
矛盾：AI 工作流自动化（Loops/Agents）是提升生产力的路径（wiki 多页庆祝这一方向） vs AI Loops 可能产生相反效果——AI 跑目标导向的 Loop 越来越聪明，人类跑流程导向的 Loop（会议/审批）越来越疲惫。Loop 在改写人类，而不是人类在利用 Loop。来自 [[raw/2026-06-19/AI知识体系礼记/OpenClaw 到 Hermes：这几个月.md|来源: OpenClaw 到 Hermes 这几个月]]
反傻瓜流程悖论
企业合规流程在积极抵消 AI 效率增益——“AI 5 分钟写好的代码，走 7 道审批要 5 天”。AI 的效率增益不取决于模型能力，而取决于组织流程是否允许效率落地。
AI Loop 悖论
AI 运行目标导向的 Loop（goal-oriented loops），越跑越聪明；人类被困在流程导向的 Loop（process-oriented loops）——周会→需求评审→技术评审→测试评审→上线评审→回顾会，越跑越疲惫。Loop 在改写人类，而不是人类在利用 Loop。
平行宇宙
技术团队达到 80% AI 采纳率，业务团队仍为 0%。技术团队为技术团队开发的工具永远不会触及业务方——但实际瓶颈往往在业务侧。
五把手术刀
- 停止订阅 AI 新闻
- 从 OKR 中删除 AI
- 也给业务团队装备 AI 工具
- 审批流程砍半
- 接受你不能追逐每个新工具
核心论点：AI 是工具，不是信仰。让你不被淘汰的是聚焦你的实际问题，而不是追逐工具。
2026-07 更新：OpenClaw 修正视角与 ADE 路线
6 月下旬资料对 OpenClaw 的判断更冷静：它有很强的演示和市场教育价值，但通用数字员工要长期留存，必须面对 GUI 状态、登录态、页面变化、ReAct 成本、权限边界和记忆持久化这些硬问题。能”看起来能操作网页”不等于能成为稳定生产系统。[[raw/2026-06-24/叶小钗/OpenClaw、WorkBuddy、Loop 工程：谁在火，谁有用，谁还在 Demo.md|来源: OpenClaw/WorkBuddy/Loop]] [[raw/2026-06-29/叶小钗/这届 Agent，全是草台班子：到底什么 Agent 在产生价值？.md|来源: 什么 Agent 有价值]]
新的分叉是 ADE/Worktree First：Orca 这类面向 AI Coding 的 ADE 把多代理协同、worktree、SSH/远程运行和 IDE 体验捆在一起，强调给 Agent 一个适合编码的开发环境，而不是让它模拟人类点网页。这条路线与 OpenClaw 的通用 GUI Agent 路线形成对照。[[raw/2026-07-01/爱海贼的无处不在/AI编程实践第15节：Orca 的多代理协同开发，专门为AI Coding 打造的 IDE.md|来源: Orca ADE]]
编排层与运行时继续分离：AgentTeams/WorkBuddy/Orca 的共同启发是，多 Agent 价值不在”让多个模型聊天”，而在任务拆分、权限、共享状态、检查点和结果整合。运行时可以换，编排契约必须稳定。[[raw/2026-06-30/望宸/AgentTeams 和 Claude Tag 都进入群聊模式，是新范式还是新叙事？.md|来源: AgentTeams vs Claude Tag]]
相关页面
- [[wiki/entities/Claude Code]]
- [[wiki/concepts/Agent 原理、记忆与上下文工程]]
- [[wiki/concepts/Superpowers 与编程治理框架]]
- [[wiki/entities/Workspace Agents 与企业工作流]]
- [[wiki/concepts/上下文管理与 Harness Engineering]]