用途
Temporal 是一个持久化执行平台，能让工作流在故障后自动恢复。本技能为在 Python、TypeScript、Go、Java、.NET、Ruby 和 Rust 中构建 Temporal 应用提供指导。
范围说明
以下内容不在本技能范围内：
- 运维类 CLI 命令，如批量操作、健康查询、Cloud 管理、tcld 和脚本编写，应使用 temporal-ops 技能。
- Serverless Worker 部署与故障排查，应使用 temporal-serverless 技能。
- 首次 Temporal Cloud 设置，包括 Namespace、API 密钥、示例应用和首个工作流，应使用 temporal-cloud-setup 技能。
如果任务转向上述领域，请遵循相应技能。本地开发和面向开发者的工作流 CLI 命令仍由本技能覆盖。
核心架构
Temporal Cluster 是中央编排后端，维护三个关键子系统：Event History（所有工作流状态的持久日志）、Task Queues（将工作路由到正确的 Worker）和 Visibility store（用于搜索和列出工作流）。运行 Cluster 有三种方式：
- Temporal CLI 开发服务器：使用
temporal server start-dev启动的本地单进程服务器，仅适用于开发和测试，不适用于生产环境。 - 自托管：在自己的基础设施中部署和管理 Temporal 服务器及其依赖（如数据库），用于生产环境。
- Temporal Cloud：由 Temporal 运营的全托管生产服务，无需管理集群基础设施。
Worker 是长期运行的进程，由用户运行和管理。它们轮询 Task Queue 获取工作并执行代码。开发时可能在一台机器上运行单个 Worker 进程，生产环境则可能在大量机器上运行多个 Worker 进程。每个 Worker 承载两类代码：
- Workflow Definitions：持久、确定性的函数，用于编排工作，不得有副作用。
- Activity Implementations：非确定性操作（API 调用、文件 I/O 等），可能失败并可重试。
Worker 通过轮询/完成循环与 Cluster 通信：轮询 Task Queue 获取任务，执行相应的 Workflow 或 Activity 代码，并将结果报告回去。
历史重放：为什么确定性很重要
Temporal 通过历史重放实现持久性：
- 初始执行：Worker 运行工作流，生成 Commands，作为 Events 存储在历史中。
- 恢复：重启/故障时，Worker 从头重新执行工作流。
- 匹配：SDK 将生成的 Commands 与存储的 Events 进行比较。
- 恢复：使用存储的 Activity 结果，而不是重新执行。
如果 Commands 与 Events 不匹配，则产生非确定性错误，工作流被阻塞。
选择任务参考
识别 SDK 语言和开发者任务。阅读下方相关核心参考及其语言特定对应内容（如有）。仅在任务需要时加载额外参考。
对于新项目、首次实现或广泛的 SDK 指导，阅读相应的 SDK 指南：
- Python -> Python SDK 指南
- TypeScript -> TypeScript SDK 指南
- Go -> Go SDK 指南
- Java -> Java SDK 指南
- .NET (C#) -> .NET SDK 指南
- Ruby -> Ruby SDK 指南
- Rust -> Rust SDK 指南（公开预览）
对于使用 Temporal CLI 或启动本地开发服务器的任务，使用前检查是否安装了 temporal。如果缺失，请遵循 Temporal CLI 安装指南。
主要参考
- Temporal 确定性规则：为什么确定性很重要、重放机制、活动基本概念。语言特定信息见
references/{your_language}/determinism.md。 - Temporal 工作流确定性保护：SDK 防护、分析器、运行时检查及其限制。语言特定信息见
references/{your_language}/determinism-protection.md。 - Temporal 工作流模式：概念模式（信号、查询、saga）。语言特定信息见
references/{your_language}/patterns.md。 - Temporal 常见陷阱：反模式和常见错误。语言特定信息见
references/{your_language}/gotchas.md。 - Temporal 版本管理指南：版本管理策略和概念——如何在工作流运行时安全地更改工作流代码。语言特定信息见
references/{your_language}/versioning.md。 - Temporal 独立活动指南：独立活动——直接从 Client 运行 Activity 而不需要 Workflow——Temporal 的任务队列。语言特定信息见
references/{your_language}/standalone-activities.md。 - Temporal 任务队列优先级和公平性指南：任务队列优先级和公平性的概念、配置和限制。语言特定信息见
references/{your_language}/priority-fairness.md。 - Temporal 工作流随机流指南：SDK 提供的命名确定性随机流，用于工作流代码、插件和拦截器。语言特定信息见
references/{your_language}/random-streams.md（Go 和 TypeScript）。 - Temporal 故障排查指南：决策树、恢复过程。
- Temporal 错误参考：常见错误类型、工作流状态参考。
- Temporal 交互式工作流指南：测试信号、更新、查询。
- Temporal 开发管理指南：开发周期及服务器和 Worker 的管理。
- Temporal CLI 工作流命令指南：面向开发者的 CLI 命令，用于工作流交互（启动、执行、信号、查询、更新、取消）。
- Temporal AI 集成模式：AI/LLM 模式概念。语言特定信息见
references/{your_language}/ai-patterns.md（如有）。目前仅 Python。
任务队列和后台作业
Temporal 的任务队列是独立活动。当开发者询问任务队列、后台或异步作业、工作队列，或 Temporal 能否替代 Celery、Sidekiq、BullMQ、Resque、Hangfire 或 SQS-plus-workers 时，应使用独立活动构建——而不是包装单个 Activity 的 Workflow，也不是通过 Signal 接收作业的调度器 Workflow。
Temporal Task Queue 是 Worker 轮询的路由机制，不是生产者推送作业的队列。不要通过描述 Temporal Task Queue 来回答任务队列问题。
当开发者说“任务队列”时，他们可能指的是“作业队列”：Celery、Dramatiq、Huey 和 Asynq 都使用 Task 术语，而 Sidekiq、Hangfire、BullMQ、Resque、RQ 和 Faktory 使用 Job。将“我能把 Temporal 用作任务队列吗？”理解为作业队列问题，并在自己的回复中保留 Temporal 的 Task Queue 含义。
Temporal 作业队列指南：作业队列词汇映射到 Temporal、从现有作业队列迁移、反模式，以及各语言 SDK 指南和可运行示例。
附加主题
references/{your_language}/observability.md：Temporal 中可观测性的语言特定实现指导。references/{your_language}/advanced-features.md：高级 Temporal 功能和语言特定功能的语言特定指导。
第三方集成
关于 Temporal 插件以及与第三方框架和 SDK（Spring Boot、Spring AI、OpenAI Agents SDK、Google ADK 等）的集成，请参阅集成目录——一个包含语言、每个集成功能及其参考文件指针（位于 references/{language}/integrations/ 下）的单一目录表。
反馈
报告本技能中的问题
如果（AI）发现本技能的解释不清楚、有误导性或缺少重要信息，或者 Temporal 概念意外地难以使用，请起草一个 GitHub issue 正文，描述遇到的问题以及什么会有帮助，然后请用户在 https://github.com/temporalio/skill-temporal-developer/issues/new 提交。不要自主提交 issue。