多Agent系统规模化实战：Hermes与LobeHub架构复盘

原文首次发表于 tamiz.pro。

2025 年，AI 智能体领域发生了剧烈转变。从最初的单智能体聊天界面，爆发式地演变为多智能体生态系统——数十甚至数百个专业化智能体在其中协调、辩论并执行复杂工作流。Hermes 和 LobeHub 作为两种截然不同的解决方案浮出水面——既非玩具演示，也非企业级套件——它们的架构决策揭示了构建超越少数并发智能体规模系统的真正关键。

这不是一篇智能体框架综述。这是一篇工程复盘，讨论的是当你不再将智能体视为孤立的 LLM 调用，而是将其视为网络化服务时，所面临的硬问题。

核心问题：为何多智能体扩展比看起来更难

单个智能体调用 LLM 是一个已被充分理解的模式。你发送一个提示词，得到一个响应，处理延迟和 token 预算。思维模型很简单，因为拓扑结构trivial：一次请求、一个智能体、一次模型调用。

多智能体系统引入了三个叠加的困难：

通信复杂性：智能体之间需要交换消息、共享状态、协调行动。这是一个披着对话外衣的分布式系统问题。

编排开销：决定哪个智能体在何时、以何种顺序、在什么条件下运行，在本就充满不确定性的 LLM 层之上又增加了一个控制平面。

成本与延迟倍增：每一次智能体间消息传递都可能触发一次 LLM 调用。一个 3 智能体轮询、每轮 5 条消息的交互，可以轻易地为单个用户请求产生 15+ 次模型调用。

天真的做法——并行启动所有智能体、让它们通过共享消息总线交流、聚合结果——在你尝试大规模运行时就会失效。随后你会遇到资源竞争、无界扇出以及在智能体间信任边界流动的提示词注入攻击。

Hermes 和 LobeHub 以不同方式解决了这个问题。理解这两种方法是将设计空间内化的最佳途径。

架构实践：Hermes 模式

Hermes 将多智能体协调视为带有类型化交互协议的消息传递系统。其关键洞察是，大多数智能体间的通信遵循可预测的模式——子任务委托、结果综合、冲突解决——这些模式应该是显式的，而非涌现的。

┌─────────────────────────────────────────────────┐
│                   User Request                   │
└──────────────────────┬──────────────────────────┘
                       ▼
              ┌────────────────┐
              │   Orchestrator  │ ← Static routing table + dynamic load balancing
              └────────┬───────┘
                       ▼
        ┌──────────────────────────────┐
        │       Message Router         │ ← Typed message queues per agent group
        └────────┬─────────────┬───────┘
                 ▼             ▼
      ┌────────────────┐ ┌────────────────┐
      │   Worker Pool   │ │   Specialist    │
      │   (parallel)   │ │   (sequential) │
      └────────┬───────┘ └────────┬───────┘
               ▼                   ▼
      ┌────────────────────────────────────┐
      │         Result Aggregator           │ ← Deterministic merge + LLM reconciliation
      └────────────────────────────────────┘

Hermes 将智能体分为两层：

Worker 智能体：无状态、并行，专注于狭窄的子任务（检索、代码执行、验证）。这些是苦力。

Specialist 智能体：有状态、顺序，负责依赖于先前结果的推理密集型步骤。

关键的设计选择是，workers 之间从不直接对话。所有智能体间通信都通过编排器流动，编排器强制执行一个有向无环通信图。这防止了智能体间消息传递的组合爆炸，并使执行计划可审计。

类型化协议层

Hermes 为智能体消息引入了一个最小化 schema：

// Core message types in Hermes
interface AgentMessage {
  id: string;
  type: 'delegation' | 'result' | 'conflict' | 'escalation';
  sender: AgentId;
  recipient: AgentId | 'orchestrator';
  payload: AgentPayload;
  contextRef?: string;  // Reference to shared context blob
  ttl: number;          // Time-to-live in seconds
}

