参考:多层架构图(知乎 @时光相机)、preprints.org survey、Ranjankumar.in 七层模型、arXiv NLAH 论文、Firecrawl 成熟度框架
一、引言:为什么 Harness 是 2026 年最重要的 AI 工程概念
2026 年,AI 圈正在发生一场静默但深刻的认知转变。
过去两年,所有人的注意力都在模型本身——GPT-4、Claude 3、Gemini 的参数竞赛,多模态能力的突破,推理能力的飞跃。但一个被忽视的真相是:当基础模型能力趋于收敛时,决定 AI 应用成败的不再是模型本身,而是围绕它的"Harness"(马具/控制架)。
这张流传于知乎的架构图,用同心圆的方式揭示了一个核心事实:
"The harness is multi-layered, not a single wrapper."
(Harness 是多层的,不是一个简单的包装器。)
图片中心是一个明确标注为 "Stateless model" 的 LLM——无状态模型。这意味着 LLM 本身不记忆任何事情,每次调用都是独立的、无状态的。所有记忆、状态、工具调用、安全控制,都必须由外层的 Harness 提供。
这与 2025 年的主流认知形成了鲜明对比:那时候人们以为只要有一个强大的 LLM API,套一个简单的 prompt template,就能做出生产级应用。2026 年的工程实践已经证明,这种想法不仅天真,而且危险。
二、图片解读:三层同心圆架构
2.1 核心层:LLM(Stateless Model)
图片最核心的位置是一个大脑图标,标注为 LLM - Stateless model。
这个标注极其重要。它明确告诉我们:
- LLM 本身是无状态的
- 它不会记住之前的对话(除非你把历史塞给它的 context window)
- 它不会主动调用工具(除非你通过 prompt 或 function calling 接口让它这么做)
- 它不具备安全检查能力(除非你通过 system prompt 限制它)
换句话说,LLM 是一个纯粹的语言推理引擎,但它需要一个完整的"身体"才能在世界中行动。
2.2 第一层:Runtime(运行时)
紧邻 LLM 的第一层是 Runtime,包含四个核心模块:
| 模块 | 功能 | 为什么重要 |
|---|---|---|
| Orchestration Loop | 编排循环 | 让 LLM 从"一次性调用"变成"持续运行" |
| Output Parsing | 输出解析 | 把 LLM 的自由文本转化为结构化数据 |
| Prompt Construction | 提示词构建 | 动态组装每次调用的上下文 |
| Error Handling | 错误处理 | 当 LLM 输出无效时如何恢复 |
Orchestration Loop 是最关键的。它让系统能够:
- 接收用户请求
- 调用 LLM 生成思考/行动
- 解析输出,决定是否需要调用工具
- 执行工具,获取结果
- 将结果反馈给 LLM,继续下一步
- 重复直到任务完成
这就是 ReAct、CoT、Tool Use 等模式的基础。没有这个循环,LLM 只是一个回答问题的大脑,不是一个能完成任务的 Agent。
2.3 第二层:Capabilities(能力层)
第二层是 Capabilities,包含:
| 模块 | 功能 |
|---|---|
| Tools | 工具注册与调用 |
| Memory | 记忆存储与检索 |
| Context Management | 上下文窗口管理 |
| State Management | 状态持久化 |
这一层回答了"Agent 能做什么、记得什么"的问题。
Memory 尤其关键。因为 LLM 是无状态的,Memory 模块负责:
- 短期记忆:当前对话的历史记录
- 长期记忆:跨会话的用户偏好、知识库
- 工作记忆:任务执行过程中的中间结果
Context Management 解决的是"Lost in the Middle"问题——当上下文窗口塞满 40 个 RAG chunk 时,LLM 对中间内容的推理能力显著下降。Harness 需要智能地筛选、排序、压缩上下文,而不是简单地把所有东西塞进去。
2.4 第三层:Safety & Scale(安全与扩展层)
最外层是 Safety & Scale,包含:
| 模块 | 功能 | 生产必要性 |
|---|---|---|
| Guardrails & Safety | 安全护栏 | 防止有害输出、越狱攻击 |
| Verification Loops | 验证循环 | 确认 LLM 输出的正确性 |
| Tool Scoping | 工具作用域 | 限制 LLM 能调用的工具范围 |
| Subagent Orchestration | 子代理编排 | 协调多个 Agent 协作 |
| Prompt Loops | 提示词循环 | 迭代优化 prompt(图中标注为"Crempt Loops",应为笔误) |
这一层是生产部署的"保险丝"。
Guardrails 在输入端过滤恶意 prompt(如"Ignore all previous instructions..."),在输出端检测有害内容。
Verification Loops 是 Harness 的一个关键设计:当 LLM 生成一个结果后,不立即返回给用户,而是先经过一个验证循环——可能是另一个 LLM 作为 judge,可能是规则引擎检查,也可能是沙箱执行测试。
Tool Scoping 防止 LLM "想象"出不存在的工具。在复杂系统中,如果没有明确的工具注册表,LLM 可能会 hallucinate 出一个 API 调用,导致系统错误。
三、学术定义:六组件形式化框架
2026 年 4 月,preprints.org 上发表了一篇题为 "Agent Harness for Large Language Model Agents: A Survey" 的综述论文,首次给出了 Harness 的形式化定义:
H = (E, T, C, S, L, V)
| 组件 | 全称 | 对应图片中的层 |
|---|---|---|
| E | Execution Loop | Runtime - Orchestration Loop |
| T | Tool Registry | Capabilities - Tools |
| C | Context Manager | Capabilities - Context Management |
| S | State Store | Capabilities - Memory + State Management |
| L | Lifecycle Hooks | Safety & Scale - Guardrails, Verification |
| V | Evaluation Interface | Safety & Scale - Verification Loops |
这个六组件框架与图片中的三层架构高度对应:
- E(执行循环) ↔ Runtime
- T(工具注册表)+ C(上下文管理器)+ S(状态存储) ↔ Capabilities
- L(生命周期钩子)+ V(评估接口) ↔ Safety & Scale
论文强调:"The harness comprises six components around the model. The layer underneath them is what turns a harness into a platform."
(Harness 由围绕模型的六个组件组成。它们下面的那一层,才是把 Harness 变成平台的东西。)
四、工程实践:七层生产 Harness
Ranjankumar.in 的博客文章提出了一个更细粒度的 七层生产 Harness 模型:
Layer 1: Normalization(归一化层)
- 剥离输入噪声(尾部空格、OCR 伪影、HTML 实体)
- 检测 prompt 注入攻击
- 确保多客户端一致性(移动端和桌面端发送的请求格式一致)
没有这一层会怎样: Prompt 注入攻击、UI 元数据导致的推理失败、不同客户端行为不一致。
Layer 2: Context Orchestration(上下文编排)
- 不是"把所有东西塞进 prompt"
- 而是"精确组装当前任务所需的上下文"
- Retrieve → Filter → Rank → Compress → Assemble
没有这一层会怎样: 为模型忽略的 token 付费,重要的 token 被埋没在冗余信息中。
Layer 3: Constraint Layer(约束层)
- 定义模型能调用哪些工具
- 定义能读取/写入哪些数据
- 工具注册表 + 动作 schema + 权限模型
没有这一层会怎样: 模型"想象"出不存在的 API,成为攻击面。
Layer 4: Gated Execution(门控执行)
- 模型提议,门控决定
- 高风险操作触发人工审批
- 低风险操作运行自动化策略检查
没有这一层会怎样: 结构正确的输出造成真实世界损害(如 WHERE 子句匹配一切的 DELETE 查询)。
Layer 5: Tool Interface(工具接口)
- 工具适配器、沙箱、子生命周期管理
Layer 6: Output Validation(输出验证)
- 结构验证、语义验证、安全验证
Layer 7: State Management(状态管理)
- 检查点-恢复能力
- 跨会话记忆
- 长运行任务的容错
没有这一层会怎样: Agent 在第 14 步崩溃,从第 1 步重新开始,导致重复操作和数据损坏。
五、关键证据:Harness 如何"物质性地"改变 Agent 行为
2026 年 3 月的 arXiv 论文 "Natural-Language Agent Harnesses" 提供了关键的实验证据。
研究人员测试了一个核心问题:Harness logic 是否只是 prompt decoration(装饰),还是 behaviorally real controls(真正的行为控制)?
5.1 实验结果
在 SWE-bench Verified 基准上:
- Full IHR(完整 Intelligent Harness Runtime)相比轻量级版本,工具调用、LLM 调用和运行时间大幅增加
- 约 90% 的 token 和调用发生在委托的子 Agent 中,而非运行时拥有的父线程中
- 增加的预算反映了多阶段探索、候选比较、产物交接和额外验证
5.2 关键结论
"The trajectory-level evidence shows that Full IHR is not a prompt wrapper."
(轨迹级证据表明,完整的 IHR 不是一个 prompt 包装器。)
这意味着:
- Harness 不是 prompt engineering 的换皮
- Harness 的结构性改变(多阶段、子 Agent、验证循环) materially 改变了 Agent 的行为
- 同样的基础模型,在不同的 Harness 下,会采取完全不同的行动路径
5.3 有趣的失败模式
论文还发现了一些"对齐失败"(alignment failures):
在某些案例中,更复杂的 Harness 会让 Agent 组织得更好、花费更多,但偏离了最短的对齐修复路径。这说明 Harness 设计不是"越复杂越好",而是需要在"结构"和"灵活性"之间找到平衡。
六、成熟度框架:从 Basic 到 Adaptive
Firecrawl 的博客提出了 Harness 成熟度的三个阶段:
Level 1: Basic Harness(基础级)
- 简单的 ReAct 循环
- 少量硬编码工具
- 基础 prompt template
- 无持久记忆
特征: 能完成简单任务,遇到边缘情况就失败。
Level 2: Robust Harness(健壮级)
- 完整的错误处理
- 工具注册表和 schema 验证
- 上下文压缩和检索
- 安全检查层
- 状态检查点
特征: 能处理生产环境中的噪声和失败。
Level 3: Adaptive Harness(自适应级)
- 动态工具发现
- 自我评估和策略调整
- 多 Agent 协调
- 长期记忆和个性化
- 持续学习和优化
特征: 系统能根据任务复杂度自动调整策略,像经验丰富的工程师一样工作。
七、主流系统对比
| 系统 | Harness 特点 | 成熟度 |
|---|---|---|
| Claude Code | 五层 Prompt 组装模型,权限桥安全系统,DAG 任务调度 | Level 2-3 |
| OpenAI Agents SDK | 基于 agent loop 的编排,支持 handoffs | Level 2 |
| LangChain/LangGraph | 模块化工具链,图结构工作流 | Level 1-2 |
| AutoGPT | 早期探索,缺乏约束层和验证层 | Level 1 |
| Devin (Cognition) | 自适应 Harness,能根据任务调整策略 | Level 3 |
八、未来方向:Harness 工程的下一步
8.1 从 Prompt Engineering 到 Context Engineering
2025 年的主流是"Prompt Engineering"——如何写好一个 prompt。2026 年的共识是:当任务跨越多个 context window 时,"durable state surfaces, validation gates, and clear responsibility boundaries" 比单次 phrasing 更重要。
8.2 Harness as Code
像 Harness.io(CI/CD 平台)倡导的那样,把 prompts、evals、policies、configs 都当作代码管理,使用 semantic evaluation 和 progressive delivery(金丝雀发布)。
8.3 可迁移的 Harness
论文提出的一个愿景:Harness 逻辑应该可以在不同 runtime 之间迁移、消融(ablate)和比较。这意味着 Harness 设计本身成为一个可研究、可复现的一等对象。
8.4 LLM-in-the-Runtime
最激进的设想:把 LLM 放在 runtime 循环内部,让它读取 Harness 定义、当前状态和环境,然后选择下一步动作。这就是论文提出的 Intelligent Harness Runtime (IHR)。
九、结论
那张知乎流传的架构图,看似简单,实则揭示了一个深刻的工程真理:
LLM 是 Stateless 的。让它有用的,是 Harness。
2026 年,AI 应用竞争的焦点已经从"谁的模型更强"转向"谁的 Harness 更完善"。这不是因为模型不重要,而是因为当大家用相似的模型时,Harness 的质量决定了产品能否在生产环境中生存。
从学术定义(H = (E,T,C,S,L,V))到工程实践(七层生产 Harness),从成熟度框架(Basic → Robust → Adaptive)到实验证据(IHR 不是 prompt wrapper),Harness Engineering 正在从一个模糊的概念变成一门系统的工程学科。
对于那些还在用"一个 prompt + 一个 API 调用"做 AI 应用的团队来说,是时候升级了。马具不只是装饰——它是让马能跑、能拉、能驮的关键。
参考来源
- Agent Harness Survey - preprints.org, 2026-04-28. Manuscript 202604.0428. https://www.preprints.org/manuscript/202604.0428
- Harness Engineering: The Missing Layer - Ranjankumar.in, 2026-04-03. https://ranjankumar.in/harness-engineering-the-missing-layer-between-llms-and-production-systems
- Natural-Language Agent Harnesses - arXiv 2603.25723, 2026-03-26. https://arxiv.org/html/2603.25723v1
- What is an Agent Harness? - Firecrawl Blog, 2025-12-16. https://www.firecrawl.dev/blog/what-is-an-agent-harness
- AI Deployment in 2026: CI/CD for LLMs - Harness.io Blog, 2026-03-26. https://www.harness.io/blog/ai-deployment-in-production-orchestrate-llms-rag-agents
- 知乎:万字讲透 Agent Harness 的十二大模块 - 2026-04-19. https://zhuanlan.zhihu.com/p/2029220210800883392
- 知乎:Harness 到底是什么?四层拆解 - 2026-04-05. https://zhuanlan.zhihu.com/p/2024269041427072886
- 知乎:从驯马到造车:Harness Engineering 将如何定义下一代 AI 应用 - 2026-04-09. https://zhuanlan.zhihu.com/p/2025494331763499483
#AgentHarness #AI工程 #LLM架构 #深度研究 #2026
讨论回复
0 条回复还没有人回复,快来发表你的看法吧!
推荐
智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用,智谱新一代旗舰模型 GLM-5 已上线,在推理、代码、智能体综合能力达到开源模型 SOTA 水平。