Files
msd-core/docs/zh-CN/how-to/configure-model-profiles.md
Tom Boucher 1adf6d2245 fix(#3620): point the docs at files that actually exist (#3658)
* fix(3620): point the docs at files that actually exist

docproof found 34 stale references; the reporter hand-read all 34 and reported the 8 that
are real, explaining why the other 26 are deliberate (files the documents themselves label
legacy or "superseded by", and one pre-Diataxis link label whose target still resolves).
Those 26 are left alone — re-touching them would contradict the issue's own analysis.

Every claim was re-verified against git ls-files at HEAD before editing.

docs/INVENTORY.md said its roster is anchored by six drift-control tests. Five are gone
(commands-doc-parity, agents-doc-parity, cli-modules-doc-parity, hooks-doc-parity in
5d8a8c4d; command-count-sync in fbf30792), so the sentence now names the one that exists.
Whether one test is sufficient coverage is a maintainer question the issue explicitly
declined to answer, so no new drift tests are proposed here.

The four translations were a revision further behind, each naming a seventh test deleted in
ae8bb707 that the English file had already dropped. All four now match.

Renamed targets corrected in CONTEXT.md, VERSIONING.md, docs/CONFIGURATION.md and the
update workflow. The new test names carry no issue-NNN- prefix, which is what
lint-regression-test-names requires, so they are the correct targets.

docs/TESTING-SUITES.md is the one that could cost somebody time: it INSTRUCTED contributors
to add an acknowledgment to the legacy drift-ack file, which CONTRIBUTING.md says to never
use. Rewritten from the real workflow — per-PR fragments under the drift-acks directory,
and a spent base-side ack is re-armed by rewording that fragment's reason in place, never
by adding a duplicate, since two sources naming one path is a hard error.

docs/skills/discovery-contract.md's heading named a query module deleted in 11918dcc. The
section was REMOVED rather than retargeted: its documented behavior (skip the deprecated
root) is not what the surviving code does — skill-manifest includes that root marked
deprecated:true — so retargeting would have documented something false.

Found and fixed inline, same class: VERSIONING.md described an SDK bundling step the
release workflow does not have (zero such mentions in that file); CONFIGURATION.md and four
translations named a dead model-catalog triple collapsed by ADR-457.

Dead config removed: the changeset lint's user-facing prefix list still carried two retired
sdk entries. git ls-files -- 'sdk/*' returns nothing. No test pins that array.

Left deliberately: the comment explaining the retired catalog path, the install regression
test that reconstructs the old broken layout to prove it fails, and the generated
test-timings cache. Each is a legitimate mention of a dead path, not drift.

Note lint-removed-but-needed cannot catch this class: it diffs baseRef...HEAD, so it only
sees files deleted in the change under review. These were orphaned by PRs that predate the
lint. A repo-wide existence audit would need a suppression mechanism for the 26 deliberate
mentions above; that is a feature, not part of this fix.

Fixes #3620

* chore(3620): backfill changeset PR number (#3658)

---------

Co-authored-by: sim <sim@local>
2026-08-19 01:54:01 -04:00

220 lines
7.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 如何配置模型配置文件
为您的项目选择合适的模型层级策略,然后在不编写大型覆盖块的情况下调整单个代理或整个阶段类型。本指南从最简单的控制选项开始,逐步介绍到动态路由。
---
## 四种配置文件(以及 `adaptive` 和 `inherit`)
在 `.planning/config.json` 中设置 `model_profile`,或通过 `/gsd-config --profile <name>` 设置:
| 配置文件 | 规划器 | 执行器 | 研究员 | 验证器 | 适用场景 |
|---------|---------|----------|-------------|----------|----------|
| `quality` | Opus | Opus | Opus | Sonnet | 对成本要求较低、注重生产质量的工作 |
| `balanced` | Opus | Sonnet | Sonnet | Sonnet | 常规开发——默认选项 |
| `budget` | Sonnet | Sonnet | Haiku | Haiku | 快速原型开发、成本敏感场景 |
| `adaptive` | Opus | Sonnet | Sonnet | Sonnet | 与其他层级在运行时感知配置文件下的解析方式相同;在频繁切换运行时环境时使用 |
| `inherit` | (会话模型) | (会话模型) | (会话模型) | (会话模型) | 非 Anthropic 提供商(OpenRouter、本地模型)——所有代理遵循当前会话模型 |
上表展示的是代表性子集。全部 33 个内置代理在 `gsd-core/bin/shared/model-catalog.json` 中均有明确的按配置文件层级分配。完整表格请参阅配置参考中的 [模型配置文件](../CONFIGURATION.md#model-profiles)。
**通过命令快速切换:**
```bash
/gsd-config --profile balanced # Normal development
/gsd-config --profile budget # Prototyping or high-cost phases
/gsd-config --profile quality # Production release
/gsd-config --profile inherit # OpenRouter, local models
```
**或直接编辑 `.planning/config.json`:**
```json
{
"model_profile": "balanced"
}
```
---
## 按代理覆盖(`model_overrides`)
如果某个代理需要不同的层级而不想更改整个配置文件,请使用 `model_overrides`:
```json
{
"model_profile": "balanced",
"model_overrides": {
"gsd-executor": "opus",
"gsd-codebase-mapper": "haiku"
}
}
```
有效值:`opus`、`sonnet`、`haiku`、`inherit`,或任何完全限定的模型 ID(例如 `"openai/o3"`、`"google/gemini-2.5-pro"`)。
`model_overrides` 可在 `.planning/config.json` 中按项目设置,也可在 `~/.gsd/defaults.json` 中全局设置。项目级条目在冲突时优先;不冲突的全局条目会被保留。
**关于 Codex 和 OpenCode 的重要说明:** 这些运行时会在安装时将解析后的模型嵌入每个代理的静态配置中。编辑 `model_overrides` 后,需重新运行安装程序使更改生效:
```bash
npx @opengsd/gsd-core@latest --codex --global # or --opencode, --kilo, etc.
```
---
## 按阶段类型设置模型(`models`)
如果您希望在不学习全部 33 个代理名称的情况下实现"规划阶段用 Opus、其余用 Sonnet"的效果,请使用 `models` 块。它将六种阶段类型映射到层级别名:
```json
{
"model_profile": "balanced",
"models": {
"planning": "opus",
"discuss": "opus",
"research": "sonnet",
"execution": "opus",
"verification": "sonnet",
"completion": "sonnet"
}
}
```
阶段类型及其对应的代理:
| 阶段类型 | 涵盖的代理 |
|---|---|
| `planning` | `gsd-planner`、`gsd-roadmapper`、`gsd-pattern-mapper` |
| `research` | `gsd-phase-researcher`、`gsd-project-researcher`、`gsd-research-synthesizer`、`gsd-codebase-mapper`、`gsd-ui-researcher` |
| `execution` | `gsd-executor`、`gsd-debugger`、`gsd-doc-writer` |
| `verification` | `gsd-verifier`、`gsd-plan-checker`、`gsd-integration-checker`、`gsd-nyquist-auditor`、`gsd-ui-checker`、`gsd-ui-auditor`、`gsd-doc-verifier`、`gsd-code-reviewer` |
| `discuss` | `gsd-assumptions-analyzer` |
| `completion` | 保留——目前无子代理;已被模式接受以备向后兼容 |
`models` 块仅接受层级别名(`opus`、`sonnet`、`haiku`、`inherit`)。如需使用完全限定的模型 ID,请改用按代理设置的 `model_overrides`。
**将 `models` 与按代理例外结合使用:**
```json
{
"model_profile": "balanced",
"models": {
"research": "sonnet"
},
"model_overrides": {
"gsd-codebase-mapper": "haiku"
}
}
```
全部五个研究代理解析为 `sonnet`,*除* `gsd-codebase-mapper` 被固定为 `haiku` 之外。
---
## 动态路由——默认使用低成本层级,失败时升级
如果您希望默认使用较低成本的层级,仅在代理未通过质量门控时才升级,请启用 `dynamic_routing`:
```json
{
"dynamic_routing": {
"enabled": true,
"tier_models": {
"light": "haiku",
"standard": "sonnet",
"heavy": "opus"
},
"escalate_on_failure": true,
"max_escalations": 1
}
}
```
每个代理都有一个默认层级(`light`、`standard` 或 `heavy`)。第一次尝试时,GSD Core 选择 `tier_models[default_tier]`。如果编排器检测到软失败(验证不确定、计划检查被标记等),则将代理提升一级重新启动。`max_escalations` 限制总重试次数。
已处于 `heavy` 层级的代理无法进一步升级。
**在保留动态解析的同时关闭升级:**
```json
{
"dynamic_routing": {
"enabled": true,
"escalate_on_failure": false
}
}
```
无论结果如何,每次尝试都使用 `tier_models[default_tier]`——适用于希望明确指定层级到模型的映射但不需要升级行为的场景。
`dynamic_routing` **默认禁用**。省略该块或设置 `enabled: false` 将保留静态解析。
---
## 在非 Anthropic 运行时上使用 GSD Core
如果您为 Codex、OpenCode、Gemini CLI 或 Kilo 安装了 GSD Core,安装程序已在您的配置中设置了 `resolve_model_ids: "omit"`。这告知 GSD Core 跳过 Anthropic 模型 ID 解析,让运行时选择其自己的默认模型。基本情况下无需手动设置。
**如果您希望在 Codex 上使用分层模型:**
```json
{
"runtime": "codex",
"model_profile": "balanced"
}
```
GSD Core 将每个层级别名解析为运行时层级映射中定义的 Codex 原生模型和推理力度。
**如果您希望在任意非 Claude 运行时上使用按代理模型 ID:**
```json
{
"resolve_model_ids": "omit",
"model_overrides": {
"gsd-planner": "o3",
"gsd-executor": "o4-mini",
"gsd-debugger": "o3"
}
}
```
有关完整的运行时感知配置文件参考及 `model_policy` 接口(v1.42 中新增的提供商中立预设),请参阅[配置参考——模型配置文件](../CONFIGURATION.md#model-profiles)。
---
## 解析优先级(从高到低)
当多个层级同时适用时,解析器选取优先级最高的条目:
```text
1. model_overrides[<agent>] — per-agent; full IDs; targeted exception
2. dynamic_routing.tier_models[<tier>] — when enabled; escalates on soft failure
3. models[<phase_type>] — coarse phase-level tier
4. model_profile (per-agent column) — global tier strategy
5. Runtime default — when nothing else applies
```
---
## 选择合适的控制选项
| 您的需求 | 使用 |
|---|---|
| 对所有代理采用统一的层级策略 | `model_profile` |
| 粗粒度的阶段级调整("规划阶段用 Opus") | `models.<phase_type>` |
| 按代理精细控制("强制代码库映射器使用 Haiku") | `model_overrides[<agent>]` |
| 为特定代理指定完全限定的模型 ID | `model_overrides[<agent>]: "openai/gpt-5"` |
| 默认低成本,仅在失败时升级 | `dynamic_routing` |
| 所有代理遵循会话模型(非 Anthropic 提供商) | `model_profile: "inherit"` |
---
## 相关文档
- [配置参考](../CONFIGURATION.md)
- [多代理编排](../explanation/multi-agent-orchestration.md)
- [命令参考](../COMMANDS.md)
- [文档索引](../README.md)