Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[M3 Bug] Tool calling: array arguments always emitted as {"item": [...]} (100% reproducible, trigger independent of field name) + numeric arguments serialized as strings

Đang mở
  • Có gì không ổn?
#37 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
json
Lĩnh vực
ai

Hướng nghiên cứu

Start by comparing the reported tool-call arguments with the JSON schemas in the issue, especially the array fields and numeric fields. The report does not identify repository files, tests, or an implementation entry point, so first locate where tool-call arguments are generated or validated. Done means reproducing the wrapped arrays and stringified numbers and confirming the emitted arguments match the declared schema types.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

Reporting a second, always-reproducible variant of the item-wrapping bug in #29, plus a related number-serialization issue. Unlike #29 (15-35% intermittent, trigger narrowed to a property named item_ids together with a prompt that avoids the word "item"), this variant is 100% reproducible and fires on array fields whose names have nothing to do with item.

Two symptoms, both in the model's own tool-call arguments, before any client-side validation:

  1. Array arguments are emitted as {"item": [...]} instead of a JSON array.
  2. Numeric arguments are emitted as JSON strings ("maxCharacters": "6000").

Reproduction: 100% of calls, across three tools

Client: OpenAI-compatible chat-completions endpoint, agent harness. No sampling parameters set.

Tool / argument Model Shape emitted Result
suggestions (array of objects) MiniMax-M3.1-Flash {"item": [...]} schema validation rejects the call
suggestions (array of objects) DeepSeek (same harness, same schema) [...] accepted
reviewed (array of strings) MiniMax-M3.1-Flash {"item": [...]} schema validation rejects the call
reviewed (array of strings) DeepSeek (same harness, same schema) [...] accepted
urls (array of strings) MiniMax-M3.1-Flash {"item": [...]} schema validation rejects the call
urls (array of strings) DeepSeek (same harness, same schema) [...] accepted

Same tool, same schema, same harness, same argument names - only the model differs. Over 1,500 MiniMax tool calls in our logs, every wrapped array used the key item; no other key ever appeared.

The trigger is not an item* property name

#29's 2026-07-28 update narrows the trigger to a property named item_ids (or similar item*) combined with a prompt that never uses the word "item", and reports that "realistic schemas with no item* property have been clean in everything I have run since - 26/26 calls on one real workload, and 56/56 on a larger schema".

That does not hold for the schemas below. None of the array fields is named item*:

{
  "type": "object",
  "properties": {
    "suggestions": { "type": "array", "items": { "type": "object", "properties": { "title": { "type": "string" } } } },
    "reviewed":    { "type": "array", "items": { "type": "string" } }
  },
  "required": ["suggestions"]
}

and:

{
  "type": "object",
  "properties": {
    "urls": { "type": "array", "items": { "type": "string" } },
    "maxCharacters": { "type": "number" }
  },
  "required": ["urls"]
}

For these, the item wrapping occurs on every single call (22/22 and 5/5 in our logs), and the field name is irrelevant. A separate card-rendering schema declaring "sections": {"type": "array"} explicitly - i.e. the shape is unambiguous - also wraps on every call.

One hypothesis worth considering: items is the JSON Schema keyword for array elements, and the model may be conflating that keyword with an output key whenever the schema uses items for element typing - which is to say, in essentially every array schema - regardless of the property's own name.

Number arguments are serialized as strings

A separate symptom in the same tool calls: numeric arguments arrive as JSON strings, so a number schema rejects them.

{ "server": "exa", "tool": "exa_web_fetch_exa",
  "arguments": { "maxCharacters": "6000", "urls": { "item": ["https://example.com/a", "https://example.com/b"] } } }

The schema declares maxCharacters as number; the client-side validator reports maxCharacters 需要 number，收到 string. A numResults: 2 argument is likewise emitted as "2".

The same harness, same tool, same argument, with DeepSeek emits "maxCharacters": 6000 as a native number and succeeds.

Why this matters beyond cosmetics

The malformed arguments are syntactically valid JSON, so nothing raises on parse. The failure surfaces only when the consumer validates against the schema, and by then the model's output has already been discarded and the call has to be retried. In an agent loop that means the tool never runs, the model sees a validation error instead of a result, and the surrounding task can fail or silently lose data. In our case one of the affected tools is the heartbeat's own log-recording call, so the patrol record was simply missing for those runs.

Questions

  • Is this the same root cause as #29, and does the fix for #29 also cover the always-reproducible variant?
  • Is there a supported strict / constrained-decoding mode for tool calls that would enforce the declared JSON types?
  • Is the number-to-string serialization related to the same mechanism, or separate?

Notes on version

Observed with MiniMax-M3.1-Flash through an OpenAI-compatible gateway. Happy to supply raw request/response pairs and the exact schemas if useful.

Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
493
Fork
60
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MiniMax-AI/MiniMax-M3

Tất cả issue của MiniMax-AI/MiniMax-M3

Issue tương tự

Thêm issue về AI Infra & Agents

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.