devos/Docs/DevOS-Platform-v2/04_EVENT_TASK_JOB.md

# `04_EVENT_TASK_JOB.md`

> DevOS Developer Work OS
> Event / Task / Job / Execution / Queue / Scheduler / Workflow 设计规范
> Version: 1.0

---

## 1. 文档目标

本模块定义 DevOS 的**异步执行基础设施**。

上一份 `03_RESOURCE_ACTION_MODEL.md` 已经确定：

> 所有业务行为最终都必须进入 `Action Runtime`。

但真实系统中，大量 Action 不适合在 HTTP 请求生命周期内直接完成，例如：

* 扫描网站
* SSH 执行命令
* Docker 操作
* Git Clone
* DNS 检测
* 批量生成内容
* 批量外链提交
* AI Agent 执行任务
* 定时任务
* 大规模数据同步
* 文件处理
* 部署
* 监控检查

因此 DevOS 必须在 Action Runtime 之上建立统一的：

```text
Event
Task
Job
Execution
Queue
Scheduler
Workflow
Worker
```

体系。

核心目标：

> **任何耗时、可重试、可取消、可恢复、可观察的操作，都必须进入统一 Execution Runtime。**

---

# 2. 核心模型

DevOS 不应该把：

```text
Task
Job
Workflow
Queue
Cron
Agent Task
```

设计成互相独立的系统。

统一模型：

```text
Event
  ↓
Trigger
  ↓
Task
  ↓
Workflow
  ↓
Action
  ↓
Execution
  ↓
Job
  ↓
Worker
```

其中：

```text
Task
```

是**业务任务**。

```text
Execution
```

是**一次具体执行实例**。

```text
Job
```

是进入队列、等待 Worker 执行的工作单元。

---

# 3. Event

Event 表示：

> 系统中已经发生了一件事情。

例如：

```text
user.created
website.created
website.scan.completed
deployment.failed
server.offline
task.completed
plugin.installed
agent.goal.created
```

Event 不负责执行。

Event 只描述：

```text
发生了什么
```

---

## 3.1 Event 结构

```ts
interface DevOSEvent<T = unknown> {
  id: string

  type: string

  version: number

  timestamp: string

  actor?: Actor

  organizationId?: string

  resource?: {
    type: string
    id: string
  }

  data: T

  metadata?: Record<string, unknown>

  correlationId?: string

  causationId?: string
}
```

例如：

```json
{
  "id": "evt_123",
  "type": "website.created",
  "version": 1,
  "timestamp": "2026-09-08T12:00:00Z",
  "resource": {
    "type": "seo.website",
    "id": "web_001"
  },
  "data": {
    "domain": "example.com"
  }
}
```

---

# 4. Event Bus

DevOS 使用统一 Event Bus。

```text
Action Runtime
      │
      ▼
   Event Bus
      │
 ┌────┼──────────┐
 ▼    ▼          ▼
Task  Plugin   Agent
 │
 ▼
Workflow
```

Event Bus 必须支持：

* publish
* subscribe
* retry
* dead letter
* ordering
* correlation
* tracing

---

## 4.1 Event Handler

插件可以订阅事件：

```ts
eventBus.subscribe(
  "website.created",
  async event => {
    // ...
  }
)
```

但 Handler 不应该直接执行大量业务逻辑。

推荐：

```text
Event Handler
     ↓
Create Task
     ↓
Queue
     ↓
Worker
     ↓
Action
```

而不是：

```text
Event Handler
     ↓
直接执行 30 秒任务
```

---

# 5. Task

Task 表示：

> 用户、Agent、系统要求完成的一项业务工作。

例如：

```text
扫描 example.com
部署项目
同步 GitHub Repository
检查服务器
生成 100 篇文章
提交 200 个外链
```

Task 是业务层概念。

---

## 5.1 Task 状态

```text
draft
queued
running
waiting
paused
completed
failed
cancelled
```

推荐状态机：

```text
draft
  │
  ▼
queued
  │
  ▼
running
 ┌┼───────────────┐
 ▼▼               ▼
waiting        completed
 │
 ▼
running

running
 ├── failed
 └── cancelled
```

---

# 6. Task 数据模型

```ts
interface Task {
  id: string

  type: string

  name?: string

  description?: string

  status: TaskStatus

  priority: number

  organizationId: string

  projectId?: string

  resource?: ResourceRef

  input?: unknown

  output?: unknown

  createdBy: Actor

  parentTaskId?: string

  workflowId?: string

  createdAt: Date

  startedAt?: Date

  completedAt?: Date

  error?: TaskError
}
```

