Claude Code Orchestra

克劳德代码乐团

Claude Code的编排层，将任务路由到正确的LLM，通过钩子执行安全规则，并在会话之间保持上下文。为我自己管理七个生产服务的工作流而构建——共享它是因为模式是可重用的。

这是什么（30秒版）

我打开了一个类似“向支付API添加重试逻辑”的问题。系统：

1. 计划 --架构师代理确定工作范围并选择合适的工具
2. 实现 --代码代理使用GPT-5.2 Codex编写更改
3. 验证 --钩子会阻止提交，直到模式得到验证、测试通过并导入跟踪到入口点
4. 评论 --一名法官代理人进行恶意审查，寻找死代码、安全问题和遗漏的边缘案件

我可以在每一步停止或覆盖。没有我的批准，任何东西都不能装运。

里面有什么

建筑

User Request
    |
    v
[Intent Detection] --> Capability Registry (68 entries)
    |
    v
[Agent Selection] --> architect-planner | code-worker | code-judge
    |                  research-specialist | reasoning-specialist
    |                  realtime-specialist | gemini-specialist
    v
[MCP Tool Dispatch] --> Gemini 3 Pro | GPT-5.2 | Grok 4 | Perplexity | DeepSeek
    |
    v
[Hook Validation] --> Pre-tool gates | Post-tool verification | Session lifecycle
    |
    v
[Output with Proof] --> Tests passed | Screenshots taken | API responses verified

快速开始

