多智能体协作，不是多开几个 Agent：从中介者模式看 OpenClaw 和 Hermes Agent

这次我想把话再往前推一步。多智能体不是 AI 突然发明出来的一种"新组织学"。它更像是软件行业过去二十年已经反复踩过的几类协调问题，在 LLM 时代重新回来了一遍。只不过这次，系统里多了一个会推理、会犯错、会临场改主意的执行单元。所以真正值得看的，从来不是"一个 agent 写代码，另一个 agent 做测试"这种角色分工。而是下面这几个更硬的问题：- 谁负责拆任务- 谁负责分配权限和预算- 谁决定上下文该给到哪一层- 子任务失败以后，系统怎么重试、降级、终止这也是我最近把 OpenClaw 和 Hermes Agent 放在一起看时，最强烈的感觉。截至 2026-04-14，OpenClaw 最新 release 是 2026.4.12，发布时间是 2026-04-13；Hermes Agent 最新 release 是 v0.9.0 / v2026.4.13，发布时间同样是 2026-04-13。它们都还在快速演进，但我越来越确定一件事：**多智能体真正成熟的标志，不是并发数变多，而是它越来越像一个有控制平面、有执行平面、有恢复机制的系统。**如果只想先抓一眼版，我会把它画成这样：mermaidflowchart LR U[用户目标] --> CP[控制平面<br/>CLI / Gateway / Orchestrator] CP --> PL[策略与预算<br/>Policy / Budget / Approval] CP --> EP[执行平面<br/>Agents / Tools / Workers] EP --> OBS[观测与恢复<br/>Logs / Events / Retry] OBS --> CP PL --> EP## 如果你做过业务系统，这一波会很眼熟我第一次认真拆多智能体时，脑子里冒出来的不是"AI 团队协作"。而是以前做业务系统时那些老朋友：- API Gateway- Workflow Engine- Message Bus- Supervisor- Controller Loop说白了，今天很多多智能体框架干的事情，老业务系统早就干过。只是名字不一样。以前我们管它叫流程编排、任务调度、控制回路、失败恢复、补偿事务。现在换到 agent 这边，名字变成了 delegation、subagent、context engine、toolset、sandbox、memory worker。骨架其实没变。真正变的是：**以前执行节点大多是确定性的函数或服务，现在执行节点里混进了一个非确定性的 LLM。**这会带来一个本质变化：> 过去的软件系统，难点在分布式协调。 > 现在的 agent 系统，难点变成了"概率性规划"叠加"确定性治理"。我越来越相信，后面真正能落地的多智能体，不会是"agent 社会"，而会是"概率性规划器 + 确定性控制面 + 受限执行 worker"的组合。## 为什么我坚持说它先是中介者模式中介者模式最值钱的地方，不是抽象漂亮。而是它专门解决一种很现实的问题：**一旦协作对象变多，直接互相调用会把系统拖进耦合泥潭。**先看一个反例。很多人第一次写多 agent，脑子里大概是这个结构：tsclass ResearchAgent { run(task) { const facts = web.search(task); return CodeAgent.run({ type: 'implement', facts }); }}class CodeAgent { run(task) { const patch = writeCode(task.facts); return ReviewAgent.run({ type: 'review', patch }); }}class ReviewAgent { run(task) { if (!task.patch.pass) { return ResearchAgent.run({ type: 'recheck' }); } return task.patch; }}这段伪代码的问题不是"写得不优雅"。而是结构上已经开始失控了。ResearchAgent 知道 CodeAgent，CodeAgent 知道 ReviewAgent，ReviewAgent 又反过来知道 ResearchAgent。角色一多，链路就会从 n 条，膨胀成接近 n² 的通信关系。更麻烦的是，下面这些东西会马上散掉：- 权限判断散在每个 agent 里- 重试策略散在每个 agent 里- 成本统计散在每个 agent 里- 日志和状态树散在每个 agent 里这时候你再加一个 SecurityAgent、MemoryAgent、PlanningAgent，系统很快就会从"多智能体"变成"多处 prompt 相互引用"。直接互聊和中介层编排，结构差别其实一眼就能看出来：mermaidflowchart LR subgraph A[直接互聊] R[Research] C[Code] V[Review] M[Memory] R --> C C --> V V --> R R --> M M --> C V --> M end subgraph B[中介者编排] O[Orchestrator] R2[Research] C2[Coding] V2[Review] M2[Memory] O --> R2 O --> C2 O --> V2 O --> M2 R2 --> O C2 --> O V2 --> O M2 --> O end中介者模式真正解决的是这个。它不让 agent 直接互相耦合，而是统一交给编排层：tstype Task = { id: string; goal: string; context: string; toolset: string[]; budget: { maxTokens: number; maxTimeMs: number }; outputSchema: string; retryPolicy: 'none' | 'once' | 'bounded';};class Orchestrator { run(userGoal: string) { const queue = this.plan(userGoal); while (queue.hasNext()) { const task = queue.next(); if (!this.policy.allow(task)) { this.recordBlocked(task); continue; } const agent = this.selectAgent(task); const result = agent.execute(task); this.observe(task, result); if (result.status === 'needs_followup') { queue.push(...this.replan(task, result)); } } return this.summarize(); }}这里的关键不是 while 循环。而是系统里终于出现了一个单点：- 任务在这里被创建- 上下文在这里被裁剪- 权限在这里被审批- 失败在这里被归因- 结果在这里被回收这就是为什么我会说，CLI、Gateway、Orchestrator 一旦开始调多个 agent，它本质上就是中介者模式。不是像。是已经在干这件事了。## 如果把它放回业务架构演进里，会更容易看明白多智能体不是凭空冒出来的，它站在几波老架构演进的肩膀上。我会把它放进下面这条线里看：| 阶段 | 当时要解决的问题 | 当时成熟的解法 | 放到今天的多智能体里，对应的是什么 || -------------- | ---------------------- | ------------------------------------- | ---------------------------------- || 单体业务时代 | 一个请求内部怎么拆职责 | Controller / Service / Repository | 单 agent + tools || 流程化业务时代 | 跨步骤、长事务怎么走完 | BPM / Workflow Engine | Orchestrator 管任务树 || 分布式业务时代 | 多服务如何解耦和补偿 | API Gateway / MQ / Saga | 多 agent 任务契约、重试、回收 || 云原生时代 | 系统如何持续自愈 | Controller / Operator / Desired State | 持续观察 agent 状态并纠偏 || Agent 时代 | 不确定任务怎么动态拆分 | Planner + Worker + Guardrails | 非确定性规划 + 确定性执行 |这张表不是为了硬套概念。而是为了说明一件事：**多智能体最值得学的，不只是 prompt engineering，而是老系统里那些已经被证明有效的组织方式。**如果把这条演进线压成一张图，会更直观：mermaidflowchart LR A[单体分层<br/>Controller / Service / Repo] B[流程编排<br/>Workflow / BPM] C[分布式协调<br/>Gateway / MQ / Saga] D[云原生控制<br/>Controller / Operator] E[Agent 编排<br/>Planner / Worker / Guardrails] A --> B --> C --> D --> E### 业务系统 1.0：函数调用最早的业务系统很简单。入口来了，请求进 controller，controller 调 service，service 调 repository。整个链条虽然分层，但大体还是一个进程里完成的。这对应今天最常见的 agent 形态，其实就是：tsasync function singleAgentHandle(goal: string) { const plan = await llm.plan(goal); const docs = await web.search(plan.query); const file = await terminal.run(plan.command); return llm.answer({ goal, docs, file });}这种结构不是不能用。如果任务短、上下文集中、风险低，它其实是最划算的。很多团队一上来就拆多 agent，反而是在把简单问题复杂化。### 业务系统 2.0：流程编排当业务开始跨部门、跨系统、跨时间，事情就变了。一个订单不只是"查库存然后扣款"，它可能还要风控、通知、发票、客服、退款。这个时候，单纯函数调用已经不够，需要流程编排。Camunda 这类工作流系统的文档写得非常直白：流程编排是在协调业务流程中所有移动部件，让人、系统、设备一起完成端到端流程。这段历史非常重要。因为今天很多人以为多智能体是在发明"复杂任务拆分"。不是。工作流系统早就在做。真正新的地方，是把其中一部分步骤，从确定性节点，换成了概率性节点。所以我会把两者区别写成这样：ts// 传统工作流：路径大体已知workflow .start('order_fulfillment') .then('risk_check') .then('charge_payment') .then('create_shipment') .then('notify_user');// agent 编排：路径部分未知，需要先规划const plan = planner.decompose('帮我完成订单异常排查');for (const step of plan.steps) { orchestrator.dispatch(step);}你会发现，两边的骨架其实很像。真正不同的是第二段的 planner.decompose()。这里开始引入非确定性，所以后面的编排层必须更强，不然系统就会发散。更有意思的是，老工作流厂商自己也已经往这边走了。Camunda 官方现在甚至直接用了 agentic orchestration 这个词，而且明确把 AI agents 放进 BPMN 工作流里，让 deterministic rule sets、human tasks 和 AI-driven decisions 协作。这等于官方承认了一件事：agent 不是工作流的替代品，而是在吃掉工作流里"原本最难标准化的那一段"。 ### 业务系统 3.0：分布式和补偿再往后，业务进入微服务和消息化时代。你会发现，真正难的已经不是"谁做哪一步"，而是：- 谁来发命令- 谁来确认完成- 谁来处理超时- 谁来记录状态- 出错以后谁来补偿这时候你再看多智能体，味道就更熟了。今天很多 agent 框架的本质，不就是在重新回答这些问题吗？tstype AgentCommand = { taskId: string; assignee: 'research' | 'coding' | 'review'; payload: string; timeoutMs: number; retry: number; onFailure: 'replan' | 'abort' | 'fallback';};function dispatch(cmd: AgentCommand) { log.append(cmd); queue.publish(cmd.assignee, cmd);}function onResult(result) { stateStore.update(result.taskId, result.status); if (result.status === 'failed') { compensateOrReplan(result); }}这已经不是什么"灵感型协作"了。这就是命令、状态、回执、补偿。## OpenClaw 和 Hermes，分别把中介者模式做成了两种产品如果只看 marketing 词汇，OpenClaw 和 Hermes Agent 都是多智能体。但如果从模式上看，它们其实在实现两种不同的"中介层"。### OpenClaw：网关型中介者OpenClaw 官方多智能体文档给了一个非常强的信号：它的目标是让一个运行中的 Gateway 承载多个隔离 agent、多个渠道账号，再通过 bindings 把入站消息路由到对应 agent。这句话背后有三层意思：第一，它把"入口路由"放在系统中心。第二，它把"agent 身份隔离"做成了一等公民。官方文档明确写了每个 agent 都有独立的 workspace、agentDir 和 session store。第三，它的路由不是模糊的，而是确定性的。文档直接写了 bindings 的匹配优先级，而且同层冲突时"配置顺序里先出现的生效"。把这套东西翻成伪代码，大概就是：tsfunction routeInboundMessage(msg: InboundMessage) { const binding = bindings .sort(bySpecificity) .find((rule) => rule.matches(msg)); const agentId = binding?.agentId ?? defaultAgentId; const agent = agentRegistry.get(agentId); return agent.handle(msg);}注意这个结构里的重点。不是 agent.handle(msg)。而是前面的 sort(bySpecificity)、find(rule.matches)、defaultAgentId。这说明 OpenClaw 的核心价值，在于先把"谁该接这个请求"这件事做稳。这跟很多传统业务系统里 API Gateway + routing rules 的角色非常像。然后再看它的 sessions_spawn。官方文档明确说它会创建一个隔离的后台子 session，而且"always non-blocking"，会立刻返回 runId 和 childSessionKey。这说明它的子 agent 更像控制平面里被调度的后台作业，而不是一群自由聊天的数字员工。甚至连记忆，OpenClaw 2026.4.12 也开始做成 agent 了。Active Memory plugin 的官方描述，本质上就是"在主回复前，先跑一个 memory sub-agent"。这是一个特别值得注意的信号。因为它意味着，未来很多今天看起来像"函数调用"的能力，都会慢慢演进成"可独立调度、可替换、可观察的 agent worker"。### Hermes Agent：监督者型中介者Hermes Agent 的中心则完全不一样。它最值得看的不是多账号路由，而是 delegate_task。官方文档写得很硬：子 agent 由 delegate_task 拉起，拿到 isolated context、restricted toolsets、own terminal sessions，而且只有最终 summary 会进入父上下文。这四个点特别关键。它们说明 Hermes 在做的，不是"把多个 agent 接在一起"。而是"把一个主控 agent 变成监督者，然后谨慎地往外委派"。如果把这个设计翻成伪代码，会像这样：tsfunction delegateTask(goal: string, context: string, toolsets: string[]) { const child = spawnChildAgent({ freshConversation: true, context, toolsets, canDelegateAgain: false, }); const summary = child.run(goal); return summarizeForParent(summary);}这里最厉害的一点其实不是 spawnChildAgent()。而是 freshConversation: true。官方文档甚至专门强调，子 agent 对父历史"zero knowledge"，只能看到 goal 和 context 里显式喂进去的内容。很多人第一次看到会觉得太苛刻，但我觉得这反而是成熟的信号。因为这说明 Hermes 已经意识到一件事：> 多智能体系统真正稀缺的，不是共享上下文。 > 是可控的上下文。再往深一点看，它的 toolsets 也是同样思路。不同子 agent 拿不同工具集，某些能力对子 agent 永远禁用。这其实就是把"最小权限原则"前置进了编排层。如果我用一个更老派的概念来形容，Hermes 像的不是消息总线。它更像 Erlang/OTP 里的 supervisor tree。Erlang 官方文档对 supervisor 的描述非常直白：supervisor 负责启动、停止、监控子进程，并在必要时重启，而且还要限制某段时间内的最大重启强度，避免系统无限重启自爆。把这段原则翻成 agent 世界，其实就是：tsclass Supervisor { runTaskTree(rootTask: Task) { const child = this.startChild(rootTask); const result = child.execute(); if (result.status === 'failed' && this.restartBudget.allows(rootTask.id)) { return this.restart(rootTask); } if (this.restartBudget.exhausted(rootTask.id)) { return this.abortSubtree(rootTask.id); } return result; }}这段伪代码背后的观点很明确：多智能体不是让系统更自由，而是让系统更需要监督。 ### 两者真正的差别，不在"有没有多个 agent"我会把它们的差别压缩成一句话：- OpenClaw 更像"谁来接、从哪接、隔离在哪"的中介者- Hermes 更像"谁来拆、派给谁、出了事谁兜底"的中介者放到架构上看，就是这样：| 维度 | OpenClaw | Hermes Agent || -------------- | --------------------------------------- | -------------------------------------------- || 中介层核心职责 | 入口路由、身份隔离、会话隔离 | 任务拆解、子 agent 委派、结果回收 || 更像什么老架构 | Gateway / Channel Router | Supervisor / Task Orchestrator || 关键边界 | workspace、agentDir、bindings、sessions | context、toolsets、terminal session、summary || 最像的历史经验 | API 网关、多租户隔离、控制平面 | 工作流引擎、监督树、受限 worker pool |这也是为什么 Hermes 的 OpenClaw 迁移文档会直接把 multi-agent list 和 bindings 划进"没有直接 Hermes 等价物"的部分，建议改用 profiles 和手工平台配置去重建。这不是缺功能。这是产品哲学不一样。如果用一张图对照，两条路线会更清楚：mermaidflowchart LR subgraph OC[OpenClaw：网关型中介者] CH[Channels / Accounts] GW[Gateway + Bindings] OA[Agent A<br/>workspace / sessions] OB[Agent B<br/>workspace / sessions] ST[Session Tools / Spawn] CH --> GW GW --> OA GW --> OB GW --> ST end subgraph HE[Hermes：监督者型中介者] PA[Parent AIAgent] PG[Policy / Toolsets] CA[Child Agent A<br/>fresh context] CB[Child Agent B<br/>fresh context] SM[Summary / Result] PA --> PG PG --> CA PG --> CB CA --> SM CB --> SM SM --> PA end## 设计模式不止中介者，但中介者是总入口如果只讲中介者模式，还不够把今天的多智能体看透。我会把它拆成五层。### 1. 中介者模式：解决 N² 协作爆炸所有 agent 都通过中介层互动，避免直接互相知道对方。tsorchestrator.send('research', task);orchestrator.send('coding', task);orchestrator.send('review', task);一旦系统是这样写的，你才能集中做：- policy- audit- budget- cancellation### 2. 命令模式：把任务变成可排队、可重放的对象多智能体里真正的最小单位不是消息，而是任务命令。tstype AgentTaskCommand = { goal: string; contextRef: string; toolset: string[]; model: string; retryPolicy: 'never' | 'once' | 'bounded';};只要任务被对象化，系统才谈得上：- 入队- 并行- 暂停- 取消- 幂等### 3. 策略模式：不同 agent 不是同一把锤子多智能体真正有价值的前提，是不同任务能套不同策略。tsfunction selectExecutionStrategy(task: Task) { if (task.kind === 'search') return { model: 'cheap-fast', toolset: ['web'] }; if (task.kind === 'patch') return { model: 'strong-code', toolset: ['terminal', 'file'] }; return { model: 'default', toolset: ['memory'] };}如果每个 agent 都拿一样的模型、一样的工具、一样的权限，那很多时候你只是把一个 agent 切成了三段。### 4. 观察者模式：没有事件流，就没有多智能体运营当系统开始有后台任务、子任务树、异步完成、进度通知，观察者模式就会自动出现。tseventBus.emit('task.started', taskId);eventBus.emit('task.completed', taskId);eventBus.emit('task.failed', taskId);dashboard.subscribe(taskId, renderStatus);很多团队以为"让 agent 会调用工具"就够了。不够。没有事件流，你连问题发生在哪一步都看不清。### 5. 状态机和控制回路：AI 不是只会聊天，它还得被纠偏这一点我觉得经常被低估。Kubernetes 官方文档把 controller 定义成一种 non-terminating loop，会持续观察 current state，让系统接近 desired state。这个思路放到多智能体上，非常贴切。因为真正线上可用的 agent 系统，最后都不会是"一次回答结束"。它更像这样：tswhile (!goalSatisfied()) { const desired = planner.currentPlan(); const actual = runtime.inspect(); const diff = compare(desired, actual); for (const action of diff.actions) { orchestrator.dispatch(action); }}这其实已经不是聊天产品的脑回路了。这是控制回路。也就是说，多智能体往后走，越来越像控制系统，不只是对话系统。这条回路如果画出来，就是下面这个形状：mermaidflowchart LR G[Goal] --> P[Planner] P --> PG[Policy Gate] PG --> R[Runtime / Workers] R --> S[State Store / Events] S --> C[Compare Desired vs Actual] C --> D{Goal satisfied?} D -- No --> RP[Replan / Retry / Abort] RP --> P D -- Yes --> O[Final Output]## 真正的新东西，不是模式本身，而是"非确定性节点"进来了到这里我反而想强调一句：今天多智能体最"新"的地方，不是中介者、命令、策略、监督、控制回路这些模式。这些都不新。真正新的，是系统里开始大规模出现一种节点：- 输入不完整- 路径不固定- 输出不是严格可预测- 但它又必须被放进生产流程这就是 LLM agent。所以我现在最认同的一种架构表达，其实不是"AI 员工团队"。而是这句话：> 把不确定性交给 agent。 > 把确定性约束留给系统。用伪代码写，就是：tsconst plan = planner.propose(goal); // 允许不确定const approvedPlan = policyGate.validate(plan); // 必须确定for (const step of approvedPlan.steps) { runtime.execute(step); // 必须可观测、可取消、可追责}这也是为什么我会觉得，未来真正厉害的多智能体框架，不会只拼模型能力。它们拼的是：怎么把概率性决策，装进一个确定性外壳里。 ## 我对未来的几个判断下面这些是我的推断，不是官方 roadmap。但它们都能从现有框架和老架构经验里找到依据。### 1. 工作流引擎和多智能体会合流这件事其实已经开始了。Camunda 已经在官方文档里明说 agentic orchestration，要把 AI agents 放进 BPMN 流程里。Temporal 也一直在强调 durable execution，服务的是 order fulfillment、customer onboarding、payment processing 这种需要"绝不能凭空消失"的长事务。我对未来的判断很直接：**稳定步骤继续交给 workflow engine，不稳定步骤交给 agent。**也就是说，很多系统最后会长成：tsworkflow.step('collect_case_data');workflow.step('call_analysis_agent');workflow.step('human_approval');workflow.step('execute_fix');workflow.step('notify_customer');不是 agent 替代 workflow。而是 agent 成为 workflow 里的一个新节点类型。### 2. Context Engineering 会升级成基础设施Hermes 把 context engine 做成可插拔，delegate_task 又强调 fresh context；OpenClaw 则开始把记忆召回单独 agent 化。这两条线最后都会指向同一个结论：上下文不会再只是 prompt 的一部分。它会变成基础设施。以后真正值钱的，不是"谁家 prompt 写得更长"，而是：- 如何切 context- 如何压缩 context- 如何给不同 worker 不同粒度的 context- 如何让 summary 回传时不失真### 3. 多智能体的 moat 会越来越像"控制平面能力"我觉得以后真正能形成护城河的，不会是"我支持 8 个 agent 并发"。而是下面这些：- 任务树可视化- 子任务预算和配额- 权限审批链- 中断和取消传播- 失败恢复和重试上限- 审计日志换句话说，未来最值钱的不是 agent count。而是 control plane quality。### 4. 最先被淘汰的，会是角色扮演式多 agent什么 CEO agent、CTO agent、产品经理 agent，这类写法短期会一直有流量。但我越来越不看好它们长期能打。原因很简单：角色名不是系统边界。真正能留下来的，会是这种拆法：- research worker- browse worker- memory worker- coding worker- verification worker- approval gate为什么？因为它们对应的是能力边界、权限边界和失败边界，而不是人设边界。## 真正落地时，我会怎么选型写到这里，其实最容易被问到的不是"你说得对不对"。而是：**那到底什么时候该用单 agent，什么时候该上 workflow，什么时候才值得拆成多智能体？**我现在的判断已经很固定了。### 先看任务形状，不要先看模型能力很多团队一讨论架构，第一反应是"哪个模型更强""能不能支持 tool calling""能不能并行"。这些当然重要。但它们都排在后面。我会先看任务形状：| 任务形状 | 更合适的架构 | 为什么 || ---------------------------------------- | ----------------------------- | -------------------------------------- || 链路很短，目标清晰，强依赖完整上下文 | 单 agent + tools | 少一次拆分，就少一次上下文损耗 || 步骤相对固定，但中间有一两段非结构化判断 | Workflow + agent 节点 | 稳定骨架交给流程，不确定节点交给 agent || 子任务可并行、能力边界清晰、工具差异明显 | Supervisor + worker pool | 可以按能力、权限、预算拆分 || 多入口、多账号、多 persona、长期在线运行 | Gateway + multi-agent routing | 入口管理和隔离比任务拆解更重要 |如果我把这个判断写成伪代码，大概会是这样：tsfunction chooseArchitecture(task: { stepsArePredictable: boolean; needsLongRunningState: boolean; needsHumanApproval: boolean; hasParallelSubgoals: boolean; requiresDifferentToolsets: boolean; hasMultipleChannelsOrPersonas: boolean;}) { if (task.hasMultipleChannelsOrPersonas) { return 'gateway-multi-agent'; } if ( task.stepsArePredictable && (task.needsLongRunningState || task.needsHumanApproval) ) { return 'workflow-plus-agent-node'; } if (task.hasParallelSubgoals && task.requiresDifferentToolsets) { return 'supervisor-worker-pool'; } return 'single-agent-with-tools';}注意这段逻辑里的优先级。第一优先级不是"能不能多 agent"。而是：- 有没有稳定骨架- 有没有长期状态- 有没有人审- 有没有明确可分的子目标- 有没有多入口和多身份只有这些问题先答清，后面的架构选型才有意义。### 一条很实用的经验：先定边界，再定 agent 数量这点我越来越确信。因为很多系统表面上像在讨论"要不要 3 个 agent 还是 5 个 agent"，本质上讨论的其实应该是：- 哪一段是确定性的- 哪一段是概率性的- 哪一段必须可审计- 哪一段允许失败重试- 哪一段必须人来拍板如果这些边界没定下来，agent 数量讨论就是伪问题。我现在很少会问"需要几个 agent"。我更常问的是：tstype BoundaryDesign = { deterministicSteps: string[]; nondeterministicSteps: string[]; approvalGates: string[]; rollbackPoints: string[]; observableStates: string[];};你把这个对象先答出来，很多架构决策会自动浮出来。## 一个我更看好的落地骨架：Workflow 包住 Agent如果是要做真正线上可用的系统，我现在最看好的，不是"全靠多智能体自己跑完"。我更看好的是：**Workflow 负责骨架，Agent 负责局部不确定性。**这不是我自己拍脑袋想出来的。Camunda 官方在 agentic orchestration 的设计文档里，已经把这个思路写得很清楚了：要把 deterministic orchestration 和 dynamic orchestration 混合起来；同时还专门给了 guardrail sandwich 和 human-in-the-loop escalation 这类建议。Temporal 的官方文档则一直强调 durable execution，核心意思也很像：长流程不能"做着做着就消失"，状态和恢复必须由系统兜住。这两条线合起来，我的结论就是：> 不要让 agent 承担全部流程。 > 让 agent 承担流程里最不稳定、最难规则化、但又最值得自动化的那一段。落到结构上，我更愿意把它画成这样：mermaidflowchart TD A[Start / 收集输入] --> B[Deterministic Workflow] B --> C{是否存在非结构化判断?} C -- No --> D[按规则执行] C -- Yes --> E[调用 Planner / Specialist Agent] E --> F[Policy Gate / Approval] F --> G{高风险或低置信度?} G -- Yes --> H[Human Review] G -- No --> I[Deterministic Execution] H --> I I --> J[Verification Agent / Checks] J --> K[End / 审计日志]这张图里最关键的不是中间那个 agent。而是它两边的壳。- 前面有 deterministic workflow- 中间有 policy gate- 后面有 verification 和 auditagent 被放在中间，是因为它适合处理非结构化问题。agent 没有被放到最外层，是因为最外层必须可恢复、可审计、可中断。### 这套骨架为什么更稳因为它等于把"创造性"和"治理性"拆开了。用伪代码写，会更清楚：tsasync function runCase(caseInput: CaseInput) { const workflowState = await workflow.start(caseInput); if (workflowState.requiresOnlyDeterministicSteps) { return deterministicEngine.execute(workflowState); } const plan = await plannerAgent.propose({ goal: workflowState.goal, context: workflowState.relevantContext, }); const approved = await policyGate.validate(plan); if (!approved.ok) { return humanReviewQueue.enqueue({ caseId: workflowState.id, reason: approved.reason, }); } const result = await workerRuntime.execute(approved.plan); const verification = await verificationAgent.check(result); if (!verification.pass) { return workflow.routeTo('manual_escalation'); } return workflow.complete(result);}这段代码想表达的就一句话：**LLM 可以提议。系统必须裁决。**如果没有 policyGate.validate()、verificationAgent.check()、workflow.complete() 这几层，多智能体系统很容易"看起来很聪明，出了事却没人兜底"。### 真正该让 Agent 做的，通常是这几类事如果把实践里最适合 agent 的部分压缩一下，我会列这几类：- 分类、分诊、研判- 在多个工具之间动态选路- 在不完整信息下生成候选方案- 对非结构化文本、文档、对话做提炼- 在有限边界里做局部修复或局部调查相反，下面这些我会尽量往 deterministic workflow 里放：- 审批链- 权限校验- 扣费和预算控制- 审计记录- 超时、重试和失败恢复- 对外副作用执行，比如发货、打款、删库、发正式通知原因很简单。前一类问题，本来就带不确定性。后一类问题，一旦出错，代价太高，不能只靠"模型大概会做对"。## 一个更实操的判断式：别问"能不能上"，问"哪一段值得上"我现在在团队里更愿意推动的，不是整套系统一口气 agent 化。而是先做这种切法：tsfunction shouldAgentify(step: Step) { return ( step.inputIsUnstructured && step.outputCanBeReviewed && step.failureIsRecoverable && step.valueFromAdaptationIsHigh );}只有同时满足这四个条件，我才会比较放心地把某一步交给 agent：- 输入是非结构化的- 输出是可复核的- 失败是可恢复的- 适应性带来的收益很高少一个条件，我都会更谨慎。## FAQ：几个最容易吵起来的问题### 为什么不直接上一个更强的单 Agent能用单 agent 解决的事，我其实非常愿意先用单 agent。因为它更便宜，也更容易调。问题在于，一旦任务同时满足下面几件事，单 agent 的优势就会迅速下降：- 上下文太大，必须切片- 工具权限差异很大- 子任务能并行- 失败以后要精确归因- 有些环节必须审批，有些环节只要建议这时候真正缺的就不是"更强的脑子"。而是"更好的组织方式"。### Workflow 和 Multi-Agent 是替代关系吗我越来越不这么看。更准确地说：- workflow 负责流程边界、状态持久化、超时重试、人审和审计- agent 负责在边界内处理非结构化判断、工具选路和候选方案生成所以更稳的答案通常不是二选一。而是：workflow 打底，agent 填空。 ### OpenClaw 和 Hermes Agent 应该怎么选如果你最关心的是：- 多入口- 多账号- 多 persona- 长期在线- 路由和隔离那我会更偏向先看 OpenClaw 这条路。如果你最关心的是：- 复杂任务拆分- 子任务委派- 不同工具集 worker- 上下文裁剪- 受监督的执行树那我会更偏向先看 Hermes Agent 这条路。当然，这不是最终结论。更像是你该先从哪种问题出发。### 多智能体最容易做错的地方是什么不是模型不够聪明。而是把"多角色提示词"误当成"多智能体架构"。真正的多智能体，至少得有：- 任务契约- 权限边界- 上下文边界- 结果回收- 失败恢复- 观测与审计没有这些，很多所谓的 multi-agent，其实只是多个 prompt 在同一个上下文里轮流说话。## 什么时候不该上多智能体越写到后面，我越想补这一段。因为不是所有问题都值得拆 agent。如果任务天然是短链路，而且强依赖一份完整上下文，那单 agent 往往更省。如果系统还没有：- 日志- 状态树- 成本统计- 失败分类那也先别急着拆。因为你连"到底是哪一层在浪费钱"都看不到，拆完只会让问题更难查。还有一种特别常见的误区，是把"多角色 prompt"误当成"多智能体架构"。前者只是换几套人设说话，后者要求你真的有：- 任务契约- 权限边界- 结果回收- 失败处理没有这些，就别急着说自己做的是 multi-agent。## 写在最后我现在越来越觉得，多智能体最值得看的地方，不是它像不像一个团队。而是它终于开始像一个系统。OpenClaw 和 Hermes Agent 放在一起特别有意思。前者像网关型中介者，优先解决入口路由、身份隔离和长期运行的控制面问题；后者像监督者型中介者，优先解决任务拆分、子 agent 隔离和结果回收问题。两条路都对。只是它们分别从不同的老架构传统里长出来。所以如果你现在在做自己的多智能体系统，我觉得最值得问自己的不是："我还要不要再加两个 agent？"而是：**我到底是在堆角色，还是在设计协作结构？**真正的分水岭就在这。## 参考资料- OpenClaw 多智能体路由文档- OpenClaw Session Tools 文档- OpenClaw Gateway Architecture 文档- OpenClaw 2026.4.12 Release Notes- Hermes Agent Subagent Delegation 文档- Hermes Agent Architecture 文档- Hermes Agent Profile Commands 文档- Hermes Agent Migrate from OpenClaw 文档- Hermes Agent v0.9.0 / v2026.4.13 Release Notes- Camunda Agentic Orchestration 文档- Camunda Agentic Orchestration Glossary- Camunda Agentic Orchestration Design and Architecture- Camunda Processes / Process Orchestration 文档- Temporal 官方文档首页- Kubernetes Controllers 文档- Kubernetes Operator Pattern 文档- Erlang Supervisor Behaviour 文档