你是否有过这样的经历：已经搭建好了一个Agent，甚至还接上了ReAct循环和几个工具。演示时一切正常，但一到生产环境就崩了——模型会忘记三步之前做了什么，工具调用静默失败，上下文窗口塞满了垃圾数据。
问题的根源，往往不在模型本身，而在模型周围的一切。
实验数据可以证明这一点：有研究仅通过改变包裹LLM的基础设施（使用完全相同的模型和权重），就在TerminalBench 2.0上的排名从30名开外跃升至第5名。另一项研究通过让LLM优化基础设施本身，达到了76.4%的通过率，甚至超越了人工设计的系统。
这项至关重要的基础设施环境，就是 Agent Harness。
什么是 Agent Harness？
这个术语在2024年初被正式提出，但概念早已存在。Harness是包裹LLM的完整软件基础设施，它包含了：编排循环、工具、内存、上下文管理、状态持久化、错误处理和安全护栏。
Anthropic的Claude Code文档说得很直接：其SDK就是“驱动Claude Code的agent harness”。OpenAI的Codex团队也使用了相同的框架，明确将“agent”和“harness”等同起来，指的都是使LLM有用的那部分非模型基础设施。
LangChain的开发者Vivek Trivedy提出了一个经典公式：
“如果你不是模型，那你就是harness。”
这里有一个重要的概念区分。“Agent”是一种涌现行为：它是用户感知到的那个具有目标导向、能够自我纠正的实体。而“Harness”是产生这种行为的机制。当有人说“我构建了一个agent”，通常意味着他们构建了一个harness并为其连接了一个模型。
Beren Millidge在2023年的论文“Scaffolded LLMs as Natural Language Computers”中做了一个精确的比喻：
- 原始LLM = 没有RAM、没有磁盘、没有I/O的CPU
- 上下文窗口 = RAM（快速但有限）
- 外部数据库 = 磁盘存储（大容量但慢）
- 工具集成 = 设备驱动程序
- Harness = 操作系统
正如Millidge所写：“我们重新发明了冯·诺依曼架构”——因为这是任何计算系统的自然抽象。
环绕模型的三层工程实践
围绕模型，我们可以构建三层同心圆工程：
- Prompt工程：精心设计模型接收的指令。
- 上下文工程：管理模型在何时看到什么内容。
- Harness工程：包含前两者，再加上整个应用基础设施：工具编排、状态持久化、错误恢复、验证循环、安全执行和生命周期管理。
Harness不是一个简单的prompt包装器，它是使自主智能体行为成为可能的完整系统。
生产级 Harness 的12个核心组件
综合Anthropic、OpenAI、LangChain和更广泛的实践，一个生产级Agent Harness通常包含以下12个独特组件：
1. 编排循环（Orchestration Loop）
这是智能体的心跳。它实现了思维-行动-观察（TAO）循环，也就是我们熟知的ReAct循环。循环流程通常是：组装prompt → 调用LLM → 解析输出 → 执行工具调用 → 反馈结果 → 重复直到完成。机械上，它往往就是一个while循环。复杂性不在于循环本身，而在于循环所管理的一切。
工具是智能体的“双手”。它们被定义成模式（名称、描述、参数类型）注入到LLM的上下文中。工具层负责注册、模式验证、参数提取、沙箱执行、结果捕获和格式化为LLM可读的观察结果。
3. 内存（Memory）
内存在多个时间尺度上运作。短期内存是单个会话内的对话历史。长期内存则跨会话持久化。一个关键设计原则是：智能体应该将自己的内存视为“提示”，并在行动前验证其实际状态。
4. 上下文管理（Context Management）
这是许多智能体静默失败的地方。核心问题是上下文腐烂（Context Rot）：当关键内容落在窗口的中间位置时，模型性能会显著下降。生产级策略包括：
- 压缩：接近限制时总结对话历史。
- 观察屏蔽：隐藏旧的工具输出，但保持工具调用可见。
- 即时检索：维护轻量级标识符，按需动态加载详细数据。
- 子智能体委托：让子智能体广泛探索，但只返回压缩摘要。
5. Prompt构建（Prompt Construction）
这负责组装模型在每一步实际看到的内容。它是分层的：系统提示、工具定义、内存文件、对话历史和当前用户消息。重要上下文应放在prompt的开头和结尾。
6. 输出解析（Output Parsing）
现代harness依赖原生工具调用，模型返回结构化的tool_calls对象，而不是需要费力解析的自由文本。
7. 状态管理（State Management）
管理智能体在不同步骤间的状态。不同的框架有不同实现，例如使用类型化字典流经图节点，或用git提交作为检查点。
8. 错误处理（Error Handling）
这非常关键：一个10步的流程，即使每步成功率高达99%，端到端的成功率也只有约90.4%。错误会快速累积。成熟的harness会区分瞬态错误、LLM可恢复错误、用户可修复错误和意外错误，并采取相应策略。
9. 护栏和安全（Guardrails and Safety）
通常实现多层防护：输入护栏、输出护栏和工具护栏。“绊线”机制在触发时会立即停止智能体。核心思想是在架构上分离“决策”（模型）和“执行”（工具系统）的权限。
10. 验证循环（Verification Loops）
这是玩具演示和生产智能体的关键区别。主要方法包括：基于规则的反馈（测试、linter）、视觉反馈（屏幕截图）以及使用单独的LLM作为裁判进行评估。
11. 子智能体编排（Subagent Orchestration）
用于处理复杂任务，支持不同的执行模型，如Fork（创建副本）、Teammate（独立进程通信）或Worktree（独立代码分支）。
12. Sandbox环境
为智能体提供安全的环境来运行代码、操作文件、安装依赖，通常具备命令白名单、网络隔离等特性。
核心循环如何运作：步骤详解
了解组件后，让我们追踪一个典型的harness循环周期：
步骤1（Prompt组装）：Harness构建完整输入，将系统提示、工具、内存、历史对话和当前消息组合起来。
步骤2（LLM推理）：组装好的prompt被发送到模型API。模型生成输出，可能是文本、工具调用请求或两者皆有。
步骤3（输出分类）：Harness解析输出。如果只有文本无工具调用，则循环结束；如果有工具调用，则继续执行；如果请求交接给子智能体，则更新上下文并重新开始。
步骤4（工具执行）：对每个工具调用，验证参数、检查权限、在沙箱中执行并捕获结果。只读操作可并发，变更操作需串行。
步骤5（结果打包）：工具结果（或错误）被格式化为LLM可读的消息，以便模型进行自我纠正。
步骤6（上下文更新）：结果被追加到对话历史。如果接近上下文窗口限制，则触发压缩策略。
步骤7（循环）：返回步骤1，开始新一轮，直到满足终止条件（如无工具调用、达到轮次上限、安全护栏触发等）。
对于超长任务，Anthropic开发了两阶段“Ralph Loop”模式，利用文件系统和版本控制（如Git）来维持跨多个上下文窗口的任务连续性。
模型与Harness的共同进化
一个关键洞见是：Harness（脚手架）在建筑完成后应该被移除。随着模型能力的进化，harness的复杂性应该降低。例如，复杂的工具定义可能退化为通用的Shell执行器，复杂的规划模块可能被模型内化的能力所取代。
Harness设计的“未来验证测试”：如果系统的性能随着更强大模型的引入而提升，同时harness本身并未变得更复杂，那么这个设计就是合理的。反之，则说明harness可能做了本应由模型完成的工作。
Harness工程就是产品竞争力
使用相同底层模型的两个产品，可能因为harness设计的优劣而产生截然不同的性能表现。TerminalBench的排名变化已经清楚地证明：仅仅改变harness就能带来巨大的性能跃迁。
Harness不是已解决的问题，而是当前艰难工程的核心所在：
- 将有限的上下文作为稀缺资源进行精细化管理。
- 设计能在错误累积成灾难前将其捕获的验证循环。
- 构建能提供任务连续性同时又避免幻觉的内存系统。
- 在“为模型构建多少脚手架”和“相信模型多少能力”之间做出明智的架构权衡。
随着模型快速改进，该领域正朝着更薄、更简单的harness方向发展。但harness本身不会消失。即使是最有能力的模型，仍然需要基础设施来管理其上下文、执行工具、持久化状态和验证工作成果。
所以，下次当你的智能体失败时，别急着责怪模型。先仔细看看包裹它的Harness。 更多关于人工智能和系统架构的深度讨论，欢迎访问云栈社区与其他开发者交流。
发表于 2 小时前
|
查看: 3|
回复: 0
