人工智能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 开源仓库中「扩展面板与主 Agent 协调Extension–Agent Panel Coordination」这一设计主题在 Kun 将扩展 UI 收敛为views.rightSidebar侧边栏面板、并把主对话保留为唯一 Agent 操作面的背景下主 Kun Agent 与打开的扩展面板之间如何通过扩展注册的认证工具 workspace 作用域状态 有界项目变更事件完成项目编辑、状态同步与竞态防护而绝不共享渲染器内部状态或私有 IPC。读完本文你将掌握活动项目指针的读写约定、乐观修订optimistic revision的冲突拒绝语义、按 workspace 隔离 Host/工具/事件的实现要点以及只读轮询与破坏性取消的工具分类规则并能以仓库内置的 Kun Video Editor 为参照实现自己的协调型扩展。一、设计背景从聚合启动器到IDE 工具窗格模型Kun 在本次右侧边栏重设计之前扩展 UI 通过一个聚合启动器aggregate launcher混排多种占位模型扩展面板与主 Agent 之间缺乏清晰、可审计的协作通道。重设计的核心方向是把扩展 UI 收敛为类似 IDE 工具窗格的形态扩展声明一个views.rightSidebar视图与自己的图标Kun 在代码模式右侧垂直工具栏渲染该图标点击后在与主对话相邻的独立标签页中打开隔离视图详见 extension-right-sidebar-navigation 规格。在这个模型下主 Agent 与面板的协作遵循一条明确边界——extension-agent-panel-coordination 规格 原文规定扩展面板与主 Kun Agent 必须通过扩展的已认证、schema 校验通过的工具表面以及workspace 作用域的扩展状态进行协调Kun 不得将主渲染器 React 状态、会话对话 DOM、运行时凭据或私有 guest IPC 暴露为协调机制。这意味着协调契约由三部分组成缺一不可工具表面Tool Surface扩展注册的、声明了输入/输出 Schema 与副作用级别的工具工作区状态Workspace State存放在扩展 workspace 命名空间内的活动项目指针等状态有界事件Bounded Events项目变更后发布的可归属、有边界的 workspace 事件。对照 proposal.md 中的拒绝项可以看到设计团队曾评估过向每次提示注入面板状态的 renderer context-provider API方案最终因会扩大稳定提示面、加剧缓存抖动和跨层授权而否决改为显式工具调用因为工具调用是可审计且修订安全的。二、活动项目指针显式、workspace 作用域、绝不猜测协调的第一步是让主 Agent 知道面板当前打开的是哪个项目。规格要求支持 Agent–面板协调的扩展必须暴露一个用于解析活动面板资源的显式工具操作。该指针只能存储在扩展的 workspace 命名空间内使用前必须校验且必须返回显式的空或过期结果而不是猜测。2.1 指针的写入面板打开项目时记录当用户在面板中打开或创建项目扩展需将该项目记录为当前可信 workspace 的活动项目。在参考实现 kun-video-editor 中video-tools-project.ts的selectActiveProject通过context.storage.workspace.set(ACTIVE_PROJECT_KEY, ...)写入带schemaVersion: 1的指针记录并同时通过ui.postMessage发布kun-video-editor.project-changed消息见 video-tools-project.ts。该消息携带projectId、activeProjectId、previousProjectId、revision、generation、sequenceId、selectionGeneration、reason、transition、source等字段为后续面板刷新提供完整依据。2.2 指针的读取显式的空/过期结果video-project工具的active操作是读取路径。源码展示了三种显式结果video-tools-project.tsno-active-project存储中没有任何指针记录时返回绝不替用户随便挑一个项目stale-active-project已清除指针记录存在但 schema 版本不符、projectId 非法或项目已无法加载时扩展会先删除无效指针再返回过期结果active校验通过后返回当前项目的投影projection与currentRevision。这种显式结果优先于猜测的设计避免了 Agent 在指针失效时对不存在的项目盲目操作。三、乐观修订Agent 编辑的并发安全基础3.1 expectedRevision每次变更都声明预期修订规格中的两个场景定义了修订语义Agent 编辑面板的活动项目Agent 解析活动项目并用**其预期修订expected revision**调用受权的变更工具扩展通过面板使用的同一ProjectService提交修订并发布有界项目变更事件Agent 尝试过期编辑当 Agent 使用比面板当前项目修订更旧的修订调用变更时工具必须以当前修订拒绝该变更面板与 Agent 应能刷新而不做隐式合并。在参考实现中所有写型视频工具如video-update-timeline、video-probe、video-transcribe的输入 Schema 都要求projectId与expectedRevision整数、最小值 0参见 tool-contracts.ts。而 project-service.ts 的saveProjectWithReceipt会先assertExpectedRevision(current, expectedRevision)修订不符时抛出revision_conflict错误——绝不静默合并而是把expectedRevision与currentRevision一并返回给调用方让 Agent 重新读取后再决策。3.2 修订与选择代际generation双重校验除了项目修订参考实现还维护selection.generation与eventGeneration见 project-service.ts。updateSelection同时校验expectedRevision与expectedGeneration任一不符即抛出revision_conflict或 selection generation 冲突。这保证了 Agent 的操作不仅修订新鲜而且不会覆盖面板用户刚做出的选择变更。3.3 变更的可追溯性Mutation ReceiptsaveProjectWithReceipt中的 Receipt 是每次提交返回的变更凭据操作列表、逆操作、摘要、attribution 等Agent 每次编辑后必须消费该凭据并刷新标识符参考 agentProfiles.video-editor.instructions。这为可归属的 workspace 事件提供了数据基础——事件中的source字段可区分agent来源与手动来源。四、有界项目变更事件面板如何观察 Agent 发起的变更4.1 事件发布与刷新路径规格要求Agent 工具提交新修订后显示该项目的打开面板必须收到有界项目变更事件并重新加载该修订且不读取对话内容。参考实现的消息通道是kun-video-editor.project-changed主动画变更时同时发布active-project-changed。Webview 侧在 controller-effects.ts 订阅该通道收到事件后dispatch({ type: project-change, value: change })若事件针对当前面板项目或属于活动项目变更则调用loadProject(change.projectId)重新拉取权威状态。面板绝不会去读主对话的 DOM 或 React 状态。4.2 迟到的响应不得覆盖新选择加载代际generation规格强调活动项目变更具有权威性、可归属且竞态安全。实现上Webview 维护activeProjectResolutionGeneration与projectLoadGeneration等递增计数器每次active-project-changed事件都会使代际 1旧代际的迟到异步响应到达时会被丢弃无法把面板闪回到更早的项目选择。项目切换时还会释放旧媒体租约、清理或过滤旧项目的脚本、媒体、作业与产物规格 Project-scoped panel state never leaks across selections 的要求。4.3 面板中的同步状态展示参考实现用一个紧凑的 Agent-sync 面板替代了原先内嵌的第二个私有 Agent 对话界面见 app-timeline-panels.tsx展示当前活动项目名、r{currentRevision}修订徽标、最近一次同步的来源与修订以及aria-live的同步状态提示。它向用户传达主对话才是编辑入口这一设计立场而不是在面板内再造一个聊天室。五、Workspace 所有权隔离Host、工具与视图事件的三重隔离5.1 工具注册按 workspace 作用域键控规格要求workspace 作用域的扩展 Host 及其注册的 Agent 工具只能被激活它们的 workspace 发现与调用另一个 workspace 的激活失败或挂起不得复用第一个 workspace 的注册或存储。在 Kun 运行时工具注册以规范化 workspace 归属为键ExtensionToolRegistry使用scopedRegistrationKey(canonicalToolId, principal.workspaceRoots)管理注册同一规范工具 ID 在不同 workspace 作用域下可各自持有一份注册发现与调用都要求调用方的 workspace 与注册归属匹配registrationOwnsWorkspace、registrationForWorkspace不匹配时直接拒绝见 extension-tool-provider.ts。其测试用例discovers and invokes one independently registered handler per workspace覆盖了三个 workspace 场景验证 workspace C 无法看到 A/B 的注册见 extension-tool-provider.test.ts。5.2 视图事件按扩展身份 workspace 作用域双重路由ExtensionViewSessionService的publish逻辑先匹配extensionId再用viewSessionMatchesWorkspace/viewSessionMatchesWorkspaceKey匹配 workspace 作用域见 extension-view-session-service-core.ts。两个 workspace 各开一个视频面板时A 的 Host 发布项目变更只有 A 的 View Session 能收到B 完全不受影响。对应回归测试见 extension-view-session-service.test.ts其中明确断言 workspace B 的会话事件列表为空。5.3 激活失败必须 fail closed规格特别强调某 workspace 的 Host 无法激活时另一个 workspace 遗留的陈旧工具注册必须从该 Agent 的工具目录中缺席并在调用时被拒绝。这与可发现且仅可调用于激活它的 workspace的原则一致防止后台 Agent 会话或直接运行时工具执行跨越 workspace 边界design.md 决策 9 明确否决了保留单一全局 Host、仅在渲染器层隐藏工具的备选方案。六、只读轮询与破坏性取消分离审批模型的边界规格最后一条要求只读的渲染状态查询必须是独立的、无副作用的工具操作与渲染取消分开取消必须保留显式的副作用元数据与审批行为。参考实现的video-render-status工具声明sideEffects: read、idempotent: true而video-render-cancel声明sideEffects: destructive、idempotent: false见 tool-contracts.ts。同理还有video-analysis-statusread与video-analysis-canceldestructive、video-interchange-statusread与video-interchange-canceldestructive等成对工具。这样设计的直接收益是Agent 反复轮询导出进度时不会触发破坏性审批弹窗而一旦发起取消系统仍按完整副作用审批流程处理。规格原文对此的表述是轮询不应训练用户去批准破坏性权限。在 Agent 指令中也有对应约束导出时用只读的video-render-status轮询持久化作业仅在用户明确要求取消时才调用video-render-cancel见 contributions.json 中 agentProfiles 指令。七、参考实现全景Kun Video Editor 如何落地协调契约整个协调模型在仓库内置的 Kun Video Editorkun-examples.kun-video-editor中端到端落地可当作第三方扩展的范本7.1 清单侧声明视图、权限与 Agent Profilemetadata.json 声明views.rightSidebar的editor视图、storage.workspace、workspace.read/write、media.*、jobs.manage等最小权限集contributions.json 声明 26 个video-*工具及其allowedTools、budget并把主 Agent 编辑流程固化在agentProfiles.video-editor.instructions中——其要点正是本规格的落地先video-project解析活动项目、按expectedRevision读取/变更、把修订冲突视为刷新信号而非合并机会、用只读状态工具轮询。7.2 Host 侧工具分发与事件发布VideoEditorTools.register()遍历VIDEO_TOOL_DECLARATIONS逐个注册工具video-tools.tsinvoke按工具 ID 分发给video-tools-*.ts中对应的实现editor-request命令则是面板 Webview 走认证 RPC 调用的私有通道见 extension.ts。7.3 Webview 侧订阅有界事件、按代际加载面板通过controller-effects.ts订阅project-changed/active-project-changed/selection-changed/derived-changed等通道完成增量刷新配合代际计数防御竞态并在AgentSyncPanel中呈现同步状态见前述引用。7.4 事件的作用域校验与发布来源Host 发布事件统一走context.ui.postMessage最终由 Kun 运行时的 View Session 服务按扩展身份 workspace 作用域路由见第五节。source: agent | manual归属字段让面板可以区分Agent 改的与用户自己改的这也是规格要求的可归属attributable语义。八、给扩展作者的协调契约清单对照规格与参考实现编写一个支持 Agent–面板协调的views.rightSidebar扩展时需要满足以下可验证条件协调通道只走工具 workspace 状态 有界事件不请求访问主渲染器 React 状态、对话 DOM、运行时凭据或私有 guest IPCmanifest 中不声明超出需要的权限参考实现仅声明storage.workspace与workspace.read/write等。提供显式的活动资源解析工具无活动项目时返回no-active-project之类显式结果指针过期时返回stale-*结果并清理绝不随意选一个项目代替用户决策。所有写型工具强制expectedRevision校验冲突时返回当前修订并拒绝明确提示刷新而非合并面板与 Agent 均从权威ProjectService读取。变更后发布有界、可归属的项目事件事件包含项目 ID、修订、代际与来源打开的面板订阅事件并从权威状态刷新而不是读取对话内容。按 workspace 隔离 Host、工具与视图事件注册、发现、调用、事件路由均以规范化 workspace 作用域为键激活失败 fail closed。把只读查询与破坏性操作拆成不同工具轮询用sideEffects: read的工具取消用sideEffects: destructive的工具并保留审批。九、验证与测试依据本规格对应的实现与回归测试在仓库中均可复现工具作用域隔离extension-tool-provider.test.ts多 workspace 独立注册/调用视图事件隔离extension-view-session-service.test.ts按 workspace 路由消息、按 workspace 撤销会话修订冲突语义project-service.test.ts 与 video-tools.test.ts面板事件订阅与竞态webview-controller-projects.tsx 与 webview-controller.test.tsx整体迁移与验证任务清单见 tasks.md全部勾选完成覆盖活动项目指针权威化、事件路由隔离、只读/破坏性工具拆分等条目。这套工具 workspace 状态 有界事件的协调模型为 Kun 生态中的扩展同时提供了可审计性、并发安全与多工作区隔离主 Agent 与扩展面板共享同一份 workspace 作用域的项目事实却互不窥探对方的内部实现——这正是 IDE 工具窗格式扩展协作的正确打开方式。赞分享人工智能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 PPT基于 Kun 扩展 API v1 的人机协作演示文稿工作区实现解析Kun PPT基于 Kun 扩展 API v1 的人机协作演示文稿工作区实现解析 Kun 已经能够通过受管的 PPT Master 工作流生成原生 PPTX人工智能AI Agent自主智能体桌面应用MCP ClientsGopeed项目浏览器扩展与桌面端协同工作机制解析Gopeed项目浏览器扩展与桌面端协同工作机制解析 Gopeed作为一款优秀的下载管理工具其浏览器扩展与桌面客户端的协同工作能力一直是开发者关注的重点。近期有网络CLI后端Kun 扩展平台架构与边界单 Agent Runtime 之上的安全扩展模型Kun 扩展平台架构与边界单 Agent Runtime 之上的安全扩展模型 本文以 docs/extensions/architecture.md http人工智能AI Agent自主智能体桌面应用MCP Clients创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考