Agent harness：藏在大模型背后的“操作系统”

URL: https://mp.weixin.qq.com/s/GozWb4Kl3RE_joua0H-xFg

大模型决定智能体的上限，而“Harness”则决定其下限与可靠性。当智能体在真实场景中频频“翻车”时，问题往往不在于模型本身，而在于包裹它的那套基础设施。在过去的两年里，构建一个能聊天的AI应用已非难事。许多人甚至通过简单的ReAct循环和几行工具调用代码，就搭建出一个“智能体”。这些程序在精心准备的演示中往往表现亮眼，然而一旦试图将其推向真实生产环境，各种问题便接踵而至：• 模型在几次步骤之后便“忘记”了自己之前的决策依据• 工具调用在后台悄无声息地失败，程序却毫无察觉• 模型的上下文窗口很快被大量冗余、无用的信息填满，导致性能直线下降问题的根源，往往不是模型不够强，而是“包围”模型的那整套系统工程出了问题LangChain团队在一次实验中，仅更换了包裹其大语言模型（LLM）的基础设施代码，而保持模型权重完全不变，其智能体在TerminalBench 2.0基准测试中的排名便从30名开外跃升至第5名。另一项独立研究则显示，通过让另一个大模型来优化这套基础设施，其任务通过率达到了76.4%，超越了所有人工设计的系统。这套至关重要的基础设施，如今有了一个正式的名字 —— Agent Harness什么是 Agent Harness“Agent Harness”这一术语在2026年初被正式提出，但其核心概念早已存在。简单来说，Harness是包裹在大语言模型周围的完整软件基础设施。它包含：编排循环、工具调用、记忆系统、上下文管理、状态持久化、错误处理以及安全护栏。如果把“智能体”（Agent）看作是用户所感知到的那个能够自主设定目标、使用工具、自我修正的智能行为，那么Harness就是制造出这一切行为的后台机器。一个形象的类比是：一个原始的、未经封装的大模型，好比一块没有操作系统的中央处理器（CPU）。而Agent Harness，就是让它变得真正有用的操作系统。• 上下文窗口 = 内存（RAM），快速但容量有限。• 外部数据库 = 硬盘，存储量大但访问速度慢。• 工具集成 = 设备驱动程序，让模型能与外部世界交互。• Harness = 操作系统，统一管理和调度所有资源。围绕模型的“三层工程”为了构建一个可靠的智能体，我们需要在三个层面上进行系统工程：1. 提示词工程（Prompt Engineering）：设计模型接收的指令。2. 上下文工程（Context Engineering）：管理模型在每个步骤能“看到”哪些信息。3. Harness工程（Harness Engineering）：这是前两者的总和，再加上完整的应用基础设施，包括工具编排、状态持久化、错误恢复、验证循环、安全机制和生命周期管理。Harness核心组件编排循环：智能体的“心跳”这是整个系统的核心引擎，它实现了“思考-行动-观察”（Thought-Action-Observation, TAO）的循环，也就是我们常说的ReAct循环。其机械逻辑极其简单，通常就是一个while循环。真正的复杂性体现在它管理的一切：工具（Tools）• 工具被定义为结构化模式（包含名称、描述、参数类型），并注入到LLM的上下文中。• Harness负责工具的注册、参数验证、沙盒执行、结果捕获，并将结果格式化为模型可读的观察信息。例如，Anthropic的Claude Code提供了文件操作、搜索、代码执行等六大类工具；OpenAI的智能体软件开发工具包（SDK）则提供了网页搜索、代码解释器等托管工具。记忆（Memory）• 短期记忆：单次会话中的对话历史。• 长期记忆：跨会话持久化的信息。关键设计原则：智能体必须将记忆视为“线索”，并在执行关键操作前通过实际状态进行验证，以避免被过时或错误的信息误导。例如，Claude Code采用三层记忆层级：轻量级索引（常驻内存）、按需加载的详细主题文件、以及仅通过搜索访问的原始对话记录。上下文管理（Context Management）这是许多智能体“无声失败”的根源。核心问题是 “上下文衰减”：当关键信息位于提示词的中段位置时，模型性能会下降30%以上，这就是著名的“迷失在中间”（Lost in the Middle）现象。即便拥有百万token的上下文窗口，随着内容增长，模型遵循指令的能力也会持续衰减。生产环境下的应对策略包括：• 压缩（Compaction）：当接近上下文窗口限制时，对历史对话进行总结，保留架构决策等关键信息，丢弃冗余的工具输出。• 观察掩码（Observation Masking）：隐藏旧的工具输出，只保留工具调用记录。• 按需检索（Just-in-time Retrieval）：不加载完整文件，而是动态地、有针对性地读取所需数据。• 子智能体委派（Sub-agent Delegation）：让专门的子智能体去探索，并返回摘要（通常1000-2000 token）提示词构建（Prompt Construction）这定义了模型在每个步骤实际看到的内容：系统提示，工具定义，记忆文件，对话历史和当前用户消息。OpenAI 的 Codex 使用严格的优先级堆栈：服务器控制的系统消息（优先级最高）、工具定义、开发者指令、用户指令（如 AGENTS.md 文件），然后是对话历史输出结构化（Output Parsing）Harness 依赖原生的工具调用，即模型返回结构化的tool_calls对象，而非需要手动解析的文本，然后框架会检查：是否存在工具调用？如果有则执行并循环；否则生成最终答案。对于结构化输出，OpenAI 和 LangChain 都支持通过 Pydantic 模型约束响应的模式。传统的如 RetryWithErrorOutputParser等方案仍可用于边缘情况。状态、错误处理与安全状态管理：LangGraph将状态建模为类型化的字典，通过图节点传递。Claude Code则使用git提交作为检查点，文件作为结构化草稿。错误恢复：在一个10步的流程中，即使每一步的成功率高达99%，最终的整体成功率也仅有约90.4%。错误会迅速累积。成熟的Harness能区分四种错误类型：瞬时错误（自动重试）、可恢复错误（作为消息返回给模型，让其自行调整）、需人工介入错误、以及致命错误（中断调试）。安全护栏：OpenAI的SDK实现了三层护栏：输入护栏、输出护栏和工具护栏，并设有“触发线”机制，可在必要时立即终止智能体。Anthropic则采用“模型决定做什么，工具系统决定被允许做什么”的架构分离理念，实现了细粒度的权限控制。验证循环这是区分 demo 和生产级 Agent 的关键。Anthropic 推荐三种方法：基于规则的反馈（测试、静态分析工具、类型检查器）、视觉反馈（截取任意 UI 任务截图）、LLM裁判（用一个独立的子 Agent 评估输出）。Claude Code 的创建者指出，让模型能够验证自身工作可将质量提升2-3倍。子代理编排（Subagent Orchestratoin）Claude Code 支持三种执行模型：派生（子 Agent继承父 Agent 上下文），队友（独立 Agent，相互之间基于文件通信），工作树（独立的 Git 工作树，每个 Agent 有隔离的分支）。OpenAI 的 SDK 支持将 Agent 作为工具调用，即一个主 Agent 处理有限个子 Agent。LangGraph 则将子 Agent 实现为一个有状态的嵌套图。Harness的工作流程一个完整的智能体循环通常遵循以下步骤：提示词组装：Harness构建完整的输入，包括系统提示、工具定义、记忆内容、对话历史和当前用户消息。为规避“迷失在中间”问题，重要信息会被放在开头和结尾。模型推理：将组装好的提示发送给模型应用程序接口（API），模型生成文本或工具调用请求。输出分类：若无工具调用，则循环结束；若有，则进入执行阶段。工具执行：验证参数、检查权限、在沙盒中执行并捕获结果。只读操作可并行，修改操作串行。结果封装：将工具结果格式化为模型可读的消息，错误也被封装返回，让模型有机会自我修正。上下文更新：将结果追加到对话历史，并在必要时触发压缩。循环：返回第1步，直到满足终止条件（如无工具调用、达到最大轮次、用户中断等）。主流Harness框架的实现虽然各大框架的核心模式趋于一致，但其设计哲学各有侧重。Anthropic（Claude Code）采用“收集-行动-验证”（Gather-Act-Verify）循环。其SDK通过一个简单的query()函数开启智能体循环。Harness本身是一个“无脑循环”，所有智能都归属于模型。它定期删除Harness中的计划步骤，因为新模型已内化了这些能力。OpenAI（Agents SDK）强调“代码优先”，工作流逻辑用原生Python表达。其Codex Harness采用三层架构：核心层、应用服务器层和客户端层，所有客户端共享同一个Harness。LangChain（LangGraph）将Harness建模为一个显式的状态图，由llm_call和tool_node两个节点通过条件边连接。它从早期的AgentExecutor演进而来，解决了扩展性和多智能体支持的不足。CrewAI实现基于角色的多智能体架构，包含智能体（Harness+LLM+工具）、任务和团队（Crew）三个核心概念AutoGen开创了对话驱动的编排模式，支持顺序、并发、群聊、移交和“磁力”（由管理者协调）五种编排模式。关键架构决策权衡在实践中，工程师需要权衡以下几个关键点：1. 单智能体 vs 多智能体：优先最大化单智能体的能力。多智能体系统会引入额外的开销和上下文丢失风险。仅在工具超过10个或存在明显不同的任务领域时，才考虑拆分。2. ReAct vs 计划-执行：ReAct灵活但步骤成本高；“计划-执行”模式将规划与执行分离，LLMCompiler报告称其速度比顺序ReAct快3.6倍。3. 上下文窗口管理：权衡五种主要方法：基于时间清理、对话总结、观察掩码、结构化笔记和子智能体委派。研究表明，优先保留推理痕迹而非原始工具输出，可减少26%-54%的token消耗，同时保持95%以上的准确率。4. 验证循环：“计算验证”（如测试）提供确定性反馈；“推理验证”（如LLM作为评判者）捕捉语义问题但会增加延迟。理想的架构应同时包含“引导”（前馈）和“感知”（反馈）机制。5. 权限与安全：在“宽松”（快速但风险高）和“严格”（安全但流程慢）之间做出选择，这完全取决于部署场景。6. 工具范围：工具越多，表现越差。核心原则是：仅暴露当前步骤所需的最小工具集。7. Harness的“厚度”：这是最根本的哲学分歧：是将更多逻辑构建在Harness中，还是留给模型？Anthropic押注于“薄”Harness和更强大的模型；而基于图的框架则押注于明确的流程控制。Harness即产品两个使用完全相同模型的产品，可以仅仅因为Harness的设计不同，而表现出天壤之别的性能。TerminalBench的证据非常清晰：仅改变Harness，就能让智能体的排名提升20多位。Agent Harness并非一个已解决问题或是成熟的层级，恰恰相反，它是 当今AI工程领域最核心的挑战。它关乎如何将上下文作为稀缺资源管理，如何设计验证循环以阻止错误蔓延，如何构建无幻觉的记忆系统，以及如何做出关于未来“脚手架”厚度的关键架构决策。虽然随着模型的持续进化，Harness正不可避免地变得越来越“薄”，但只要模型还需要被管理、被赋予工具、被验证，那么Harness本身就不会消失。当下一次你的智能体失败时，或许不应归咎于模型，而是审视一下它的Harness。本文整理自 @akshay_pachaarhttps://x.com/akshay_pachaar/status/2041146899319971922