配置驱动架构
Config-Driven Architecture
通过YAML配置文件统一管理系统行为，支持Pydantic schema验证和环境变量覆盖
子问题
1.配置schema定义与验证
2.多层配置合并策略
3.环境变量覆盖
4.运行时配置热加载
5.双子系统配置隔离与独立演进
6.提供商注册表设计与关键词自动匹配
7.阶段特化模型选择（规划 vs 实现）
8.配置格式迁移与向前兼容
各项目的解法1 solutions
Signals
横向对比
| 维度 | DeepCode |
|---|---|
| 配置格式 | 双轨：MCP Agent 用 YAML，Nanobot 用 JSON + Pydantic BaseSettings |
| 密钥管理 | secrets.yaml 独立文件，优先于环境变量，支持 3 提供商 |
| 提供商匹配 | ProviderSpec 冻结 dataclass 注册表，关键词 + key 前缀 + URL 三重匹配 |
| 阶段特化 | planning_model / implementation_model 分开配置，缺失回退 default_model |
| 配置验证 | Nanobot 轨用 Pydantic BaseSettings，MCP Agent 轨无验证直接 yaml.safe_load |
| 配置迁移 | _migrate_config() 处理格式变更，camelCase ↔ snake_case 自动转换 |
| 提供商数量 | MCP Agent 轨 3 个，Nanobot 轨 11 个（含 2 网关 + 1 本地部署） |
最佳实践
1.使用Pydantic BaseSettings做类型安全的配置验证
2.配置文件优先，环境变量作为覆盖层
3.用冻结 dataclass 元组作为提供商注册表，新增提供商只需加一条记录
4.API key 前缀和 URL 关键词自动检测网关提供商
5.planning_model / implementation_model 分离，平衡成本与质量