你的 Agent Harness 应该自我修复

作者：Avi Chawla（@_avichawla，DailyDoseOfDS 联合创始人，前 Mastercard AI 工程师）

Agent 完成一个难任务之后，可以把这次奏效的做法存下来，下次直接复用。这是一种有用的运行时学习：改进存在于模型权重之外，能跨会话保留。

生产环境里的失败则是另一回事。有用的信息散落在执行 trace、工具返回值、本地代码、配置和最终结果里。一个补丁可以修掉这次事故，但只有系统同时记录下「应该发生什么」并再测一次，这次失败才会变成可复用的知识。

于是 agent 的自我改进有了两条各自独立的回路：

成功的运行，可以产出可复用的流程。

失败的运行，可以产出经过审查的修复和回归用例。

不做权重更新也能让 agent 变强

模型不需要更新权重，agent 系统就能变强。它改的是模型周围的产物：指令、skills、工具描述、检索策略、配置、评估用例。只要后续运行使用了这些改动，即使底层模型一模一样，系统行为也已经变了。

这个区分很重要，因为 agent 的失败很少是「最后一句答错了」。agent 会连续做决策：选工具、拼参数、解读结果、更新计划、决定何时停下。所以一份有用的学习记录需要的不是最终输出，而是足以定位「哪一步决策错了」的证据。

Hermes 里的程序性记忆

Hermes Agent 把 skills 当作程序性记忆。完成复杂任务后，它可以把有用的方法写进 SKILL.md。后来的任务可以直接加载这个 skill，而不是重新推导同样的流程。

存下来的产物可读、可编辑：它能写明这套流程在什么情况下适用、用哪些工具、按什么顺序、哪些约束必须保持成立。相比权重更新，这种学到的行为更容易检查。

Hermes 还会长期维护这批 skill：curator 会改写描述不清的条目、合并重叠的、删掉过时的。这种维护是必要的——skill 目录无限膨胀，本身就会变成一个检索问题。

另一条路是 Hermes Forge，用 GEPA（Genetic-Pareto Prompt Evolution）在 prompts、skills、工具描述的变体上做搜索。GEPA 跑在 agent 循环之外：在一组定义好的任务上评估候选变体，用执行反馈提出新候选，保留那些在满足约束的前提下提升目标的变体。这是对文本和配置做的优化，不是 GPU 微调。

两个机制解决的是相关但不同的问题：运行时创建 skill，保存下任务中奏效的流程；离线演化，在一组评估集上比较变体。

Hermes skill 回路的边界

成功运行之后保存下来的流程，继承了 agent 对那一次运行的判断。任务可能完成了，但用的是脆弱的方法、不必要的贵路线，或者只是碰巧成立过的假设。

自动更新 skill 还有相关风险：生成的修订可能用更弱的版本覆盖精心写过的指令，除非系统对改动做了版本管理、并在提升之前先评估。

离线优化也有边界：结果取决于喂给它的用例和目标。只在生产输入下才会出现的失败，不会影响优化器，直到有人把这个用例抓下来并给出有用的评估信号。

Trace 记录了事故，但它不会自己把事故变成行为改变。

用 Opik 把生产失败变成反馈

一次生产事故要变成可复用的知识，系统需要记录四类信息：

第一个偏离预期的步骤。

故障来自模型、工具、配置还是应用代码。

那个既能修正故障、又不掩盖其他问题的改动。

如果同样的行为再次出现就会失败的测试。

Opik 把这些记录连在一个调试工作流里。它的 Hermes 插件把每一轮 agent 对话记成一条根 trace，模型调用和工具调用各有自己的 span。

完整的序列是：

失败的 trace → 诊断 → 提议 diff → 人工批准 → 重跑 → 回归测试

每一阶段都为下一阶段产出证据。这个工作流不允许 agent 未经审查就改生产代码，也不把「看起来合理的补丁」当作事故已解决的证明。

执行 trace

opik-hermes 插件为每一轮 Hermes turn 抓一条根 trace。模型 span 里有消息、输出、provider、token 用量和成本；工具 span 里有工具参数和返回结果。

这个结构的重要性在于：看得见的错误往往出现在真正的故障之后。最终答案错了，可能是因为前面某次搜索什么都没返回、某个工具收到了畸形的参数，或者 agent 接受了一个无效的中间结果。span 树保留了这条因果顺序。

失败检测

有些失败是明确的异常，另一些则正常结束，但工具选得差、答案不完整、延迟过高或者成本异常。Opik 可以通过错误状态、反馈评分、在线评估、延迟和成本把这些候选失败捞出来，也可以用阈值把事件发到 Slack、PagerDuty 或 webhook。

检测只是找出需要调查的运行，它不判断根因，也不决定该改哪个产物。

trace 与源码级诊断

