Interface Lab
登录
Agent 深度解析

Agent 深度解析

面向零基础读者，完整拆解项目创作 Agent 的界面、流程、事件、数据、保存模型和项目 review 结论。

Interface Lab Agent 深度解析

Last updated: 2026-06-11

2026-06-11 更新

Preview 现在不只是展示 iframe。生成后服务端会先做静态渲染契约 QA，拦截空白 HTML、root-only 壳和 Prompt 文档泄漏等明显问题；前端 Preview iframe 还会回传 runtime QA 摘要，包括可见文本长度、横向溢出、图片加载、console error 和 runtime error，并写回 qa_report.runtimeRenderQa。如果本轮命中了知识库，Orson 的 Preview 审查区也会显示知识执行证据摘要，提示哪些知识有页面/源码信号、哪些需要复核。这个检查不依赖 Playwright，适合在线 Agent 的同步路径；Playwright/Browserless/CI 属于异步浏览器验收层，WORKFLOW_BROWSER_QA_AUTO_ENQUEUE=true 可让生成/保存后自动排队，npm run workflow:browser-qa:run 可在本地/CI/worker 环境消费队列并把结果写入 workflow_browser_qa_runs，截图会写入私有 workflow-browser-qa-artifacts bucket，作品分析页会用 signed URL 展示 QA 摘要和缩略图。常驻 worker 和自动修复闭环仍是下一阶段。

2026-05-20 更新

项目创作页现在把同一条 workflow 呈现为 PM 调度的 Agent Team，并把 PM 聊天和 Overview 合并成 PM Hub / Intent Overview。底部输入框只负责输入、附件、模型选择和发送；Agent 的工作进度和完成汇报显示在各自的画布工作区里。Designer 负责 Design System；文案与信息架构负责网站结构和 section 内容；Skill 管理员负责 Skills 推荐与取舍；Programmer 负责 Preview 里的 Code tab；质检评审负责 Prompt QA 和 Preview 检查状态。

普通 brief 现在会在同一个后端 workflow 内拆成 PM、Designer、Content、Skill Manager、QA 的角色化模型调用。这比单次大 JSON 规划更接近真实团队分工，但仍不是持久化的多 subagent runtime。规划器还会拦截内部模板短语，避免 Use the exact colors、User brief:、problem / process / outcome 这类内容污染 Design System、Content 或 Full Prompt；并为“电商数据看板”这类 dashboard 需求生成真实指标、图表、筛选器、表格和操作规划。

2026-05-18 更新

Agent 现在会在生成代码前展示 Intent Map、Decision Board、Capability Fit、Design System Hub、Prompt Template 和 Prompt QA。默认 discussion 模式停在方案确认；Auto 开启且 Prompt QA 通过后才继续生成代码。

2026-05-17 更新：项目创作页保留固定左侧 Agent 面板和右侧 React Flow 无限画布。网站模式默认出现 Overview、Skills、Design System、网站架构、分 section 内容输入、约束、Full Prompt 和 Preview；Code 不再是独立画布节点，而是 Preview 大窗口里的 代码 tab。生成代码时自动切到 代码 tab，预览 artifact 完成后自动切回 Preview tab，之后用户可以手动切换。Skill 选择移入右侧 Skills 推荐卡片，网站架构支持加号新增 section 并选择常见类型，Design System 和 Full Prompt 默认展示分区块。连线默认半透明，生成中播放动画，完成后变为白色。用户仍不右键建节点，也不手动拖拽连线。

这篇文档给谁看

这篇文档写给第一次接触 AI Agent、也不熟悉前端工程的人。它不是接口清单，也不是给维护者看的变更备忘，而是把 Interface Lab 里的项目创作 Agent 拆开讲清楚：它在页面上看起来是什么、背后由哪些模块协作、一次生成从哪里开始、为什么要先保存草稿、什么时候才会进入“我的项目”。

如果只记住一句话：Interface Lab 的 Agent 是一个“带流程图的 UI 生成工作台”。用户在统一输入框里给它文字、链接、代码、图片和文件，再选择模型，并在右侧 Skills 卡片里选择或接受推荐；网站模式会先把需求拆成 PM Hub、Skills、Design System、网站架构、Prompt QA、Full Prompt 和 Preview，最后由用户显式保存成正式作品。

