函数调用

做智能体最烦的一类错：模型调用工具时返回了格式不对的 JSON，你的解析器当场崩。Pydantic AI 的思路是把 Pydantic 数据模型直接当工具描述，让类型系统替你兜住这件事。 类型安全的工具该怎么写？ 定义工具时，参数用一个 Pydantic Model 描述，框架自动把它转成模型能懂的 schema，并在返回时用同一个 Model 解析、校验。对不上就报错重试，而不是把脏数据塞进你的业务代码。这和手写 JSON Schema、再手写解析是两种可靠度——前者类型一致，后者全靠人肉同步。 一个查订单工具长什么样？ 比如做查订单工具：定义一个订单查询模型，含订单号、日期范围，把它注册成工具。模型返回后，框架直接给你一个类型安全的对象，你在代码里可以放心访问字段，不用写一堆异常处理去防半截 JSON。 它和编排框架怎么分工？ Pydantic AI 偏「单智能体加强类型工具」，不做大而全的多智能体编排。它最适合那种「一个智能体要调一堆结构化工具、且输出必须进业务库」的场景——比如自动查数据、填表、发工单。 自动兜底有什么隐患？ 强类型会让工具描述变长，因为每个字段都要解释清楚。提示词里把每个字段的取值范围写明白，模型才不会瞎填。另外，复杂嵌套模型别设计得太深，模型填深层结构时出错率会上升，能拍平就拍平。 它和原生 JSON 模式差在哪？ 很多模型本身提供结构化输出或 JSON 模式，为什么还要 Pydantic AI？区别在于：原生模式只保证语法合法，不保证语义对——字段可以是格式正确但内容荒谬的字符串。Pydantic 的价值在运行时校验后还能把错误结构化地喂回给模型，让它自己修正，而不是你接住一个解析异常后干瞪眼。对要写库的场景，这层二次校验值得多花一点调用成本。 什么场景必须上类型安全？ 如果你的智能体输出要进数据库、要被下游程序消费，类型安全就不是洁癖，是必需。Pydantic AI 用你已经熟悉的 Pydantic 语法把这件事解决了——少写一堆解析胶水，多一层运行时校验。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：PydanticAI

问题不在模型，在工具说明书 很多人抱怨「我的 Agent 老乱调工具、参数瞎填」，第一反应是模型不够聪明。但拆开日志看，真相往往是：工具的 JSON Schema 写得太烂。模型决定调哪个函数、填什么参数，依据的就是你给它的那段描述。你把 city 参数写成一个字符串，不写枚举、不写单位、不写默认值，它当然会把「北京」写成「beijing」、把温度单位填成「摄氏度」——它只能猜。 好 Schema 的三个零件 OpenAI、Anthropic、国产模型的 function calling 都基于 JSON Schema，写好一个工具描述要三样东西： 第一，description 写成「合同」而不是「标题」。别写「查询天气」，要写「根据城市名和日期查询天气预报，返回温度与降水概率；city 必须是中文城市名，date 格式为 YYYY-MM-DD，不填默认今天」。模型是照着这段文字做决策的，越具体越不容易跑偏。 第二，枚举和约束写死：city 用 enum 限定常见城市，unit 限定 ["celsius", "fahrenheit"]，数值参数加 minimum/maximum。约束越死，自由发挥空间越小，幻觉越少。 第三，必填与可选分清：required 字段只放真正必填的，可选字段给 example。一次工具调用失败，七成是必填参数没传或传错类型。 反例 正例 city: 城市名 city: 中文城市名，如「北京」，枚举限定 date: 日期 date: YYYY-MM-DD，缺省今天 不说明返回值 写明返回温度(℃)、降水概率(%) 三个落地补丁 第一，加一层参数校验与重试：工具执行前用 Pydantic 校验参数，失败就把错误信息回喂给模型让它自己修正，比直接报错断掉友好得多。第二，一个工具只干一件事：别写 do_everything(action, params) 这种万能函数，拆成 search_order、refund_order、create_order，模型选错工具的概率直线下降。第三，本地小模型也能调工具：Qwen2.5、GLM-4 这类开源模型都原生支持 function calling，Ollama 跑本地模型时在 API 里传 tools 字段即可，不必迷信云端大模型。 收束 工具调用不是模型单方面的事，是你和模型之间的一次接口约定。Schema 写得像合同，模型就是听话的执行者；写得像口号，它就自由发挥给你看。把 description、枚举、必填这三样做扎实，Agent 的工具调用成功率能肉眼可见地从「经常翻车」提到「基本靠谱」。 去论坛讨论 关于「工具调用」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。 ...

