2024年并未如多数人所预期的那样，迎来AI Agent的全面爆发。但若你曾关注那些真正投身Agent开发的团队，便会发现，大家早已悄然潜入一片更深的水域。深水区的游泳法则与浅水区截然不同——没有一套趁手的装备，很容易陷入困境。

那么，这个“深水区”究竟需要什么？答案指向了Agent Infra层，即那些支撑Agent底层能力的工具与应用。俗话说“要想富，先修路”，在此同样适用——只有基础设施先行，Agent的繁荣才不会沦为空谈。过去几个月，我们正是在这一领域进行了大量实践，并催生了新产品——Chat2API。今天这篇文章，暂且不谈产品形态，而是聚焦一个问题：Agent开发者如何在水下保持稳定？核心方法论之一，便是构建一套有效的评估体系。

用户到底需要什么样的AI应用？

在2024年，从用户需求角度而言，有两个趋势已基本明朗：

• 第一，用户对“AI能生成内容”已不再感到新奇，他们真正在意的是生成的内容是否有用、准确、可控。
• 第二，别指望用户自己去配置复杂的提示词、外部工具，或者亲手整理RAG知识库。他们要的是“拿来即用”的体验。

这两个信号，直接将开发者从“浅水尝试区”推向了“深水实验区”。

浅水区是什么样？借助Dify、LangChain这类工具，搭配RAG（记忆）和函数调用，就能快速拼出一个Agent。但至于这个Agent干活质量究竟如何，说实话，很多人并未认真思考过。而到了深水区，Agent的行为必须被量化评估，再决定能否发布、是否需要进化。换句话说，评估结果就是Agent能否上线的“准生证”，也是推动其持续优化的“方向盘”。

我们将这种开发方式称为：Evaluation-driven development。2024年下半年，我们一直在践行这一理念。

如何用评估促进产品迭代？

深水区的第一件事，就是为自己所在的场景构建一套评估测试集。这套测试集，在很大程度上代表了用户需求——提示词该怎么调、模型该怎么选、知识库该怎么检，都必须围绕它来展开。

举个具体例子。比如对日期的理解，用户描述日期的方式可谓五花八门：

• 直接的历法日期（阴历、阳历）
• “今天”、“明天”、“明年此时”这类相对说法
• 节气、节日等别称
• 事件描述，例如“xx公司成立那天”、“暑假”、“寒假”

面对这种情况，我们需要先为每一种描述方式建立从自然语言到绝对日期的映射关系，然后再一轮轮调优提示词，直至整体表现达到最优。

理论上，这些评估测试集最好从真实用户反馈中获取。但这里有一个现实问题：这就陷入了“蛋生鸡还是鸡生蛋”的悖论。我们当然希望“越多使用，越多反馈，越好产品”。但现实往往是——用户第一次使用，效果不佳，就直接弃用了，再也收不到数据。因此，开发者自己必须有能力构建出足够数量、足够合理的冷启动测试数据集，然后在此基础上不断迭代完善。

从这个角度看，深水区的Agent开发更像一门实验科学，而且这个实验，从一开始就不能太差。

LangChain家族的AI度量观测工具LangSmith，在其官方文档中给出了一张图，很好地概括了LLM AI应用的实验方法。如果我们用“考试”来打比方，这套体系中各个要素的关系就很容易理解了：

实际上，这套评估方法与非AI产品的A/B测试方法是相通的：

• 我们抛出两个问题：按钮位置在A还是B？
• 打分标准：看哪个位置的点击率或转化率更高。
• 参加考试的“考生”：就是这个应用。
• 最终分数：对A/B测试结果的置信度解读。

只不过在LLM AI应用中，打分标准不像点击率那么确定。LLM里的题目更像是“陈述题”，可以类比高考历史论述题的评分方式：

第一步：定维度

• 相关度：回答是否紧扣主题。
• 正确度：内容是否存在错误。
• 完整度：是否包含了所有必要内容。
• ……（根据具体场景增加维度）

第二步：定打分标准

每个维度上，按1-5分依次定档划分。

第三步：开始评卷

有两种方式。可以用大模型机器评分：把评分标准作为提示词，和需要评分的答案同时发给高级大模型（比如GPT-4o）来打分。也可以人工辅助评分：业务专家对机器评分的结果进行快速审核，直到机器给出的标准能打出和人类相近的分数。

当然，Agent的评估远不止这些。LangSmith还给出了更完整的方法论，包括：如何生成高质量的评估数据（手动收集、或利用大模型合成，再用人工修正）；如何构建评分标准；如何汇总并解读分数。这里不一一罗列，参考下图即可。

一旦评估体系建立起来，就有了向更高标准演进的方向。可以采取的措施包括：选择不同的大模型、调整提示词、优化知识检索方法、切换不同用户群体，甚至可以使用像Dspy这样的开源项目，它能够在你每次修改LLM、检索器或评估标准时，自动重新优化一组新的提示和示例，来最大化地满足你的评估标准。

由此可见，评估标准的建立是Agent优化的最强驱动力，Evaluation-driven development是Agent开发的必然趋势。

在深水区的实践中，Evaluation是一项系统工程。它不仅要对Agent的整体输出做评估，也要细化到工作流的每一个节点。

例如，在一个典型的Agent流程中，Agent首先从文档库检索到相关问题的解决方案，然后依据解决方案决定是否调用工具（函数调用）。为了让Agent的回答准确率达到最高，我们除了要对比最终结果，还需要在各个节点中设立相应的评估方案（图中红色标记）。

要系统地把这套评估体系做扎实，本质上是个“脏活累活”。但正如前面所说，也唯有这套体系，才能随着用户的使用，让Agent越来越聪明。

正因如此，市场上也涌现了不少评估工具。下面这张表里的几个产品，它们的官方文档和博客，能帮你对Evaluation理解得更透彻。

能不能让评估变得更简单？

不过，如果你仔细看过这些工具，就会发现：它们提供的只是一个框架——包含DataSet、Evaluator、Task、Score这些固定的位置，但里面具体要放什么内容，还是得开发者自己去填充和构建。

好消息是，在某些特定的评估环节上，比如“工具使用能力”的评估，是有可能标准化的。典型场景包括：

• 选择工具：Agent能否从众多工具中挑出正确的那一个？比如，查询用户地址要调用searchUser，而不是updateUser。
• 参数转换：Agent需要将自然语言转换成正确的函数调用格式，比如从“帮我查一下张三的地址”中，提取出正确的参数值。

选择工具相对简单。而第二项评估——参数转换，就要繁琐很多：首先要构建大量的对话数据，并在这些数据中标注出对应的函数调用；评估时，还需要解析函数语言、提取参数，再和对话中的数据进行比对……工作量相当繁重。

不过，我们为此而开发的Chat2API，正是为了应对这类问题而诞生的。下一篇，我们来详细讲讲Chat2API的诞生过程与具体方法。