先用生活语言理解 Agent

普通聊天机器人像一个会回答问题的人。Interface Lab 的 Agent 更像一个小型设计制作组：

  • PM Hub：汇总用户需求、意图判断、缺失信息、方案确认和 PM 汇报。
  • 输入器：从统一输入框接收用户需求、素材、图片、链接和代码。
  • 产品经理：判断需求是否清楚；不清楚时，把缺失信息放进 PM Hub 或对应节点，并给用户选项式追问。
  • 设计师：整理 Design System，看页面应该长什么样。
  • 文案与信息架构：整理网站架构、内容输入、标题、CTA、SEO/alt 文案和页面模块。
  • Skill 管理员：从真实 Skills 库中推荐、解释和限制最多 8 个 Skill。
  • Prompt 工程师：把规划节点整理成可以复用的 Full Prompt。
  • 前端工程师：把 Full Prompt 写成单文件 HTML。
  • 质检评审：检查 Prompt 是否允许进入代码生成，并把阻断或警告显示在 Prompt QA。
  • 预览员：把 HTML 放进支持脚本运行的 sandbox iframe 里，让用户直接看结果。
  • 归档员：用户点击 Save work 后，才把草稿发布成“我的项目”；用户也可以从“我的项目”删除作品或发布到社区。

这就是为什么它不是“点一下直接出图”的工具，而是一条可追踪、可修改、可保存的创作链路。

当前 Agent 在网站里的位置

Rendering diagram...

Agent 是 Interface Lab 从“看作品”走向“生成自己的作品”的核心入口。它的主要页面是：

  • 页面入口：/[locale]/create/new
  • 已保存项目列表：/[locale]/create
  • 已保存作品分析：/[locale]/create/[id]，会回看 Style / Prompt / HTML，并在有关联 workflow 时显示 RAG / Agent 证据摘要，包括知识执行信号、角色产物摘要、Agent Team health（平均置信度、阻断/风险、低置信角色）和已持久化的 compact task timeline。
  • 从作品回到可编辑 Agent：/[locale]/create/new?work=<generatedPageId>

用户能看到什么

用户在项目创作页看到的是一个分区工作台：

  • 左侧输入与控制区：统一输入框、网站/PPT/移动应用模式、模型选择和权限提示。
  • 统一输入框：支持文字、链接、代码、附件选择、文件拖拽和图片粘贴；上传后的素材会显示为可移除 chip。
  • 右侧无限画布：网站模式下自动显示 PM Hub / Overview、Skills、Design System、网站架构、Prompt QA、Full Prompt 和 Preview。
  • Preview：同一个大窗口里包含 代码 和 Preview 两个 tab，代码生成中自动显示代码，生成完成后自动切到最终 iframe 预览，并显示 iframe runtime QA 状态。
  • 连线动画：默认半透明，Agent 推进时变成输送动画，完成后变为白色，用户不手动连线。
  • 顶部保存按钮：把当前 workflow 草稿发布到“我的项目”。

页面默认把模型和素材收进底部小按钮里，Skills 则放进右侧推荐卡片；Agent 汇报不再挤在输入区，而是在对应节点内显示。

网站模式的节点

当前网站模式节点是固定的：

  1. PM Hub / Overview：用户需求摘要、意图判断、缺失信息、方案确认和 PM 汇报。
  2. Skills：根据需求从 Skill 库中推荐合适能力，也允许用户在同一张卡片里手动选择。
  3. Design System：整理视觉方向、色彩、字体、布局、组件和动效。
  4. 网站架构：整理页面模块、导航、section 顺序、标题、正文、CTA、SEO/alt 文案和响应式结构。
  5. Prompt QA：检查 Prompt 质量、阻断项和警告，并判断是否允许进入代码生成。
  6. Full Prompt：把前面节点编译成最终代码生成提示词。
  7. Preview 的 代码 tab：显示生成代码 artifact。普通需求显示单文件 HTML；DeepSeek full prompt 会显示 React/Vite 文件包。
  8. Preview 的 Preview tab：把最终 htmlCode 放进 sandbox="allow-scripts" 的 iframe 里预览。React/Vite 文件包会先由服务端构建，再内联回 iframe 可用的 HTML。iframe 会回传 runtime QA 摘要，让 Orson 能看到空白、横向溢出、图片加载和控制台错误风险。

