agentor

开场：Agent 框架的真正难点不是"能调工具"

2024 到 2026 年，Agent 框架像雨后春笋冒出来——LangChain、LlamaIndex、CrewAI、AutoGen……但用过的工程师都会发现同一件事：Demo 容易，生产难。Agent 跑到一半崩了，重启后上下文全丢；任务被中断，不知道从哪继续；想回溯某次运行为什么这么决策，查不到任何记录。

CelestoAI/agentor 直接把这三件事做成了框架的一等公民。它的自我定位是 "Claude Managed Agents 的开源版本"——把闭源 SaaS 里那些工程细节下沉到开源库。214 颗星、Apache-2.0、Python 3.11+。

背景：Celesto AI 的开源策略

作者 Aniket Maurya 来自 Celesto.ai（CelestoAI）。项目托管在组织名下，README 顶部同时挂了 CelestoAI 的品牌图和 docs.celesto.ai 文档站链接。

开源版本与商业版的边界在 README 里写得很清楚：开源部分（pip install agentor）搭载 Agentor 自己的 Agent 引擎，包含 durable 与 forkable runs；而观测能力（Observability）指向 Celesto 的托管服务——enable_tracing=True 需要 CELESTO_API_KEY。

这是一个清晰的"引擎开源、平台收费"的分层设计：核心执行能力完全本地可控，深度可观测性作为增值服务。

类比：像一套带"存档点"的游戏存档系统

普通 Agent 框架像即时战略游戏——单位一旦阵亡就没了。agentor 更像带存档的角色扮演游戏：每次运行（run）被持久化成一个只追加的事件日志（append-only event log），进程被 kill 掉也不影响。

这带来三个具体能力：

• resume —— 中断的运行可以从断点继续
• fork —— 把任意已持久化的运行（包括已完成的）分叉成一个全新的独立运行，保留完整 trace 和模型的推理过程，而父运行不受影响
• tracing —— 可追溯提示词、工具参数、工具结果与模型推理

fork 这个设计尤其聪明：它让"试试另一个思路"变成一次廉价的分支操作，而不是重跑。

核心功能：五个能力点

1. 装饰器式 MCP Server（自称"唯一完全 FastAPI 兼容的 MCP Server"）

from agentor.tools import GetWeatherTool
from agentor import Agentor

agent = Agentor(name="Weather Agent", model="gpt-5-mini", tools=[GetWeatherTool()])
result = agent.run("What is the weather in London?")
agent.serve()   # 一行变成 ASGI 应用

agent.serve() 返回的是普通 ASGI 应用，可以托管到任何跑 Python 服务的地方（Uvicorn/FastAPI 均可）。

2. Durable Runs 给 Agent 挂一个 store，每次运行即持久化。FileStore("runs") 是最简单的实现，也支持 Postgres（agentor[postgres]）。

3. Agent-to-Agent（A2A） 内置 a2a-sdk>=0.3.10，支持多 Agent 通信——这是 2026 年 Agent 框架的新标配。

4. Tool Search API "减少工具上下文膨胀"——当 Agent 有 50 个工具时，全部塞进 prompt 会烧掉大量 token 且降低选择精度。这个 API 让模型按需检索工具。

5. 任意 OpenAI 兼容提供商

agent = Agentor(name="Assistant", model="openrouter/auto",
                base_url="https://openrouter.ai/api/v1", api_key=...)

通过 base_url 指向任何说 /chat/completions 的服务：OpenRouter、Groq、Together、Fireworks、DeepSeek、vLLM、Ollama、Anthropic 与 Gemini 的兼容端点。底层用 LiteLLM 做路由。

上手门槛：pip 装完就能跑

pip install agentor                 # 基础安装
pip install "agentor[google]"       # GmailTool、CalendarTool
pip install "agentor[all]"          # 全部可选工具

可选 extras 设计得很克制：google（GmailTool/CalendarTool，约 100MB）、exa、git、github、slack、postgres、scrapegraph。README 明确说明这些工具在依赖缺失时会给出清晰的 ImportError 而不是静默失败。

环境要求：Python 3.11+，需要一个 LLM API Key。没有 Dockerfile、没有 compose——因为它是库而非独立服务。

争议与局限

• "唯一完全 FastAPI 兼容的 MCP Server"是自我宣称：这类 superlative 难以客观验证，读者应自行评估。
• 观测能力绑定商业服务：追踪功能需要 Celesto 的 API Key，开源版本能拿到完整的 durable/fork，但深度 tracing 要上云。对"数据不能出内网"的团队这是个真实的取舍。
• 贡献者数为 0：GitHub API 的 contributors 端点返回 0（仓库尚未被其他开发者提交过代码），README 显示项目由 Celesto 团队维护。技术路线会随公司战略调整。
• 依赖面较宽：litellm、mcp、a2a-sdk、fastapi、uvicorn、bm25s、pystemmer、typeguard 全在基础依赖里，安装体积和版本冲突风险高于轻量框架。
• Python 3.11+ 的硬性下限：不兼容 3.10 及以下。
• 项目年龄短：创建于 2025 年 6 月，API 仍在快速演进（README 提到 pip 装的是 v0.1.0 线）。

行业意义

agentor 最有价值的贡献，是把 "durable execution" 这个概念下沉到了开源 Python 生态。LangSmith（LangChain 系）、Langfuse 等商业可观测性平台能做类似的事，但那是 SaaS；agentor 让你在自己的进程里拥有事件溯源式的运行记录。

fork 语义尤其值得行业关注——它把 Agent 运行的版本控制做成了原语。想象一下：Agent 生成了一份方案，你 fork 出三个变体并行评估，最后选一个合并。类比 git，但对象是 Agent 运行。

而 Tool Search API 则直指 2026 年 Agent 工程的真实痛点：工具太多导致上下文膨胀。这个问题在 MCP 生态快速扩张后会变成普遍矛盾。

适合谁

适合：需要生产级 Agent（可恢复、可追溯、可分叉）的 Python 团队；想用同一套代码切换多个 LLM 提供商的开发者；自建 MCP 工具并需要 FastAPI 集成的前端/后端工程师；多 Agent 编排实验者。

不适合：只想要一个轻量 LLM 调用封装的开发者（这个框架太重）；完全不能接受任何数据出内网的场景（tracing 需上云）；非 Python 栈的团队。

一句话结论：把"生产级 Agent"最难的那部分——持久化、恢复、分叉、追踪——做成了可自托管的开源库，在 Python Agent 框架里工程完成度相当突出；代价是依赖面宽、观测能力需上云、且项目由单一团队主导。