interface AgentPayload {
  task?: string;
  result?: AgentResult;
  error?: AgentError;
  vote?: { agentId: AgentId; confidence: number; reasoning: string };
}

interface AgentResult {
  output: string;
  tools_used: string[];
  tokens_consumed: number;
  confidence: number;
  citations?: SourceReference[];
}

这看起来可能像是比自由形式的智能体对话多余的样板代码，但这就是可监控可调试系统与黑箱推理追踪（你只能从文本中解析）之间的区别。当凌晨 3 点智能体调用失败时，你需要的是结构化的错误传播，而不是需要从散文描述中解析的黑箱推理追踪。

Hermes 如何管理成本

成本模型是 Hermes 真正有趣的地方。它没有让智能体自由消耗 token，而是实现了一个预算感知的路由层：

class BudgetAwareRouter:
    def __init__(self, agent_registry, cost_tracker):
        self.agents = agent_registry
        self.cost = cost_tracker
        self.default_budget_per_request = 5000  # tokens
        self.max_concurrent_agents = 8

async def route(self, user_request, context):
        plan = self._decompose_task(user_request)
        cost_estimate = self._estimate_cost(plan)

if cost_estimate > self.default_budget_per_request:
            # Trigger agent compression: merge low-value agents
            plan = self._compress(plan)

return await self._execute_plan(plan)

路由器通过分析任务分解来预估 token 成本，然后再执行。如果计划超出预算，它会压缩智能体图——合并冗余的 specialists 或为低优先级步骤回退到更便宜的模型。这不是硬限制；它是一种启发式优化，防止复杂请求的成本失控。

架构实践：LobeHub 模式

LobeHub 采用了截然不同的方法。它没有强制执行严格的自上而下编排，而是将智能体协调视为具有 gossip 式共识的点对点网格。

     ┌─────────┐
     │ Agent A  │◄──────────────────────────────────┐
     └────┬────┘                                    │
          │ gossip                                   │ shared state
     ┌────▼────┐                              ┌─────────────┐
     │ Agent B  │◄─────────────────────────────│  State Bus   │
     └────┬────┘                              └──────┬──────┘
          │                                           │
     ┌────▼────┐                                      │
     │ Agent C  │◄─────────────────────────────────────┘
     └─────────┘

All agents read/write to a shared state bus.
     Consensus emerges through voting rounds.

LobeHub 的设计哲学是，复杂问题受益于多样化的并发推理，而非顺序分解。多个智能体独立地处理同一个问题，然后通过投票机制达成共识。

共识协议

interface ConsensusRound {
  roundId: string;
  question: string;
  participants: AgentId[];
  deadline: number;       // Unix timestamp
  quorumSize: number;
  strategy: 'majority' | 'weighted' | 'unanimous';
  votes: Vote[];
  result?: ConsensusResult;
}

interface Vote {
  agentId: AgentId;
  position: string;
  confidence: number;
  reasoning: string;
  timestamp: number;
}

interface ConsensusResult {
  agreedPosition: string;
  confidence: number;
  dissentingViews: DissentingView[];
  roundId: string;
  converged: boolean;
}

共识机制是 LobeHub 的核心。当智能体出现分歧——它们会的，因为 LLM 是非确定性的——系统不会默认采用简单多数。它运行加权投票，在类似任务上有更高历史准确率的智能体获得更大影响力。

class WeightedConsensusEngine:
    def __init__(self, agent_reputation_store):
        self.reputation = agent_reputation_store
        self.confidence_threshold = 0.75
        self.max_rounds = 3

async def reach_consensus(self, round: ConsensusRound) -> ConsensusResult:
        votes = await self.collect_votes(round)

if not self._has_quorum(votes, round.quorumSize):
            return await self.expand_participants(round)

weighted = self._apply_weights(votes)
        agreed = self._find_agreement(weighted)

if agreed.confidence < self.confidence_threshold and round.round_num < self.max_rounds:
            # Trigger a refinement round with targeted follow-up questions
            return await self.run_refinement_round(round, agreed)

return agreed

