1049 lines
25 KiB
Markdown
1049 lines
25 KiB
Markdown
# 智能体页面整改升级文档
|
||
|
||
> 版本：2026-03-14
|
||
> 依据：当前项目实现 + 现有“智能体”页面代码 + 提供的业务流程图
|
||
> 目标：把当前“智能体预设页”升级为“可承载 SKU 素材拉取、业务规则选择、Prompt 分段组装、结果执行与复盘”的工作流型智能体页面。
|
||
|
||
---
|
||
|
||
## 1. 文档结论
|
||
|
||
当前系统已经具备一套可运行的“智能体预设执行底座”：
|
||
|
||
- 已有公共/私有智能体
|
||
- 已有固定四级分类
|
||
- 已有槽位提示词与参考图
|
||
- 已有智能体执行快照
|
||
- 已能在画布页右侧对话链路中串行执行智能体
|
||
|
||
但从你提供的流程图来看，业务想要的并不是“选一个预设然后上传 3 张图执行”，而是一个完整的家居场景工作流：
|
||
|
||
1. 先输入主 `sku` / 搭配 `sku`
|
||
2. 拉取素材库、品牌图、详情页图、点位图等结构化输入
|
||
3. 根据品牌/店铺/规则做预判
|
||
4. 进入人群选择
|
||
5. 再进入主题风格
|
||
6. 再进入空间与子空间
|
||
7. 再进入硬装、软装、光氛、配饰
|
||
8. 最后把多段 Prompt 进行结构化拼装并输出
|
||
|
||
所以本次整改的核心不是“继续往 AgentPreset 上堆字段”，而是：
|
||
|
||
- 保留当前 `AgentPreset` 作为“执行模板层”
|
||
- 在它之上新增“工作流编排层”
|
||
- 把当前智能体页面从“卡片库”升级为单一的“向导式工作流页面”
|
||
- 页面右侧只保留“轻量对话 / 执行面板”，不再保留独立的快捷预设模式
|
||
- 且每个环节的功能按钮名称、功能卡片预览图都必须由系统设置统一配置
|
||
|
||
一句话概括：
|
||
**现有系统适合做智能体模板库，不足以直接承载流程图里的业务编排。整改方向应当是“模板执行器 + 工作流引擎”双层架构。**
|
||
|
||
---
|
||
|
||
## 2. 当前系统现状梳理
|
||
|
||
### 2.1 当前页面形态
|
||
|
||
当前智能体模式挂载在画布页中，而不是独立的业务工作台：
|
||
|
||
- 页面入口：`app/canvas/[id]/page.tsx`
|
||
- 左侧：`components/agents/AgentPresetPanel.tsx`
|
||
- 右侧：`components/canvas/CanvasChatPanel.tsx`
|
||
|
||
现状本质上是：
|
||
|
||
- 左侧选一个智能体预设
|
||
- 右侧按预设要求上传图片并发送
|
||
- 后端按槽位顺序执行
|
||
- 结果回流到对话区与画布
|
||
|
||
### 2.2 当前已具备的能力
|
||
|
||
#### 页面层
|
||
|
||
- 支持“智能体模式”和普通画布模式切换
|
||
- 支持公共智能体 / 我的智能体
|
||
- 支持新建、编辑、删除、复制智能体
|
||
- 支持智能体预览图、二级类型、分类路径、槽位配置
|
||
|
||
#### 数据层
|
||
|
||
已有表结构：
|
||
|
||
- `AgentPreset`
|
||
- `AgentPresetSlot`
|
||
- `AgentPresetReferenceAsset`
|
||
- `AgentPresetExecutionSnapshot`
|
||
|
||
相关定义位于：
|
||
|
||
- `lib/db/schema.ts`
|
||
- `types/agent.ts`
|
||
|
||
#### 执行层
|
||
|
||
当前后端已经支持：
|
||
|
||
- 智能体权限校验
|
||
- 槽位串行执行
|
||
- 槽位参考图拼接
|
||
- 生图 / 视频执行
|
||
- 执行快照持久化
|
||
|
||
主链路位于：
|
||
|
||
- `app/(chat)/api/chat/route.ts`
|
||
|
||
### 2.3 当前设计的硬限制
|
||
|
||
这也是和流程图差距最大的部分：
|
||
|
||
1. 当前智能体更像“静态预设卡片”，不是“流程型工作台”
|
||
2. 分类是固定四级：
|
||
- 产品品类
|
||
- 人群标签
|
||
- 使用场景
|
||
- 品牌
|
||
3. 智能体执行目前对图片上传有明显固定假设：
|
||
- 非生文智能体只要有上传需求，默认就是 3 张图
|
||
- 前端文案直接写死为“产品图1、产品图2、模特图”
|
||
4. 现有页面没有工作流步骤状态，也没有“上一步/下一步/跳步/分支”
|
||
5. 现有 Prompt 组织方式是“槽位提示词”，不是“提示词 A/B/C/D/E/F/G 分段拼装”
|
||
6. 现有系统没有 SKU 素材库 API 编排、规则命中、候选方案推荐与拒绝回路
|
||
|
||
---
|
||
|
||
## 3. 对流程图的业务理解
|
||
|
||
从流程图可提炼出一条比较清晰的业务主链，虽然图中有若干分支和红字规则说明，但主干很明确。
|
||
|
||
### 3.1 阶段一：基础输入与素材回收
|
||
|
||
流程起点是：
|
||
|
||
- 输入主 `sku` / 搭配 `sku`
|
||
- 请求素材库 API
|
||
- 获取品牌选择 / 店铺选择相关上下文
|
||
- 返回商品点位图、品牌详情页图片、素材地址等
|
||
- 获取图片数据
|
||
|
||
这一阶段的本质不是“用户上传图”，而是：
|
||
|
||
- 由系统先拉结构化素材
|
||
- 再决定后续推荐路径
|
||
|
||
这意味着“智能体页”的第一页应该是“业务输入页”，不是“卡片列表页”。
|
||
|
||
### 3.2 阶段二：人群建模
|
||
|
||
流程图在人群选择阶段已经非常明确，属于家居场景策略分层，例如：
|
||
|
||
- 独居青年
|
||
- 年轻情侣 / 夫妻
|
||
- 中年无孩夫妻
|
||
- 有孩家庭
|
||
- 老年夫妻
|
||
|
||
同时还有一层更细的人设分型，用于产生 Prompt A / Prompt B 一类的中间结果。
|
||
这说明“人群”不是普通筛选条件，而是会直接影响：
|
||
|
||
- 场景叙事
|
||
- 风格偏好
|
||
- 家具陈列方式
|
||
- 软装组合策略
|
||
- 光影氛围
|
||
|
||
### 3.3 阶段三：主题风格选择
|
||
|
||
流程图中的风格选择是完整的业务核心层，至少包含：
|
||
|
||
- 日系风
|
||
- 新中式
|
||
- 美式
|
||
- 治愈风
|
||
- 现代风格
|
||
- 混搭风
|
||
- 中古风
|
||
- 奶油风
|
||
|
||
同时还存在“风格拒绝 / 风格不适配 / 进入其他匹配分支”的意思。
|
||
这说明页面必须支持：
|
||
|
||
- 推荐风格
|
||
- 人工改选风格
|
||
- 拒绝当前推荐并重新计算
|
||
- 记录本轮风格决策原因
|
||
|
||
### 3.4 阶段四：空间与子空间选择
|
||
|
||
流程图中空间不是单一字段，而是分层的，例如：
|
||
|
||
- 客厅
|
||
- 厨房
|
||
- 卧室
|
||
- 餐厅
|
||
- 书房
|
||
- 门厅
|
||
- 阳台
|
||
- 卫生间
|
||
|
||
并且至少存在子空间层，比如客厅下继续细分：
|
||
|
||
- 电视柜空间
|
||
- 沙发空间
|
||
|
||
这代表系统需要支持“房间 -> 区域”的双层空间定位，而不是现在简单的 `usageScenario`。
|
||
|
||
### 3.5 阶段五：硬装方案
|
||
|
||
流程图里在空间后进入硬装阶段，存在：
|
||
|
||
- 硬装方案 1
|
||
- 硬装方案 2
|
||
- 硬装方案 3
|
||
|
||
这说明需要有：
|
||
|
||
- 多候选方案推荐
|
||
- 用户选中其一
|
||
- 选中后产出新的 Prompt 片段
|
||
|
||
### 3.6 阶段六：软装方案
|
||
|
||
随后进入软装阶段，包括：
|
||
|
||
- 软装选择
|
||
- 软装方案 1 / 2
|
||
- 提炼软装搭配方案
|
||
- 再扩展为多个软装输出方案
|
||
|
||
这部分业务明显不是“一个下拉框”能承载的，它更像：
|
||
|
||
- 推荐集
|
||
- 策略收敛
|
||
- 再次展开
|
||
|
||
说明流程引擎要支持“先收敛后发散”的中间计算节点。
|
||
|
||
### 3.7 阶段七：光氛 / 时段
|
||
|
||
流程图中还有明显的氛围层，例如：
|
||
|
||
- 自然阳光
|
||
- 浪漫夜晚
|
||
- 其他光照氛围
|
||
|
||
这部分通常会影响：
|
||
|
||
- 色温
|
||
- 明暗
|
||
- 阴影
|
||
- 家具高光
|
||
- 玻璃 / 金属 / 木质表现
|
||
|
||
所以它应该成为 Prompt 里的独立片段，而不是塞在一句总提示词里。
|
||
|
||
### 3.8 阶段八：家居配饰陈列
|
||
|
||
流程图最后还有配饰陈列层，例如：
|
||
|
||
- 家居配饰方案 A
|
||
- 家居配饰方案 B
|
||
- 家居配饰方案 C
|
||
|
||
这说明业务最终追求的不是一个抽象 prompt，而是一套完整的空间视觉表达方案。
|
||
|
||
### 3.9 阶段九：Prompt 组合与最终输出
|
||
|
||
流程图最左侧存在多次“提示词 A / B / C / D / E / F / G ...”的汇总链路，底部还有：
|
||
|
||
- 提示词整合
|
||
- AI 优化提示词输出组合
|
||
- 输出
|
||
|
||
这说明真正的终态不是“保存一个智能体”，而是：
|
||
|
||
- 在多次选择后形成结构化 Prompt 资产
|
||
- 再将其交给生成执行层
|
||
- 并保留可复用、可复盘、可迭代的中间状态
|
||
|
||
---
|
||
|
||
## 4. 当前页面与流程图的差距诊断
|
||
|
||
| 维度 | 当前系统 | 流程图要求 | 结论 |
|
||
| --- | --- | --- | --- |
|
||
| 页面入口 | 预设卡片列表 | 向导式业务工作台 | 不匹配 |
|
||
| 数据输入 | 以手动上传为主 | `sku`、品牌、店铺、素材库 API | 缺失 |
|
||
| 分类结构 | 固定四级分类 | 多阶段决策流 | 不够 |
|
||
| 核心交互 | 选预设 -> 发消息 | 分阶段推荐、选择、拒绝、回退 | 缺失 |
|
||
| Prompt 结构 | 单槽位提示词 | Prompt A-G/H 分段组装 | 缺失 |
|
||
| 结果逻辑 | 槽位串行执行 | 工作流节点驱动执行 | 不够 |
|
||
| 输入图片规则 | 固定 3 张图 | 应由流程或模板动态决定 | 不合理 |
|
||
| 推荐机制 | 无真正推荐，只是筛选 | 根据品牌/店铺/规则给候选方案 | 缺失 |
|
||
| 异常分支 | 几乎没有 | 存在拒绝、重算、兜底 | 缺失 |
|
||
| 复盘能力 | 只有最终执行快照 | 需要节点级决策链路快照 | 不够 |
|
||
|
||
核心判断：
|
||
|
||
- 现在的“智能体页面”是一个**模板选择器**
|
||
- 你们流程图要做的是一个**流程型业务 Agent**
|
||
|
||
因此整改不应仅停留在 UI 调整，而应该同步升级：
|
||
|
||
- 页面交互模型
|
||
- 数据模型
|
||
- 后端编排模型
|
||
- Prompt 资产模型
|
||
|
||
---
|
||
|
||
## 5. 整改升级目标
|
||
|
||
### 5.1 业务目标
|
||
|
||
将智能体页面升级为一套面向家居场景业务的工作流平台，支持：
|
||
|
||
1. 结构化输入业务参数
|
||
2. 自动回收素材库和品牌资源
|
||
3. 分阶段完成人群、风格、空间、硬装、软装、光氛、配饰选择
|
||
4. 自动生成分段 Prompt
|
||
5. 一键调用底层生图 / 视频执行器
|
||
6. 沉淀流程资产与执行资产
|
||
|
||
### 5.2 技术目标
|
||
|
||
1. 保留当前 `AgentPreset` 体系，不推倒重来
|
||
2. 在其上新增 `Workflow` 层
|
||
3. 页面只保留“工作流模式”，右侧保留轻量对话 / 执行面板
|
||
4. 所有流程步骤都支持配置化，而非写死在页面里
|
||
5. 中间过程必须可追踪、可回显、可恢复
|
||
|
||
### 5.3 产品目标
|
||
|
||
让运营、策划、业务同学未来可以不用改代码就维护：
|
||
|
||
- 人群选项
|
||
- 风格选项
|
||
- 空间选项
|
||
- 方案推荐规则
|
||
- Prompt 片段模板
|
||
- 输出模板
|
||
- 每个环节的功能按钮名称
|
||
- 每个环节的功能卡片预览图
|
||
|
||
---
|
||
|
||
## 6. 升级后的总体方案
|
||
|
||
### 6.1 总体架构建议
|
||
|
||
建议采用双层架构：
|
||
|
||
#### 第一层：工作流编排层
|
||
|
||
负责：
|
||
|
||
- 管业务步骤
|
||
- 管每一步的候选项
|
||
- 管依赖关系和分支
|
||
- 管 API 拉取和规则命中
|
||
- 管 Prompt 分段组装
|
||
|
||
#### 第二层：执行模板层
|
||
|
||
继续复用现有 `AgentPreset`，负责：
|
||
|
||
- 选择底层模型
|
||
- 组织参考图
|
||
- 处理最终执行参数
|
||
- 串行执行生成
|
||
- 输出消息流与快照
|
||
|
||
### 6.2 不建议的做法
|
||
|
||
不建议把流程图里的所有信息都继续塞进当前 `AgentPreset.categoryPath` 或 `slots` 中，因为这会导致：
|
||
|
||
- 配置越来越混乱
|
||
- 前后端逻辑高度耦合
|
||
- 无法表达分支、推荐、拒绝和回退
|
||
- 后续维护成本极高
|
||
|
||
### 6.3 建议的交互模式
|
||
|
||
在 `/canvas/[id]?mode=agent` 下只保留一种交互模式：
|
||
|
||
1. 工作流模式
|
||
- 左侧为步骤流工作台
|
||
- 右侧为轻量对话 / 执行面板
|
||
- 底层继续复用 `AgentPreset` 作为执行模板层
|
||
|
||
这里要明确区分：
|
||
|
||
- 页面模式：只保留工作流模式
|
||
- 底层能力：继续复用现有智能体预设、执行链路、执行快照
|
||
|
||
也就是说，后续不再把“公共/私有智能体卡片墙”作为用户主界面，而是把它沉到配置层或模板层。
|
||
|
||
---
|
||
|
||
## 7. 页面整改方案
|
||
|
||
### 7.1 页面布局建议
|
||
|
||
建议将页面固定为“左侧工作流面板 + 右侧轻量对话 / 执行面板”。
|
||
|
||
#### 左侧工作流面板
|
||
|
||
由上到下分成五块：
|
||
|
||
1. 项目基础信息
|
||
- 主 `sku`
|
||
- 搭配 `sku`
|
||
- 品牌
|
||
- 店铺
|
||
- 素材拉取状态
|
||
|
||
2. 步骤导航
|
||
- 基础输入
|
||
- 人群
|
||
- 风格
|
||
- 空间
|
||
- 硬装
|
||
- 软装
|
||
- 光氛
|
||
- 配饰
|
||
- 输出确认
|
||
|
||
3. 当前步骤候选区
|
||
- 推荐项
|
||
- 全量项
|
||
- 拒绝重算
|
||
- 手动覆盖
|
||
- 每个候选项以功能卡片展示，卡片标题和预览图均从系统设置读取
|
||
|
||
4. Prompt 预览区
|
||
- Prompt A
|
||
- Prompt B
|
||
- Prompt C ...
|
||
- 最终组合 Prompt
|
||
|
||
5. 执行区
|
||
- 生成预览
|
||
- 执行按钮
|
||
- 执行日志
|
||
|
||
#### 右侧轻量对话 / 执行面板
|
||
|
||
继续复用 `CanvasChatPanel`，承接：
|
||
|
||
- 中间说明
|
||
- 用户补充一句自然语言要求
|
||
- 执行结果
|
||
- 图片 / 视频流式回显
|
||
- 结果落盘到画布
|
||
|
||
但这里不再承担主流程选择，不再作为页面的主要操作入口。
|
||
|
||
### 7.2 页面交互原则
|
||
|
||
1. 每一步都要显示“为什么推荐”
|
||
2. 每一步都允许用户手动改选
|
||
3. 改选后，后续依赖步骤要自动刷新
|
||
4. 每一步都要保存状态，支持离开后继续
|
||
5. 需要提供“查看 Prompt 来源”的透明化能力
|
||
6. 所有步骤按钮、方案按钮、功能卡片都不得在前端写死名称与图片，必须读取后台配置
|
||
|
||
---
|
||
|
||
## 8. 数据模型整改建议
|
||
|
||
当前表可以保留，但需要新增一组“工作流配置 + 会话状态”表。
|
||
|
||
### 8.1 保留的现有表
|
||
|
||
- `AgentPreset`
|
||
- `AgentPresetSlot`
|
||
- `AgentPresetReferenceAsset`
|
||
- `AgentPresetExecutionSnapshot`
|
||
- `CanvasProject`
|
||
|
||
### 8.2 建议新增的核心表
|
||
|
||
#### `AgentWorkflowTemplate`
|
||
|
||
定义一个工作流模板，例如：
|
||
|
||
- 家居场景图工作流
|
||
- 家具详情图工作流
|
||
- 品牌空间搭配工作流
|
||
|
||
关键字段建议：
|
||
|
||
- `id`
|
||
- `name`
|
||
- `code`
|
||
- `description`
|
||
- `presetType`
|
||
- `status`
|
||
- `version`
|
||
- `entryConfig`
|
||
- `outputConfig`
|
||
|
||
#### `AgentWorkflowStep`
|
||
|
||
定义工作流中的一个步骤，例如：
|
||
|
||
- 人群选择
|
||
- 风格选择
|
||
- 空间选择
|
||
- 硬装方案选择
|
||
|
||
关键字段建议：
|
||
|
||
- `workflowId`
|
||
- `stepKey`
|
||
- `stepType`
|
||
- `title`
|
||
- `description`
|
||
- `sortOrder`
|
||
- `isRequired`
|
||
- `dependsOn`
|
||
- `uiConfig`
|
||
- `dataSourceConfig`
|
||
- `promptFragmentConfig`
|
||
|
||
#### `AgentWorkflowOption`
|
||
|
||
定义步骤内的候选项，例如：
|
||
|
||
- 独居青年
|
||
- 日系风
|
||
- 客厅
|
||
- 电视柜空间
|
||
|
||
关键字段建议：
|
||
|
||
- `workflowId`
|
||
- `stepKey`
|
||
- `optionKey`
|
||
- `label`
|
||
- `displayName`
|
||
- `buttonName`
|
||
- `previewAssetId`
|
||
- `previewImageUrl`
|
||
- `value`
|
||
- `tags`
|
||
- `promptFragment`
|
||
- `sortOrder`
|
||
- `ruleConfig`
|
||
|
||
#### `AgentWorkflowSession`
|
||
|
||
一次用户真实使用工作流时的会话。
|
||
|
||
关键字段建议：
|
||
|
||
- `id`
|
||
- `workflowId`
|
||
- `projectId`
|
||
- `userId`
|
||
- `status`
|
||
- `inputPayload`
|
||
- `resolvedContext`
|
||
- `assembledPrompt`
|
||
- `selectedExecutionPresetId`
|
||
- `createdAt`
|
||
- `updatedAt`
|
||
|
||
#### `AgentWorkflowStepState`
|
||
|
||
存储一次会话中每一步的状态。
|
||
|
||
关键字段建议：
|
||
|
||
- `sessionId`
|
||
- `stepKey`
|
||
- `selectedOption`
|
||
- `candidateOptions`
|
||
- `decisionReason`
|
||
- `promptFragment`
|
||
- `status`
|
||
- `version`
|
||
|
||
#### `AgentWorkflowMaterialSnapshot`
|
||
|
||
记录素材库 API 拉回来的上下文快照。
|
||
|
||
关键字段建议：
|
||
|
||
- `sessionId`
|
||
- `sku`
|
||
- `materialSource`
|
||
- `payload`
|
||
- `normalizedPayload`
|
||
- `status`
|
||
|
||
### 8.3 系统设置配置项建议
|
||
|
||
这条是本次新增的强制要求：
|
||
|
||
- 每个环节都要能在系统设置里编辑功能名字
|
||
- 每个环节都要能在系统设置里编辑功能卡片预览图
|
||
|
||
这里的“每个环节”至少包括：
|
||
|
||
- 人群按钮
|
||
- 风格按钮
|
||
- 空间按钮
|
||
- 子空间按钮
|
||
- 硬装方案按钮
|
||
- 软装方案按钮
|
||
- 光氛按钮
|
||
- 配饰方案按钮
|
||
- 其他后续扩展出来的工作流节点按钮
|
||
|
||
建议不要把这些内容继续零散塞在多个老配置字段里，而是新增一组专门的工作流 UI 配置，例如：
|
||
|
||
- `agentWorkflowUiConfig`
|
||
|
||
建议结构：
|
||
|
||
```json
|
||
{
|
||
"steps": {
|
||
"audience": {
|
||
"title": "人群选择",
|
||
"options": [
|
||
{
|
||
"key": "single_youth",
|
||
"buttonName": "独居青年",
|
||
"previewImageUrl": "https://...",
|
||
"description": "适合小户型、年轻感、轻量生活方式"
|
||
}
|
||
]
|
||
},
|
||
"style": {
|
||
"title": "主题风格",
|
||
"options": [
|
||
{
|
||
"key": "cream_style",
|
||
"buttonName": "奶油风",
|
||
"previewImageUrl": "https://..."
|
||
}
|
||
]
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
前台页面约束建议：
|
||
|
||
1. 所有按钮文案优先读取 `buttonName`
|
||
2. 所有卡片图片优先读取 `previewImageUrl`
|
||
3. 未配置图片时才显示默认占位图
|
||
4. 未配置名称时才回退到系统内置 key 对应文案
|
||
|
||
### 8.4 后台配置方式建议
|
||
|
||
系统设置页需要新增“工作流功能卡片配置”区域，支持：
|
||
|
||
1. 按步骤管理卡片
|
||
2. 修改按钮名称
|
||
3. 上传或替换预览图
|
||
4. 控制排序
|
||
5. 启用/停用单个选项
|
||
6. 配置说明文案
|
||
|
||
后台的目标不是只管理“分类列表”，而是管理：
|
||
|
||
- 这个步骤显示哪些按钮
|
||
- 这些按钮怎么叫
|
||
- 卡片长什么样
|
||
- 用户点了之后对应什么业务值
|
||
|
||
### 8.5 与现有 `AgentPreset` 的关系
|
||
|
||
推荐关系如下：
|
||
|
||
- `Workflow` 负责“怎么走流程”
|
||
- `AgentPreset` 负责“最终怎么执行”
|
||
|
||
可以有两种落地方式：
|
||
|
||
1. 一个工作流最终绑定一个执行预设
|
||
2. 一个工作流根据不同分支绑定不同执行预设
|
||
|
||
建议先做第 1 种，简单稳定。
|
||
|
||
---
|
||
|
||
## 9. 接口整改建议
|
||
|
||
### 9.1 保留现有接口
|
||
|
||
继续保留：
|
||
|
||
- `GET /api/agents`
|
||
- `POST /api/agents`
|
||
- `PUT /api/agents/[id]`
|
||
- `POST /api/agents/[id]/fork`
|
||
- `POST /app/(chat)/api/chat/route.ts`
|
||
|
||
这些接口不再直接服务独立的“快捷模式页面”，而是继续作为底层模板管理与执行能力存在。
|
||
|
||
### 9.2 建议新增的工作流接口
|
||
|
||
#### 模板与配置
|
||
|
||
- `GET /api/agent-workflows`
|
||
- `GET /api/agent-workflows/[id]`
|
||
- `POST /api/agent-workflows`
|
||
- `PUT /api/agent-workflows/[id]`
|
||
- `GET /api/admin/agent-workflow-ui-config`
|
||
- `PUT /api/admin/agent-workflow-ui-config`
|
||
|
||
#### 会话与步骤
|
||
|
||
- `POST /api/agent-workflow-sessions`
|
||
- `GET /api/agent-workflow-sessions/[id]`
|
||
- `PATCH /api/agent-workflow-sessions/[id]/steps/[stepKey]`
|
||
- `POST /api/agent-workflow-sessions/[id]/recalculate`
|
||
|
||
#### 素材回收
|
||
|
||
- `POST /api/agent-workflow-sessions/[id]/fetch-materials`
|
||
- `POST /api/agent-workflow-sessions/[id]/refresh-recommendations`
|
||
|
||
#### Prompt 与执行
|
||
|
||
- `POST /api/agent-workflow-sessions/[id]/assemble-prompt`
|
||
- `POST /api/agent-workflow-sessions/[id]/execute`
|
||
|
||
说明：
|
||
|
||
- 工作流模板接口负责“业务结构”
|
||
- 工作流 UI 配置接口负责“按钮名字、卡片预览图、排序和展示态”
|
||
|
||
### 9.3 现有聊天接口需要同步整改的点
|
||
|
||
当前聊天链路把非生文智能体上传需求硬编码成了 3 张图。
|
||
后续应调整为：
|
||
|
||
- 从工作流会话读取动态输入要求
|
||
- 从执行模板读取最低执行输入要求
|
||
- 前端按实际配置渲染上传槽位
|
||
|
||
也就是说，“产品图1 / 产品图2 / 模特图”应该从业务配置中来，而不是写死在页面中。
|
||
|
||
---
|
||
|
||
## 10. Prompt 资产整改建议
|
||
|
||
### 10.1 将 Prompt 从“整段字符串”升级为“分段资产”
|
||
|
||
建议把流程图中的提示词链路标准化为：
|
||
|
||
- Prompt A：人群画像
|
||
- Prompt B：生活方式 / 情境扩展
|
||
- Prompt C：风格定义
|
||
- Prompt D：空间与功能区约束
|
||
- Prompt E：硬装约束
|
||
- Prompt F：软装与材质搭配
|
||
- Prompt G：光影氛围
|
||
- Prompt H：配饰陈列与视觉收口
|
||
|
||
### 10.2 最终 Prompt 组装格式建议
|
||
|
||
最终建议输出两份内容：
|
||
|
||
#### 面向模型的执行 Prompt
|
||
|
||
用于最终生图 / 视频调用。
|
||
|
||
#### 面向页面的结构化 Prompt 说明
|
||
|
||
用于展示给用户和运营看，例如：
|
||
|
||
```json
|
||
{
|
||
"audience": "年轻情侣",
|
||
"style": "奶油风",
|
||
"room": "客厅",
|
||
"subSpace": "沙发空间",
|
||
"hardDecoration": "方案2",
|
||
"softDecoration": "方案1",
|
||
"lighting": "自然阳光",
|
||
"accessories": "陈列B"
|
||
}
|
||
```
|
||
|
||
这样可以解决两个问题：
|
||
|
||
1. 用户知道最终结果是怎么来的
|
||
2. 后续便于埋点和复盘
|
||
|
||
### 10.3 Prompt 组装建议
|
||
|
||
最终 Prompt 建议由以下几块拼装：
|
||
|
||
1. 商品约束
|
||
2. 品牌与店铺约束
|
||
3. 人群设定
|
||
4. 风格设定
|
||
5. 空间与子空间设定
|
||
6. 硬装设定
|
||
7. 软装设定
|
||
8. 光氛设定
|
||
9. 配饰陈列设定
|
||
10. 负向约束
|
||
11. 输出质量要求
|
||
|
||
---
|
||
|
||
## 11. 推荐与规则引擎建议
|
||
|
||
流程图里存在很多红字说明，代表你们业务不是纯手动选择，而是有系统规则参与。
|
||
|
||
因此建议增加一层规则引擎，至少支持：
|
||
|
||
1. 根据品牌返回默认风格偏好
|
||
2. 根据店铺近 7 天热度或业务规则推荐优先方案
|
||
3. 根据 `sku` 类目推荐适合人群
|
||
4. 根据空间和风格过滤不适用方案
|
||
5. 用户拒绝当前推荐后，给出替代候选
|
||
|
||
规则层不一定第一期就做成复杂 DSL，但至少要把逻辑从前端 if/else 中拿出来，放到配置层或服务层。
|
||
|
||
同时要注意把“规则配置”和“展示配置”分开：
|
||
|
||
- 规则配置决定推荐逻辑
|
||
- 展示配置决定按钮名称和预览图
|
||
|
||
不要把卡片图片和按钮文案混进规则代码里。
|
||
|
||
---
|
||
|
||
## 12. 执行快照整改建议
|
||
|
||
当前已有 `AgentPresetExecutionSnapshot`，但它更偏“执行结果快照”，不够表达工作流全过程。
|
||
|
||
建议增加两类快照：
|
||
|
||
### 12.1 流程快照
|
||
|
||
记录：
|
||
|
||
- 每一步选择了什么
|
||
- 为什么推荐
|
||
- 是否手动覆盖
|
||
- Prompt 片段是什么
|
||
|
||
### 12.2 执行快照
|
||
|
||
继续记录：
|
||
|
||
- 最终执行模型
|
||
- 输入图片
|
||
- 最终 Prompt
|
||
- 输出图片 / 视频
|
||
|
||
这样以后才能回答：
|
||
|
||
- 这张图为什么会生成成这样？
|
||
- 是哪个阶段的选择导致的？
|
||
- 哪个人群 / 风格组合转化更高？
|
||
|
||
---
|
||
|
||
## 13. 分期实施建议
|
||
|
||
### Phase 1：页面结构整改
|
||
|
||
目标：
|
||
|
||
- 收敛为单一工作流模式
|
||
- 左侧改造成步骤导航 + 步骤候选区 + Prompt 预览区
|
||
- 右侧保留轻量对话 / 执行面板
|
||
|
||
交付：
|
||
|
||
- 新工作流面板 UI
|
||
- 轻量对话 / 执行面板 UI 收敛
|
||
- 工作流会话状态管理
|
||
- 基础步骤切换和保存
|
||
|
||
### Phase 2：数据与配置整改
|
||
|
||
目标：
|
||
|
||
- 新增工作流模板、步骤、选项、会话、步骤状态表
|
||
- 后台支持配置步骤选项与基础 Prompt 片段
|
||
|
||
交付：
|
||
|
||
- 数据库迁移
|
||
- 工作流 CRUD 接口
|
||
- 后台配置入口
|
||
- 工作流功能按钮名称与预览图配置能力
|
||
|
||
### Phase 3：素材 API 与规则接入
|
||
|
||
目标：
|
||
|
||
- 接入 `sku` 素材库
|
||
- 接入品牌/详情图/点位图回收
|
||
- 加入基础推荐逻辑
|
||
|
||
交付：
|
||
|
||
- 素材获取接口
|
||
- 推荐结果回填
|
||
- 拒绝重算链路
|
||
|
||
### Phase 4：Prompt 引擎与执行联动
|
||
|
||
目标：
|
||
|
||
- 实现 Prompt A-H 分段资产
|
||
- 将最终 Prompt 接入现有执行模板
|
||
- 支持动态输入槽位
|
||
|
||
交付：
|
||
|
||
- Prompt 组装服务
|
||
- 聊天执行链路对接
|
||
- 动态上传槽位与执行参数
|
||
|
||
### Phase 5：复盘与运营能力
|
||
|
||
目标：
|
||
|
||
- 工作流快照
|
||
- 转化分析
|
||
- 方案命中率分析
|
||
|
||
交付：
|
||
|
||
- 决策链路回放
|
||
- 推荐命中统计
|
||
- 执行效果分析面板
|
||
|
||
---
|
||
|
||
## 14. 风险点
|
||
|
||
### 14.1 最大风险
|
||
|
||
如果继续沿用“当前预设卡片模型”硬扩展，会快速出现：
|
||
|
||
- 字段爆炸
|
||
- 逻辑散落前端
|
||
- 分支不可维护
|
||
- 配置不可复用
|
||
|
||
### 14.2 第二个风险
|
||
|
||
如果一次性从“预设卡片 + 对话框”切换到“工作流模式”，会带来认知迁移成本。
|
||
但本次产品方向已经明确为只保留工作流模式，因此建议：
|
||
|
||
- 不再保留双模式入口
|
||
- 在页面中用明确步骤导航和默认推荐项降低学习成本
|
||
- 通过轻量对话 / 执行面板承接补充输入和结果追调
|
||
|
||
### 14.3 第三个风险
|
||
|
||
如果素材 API、规则引擎、Prompt 组装全部在第一期一起做，开发跨度太大。
|
||
建议按“页面壳子 -> 数据配置 -> 素材接入 -> 执行联动”逐步推进。
|
||
|
||
---
|
||
|
||
## 15. 验收标准建议
|
||
|
||
本次整改完成后，至少应满足以下标准：
|
||
|
||
1. 用户可以在智能体页直接输入主 `sku` / 搭配 `sku`
|
||
2. 页面可拉取素材库数据并展示回收结果
|
||
3. 用户可以按步骤完成：
|
||
- 人群
|
||
- 风格
|
||
- 空间
|
||
- 硬装
|
||
- 软装
|
||
- 光氛
|
||
- 配饰
|
||
4. 每一步都可以看到推荐项和手动覆盖项
|
||
5. 系统可以实时生成分段 Prompt 和最终 Prompt
|
||
6. 最终 Prompt 可以联动现有生图 / 视频执行链路
|
||
7. 全过程状态可保存、可恢复、可复盘
|
||
8. 每个环节的功能按钮名称都可在系统设置编辑
|
||
9. 每个环节的功能卡片预览图都可在系统设置上传与替换
|
||
|
||
---
|
||
|
||
## 16. 对当前代码的具体整改建议
|
||
|
||
### 应保留复用
|
||
|
||
- `app/canvas/[id]/page.tsx`
|
||
- 继续作为页面入口
|
||
- `components/canvas/CanvasChatPanel.tsx`
|
||
- 继续作为执行与结果区
|
||
- `app/(chat)/api/chat/route.ts`
|
||
- 继续作为统一执行入口
|
||
- `AgentPreset*` 相关表与组件
|
||
- 继续作为模板执行层
|
||
|
||
### 应重点改造
|
||
|
||
- `components/agents/AgentPresetPanel.tsx`
|
||
- 从卡片筛选面板升级为“纯工作流面板”
|
||
- `components/agents/AgentPresetDialog.tsx`
|
||
- 与工作流模板编辑器解耦
|
||
- `app/(chat)/api/chat/route.ts`
|
||
- 去掉固定 3 张上传的硬编码依赖
|
||
- 适配工作流右侧轻量执行面板
|
||
- `app/(admin)/settings/admin-settings-client.tsx`
|
||
- 后台配置从“固定四级分类”扩展为“工作流配置中心”
|
||
- 新增每个环节按钮名称与功能卡片预览图配置
|
||
- `app/api/site-settings/route.ts`
|
||
- 增加工作流 UI 配置字段的读写
|
||
- 智能体工作流左侧步骤组件
|
||
- 所有按钮名称和卡片预览图都从系统设置读取
|
||
|
||
### 应新增
|
||
|
||
- 工作流模板配置页
|
||
- 工作流会话状态服务
|
||
- 素材回收服务
|
||
- Prompt 组装服务
|
||
- 推荐规则服务
|
||
- 工作流功能卡片配置的数据结构与上传能力
|
||
|
||
---
|
||
|
||
## 17. 最终建议
|
||
|
||
本项目下一步不建议再把“智能体页面”理解成“更多卡片、更多筛选项、更多槽位”。
|
||
正确方向应该是：
|
||
|
||
**把当前智能体能力降级为底层执行器，把真正的业务体验统一收敛为单一工作流编排页面。**
|
||
|
||
这样做的好处是：
|
||
|
||
1. 不浪费当前已经写好的智能体执行链路
|
||
2. 能真正承接流程图里的复杂业务流程
|
||
3. 后续可扩展到更多行业工作流，而不只是当前家居场景
|
||
|
||
---
|
||
|
||
## 18. 推荐的下一步动作
|
||
|
||
建议你们下一步按下面顺序继续推进：
|
||
|
||
1. 先确认这份文档里的工作流拆解是否和业务理解一致
|
||
2. 再确定第一期到底做“纯页面壳子”还是“页面壳子 + 素材拉取”
|
||
3. 然后我可以继续帮你们往下出第二份文档：
|
||
- 页面原型与信息架构文档
|
||
- 或数据库/API 详细设计文档
|