从零设计生产级Multi-Agent Harness全拆解
从零设计生产级 Multi-Agent Harness 全拆解
核心观点
Multi-Agent 系统从 Demo 到生产的鸿沟，不靠更强的模型或更精妙的 Prompt 跨越，而是靠背后的运行时底座——Multi-Agent Harness。它负责编排、调度、记忆、状态、工具治理、预算控制、可观测性、安全边界，是 Agent 的"操作系统"。
"Prompt 是台词，Agent 是演员，工具是道具，模型是大脑，而 Harness 是整个舞台的导演、灯光、调度系统、安全规章和票务系统。"
文章从五大核心模块拆解生产级 Harness 设计：架构编排、工具治理、状态与记忆、评估体系、成本控制，外加 MCP 工具接入。
Harness vs 其他概念
| 概念 | 解决的问题 |
|---|---|
| Prompt 模板 | 让模型理解任务 |
| Orchestrator | 解决执行顺序 |
| Agent Framework（LangGraph/AutoGen） | 提供积木 |
| Harness | 把积木拼成生产建筑：资源、记忆、成本、安全、可观测 |
模块一：架构编排
核心原则
Agent 负责局部智能，Harness 负责全局控制。 别让 Agent 开车，让 Agent 当导航。
Orchestrator 独占的五项决策权
- 任务生命周期：创建→规划→执行→审查→完成/失败，明确状态机
- 执行计划裁决：计划可来自 Planner Agent，但一旦生成由 Orchestrator 接管
- Agent 路由：结合任务类型、Agent 能力、权限、历史质量评分
- 失败处理：重试/降级/跳过/终止，不让出错 Agent 自己决定
- 硬终止条件：max_steps / max_tokens / max_duration / max_tool_calls 四道硬闸
声明式计划 vs 命令式调用
- 声明式：
{step: 1, intent: "research", agent: "researcher", input: "..."}- Harness 可重排/并行/拒绝/审查
- 命令式：
await researcher.run("...")- 方向盘交给了 Agent，失去控制
模块二：工具治理（Tool Registry）
核心理念
工具不是函数调用，而是生产资源的对外授权点。给 Agent 一个工具 = 给它一把权限钥匙。
Tool Registry 九项元信息
| # | 元信息 | 说明 |
|---|---|---|
| 1 | 工具名称 | 唯一标识 |
| 2 | 工具描述 | 给 LLM 看的说明 |
| 3 | 输入参数 JSON Schema | 用于校验 |
| 4 | 允许调用的 Agent 列表 | RBAC |
| 5 | 调用超时与速率限制 | 防资源耗尽 |
| 6 | 风险等级 | 低/中/高 |
| 7 | 是否需要人工确认 | Human-in-the-Loop |
| 8 | 输出结果结构 | 标准化 |
| 9 | 审计日志策略 | 保存什么、保留多久、谁能看 |
关键原则：哪怕只有 3 个工具，也从第一天起强制走 Tool Registry。先有规矩，后扩规模。
模块三：状态与记忆
状态 vs 记忆
| 状态（State） | 记忆（Memory） | |
|---|---|---|
| 生命周期 | 短（当前任务） | 长（跨任务） |
| 关心 | 一致性 | 相关性 |
状态三层
- Working State：当前步骤临时上下文，任务结束即丢
- Session State：会话内多 Agent 共享，放 Redis 设 TTL
- Execution Log：不可变日志，用于审计/回放/评估
记忆两类
- Episodic Memory（事件记忆）：踩过的坑、用户偏好、处理经验
- Semantic Memory（语义记忆）：领域概念、业务规则、工具约束
两个被低估的设计点
注入时机：生产推荐混合模式——前置注入少量高置信记忆 + 提供 memory_search 工具供 Agent 主动调用。
遗忘机制：基于访问频次、创建时间、重要性、最近使用计算保留分数：
- 低分 → 删除
- 中分 → 压缩为摘要
- 高分 → 保留原文
"记忆不是仓库，而是花园。需要定期修剪。"
模块四：评估体系
四层 Eval Pipeline
| 层级 | 评估内容 |
|---|---|
| Component Eval | 单 Agent 是否选对工具、参数合规、输出符合角色 |
| Trajectory Eval | 步骤是否必要、顺序合理、是否重复/循环（Multi-Agent 最大创新点） |
| Task Completion Eval | 是否满足用户目标、覆盖必要信息、无事实错误 |
| End-to-End Eval | 用户采纳率、人工返工率、处理时长、单位任务成本 |
混合评估方法
- 单元测试检查代码
- Schema 校验结构化输出
- 规则引擎检查安全约束
- 检索对齐校验引用来源
- LLM-as-Judge 评开放式表达
- 人工抽检校准 Judge 偏差
- 线上反馈验证业务效果
关键：Eval 必须进入 CI。Prompt 就是代码，工具 Schema 就是接口，执行轨迹就是日志，Eval 就是测试体系。
模块五：成本控制（Token Budget）
三大策略
策略一：Model Routing（模型路由）
- 分类/摘要/格式转换 → 小模型
- 复杂推理/最终合成 → 强模型
- 高风险审查 → 强模型 + 规则校验
- 低价值重试 → 禁止高价模型
策略二：Context Compression（上下文压缩）
- 保留最近几轮原文 + 更早历史压缩为结构化摘要
- 事实型任务保留原始引用，合规型任务关键证据不可压缩
策略三：Budget 分级降级
| 区间 | 预算剩余 | 动作 |
|---|---|---|
| 绿区 | >50% | 正常执行 |
| 黄区 | 20%-50% | 压缩上下文 |
| 红区 | 5%-20% | 切小模型 + 跳过 CoT |
| 熔断区 | <5% | 强制收束，返回 partial result |
核心监控指标
- 单任务 Token 总量 / 单 Agent Token 占比
- 工具结果 Token 占比 / 重试 Token 占比
- 预算熔断次数
- 单位业务结果成本（每完成一个合格任务多少钱）——能回答这个才进入可运营阶段
MCP 工具接入
MCP 解决什么
工具一次实现，所有支持 MCP 的 LLM 应用都能调用。类比：MCP 之于 AI 工具 = USB-C 之于充电接口。
对 Harness 的意义
- 快速扩展能力（文件系统/数据库/Git/Slack/Jira等一键接入）
- 生态可复用（业界 MCP Server 直接拿来用）
- 解耦工具与模型（切换模型成本低）
五条最佳实践
- 永远不要把 MCP Server 直接暴露给 Agent——必须经过 Tool Registry
- 给每个 MCP Server 单独配额——一个流氓 Server 不应拖垮系统
- 白名单而非黑名单——只开放业务真正需要的工具
- 高风险工具走 Human-in-the-Loop——文件写入/删除/代码执行/数据库写/外部支付
- 所有 MCP 调用打 Trace——来源、参数、结果、调用者可追溯
"MCP 让工具接入变得便宜，Harness 让工具调用变得可信。两者必须搭配。"
落地路线（三阶段）
| 阶段 | 目标 | 重点 |
|---|---|---|
| Phase 1 MVP | 跑通一条端到端业务闭环 | 最小 Orchestrator + Tool Registry + 简单状态 + 基础 Trace + 评估数据集 |
| Phase 2 Hardening | 把 Demo 变成可控系统 | Budget/权限/重试/压缩/轨迹评估/审计/回归测试 |
| Phase 3 Scale | 支撑更多场景与并发 | 分布式队列/多租户/动态路由/A/B测试/长期记忆治理/统一MCP平台/成本看板 |
技术选型建议
- 小团队：LangGraph 或自研轻量状态机 + FastAPI + Redis + PostgreSQL/pgvector + Langfuse + LiteLLM
- 企业团队：重视权限/审计/多租户/成本中心/数据治理，MCP 作为标准但不允许直连 Agent
- 研究团队：探索动态 Planner/自反思/自动 Eval/长期记忆压缩，但区分研究效果和生产 SLA
关键引用
"没有 Harness，Multi-Agent 只是热闹；有了 Harness，Agent 才可能成为生产力。"
"Multi-Agent Harness 不是纯算法项目，而是系统工程。需要算法、后端、平台、安全、业务专家的多角色协同。"
"未来的竞争，不是谁的 Agent 更多，而是谁的 Harness 更稳。"