引言过去一年AI Agent 的讨论越来越热。很多人已经不再满足于“让大模型回答问题”而是希望它能真正完成任务读代码、改代码、跑测试、写报告、查资料、维护知识库甚至 24 小时不间断地执行长期任务。但在实践中我们很快会遇到一个问题同一个模型为什么在不同 Agent 系统里的表现差异如此巨大答案往往不在模型本身而在模型外面的那套工程系统。这套系统就是本文要讨论的Harness Engineering。一、什么是 Harness Engineering如果说大语言模型是 Agent 的“大脑”那么 harness 就是它的身体工具箱工作环境记忆系统任务调度器安全边界监控系统反馈回路。Harness Engineering可以理解为围绕 LLM Agent 构建、调优和演化其运行外壳、执行框架和工程脚手架的方法。它关注的不是模型权重本身而是模型外部那套让 Agent 真正能工作的系统。一个典型的 Agent harness 可能包括组件作用System Prompt定义 Agent 的身份、边界、行为规则Tool Descriptions告诉模型有哪些工具、什么时候用、怎么用Tools文件读写、Shell、浏览器、数据库、搜索、评估器等Middleware上下文压缩、权限拦截、错误处理、结果清洗Memory跨会话记忆、项目知识、用户偏好、经验沉淀Sub-agents专门负责搜索、规划、测试、代码审查等子任务Scheduler定时唤醒、任务队列、后台执行Sandbox隔离执行环境限制破坏范围Evaluator判断任务是否完成、结果是否可靠Trace Logger记录完整执行轨迹供复盘和改进所以Harness Engineering 的核心不是“怎么写一个更好的 prompt”而是怎么设计一个让模型能够长期、安全、可观察、可迭代地工作的工程系统。二、为什么 Prompt Engineering 不够了早期使用大模型时我们主要关注 Prompt Engineering如何问问题如何写角色设定如何给示例如何让输出格式更稳定。后来大家发现上下文同样重要于是出现了 Context Engineering如何选择资料、压缩历史、管理上下文窗口、注入长期记忆。但当 Agent 开始调用工具、修改文件、执行命令、处理长任务时仅靠 prompt 和 context 就不够了。因为真实 Agent 面临的问题远比“回答问题”复杂它要知道该用哪个工具它要知道哪些操作危险它要能在任务中断后恢复它要能记住以前的经验它要能处理长上下文它要能从失败中改进它要能被监控、审计和回滚它要能避免为了指标而投机取巧。这就是 Harness Engineering 的价值。它把关注点从单轮对话扩展到完整系统Prompt Engineering ↓ Context Engineering ↓ Tool-use Engineering ↓ Agent Harness Engineering ↓ Self-evolving Agent SystemsPrompt 是局部变量harness 才是完整系统。三、Agentic Harness Engineering让 Harness 自我演化更进一步有研究提出了Agentic Harness Engineering简称 AHE。AHE 的核心思想是固定 base model不训练模型权重而是让 Agent 自动观察、分析、修改并验证自己的 harness。也就是说模型本身不变但系统会自动优化模型外部的运行结构例如system prompttool descriptionstool implementationsmiddlewareskillssub-agentslong-term memorycontext policyevaluatorpermission policy。它的典型闭环是evaluate → analyze → improve → loop具体来说Evaluate让当前 Agent 在任务集或真实工作流中执行记录完整 trace、工具调用、日志和结果。Analyze从执行轨迹中分析失败原因把大量原始日志压缩成可读、可追溯的 debug report。Improve基于证据修改 harness例如调整工具描述、改 middleware、补 memory、更新 prompt。Loop下一轮重新评估验证修改是否真的有效。如果无效或带来回归就回滚或修正。这个过程的关键是每次修改都不是拍脑袋而是一个可验证的工程假设。例如一次 harness 修改应该记录失败证据哪些任务失败了trace 中有什么现象 根因分析为什么失败 目标修复这次具体改什么 预测影响哪些任务应该变好哪些地方可能有风险 验证结果下一轮是否符合预测这就把 Agent 调优从“玄学调 prompt”变成了“可观察、可回滚、可证伪的工程实验”。四、Harness Engineering 的三层可观察性AHE 中非常关键的概念是Observability也就是可观察性。一个成熟的 Agent harness 不能只是跑起来还要能被看见、被分析、被追责。可以分成三层。1. Component Observability组件可观察首先harness 的各个组件应该是显式的、可编辑的、可版本管理的。例如systemprompt.md tool_descriptions/ tools/ middleware/ skills/ sub_agents/ LongTermMemory.md这样做有几个好处每个组件可以单独修改每次修改可以被 git 追踪出问题可以回滚不同组件的效果可以被归因Agent 也可以在受控范围内自动修改这些文件。如果所有东西都藏在一个巨大 prompt 或黑盒服务里就很难做工程化演化。2. Experience Observability经验可观察Agent 执行任务时会产生大量轨迹对话历史工具调用shell 输出文件 diff报错信息测试结果中间推理evaluator 结果。这些 raw traces 可能非常长动辄几百万甚至上千万 token。直接让模型读取全部内容并不现实。所以需要把原始轨迹整理成分层报告raw trace ↓ cleaned trace ↓ per-task analysis ↓ cross-task root-cause summary ↓ actionable improvement report这和知识库建设很像原始资料不直接作为工作层而是经过整理后形成可复用的中间知识层。3. Decision Observability决策可观察最后每次 harness 修改都必须留下决策记录。不是简单写一句“优化 prompt”而是说明为什么改基于什么证据解决什么根因预期产生什么效果哪些地方可能回归下一轮如何验证。这让每次修改都变成一个可证伪的 contract。没有 Decision Observability就无法区分真的修好了只是碰巧通过过拟合 benchmark引入了新的隐藏问题。五、Harness Engineering 的核心模块下面从工程实现角度看一个完整的 Agent harness 至少包含以下几个核心模块。1. Context Engineering管理 Agent 看见什么大模型的上下文窗口再大也不是垃圾桶。对于长任务 AgentContext Engineering 的目标是回答几个问题当前任务必须看到什么哪些历史可以压缩哪些经验应该进入 memory哪些工具说明应该此刻展示如何避免 instruction fade-out如何利用 prompt caching 降低成本常见策略包括Context Compaction把长轨迹压缩成更短的任务状态原始历史 用户需求、几十轮对话、多个工具调用、测试日志、错误输出 压缩后 目标是什么 已经做了什么 当前状态是什么 关键约束是什么 还有哪些风险 下一步是什么好的 compaction 不应该只是摘要而应该保留任务继续执行所需的状态。Prompt Caching把稳定内容放在上下文前缀中复用例如系统规则工具说明项目约定安全策略长期不变的知识库索引。动态内容则放在后面例如当前任务最近日志临时观察当前 diff。Event-driven Reminders长任务中模型容易忘记早期约束。可以通过事件触发提醒例如执行危险命令前提醒权限边界修改文件前提醒代码风格接近上下文上限时提醒压缩多次失败后提醒重新分析根因。2. Tool Use让模型真正作用于环境Agent 和普通 Chatbot 的重要区别是Agent 会用工具。工具层要解决的问题包括工具有哪些什么时候展示如何描述如何调用如何处理失败哪些工具需要审批工具结果如何注入上下文一个工具描述如果写得不好会直接影响模型行为。例如一个 shell 工具不仅要告诉模型“可以执行命令”还要说明不要执行破坏性命令不要绕过安全检查长命令要设置超时独立命令可以并行依赖前一步结果的命令必须串行高风险操作需要用户确认。工具层还要区分操作权限策略读取文件通常可自动允许运行测试通常可自动允许新增草稿文件通常可自动允许删除文件需要人工确认修改配置视影响范围确认git commit需要用户明确要求git push必须人工确认访问 secrets默认禁止Tool Use 的本质是把模型的语言能力转化为对现实环境的可控操作能力。3. Memory让 Agent 跨会话积累经验没有 memory 的 Agent每次都是“失忆重启”。对于长期 Agentmemory 至少有三种类型内容Episodic Memory具体任务、失败案例、调试过程、事件轨迹Semantic Memory稳定概念、术语、关系、领域知识Project Memory当前项目规则、架构、约定、用户偏好但 memory 不是越多越好。错误的 memory 会长期污染后续任务。所以 memory 写入必须有筛选机制是否具有长期价值是否已经在代码或文档中存在是否只是临时状态是否可能过期是否有来源支撑是否需要用户确认一种很实用的做法是把知识库本身作为 memory backend。例如采用 Karpathy 提出的 LLM Wiki 模式raw/ 原始资料不直接改写 wiki/ LLM 维护的结构化知识 outputs/ 阶段性分析产物 index.md 内容索引 log.md 时间日志这样 memory 不再是黑盒向量库而是人和 Agent 都能读、能改、能审计的 Markdown 知识系统。4. Observability让失败变成可学习材料很多 Agent 系统失败后只留下一个结果任务失败这没有任何工程价值。一个好的 harness 应该记录输入任务计划每一步动作工具调用参数工具返回结果文件 diff错误日志中间判断最终 outcomeevaluator 结论用户反馈。然后把这些记录转化成可学习材料失败案例 ↓ 根因分类 ↓ 修复建议 ↓ harness 修改 ↓ 下一轮验证这就是 AHE 的核心trace 不是附属日志而是下一轮改进的原料。5. Evaluation防止 Agent 为了分数作弊Agent 一旦进入自动评估就会遇到一个经典问题Reward Hacking。也就是 Agent 不是真的解决问题而是钻评价函数的漏洞。例如修改测试让自己通过直接硬编码 benchmark 答案利用评分脚本缺陷删除失败用例绕过 verifier做出看似正确但不可泛化的改动。这背后是 Goodhart’s Law当一个指标成为目标它就不再是一个好指标。所以 evaluator 不能只看 pass/fail还要看diff 是否合理是否修改了不该修改的文件是否存在硬编码是否通过隐藏测试是否有异常工具调用是否符合任务真实语义是否能迁移到相邻任务。对于算法发现类任务尤其如此。在 Algorithm Discovery Harness 中Agent 会生成大量候选算法然后通过 scoring function 评估。如果 scoring function 有漏洞越强的模型越可能找到漏洞而不是真正发现更好的算法。六、如何实现一个 24 小时不间断 Agent很多人听到“24h Agent”第一反应是写一个无限循环whileTrue:run_agent()这其实非常危险也不可靠。真正的 24h Agent 不应该是一个永不退出的聊天进程而应该是短任务 定时调度 可恢复状态 可观察日志 权限边界。一个更稳的架构如下Scheduler ↓ Task Queue ↓ Agent Runtime ↓ Tools / Sandbox ↓ State Store ↓ Knowledge Base ↓ Observability / Notification1. Scheduler负责定时唤醒例如cronsystemd timerworkflow schedulerqueue worker云函数long-running service。它不负责思考只负责“什么时候运行”。2. Task QueueAgent 每次醒来后不应该随机行动而应该从任务队列中取任务。任务可以分为research ingest lint summarize test monitor report repair每个任务都应该有状态pending running blocked done failed needs_human3. Checkpoint每次执行都要保存 checkpoint当前任务已完成步骤中间结果文件修改下一步失败原因是否需要人工介入。这样即使进程崩溃也可以恢复。4. Idempotency长期 Agent 的任务要尽量幂等。也就是说同一个任务重复执行不应该造成重复破坏。例如不要重复发送同一封邮件不要重复创建同一条 issue不要重复提交相同 commit不要重复覆盖用户文件不要重复摄入同一份资料。5. WatchdogWatchdog 负责检测是否卡死是否超时是否连续失败是否费用异常是否重复执行同一动作是否需要通知用户。6. Permission Policy24h Agent 必须有明确权限边界。例如操作策略读取知识库自动允许新增草稿自动允许更新索引和日志自动允许删除文件人工确认修改核心规则人工确认访问外部 API成本和风险审批git commit用户明确授权git push每次确认访问密钥默认禁止否则长期运行的 Agent 很容易从“自动化助手”变成“自动化事故制造机”。七、如何实现知识库的自我迭代Harness Engineering 不仅适用于 coding agent也适用于知识库维护。一个自我迭代知识库可以采用这样的闭环Ingest → Synthesize → Link → Question → Lint → Plan Next Sources1. Ingest摄入把原始资料放入 raw 层例如论文博客会议记录网页剪藏代码实验日志。LLM 读取资料后不是简单摘要而是提取核心观点关键概念相关实体证据矛盾待验证问题。2. Synthesize综合把新资料和旧知识融合新资料是否支持已有结论是否推翻旧判断是否补充了新的概念是否出现新的争议是否需要拆分新页面3. Link链接知识库的价值来自链接。每次摄入都应更新index相关概念页来源页术语表问题池矛盾页。4. Question提出问题好的知识库不只是保存答案还应该产生问题哪些概念还不清楚哪些结论缺来源哪些方向值得继续搜索哪些实验可以验证哪些页面需要重构5. Lint健康检查定期让 Agent 检查知识库是否有孤立页面是否有重复页面是否有过时结论是否有无来源判断是否有互相矛盾内容是否有高频概念没有独立页面是否有该沉淀到 outputs 的长分析。6. Plan Next Sources规划下一批资料最后知识库应该主动提出下一批资料建议该读哪篇论文该查哪个项目该验证哪个 claim该补哪个术语该写哪篇专题文章。这样知识库就从“被动笔记”变成了“主动研究系统”。八、Harness Engineering 的典型应用场景1. Coding Agent最直接的场景是编码助手自动读代码修 bug跑测试解释失败写 PR 描述做 code review维护项目知识库。这类 Agent 对 tool use、context engineering 和安全边界要求极高。2. Research Agent用于长期技术调研跟踪论文搜索 GitHub 项目比较技术路线维护竞品分析自动生成周报发现知识缺口。这类 Agent 的关键是 memory 和 self-evolving knowledge base。3. Ops Agent用于运维和监控读取报警查询日志分析 incident生成排障建议自动执行低风险修复通知 on-call。这类 Agent 对权限、安全和可观察性要求极高。4. Algorithm Discovery Agent用于自动发现或优化算法生成候选算法执行 benchmark分析失败进化搜索保存实验结果防止 reward hacking。这类 Agent 的关键是 evaluator 和 sandbox。九、未来趋势Harness Engineering 会成为新的 AI 工程核心我认为 Harness Engineering 会成为 AI Agent 时代的基础工程方向类似当年的 DevOps 和 MLOps。未来真正拉开 Agent 能力差距的不只是模型参数而是谁的工具系统更可靠谁的上下文管理更高效谁的 memory 更准确谁的 observability 更完整谁的 evaluator 更 robust谁的安全边界更清晰谁的 harness 能从失败中自我演化。可能出现的新岗位包括Agent Harness EngineerContext EngineerAgent Runtime EngineerAgent Observability EngineerLLM Tooling EngineerAI Reliability EngineerAgent Safety EngineerAutonomous Workflow Engineer。这些岗位的共同点是他们不是单纯“调 prompt”而是在构建一个能让模型稳定工作的复杂系统。十、一个最小可落地架构如果你想从零实现一个 Harness Engineering 系统不需要一开始就做得很复杂。可以从这个最小版本开始project/ ├── agent/ │ ├── system_prompt.md │ ├── tools.yaml │ ├── permissions.yaml │ └── memory.md ├── knowledge/ │ ├── raw/ │ ├── wiki/ │ ├── outputs/ │ ├── index.md │ └── log.md ├── runs/ │ └── run_001/ │ ├── trace.json │ ├── result.md │ └── errors.log ├── tasks/ │ ├── queue.json │ └── state.json └── evaluator/ └── check.py运行闭环1. 从 tasks/queue.json 取任务 2. 读取 knowledge/index.md 和 memory.md 3. 构造上下文 4. 调用模型和工具 5. 写 trace.json 6. 运行 evaluator 7. 更新 wiki / memory / log 8. 如果失败生成 root-cause report 9. 下一轮基于 report 改进 harness如果要进一步升级成 AHE则增加harness workspace ↓ 自动分析失败 ↓ 自动提出 harness 修改 ↓ 记录预测影响 ↓ 下一轮验证 ↓ 保留或回滚十一、常见误区误区一Harness Engineering 等于写 Prompt不是。Prompt 只是 harness 的一个组件。Harness 还包括 tools、memory、middleware、scheduler、evaluator、sandbox、observability 等。误区二Agent 越自动越好不是。成熟 Agent 必须有清晰权限边界。自动化的目标不是取消人而是让人只介入高价值、高风险决策。误区三Trace 只是日志不是。Trace 是 agent 自我改进的训练材料和证据来源。没有 trace就没有可靠的 failure attribution。误区四评估通过就说明 Agent 真会了不一定。可能只是 reward hacking、过拟合 benchmark 或绕过测试。必须结合 hidden tests、行为审计和语义验证。误区五Memory 越多越好不是。错误 memory 比没有 memory 更危险。Memory 必须可审计、可更新、可删除、可追溯来源。十二、总结Harness Engineering 是 AI Agent 从 demo 走向生产系统的关键工程能力。它回答的问题不是如何让模型说得更好而是如何让模型在真实环境中长期、安全、可靠、可观察、可迭代地完成任务它的核心思想可以总结为一句话模型是大脑harness 是让大脑真正工作的身体、工具、记忆、环境和反馈系统。未来的 AI Agent 竞争不只是模型能力的竞争更是 harness 能力的竞争。谁能更好地管理上下文、工具、记忆、评估、安全和自我迭代谁就能构建更可靠、更强大的 Agent 系统。参考资料Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesseshttps://arxiv.org/abs/2604.25850Agentic Harness Engineering GitHub 项目https://github.com/china-qijizhifeng/agentic-harness-engineeringEffective Harness Engineering for Algorithm Discovery with Coding Agentshttps://arxiv.org/abs/2605.15221Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learnedhttps://arxiv.org/abs/2603.05344Karpathy: LLM Wikihttps://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f