一句话结论Agent智能体要变得更好用瓶颈不在再换一个更聪明的模型而在把harnessAgent 身边那一整套支撑系统——工具、规则、记忆、流程做成observable看得见、能撤回、能讲清楚是谁起的作用的工程对象。 2. 它在解决什么问题Agent智能体——比如帮你写代码、整理资料的那种 AI表现好不好越来越依赖它身边的harness——也就是用什么工具、看什么规则、记得哪些经验、出错了怎么办这一整套外围设施。 但目前优化 harness主要还是靠人手工干看一堆日志 → 猜哪里出了问题 → 改提示词 → 加规则 → 再试一次。和炼丹差不多。 作者认为让 Agent 自动改进 harness 之所以难不是因为它没想法而是因为有三个绕不过去的坎 **① 可编辑空间不清晰不知道该改哪里**prompt、tool、middleware、memory、sub-agent ——这些组件搅在一起Agent 自己也分不清这次该动哪一块。 **② 轨迹信号被海量日志淹没信息太多反而看不见**每次rollout让 Agent 完整跑一遍任务的过程会产生几百万字的过程记录真正出错的瞬间埋在一堆细节里。直接把这堆原始数据丢给 Agent 让它改它消化不了。 **③ 改动效果难归因搞不清是谁起的作用**就算分数涨了也搞不清是 A 改动起效了还是 B 改动起效了还是 C 改动其实是反作用、只是被别的掩盖了。也就不知道该保留什么、撤回什么。 这篇论文要解决的不是让 Agent 自己写提示词而是怎么让 Agent 稳定地、跨多个层面地把整个 harness 迭代得越来越好。 3. 核心方法 论文提出AHEAgentic Harness Engineering把这套迭代做成一个能自动跑的闭环围绕observability让每一层都看得见搭了三层结构。 3.1 Component Observability组件可观测 把 harness 拆成7 类显式 component可独立编辑的文件模块system prompt系统提示词——角色与原则tool description工具说明——告诉 AI 有什么工具可用tool implementation工具实现——工具自己的代码middleware中间件——管控逻辑、守卫规则skill技能——可复用的做事经验sub-agent configuration子任务配置——多角色协作时的分工long-term memory长期记忆——积累下来的可迁移经验每一类都有固定挂载点、文件级别的 diff修改记录。想改什么、改了什么、要不要回滚撤回一目了然。 3.2 Experience Observability经验可观测 引入一个专门的Agent Debugger调试助手把又长又乱的 rollout 轨迹蒸馏成分层证据task-level单个任务出了什么问题benchmark-level一批任务里有什么共性问题需要时还能下钻回原始 trace原始过程记录也就是不让优化 Agent 直接吃日志垃圾堆而是吃一份结构化的根因分析报告。 3.3 Decision Observability决策可观测 每改一处必须同时写一份change manifest改动说明书本质是一份赌约包含看到的失败证据推断的根因具体修复动作预测会修好的任务可能回归的任务下一轮跑完后系统会自动拿真实结果去对账。预测兑现的改动留下没兑现的按文件粒度回滚。 每次修改都成了一份可被打脸的承诺而不是我觉得这样改挺好。 4. 对普通人和团队的启发 这篇论文的方法论对任何一个想把流程做扎实的团队都有用。 ① 经验不能只活在脑子里要变成 component可被替换的文件 很多团队的最佳实践都是口口相传或者藏在某个人脑子里——人一走就没了新人来了得从头摸。 论文的启发是把经验沉淀成独立的文件或模块让它可以被对比、替换、回滚。今天发现某个做法不灵了能精准换掉而不是把整套流程推倒重来。 ② 日志要做成 observability不只是有记录 很多团队记日志只是为了出事时甩锅用平时没人看。 但真正有价值的记录应该是结构化的、能让人快速看出问题在哪的——比如任务编号 阶段 出错类型 上下文而不是一大段自由文本。observability 这个词的核心不是有日志而是看得见问题、说得清原因、追得到源头。只有做到这一步下次想复盘、想让 Agent 帮你分析才有材料可用。 ③ 写下来的 long-term memory 比反复嘱咐更值钱 论文里有个数据很扎心单独把 long-term memory 这一块换上演化版整体表现就能从 69.7% 拉到 75.3%在难题上甚至到 63.3%。 换成日常工作的语言就是把团队踩过的坑写进可查阅的文档里比每次开会重复强调要有用得多。提示词、口头嘱咐都会衰减写下来的东西不会。 ④ 验收不该只看做没做完还要核对 change manifest 里的预测 大多数团队的复盘只看任务有没有交付。但更值钱的是问一句“上次我们做这个决定时预测的好处和坏处都兑现了吗”这就是 change manifest 的精神——把每个决策都写成一份可被证伪的赌约。长期下来才能知道哪些团队成员的判断更靠谱、哪些做法是真的有效。这件事 Agent 能做人也该做。 ⑤ 多人协作的关键不是加人而是把 sub-agent configuration 做成系统 论文里把多个 Agent 协作的分工方式sub-agent configuration也当成一个可演化的组件。换到团队场景就是多招一个人不会自动让事情变好关键在于角色边界、交接规则、验收标准本身是否清晰、是否在迭代。 很多团队人多了反而更慢就是因为这套协作配置从来没被认真设计过。 ⑥ Prompt 只能定方向tool / middleware / memory 才是真正起作用的 论文有个反直觉的 ablation消融实验——一次只换一个组件看谁起作用只改 system prompt 反而会让效果变差69.7% → 67.4%真正稳定带来提升的是 tools、middleware、memory 这些硬的部分。 对团队的意思是靠开会强调、靠老板嘱咐推动改进效率最低。真正起作用的是把要求做进工具、做进流程、做进新人入职文档里——也就是把 prompt 层的要求下沉到 tool / middleware / memory 层。 5. 论文金句Harness 的自动进化难点不在再找一个更聪明的模型而在让每一层 component、每一段 rollout、每一次改动都 observable——看得见、说得清、撤得回。真正能迁移的经验不是更长的 prompt而是被固化进 tool、middleware 和 long-term memory 里的工程结构。如果一次改动写不出 change manifest——说不清要修什么、可能伤到什么——那它就还不是工程只是试错。Prompt 负责提高做对的概率harness 负责在没做对时仍然能发现、限制、记录并恢复。多 agent 的能力不是多开几个模型而是把角色、上下文、工具和验收关系做成一个可演化的执行系统。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
Harness工程论文解读：Agentic Harness Engineering
一句话结论Agent智能体要变得更好用瓶颈不在再换一个更聪明的模型而在把harnessAgent 身边那一整套支撑系统——工具、规则、记忆、流程做成observable看得见、能撤回、能讲清楚是谁起的作用的工程对象。 2. 它在解决什么问题Agent智能体——比如帮你写代码、整理资料的那种 AI表现好不好越来越依赖它身边的harness——也就是用什么工具、看什么规则、记得哪些经验、出错了怎么办这一整套外围设施。 但目前优化 harness主要还是靠人手工干看一堆日志 → 猜哪里出了问题 → 改提示词 → 加规则 → 再试一次。和炼丹差不多。 作者认为让 Agent 自动改进 harness 之所以难不是因为它没想法而是因为有三个绕不过去的坎 **① 可编辑空间不清晰不知道该改哪里**prompt、tool、middleware、memory、sub-agent ——这些组件搅在一起Agent 自己也分不清这次该动哪一块。 **② 轨迹信号被海量日志淹没信息太多反而看不见**每次rollout让 Agent 完整跑一遍任务的过程会产生几百万字的过程记录真正出错的瞬间埋在一堆细节里。直接把这堆原始数据丢给 Agent 让它改它消化不了。 **③ 改动效果难归因搞不清是谁起的作用**就算分数涨了也搞不清是 A 改动起效了还是 B 改动起效了还是 C 改动其实是反作用、只是被别的掩盖了。也就不知道该保留什么、撤回什么。 这篇论文要解决的不是让 Agent 自己写提示词而是怎么让 Agent 稳定地、跨多个层面地把整个 harness 迭代得越来越好。 3. 核心方法 论文提出AHEAgentic Harness Engineering把这套迭代做成一个能自动跑的闭环围绕observability让每一层都看得见搭了三层结构。 3.1 Component Observability组件可观测 把 harness 拆成7 类显式 component可独立编辑的文件模块system prompt系统提示词——角色与原则tool description工具说明——告诉 AI 有什么工具可用tool implementation工具实现——工具自己的代码middleware中间件——管控逻辑、守卫规则skill技能——可复用的做事经验sub-agent configuration子任务配置——多角色协作时的分工long-term memory长期记忆——积累下来的可迁移经验每一类都有固定挂载点、文件级别的 diff修改记录。想改什么、改了什么、要不要回滚撤回一目了然。 3.2 Experience Observability经验可观测 引入一个专门的Agent Debugger调试助手把又长又乱的 rollout 轨迹蒸馏成分层证据task-level单个任务出了什么问题benchmark-level一批任务里有什么共性问题需要时还能下钻回原始 trace原始过程记录也就是不让优化 Agent 直接吃日志垃圾堆而是吃一份结构化的根因分析报告。 3.3 Decision Observability决策可观测 每改一处必须同时写一份change manifest改动说明书本质是一份赌约包含看到的失败证据推断的根因具体修复动作预测会修好的任务可能回归的任务下一轮跑完后系统会自动拿真实结果去对账。预测兑现的改动留下没兑现的按文件粒度回滚。 每次修改都成了一份可被打脸的承诺而不是我觉得这样改挺好。 4. 对普通人和团队的启发 这篇论文的方法论对任何一个想把流程做扎实的团队都有用。 ① 经验不能只活在脑子里要变成 component可被替换的文件 很多团队的最佳实践都是口口相传或者藏在某个人脑子里——人一走就没了新人来了得从头摸。 论文的启发是把经验沉淀成独立的文件或模块让它可以被对比、替换、回滚。今天发现某个做法不灵了能精准换掉而不是把整套流程推倒重来。 ② 日志要做成 observability不只是有记录 很多团队记日志只是为了出事时甩锅用平时没人看。 但真正有价值的记录应该是结构化的、能让人快速看出问题在哪的——比如任务编号 阶段 出错类型 上下文而不是一大段自由文本。observability 这个词的核心不是有日志而是看得见问题、说得清原因、追得到源头。只有做到这一步下次想复盘、想让 Agent 帮你分析才有材料可用。 ③ 写下来的 long-term memory 比反复嘱咐更值钱 论文里有个数据很扎心单独把 long-term memory 这一块换上演化版整体表现就能从 69.7% 拉到 75.3%在难题上甚至到 63.3%。 换成日常工作的语言就是把团队踩过的坑写进可查阅的文档里比每次开会重复强调要有用得多。提示词、口头嘱咐都会衰减写下来的东西不会。 ④ 验收不该只看做没做完还要核对 change manifest 里的预测 大多数团队的复盘只看任务有没有交付。但更值钱的是问一句“上次我们做这个决定时预测的好处和坏处都兑现了吗”这就是 change manifest 的精神——把每个决策都写成一份可被证伪的赌约。长期下来才能知道哪些团队成员的判断更靠谱、哪些做法是真的有效。这件事 Agent 能做人也该做。 ⑤ 多人协作的关键不是加人而是把 sub-agent configuration 做成系统 论文里把多个 Agent 协作的分工方式sub-agent configuration也当成一个可演化的组件。换到团队场景就是多招一个人不会自动让事情变好关键在于角色边界、交接规则、验收标准本身是否清晰、是否在迭代。 很多团队人多了反而更慢就是因为这套协作配置从来没被认真设计过。 ⑥ Prompt 只能定方向tool / middleware / memory 才是真正起作用的 论文有个反直觉的 ablation消融实验——一次只换一个组件看谁起作用只改 system prompt 反而会让效果变差69.7% → 67.4%真正稳定带来提升的是 tools、middleware、memory 这些硬的部分。 对团队的意思是靠开会强调、靠老板嘱咐推动改进效率最低。真正起作用的是把要求做进工具、做进流程、做进新人入职文档里——也就是把 prompt 层的要求下沉到 tool / middleware / memory 层。 5. 论文金句Harness 的自动进化难点不在再找一个更聪明的模型而在让每一层 component、每一段 rollout、每一次改动都 observable——看得见、说得清、撤得回。真正能迁移的经验不是更长的 prompt而是被固化进 tool、middleware 和 long-term memory 里的工程结构。如果一次改动写不出 change manifest——说不清要修什么、可能伤到什么——那它就还不是工程只是试错。Prompt 负责提高做对的概率harness 负责在没做对时仍然能发现、限制、记录并恢复。多 agent 的能力不是多开几个模型而是把角色、上下文、工具和验收关系做成一个可演化的执行系统。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
