🧩 拆：子方法分包背后的架构取舍

从“ 大一统 ”到“ 模块化自治 ”

使用者痛点：一次性引入整个 SDK，导致 bundle 体积膨胀、加载慢、Tree‑shaking 失效。

v1 时代的 @opentiny/genui-sdk-vue 是典型的“大一统”架构——所有功能打包在一起，入口只有一个。至于好处是简单，install 一次import 一次全有了。说到但代价是沉重，只想用渲染器。却被迫携带 Chat、ConfigProvider 等代码。

v1 的子方法分包导出不仅是“拆包”，更是一次职责边界划分

• @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. 默认入口保留：全量入口仍然存在老项目零改动升级。
2. 子方法自治：每个子包拥有独立依赖图，不会相互污染。
3. 物料也跟着拆：内置 OpenTiny 物料从全量引入变为 @opentiny/vue-button,@opentiny/vue-grid 等按需子包。

数据说话 —— Renderer 场景实测数据

指标	调整前	调整后
整体 bundle 大小	14 MB	8 MB
SDK 占比/
% 的降幅不是随便拆包就能达到的。这背后是对依赖图的精细梳理——哪些是 renderer 真正需要的，哪些是“顺带带上”的，都重新审视了一遍。

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

从“单打独斗”到“团队作战”

使用者痛点：单模型承担所有业务时响应迟缓、推理质量不稳定、难以 新能力。

GenUI Playground 之前采用单模型架构 - 一个模型负责意图理解、UI 生成、操作执行。场景复杂时力不从心：让同一个通用模型同时做客服、数据分析、代码审查，它哪样都做不好。

A2A协议 - 把外部 AI 智能体注册为 Tool，与 MCP Tools、Skill Tools 并列注入对话。程序从“单模型包办”升级为 “主 Agent 编排 + 领域 Agent 执行” 的多智能体模式：

├── MCP Tools
├── Skill Tools
└── A2A Agent
├── 客服 Agent
├── 数据分析 Agent
└── 代码审查 Agent

This design’s brilliance lies in a : regardless of being an MCP tool。a skill or an external agent,it is treated as a Tool in dialogue. The master Agent only needs to know *what* a Tool can do and *when* to invoke it.

当前状态与未来路线

A2A 当前基于协议 v0，实现了完整的 “主 Agent 编排 → 领域 Agent 执行 → 结果回写 Schema” 链路。怎么说呢，官方已发布 v1 稳定版。GenUI 正在推进协议升级，预计下一个版本完成切换。

User Pain Point: 升级过程是否会破坏已有集成？答案在于A2A Card 格式的向后兼容性设计。

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

不是 “要不要思考”。而是 “什么时候思考”

User Pain Point: 开发者常在 “快但不稳” 与 “稳但慢” 间犹豫，需要手动切换模型或维护两套代码。其实，

enable_thinking 的模型提供了模式拆分：

• {modelName} → No‑Thinking 模式。{ thinking: { type: 'disabled' } },追求速度。
• {modelName}-thinking → Thinking 模式。{ thinking: { type: 'enabled' } },追求深度推理。

This isn’t a simple toggle—it's an architectural scene adaptation :

• Simpler UI generation → No‑Thinking .
• C​omplex interaction logic → Thinking .

The developer now picks mode per scenario instead of juggling trade‑offs.

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

RFC 的引入不是偶然

User Pain Point: 全量 JSON 返回导致 token 消耗大、网络抖动、前端渲染卡顿。

RFC 6902 实现完整的 JSON Patch Zod Schema。这不是随意选协议，而是有意为之：

1. 增量传输 :仅发送 diff 而非完整文档，降低网络开销。
2. 原子性 :每条指令要么成功要么失败，避免半更新状态。
3. 可验证 :"test") 操作可在 apply 前检查前置条件，提高安全性。老实说，

对大模型输出的意义

• Token 消耗降低 :只返回变化部分。而非每次完整 JSON，
• 更新更精确 :RFC 操作比整段替换更稳健。
• 流式体验更好 :小 diff 更快抵达前端，实现即时 UI 更新。

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

不是 “全给你”。而是 “你需要才给”

User Pain Point: 一次性注入全部 Skill 内容会占满 LLM，使主要业务信息被淹没。

The v1 Playground introduces a progressive disclosure mechanism for Skills:

• The system prompt only injects skill Name & Description List.If model decides a skill is needed,it calls to fetch full body on demand.
• This prevents context overflow and keeps prompts focused.
- Analogy: Library catalog cards vs. pulling every book onto your desk.

Supports importing an entire SKILL directory . After import you can browse and edit each file via a tree panel—elevating Skills from single-file experiments to organized knowledge units.

- 🎨模板体验 : 不仅 能 用。更 好 用

li>: not just responsive but fine-tuned for touch gestures. li>: complete visual overhaul rar than simple color swaps. li>: both dialogs and templates support JSON import/export—solving cross‑environment reproducibility.

User Pain Point:

- 🏗️ 架构师视角

维度	拆	& 合
	实现 ~30% 包体降幅。	+ A2A 协议 + JSON Patch + 渐进 Skill + 多模态模型等组合，实现程序协同高效。
	No‑Thinking vs Thinking 两种能力，同一模型按场景切换。
	Main Agent + Domain Agents，统一 Tool 接口。
	增量流式传输。
	按需加载避免上下文爆炸。

---