从零设计生产级 Multi-Agent Harness

核心观点

真正决定 Multi-Agent 系统能否落地的，不是更强的模型或更精妙的 Prompt，而是背后那个常常被忽略的运行时底座——Multi-Agent Harness（多智能体执行框架）。

一、Harness 是什么

定义

Multi-Agent Harness 指的是把多个 Agent 的能力、工具、状态、通信、编排、监控统一收束在一个运行时之内的框架。

与相关概念的区别

概念	解决的问题	Harness 的额外职责
Prompt	怎么让模型理解任务	Harness 解决"怎么让模型可靠地完成任务"
Orchestrator（编排器）	顺序问题	Harness 还要解决资源、记忆、成本、安全、可观测
Agent Framework（LangGraph、AutoGen）	提供积木	Harness 是把积木拼成生产建筑的工程方案

类比

Prompt 是台词，Agent 是演员，工具是道具，模型是大脑，而 Harness 是整个舞台的导演、灯光、调度系统、安全规章和票务系统。

二、架构编排：Agent 出主意，Harness 拿决定

核心原则

Agent 负责局部智能，Harness 负责全局控制。

常见失败模式

让 Planner Agent 自己决定调用哪个 Agent、是否继续、是否重试——短期灵活，长期危险。因为大模型没有天然的成本意识、并发意识、权限意识、全局一致性意识。

Orchestrator 独占的五项决策权

决策权	说明
任务生命周期	每个任务从创建、规划、执行、审查、完成、失败，都要有明确的状态机
执行计划裁决	计划可来自静态 DAG 或 Planner Agent，但一旦生成必须由 Orchestrator 接管，判断每一步是否能跑、是否并行、是否超预算
Agent 路由	结合任务类型、Agent 能力、权限、历史质量评分进行路由
失败处理	某个 Agent 失败后是重试、降级、跳过还是终止，不能让出错 Agent 自己说了算
硬终止条件	必须有 `max_steps`、`max_tokens`、`max_duration`、`max_tool_calls` 四道硬闸

声明式计划 vs 命令式调用

命令式：直接 await researcher.run(...) — 把方向盘交给了 Agent
声明式：Planner 输出声明式计划 — Harness 可以介入重排顺序、并行优化、拒绝某些步骤、执行前做安全审查

别让 Agent 开车，让 Agent 当导航。

三、工具治理：Tool Registry 是 Agent 的安全边界

核心理念

工具不是函数调用，而是生产资源的对外授权点。你给 Agent 一个工具，等于给它一把权限钥匙。

Tool Registry 九项元信息

元信息	说明
工具名称	唯一标识
工具描述	给 LLM 看的说明
输入参数 JSON Schema	用于校验
允许调用的 Agent 列表	RBAC 权限控制
调用超时与速率限制	防滥用
风险等级	低/中/高
是否需要人工确认	高风险操作必须确认
输出结果结构	结构化定义
审计日志策略	保存什么、保留多久、谁能看

落地建议

哪怕只有 3 个工具，也从第一天起强制走 Tool Registry。先有规矩，后扩规模。

工具治理不是装饰层，而是结构层。如果没有统一入口，系统会迅速演化成一团"散落的特权代码"，再想收回来代价极高。

四、状态与记忆：记住该记的，忘掉该忘的

记忆的四种典型失败

失败类型	表现
记得太少	每次都像第一次，无法复用经验
记得太多	上下文膨胀，检索噪声大，成本爆炸
不分层	临时数据和长期知识混在一起
不遗忘	过期信息长期污染决策

状态 vs 记忆

	状态（State）	记忆（Memory）
定义	当前任务运行所需的数据	跨任务复用的经验和知识
生命周期	短	长
关注点	一致性	相关性

状态分层

层级	说明
Working State	当前步骤的临时上下文，任务结束即丢
Session State	一次会话里多个 Agent 共享的信息，放 Redis，设 TTL
Execution Log	不可变执行日志，用于审计、回放、评估

记忆分层

类型	说明	示例
Episodic Memory（事件记忆）	踩过的坑、用户偏好、某类问题处理经验	"用户偏好 Python"
Semantic Memory（语义记忆）	领域概念、业务规则、工具约束	"该接口有速率限制"

注入时机（Retrieval Timing）

模式	优点	缺点
任务前自动注入	简单稳定	费 Token
按需检索	省钱	Agent 可能忘记调用
混合模式（推荐）	前置注入少量高置信记忆 + 提供 `memory_search` 工具供 Agent 主动调用	—

遗忘机制（Memory Forgetting）

记忆不是仓库，而是花园。需要定期修剪。

基于访问频次、创建时间、重要性、最近使用计算保留分数：

低分记忆 → 直接删除
中分记忆 → 压缩为摘要
高分记忆 → 保留原文

五、评估体系：不要只看答案，要看轨迹

为什么只看最终答案不够

最终报告对了，但中间用了未授权的数据源
最终代码能跑，但 Agent 调用了十几次无意义工具
最终回答完整，但关键事实来自错误检索
某次结果成功，只是因为重试撞上了正确答案

四层评估体系

层级	名称	评估内容
第一层	Component Eval（组件评估）	单 Agent 是否选对工具、参数是否合规、输出是否符合角色职责
第二层	Trajectory Eval（轨迹评估）	步骤是否必要、顺序是否合理、是否重复调用、是否陷入循环。Multi-Agent 最大的创新点
第三层	Task Completion Eval（任务完成度）	是否满足用户目标、是否覆盖必要信息、是否存在事实错误
第四层	End-to-End Eval（端到端业务效果）	用户是否采纳、人工返工率、处理时长、单位任务成本

LLM-as-Judge 的局限