这本质上是一种分布式推理协议——借鉴了 Raft 和 Paxos 等共识算法，但针对概率性、非确定性的参与者进行了适配。精炼轮次的设计尤为巧妙：系统不再只是重新投票，而是识别出具体的分歧点，并要求各 AI 智能体直接针对这些分歧进行回应。

LobeHub 的优势与劣势

优势

• 涌现行为：复杂的解决方案从简单的局部交互中自然涌现
• 容错性：编排层不存在单点故障
• 创造力：发散性的思考路径产生新颖的解决方案

劣势

• 延迟更高：多轮推理累积起来延迟较高
• 成本：AI 智能体越多、投票越多、消耗的 token 越多
• 可调试性：更难追溯某个特定输出是如何产生的
• 收敛保证：非确定性输入意味着收敛是概率性的

2025 年格局：发生了什么变化

2024 至 2025 年间的三个转变，使多智能体系统在生产规模上变得可行：

1. 结构化输出可靠性大幅提升

早期的 AI 智能体框架在可靠解析 LLM 输出方面困难重重。函数调用不一致、JSON 提取静默失败、错误处理也是事后才想到的。到 2025 年，主流提供商（OpenAI、Anthropic、Google）已经将结构化输出 API 成熟到确定性解析变得可行的程度。这是多智能体系统最重要的基础设施发展——如果你无法可靠地解析 AI 智能体的响应，就无法围绕它构建协议。

2. 上下文窗口扩大

200K+ 的上下文窗口意味着 AI 智能体可以在不频繁往返的情况下共享大量状态。Hermes 利用这一点采用了共享上下文 blob 模式：不再向每个 AI 智能体重新解释问题，而是传递一种压缩后的上下文表示，AI 智能体基于共同的理解进行操作。这显著降低了延迟和 token 成本。

3. 通用型 AI 智能体的消亡

2024 年初构建"通用"AI 助手的风潮在自身重量下崩塌了——太多的 AI 智能体循环、太少的专业化、太严重的幻觉。2025 年的赢家是每个 AI 智能体都有明确范围界定、工具访问权限有精确定义、可衡量准确率的系统。这就是为什么 Hermes 和 LobeHub 都将 AI 智能体专业化作为首要原则，而不是事后补救。

跨方案模式：两种方法的共同点

尽管架构不同，Hermes 和 LobeHub 在几个模式上殊途同归，这些模式似乎是任何生产级多智能体系统都必需的：

模式 1：AI 智能体身份与生命周期管理

每个 AI 智能体都需要一个稳定的身份，而不仅仅是一个名字。这包括：

• 一个唯一的、带版本的 AI 智能体 ID，用于跨会话追踪
• 一个能力清单，声明该 AI 智能体使用的工具和模型
• 一个随时间衰减的信誉或准确率评分
• 明确的生命周期状态：idle → assigned → active → completed / failed

interface AgentManifest {
  agentId: string;
  version: string;
  capabilities: Capability[];
  model: ModelSpec;
  toolAccess: ToolAccessPolicy;
  maxContextTokens: number;
  timeoutMs: number;
}

interface AgentState {
  agentId: string;
  status: 'idle' | 'assigned' | 'active' | 'completed' | 'failed' | 'timeout';
  currentTask?: string;
  sessionHistory: MessageHistory;
  lastActiveAt: number;
  errorCount: number;
}

模式 2：确定性降级链

两个系统都在每一层实现了降级链：

• 模型降级：如果主模型超过延迟或成本阈值，降级到质量降低（但可接受）的更便宜的模型
• AI 智能体降级：如果专业 AI 智能体失败或超时，路由到通用 AI 智能体或缓存结果
• 协议降级：如果共识未能收敛，回退到置信度最高的单个 AI 智能体输出，并附上异议

模式 3：结构化可观测性

无法观测就无法调试。两个系统都将可观测性作为一等公民来对待：

