CubePi vs pi-agent-core
pi-agent-core 是一个 TypeScript Agent 框架。CubePi 是同一套架构的 Python 独立重实现 —— 同样的线性 agent 循环(agent.ts + agent-loop.ts 对应 CubePi 的 agent.py + loop.py)—— 围绕 Pydantic v2、asyncio 原生原语和内置 checkpointing 重新构建。
所以这与其说是「谁更好」,不如说是「你在哪个生态」。如果你的技术栈是 TypeScript/Node,pi-agent-core 原生契合。如果你的技术栈是 Python,CubePi 给你同样的心智模型,而无需把 JS 运行时拖进你的服务里。
从 TypeScript 迁移到 Python
| pi-agent-core | CubePi | |
|---|---|---|
| 语言 / 运行时 | Node.js 上的 TypeScript | Python 3.11+ |
| 并发模型 | Promise / async-await | asyncio —— 异步优先,每个入口都是 async |
| 模式与校验 | TypeScript 类型(编译期) | Pydantic v2 模型 —— 工具参数运行时校验 |
| Agent 模型 | 线性 agent 循环(agent.ts + agent-loop.ts) | 同样的线性循环(agent.py + loop.py) |
| Provider | Provider 抽象 | Provider 协议 —— 内置 Anthropic 与 OpenAI |
同一套架构,Pythonic 的表层
CubePi 刻意保留了 pi-agent-core 的核心理念:agent 是一个循环,而不是一张图。改变的是表层。工具是普通的 async 函数,其参数是 Pydantic 模型,因此模型返回的参数会在运行时被校验,而不只是类型提示。流式输出是单个 async 迭代器。最终代码读起来像地道的 Python,而非把 TypeScript API 直译成 Python。
CubePi 在 Python 侧带来的增量
内置 checkpointing:追加式持久化层,提供 memory、SQLite、Postgres 后端,无论对话多长,每轮写入都是 O(1)。
原生 OpenTelemetry:Tracer 与 Meter 开箱即用地输出带 GenAI 语义约定属性的 OTel span,可导出到任意 OTLP 后端(Jaeger、Tempo、Honeycomb、Langfuse、Datadog……),并附带 cubepi trace CLI 用于本地 JSONL trace。
MCP 加载器(支持 HTTP 与 stdio 传输)、用于确定性测试的流式仿真 FauxProvider,以及精简的依赖足迹:核心依赖只有 pydantic、anthropic、openai,其余皆为可选 extra。
该怎么选
如果你的服务是 TypeScript/Node 并希望留在该运行时,选 pi-agent-core。如果你用 Python 构建,并想要同样的线性循环 agent 模型 —— 一等公民的 asyncio、Pydantic 校验的工具、追加式持久化、原生 OpenTelemetry —— 而不想在 Python 旁边再跑一个 JavaScript 运行时,选 CubePi。