Provider-agnostic LLM API
把 OpenAI/Anthropic/Google 等不同模型的鉴权、模型命名、流式输出与错误语义统一在一个抽象层，让上层只关注“消息、工具、输出”三件事，从而把切换供应商的成本降到配置层。
Pi Monorepo 把“做智能体”拆成可复用的基础件：上层用统一的多厂商 LLM API 做模型切换，中层用可工具调用的运行时编排状态与动作，下层提供 CLI/TUI/Web UI 与部署脚手架，把从原型到可交付的路径压缩成一套可组合的工作流。它适合把内部开发助手、运维自动化与交互界面放进同一仓库，用一致的配置与脚本让团队协作、测试与发布更可控。
| ✕传统痛点 | ✓创新方案 |
|---|---|
| 每家模型厂商的 API/鉴权/流式差异大，迁移成本高 | 用统一接口封装多家 LLM Provider，把模型选择与应用逻辑解耦 |
| Agent 工具调用、状态管理与 UI 往往散落在多个仓库，难以协同发布 | 把运行时、CLI、TUI/Web UI 与部署工具放在同一 Monorepo，以工作区脚本实现一致构建与检查 |
1git clone https://github.com/badlogic/pi-mono.git && cd pi-mono && npm install1npm run build && npm run check1./.test.sh # 或者 ./.pi-test.sh| 核心场景 | 目标人群 | 解决方案 | 最终收益 |
|---|---|---|---|
| 面向研发团队的终端开发助手 | 中大型研发团队 | 把代码问答、改动建议与任务分解放进统一的 coding agent CLI/TUI | 减少上下文切换，让评审与修复更快闭环 |
| 面向产品/平台的多模型适配层 | 做 AI 功能的产品平台团队 | 用统一 LLM API 封装多供应商差异 | 同一业务逻辑可按成本/合规/效果切换模型，降低供应商锁定风险 |
| 面向基础设施团队的推理交付工具链 | 负责推理服务的 Infra 团队 | 用 pods 工具管理 vLLM 部署与运行 | 更快把模型推理端点交付给内部应用，并标准化运维流程 |
