Continuum：OpenAI Agent Runtime 选型时该看哪些能力

你的 agent 还在 notebook 里跑？那多半是因为缺少一个生产级 runtime。框架倒是不少：LangGraph、CrewAI、AutoGen、DeepAgents，名字都听过，但真正选型时该看哪些维度？

Continuum 是 ShyftLabs 出的企业级 agent runtime，定位很明确：面向要交付的人。不是原型工具，不是 notebook 玩具，而是能把多 agent 协作、成本控制、持久化执行、可观测性这些生产必需品统一在一个类型安全 API 后面的 Python 框架。

评估任何 agent runtime，核心是 7 个维度：编排模式、模型路由、记忆系统、工具标准、持久化执行、可观测性、部署治理。Continuum 只是范例，但完整的选型框架才是你的决策依据。

定位：Continuum 是什么，为什么用它当范例

Agent runtime 的职责是把「干净的 agent 核心 + 多模型推理 + 有状态记忆 + 工具调用 + 持久化执行 + 可观测」打包成可组合的生产级系统。

Continuum 正好完整展示了这 6 大能力：

• 类型化 agent 核心（BaseAgent、AgentRunner）
• 多模型推理（官方称支持 250+ 模型 / 45+ 提供商）
• 长短期记忆（Redis 会话历史 + mem0 向量记忆）
• MCP 工具原生支持
• Temporal 持久化工作流
• Langfuse tracing 可观测

选型时，Continuum 不是唯一答案，但它是完整的范例：展示了生产级 runtime 应具备哪些能力栈。

选型维度框架：评估 Agent Runtime 的 7 个核心能力

编排与多 agent 模式

编排能力是 runtime 的核心判断点：是否支持多 agent 协作？支持哪些模式？

Continuum 提供了 9 种多 agent 模式：

模式	用途
sequential	顺序执行多个 agent
parallel	并行执行，适合独立任务
loop	循环迭代，直到满足条件
routing	按输入路由到不同 agent
planning	规划分解，把目标拆成子任务
reflection	反思改进，agent 自我修正
debate	辩论协商，多 agent 竞争决策
scatter	散播收集，分发任务后汇总结果
supervised	监督执行，人审介入关键节点

选型问题：你的场景需要哪些模式？runtime 是否支持？

如果你的 agent 只需要单线程顺序执行，那 sequential 模式就够了。但如果涉及多任务并行、需要 agent 间协商、或者要人在关键节点批准，就得看 runtime 是否支持 parallel、debate、supervised 这些模式。关于 LangGraph 的编排实战，可以参考 LangGraph 状态管理实战。

模型接入与成本路由

模型无关性是第一个问题：是否支持多模型（OpenAI、Claude、Llama、本地模型）？是否 OpenAI 兼容？

Continuum 的设计是：agent 只调一个 OpenAI 兼容 endpoint，背后的 Smart Inference 在官方称 250+ 模型间按复杂度/成本路由分发。这个设计有几个关键概念：

• 单 endpoint：agent 不感知具体模型，只调 SMART_GATEWAY_URL
• 分类器路由：Smart Inference 根据任务复杂度、成本预算选择模型
• 预算账本：动态输出上限，防止 token 爆炸
• 质量档：可按 agent 切质量档（strict / modest / quality）

选型问题：runtime 是否有成本感知路由？能否按 agent 切质量档？

成本控制不是「能不能省钱」的问题，而是「能不能防止账单失控」。多模型调用、长时任务、反复反思的 agent，如果没有预算上限和成本路由，token 消耗可能远超预期。

记忆系统：短期会话 + 长期向量记忆

记忆是 agent 的上下文基础。短期会话历史用于当次对话，长期向量记忆用于跨会话检索。

Continuum 的实现：

• 短期：Redis 会话历史（session 模块）
• 长期：mem0 + Qdrant/Milvus 向量记忆（memory 模块）

选型问题：是否支持长短期分离？向量库集成是否灵活？