---

# 7. Task Type

Task 必须拥有 namespace。

例如：

```text
core.backup
devops.deploy
devops.server.scan
seo.website.scan
seo.content.generate
seo.link.build
agent.goal.execute
```

插件：

```text
plugin.cloudflare.dns.sync
plugin.github.repository.sync
plugin.wordpress.publish
```

---

# 8. Job

Job 是：

> Task 中需要实际执行的工作单元。

一个 Task 可以包含多个 Job。

例如：

```text
Task:
SEO 网站优化

Jobs:
 ├── Crawl Website
 ├── Analyze Keywords
 ├── Generate Content
 ├── Publish Content
 └── Build Backlinks
```

因此：

```text
Task ≠ Job
```

---

# 9. Job 生命周期

```text
pending
  ↓
queued
  ↓
running
  ↓
completed
```

异常：

```text
running
 ├── retrying
 │     ↓
 │   queued
 │
 ├── failed
 │
 └── cancelled
```

---

# 10. Execution

Execution 是 DevOS 最重要的运行时概念之一。

定义：

> 一个 Action 被实际执行一次，就是一个 Execution。

例如：

```text
Action:
seo.website.scan

Execution:
exec_123
```

同一个 Action 可以执行：

```text
exec_001
exec_002
exec_003
```

---

## 10.1 Execution 数据

```ts
interface ActionExecution {
  id: string

  actionId: string

  taskId?: string

  jobId?: string

  status: ExecutionStatus

  mode: "sync" | "async" | "stream"

  actor: Actor

  input: unknown

  output?: unknown

  error?: ExecutionError

  progress?: ExecutionProgress

  startedAt?: Date

  completedAt?: Date

  duration?: number

  attempt: number

  maxAttempts: number

  createdAt: Date
}
```

---

# 11. Task / Job / Execution 的关系

必须严格区分：

```text
Task
  │
  ├── Job
  │     └── Execution
  │
  ├── Job
  │     └── Execution
  │
  └── Job
        └── Execution
```

例如：

```text
Task: 部署网站

Job 1: Build
Execution 1

Job 2: Upload
Execution 1

Job 3: Restart Container
Execution 1
```

如果 Job 重试：

```text
Job
 ├── Execution attempt 1 → failed
 ├── Execution attempt 2 → failed
 └── Execution attempt 3 → completed
```

因此：

> **Execution 是不可复用的执行记录。**

---

# 12. Queue

Queue 负责：

> 把待执行 Job 从生产者传递给 Worker。

架构：

```text
Action Runtime
      │
      ▼
     Job
      │
      ▼
    Queue
      │
      ▼
    Worker
      │
      ▼
   Execution
```

---

# 13. Queue 类型

DevOS 初期至少支持：

```text
default
high
low
scheduled
agent
workflow
```

但不要为每种业务创建独立 Queue 系统。

应该统一 Queue Runtime：

```ts
queue.enqueue({
  queue: "default",
  jobId,
  priority
})
```

---

# 14. Worker

Worker 是真正执行 Job 的进程。

```text
┌─────────────────────┐
│      DevOS API      │
└──────────┬──────────┘
           │
           ▼
        Queue
           │
    ┌──────┼──────┐
    ▼      ▼      ▼
 Worker  Worker  Worker
```

Worker：

1. 获取 Job
2. 创建 Execution
3. 加载 Action
4. 验证 Input
5. 检查权限
6. 执行 Action
7. 更新 Progress
8. 保存 Result
9. 写 Audit
10. 发布 Event

---

# 15. Worker 不允许绕过 Action Runtime

这是 DevOS 的核心规则。

错误：

```ts
worker(async job => {
  await prisma.website.update(...)
})
```

正确：

```ts
worker(async job => {
  await actionRuntime.execute({
    action: "seo.website.scan",
    input: job.input
  })
})
```

也就是说：

```text
Worker
  ↓
Action Runtime
  ↓
Action
```

而不是：

```text
Worker
  ↓
Database
```

---

# 16. Retry

所有异步 Job 必须支持 Retry Policy。

```ts
interface RetryPolicy {
  maxAttempts: number

  strategy:
    | "fixed"
    | "linear"
    | "exponential"

  delayMs: number

  maxDelayMs?: number

  retryOn?: string[]
}
```

