Functionary：可控工具调用的对话语言模型
Functionary 是一个能解读并执行函数/插件的语言模型，自动决定何时调用工具、并行或串行执行，并理解工具返回的结果。
- Star 数
- ★ 1.6k
- 最近更新
- 3 个月前
- License
- MIT
- 主语言
- Python
- FA 评分
- 30/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 平台专用OpenAI API
- 费用
- 免费，无需付费服务
- 上手难度
- 高 · 需要较重的基础设施
- 开始前需要
- 典型场景
- 希望为聊天机器人添加查询天气、调用内部 API 等功能的开发者。
- 不适合
- 需要长期维护和支持的生产团队，项目已弃用且不再修复问题
- 只有单张消费级显卡的用户，中等模型需 4×A6000 或 2×A100 80GB
- 希望开箱即用、无需自行部署推理服务器的用户
这个 Agent 能做什么，适合哪些场景？
Functionary 是一个由 MeetKai 开发的语言模型，专注于函数调用。它能够根据用户指令判断是否调用工具以及如何调用，支持并行调用和基于工具结果的响应生成。项目已弃用，但提供了多种模型版本，例如 meetkai/functionary-v4r-small-preview 和 functionary-medium-v3.1。部署方式包括 vLLM、SGLang 和 TGI 服务器，并提供 OpenAI 兼容的 API 接口。尽管项目不再维护，但代码和文档仍具有参考价值。
Functionary 根据用户消息和提供的 JSON Schema 格式的工具定义，利用模型判断是否需要调用工具以及调用哪些工具，生成包含函数名和参数的 tool_calls。它支持并行调用，并能理解工具执行结果，进而生成自然的回复。部署后，通过 OpenAI 兼容的 /v1/chat/completions 接口接收请求，返回标准的聊天补全响应。
- 希望为聊天机器人添加查询天气、调用内部 API 等功能的开发者。
- 需要让模型根据用户请求自动调用多个工具（如查询航班和酒店）的场景。
- 需要模型在调用工具后根据结果生成连贯回复的客户支持系统。
- 作为研究工作，分析函数调用模型的设计与实现。
- 需要本地部署 LLM 服务，且希望使用 OpenAI 兼容接口的团队。
如何安装或部署这个 Agent？
项目已弃用，README 提供了安装步骤：1. 克隆仓库；2. 使用 pip 安装依赖，vLLM 版本执行 pip install -e .[vllm]，SGLang 版本执行 pip install -e .[sglang] --find-links ...。
如何使用这个 Agent？
部署服务器：使用 vLLM 启动 python3 server_vllm.py --model "meetkai/functionary-v4r-small-preview" --host 0.0.0.0 --port 8000 --max-model-len 8192。然后通过 OpenAI 客户端调用，设置 base_url="http://localhost:8000/v1" 和 api_key="functionary"，发送包含 messages 和 tools 的 chat.completions 请求。
这个 Agent 有哪些优点和局限？
- 支持并行函数调用和代码解释器，功能丰富。
- 在 Berkeley Function-Calling Leaderboard 中排名第二，性能表现优秀。
- 提供 OpenAI 兼容接口，易于集成现有应用。
- 支持多种部署后端：vLLM、SGLang、TGI，可根据需求选择。
- 项目已正式弃用，不再维护，无后续更新和缺陷修复。
- 中等模型需要多 GPU（如 4×A6000），硬件成本高。
- GGUF 模型在 llama.cpp 的集成可能滞后，需使用特定脚本。
- 依赖特定推理服务，不是开箱即用的独立应用。
这个 Agent 与同类方案有什么区别？
README 将 Functionary 与 NexusRaven、Gorilla、Glaive 和 GPT-4-1106-preview 进行了对比，突出其支持多轮对话、缺失参数追问、基于工具结果生成回答等特点。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Functionary：可控工具调用的对话语言模型 当前 | 30 · 缺口较多 | 自托管服务免费 | ★ 1.6k | 3 个月前 | Python | OpenAI API |
| LLM-in-Sandbox | 52 · 缺口较多 | 命令行工具免费 + 模型费 | ★ 245 | 1 个月前 | Python | OpenAI API · Claude API |
| Forge：自托管 LLM 工具调用的可靠性层 | 49 · 缺口较多 | 命令行工具免费 + 模型费 | ★ 2.3k | 4 天前 | Python | OpenAI API · Claude API |
| Qwen-Agent | 42 · 缺口较多 | 代码库 / SDK免费 + 模型费 | ★ 17k | 7 个月前 | Python | — |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示：仓库未提供权限管理、用户确认、数据流透明、敏感数据处理、依赖安全、外部影响、回滚或来源归属的说明。所有信任相关标准均无证据支持，因此得分为0。
证据显示：README和测试文件提供了部分一致性证据，如测试用例和提示模板测试，但未提供失败消息处理或依赖可用性保证。自一致性得1分，依赖可用性得1分，失败消息得0分。
证据显示：README提供了多种部署场景和模型选择，但未明确能力边界或触发精度。受众和场景得2分，能力边界得1分，触发精度得1分，环境适配得1分。
证据显示：README提供了安装说明、示例和模型列表，但缺少已知限制、版本变更日志和维护责任说明。信息架构得2分，安装说明得2分，命名稳定性得1分，示例和FAQ得2分，已知限制得1分，许可证得2分，版本变更日志得1分，维护责任得1分。
证据显示：README提供了使用示例和输出格式，但未提供性能基准或成本效益分析。输出可用性得2分，边际价值得2分，成本效益得1分。
证据显示：README中的声明部分有测试支持，但缺乏独立验证和事实与推断的区分。声明可追溯性得1分，跨来源佐证得1分，事实推断分离得1分。
- 源码中未见：最小权限约束只授予完成任务所需的权限：用专用账号或只读令牌，并限定可访问的目录和仓库。
- 源码中未见：执行前用户确认开启或自行加上执行前确认；先在沙箱或测试环境跑通，确认行为后再接入真实数据。
- 源码中未见：数据流向说明运行时观察它连接了哪些外部服务（代理或防火墙日志）；弄清数据去向之前不要输入敏感数据。
- 源码中未见：敏感信息处理使用专用、低权限、可随时吊销的 API 密钥，不要复用生产凭据，也不要让密钥出现在日志里。
- 源码中未见：依赖安全审查安装前固定版本并做一次依赖扫描（如 npm audit、pip-audit）；优先放在容器里运行。
- 源码中未见：外部影响披露先弄清它会写入、发送或修改哪些外部系统，用测试账号或测试仓库验证后再接入正式环境。
- 源码中未见：回滚或恢复路径运行前先备份，或在 git 分支、快照上操作，确保改动可以撤销。
- 源码中未见：来源归属可核验从官方仓库或包源安装，核对发布者和仓库地址，避免同名仿冒包。
- 仓库已弃用，代码和文档可能过时，不应在生产环境中使用。
- 未提供安全审计或权限管理说明，使用前需自行评估风险。
- 依赖项版本固定，但未提供安全漏洞扫描或更新策略。