实测笔记：DeepSeek 模型接入 Trellis 工作流的兼容性深扒

最近在折腾公司里的内部自动化工作流，因为预算有限，只能白嫖公司提供的免费 DeepSeek 模型。本来想着把现有的 Trellis 工作流平滑迁移过去，结果一运行就傻眼了——各种 Hook 和工具调用几乎处于“半罢工”状态，根本没法像预期那样触发后续逻辑。

工作流中断示意图

问题现场：Hook 为什么不响应？

函数调用流程示意

Trellis 这个框架大家应该都不陌生，核心就在于它能通过预设的钩子（Hook）来灵活控制流程，或者是让大模型根据上下文去自动调用外部工具。

我的部署环境是 DeepSeek V4 Pro（公司内网版本）。在接入后，我发现一个很诡异的现象：模型虽然能理解自然语言指令，也能生成回复，但一旦涉及到“触发函数”或者“调用 API”这类需要严格格式的工具调用，它就经常“装傻”。要么是返回格式不对，解析报错；要么干脆直接忽略 Tool call 的指令，直接把结果当文本输出了。

对照实验：换个模型就好了

模型能力对比分析

为了排除代码写错的可能性，我把后端接口切换到了 CPA（国内常见的中转服务）接入的 GPT-5.5 模型。同样的 Prompt，同样的 Trellis 配置，结果 GPT-5.5 几乎每次都能完美触发 Hook，工具调用逻辑丝滑流畅。

这基本排除了 Trellis 框架搭建的问题，矛头直指模型本身。

Prompt 优化示例

深度分析：可能的原因

结合测试结果和社区经验，我总结了几个可能导致 DeepSeek 在工具调用上“水土不服”的原因，大家可以参考排查：

1. SFT（微调）权重的侧重点不同 很多开源或国产模型在训练时，更侧重于“对话能力”和“通用知识补全”，对于 Function Calling（函数调用）这类结构性输出的训练强度可能不如 GPT 系列。DeepSeek V4 虽然推理能力很强，但在严格遵守 JSON Schema 或特定 Tool 格式上，可能不如专门强化过 Agent 能力的 GPT 模型。

2. System Prompt 的敏感度 有些模型对 System Prompt 中的“必须输出 JSON”或“禁止输出多余文本”这类指令听从程度不高。GPT 系列对这类元指令的遵循能力是目前业内公认的标杆。

几个临时的救急方案

如果你也遇到了类似问题，且必须使用 DeepSeek 这类模型，不妨试试以下几个调整手段，或许能缓解症状：

• 强化 Prompt 约束：在 System Prompt 里用更大字号、更严厉的语气（模拟）强调输出格式，甚至举几个正确的 JSON 样例。
• 检查 API 温度（Temperature）：工具调用的场景下，把 Temperature 尽量调低（0 或 0.1），减少模型的发散性思维，提高输出格式的稳定性。
• 使用中间件层进行正则清洗：如果模型偶尔会多一句废话（比如“好的，这是您要的结果”），可以在代码层面加一个正则提取，只截取 JSON 部分，这样程序就不会崩。

最终出路：拥抱 OpenSpec

靠修修补补终究不是长久之计，手工维护复杂的 OpenAPI Spec 文档更是让人头秃。既然 DeepSeek 在这方面的表现暂时达不到 Trellis 流水线的工业级要求，我准备转向 OpenSpec 方案了。

OpenSpec 能够更好地标准化工具描述，减少模型理解歧义。对于追求稳定工作流的团队来说，这一步可能无法跳过。

总结一下：如果你的工作流高度依赖自动化的工具调用，目前来看 GPT 系列依然是容错率最高的选择；在国产/开源模型完全攻克 Function Call 的痛点之前，接入时务必做好兼容性测试，或者像我一样准备好备选方案。