大模型工具调用参数为空怎么办：Go 用 json.RawMessage 区分缺失与 null

接入大模型工具调用时，最容易被忽略的不是函数名，而是参数状态：字段没传、字段传了 null、传了空对象 {}，以及传入完整对象，业务上往往是四种不同情况。若直接把参数反序列化到结构体，前面三种状态很容易被压成同一个零值。

把工具参数先保留为 json.RawMessage，再在 validateArgs 中区分“缺失、null、空对象、合法对象”，能让模型输出和业务校验各自保持清晰边界。

为什么普通结构体会丢掉工具参数状态

假设模型返回一条工具调用，外层 JSON 里有 name 和可选的 arguments。把 arguments 直接定义成结构体指针时，缺失字段和显式 null 都可能得到 nil；定义成普通结构体时，{} 和字段缺省又会落到零值。

这会制造一个实际问题：天气查询工具缺少城市时，应该返回“缺少参数”；而一个允许默认城市的工具，收到空对象时可能可以继续。两者都被当成零值后，runTool 只能猜。

最小配方：用 json.RawMessage 保留四种输入

先让外层请求保存原始参数。下面的示例只保留与判断有关的字段，工具名和参数名也保持稳定，方便把错误绑定回一次调用。

type ToolCall struct {
    Name string          `json:"name"`
    Args json.RawMessage `json:"arguments"`
}

type WeatherArgs struct {
    City string `json:"city"`
}

func decodeArgs(call ToolCall) (json.RawMessage, error) {
    if call.Args == nil {
        return nil, errors.New("arguments missing")
    }
    if bytes.Equal(bytes.TrimSpace(call.Args), []byte("null")) {
        return nil, errors.New("arguments null")
    }
    if !json.Valid(call.Args) {
        return nil, errors.New("arguments invalid")
    }
    return call.Args, nil
}

这里的关键不是把 JSON 延迟到最后，而是先保留它。call.Args == nil 只判断字段是否出现；bytes.TrimSpace 后比较 null，则把显式空值单独拎出来。真正的对象才交给 json.Unmarshal。

validateArgs 还要拦住空对象和未知业务值

仅完成反序列化还不够。{} 是合法 JSON，却不代表满足工具契约。把形态校验和字段校验放到 validateArgs，runTool 就不需要重复判断。

func validateArgs(raw json.RawMessage) (WeatherArgs, error) {
    if raw == nil {
        return WeatherArgs{}, errors.New("arguments missing")
    }
    trimmed := bytes.TrimSpace(raw)
    if bytes.Equal(trimmed, []byte("null")) {
        return WeatherArgs{}, errors.New("arguments null")
    }
    if bytes.Equal(trimmed, []byte("{}")) {
        return WeatherArgs{}, errors.New("city required")
    }

    var args WeatherArgs
    if err := json.Unmarshal(trimmed, &args); err != nil {
        return WeatherArgs{}, fmt.Errorf("arguments invalid: %w", err)
    }
    if strings.TrimSpace(args.City) == "" {
        return WeatherArgs{}, errors.New("city required")
    }
    return args, nil
}

如果工具契约允许空对象表示默认城市，应把 {} 分支改成填充默认值，并在注释或契约中写明。不要把它悄悄当成缺失参数，否则调用方无法预测行为。

把分支接到工具执行前，错误才不会混在一起

最后让调用链固定为 decodeArgs → validateArgs → runTool。模型给出坏参数时，在执行外部工具前结束；这既避免无效请求，也能在日志里保留准确原因。

func runTool(call ToolCall) (string, error) {
    raw, err := decodeArgs(call)
    if err != nil {
        return "", err
    }
    args, err := validateArgs(raw)
    if err != nil {
        return "", err
    }
    return queryWeather(args.City)
}

如果外层结构已经直接拿到 json.RawMessage，也可以省掉 decodeArgs 的重复反序列化；但分支职责仍建议保留：一处判断 JSON 形态，一处判断业务字段，一处执行工具。

四种输入应该如何测试

测试重点不是覆盖更多城市，而是确认每种参数形态落到预期错误。可以用表驱动测试把契约写成可读的边界。

tests := []struct {
    name string
    raw  json.RawMessage
    want string
}{
    {"missing", nil, "arguments missing"},
    {"null", json.RawMessage("null"), "arguments null"},
    {"empty object", json.RawMessage("{}"), "city required"},
    {"valid", json.RawMessage(`{"city":"杭州"}`), ""},
}

运行测试时还应补一条非法 JSON 和一条 city 只有空格的输入。若上游协议允许数组、字符串等形态，也要明确它们是拒绝还是转换，别让 json.Unmarshal 的默认错误替你决定产品语义。

常见问题：json.RawMessage 的边界在哪里

json.RawMessage 能判断字段是否缺失吗？

能。对结构体字段来说，字段未出现时通常保持 nil；但如果业务允许空字节或上游做了预处理，仍应在进入校验前统一规范输入。

为什么不直接用 map[string]any？

map 适合字段动态变化的协议，但数字默认可能落成 float64，类型断言也更分散。参数形态固定时，用 json.RawMessage 加目标结构体更容易维护。

工具没有参数时要不要传空对象？

取决于工具契约。无参数工具可以约定缺失和 {} 都成功；有必填字段的工具则应保留两者的区别，并给出稳定错误。

校验通过后还要做什么？

在 runTool 内记录工具名、校验结果和错误分类，再执行实际调用；不要把完整原始参数写进可能包含敏感信息的普通日志。

小结：先保留状态，再决定业务含义

大模型输出的工具参数不是“能不能反序列化”这么简单。json.RawMessage 让 Go 程序先看见原始状态，validateArgs 再依据工具契约做判断，最后由 runTool 承担执行。这个顺序足够小，也能为后续增加参数版本、错误码或重试策略留下位置。