很多设计工具一谈组件，就会变成素材库或模型下载站。

但对 agent harness 来说，组件库首先不是展示给人挑选的图库，而是机器可读的 placement contract。Agent 需要知道一个对象如何被理解、放置、验证和引用。

这就是 Semantic Component Registry 的价值。

.skp 文件本身不够

一个 SketchUp component 文件可以包含几何，但 agent 还需要更多信息：

  • 它是什么类别；
  • 尺寸是多少；
  • bounds 如何计算；
  • 插入点在哪里；
  • 哪些 anchor 要贴墙或落地；
  • 前后左右 clearance 是多少；
  • 允许哪些 placement rules；
  • asset path 和 fallback 是什么；
  • 来源和授权信息是什么；
  • 用户可能用哪些中英文别名来搜索它。

如果没有这些 metadata，agent 只能“找一个模型”。它不能可靠地决定怎么放、放到哪里、是否越界、是否与空间规则冲突。

Component registry 是 reasoning contract

SAH 的组件 registry 目标是让 agent 通过 machine-readable manifest 做 reasoning。

例如，当用户说“把镜子放在洗手台上方”，agent 不能只搜索“mirror”。它需要知道 mirror 的尺寸和 bounds、vanity 或 sink 的位置、相对关系、是否应该继承 wall provenance、放置结果是否进入 design_model.json、SketchUp bridge 执行后返回哪个 entity id。

这不是素材检索问题，而是语义定位问题。

Project-local components 很关键

产品可以带一个 seed library，但设计师项目会有自己的本地组件。

SAH 支持 project-local component_library.json，并通过 assets.lock.json 记录项目实际使用的组件和资产引用。这解决两个问题：

  • 项目可以复现自己实际用过哪些组件；
  • 产品不需要一开始就构建大型公共资产市场。

项目局部组件可以来自本地 .skp、SketchUp 当前选中对象、外部下载模型或手工注册 metadata。但无论来源是什么，进入 agent 工作流前都应该补齐语义字段。

.skp 几何只是资产。Manifest 才是 agent 能理解的 contract。

Asset lock 是可复现性的边界

assets.lock.json 不应该记录整个组件库。它应该记录当前项目实际引用的组件。

这让项目知道哪个 component id 被哪些 instances 使用、本地 cache path 是什么、source 和 license metadata 是什么、procedural fallback 是否存在、asset 当前只是 referenced 还是 cached。

这和软件依赖 lockfile 的思想类似：项目需要知道自己实际依赖了什么，而不是假设未来 registry 一直可用。

Procedural fallback 是早期产品能力

在早期阶段，真实 .skp asset 可能还不完整。SAH 支持 procedural fallback，让 bridge 可以用尺寸创建 box-like placeholder。

这不是最终视觉质量方案，但它对 vertical slice 很重要：component search 可以先跑通，placement 和 clearance 可以验证，bridge execution 可以返回 entity ids，asset pipeline 可以逐步完善。

这也是开发者应该关注的 tradeoff：先建立语义和执行闭环，再逐步丰富资产。

License 和 provenance 是架构字段

组件不是只有几何。设计软件里，来源和授权也会影响产品能力。

如果 agent 帮用户使用外部模型，它需要能记录 source、license、redistribution 和 cache 状态。否则后续发布、共享、迁移或商业使用都会变得不清楚。

所以 provenance 不应该只是 README 里的说明，而应该进入 component metadata 和 asset lock。

Source trace