生产级 Multi-Agent 系统目标，是不是 Agent 越多越强？

Icarus_

355人浏览 · 2026-06-02 13:07:37

Icarus_ · 2026-06-02 13:07:37 发布

以下是为您总结的文章核心内容，以及针对面试问题的口述回答版本：

一、文章核心总结

本文的核心观点是：生产级 Multi-Agent 系统拼的不是 Agent 的数量，而是底层运行时框架 Harness 的稳定性。 理念是：“Agent 负责局部智能，Harness 负责全局控制”。

核心矛盾（生产鸿沟）： 在 Demo 阶段，Agent 可能只是简单的链式调用；但在生产环境中，会遇到循环卡死、黑盒不可解释、Token 消耗过大（爆 Token）、工具乱调用等问题。
Harness 的作用： 为了解决这些问题，引入了一个中间层 Harness（管控层），它负责“接管生产约束”，确保 Agent 不仅聪明，而且可控。
1. 编排调度： 决定任务的执行顺序（谁先跑，谁能并行），解决效率问题。
2. 工具治理： 精细化管理，规定谁（哪个 Agent）能调用什么工具，防止越权。
3. 轨迹评估： 在执行过程中不断审视过程是否依然可信，防止跑偏。
4. 预算控制： 设定资源上限，当成本过高或效果不佳时自动降级或熔断（止损）。
5. Trace 审计： 记录结果如何得出，便于事后复盘和责任界定。
核心结论： 随着系统中 Agent 数量的增加，混乱会指数级上升，因此越需要 Harness 来“兜住执行边界”，保证系统的稳定性。

从七个层次详细拆解了生产级 Multi-Agent Harness 的核心能力

架构编排（决策权边界）：Planner Agent 只输出声明式计划（当导航），Orchestrator 掌握裁决权（握方向盘），Harness 强制管控任务生命周期、Agent路由、失败处理和硬终止条件。
1. 决策权边界：Agent 出主意，Harness 拿决定
  
  Harness 的内部工作机制，强调了 Planner（规划者） 与 Harness（仲裁者） 之间的权责划分。
2. 工作流程：
  1. 输入： 用户提交任务。
  2. 出主意（Planner Agent）： Planner 负责构思并输出一份“声明式计划”（即打算怎么做）。
  3. 拿决定（Orchestrator/Harness）： 真正的权力掌握在 Orchestrator（编排器，即 Harness 的核心）手中。它拥有绝对的否决权，会裁决三个关键问题：
    - 能否执行？
    - 是否并行？
    - 是否超预算？
  4. 执行（Worker Agents）： 只有被 Harness 批准后的步骤，才会交给底层的 Worker Agents 去实际执行。
3. Harness 的具体管控点： 除了上述裁决，Harness 还管理任务生命周期、计划变更、Agent 路由以及失败后的重试处理，并设定了不可逾越的“硬终止条件”（如安全红线）。
4. 核心结论： 这是一种“计划经济”式的管控思路。“Planner 只提交计划，方向盘必须握在 Harness 手里”，绝不让 Agent 拥有完全的自由裁量权。
工具治理（Tool Registry安全边界）：工具不是普通函数，而是生产资源的授权点。哪怕只有3个工具，也从第一天起强制走 Tool Registry，进行 Schema 校验、权限检查、风险分级、人工确认和审计日志。
1. Agent 与外部世界交互的接口——工具（Tool）。它指出在生产环境中，工具调用不仅仅是写代码调用 API，而是涉及安全和权限的资源操作。
2. 工具调用流程（严格的多重安检）：
  1. 入口： Agent 发出工具请求。
  2. Schema 校验： 检查参数类型、必填项等基础格式是否正确。
  3. 权限检查： 基于 Agent 的身份、用户身份或租户隔离策略，检查是否有调用资格。
  4. 风险分级： 对工具进行分级（只读 / 写入 / 高危）。
    - 如果是高风险动作，则必须引入人工确认环节。
  5. 执行与日志： 通过所有检查后，才允许“真实工具执行”，并且必须留下“审计日志”（记录调用者、参数、结果和时间）。
  6. 拦截机制： 任何一个环节校验失败，系统都会直接拦截，采取拒绝、打回或降级处理。
