Forge：为本地大模型打造安全可靠的工具调用中间件

如果你正在本地部署大语言模型并且想让模型安全、可靠地调用外部工具比如搜索、计算、文件操作那么 Forge 这个项目值得你立刻关注。它不是另一个模型而是一个开源的“可靠性层”专门为本地模型提供工具调用的护栏和治理能力。简单说它能让你的本地 LLM 在调用工具时行为更可控、更安全、更稳定避免模型“乱来”或产生不可预知的风险。这个项目在 GitHub 上已经获得了超过 2.2k 的 stars核心价值在于它解决了本地模型工具调用的两大痛点安全隔离与流程可控。它不绑定特定模型理论上可以对接任何提供 OpenAI 兼容 API 的本地模型服务如 LM Studio、Ollama 部署的模型。对于开发者而言这意味着你可以在享受本地模型隐私和数据安全优势的同时为其赋予类似云端 API如 OpenAI 的 Function Calling那样结构化、可管理的外部工具调用能力。本文将带你快速了解 Forge 的核心能力、部署方式并通过实际测试验证其如何为本地模型调用工具加上“安全护栏”。我们会重点关注它的架构设计、与 LangChain 工具调用的区别、如何启动服务、如何进行功能测试以及在实际使用中需要注意的性能和边界问题。无论你是想构建完全离线的 AI 应用还是希望增强现有本地模型工作流的可靠性这篇文章都能提供直接的参考。1. 核心能力速览在深入细节之前我们先通过一个表格快速把握 Forge 项目的关键信息能力项说明项目类型开源模型工具调用可靠性中间件Reliability Layer核心功能为本地大语言模型提供安全、可控的工具调用Function Calling能力包括工具路由、输入/输出验证、执行隔离、错误处理和监控。对接模型任何提供 OpenAI 兼容 API 的本地模型服务如通过 Ollama, LM Studio, vLLM, Text Generation Inference 等部署的模型。硬件门槛无特定要求取决于你本地运行的基座模型。Forge 本身作为中间件资源消耗极低。启动方式提供 Docker 快速启动也支持源码部署Python。是否支持 API是。Forge 本身会暴露一个标准的 OpenAI 兼容 API你的应用调用 ForgeForge 再代理请求到你的本地模型并管理工具调用。是否支持批量任务支持通过 API 进行并发请求具备任务队列和基础监控能力。关键特性工具护栏严格定义工具可用边界防止模型越权操作。执行沙箱可选将工具执行在隔离环境中运行提升安全性。输入验证对模型生成的工具调用参数进行格式和内容校验。错误恢复工具执行失败时可配置重试或向模型反馈错误信息。适合场景1. 构建高可靠性的本地 AI Agent 或自动化工作流。2. 在敏感数据环境下为本地模型添加可控的外部能力扩展。3. 需要对比和评估不同本地模型工具调用效果的场景。2. 适用场景与使用边界Forge 的设计目标非常明确让本地模型的工具调用变得像云端服务一样可靠和安全。它主要适用于以下几类用户和场景适合谁用本地模型开发者/研究者希望测试和增强本地模型如 Llama、Qwen、DeepSeek的工具调用能力而不想从头搭建复杂的管理框架。企业内网应用开发者需要在数据不出域的前提下构建具备文件处理、数据查询、系统操作等能力的 AI 应用。AI Agent 爱好者想要搭建完全离线的个人助理能安全地执行如天气查询模拟、笔记整理、代码执行等任务。能解决什么问题安全性问题防止模型在调用工具时传入恶意参数或尝试执行危险操作如rm -rf /。稳定性问题当工具执行出错如网络超时、资源不存在时提供标准的错误处理和重试机制避免整个流程崩溃。可控性问题精确控制模型在某个会话中可以使用哪些工具以及工具的使用频率和顺序。可观测性问题提供工具调用的日志、监控和审计功能方便调试和复盘 Agent 的行为。不适合什么场景超轻量级单次调用如果你的需求只是让模型偶尔调用一次计算器直接使用 LangChain 或 LlamaIndex 的简单工具链可能更直接。无需安全隔离的场景如果工具本身完全可信且运行在高度可控的环境内Forge 的沙箱等安全特性可能显得冗余。对延迟极其敏感Forge 作为中间件会引入额外的网络跳转和处理开销。对于要求极低延迟的实时交互场景需要评估其性能影响。重要边界与合规提醒工具本身的安全性Forge 是“护栏”不是“万能药”。它管理工具调用的过程但工具本身的实现是否安全、是否有漏洞仍需开发者负责。例如一个“文件读取”工具需要在其内部做好路径遍历攻击的防护。模型与工具的授权确保你部署的本地模型和通过 Forge 调用的工具如内部 API、数据库拥有合法的使用授权。数据隐私虽然部署在本地但所有流经 Forge 的提示词、模型输出和工具调用数据都应被视为敏感信息需按照内部数据管理策略进行处理。3. 环境准备与前置条件部署和测试 Forge 之前你需要准备好以下环境。Forge 本身对环境要求不高核心依赖在于一个已经运行起来的本地大模型服务。1. 基础运行环境操作系统Linux (推荐 Ubuntu 20.04), macOS, 或 Windows (WSL2 推荐)。容器运行时如果使用 Docker 方式部署需要安装 Docker 和 Docker Compose。Python 环境如果使用源码部署需要 Python 3.9 和 pip。2. 本地模型服务必需这是 Forge 工作的前提。你需要先在本机或内网启动一个本地大模型并确保其提供OpenAI 兼容的 API 接口。常见的部署方式有Ollama最简单ollama run llama3.2后默认 API 在http://localhost:11434。LM Studio图形化界面启动模型后在设置中开启“本地服务器”通常地址为http://localhost:1234。vLLM / Text Generation Inference (TGI)适合高性能推理部署后提供兼容 API。请务必先验证你的本地模型 API 可以正常访问例如用 curl 测试curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: llama3.2, messages: [{role: user, content: Hello}], max_tokens: 10 }收到正常的 JSON 响应即表示模型服务就绪。3. 网络与端口Forge 服务会占用一个新的端口默认可能是8000或3000。确保该端口未被占用或者你懂得如何修改 Forge 的配置来更换端口。确保你的应用或测试客户端能够访问到运行 Forge 服务的机器和端口。4. 安装部署与启动方式Forge 提供了多种部署方式这里介绍最常用的两种Docker 快速启动和源码安装。4.1 方式一Docker 快速启动推荐这是最快捷、依赖最少的方式适合快速体验和测试。获取项目配置从 Forge 的 GitHub 仓库获取docker-compose.yml配置文件。git clone https://github.com/kyrolabs/forge.git cd forge如果网络问题也可以直接查看仓库中的docker-compose.yml示例并根据注释修改。配置环境变量关键步骤是告诉 Forge 你的本地模型 API 地址。编辑docker-compose.yml或创建一个.env文件。# 示例 docker-compose.yml 关键部分 version: 3.8 services: forge: image: kyrolabs/forge:latest ports: - 3000:3000 # 将宿主机的3000端口映射到容器内的3000端口 environment: - OPENAI_API_BASEhttp://host.docker.internal:11434/v1 # 重点指向本地模型服务 - OPENAI_API_KEYsk-no-key-required # 本地模型通常不需要key但字段需存在 # 其他配置...注意OPENAI_API_BASE的值。如果你的模型服务运行在宿主机的11434端口在 Docker 容器内需要通过host.docker.internal这个特殊域名来访问宿主机。如果你使用 Linux 或网络模式不同可能需要改为宿主机的真实 IP。启动 Forge 服务docker-compose up -d使用docker logs -f forge查看启动日志确认无报错。验证服务访问http://localhost:3000/health或调用其 API 端点检查是否返回成功信息。curl http://localhost:3000/health # 预期返回{status:ok}4.2 方式二源码安装与启动适合需要深度定制或开发的用户。克隆代码与安装依赖git clone https://github.com/kyrolabs/forge.git cd forge pip install -e . # 或者根据项目要求 pip install -r requirements.txt配置环境变量同样需要设置模型 API 地址。# Linux/macOS export OPENAI_API_BASEhttp://localhost:11434/v1 export OPENAI_API_KEYsk-no-key-required # Windows (PowerShell) $env:OPENAI_API_BASEhttp://localhost:11434/v1 $env:OPENAI_API_KEYsk-no-key-required启动服务根据项目说明启动 Forge 应用。可能是python -m forge.app # 或 uvicorn forge.main:app --host 0.0.0.0 --port 3000服务启动后同样通过http://localhost:3000/health验证。无论哪种方式启动成功后Forge 就作为一个代理服务运行起来了。你的应用程序不再直接请求本地模型如http://localhost:11434而是请求 Forge 的地址如http://localhost:3000。Forge 会接收请求与模型交互管理其中的工具调用流程最后将结果返回给你的应用。5. 功能测试与效果验证现在Forge 服务已经运行并连接到了你的本地模型。我们来测试它的核心功能工具调用。测试将围绕一个经典场景展开让模型使用“计算器”工具。5.1 定义并注册工具首先我们需要告诉 Forge 有哪些工具可用。Forge 通常通过一个配置文件或 API 来注册工具。这里以编写一个简单的 Python 工具定义文件为例。创建工具定义文件tools.py# tools.py from forge.sdk import Tool, tool tool class CalculatorTool(Tool): 一个简单的计算器工具用于执行基础数学运算。 name calculator description 执行数学计算。输入一个包含数字和运算符 - * /的字符串表达式。 parameters { type: object, properties: { expression: { type: string, description: 数学表达式例如 3 5 * (2 - 1) } }, required: [expression] } async def execute(self, expression: str) - str: 执行计算。注意使用 eval 仅用于演示在生产环境中极其危险必须替换为安全的解析器。 try: # 警告实际生产环境严禁使用 eval此处仅为演示。 # 应使用 ast.literal_eval 或自定义安全计算库。 result eval(expression) return f计算结果: {result} except Exception as e: return f计算错误: {e}重要安全警告上述代码中的eval函数仅用于演示在实际生产环境中使用会带来严重的安全风险代码注入。你必须将其替换为安全的数学表达式解析器如ast.literal_eval处理有限操作或使用numexpr、sympy等库。让 Forge 加载工具具体方式取决于 Forge 的版本和配置。可能需要将工具类放在特定的目录下Forge 自动扫描。通过环境变量指定工具模块。通过启动参数加载。 请查阅 Forge 项目的最新文档了解如何注册自定义工具。假设我们通过环境变量FORGE_TOOLS_MODULEtools让 Forge 加载了我们的tools.py模块。5.2 测试工具调用流程现在我们模拟一个客户端向 Forge 发起一个聊天请求并观察它如何引导模型使用我们注册的计算器工具。构造请求向 Forge 的/v1/chat/completions端点发送请求这与直接请求 OpenAI 或本地模型 API 格式一致但关键是要在tools参数中列出可用的工具。curl -X POST http://localhost:3000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-no-key-required \ -d { model: llama3.2, # 这个模型名会传递给后端的本地模型 messages: [ {role: user, content: 请计算一下 15 乘以 28 再加上 7 等于多少} ], tools: [ { type: function, function: { name: calculator, description: 执行数学计算。输入一个包含数字和运算符 - * /的字符串表达式。, parameters: { type: object, properties: { expression: { type: string, description: 数学表达式例如 \3 5 * (2 - 1)\ } }, required: [expression] } } } ], tool_choice: auto, # 让模型决定是否调用工具 max_tokens: 500 }分析响应第一次模型通过 Forge可能会返回一个要求调用工具的响应。{ id: chatcmpl-..., choices: [{ index: 0, message: { role: assistant, content: null, tool_calls: [{ id: call_..., type: function, function: { name: calculator, arguments: {\expression\: \15 * 28 7\} } }] }, finish_reason: tool_calls }] }这表明模型决定调用calculator工具并生成了参数15 * 28 7。Forge 的执行与返回此时Forge 会拦截这个响应。它会验证检查calculator工具是否已注册参数格式是否符合定义。执行在安全上下文如果配置了沙箱中调用tools.CalculatorTool.execute(expression15 * 28 7)。处理结果获取工具执行结果计算结果: 427。组织后续请求Forge 会自动将工具执行结果作为一条新的tool角色消息连同之前的对话历史再次发送给本地模型让模型生成最终面向用户的回答。最终响应客户端最终会收到一个包含模型最终回答的响应。{ id: chatcmpl-..., choices: [{ index: 0, message: { role: assistant, content: 根据计算15 乘以 28 等于 420再加上 7最终结果是 427。, tool_calls: null }, finish_reason: stop }] }至此一次完整的、由 Forge 管理的工具调用流程完成。用户看到的是最终答案而背后的工具调用、错误处理、多轮交互均由 Forge 透明地管理。5.3 测试错误处理为了验证 Forge 的“护栏”作用我们可以测试一个错误场景。发送一个会导致工具出错的请求... # 同上一个curl请求修改用户消息为 -d { ... messages: [ {role: user, content: 请计算一下 10 除以 0 是多少} ], ... }观察响应如果我们的calculator工具实现中eval遇到除零错误会返回计算错误: division by zero。Forge 会将该错误信息反馈给模型。一个足够聪明的模型可能会在最终回答中表示“除以零是未定义的”。而如果模型仍然坚持错误调用Forge 可以根据配置决定是否重试或终止会话防止无限循环。这体现了其错误处理和流程控制能力。6. 接口 API 与批量任务Forge 的核心价值通过其 API 体现。它完全兼容 OpenAI API 格式这意味着任何能调用 OpenAI 的代码库或工具如 LangChain, LlamaIndex, OpenAI SDK都能无缝切换到 Forge只需修改base_url。6.1 标准 API 调用示例Pythonimport openai from openai import OpenAI # 将客户端指向 Forge 服务 client OpenAI( base_urlhttp://localhost:3000/v1, # Forge 的地址 api_keysk-no-key-required # 本地服务通常不需要有效的key ) # 定义可用的工具 tools [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气, parameters: { type: object, properties: { location: {type: string, description: 城市名}, unit: {type: string, enum: [celsius, fahrenheit]} }, required: [location] } } } ] # 发起聊天请求允许模型调用工具 response client.chat.completions.create( modelllama3.2, # 此模型名会传递给后端 messages[{role: user, content: 北京现在天气怎么样}], toolstools, tool_choiceauto, ) message response.choices[0].message print(message) # 处理工具调用在实际的流式或自动Agent中这部分由Forge自动完成 # 此处演示原理如果消息包含 tool_calls则需要执行工具并将结果追加回对话。 if message.tool_calls: # 模拟工具执行结果 tool_result 北京当前天气晴朗气温 22 摄氏度。 # 接下来需要将 tool_result 作为新的消息连同历史消息再次发送给模型。 # Forge 自动完成了这整个循环。6.2 批量任务处理Forge 本身并不直接提供一个“批量任务上传界面”但其 API 特性使得实现批量处理非常容易。方案一并发请求由于 Forge 是一个 HTTP 服务你可以使用异步客户端并发发送多个请求。import asyncio import aiohttp import json async def ask_forge(session, prompt): async with session.post( http://localhost:3000/v1/chat/completions, json{ model: llama3.2, messages: [{role: user, content: prompt}], max_tokens: 100 }, headers{Authorization: Bearer sk-no-key-required} ) as resp: return await resp.json() async def main(): prompts [问题1, 问题2, 问题3] # 你的批量问题列表 async with aiohttp.ClientSession() as session: tasks [ask_forge(session, p) for p in prompts] results await asyncio.gather(*tasks) for r in results: print(r[choices][0][message][content]) # asyncio.run(main())方案二利用 Forge 的潜在队列特性关注 Forge 项目的更新它可能在未来版本中集成更强大的任务队列和批处理功能。目前你可以使用像CeleryRedis或RQ这样的外部队列系统将任务排队由工作进程消费并调用 Forge API。6.3 与 LangChain 集成如果你已经在使用 LangChain集成 Forge 非常简单只需将 LLM 的base_url指向 Forge。from langchain_openai import ChatOpenAI from langchain.agents import initialize_agent, Tool from langchain.chains import LLMMathChain # 1. 初始化指向 Forge 的 LLM llm ChatOpenAI( modelllama3.2, # 任意名称会传递给Forge openai_api_basehttp://localhost:3000/v1, openai_api_keysk-no-key-required, temperature0 ) # 2. 定义 LangChain 工具注意这些工具的定义需要与在 Forge 中注册的工具协调 # 假设 Forge 已经管理了一个计算器工具这里可以是一个简单的包装器 def calculator_wrapper(expression: str) - str: # 这里可以包含直接调用 Forge API 进行工具调用的逻辑 # 更优雅的方式是让 LangChain Agent 的 LLM 通过 Forge 来调用工具。 # 本例展示一种混合思路简单工具直接本地执行复杂或需安全隔离的工具通过 Forge。 try: # 安全计算示例替换危险的 eval import ast import operator # 使用 ast.literal_eval 进行简单安全计算有限制 # 生产环境应用更完善的库 node ast.parse(expression, modeeval) # ... 安全评估逻辑 ... return fResult: {eval(expression)} # 再次强调仅演示 except Exception as e: return fError: {e} tools [ Tool( nameCalculator, funccalculator_wrapper, description用于计算数学表达式。输入一个字符串例如 3 5 * 2。 ), ] # 3. 创建 Agent。此时Agent 的 LLM 是连接到 Forge 的。 # Forge 会处理 LLM 产生的工具调用意图。 agent initialize_agent(tools, llm, agentzero-shot-react-description, verboseTrue) # 4. 运行 agent.run(15乘以28再加7等于多少)关键理解在这种集成中LangChain Agent 负责推理和决定使用哪个工具根据 description。当 Agent 的 LLM即指向 Forge 的ChatOpenAI实例输出一个工具调用动作时这个动作会被 LangChain 框架执行调用本地的calculator_wrapper函数。如果你想完全利用 Forge 的工具管理、沙箱和安全特性最佳实践是将工具的具体实现也注册到 Forge 端并确保 LangChain Agent 的工具描述与 Forge 中的工具定义一致让模型通过 Forge 的流程来调用。这可能需要定制 LangChain 的 Agent 执行器。7. 资源占用与性能观察Forge 作为中间件其本身的资源消耗非常低主要开销在于网络转发和少量的逻辑处理。性能瓶颈通常出现在两个地方本地模型推理速度和工具执行时间。Forge 服务本身资源占用CPU/内存通常可以忽略不计。在 Docker 容器中空闲时可能仅占用几十 MB 内存和个位数百分比的 CPU。网络延迟Forge 在客户端和本地模型之间增加了一次网络跳转。在本地环路localhost中这个延迟增加通常小于 1 毫秒可忽略。但在跨主机部署时需要考虑。端到端延迟分析 一次完整的工具调用请求的延迟 客户端到 Forge 的网络时间Forge 处理时间Forge 到本地模型的网络时间模型生成时间可能包含多轮工具执行时间。模型生成时间这是最大的变量取决于模型大小、你的硬件和生成 token 的数量。工具执行时间如果你的工具需要访问网络 API如查询数据库、调用外部服务这部分时间可能很长。多轮交互如果模型第一次调用工具的结果不理想Forge 可能会组织新一轮的模型调用这会增加总时间。监控建议查看日志Forge 通常会输出结构化日志记录每个请求的 ID、模型响应时间、工具调用详情和错误信息。启动时注意观察日志级别。使用 APM 工具对于生产环境可以考虑将 Forge 与 Prometheus、Grafana 或 OpenTelemetry 集成以监控请求速率、延迟分布和错误率。压力测试使用像wrk或locust这样的工具模拟并发用户向 Forge 发送请求观察其在不同负载下的响应时间和资源使用情况。性能优化方向模型层面使用量化模型、更高效的推理后端如 vLLM来加速模型响应。工具层面优化工具本身的执行效率对耗时工具考虑异步或缓存。Forge 配置根据文档调整 Forge 的并发 workers 数量、请求超时时间等参数。8. 常见问题与排查方法在部署和使用 Forge 过程中你可能会遇到以下问题问题现象可能原因排查方式解决方案Forge 服务启动失败1. 端口被占用。2. 依赖包缺失或版本冲突。3. 环境变量配置错误。1. 查看 Docker 或应用日志 (docker logs forge)。2. 检查OPENAI_API_BASE等环境变量是否正确设置。1. 更换端口或关闭占用端口的进程。2. 根据日志安装缺失依赖或解决冲突。3. 核对环境变量确保指向可访问的本地模型 API。访问/health正常但调用聊天 API 返回错误1. 本地模型服务未运行或不可达。2. 传递给 Forge 的model参数与后端模型不匹配。3. 网络策略防火墙、Docker 网络阻止连接。1. 直接 curl 测试本地模型 API 是否正常。2. 检查 Forge 日志看其转发请求时是否收到模型端的错误。1. 确保本地模型服务已启动并监听正确端口。2. 确认model参数名对于 Ollama 通常是模型名对于 LM Studio 可能是gpt-3.5-turbo模拟。3. 在 Docker 内尝试 curl 模型地址检查网络连通性。模型不调用工具直接回复1. 工具定义 (tools参数) 未在请求中提供或格式错误。2. 模型能力不足不理解工具调用格式。3.tool_choice参数设置为none。1. 检查请求 JSON 中tools数组是否正确。2. 使用简单的提示词和工具如计算器测试模型的基础工具调用能力。3. 确保tool_choice是auto或{type: function, function: {name: xxx}}。1. 修正工具定义确保name,description,parameters字段完整。2. 尝试更换一个已知工具调用能力更强的模型如 GPT-4 微调模型、Qwen2.5-Coder 等。3. 调整tool_choice参数。工具调用被 Forge 拒绝1. 工具在 Forge 端未正确注册。2. 模型生成的工具参数不符合 JSON Schema 定义。3. 工具执行时抛出未处理异常。1. 查看 Forge 日志通常会有详细的验证错误信息。2. 检查模型返回的arguments字符串是否是合法的 JSON。1. 确认工具类已被 Forge 加载。2. 在工具定义中使用更宽松的 Schema或增强模型的提示工程使其输出更规范的 JSON。3. 在工具代码中添加完善的异常捕获和日志。请求超时1. 模型推理时间过长。2. 工具执行时间过长如网络请求。3. Forge 或客户端设置的超时时间太短。1. 观察模型服务本身的负载和响应时间。2. 检查工具实现是否有阻塞或慢操作。1. 调整模型推理参数如max_tokens。2. 优化工具性能或将其改为异步。3. 增加客户端和 Forge 服务的超时设置。Docker 容器内无法连接宿主机的模型服务Docker 容器网络隔离。在容器内执行curl http://host.docker.internal:PORT测试。使用host.docker.internalMac/Windows或--networkhost模式Linux运行 Docker 容器或使用宿主机 IP 地址。9. 最佳实践与使用建议为了稳定、高效、安全地使用 Forge建议遵循以下实践从小处开始逐步验证首先部署一个最简单的工具如计算器、回显工具确保整个链路客户端 - Forge - 本地模型 - 工具执行 - 返回能跑通。再逐步添加更复杂的工具和业务逻辑。工具设计与安全第一输入验证不仅在 Forge 的 Schema 层做验证在工具的执行函数内部也要对输入进行严格的校验和清洗。避免eval如示例所示绝对不要在工具实现中使用eval、exec等函数。使用安全的解析库或白名单机制。权限最小化工具只应拥有完成其功能所必需的最小系统权限。例如文件操作工具应限制在特定目录。利用 Forge 的沙箱功能如果支持对于执行不确定或潜在风险代码的工具如代码执行、Shell 命令务必配置 Forge 在沙箱如 Docker 容器、gVisor中运行它们实现物理隔离。清晰的工具描述工具的name和description要清晰准确。模型的工具调用能力很大程度上依赖于这些描述。好的描述能显著提升模型选择正确工具和生成正确参数的几率。模型提示工程在发送给模型的系统提示systemmessage中可以明确说明可用的工具及其用途引导模型更好地利用它们。日志与监控启用 Forge 的详细日志记录每一次工具调用的输入、输出和耗时。这对于调试 Agent 行为和优化性能至关重要。考虑将日志接入 ELK 或类似系统便于查询和分析。版本管理将你的工具定义、Forge 配置文件和模型部署配置进行版本控制如 Git。这有助于回滚和团队协作。合规与审计如果工具会处理用户数据或执行重要操作确保有审计日志记录“谁在什么时候通过哪个模型调用了什么工具输入输出是什么”。Forge 项目正在快速发展其架构和功能可能会持续演进。本文基于其作为“可靠性层”的核心定位和常见使用模式进行阐述。在实际部署时请务必参考其官方 GitHub 仓库的最新文档和示例以获取最准确的配置和 API 信息。通过将 Forge 引入你的本地模型技术栈你可以在享受本地化部署的数据隐私和成本优势的同时为你的 AI 应用构建起一道坚固、可控的工具调用防线。