我如何设计一个 AI + GraphQL + OCR 的可扩展系统

很多 AI 系统一开始只是“把模型接起来”，但一旦进入真实环境，很快就会在几个地方同时失控：上传链路混乱、任务状态不可追踪、权限边界散落、失败重试没有统一语义。问题往往不在模型本身，而在外围系统从一开始就没有被当成一等公民来设计。

系统边界

我倾向于把系统拆成四层：

1. Gateway 负责身份、访问控制和统一 API 入口。
2. Orchestrator 负责任务状态机和队列编排。
3. Workers 负责 OCR、模型推理与后处理。
4. Storage 负责对象存储、结构化结果和日志。

这样的拆法不是为了追求“服务多”，而是为了把失败语义和职责边界固定下来。OCR 失败不会直接污染上层 API，权限逻辑也不会散落在每个 worker 里，后续要替换推理引擎时也不需要重写整个控制面。

为什么 GraphQL 适合作为控制面

GraphQL 不适合承载所有大流量二进制数据，但它很适合作为控制面。我更愿意把它用于：

• 查询任务状态
• 拉取结构化结果
• 聚合多个服务的元数据
• 给前端提供稳定的数据契约

而真正的文件上传和大体积内容处理，应该走对象存储或专门的上传通道。这样做的直接收益是控制面始终保持轻量，调试和观测也更简单。

任务流比模型调用更重要

AI 系统最容易被低估的部分是任务流。通常我会先写清楚下面这些问题，再去接模型：

• 请求是否幂等
• 失败是否可重试
• 中间结果是否可追踪
• 每一步的输入输出是否可审计

如果这些问题没有先设计清楚，后面再加监控和补偿逻辑，成本会变得很高。很多团队把“任务系统”当成后期补丁，结果就是状态既不可信，也无法做审计。

我关心的不是“微服务”，而是可维护服务边界

服务数量不是重点。重点是边界是否稳固。一个系统就算只有三个服务，只要责任明确、队列可靠、权限集中，也比十几个边界模糊的服务更健康。真正让系统复杂的从来不是服务个数，而是边界不稳定导致的跨层耦合。

最终我想构建的不是“AI demo”，而是一条可以持续扩展的数据处理管道。