例如：

```json
{
  "maxAttempts": 5,
  "strategy": "exponential",
  "delayMs": 1000,
  "maxDelayMs": 60000
}
```

执行：

```text
1s
2s
4s
8s
16s
```

---

# 17. 什么错误可以 Retry

应该区分：

### Retryable

```text
network timeout
connection reset
temporary API failure
rate limit
temporary database error
503
```

### Non-Retryable

```text
permission denied
invalid input
resource not found
authentication failed
business rule violation
```

Action 可以定义：

```ts
retryableErrors: [
  "NETWORK_TIMEOUT",
  "RATE_LIMIT",
  "TEMPORARY_UNAVAILABLE"
]
```

---

# 18. Dead Letter Queue

超过最大 Retry：

```text
Job
 ↓
retry
 ↓
retry
 ↓
retry
 ↓
failed
 ↓
DLQ
```

Dead Letter Queue 用于：

* 人工检查
* Debug
* 恢复
* 重新执行

UI 应提供：

```text
Failed Jobs

[Retry]
[Replay]
[Cancel]
[View Error]
[View Logs]
```

---

# 19. Progress

长任务必须支持 Progress。

```ts
interface ExecutionProgress {
  current: number

  total?: number

  percentage?: number

  message?: string

  phase?: string
}
```

例如：

```text
SEO Scan

Phase: Crawl

████████████░░░░ 72%

723 / 1000 pages
```

Worker：

```ts
ctx.progress({
  current: 723,
  total: 1000,
  phase: "crawl",
  message: "Scanning pages"
})
```

---

# 20. Cancellation

Task 必须支持取消。

```text
User
 ↓
Cancel Task
 ↓
Task.cancel()
 ↓
AbortSignal
 ↓
Worker
 ↓
Action
```

Action Context：

```ts
interface ActionContext {
  signal: AbortSignal
}
```

Action：

```ts
if (ctx.signal.aborted) {
  throw new CancelledError()
}
```

---

# 21. Pause / Resume

不是所有任务都可以 Pause。

Action 可以声明：

```ts
supportsPause: true
```

如果支持：

```text
running
   ↓
paused
   ↓
running
```

如果不支持：

```text
Cancel
+
Create new execution
```

不要强行模拟所有 Action 都可以暂停。

---

# 22. Scheduler

Scheduler 负责：

> 在指定时间触发 Task。

支持：

```text
once
interval
cron
event-driven
```

例如：

```text
每天 02:00
每 30 分钟
每周一
每次网站创建后
```

---

# 23. Schedule

```ts
interface Schedule {
  id: string

  name: string

  actionId?: string

  taskType: string

  scheduleType:
    | "once"
    | "interval"
    | "cron"
    | "event"

  expression?: string

  timezone?: string

  enabled: boolean

  input?: unknown

  nextRunAt?: Date

  lastRunAt?: Date
}
```

---

# 24. Cron

例如：

```text
0 2 * * *
```

表示：

```text
每天凌晨 2 点
```

但是：

> Scheduler 不应该直接执行 Action。

必须：

```text
Scheduler
   ↓
Create Task
   ↓
Create Job
   ↓
Queue
   ↓
Worker
   ↓
Action Runtime
```

---

# 25. 为什么 Scheduler 不能直接执行

错误：

```text
Cron
 ↓
Action
```

正确：

```text
Cron
 ↓
Task
 ↓
Job
 ↓
Queue
 ↓
Execution
```

这样才能获得：

* Audit
* Retry
* Progress
* Cancellation
* Observability
* History
* Permission
* Agent compatibility

---

# 26. Workflow

Workflow 是：

> 多个 Action / Task 按逻辑组合形成的业务流程。

例如：

```text
Website Scan
      ↓
Analyze
      ↓
Generate Report
      ↓
Notify User
```

---

# 27. Workflow 不应该成为第二套执行引擎

这是非常重要的一点。

不要实现：

```text
Action Runtime
Workflow Runtime
Agent Runtime
Plugin Runtime
```

四套执行逻辑。

正确：

```text
             Workflow
                │
                ▼
          Action Runtime
                │
          ┌─────┼─────┐
          ▼     ▼     ▼
       Action Action Action
```

Workflow 只是**编排层**。

---

# 28. Workflow Node

