快速结论
模型生成工具调用，应用负责执行。写操作超时后先查询真实状态；业务操作键与执行记录应由应用管理，不能只靠 tool_call_id 或模型记忆防止重复副作用。
- DeepSeek 官方文档说明，模型返回工具调用，具体函数由应用执行。
- 查询重试与有副作用的写操作需要采用不同处理策略。
- 本文中的 operation_key 是应用层示例字段，不是 DeepSeek API 参数。
- 教程提供工程方法，没有执行真实发布、转账或消息发送测试。
本次更新：10 月 13 日核验后新增，标明公告日期、适用范围与文档指导性质。
DeepSeek Tool Calls 文档将工具执行交给应用。模型提出调用之后，是否重试、如何确认结果与避免重复写入，也需要由执行层设计。本篇给出方法示例，没有操作真实业务系统。
1. 先区分查询与写操作
读取统计、查看状态和检索资料，通常没有业务写入；创建文章、修改记录或发送消息则可能产生副作用。即使工具都叫“调用”，重试策略也不能统一处理。
有副作用的请求超时，并不证明目标系统没有执行。先用目标对象 ID、业务操作记录或可查询状态确认，再决定是否重试。
2. 应用维护业务操作记录
下面是应用层示例，不是模型 API 的额外字段：
| 字段 | 用途 |
|---|---|
| operation_key | 标识一次明确授权的业务操作 |
| target_id | 查询目标对象或执行结果 |
| state | 待执行、执行中、成功或结果未知 |
| result | 返回值或核对后的真实状态 |
操作键应按业务语义生成，区分两次合法操作。对同一操作的并发请求，需要执行层的原子状态处理；仅在提示词里说“不要重复”不足以约束真实系统。
3. 超时后的恢复顺序
先保留原请求、操作键和已知目标 ID；随后查询目标系统。若已成功，回传实际结果；若明确失败，再按业务策略重试；无法判断时保留“结果未知”，等待核对，不把它伪装成成功或立即再次写入。
tool_call_id 用于关联模型对话中的调用与结果，不能直接代替跨重启、跨会话的业务去重记录。即便同一个业务操作被模型再次提出，应用仍需根据已有执行状态处理。
4. 回传错误也要真实
把失败类型、可恢复条件和已发生的动作反馈给模型。设置总轮数和超时边界，避免在反复调用中扩大副作用。服务商错误码可对照官方说明，但模型请求可重试，不代表对应业务写操作也可以盲目重试。
验收时用测试对象检查重复调用、网络中断和进程重启。目标是可核对和可恢复的执行记录；实际保证取决于目标系统与应用实现。
参考资料
本文依据以下资料整理，版本与接口信息请以来源页面的现行说明为准。