• 追踪：每次 AI 智能体调用都通过一个 span 进行追踪，捕获输入、输出、token 数、延迟和工具调用
• 成本追踪：按 AI 智能体、按请求、按会话的成本细分
• 质量指标：置信度评分、一致性检查和人机回环反馈机制
• AI 智能体健康仪表盘：每个 AI 智能体的错误率、延迟百分位和信誉评分

# 示例：AI 智能体生命周期的结构化日志记录
class AgentTelemetry:
    def __init__(self):
        self.tracer = OpenTelemetryTracer("multi-agent-system")
        self.metrics = PrometheusMetrics("agent_system")

    async def record_agent_call(self, call: AgentCall) -> None:
        with self.tracer.start_span("agent.invocation", trace_id=call.trace_id) as span:
            span.set_attribute("agent.id", call.agent_id)
            span.set_attribute("agent.model", call.model)
            span.set_attribute("tokens.input", call.input_tokens)
            span.set_attribute("tokens.output", call.output_tokens)
            span.set_attribute("latency_ms", call.latency_ms)
            span.set_attribute("confidence", call.result.confidence)
            span.set_attribute("cost_cents", call.estimated_cost_cents)

            if call.error:
                span.record_exception(call.error)
                self.metrics.increment("agent.errors", labels={"agent": call.agent_id})
            else:
                self.metrics.histogram("agent.latency", call.latency_ms,
                                       labels={"agent": call.agent_id})

模式 4：AI 智能体间状态隔离

AI 智能体绝不能直接共享可变状态。每个 AI 智能体操作于其所需上下文的不可变快照上，任何状态变更都通过显式消息传递。这防止了竞态条件，使调试变得可控，并支持为质量保证而重放 AI 智能体交互。

常见陷阱：多智能体系统在生产中失败的地方

基于 Hermes 和 LobeHub 部署后的复盘，以下是出现最频繁的失败模式：

陷阱 1：无界扇出

诱惑在于为每个子任务、每个验证步骤、每个边缘情况都生成一个 AI 智能体。这会造成指数级成本和延迟。两个系统都在编排器层面强制执行扇出上限：

interface OrchestrationPolicy {
  maxDepth: number;           // AI 智能体调用的最大嵌套深度
  maxFanOut: number;          // 最大并发 AI 智能体数
  maxTotalAgents: number;     // 每次请求的硬上限
  budgetCapTokens: number;    // Token 预算上限
  budgetCapUSD: number;       // 成本上限
  circuitBreaker: {
    errorRateThreshold: number;  // 如果 >X% 的 AI 智能体失败则触发
    timeoutThreshold: number;     // 如果平均延迟 >Y ms 则触发
  };
}

陷阱 2：通过 AI 智能体通道进行提示注入

当 AI 智能体自由通信时，恶意的用户输入可以通过 AI 智能体网络传播。如果 AI 智能体 A 向 AI 智能体 B 生成一条消息，而该消息包含 AI 智能体 B 将其视为权威的指令，就形成了提示注入攻击向量。两个系统都实现了：

• 每个 AI 智能体边界的输入清理
• 权限作用域：AI 智能体只能修改其被明确授权修改的状态
• 指令与数据分离：AI 智能体消息被解析和重构，绝不直接执行

陷阱 3：非确定性输出破坏调试

LLM 输出是概率性的。对同一 AI 智能体的两个相同请求可能产生不同结果。这使得测试几乎不可能，调试令人沮丧。缓解策略：

• 调试期间使用种子固定以实现可重现性（生产环境不行）
• 尽可能在随机操作周围使用确定性包装器
• 基于 diff 的测试：语义上比较输出，而非逐 token 比较
• 带大规模黄金数据集的回归测试套件

陷阱 4：上下文膨胀

随着 AI 智能体累积对话历史，上下文窗口很快被填满。两个系统都使用激进的上下文压缩：

• 摘要：较早的对话轮次被摘要，而非截断
• 相关性过滤：仅包含与当前 AI 智能体任务相关的上下文
• 去重：识别并移除各 AI 智能体上下文中的冗余信息