```ts
interface WorkflowNode {
  id: string

  type:
    | "action"
    | "condition"
    | "parallel"
    | "foreach"
    | "wait"
    | "approval"

  config: unknown
}
```

例如：

```text
Node A: website.scan
Node B: website.analyze
Node C: condition
Node D: content.generate
Node E: publish
```

---

# 29. Workflow Edge

```ts
interface WorkflowEdge {
  from: string

  to: string

  condition?: string
}
```

形成：

```text
A
│
▼
B
│
▼
C
├── true  → D
└── false → E
```

---

# 30. Parallel

Workflow 必须支持并行。

```text
           Scan
             │
       ┌─────┼─────┐
       ▼     ▼     ▼
     SEO   Links  Content
       │     │     │
       └─────┼─────┘
             ▼
           Report
```

---

# 31. Foreach

例如：

```text
100 Websites
```

执行：

```text
foreach website:
    website.scan
```

而不是生成一个包含 100 个硬编码节点的 Workflow。

---

# 32. Approval

危险操作必须支持人工审批。

例如：

```text
Agent
 ↓
Generate deployment plan
 ↓
Approval
 ↓
Deploy
```

或者：

```text
Agent
 ↓
Build 200 backlinks
 ↓
Approval
 ↓
Execute
```

Workflow Node：

```ts
{
  type: "approval",
  config: {
    requiredRole: "admin"
  }
}
```

---

# 33. Wait

Workflow 需要支持等待。

例如：

```text
Deploy
 ↓
Wait 10 minutes
 ↓
Health Check
```

不要让 Worker：

```ts
await sleep(10 * 60 * 1000)
```

这会浪费 Worker。

应该：

```text
Workflow
 ↓
Create delayed Job
 ↓
Worker release
 ↓
Queue
 ↓
10 minutes later
 ↓
continue
```

---

# 34. Event-driven Workflow

Workflow 可以等待 Event。

例如：

```text
Create Deployment
 ↓
WAIT deployment.completed
 ↓
Run Health Check
```

这比轮询更加高效。

---

# 35. Task 与 Agent

Agent 不应该拥有独立 Task 系统。

正确：

```text
Agent
 ↓
Goal
 ↓
Plan
 ↓
Task
 ↓
Action
 ↓
Execution
```

例如用户：

```text
让 example.com 在 10 天内提升 SEO
```

Agent：

```text
Goal
 ↓
Plan
 ├── Website Scan
 ├── Keyword Research
 ├── Content Generation
 ├── Content Publishing
 └── Backlink Building
```

这些全部转换为：

```text
Task
```

然后使用统一 Task Runtime。

---

# 36. Agent 与 Workflow

Agent 可以动态生成 Workflow。

例如：

```text
Goal
 ↓
Agent Planning
 ↓
Workflow
 ↓
Task
 ↓
Action
```

但 Agent 也可以直接创建 Task：

```text
Agent
 ↓
Task
 ↓
Action
```

因此：

```text
Workflow = 固定/半固定流程

Agent = 动态决策
```

两者不是竞争关系。

---

# 37. Plugin 与 Task

Plugin 可以注册：

```text
Action
Resource
Event
Task Type
Workflow Node
Scheduler
UI
```

例如 GitHub Plugin：

```text
plugin.github
 ├── Resource
 │    └── repository
 │
 ├── Action
 │    ├── repository.sync
 │    ├── repository.create
 │    └── repository.dispatch
 │
 └── Events
      ├── repository.updated
      └── workflow.completed
```

所有执行仍然经过：

```text
Action Runtime
```

---

# 38. MCP 与 Task

MCP 是能力访问层。

例如 MCP Tool：

```text
seo_scan_website
```

不要直接执行：

```text
MCP
 ↓
HTTP
 ↓
业务代码
```

应该：

```text
MCP Tool
 ↓
Action
 ↓
Action Runtime
 ↓
Task / Execution
```

因此 MCP 只是 Action Runtime 的一个入口。

---

# 39. CLI

CLI 同样如此：

```bash
devos action seo.website.scan
```

内部：

```text
CLI
 ↓
Action Runtime
 ↓
Execution
```

---

# 40. API

HTTP：

```http
POST /api/actions/seo.website.scan
```

内部：

```text
HTTP Controller
 ↓
Action Runtime
 ↓
Execution
```

---

# 41. UI

按钮：

```text
[Scan Website]
```

内部：

```text
UI
 ↓
API
 ↓
Action Runtime
 ↓
Task
 ↓
Job
```

