问题
用 MCP 搭建图像工作流的开发者缺少统一入口：生成、参考图编辑、后续修改分散在多个工具里，而后续编辑必须携带先前图像与会话上下文；长任务还缺少异步状态机制。信号 2 进一步指出，视觉 Agent 检索目前被单步检索器严重拖累——Agent 每个中间步骤都要发出文本查询，当视觉线索难以用文字描述时会卡住。两个信号分别指向同一链条的两端：入口/会话层与检索层。但两条信号均为发布/论文型信号，实际开发者痛感证据偏弱。
目标用户
正在为 Spaces 或 MCP 客户端搭建图像生成工作流的开发者，以及构建带检索工具的 LLM Agent 的开发者。属于开发者工具细分市场，规模定性偏小众但增长中，MCP 生态尚在早期。
解决方案
- 统一 MCP 入口：一个会话式服务器，把图像生成、参考图编辑、后续修改、prompt 建议路由到后端模型
- 持久会话/对话状态：跟进编辑自动携带先前图像与会话上下文，开发者无需手动传递历史
- 异步任务与状态轮询：长任务立即返回 job ID，提供类似 eye_art_image_status 的轮询接口
- 链式视觉检索（加分项）：在单次工具调用内返回关联图像链，减少 Agent 的中间文本查询次数——借鉴 VHOP 思路但 MVP 可先用简化的多图返回实现
MVP 范围
第一版只做：一个符合 MCP 规范的图像生成/编辑统一服务器，支持持久会话（跨轮携带先前图像与上下文）和异步任务（返回 job ID + 状态查询接口）。不做：训练自有多步检索模型（VHOP 属研究范畴）、自建图像生成底模（转发到已有 API）、SVG 生成等外围功能。MVP 阶段重点验证开发者是否真的需要持久会话与异步状态查询这两个特性。
风险
- 付费不明：两条信号均无付费意愿，目标用户是习惯用免费开源工具的开发者，商业化路径可能要靠托管服务或企业内部部署。
- 已有先行者：Eye.Art Polyphemus 已作为托管路由上线，功能高度重叠；VHOP-Router 代表的研究方向也可能被大厂或模型厂商直接吸收进生态。
- 平台依赖：深度绑定 MCP 协议与 Hugging Face Spaces 生态，协议演进或平台政策变化会直接冲击产品。
- 需求验证不足：两条信号都来自发布与论文，几乎没有用户评论或实际使用反馈，可能存在“发布热闹、需求稀薄”的风险。
已有产品
| 产品 | 定位 | 价格 |
|---|---|---|
| Eye.Art Polyphemus | 信号 1 中已上线的托管 MCP 路由，覆盖统一入口、持久会话与异步任务轮询，与本机会高度重叠 | — |
| VHOP-Router | 研究侧的多步视觉检索路由，解决的是中间步骤检索瓶颈，与本机会的图像链检索部分相关 | — |
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
Hugging Face 论坛 · Show and Tell10月2日新品发布▲ 00 条评论
“It’s a hosted router, not an HF model or downloadable checkpoint: one conversational MCP entry point routes requests to image generation, reference-image edits, SVG creation, prompt ideas, and follow-up edits.”
AI 图像工作流缺少统一入口，且跟进编辑需要携带先前图像与会话上下文，长任务需要异步状态查询。原文
arXiv cs.IR10月1日新能力
“visual agentic search remains severely bottlenecked by standard single-step retrievers. In current pipelines, the agent must issue text queries for every intermediate step, struggling when visual clues are difficult to describe”
Visual agentic search remains severely bottlenecked by standard single-step retrievers that require the agent to issue text queries for every intermediate step.原文