尧图网站建设 
人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载导读本文基于 IronClaw 仓库 docs/internal/design/oobe.md 设计简报展开系统讲解 WebChat v2 面向新用户「前五分钟」的首次体验Out-of-Box Experience, OOBE设计用户在完成账号/工作区开通后第一次进入 Web 聊天界面的那一刻产品如何通过「建议任务卡片」完成冷启动、如何呈现第一条自动化建议、以及如何在返回用户场景中复用同一套抽屉控件。读完本文你将掌握该设计的双轨演进历史Foundational → Vision、建议任务卡片的视觉语言与状态模型、可复用任务抽屉的交互形态以及它与仓库中已落地的持久化后端建议契约suggestions.list / generate / start / dismiss之间的真实对接关系。一、要解决的核心问题冷启动与第一条自动化WebChat v2 的落地视图landing view今天是「大标题 输入框 三个静态建议 chip」对应组件为 empty-state.tsx。仓库中已经原型化的自动化表面——「Done for you」轮播carousel、行内日历改期卡片、Plan 卡片、agent 模式药丸pill——全都假设自动化已经存在。而一个全新账号没有任何自动化因此两个关键时刻是空白的冷启动cold start什么都没有用户不知道 IronClaw 能为他做什么第一条自动化出现first automation appearing第一个「替你完成」的时刻如何呈现。设计简报给出的目标是设计新用户的前五分钟——账号/工作区开通后落在 Web 聊天界面的瞬间。非目标non-goals同样明确不重设计稳态聊天、不重设计自动化管理页、不重设计扩展目录只在其上增加一层首次运行体验并复用已有能力。二、双轨设计Foundational 与 VisionVersion 开关设计载体是自包含的交互原型 mockup.html内置Version开关Foundational / Vision与Scene开关First run / Thread / Plan可在浏览器中直接打开播放。两套设计共享同一套卡片语言并在自动化存在后收敛到同一个「已填充的轮播」。2.1 Foundational —— 近期的、贴合当前 main 的实现面向多租户企业部署只做今天 v2 系统上轻量可行的事工具由管理员白名单、用户自行授权不设独立的连接面板每张建议卡片携带「Connect Tool」CTA授权通过模态 OAuth「浏览器」对话框完成登录 → 批准 scopes。连接成功后卡片变为可操作的建议。建议卡片在第一步即出现agent 立即给出第一批建议无需先「挣得」一个空冷启动每张卡片从connect状态开始工具授权后变为 approve/modify/dismiss。卡片以提案语气呈现Triage your inbox运行后翻转成结果语气Triaged your inbox。无用户名除非能从确定性来源管理员预配置、email、Slack 资料推导出来默认是匿名称呼Welcome to IronClaw. 普通账号 chip。agent 模式收敛为三种默认SuggestSuggest——执行任务或自动化前始终请求批准Plan——先描述活动与所需步骤等待批准Auto Approve——自动批准用户已批准过的任务类型以及用户显式请求的任何任务。使用main 的 composer和朴素pills-collapse 抽屉用户开始输入时任务卡片折叠为 composer 上方的一行药丸无边框/无吸附抽屉。2.2 Vision —— 北极星目标在 Foundational 之上叠加理想化的首次运行体验冷启动连接流一个「连接你的工具」面板用户选择工具后排队式模态 OAuth「浏览器」对话框逐个走完一次登录、每个工具批准 scopes直到全部授权随后是期待节拍 → 第一张卡片揭晓。支持具名问候语与四模式集合Suggest / Plan / Auto /Bypass。首条自动化揭晓情感峰值——一段短暂的期待节拍品牌化NEAR 进度指示器 骨架瓦片随后第一张「Done for you」卡片以 Gemini 风格ai-spark边框扫光凭空浮现。在prefers-reduced-motion下被抑制。吸附式任务抽屉建议卡片放入一个吸附在 composer 上、向上延伸的带边框抽屉框内品牌化进度指示器 agent 活动字符串位于抽屉上方抽屉头部携带副标题左上折叠/展开卡片 ↔ 药丸关闭✕关闭后出现「Show suggestions」恢复条。输入时仍折叠为药丸。设计原则Vision 的每一件都是 Foundational 对应物的超集逐卡连接 → 批量连接静态首卡 → 动画揭晓朴素抽屉 → 吸附框3 模式 → 4 模式Foundational 永不丢弃Vision 只是扩展它。三、任务抽屉可复用控件而非一次性 OOBE 装置设计简报明确强调抽屉不只是 OOBE 设备它是返回用户或打开新线程时「建议任务」的可复用表面折叠态紧凑的可滚动药丸行品牌 logo 标题吸附在 composer 上展开态Vision完整卡片框。这为返回用户提供了一个持久的、可关闭的「这是我接下来可以接手的事」提示affordance而不会霸占线程。抽屉的状态机open / collapsed / dismissed在 PLAN.md 中被明确复用Vision 的吸附抽屉「复用 Foundational 抽屉状态机」。四、卡片设计语言两个版本共享真实品牌产品 logoGmail、Google Calendar、Docs、Drive、Slack 全彩GitHub Notion 通过currentColor单色以跟随主题而非占位字形。标题优先的头部图标 任务标题无状态标签状态从操作行读取。弱化的「From app · time」来源行实心主按钮 次级文字按钮Approve / Modify / Dismiss所有模式下链接按钮均带图标。更大圆角、柔和阴影、紧凑高度操作行底部对齐。这份卡片语言在仓库中的实现位置与原型记录可对照 mockup.html 与 integration-review.html后者为自包含的视觉评审页面含 5 层集成示意图、依赖图与阶段时间线。五、代码落点这套设计住在哪里设计简报给出了精确的仓库落点SPA 技术栈为React 19 TypeScript Tailwind v4设计令牌在styles/app.css落地视图empty-state.tsx在main上自动化表面组件族automation-carousel.tsx、automation-task-card.tsx、task-action-bar.tsx、mode-selector.tsxmock 数据接缝lib/automation-tasks*.tshooks/useAutomationTasks.ts以及 DEV 环境pages/design-preview/design-preview-page.tsx——这些在 PR #6994 中原型化后被回滚不在main上其形态记录在 mockup 与接线契约中后端契约文件AUTOMATION-TASKS-CONTRACT.md提案版接线AutomationTask领域模型、5 个持久事件、投影、HTTP 路由与 facade 方法治理文档VISION-RECONCILIATION.mdgoverns——当与 PROPOSAL/PLAN/IMPLEMENTATION 冲突时以此为准配套 README.md概述、PROPOSAL.md完整规格、PLAN.md执行顺序、CHECKLIST.md完成定义。设计简报同时指出了当前的真实状态今天轮播在无任务时return null全新账号看到的是未变化的 hero composer——即冷启动状态目前未被设计这正是该 mockup 要填补的部分。六、已经落地的 vs. 需要后端的设计简报把工作分成两类边界清晰已原型化后回滚PR #6994纯展示、mock 数据轮播 任务卡 操作栏、日历改期卡、Plan 卡、agent 模式药丸以及端点形态的数据接缝。而品牌化的NearProcessIndicator#6901与AuthRequired连接器路径已在main上。需要后端issue #6993「还没有自动化」/「正在做第一条」的投影状态揭晓由AutomationTaskAutomated投影事件驱动期待/骨架状态返回用户的抽屉建议 feed三模式 vs 四模式的 agent 模式门控——这些是 AUTOMATION-TASKS-CONTRACT.md §2–§7 接线之上的新 UI。6.1 提案契约历史记录AutomationTask 领域模型契约文档§§1–3 已被 PR #7694 取代仅作设计意图记录曾规划如下 Rust 模型镜像 TS 的AutomationTask标识符用ironclaw_common的 newtypepub struct AutomationTaskId(String); // newtype校验 pub enum AutomationApp { // #[serde(rename_all snake_case)] Gmail, GoogleCalendar, GoogleDocs, Slack, Notion, } pub enum AutomationTaskKind { // snake_case EmailTriage, CalendarAccept, CalendarReschedule, DocInsights, } pub enum AutomationTaskState { // snake_case Suggested, InProgress, Automated, Reverted, Cancelled, }以及 5 个持久事件AutomationTaskProposed/Modified/Automated/Reverted/Cancelled每个都脱敏、可重放、经持久化 sink 追加配(tenant, user)作用域过滤的AutomationTaskProjection带重放游标并强制跨用户隔离回归测试。七、治理变更Vision 直接对接已落地的持久化后端建议契约关键转折PR #7694 直接落地了「持久化后端建议」契约feat: add durable backend suggestions它是后端纯实现明确「前端文件不变、前端消费不在其范围」。这恰好补上了 PR #6994 占据的接缝——#7694 是生产者#6994 变为消费者。于是程序从「先 Foundational 后 Vision」转向直接构建 VisionFoundationalPhase 1UX 被裁掉VISION-RECONCILIATION.md 成为治理文档。7.1 冻结在 ironclaw_product_contracts 中的契约方法WebUI 路由产品操作GET/api/webchat/v2/suggestionssuggestions.listPOST/api/webchat/v2/suggestions/generatesuggestions.generatePOST/api/webchat/v2/suggestions/{id}/startsuggestion.startDELETE/api/webchat/v2/suggestions/{id}suggestion.dismiss响应形态RebornSuggestionsResponse { status: empty | generating | ready | failed, generation_id?: string, retry_after_seconds?: number, suggestions: RebornSuggestion[], } RebornSuggestion { id, title, description, suggested_prompt, thread_id?, run_id? } RebornSuggestionStartResponse { suggestion_id, thread_id, run_id } RebornSuggestionDismissResponse { suggestion_id, dismissed }这些类型在仓库中有源码级印证suggestions.rs 声明了SUGGESTIONS_LIST_VIEWsuggestions.list无分页 ProductView、SUGGESTIONS_GENERATE_COMMANDsuggestions.generate、SUGGESTION_START_COMMANDsuggestion.start与SUGGESTION_DISMISS_COMMANDsuggestion.dismiss四个命令描述符并配有序列化测试generate请求必须携带client_action_idlist请求为空输入响应含status/generation_id/retry_after_seconds/suggestions字段。对应的 DTO 与响应类型位于 product_wire.rs路由处理器与描述符行在 handlers.rs 与 descriptors.rs并有 webui_v2_descriptors_contract.rs 等契约测试守护。异步生成语义POST generate携带client_action_id返回202与status: generating及retry_after_seconds提示客户端轮询GET suggestions。每个(tenant_id, user_id)存在一套卡片新一轮生成清除上一套。卡片数量限制在1–5条schemas/suggestions.output.v1.jsontitle≤ 80、description≤ 240、suggested_prompt≤ 2000 字符。路由与前端建议表面始终开启且表面保持懒加载使其卡片/图标代码不进入 eager/chatbundle。7.2 Vision 因此获得了什么POR 元素之前有了 #7694持久卡片存储、路由、生产者全新未建已落地期待 /「正在做第一条」状态「新投影状态#6993」真实empty/generatingretry_after_seconds首卡揭晓ai-spark conjure需要AutomationTaskAutomated事件可用触发generating → ready转换Approve → 运行经handleSend提示注入被取代suggestion.start返回{thread_id, run_id}卡片实时状态已退役——无持久绑定复活卡片携带持久thread_id/run_idDismiss本地组件状态持久DELETE吸附抽屉 · 具名问候前端 / 开放决策不受影响其中影响最大的是「卡片实时状态」卡片级持久状态曾因「需要持久化的逐任务记录」而被退役而 #7694 正是那条记录——返回用户卡片能显示真实状态因为 suggestion→thread/run 的绑定是持久化的、重启后依然存活。7.3 连接模型的裁决connect 不再是一个卡片状态生成的卡片原不携带工具身份与连接状态{ id, title, description, suggested_prompt, thread_id?, run_id? }这是刻意为之prompts/suggestion_generation.md 指示生成器「没有证据表明账号/扩展/凭证/能力可用时不得声称其可用」且偏好「assistant 在普通对话中能完成的工作」。模型能看到扩展扩展搜索在能力白名单内但输出 schema 无处声明它。最终裁决§3.1connect 不再是卡片状态。Vision 冷启动连接面板作为独立的落地表面保留由扩展目录useExtensions驱动而非由建议卡片驱动。connect 与 suggestions 成为两个并列表面Landing ├── Connect panel ← extensions catalog (useExtensions)批量 OAuth walk └── Suggestion drawer ← GET /suggestions工具无关的卡片后果卡片永不因连接而阻塞——卡片一经存在即可 start即时just-in-time授权仍然有效——若一次 start 的运行需要未连接的工具agent 发出既有的AuthRequired门框线程渲染AuthOauthCard已落地的既有路径不变待 QA 验证假设AuthRequired会为 suggestion-started 运行触发因为是同一 agent loop应会触发但尚未测试。面板失去逐卡「为什么这个工具重要」的框架——被接受的权衡resolveConnectExtension被废弃删除其职责是卡片appid → 目录扩展目录驱动面板直接读目录。但它验证的复用模式——懒加载真实ConfigureModal而非克隆useOauthSetup约 250 行的弹窗/轮询状态机——被继承到 V1 面板也正是该面板构建便宜的原因。落地后的icon/sources细节见 SUGGESTION-ICONS.mdicon是必填的、provider 中立的语义任务枚举email/calendar/document/storage/spreadsheet/presentation/code/messaging/notes/web/memory/genericgeneric为兜底只控制卡片字形不是扩展身份sources是 1–5 条人类可读来源标签纯展示、前端绝不从中推导图标或 setup 路由。八、契约带来的两个已决决策卡片并行运行——单一活动锁被移除。原设计将「同时只有一个活动任务」建立在submit_turn返回DeferredBusy/RejectedBusy线程上已有运行在跑之上但suggestion.start为每条建议创建独立线程后端并无约束需要镜像——批准一张卡不再禁用其他卡这正是 Vision 多卡抽屉想要的。「 Automation」被移除。卡片 schema 没有automation_prompt字段#7694 也未新增自动化路由没有可构建的依据与其保留一个无持久背书的客户端合成提示注入不如整条从卡片移除。若日后循环自动化成为首运行目标需要自己的后端契约。九、重构映射与切片计划PR #6994治理文档给出 keep/change/delete 重构映射KeepChangeDeleteSuggestedTaskCard展示层DEMO_TASKS→GET /suggestions generate/pollresolveConnectExtension 测试SuggestedTaskSurface外壳Approve →POST /{id}/start→onSelectThread(thread_id)unconnected卡片状态常开建议表面路由无 flagDismiss →DELETE /{id}卡片上的ConfigureModal接线懒加载 bundle 纪律SuggestedTask类型 →RebornSuggestion形态chat.oobe.connectUnavailable11 个 localeNearProcessIndicatorrender-prop卡片状态派生自绑定的run_idconnectedIds状态切片计划slices 1–6、9、10 已构建✅ 建议 API 客户端 类型四个类型化调用遵循lib/api.ts约定apiFetch、clientActionId()DTO 镜像RebornSuggestion✅ 表面消费真实数据mount 时listempty→ generate CTAgenerating→ 按retry_after_seconds轮询ready→ 渲染卡片failed→ 重试✅ start dismissApprove 调start并导航到返回的thread_iddismiss 调DELETE✅ 移除连接模型unconnected状态、解析器、i18n key✅ V3 期待状态empty CTA / generating 骨架 / failed 重试generating 态在静态.v2-skeleton瓦片上渲染品牌化 NEAR 指示器✅ V2 揭晓克制的卡片入场.oobe-card-reveal复用已批准的v2-page-in关键帧prefers-reduced-motion抑制注意这是治理干净的版本不是mockup 中即兴的 conic-gradient ai-spark 边框扫光——那会绕过app.css的静态运动策略⏳ 卡片实时状态订阅绑定run_id反映运行中/完成/失败未构建⏳ V1 连接面板目录驱动的冷启动「Connect your tools」表面复用ConfigureModal模式未构建✅ V4 吸附抽屉框表面以带边框抽屉渲染头部「Suggested for you · approve to run, or tweak first」吸附在 composer 附近未做真正的边框融合保留圆角框 紧凑间隙以不触碰已落地的ChatInput✅ 刷新 连接入口issue #7815F1/F2——抽屉头部带刷新控件重跑generate进行中禁用与/extensions入口空/失败 CTA 行将 generate/retry 与同一连接入口配对。剩余的 Vision 后续未构建供设计评审跟踪卡片实时状态slice 7、V1 连接面板slice 8、agent 模式选择器Suggest / Plan / Auto / Bypassnet-new需持久住所 类型化门控接线、输入折叠为药丸、具名问候 顶栏客户端用户名调用V5推迟需要确定性用户名来源、ai-spark 揭晓若采用不绕过运动策略的动画方案。十、安全与隔离约束租户/用户作用域投影按(tenant, user)过滤跨用户隔离回归测试强制仅经中介的效果Approve/Modify(rerun)/Revert 是真实第三方效果必须经能力宿主 产品适配器成功仅由 provider 证据 回读确认绝无乐观回显脱敏每个事件 payload 默认敏感在 log / 持久追加 / 投影 / 传输 / 模型可见结果之前承担脱敏义务自主性升级autoFoundational与bypassVision对整类任务抑制批准门均需显式门控抑制测试 每次自动运行动作的审计痕迹auto把global_auto_approve从单一布尔推广为按类型的同意无新认证路径connect 复用共享扩展授权解析器凭证身份与扩展身份保持分离。十一、开放问题截至文档状态分期Foundational 先对当前 main 落地Vision 中哪件先毕业——吸附抽屉、连接流还是揭晓动画用户名推导Foundational多个确定性来源同时存在时哪个优先管理员预配置 vs email vs Slack 资料全部失败时的兜底是什么Auto Approve 范围「用户已批准的任务类型」如何定义与界定按工具、按动作、消费/影响上限企业工具配置管理员预配置的工具集如何呈现给用户——只读「由你的工作区连接」提示还是不可见Vision 冷启动是否播种一条真实的低风险自动化以保证首卡出现还是等待有机活动替换 UX新一轮生成清除上一套用户在阅读中遇到替换落地时抽屉该做什么逐卡连接未来若加逐卡连接动作必须由后端给出类型化扩展身份或经扩展目录解析绝不能从icon或人类可读的sources字符串推断身份。延伸阅读仓库内设计包主页docs/internal/design/oobe/README.md执行概述与评审入口治理文档docs/internal/design/oobe/VISION-RECONCILIATION.md与已落地后端契约的全面对账完整规格docs/internal/design/oobe/PROPOSAL.mdshipped vs net-new 范围、依赖清单、安全模型、测试策略执行计划docs/internal/design/oobe/PLAN.md阶段、门、PR 尺寸完成定义docs/internal/design/oobe/CHECKLIST.md后端契约源码crates/contracts/ironclaw_product_contracts/src/suggestions.rs、crates/contracts/ironclaw_product_contracts/src/product_wire.rs路由与描述符crates/product/ironclaw_webui/src/webui_v2/handlers.rs、crates/product/ironclaw_webui/src/webui_v2/descriptors.rs前端表面crates/product/ironclaw_webui/frontend/src/pages/chat/components/suggested-task-surface.tsx、crates/product/ironclaw_webui/frontend/src/pages/chat/lib/suggestions-api.ts赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw OOBE 首次运行引导从空白落地页到 Agent 驱动的建议卡片全链路解析IronClaw OOBE 首次运行引导从空白落地页到 Agent 驱动的建议卡片全链路解析 IronClaw 的 OOBEOut of Box Exper人工智能AI 应用交互助手AI AgentIronClaw OOBE 首启引导设计解析两阶段提案、已发货建议契约与 WebChat v2 冷启动方案IronClaw OOBE 首启引导设计解析两阶段提案、已发货建议契约与 WebChat v2 冷启动方案 IronClaw 的 OOBEOut of Bo人工智能AI 应用交互助手AI AgentIronClaw OOBE 首次运行体验实现指南建议卡片从前端组件到持久化后端契约的完整落地IronClaw OOBE 首次运行体验实现指南建议卡片从前端组件到持久化后端契约的完整落地 本文以 IMPLEMENTATION.md https://li人工智能AI 应用交互助手AI Agent上一篇5分钟搭建开源数字标牌系统LibreSignage完全指南下一篇如何快速掌握缠论分析ChanlunX 通达信插件完整实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 IronClaw 新用户首次体验（OOBE）设计解析：从冷启动到第一条建议卡片
人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载导读本文基于 IronClaw 仓库 docs/internal/design/oobe.md 设计简报展开系统讲解 WebChat v2 面向新用户「前五分钟」的首次体验Out-of-Box Experience, OOBE设计用户在完成账号/工作区开通后第一次进入 Web 聊天界面的那一刻产品如何通过「建议任务卡片」完成冷启动、如何呈现第一条自动化建议、以及如何在返回用户场景中复用同一套抽屉控件。读完本文你将掌握该设计的双轨演进历史Foundational → Vision、建议任务卡片的视觉语言与状态模型、可复用任务抽屉的交互形态以及它与仓库中已落地的持久化后端建议契约suggestions.list / generate / start / dismiss之间的真实对接关系。一、要解决的核心问题冷启动与第一条自动化WebChat v2 的落地视图landing view今天是「大标题 输入框 三个静态建议 chip」对应组件为 empty-state.tsx。仓库中已经原型化的自动化表面——「Done for you」轮播carousel、行内日历改期卡片、Plan 卡片、agent 模式药丸pill——全都假设自动化已经存在。而一个全新账号没有任何自动化因此两个关键时刻是空白的冷启动cold start什么都没有用户不知道 IronClaw 能为他做什么第一条自动化出现first automation appearing第一个「替你完成」的时刻如何呈现。设计简报给出的目标是设计新用户的前五分钟——账号/工作区开通后落在 Web 聊天界面的瞬间。非目标non-goals同样明确不重设计稳态聊天、不重设计自动化管理页、不重设计扩展目录只在其上增加一层首次运行体验并复用已有能力。二、双轨设计Foundational 与 VisionVersion 开关设计载体是自包含的交互原型 mockup.html内置Version开关Foundational / Vision与Scene开关First run / Thread / Plan可在浏览器中直接打开播放。两套设计共享同一套卡片语言并在自动化存在后收敛到同一个「已填充的轮播」。2.1 Foundational —— 近期的、贴合当前 main 的实现面向多租户企业部署只做今天 v2 系统上轻量可行的事工具由管理员白名单、用户自行授权不设独立的连接面板每张建议卡片携带「Connect Tool」CTA授权通过模态 OAuth「浏览器」对话框完成登录 → 批准 scopes。连接成功后卡片变为可操作的建议。建议卡片在第一步即出现agent 立即给出第一批建议无需先「挣得」一个空冷启动每张卡片从connect状态开始工具授权后变为 approve/modify/dismiss。卡片以提案语气呈现Triage your inbox运行后翻转成结果语气Triaged your inbox。无用户名除非能从确定性来源管理员预配置、email、Slack 资料推导出来默认是匿名称呼Welcome to IronClaw. 普通账号 chip。agent 模式收敛为三种默认SuggestSuggest——执行任务或自动化前始终请求批准Plan——先描述活动与所需步骤等待批准Auto Approve——自动批准用户已批准过的任务类型以及用户显式请求的任何任务。使用main 的 composer和朴素pills-collapse 抽屉用户开始输入时任务卡片折叠为 composer 上方的一行药丸无边框/无吸附抽屉。2.2 Vision —— 北极星目标在 Foundational 之上叠加理想化的首次运行体验冷启动连接流一个「连接你的工具」面板用户选择工具后排队式模态 OAuth「浏览器」对话框逐个走完一次登录、每个工具批准 scopes直到全部授权随后是期待节拍 → 第一张卡片揭晓。支持具名问候语与四模式集合Suggest / Plan / Auto /Bypass。首条自动化揭晓情感峰值——一段短暂的期待节拍品牌化NEAR 进度指示器 骨架瓦片随后第一张「Done for you」卡片以 Gemini 风格ai-spark边框扫光凭空浮现。在prefers-reduced-motion下被抑制。吸附式任务抽屉建议卡片放入一个吸附在 composer 上、向上延伸的带边框抽屉框内品牌化进度指示器 agent 活动字符串位于抽屉上方抽屉头部携带副标题左上折叠/展开卡片 ↔ 药丸关闭✕关闭后出现「Show suggestions」恢复条。输入时仍折叠为药丸。设计原则Vision 的每一件都是 Foundational 对应物的超集逐卡连接 → 批量连接静态首卡 → 动画揭晓朴素抽屉 → 吸附框3 模式 → 4 模式Foundational 永不丢弃Vision 只是扩展它。三、任务抽屉可复用控件而非一次性 OOBE 装置设计简报明确强调抽屉不只是 OOBE 设备它是返回用户或打开新线程时「建议任务」的可复用表面折叠态紧凑的可滚动药丸行品牌 logo 标题吸附在 composer 上展开态Vision完整卡片框。这为返回用户提供了一个持久的、可关闭的「这是我接下来可以接手的事」提示affordance而不会霸占线程。抽屉的状态机open / collapsed / dismissed在 PLAN.md 中被明确复用Vision 的吸附抽屉「复用 Foundational 抽屉状态机」。四、卡片设计语言两个版本共享真实品牌产品 logoGmail、Google Calendar、Docs、Drive、Slack 全彩GitHub Notion 通过currentColor单色以跟随主题而非占位字形。标题优先的头部图标 任务标题无状态标签状态从操作行读取。弱化的「From app · time」来源行实心主按钮 次级文字按钮Approve / Modify / Dismiss所有模式下链接按钮均带图标。更大圆角、柔和阴影、紧凑高度操作行底部对齐。这份卡片语言在仓库中的实现位置与原型记录可对照 mockup.html 与 integration-review.html后者为自包含的视觉评审页面含 5 层集成示意图、依赖图与阶段时间线。五、代码落点这套设计住在哪里设计简报给出了精确的仓库落点SPA 技术栈为React 19 TypeScript Tailwind v4设计令牌在styles/app.css落地视图empty-state.tsx在main上自动化表面组件族automation-carousel.tsx、automation-task-card.tsx、task-action-bar.tsx、mode-selector.tsxmock 数据接缝lib/automation-tasks*.tshooks/useAutomationTasks.ts以及 DEV 环境pages/design-preview/design-preview-page.tsx——这些在 PR #6994 中原型化后被回滚不在main上其形态记录在 mockup 与接线契约中后端契约文件AUTOMATION-TASKS-CONTRACT.md提案版接线AutomationTask领域模型、5 个持久事件、投影、HTTP 路由与 facade 方法治理文档VISION-RECONCILIATION.mdgoverns——当与 PROPOSAL/PLAN/IMPLEMENTATION 冲突时以此为准配套 README.md概述、PROPOSAL.md完整规格、PLAN.md执行顺序、CHECKLIST.md完成定义。设计简报同时指出了当前的真实状态今天轮播在无任务时return null全新账号看到的是未变化的 hero composer——即冷启动状态目前未被设计这正是该 mockup 要填补的部分。六、已经落地的 vs. 需要后端的设计简报把工作分成两类边界清晰已原型化后回滚PR #6994纯展示、mock 数据轮播 任务卡 操作栏、日历改期卡、Plan 卡、agent 模式药丸以及端点形态的数据接缝。而品牌化的NearProcessIndicator#6901与AuthRequired连接器路径已在main上。需要后端issue #6993「还没有自动化」/「正在做第一条」的投影状态揭晓由AutomationTaskAutomated投影事件驱动期待/骨架状态返回用户的抽屉建议 feed三模式 vs 四模式的 agent 模式门控——这些是 AUTOMATION-TASKS-CONTRACT.md §2–§7 接线之上的新 UI。6.1 提案契约历史记录AutomationTask 领域模型契约文档§§1–3 已被 PR #7694 取代仅作设计意图记录曾规划如下 Rust 模型镜像 TS 的AutomationTask标识符用ironclaw_common的 newtypepub struct AutomationTaskId(String); // newtype校验 pub enum AutomationApp { // #[serde(rename_all snake_case)] Gmail, GoogleCalendar, GoogleDocs, Slack, Notion, } pub enum AutomationTaskKind { // snake_case EmailTriage, CalendarAccept, CalendarReschedule, DocInsights, } pub enum AutomationTaskState { // snake_case Suggested, InProgress, Automated, Reverted, Cancelled, }以及 5 个持久事件AutomationTaskProposed/Modified/Automated/Reverted/Cancelled每个都脱敏、可重放、经持久化 sink 追加配(tenant, user)作用域过滤的AutomationTaskProjection带重放游标并强制跨用户隔离回归测试。七、治理变更Vision 直接对接已落地的持久化后端建议契约关键转折PR #7694 直接落地了「持久化后端建议」契约feat: add durable backend suggestions它是后端纯实现明确「前端文件不变、前端消费不在其范围」。这恰好补上了 PR #6994 占据的接缝——#7694 是生产者#6994 变为消费者。于是程序从「先 Foundational 后 Vision」转向直接构建 VisionFoundationalPhase 1UX 被裁掉VISION-RECONCILIATION.md 成为治理文档。7.1 冻结在 ironclaw_product_contracts 中的契约方法WebUI 路由产品操作GET/api/webchat/v2/suggestionssuggestions.listPOST/api/webchat/v2/suggestions/generatesuggestions.generatePOST/api/webchat/v2/suggestions/{id}/startsuggestion.startDELETE/api/webchat/v2/suggestions/{id}suggestion.dismiss响应形态RebornSuggestionsResponse { status: empty | generating | ready | failed, generation_id?: string, retry_after_seconds?: number, suggestions: RebornSuggestion[], } RebornSuggestion { id, title, description, suggested_prompt, thread_id?, run_id? } RebornSuggestionStartResponse { suggestion_id, thread_id, run_id } RebornSuggestionDismissResponse { suggestion_id, dismissed }这些类型在仓库中有源码级印证suggestions.rs 声明了SUGGESTIONS_LIST_VIEWsuggestions.list无分页 ProductView、SUGGESTIONS_GENERATE_COMMANDsuggestions.generate、SUGGESTION_START_COMMANDsuggestion.start与SUGGESTION_DISMISS_COMMANDsuggestion.dismiss四个命令描述符并配有序列化测试generate请求必须携带client_action_idlist请求为空输入响应含status/generation_id/retry_after_seconds/suggestions字段。对应的 DTO 与响应类型位于 product_wire.rs路由处理器与描述符行在 handlers.rs 与 descriptors.rs并有 webui_v2_descriptors_contract.rs 等契约测试守护。异步生成语义POST generate携带client_action_id返回202与status: generating及retry_after_seconds提示客户端轮询GET suggestions。每个(tenant_id, user_id)存在一套卡片新一轮生成清除上一套。卡片数量限制在1–5条schemas/suggestions.output.v1.jsontitle≤ 80、description≤ 240、suggested_prompt≤ 2000 字符。路由与前端建议表面始终开启且表面保持懒加载使其卡片/图标代码不进入 eager/chatbundle。7.2 Vision 因此获得了什么POR 元素之前有了 #7694持久卡片存储、路由、生产者全新未建已落地期待 /「正在做第一条」状态「新投影状态#6993」真实empty/generatingretry_after_seconds首卡揭晓ai-spark conjure需要AutomationTaskAutomated事件可用触发generating → ready转换Approve → 运行经handleSend提示注入被取代suggestion.start返回{thread_id, run_id}卡片实时状态已退役——无持久绑定复活卡片携带持久thread_id/run_idDismiss本地组件状态持久DELETE吸附抽屉 · 具名问候前端 / 开放决策不受影响其中影响最大的是「卡片实时状态」卡片级持久状态曾因「需要持久化的逐任务记录」而被退役而 #7694 正是那条记录——返回用户卡片能显示真实状态因为 suggestion→thread/run 的绑定是持久化的、重启后依然存活。7.3 连接模型的裁决connect 不再是一个卡片状态生成的卡片原不携带工具身份与连接状态{ id, title, description, suggested_prompt, thread_id?, run_id? }这是刻意为之prompts/suggestion_generation.md 指示生成器「没有证据表明账号/扩展/凭证/能力可用时不得声称其可用」且偏好「assistant 在普通对话中能完成的工作」。模型能看到扩展扩展搜索在能力白名单内但输出 schema 无处声明它。最终裁决§3.1connect 不再是卡片状态。Vision 冷启动连接面板作为独立的落地表面保留由扩展目录useExtensions驱动而非由建议卡片驱动。connect 与 suggestions 成为两个并列表面Landing ├── Connect panel ← extensions catalog (useExtensions)批量 OAuth walk └── Suggestion drawer ← GET /suggestions工具无关的卡片后果卡片永不因连接而阻塞——卡片一经存在即可 start即时just-in-time授权仍然有效——若一次 start 的运行需要未连接的工具agent 发出既有的AuthRequired门框线程渲染AuthOauthCard已落地的既有路径不变待 QA 验证假设AuthRequired会为 suggestion-started 运行触发因为是同一 agent loop应会触发但尚未测试。面板失去逐卡「为什么这个工具重要」的框架——被接受的权衡resolveConnectExtension被废弃删除其职责是卡片appid → 目录扩展目录驱动面板直接读目录。但它验证的复用模式——懒加载真实ConfigureModal而非克隆useOauthSetup约 250 行的弹窗/轮询状态机——被继承到 V1 面板也正是该面板构建便宜的原因。落地后的icon/sources细节见 SUGGESTION-ICONS.mdicon是必填的、provider 中立的语义任务枚举email/calendar/document/storage/spreadsheet/presentation/code/messaging/notes/web/memory/genericgeneric为兜底只控制卡片字形不是扩展身份sources是 1–5 条人类可读来源标签纯展示、前端绝不从中推导图标或 setup 路由。八、契约带来的两个已决决策卡片并行运行——单一活动锁被移除。原设计将「同时只有一个活动任务」建立在submit_turn返回DeferredBusy/RejectedBusy线程上已有运行在跑之上但suggestion.start为每条建议创建独立线程后端并无约束需要镜像——批准一张卡不再禁用其他卡这正是 Vision 多卡抽屉想要的。「 Automation」被移除。卡片 schema 没有automation_prompt字段#7694 也未新增自动化路由没有可构建的依据与其保留一个无持久背书的客户端合成提示注入不如整条从卡片移除。若日后循环自动化成为首运行目标需要自己的后端契约。九、重构映射与切片计划PR #6994治理文档给出 keep/change/delete 重构映射KeepChangeDeleteSuggestedTaskCard展示层DEMO_TASKS→GET /suggestions generate/pollresolveConnectExtension 测试SuggestedTaskSurface外壳Approve →POST /{id}/start→onSelectThread(thread_id)unconnected卡片状态常开建议表面路由无 flagDismiss →DELETE /{id}卡片上的ConfigureModal接线懒加载 bundle 纪律SuggestedTask类型 →RebornSuggestion形态chat.oobe.connectUnavailable11 个 localeNearProcessIndicatorrender-prop卡片状态派生自绑定的run_idconnectedIds状态切片计划slices 1–6、9、10 已构建✅ 建议 API 客户端 类型四个类型化调用遵循lib/api.ts约定apiFetch、clientActionId()DTO 镜像RebornSuggestion✅ 表面消费真实数据mount 时listempty→ generate CTAgenerating→ 按retry_after_seconds轮询ready→ 渲染卡片failed→ 重试✅ start dismissApprove 调start并导航到返回的thread_iddismiss 调DELETE✅ 移除连接模型unconnected状态、解析器、i18n key✅ V3 期待状态empty CTA / generating 骨架 / failed 重试generating 态在静态.v2-skeleton瓦片上渲染品牌化 NEAR 指示器✅ V2 揭晓克制的卡片入场.oobe-card-reveal复用已批准的v2-page-in关键帧prefers-reduced-motion抑制注意这是治理干净的版本不是mockup 中即兴的 conic-gradient ai-spark 边框扫光——那会绕过app.css的静态运动策略⏳ 卡片实时状态订阅绑定run_id反映运行中/完成/失败未构建⏳ V1 连接面板目录驱动的冷启动「Connect your tools」表面复用ConfigureModal模式未构建✅ V4 吸附抽屉框表面以带边框抽屉渲染头部「Suggested for you · approve to run, or tweak first」吸附在 composer 附近未做真正的边框融合保留圆角框 紧凑间隙以不触碰已落地的ChatInput✅ 刷新 连接入口issue #7815F1/F2——抽屉头部带刷新控件重跑generate进行中禁用与/extensions入口空/失败 CTA 行将 generate/retry 与同一连接入口配对。剩余的 Vision 后续未构建供设计评审跟踪卡片实时状态slice 7、V1 连接面板slice 8、agent 模式选择器Suggest / Plan / Auto / Bypassnet-new需持久住所 类型化门控接线、输入折叠为药丸、具名问候 顶栏客户端用户名调用V5推迟需要确定性用户名来源、ai-spark 揭晓若采用不绕过运动策略的动画方案。十、安全与隔离约束租户/用户作用域投影按(tenant, user)过滤跨用户隔离回归测试强制仅经中介的效果Approve/Modify(rerun)/Revert 是真实第三方效果必须经能力宿主 产品适配器成功仅由 provider 证据 回读确认绝无乐观回显脱敏每个事件 payload 默认敏感在 log / 持久追加 / 投影 / 传输 / 模型可见结果之前承担脱敏义务自主性升级autoFoundational与bypassVision对整类任务抑制批准门均需显式门控抑制测试 每次自动运行动作的审计痕迹auto把global_auto_approve从单一布尔推广为按类型的同意无新认证路径connect 复用共享扩展授权解析器凭证身份与扩展身份保持分离。十一、开放问题截至文档状态分期Foundational 先对当前 main 落地Vision 中哪件先毕业——吸附抽屉、连接流还是揭晓动画用户名推导Foundational多个确定性来源同时存在时哪个优先管理员预配置 vs email vs Slack 资料全部失败时的兜底是什么Auto Approve 范围「用户已批准的任务类型」如何定义与界定按工具、按动作、消费/影响上限企业工具配置管理员预配置的工具集如何呈现给用户——只读「由你的工作区连接」提示还是不可见Vision 冷启动是否播种一条真实的低风险自动化以保证首卡出现还是等待有机活动替换 UX新一轮生成清除上一套用户在阅读中遇到替换落地时抽屉该做什么逐卡连接未来若加逐卡连接动作必须由后端给出类型化扩展身份或经扩展目录解析绝不能从icon或人类可读的sources字符串推断身份。延伸阅读仓库内设计包主页docs/internal/design/oobe/README.md执行概述与评审入口治理文档docs/internal/design/oobe/VISION-RECONCILIATION.md与已落地后端契约的全面对账完整规格docs/internal/design/oobe/PROPOSAL.mdshipped vs net-new 范围、依赖清单、安全模型、测试策略执行计划docs/internal/design/oobe/PLAN.md阶段、门、PR 尺寸完成定义docs/internal/design/oobe/CHECKLIST.md后端契约源码crates/contracts/ironclaw_product_contracts/src/suggestions.rs、crates/contracts/ironclaw_product_contracts/src/product_wire.rs路由与描述符crates/product/ironclaw_webui/src/webui_v2/handlers.rs、crates/product/ironclaw_webui/src/webui_v2/descriptors.rs前端表面crates/product/ironclaw_webui/frontend/src/pages/chat/components/suggested-task-surface.tsx、crates/product/ironclaw_webui/frontend/src/pages/chat/lib/suggestions-api.ts赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw OOBE 首次运行引导从空白落地页到 Agent 驱动的建议卡片全链路解析IronClaw OOBE 首次运行引导从空白落地页到 Agent 驱动的建议卡片全链路解析 IronClaw 的 OOBEOut of Box Exper人工智能AI 应用交互助手AI AgentIronClaw OOBE 首启引导设计解析两阶段提案、已发货建议契约与 WebChat v2 冷启动方案IronClaw OOBE 首启引导设计解析两阶段提案、已发货建议契约与 WebChat v2 冷启动方案 IronClaw 的 OOBEOut of Bo人工智能AI 应用交互助手AI AgentIronClaw OOBE 首次运行体验实现指南建议卡片从前端组件到持久化后端契约的完整落地IronClaw OOBE 首次运行体验实现指南建议卡片从前端组件到持久化后端契约的完整落地 本文以 IMPLEMENTATION.md https://li人工智能AI 应用交互助手AI Agent上一篇5分钟搭建开源数字标牌系统LibreSignage完全指南下一篇如何快速掌握缠论分析ChanlunX 通达信插件完整实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考