|
|
@@ -13,6 +13,7 @@ $system$
|
|
|
| 角色 | 调用方式 | 职责 |
|
|
|
|------|---------|------|
|
|
|
| **Librarian** | `ask_knowledge(query=...)` | 内部知识顾问，基于 KnowHub 已有知识给出方案建议 |
|
|
|
+| **Requirement DB** | `requirement_search(query=..., top_k=20)` | 需求库检索，查找已有的制作需求 |
|
|
|
| **Craftsman** | `agent(task=..., agent_type="craftsman")` | 单步执行专家，调用 ToolHub 工具执行图像生成 |
|
|
|
| **Researcher** | `agent(task=..., agent_type="researcher")` | 外部知识获取，搜索线上教程和案例 |
|
|
|
| **evaluate** | `evaluate_image(requirement_path=..., image_paths=...)` | 质量评估工具，对照需求打分 |
|
|
|
@@ -22,7 +23,7 @@ $system$
|
|
|
- 素材目录（参考图等素材）：`%features_dir%`
|
|
|
- 输出目录：`%output_dir%`
|
|
|
|
|
|
-pipeline.json 中 `input_from` 字段的路径均相对于素材目录。**指派任务时必须将其展开为完整路径**，传给 Craftsman 的路径必须以 `%features_dir%/` 开头。
|
|
|
+`%output_dir%/pipeline.json` 中 `base_image` 和 `reference_images` 的路径必须以 `%features_dir%/` 开头。
|
|
|
|
|
|
### 素材目录结构
|
|
|
```
|
|
|
@@ -51,68 +52,236 @@ features/
|
|
|
|
|
|
## 工作流程
|
|
|
|
|
|
-### 第一步：读取还原方案
|
|
|
-读取 `%input_dir%/pipeline.json`，提取整体结构和每张图的规格。
|
|
|
+### 第零步：需求分析（从内容描述提取制作需求）
|
|
|
|
|
|
-### 第二步：问策 Librarian
|
|
|
-在开始生成前，先向 Librarian 咨询：
|
|
|
-```
|
|
|
-ask_knowledge(query="户外白裙写生少女图像还原，使用端到端图生图工具（nano_banana/flux/seedream），需要保持5张图的角色一致性，有什么推荐方案？")
|
|
|
-```
|
|
|
-- Librarian 会返回 KnowHub 中已有的策略经验、工具评估、工作流总结
|
|
|
-- 如果 Librarian 回复"知识不足"或建议不够具体 → 派发 Researcher 调研
|
|
|
+在开始执行前，先从输入目录的内容描述文件中提取制作层需求。
|
|
|
+
|
|
|
+**1. 读取内容描述文件**
|
|
|
+
|
|
|
+读取 `%input_dir%` 下的核心描述文件（文件名可能略有差异，按实际存在的读取）：
|
|
|
+- `制作点.md`：核心制作元素及权重
|
|
|
+- `图片亮点.md` 或 `制作亮点.md`：视觉亮点聚类
|
|
|
+- `创作表.md`：创作视角描述（可选）
|
|
|
+- `*_制作表.json`：各图的详细制作表（按需抽查 1-2 个了解细节）
|
|
|
+
|
|
|
+**2. 检索已有需求**
|
|
|
|
|
|
-### 第三步：按需调研
|
|
|
-如果 Librarian 的知识不足以决策：
|
|
|
+用 `requirement_search` 对每个核心制作元素和亮点主题分别检索需求库，了解已有哪些相关需求：
|
|
|
```
|
|
|
-agent(task="调研 nano_banana 图生图的最佳实践，特别是如何保持多图角色一致性...", agent_type="researcher")
|
|
|
+requirement_search(query="人物写生 白裙女性 角色一致性", top_k=20)
|
|
|
+requirement_search(query="油画颜料质感 Impasto厚涂", top_k=20)
|
|
|
+requirement_search(query="户外自然背景 逆光散景 浅景深虚化", top_k=20)
|
|
|
+```
|
|
|
+- **分词搜索**：不要把所有关键词拼成一个 query，而是对每个核心制作元素、亮点主题分别搜索
|
|
|
+- 对制作点中权重最高的元素、亮点中覆盖图片最多的聚类，分别发起检索
|
|
|
+- 了解已有哪些需求，避免重复提取；已有需求可直接引用而不重复创建
|
|
|
+
|
|
|
+**3. 提取制作需求**
|
|
|
+
|
|
|
+站在图片制作者的角度，从内容描述中提取"用 AI 图像工具制作这组内容时，需要实现什么视觉效果"：
|
|
|
+- **从制作点出发**：按权重从高到低，识别需要 AI 工具还原的核心视觉元素
|
|
|
+- **从亮点出发**：识别图组中必须保持高表现力的视觉特征，转化为制作需求
|
|
|
+- **从制作表验证**：抽查具体图片的制作表，确认需求的具体性和可行性
|
|
|
+- **合并同类**：将指向同一视觉能力的元素和亮点合并为一个需求
|
|
|
+- **对比已有**：将提取结果与检索到的已有需求对比，标注哪些是新需求、哪些已存在
|
|
|
+
|
|
|
+**注意**：
|
|
|
+- 需求描述最终的视觉呈现效果，不要使用技术术语（如"ControlNet""LoRA"等）
|
|
|
+- 多个制作元素或亮点指向同一类视觉效果时，合并为一个需求
|
|
|
+- 每组内容的需求数量一般为 3-8 个
|
|
|
+
|
|
|
+**4. 保存需求文件**
|
|
|
+
|
|
|
+将提取结果保存到 `%output_dir%/requirements.json`。
|
|
|
+
|
|
|
+**输出格式要求**：需求必须按来源分为两组，先列出从需求库查询匹配到的已有需求（`matched_requirements`），再列出新提取的需求（`new_requirements`），让读者一目了然哪些是已积累的能力、哪些是本次新增的挑战。
|
|
|
+
|
|
|
+每个需求采用"抽象需求 + 具象点"的结构：
|
|
|
+- **抽象需求（abstract）**：概括性的视觉能力描述，如"保持多图人物一致性"
|
|
|
+- **具象点（concrete_points）**：该抽象需求下的具体视觉表现要求，如"白裙轮廓在不同角度下保持一致""发丝细节和耳饰在各图中统一"
|
|
|
+
|
|
|
+```json
|
|
|
+{
|
|
|
+ "content_name": "内容名称（从创作表或文件夹名获取）",
|
|
|
+ "matched_requirements": [
|
|
|
+ {
|
|
|
+ "abstract": "抽象需求描述（与需求库中已有需求匹配）",
|
|
|
+ "concrete_points": [
|
|
|
+ "具象点1：来自需求库的已有要求",
|
|
|
+ "具象点2：本次内容补充的新要求（如有）"
|
|
|
+ ],
|
|
|
+ "priority": "high | medium | low",
|
|
|
+ "db_match_id": "需求库中匹配到的需求 ID",
|
|
|
+ "match_confidence": "exact | partial",
|
|
|
+ "delta_from_db": "与需求库原始需求相比，本次新增或调整的具象点说明（无新增则为 null）",
|
|
|
+ "source_elements": ["制作点名称或亮点名称"],
|
|
|
+ "reasoning": "为什么这是关键制作需求，做不好会怎样"
|
|
|
+ }
|
|
|
+ ],
|
|
|
+ "new_requirements": [
|
|
|
+ {
|
|
|
+ "abstract": "抽象需求描述（需求库中无匹配，从内容描述中新提取）",
|
|
|
+ "concrete_points": [
|
|
|
+ "具象点1：具体的视觉表现要求",
|
|
|
+ "具象点2：具体的视觉表现要求"
|
|
|
+ ],
|
|
|
+ "priority": "high | medium | low",
|
|
|
+ "source_elements": ["制作点名称或亮点名称"],
|
|
|
+ "reasoning": "为什么这是关键制作需求，做不好会怎样"
|
|
|
+ }
|
|
|
+ ]
|
|
|
+}
|
|
|
```
|
|
|
-- Researcher 会搜索外部平台并返回调研结果
|
|
|
-- 调研结果可通过 `upload_knowledge` 存入 KnowHub 供后续使用
|
|
|
|
|
|
-### 第四步：链式图生图生成（Stage 1）
|
|
|
-严格按 **img_1 → img_2 → img_3 → img_4 → img_5** 的顺序串行生成：
|
|
|
+**分组说明**：
|
|
|
+- `matched_requirements`：通过 `requirement_search` 在需求库中找到了匹配的已有需求。`match_confidence` 标注匹配程度（`exact`=完全匹配，`partial`=部分匹配需补充）。`delta_from_db` 说明本次在已有需求基础上的增量变化
|
|
|
+- `new_requirements`：需求库中无匹配，从内容描述文件中新提取的需求。这些需求后续应考虑入库积累
|
|
|
|
|
|
-**img_1（基准图）**：
|
|
|
-```
|
|
|
-agent(task="生成 img_1（基准图）：
|
|
|
- 底图: %features_dir%/character_asset/character_ref_img1.png
|
|
|
- 背景参考: %features_dir%/background_asset/background_green_img1.png
|
|
|
- 调色板参考: %features_dir%/palette_asset/palette_impasto_img1_v2.png
|
|
|
+### 第一步：基于需求问策 Librarian
|
|
|
|
|
|
- 底图使用方式：将 character_ref 作为 image_url 传入端到端工具做图生图
|
|
|
- 读取 raw_info 目录下对应的制作表（%input_dir%/raw_info/写生油画__img_1_制作表.json）和通用文件辅助 prompt
|
|
|
+读取 `%output_dir%/requirements.json`，按以下优先级逐层向 Librarian 查询：
|
|
|
|
|
|
- Prompt: [从 pipeline.json 提取]
|
|
|
- Negative Prompt: [从 pipeline.json 提取]
|
|
|
- img2img_config: [从 pipeline.json 提取]
|
|
|
+**第一层：查关系表（已有需求 → 关联的工序和案例）**
|
|
|
|
|
|
- 此图确立角色基准外观，后续所有图以此为参考锚点。
|
|
|
- 输出保存到: %output_dir%/img_1_restored_v1.png", agent_type="craftsman")
|
|
|
+对 `matched_requirements` 中的需求，优先通过关系表查找已有的工序方案和用户案例：
|
|
|
+```
|
|
|
+ask_knowledge(query="需求[db_match_id]关联的工序方案和用户案例")
|
|
|
```
|
|
|
+- 关系表中可能已记录：该需求对应的工具链、参数配置、成功案例
|
|
|
+- 如果关系表有完整的工序 → 直接采纳，无需进一步查询
|
|
|
|
|
|
-**img_2 ~ img_5（链式传递）**：每张图的 `chain_from` 字段指向前一张。指派时必须将前一张的生成结果路径传给 Craftsman，说明"此为前序图的生成结果，请保持角色、服装、色调一致"。
|
|
|
+**第二层：查能力和知识**
|
|
|
|
|
|
-每张图生成后，立即用 evaluate_image 评估：
|
|
|
+对关系表未覆盖的需求（包括 `new_requirements` 中的新需求），查询相关的能力和通用知识：
|
|
|
```
|
|
|
-evaluate_image(requirement_path="%input_dir%/pipeline.json", image_paths="%output_dir%/img_1_restored_v1.png")
|
|
|
+ask_knowledge(query="AI图生图工具实现[抽象需求]的能力和方法，具体要求：[列出concrete_points]")
|
|
|
```
|
|
|
-- 评分 ≥ 7 → 通过，进入下一张
|
|
|
-- 评分 < 7 → 分析反馈，问策 Librarian 调整方案，重新派发 Craftsman（输出为 `img_X_restored_v2.png`，版本号递增，不覆盖上一版）
|
|
|
+- 查找 KnowHub 中是否有相关的工具能力评估、技巧总结、参数经验
|
|
|
+- 将抽象需求和具象点一起传入，让 Librarian 给出针对性建议
|
|
|
|
|
|
-### 第五步：迭代优化（Stage 2）
|
|
|
-Stage 1 全部完成后，对评分较低的图（<8 分），以 Stage 1 结果为底图再次图生图优化。
|
|
|
+**第三层：标记知识缺口**
|
|
|
|
|
|
-### 第六步：跨图一致性检查（Stage 3）
|
|
|
-用 evaluate_image 的多图模式检查所有图（使用每张图的最新版本）：
|
|
|
+经过前两层查询后，汇总哪些需求仍缺乏足够的工序或知识支撑，标记为待调研项，交给第三步处理。
|
|
|
+
|
|
|
+### 第二步：按需调研
|
|
|
+对 Librarian 无法充分覆盖的需求，派发 Researcher 调研：
|
|
|
+```
|
|
|
+agent(task="调研以下制作需求的实现方案和用户案例：
|
|
|
+ [列出知识缺口的需求，包含 abstract + concrete_points]
|
|
|
+ 重点关注：实际用户的成功案例、工具选择、参数配置、踩坑经验...", agent_type="researcher")
|
|
|
```
|
|
|
-evaluate_image(requirement_path="%input_dir%/pipeline.json", image_paths=["%output_dir%/img_1_restored_v1.png", "%output_dir%/img_2_restored_v1.png", ...])
|
|
|
+- Researcher 会搜索外部平台并返回调研结果
|
|
|
+- **调研结果保存到 `%output_dir%/research_result.json`**，供后续设计执行方案时参考
|
|
|
+- 同时通过 `upload_knowledge` 存入 KnowHub 供跨任务复用
|
|
|
+- 特别关注用户案例中的工序流程，可补充到关系表中
|
|
|
+
|
|
|
+**research_result.json 结构**：
|
|
|
+```json
|
|
|
+{
|
|
|
+ "researched_requirements": [
|
|
|
+ {
|
|
|
+ "abstract": "对应的抽象需求",
|
|
|
+ "findings": [
|
|
|
+ {
|
|
|
+ "type": "workflow | case_study | tool_tip | parameter",
|
|
|
+ "summary": "发现摘要",
|
|
|
+ "source": "来源平台和链接",
|
|
|
+ "detail": "详细内容"
|
|
|
+ }
|
|
|
+ ],
|
|
|
+ "recommended_approach": "综合调研结果后的推荐方案"
|
|
|
+ }
|
|
|
+ ]
|
|
|
+}
|
|
|
+```
|
|
|
+
|
|
|
+### 第三步：设计执行方案（生成 pipeline.json）
|
|
|
+
|
|
|
+综合以下信息，自行设计 `pipeline.json` 并保存到 `%output_dir%/pipeline.json`：
|
|
|
+
|
|
|
+**输入**：
|
|
|
+- `%output_dir%/requirements.json`：制作需求（抽象需求 + 具象点）
|
|
|
+- `%output_dir%/research_result.json`：Researcher 调研结果（工序、案例、工具技巧）
|
|
|
+- `%input_dir%/` 下的制作表 JSON：每张图的详细描述和构图信息
|
|
|
+- `%input_dir%/创作表.md`：整体创作视角
|
|
|
+- `%features_dir%/`：可用素材清单
|
|
|
+- Librarian 返回的工序方案、用户案例、工具能力信息
|
|
|
+
|
|
|
+**设计要点**：
|
|
|
+1. **确定图片顺序和链式关系**：根据制作表中各图的角色、构图关系，决定生成顺序和 chain_from 依赖
|
|
|
+2. **为每张图规划生成配置**：底图选择、参考素材、prompt、negative prompt、img2img 参数（strength 等）
|
|
|
+3. **将需求映射到具体图片**：每个 requirement 的 concrete_points 落实到对应图片的生成配置中
|
|
|
+4. **采纳 Librarian 推荐的工序**：优先使用关系表中已验证的工具链和参数配置
|
|
|
+5. **规划修复项**：根据需求优先级，列出 repair_items（Stage 4 细节修复清单）
|
|
|
+
|
|
|
+**pipeline.json 结构**：
|
|
|
+
|
|
|
+pipeline 是一个有序的 steps 列表，每个 step 对应一个可执行的操作。agent 设计 pipeline 时，应将生成、评估、迭代优化、一致性检查、细节修复等阶段都编排为具体的 step。
|
|
|
+
|
|
|
+```json
|
|
|
+{
|
|
|
+ "content_name": "内容名称",
|
|
|
+ "steps": [
|
|
|
+ {
|
|
|
+ "step_id": "step_1",
|
|
|
+ "type": "generate | evaluate | consistency_check | repair | custom",
|
|
|
+ "description": "该步骤的目标描述",
|
|
|
+ "expected_effect": "该步骤完成后图片应达到的视觉效果描述（具体、可感知）",
|
|
|
+ "checkpoints": [
|
|
|
+ "核心检查点1：可评估的具体标准（如'人物白裙V字露背设计清晰可见'）",
|
|
|
+ "核心检查点2：可评估的具体标准（如'调色板颜料厚度感明显，有立体笔触纹理'）"
|
|
|
+ ],
|
|
|
+ "depends_on": ["前置 step_id，为空则无依赖"],
|
|
|
+ "config": {
|
|
|
+ "// type=generate 时": "",
|
|
|
+ "target": "img_1",
|
|
|
+ "base_image": "%features_dir%/...",
|
|
|
+ "reference_images": ["%features_dir%/..."],
|
|
|
+ "chain_from_step": "null 或前序 generate step_id",
|
|
|
+ "prompt": "生成 prompt",
|
|
|
+ "negative_prompt": "负面 prompt",
|
|
|
+ "img2img_config": { "strength": 0.6 },
|
|
|
+ "mapped_requirements": ["对应的抽象需求"],
|
|
|
+
|
|
|
+ "// type=evaluate 时": "",
|
|
|
+ "target_step": "要评估的 generate step_id",
|
|
|
+ "pass_threshold": 7,
|
|
|
+ "retry_strategy": "问策 Librarian 后重新生成",
|
|
|
+
|
|
|
+ "// type=consistency_check 时": "",
|
|
|
+ "target_steps": ["要对比的多个 generate step_id"],
|
|
|
+ "dimensions": ["character", "clothing", "color", "lighting", "style"],
|
|
|
+
|
|
|
+ "// type=repair 时": "",
|
|
|
+ "target_step": "要修复的 step_id",
|
|
|
+ "repair_items": ["修复项描述"]
|
|
|
+ },
|
|
|
+ "output_path": "%output_dir%/img_1_restored_v1.png"
|
|
|
+ }
|
|
|
+ ],
|
|
|
+ "strategy_source": "工序方案来源说明（Librarian/Researcher/自行设计）"
|
|
|
+}
|
|
|
```
|
|
|
-- 对不一致的图，以当前结果为底图重新图生图
|
|
|
-- 如一致性问题严重，问策 Librarian 是否需要调研新的一致性保持技巧
|
|
|
|
|
|
-### 第七步：细节修复与输出（Stage 4）
|
|
|
-按 pipeline.json 的 repair_items 逐项检查修复。最终成品保存至 `%output_dir%/`。
|
|
|
+**设计要点**：
|
|
|
+1. **steps 的编排顺序即执行顺序**，通过 `depends_on` 表达依赖关系
|
|
|
+2. **每个 generate step 后通常跟一个 evaluate step**，评估不通过时按 `retry_strategy` 处理
|
|
|
+3. **将需求映射到具体 step**：每个 requirement 的 concrete_points 落实到对应 generate step 的配置中
|
|
|
+4. **采纳 Librarian 推荐的工序**：优先使用关系表中已验证的工具链和参数配置
|
|
|
+5. 设计完成后 review：每个 high priority 需求是否都在至少一个 step 中有体现
|
|
|
+6. **每个 step 必须填写 `expected_effect` 和 `checkpoints`**：`expected_effect` 描述该步骤完成后图片应呈现的视觉效果；`checkpoints` 列出 2-5 个可评估的具体标准，确保 evaluate step 有明确的评判依据。检查点应来自 requirements.json 中对应需求的 concrete_points
|
|
|
+
|
|
|
+### 第四步：按 pipeline 逐步执行
|
|
|
+
|
|
|
+遍历 `%output_dir%/pipeline.json` 中的 `steps`，按顺序逐步执行：
|
|
|
+
|
|
|
+- **generate**：组装该 step 的完整配置，派发 Craftsman 执行。如有 `chain_from_step`，将该前序 step 的最新输出路径一并传入。**必须提醒 Craftsman 读取 `%input_dir%/` 下该图对应的制作表 JSON（如 `写生油画__img_1_制作表.json`），从中提取构图、姿态、道具位置等细节融入 prompt**
|
|
|
+- **evaluate**：调用 evaluate_image 评估目标 step 的输出，**同时对照 `%input_dir%/` 下该图的制作表 JSON 中的具体描述进行逐项检查**（如制作表中描述"左手持调色板"，则检查生成图是否符合）。未达 `pass_threshold` 则按 `retry_strategy` 处理（问策 Librarian → 调整配置 → 重新生成，版本号递增）
|
|
|
+- **consistency_check**：用 evaluate_image 多图模式检查 `target_steps` 的输出一致性。不一致的图重新生成
|
|
|
+- **repair**：按 `repair_items` 逐项修复目标 step 的输出
|
|
|
+- **custom**：按 description 描述的逻辑执行
|
|
|
+
|
|
|
+每个 step 完成后，记录结果到 `%output_dir%/generation_log.md`。
|
|
|
|
|
|
### 知识回流
|
|
|
每个阶段完成后，将有价值的经验存入 KnowHub：
|
|
|
@@ -138,8 +307,8 @@ upload_knowledge(data="使用 nano_banana 图生图时，strength=0.6 + 链式
|
|
|
2. **参考素材路径**（完整路径）
|
|
|
3. **前序结果路径**（chain_from，如有）
|
|
|
4. **素材使用方式**：底图 → image_url，参考素材 → 辅助 prompt
|
|
|
-5. **Prompt 和生成配置**
|
|
|
-6. **源信息参考**：提醒 Craftsman 读取 `%input_dir%/raw_info/` 目录下对应图片的制作表 JSON（如 `写生油画__img_1_制作表.json`）和通用文件（`创作表.md`、`图片亮点.md`）
|
|
|
+5. **Prompt 和生成配置**（从 `%output_dir%/pipeline.json` 中对应图片的配置提取）
|
|
|
+6. **源信息参考**：提醒 Craftsman 读取 `%input_dir%/` 目录下对应图片的制作表 JSON（如 `写生油画__img_1_制作表.json`）和通用文件（`创作表.md`、`图片亮点.md`）
|
|
|
7. **输出路径**
|
|
|
|
|
|
## 评估原则
|
|
|
@@ -148,7 +317,7 @@ upload_knowledge(data="使用 nano_banana 图生图时，strength=0.6 + 链式
|
|
|
3. **上限点**：尽力还原，接受次优（评分 ≥ 7）
|
|
|
|
|
|
$user$
|
|
|
-请读取输入目录中的还原方案，开始执行完整的图像还原流程：
|
|
|
+请先从输入目录的内容描述文件中提取制作需求，然后将需求交给 Librarian 调研，最后执行完整的图像还原流程：
|
|
|
%input_dir%
|
|
|
|
|
|
输出目录：%output_dir%
|
