Agent Harness 架构¶

📊 Level ⭐⭐⭐ | 14.3KB

7 层架构¶

层级	核心职责	关键设计
L1 执行引擎	双循环稳定性	快执行循环 + 慢思考循环（每3步/出错触发），成功率 60%→90%+
L2 工具系统	安全可控	五级风险分级（L0-L4）+ 路径安全 + MCP 生态
L3 上下文	成本控制	阶梯压缩降 52% Token + 会话隔离
L4 记忆系统	知识准确	三层记忆架构 + 知识编译（幻觉率 30%→5%）
L5 决策引擎	自主运行	愿景→目标→任务→动作四层目标分解
L6 多 Agent	协作	任务分配 + 共识 + 冲突解决
L7 行业应用	业务落地	医疗/法律/金融/研发

核心设计原则¶

Harness = 底盘 + 刹车 + 仪表盘 + 安全带：框架给工具，Harness 给系统级保障
稳定压倒一切：断点续跑、多模型容灾、五级风险分级
成本意识：上下文压缩 52%、简单任务用便宜模型
知识编译：写入时做对，读取时直接用，而非让大模型总结

工具系统设计¶

L0：只读操作，自动执行
L1：新文件写入，自动执行 + 日志
L2：修改已有文件，Diff 预览 + 10 秒自动执行
L3：删除/系统命令，必须人工审批
L4：格式化/高危命令，直接拦截

深度分析¶

架构演进逻辑：从工具箱到操作系统 Agent Harness 的 7 层架构体现了从「单点工具调用」向「系统级保障」的范式转变。传统框架（如 LangChain）聚焦于「给 Agent 提供工具」，而 Harness 强调「给 Agent 提供运行环境」——这类似于从「给汽车提供零件」到「提供整车底盘+安全系统」的区别。L1 执行引擎的双循环设计是核心，它将快速执行（响应速度）与慢速复盘（质量保障）分离，避免了单循环模式下「为快失准」的问题。 稳定性设计的工程价值 断点续跑机制是生产级系统的分水岭。在复杂长程任务中，网络波动、模型超时、外部 API 不可用等问题不可避免。没有断点续跑，Agent 从头重来的成本极高；有了断点续跑，任务可以在任意稳定点恢复。这将「任务完成率」从「尽力而为」提升到「可承诺」。多模型容灾层进一步保障了单一模型故障不影响整体系统可用性，成本降 50% 的数字背后是「用便宜模型处理简单任务，昂贵模型处理复杂任务」的精细化成本管理。 工具系统的风险分级哲学 五级风险分级（L0-L4）将「人工介入」从全局要求降级为按需触发。L0 只读操作完全自动化，L4 高危命令直接拦截，中间层级提供渐进式安全保障。这种设计的精妙之处在于：它不追求「零风险」，而是追求「风险可见且可控」。每个操作的风险等级由系统判定而非人工判断，审批节点仅在必要时触发，这解决了完全人工审批带来的效率瓶颈问题。 记忆系统的知识编译范式 传统 RAG 的问题是「读取时让大模型总结」——这意味着每次检索都依赖模型的推理能力，且推理质量不稳定。知识编译范式反其道而行：在写入时完成知识的结构化和 QA 化，读取时直接获取准确答案。幻觉率从 30% 降至 5%，准确率 95%+ 的代价是在写入阶段投入更高成本，但读取阶段的延迟和成本都大幅降低。这是典型的「写入时花功夫，读取时享便利」的设计理念。

实践启示¶