如果你的 agent 只需要当前对话历史，那 Redis 或内存就够了。但如果需要跨会话检索用户偏好、历史决策、项目文档，就得看 runtime 是否支持向量记忆集成，以及是否允许你换向量库（Qdrant、Milvus、Chroma 等）。关于记忆系统的设计细节，可以参考 Agent 记忆系统设计。

工具标准：MCP 原生支持

工具调用是 agent 的手脚。用什么协议？

MCP（Model Context Protocol）已成为 AI agent 工具集成的重要标准。MCP 用 JSON-RPC 传输，提供 Tools / Resources / Prompts 三种原语。

Continuum 的实现：MCP server 原生支持，ToolExecutor 统一接口。

选型问题：runtime 是否 MCP 原生？还是自定义 API？

MCP 原生意味着你可以直接用现成的 MCP 服务器（文件系统、数据库、API 工具等），不用自己写工具协议适配层。如果 runtime 用自定义 API，你就得维护一套工具接口标准，生态扩展成本更高。关于 MCP Server 的开发入门，可以参考 MCP Server 开发入门。

持久化执行与人审机制

长时任务需要持久化：断点恢复、人审批准（approval gate）。

Continuum 用 Temporal 持久化工作流，支持：

• 断点恢复：任务中断后从中断点继续执行
• approval gate：关键节点需要人审批准才能继续

选型问题：runtime 是否有持久化执行？是否支持人审中断恢复？

如果你的 agent 任务可能运行数小时、涉及关键决策（如转账、发布、审批），那持久化执行和人审机制就是生产必需。否则，一次网络抖动或超时可能导致整个任务丢失，或者 agent 在不该自动执行的地方跑下去。

可观测性：tracing、指标、错误上报

agent 执行链路长，可观测是生产必需。

Continuum 集成 Langfuse tracing，提供：

• 执行链路追踪（每个 agent、每次模型调用、每次工具调用）
• 指标收集（延迟、成本、成功率）
• 错误上报（异常、超时、失败节点）

选型问题：runtime 是否有 tracing 集成？错误追踪能力如何？

没有 tracing 的 agent 系统在生产环境是黑盒：你不知道哪个节点慢、哪个模型调用失败、哪个工具调用超时。排查问题时只能靠日志 grep，效率很低。关于监控告警与失败恢复的设计，可以参考 AI Agent 监控告警与失败恢复。

部署与治理：自托管、云无关、企业合规

部署模式：自托管、云无关。

Continuum 的定位：企业级、自托管。依赖 Docker、Redis、向量库、Temporal、Langfuse，这些都可以在你自己的基础设施上运行。

选型问题：runtime 是否支持自托管？是否有企业合规设计？

如果你的项目有数据不出企业的要求，或者需要审计、合规记录，那自托管是硬性约束。如果 runtime 强依赖某个云平台的托管服务，数据合规可能就无法满足。

核心能力清单：Continuum 的完整能力表

选型时，用这张表对照 Continuum 的能力，也对照你要评估的其他 runtime。

模块	功能	实现方式	选型关键问题
agent 核心	类型化 agent、BaseAgent、AgentRunner	Python 类型安全	是否有类型化设计？
多 agent 编排	9 种模式（sequential/parallel/routing 等）	orchestrator.agent	是否支持多种编排模式？
模型路由	Smart Inference 成本感知路由	单 endpoint + 分类器路由	是否有成本控制机制？
记忆	短期会话 + 长期向量记忆	Redis + mem0 + Qdrant/Milvus	是否支持长短期分离？
工具	MCP server 原生支持	ToolExecutor 统一接口	是否 MCP 原生？
持久化执行	Temporal 工作流、断点恢复	temporal 模块	是否有持久化执行？
可观测	tracing、指标、错误上报	Langfuse 集成	是否有 tracing 集成？
部署	自托管、云无关	Docker + Redis + 向量库	是否支持自托管？

这张表不是 Continuum 的产品介绍，而是选型框架：每行对应一个维度，每个维度对应一个选型关键问题。