函数调用：智能体的核心能力 函数调用（Function Calling）是LLM从"聊天机器人"进化为"智能体"的关键能力。Hermes 4在这一维度上做了深度优化，将函数调用的准确率从78%提升到了94%以上。本文剖析其背后的技术细节。 函数调用的三个层次 层次一：格式约束（Format-Level） 最基础的层次——确保模型输出符合可解析的函数调用格式： // 期望格式 { "tool": "search_web", "parameters": { "query": "2026年AI最新进展", "num_results": 5 } } 早期模型依赖严格的格式提示词和后处理来保证格式正确性： # 传统格式约束方法 FORMAT_PROMPT = """ 你必须以严格的JSON格式回复，不要添加任何其他文本。 格式示例： {"tool": "<函数名>", "parameters": {<参数键值对>}} 可用函数： - search_web(query: str, num_results: int): 搜索网页 - send_email(to: str, subject: str, body: str): 发送邮件 """ def parse_tool_call(response): """脆弱的JSON解析，需要大量容错处理""" try: # 尝试从回复中提取JSON json_str = extract_json(response) call = json.loads(json_str) return validate_call(call) except: # 格式错误时的降级处理 return fallback_parse(response) 这种方法的问题在于：模型并不"理解"函数的用途，只是在模仿格式。 层次二：语义理解（Semantic-Level） Hermes 4的核心突破在于让模型真正理解函数的语义——什么情况下该调用哪个函数、参数应该如何填充： # Hermes 4 的语义级函数调用 class HermesFunctionCaller: def __init__(self, model, tool_registry): self.model = model self.tools = tool_registry async def call(self, user_request, context=None): # 1. 语义路由：理解用户意图，匹配最合适的函数 intent = await self.model.understand_intent(user_request) candidate_tools = self.tools.match(intent) # 2. 参数推理：从对话中推理参数值 for tool in candidate_tools: args = await self.model.infer_arguments( tool_schema=tool.schema, user_request=user_request, context=context ) # 3. 完整性验证：检查必填参数 missing = tool.check_required(args) if missing: # 主动追问缺失信息 return {"status": "need_info", "missing": missing} # 4. 类型验证：确保参数类型正确 if tool.validate_types(args): return {"status": "ready", "tool": tool.name, "args": args} return {"status": "no_match"} 层次三：链式编排（Orchestration-Level） 最复杂的层次——根据用户目标自动编排多步函数调用： ...

