TLDRAgent 模型Model 框架Harness。所谓 Harness Engineering就是围绕模型构建系统把模型变成真正能干活的“工作引擎”。模型提供智能而 harness 让这种智能变得可用。本文尝试定义什么是 harness并推导出当下以及未来智能体所需的核心组成部分。能不能有人好好定义一下“Harness”Agent Model Harness如果你不是模型本身那你就是 harness。harness 指的是除了模型之外的所有代码、配置以及执行逻辑。一个裸模型并不是智能体只有当 harness 为它提供状态管理、工具执行、反馈循环以及可约束的执行环境时它才真正成为一个 agent。具体来说harness 通常包括System Prompt系统提示词工具、技能、MCP 以及它们的描述配套基础设施文件系统、沙箱、浏览器等编排逻辑子代理调度、任务交接、模型路由用于确定性执行的 Hook / 中间件如上下文压缩、续写、lint 检查等当然模型和 harness 的边界可以有很多不同的划分方式但我认为这种定义最清晰因为它迫使我们从“如何围绕模型智能构建系统”的角度来思考问题。接下来我们会从“模型本身的能力边界”出发反向推导为什么需要这些 harness 组件。从模型视角看为什么需要 Harness我们希望智能体完成很多事情但模型本身并不具备这些能力这正是 harness 的作用所在。模型本质上只是接收输入文本、图像、音频、视频等输出文本。仅此而已。它原生无法做到在多轮交互中持续保存状态执行代码获取实时信息搭建运行环境、安装依赖来完成任务这些全部都是 harness 层的能力。LLM 的结构决定了必须有一层“外部系统”来包裹它才能让它真正做事。举个简单例子为了实现“聊天”这种产品体验我们会用一个循环不断追加历史消息并传给模型。这本质上就是最基础的 harness。核心思想是把我们期望的 agent 行为转化为 harness 中的具体功能。从“想要的行为”反推 Harness 设计Harness Engineering 的作用是帮助人类向模型注入有效的先验从而引导其行为。随着模型能力提升harness 也在被用来“精细化补强”模型让它完成原本做不到的任务。我们不打算罗列所有功能而是遵循一个思路来推导想要的行为或需要修正的问题 → 对应的 harness 设计用文件系统实现持久存储与上下文管理我们希望智能体具备持久存储能力能处理真实数据能把超出上下文的信息卸载出去并跨会话保留工作成果。模型只能处理当前上下文窗口内的信息。没有文件系统之前用户只能手动复制粘贴数据这种方式既低效也不适用于自动化 agent。现实世界本来就是通过文件系统来组织工作的而模型在训练中也接触了大量相关数据因此一个自然的方案就是在 harness 中内置文件系统抽象并提供文件操作工具。文件系统是最基础的 harness 原语之一因为它带来了智能体可以读取数据、代码和文档可以逐步存储和卸载信息而不是全部塞进上下文能保存中间结果实现跨会话状态成为协作载体多个 agent 和人类可以通过共享文件协同工作再加上 Git就可以实现版本控制、回滚错误、分支实验等能力。用 Bash 代码执行作为通用工具我们希望智能体能自主解决问题而不是事先为每个动作都设计工具。当前主流模式是 ReAct模型思考 → 调用工具 → 观察结果 → 循环。但 harness 只能执行预先定义好的工具。更好的方式是提供一个通用工具——比如 bash让模型通过写代码并执行代码自主解决问题。这相当于给模型一台计算机。它可以动态创建工具而不是受限于固定接口。虽然 harness 仍然会提供其他工具但“代码执行”已经成为默认的通用解法。沙箱与执行环境运行与验证工作的基础智能体需要一个安全、默认配置良好的环境来执行任务、观察结果并持续推进。我们已经给了模型存储和执行能力但这些必须运行在某个环境中。直接在本地执行不安全也难以扩展。沙箱sandbox提供了隔离、安全的执行环境。harness 可以连接到沙箱来执行代码查看文件安装依赖完成任务还可以通过白名单命令、网络隔离等方式增强安全性。同时沙箱支持按需创建、并行扩展、任务完成后销毁。好的环境还需要好的默认工具语言运行时和依赖Git、测试工具 CLI浏览器用于网页交互与验证这些工具让 agent 能够查看日志、截图、运行测试构建“自验证循环”写代码 → 跑测试 → 修复错误这些能力全部由 harness 决定而不是模型本身。记忆与搜索实现持续学习我们希望智能体能记住经验并访问训练后才出现的信息。模型的知识只来自参数和当前上下文。无法修改权重时“增加知识”的唯一方式就是——把信息注入上下文。文件系统再次成为核心harness 会加载类似 AGENTS.md 的记忆文件到上下文agent 可以持续更新这个文件下次启动时再注入这就是一种“持续学习”。对于实时信息则需要Web 搜索MCP 工具如 Context7这些让模型获取训练截止之后的新知识。对抗 Context Rot上下文退化智能体在长时间运行中不应该性能下降。Context Rot 指的是随着上下文变长模型推理能力下降。上下文是稀缺资源因此 harness 必须管理它。本质上harness 是“上下文工程”的执行系统。关键策略包括1. 上下文压缩Compaction 当上下文接近上限时对历史内容进行总结和卸载让任务继续进行。2. 工具调用结果卸载 大体量输出只保留头尾完整内容存入文件系统避免污染上下文。3. Skills渐进式加载 避免一开始加载过多工具通过“按需暴露”减少上下文负担。长周期自主执行我们希望智能体能在长时间内自主、正确地完成复杂任务。但现实中模型会过早停止难以分解复杂问题跨上下文窗口时失去连贯性因此需要 harness 设计来弥补。关键机制包括文件系统 Git 记录长期任务进度支持多 agent 协作。Ralph Loop持续执行机制 拦截模型“结束”行为重新注入任务目标在新上下文中继续执行。规划与自验证先拆解任务planning每步完成后进行验证测试、日志、评估harness 可以通过 hook 自动运行测试并将错误反馈给模型。Harness 的未来模型训练与 Harness 的耦合像 Claude Code、Codex 这样的系统已经是在“模型 harness”共同参与的环境中进行后训练的。这带来一个循环发现有用的 harness 原语加入系统用它们训练下一代模型但这也带来副作用比如对特定工具过拟合例如 apply_patch。但这不意味着模型自带的 harness 就是最优的。例如在 Terminal Bench 2.0 上仅通过优化 harness就能显著提升模型表现。Harness Engineering 的发展方向随着模型能力提升一些能力会被“内化”进模型比如规划能力自验证能力长任务一致性这似乎意味着 harness 重要性下降。但实际上不会。就像 prompt engineering 依然重要一样harness engineering 仍然是构建优秀智能体的关键。因为它不仅是“补模型短板”更是在提供更好的运行环境提供合适的工具管理状态构建验证机制这些都会提升任何模型的效率。当前一些值得探索的方向包括协调数百个 agent 并行协作让 agent 分析自身执行轨迹修复 harness 层问题动态按需组装工具和上下文而不是预先配置本文的核心目的是说明 harness 是什么以及它如何由“我们希望模型完成的任务”所决定。模型提供智能而 harness 让智能真正发挥作用。期待更多更好的 harness、更强的系统以及更强大的智能体。最后我们整理出这套 AI 大模型 突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2025 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要 《AI大模型入门进阶学习资源包》下方扫码获取~资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。需要这份AI大模型资料清单的话在评论区回复「清单」即可我会根据大家的问题继续补充对应的实战内容。