egg-toolbox：为本地大模型统一工具调用能力的开源中间件

egg-toolbox 是一个开源的 OpenAI 兼容 API 中间件，让任何支持工具调用模板格式的本地大模型都能获得结构化工具调用能力，无需针对 OpenAI 格式进行微调。

本地部署大语言模型（LLM）已成为许多开发者和企业的首选方案，既能保护数据隐私，又能降低 API 调用成本。然而，不同推理后端（如 vLLM、SGLang、llama.cpp、tinygrad）对工具调用（Tool Calling）的支持程度参差不齐，而且每当有新模型发布时，各个后端都需要单独适配，这导致了重复工作和漫长的等待周期。

更棘手的是，许多优秀的开源模型（如 Qwen、DeepSeek、Llama 3 等）虽然在对话模板中支持工具调用格式，但并未针对 OpenAI 风格的 tool_calls 输出进行微调。这意味着开发者无法直接在这些模型上使用 OpenAI 兼容的工具调用 API。

egg-toolbox 正是为解决这一痛点而生。它是一个纯 Python 实现的通用工具调用中间件，作为 OpenAI 兼容的 API 服务器运行，可以为任何支持工具调用模板格式的模型添加结构化工具调用能力——无需模型针对 OpenAI 格式进行微调。

这个项目的雄心壮志是成为所有主流本地推理引擎的默认工具调用前端。通过 egg-toolbox，为新发布的模型添加工具支持变成了一次性工作，所有后端（tinygrad、vLLM、SGLang、llama.cpp）可以同时受益。

egg-toolbox 采用了一种极其聪明的设计：每种工具调用格式（Hermes、Llama 3、Mistral、DeepSeek、Command-R、Functionary 等）都有一个独立的状态机解析器，用纯 Python 实现，不依赖任何后端。这意味着当你需要支持一个新的模型家族时，只需编写一次格式处理器，所有后端都能立即使用。

项目定义了两个抽象后端接口：

• StepBackend：适用于逐 token 生成的引擎（如 tinygrad、llama-cpp-python）
• ConstraintBackend：适用于批处理引擎（如 vLLM、SGLang）

这种设计让同一个格式层可以适配两种完全不同的解码风格。语法/约束注入和流式解析发生在请求边界，而不是解码循环内部，因此在批处理引擎上的开销几乎为零。

egg-toolbox 内部使用 SemanticEvent 作为通用中间表示层。OpenAI 和 Anthropic 的格式都是这个 IR 的无损投影。工具调用解析使用每种格式的状态机解析器（而非正则表达式），确保流式行为正确。

项目采用分阶段开发策略：

第一阶段（已完成）：类型系统、模板引擎、流式解析器、tinygrad 后端、OpenAI 兼容的 /v1/chat/completions 端点（支持流式和非流式）、token 用量统计、tool_choice 支持、错误处理等。

第二阶段（进行中）：格式处理器。目前已完成 Hermes、Llama 3、Mistral、DeepSeek、Command-R、Functionary（v3 + v3.1）和 Generic 处理器。Harmony（OpenAI gpt-oss 多通道）格式正在开发中。

第三阶段（计划中）：vLLM、SGLang 和 llama-cpp-python 后端支持。

第四阶段（计划中）：GBNF 语法生成、Anthropic /v1/messages 投影、完整的差异模板分析检测器、并行工具流式传输、语法引导的推测解码。

安装非常简洁，支持可编辑模式安装：

python3 -m venv .venv
source .venv/bin/activate
pip install -e "./egg-toolbox[tinygrad,dev]"

启动服务器只需一行命令：

python -m egg_toolbox path/to/model.gguf --backend tinygrad --host 127.0.0.1 --port 8000