Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

fix(llm): handle_no_tool_calls 仍会落盘空 assistant 行——#168 的同族遗留通道

未关闭
  • 哪里不对？
#196 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
68/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
rust
领域
backend

调研方向

Read src/run_core.rs around handle_no_tool_calls (lines 835–857) and compare its empty-content handling with the has_persistable_interrupt logic from issue #168. Add a test for a normal stop with empty content and no tool calls, then run cargo test --lib and cargo test --test invariants. Done means the transcript has no empty assistant row, with the predicate covered by an assertion or equivalent reasoning.

由索引模型根据 Issue 内容生成。

描述

优先级 P3 · 依赖：无（同族于已修复的 #168）

基线 HEAD = e9e314ec

Summary

#168 修复了「中断在 tool_call 阶段落盘空 assistant 消息」的中断路径，但交付说明
（infra4agent#8）已指出：同族通道 run_core::handle_no_tool_calls 未被处理，
且当时标记为「超范围，故未动」——但没有开跟进单。本单补上这个跟踪项。

src/run_core.rs:835-857：

fn handle_no_tool_calls(&mut self, completion: &Completion, step: usize) -> Option<FinishReason> {
    if !completion.tool_calls.is_empty() { return None; }
    let mut msg = Message::assistant(completion.content.clone());   // ← content 可为空串
    msg.reasoning_content = completion.reasoning_content.clone();
    self.push_message(step, msg);                                    // ← 无条件落盘
    ...
}

即：正常停止（非中断）且 content 为空时，仍会落盘一条
{"role":"assistant","content":""} 的 transcript 行。

为什么目前危害低（但不该长期如此）

#168 的三层防线已把「空 assistant」在出网与读取两侧都拦住了，已实测确认：

  1. serialize_messages_anthropic / openai build_request 的 is_empty_assistant 过滤；
  2. SessionReader::load_messages 与 load_messages_with_orphan_results 的加载期过滤。

→ 不会污染线上请求，因此本单是 P3 而非 P2。

建议

两种方向，择一即可（建议 ①）：

  1. 不落盘：handle_no_tool_calls 在 content 与 reasoning_content 均为空时
    不 push（与 #168 的 has_persistable_interrupt 判据保持一致的语义）；
  2. 落盘但标记：保留行以便审计，明确标注其为「无内容终止」，
    并确保所有 serializer/loader 一致丢弃。

验收条件

  • 构造「模型返回 finish_reason=stop + 空 content + 无 tool_calls」的场景，
    断言 transcript 不含空的 assistant 行（或按方向 ② 断言其被一致丢弃）；
  • 回归：cargo test --lib 0 failed；cargo test --test invariants 0 failed；
  • 若为 is_empty_assistant / has_persistable_interrupt 类判据，
    必须补断言或补等价性论证，不得使用 #[mutants::skip]（#168 的既定纪律，
    已实测该门禁对本修复有效：撤销 skip 后变异可被杀死）。
主要语言
Rust
星标
4
派生
0
平均合并
5 小时 32 分钟
30 天内合并 PR
7

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

jeffkit/recursive 的其他 Issue

查看 jeffkit/recursive 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。