我才发现这些架构的“拆”与“合”哲学

GenUI SDK 项目 v1.2.0：架构师的"拆与合"哲学

如果 v1.1.0 是 GenUI SDK 在说"我能做什么"，那 v1.2.0 就是在回答"我该怎么做好"。这次更新背后藏着一套关于"拆与合"的技术哲学------拆的是包体积和思考模式，合的是 Agent 协作与流式更新。作为架构师，我看到的不只是新功能，而是设计取舍的智慧。

🧩 拆：子路径分包背后的架构取舍

从"大一统"到"模块化自治"

v1.1.0 时代的 @opentiny/genui-sdk-vue 是一个典型的"大一统"架构------所有功能打包在一起，入口只有一个。这种设计的好处是简单：install 一次，import 一次，全有了。但代价是沉重：你只用渲染器，却被迫扛着 Chat 和 ConfigProvider 的代码。

v1.2.0 的子路径分包导出 不只是"做了拆包"，而是做了一次架构层面的职责边界划分：

@opentiny/genui-sdk-vue           → 全量入口（默认，向后兼容）
@opentiny/genui-sdk-vue/chat      → 对话组件独立入口
@opentiny/genui-sdk-vue/renderer  → 渲染器独立入口
@opentiny/genui-sdk-vue/config-provider → 配置独立入口
@opentiny/genui-sdk-vue/transform-jsx   → JSX转换独立入口

这套设计有意思的地方在于：

1. 默认入口保留 ------不是粗暴拆完就没了，全量入口 @opentiny/genui-sdk-vue 仍然存在，老项目零改动升级
2. 子路径自治------每个子包有自己的依赖图，不会互相污染
3. 物料也跟着拆 ------内置 OpenTiny 物料从 @opentiny/vue 全量引入变成了 @opentiny/vue-button、@opentiny/vue-grid 等子包级按需引入

数据说话

renderer 场景下的实测数据：

指标	优化前	优化后
整体 bundle	14.67 MB	8.02 MB
SDK 占比	~3.04 MB（20.72%）	~506 KB（6.64%）
包体降幅	---	83%

83% 的降幅不是随便做做拆包就能达到的，这背后是对依赖图的精细梳理------哪些是 renderer 真正需要的，哪些是"顺带带上的"，全部重新审视了一遍。

🤝 合：A2A 智能体协作的设计哲学

从"单打独斗"到"团队作战"

GenUI Playground 之前是典型的单模型架构------一个模型包办一切，从理解意图到生成 UI 到执行操作。这在简单场景下没问题，但面对复杂业务就力不从心了：你让一个通用模型同时做客服、做数据分析、做代码审查，它哪样都做不精。

v1.2.0 引入了 A2A（Agent-to-Agent） 协议，把外部 AI 智能体注册为 Tool，与 MCP Tools、Skill Tools 一并注入对话。架构从"单模型包办"升级为"主 Agent 编排 + 领域 Agent 执行"的多智能体模式：

主 Agent（编排者）
  ├── MCP Tools（基础工具）
  ├── Skill Tools（技能包工具）
  └── A2A Agent（领域专家）
       ├── 客服 Agent
       ├── 数据分析 Agent
       └── 代码审查 Agent

这个设计的精妙之处在于统一工具层------不管你是 MCP 工具、Skill 还是外部 Agent，在对话里都是 Tool。主 Agent 不需要知道你是什么类型的 Tool，只需要知道你能做什么、什么时候该叫你。

当前状态与未来路线

当前 A2A 实现基于协议 v0.3.0，已支持完整的"主 Agent 编排 → 领域 Agent 执行 → 结果回写 Schema"链路。A2A 官方已发布 v1.0.0 稳定版，GenUI 团队正推进协议升级适配，预计下一版本完成切换。

作为架构师，我关注的是这个升级路径是否平滑。v0.3.0 → v1.0.0 的核心变化在 Agent Card 解析、调用约定和错误处理------这些是互操作性的关键。如果切换设计得当，对外部 Agent 的注册方式影响很小，只需要更新 Agent Card 格式即可。

