用于目录数据的 LangGraph 智能体

问题

把第三方车辆和零件数据导入公司目录是重复的手工工作。需要有人选择许多参数、下载数据、清洗数据，并把每条记录映射到正确的目录表中。

目标是把这项工作自动化，让数据团队不必再手动处理。

工作原理

1. 请求 从下拉列表中选择品牌、车型、年份和地区。
2. 解析变体 找到所有匹配的车型变体，并展开为需要获取的目录范围。
3. 获取 调用第三方目录 API，带缓存和重试。
4. 规范化与映射 清洗记录，并映射到正确的目录表。
5. 写入 分批保存到 PostgreSQL，并设有检查点，使任务可以安全地续跑或取消。
6. 报告 展示每个批次是如何规范化和映射的，方便数据团队核查。

• 调度器APScheduler，配有用于定时和手动运行的小型界面
• 缓存目录数据缓存到分组级别
• 管控范围限制、任务状态和可见的 API 用量

我构建了什么

• 先求简单，再求可预测。第一个版本接收自然语言请求，带有澄清步骤，并记录智能体的每一步以便调试。工作流稳定后，我把自由文本换成了下拉选项，让每次运行都可以重复。
• 为什么用 LangGraph。LLM 只承担一小部分工作，但 LangGraph 依然物有所值：工作流结构清晰、易于检查，并能在失败后续跑。
• 为超大任务而设计。保存是分块且可续跑的，因此一个拥有超过 10 万个变体的车型在失败后不必从头开始。
• 定时调度。APScheduler 通过一个小型界面按计划或按需运行任务。
• 可审核的输出。自动生成的报告展示每个批次是如何规范化和映射的，非工程人员也能审核结果。
• 文档。我为目录结构编写了参考文档，说明智能体读取哪些表、写入哪些表。

工程判断

在动手之前，我比较了自建与采购两种方案。我研究了现有的 AI 数据采集工具，以及 Airflow、Prefect 和 Celery 等工作流引擎，选择了一种符合项目阶段、日后也能扩展的轻量方案。

我还让任务范围和计费 API 的用量保持可见，而不是把它们隐藏在自主行为背后。这种设计减少了手工工作，同时让人始终掌控成本和数据。

状态

这个原型可以运行，带有定时调度和供数据团队使用的演示界面，当时正在被整合进一个统一的内部管理工具。我于 2026 年 7 月离职时，它尚未投入生产。

本页面略去了雇主代码、内部数据和私有网址。