1. 从单层尝试逐步构建 不要试图一次性实现完整 7 层架构。建议从 L1 执行引擎 + L2 工具系统开始，验证双循环稳定性后再逐步引入上下文工程和记忆系统。每一层的复杂度都需要工程团队有相应的运维能力。 2. 工具风险分级需要结合业务场景定制 五级分级是通用框架，具体阈值（如 L3 审批的触发条件）需要根据业务风险承受能力调整。医疗场景的 L3 可能对应法律场景的 L2。风险分级表应该作为配置项而非硬编码。 3. 上下文压缩策略应成为成本控制核心 52% Token 降低不是一次性优化，而是持续的成本管理实践。建议在 L3 上下文工程层建立压缩效果的监控面板，追踪每日的 Token 消耗趋势，识别异常的上下文膨胀。 4. 知识编译需要提前投入 知识编译的收益在读取侧，但成本在写入侧。如果业务场景中读取频率远高于写入频率（如客服、知识库查询），知识编译的 ROI 极高。但如果写入频率也很高，需要评估维护知识库的成本是否超过收益。 5. 多模型容灾的路由规则需要持续优化 20+ 路由规则不是一次性配置，而是随着业务运行持续调优的系统。建议建立模型表现的历史数据库，定期分析「哪些任务类型适合哪个模型」，让路由规则从经验积累中迭代进化。 6. 多 Agent 协作优先解决冲突检测 L6 多 Agent 层最难的不是任务分配，而是冲突解决。建议在初期就建立冲突检测机制——当多个 Agent 对同一资源或同一决策有不同意见时，系统能够记录冲突并触发人工审核或规则仲裁。

全链路运行链视角（2026-10-05 若飞）¶

Agent 不是 LLM 加一串工具，而是一条带状态、验证和恢复能力的运行链：Goal → Plan → Context → Decide → Act → Observe → Verify → State → Next。这不是给所有 Agent 产品画同一张图，而是给 Planner/Tool/MCP/Memory/Reflection 各找运行坐标——先看它们站在链上哪一段。

模块职责分层：Planner 管阶段不是一次性剧本（决定当前阶段目标/允许工具/保留证据/进入下一阶段条件），与 Workflow 互补——稳定部分固化、未知分支交给模型；Reasoning 只负责当前轮次局部决策，不能替系统做权限、保存状态、验收——prompt 不是架构边界，权限/状态/验证/恢复要放到模型外运行时；Tool 按副作用四层分（只读查询/改本地状态/影响外部系统/高成本调用，各有对应架构处理）；Function Calling 是调用表达方式，MCP 是协议层且不是安全边界的全部（授权/审计/沙箱/脱敏仍由宿主完成）；Harness 负责把调用放进权限、状态、验证和恢复机制里。

Memory 三对象 vs 本文 L4 记忆层：上下文窗口（模型下一步决策，常见错误是把完整日志塞进去）、事件日志（系统恢复和审计，常见错误是只让模型"记住"）、可复用记忆（未来任务，常见错误是把一次偶然结果写成规则）——三层不能互相替代，Memory 的关键不是"存得多"而是"什么时候把什么拿出来"。与本文 L4 的三层记忆架构互补：本文补的是运行链坐标下的存储对象划分与读出时机。

Reflection 两层闭环：反馈生成（从测试失败/工具错误/用户补充/审查意见提炼问题）+ 反馈生效（把稳定问题写入下一轮上下文/规则/评测样例/技能文档/版本化配置）——价值不在总结而在让错误对下一次有用，与 Reflexion 论文的语言反思+episodic memory buffer 一脉相承但落到生产验证器。

Harness 七项运行时职责：上下文装配、工具路由、权限控制、状态保存、验证机制、追踪观测、恢复停止。Harrison Chase 的 Meta-Harness 讨论：Agent 持续学习不只发生在模型层，也可能发生在 harness layer 和 context layer——系统改进有时不来自模型权重，而来自上下文装配、工具定义、校验规则、评测样例和恢复策略。

五组概念拆分与架构评估五问：Planner≠Workflow（动态阶段 vs 固化稳定路径）、Reasoning≠Reflection（当前轮次 vs 反馈改进）、Tool≠MCP（能力 vs 接入协议）、Memory≠聊天记录（上下文/事件日志/可复用经验）、Agent≠LLM+Prompt（还需循环/工具/状态/验证/交互）。评估一个 Agent 架构看五点：模型下一轮到底读到什么、工具调用副作用边界、失败恢复能否回到确定状态、完成判断绑定什么证据、错误是否进入下一次。

参见¶

原文存档
Harness Engineering（Harness 工程方法论）