第十五章演化路线图：从能跑到智能¶

编排器的演化不是线性的，而是螺旋上升的。每一轮"踩坑→修复→优化"都在提升系统的可靠性和智能度。

15.1 三阶段演化模型¶

阶段一：能跑起来
  → 手动启动、脚本守护、基本容错
  → 关键指标：运行时长 > 1小时不崩溃

阶段二：可靠运行
  → 自动重启、状态持久化、多层防护
  → 关键指标：运行时长 > 24小时不失控

阶段三：智能增强
  → 自适应调度、经验学习、生态扩展
  → 关键指标：越跑越好，不再重复犯错

15.2 当前位置评估¶

编排器	阶段一	阶段二	阶段三
Tmux-Orchestrator	✅	🔄	❌
Overstory	✅	✅	🔄
Composio	✅	🔄	❌
agency-agents-zh	✅	❌	❌

Overstory 最接近阶段三，因为它已经实现了： - 结构化知识积累（Mulch） - AI辅助冲突解决（Level 3 合并） - 分层看门狗监控（Bash timer + AI 分诊） - 基于能力的调度（与 Agent 身份解耦）

15.3 阶段三的关键技术¶

自适应调度¶

当前：固定间隔巡检（每60秒一次）目标：根据 Agent 状态动态调整

Agent 活跃中 → 每5分钟检查一次（省资源）
Agent 可能卡住 → 每1分钟检查
Agent 确定卡住 → 立即干预
Agent 在 429 冷却中 → 等冷却结束再检查

Overstory 的做法：分层看门狗已经实现了自适应调度的原始形态——Tier 0 做固定巡检，但 Tier 1（AI 分诊）会智能决策何时干预以及如何干预。

经验学习¶

当前：LEARNINGS.md 人工维护目标：Agent 自动从错误中提取经验

Agent 崩溃 → 记录崩溃原因
Agent 重试3次 → 提取共性 → 写入 LEARNINGS.md
下次遇到同类问题 → 自动应用经验

Mulch 作为经验学习的种子：Overstory 的 Mulch 知识库已经存储了冲突模式和失败模式。下一步是让模式提取自动化，而不需要显式写入。

跨项目协调¶

当前：每个项目独立编排目标：编排器网络，跨项目资源共享

项目A的 Agent 空闲 → 借给项目B用
项目A遇到 429 → 项目B的 Agent 接力
全局 Supervisor → 协调所有编排器

Supervisor 模式：我们自己的 Supervisor agent（见第三章）已经实现了这种模式的原始形态——它监控多个项目，可以跨项目重启/停止 Agent。但它缺乏动态资源重分配能力。

多运行时编排¶

当前：大多数编排器锁定在单一运行时目标：在同一条流水线中无缝混用不同的 AI 运行时

Coordinator: claude-opus-4（复杂推理）
Scout: claude-haiku（快速探索）
Builder: codex（代码生成）
Reviewer: claude-sonnet-4（质量均衡）

Overstory 的 11 个运行时适配器是这一愿景最完整的实现。关键的架构决策是 AgentRuntime 接口——一个统一 API，将运行时差异抽象化。

生态互操作¶

当前：每个编排器都是孤岛目标：编排器之间共享 Agent、技能和知识

Hermes 技能 → 可供 Overstory Agent 使用
Overstory Mulch 知识 → Tmux-Orchestrator 可查询
agency-agents-zh Agent 定义 → 可部署到任何运行时

agency-agents-zh 的跨平台部署是朝这个方向迈出的一步——它的 install.sh 能将 Agent 定义转换为 10+ 种工具格式。但真正的互操作需要共享协议（不仅仅是共享定义）。

15.4 成熟度矩阵¶

维度	阶段一	阶段二	阶段三
容错	手动重启	自动重启 + 看门狗	自愈 + 预测性维护
通信	tmux send-keys	SQLite 邮件	协议无关总线
知识	无	LEARNINGS.md	结构化 + 自动提取
隔离	会话隔离	git worktree	动态 worktree 池
调度	手动分配	脚本驱动	基于能力 + 自适应
可观测性	tmux capture-pane	事件存储 + 仪表盘	实时分析 + 告警
安全	Prompt 规则	铁律 + 外部守卫	沙箱执行 + 审计
部署	手动 tmux 配置	systemd + 一键脚本	云原生 + 自动扩缩容

15.5 开放问题¶

Agent 可靠性天花板：LLM 本身的可靠性决定了编排器的上限。无论编排多么精巧，都无法弥补一个持续产生幻觉的模型。
上下文窗口限制：128K/200K 是否足够支撑复杂项目？Overstory 的 overlay 注入是解决这一问题的一种方式——只注入需要的内容，而非全部。
成本控制：7x24 运行意味着 7x24 的 API 费用。分层监控（例行检查用 haiku，复杂决策用 opus）是 Overstory 的成本优化策略。
安全边界：Agent 能做什么不能做什么？谁来判断？铁律 + 外部守卫模式是务实的方案，但需要正式的安全模型。
人机协作模式：完全自治 vs 人在回路，哪种更好？agency-agents-zh 的 decision_gate 协议和 Overstory 的升级路径表明答案是"取决于场景，两者都需要"。
合并智能：AI 辅助合并能变得多聪明？Overstory 的 Level 3 合并（查询 Mulch 获取历史模式）很有前景，但合并冲突仍然是多 Agent 系统中最困难的问题之一。

15.6 预测¶

基于当前趋势，未来 1-2 年 AI Agent 编排将走向：

标准化：将出现行业标准 Agent 通信协议（超越 MCP）。Overstory 的 9 种邮件协议有可能成为事实标准。
云原生化：编排器将从单机 Bash 脚本演进为 K8s Operator。Composio 的仪表盘已经具备云感知能力；下一步是完整的 K8s 集成。
可观测性：Agent 行为可视化——像监控微服务一样监控 Agent。Overstory 的事件存储和 Composio 的仪表盘都是早期案例。
市场生态：Skill/Agent 市场——可交易、可组合。agency-agents-zh 的目录结构是这一形态的原型。
自演化：编排器将自动优化自身的参数和策略。Mulch 的冲突模式学习是迈向这一目标的第一步。
多模型流水线：有意为不同阶段使用不同模型（快速模型用于侦察，智能模型用于审查）的流水线将成为默认选择。成本效益和质量同时提升。
人机遥测：实时仪表盘不仅展示 Agent 健康状态，还包括决策质量、成本效率和人机监督指标。

15.7 小结¶

编排器的演化路线：

能跑 → 可靠 → 智能 → 生态
  ↑                         |
  └───────── 持续迭代 ──────┘

核心信念：好的编排器是打磨出来的，不是设计出来的。 每一次崩溃、每一次 429、每一次 Agent 偷懒——它们都在告诉你下一步该改进什么。

任何团队的实践路径：

从 tmux + bash 开始（阶段一，数天即可实现）
加入 systemd + 看门狗 + LEARNINGS.md（阶段二，数周稳定下来）
引入结构化通信 + 知识库 + 多运行时（阶段三，数月走向成熟）
回馈生态——分享你的模式、你的技能、你用血泪换来的教训

未来属于那些能学习、适应和协作的编排器——而不仅仅是能跑的。

第十五章 演化路线图：从能跑到智能¶