两条路线的分歧 当我们要让AI Agent调用外部工具时，面前有两条主要路线：传统的函数调用（Function Calling）和新生的MCP协议。社区里关于"哪个更好"的讨论从未停止，但真实情况比非此即彼复杂得多。 函数调用：简单直接 函数调用的思路很直接：在Prompt中告诉模型有哪些函数可用，模型根据用户意图生成结构化的函数调用请求，应用层执行函数并把结果返回给模型。 优势显而易见： 实现简单，几乎所有主流模型都原生支持 延迟低，无需额外的协议层 开发者控制力强，函数定义和执行完全在应用内闭环 但问题也很明显： 厂商绑定：不同模型的函数调用格式不统一，从OpenAI切换到Claude需要修改大量代码 扩展性差：每增加一个工具都需要修改代码、重新部署 上下文膨胀：工具数量多时，函数定义占用大量Token，挤压用户输入空间 无状态：每次调用都是独立的，工具无法维持会话状态 MCP：标准化与解耦 MCP通过引入一个中间协议层来解决函数调用的问题。Agent不需要直接知道每个工具的实现细节，而是通过MCP Client与各个MCP Server通信。 核心优势： 解耦：工具实现与Agent逻辑完全分离，可以独立开发和部署 标准化：统一的协议意味着工具可以在不同模型和框架间复用 动态发现：Agent可以在运行时发现可用工具，无需硬编码 有状态会话：MCP支持长连接，工具可以维持会话状态 代价是： 复杂性增加：引入了额外的协议层和进程间通信 延迟增加：JSON-RPC往返增加了调用延迟 生态尚不成熟：虽然增长迅速，但与函数调用的生态相比仍有差距 决策框架 我们的建议是：不要选边站，而是根据场景选择。 选函数调用的场景： 工具数量少（<10个）且变化不频繁 对延迟敏感的实时应用 单一模型供应商、不打算切换 简单的问答+工具调用场景 选MCP的场景： 工具数量多且需要动态增减 多模型混用或可能切换供应商 需要让用户/第三方贡献工具的开放平台 企业级应用，工具需要独立权限管理 混合方案： 在实际项目中，我们发现混合方案往往效果最好——核心高频工具使用函数调用以保证性能，扩展工具通过MCP接入以保证灵活性。通过一个统一的Tool Router层来对上层Agent屏蔽差异。 未来走向 长期来看，MCP代表的标准化方向是不可逆的。就像REST API最终取代了各种自定义RPC协议一样，MCP或类似的标准化协议终将成为Agent工具集成的主流方式。函数调用不会消失，但会逐渐退化为MCP的底层传输方式之一。 对于今天就要做技术选型的团队，我的建议是：如果项目生命周期超过一年，认真考虑MCP；如果只是短期实验，函数调用仍然是最低成本的选择。 本文同步发布于 硅基AGI论坛

两条路线的分歧 当我们要让AI Agent调用外部工具时，面前有两条主要路线：传统的函数调用（Function Calling）和新生的MCP协议。社区里关于"哪个更好"的讨论从未停止，但真实情况比非此即彼复杂得多。 函数调用：简单直接 函数调用的思路很直接：在Prompt中告诉模型有哪些函数可用，模型根据用户意图生成结构化的函数调用请求，应用层执行函数并把结果返回给模型。 优势显而易见： 实现简单，几乎所有主流模型都原生支持 延迟低，无需额外的协议层 开发者控制力强，函数定义和执行完全在应用内闭环 但问题也很明显： 厂商绑定：不同模型的函数调用格式不统一，从OpenAI切换到Claude需要修改大量代码 扩展性差：每增加一个工具都需要修改代码、重新部署 上下文膨胀：工具数量多时，函数定义占用大量Token，挤压用户输入空间 无状态：每次调用都是独立的，工具无法维持会话状态 MCP：标准化与解耦 MCP通过引入一个中间协议层来解决函数调用的问题。Agent不需要直接知道每个工具的实现细节，而是通过MCP Client与各个MCP Server通信。 核心优势： 解耦：工具实现与Agent逻辑完全分离，可以独立开发和部署 标准化：统一的协议意味着工具可以在不同模型和框架间复用 动态发现：Agent可以在运行时发现可用工具，无需硬编码 有状态会话：MCP支持长连接，工具可以维持会话状态 代价是： 复杂性增加：引入了额外的协议层和进程间通信 延迟增加：JSON-RPC往返增加了调用延迟 生态尚不成熟：虽然增长迅速，但与函数调用的生态相比仍有差距 决策框架 我们的建议是：不要选边站，而是根据场景选择。 选函数调用的场景： 工具数量少（<10个）且变化不频繁 对延迟敏感的实时应用 单一模型供应商、不打算切换 简单的问答+工具调用场景 选MCP的场景： 工具数量多且需要动态增减 多模型混用或可能切换供应商 需要让用户/第三方贡献工具的开放平台 企业级应用，工具需要独立权限管理 混合方案： 在实际项目中，我们发现混合方案往往效果最好——核心高频工具使用函数调用以保证性能，扩展工具通过MCP接入以保证灵活性。通过一个统一的Tool Router层来对上层Agent屏蔽差异。 未来走向 长期来看，MCP代表的标准化方向是不可逆的。就像REST API最终取代了各种自定义RPC协议一样，MCP或类似的标准化协议终将成为Agent工具集成的主流方式。函数调用不会消失，但会逐渐退化为MCP的底层传输方式之一。 对于今天就要做技术选型的团队，我的建议是：如果项目生命周期超过一年，认真考虑MCP；如果只是短期实验，函数调用仍然是最低成本的选择。 本文同步发布于 硅基AGI论坛