适合：评估表达完整性、推理连贯性、总结质量等开放式输出
不适合：事实正确性、代码可运行性、SQL 结果、权限合规——应优先用确定性检查

成熟 Eval 必然是混合的

单元测试检查代码
Schema 校验结构化输出
规则引擎检查安全约束
检索对齐校验引用来源
LLM-as-Judge 评开放式表达
人工抽检校准 Judge 偏差
线上反馈验证业务效果

Eval 必须进入 CI

每次改 Prompt、换模型、加工具、调参数，都要跑回归。Prompt 就是代码，工具 Schema 就是接口，执行轨迹就是日志，Eval 就是测试体系。

六、成本控制：Token Budget 是生命线

为什么 Multi-Agent 烧钱

每个 Agent 都有 System Prompt
每个 Agent 都需要上下文
工具结果会被塞回模型
Planner 生成计划 → Worker 执行步骤 → Reviewer 审查输出
失败后还要重试
多轮协作让历史不断复制膨胀

策略一：Model Routing（模型路由）

任务类型	模型选择
分类、摘要、格式转换	小模型即可
复杂推理、最终合成	强模型
高风险审查	强模型 + 规则校验双保险
低价值重试	禁止使用高价模型

目标不是一味省钱，而是在质量和成本之间找到可控平衡。

策略二：Context Compression（上下文压缩）

保留最近几轮原文 + 把更早历史压缩成结构化摘要
摘要中只保留：关键事实、决策、未解决问题、工具结果引用
注意：事实型任务必须保留原始引用，合规型任务关键证据不可压缩

策略三：Budget 分级降级

区间	策略
绿区（>50%）	正常执行
黄区（20%–50%）	压缩上下文
红区（5%–20%）	切小模型 + 跳过 CoT
熔断区（<5%）	强制收束，返回 partial result

关键监控指标

单任务 Token 总量
单 Agent Token 占比
工具结果 Token 占比
重试 Token 占比
不同路由策略下的成本与成功率
预算熔断次数
单位业务结果成本（每完成一个合格任务多少钱）

当你能精准回答最后一项时，Agent 系统才真正进入了可运营阶段。

七、MCP 工具接入：标准化是趋势，但不能裸奔

MCP 解决的核心问题

MCP 之于 AI 工具，如同 USB-C 之于充电接口。

工具一次实现，所有支持 MCP 的 LLM 应用都能调用。

MCP 对 Harness 的三点意义

快速扩展能力：通过 MCP Server 一键接入文件系统、数据库、Git、Slack、Jira、内部 API
生态可复用：业界形成的 MCP Server 可以直接拿来用
解耦工具与模型：工具实现不绑定特定 LLM，切换模型成本更低

MCP 接入最佳实践

实践	说明
永远不要把 MCP Server 直接暴露给 Agent	必须经过 Tool Registry。MCP 提供"能力"，Harness 提供"治理"
给每个 MCP Server 单独配额	一个流氓 MCP Server 不应该拖垮整个系统
白名单而非黑名单	哪怕 MCP Server 暴露了 50 个工具，也只把业务真正需要的几个开放给特定 Agent
高风险工具走 Human-in-the-Loop	文件写入、删除、代码执行、数据库写、外部支付不能让 Agent 自动执行
所有 MCP 调用都要打 Trace	工具来源、参数、结果、调用者必须可追溯

MCP 让工具接入变得便宜，Harness 让工具调用变得可信。两者必须搭配，不可偏废。

八、可观测性

传统后端出问题看日志、指标、链路。Agent 系统更需要这些，因为 Agent 的错误往往不是异常，而是过程偏移。

过程偏移的表现：

调用了错误工具
读取了错误记忆
误解了用户目标
因为压缩丢了关键约束
因为预算不足提前收束
因为路由用了能力不够的小模型

九、落地路线：分三阶段演进

Phase 1 — MVP

跑通一条端到端业务闭环：

最小 Orchestrator + Tool Registry
简单状态 + 基础 Trace
评估数据集

不要一开始就上动态 Planner、十个 Agent、复杂长期记忆。先把一条链路跑稳。

Phase 2 — Hardening

把 Demo 变成可控系统：

增加 Budget、权限、重试、压缩
轨迹评估、审计、回归测试
重点解决"为什么错、哪里贵、哪里慢、哪里不安全"

Phase 3 — Scale

支撑更多场景与并发：

分布式队列、多租户隔离
动态模型路由、Agent 质量排行榜
A/B 测试、长期记忆治理
统一 MCP 接入平台、成本看板

技术选型建议

团队类型	推荐方案
小团队	LangGraph 或自研轻量状态机 + FastAPI + Redis + PostgreSQL/pgvector + Langfuse/OpenTelemetry + LiteLLM 网关
企业团队	更重视权限、审计、多租户、成本中心、数据治理。MCP 作为接入标准，但不允许直连 Agent
研究团队	可探索动态 Planner、自反思、自动 Eval、长期记忆压缩，但务必区分研究效果和生产 SLA

总结

未来的竞争，不是"谁的 Agent 更多"，而是"谁的 Harness 更稳"。

落地前必须回答的十个问题

任务怎么进来？
谁负责拆解？
谁负责调度？
工具怎么接？
状态放哪里？
记忆怎么检索？
预算怎么控制？
轨迹怎么评估？
失败怎么处理？
审计怎么保留？

把这十个问题回答清楚，你就已经越过了大多数 Agent Demo 的边界。

组织层面提醒

Multi-Agent Harness 不是纯算法项目，而是系统工程。它需要算法、后端、平台、安全、业务专家的多角色协同。如果团队只让一个"会写 Prompt 的同学"负责全部，几乎一定卡在 Demo 阶段。