详细内容或原文请订阅后点击阅览
为我的 LangGraph AI 代理构建合适的后端
将演示代理转变为可以保留真实预订数据的东西为我的 LangGraph AI 代理构建适当的后端一文首先出现在走向数据科学上。
来源:走向数据科学中，我构建了一个有状态的 LangGraph 代理，用于处理 15 分钟的预订流程，并使用 Streamlit UI 对其进行包装，以改善用户体验。
代理像真正的客户服务代表一样处理整个预订流程。它是一个基于 LangGraph 的代理，可以协调以下操作：
下一阶段是构建一个适当的后端，我们首先实现一个 Postgres 数据库，而不是将所有内容都保存在内存中。
我们保留 Streamlit 作为用户界面，并用 PostgreSQL 替换内存适配器。
这也将允许我们拥有共享相同后端的多个前端（例如 WhatsApp、Streamlit）。因此，我们正在将其转变为能够处理实际业务的合适产品。
该项目的完整源代码可在 GitHub 上的 customer-service-agent 上获取。请随意克隆该存储库并自行测试。
数据库现在是什么样子
甚至很难将其称为数据库，因为它只是进程内的两个 Python 对象：
第一个是 LangGraph 检查点，它是一个状态持久层，在执行的每一步保存代理图状态的快照。
当图表被编译时，对话状态被存储在内存中。
graph.compile(checkpointer=checkpointer 或 MemorySaver())
检查点允许代理跨回合恢复。如果我们没有它，每条客户消息都将是一次新的对话。
第二个对象是一个锁后面的 Python 列表。已确认的约会存储在内存存储库中，如下所示：
调度引擎调用list_bookings()来避免重复预订。调用 create_booking() 进行确认，它重新检查重叠并附加到列表中。