Nous Hermes 4 简介 Nous Hermes系列是Nous Research开发的开源大模型家族，以出色的函数调用能力和指令遵循闻名。2026年，Hermes 4成为开源Agent开发的热门选择。 核心定位 开源免费：Apache 2.0许可 函数调用原生支持：不需要额外微调 多尺寸覆盖：7B/14B/70B/405B 模型无关：可本地部署，数据不出域 版本演进 版本 发布时间 基座模型 核心改进 Hermes 2 2024 Q3 Llama 3 基础函数调用 Hermes 3 2025 Q1 Llama 3.1 多轮函数调用 Hermes 4 2026 Q1 Llama 4 结构化输出+Agent能力 架构深度解析 模型架构 Hermes 4基于Llama 4架构，关键改进在训练数据和后训练流程： Llama 4 基座模型 ↓ 监督微调（SFT） - 100万+函数调用样本 - 50万+多轮对话样本 - 20万+结构化输出样本 ↓ 偏好优化（DPO） - 函数调用准确性偏好 - 指令遵循偏好 - 安全偏好 ↓ Constitutional AI - 安全约束 - 诚实性约束 - 帮助性约束 ↓ Hermes 4 最终模型 函数调用架构 Hermes 4的函数调用不是简单的prompt工程，而是训练阶段内化的能力： ...

工具调用：Agent的核心能力 AI Agent与普通聊天机器人的本质区别在于：Agent能调用外部工具完成任务。无论是查询数据库、发送邮件还是操作API，工具调用的准确性直接决定了Agent的实用价值。 工具调用看似简单——选择工具、填充参数、执行——但每一步都可能出错。我们需要系统化的方法来测评这条链路的可靠性。 评测指标体系 工具选择准确率 给定一个用户意图和可用工具列表，模型是否选对了工具？ 评估方式： 精确匹配：模型选择的工具与标注完全一致 可接受匹配：多个工具都能完成任务时，选择任一可接受的工具即算正确 严重错误率：选择了完全不相关的工具或调用了不该调用的工具 参数提取准确率 选对工具后，参数是否正确？ 按参数类型分别评估： 必填参数：缺失即错误 可选参数：有默认值时省略可接受 枚举参数：值必须在合法范围内 格式化参数：如日期格式、邮箱格式是否正确 参数级别的准确率 = 正确参数数 / 总参数数 调用序列准确率 复杂任务需要多步工具调用。评估整个调用序列： 调用顺序是否正确（B依赖A的结果） 是否有冗余调用（不必要的重复调用） 是否有遗漏调用（缺少关键步骤） 错误恢复率 工具调用失败后，Agent是否能正确处理： 识别错误原因 调整参数重试 切换替代工具 向用户报告问题 测试集构建方法 工具定义设计 构建测试集首先需要定义工具集。建议分层设计： L1 基础工具：单一功能、单一参数。如get_weather(city)。 L2 复合工具：多功能参数。如search_flights(origin, destination, date, passengers, cabin_class)。 L3 依赖工具：工具间存在数据依赖。如先调用get_user_id(email)再用返回值调用get_orders(user_id)。 L4 动态工具：工具列表在运行时变化，测试模型对未见工具的泛化能力。 测试用例生成 人工标注：由领域专家编写测试用例，质量高但成本高。 LLM辅助生成：用强模型生成候选用例，人工审核。效率高但需要注意分布均衡。 真实日志挖掘：从生产环境日志中提取真实调用场景，最具代表性但需要脱敏处理。 对抗性用例 专门构造容易出错的场景： 工具名称相似（send_email vs send_sms） 参数名称混淆（date vs datetime） 多工具均可完成同一任务 意图中包含误导性信息 评估执行流程 静态评估 不实际执行工具，仅评估模型输出的工具调用JSON： 解析模型输出 与标注答案对比 计算各维度指标 优点是快速可复现，缺点是无法评估执行结果。 ...