---

# 42. 所有入口统一

最终 DevOS 必须形成：

```text
                     ┌── UI
                     │
                     ├── REST API
                     │
                     ├── GraphQL
                     │
                     ├── CLI
                     │
                     ├── MCP
                     │
                     ├── Agent
                     │
                     ├── Plugin
                     │
                     └── Scheduler
                            │
                            ▼
                     Action Runtime
                            │
                            ▼
                         Task
                            │
                            ▼
                           Job
                            │
                            ▼
                          Queue
                            │
                            ▼
                         Worker
                            │
                            ▼
                        Execution
                            │
                            ▼
                          Event
```

这是 DevOS 最重要的基础设施闭环之一。

---

# 43. 数据库设计

建议 PostgreSQL。

核心表：

```text
events
tasks
jobs
executions
schedules
workflows
workflow_nodes
workflow_edges
task_logs
execution_logs
dead_letter_jobs
```

---

# 44. Event 表

```sql
events
-----
id
type
version
organization_id
actor_type
actor_id
resource_type
resource_id
data
metadata
correlation_id
causation_id
created_at
```

---

# 45. Task 表

```sql
tasks
-----
id
type
name
status
priority
organization_id
project_id
resource_type
resource_id
input
output
created_by
parent_task_id
workflow_id
created_at
started_at
completed_at
error
```

---

# 46. Job 表

```sql
jobs
----
id
task_id
queue
status
priority
attempt
max_attempts
available_at
started_at
completed_at
worker_id
error
created_at
```

---

# 47. Execution 表

```sql
executions
----------
id
action_id
task_id
job_id
status
mode
actor
input
output
error
attempt
started_at
completed_at
duration
created_at
```

---

# 48. Schedule 表

```sql
schedules
---------
id
name
task_type
action_id
schedule_type
expression
timezone
enabled
input
next_run_at
last_run_at
created_at
```

---

# 49. Log

日志不要全部塞到 Task 表。

单独：

```text
execution_logs
```

例如：

```ts
interface ExecutionLog {
  executionId: string

  level: "debug" | "info" | "warn" | "error"

  message: string

  metadata?: Record<string, unknown>

  timestamp: Date
}
```

---

# 50. Correlation ID

所有任务链必须支持：

```text
correlationId
causationId
requestId
executionId
taskId
jobId
```

例如：

```text
HTTP Request
requestId=req_001

Agent Goal
correlationId=goal_001

Task
taskId=task_001

Job
jobId=job_001

Execution
executionId=exec_001
```

这样才能追踪完整链路。

---

# 51. Observability

每一次 Execution 至少应该能够看到：

```text
Status
Duration
Worker
Attempts
Input
Output
Error
Logs
Progress
Events
Parent Task
Triggered By
```

UI：

```text
Task Detail
────────────────────────────

Status: Running

Progress: 72%

Execution
  exec_123

Attempt: 2 / 5

Worker:
  worker-03

Duration:
  01:23

Logs:
  ...
```

---

# 52. Concurrency

Task / Action 可以定义：

```ts
concurrency: {
  max: 5
}
```

例如：

```text
SEO Crawl
max concurrency = 5
```

避免：

```text
1000 websites
 ↓
1000 simultaneous requests
 ↓
system collapse
```

---

# 53. Resource Lock

某些 Action 需要锁。

例如：

```text
deploy project A
```

同一个 Project 不允许同时：

```text
deploy A
deploy A
```

可以：

```ts
lock: {
  key: "project:{projectId}:deployment"
}
```

系统：

```text
Job A → lock acquired
Job B → waiting
```

---

# 54. Idempotency

异步任务必须考虑重复执行。

例如：

```text
publish article
```

如果 Worker：

```text
执行成功
 ↓
Worker crash
 ↓
没有保存 completed
 ↓
Retry
```

可能导致重复发布。

因此 Action 应支持：

```ts
idempotencyKey
```

例如：

```text
publish:{articleId}:{version}
```

---

# 55. Transaction Boundary

不要试图把整个异步任务放进一个数据库 Transaction。

错误：

```text
BEGIN
 ↓
HTTP API
 ↓
SSH
 ↓
Docker
 ↓
GitHub
 ↓
COMMIT
```

正确：

```text
DB transaction
 ↓
Create Task
 ↓
COMMIT

Worker
 ↓
Action
 ↓
external system
 ↓
Save result
```

