人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载本篇文章围绕 gsd-2 项目的模型路由设计展开系统讲解为什么要按任务类型分级选择模型、如何在真实项目中实现能力感知的路由以及如何度量路由带来的成本收益。读完你可以掌握一套可直接落地的成本-质量权衡框架从任务分类、模型分级、能力档案评分到 budget pressure 与 verbose 观测的完整闭环。核心洞察质量需求随任务变化模型却一成不变绝大多数 Agent 系统存在一个结构性的浪费不同任务的质量要求差异极大但系统对所有任务使用同一个模型。一次架构评审出错错误会级联传导到下游每一个子任务产生数倍于任务本身的返工成本一个文档更新或样板代码生成出错修正成本微乎其微。用一个最强的模型处理全部任务等价于用旗舰机型完成所有日常琐事用一个最便宜的模型处理全部任务则会在需要深度推理的关键节点反复烧掉迭代次数。两者都不是最优解。正确的做法是按任务类型对模型分层调度——让最强的模型只出现在错误代价最高的环节让足够胜任的模型处理常规工作让最小最快的模型处理可预测、低推理深度的任务。最优模型路由策略任务类型 → 模型层级对照表gsd-2 的开发文档中多套模型building-coding-agents 系列对路由策略达成了一致结论。其核心映射关系如下任务类型模型层级理由规划、架构、评审Frontier始终使用规划错误会级联传导到所有下游任务歧义消解Frontier错误解读 浪费整个执行过程定义清晰的实现CRUD、标准 UI、工具类中层级 / 能力足够但更便宜任务定义明确模式已经建立代码评审、测试生成中层级依据已知标准做评估而非生成全新方案摘要任务记录、manifest 更新最轻的可行模型需要语言能力推理深度要求极低样板代码小型/快速模型输出可预测推理需求低这条规则的本质是把模型能力与错误成本对齐错误代价高的任务规划、架构、歧义消解永远走最强模型错误代价低的任务摘要、样板代码用最便宜的模型即可。中段任务实现、评审、测试则使用能力足够的中层级模型。非显而易见的成本优化减少浪费的 Token 比降低 Token 单价更有杠杆在预算优化的优先级上原文档给出了一个常被忽略的关键洞察减少浪费的 Token 比降低 Token 单价更有杠杆。一个臃肿的上下文窗口在每一次调用上都会产生成本。从上下文组装中裁剪掉 500 个不必要的 Token在整个项目周期内节省的成本高于切换到便宜 10% 的模型。这个结论的理由很直接模型单价是一次性谈判的常量而上下文体积是每一次调用都要付费的变量。一次调用省 500 Token 看似微小但乘上项目生命周期内的调用次数其收益会被放大成百上千倍。因此成本优化应遵循两个方向并行控制上下文体积裁剪冗余内容、压缩历史、精简提示词组装按任务路由模型让每一次调用都恰好使用够用的模型而不是清一色用旗舰。gsd-2 仓库对此有专门的工程化支撑src/resources/extensions/gsd/context-budget.ts、prompt-cache-optimizer.ts等模块负责上下文裁剪与提示词优化而路由侧的实现则由能力感知的模型选择承担。GSD 中的落地实现能力感知模型路由gsd-2 将上述策略实现在扩展目录 src/resources/extensions/gsd/model-router.ts 中并经历了从复杂度分层到能力感知的演进设计决策见 ADR-004-capability-aware-model-routing用户手册见 dynamic-model-routing。早期路由器是一维的复杂度分层路由按复杂度把任务归入 light / standard / heavy 三档再在档内选最便宜模型。这在同档模型可互换的假设下成立但当用户配置异构 Provider 池Claude 强在架构与全新实现、Codex 强在调试与根因分析、Gemini 强在长上下文综合与研究型任务、小模型强在廉价验证与轻量 hook时同档内不同模型的差异就无法表达了。能力感知路由正是为了解决这一缺口而设计。两阶段路由管线每个由 auto-mode 派发的单元都要经过两级选择阶段一复杂度分类——决定任务的档位light / standard / heavy阶段二能力评分——在档位内按任务需求 × 模型能力的匹配度对候选模型排序选优。整条管线的关键不变量是downgrade-only 语义用户配置的模型永远是天花板路由只允许向下降级绝不向上超出用户的配置。实际解析流程在resolveModelForComplexity()中严格按序执行unit dispatch → classifyUnitComplexity(unitType, unitId, basePath, budgetPct) [复杂度分类单位类型默认档位 → 元数据分析 → 自适应调整 → 预算压力] → resolveModelForComplexity(classification, phaseConfig, routingConfig, availableModelIds) → STEP 1: 过滤出该档位可用的模型从用户天花板向下仅降级 → STEP 2: 若启用能力路由且候选多于 1 个 → computeTaskRequirements(unitType, taskMetadata) 动态任务需求向量 → scoreEligibleModels(eligible, requirements) 对候选模型评分 → 选择最高分模型2 分以内按成本决胜成本相同按 ID 字典序 → STEP 3: 组装 fallback 链 → resolveModelId() → pi.setModel()七维能力档案每个模型都有一份 0–100 的能力档案覆盖七个维度MODEL_CAPABILITY_PROFILESinterface ModelCapabilities { coding: number; // 全新实现、代码生成 debugging: number; // 根因分析、错误诊断、重构 research: number; // 信息综合、调查、探索 reasoning: number; // 多步逻辑、规划、架构 speed: number; // 响应延迟思考时间的倒数 longContext: number; // 大输入窗口的有效利用 instruction: number; // 指令遵循、结构化输出遵从 }要点如下没有 costEfficiency 维度。成本不作为评分维度参与而是作为约束条件在预算压力与档位经济性中单独处理无档案模型默认均匀 50 分。这使能力评分对这类模型退化为空操作回退到档内最便宜的旧行为实现优雅降级——不配置异构池的用户行为零变化档案是启发式排序不是基准测试结果。仓库中明确注释了这一点并允许用户通过modelOverrides覆盖。内置档案覆盖 Claude 4.6/4.7 家族、OpenAI GPT-4.x 与 GPT-5.x 系列、o 系列推理模型o1 / o3 / o4-mini 等、Gemini 2.0/2.5 以及 deepseek-chat。例如const MODEL_CAPABILITY_PROFILES: Recordstring, ModelCapabilities { claude-opus-4-6: { coding: 95, debugging: 90, research: 85, reasoning: 95, speed: 30, longContext: 80, instruction: 90 }, claude-sonnet-4-6: { coding: 85, debugging: 80, research: 75, reasoning: 80, speed: 60, longContext: 75, instruction: 85 }, claude-haiku-4-5: { coding: 60, debugging: 50, research: 45, reasoning: 50, speed: 95, longContext: 50, instruction: 75 }, gpt-4o-mini: { coding: 55, debugging: 45, research: 40, reasoning: 45, speed: 90, longContext: 45, instruction: 70 }, gemini-2.5-pro: { coding: 75, debugging: 70, research: 85, reasoning: 75, speed: 55, longContext: 90, instruction: 75 }, deepseek-chat: { coding: 75, debugging: 65, research: 55, reasoning: 70, speed: 70, longContext: 55, instruction: 65 }, };注意同一家族内 speed 与推理深度的反比关系opus 系 speed 只有 30haiku 系则高达 95——这正是轻任务用小模型、重任务用大模型的数据化表达。动态任务需求向量任务需求不是静态查表而是由(unitType, TaskMetadata)动态计算从而保留复杂度分类器已捕捉的细微差别。各单元类型的基础需求向量BASE_REQUIREMENTSconst BASE_REQUIREMENTS: Recordstring, PartialRecordkeyof ModelCapabilities, number { execute-task: { coding: 0.9, instruction: 0.7, speed: 0.3 }, research-milestone: { research: 0.9, longContext: 0.7, reasoning: 0.5 }, research-slice: { research: 0.9, longContext: 0.7, reasoning: 0.5 }, plan-milestone: { reasoning: 0.9, coding: 0.5 }, plan-slice: { reasoning: 0.9, coding: 0.5 }, replan-slice: { reasoning: 0.9, debugging: 0.6, coding: 0.5 }, reassess-roadmap: { reasoning: 0.9, research: 0.5 }, complete-slice: { instruction: 0.8, speed: 0.7 }, run-uat: { instruction: 0.7, speed: 0.8 }, discuss-milestone: { reasoning: 0.6, instruction: 0.7 }, complete-milestone: { instruction: 0.8, reasoning: 0.5 }, };对照上文的路由策略表可以看到完整映射规划类plan-、reassess-roadmap重点押在 reasoning 上对应Frontier 始终研究类research-押在 research longContext执行类execute-task押在 coding instruction摘要与收尾类complete-slice、run-uat、complete-milestone押在 instruction speed——对应最轻的可行模型。computeTaskRequirements()还会对execute-task结合任务元数据进一步细化src/resources/extensions/gsd/model-router.ts文档/配置/重命名类任务tags 命中docs|readme|comment|config|typo|rename→ 提高 instruction、降低 coding调试类关键词concurrency、compatibility→ 提高 debugging 与 reasoning迁移/架构类关键词migration、architecture→ 提高 reasoning 与 coding大文件任务fileCount ≥ 6 或 estimatedLines ≥ 500→ 提高 coding 与 reasoning。评分函数与决胜规则评分是加权平均scoreModel()model-router.tsscore Σ(weight × capability) / Σ(weights)function scoreModel( model: ModelCapabilities, requirements: PartialRecordkeyof ModelCapabilities, number, ): number { let weightedSum 0; let weightSum 0; for (const [dim, weight] of Object.entries(requirements)) { const capability model[dim as keyof ModelCapabilities] ?? 50; weightedSum weight * capability; weightSum weight; } return weightSum 0 ? weightedSum / weightSum : 50; }评分输出在 0–100 之间可直接横向比较。决胜规则scoreEligibleModels()是按评分降序排列若两个模型评分差≤ 2 分取更便宜的按MODEL_COST_PER_1K_INPUT内置成本表若成本相同按模型 ID 字典序决胜保证确定性。2 分阈值是关键设计它防止微不足道的评分差异推翻成本优化避免看起来精确实则启发式的分数产生误判。配置实践如何在项目中启用并按需调整动态路由默认关闭在 preferences 中开启详见 dynamic-model-routing--- version: 1 dynamic_routing: enabled: true ---完整配置项dynamic_routing: enabled: true tier_models: # 显式指定每档模型可选 light: claude-haiku-4-5 standard: claude-sonnet-4-6 heavy: claude-opus-4-6 escalate_on_failure: true # 任务失败时升档重试默认 true budget_pressure: true # 接近预算上限时自动降档默认 true cross_provider: true # 允许跨 Provider 选模型默认 true hooks: true # 对 post-unit hooks 也应用路由默认 true capability_routing: true # 档内启用能力评分默认 true allow_flat_rate_providers: false # 对包月订阅 Provider 启用路由默认 false关键配置项的行为说明tier_models为每档显式锁定模型。未配置时使用内置能力映射自动选择Lightclaude-haiku-4-5、gpt-4o-mini、gpt-4.1-mini、gemini-2.0-flash 等Standardclaude-sonnet-4-6、gpt-4o、gpt-4.1、gemini-2.5-pro、deepseek-chat 等Heavyclaude-opus-4-6、gpt-5、gpt-5-pro、o1、o3、o4-mini 等。escalate_on_failure任务在某档失败后重试时升档Light → Standard → Heavy。防止便宜模型在需要深度推理的任务上白白消耗重试次数。budget_pressure接近预算上限时渐进降档。实现位于 complexity-classifier.ts 的applyBudgetPressure()阈值如下预算使用率效果 50%不调整50–75%Standard → Light75–90%更激进的降档 90%几乎所有任务 → Light仅 Heavy 保持 Standardallow_flat_rate_providers默认情况下当活跃 Provider 是包月订阅claude-code、GitHub Copilot、外部 CLI Provider时动态路由被抑制因为每次请求成本相同、降档只会降低质量。设为true可以在单个订阅的 Token 预算内做智能按任务选择例如研究用 haiku、架构用 opus此时建议同时关闭cross_provider避免路由器逃逸到未配置的 Provider。覆盖能力档案如果你对某个模型的实际表现有更好的判断可通过modelOverrides深合并覆盖内置档案只覆盖指定维度{ providers: { anthropic: { modelOverrides: { claude-sonnet-4-6: { capabilities: { debugging: 90, research: 85 } } } } } }覆盖是部分深合并未指定的维度保留内置值。这为模型家族演进、内置档案过期提供了立即生效的逃生通道而无需等待 GSD 发版。观测与调试让每次路由决策都可解释每次路由决策都可通过 verbose 模式检查。当能力评分为胜出者时日志包含完整评分明细Dynamic routing [S]: claude-sonnet-4-6 (capability-scored) — claude-sonnet-4-6: 82.3, gpt-4o: 78.1, deepseek-chat: 72.0当为纯档位路由时评分被禁用、只有一个候选、或路由守卫生效Dynamic routing [S]: claude-sonnet-4-6 (standard complexity, multiple steps)RoutingDecision中的selectionMethod字段capability-scored | tier-only明确标识走的是哪条路径capabilityScores记录每个候选模型的得分taskRequirements记录实际使用的需求向量wasDowngraded标记是否发生了降级。管线各步骤的执行顺序也被显式保证复杂度分类决定档位预算压力可能降低档位按档位过滤候选模型仅从用户天花板向下能力评分对候选集排序评分 2 分以内按成本决胜。因此当用户看到预算压力导致高评分模型未被选中时reason 字符串中会包含budget pressure: 85%之类的明确说明管线顺序先于评分运行不存在逻辑冲突。测量追踪每次成功任务的成本而非每次任务的成本路由是否真正省钱取决于你如何度量。原文档给出的测量原则是追踪 cost-per-successful-task每次成功任务的成本而不是 cost-per-task每次任务的成本。如果便宜的模型需要两倍的迭代次数才能完成任务它实际上并不更便宜——省下的单价被加倍的重试次数吞掉了。这一原则在 gsd-2 中有对应的工程机制自适应学习路由历史.gsd/routing-history.json按档位、按单元类型记录成功/失败。某档失败率超过 20% 时后续同类任务自动升档用户反馈over / under / ok的权重是自动结果的 2 倍详见 routing-history.ts 与 complexity-classifier.ts 中的getAdaptiveTierAdjustment()。这正是便宜模型若反复失败就应升档的自动化版本失败升档escalate_on_failure保证重试时进入更高档位避免廉价模型在重试上烧钱成本表对比内置的MODEL_COST_PER_1K_INPUT成本表model-router.ts用于跨 Provider 的成本对比与决胜实际计费仍以 Provider 为准。原文档同时引述了行业数据Grok 在编排层执行路由时报告了 60–70% 的成本降低且零质量损失。该数字来自文档中转述的第三方报告作为行业参考而非本项目实测在 gsd-2 的官方文档中动态路由自身的收益表述是在封顶套餐上减少 20–50% 的 Token 消耗且不牺牲关键环节的质量dynamic-model-routing。测试验证评分逻辑的正确性由单测保障能力路由不是黑盒。仓库在 tests/capability-router.test.ts 中对核心函数做了系统性单测覆盖scoreModel单维加权、双维加权、空需求向量返回 50、未知维度按 50 兜底computeTaskRequirements无元数据的 execute-task 返回基础向量、docs/readme 标签调整、concurrency/compatibility 关键词提升 debugging、migration/architecture 关键词提升 reasoning、fileCount ≥ 6 或 estimatedLines ≥ 500 触发大任务提升、未知单元类型回退到{ reasoning: 0.5 }MODEL_CAPABILITY_PROFILES所有已映射档位的模型都必须有档案且七个维度齐全、取值均在 0–100 范围内。这些测试保证了加权平均公式正确、元数据细化行为稳定、档案数据表完整这三条底线也印证了 ADR-004 中评分函数是适合确定性单测的纯函数的设计判断。边界与注意事项落地这套策略时需要注意几个边界档案是启发式不是基准内置能力分数表达的是模型间的相对强弱不是实测基准。模型家族快速演进时档案会漂移应通过modelOverrides修正并关注仓库对档案表完整性的 lint 约束未知模型默认均匀 50 分自定义 Provider、本地模型或厂商别名若不在内置档案中会以 50 分参与竞争按档内成本排序。如需让路由理解这些模型请用modelOverrides补充档案2 分决胜阈值只有当评分差异超过 2 分时才让更强胜出否则交给成本与确定性 ID 决胜——防止启发式分数过度覆盖成本优化降级语义是硬约束无论评分如何路由都不会升到用户配置的模型之上这是用户控制权不可被路由绕过的底线。从任务类型 → 模型层级的策略表到复杂度分类 能力评分的两阶段管线再到 cost-per-successful-task 的度量原则这套成本-质量权衡框架已经完整沉淀在 gsd-2 的源码、文档与测试之中可直接作为同类 Agent 系统路由设计的参照实现。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐GSD 模型配置Model Profiles指南为每个 GSD 代理精确分配 Claude 模型平衡质量与 Token 消耗GSD 模型配置Model Profiles指南为每个 GSD 代理精确分配 Claude 模型平衡质量与 Token 消耗 导读get shit d人工智能AI 应用提示工程开发工具工作流自动化AI AgentGSD-2 能力感知模型路由ADR-004从复杂度分层到任务需求 × 模型能力的双维调度GSD 2 能力感知模型路由ADR 004从复杂度分层到任务需求 × 模型能力的双维调度 导读 GSD 2 的自动模式auto mode原本依赖人工智能AI Agent代码智能体Agent 编排CLIAI 应用Whisper模型量化工具CompressTables与权重压缩实践Whisper模型量化工具CompressTables与权重压缩实践 引言模型压缩的必要性与挑战 在深度学习模型部署过程中尤其是在资源受限的环境如边缘设人工智能语音音频本地部署桌面应用上一篇如何快速掌握Async/AwaitECMAScript异步编程的完整入门教程下一篇ComfyUI-WanVideoWrapper多模型协作Lynx与LongCat-Video融合教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考