如何构建持续进化的 Agent：模型、Harness 与上下文的改进路径

同样一个错误，如果每次都要人重新指出来，Agent 就只是在重复完成任务。要让它越用越好，得把一次失败转变成下一次执行时真正生效的改变。

这件事至少涉及三个问题：哪里出了错，该改什么，以及怎样知道修改有效。

LangChain 联合创始人 Harrison Chase 在近期的讲座中给出了一套很实用的拆解方式：先把 Agent 分成模型、Harness 和上下文，再用运行轨迹与评估把它们串联起来。

先判断，问题应该改在哪一层

模型负责推理和决策。 不同模型在速度、上下文容量与任务能力上各有取舍。除了驱动 Agent 的核心模型之外，系统里往往还有负责护栏与评估的辅助模型。

Harness 负责让决策变成动作。 它决定模型看到什么，调用工具执行什么，怎样观察和验证结果，以及如何保存文件和状态。文件系统、沙箱、上下文管理、人工介入和子智能体，都可以纳入这套执行系统。

上下文负责提供完成任务所需的知识。 它可以是 Markdown 文件、项目说明、组织知识或用户偏好。模型有没有能力，和它是否拿到了必要信息，是两个需要分别检查的问题。

模型、Harness 与上下文共同构成智能体。

这样拆开后，“让 Agent 学会一件事”就有了更具体的含义：可以更新模型权重，可以改执行逻辑，也可以补充它下一次会读取的知识。

模型层：从好轨迹中学习，或在任务中训练

监督微调的思路，是收集运行轨迹，筛选出希望模型学习的样本，再用这些样本训练模型。它比较适合分类、抽取、摘要这类定义清楚的任务。

演讲中的 smithtune 流程将这条路线串了起来：从 LangSmith 获取轨迹，筛选处理数据，再交给提供训练接口的模型服务商，最终得到调整后的模型。

强化学习则从任务出发：让 Agent 执行任务，对执行结果评分，再更新权重，继续新一轮尝试。它需要处理的环节更多，但为复杂任务提供了另一条改进路线。

权重更新涉及训练数据、时间和资金，通常值得由人明确决定何时启动。诊断阶段先分清问题发生在哪一层，才能判断是否需要承担这部分成本。

Harness 层：把一次排错变成系统修改

如果问题出在工具、提示词或执行逻辑上，改进路径可以从轨迹开始：查看过程，识别问题，修改代码或指令，再验证效果。

LangSmith Engine 展示了其中一部分如何自动化。后台 Agent 查看轨迹，把相似问题聚在一起，然后提出修复建议、代码变更、测试或新增评估样本。

LangSmith Engine 将监测、构建、测试和部署连成循环。

Harness 的核心逻辑通常影响所有用户，因此修复建议需要经过审查。后台流程负责发现与准备，人负责判断是否接受变更——这是一种可以逐步推进的协作方式。

上下文层：把使用经验写进下一次能读到的知识

上下文往往只是文本，修改成本相对低，还可以按不同范围保存：整个 Agent 共用的知识、组织层面的知识，以及单个用户的记忆。

Hex 的例子很直观。它的数据分析 Agent 有一个统一上下文层，Review Agent 在后台分析交互，找出知识缺口并建议修正。一次使用暴露出的问题，可以进入下一轮上下文更新。Profound 则同时维护品牌层面的 Brand Records 和来自用户交互的 Personal Records，让共享知识与个人偏好各有存放位置。OpenWiki 把类似思路用于编程：先从代码仓库建立知识，再从编程 Agent 的运行轨迹里观察它遇到了什么困难，把相关知识补回去。

上下文可以在用户或组织层面持续更新。

这条路线的难点，是选择值得保留的内容，以及决定它应该影响谁。一次交互里出现的信息，要经过整理，才能成为以后有用的记忆。

Traces 记录发生了什么，Evals 定义什么算好

一次模型调用或工具调用，可以看作一个 run。一次请求中的多个执行步骤组成 trace；多轮交互形成 thread；trajectory 则提供标准化的查看方式。

这些记录需要留下准确的输入、输出和发生顺序，这样才能看清：Agent 读到了什么，为什么调用这个工具，执行之后环境变成了什么。

很多 Agent 错误藏在语义和对话关系里。工具可能执行成功了，Agent 却理解错了用户目标。排查时就需要结合上下文查找问题，演讲中的 AI Search 正是用自然语言条件筛选相关轨迹。

看清过程之后，还要定义好结果。所谓“Evals 是新的 PRD”，就是把抽象的产品要求，写成具体输入与可判断的预期行为。

有些任务适合精确匹配某个数字或输出；复杂任务则更适合使用标准：答案必须包含什么，不得包含什么，数据库最后应处于什么状态，工具调用是否遵循要求。

对于会修改文件和数据库的 Agent，环境最终状态尤其关键。它声称自己完成了任务，还需要与实际动作的结果对应起来。

评估真正难在输入、标准和环境

真实用户会提出意料之外的问题。生产轨迹能够帮助补齐评估输入，让测试逐步接近实际使用。

好结果的标准同样需要领域知识。业务专家必须把“这样才算做对”拆成可检查的要求，评估才能指导后续改动。

最后，Agent 需要一个可以执行动作的测试环境。模拟数据库、开发环境或服务替身，让它能运行端到端流程，也让评估能够检查动作造成的变化。

仅靠等待生产失败出现，可能错过低频却严重的问题。红队测试可以主动构造探测，寻找正确性、安全性和公平性等方面的缺陷。

例如，可以向 Agent 提出语义相近的问题，比较回答中的关键结论，沿着明显分歧继续调查。这样的探测适合放在专门的测试过程中，为排错提供线索。

Harrison Chase 明确地指出，Evals 就是 Agent 时代的 PRD，它需要定义清楚什么叫“好”，而这点恰恰是最困难的。

让一次错误留下可验证的改进

把前面的环节连起来，就得到一个持续改进的闭环：运行 Agent，收集反馈，检查相关轨迹，把问题加入评估集，再提出模型、Harness 或上下文层面的修改。

新增评估样本，让这次问题在以后仍然可见；保留此前的评估样本，让团队能检查修改是否带来其他回退。

更进一步，可以尝试让 Agent 自己发现错误、建立评估案例并建议修复。要朝这个方向前进，先让每一次人工排错都留下轨迹、测试和可复用的修改，就是具体的一步。

来源：Harrison Chase：How to Build Agents That Improve Over Time[1]

引用链接：

[1] Harrison Chase：How to Build Agents That Improve Over Time: https://www.youtube.com/watch?v=xy_7SzwsIjM