# Clone and copy into your Claude Code config
git clone https://github.com/YOUR_USERNAME/claude-code-orchestra.git
cp -r claude-code-orchestra/.claude/* ~/.claude/

# Or cherry-pick what you need:
cp claude-code-orchestra/.claude/rules/code-quality.md ~/.claude/rules/
cp claude-code-orchestra/.claude/hooks/schema-verify.sh ~/.claude/hooks/

12条硬性规定

每一条规则的存在都是因为生产中出现了问题。带有钩子的规则被积极执行——不仅被记录下来，而且被阻止：

技能库（24）

技能是结合了代理、MCP和验证门的自主工作流模板。

核心工作流程技能

发展技能

操作技能

吊钩系统（26）

钩子在工具边界执行规则。它们在每次工具调用之前/之后作为shell脚本运行。

预工具挂钩（防止不良状态）

schema-verify.sh    -> Blocks SQL until schema is queried
dead-code-check.sh  -> Blocks commits with orphan files
debug-first.sh      -> Blocks rewrites until logs are read
deploy-gate.sh      -> Blocks verification until pipeline completes
capability-enforcer  -> Validates tool availability before use

后置工具挂钩（验证和学习）

stop-verify.sh      -> Requires proof before session end
quality-validation   -> Auto-lint, type-check after code generation
test-result-tracker  -> Tracks test pass/fail ratio over time
visual-verify.sh     -> Screenshot validation for UI changes

会话生命周期挂钩

session-start-enhanced.sh -> Loads git context, project state, memory
pre-compact-save.sh       -> Saves critical state before context compaction
session-end-learning.sh   -> Extracts learnings, updates patterns

代理系统（11个合并）

最初有26种药物，在发现具有明确MCP重点的专业药物优于狭隘的单一用途药物后，合并为11种：

MCP集成（7）

能力注册表

这 capabilities-registry.json 是系统的大脑——68个条目将任务模式映射到最佳工具：

{
  "id": "codex-builder",
  "name": "Codex Builder (GPT-5.2)",
  "triggers": ["build feature", "implement", "refactor"],
  "mcp": "azure-ai-foundry",
  "model": "gpt-5.2-codex",
  "cost_tier": "high",
  "latency": "medium"
}

计划在执行前会自动添加功能注释：

3. Implement OAuth2 flow
   -> Agent: codex-builder
   -> Skills: azure-unified
   -> MCP: azure-ai-foundry, memory
   -> Confidence: 0.85

规则系统（6个域模块）

规则根据任务上下文按需加载：

在哪里使用

在我维护的七项服务的日常使用中——交易平台的Azure功能应用程序（每月执行174K多次）、语音AI转录、合规工具和内部实用程序。钩子和规则是从真实事件演变而来的：批量文件删除导致功能应用程序崩溃，对错误数据库的SQL查询，通过CI但没有工作功能的部署。

实际使用中的数字：

• 通过此系统管理的15个Azure功能应用
• 每月监控174000多个函数执行
• 跨项目维护了300多个自动化测试
• 148多个具有跨会话内存的开发会话

设计笔记（来自Ops Brain）

架构选择反映的是运营背景，而不是CS背景：

1. 故障关闭，未打开：默认情况下，钩子会阻止错误操作。带有孤立文件的提交被停止，没有警告。
2. 强制执行，不记录：每条规则都有相应的钩子。“不要硬编码凭证”是一个很好的指导方针；为API键greps的预提交挂钩是一个实际的门。
3. 循环中的人类：系统生成2-3个选项；我挑。在架构选择上没有自主决策（规则12）。
4. 明确而非神奇：能力路由使用带有成本/延迟元数据的JSON注册表，而不是隐藏的启发式方法。
5. 默认情况下进行恶意审查: code-judge 运行对抗性审计，查找死代码、模式漂移和安全漏洞。

仓库结构

.claude/
  CLAUDE.md                          # Root config: identity, 12 rules, routing
  capabilities-registry.json         # 68 capability entries with triggers + metadata
  rules/
    code-quality.md                  # Language standards, schema-first, test gates
    db-safety.md                     # Cross-DB isolation, migration safety
    visual-validation.md             # Playwright + Gemini screenshot validation
    azure-deploy.md                  # CI/CD safety, rollback procedures
    voice-agent-tuning.md            # ElevenLabs, Arabic TTS, SSML
    project-config.md                # Session lifecycle, context management
  hooks/
    schema-verify.sh                 # Pre-tool: block SQL without schema query
    dead-code-check.sh               # Pre-tool: block commits with orphan files
    stop-verify.sh                   # Post-tool: require proof before "done"
    deploy-gate.sh                   # Pre-tool: block premature verification
    session-start-enhanced.sh        # Session: load git context + project state
    README.md                        # Hook system documentation
  skills/
    multi-model-debate/
      instructions.md                # 6-model council protocol
    enforce-capabilities/
      instructions.md                # Plan enrichment with capability annotations
    ship-it/
      instructions.md                # Anti-perfectionism gate
    pre-mortem/
      instructions.md                # Risk assessment protocol
    README.md                        # How to create skills
  agents/
    architect-planner.md             # Design/planning agent
    code-worker.md                   # Implementation agent
    code-judge.md                    # Hostile review agent
    README.md                        # Agent system overview
docs/
  architecture.md                    # Detailed architecture with diagrams

你能从中学到什么

• 如何构建多代理Claude代码设置 --不仅仅是一个CLAUDE.md，而是一个完整的系统
• 如何用钩子执行规则 --在工具边界运行的shell脚本
• 如何将任务路由到最优模型 --具有成本/延迟元数据的能力注册表
• 如何在会话中持久化上下文 --status.json、decisions.log、内存MCP
• 实际生产经验 --每一条“起源：”评论都是一个形成规则的真实事件

这不是什么

• 不是框架或库，而是Claude Code的配置系统（技能、钩子、规则、代理）
• 不适用于任意设置——它反映了我的特定堆栈（Azure、PostgreSQL、Python）和我的特定偏执（模式验证、死代码检测）
• 不是正确的CI/CD的替代品——钩子添加了本地安全门，但生产部署仍然通过Azure DevOps管道进行
• 代理/技能计数会发生变化，在任何给定的提交中都可能与README不完全匹配

为什么不使用LangGraph/CrewAI/AutoGen？

这些是用于构建多代理系统的应用框架。这是一个 *开发环境* --它编排我如何编写和发布代码，而不是最终用户如何与人工智能交互。最接近的类比是高度定制的IDE配置，而不是产品架构。

贡献

PR欢迎。这是一个随着新模型和工具进化的生命系统。

如果你添加了一条新规则，请添加一条“起源：”注释，解释是什么生产事件造成了它。没有起源故事的规则只是意见。

动机和经验教训

这是在我意外部署了一个带有孤立文件的功能应用程序后开始的，该孤立文件导入了我已经删除的模块。部署成功，健康检查通过，第一个真实请求崩溃。那天晚上，我写了一个预提交钩子来跟踪来自入口点的导入。这是钩子#1。其余的则源于类似的事件。

最难的一课是关于模式漂移。我写了一个SQL迁移，假设一个列存在，因为计划说它会存在。事实并非如此。在有人注意到之前，查询在两天内默默地返回了空结果。现在每个SQL操作都会查询 information_schema 首先，没有例外，即使在开发中也是如此。仅这一条规则就比其他任何规则都能防止更多的错误。

令我惊讶的是：多模型辩论模式（将同一个问题路由到6个不同的LLM并综合分歧）始终抓住了没有单个模型标记的架构问题。这些模型在有用的方面存在分歧：一个捕捉安全问题，另一个捕捉性能影响，第三个捕捉边缘情况。分歧就是信号。

______________________________________________________________________

技能展示

多代理AI编排、生产安全挂钩、模式优先的SQL开发、多模型共识模式、会话持久性、CI/CD集成（Azure DevOps）、MCP协议集成、成本/延迟感知模型路由、防御性编码实践。

______________________________________________________________________

许可证

麻省理工学院