这是一篇由 Unify 的 Sam 和 Connor 撰写的客座博文。 Unify 正在利用生成式 AI 重塑上市团队的工作方式。作为这一转型的一部分，他们今天推出了一项新的代理功能（由 LangGraph 和 LangSmith 提供支持）。我们很高兴能更深入地了解推出此功能所经历的工程历程，并认为这是一个很棒的故事可以分享。
代理是我们正在推出的一个新功能，与我们称之为 Plays 的更广泛的自动化套件一同推出。代理本质上是研究工具——它们可以通过搜索网络、访问网站、跨页面导航以及执行标准的 LLM 合成和推理来回答问题，从而研究公司或个人。
在最初发布时，代理的目标用例是*账户资格认证*，即决定一家公司是否符合您的理想客户画像进行销售。给定一家公司以及一组问题和标准，代理会进行一些研究并决定它们是否“合格”。
示例研究问题
以下是不同用户可能向代理提出的用于研究和确定资格的一些示例性资格问题：
- 一家人力资源软件公司 ⇒
- 在这家公司招聘页面上是否有任何人力资源职位空缺？
- 招聘人力资源职位的职位空缺中是否提到了竞争对手的软件？
- 一家人工智能基础设施公司 ⇒
- 这家公司在其网站的任何地方是否提及使用 LLM？
- 该公司开放的机器学习职位是否需要有处理语言或音频 Transformer 模型的经验？
- 该网站或任何职位空缺是否提及开源 LLM？
代理 v0
我们使用 LangGraph 作为代理状态机的框架，并使用 LangSmith 作为实验和跟踪框架。我们的起点是一个非常简单的代理，尽可能地精简（甚至没有提示）。
这对于许多简单的任务来说实际上效果相当不错，但它也会出错并产生不一致的结果。分析答案背后的推理也很困难。
代理 v1
我们的下一个迭代是构建一个更复杂的代理结构，其中包含一个*初始计划*步骤和一个*反思*步骤。图表如下所示：
第一步是使用大型模型生成计划。在我们的测试中，像gpt-4o这样的主流模型在没有非常具体的提示的情况下，并不能构建出特别全面的计划。在此阶段我们获得的最佳结果是 OpenAI 的o1-preview模型。o1生成的计划之所以难以用其他模型复制，是因为它们具有：
- 非常详细的分步说明
- 潜在的陷阱和需要避免的错误，这些错误和陷阱都是正确且有用的
- 对用户问题含义的扩展，即使措辞不当
o1的主要缺点是速度。它可能需要 30-45 秒才能响应，这会显着减慢代理的整体运行速度。我们正在积极实验的一个领域是用更快、更轻量级的模型复制等效结果。
在计划之后，代理然后开始在“反思”步骤和工具调用之间循环。为此，我们尝试了几种模型。GPT-4o 和 3.5 Sonnet 等“主流”模型效果相当好。反思模型最重要的特征之一是诚实地承认自己*尚不*知道什么，以便能够适当地选择正确的后续步骤。
代理 v2
在我们的最新迭代中，我们仍然使用计划-反思-工具状态机结构。我们最积极调整和实验的领域是速度和用户体验。
速度
此架构的主要缺点（尤其是在使用 o1-preview 等较重的规划模型时）是它会大大增加整体运行时间。我们通过加速代理循环和修改产品中代理使用界面的用户体验/用户界面来应对这个问题。
我们取得的最大速度提升之一来自于并行化工具调用。例如，我们允许模型一次抓取多个网页。这很有帮助，因为每个网页可能需要几秒钟才能加载。它的效果很好，因为人类也常常这样做——一次在新标签页中快速打开多个 Google 搜索结果。
用户体验
在不牺牲准确性和功能的情况下，代理的速度最终是有限的。相反，我们决定重新设计我们产品中用于构建和测试代理的界面。最初的设计在代理运行时向用户显示一个旋转图标（几秒钟后会很痛苦）。我们更新的界面反而实时显示了代理在运行时采取的操作和决策过程。（请参阅本文顶部的视频）
实现这一点还需要一些工程上的改变。我们最初有一个简单的预测端点，在代理运行时会保持请求打开。为了处理更长的代理运行时间和实现新的分步 UI，我们将其转换为一个“异步”端点，该端点启动代理执行并返回一个 ID，该 ID 可用于轮询进度。我们将代理图和工具集成，将进度“记录”到我们的数据库中。然后，前端轮询更新，并在代理执行过程中显示新完成的步骤，直到获得最终结果。
最终的经验教训
拥抱实验
与代理合作无疑需要弄清楚新事物。研究领域目前非常不成熟，还没有明确的最先进的代理架构，不像我们在视觉或音频等其他领域所想的最先进的那样。
鉴于此，我们必须大力依靠老式的机器学习实验和评估周期来取得实质性进展。
我们对此（我们也已经在为 Unify 的另一项 LLM 驱动功能 Smart Snippets 使用 LangSmith）感到非常满意。特别是，版本化数据集正是我们所期望的。运行和比较实验非常简单，而且跟踪功能也非常出色。我们能够在数百个示例上运行新的代理版本，并在给定的数据集上快速将其与以前的版本进行比较，而无需大量的内部机器学习基础设施工作。
将代理视为暑期实习生
例如，许多具有代理构建功能的工具都围绕着编写提示、在一些测试用例上运行它、等待一个黑盒代理运行、检查结果，然后猜测如何修改提示以尝试改进它。
现在想象一下，这个代理是一个容易出现疏忽和错误的暑期实习生。如果你给实习生一个任务，他们给出了错误的答案，你只会尝试修改你的指示然后让他们自己再次去做吗？不——你会让他们展示他们是如何完成任务的，这样你就可以找出他们做错了什么。一旦你发现了他们的错误，就更容易调整你的指示，以防止错误再次发生。
回到代理，我们最终的用户体验是用户可以清楚地看到代理正在分步进行分析其决策过程，并弄清楚他们需要提供哪些额外的指导。
o1-preview 是一个可靠的模型，但速度非常慢
尽管速度很慢，但 OpenAI 的 o1-preview 模型在计划形成方面比我们尝试过的其他模型都要好。它倾向于冗长，但这种冗长通常是有价值的内容，而不仅仅是填充或样板。它始终返回我们（尚未）无法用其他模型复制的结果，但等待时间很长。我们可以通过改进用户体验来解决速度慢的问题，但随着我们扩展这个系统，o1 可能会成为瓶颈。
赋能终端用户进行实验
我们看到用户在使用 LLM 驱动的功能时面临的最大挑战是弄清楚如何迭代。许多用户对 LLM 或提示策略的接触很少。作为用户，如果我点击“生成”但结果只有部分正确，接下来我该做什么？如何进行迭代并取得进展，而不会在已经正确的示例中出现回归？
我们认为用户界面和 LLM 的交叉领域充满颠覆性。虽然我们对迄今为止开发的用户界面感到兴奋，但让用户更容易进行实验和纠正代理的错误将是我们未来关注的重点之一。