Agentic Engineering
范式层：先判断，再行动
框架选择是第一个决策。选错范式，执行再好也是南辕北辙。
任务交付型（Task-Delivery）
适用场景：端到端产出、一次性任务、流程固定
| 特征 | 描述 |
|---|---|
| 生命周期 | 任务开始 → 执行 → 交付完成 → 结束 |
| 执行器 | 按需启动，执行完销毁 |
| 典型框架 | CrewAI / AutoGen |
| 哲学 | "做完了" |
状态维持型（State-Maintenance）
适用场景：持续运行系统、事件驱动、长期监控
| 特征 | 描述 |
|---|---|
| 生命周期 | 执行器常驻 idle，状态机维持基线 |
| 触发方式 | 事件 / 状态变化 → 唤醒对应 executor |
| 典型框架 | LangGraph |
| 哲学 | "一直 ready" |
核心洞察（洪亮，2026-05-13）：状态机的存在不是为了 close task，而是为了 trigger task。这是两种哲学的根本区别：流水线思维 vs 反应式思维。
RL vibe > Harness
- Harness 路线：堆砌最佳实践架构，本质是"刻舟求剑"，只能做业务流程模板
- RL vibe 路线：模型自己长出推理能力，协调者只负责维持上下文和记忆
协调者角色
人从"执行者"变成"协调者"：
- 设定目标，不设计流程
- 维持上下文，不编写代码
- 审查结果，不参与执行
生态层：蜂巢与外在群落
蜂巢（Hive）
agentic-engineering MCP 是自我进化的集群核心：
- Operator（我）是态势感知入口，掌握工具架构，按需调用
- 分支是蜂巢内的职能单元，按需唤醒
- 记忆 + Dreaming是蜂巢的集体记忆，持续沉淀
外在群落（External Colonies）
蜂巢之外不是虚空，是整片信息生态。外部 ACP/MCP 按生态位分类：
| 生态位 | 含义 | 示例 |
|---|---|---|
| 🏠 另一个蜂巢 | 其他 Agent 集群 | AutoGen Studio、LangGraph Studio |
| 🌼 油菜花群落 | 数据源 | 欧洲电力市场、金融行情、天气 API |
| 🌿 麦卢卡树丛 | 专业领域知识 | 法规库、行业标准、研究报告 |
| 🌊 河流 | 持续流式信息 | 新闻、社交媒体、监控告警 |
交互规则
蜂巢是主体，外在群落是客体。交互规则由蜂巢定义：
- 采蜜：按需从外在群落取数据（MCP 调用）
- 酿蜜：将原始数据加工成决策和知识（内部处理）
- 分蜂：集群自我进化，扩展新分支或新群落
蜂巢不需要知道树丛的内部结构，只需要知道什么时候开花、花蜜在哪、怎么采。
四个属性
- 宏大的 — 不是做一个小工具，是构建可持续进化的智能生态
- 主体视角的 — 蜂巢是主体，外在群落是客体，交互规则由蜂巢定义
- 可执行的 — 每个 MCP 都是可调用的服务，不是概念图
- 自洽的 — 内部进化逻辑和外部交互逻辑一致，不矛盾
分支索引
| 分支 | 定位 | 触发场景 |
|---|---|---|
| coding/ | 代码交付、contract-first、PACT loop | 需要产出 merge-ready 代码时 |
| composing/ | 创作（歌曲/文案）、DeepSeek thinker → MiniMax maker 双模型管线 | 歌曲创作、文案生成 |
| supervising/ | Agent 监督、编排逻辑、状态监控 | 需要多 Agent 协同编排时 |
| 量化交易/ | 量化策略、交易执行、风险控制 | 金融交易相关任务 |
执行原则
- 先判断范式，再选择分支 — 框架选错，流程再好也是白搭
- 协调者心态 — 人只设定目标和维持上下文，AI 负责执行
- 记忆即资产 — 每个任务学到的经验必须沉淀到记忆，否则等于没做
- 触发 > 轮询 — 优先事件驱动，不做无效的定期检查
- 蜂巢视角 — 站在主体看世界，外在群落是资源不是约束