【AI实战项目问答】AI 修图智能体-20 个重难点技术问题与高质量答案

文章目录

• • 一、整体架构与 Agent 编排
  • • Q1. 这个项目的整体架构是怎么分层的？一次 AI 修图请求从输入到画布更新走了哪些环节？
    • Q2. 为什么用 LangGraph 搭建 Agent，而不是让大模型直接输出一段 JSON？
    • Q3. 「一处定义，界面与 Agent 共用」的工具注册表是怎么设计的？
    • Q4. 为什么要把「遮罩素材 ID」「修订号」这类参数藏起来，不给模型看？
    • Q5. 模型给出的计划为什么必须由服务端二次校验？具体校验了什么？
    • Q6. 多步计划是怎么推进的？为什么说「计划本身就是断点」？
  • 二、选区、遮罩与图层系统
  • • Q7. 选区为什么和修订号强绑定？多步计划中多个步骤怎么共用同一块选区？
    • Q8. SAM 点选为什么能做到毫秒级响应？做了哪些优化？
    • Q9. 遮罩是画布坐标，图层却可能被移动、缩放过，怎么把两者对齐？
    • Q10. 「一键拆层」背后的像素处理链路是怎样的？为什么要把主体先挖掉再让模型修背景？
    • Q11. 「把任意物体提升为独立图层」如何做到幂等？已经拆过层时怎么处理？
    • Q12. 图层文档模型为什么用「贴图 + 变换」而不是直接把像素烧平？
    • Q13. 撤销 / 重做是怎么实现的？为什么选区的撤销要另做一套？
  • 三、异步执行、实时推送与模型接入
  • • Q14. 为什么把工具分成「异步队列」和「同步当场执行」两类？
    • Q15. SSE 实时进度是怎么做到不丢消息、不悬挂连接的？
    • Q16. 前端为什么要做「假进度」？平滑算法是怎么设计的？
    • Q17. Provider 抽象层解决了什么问题？对接真实图像模型踩了哪些坑？
  • 四、前端画布工程实践
  • • Q18. react-konva 画布是怎么组织视口、图层与坐标系的？
    • Q19. 「握持上一帧 + 淡出」和本地乐观预览分别解决了什么体验问题？
  • 五、安全、健壮性与部署
  • • Q20. 认证、越权与素材安全是怎么做的？部署上又有哪些取舍？

一、整体架构与 Agent 编排

Q1. 这个项目的整体架构是怎么分层的？一次 AI 修图请求从输入到画布更新走了哪些环节？

答案

• 三层分离：前端是 React + Konva 单页应用（生产环境与后端同源托管）；后端 FastAPI 内部按路由层 / 业务服务层 / 数据访问层分层；耗时任务由独立的 ARQ Worker 进程执行。
• 三类存储各司其职：PostgreSQL 存业务数据（用户、素材元信息、工具调用记录、编辑会话与画布文档、Agent 轮次）；Redis 同时承担队列、Pub/Sub 消息通道和轻量缓存（如选区）；MinIO 存图片字节，对外只暴露短时签名 URL。
• 一次请求的完整链路：用户输入一句话 → 服务端拼出「画布摘要」（画幅、图层清单、有无选区、修订号）→ 规划模型以 function calling 输出工具调用 → 服务端做校验、依赖补全与环检测 → 多步计划先停下来等待用户确认 → 按依赖关系拓扑推进，像素类工具丢进队列异步执行 → 每次状态变化既落库又发布到 Redis 频道 → SSE 实时推给前端 → 前端刷新文档并更新画布。
• 三条贯穿全局的设计原则：
• 「慢的走异步、快的走同步」——按工具是否产生像素分流；
• 「状态以服务端为准，前端只做乐观预览」；
• 「S