🎭 拆：思考模式拆分------速度与深度的选择题

不是"要不要思考"，而是"什么时候思考"

v1.2.0 对支持 enable_thinking 的模型（如 DeepSeek-V4-Flash/Pro）做了模式拆分：

• {modelName} → No-Thinking 模式，thinking: { type: 'disabled' }，追求速度
• {modelName}-thinking → Thinking 模式，thinking: { type: 'enabled' }，追求深度

这个设计不是一个简单的开关，而是架构层面的场景适配：

• 简单 UI 生成 → No-Thinking，快出快回，用户体验流畅
• 复杂交互逻辑 → Thinking，深度推理，输出质量更高

开发者不再需要在"快但不稳"和"稳但慢"之间纠结------同一个模型，两种模式，按场景选择。

🔄 合：JSON Patch 流式更新------精妙的增量协议

RFC 6902 的引入不是偶然

v1.2.0 基于 RFC 6902 构建了完整的 JSON Patch Zod Schema。这不是随便选了个协议，而是有意为之：

RFC 6902 定义了一套标准的 JSON 文档操作指令（add、remove、replace、move、copy、test），每条操作都是原子性的。这跟流式更新的需求天然契合：

1. 增量传输------不需要每次传完整 JSON，只传 diff 操作
2. 原子性------每条操作要么成功要么失败，不会出现"半更新"状态
3. 可验证 ------test 操作可以在 apply 之前检查前置条件

对大模型输出的意义

之前大模型返回的是完整 schemaJson，每次更新都是全量替换。现在有了 JSON Patch，模型只需要返回 diff 操作，这意味着：

• Token 消耗降低------不再每次输出完整 JSON，只输出变化部分
• 更新更精确------RFC 6902 的操作指令比"重新写一遍"更稳定
• 流式体验更好------小的 diff 更快到达，UI 更新更及时

📦 Skill 渐进式披露------上下文管理的智慧

不是"全给你"，而是"你需要才给"

Skill（技能包）支持是 v1.2.0 Playground 的重要升级。最有意思的设计是渐进式披露：

• 系统提示词中只注入技能的名称与描述列表
• 当模型判断需要某技能时，通过 get_skill_content 按需拉取完整正文
• 避免一次性占满上下文窗口

这就像图书馆------书架上只放目录卡片，你需要哪本书才去取，而不是把所有书堆在桌面上。

文件夹 Skill 导入

支持导入完整 SKILL 目录（含 SKILL.md 与附属模块），导入后可在树形面板中浏览、编辑各文件。这让 Skill 从"单文件试验品"进化为"可组织的知识单元"。

🎨 模板体验：不是"能用"，而是"好用"

v1.2.0 专门打磨了模板的终端体验：

• 移动端优化------不是随便适配，而是针对性打磨
• 暗黑模式适配------不只是改颜色，是完整的视觉体验升级
• 历史导入导出------对话与模板均支持 JSON 格式的导入/导出，跨环境复现问题终于有解了

🏗️ 架构师视角总结

v1.2.0 的"拆与合"哲学：

维度	拆	合
包体积	子路径分包，83%降幅	默认入口保留，向后兼容
模型	思考/非思考模式拆分	同一模型两种能力统一入口
Agent	---	A2A协议，外部Agent注册为Tool
更新	---	JSON Patch原子操作合流式传输
Skill	---	渐进式披露，按需加载

拆 是为了让每个模块更轻、更专注；合是为了让系统更协调、更高效。好的架构不是一味地拆或一味地合，而是在合适的维度做合适的取舍。v1.2.0 在这一点上做得相当到位。

---

GenUI SDK 官网 ：opentiny.design/genui-sdk

GenUI SDK GitHub 仓库 ：github.com/opentiny/ge...（欢迎 Star ⭐）