68 lines
2.4 KiB
Markdown
68 lines
2.4 KiB
Markdown
# 项目分析入库（多源）
|
|
|
|
- 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](D:/Code/AI/agent-park/prisma/schema.prisma)
|
|
- [route.ts](D:/Code/AI/agent-park/src/app/api/projects/route.ts)
|
|
- [route.ts](D:/Code/AI/agent-park/src/app/api/projects/[slug]/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](D:/Code/AI/agent-park/docs/integrations/n8n/registry.json)。
|
|
- 若 discovery 服务未来并入仓库，应第一时间把这里改成具体路由与 schema 映射。
|