HermesAgent插件开发:编写你的第一个Tool 想让你的HermesAgent变得更强大,能够调用外部服务或执行特定任务吗?关键在于为其编写自定义Tool。这听起来有点技术门槛,但别担心,整个过程其实逻辑清晰,遵循一套标准化的流程就能搞定。下面,我们就来手把手拆解创建第一个Tool的完整步骤

想让你的HermesAgent变得更强大,能够调用外部服务或执行特定任务吗?关键在于为其编写自定义Tool。这听起来有点技术门槛,但别担心,整个过程其实逻辑清晰,遵循一套标准化的流程就能搞定。下面,我们就来手把手拆解创建第一个Tool的完整步骤。
长期稳定更新的攒劲资源: >>>点此立即查看<<<
一切从定义开始。你的Tool必须继承HermesAgent框架提供的基类,并实现规定的接口。这一步的核心目的,是让框架能够准确识别、序列化并最终调度你的工具。其中,名称、描述和参数定义这几项元信息尤为重要,它们将直接用于大语言模型(LLM)的“工具选择”推理过程。
具体操作可以分四步走:
首先,创建一个新的Python文件,比如命名为 weather_tool.py。
接着,导入必要的模块,通常是 HermesTool 基类,如果框架支持装饰器模式,也可能用到 @tool 装饰器。
然后,定义你的工具类。例如,可以创建一个 WeatherQueryTool 类,并为其设置关键属性:name = “get_weather”,description = “根据城市名获取当前天气信息”。名字要简洁,描述要清晰,这直接关系到LLM能否正确理解和使用它。
最后,在类中声明 parameters 字典。这个字典定义了工具所需的输入,比如一个名为 “city” 的参数(类型为 str),以及一个可选的 “unit” 参数(可设置默认值为 “celsius”)。每个参数都需要明确其 type 和 description。
定义好了骨架,接下来就要注入灵魂——实现 call 方法。这个方法是工具被执行时的实际入口,它接收标准化的参数字典,并负责返回LLM能理解的结构化结果。这里有个关键原则:必须确保异常可被优雅捕获,并返回友好的错误信息,避免因单个工具故障而中断整个Agent的工作流。
实现过程大致如下:
在Tool类中定义方法:def call(self, **kwargs) -> dict:。
从 kwargs 中提取出 city 等参数值,并进行基本的校验,比如确保城市名非空且为字符串类型。
构造HTTP请求的URL,调用一个公开的天气API(例如OpenWeatherMap),记得携带必要的API Key和查询参数。
收到响应后,解析JSON数据,提取出我们关心的字段,比如 temperature(温度)、condition(天气状况)、humidity(湿度)。
最后,返回一个结构清晰的字典,例如:{“temperature”: 23.5, “condition”: “partly cloudy”, “humidity”: 64}。这个结果会被HermesAgent框架传递给LLM进行后续解读。
工具编写完毕,但如果你不“告诉”Agent,它就永远不知道这个新能力的存在。因此,必须将Tool显式注册到HermesAgent的运行时环境中。这个过程会触发框架内部的元数据校验和索引构建。
注册方式很简单:在初始化你的Agent对象之后,直接调用 agent.register_tool(WeatherQueryTool()) 即可。
注册成功后,通常会在日志中看到类似 Registered tool: get_weather 的输出。为了确认,你可以调用 agent.list_tools() 方法,检查返回的列表里是否包含了 get_weather 及其完整的描述信息。
除了代码注册,有些框架也支持YAML配置方式。如果采用这种模式,你需要在 tools.yaml 这样的配置文件中添加对应的工具块,并指定模块路径和类名。
在将工具投入生产环境前,充分的测试是必不可少的。单元测试能确保你的Tool在各种输入条件下都能返回预期的格式和内容,有效防止因参数缺失、网络异常或类型错误导致整个Agent意外崩溃。
测试可以这样组织:
创建测试文件 test_weather_tool.py,导入 pytest 和你的 WeatherQueryTool。
编写第一个测试函数 test_call_with_valid_city,传入合法的参数如 {“city”: “Beijing”},然后断言返回的字典中包含 “temperature” 这个键。
再编写一个测试函数 test_call_with_empty_city,验证当城市参数为空时,工具是否能正确地抛出 ValueError 或返回一个结构化的错误信息,例如 {“error”: “city cannot be empty”}。
为了提高测试的稳定性和速度,建议使用 responses 这类库来模拟HTTP响应,从而隔离对外部API的依赖。
这是最后一步,也是至关重要的一步。LLM本身并不知道你的工具能做什么,它需要通过系统提示词(system prompt)来了解每个工具的功能边界和调用语法。你必须将Tool的描述信息注入到system prompt的特定部分,否则模型永远不会生成相应的工具调用指令。
具体操作流程是:
首先,调用框架提供的 agent.get_tool_descriptions() 方法,获取所有已注册工具的标准JSON Schema描述片段。
然后,将这个片段嵌入到你的system prompt末尾。格式通常是类似 {“name”: “…”, “description”: “…”, “parameters”: {…}} 的JSON结构。
在prompt中,最好给出明确的指示,例如:“仅当用户问题明确涉及天气查询时,才调用get_weather工具;否则不调用任何工具。” 这能引导LLM更精准地使用工具。
完成以上步骤后,就可以进行验证了。向Agent发送一个查询天气的请求,观察LLM的输出中是否出现了预期的工具调用结构,例如:{“name”: “get_weather”, “arguments”: “{…}”}。如果出现了,恭喜你,你的第一个HermesAgent Tool已经成功上线运行。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述