- 综合排序
- 最热优先
- 最新优先
Agent 系列（三）：Harness Engineering
2026 年 2 月，OpenAI 连续发布关于 Codex 的几篇技术文章，明确把 “harness” 放到了 Agent 工程的中心位置：他们关注的重点，已经不只是模型怎么写代码，而是如何围绕 Agent 他提到： Agent 在实际任务中总会反复犯同一类错误，于是建议 “每当 Agent 犯错，就花时间工程化一个机制，确保它永远不再犯同样错误“ 这就是 “Engineer the harness” 的核心想法 二、Harness Engineering 到底是什么 通俗来说，Harness Engineering 就是围绕 AI Agent 搭建一整套 “可执行、可验证、可约束、可迭代” 的外层运行系统。 这里的 “Harness” 可以理解为驾驭/缰绳，它不是一段 Prompt，也不是单个工作流，而是给 Agent 量身定制的 “工作轨道”： • 模型负责思考和决策； • Harness 负责把思考变成稳定执行 `Agent Harness` 系统架构示意图 `Observation、Context、Memory、Actions` 等核心层级闭环 五、Harness Engineering 真正改变的是什么？
3.6K22编辑于 2026-03-30- 来自专栏开源物联网平台开发
Agent Harness 的解剖结构
Agent Harness 的解剖结构 原文标题: The Anatomy of an Agent Harness 作者: Vivek Trivedy 来源: LangChain Blog 原文链接 : https://blog.langchain.com/the-anatomy-of-an-agent-harness/ 翻译时间: 2026-03-21 摘要 (TL;DR) Agent = Model + Harness 代理（Agent）由两部分组成： 模型（Model）: 包含智能和推理能力 Harness（框架/装备）: 提供执行环境、工具集成和控制系统 引言 在构建 AI 代理系统时，很多人只关注模型本身的能力 本文深入探讨了 Agent Harness 的架构设计，帮助开发者理解如何构建可靠、可扩展的代理系统。 Harness 的核心组成部分 1. 持续测试和优化是成功的关键 进一步阅读 LangChain 官方文档 Agent 开发最佳实践 Harness Engineering 相关文章 注意：本文是基于原文核心概念的翻译和总结。
55510编辑于 2026-04-02 - 来自专栏DeepHub IMBA
Agent = Model + Harness：模型决定上限Harness 决定下限
Agent = Model + Harness 每一个 AI 编码 Agent 都是同样的两部分结构： Agent = Model + Harness 模型是认知基础：处理文本、生成 Token 的神经网络 Harness 是除此之外其他东西，可以把一个无状态的语言模型，变成一个能持续产出工作的编码 Agent。 编码 Agent Harness 的七个组件 Harness 不是一块单一的基础设施而是一层一层叠起来的能力栈。每个 AI 编码 Harness，不管包的是哪个模型，都会以某种形式提供下面这七层。 Harness 负责派生子 Agent —— 拥有独立上下文的独立模型实例 —— 在它们之间路由任务，并安排工作顺序。 Harness 是载体，治理是指令集。 把编码 Agent 的 Harness 理解成一个操作系统，而不是一个聊天界面，那些原本看起来像是小调整的配置决策，就会变成架构决策。
17610编辑于 2026-05-20 三个 Agent Harness 框架对比：OpenClaw、Hermes Agent、OpenHuman 到底差在哪？
AI Agent harness，但重点完全不同： •OpenClaw 解决的是入口与控制平面问题：怎么让 Agent 常驻在用户已有设备和聊天渠道里。 Hermes Agent：会自我改进的 Agent 运行时 Hermes Agent 的关键词是 self-improving。 harness”。 如果目标是构建一个能长期学习、搜索历史、生成技能、跨环境执行复杂任务的 Agent harness，优先看 Hermes Agent。 这三个项目放在一起看，刚好对应 Agent 产品化的三条路径： 1先把入口打通，让 Agent 能被随时唤起。 2再把经验沉淀下来，让 Agent 越用越强。
32521编辑于 2026-05-26Multi-Agent系统Harness Engineering架构的思考与实践
模型的推理能力决定agent的上限，但只有在合适的harness中，这种能力才能被稳定地转化为可执行、可验证、可交付的任务完成能力。 harness这套agent工程应该怎么设计，首先还是需要基于agent的技术设计和实现架构，我们需要先从agent的设计模式入手，先看清楚单agent和多agent目前的技术发展，工程落地现状，各自能走多远 所我们可以看到强如opus4.6这样的模型，在使用multi-agent架构完成复杂任务上，也需要投入大量精力在Harness上。 考虑到MAS复杂度高于单agent，在MAS中生效的Harness工程架构应用范围可以覆盖单agent，所以后文提到的harness的架构设计都以MAS为基准进行设计知识供给层：不是仓库，是主动的信息生态定位 这正是三阶段演化能够成立的前提-不是因为模型越来越强就可以去掉Harness，而是因为Harness在，模型才可以将其决策推理应用到容错性更低，但价值更高的场景结语当下大模型和agent技术都发展飞快，
3.9K42编辑于 2026-03-13长时 Agent 怎么交接班：读 Anthropic 这篇 harness 文章
长时Agent怎么交接班：读Anthropic这篇harness文章Anthropic工程团队最近发了一篇文章，题目叫《Effectiveharnessesforlong-runningagents》。 ，就把功能标成done这篇文章把问题放回到了harness。 所以文章的核心目标只有两个：先把初始环境搭成一个适合分轮推进的状态再让每一轮session都只做增量工作，并把状态交接清楚Anthropic的做法：拆成两个agent角色整个harness分成两个角色： 因为它说明文章想表达的不是“有了浏览器工具以后，长时Agent就稳了”，而是：如果你想让长时Agent跑得更稳，端到端测试必须进入harness。 所以这篇文章更适合被理解成：一套已经在工程里验证过、能明显提升长时Agent稳定性的harness设计。它还不是终局，但已经足够具体。
29900编辑于 2026-04-11- 来自专栏机器学习与统计学
2026 年，AI 编程 Agent 的真正分水岭——Harness 详解
现在社区里有一个越来越清晰的共识： Agent = Model + Harness Agent = Model + Harness 公式图解 Model 就是大模型本身——GPT、Claude、Gemini 《Harness Engineering for Coding Agent Users》，给了一个特别精辟的定义： Harness 由两部分组成：Guides（前馈控制） 和 Sensors（反馈控制 Claude Code 是一个优秀的 harness，特定任务的 Agent harness 在窄领域表现更好。Managed Agents 可以容纳任何一种。 所以，"harness 才是分水岭"这个说法对吗？ 我觉得对了一大半，但需要补充： 对的部分：在模型能力差距日益缩小的今天，harness 确实是决定 Agent 实际表现的最大变量。 所以更准确的说法是： 模型决定了 Agent 的能力上限，harness 决定了 Agent 能发挥出多少。
5.7K82编辑于 2026-04-13 - 来自专栏DeepHub IMBA
Prompt、Context、Harness：AI Agent 工程的三层架构解析
或者说coding agent = AI model(s) + harness。模型是马，Harness 是所有其他部分，比如缰绳、马鞍、马蹄，甚至是路。 在cc中，AGENTS.md 和 CLAUDE.md 是最直接的方式：Harness 将这些 markdown 文件确定性地注入 Agent 的系统提示。 Agent 理解任务也拥有正确的信息，但仍然漂移、循环、做破坏性改动、静默失败或在长任务上质量衰减——Harness Engineering 出了问题。 Harness 层缺了 Context 层，则是一个受约束但无法获取所需信息的 Agent。缺哪个都不行。 如果正在用前沿模型而 Agent 质量仍然不稳定，模型几乎可以确定不是症结所在。Harness 才是。而 Harness 不用等下一个模型版本就可以修。
1.3K21编辑于 2026-04-15 - 来自专栏大前端修炼手册
从 OpenClaw 到 Android：Harness Engineering 是怎么让 Agent 变得可用的
说白了：Agent 出问题，80% 是脚手架的问题，不是模型的问题。这也是为什么 Harness Engineering 这个词会出现——专门描述"围绕模型的那层工程壳"。 三、Harness Engineering 的本质：在运行时建立边界 如果把 Agent 系统想象成一个工厂，模型是工人，Harness 是工厂的布局、流水线、操作规程和安全装置。 Harness Engineering 的核心转变是——把"说服"变成"约束"。 2025 年 Vercel 的 AI SDK 团队做过一个反直觉的实验：给 Agent 提供 20 个工具 vs. Android 上搭 Agent Harness，和服务端有什么不一样？ 最大的不同是资源约束。 Android 上的 Agent 还在早期，但 Harness Engineering 的方法论已经成熟了。这轮技术演进，最先吃到红利的，应该是那些把工程基础打好的人。
1K10编辑于 2026-04-02 Agent 系列（五）：从 LLM 的角度聊 Prompt、Context 和 Harness
在一个 Agent 系统中，Context Engineering 还要决定当前任务目标是什么，历史执行到了哪一步，已经调用过哪些工具，工具返回了什么结果，哪些状态需要保留，哪些中间过程可以丢弃。 Harness Engineering 需要解决的问题。 Harness 让模型能力进入业务闭环 以 Agent 为例，一个 Agent 不能只靠 Prompt 和 Context，如果一个 Agent 要完成 “查询告警信息并生成处理建议” 这个任务，系统至少要处理这些问题 这也是为什么今天的 Agent 框架越来越强调 trace、checkpoint、human in the loop、guardrails、eval、tool approval 和 workflow。 三个阶段的关系的总结 4 月份在腾讯云社区 AI 公开课上，我做了一个名为《从 ReAct 到 Harness：谈谈 LLM Agent 的演进历程》的主题演讲，这里面我讲了三次范式迁移的分化过程（PPT
13710编辑于 2026-05-26- 来自专栏架构之巅
Harness架构下的Agent研发：从SDK到工程化实践
然而，当开发者试图将这些“天才大脑”转化为能独立完成代码编写、数据分析、信息整合等复杂任务的“智能体”（Agent）时，却常常感到力不从心。 Agent SDK：开箱即用的智能体构建利器理解了Harness的理念后，如何快速将其付诸实践？ Claude公司推出的 Agent SDK,他实现了与claude code一样的能构建自主读取文件、运行命令、搜索网页、编辑代码等的 AI 智能体，正是这样一套践行Harness理念的通用开发工具包 革命性的开发体验使用Agent SDK，构建一个智能体变得异常简洁。 应用前景与当前挑战基于Harness架构和Agent SDK，可以快速构建出多种实用的智能体应用：自动化的代码助手：不仅能建议代码，更能直接分析代码库、定位错误、编写测试并执行修复，形成“分析-修改-验证
1K20编辑于 2026-04-07 Harness Engineering 被讲烂之后，Agent 工程真正难的是什么？
这层系统，现在常被叫作Harness。Harness要解决什么问题一个Agent连续跑几个小时以后，真正麻烦的地方，常常不是它能不能继续往下跑，而是它是否还知道自己在做什么。它怎么知道刚才做到哪一步？ Anthropic：把Harness拆成一套Agent操作系统在这三家里，Anthropic是把Harness拆得最细的一家。 这说明一件事：长程Agent的问题，很大一部分是交接问题。Harness要让下一轮Agent不必靠猜。再往前一步，是上下文怎么进入Agent。 所以Harness不只是“给Agent接工具”。更重要的是：把工具设计成Agent能理解、能选择、能验证的行动接口。另一个问题是自评。 这让评估也成了Harness的一部分。Agent的质量不能只看最终回答，还要看它在环境中的行动和结果。
25210编辑于 2026-05-20我用 PAICodex 理解 Harness Engineering：Agent 工作环境到底怎么搭
这就是我现在理解的Harness：它不像一套框架名词，也不像几个Agent拼起来的流程。它更像一个工作场。 好的入口更像一张简短地图：先告诉Agent现在在哪，去哪找资料，哪些地方不能乱碰。入口太短，Agent会猜。入口太长，它会淹没。Harness的难点就在这个尺度上。 这几轮我和Agent之间的反馈过程，本身就是一种直观的Harness，甚至比引用别人的Harness文章更能说明它是什么。这也侧面说明一件事：如果没有外部反馈，Agent很容易停在第一版。 工具可以换，只要这些关系还在，Agent就有工作场。工作场的核心是沉淀如果只让我用一句话说Harness的精髓，我会说：把每一次对Agent的临时提醒，尽量沉淀成下一次默认生效的环境。 所以我现在不太愿意把Harness讲成“模型之外的工程系统”这么宽泛的话。那句话没错，但容易变成概念。对我来说，它更具体：Harness是一个让Agent不必每次从零开始，也不能随便宣布完成的工作场。
16510编辑于 2026-05-20Agent 搜索里，Harness 比检索方法更重要
这个背景也解释了为什么这篇论文没有只停留在检索算法对比上，而是把重点放在了Harness、工具返回方式，以及端到端Agent表现。 他们比较了两种Harness：自定义Harness：Chronos，作者团队自建的长对话记忆Agent运行环境；AI厂商原生CLIHarness：ClaudeCode、Codex、GeminiCLI。 除了比较不同Harness，这篇论文还特别看了一个细节：搜索结果是怎么返回给Agent的。 另外，Harness本身也要被认真评估。很多时候，我们说一个Agent“检索能力不行”，不一定是模型不行，也不一定是检索方法不行，可能是Harness没有把搜索工具设计好。 Agent搜索能力不是一个单点能力，而是由模型、检索方法、工具接口和Harness一起组成的。一句话总结这篇论文表面上是在比较grep和向量检索，但它真正讨论的是Agent搜索的系统设计问题。
11510编辑于 2026-05-26agents-hive 开源了：一个面向生产的Harness Agent 工程
agents-hive 正式开源啦商业级 Agent 工程化管理系统 我们理解的 Agent Harness 在 agents-hive 的设计里，Harness 从来不是"让 Agent 跑起来的东西 Harness 是 Agent 的完整生命周期管理系统。 它是 Agent 的运行容器、安全边界、观测仪表盘、调试工作台和迭代引擎。 Harness沙箱隔离│权限控制│成本控制│超时熔断│审计日志Agent RuntimeReAct循环│工具调度│上下文管理│状态持久化│任务恢复 agents-hive 的四大核心工程能力 全链路无死角执行回放 这是我们认为 Harness 最基础也最重要的能力。 生产级安全与约束体系 安全是生产级 Harness 的底线。
20710编辑于 2026-05-18- 来自专栏运维有术
6.7% 到 68.3%：Harness Engineering 六大支柱如何重塑 AI Agent 开发
Agent = Model + Harness：一个把系统切开的公式图 2：Agent = Model + Harness 三层嵌套架构LangChain 把这件事用一句话说透了：Agent = Model 模型本身只是能力的来源，只有通过 Harness 把状态、工具、反馈和约束串起来，它才真正变成一个 Agent。 他们的对比数据很有说服力：配置耗时花费效果Solo Harness（单 Agent + 最少工具）20 分钟$9跑不起来的半成品Full Harness（三 Agent + 完整工具链）6 小时$200 Agent 布置任务外包确定性任务挑出 Agent 几乎一定能做好的任务后台跑工程化 Harness每当 Agent 犯错，就工程化一个解决方案让它永远不再犯始终有 Agent 在跑目标是 10-20% Harness）：https://blog.langchain.com/the-anatomy-of-an-agent-harness/如果你的团队也在做 AI Agent 开发，转发给同事看看——说不定你们踩的坑
83121编辑于 2026-04-27 - 来自专栏用户10389108的专栏（2）
01｜什么是 Agent Harness：为什么大模型需要一个“工程外壳”
Harness的价值，就是把这个循环组织起来。Harness包含什么一个实际可用的AgentHarness，至少包含六类能力。第一是上下文管理。 不同执行环境决定了Agent能做什么，也决定了风险边界。第四是权限控制。哪些命令能直接跑，哪些必须确认，哪些永远禁止。没有权限层，Agent越强越危险。第五是验证机制。 为什么不能只靠长上下文很多人会把Agent的问题归结为上下文不够长。上下文确实重要，但不是唯一答案。如果把整个仓库都塞给模型，会遇到三个问题。第一，成本高。代码库越大，Token越贵，响应越慢。 所以成熟的Harness不追求“把所有东西塞进去”，而是追求“在需要的时候拿到正确上下文”。 Harness的边界AgentHarness不是魔法。它能提高执行效率，但不能替代工程判断。
1200编辑于 2026-05-28 - 来自专栏.NET 全栈开发专栏
Windows 原生部署 Hermes Agent + 火山引擎 Agent Plan + Harness + 飞书机器人 完整实战教程与踩坑总结
最近成功在Windows上部署了HermesAgent，完整接入火山引擎AgentPlan+Harness联网搜索，并打通飞书机器人，同时增加了图片、视频生成等能力。以下是详细部署流程和踩坑总结。 utm_campaign=20260511&utm_content=Agent_plan&utm_medium=post&utm_source=od_community&utm_term=adg_hangzhou advancedActiveKey=agentPlan配置模型及BaseURL配置Harness（可选）创建AgentPlan个人版专属APIKey二、安装HermesNousResearch为HermesAgent 在控制台使用配置-配置Harness中领取权益并获取联网搜索APIKey。 部署过程中如果遇到其他问题，欢迎在评论区留言交流，一起玩转Agent！点赞+在看，支持更多实用干货～
76930编辑于 2026-05-13 - 来自专栏大前端修炼手册
Anthropic 的 Harness 启示：当 AI Agent 开始长跑，架构才是真正的天花板
Anthropic 的工程师最近发表了一篇内部研究——《Harness Design for Long-Running Application Development》，把这个问题说透了：模型能力到了一定水位 三、GAN 思路移植到 Agent 架构 Anthropic 的解决方案，本质上是把生成对抗网络（GAN）的思路搬到了 Agent 编排层面。 token 逻辑 stub 了，后续 Sprint 补## 下一步 实现 `authMiddleware(requiredRole)` 函数，挂到需要权限的路由上 八、一个更大的问题：架构师的角色在变 Harness 现在这个分工在变：架构师设计 Agent 协作边界，AI 填充实现。技能树在迁移，但"系统思维"这条根没变。 Harness Design 的价值并非恒定——它是突破模型原生能力边界的手段。 • 开源的 Harness 框架会不会出现？目前 LangGraph、CrewAI、AutoGen 都在做类似的事，但 Anthropic 的这套思路还没有完整的开源对应物。
45810编辑于 2026-04-02 - 来自专栏有文化的技术人
Agent Harness：不是给 AI 套缰绳，而是给它造一个操作系统
这套机制，就是 「Agent Harness」。 二、Harness 不是缰绳，是操作系统 很多人第一次听到 Harness 这个词，直觉反应是"给 AI 加限制"、"套个缰绳让它别乱跑"。 分层只是告诉 Agent "做什么"，但 Harness 还得管住 Agent "怎么做"以及"做砸了怎么兜"。所以分层只是 Harness 的一个切面，远不是全部。 「好的 Harness 不只是消费模型能力，它还在生产模型训练数据。」 Agent 用得越多，Harness 捕获的数据越多，模型改进得越快，Agent 做得越好。 对应到 Harness 设计上，Script 层的重点不该是"替代 Agent 生成内容"，而是"快速验证 Agent 生成的内容是否合格"。 好的 Harness，不是把 Agent 的工作抢过来自己做，而是在 Agent 需要的时候提供支撑，不需要的时候退到一边去。
42910编辑于 2026-04-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号