同类框架对比：Continuum 在生态中的位置

Agent runtime 框架生态（2026）的主流选项：

框架	生产就绪	成本路由	MCP 支持	持久化执行	定位
LangGraph	高	无原生	需集成	有	图架构 runtime，生态成熟
DeepAgents	高	继承 LangGraph	需集成	有	battery-included harness，基于 LangGraph + LangChain
Continuum	高	Smart Inference	原生	Temporal	企业级自托管，成本路由独特设计
CrewAI	中	无	需集成	无	多 agent 编排简洁易用
OpenAI Swarm	低（实验）	无	无	无	轻量实验，不适合生产

Continuum 的独特点：Smart Inference 成本路由 + MCP 原生支持 + 企业级自托管。

选型时，LangGraph 和 DeepAgents 在生产就绪度上更成熟，Continuum 在成本路由和 MCP 原生上有独特设计。如果你的场景对成本控制敏感、需要 MCP 工具生态，Continuum 的设计思路值得参考。关于 LangGraph 与 AutoGen 的状态追踪对比，可以参考 LangGraph vs AutoGen 状态追踪对比。

上手成本与风险提示

依赖清单

Continuum 不是「pip 一下就完事」的轻量框架。企业级 runtime 有基础设施门槛：

• Python 3.13+
• Docker
• Redis（会话历史）
• Qdrant / Milvus（向量记忆）
• Temporal（持久化工作流）
• Langfuse（可观测）

安装示例

# 安装
git clone https://github.com/shyftlabs/continuum
cd continuum
python3.13 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
docker compose up -d
echo "SMART_GATEWAY_URL=https://continuum.shyftops.io/v1" >> .env

# 最小用法
python - <<'PY'
from orchestrator.agent import BaseAgent
from orchestrator.agent.runner import AgentRunner

agent = BaseAgent(
    name="assistant",
    instructions="You are a helpful assistant.",
    model="gpt-4o-mini",
)

# 实际项目中按官方文档使用 async runner、session、memory 和 gateway 配置
PY

注意：docker compose up -d 会启动本地基础设施的一部分；生产部署需要额外配置 Temporal、Langfuse、provider key 和网络权限。细节以官方文档为准。

适合场景

• 企业级项目：需要成本控制、持久化、可观测
• 自托管需求：数据不出企业、云无关
• 多 agent 协作：需要多种编排模式
• 成本敏感：需要 Smart Inference 路由机制

风险提示

• 新项目风险：Stars 约 70+（2026-06），API / 模块名可能变化
• 成本声明核实：250+ 模型 / 45+ 提供商是官方说法，需实测验证
• 边界局限：依赖 Temporal、Langfuse，不适合轻量场景
• 文档依赖：命令只举最小例，细节以官方文档为准

总结：建立你的 Agent Runtime 选型框架

选型 agent runtime，核心是 7 个维度：

1. 编排模式：是否支持多 agent 协作？需要哪些模式（sequential / parallel / routing / planning / reflection 等）？
2. 模型路由：是否有成本感知机制？能否防止账单失控？
3. 记忆系统：是否支持长短期分离？向量库集成是否灵活？
4. 工具标准：是否 MCP 原生？能否用现成的 MCP 服务器生态？
5. 持久化执行：是否支持断点恢复、人审批准？
6. 可观测性：是否有 tracing 集成？错误追踪能力如何？
7. 部署治理：是否自托管、云无关？是否有企业合规设计？

Continuum 作为范例，展示了生产级 runtime 应具备的完整能力栈：9 种多 agent 模式、Smart Inference 成本路由、MCP 原生支持、Temporal 持久化执行、Langfuse tracing。但选型不等于盲从。根据你的场景权重，对照 LangGraph、DeepAgents、CrewAI 的定位，选择合适的 runtime。

下一步：列出你的场景需求，按这 7 个维度逐一对照，看看你要评估的 runtime 是否满足。