原文标题：Human judgment in the agent improvement loop 原文链接：https://blog.langchain.com/human-judgment-in-the-agent-improvement-loop/
作者：Rahul Verma，LangChain 部署工程师
AI Agent 在最好的时候反映了您的团队随时间积累的知识和判断。其中一些是已经记录下来并且 Agent 可以轻松使用的制度知识。但大多数伟大的组织也依赖于存在于员工思想中的隐性知识。团队通常不会意识到这些信息对于执行有意义的工作有多么关键，直到他们尝试构建 AI Agent 来自动化它。确保这种智慧进入 Agent 需要一个改进循环，其中包含来自领域专家的输入。
在本指南中，我们将涵盖：
- 您的 Agent 的哪些组件将受益于吸收人类判断
- 如何在开发生命周期的每个步骤中将人类判断纳入您的 Agent
真实灵感的例子：交易员副驾驶
想象一个金融服务公司，其交易员需要最新的市场数据。今天，他们向数据科学团队发送问题。数据科学家编写 SQL 查询，检索相关数据，然后将结果发送回。由于 LLM 擅长生成 SQL，此工作流是使用 AI Agent 自动化的自然候选者：交易员获得更快的响应，而数据科学家可以自由地处理更有趣的项目。
为了使此系统可靠地工作，Agent 需要在金融服务域级别和技术数据库层都有上下文。前者包括确定如何解释”今天的敞口”或”最近波动”等请求的非书面交易约定。后者包括有关数据库的实用知识，例如哪些表是权威的与过时的，或哪些查询模式往往是不正确或效率低下的。我们需要与适当的主题专家进行接触，以包括 Agent 需要的所有非书面上下文。
我们将在整个指南中使用此示例来提供具体的实现示例。这是一个很好的例子，因为架构很简单，它 展示了在 Agent 设计中涉及人类判断的关键原则。
让我们回顾一下 Agent 的不同组件，这些组件可以通过人类判断改进。
人类输入如何改进 AI Agent 的每个组件
构建 Agent 意味着决定何时调用 LLM 以及在每次调用时提供什么上下文（例如，文档、记忆、对话历史、工具）以达到所需结果。这些设计选择中的每一个都受益于来自正确利益相关者的输入。
工作流设计
现在的 LLM 擅长对自己的行动进行排序。给他们一些工具和自然语言指令，他们就会弄清楚以什么顺序调用哪些工具。但是，使用确定性代码来定义工作流的某些部分有好处：更低的延迟、更少的令牌，以及关键步骤实际运行的保证。 在某些监管或高风险设置中，您需要代码来严格控制操作序列。在我们的交易员副驾驶中，我们将让 LLM 自主生成和执行 SQL 查询，但添加代码以要求它在将最终答案返回给交易员之前验证最终答案符合我们公司的风险和合规要求。我们需要来自风险和合规专家的输入来创建强制执行公司标准的自动化检查。我们也可以在 Agent 的预加载上下文中包含该信息，以改善其第一次创建有效答案的几率。
工具设计
开发人员必须实现 Agent 可以使用的工具，并配置 LLM 依赖于决定何时调用它们的名称、参数和描述。在工作流的不同阶段改变可用工具通常很有用。限制单个 LLM 调用的工具集可以指导模型朝向预期行为，并减少它选择不相关选项的可能性。
我们的副驾驶的工具可能包括数据库模式检查、查询执行和数据库文档检索。关键的权衡是 LLM 生成查询的灵活性与控制：一般的 execute_sql 步骤允许灵活的查询但增加风险；参数化查询工具更安全但功能较少。仔细审查您的业务约束可能会让您了解哪个选项适合您，但要确定无疑，您需要运行评估以确定您的工具设计的性能和风险特征，并且只有在所有利益相关者对结果满意时才发送。
Agent 上下文
早期的 Agent 只是给了模型一个系统提示和一组工具定义。随着时间的推移，行业已转向在执行开始时为 Agent 提供丰富得多的上下文。 Anthropic 的 Skills，自 10 月推出以来迅速获得欢迎的标准，是这一趋势的一个突出例子。
与其将所有内容塞进一个系统提示，您的团队可以提前策展文档、示例和域规则，然后让 Agent 在运行时获取所需内容。这使得 Agent 可以使用更多的知识，而无需膨胀系统提示。有效的 Agent 设计涉及决定 Agent 应该访问什么知识，并将其组织起来，以便 Agent 可以在正确的时刻检索正确的信息。
至少，我们的交易员副驾驶需要知道如何使用数据库并理解其模式。根据我们的副驾驶需要的来自我们团队的额外知识的性质和数量，我们不仅要花时间收集知识，而且还要确定如何将其结构化并逐步向我们的 Agent 披露。
选择和组织 Agent 启动时可用的信息是上下文工程的一部分。上下文工程还涵盖在 Agent 完成任务时在每个 LLM 调用中提供的信息如何演变。您的人类利益相关者在审查 Agent 的输出和评估分数时提供的反馈可能会影响您如何为 Agent 处理端到端上下文工程的方式。
现在我们已经概述了受益于人类判断的 Agent 部分，我们将介绍如何收集该人类输入。
将人类判断纳入 Agent 改进循环
在 LangChain，我们与数百个部署 AI Agent 的组织合作过。最成功的团队遵循紧密的迭代循环：他们快速构建 Agent，将其部署到生产或类似生产的环境，并在每一步收集数据以指导改进。 我们称之为”Agent 改进循环”，因为我们观察到大多数成功的 Agent 都经历过这个循环多次，并且之前在 这里 已经更详细地介绍过。
快速且频繁地迭代至关重要，因为 LLM 的实时推理而非代码决定了 Agent 的行为。在 Agent 运行之前不可能知道它会做什么。AI Agent 接口通常是自由形式的，例如用户可以输入任何内容的文本框，这使得更难预测您的用户与 Agent 之间的交互会是什么样子。将您的 Agent 放在用户面前是收集您最终成功所需数据的唯一方法。
我们将在讨论如何有效地纳入人类输入的同时，逐步介绍飞轮的以下阶段：
- 实现 Agent 的第一个版本
- 监控 Agent 上线后的情况，并收集生产数据以帮助改进它
- 实现和测试改进版本的 Agent
在我们深入讨论之前，值得强调一个适用于整个开发生命周期的原则。
高返回人类时间投资的关键：自动化评估，与人类判断一致
我们观察到** 当人类帮助设计和校准自动化评估人员时，团队会获得更多的杠杆，而不是手动审查大量 Agent 输出**。无论您的团队有多大或资源充足，依赖广泛的手动审查很少是经济上的。可扩展的方法是将专家判断转化为自动化评估，让您可以测试广泛和连续。这就是 LangSmith 的 Align Evaluator 功能帮助的内容。它提供用户界面，用于使用策展示例和来自主题专家的反馈来校准 LLM-as-a-judge 评估人员。我们建议对任何旨在模拟非开发人员利益相关者判断的评估人员使用此功能。
让我们从假设交易公司的角度，通过改进循环的每个阶段来跟踪交易员副驾驶。我们将看看如何有效地纳入人类输入，特别是如何将该输入引导到自动化评估中。
开发：策展测试套件和评估人员
在开发开始之前，工程师应该至少有一小套用例场景和预期行为作为项目要求的一部分。这些初始测试有助于确认 Agent 正确执行核心任务。随着 Agent 接近生产就绪，工程师应与产品经理和主题专家合作，构建更全面的测试套件，评估整体行为和关键子组件。
对于我们的副驾驶，我们将使用 LangSmith 的 datasets 功能来手动创建一些地面真实数据集，配对自然语言问题及其正确答案。我们还将创建包含在我们数据库环境中良好、高性能 SQL 的示例的数据集。当我们的开发人员构建 Agent 时，我们将使用 LangSmith 的 evaluations 功能来针对这些数据集运行测试。LangSmith UI 允许我们的技术和非技术团队成员审查评估结果并对其进行注释，以便每个人都可以协调开发人员的下一步。
我们可以通过用我们在手动测试期间遇到的有趣案例的灵感增加我们的初始数据集，在这个阶段创建一个迷你飞轮。 这有助于逐步自动化我们的反馈循环，并确保在我们准备发送 Agent v1 时拥有全面的测试套件。
部署后：使用自动化评估和监控来将人类注意力指向最需要的地方
一旦您的 Agent 上线，您需要确保其可靠性，并快速识别问题或改进的机会。验证用户体验的传统方式是满意度调查和用户访谈，但该方法的缺陷是它衡量用户告诉您的内容，而不是他们实际做的。LLM-as-a-judge 评估人员为我们提供了一种更强大的方法。在生产数据上运行的自动化评估可以帮助监控 Agent 并浮出保证人类注意力的情况。 例如，LLM 法官可以自动检测用户何时表示沮丧，并标记这些交互以供审查。然后团队成员可以调查跟踪并决定该问题是否反映了错误、Agent 知识的差距或工作流中的弱点。
我们假设的公司将首先设置 LangSmith tracing 来捕获我们的 Agent 与交易员的所有交互。接下来我们将为以下内容设置 LangSmith 的 automations 功能：
在线评估：配置 LangSmith 以在可观察性数据传入时对其运行评估人员。例如，我们希望对缓慢或危险的 SQL 查询进行自动化代码检查，以及 LLM-as-a-judge 评估人员审查对话，查看用户是否对副驾驶提供的答案表示满意。警报：当 LangSmith 看到错误、延迟或负在线评估分数的峰值时，它将触发我们预先存在的警报系统，以便我们的团队可以快速修复根本问题注释队列：我们通过将注意到的跟踪发送到 LangSmith annotation queue 来标记它们进行人工审查。在队列中，我们将有主题专家审查在线评估人员返回非常负反馈分数的案例，指示 Agent 有问题。边界反馈分数会建议我们需要调整评估人员本身。LangSmith 保存通过注释队列提交的反馈，以便可用于未来的自动化和手动分析。
洞察 Agent：从跟踪数据中获取价值的另一种方式
对实时行为的非结构化探索激发了 AI Agent 一些最有价值的改进。 为了支持这一点，LangSmith 提供 Insights Agent，一个内置的 AI Agent，以最小的用户配置分析大量跟踪数据。它浮出 Agent 行为中的模式和趋势，这些模式和趋势从单个跟踪或确定性评估中不会很明显。最终您仍然会让您的人类利益相关者审查洞察报告以协调下一步，但该功能启动了该过程。
对于我们的交易副驾驶，我们可能会自动运行洞察报告，识别相似的对话并将其聚类为用例类别。了解交易员提出副驾驶的问题背后的主题有助于我们识别我们应该额外确保良好支持的用例，甚至未来的产品补充，这将为交易员提供更好的服务。
随着自动化评估、人工注释和聚合级洞察的积累，它们提供了 Agent 在现实世界中如何执行的清晰图景。这些学习进入循环的最后一步：通过构建 Agent 的下一个版本来重启迭代循环。
持续优化：将今天的生产数据转变为明天的测试套件
当您构建 Agent 的第一个版本时，您的评估套件最多是对您需要验证它起作用的测试的有根据的猜测。推出后，您可以访问更好的测试案例来源：真实的生产数据。
您需要将此数据整理成全面但不必要的庞大测试套件。自动化系统可以帮助生成候选数据集，例如，通过根据评估人员结果过滤生产跟踪。但 我们通常需要人类判断来策展平衡、代表性的评估集。 如果选择仔细，评估可以在仅数百个示例上有用地运行，因此值得让专家参与决定应该定义测试套件的示例。
一旦我们的交易公司在生产中运行了一段时间的副驾驶，该团队将有权访问真实的 SQL 查询和聊天机器人对话，以及通过监控和策展注释队列收集的在线评估人员结果和人工观点。
我们的团队可以从审查的跟踪创建数据集，以运行更强大的评估套件，导致 v2 及以后 Agent 性能的巨大改进。我们可以策展的最有用的数据集之一是”黄金数据集”，包括副驾驶迄今为止最佳工作的示例，因此我们可以将其用作基线以确保未来版本的性能至少一样好。LangSmith 使这很容易组合在一起。使用在线评估人员分数来识别候选跟踪，然后将它们放在注释队列中，以便我们的主题专家可以决定哪些实际上属于黄金数据集。
结论
有效的 Agent 开发将人类判断与自动化评估的可扩展性相结合。人类专业知识通过塑造工作流、工具、上下文和评估标准来帮助定义”好”的样子。自动化评估人员大规模应用该判断，帮助团队快速测试 Agent、监控其在生产中的行为，并将人类注意力指向最重要的案例。
随着时间的推移，这创造了一个飞轮。人类反馈改进了评估人员、测试套件和 Agent 本身，我们部署的改进 Agent 为我们提供了更多数据，告诉我们如何改进它，这些洞察推动了下一个开发迭代。
我们使用了一个简单的用例来说明这个过程，但 相同的原则适用于构建任何 Agent：构建紧密迭代循环，在可扩展的评估中捕获专家判断，并不断将生产数据转变为更好的测试。 这是创建为您的业务创造有意义价值的 AI Agent 的关键。