agent-park/docs/integrations/n8n/workflows/03-project-ingestion-multi-source.md

项目分析入库（多源）

• Registry ID: project-ingestion-multi-source
• n8n Workflow ID: 1Ig1CyVMsGJFaHOe
• Status: external-upstream
• 角色: 消费 discovery 任务队列，补齐项目事实、外链和标签，再把结果写回 AgentPark 的项目主数据。

触发方式

• 定时触发
• 当前已核查行为：约每 10 分钟轮询一次

外部输入

• discovery task queue
• 浏览器抓取与页面解析
• AI 提取和结构化能力
• 标签池 / 分类规则

主流程

1. 轮询 discovery 任务队列，拉取待处理项目。
2. 把任务置为 IN_PROGRESS。
3. 基于 sourceUrl 和 sourceType 打开外部页面，采集项目事实。
4. 生成标准化项目资料，如标题、描述、正文、分类、外链、标签候选。
5. 写回任务完成接口，完成项目入库。
6. 出错时写回失败状态。

输出结果

• project content
• tag assignments
• task completion status

与仓库的关系

这是“项目从发现到落库”的核心桥梁，但它不通过当前仓库中的显式 /api/discovery/* 路由实现。当前仓库能确认的消费面主要是项目表结构和展示接口：

• schema.prisma
• route.ts
• route.ts

系统边界

当前仓库没有以下接口实现：

• GET /api/discovery/tasks
• PATCH /api/discovery/tasks/:id
• POST /api/discovery/tasks/:id/complete
• 失败回写相关接口

这说明项目入库队列服务是外部系统。当前仓库只能消费最终入库结果，而不能独立运行整条入库工作流。

已确认要点

• 已通过 live n8n MCP 核查 workflow 元数据与职责。
• 该流程会先标记 IN_PROGRESS，再进行浏览器与 AI 分析。
• 当前仓库看到的是结果表和查询接口，不是入库执行器本身。

对 AI/GSD 的意义

后续如果要梳理“项目数据源头 -> 展示”，必须把这条流程当作核心中间层，而不是假设项目直接从 GitHub 写入 projects。

维护要求

• 任务字段、回写结构、标签落库策略变化时，同步更新 registry.json。
• 若 discovery 服务未来并入仓库，应第一时间把这里改成具体路由与 schema 映射。