Hey，大家好！今天来聊聊如何评估你的AI Agent。其实核心就是将系统构建过程中的磕磕碰碰构建成一个持续改进Agent性能的专有数据集。

首先，让我们聊聊“简单即是美”。一提到评估LLMs的方法，你可能会看到一堆令人眼花缭乱的缩写、基准测试和学术论文。但别担心，如果你正在构建一个特定领域的Agent，你的任务范围要小得多，而且你对它已经很熟悉了。所以，别在网上乱搜了，开始思考你要解决的问题。不要等到以后才考虑评估问题，从一开始就要小规模地、逐步地构建你的评估套件。

接下来，观察你的Agent是如何失败的。找到失败案例应该不难，但要准确找出在LLM调用的长链中你的Agent在哪里偏离了轨道，可能需要一些工作。然后，你可以专注于链中的一个特定步骤。制定一个简单的断言，描述你认为Agent在这种特定情况下应该展示的行为。这与传统的单元测试类似。调整你的Agent，然后重新运行那一步。当然，LLM的输出是概率性的事件，我们不能期望100%的成功率。目标是通过重复这个循环——识别失败，添加断言，调整Agent行为——随着时间的推移提高通过率。

但这个过程听起来简单，要有效实施它，依赖于一些重要的基础能力。为了快速定位失败，你需要追踪和可视化Agent轨迹。要恢复和重播特定步骤，你需要某种检查点。要随着时间监控断言通过率，你依赖于测试用例的版本化数据集和一个跟踪指标的用户界面。

“流程工程”比“提示词工程”更重要。“提示词工程”直到最近还被视为一项必备技能。但是，如果在这方面过分强调，可能意味着你走错了方向。所有这些策略在某些情况下可能有效，但存在一个真正的风险，那就是过分关注局部最优而忽略了更大的画面。如果提示词对Agent性能的影响很小，你应该关注什么？调整你的Agent遵循的多步骤迭代流程。

一个系统成功的关键在于能够快速评估你对Agent控制流的更改。解决这个问题超越了评估，触及到了核心系统设计。Agent的架构必须是可组合的——就像一套可互换的乐高积木。这里没有简单的解决方案，它将需要针对你的问题进行精心设计。成功的Agent第一轮将围绕特定用例，但通用Agent框架无疑会迅速成熟。

一旦你有了灵活的Agent架构和基础设施来识别、重播和纠正失败案例，事情就开始变得有趣了。你自然会陷入一个迭代的评估过程——当以标准化的方式跟踪时——会产生一个极其宝贵的数据集。你的开发速度会随着全面的评估覆盖提供信心而加快。相同的数据集可以重新用于微调，允许模型完全内化过去失败和课程修正的集合。你的Agent将越来越多地“知道”采取正确的行动，而无需调整提示或重新排序流程中的步骤。

如果有什么比你的Agent控制流更重要，那就是底层LLM的能力。新的通用模型层出不穷，专门为Agent设计的模型也有一些。这些发展不是对特定用例Agent的威胁，而是相反，它们将推动更大的可能性的边界。