Hermes 与 Agent 工程：把函数调用从提示词技巧变成可解析协议

原创

用户12339161

发布于 2026-10-13 16:27:40

1800

核心结论： Agent 工程的核心矛盾是模型会推理，但外部世界需要确定接口。Hermes 系列模型的价值不在于“更聪明”，而在于把工具调用从脆弱的自然语言解析变成了可解析的结构化协议。Hermes 不是 Agent 框架，它是 Agent 的“大脑”；工程要做的，是给大脑配上手、眼睛和刹车。

一、Hermes 在 Agent 工程中的位置

一个可用的 Agent 通常由五部分组成：模型（做决策）、循环（感知→思考→行动→观察）、工具（API、数据库、代码执行）、状态（对话历史与中间结果）、权限与审计。Hermes 属于第一层——它是被编排的决策层，不是 LangGraph、AutoGen 那样的编排框架。

选 Hermes 作为决策层的工程理由有三条。第一，函数调用格式稳定：Agent 最怕模型输出“看起来像 JSON 但不是 JSON”，Hermes 在工具调用上训练充分，参数解析成功率更高。第二，支持 JSON Mode，需要结构化结果时可直接约束输出格式。第三，开源可私有化，通过 vLLM、Ollama 本地部署，数据不出域。

二、函数调用即协议

Hermes 的接口设计把工具调用变成了可解析的协议而非提示词技巧。模型在需要调用工具时，输出固定格式：

<tool_call>{"name":"get_weather","arguments":{"city":"北京"}}</tool_call>

工具执行后，结果以 <tool_response> 回传，模型继续推理。这个闭环的工程意义在于：解析器不再需要“猜”模型想调什么工具，只需要按标签切分和 JSON 反序列化。

三、最小 Agent Loop

以下代码假设 Hermes 已通过 OpenAI 兼容接口（vLLM/Ollama）部署在本地。核心逻辑不到 40 行，跑通完整闭环：

import json
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="none")

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "查询城市天气",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"]
        }
    }
}]

def get_weather(city: str) -> str:
    return f"{city}：晴，25℃"

def run_agent(prompt: str, max_steps: int = 5) -> str:
    msgs = [{"role": "user", "content": prompt}]
    for _ in range(max_steps):                # 循环上限，防止失控
        resp = client.chat.completions.create(
            model="hermes-3", messages=msgs, tools=tools, temperature=0
        )
        msg = resp.choices[0].message
        if not msg.tool_calls:                # 没有工具调用 → 输出最终答案
            return msg.content
        call = msg.tool_calls[0]
        args = json.loads(call.function.arguments)
        result = get_weather(**args)          # 执行本地工具
        msgs.append(msg.model_dump(exclude_none=True))
        msgs.append({"role": "tool", "tool_call_id": call.id,
                     "content": result})       # 回传结果
    return "达到最大步数"

这段代码省略了错误处理、并发和权限校验，但它已经具备 Agent Loop 的核心骨架。关键设计是 max_steps——没有上限的 Agent 会烧 token、卡死任务。

四、从 Demo 到生产的六个工程点

第一，系统提示即契约。 明确角色、工具范围、输出格式和拒绝策略。提示词越窄，行为越稳。

第二，工具 Schema 要窄。 参数越少、类型越明确，模型越不容易编造。一个工具只做一件事。

第三，循环上限与超时。 步数、时间、成本都要设阈值，超过即退出并报告状态。

第四，状态持久化。 每步保存对话和中间结果，支持断点续跑、回放和人工接管。

第五，权限与审计。 工具调用前校验权限，调用后记录日志。敏感操作必须有人类确认节点。

第六，评估与回放。 保留完整的调用轨迹（trace），便于回溯“模型为什么走了这一步”。

Hermes 作为决策层的优势在 tool_calls 结构化输出上体现得最清楚：模型返回的不是需要解析的自然语言，而是带 id、function.name、function.arguments 的标准对象。工程侧要做的是围绕这个协议补齐循环控制、状态管理和权限边界——这恰恰是 Agent 工程真正的工程量所在。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

agent