代理编排（Outer Loop）
Outer Loop 是站在单个 agent 之外、负责统筹整个任务流程的那一层。
它关注的不是“某一步怎么执行”，而是：
- 任务怎么拆
- 该调用哪个 agent
- 调用顺序怎么安排
- 失败后是重试、回退还是换路径
一句话记忆：内层执行，外层编排。
先区分 Inner Loop 和 Outer Loop
- Inner Loop：开发者在本地改代码、跑测试、看结果的循环
- Outer Loop：代码提交之后，在 GitHub、CI、Jira、监控和自动化系统里继续推进任务的循环
放到 Agent 语境里：
- Inner Loop Agent：在本地协助你完成当前任务
- Outer Loop Agent：在云端或系统中独立推进整件事
为什么需要 Outer Loop
如果没有 Outer Loop，流程控制就会散落在每个 agent 里，导致：
- 多 agent 协作边界混乱
- 重试、回退、异常处理重复实现
- 很难统一治理和优化
所以可以简单理解为：
- agent 负责干活
- Outer Loop 负责把这些活串起来
一个直观例子
以“旅行助手”为例，系统里可能有：
calendar_agentflight_agenthotel_agentpolicy_agent
Outer Loop 负责：
- 判断这是“出差规划”任务
- 决定先读日程，再查机票和酒店
- 安排调用顺序
- 某一步失败时决定重试、回退或换方案
- 最后汇总结果
这里真正“查机票”的是 flight_agent，不是 Outer Loop。
Outer Loop 负责的是：谁先上、谁后上、失败了怎么办。
为什么 Outer Loop Agent 值得关注
参考 Agents in the Outer Loop，它近两年更重要，主要因为两点：
1. 更安全
Outer Loop Agent 往往运行在独立的云端环境里，权限和影响范围更容易控制，不需要像本地 agent 那样频繁人工确认。
2. 更容易扩展
它适合在独立容器、VM、GitHub Action 或 Kubernetes Pod 中运行，因此更容易并发处理大量重复任务。
OpenClaw 可以怎么理解
从 OpenClaw 的公开设计看，整体明显更偏 Outer Loop。
原因是：
- 它的核心是长期运行的
Gateway，负责承接多入口、多会话、路由、持久化和控制平面。 - 它的 agent 运行路径强调完整回路：任务进入系统后，会经过上下文组装、模型推理、工具执行、结果流式返回和状态持久化。
- 它支持本地和远程 Gateway，也支持把 agent 跑在独立主机上，而不是仅仅绑定在某个开发者本地 IDE 里。
所以更准确的理解是：
- OpenClaw 不是纯粹的 Inner Loop 助手
- 它更像一个偏 Outer Loop 的 agent runtime / gateway 平台
- 同时也兼容 CLI、TUI、本地 app 这类更接近 Inner Loop 的交互入口
更适合哪些任务
Outer Loop 更适合：
- 重复性高的任务
- 可流程化的任务
- 有明确触发信号的任务
- 不需要人类持续盯着每一步的任务
典型例子：
- CVE 修复
- 生产错误日志修复
- 自动化提 PR
- 多仓库批量维护
而探索性强、交互频繁、需要即时试错的工作，通常更适合放在 Inner Loop。
和相关概念的关系
- LLM 路由：决定请求发给哪个模型
- 代理编排（Outer Loop）：决定整个任务流程怎么推进
- AI原生代理数据平面：把路由、编排、护栏、观测等能力统一托管起来
可以压缩记成：
LLM 路由是模型层调度Outer Loop是任务层调度AI 原生代理数据平面是承接这些能力的基础设施
如何记忆
Outer Loop 不负责把一步做对，而是负责让整个任务持续往前走。