Eino Tool 开发：三种姿势，我踩过的坑
Eino Tool 开发：三种姿势，我踩过的坑
最近在用 Eino 做 Agent 开发，发现创建 Tool 有三种方式。踩了一些坑，记录一下。
为什么需要 Tool？
LLM 本身只能处理文本，想让它查数据库、调 API、操作文件？这些都需要 Tool。
简单说：Tool 就是给 LLM 装上的"手"，让它能干实事。
Eino 里创建 Tool 有三种方式，各有优劣，选对了事半功倍。
先说结论
不想看长文的直接看这里：
- 赶时间/写 demo：
InferTool，一行搞定 - 要控制参数描述：
NewTool，手动定义 - 正经项目：实现接口，别偷懒
下面详细说。
方式一：InferTool
这个最省事，从函数签名自动推断工具定义。
// 定义参数结构体，tag 里写描述typeUserUpdateParamsstruct{UserIDstring`json:"user_id" jsonschema_description:"用户ID"`Name*string`json:"name,omitempty" jsonschema_description:"用户名"`Email*string`json:"email,omitempty" jsonschema_description:"邮箱地址"`}// 处理函数funcUpdateUserFunc(_context.Context,params*UserUpdateParams)(string,error){// 业务逻辑return`{"msg": "ok"}`,nil}// 一行创建工具updateTool,_:=utils.InferTool("update_user","更新用户信息",UpdateUserFunc)优缺点：
| 优点 | 缺点 |
|---|---|
| 代码最简洁，一行创建 | 依赖jsonschema_descriptiontag，容易遗漏 |
| 自动生成 JSON Schema，类型安全 | 参数描述分散在 struct 中，不便于集中管理 |
| 函数签名改了自动同步 | 无法注入外部依赖（db、cache 等） |
| 编译期检查参数类型 | 不支持枚举值（Enum） |
适用场景：写 demo、快速原型、参数结构简单且无外部依赖的工具。
方式二：NewTool
手动定义 ToolInfo，然后挂个函数上去。
// 参数结构体typeUserCreateParamsstruct{Namestring`json:"name"`Rolestring`json:"role"`}// 处理函数funcCreateUserFunc(_context.Context,params*UserCreateParams)(string,error