Ziya
2565133af3
implemented（除 4 篇超长文档随后补）、proposed、rejected 全树配对； 同一流水线 + 二遍校验（paraphrase-back + 仓库上下文一致性）产出。 docs/rfc/implemented/AGENTS.md 与其 CLAUDE.md 符号链接列入排除 （agent 指令文件，与根 AGENTS.md 同策略）。
24 lines
1.7 KiB
Markdown
24 lines
1.7 KiB
Markdown
# RFC：使用自定义类型化工具 schema DSL 替代 schemastery
|
|
|
|
Status: implemented
|
|
|
|
[English](2026-06-11-custom-schema-dsl.md) | 中文
|
|
|
|
## 问题
|
|
|
|
工具参数必须以标准 JSON Schema 的形式传递给模型，同时让工具作者在 `execute(args)` 中获得类型推导而无需类型断言。schemastery 已用于插件配置，但工具作者 API 需要的是逐属性的 `required: true` 布尔值，而非 JSON Schema 的独立 `required` 数组。
|
|
|
|
## 决策
|
|
|
|
在 dsh-tools 中实现一个小型自定义 DSL：`SchemaSpec`（逐属性规格，带 `required: true` 布尔值）；类型层面的 `InferArgs<S>` 将规格映射为参数类型（required 键为必选，其余通过 `?` 真正可选）；运行时的 `schemaSpecToJsonSchema()` 转换器；以及将它们串联起来的 `defineTool()`。`ToolRegistry.register()` 仍接受原始 JSON Schema 的 `ToolDefinition`——MCP 来源的工具就是这样注册的。
|
|
|
|
## 曾考虑的替代方案
|
|
|
|
**schemastery**（已 vendor、用于插件 Config）经评估后被否决：它面向的是基于 StandardSchema 的校验/转换，而非 JSON Schema *生成*，因此会增加间接层却无法干净地产出协议格式（wire format）。
|
|
|
|
## 后果
|
|
|
|
- 第一方工具作者获得零类型断言的类型化参数；类型体操的成本留在核心包内部（符合 AGENTS.md 的类型安全策略）。
|
|
- DSL 刻意保持小巧（string/number/boolean/object/array、enum、default、嵌套 properties/items）。相对完整 JSON Schema 的缺口（union、format、约束）在真实工具提出需求之前暂不填补。
|
|
- `InferArgs` 映射在一次早期可选性 bug 之后已有类型层面的回归测试。
|