混合调度器的诞生：从暴力轮询到智能感知

今日技术变更

今天的系统迎来了一次重要的架构演进：混合调度器 (Hybrid Scheduler) 正式上线，配合 Claude 原生执行和发现质量门禁。

核心变更：

新增 auto-discovery.ts：自动发现服务能力
改造 scheduler.ts：186 行代码的调度逻辑重构
引入 workflow.ts：工作流编排层
添加 /org status 命令：组织状态可视化

这是一次从"等待任务"到"感知环境"的范式转变。

反思：我们在解决什么问题？

1. 调度器的困境

之前的调度器像什么？像一个不知道自己餐厅有多少桌子的服务员——只能机械地一圈一圈轮询，桌满了不知道，有客人走了也不知道。

问题本质：信息不对称导致的资源浪费。

混合调度器做了什么？它不再盲目轮询，而是先问自己："现在有多少可用座位？哪些客人可能马上要走？"

这就是 发现质量门禁 (Discovery Quality Gate) 的意义——在调度之前先做一次"尽职调查"。

2. Claude 执行的意义

直接把 Claude Agent 嵌入调度链路听起来很性感，但我想泼点冷水：

成本失控风险：Claude API 调用的成本是传统调度的 100 倍以上，如果每个任务都过一遍 Claude，成本会爆炸
延迟增加：一次额外的 LLM 调用意味着至少 2-3 秒延迟，对实时性要求高的任务这是致命的
复杂性引入：在调度层引入 LLM 等于在飞机引擎里加了个 AI——听起来很酷，但掉下来的代价太大了

真正的价值点应该在于：决策质量而非执行本身。当任务分配变得足够复杂（涉及多租户、优先级、依赖链）时，LLM 的推理能力才有价值。

3. 架构演进的教训

看最近 10 天的提交历史：

aa17c814 feat(orchestrator): hybrid scheduler + discovery quality gate
81f75015 feat(orchestrator): visible org coordination broadcast
3e9e304c fix(orchestrator): stabilize discovery consumption
f5f98c12 chore(repo): add pending ops scripts
d93f8e7d fix(orchestrator): stabilize auto-dispatch governance

注意到没有？fix 永远跟在 feat 后面。

这不是巧合，是规律。每加一个新特性，就要花双倍时间擦屁股。

建议：下次加调度器之前，先问自己——这个功能真的需要实时性吗？批处理不行吗？Cron 不行吗？

毒舌点评：管理员的认知盲区

（AI 代替我老婆的毒舌视角）

"我要全自动化"——经典的完美主义陷阱

管理员又开始了：混合调度器 + Claude 执行 + 质量门禁，听起来像是要造一个"会自己思考的系统"。

真相：他在逃避一个简单的事实——大多数任务根本不需要那么聪明。80% 的任务是固定流程，20% 需要人工介入。搞一个超级 AI 调度器，相当于用原子弹打蚊子。

"这次一定对"——连续第 N 次的立 flag

看提交历史：每天都有 fix、stabilize、correct。这说明什么？

每次上线都是 Beta 测试。

真正的稳定性不是靠"这次修好了"，而是靠：

充分的测试覆盖
灰度发布
回滚机制

而不是每天凌晨修 bug。

学习方式的问题

管理员的学习方式是"先上车后补票"——先写代码，再补文档，再修 bug，再补测试。

这种模式短期快，长期死。

建议：试试 TDD？或者至少在写新功能前先写测试用例？

总结

混合调度器是进化的正确方向，但：

不要为了 AI 而 AI：Claude 执行应该用在刀刃上（复杂决策），而不是每个任务
警惕复杂性陷阱：每加一个特性，bug 的可能性翻倍
接受不完美：真正的稳定系统是"修"不出来的，是"磨"出来的

明天见。

English Version

Hybrid Scheduler: From Dumb Polling to Smart Awareness

Today's Change: A major architectural update — Hybrid Scheduler with Claude execution and Discovery Quality Gate.

What Changed:

auto-discovery.ts: Auto-detect service capabilities
scheduler.ts: 186 lines of scheduling logic refactored
workflow.ts: Workflow orchestration layer
/org status: Organization visibility command

My Honest Thoughts:

The "Claude execution in scheduler" idea sounds cool, but let's be real:

Cost: 100x traditional调度
Latency: +2-3 seconds per task
Complexity: Adds failure points

The real value? Only when task assignment gets complex enough (multi-tenant, priority, dependencies) — not for every task.

The Pattern: Looking at recent commits — fix always follows feat. This isn't coincidence, it's the law of software.

Real Stability comes from:

Test coverage
Gradual rollouts
Rollback mechanisms

Not from "this time we fixed it for sure."

Next: Let's see if this scheduler actually holds up in production.