Anthropic流式请求结束后server_tool_use的input仍为空

流里已经出现 input_json_delta，里面有工具参数，等到请求结束，Python SDK汇总出的 server_tool_use.input 却仍是 {}。如果同类非流式响应能返回参数，先检查流式事件有没有被SDK正确归入内容块。

这里有一个明确的旧版边界：anthropic Python SDK 0.52.1的参数累积逻辑只处理 tool_use，0.52.2把 server_tool_use 也纳入处理。0.52.2于2025年6月2日发布。本文说明这条历史路径，不能仅凭空对象就认定当前SDK仍有这个缺陷。

空对象出现在什么时候

content_block_start 开始一个工具块时，input 可以是空对象。随后到达的 partial_json 是字符串片段，例如半个字段名或还没有闭合的字符串；它不需要每段都能单独解析。

检查时记录内容块的 index、块类型、delta类型与完成事件。不要只看终端有没有输出文本：text_stream 面向文本输出，工具参数并不属于文本delta。流式汇总对象与原始事件是两份不同层次的观察结果。

需要区分两种情况：正在接收的块还没有结束，空对象可能只是中间状态；对应块已经结束，完整消息也已收完，原始参数delta存在而汇总对象仍为空，才值得检查累积逻辑。content_block_stop 只表示那个内容块结束，整个消息还需要检查 message_stop、结束原因及流内错误。连接中断不能按正常结束处理。

核对实际运行环境的SDK

下面只读取当前Python解释器安装的版本，不发送请求：

from importlib.metadata import version

print(version("anthropic"))

应在运行服务所用的虚拟环境或容器中查看。锁文件、开发机和工作进程可能不是同一个版本。若使用了封装SDK，还要核对事件有没有在封装层被过滤，或者所有块都被错误地合并到一个缓冲区。

在已确认的旧版路径中，0.52.1按 content_block.type == "tool_use" 选择是否累积参数，因此服务器工具块会被遗漏。0.52.2同时识别 ToolUseBlock 和 ServerToolUseBlock。核对过的正式1.13.0实现也处理这两种类型，并按内容块索引保存参数缓冲。

升级应选择与应用依赖相容、包含该修复的正式版本，再检查已有事件与最终消息是否一致。0.52.2是修复边界，不代表今天必须把整个应用固定到这个历史版本。模型、工具名称和工具版本的兼容性还要另外核对，不能把2025年的代码执行请求原样当作现行调用示例。

自己累积参数时，保留块的边界

应用确实需要处理原始SSE时，按 index 分开累积 partial_json，同时保留该索引对应的块类型和工具ID。多个工具块的字符串拼到一起，即使偶尔能解析，也不能说明参数属于同一次调用。

中途能解析出一个对象，也不表示工具参数已经完整。流式解析器可能给出部分字段；接收逻辑仍需要完成事件、完整JSON检查与工具自身的参数约束。普通JSON语法问题可以对照解析失败与流式半成品的区别，不要用补引号、截掉尾部文本的方法掩盖缺失事件。

server_tool_use 由服务器执行。最终参数显示为空，不能据此断言工具没有执行，更不能把提取出的代码再当客户端工具补跑。存在费用或写入动作的请求，也不适合为排查而盲目重发。

如果出错发生在下一轮发送历史时，例如提示缺少 tool_result，检查的是客户端工具消息配对；可按历史裁剪后的工具请求与结果检查处理。这与本篇的服务器工具响应重建是不同路径。

修正后，用已有受控事件记录核对每个索引的参数归属，再在允许的测试请求中检查最终消息。原始delta存在、消息正常完成、对应块参数完整，才能确认这一条路径恢复；只看到文字回答或没有抛异常，检查还不充分。