面向2026，AI Agent Harness 最小化设计指南与实践思考

2026年AI Agent领域最热门的词汇无疑是“Harness”。打开行业社群、技术博客随处可见“今天你Harness了吗”的调侃与讨论但热闹背后是对这个概念的普遍误解与滥用。过去两三年AI Agent领域迎来爆发式增长各式各样的框架、脚手架、编排工具如雨后春笋般涌现可大多陷入技术债的泥潭热闹一阵后便销声匿迹。很多开发者急于追赶潮流盲目堆砌组件、封装复杂逻辑却忽略了一个核心问题一个能适配未来模型迭代、真正实用的Agent Harness到底需要哪些核心能力它不是越复杂越好反而需要极致的克制与极简的设计。本文不聊宏大的Harness Engineering概念也不陷入繁杂的术语纷争只聚焦Harness本身用通俗易懂的语言拆解其核心逻辑、组件构成与设计原则帮你摆脱过去两年积累的技术债理解如何设计或选择一个面向2026的最小化Agent Harness。毕竟在AI Agent的世界里做好底层底座模型才能完成剩下的所有事。正本清源Harness到底是什么不是什么要设计好Harness首先要搞懂它的本质。很多人将其与Agent框架、运行时混为一谈甚至把各种复杂功能都塞进Harness最终导致系统臃肿、难以维护。要理清这个概念我们可以先做一次简单的赛博考古看看Harness的起源与演变。在传统软件工程中Test Harness测试自动化框架指的是为执行测试而建立的自动化环境核心目标是“去人工化”让测试流程能够自动运行、自动反馈结果。而在LLM大语言模型和Agent领域Harness的含义经历了一个明显的演变过程。最初Harness主要用于LLM评测场景。比如在SWE-bench等复杂评测基准中单纯的LLM很难拿到高分需要一套外置的循环和工具来辅助测试此时的Harness仅局限于评估领域功能相对单一。这种情况直到Claude-Code等应用出现后才发生改变Agent Harness逐渐被赋予了新的含义支撑AI Agent稳定工作的底层底座。目前能找到的最早系统阐述“agent harness”的文献来自2025年9月23日开发者Vivek Trivedy的博客他将其定义为“增强模型运行时执行能力的外部功能集合”。而Harness的真正爆火离不开两大巨头的推动2025年11月26日Anthropic发布的《Effective harnesses for long-running agents》以及2026年2月11日OpenAI发布的《Harness engineering: leveraging Codex in an agent-first world》。这两篇文章明确了Harness在Agent系统中的核心地位也让更多开发者开始关注这一领域。用一句话就能说清Harness的本质它就是包裹在LLM外面的软件外壳。LLM本身只是一个会“说话”的模型能理解自然语言、输出文本但无法直接与外部环境交互、完成具体任务。而Harness的作用就是把这个“只会说话”的模型变成一个“能做事”的Agent甚至是能持续运行数小时的long-running Agent长期运行Agent。这里必须区分三个容易混淆的概念Agent Frameworks框架、Runtimes运行时和Harnesses底座很多人正是因为分不清这三者才导致设计出的系统混乱不堪。结合LangChain官方文章的解读我们可以用最通俗的语言讲明白它们的区别运行时Runtime解决的是“Agent怎么在生产环境中稳定、持久地跑起来”的问题是底层的基础设施相当于Agent的“地基”负责处理进程管理、资源分配、错误恢复等底层逻辑框架Framework提供一套抽象和编程模型帮开发者“更容易地编写Agent应用”相当于Agent的“脚手架”减少重复编码规范开发流程而Harness则是在框架之上加上默认配置、常用工具和标准化工作流做成“拿来就能跑任务的高层套件”相当于Agent的“成品外壳”开发者不需要从零搭建只需根据需求微调就能让Agent投入使用。需要明确的是这些概念都是人为定义的是先有了具体的技术实现才有了对应的概念命名。我们不必纠结于术语的严谨性核心是理解Harness的定位它是衔接LLM与实际任务的桥梁是让模型“落地做事”的关键而非一个堆砌功能的容器。设计哲学Less is More与未来模型能力共生设计Harness的核心哲学来自两篇经典文章的启示《How To Be A World-Class Agentic Engineer》和《Learning the Bitter Lesson》。这两篇文章总结的核心经验的就是“Less is More”少即是多。在AI Agent领域各种人为加入的结构、逻辑或偏置虽然短期内能提升Agent的表现却会在长期成为限制随着模型能力的提升这些人工设计的部分终将被淘汰。《The Bitter Lesson》在Agent领域的推论尤为值得深思在Harness中写的每一行“聪明”的控制逻辑都是在和未来的模型能力对赌。我们可以回顾过去两年的技术迭代就能明白这个推论的正确性2024年很多开发者花费大量精力编写精巧的ReAct状态机用于控制Agent的工具调用流程可到了2025年模型原生支持多轮工具调用那些复杂的状态机反而成了负担不仅占用资源还限制了模型能力的发挥2025年不少团队投入人力开发复杂的Planning规划模块帮Agent梳理任务流程、拆分步骤可到了2026年模型的推理能力大幅提升已经能够自主完成规划那些人工编写的Planner反而成了Agent能力的天花板无法充分发挥模型的潜力。这并不是说不需要Harness而是说Harness的设计必须保持克制。每个组件在加入前都应该问自己一个问题“这个东西模型自己能不能学会”如果答案是“迟早能”那这个组件就是辅助组件写的时候就要预留拆除的口子不能与核心逻辑深度耦合如果答案是“不可能”因为它涉及的是LLM外部的物理世界或系统级能力无法通过模型迭代学会那这个组件才是核心组件必须保留且做好优化。换句话说极简的、最小化必要的组件才是一个能扛住未来3-6个月模型迭代的Harness的核心。尤其是以“long-running”长期运行为目标的Harness更需要区分核心组件与辅助组件避免被短期需求绑架陷入技术债的陷阱。具体来说面向long-running的Harness组件可以清晰地划分为两类一类是不可替代的核心组件包括Agent Loop、Context管理、原子化工具、File System、Subagent和Hooks另一类是短期内的补丁属于辅助组件随着模型能力的提升终将被取代。接下来我们重点拆解这些核心组件搞懂它们的作用、设计逻辑与实践方法。核心组件拆解一个最小化Harness的必备能力一个最小化的Agent Harness不需要复杂的功能堆砌只要做好以下6个核心组件就能支撑Agent稳定运行、适配未来模型迭代。这些组件相互配合、各司其职构成了Harness的核心骨架。一、Agent LoopAgent的核心运行循环所有关于Agent的故事都始于Agent Loop代理循环。一个好的Agent Loop必然是极其简洁的核心原则是“由LLM主导决策而非人为预设路径”。因为LLM的本质是一个预测下一个Token的自回归模型这个基本盘在长远来看不会改变Agent Loop的作用只是辅助这个过程持续下去而不是替代模型做决策。从最底层的逻辑来看Agent Loop的核心流程只有四步执行工具、捕获结果、追加上下文、再次调用LLM。这个循环不断重复直到Agent完成任务或停止运行。我们可以通过一段简单的代码直观理解Agent Loop的核心逻辑来自learn-claude-codedefagent_loop(query):messages[{role:user,content:query}]whileTrue:responseclient.messages.create(modelMODEL,systemSYSTEM,messagesmessages,toolsTOOLS,max_tokens8000,)messages.append({role:assistant,content:response.content})ifresponse.stop_reason!tool_use:returnresults[]forblockinresponse.content:ifblock.typetool_use:outputrun_bash(block.input[command])results.append({type:tool_result,tool_use_id:block.id,content:output,})messages.append({role:user,content:results})这段代码就是Agent Loop的核心实现接收用户查询后调用LLM生成响应如果响应是工具调用就执行对应的工具并捕获结果将结果追加上下文后再次调用LLM如果响应不是工具调用就返回结果循环结束。这里需要注意的是所有的“智能”都来自LLM预测下一个Token时的内在推理Harness只是把工具调用的结果喂回给模型让这个推理过程能够持续下去。Agent Loop不需要复杂的控制逻辑越简洁越能适配未来模型能力的提升。当然从工程实践和生产级应用的角度来看Agent Loop虽然本质上是这个while-true循环但需要增加大量的防御机制来提升韧性。据非官方流出的Claude-code源码分析其queryLoopsrc/query.ts:241围绕核心循环构建了超过1700行的防御层这些防御机制包括Streaming处理支持实时输出提升用户体验避免长时间等待权限检查限制Agent的操作范围防止越权行为保障系统安全Tool格式处理与校验确保模型输出的工具调用格式正确避免解析错误错误恢复当工具调用失败、模型响应异常时能够自动重试或降级处理保证循环不中断除此之外还有超时控制、日志记录、资源限制等防御机制这些都是生产级Harness不可或缺的但它们都属于“辅助优化”没有改变Agent Loop的核心逻辑。二、Context管理解决Agent的“记忆难题”过去半年多“Context Engineering”上下文工程这个词开始频繁出现在Agent领域。它不是简单的Prompt调优而是解决一个更根本的矛盾不断累加的消息与LLM有限的上下文长度、注意力之间的矛盾。在long-running状态下Agent会持续调用工具、生成结果这些内容不断追加到上下文的消息列表中最终会导致两个严重问题一是Context溢出超出LLM上下文窗口的物理上界导致模型无法处理二是Context Rot即使消息没有超出上下文窗口过多的无效信息、中间过程也会污染上下文严重干扰模型的推理导致Agent决策失误。因此优秀的Harness必须具备强大的Context管理能力其核心目标不是简单地拼接、修剪Prompt而是在保证信息完整度、KV-cache命中率和Token成本之间找到最优解。KV-cache是LLM加速推理的关键机制缓存命中率越高推理速度越快、成本越低而Context管理的核心就是在不影响模型推理的前提下优化缓存使用、控制Token消耗。结合Claude Code、OpenAI Codex等主流Harness的实践Context管理主要有四种核心方式每种方式都有其适用场景可根据实际需求组合使用。第一种是Microcompact微压缩主要用于处理前几轮工具调用产生的中间结果。这些中间结果大多是临时的、非关键的保留下来只会占用上下文空间、降低缓存命中率因此需要针对性压缩。据Claude Code源码分析它主要采用两种处理方式Time-based Microcompact基于时间的微压缩当用户离开一段时间后回来服务端的Prompt缓存已经过期此时无需保护缓存直接构造新的消息对象替换旧的工具结果内容既能释放上下文空间又不影响后续推理Cached Microcompact上下文编辑微压缩在缓存存活期间不能直接替换消息内容否则会破坏缓存而是通过Anthropic API的Context editing机制在API层面删除指定工具的tool_result实现无损压缩。第二种是Summary、Compact、Auto-Compact摘要压缩当手动或自动触发阈值时比如上下文Token数达到设定上限Harness会调用LLM根据现有的上下文生成总结和摘要并用摘要替换掉之前的上下文从而大幅减少Token消耗。以Claude Code为例其生成的摘要必须包含以下9个部分确保关键信息不丢失Primary Request and Intent主要请求和意图Key Technical Concepts关键技术概念Files and Code Sections文件和代码段Errors and fixes错误和修复Problem Solving问题解决过程All user messages所有用户消息Pending Tasks待处理任务Current Work当前工作进度Optional Next Step可选下一步。不同模型的API设计不同摘要压缩的方式也略有差异。Anthropic Claude API中系统提示词与消息是独立的因此可以采用“完全summary”模式把历史消息整体替换为摘要而OpenAI的Codex则采用“初始上下文最近用户消息最多20k tokens摘要”的分层模式兼顾缓存命中率和信息完整性。第三种是Offload卸载与摘要压缩的“有损压缩”不同Offload是“无损压缩”。它利用File System文件系统将上下文内容写入文件中永久保存然后释放对应的上下文窗口空间在后续需要时再按需加载。这种方式适合保存那些关键的、不能丢失的上下文信息既能控制当前上下文的Token数又能保证信息的完整性。第四种是Isolation隔离对于存在大量工具调用和探索过程的复杂任务将大任务拆解成多个小任务分别由Subagent子代理完成从而实现上下文的独立和隔离避免不同任务的中间过程相互污染提升模型推理的准确性。总结来说Context管理的核心是“取舍”在信息完整、缓存高效、成本可控之间找到平衡既不让Agent“忘记关键信息”也不让无效信息占用过多资源。三、原子化工具Agent的“基础能力库”很多开发者在设计Harness时会陷入一个误区工具越多越好认为提供的工具越全面Agent的能力就越强。但实际上过多的工具不仅会降低Agent的调用准确率还会占用宝贵的上下文空间导致Context Rot反而影响Agent的表现。严格来说LLM所谓的“tool-using”使用工具并不是真正在“使用工具”。模型本身只是在输出一种特殊格式的工具调用文本真正的工具执行是由Harness去解析这些文本后转化为对外部环境的真实调用。因此工具的质量远比数量重要一个优秀的工具层应该具备四个核心特质原子性、正交性、完备性、可组合性。原子性每个工具只做一件明确的事不做多余的功能封装。比如“读取文件”和“写入文件”应该是两个独立的工具而不是一个“文件操作”工具包含多种功能正交性不同工具的功能互不重叠避免重复封装。比如“正则处理”工具和“文本编辑”工具功能边界清晰不会出现一个操作可以用多个工具完成的情况完备性基础工具能够覆盖Agent的核心需求通过组合可以实现复杂功能。不需要追求“大而全”但要保证“小而精”可组合性工具之间可以自由组合通过简单工具的叠加实现复杂的任务流程。比如“读取文件”“正则处理”“写入文件”可以完成文件内容的提取与修改。换句话说工具层应该尽可能“原语化”每个工具都是一个基础的“操作单元”这些单元可以自由组合从而构建出复杂的行为。无论是Manus的三层工具设计还是Anthropic提出的tool-search-tool与programmatic tool calling背后的核心逻辑都是一致的找到Agent最容易理解、最容易稳定调用的“原生工具”。所谓原生工具不是工程师为了业务方便封装出的高度特化接口而是那些模型更熟悉、在训练数据中出现频率极高、更容易进入agentic RL训练分布的工具形式。简单来说就是“模型天生就会用”的工具。在这一点上行业内已经形成了一个共识bash is all you needBash就足够了。像Bash、文件读写、文本编辑、正则处理这类底层能力本来就是Linux和软件工程世界中最常见的操作接口在LLM的训练数据中出现频率极高模型对其理解程度远超那些人为定义、语义暧昧、接口风格各异的自定义工具。举个例子一个自定义的“代码格式化”工具需要模型理解该工具的接口参数、返回格式还要记住工具的功能定位而如果直接使用Bash中的fmt命令模型凭借训练数据中的知识就能轻松调用无需额外学习。因此与其为Agent提供几百个高度特化的第三方插件不如优先提供少量稳定、低层、可组合的基础能力这才是提升Agent工具调用效率的关键。四、File SystemAgent的“记忆与工作台”在Agent系统中File System文件系统的意义远不只是“保存文件”那么简单。它是Agent的“工作记忆”“执行环境”和“隔离边界”是Harness中不可或缺的核心组件尤其对于coding agent代码代理这类场景文件系统更是核心中的核心。首先文件系统是Agent的“工作记忆”。Agent在执行长期任务时会产生大量的中间结果、任务计划、草稿、观察记录这些内容如果只保存在上下文窗口中不仅会占用大量Token还会随着上下文压缩而丢失。而文件系统可以将这些信息持久化下来相当于Agent的“笔记本”需要时可以随时读取、修改避免信息丢失。这也正是上文中提到的Context Offload上下文卸载的核心依托。其次文件系统是Agent的“执行环境”。尤其在coding agent场景下代码、配置文件、日志、测试输出、脚本和文档本来就是围绕文件来组织的。Agent要编写代码就需要读取现有文件、写入新文件要运行测试就需要执行文件中的脚本要排查错误就需要查看日志文件。相比额外发明一套新的记忆接口或工具抽象直接为Agent提供read、write、edit等基础文件操作更符合Agent的使用习惯也更贴近操作系统级的真实工作流。最后文件系统是Agent的“隔离边界”。通过受控目录、虚拟文件系统或沙箱环境可以限制Agent的操作范围与权限防止Agent误操作、越权访问保障系统安全。比如为Agent分配一个独立的沙箱目录Agent只能在该目录内进行文件操作无法访问系统的核心目录和敏感文件从而降低安全风险。在《Everything is Context: Agentic File System Abstraction for Context Engineering》一文中作者借用了Unix哲学中的“Everything is a file”一切皆文件理念将其应用到Agent的文件系统设计中。无论是Agent的上下文、任务计划、记忆还是外部环境的状态都可以以文件的形式存储和访问这种设计既符合极简哲学又能让Agent的操作更统一、更高效。总结来说文件系统在Harness中承担着“记忆存储、环境支撑、安全隔离”三大核心角色是Agent能够长期稳定运行的基础。一个优秀的Harness必然会对文件系统进行精心设计而非简单地复用系统自带的文件功能。五、SubagentAgent的“分身与协作伙伴”Subagent子代理最初是为了解决Context Isolation上下文隔离的问题后来逐渐演化为一种任务调度与多Agent协作的基本单元。在复杂任务中主Agent的上下文是非常宝贵的资源而像搜索大型代码库、运行测试、排查错误、做长时间分析这类任务往往会产生大量的过程性噪音如果把这些中间过程全部塞进主对话不仅会污染主线上下文还会降低后续推理和决策的质量。因此一个自然的解决方案是spawn生成一个Subagent让它在独立的上下文中完成这些“脏活累活”。主Agent不需要关注Subagent的完整执行过程只需要接收Subagent返回的总结性结果再将这段结果作为tool_result写回自己的上下文。从主Agent的视角来看它只是调用了一个高阶工具AgentTool并没有改变核心的queryLoop结构。举个例子主Agent需要完成一个“代码重构”任务其中包含“搜索代码库中的重复代码”“分析重复代码的优化方案”“运行测试验证优化效果”三个子任务。如果主Agent自己完成这些任务搜索和测试过程中产生的大量日志、中间结果会污染上下文影响核心的重构决策。而如果生成三个Subagent分别负责这三个子任务主Agent只需要接收每个Subagent的总结结果就能专注于核心的重构决策既提高了效率又保证了推理质量。除了上下文隔离Subagent还是一种高效的任务调度机制。这种调度通常有两种形式同步Subagent像普通工具一样调用主Agent会阻塞等待Subagent完成任务、返回结果再继续推进后续流程。这种方式适合子任务与主任务关联性强、需要及时反馈的场景异步Subagent作为后台任务运行主Agent不需要等待继续推进自己的流程Subagent完成任务后结果会稍后回收。这种方式适合子任务耗时较长、与主任务关联性较弱的场景能够提高整体任务的执行效率。一旦进入异步模式系统就必须维护一个全局任务注册表比如Claude Code中的AppState.tasks用于记录所有后台Subagent的状态、任务描述、执行进度等信息。这些后台Subagent会在后台持续运行完成任务后通过信息注入的方式将结果加入到主Agent的Agent Loop中确保主Agent能够及时获取子任务结果。当多个后台Subagent同时运行时Subagent的价值就不再只是上下文隔离而是多Agent协作multi-agent orchestration的起点。多个Subagent可以并行执行不同的子任务相互配合完成复杂的大型任务而主Agent则承担着“任务分配、结果汇总、决策推进”的核心角色。六、HooksHarness的“扩展与控制接口”前面我们提到Agent Loop的核心逻辑必须简洁不能堆砌复杂的业务逻辑否则会变成一个巨大的if-else状态机难以维护、无法适配未来模型的迭代。但Harness又需要具备扩展能力以满足不同场景的需求比如安全控制、记忆治理、任务编排等。这时Hooks钩子就发挥了关键作用。Hooks的意义在于把复杂的扩展逻辑移到Agent Loop外部通过在关键节点定义事件让Harness能够在不修改Loop核心逻辑的前提下实现各种扩展功能。简单来说Hooks就是在Agent运行的关键节点上“插个队”捕捉状态、注入上下文、拦截风险、验证结果而不必让Loop自己理解所有规则。常见的Hooks事件包括PreToolUse工具调用前、PostToolUse工具调用后、PreCompact上下文压缩前、SubagentStop子代理停止时等。这些事件定义了Agent系统中的关键边界一旦边界清晰很多能力就可以通过外部策略注入而不需要直接修改Loop本身安全策略可以挂在工具调用前后比如PreToolUse时检查Agent的操作权限PostToolUse时验证工具调用结果的安全性防止恶意操作记忆治理可以挂在上下文压缩前后比如PreCompact时检查上下文的关键信息确保压缩后不丢失核心内容PostCompact时更新文件系统中的持久化记忆任务编排可以挂在Subagent的生命周期上比如Subagent spawn时分配资源Subagent Stop时回收资源、汇总结果除此之外日志记录、性能监控、错误报警等功能都可以通过Hooks实现。Hooks的本质是“机制与策略分离”Agent Loop负责推进执行流程机制Hooks负责施加控制、实现扩展策略。这种设计既保证了Loop的简洁性又让Harness具备了强大的扩展性能够适配不同场景的需求。边界组件那些可取舍的“辅助能力”除了上述6个核心组件行业内还经常讨论一些与Harness相关的概念比如Checkpointing/Recovery、Planner/Todo-list、Skills、MCP/Plugins、Memory、Agent Team等。这些组件并非每个Harness都必需理解它们的定位有助于我们避免过度设计保持Harness的极简性。Checkpointing / Recovery检查点与恢复对于long-running Agent来说错误恢复和状态检查点确实很重要。毕竟Agent可能会持续运行数小时中途如果出现系统崩溃、网络中断等问题没有检查点的话之前的工作就会全部丢失损失巨大。但从Harness的视角来看Checkpointing并不是一个独立的组件而是各个核心组件协作的产物。File System负责将Agent的状态、中间结果持久化作为检查点的存储载体Hooks负责在关键节点比如工具调用完成、上下文压缩后触发保存操作创建检查点Agent Loop负责在系统恢复后从检查点加载状态继续推进任务。因此我们不需要单独设计一个“Checkpointing组件”只需要利用好现有的核心组件就能实现检查点与恢复功能。Planner / Todo-list规划器/待办列表2026年初Claude Code取消了内置的todo-list工具这个举动恰好印证了《The Bitter Lesson》的预言。原因很直接新版本模型的推理能力已经足够强能够自主梳理任务流程、拆分步骤不再需要人为维护一个显式的待办列表。过去很多开发者认为Planner是Harness的核心组件花费大量精力编写复杂的规划逻辑可随着模型能力的提升这些人工规划的组件反而成了负担。如果一定要设计Planner或Todo-list必须确保它能被干净地剥离不能与Agent Loop深度耦合否则未来模型能力提升后这些组件会难以拆除形成技术债。Skills技能Skills本质上是核心组件的组合产物它不是Harness的底层组件而是Harness之上的应用层。一个Skill通常包含一个命令注册表、按需的消息注入以及一堆说明文档本质上是将核心工具、上下文管理、Subagent等能力组合起来实现一个特定的业务场景比如“代码调试”“文档生成”。因此Skills属于应用层面的封装不需要包含在最小化Harness的设计中。MCP / Plugins协议/插件MCPMulti-Agent Communication Protocol是一个协议层用于解决多Agent之间的通信问题它不是Harness的本体。支持MCP当然是一个加分项能够让Harness更好地适配多Agent场景但它解决的是“如何暴露外部资源、实现Agent间通信”的问题而非“Harness应该具备哪些核心能力”的问题。因此MCP和Plugins都属于扩展能力不是最小化Harness的必备组件。Memory记忆Memory无疑是Agent系统的重要组成部分但截至目前业内尚未形成共识的记忆形态。无论是OpenClaw还是Claude Code都普遍采用基于Markdown文件的轻量级记忆方案这种“文件即记忆”的方式虽然朴素却恰好符合Harness的极简哲学。与其花费精力打造一个复杂的记忆数据库设计复杂的记忆检索、更新逻辑不如让Agent用最熟悉的文件接口来管理自己的长期状态。文件系统本身就具备持久化、可编辑、可检索的能力能够满足Agent的大部分记忆需求这种方式既简洁又高效也能适配未来模型能力的提升。Agent Team and Multi-agent代理团队与多代理当需要处理超大型复杂任务时单Agent往往难以胜任此时就需要扩展到多Agent协作。但从Harness的角度来看多Agent系统的核心基础设施与单Agent完全一致——每个Agent内部的Harness都包含同样的Agent Loop、Context管理、原子化工具等核心组件唯一新增的是Agent之间的连接方式。如果你的Harness为单Agent设计得足够好扩展到Agent Team时90%的基础设施可以直接复用。Subagent和Agent Team Member代理团队成员虽然都属于“子代理”但存在明显区别我们可以通过下表清晰区分维度Subagent子代理Agent Team Member代理团队成员生命周期任务完成 → 销毁跨任务存活可能运行数小时身份匿名只有任务描述有角色身份“reviewer”“coder”“tester”状态无状态结果返回后消失有持久状态自己的上下文历史、记忆文件生成方式主Agent spawn生成预先定义 / 动态spawn均可从Harness的角度来看多Agent系统需要额外提供三个核心能力一是Agent注册表用于记录所有Agent的运行状态、角色身份二是生命周期钩子用于在Agent生成、闲置、终止时执行对应的操作三是优雅退出与资源回收机制这是最容易被忽视也最关键的一点能够避免资源泄露保证系统稳定运行。此外Subagent是单向通信主Agent发任务 → Subagent返回结果而Agent Team需要双向甚至多向通信。但通信方式的设计依然应该遵循“贴合LLM习惯”的原则——共享文件系统本身就是最自然的通信通道Agent可以通过读写同一个文件来传递信息无需设计复杂的通信协议。Harness Engineering更大的循环更强的进化能力受限于篇幅本文不展开太多关于Harness Engineering的内容但我们可以简单理解其核心逻辑。借用《Harness Engineering 在讨论什么三个 Scaling 维度的统一框架》一文的观点Harness Engineering的核心关键词是Scalability可扩展性具体包括三个维度时间的延展让Agent能够长期运行、空间的扩展让Agent能够处理更复杂的任务、交互方式的进化让Agent能够更好地与人类、其他Agent协作。在我看来Harness Engineering和Compound Engineering复合工程是同义词其真正的价值在于“如何让Agent越跑越好”。而这一切的前提都是一个好用的Harness加上一个更大的循环。一个完整的Agent系统其实存在两个循环这两个循环相互支撑、协同工作第一个是Inner Loop内部循环也就是我们本文重点讨论的Agent Loop是单次任务内的“工具调用 → 结果捕获 → 上下文追加 → 下一步决策”循环负责完成具体的任务执行第二个是Outer Loop外部循环也叫进化循环是跨任务的“执行 → 评估 → 反馈 → 改进”循环负责让Agent在长期运行中不断优化自身能力这也是Harness Engineering的核心讨论对象。这种双循环的理念在Andrej Karpathy的AutoResearch自动研究和Ralph Loop的相关研究中都能看到。需要注意的是Outer Loop不需要另起一套架构它是Inner Loop的核心组件在更大时间尺度上的复用Hooks提供观测点用于捕捉Agent的运行状态和执行结果File System提供持久化记忆用于保存评估数据和反馈信息Subagent提供并行实验能力用于测试不同的改进方案Context管理保证运行不会失控确保改进过程有序推进。简单来说Harness Engineering就是利用Harness的核心组件构建一个让Agent能够自我迭代、持续进化的生态让Agent不仅能“完成任务”还能“越做越好”。好Harness的四大设计原则理解了核心组件和边界组件后我们还需要掌握好Harness的设计原则。这些原则是极简哲学的具体体现也是避免技术债、适配未来模型迭代的关键。一、极简性Minimality核心原则就是“能不加的组件就不加”。每个组件在加入Harness之前都要问自己一个问题“如果去掉它Agent是完全不能跑还是只是跑得没那么好”如果去掉某个组件后Agent完全无法运行说明这个组件是核心组件必须保留如果只是跑得没那么好说明这个组件是辅助组件能不加就不加即使加了也要预留拆除的口子。极简性不是“偷工减料”而是“精准取舍”让Harness只保留最核心的能力避免臃肿。二、可拆卸性Removability这是《The Bitter Lesson》的工程实践也是避免技术债的关键。辅助组件必须能被干净地移除而不是和核心组件纠缠在一起形成“牵一发而动全身”的局面。我们今天写的辅助组件很可能在六个月后就会被模型能力淘汰因此在设计时必须保证这些组件的独立性不与Agent Loop、Context管理等核心组件深度耦合。比如将辅助组件通过Hooks注入而不是直接修改核心逻辑这样未来需要拆除时只需要移除对应的Hooks不会影响整个Harness的运行。三、模型无关性Model AgnosticismHarness不应该为某个特定模型的怪癖做特殊适配。好的Harness换一个模型后只需要修改API调用相关的代码就能正常运行不需要大规模调整核心逻辑。比如Anthropic Claude和OpenAI GPT的API调用格式不同我们可以将API调用封装成一个独立的模块Harness的核心组件只调用这个模块不直接与具体的模型API交互。这样一来更换模型时只需要修改这个封装模块核心组件无需改动。当然针对特定模型的Prompt优化是另一回事这属于应用层面的适配不是Harness核心逻辑的适配。四、面向进化Evolution-ReadyHarness的终极目标不是“跑一个任务”而是“提供一个让Agent越跑越好的环境”。因此每个组件的设计都应该考虑它如何为Outer Loop进化循环贡献数据、反馈或可调参数比如Context管理组件不仅要优化当前任务的上下文还要记录上下文的变化数据为Agent的推理优化提供依据Hooks不仅要实现扩展功能还要捕捉Agent的运行状态为评估和反馈提供数据File System不仅要保存中间结果还要记录Agent的执行日志为改进方案的制定提供支撑。只有这样Harness才能支撑Agent的持续进化。结语克制才是Harness的核心价值2026年AI Agent领域的竞争已经从“功能堆砌”转向“底层能力比拼”而Harness作为Agent的核心底座其设计水平直接决定了Agent的性能、稳定性和可进化性。很多开发者急于追赶潮流盲目封装复杂逻辑、堆砌工具组件最终导致Harness臃肿不堪、难以维护陷入技术债的泥潭这正是对Harness本质的误解。Agent Harness不是越复杂越好恰恰相反它的价值在于克制。2023-2026年的Agent发展史本质上是一部“人为控制逻辑不断被模型能力淘汰”的历史。从ReAct状态机到复杂Planner从大量自定义工具到原子化基础工具我们逐渐意识到Harness的真正使命是为模型提供一个稳定、安全、可进化的运行环境然后把决策权交还给模型本身。一个面向2026的最小化Agent Harness不需要复杂的功能只需要做好Agent Loop、Context管理、原子化工具、File System、Subagent和Hooks这6个核心组件遵循极简、可拆卸、模型无关、面向进化的设计原则就能适配未来模型的迭代支撑Agent长期稳定运行。