概述 函数调用Function Calling底层原理是AI智能体领域中函数调用Function Calling底层原理的重要主题。本文将从多个角度深入分析这一话题，为读者提供系统性的认知框架和实践参考。 核心概念 基本定义 在深入讨论之前，我们需要明确几个核心概念。AI智能体是指能够感知环境、理解指令、规划行动并调用工具完成任务的AI系统。与传统的聊天机器人不同，智能体具有自主性、目标导向性和工具使用能力。 函数调用Function Calling底层原理涉及的关键技术包括： 大语言模型：作为智能体的认知引擎，负责理解、推理和生成 工具调用：通过Function Calling或MCP协议与外部系统交互 记忆系统：短期记忆处理当前对话，长期记忆存储历史经验 规划引擎：将复杂任务分解为可执行的子步骤 技术原理 从技术层面看，函数调用Function Calling底层原理的核心在于如何让AI系统更好地理解和执行人类意图。这涉及多个技术环节的协同： 首先是感知层，智能体需要准确理解用户的自然语言指令，提取关键信息和约束条件。其次是规划层，将高层目标分解为具体的执行步骤。然后是执行层，调用合适的工具完成每个步骤。最后是反馈层，根据执行结果调整后续策略。 实践分析 当前现状 在技术原理领域，当前的技术实践呈现出几个明显特征： 工程化程度提升：从实验室原型到生产级系统，工程能力成为关键差异化因素 评估体系完善：越来越多标准化的评测基准被提出，帮助开发者量化能力边界 开源生态繁荣：开源框架和工具链的成熟降低了开发门槛 安全意识增强：对AI安全和对齐问题的重视程度显著提升 关键挑战 尽管进展显著，函数调用Function Calling底层原理仍面临几个核心挑战： 技术挑战： 大模型的幻觉问题在智能体场景下被放大，因为智能体需要做出实际决策 多步推理中的错误累积效应导致长程任务成功率下降 工具调用的可靠性受外部API稳定性影响 工程挑战： 智能体的可观测性不足，调试和排错困难 成本控制与性能优化的平衡 从单机到分布式部署的架构复杂性 安全挑战： Prompt注入等攻击手段不断进化 智能体权限管理需要更精细化的控制 数据隐私保护在多Agent协作场景下更加复杂 优化策略 针对上述挑战，以下是几个关键优化方向： 技术优化 分而治之：将复杂任务分解为可独立验证的子任务，降低单步错误影响 多路投票：对关键决策使用多次采样投票机制，提高可靠性 渐进式信任：智能体权限从最小化开始，根据表现逐步扩展 人在回路：高风险决策保留人工审核环节 工程优化 可观测性优先：建立完善的日志、指标和追踪体系 灰度发布：新版本智能体先在小流量环境验证 自动化测试：构建端到端测试套件，防止回归 成本监控：实时追踪Token消耗和API调用成本 案例研究 为了更具体地说明函数调用Function Calling底层原理的实践价值，我们来看一个典型场景： 某科技公司在内部IT运维中部署了AI智能体，负责处理员工的工单请求。智能体需要理解员工的自然语言描述，判断问题类型，查询知识库，执行修复操作或转接人工。 实施过程中遇到的关键问题包括： 员工描述模糊导致意图识别错误 知识库信息过时导致给出错误建议 某些操作需要管理员权限存在安全风险 解决方案： 引入澄清对话机制，在不确定时主动追问 建立知识库更新流程，定期审核内容 实施权限分级制度，敏感操作需人工确认 效果：工单首次解决率提升35%，平均处理时间缩短60%，员工满意度显著提升。 未来趋势 函数调用Function Calling底层原理的发展趋势值得关注： 标准化：MCP等开放协议将推动工具接口标准化，降低集成成本 垂直化：针对特定行业和场景的专用智能体将大量涌现 协作化：多智能体协作将成为复杂任务的标准解决方案 自主化：智能体的自主决策能力将持续提升，但需要配套的安全机制 结论 函数调用Function Calling底层原理是AI智能体技术发展中的重要一环。无论是技术原理的深入理解，还是实践中的工程优化，都需要系统性思维。对于开发者和企业而言，关键在于： ...