trace 解释运行时发生了什么；根因分析通常还需要产生它的源码和配置。在项目目录里跑 opik connect，会给 Ollie 一个只作用于该会话的项目访问权：它可以查看相关文件、与失败的 span 树比对，并提出 Git 风格的 diff。写文件仍然需要显式批准。

作者的实测：让 Hermes 安装 pip-audit 并扫描当前 Python 环境。运行在环境验证阶段就失败了。trace 显示了失败，连接的配置解释了原因——execute_code 工具用了不被支持的 cloud_runner 环境值。Ollie 提出了一个很小的配置改动，并说明它对应哪个验证错误；diff 一直保持待批准状态，直到他点了同意。

Ollie 负责 trace 和代码分析，开发者决定诊断和 diff 是否成立。

重跑与 Agent Sandbox

批准只代表允许改动生效，验证需要再跑一次。Ollie 可以用原始 trace 的输入重跑，更新后的执行会作为新 trace 回到 Opik，与失败那次直接对比。批准配置改动之后，同一条 pip-audit 请求第二次跑通了。

Opik 的 Agent Sandbox 通过 Agent Playground 覆盖更广的交互式测试。opik endpoint 会在本地运行 agent 并把它暴露在 Opik UI 里，然后可以测试 prompt、模型设置和工具定义，每次执行都生成完整 trace。

两条命令的分工：opik connect 让 Ollie 访问项目，做源码检查、经批准的文件改动和重跑；opik endpoint 在本地运行 agent 并接到 Agent Playground，做交互式测试。需要同时做代码级诊断和受控测试时，两条一起跑。

回归测试

失败的输入只有在系统记录了「下次应该发生什么」之后才变得可复用。Opik Test Suites 把这些期望写成自然语言断言，由 LLM judge 对照 agent 输出判定通过或失败。执行策略还可以要求多次成功——agent 是非确定性的，这一点很重要。

测试套件本身并不教会 Hermes 什么，是 Hermes 加 Opik 的组合为 prompt 修订、工具更新、配置改动和 skill 演化提供了持久的评估信号。每一个候选改动在发布前都要对照同一个失败做检查。

合并起来的工作流

Hermes 在执行期间保存被证明有用的方法，离线优化器把新的 skill、prompt、工具描述变体拿去和任务集比对。Opik 提供生产证据：记录执行、支持 trace 级诊断、把代码改动留在批准之后、重跑原始输入、把期望行为存成回归用例。

于是得到一个更完整的回路：Hermes 完成任务并保存可复用的流程；生产运行在 Opik 里生成 trace 和反馈；失败的 trace 被拿去和项目源码对照诊断；开发者审查提议的改动；用原始输入对更新后的 agent 重跑；失败与期望行为变成一个测试用例；后续改动都要对着累积起来的测试套件评估。

系统并不是在从每一次生产事故里自动学习。它把生产事故变成结构化、可审查的改进输入。这个更窄的说法，才是真正有用的那个。

评估和发布的约束

这条回路改善了反馈路径，但没有消掉 agent 评估里最难的部分。

失败的挑选仍然重要。超时、错误答案、非法工具调用需要不同的断言；把每一条异常 trace 都变成测试，会得到一个充满噪音的套件。

LLM judge 不是 ground truth。自然语言断言做行为检查很方便，但 schema、退出码、数据库状态和精确的工具参数，仍然应该用确定性校验器。

一次重跑通过只能证明一个用例。补丁仍可能影响其他任务；在把它当成安全发布之前，需要更广的套件和重复执行。

学到的产物需要版本管理。skills、prompts、工具描述、配置和测试都应该和引入它们的改动绑在一起，否则团队无法解释行为为什么变了，也无法回滚一次糟糕的更新。

这些约束是设计的一部分，不是例外。当反馈可观察、改动可审查、结果又被拿去对照原来失败的行为测试过，agent 的改进才变得可靠。

原文：https://x.com/i/article/2098680438302932992

#Agent #Harness #可观测性

编者提示一：这篇内容对普通读者最直接的用法，是把它当作一次可以照着跑的 AI 工作流示范。建议先挑文中提到的一款工具（如 ChatGPT、Claude、Grok Bot 或对应的开源模型），把作者演示的输入、配置和调用步骤在自己的写作、编程或日常办公任务上小规模复现一遍，再评估生成结果与投入时间的性价比。

编者提示二：如果你正在用 AI 提升效率或探索第二收入，读这篇时建议带着三个问题：作者具体输入了什么材料、做了哪些设置与测试、最终输出了什么可交付的成果。把这三点套用到自己的场景，能快速判断这套方法是否值得迁移。

所属专题

本文收录于以下专题：

• DeepSeek Harness 从入门到精通

原文信息

作者：yibie（@yibie）

原文地址：