核心用法
Council Builder 是一个多代理系统构建引擎，专为需要构建定制化AI团队的用户设计。其核心流程分为七个阶段：
Phase 1: 发现 — 通过三轮结构化访谈（身份、痛点、偏好）深度理解用户工作场景，必要时分析历史使用数据。
Phase 2: 规划 — 设计3-7个代理的委员会架构，定义每个代理的名称、角色、专业领域和人格特征，以表格形式呈现并获取用户确认。
Phase 3: 构建 — 执行标准化初始化脚本，为每个代理创建完整目录结构（SOUL.md人格文件、AGENTS.md协调规则、memory记忆目录、.learnings自改进日志等），严格遵循"无企业语言"的写作规范。
Phase 4: 自适应路由 — 配置Fast/Think/Deep/Strategic四级模型路由策略，设置升级/降级阈值和速率限制回退行为。
Phase 5: 自改进系统 — 建立错误检测、学习日志、跨代理知识共享和每周学习指标量化机制。
Phase 6-7: 验证与扩展 — 交付完整文件清单和协调图谱，支持后续代理的增删改操作。
显著优点
- 人格化设计: 每个代理都是独特"角色"而非模板，避免同质化
- 语言自适应: 支持多语言SOUL编写，贴合用户实际工作语境
- 文件驱动协调: 通过共享目录实现代理间通信，边界清晰可审计
- 强制自改进: 错误日志、学习指标、周期性回顾构成闭环优化
- 可视化架构: 生成自适应路由学习文档，便于培训和交接
潜在局限
- 启动成本较高: 需投入时间完成多轮访谈和确认流程
- 维护复杂度: 代理数量增加后，协调规则和网络效应可能难以预测
- 人格一致性风险: 修改代理时需刻意维护原有性格连贯性
- 删除代理的沉没成本: 仅移至回收站而非彻底删除，长期可能积累冗余
适合人群
- 知识工作者、创作者、研究者、项目经理等需要多维度专业支持的用户
- 已明确工作流痛点、希望系统性重构人机协作模式的团队
- 追求个性化AI体验、厌倦通用助手局限性的进阶用户
常规风险
- 过度设计: 建议3-7个代理，但"每个代理必须证明其存在价值"的原则可能被忽视
- 路由阈值僵化: 预设的Fast/Think/Deep/Strategic分级可能不匹配实际任务复杂度分布
- 学习数据孤岛: 跨代理共享依赖
shared/learnings/CROSS-AGENT.md，若更新不及时可能形成信息壁垒 - 人格漂移: 长期使用后代理响应风格可能逐渐趋同，需定期参照SOUL.md校准