3. 核心结论： 哪怕初期只有很少的工具，也必须建立统一的入口和严格的治理流程，因为在生产环境中，“工具即权力”。
状态与记忆（分层与修剪）：区分短期的 State（Working/Session/Log）和跨任务的 Memory（Episodic/Semantic）。记忆不是仓库是花园，采用混合注入方式，并建立遗忘机制（低分删除、中分摘要、高分保留）。
评估体系（看重轨迹）：不能只看最终答案，要看中间执行轨迹。建立四层评估：单组件评估、轨迹评估、任务完成度评估、端到端业务评估。Eval 必须进入 CI 进行回归。
成本控制（Token Budget生命线）：Token 预算不是事后统计，而是实时调度。通过模型路由、上下文压缩，以及四级降级状态机（绿区正常 -> 黄区压缩 -> 红区切小模型 -> 熔断区强制收束/转人工）来控制成本。
MCP 接入（标准化不等于裸奔）：MCP 提供工具能力，Harness 提供治理。绝不允许 Agent 直连 MCP Server，必须经 Harness 安全网关，实施工具白名单、单独配额、高风险人工确认及全链路 Trace。
可观测性与落地路线：全链路 Trace 记录从输入到降级的所有细节，防止过程偏移。落地分三步走：MVP（跑通闭环）-> Hardening（补齐权限/预算/评估等控制）-> Scale（扩大规模与并发）。

二、面试口述版本

面试官：“你怎么看 Multi-Agent 的未来？是不是 Agent 越多越强？”

你的回答（口述版）：

“面试官您好，我不认为未来竞争是看谁堆了更多的 Agent。Multi-Agent 在 Demo 阶段确实可以靠拆分 Planner、Worker、Reviewer 这些角色快速出效果，但一旦进入生产环境，真正难的是稳定性、成本、权限、评估和可观测性。

我的核心观点是：Agent 负责局部智能，而 Harness 负责全局控制。

如果把 Multi-Agent 系统比作一场戏，Agent 是演员，Harness 就是导演、调度台和安全规章。生产级系统必须通过 Harness 管住 Agent，具体来说我认为有五个关键点：

第一是编排与决策权。 不能让 Agent 自己既当裁判又当运动员。Planner 只能提出声明式的计划，而任务的 lifecycle、路由、重试和硬终止条件，必须由 Harness 里的 Orchestrator 来裁决。我们要让 Agent 当导航，但方向盘必须握在 Harness 手里。

第二是工具治理。 给 Agent 工具不是给函数，而是给权限钥匙。所有的工具调用必须经过统一的 Tool Registry，做入参校验、RBAC 权限控制和高危操作审批。即使接入 MCP 这种标准协议，也绝不能让 Agent 直连，必须经过 Harness 的安全网关，MCP 提供能力，但 Harness 必须提供治理。

第三是状态与记忆。 必须把短期的运行 State 和长期的 Memory 分离。同时记忆不是只增不减的仓库，而是需要修剪的花园，要有遗忘机制，低分的删除，中分的摘要，高分的保留，避免上下文膨胀污染决策。

第四是成本控制。 Token 预算是生命线，它不能是事后算账，必须是实时调度。要根据任务进度做模型路由，比如简单任务用小模型；同时设定预算降级状态机，剩余预算多时正常跑，不足时压缩上下文或切小模型，触达熔断线就强制收束或转人工。

最后是评估与可观测。 Multi-Agent 最怕黑盒，最终答案对了不代表过程没问题。所以我们不能只看结果，必须看‘轨迹’，建立组件、轨迹、任务完成度到端到端的四层评估体系；同时铺全链路的 Trace，记录每一次工具调用、路由选择和降级原因。

Multi-Agent Eval：不要只看答案，要看轨迹

评估的四个维度（不仅看结果，还要看过程）：
1. Component Eval： 单元测试，检查单个 Agent 或工具的输入输出是否合规。
2. Trajectory Eval： 过程评估，检查中间步骤是否必要、是否存在死循环或无效绕路。
3. Task Completion： 检查是否真正满足了用户的原始目标（有时答案对，但没解决根本问题）。
4. End-to-End Eval： 业务指标评估，看采纳率、返工率和成本效益。
技术实现手段：
- 确定性检查： 类似代码测试，检查 Schema 对齐、权限合规等。
- LLM-as-Judge（大模型裁判）： 利用另一个大模型来评估执行轨迹的表达完整性和连贯性。
核心结论： 一个 Agent 系统即使最终答案正确，也不代表它的执行过程是可信的（可能只是运气好或走了歪路）。因此，必须通过 CI（持续集成）流水线，将 Prompt、模型和工具的变更纳入回归测试，确保系统行为的稳定性。