144 lines
8.6 KiB
Markdown
144 lines
8.6 KiB
Markdown
# Deferred Decisions Registry
|
||
|
||
## Active Items
|
||
|
||
### [cloud-deploy-route-b] 路线 B：云服务器正式部署
|
||
- **status**: deferred
|
||
- **tags**: deployment, docker, nginx, cloud, production
|
||
- **recorded**: 2026-04-12
|
||
- **source_chat**: [发布到手机浏览器的方案讨论](discussion-publish-routes)
|
||
- **prerequisite**: 路线 A（内网穿透 + 移动端适配）完成后
|
||
- **related_files**:
|
||
- art-agent/backend/app/main.py
|
||
- art-agent/frontend/next.config.ts
|
||
- art-agent/frontend/.env.local
|
||
- art-agent/backend/.env
|
||
- **context**: |
|
||
买轻量云服务器（2C2G ~50元/月），编写前后端 Dockerfile + docker-compose，
|
||
配置 Nginx/Caddy 反向代理统一入口，HTTPS 自动签证书，
|
||
环境变量搬迁（去掉本地代理配置），可选绑定域名。
|
||
预估工作量 1-2 天。
|
||
- **chosen_alternative**: 路线 A — 本地运行 + 内网穿透（Cloudflare Tunnel / ngrok）
|
||
- **deferred_reason**: 当前阶段只需自己和朋友试用，内网穿透足够
|
||
|
||
### [style-pipeline-layered] 分层组合风格一致性产线
|
||
- **status**: deferred
|
||
- **tags**: 风格一致性, IP-Adapter, LoRA, ControlNet, 量产, 美术产线, InstantStyle
|
||
- **recorded**: 2026-04-12
|
||
- **updated**: 2026-04-13
|
||
- **source_chat**: [风格一致性技术方案讨论](style-consistency-discussion)
|
||
- **prerequisite**: EPEEKit 进入美术资源量产阶段（风格方向已确定、需要批量产出同风格素材）
|
||
- **related_files**:
|
||
- art-agent/backend/app/services/image_gen.py
|
||
- art-agent/backend/app/config.py
|
||
- **context**: |
|
||
分层组合的风格一致性产线：
|
||
1. 探索期（当前）：Prompt + 参考图，快速试错确定风格方向
|
||
2. 锁定期：IP-Adapter / ControlNet，选 3-5 张精选图作为风格锚点，推理时注入风格
|
||
3. 量产期：LoRA + ControlNet，用精选图训练 LoRA（20-50 张），批量产出同风格资源
|
||
4. 贯穿全程：标准化 Prompt 模板 + Negative Prompt 模板，确保品质下限
|
||
各阶段可叠加使用，不互斥。LoRA 训练需要同风格样本积累到足够数量。
|
||
|
||
2026-04-13 调研补充 — 风格迁移模型层级：
|
||
- Kolors IP-Adapter（当前在用）：通用 IP-Adapter，风格迁移弱，内容+风格+构图混合提取
|
||
- InstantStyle（Replicate 可用）：专门分离内容/风格，风格迁移强，但贵且慢
|
||
- Style IPAdapter for NoobAI-XL（CivitAI）：最强画风迁移（线条+着色技法），需 ComfyUI
|
||
- ICAS 框架（学术前沿 2025.04）：IP-Adapter + ControlNet 组合，多主体风格一致性最优
|
||
锁定期的最佳方案：迁移到 HF Inference Endpoints 后，用 NoobAI-XL + Style IPAdapter + ControlNet
|
||
- **chosen_alternative**: 当前使用 Prompt Engineering + LLM 参考图理解（探索期方案）
|
||
- **deferred_reason**: 风格方向尚未确定，过早引入 LoRA/ControlNet 是过度优化
|
||
|
||
### [hf-inference-endpoints] 迁移到 Hugging Face + Inference Endpoints
|
||
- **status**: deferred
|
||
- **tags**: 基础设施, Hugging Face, Inference Endpoints, ComfyUI, 自定义模型, 风格迁移
|
||
- **recorded**: 2026-04-13
|
||
- **source_chat**: [Kolors 风格迁移排查与模型调研](kolors-style-investigation)
|
||
- **prerequisite**: 探索期结束、确定要用的模型组合后
|
||
- **related_files**:
|
||
- art-agent/backend/app/services/image_gen.py
|
||
- art-agent/backend/app/config.py
|
||
- **context**: |
|
||
将生图基础设施从 Replicate API 迁移到 Hugging Face Inference Endpoints：
|
||
1. 可部署任意 ComfyUI 工作流（NoobAI-XL + Style IPAdapter + ControlNet 等任意组合）
|
||
2. 不受 Replicate 模型作者暴露的参数限制，完全控制推理流程
|
||
3. CivitAI 上的任何 LoRA、IP-Adapter 权重都能直接加载
|
||
4. 按 GPU 时长计费，批量生成时远比 Replicate 按次付费便宜
|
||
5. 是 style-pipeline-layered 延期方案中"锁定期 → 量产期"的基础设施
|
||
背景：当前在 Replicate 上可用的风格迁移模型有限——
|
||
- Kolors IP-Adapter：风格迁移弱（混合提取内容+风格+构图）
|
||
- InstantStyle（jyoung105/instant-style）：风格迁移强但贵（$0.12/次）且慢（~128s）
|
||
- Style IPAdapter for NoobAI-XL：最强画风迁移，但需 ComfyUI 环境，Replicate 上无法使用
|
||
迁移到 HF Inference Endpoints 后可自由组合以上所有方案。
|
||
- **chosen_alternative**: 当前使用 Replicate API（Kolors IP-Adapter + Flux + SDXL）
|
||
- **deferred_reason**: 探索期用 Replicate 足够快速迭代，迁移工作量较大（需搭建自定义推理服务）
|
||
|
||
### [vision-model-asset-library] 专用 Vision 模型用于资源库功能
|
||
- **status**: deferred
|
||
- **tags**: 资源库, vision, CLIP, BLIP, 图片搜索, 自动标签, embedding
|
||
- **recorded**: 2026-04-12
|
||
- **source_chat**: [参考图风格解析方案讨论](vision-model-discussion)
|
||
- **prerequisite**: 资源库功能进入增强阶段（基础 Gallery 已完成）
|
||
- **related_files**:
|
||
- art-agent/frontend/src/app/gallery/page.tsx
|
||
- art-agent/backend/app/services/image_gen.py
|
||
- **context**: |
|
||
引入专用 Vision 模型（CLIP / BLIP 等）为资源库提供智能化能力：
|
||
1. 自动标签：生成的图片自动分类（UI/角色/场景/图标等）
|
||
2. 以图搜图：上传一张图，从资源库中找风格最相似的
|
||
3. 语义搜索：用自然语言搜索图片（如"蓝色水晶质感的按钮"）
|
||
4. 聚类分组：自动将图片按视觉相似性分组
|
||
可通过 Replicate 调用或本地部署，成本极低。
|
||
- **chosen_alternative**: 当前资源库使用手动标签 + Prompt 文本搜索
|
||
- **deferred_reason**: 当前阶段资源量少，手动管理足够；等资源积累到一定量级后再引入自动化
|
||
|
||
### [context-window-management] 对话上下文管理（Token 预算 + 滑动窗口 + 摘要）
|
||
- **status**: deferred
|
||
- **tags**: 上下文管理, token, 滑动窗口, 对话摘要, agent loop, 长对话
|
||
- **recorded**: 2026-04-13
|
||
- **source_chat**: [Art Agent 上下文与记忆体系讨论](memory-architecture-discussion)
|
||
- **prerequisite**: 无（随时可做，优先级高于长期记忆）
|
||
- **related_files**:
|
||
- art-agent/backend/app/agent/loop.py
|
||
- art-agent/frontend/src/lib/api.ts
|
||
- art-agent/frontend/src/lib/store.ts
|
||
- **context**: |
|
||
当前 Art Agent 对话采用"全量透传"：前端把完整 messages 发给后端，后端原样拼接传给 LLM，
|
||
没有 token 计数、截断或摘要。长对话会导致上下文超限、费用线性增长。
|
||
实施方案（自建，无需外部依赖）：
|
||
1. Token 计数：用 tiktoken 库在构建 api_messages 时计数
|
||
2. 滑动窗口：超过预算时截断最早的消息
|
||
3. 对话摘要：被截断的消息先调 LLM 生成摘要，作为压缩上下文保留
|
||
预估工作量 1-2 天，是记忆体系的第一层基础。
|
||
- **chosen_alternative**: 当前全量透传，依赖模型自身的上下文窗口上限
|
||
- **deferred_reason**: 当前探索期对话通常较短，暂未触及上限；但随着迭代使用会很快需要
|
||
|
||
### [mem0-long-term-memory] 引入 Mem0 作为长期记忆层
|
||
- **status**: deferred
|
||
- **tags**: 长期记忆, Mem0, 用户偏好, 语义检索, 事实提取, memory layer
|
||
- **recorded**: 2026-04-13
|
||
- **source_chat**: [Art Agent 上下文与记忆体系讨论](memory-architecture-discussion)
|
||
- **prerequisite**: 第一层上下文管理（context-window-management）完成后
|
||
- **related_files**:
|
||
- art-agent/backend/app/agent/loop.py
|
||
- art-agent/backend/app/config.py
|
||
- **context**: |
|
||
引入 Mem0 开源版（Apache 2.0）作为 Art Agent 的跨会话长期记忆层：
|
||
- Mem0 是"bolt-on"设计，保留自己的 agent loop，只外挂 memory API
|
||
- 核心 API：memory.add()（存储+自动事实提取）+ memory.search()（语义检索）
|
||
- 自部署：pip install mem0ai + Qdrant 向量库，LLM 用 DeepSeek 降成本
|
||
- 记忆范围：用户风格偏好、历史生成反馈、常用参数等
|
||
- 与自建 Rules/Docs 静态知识系统互补：Mem0 负责动态记忆，Rules 负责预置知识
|
||
技术选型对比（本次讨论结论）：
|
||
- Letta 不适合：它是完整 agent runtime，不是 memory layer，需要替换现有 loop
|
||
- Zep 可行但偏重：时序知识图谱能力强但集成复杂度更高
|
||
- Mem0 最适合：设计哲学完全对口"已有 agent + 外挂 memory"，集成最简（~20 行代码）
|
||
预估工作量 3-5 天（含 Mem0 部署 + 集成 + extraction prompt 调优）。
|
||
- **chosen_alternative**: 当前无长期记忆，每次会话从零开始
|
||
- **deferred_reason**: 探索期优先做第一层上下文管理；长期记忆在用户量和使用频率增长后再引入
|
||
|
||
---
|
||
|
||
## Completed / Cancelled Items
|
||
|
||
（暂无已完成或已废弃的方案）
|