外部系统必须通过：

```text
idempotency
retry
compensation
```

处理一致性。

---

# 56. Task Result

Task 最终应该有统一结果：

```ts
interface TaskResult<T = unknown> {
  success: boolean

  output?: T

  error?: {
    code: string
    message: string
    details?: unknown
  }

  statistics?: {
    duration: number
    attempts: number
  }
}
```

---

# 57. Event → Task

系统可以配置：

```text
Event
 ↓
Trigger Rule
 ↓
Task
```

例如：

```text
deployment.failed
        ↓
create:
monitor.health_check
```

或者：

```text
server.created
        ↓
install:
server.monitor
```

---

# 58. Trigger

Trigger 可以有三种：

```text
Event Trigger
Schedule Trigger
Manual Trigger
```

未来可以增加：

```text
Webhook Trigger
Condition Trigger
Agent Trigger
```

统一模型：

```ts
interface Trigger {
  id: string

  type: string

  config: unknown

  enabled: boolean

  target: {
    taskType: string
  }
}
```

---

# 59. Task Template

重复任务应该支持 Template。

例如：

```text
Website Daily SEO Check
```

模板：

```ts
{
  type: "seo.website.daily_check",

  input: {
    websiteId: "{{resource.id}}"
  }
}
```

Scheduler 使用 Template 创建 Task。

---

# 60. Task Tree

Task 支持父子关系。

```text
SEO Project
│
├── Website Scan
│
├── Keyword Research
│
├── Content
│   ├── Article 1
│   ├── Article 2
│   └── Article 3
│
└── Backlinks
    ├── Link 1
    ├── Link 2
    └── Link 3
```

这样 Agent 可以管理大型任务。

---

# 61. Task 与 Project

Project 是 Resource。

Task 可以关联 Project：

```text
Project
  │
  ├── Task
  ├── Task
  └── Task
```

因此可以获得：

```text
Project Dashboard
 ├── Running Tasks
 ├── Completed Tasks
 ├── Failed Tasks
 ├── Cost
 └── Execution Time
```

---

# 62. Cost Tracking

由于未来会有 Agent / AI Task，Execution 应支持 Cost。

```ts
interface ExecutionCost {
  provider?: string

  model?: string

  inputTokens?: number

  outputTokens?: number

  credits?: number

  money?: number

  currency?: string
}
```

这样：

```text
Project
 ↓
AI Cost
 ↓
$23.51
```

可以统一统计。

---

# 63. Resource Event

Resource 的变化应该自动产生 Event。

例如：

```text
Resource:
seo.website

Action:
update

Result:
updated

Event:
seo.website.updated
```

这样插件不需要侵入核心业务。

---

# 64. Event Sourcing

**第一版不要把 DevOS 做成完整 Event Sourcing 系统。**

使用：

```text
State in PostgreSQL
+
Event Log
```

即可。

也就是说：

```text
Database = current state

Event = historical fact
```

未来如果确实需要，再增加 Event Sourcing。

---

# 65. 推荐基础设施

第一阶段：

```text
PostgreSQL
Redis
Queue
Worker
Scheduler
```

如果使用 TypeScript：

```text
NestJS
+
BullMQ
+
Redis
+
PostgreSQL
```

是比较成熟且简单的实现组合。

---

# 66. BullMQ 的定位

如果采用 BullMQ：

```text
DevOS Queue Runtime
        │
        ▼
      BullMQ
        │
        ▼
      Redis
```

但：

> DevOS 业务层不能直接依赖 BullMQ API。

应该封装：

```ts
interface QueueRuntime {
  enqueue(job: JobPayload): Promise<void>

  cancel(jobId: string): Promise<void>

  retry(jobId: string): Promise<void>

  get(jobId: string): Promise<JobStatus>
}
```

未来可以替换：

```text
BullMQ
Temporal
RabbitMQ
SQS
NATS
```

而不用修改业务代码。

---

# 67. 第一版不要引入 Temporal

Temporal 很强，但 DevOS 第一版不需要立即依赖。

建议：

```text
V1:
BullMQ + Redis

V2:
根据 Workflow 复杂度决定是否引入 Temporal
```

尤其是：

```text
long-running workflow
durable execution
复杂 compensation
跨服务 workflow
```

真正出现需求后再升级。

---

# 68. Runtime 分层

最终后端结构建议：

