deepseek本身不内置cron调度能力，所有定时任务均依赖外部调度器调用其api；必须显式配置shell、path、环境变量密钥、完整messages上下文，并统一时区与实现重试逻辑。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek 本身不内置 cron 调度能力，所有“DeepSeek + 定时任务”的自动化，本质是用外部调度器（如系统 crontab、GitHub Actions、n8n、Airflow）调用 DeepSeek API，关键在调度层与 API 调用的衔接是否健壮。
crontab 调用 DeepSeek API 必须处理的三件事
直接写 0 9 * * * curl -X POST https://api.deepseek.com/v1/chat/completions ... 会失败——不是模型问题，是环境缺失导致的典型链路断裂。
- 必须显式指定
SHELL=/bin/bash和PATH，否则 cron 环境找不到curl或 Python 解释器 - API 密钥不能硬编码在脚本里，需通过
DEEPSEEK_API_KEY环境变量注入（crontab -e中加DEEPSEEK_API_KEY="sk-xxx"行），否则日志里会明文泄露 - 每次请求必须带完整上下文：新闻原文或提示词不能靠“上次对话记忆”，cron 是无状态的，
messages数组必须每次构造完整，包括 system 角色定义和用户输入
GitHub Actions 中定时触发 DeepSeek 的坑点
cron: '0 7 * * *' 在 GitHub Actions 中对应 UTC 时间，不是北京时间。你看到的“每天早上 7 点”其实是 UTC+0 的 7 点，即北京时间 15:00。要真正按北京时间 7 点执行，得写成 cron: '0 23 * * *'（UTC 23:00 = CST 次日 7:00）。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- Python 脚本中调用
requests.post时，timeout参数必须设（建议(10, 30)），否则网络抖动会导致整个 workflow 卡住超时失败 - 错误响应不要只 print，要用
sys.exit(1)触发 workflow 失败态，否则即使 API 返回 401，Actions 也默认标记为 success - 飞书/钉钉推送失败不能静默吞掉，需把
response.status_code和response.text写入echo "::error::"，才能在 Actions 日志里直接定位是 DeepSeek 还是 Webhook 出问题
n8n 工作流里调用 DeepSeek API 的配置细节
n8n 的 HTTP Request 节点默认不发送 Content-Type: application/json，而 DeepSeek API 强制要求该 header，漏掉就会返回 415 Unsupported Media Type。
- Headers 面板必须手动添加键值对：
Content-Type → application/json，不能依赖自动推断 - Body 选 “JSON” 模式后，内容必须是纯 JSON 对象，不能包裹在
data:或其他字段下；常见错误是写成{"data": {"model": "...", "messages": [...]}}，正确格式是{"model": "...", "messages": [...]} - DeepSeek 的
max_tokens建议设为 2048 起步，低于 1024 容易截断摘要；若返回"finish_reason": "length"，说明被强制截断，不是模型没想完
最常被忽略的是时区与重试逻辑：系统 crontab 默认用系统时区，但 n8n 和 GitHub Actions 的 cron 字段默认是 UTC，混用不统一就会“明明配了 9 点却收到 17 点的简报”。另外，DeepSeek API 没有内置重试，所有重试必须由调度层实现——比如 n8n 要开节点级 retry，GitHub Actions 要用 if: ${{ failure() }} + 重试 job，crontab 则只能靠脚本内嵌指数退避。
