LLManager 用于管理审批请求的 LangGraph 工作流

LLManager 是用于管理审批请求的 LangGraph 工作流，使用反射来随着时间的推移进行改进和学习，通过动态提示组合来处理各种审批请求。

使用方法

LLManager 可以通过设置两个自定义字段进行配置：approvalCriteria 和 rejectionCriteria。这些字段在图的配置对象中设置，可以与特定的助手关联，用于审批流程中，用来确定是否批准或拒绝请求。虽然不需要设置这些字段，因为 LLManager 会从过去的经验中学习并相应地更新其提示，但设置它们可以帮助模型做出更明智的决策，缩短“入职”时间。

创建一个新的助手后（可选地设置这些字段），就可以开始使用 LLManager 进行审批请求了。推荐的方法是通过代理收件箱进行操作。

配置

可以在图的配置对象中设置以下字段：

• approvalCriteria：定义请求被批准的标准。

• rejectionCriteria：定义请求被拒绝的标准。

• modelId：定义用于图的模型。格式应为 provider/model_name。这必须是 initChatModel 方法支持的提供者。该模型还必须支持工具调用。要使用非 OpenAI/Anthropic 模型，必须安装它们的 LangChain 集成包（OpenAI 和 Anthropic 集成包已经安装）。例如，使用 yarn install @langchain/google-genai。

开发

要在本地使用 LLManager，请按照以下步骤操作：

1、克隆仓库：git clone https://github.com/langchain-ai/llmanager.git

2、导航到项目目录并安装依赖项：cd llmanager && yarn install

3、将 .env.example 文件复制到 .env 并填写所需的值：cp .env.example .env

4、启动开发服务器：yarn dev

这将启动内存中的 LangGraph 服务器，地址为 http://localhost:2024。

评估和代理收件箱

在开发过程中，主要通过与代理收件箱交互来评估 LLManager。可以通过运行端到端评估来运行 E2E 评估，然后使用代理收件箱查看和响应审批请求。

运行 E2E 评估的命令是：yarn test:single evals/e2e.int.test.ts，将从头到尾运行图，处理 25 个独特的请求，每个 E2E 评估都会为其创建一个新的助手，反射和少样本示例是通过助手 ID 命名的。

运行评估后，应该将此图添加到代理收件箱中，访问 dev.agentinbox.ai，点击添加收件箱，输入以下值：

• 助手/图 ID：添加运行评估后在终端记录的助手 UUID。

• 部署 URL：http://localhost:2024，这是 LangGraph 服务器的 URL。

• 名称：可以是任何你想要的名称，例如 LLManager。

输入这些值后，点击提交并选择/刷新收件箱以确保你有最新的事件，你可以开始使用收件箱来接受或拒绝请求！

工作原理

当收到请求时，LLManager 将执行以下步骤：

推理

这是图的第一步，是一个子图，很容易扩展和定制以适应特定的用例。默认情况下它运行一个节点，执行以下操作：

• 构建提示：这涉及提取过去的反射，从以前的请求中获取少样本示例。少样本示例通过语义搜索检索，我们使用请求作为查询，返回过去历史中 10 个语义相似的请求。这些示例包括请求、最终答案以及答案背后的解释。使用所有这些上下文，我们提示模型生成关于是否批准请求的“推理报告”，我们明确告诉它不要做出最终决定，而是对请求进行推理。

• 生成答案：在运行推理子图后，我们返回推理报告以及提示上下文（少样本示例和反射），使用推理报告和上下文，我们提示 LLM 使用所有提供的上下文来得出最终结论。

人工审查

在生成推理报告和最终答案后，我们中断图并等待人类进行审查，批准/编辑或拒绝请求。这个步骤对于 LLManager 的学习过程至关重要，因为我们允许人类修改最终答案以及答案背后的解释。如果请求被忽略，我们不做任何处理。如果被接受/编辑，我们将最终答案、解释和请求存储在少样本示例存储中，以便在未来的请求中使用。由于我们允许人类不仅修改最终答案，还修改答案背后的解释，我们可以确保少样本示例始终是最新的，包含准确、经过人类验证的信息。

反射

LLManager 流程的最后一步是进行反射。如果请求被接受而没有更改，跳过此步骤。这是因为我们不需要反思 LLManager 做对的情况。如果提交时进行了编辑，我们调用反射子图，该子图将请求路由到一个节点。

• 答案正确，解释错误：如果唯一的更改是解释（例如，最终答案是正确的，但人类认为请求的解释是有缺陷的），我们调用 explanation_reflection 节点。该节点将请求、当前反射、原始解释和编辑后的解释传递给 LLM。然后提示 LLM 反思为什么它得到了正确的答案，但通过不恰当的推理。然后生成一个或多个新的反射，旨在防止工作流重复这个错误。

• 答案和解释都错误：如果人类编辑了最终答案和解释，我们调用 full_reflection 节点。这与上述节点非常相似，但是不是提示 LLM 反思它是如何通过不恰当的推理得到正确的解释，而是提示 LLM 反思它是如何得到完全错误的答案。同样，它至少生成一个反射，希望能防止这种情况再次发生。

生成的反射然后存储在反射存储中，在未来的请求中使用，用来帮助 LLM 生成更好的响应。

定制

LLManager 工作流是为一般的审批请求而构建的，但可以轻松定制以适应更具体的用例。你应该编辑的两个主要区域是：

• 推理子图：这是工作流的第一步，负责生成关于是否批准请求的推理报告。默认情况下，它调用单个节点并生成“推理报告”，以便稍后在最终生成中使用。你可能希望扩展这个子图，用来改变它如何创建和呈现动态上下文（少样本示例、反射），或者如何生成推理报告。

• 反射子图：这是工作流的最后一步，只有在最终答案的一个/两个部分（解释或答案）错误时才会运行。它提示 LLM 根据错误的答案和解释生成新的反射。编辑这个子图将允许你更好地控制生成和存储的反射。例如，一个定制化可能是允许 LLM 删除它认为不再相关的反射，或者允许它修改现有的反射以更准确。