分类：AI编程
工具调用格式变化，被误读为任务结束
本地小模型能否运行 AI Agent，常被简单归因于模型能力。Bees 团队在 Dev.to 的工程复盘中记录了另一种情况：他们让一组 Agent 在本地 3B 到 4B 参数模型上执行真实任务，花了 8 月和 9 月大部分时间排查，发现多数失败来自代码、解析器、工具列表和模型输出格式的不匹配。
Bees 可连接 Claude Code、Codex 或 API，也提供通过 llama.cpp 在笔记本运行的本地模型。团队称，这些故障外观与模型能力不足相似：任务停止，没有写文件，没有搜索，也没有报错。
团队最早测试 Nanbeige 4.2 3B 时，第一轮工具调用正常，但随后任务直接结束。起初他们以为 3B 模型无法胜任，甚至计划为部分角色换更大模型。
复现后发现，该模型第一轮用 JSON 发工具调用；工具结果进入上下文后，它改用 XML 风格。llama.cpp 解析器锁定首次检测到的格式，第二次调用被当作普通文本，返回 finish_reason: stop 和 tool_calls: null。Agent 循环便认为模型已完成任务。
团队表示这不是缺少 –jinja，其构建默认开启；强制 XML 解析会破坏第一轮。最终，Bees 停止提供无法在整个运行中保持同一工具调用格式的模型，改用 Qwen3 4B Instruct。复盘建议：任务看似没有动作时，先看原始回复；若文本出现 <tool_call> 或 <function=，问题可能在解析器。
工具列表和提示词不一致，小模型更难恢复
Bees 的工具很多。一个规划 Agent 首次请求约 22k tokens，其中 15.6k 来自 79 个工具 schema，16k 上下文无法容纳。团队把多数 schema 放到搜索工具后，模型先看基础集合，每次加载 4 个匹配 schema。
小模型更容易按任务词搜索，而不是按能力搜索；搜索无果时会直接放弃。团队把阅读、写作和网页工具放回常显集合，并让空搜索列出可能可用的工具名。
更隐蔽的问题是提示词矛盾：提示先说列出的工具可以直接调用，只有列表中没有时才搜索，随后又要求调用未列出的 delegation 和 knowledge 工具。大模型会继续寻找，小模型则停止运行。这个问题曾让 8 个本地模型在内部测试中失败，而相关工具从未提供给它们。团队随后扫描提示词和错误信息中的工具名，与模型可见集合比对；被提及但不可见的工具被判定为 bug。无法工作的工具也会隐藏，例如网页搜索只在 API key 存在时显示。
缓存、超时和本机资源也会影响长任务
搜索工具保留最近 8 个已加载 schema，超过后丢弃最早描述。一次较长邮件任务中，模型在 14 次搜索后调用早期加载过的浏览器工具，但描述已被移除。适配器按当前列表检查，未找到就抛出 unknown tool 并终止运行。修复后，调用会被传递下去：工具存在则执行，模型编造名称则返回普通工具错误。
记忆服务暴露了本地资源问题。Bees Agent 会保存记忆以跳过已处理事项并遵守每日限制。一段时间内，记忆保存全部失败，报错 Extraction failed。原因是 Qwen3.5 4B 在开启聊天模板后默认思考，每次事实提取生成 2000 到 8500 tokens 思考内容，约 30 tokens/秒，超过 300 秒超时；llama.cpp 单 slot 还让后续保存排队。最终，团队在调用中加入 chat_template_kwargs: { enable_thinking: false }。
本地 Agent 的第一道门槛是工程接口
这次复盘没有把问题简单归结为小模型能力不足，而是说明本地 Agent 的可用性取决于模型、解析器、工具注册、上下文管理和资源调度的配合。
- 任务没有动作时，先检查原始输出是否已有工具调用片段。
- 提示词提到的工具必须真实可见；小模型对矛盾指令的容错更低。
- 工具 schema 缓存、上下文窗口和本机性能都会影响长任务。
- 本地模型可以减少 API 费用，但工程验证不能省略。
对本地 AI 编程和 Agent 开发者来说，当小模型没有完成任务，优先排查解析和工具接口，通常比直接换更大模型更接近问题本身。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ben-di-xiao-mo-xing-pao-agent-xian-bie-ji-zhe-huan-geng-da