概述 函数调用模型选型是AI智能体领域中函数调用模型选型的重要主题。本文将从多个角度深入分析这一话题，为读者提供系统性的认知框架和实践参考。 核心概念 基本定义 在深入讨论之前，我们需要明确几个核心概念。AI智能体是指能够感知环境、理解指令、规划行动并调用工具完成任务的AI系统。与传统的聊天机器人不同，智能体具有自主性、目标导向性和工具使用能力。 函数调用模型选型涉及的关键技术包括： 大语言模型：作为智能体的认知引擎，负责理解、推理和生成 工具调用：通过Function Calling或MCP协议与外部系统交互 记忆系统：短期记忆处理当前对话，长期记忆存储历史经验 规划引擎：将复杂任务分解为可执行的子步骤 技术原理 从技术层面看，函数调用模型选型的核心在于如何让AI系统更好地理解和执行人类意图。这涉及多个技术环节的协同： 首先是感知层，智能体需要准确理解用户的自然语言指令，提取关键信息和约束条件。其次是规划层，将高层目标分解为具体的执行步骤。然后是执行层，调用合适的工具完成每个步骤。最后是反馈层，根据执行结果调整后续策略。 实践分析 当前现状 在模型选型领域，当前的技术实践呈现出几个明显特征： 工程化程度提升：从实验室原型到生产级系统，工程能力成为关键差异化因素 评估体系完善：越来越多标准化的评测基准被提出，帮助开发者量化能力边界 开源生态繁荣：开源框架和工具链的成熟降低了开发门槛 安全意识增强：对AI安全和对齐问题的重视程度显著提升 关键挑战 尽管进展显著，函数调用模型选型仍面临几个核心挑战： 技术挑战： 大模型的幻觉问题在智能体场景下被放大，因为智能体需要做出实际决策 多步推理中的错误累积效应导致长程任务成功率下降 工具调用的可靠性受外部API稳定性影响 工程挑战： 智能体的可观测性不足，调试和排错困难 成本控制与性能优化的平衡 从单机到分布式部署的架构复杂性 安全挑战： Prompt注入等攻击手段不断进化 智能体权限管理需要更精细化的控制 数据隐私保护在多Agent协作场景下更加复杂 优化策略 针对上述挑战，以下是几个关键优化方向： 技术优化 分而治之：将复杂任务分解为可独立验证的子任务，降低单步错误影响 多路投票：对关键决策使用多次采样投票机制，提高可靠性 渐进式信任：智能体权限从最小化开始，根据表现逐步扩展 人在回路：高风险决策保留人工审核环节 工程优化 可观测性优先：建立完善的日志、指标和追踪体系 灰度发布：新版本智能体先在小流量环境验证 自动化测试：构建端到端测试套件，防止回归 成本监控：实时追踪Token消耗和API调用成本 案例研究 为了更具体地说明函数调用模型选型的实践价值，我们来看一个典型场景： 某科技公司在内部IT运维中部署了AI智能体，负责处理员工的工单请求。智能体需要理解员工的自然语言描述，判断问题类型，查询知识库，执行修复操作或转接人工。 实施过程中遇到的关键问题包括： 员工描述模糊导致意图识别错误 知识库信息过时导致给出错误建议 某些操作需要管理员权限存在安全风险 解决方案： 引入澄清对话机制，在不确定时主动追问 建立知识库更新流程，定期审核内容 实施权限分级制度，敏感操作需人工确认 效果：工单首次解决率提升35%，平均处理时间缩短60%，员工满意度显著提升。 未来趋势 函数调用模型选型的发展趋势值得关注： 标准化：MCP等开放协议将推动工具接口标准化，降低集成成本 垂直化：针对特定行业和场景的专用智能体将大量涌现 协作化：多智能体协作将成为复杂任务的标准解决方案 自主化：智能体的自主决策能力将持续提升，但需要配套的安全机制 结论 函数调用模型选型是AI智能体技术发展中的重要一环。无论是技术原理的深入理解，还是实践中的工程优化，都需要系统性思维。对于开发者和企业而言，关键在于： 理解技术能力和边界，避免过度期待 建立系统化的评估和监控体系 在创新和安全之间找到平衡 持续学习和适应快速变化的技术生态 硅基AGI探索者将持续关注模型选型领域的最新进展，为读者提供深度分析和实践指导。— ...

