人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载本篇技术指南以 Kun 仓库中的 OpenSpec 变更提案 unify-code-design-and-work/proposal.md 为主线系统讲解 Kun 如何将顶层Code | Write | Design三工作台收拢为Code | Work把 Design 从独立工作台降级为 Code 工作台内每回合可选的任务模式并引入DesignTaskProfile首个回合锁定、内嵌设计白板与 HTML/AI 图像双主输出通道。读完本文你将掌握这套改造的契约设计design-task-profile.ts、准入锁定逻辑turn-service-design-admission.ts、渲染器任务状态机useWorkbenchTaskSurface.ts以及 Work 呈现别名对write协议兼容的完整方案。背景为什么要把 Code | Write | Design 收拢为 Code | Work提案开篇## Why指出现状的三重问题会话碎片化Code、Write、Design 是三个顶层工作台尽管 Design 已与 Kun 共享同一 runtime且能在 Code 右侧白板中渲染但用户仍然被迫在描述任务之前先选择一个应用表面Write 名不副实Write 已覆盖 Markdown、PDF、图片和六种 Office 格式DOC/DOCX/XLS/XLSX/PPT/PPTXWrite 这个名字已无法描述其工作台范围导航与对话归属割裂Design 拥有独立的 sidebar、stage、线程注册表和按文档组织的会话与 Code 的 tabbed 右工作区各自为政而 Code 已有的 Canvas 面板虽然能展示 Design 文档但只是瞬态分支不跑完整的 HTML/ShapeOps 管线。因此本变更的目标非常收敛保留一个 Kun runtime、稳定的扩展与持久化write标识符、.kun-design下的既有 Design 产物文件、图像提供方能力检查以及 700 行的源文件门限authored-file gate见 design.md 的 Context 部分。Design 与 Code 共用 HTTP/SSE只是被投影成三条渲染器路由改造的本质是重排这层投影而不是重写 runtime。顶层导航从 Code | Write | Design 到 Code | Workproposal.md的 What Changes 部分给出了明确的导航变更顶层导航由Code | Write | Design替换为Code | Work同时保留稳定的内部write路由、设置项、扩展、IPC 与持久化标识符Design 成为 Code 工作台内的对话模式conversation mode用户在模式中立的会话里每一回合都可以选择 Code 或 Design会话列表不给会话行打 Code/Design 标识只有 Design 文档、输出介质、目标和样式快照会随首个被接受的 Design 回合锁定。也就是说顶层只有两个入口是用户可见的变化而write这组内部标识符一个都不动。tasks.md的第 4 节还记录了一个细节Code/Work 的分段控件segmented control最终被替换为紧凑的无障碍下拉accessible dropdown以保证在窄 sidebar 中依然可读且不破坏工作台路由。对应的工作台路由实现证据位于 src/renderer/src/components/workbench/useWorkbenchNavigationController.test.ts导航控制器回归测试顶层模式枚举在 threads.ts 中定义为ThreadAgentSurface z.enum([code, write, design])。核心设计工作台归属与 per-turn 任务表面分离这是整个改造最关键的决策见 design.md 的 Decisions 第一节从 Code 工作台新建的会话始终持久化thread.agentSurface: codewrite仍归 Work 所有遗留的独立 Design 记录可以保留thread.agentSurface: designCode 会话的每一回合可选择 Code 或 Design并按回合持久化Code 回合发送agentSurface: codeDesign 回合发送agentSurface: design加上 Design 标志位与文档目标准入admission不得把一个显式 Code 拥有的线程在接受 Design 回合时重新打标签。这样做的收益一个任务列表 一条时间线timeline同时 runtime 依然能依据每回合的表面选择正确的指令、子代理与工具。每回合的表面与可选的 Design 档案成为可持久化的 runtime 权威用于重载、队列恢复、扩展路由和审计。会话行保持视觉上的模式中立不渲染 Code/Design 身份图标也不渲染产物徽标因为组合器composer的选择描述的是下一回合而不是整段会话。Design 回合采用 Agent/Direct 执行。渲染器侧的实现位于 useWorkbenchTaskSurface.ts其中关键判断// 只有遗留的独立表面才锁定任务模式Code-owned 会话永远按回合选择 return thread.agentSurface write || thread.agentSurface design而下一回合表面的推导优先级为遗留 Design 会话 → 已持久化的草稿 → pendingDesignThreadIntent → 已锁定 profile → 默认code。当线程拥有锁定文档目标或遗留注册表绑定时白板的挂载独立于下一回合的表面选择——即白板跟随文档而非跟随下一回合模式designProfile.documentTarget驱动。统一任务分类器实现在 design-task-classification.ts它被任务列表资格、导航、返回记忆和画布恢复路径共享但绝不用它给会话行分配 Code/Design 图标export function isDesignWorkbenchThread(threadId, thread, registry): boolean { if (isLegacyDesignWorkbenchThread(threadId, thread, registry)) return true if (!thread) return false // Code-owned 会话只有通过锁定 Design 文档才具备 Design 能力 return Boolean(thread.designProfile) }DesignTaskProfile结构化设计档案与首个回合锁定契约字段DesignTaskProfile是本次改造新增的严格持久化契约完整定义在 kun/src/contracts/design-task-profile.ts基于 zod。关键字段如下字段类型/取值说明version1契约版本严格字面量documentTarget{ documentId, boardArtifactId }每任务唯一、可独立写画的文档绑定两者均为 1128 字符且须匹配^[A-Za-z0-9][A-Za-z0-9._-]*$的稳定标识符outputMediumhtml \| image输出介质HTML 为默认targetweb \| app目标平台直接影响默认画布尺寸见下文preset14 种设计系统预设none / shadcn / radix / material / ios / fluent / ant / chakra / carbon / polaris / bootstrap / geist / brutalism / editorialpresetSourceexplicit \| root-design-md \| workspace-default \| noneAuto 解析来源锁定时固化styleSnapshot版本 1、sourceHash、sourceName、content≤16 000 字符、truncated?根DESIGN.md的不可变解析投影仅当presetSource root-design-md时合法superRefine 校验canvasEnginekun \| excalidraw可选绑定画布的渲染引擎缺省表示遗留 Kun canvascontext有界DesignContextSnapshotdesignType、brandColor、tone最多 12 项且不可重复、designGuidelines≤4 000、radius、density、fontStylelockedAtTurnId字符串仅存在于运行时已锁定档案中标记锁定回合DesignImagePlacementTarget还细化了 AI 图像放置目标shapeId 恰好一个expectedImageUrl或expectedHolderKindexplicit / implicit-image / implicit-frame / implicit-rect用于幂等放置。锁定语义与错误码一个 Code 工作台线程在首个被接受的 Design 回合之前没有锁定档案。首个 Design 回合被接受时lockedAtTurnId与该档案被原子写入之后后续 Design 回合必须与锁定档案完全一致通过sameDesignTaskProfile的 JSON 比较见 domain/design-task-profile.ts否则拒绝并返回design_profile_locked后续 Code 回合不带档案即可被接受且不会被task_surface_locked拒绝再次进入 Design 时复用锁定档案不重新锁定、不修改。这两个错误码task_surface_locked与design_profile_locked被注册进共享 runtime 错误契约kun/src/contracts/errors.ts、kun/src/server/routes/runtime-error.ts并规定确定性的 4xx 拒绝必须恰好失败一次而不是进入未知结果恢复循环见 tasks.md 第 12 节。准入解析原子决策链准入逻辑集中在 kun/src/services/turn-service-design-admission.ts 的resolveDesignTurnAdmission。它在持有线程级 mutation 锁的情况下运行保证任何 attachment 绑定、文档提交、模型回合、item 或事件产生之前任务/档案归属已经确定因此锁定决策是原子的。核心校验链包括表面锁定检查若lockedTaskSurface与请求表面冲突抛TaskSurfaceLockedErrordesignProfile与designDocumentTarget必须成对出现且documentTarget必须与designProfile.documentTarget一致否则抛TurnConflictError提交档案必须通过DesignTaskProfileInputSchema严格解析不支持的中介、预设、目标、超长上下文或错配文档 id 都在模型回合开始前被拒已锁定档案存在时Code 回合不得携带档案/文档目标Design 回合若档案或文档目标不匹配则抛DesignProfileLockedError匹配则返回锁定档案作为effectiveProfile首次 Design 回合通过lockDesignTaskProfile(submittedProfile, turnId)完成锁定并返回locksProfile: true。对应的测试位于 kun/src/services/turn-service-task-surface-lock.test.ts覆盖了首个回合前任选模式首个 Code 回合之后允许进入 Design混合历史逐回合 Code/Design 选择等场景以及design_profile_locked与 Code-with-profile 冲突用例。每次 Design 回合的快照语义thread-design-profilespec 要求每个 Design 回合及其 user item 都记录生效档案与文档目标用于审计、回放与画布路由。这意味着队列重试排队中的 Design 消息在用户修改全局 Design 设置后被重试时使用原排队时快照的档案与文档目标而不是可变的全局设置画布重放错过的 Design 操作回放时只有 thread、turn、document、board 目标全部匹配当前活跃 Design 任务的才被应用渲染器本地存储只是发送前草稿/缓存不是权威权威始终是 runtime 数据design.md 明确说明。Fork保留意图但不共享可变画布状态Fork 一个 Design 任务时锁定档案被复制同时绑定文档被克隆为独立可写的新绑定retargetDesignTaskProfile 文档克隆。渲染器侧 design-locked-profile.ts 提供cloneDesignTaskProfile与restoreLockedDesignDocument线程恢复元数据ResumeSessionMetadata携带sourceDesignProfile、sourceDesignDocumentTarget与requiresIndependentDesignTarget见 threads.ts。还有一个重要的失败边界从历史回合发起 fork 时如果该回合不存在文档快照操作必须在克隆前显式失败返回 unsupported-history 错误绝不能把截断的聊天与未来的画布状态配对tasks.md 第 7.7 节专门做了 fault-injection 覆盖。遗留数据处理原则档案解析对新写入严格、对遗留字段宽容无档案的旧线程保持可读绝不虚构档案只有新 Design 工作流显式创建时才生成。遗留的agentSurface: design或 Design 线程注册表记录是任务列表中的一等公民其注册表文档绑定是权威选择该会话时通过同一完整画布表面恢复原始可写的.kun-design文档——只改呈现与导航不迁移、不复制、不删除任何线程归属、档案、注册表或产物数据。内嵌设计白板在 Code 右侧跑完整 Design 管线embedded-design-whiteboard能力要求 Code 右工作区挂载绑定文档时具备既有 HTML、SVG、动效、多屏、设计系统、原型、选择、撤销与导出能力而不是原来的只读瞬态分支。渲染器用CodeCanvasDesignSurface描述白板目标code-canvas-design-surface.tsexport type CodeCanvasDesignSurface { surfaceKind?: kun-canvas | kun-design | kun-whiteboards threadId: string workspaceRoot: string documentId: string boardArtifactId?: string readOnly?: boolean canonicalDocumentId?: string continuationOperationId?: string } | nullsurfaceKind用来区分三种白板宿主轻量 Code canvas、完整.kun-design文档、中央 Work 白板boardArtifactId在多画板文档内钉住画板避免模式切换挂载到无关的空白画布。目标持久化在浏览器存储键kun.codeCanvas.designSurface.v2下面板折叠与渲染器重载后仍存活锁定档案在线程加载时重新断言该缓存comment 明确指出 A locked runtime Design profile remains authoritative and reasserts this cache on thread load。关键行为design.md 与 spec 交叉确认面板呈现变化不改变任务状态折叠、聚焦、缩放、重开只影响呈现任务、锁定档案、选中文档与画板状态不变关闭右面板不清除绑定持久重放面板重开时对错过的操作幂等地应用durable replay receipts防止已投递的结果被二次应用工具结果身份去重目标水合hydrationDesign 会话在文档目标水合完成前右面板保持Design loading 状态绝不回退到轻量 Code canvasCode 白板接收完成的渲染器工具结果若画布工具结果先于线程文档就绪完成渲染器在文档激活后将结果重放到匹配会话白板spec 场景首回合竞态空工作台发送首个 Design 回合且新 Code-owned 会话在createThread返回前已激活时pending Design 选择与临时文档在绑定前保持活跃pendingDesignThreadIntentprovisionalDesignThreadIdsRef见 useWorkbenchTaskSurface.ts 的ensureDesignThread发送失败时通过rollbackProvisionalThread回滚临时文档不留下空文档。白板恢复的完整实现链在 design-locked-profile.tsactivateLockedDesignDocument先restoreLockedDesignDocument必要时rehydrateArtifacts再以canvasDocumentKey(workspaceRoot, boardArtifactId, .kun-design/documentId)为目标等待画布就绪waitForCanvasDocumentKey默认 5 秒超时失败时给出可读错误并保持绑定不变。测试覆盖见 code-canvas-design-surface.test.ts 与 canvas 系列回归tasks.md 第 8 节记录 88 个文件 709/709 测试通过涵盖重放恢复、图完整性、标注、导出、剪贴板、快捷键、缩放与组合器路由。HTML 与 AI 图像两条互不静默降级的主输出通道proposal.md明确规定HTML 是默认交互输出AI 图像任务在白板上产出光栅资产绝不静默回退为 HTML而 HTML 任务可以调用图像生成作为支撑资产。设计决策design.md进一步给出两条通道的语义html走既有 screen factory 与链接式 HTML 续写linked HTML continuation续写渲染为来源回合内部的进度而不是另一条用户消息image要求 runtime 具备图像生成能力公告光栅通道禁止 HTML-screen 回退。模型侧的执行指令由 kun/src/prompt/design-task-profile.ts 的buildDesignTaskProfileInstruction生成它只从不可变线程快照派生const frame profile.target app ? 390x844 mobile-first : 1280x800 desktop-first const output profile.outputMedium image ? The primary deliverable is a generated raster image. Do not silently substitute HTML. : The primary deliverable is an interactive HTML interface. Raster images may only support it.注意这里app目标使用390×844 移动优先、web使用1280×800 桌面优先的默认画布尺寸并在每条指令中输出锁定回合、绑定文档、绑定画板、输出介质、目标、预设及来源、样式快照哈希和视觉上下文快照。渲染器侧的确定性放置逻辑spec 的 AI-image placement 要求为generate_image成功完成后幂等地填充选中的空 holder不改变其边界否则插入推荐槽位工具结果身份completion identity保证 SSE 重连重放时不重复插入见 canvas-generated-image-replay.ts进行中的生成显示持久占位符成功原位替换失败/中止显示可操作错误状态原因、耗时、重试动作且永不退回空白canvas-image-generation-progress.ts交付文案随完成度变化助手说会把图像放到白板时状态保持 in-progress工具成功后才变为 delivered。能力失败不改变任务意图spec 场景场景行为首回合前图像生成被禁用diagnostics 报告未启用AI image从输出选项中消失未锁定的陈旧 image 草稿规范化为 HTML首回合前已启用但不可用未配置 providerAI image置灰并显示 runtime 原因 Image Generation 设置入口HTML 保持可用锁定后 provider 被移除保留档案与草稿、阻止 Design 提交并给配置动作会话保持 AI image 身份这些场景在 useWorkbenchTaskSurface.ts 中有直接实现draftNeedsImageFallback仅在未锁定任务表面、无锁定档案且图像生成明确禁用时把草稿介质规范化为html——一旦锁定绝不做静默切换。样式播种一次解析之后尊重文档设计系统Design 组合器复用既有DesignSystemPreset目录与 Design 上下文字段。在首次发送前Auto按如下顺序解析design.md 决策有效的根DESIGN.md源码中root-design-md来源要求捕获sourceHash/sourceName与 ≤16 000 字符的内容投影且 UI 要标明该项目的样式来源见 design-task-profile.ts 与 spec工作区 Design 默认workspace-default无none。解析结果被快照进锁定档案。文档生成后文档自身持久化的设计系统成为权威后续全局设置变化不能隐式重排其样式——这正是styleSnapshot与presetSource存在的意义且buildDesignTaskProfileInstruction明确要求模型不要重读当前工作区文件后续编辑不得重排本任务。Work呈现别名与 Office 语义work-product-surfaceWork 是一次纯呈现改名design.md 决策 Keep Work as a presentation alias只有面向用户的模式、工作台、助手、引导onboarding、设置与文档措辞改为 Work/办公稳定的代码标识符与持久化线程标题保持write/Write Assistant渲染器把它们映射为本地化产品标签扩展贡献到workbench:write时继续匹配 Work 表面无需新增workbench:worktokenWork 发送回合时 runtime 仍使用agentSurface: write具体动词writing、polishing、formatting 等在描述真实功能时保持不变。同时 Work 的措辞必须如实反映能力边界描述 Markdown/文本编辑以及 Office/PDF 的预览、选择、引用、分析与生成流程不得声称原生编辑 Office 文件DOC/DOCX/XLS/XLSX/PPT/PPTX 打开后保持既有的只读预览、选择、语义上下文与实时刷新行为不变。所有受支持语言都要提供 Work 产品标签且不改名既有的write*i18n 键locale parity 校验。风险应对与迁移路径design.md 记录了 6 项已识别的风险及对策风险对策完整 Design 画布控件在右面板过宽增加聚焦/展开呈现与单面板窄布局缩放/折叠永不改变任务/档案状态首发送竞态锁错档案或产生重复文档客户端请求幂等 原子 runtime 准入 临时文档回滚路径rollbackProvisionalThreadShapeOps 重放到错误文档每个 Design 回合持久化文档/画板目标实时与重放过滤都要求它AI 图像档案锁定后生成能力消失保持档案锁定、保留草稿、以 runtime 能力原因阻止提交并链接图像生成设置绝不静默切换 HTML既有扩展依赖workbench:design/workbench:write从活跃任务表面派生 Design 上下文保持稳定的 Write token 不变旧 Design 会话不可访问统一任务列表纳入项目自有遗留 Design 会话恢复既有注册表文档不迁移不删除 runtime 记录与文件迁移分 6 步design.md Migration Plan先加宽容的可选 runtime/档案契约旧记录无档案可加载→ 显式化新建 Code/Design 线程并更新共享 Code 任务过滤器 → 在 Code 右工作区挂载完整 Design 文档表面并路由锁定回合 → 上线统一组合器/列表/空态并移除独立 Design 入口 → 应用 Work 显示别名不改写已存设置或线程→ 遗留与 Code-owned Design 任务都绑定到可复用完整 Design 画布。回滚只需移除新 UI 入口可选线程/回合元数据与.kun-design内容对旧版本依然可读。验证与交付门禁tasks.md记录了完整验证证据2026-08-12 至 2026-08-14首轮typecheck 与生产构建通过249 个聚焦 renderer/main 测试、40 个聚焦 Kun 测试、2 个 runtime-manifest 测试、127 个聚焦 canvas 生命周期测试通过复查轮聚焦 Kun 46/46、聚焦 renderer/main 143/143全量 Kun 4352 通过顶层全量运行 6896 通过残余失败均被对照HEAD验证为 ToolStormBreaker/loop recovery、原生node-pty/better-sqlite3ABI、TUI/goal 时序等既有基线问题内嵌白板轮88 个聚焦 Design canvas 文件 709/709 通过逐回合表面修正轮严格 OpenSpec validation 通过Kun 准入 12/12含新增design_profile_locked用例渲染器 39/39store 准入/引导/分类 60/60模式中立呈现轮sidebar per-turn 19/19Kun 准入/档案 21/21首发送竞态轮7 个聚焦文件 55/55。验证命令门禁为npm run typecheck、npm run test、npm run build、npm run lint、npm run check:file-lines700 行/文件门限与git diff --check外加 strict OpenSpec validation。这些命令与测试脚本可在仓库 package.json、scripts/run-tests.mjs 与 scripts/check-file-lines.mjs 中查看。小结这次改造的技术内核可以浓缩为三句话顶层只保留 Code 与 Work 两个表面Design 退化为 Code 工作台内按回合可选的任务模式每个 Design 任务通过DesignTaskProfile在首个被接受的回合原子锁定文档、介质、目标与样式快照形成不可变的 runtime 权威完整 Design 管线以CodeCanvasDesignSurface内嵌进 Code 右白板HTML 与 AI 图像作为两条互不静默降级的主输出通道。而对外呈现上的 Write→Work 改名只是一层不触碰write*协议、IPC、存储键与扩展 token 的本地化别名。对开发者而言理解 design-task-profile.ts 的契约、turn-service-design-admission.ts 的原子准入、useWorkbenchTaskSurface.ts 的任务状态机与 design-locked-profile.ts 的文档恢复链即可完整把握该功能的持久化语义与回放安全边界。赞分享人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载相关推荐OpCore-Simplify 完整指南如何快速自动生成可引导的 OpenCore EFIOpCore Simplify 完整指南如何快速自动生成可引导的 OpenCore EFI OpCore Simplify 是一个自动生成 OpenCore开发工具CLIKun Design 模式深度指南AI 设计工作台与设计→代码一体化闭环Kun Design 模式深度指南AI 设计工作台与设计→代码一体化闭环 Design mode设计模式是 Kun 桌面端 Code chat 工作台人工智能AI Agent自主智能体桌面应用MCP ClientsKun Design 模式实施蓝图在现有工作区架构上落地第三个顶层设计工作区Kun Design 模式实施蓝图在现有工作区架构上落地第三个顶层设计工作区 Kun 是一个 Local first 的 AI agent 工作区同一套运行人工智能AI Agent自主智能体桌面应用MCP Clients创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
