DeepSeek 不是插件式工作流引擎，需由外部系统（如 Airflow、Camunda）负责流程调度，DeepSeek 仅处理决策逻辑；调用必须带 context_id 以维持状态；须用异步服务任务封装 API 调用；输出需经 Pydantic schema 校验；并严格裁剪上下文防 token 超限。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek 不是插件式工作流引擎，它本身不提供原生的 BPMN 编排能力；集成时必须明确区分「决策逻辑」和「流程调度」职责——前者由 DeepSeek 承担，后者得靠外部工作流系统（如 Apache Airflow、Camunda 或自研调度器）驱动。
DeepSeek API 调用必须带 context_id 参数
在自动化工作流中重复调用 deepseek-api 时，若忽略上下文标识，模型会丢失对话历史与任务状态。例如审批流中连续调用三次 /v1/decision 接口，不传 context_id 就等同于三次独立提问，无法支撑多步推理。
实操建议：
- 每次流程启动时生成唯一
context_id（推荐 UUID4），并贯穿整个 DAG 的所有 DeepSeek 调用节点 - 在工作流存储层（如 Redis）以
context_id为 key 持久化中间状态，供后续步骤读取 - 避免把
context_id硬编码进配置文件或环境变量，应由调度器动态注入到每个任务的 payload 中
不能直接在 Camunda 的 <scriptTask> 里执行同步 HTTP 请求
Camunda 默认脚本任务运行在 Java 主线程，同步阻塞式调用 deepseek-api 容易触发超时（默认 5s），且无法处理重试、熔断、fallback 等容错逻辑。
正确做法是把 DeepSeek 调用封装为异步服务任务：
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- 用 Spring Boot 写一个
DeepSeekDecisionService，内部使用WebClient+RetryTemplate实现带退避的重试 - 在 Camunda 流程图中将该服务注册为
<serviceTask>，类型设为external - 通过
topic订阅机制由外部 worker 拉取任务，执行完再回调complete()
错误示例：<scriptTask scriptFormat="javascript">...fetch("https://api.deepseek.com/v1/analyze")...</scriptTask> —— 这类写法在高并发下极易导致线程池耗尽。
输出结构不稳定时，必须加 schema 校验层
DeepSeek 的 JSON 输出受 prompt 影响大，即使固定 prompt，在低负载/高负载切换时也可能返回字段缺失或类型错乱（比如 "risk_score": "0.42" 字符串 vs "risk_score": 0.42 数字）。工作流下游若直接解析，容易抛 KeyError 或类型转换异常。
建议在调用后立即插入轻量校验：
- 用 Pydantic v2 的
RootModel定义强约束 schema，例如要求risk_score: float、action: Literal["approve", "reject", "escalate"] - 校验失败时统一走 fallback 分支（如人工审核节点），而非让整个流程中断
- 不要依赖
json.loads(response.text).get("risk_score", 0.0)这类宽松写法——它掩盖了模型输出漂移问题
最易被忽略的一点：DeepSeek 的 token 限长对长流程极其敏感。一个含 5 个决策节点的工作流，若每个节点都传入完整日志上下文，很容易在第 3 步就触发 413 Request Entity Too Large。必须在调度器侧做上下文裁剪，只保留最近 2 轮交互 + 当前任务所需字段，而不是无脑透传全部 history。