```text
apps/
  api/
  worker/
  scheduler/

packages/
  core/
  resource/
  action/
  event/
  task/
  execution/
  queue/
  workflow/
  scheduler/
  plugin/
  agent/
  mcp/
```

---

# 69. Action Runtime 与 Task Runtime

职责必须明确：

```text
Action Runtime
=
执行一个 Action
```

```text
Task Runtime
=
管理一个业务任务
```

```text
Execution Runtime
=
记录一次实际执行
```

```text
Queue Runtime
=
负责调度工作
```

```text
Workflow Runtime
=
编排多个步骤
```

```text
Scheduler
=
决定什么时候创建 Task
```

---

# 70. 最终架构

```text
                         DevOS
                           │
             ┌─────────────┴─────────────┐
             │                           │
        Platform Core               Extensions
             │                           │
   ┌─────────┼─────────┐          ┌──────┼──────┐
   │         │         │          │      │      │
Resource   Action    Event       SEO   GitHub  Docker
   │         │         │
   └─────────┼─────────┘
             │
        Action Runtime
             │
        ┌────┴────┐
        │         │
      Sync      Async
                  │
                Task
                  │
                 Job
                  │
                Queue
                  │
                Worker
                  │
             Execution
                  │
                Event
```

---

# 71. 黄金规则

DevOS `04` 必须严格遵守以下规则：

### Rule 1

```text
所有异步业务必须通过 Task Runtime
```

### Rule 2

```text
所有实际执行必须产生 Execution
```

### Rule 3

```text
所有 Job 必须经过 Queue Runtime
```

### Rule 4

```text
Worker 不允许直接调用业务 Service
```

### Rule 5

```text
Scheduler 不允许直接执行 Action
```

### Rule 6

```text
Workflow 不允许建立第二套 Action 执行机制
```

### Rule 7

```text
Agent 不允许建立自己的 Task System
```

### Rule 8

```text
MCP 不允许绕过 Action Runtime
```

### Rule 9

```text
Plugin 不允许绕过 Permission / Audit / Execution
```

### Rule 10

```text
Retry / Cancel / Progress / Audit / Observability
必须成为 Runtime 能力，而不是每个业务自己实现
```

---

# 72. Zcode 实现要求

Zcode 下一阶段实现必须至少包含：

```text
packages/task
packages/job
packages/execution
packages/event
packages/queue
packages/worker
packages/scheduler
packages/workflow
```

以及：

```text
apps/api
apps/worker
apps/scheduler
```

---

## 必须实现的 API

```text
POST   /tasks
GET    /tasks
GET    /tasks/:id
POST   /tasks/:id/cancel
POST   /tasks/:id/retry

GET    /executions/:id
GET    /executions/:id/logs

GET    /jobs
GET    /jobs/:id

GET    /schedules
POST   /schedules
PATCH  /schedules/:id
DELETE /schedules/:id

GET    /workflows
POST   /workflows
GET    /workflows/:id
POST   /workflows/:id/run
```

---

# 73. 必须实现的 UI

DevOS Dashboard 至少提供：

```text
Tasks
 ├── All
 ├── Running
 ├── Waiting
 ├── Completed
 ├── Failed
 └── Cancelled

Executions

Jobs

Schedules

Workflows
```

Task Detail：

```text
Overview
Progress
Executions
Logs
Events
Children
Input
Output
Error
```

---

# 74. 最终目标

完成 `04_EVENT_TASK_JOB.md` 后，DevOS 就拥有了一个统一的：

> **Durable Execution Foundation**

从此以后：

```text
SEO
DevOps
Content
CRM
Monitoring
Deployment
Agent
Plugin
MCP
```

都不应该自己重新实现：

```text
Queue
Retry
Scheduler
Worker
Progress
Cancellation
Execution
Task
Workflow
Audit
```

而应该直接使用 DevOS Runtime。

最终形成：

```text
              DevOS Execution Runtime
                       │
       ┌───────────────┼────────────────┐
       │               │                │
     Human           Agent           Scheduler
       │               │                │
       └───────────────┼────────────────┘
                       ▼
                     Task
                       ▼
                      Job
                       ▼
                     Queue
                       ▼
                    Worker
                       ▼
                  Action Runtime
                       ▼
                   Execution
                       ▼
                     Event
                       ▼
              Plugin / Workflow / Agent
```

**这一步完成后，DevOS 才真正从“后台管理系统”开始变成一个可以承载大量应用和 Agent 的通用执行平台。**