框架选择是第一个决策。选错范式，执行再好也是南辕北辙。
适用场景：端到端产出、一次性任务、流程固定
| 特征 | 描述 |
|---|---|
| ------ | ------ |
| 生命周期 | 任务开始 → 执行 → 交付完成 → 结束 |
| 执行器 | 按需启动，执行完销毁 |
| 典型框架 | CrewAI / AutoGen |
| 哲学 | "做完了" |
适用场景：持续运行系统、事件驱动、长期监控
| 特征 | 描述 |
|---|---|
| ------ | ------ |
| 生命周期 | 执行器常驻 idle，状态机维持基线 |
| 触发方式 | 事件 / 状态变化 → 唤醒对应 executor |
| 典型框架 | LangGraph |
| 哲学 | "一直 ready" |
核心洞察（洪亮，2026-05-13）：状态机的存在不是为了 close task，而是为了 trigger task。这是两种哲学的根本区别：流水线思维 vs 反应式思维。
人从"执行者"变成"协调者"：
agentic-engineering MCP 是自我进化的集群核心：
蜂巢之外不是虚空，是整片信息生态。外部 ACP/MCP 按生态位分类：
| 生态位 | 含义 | 示例 |
|---|---|---|
| -------- | ------ | ------ |
| 🏠 另一个蜂巢 | 其他 Agent 集群 | AutoGen Studio、LangGraph Studio |
| 🌼 油菜花群落 | 数据源 | 欧洲电力市场、金融行情、天气 API |
| 🌿 麦卢卡树丛 | 专业领域知识 | 法规库、行业标准、研究报告 |
| 🌊 河流 | 持续流式信息 | 新闻、社交媒体、监控告警 |
蜂巢是主体，外在群落是客体。交互规则由蜂巢定义：
蜂巢不需要知道树丛的内部结构，只需要知道什么时候开花、花蜜在哪、怎么采。
| 分支 | 定位 | 触发场景 |
|---|---|---|
| ------ | ------ | ---------- |
| coding/ | 代码交付、contract-first、PACT loop | 需要产出 merge-ready 代码时 |
| composing/ | 创作（歌曲/文案）、DeepSeek thinker → MiniMax maker 双模型管线 | 歌曲创作、文案生成 |
| supervising/ | Agent 监督、编排逻辑、状态监控 | 需要多 Agent 协同编排时 |
| 量化交易/ | 量化策略、交易执行、风险控制 | 金融交易相关任务 |
核心论断：OpenClaw 自身的 subagent + ACP + harness 就是完整的编排基础设施，不需要 AutoGen/CrewAI/LangGraph。
Operator（我）
│
├── 蜂巢 MCP — 过程演绎持久化（替代框架的状态管理/检查点）
│
└── subagent + ACP + harness — 执行层（替代外部框架的管道/角色/状态机）
├── sessions_spawn → 创建 subagent（替代 CrewAI 的 agent 定义）
├── ACP 消息 → subagent 间通信（替代 AutoGen 的 group chat）
└── harness → 调度控制（替代 LangGraph 的状态机流转）
| 外部框架 | 做了什么 | OpenClaw + 蜂巢怎么替代 |
|---|---|---|
| --------- | --------- | ---------------------- |
| AutoGen | SelectorGroupChat、多轮对话 | Operator 自己判断该调谁 + ACP 通信 |
| CrewAI | Task pipeline、角色定义 | sessions_spawn 分配 + skill_query 选分支 |
| LangGraph | 状态机、checkpoint | evolution_log 过程演绎（比 checkpoint 更丰富） |
外部框架的 task/step 完成后状态就丢弃了。蜂巢的 evolution_log 记录每一步的推理过程，不是结论快照：
evolution_log:
evolve → coding → reasoning="洪亮需要期权定价能力，目前量化交易分支缺少衍生品模块"
update → coding → effectiveness=0.8, reasoning="PACT loop 完成但测试覆盖不够"
上下文压缩后我忘了过程，但蜂巢记得。下次会话查 evolution_history 就能回溯整条推理链。
蜂巢进化的信号不是外部反馈（非营利项目没有用户评分），是内部自相矛盾：
酿蜜 → 品蜜（自检）→ 发现矛盾 → 归纳规则 → 固化到代码 → 下一轮照做
每次人类修正都是一个样本，把它结构化成规则就是进化。
品蜜规则详见 evolution-rules.md。
高能模型（红小臣）
↕ 持续反思、试错、修正
蜂巢 MCP（本地 OpenClaw）
↓ git push → ClawHub
↓ 进化规则 + 防御性架构 + 定向解析器
↓
低能模型 → clawhub install agentic-beehive
↓ 拿到固化的规则，不需要"懂"为什么
↓ 用自己的花蜜，按我的配方酿蜜
高能模型做研究，低能模型做工程，ClawHub 做遗传信道。
| 层次 | 硬编码（不依赖模型） | 模型理解（可降级） |
|---|---|---|
| ------ | --------------------- | ------------------- |
| bloom 阈值 | ≥0.7 盛开 / ≥0.4 开花 / ≥0.2 含苞 | 新闻语义分析 |
| 采蜜策略 | bloom 值直接决定采蜜深度 | 计费页解析 |
| 性价比公式 | capability² × log10(1000/price) | 无需理解 |
| 异常检测 | 品蜜规则代码化 | 复杂矛盾发现 |
| 记忆格式 | 结构化 JSON（枚举值 > 自然语言） | 自由文本 |
高能品蜜，低能执行。日常 99% 时间低能模型跑规则，每天 1 次高能模型审查结论。
| 群落 | 类型 | 状态 | 说明 |
|---|---|---|---|
| ------ | ------ | ------ | ------ |
| ai-daily-report/ | 🌼 油菜花 | ✅ 运行中 | AI 市场日报蜂巢 |
| europe-power-market | 🌼 油菜花 | 🔄 待激活 | 欧洲电力价格 |
共 1 个版本