DeepSeek Tool Calls 实战：把工具参数、执行结果与最终回答接成闭环

在运营系统里，Agent 可以先查活动数据再写摘要。实现这一点需要接通三个环节：模型提出调用、应用执行函数、模型读取结果。DeepSeek 官方文档明确说明，模型不会替应用执行真实函数。

先从只读查询开始

示例工具 get_campaign_metrics 接受 campaign_id。返回值可以是业务后端提供的统计记录，而不是模型自行补出的数字。首次接入建议只提供查询能力，先观察参数与结果是否对应。

{
  "type": "function",
  "function": {
    "name": "get_campaign_metrics",
    "description": "查询当前用户可访问的活动统计",
    "parameters": {
      "type": "object",
      "properties": {
        "campaign_id": {"type": "string"}
      },
      "required": ["campaign_id"],
      "additionalProperties": false
    }
  }
}

这只是工具定义片段，不是完整请求，也不包含统计后端实现。应用还要核对活动是否属于当前用户、参数是否在业务允许范围内。

正确的消息顺序

1. 发送用户问题、历史消息与 tools 定义。
2. 读取助手消息；若有 tool_calls，先保存完整助手消息。
3. 对每个调用，按函数名称白名单解析 arguments，验证参数和访问权限。
4. 执行查询，用对应调用的 ID 追加工具结果消息。
5. 再请求模型，让它基于结果回答；若继续调用，则重复处理。
6. 达到最终回答、轮次上限或总超时时结束，向用户说明未完成部分。

工具结果消息的关键关联形式是：

{
  "role": "tool",
  "tool_call_id": "来自上一步调用的实际 ID",
  "content": "后端查询结果的 JSON 字符串"
}

不要漏掉前一条含 tool_calls 的助手消息，也不要给多个调用复用一个 ID。查询失败时回传实际错误状态；空结果、无权限和服务失败应分别处理。

strict 与思考模式的边界

strict 是 Beta 功能，官方要求使用 https://api.deepseek.com/beta，为工具设置 strict: true，并遵守支持的 JSON Schema 子集。它约束参数结构，不能代替授权检查或保证业务数据正确。

按当前 Chat Completions 文档，思考模式不支持 tool_choice: required 或指定函数名称的强制选择，会返回 400；这不等于思考模式完全不支持工具调用。接入前区分模式、API 格式和具体参数。

发布前观察什么

记录调用轮数、参数校验失败率、工具耗时和最终引用是否匹配结果。写操作还应使用业务幂等机制，避免超时重试产生重复动作。本文为文档与流程示例，没有调用付费模型，也没有声称已测得生产成功率。