Bug: long running agent tasks in Ollama leads to unexpected stop tokens before tool calls
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 74/100
Hướng nghiên cứu
Start in src/eca/llm_providers/ollama.clj and read normalize-messages, comparing its message handling with the Anthropic adapter’s merge-adjacent-assistants. Check how request JSON keys are encoded and how assistant history items become Ollama chat messages. Done means prior tool calls are sent with the expected key and consecutive assistant content and tool calls are grouped as described; the issue names no test file, so locate the relevant provider tests.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.
Describe the bug
When using the Ollama API and long running agent tasks, the models (tested on qwen 3.5/3.8) emit unexpected stop tokens where a tool call is expected.
To Reproduce
Steps to reproduce the behavior:
- Use a model hosted by Ollama with the Ollama Api
- Start a long running task
- At some point the model outputs:
Now I edit file X <stop_token>
Expected behavior
The model emits a tool call request instead of the stop token.
Cause and fix
The reason for the behavior is twofold. Both problems are in normalize-messages in src/eca/llm_providers/ollama.clj.
-
Previous tool calls are silently dropped. The assistant tool-call messages are built with the key
:tool-calls, and the body is encoded with a plain(json/generate-string body)(no key-fn), so the wire key is"tool-calls". Ollama's/api/chatexpectstool_calls(API docs) and silently ignores unknown fields, so the request succeeds but the model never sees its earlier tool calls. (The response side already reads:tool_callscorrectly.) -
One model response is sent as several assistant turns. Each history item becomes its own message: the reasoning (as plain
content), the visible text, and the tool call. Ollama renders every assistant message as its own finished turn. The model's history therefore contains many turns of the form "I'll do X now", followed by an end-of-turn marker. That never happened during generation, where the call followed in the same turn. The model imitates the pattern and ends its turn right after announcing the action, so the stop token becomes likely. Each failure also adds another such example, which is why it gets worse in long sessions.
Fix
- Use
:tool_callsinstead of:tool-calls. - Merge consecutive assistant messages into one (reasoning first, then text, joined by a blank line, with all tool calls concatenated). A
toolmessage between two responses keeps them separate. The Anthropic adapter already does this withmerge-adjacent-assistants.
Workaround until released
Pointing the provider at Ollama with "api": "anthropic" avoids the problem, because that adapter already merges messages and sends tool_use blocks (Ollama converts them to tool_calls).
- Ngôn ngữ chính
- Clojure
- Star
- 1k
- Fork
- 82
- Merge trung bình
- 2 ngày 10 phút
- Pull request đã merge (30 ngày)
- 19
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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của editor-code-assistant/eca
-
Built-in web search is disabled for newer OpenAI modelsCó thể đã có người làm @stamdrovas đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
editor-code-assistant/eca#677 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Models doesn't work when fetchModels: false is usedCó thể đã có người làm @zikajk đã nhận 8 ngày trước. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
editor-code-assistant/eca#661 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug
Độ khó 4/5 1-2 ngày Mức phù hợp với người mới 54/100
editor-code-assistant/eca#674 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
editor-code-assistant/eca#671 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
editor-code-assistant/eca#670 ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của editor-code-assistant/eca
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
clojure-emacs/cider#4224 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
.Needs Triage Priority:P3 Type:Bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
metabase/metabase#85686 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
defold/defold#13578 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug: Editing the L value in HSL mode resets H and S to 0Có thể đã có người làm @makesomethingshit đã nhận 3 ngày trước. Đang mởgood first issue WG adoption
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
pgwire tokens-reqd
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Maintainer thường phản hồi trong vòng 1 ngày