这些节点不是装饰，而是前后端共享的一套状态语言。服务端用 SSE 事件告诉前端“哪个节点开始了”“哪条连线激活了”“哪个节点完成了”，前端再把这些事件变成动画和内容更新。

Full Prompt 的 React/Vite 模式

当用户粘贴的是完整 React/Vite/Tailwind 实现 prompt，并且选择 DeepSeek 模型时，Agent 现在默认走真实 React/Vite artifact 路径，而不是先把 prompt 压缩成 brief。

  • 模型直接收到原始 full prompt。默认情况下，服务端会让 DeepSeek 分别生成更小的 Hero、ContentSections 组件和 index.css，App.tsx 只由服务端写一个组合壳。这样避免 DeepSeek 一次性返回过大的文件包，同时不走 brief。
  • 服务端只接受 src/App.tsx、src/index.css、src/data.ts 和 src/components/*.tsx。
  • index.html、src/main.tsx、Vite/Tailwind/PostCSS 配置和 package.json 由服务端固定生成。
  • 依赖来自固定白名单，不允许模型声明动态安装。
  • 服务端在临时目录运行 vite build。
  • 构建后的 CSS 和 JavaScript 会内联回 htmlCode，所以现有 Preview iframe、保存后的作品页和社区发布页仍然兼容。
  • 源码文件、构建日志和服务端 QA 元数据会一起保存到 workflow version 和 generated page；前端 runtime QA 摘要会通过 workflow canvas PATCH 写回 QA 报告。
  • 构建失败或 QA 失败最多触发一次模型修复；如果仍失败，就返回真实错误，不再生成假的本地占位页面。

这让完整实现类 prompt 更接近真实前端工程师的工作方式，同时保留当前“先草稿、后保存”的产品模型。

三种创作模式

网站模式

网站模式是当前已实现的主流程。选择网站后，右侧工作区会显示网页生成节点框架和半透明连线。Agent 会按 PM Hub / Overview、Skills、Design System、网站架构、Full Prompt、Prompt QA、Preview 内代码 tab、Preview tab 的顺序推进，并在推进时激活连线动画。

如果需求缺信息，Agent 不会直接丢一个开放式问题，而是把缺失项写入 PM Hub 或对应节点，并给出合理选项和自定义回答入口。

PPT 模式

PPT 模式是未来工作流入口，当前只展示为 disabled/coming soon。后续会有独立的页面结构、内容大纲、视觉系统、Slide 生成和预览节点。

移动应用模式

移动应用模式也是未来工作流入口，当前只展示为 disabled/coming soon。后续会有 App 信息架构、屏幕流程、组件系统、交互状态和移动端预览节点。

修改模式

当已有生成结果后，输入框会变成“修改要求”入口。

流程是：

  1. 用户输入修改要求。
  2. Agent 读取当前 workflow version。
  3. 按 Design System、Full Prompt、Preview 内代码 tab、Preview tab 的顺序创建新版本。
  4. 新版本仍然只是草稿。
  5. 用户再次点击 Save work，才会更新原作品或发布新作品。

一次完整生成到底发生了什么

Rendering diagram...

这条链路里最重要的设计是“先保存 workflow 草稿，再由用户决定是否发布”。这样用户可以预览和修改，不会因为一次生成就污染“我的项目”列表。

为什么要拆成角色规划和代码生成

早期做法通常会让模型一次返回一个巨大 JSON，里面既有结构化字段，也塞着完整 HTML。这样很容易出问题：

  • HTML 太长，JSON 被截断。
  • 模型输出 markdown fence，JSON 解析失败。
  • 一点引号或换行错误就导致整次生成失败。
  • 长 HTML 会挤占结构化设计说明的 token 空间。

当前普通 brief 实现把生成拆成几段：

  1. PM Planner：生成标题、overview、意图判断、决策摘要和缺失信息。
  2. Designer Planner：生成 Design System、设计面板和 token。
  3. Content Planner：生成网站架构、内容输入、标题、CTA、SEO/alt 文案和模块说明。
  4. Skill Manager Planner：只从真实 Skill 库中选择和解释最多 8 个 Skill。
  5. QA Reviewer：检查组装后的 Full Prompt 是否允许进入代码生成。
  6. HTML / React-Vite 代码生成：通过 QA 后再生成预览代码。

这就是 src/lib/generation/workflow.ts 里 runWorkflowPlan 的核心价值。它把“结构化思考”“角色分工”和“代码输出”拆开，同时用模板污染检测防止内部 prompt 说明被当成页面内容。

前端怎么听懂服务端

前端组件是 src/components/project-workflow.tsx。

它维护几类状态：

  • messages：对话记录。
  • assets：用户上传或粘贴的素材。
  • selectedSkillSlugs：用户选择的 Skills。
  • artifacts：Agent 生成出来的标题、Style、Full Prompt、HTML、版本号和保存状态。
  • nodeStatus：各个 workflow 节点当前是 idle、streaming、asking、awaiting-confirmation、modifying、complete 还是 error。
  • agentReports：各 Agent 工作区里的最新工作中、完成、阻断或评审汇报。
  • activeEdges / completedEdges：节点之间的连线动画。

服务端返回的是 SSE 文本流。前端用 readWorkflowStream 一段段读取，找到 data: 行，再交给 handleWorkflowEvent 处理。

主要事件包括：

  • run:start：一次运行开始，记录 runId。
  • node:start：某个节点开始工作。
  • edge:activate：某条连线亮起来。
  • artifact:complete：某个节点的结果完成，例如 fullPrompt 或 htmlCode。
  • question：Agent 需要追问。
  • awaiting_style_confirmation：历史兼容事件；未来应迁移为规划确认。
  • run:error：生成失败。
  • run:complete：本轮结束。

连线动画怎么来的

右侧画布由 @xyflow/react 渲染。初始网站节点框架带有半透明默认连线；前端收到 edge:activate 后把对应 React Flow edge 切换为动画状态，节点完成后连线变为白色。节点可以拖拽和缩放，连线跟随节点位置自动重绘，普通用户路径不提供右键建节点或手动连线。

素材是怎么进入 Agent 的

素材入口在 /api/generate/assets。

当前支持：

  • 链接：抓取公开网页文本，过滤 HTML、script、style。
  • 代码：保存用户粘贴的代码文本。
  • 文本类文件：提取内容，例如 txt、md、json、html、css、js、ts。
  • 图片：上传到私有 Storage，并生成摘要说明。
  • PDF / Word 等文件：可以保存，但当前没有专用解析器，只保留文件和摘要。

安全处理包括：

  • 必须登录且具备 Pro/admin 权限。
  • 链接只允许 http/https。
  • 禁止抓取 localhost、127.0.0.1、10.x、192.168.x、172.16-31.x、169.254.x 等本地或内网地址。
  • 文件上传到私有 workflow-assets bucket。
  • Storage 路径以用户 id 开头，RLS 只允许 owner 访问。

当前限制也要说清楚：图片已经能作为素材保存，但模型接口没有显式声明 vision 能力，所以图片不会真正被视觉模型读取。用户最好在 prompt 里补充图片重点。

数据库里保存了什么

Rendering diagram...

用零基础的话说：

  • workflow_runs 是一次 Agent 会话。
  • workflow_run_versions 是这次会话里的每个草稿版本。
  • workflow_run_assets 是这次会话用过的素材。
  • generated_pages 是用户点击保存后，真正进入“我的项目”的作品。
  • generated_page_skills 是作品和 Skills 的关系表。
  • templates 是公开社区模板；从“我的项目”发布到社区时，会创建或更新 community-<generatedPageId> 模板。

为什么有 Draft 和 Saved 两层

这是当前 Agent 最重要的产品设计。

Draft 指 workflow 草稿：

  • 生成后马上存在。
  • 可以继续修改。
  • 不进入“我的项目”。
  • 存在 workflow_run_versions。

Saved 指正式作品：

  • 用户点击 Save work 后才存在。
  • 会出现在“我的项目”。
  • 可以打开作品分析页。
  • 可以从“我的项目”删除，或发布到社区。
  • 存在 generated_pages。

这样做的好处是：用户可以先试错，不会每次生成都把项目列表弄乱。

保存时发生什么

保存入口是 /api/generate/workflow/save。

保存时服务端会：

  1. 检查用户是否登录。
  2. 检查是否 Pro/admin。
  3. 根据 versionId 找到当前 workflow version。
  4. 确认这个 version 属于当前用户。
  5. 确认里面有 html_code。
  6. 如果是首次保存，就 insert 到 generated_pages。
  7. 如果是更新已有作品，就 update 对应 generated_pages。
  8. 同步 generated_page_skills。
  9. 把 workflow_run_versions.generated_page_id 回写为正式作品 id。
  10. 返回生成作品 id、标题、HTML、Prompt 等内容给前端。

当一个 workflow 已经关联了作品时，前端会让用户选择：

  • Update same work：更新同一个作品。
  • Publish new work：发布成一个新作品。

在“我的项目”列表中，用户还可以对每个 saved work 执行：

  • Publish to community：复制 HTML、Prompt、Design.md、Skills 和推断标签到公开 templates。
  • Delete：删除自己的 generated_pages 作品。

从作品回到 Agent

作品分析页如果发现 workflowVersionId 存在，会显示“编辑/更新”入口。

点击后进入：

/[locale]/create/new?work=<generatedPageId>

服务端页面会调用 getWorkflowDraftForGeneratedPage，从 generated_pages 找到关联的 workflow version，再恢复：

  • messages
  • selected skills
  • model
  • assets
  • full prompt
  • html
  • design.md
  • design-system sections

这就是为什么作品可以继续被 Agent 修改，而不是只能静态预览。

代码地图

如果要从代码理解 Agent，可以按这个顺序读：

  1. src/app/[locale]/create/new/page.tsx

页面入口。读取用户、Skills、模型配置，以及可恢复的 workflow draft。

  1. src/components/project-workflow.tsx

前端主组件。负责对话、素材、Skill 选择、节点状态、SSE 读取、保存按钮和 Preview。

  1. src/components/project-workflow.tsx

React Flow 无限画布、网站节点卡片、统一输入框、SSE 状态、保存按钮和 Preview。

  1. src/app/api/generate/assets/route.ts

素材 API。处理链接、代码、文件、图片和安全限制。

  1. src/app/api/generate/workflow/stream/route.ts

Agent 主入口。做权限检查、创建 run、调用 intent、调用 generate、写 version、推送 SSE 事件。

  1. src/lib/generation/workflow.ts

Agent 编排核心。包含 Intent 判断、Workflow Orchestrator Skill、Brief JSON 生成、HTML 生成、fallback 和解析逻辑。

  1. src/lib/generation/llm.ts

模型适配层。处理 DeepSeek、PackyAPI、OpenAI-compatible 模型、超时、空响应、JSON 解析和健康检查。

  1. src/app/api/generate/workflow/save/route.ts

显式保存。把 workflow version 发布到 generated_pages。

  1. src/app/[locale]/account/actions.ts

“我的项目”操作。删除 saved work，或把 saved work 发布成社区模板。

  1. src/lib/data.ts

读取已保存项目、恢复 workflow draft、把 generated page 转成分析页可用数据。

  1. supabase/migrations/202605140001_workflow_agent_assets.sql 和 20260514104547_workflow_explicit_save.sql

数据库表、RLS、Storage bucket、workflow 与 generated page 的连接。

项目 review：当前做得好的地方

  • 架构层次清楚：前端 UI、SSE 编排、生成逻辑、素材处理、保存逻辑分层明确。
  • 用户体验安全：生成先进入 workflow 草稿，不会自动污染正式作品列表。
  • 社区复用链路已经打通：saved work 可以从“我的项目”直接发布为公开模板。
  • 可追溯性强：input_snapshot 保留 messages、skills、model、assets，方便从作品恢复 workflow。
  • 生成稳定性更好：Brief JSON 与 HTML 文本分离，降低大 JSON 截断和解析失败概率。
  • 权限边界明确：生成、素材上传、保存都要求 Pro/admin。
  • 私有数据保护到位：workflow 表和 storage bucket 都按 owner-only RLS 保护。
  • 素材抓取有安全防线：禁止本地和内网链接，降低 SSRF 风险。
  • 可视化状态好理解：节点状态和连线让用户知道 Agent 不是黑箱。

项目 review：需要注意的风险

  • 当前规划节点已经可视化，但仍需要把“规划确认”做成真正的生成闸门：先只生成规划，用户编辑或回答缺失信息后，再编译 Full Prompt 并生成代码。
  • 前端和服务端都各自定义了一套 Workflow 类型。短期可读，长期容易漂移。可以考虑把共享事件和 artifact 类型抽到同一个文件。
  • 保存流程不是完整数据库事务。generated_pages、generated_page_skills、workflow_run_versions 多步写入中如果中途失败，可能产生部分同步状态。未来可以迁移成数据库函数或更严格的补偿逻辑。
  • 没有额度账本。现在 Pro/admin 可以调用 Agent，但没有 prompt quota、token 记录或生成次数控制。
  • 素材解析还不完整。PDF、Word 和图片都能保存，但没有深度解析或 vision 读取。
  • 没有系统化 E2E 测试。登录、权限、SSE、保存、恢复 workflow 都适合加 Playwright 测试。
  • 错误提示还可以更产品化。模型空响应、JSON 失败、超时、素材解析失败等错误已经被捕获，但面向零基础用户还可以更友好。
  • 多语言细节还有少量不一致。例如保存成功后追加的 assistant message 目前是英文。

后续开发计划

后续开发目标不是把 Agent 做得更“会聊天”，而是让它更像一个可靠的设计生产系统：能理解素材、能分阶段决策、能观察自己的结果、能自动修复明显问题，并且能被计费、测试、追踪和回滚。

第一阶段：把现有链路做稳

这一阶段优先解决工程稳定性，目标是让当前 Agent 在真实用户使用时更不容易出现半成功状态。

  1. 统一 Workflow 类型

把前端和服务端重复定义的事件、节点、artifact 类型抽到共享文件，例如 src/lib/workflow/types.ts。这样 SSE 事件新增字段时，前后端会一起得到类型提醒。

  1. 保存流程事务化

把 generated_pages、generated_page_skills、workflow_run_versions 的多步写入收敛到 Supabase RPC 或数据库函数里。目标是保存要么全部成功，要么全部失败，不留下半保存作品。

  1. 补齐多语言体验

将保存成功、错误提示、等待确认、素材解析失败等 assistant message 接入 locale 文案。这样中文站不会突然出现英文系统消息。

  1. 增加基础 E2E 测试

用 Playwright 覆盖登录权限、生成 SSE、规划确认、保存作品、从作品回到 Agent 修改这几条主路径。测试不要求覆盖所有 UI 细节，但要保护核心链路不被改坏。

第二阶段：把“规划确认”做成真正的分阶段 Agent

当前网站模式已经有 Overview、Design System、网站架构、内容输入和约束节点，但生成链路仍应继续向真正分阶段演进：

  1. 第一段只生成规划节点，不生成最终代码。
  2. 用户可以编辑网站架构和内容输入，也可以回答缺失信息。
  3. 确认后，服务端再用最终规划节点编译 Full Prompt 并生成代码。
  4. 每一次规划修改都保存成 workflow version，方便回看为什么最终结果变成这样。

这样做以后，Agent 才真正拥有“先对齐规划，再开始生产”的能力。对零基础用户来说，也更容易理解：先定蓝图，再开始施工。

第三阶段：加入结果观察和自我修复

这是它和成熟 Agent 差距最大的地方。当前 Agent 已经能做服务端静态 QA 和前端 iframe runtime 摘要，但还没有完整的截图、视觉模型评审和自动修复闭环。

建议新增一个 QA 节点，放在 Preview 之后：

Rendering diagram...

QA 节点可以继续补齐三类检查：

  • 浏览器控制台是否有错误，并把错误持久化到 workflow version。
  • iframe 是否真的渲染出内容，而不是空白页，并覆盖 desktop/mobile 两种 viewport。
  • 主要文字、按钮、卡片是否明显溢出、重叠或在截图层面视觉失败。

更进一步，可以把截图交给支持视觉理解的模型，让 Agent 判断页面是否符合 brief 和 style。这样 Agent 不只是“写代码”，而是开始拥有“看结果、改结果”的闭环。

第四阶段：增强素材理解能力

当前素材系统已经能保存链接、代码、文本文件、图片、PDF 和 Word，但图片和复杂文档还没有被真正深度理解。后续可以按价值从高到低推进：

  1. PDF / Word 文本解析

提取文档标题、章节、表格、清单和关键段落，让它们进入生成上下文。

  1. 图片 vision 读取

对上传图片生成视觉描述，包括主体、布局、颜色、字体倾向、组件形态和可复用设计线索。

  1. 素材引用追踪

在生成结果里记录哪些设计判断来自哪个素材。这样用户能知道 Agent 为什么这么设计。

  1. 素材摘要缓存

同一个素材重复使用时，直接复用已经解析过的摘要，减少模型成本和等待时间。

第五阶段：版本、回滚和对比

现在 workflow 已经有 version，但用户主要看到的是当前版本。后续可以把版本能力产品化：

  • 展示版本历史：每次生成、风格修改、代码修复、保存都能回看。
  • 支持版本对比：比较两个版本的 prompt、style 和 HTML 差异。
  • 支持回滚：用户可以把某个旧版本恢复为当前草稿。
  • 支持命名版本：例如“客户 A 方向”“深色版”“移动端优化版”。

这会让 Agent 从一次性生成工具变成可迭代的设计工作流。

第六阶段：额度、成本和运行记录

当 Agent 面向更多用户时，需要把模型调用变成可管理资源：

  • 建立 usage ledger，记录 runId、versionId、userId、model、tokens、成本、耗时和状态。
  • 增加用户额度和套餐限制，例如每日生成次数、素材解析次数、vision 次数。
  • 给管理员提供失败率、平均耗时、模型成本、保存转化率等看板。
  • 对高成本操作做明确提示，例如 vision 解析、多轮自动修复、大文件解析。

这部分不是炫技，但决定 Agent 能不能长期运营。

第七阶段：Prompt、Skill 和评测体系

当前 Agent 已经可以引用 Skills。后续可以让 Skills 更像可治理的知识资产：

  • 给每个 Skill 增加版本号，记录某次生成使用的是哪个版本。
  • 增加 Skill 适用场景和冲突提示，减少用户乱选。
  • 建立一组标准评测 brief，例如 SaaS dashboard、portfolio、mobile app、landing page。
  • 每次修改编排逻辑或 prompt 后，跑一批固定评测，比较可用性、视觉质量、错误率和保存成功率。

这样可以避免 Agent 靠感觉变好，而是能用样例和数据证明变好。

推荐优先级

如果资源有限，建议按这个顺序推进：

  1. 真正的规划确认闸门。
  2. 生成后 QA / 自我修复循环。
  3. 保存事务化和共享 Workflow 类型。
  4. Playwright E2E 测试。
  5. 素材 vision 和 PDF / Word 深度解析。
  6. 版本对比、回滚和命名版本。
  7. 额度账本、成本看板和评测集。

最关键的一步是 QA / 自我修复。因为常规成熟 Agent 和当前 Agent 的最大差距，不是会不会生成，而是能不能观察自己的输出，并在用户看到之前修掉明显问题。

给零基础听众的讲解顺序

如果要把这个 Agent 分享给完全没有基础的人，可以按这个顺序讲：

  1. 先看结果：展示 /create/new 页面，说明它不是聊天框，而是一个工作台。
  2. 再看节点：Input、Style、Full Prompt、Preview 以及 Preview 内的代码 tab 分别是什么意思。
  3. 解释草稿：生成结果先是 Draft，不会立刻进入“我的项目”。
  4. 解释保存：只有 Save work 后，才变成正式作品。
  5. 解释修改：已保存作品可以回到 Agent 继续修改。
  6. 解释背后：前端负责显示，服务端负责编排，模型负责生成，Supabase 负责保存。
  7. 最后讲风险：图片还不是 vision 分析，保存还不是事务，未来需要额度和测试。

一句话总结

Interface Lab Agent 的本质不是“一个 prompt”，而是一套可视化、可追踪、可恢复、可保存的 UI 生成系统。它把用户输入、资源库 Skills、素材上下文、模型生成、版本草稿和正式作品连接起来，让一次 AI 生成变成可以复盘和继续迭代的设计资产。