何时使用哪种方案

Hermes 和 LobeHub 都不是普遍更好的。正确的架构取决于你的需求。

新兴共识：混合架构

2025 年最有前景的系统结合了两种方案。它们使用 Hermes 风格的编排进行高层任务分解，使用 LobeHub 风格的共识处理推理关键子任务。结果是一个既快速又有创造力、既有界限又有探索性的系统。

典型的混合流程：

1. 将用户请求分解为任务图（Hermes 风格）
2. 将每个节点路由到适当的 AI 智能体类型（专家型 vs 工作型）
3. 并行执行独立节点（Hermes 风格）
4. 在存在多种解释的依赖节点上达成共识（LobeHub 风格）

使用确定性合并逻辑聚合结果，仅在必要时回退到 LLM 协调

这种混合方式正在成为生产级多智能体系统的事实标准模式，因为它能同时发挥两种范式的优势并削弱其弱点。

构建你自己的系统：一份实用清单

如果你计划在 2025 年构建多智能体系统，以下来自 Hermes、LobeHub 及相关系统的证据表明你需要：

第一阶段：基础（第 1–2 周）

• [ ] 定义你的智能体类型分类（专家型 vs 工作型 vs 编排型）
• [ ] 实现带类型的消息协议（不要使用原始字符串）
• [ ] 构建确定性任务分解引擎
• [ ] 在编写任何智能体逻辑之前先搭建结构化可观测性

第二阶段：核心引擎（第 3–4 周）

• [ ] 实现带扇出控制和熔断器的编排器
• [ ] 构建带能力清单和信誉追踪的智能体注册表
• [ ] 创建预算感知路由层
• [ ] 实现上下文压缩和共享状态管理

第三阶段：韧性（第 5–6 周）

• [ ] 在每一层添加降级链
• [ ] 在智能体边界实现提示注入防御
• [ ] 如果你的用例需要发散推理，构建共识协议
• [ ] 为智能体交互创建回放/调试模式

第四阶段：规模化（第 7–8 周）

• [ ] 添加智能体池和连接管理
• [ ] 为编排器实现水平扩展
• [ ] 构建自动化智能体评估和 A/B 测试基础设施
• [ ] 为高风险操作部署护栏和人工介入检查点

常见问题

问：我真的需要自定义多智能体框架吗？还是可以用 LangGraph 或 AutoGen？

对于简单的工作流，这两个框架都够用。但它们抽象掉了生产环境中真正重要的规模化问题：成本控制、可观测性、提示注入防御以及负载下的韧性。Hermes 和 LobeHub 的做法表明，这些问题需要通用框架无法处理的架构决策。如果你构建的东西需要在规模化下可靠运行，投入专用基础设施是值得的。

问：如何在线性编排和对等共识之间做选择？

经验法则：当问题有清晰子组件可以分解并独立解决时（数据处理、代码生成、工单处理），使用线性编排。当问题需要创造性综合、权衡分析，或者存在多个正确答案而你需要找到最佳方案时（策略规划、研究综合、设计评审），使用共识方式。混合方式能兼得两者优势。

问：一个复杂多智能体请求的现实成本是多少？

在 2025 年观察到的生产系统中，一个经过良好优化的 5–8 个智能体多智能体请求通常花费 $0.50–$3.00，取决于复杂度和模型选择。未经优化的系统很容易超过每个请求 $10。关键差异化因素在于是否使用了预算感知路由和上下文压缩。如果你的成本更高，很可能是因为生成了过多智能体或未能有效压缩共享上下文。

2025 年的 AI 智能体爆发不在于让单个智能体更聪明——而在于构建多个专业智能体能有效协作的系统。Hermes 和 LobeHub 代表了该设计空间中两个经过验证的切入点，它们正在收敛的混合架构表明这个领域仍在快速演进。随着多智能体系统从实验性走向关键基础设施，现在内化这些模式的工程师将获得显著优势。

如需进一步行动，你可以考虑屏蔽此人和/或举报滥用。