提升 Agent 本质是数据挖掘问题，大多数人第一步就搞错了

做 Agent 的人最容易犯的错，就是把“调 prompt”当成第一优先级。结果折腾了几周，模型该犯的错还是在犯，而且你根本说不清到底是工具设计问题、记忆没对齐，还是模型本身就不适合这个任务。

LangChain Labs 负责人 Vivek Trivedy 在 2026 年 7 月的一篇博客里把这个问题说透了：提升 Agent 本质上是个数据问题，不是 prompt 问题。他说 Continual Learning、Harness Engineering、Post-Training 这三件事，底层其实是同一套东西——大规模整理数据，跑实验，再把结果回灌给 Agent。

这篇文章里，我会把这条思路拆成一套前端工程师也能直接用的四步流程。

一、为什么大多数人第一步就错了

现在市面上大多数 Agent 教程都在教你怎么写更好的 system prompt、怎么编排工具、怎么调 temperature。这些当然有用，但它们解决的是“模型知不知道该做什么”，而不是“模型做错了你有没有办法发现和修复”。

Trivedy 的核心观点是：Traces 是 Agent 改进的货币。

Agent 的行为比传统代码更黑盒。你光读代码，猜不到它在真实环境里会怎么跑；它用工具、查记忆、做决策，每一步都可能偏。Trace 把这些动作投影成可读数据，让你能像排查线上 Bug 一样排查 Agent。

但这里有个现实问题：现代 Agent 产生的数据量极其夸张。一次真实任务可能产生几十万甚至上百万 token 的 trace，靠人看根本看不完。于是问题就变成了：你怎么从海量 trace 里，低成本地找到值得改进的信号？

二、四个阶段，把数据挖掘变成 Agent 的自动改进循环

Trivedy 给了一套很具体的实践路径。

1. 先跑起来，把 Trace 收上来

很多人卡在“先优化再上线”的陷阱里。实际上，最快的改进方式，是先搭一个能用的版本，让它上线跑真实流量。

Trace 就是你唯一能信任的反馈源。它记录了 Agent 每一步想什么、调用什么、得到什么、最后输出什么。没有 trace，优化就是盲人摸象。

2. 从 Trace 里挖信号

收集到 trace 之后，下一步是找“哪些地方值得改”。

Trivedy 提到他们做了一件事：微调了一个专门 judge trace 的开源小模型。这个模型的职责是读大量 trace，判断哪些片段是“做对了的”，哪些是“明显翻车的”。

有意思的结论是：在窄任务上，开源小模型比闭源大模型更准，而且成本低一个数量级。因为公司内部对 trace 的判断标准是高度定制化的，通用大模型反而不如专门训练过的小模型好使。

这里的核心思想是：把“从海量 trace 里找问题”这件事本身，也做成一个专门的 Agent 或模型任务。

3. 把信号转成 Evals

找到问题之后，不是直接去改 prompt，而是先把这些问题整理成 Evals——也就是专门针对这个 Agent 的测试集。

Trivedy 说得很直接：Evals 就是 Agent 的训练数据。

evals 的意义在于，它给你一个可重复、可量化的改进基准。没有 evals，你改完一个参数，靠感觉说“好像变好了”，这不是工程，是玄学。有了 evals，你至少能跑个自动化测试，看看这次改的是不是真的提升了正确率。

4. 在 Evals 上跑改进实验

有了 evals，改进就变成了一个标准的 hill-climbing 问题：你有一个目标函数（eval 分数），你不断调整模型或 harness 的参数，看分数往不往上涨。

Trivedy 在 Terminal Bench 2.0 上的实验结果是：仅仅通过调整 harness 并做 hill-climbing，就能比 baseline 提升 13.7%。这还没碰模型权重本身。

这说明了一个被很多人忽略的事实：在很多场景下，改 harness 比改模型 ROI 更高。Harness 就是你给模型搭的“工作台”——包括工具怎么暴露、记忆怎么组织、子任务怎么拆分、失败时怎么重试。这些工程层面的优化，往往比换模型、加 prompt 更有效。

三、Harness Engineering 和 Fine-tuning 怎么选

这是实际做 Agent 的人最关心的问题：到底什么时候该改 harness，什么时候该训模型？

Trivedy 的答案很务实：从 harness 开始，因为它的反馈循环更快。

• Harness 调整是工程变更，你可以今天改，明天看 evals 涨没涨。
• Fine-tuning 需要收集数据、训练、部署，周期以周甚至月计。
• 而且模型越强，harness 能“溶解”的空间就越大——模型自己能做更多决策，你需要的 orchestration 反而变少。

他给出的判断标准是：如果你的问题可以通过改工具、改记忆、改流程解决，就不要急着去训模型。先把 harness 压榨到极限，再考虑模型层面的优化。

四、前端团队能立刻落地的三个动作

这篇文章读完之后，你可以直接做这三件事：

1. 给你的 Agent 接 trace 采集。至少先记录每一次工具调用、每一次 LLM 请求、每一次最终输出。LangSmith、LangFuse、Arize 这些工具都能做，哪怕先存 JSON 文件也比没有强。

2. 用开源小模型做 trace judge。找一个窄领域任务，把你最近一周的 trace 喂给小模型，让它标出“成功/失败”。看看它和人工标注的重合度是多少。如果小模型够用，你就能低成本地搭建自动化问题发现管线。

3. 把问题样本转成 evals 集。不要只改一次 prompt 就完事。把 trace judge 标出来的失败案例整理成测试集，每次调整 harness 或模型之后自动跑一遍。有了量化基准，改进才有意义。

结语

Agent 不是调 prompt 调出来的，是数据喂出来的。

但这里的“数据”不是预训练数据，而是 Agent 自己在真实环境里跑出来的 trace。谁能最快地收集、筛选、回灌这些数据，谁家的 Agent 就最有可能持续变强。

前端工程师在过去十年已经习惯了“看日志调 Bug”这套流程。现在做 Agent，本质上只是把这套能力搬到了 AI 系统上——只不过这一次，你 debug 的对象变成了一个会自己调用工具的非确定性系统。

思路没变，工具变了。先把 trace 接上，再说别的。