围绕DeepSeek API函数调用，拆解消息协议、工具Schema、多轮回传与教学场景落地，给出可复用的工程化要点。 在智能助教、教学运营和学情分析场景中，模型如果只能生成文本，价值会被限制在问答层。DeepSeek API的函数调用把意图识别与业务动作连接起来：模型根据用户问题和工具描述决定是否调用、调用哪个工具、传什么参数，业务系统执行后把结构化结果回传，模型再组织成可读回复。对AI指导老师而言，理解这条链路比记住某个参数更重要，因为它决定了助教能否安全地查数据、调资源、建计划。
1. 从自然语言到可执行动作的协议链路
DeepSeek API的函数调用沿用对话补全的消息流。请求侧在messages之外增加tools数组，每个工具声明名称、用途和参数结构，tool_choice用于控制自动选择、禁止调用或强制指定工具。模型返回的assistant消息中可能出现tool_calls数组，每一项带有调用id、函数名和JSON字符串形式的arguments。业务后端需要解析arguments，完成参数校验、权限检查和实际执行，再把结果以role为tool、tool_call_id与调用id对应的消息追加到对话中，发起下一轮请求，直到模型不再产生tool_calls并给出最终回复。模型本身不执行函数，它只生成调用意图，真正执行权始终在后端。 这条链路的关键在于消息闭环。缺少tool_call_id会导致模型无法把结果与调用对应，直接把工具结果写进user消息也会破坏协议语义。教学场景中，学生问“本周还有哪些作业没交”，模型可能先调用query_homework，再根据返回的未交列表调用get_knowledge_mastery获取薄弱点，最后组织回复。每一步都需要后端把结构化结果回传，而不是让模型猜测数据。并行工具调用出现时，还要按id聚合多个tool消息，确保顺序和对应关系清晰。 调试阶段建议先使用非流式请求观察完整tool_calls结构，再接入业务工具。日志中保留模型原始返回、解析后的arguments、工具执行结果和下一轮请求摘要，可以快速定位是模型选错工具、参数填错，还是后端返回格式不符合预期。对AI指导老师来说，这条协议链路也是教学设计的一部分，因为工具边界越清楚，模型越不容易把查询动作误判为写入动作。
2. 工具定义与JSON Schema的约束设计
工具定义质量直接决定调用准确率。工具名宜采用动词加名词的稳定命名，例如query_homework、search_exercise、create_study_plan，description要写清用途、触发条件、不适用场景、参数含义和返回结构，避免只写一句“查询数据”。parameters使用JSON Schema描述，明确required字段、type、enum、minimum、maxLength，并设置additionalProperties为false，减少模型自由发挥。参数应少而精，学生标识、租户标识这类敏感字段不要交给模型填写，而应由后端从会话上下文注入，既降低填错概率，也避免越权风险。 工具粒度需要适中。把查学情、查作业、查课表塞进一个万能工具，会让description臃肿、参数互相干扰，模型很难稳定选择；拆得过细又会导致多轮调用增加、延迟上升。教学场景中可以把只读查询和写入操作分开，查询类工具返回精简JSON，写入类工具要求明确参数并返回操作编号。工具返回内容建议包含状态字段、数据主体和可读错误信息，同时对过长结果做裁剪或分页，防止把整张数据表塞回模型上下文。 安全约束要落在Schema和后端两层。Schema负责让模型知道什么参数合法，后端负责最终校验、权限最小化和审计记录。模型传入了不存在的课程编号，后端应返回结构化错误而不是抛出裸异常；模型试图调用未注册工具，网关应直接拒绝。工具描述中还可以写明“当用户询问未交作业时调用”“不要用于查询成绩排名”，用自然语言补充Schema难以表达的边界。对AI指导老师而言，工具说明本身就是教学策略的编码，写得好，模型才像一位知道何时查资料、何时给建议的助教。
3. 多轮回传、流式聚合与异常治理
流式模式下，tool_calls会以增量片段出现在delta中，函数名和arguments可能分多次到达。工程实现需要按index和id聚合片段，等arguments拼接成完整JSON后再执行工具，不能边流边调用。非流式请求结构更直观，适合调试和低频任务；流式适合需要即时反馈的对话界面。无论哪种模式，都要设置最大工具轮次，例如五轮以内，防止模型在工具失败时反复重试形成死循环。达到上限后应返回明确的兜底提示，而不是继续消耗请求。 异常治理要覆盖模型侧和工具侧。模型可能生成非法JSON、遗漏必填参数或选择不存在的工具，后端应返回可读错误，让模型有机会修正；工具可能超时、限流、返回空数据或权限不足，错误信息要包含错误码和简短原因，避免把堆栈暴露给模型。写操作需要幂等键，重试时不能重复创建计划或重复发送提醒。教学场景中，学情服务暂时不可用时，模型应告知用户数据服务暂不可用并建议稍后重试，而不是编造掌握度数据。 可观测性是长期运行的基础。每次请求记录trace_id、模型名称、轮次、工具名、参数摘要、执行耗时和状态码，统计工具调用成功率、无效调用率、平均轮次和P95延迟。只读工具结果可以在权限一致的前提下做短时缓存，写操作结果不适合缓存。系统提示中应明确要求模型不得虚构工具结果，工具返回为空时也要如实说明。把这些控制点做好，函数调用才不是演示功能，而是可运营的助教能力。
4. 智能助教场景的落地拆解
某在线教育机构的智能助教收到学生提问“函数部分比较薄弱，本周三前怎么复习”。系统提示把角色限定为AI指导老师，工具集包含get_learning_profile、search_resources、create_study_plan和create_reminder。第一轮模型调用get_learning_profile，后端从会话中注入学生标识，返回章节掌握度和最近练习正确率；第二轮模型根据薄弱点调用search_resources，参数为主题函数、难度基础、时长三十分钟，取回三个微课和五道练习题；第三轮模型调用create_study_plan生成复习安排，并在用户确认后调用create_reminder创建提醒。最终回复把工具结果组织成可执行的学习建议，而不是罗列原始JSON。 这个案例的工程拆分比提示词更重要。工具服务独立部署，经API网关鉴权，参数校验和结果裁剪在服务端完成，模型只负责选择工具和组织语言。学生标识、班级标识和租户标识不允许由模型自由填写，避免把A学生的数据查成B学生。写操作先返回预览，由模型询问用户是否确认，确认后再执行。审计日志记录谁在什么会话中调用了哪个工具、参数摘要和结果状态，既满足合规要求，也方便复盘模型选错工具的badcase。 效果评估应围绕任务完成而不是单轮回复。可以观察工具调用准确率、无效调用占比、平均工具轮次、任务完成率和用户修正率，再按学科、题型和用户群体拆解。若模型频繁把“查看作业”误调成“创建计划”，就要回到工具description和Schema找原因；若查询结果过长导致回复失焦，就要优化返回字段和裁剪策略。AI指导老师需要把教学策略写进工具边界和系统提示，再用真实badcase持续迭代，让函数调用真正服务于学习过程。
