Bug: long running agent tasks in Ollama leads to unexpected stop tokens before tool calls
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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).
- 主要语言
- Clojure
- 星标
- 1k
- 派生
- 82
- 平均合并
- 2 天 2 小时
- 30 天内合并 PR
- 21
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
editor-code-assistant/eca 的其他 Issue
-
Models doesn't work when fetchModels: false is used可能已有人在做 @zikajk 于 8 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 78/100
editor-code-assistant/eca#661 · 已指派 1 人 ·
维护者通常 2 天内回复
-
bug
难度 4/5 1-2 天 新手友好度 54/100
editor-code-assistant/eca#674 ·
维护者通常 2 天内回复
-
难度 3/5 1-2 天 新手友好度 45/100
editor-code-assistant/eca#671 · 2 条评论 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 25/100
editor-code-assistant/eca#670 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
editor-code-assistant/eca#669 ·
维护者通常 2 天内回复
查看 editor-code-assistant/eca 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
WG adoption
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 4 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
clojure-emacs/cider#4224 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100