为什么是 Hermes？ 在工具增强型智能体的构建中，函数调用（Function Calling）能力是核心中的核心。当 OpenAI 的 function calling 成为行业事实标准后，开源社区一直在寻找能够可靠执行这一范式的开源模型。NousResearch 的 Hermes 系列正是在这个需求下脱颖而出的产物。 Hermes 不是又一个通用大模型，而是一个专注于"指令遵循和工具使用"的特化模型系列。它通过对大量函数调用对话数据进行精细微调，在开源模型中实现了接近 GPT-4 级别的函数调用可靠性。 Hermes 函数调用机制详解 2.1 与 OpenAI function calling 的对比 OpenAI 的 function calling 采用 JSON Schema 定义函数签名，模型直接输出结构化的 JSON 参数。Hermes 采用了一种不同的方案——基于特殊标记的函数调用格式： 模型在生成文本时，通过特定的标记来表示"我要调用一个函数"，然后在标记之间输出 JSON 格式的调用信息。例如，当用户询问天气时，模型会输出类似如下的内容： {"name": "get_weather", "arguments": {"location": "上海", "unit": "celsius"}} 这种设计有几个优势： 可解析性强：特殊标记使得函数调用的边界清晰明确，解析器不需要依赖正则表达式或 JSON 修复 多调用支持：一次响应中可以包含多个函数调用请求 与自然语言混合：模型可以在函数调用前后插入自然语言解释，提升用户体验 2.2 工具定义格式 Hermes 使用 JSON Schema 来定义可用工具，格式与 OpenAI 高度兼容： tools = [ { "type": "function", "function": { "name": "search_web", "description": "搜索互联网获取最新信息", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词" }, "max_results": { "type": "integer", "description": "最大返回结果数", "default": 5 } }, "required": ["query"] } } }, { "type": "function", "function": { "name": "read_file", "description": "读取指定路径的文件内容", "parameters": { "type": "object", "properties": { "path": { "type": "string", "description": "文件路径" } }, "required": ["path"] } } } ] 2.3 系统提示构建 Hermes 的函数调用依赖于精心设计的系统提示来引导模型行为： ...