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 之上建立统一的：

Event
Task
Job
Execution
Queue
Scheduler
Workflow
Worker

体系。

核心目标：

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

---

2. 核心模型

DevOS 不应该把：

Task
Job
Workflow
Queue
Cron
Agent Task

设计成互相独立的系统。

统一模型：

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

其中：

Task

是业务任务。

Execution

是一次具体执行实例。

Job

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

---

3. Event

Event 表示：

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

例如：

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

Event 不负责执行。

Event 只描述：

发生了什么

---

3.1 Event 结构

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
}

例如：

{
  "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。

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

Event Bus 必须支持：

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

---

4.1 Event Handler

插件可以订阅事件：

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

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

推荐：

Event Handler
     ↓
Create Task
     ↓
Queue
     ↓
Worker
     ↓
Action

而不是：

Event Handler
     ↓
直接执行 30 秒任务

---

5. Task

Task 表示：

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

例如：

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

Task 是业务层概念。

---

5.1 Task 状态

draft
queued
running
waiting
paused
completed
failed
cancelled

推荐状态机：

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

running
 ├── failed
 └── cancelled

---

6. Task 数据模型

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。

例如：

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

插件：

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

---

8. Job

Job 是：

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

一个 Task 可以包含多个 Job。

例如：

Task:
SEO 网站优化

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

因此：

Task ≠ Job

---

9. Job 生命周期

pending
  ↓
queued
  ↓
running
  ↓
completed

异常：

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

---

10. Execution

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

定义：

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

例如：

Action:
seo.website.scan

Execution:
exec_123

同一个 Action 可以执行：

exec_001
exec_002
exec_003

---

10.1 Execution 数据

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 的关系

必须严格区分：

Task
  │
  ├── Job
  │     └── Execution
  │
  ├── Job
  │     └── Execution
  │
  └── Job
        └── Execution

例如：

Task: 部署网站

Job 1: Build
Execution 1

Job 2: Upload
Execution 1

Job 3: Restart Container
Execution 1

如果 Job 重试：

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

因此：

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

---

12. Queue

Queue 负责：

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

架构：

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

---

13. Queue 类型

DevOS 初期至少支持：

default
high
low
scheduled
agent
workflow

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

应该统一 Queue Runtime：

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

---

14. Worker

Worker 是真正执行 Job 的进程。

┌─────────────────────┐
│      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 的核心规则。

错误：

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

正确：

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

也就是说：

Worker
  ↓
Action Runtime
  ↓
Action

而不是：

Worker
  ↓
Database

---

16. Retry

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

interface RetryPolicy {
  maxAttempts: number

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

  delayMs: number

  maxDelayMs?: number

  retryOn?: string[]
}

例如：

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

执行：

1s
2s
4s
8s
16s

---

17. 什么错误可以 Retry

应该区分：

Retryable

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

Non-Retryable

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

Action 可以定义：

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

---

18. Dead Letter Queue

超过最大 Retry：

Job
 ↓
retry
 ↓
retry
 ↓
retry
 ↓
failed
 ↓
DLQ

Dead Letter Queue 用于：

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

UI 应提供：

Failed Jobs

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

---

19. Progress

长任务必须支持 Progress。

interface ExecutionProgress {
  current: number

  total?: number

  percentage?: number

  message?: string

  phase?: string
}

例如：

SEO Scan

Phase: Crawl

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

723 / 1000 pages

Worker：

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

---

20. Cancellation

Task 必须支持取消。

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

Action Context：

interface ActionContext {
  signal: AbortSignal
}

Action：

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

---

21. Pause / Resume

不是所有任务都可以 Pause。

Action 可以声明：

supportsPause: true

如果支持：

running
   ↓
paused
   ↓
running

如果不支持：

Cancel
+
Create new execution

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

---

22. Scheduler

Scheduler 负责：

在指定时间触发 Task。

支持：

once
interval
cron
event-driven

例如：

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

---

23. Schedule

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

例如：

0 2 * * *

表示：

每天凌晨 2 点

但是：

Scheduler 不应该直接执行 Action。

必须：

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

---

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

错误：

Cron
 ↓
Action

正确：

Cron
 ↓
Task
 ↓
Job
 ↓
Queue
 ↓
Execution

这样才能获得：

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

---

26. Workflow

Workflow 是：

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

例如：

Website Scan
      ↓
Analyze
      ↓
Generate Report
      ↓
Notify User

---

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

这是非常重要的一点。

不要实现：

Action Runtime
Workflow Runtime
Agent Runtime
Plugin Runtime

四套执行逻辑。

正确：

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

Workflow 只是编排层。

---

28. Workflow Node

interface WorkflowNode {
  id: string

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

  config: unknown
}

例如：

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

---

29. Workflow Edge

interface WorkflowEdge {
  from: string

  to: string

  condition?: string
}

形成：

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

---

30. Parallel

Workflow 必须支持并行。

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

---

31. Foreach

例如：

100 Websites

执行：

foreach website:
    website.scan

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

---

32. Approval

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

例如：

Agent
 ↓
Generate deployment plan
 ↓
Approval
 ↓
Deploy

或者：

Agent
 ↓
Build 200 backlinks
 ↓
Approval
 ↓
Execute

Workflow Node：

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

---

33. Wait

Workflow 需要支持等待。

例如：

Deploy
 ↓
Wait 10 minutes
 ↓
Health Check

不要让 Worker：

await sleep(10 * 60 * 1000)

这会浪费 Worker。

应该：

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

---

34. Event-driven Workflow

Workflow 可以等待 Event。

例如：

Create Deployment
 ↓
WAIT deployment.completed
 ↓
Run Health Check

这比轮询更加高效。

---

35. Task 与 Agent

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

正确：

Agent
 ↓
Goal
 ↓
Plan
 ↓
Task
 ↓
Action
 ↓
Execution

例如用户：

让 example.com 在 10 天内提升 SEO

Agent：

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

这些全部转换为：

Task

然后使用统一 Task Runtime。

---

36. Agent 与 Workflow

Agent 可以动态生成 Workflow。

例如：

Goal
 ↓
Agent Planning
 ↓
Workflow
 ↓
Task
 ↓
Action

但 Agent 也可以直接创建 Task：

Agent
 ↓
Task
 ↓
Action

因此：

Workflow = 固定/半固定流程

Agent = 动态决策

两者不是竞争关系。

---

37. Plugin 与 Task

Plugin 可以注册：

Action
Resource
Event
Task Type
Workflow Node
Scheduler
UI

例如 GitHub Plugin：

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

所有执行仍然经过：

Action Runtime

---

38. MCP 与 Task

MCP 是能力访问层。

例如 MCP Tool：

seo_scan_website

不要直接执行：

MCP
 ↓
HTTP
 ↓
业务代码

应该：

MCP Tool
 ↓
Action
 ↓
Action Runtime
 ↓
Task / Execution

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

---

39. CLI

CLI 同样如此：

devos action seo.website.scan

内部：

CLI
 ↓
Action Runtime
 ↓
Execution

---

40. API

HTTP：

POST /api/actions/seo.website.scan

内部：

HTTP Controller
 ↓
Action Runtime
 ↓
Execution

---

41. UI

按钮：

[Scan Website]

内部：

UI
 ↓
API
 ↓
Action Runtime
 ↓
Task
 ↓
Job

---

42. 所有入口统一

最终 DevOS 必须形成：

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

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

---

43. 数据库设计

建议 PostgreSQL。

核心表：

events
tasks
jobs
executions
schedules
workflows
workflow_nodes
workflow_edges
task_logs
execution_logs
dead_letter_jobs

---

44. Event 表

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

---

45. Task 表

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 表

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

---

47. Execution 表

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

---

48. Schedule 表

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

---

49. Log

日志不要全部塞到 Task 表。

单独：

execution_logs

例如：

interface ExecutionLog {
  executionId: string

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

  message: string

  metadata?: Record<string, unknown>

  timestamp: Date
}

---

50. Correlation ID

所有任务链必须支持：

correlationId
causationId
requestId
executionId
taskId
jobId

例如：

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 至少应该能够看到：

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

UI：

Task Detail
────────────────────────────

Status: Running

Progress: 72%

Execution
  exec_123

Attempt: 2 / 5

Worker:
  worker-03

Duration:
  01:23

Logs:
  ...

---

52. Concurrency

Task / Action 可以定义：

concurrency: {
  max: 5
}

例如：

SEO Crawl
max concurrency = 5

避免：

1000 websites
 ↓
1000 simultaneous requests
 ↓
system collapse

---

53. Resource Lock

某些 Action 需要锁。

例如：

deploy project A

同一个 Project 不允许同时：

deploy A
deploy A

可以：

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

系统：

Job A → lock acquired
Job B → waiting

---

54. Idempotency

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

例如：

publish article

如果 Worker：

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

可能导致重复发布。

因此 Action 应支持：

idempotencyKey

例如：

publish:{articleId}:{version}

---

55. Transaction Boundary

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

错误：

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

正确：

DB transaction
 ↓
Create Task
 ↓
COMMIT

Worker
 ↓
Action
 ↓
external system
 ↓
Save result

外部系统必须通过：

idempotency
retry
compensation

处理一致性。

---

56. Task Result

Task 最终应该有统一结果：

interface TaskResult<T = unknown> {
  success: boolean

  output?: T

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

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

---

57. Event → Task

系统可以配置：

Event
 ↓
Trigger Rule
 ↓
Task

例如：

deployment.failed
        ↓
create:
monitor.health_check

或者：

server.created
        ↓
install:
server.monitor

---

58. Trigger

Trigger 可以有三种：

Event Trigger
Schedule Trigger
Manual Trigger

未来可以增加：

Webhook Trigger
Condition Trigger
Agent Trigger

统一模型：

interface Trigger {
  id: string

  type: string

  config: unknown

  enabled: boolean

  target: {
    taskType: string
  }
}

---

59. Task Template

重复任务应该支持 Template。

例如：

Website Daily SEO Check

模板：

{
  type: "seo.website.daily_check",

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

Scheduler 使用 Template 创建 Task。

---

60. Task Tree

Task 支持父子关系。

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：

Project
  │
  ├── Task
  ├── Task
  └── Task

因此可以获得：

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

---

62. Cost Tracking

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

interface ExecutionCost {
  provider?: string

  model?: string

  inputTokens?: number

  outputTokens?: number

  credits?: number

  money?: number

  currency?: string
}

这样：

Project
 ↓
AI Cost
 ↓
$23.51

可以统一统计。

---

63. Resource Event

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

例如：

Resource:
seo.website

Action:
update

Result:
updated

Event:
seo.website.updated

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

---

64. Event Sourcing

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

使用：

State in PostgreSQL
+
Event Log

即可。

也就是说：

Database = current state

Event = historical fact

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

---

65. 推荐基础设施

第一阶段：

PostgreSQL
Redis
Queue
Worker
Scheduler

如果使用 TypeScript：

NestJS
+
BullMQ
+
Redis
+
PostgreSQL

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

---

66. BullMQ 的定位

如果采用 BullMQ：

DevOS Queue Runtime
        │
        ▼
      BullMQ
        │
        ▼
      Redis

但：

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

应该封装：

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

  cancel(jobId: string): Promise<void>

  retry(jobId: string): Promise<void>

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

未来可以替换：

BullMQ
Temporal
RabbitMQ
SQS
NATS

而不用修改业务代码。

---

67. 第一版不要引入 Temporal

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

建议：

V1:
BullMQ + Redis

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

尤其是：

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

真正出现需求后再升级。

---

68. Runtime 分层

最终后端结构建议：

apps/
  api/
  worker/
  scheduler/

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

---

69. Action Runtime 与 Task Runtime

职责必须明确：

Action Runtime
=
执行一个 Action

Task Runtime
=
管理一个业务任务

Execution Runtime
=
记录一次实际执行

Queue Runtime
=
负责调度工作

Workflow Runtime
=
编排多个步骤

Scheduler
=
决定什么时候创建 Task

---

70. 最终架构

                         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

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

Rule 2

所有实际执行必须产生 Execution

Rule 3

所有 Job 必须经过 Queue Runtime

Rule 4

Worker 不允许直接调用业务 Service

Rule 5

Scheduler 不允许直接执行 Action

Rule 6

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

Rule 7

Agent 不允许建立自己的 Task System

Rule 8

MCP 不允许绕过 Action Runtime

Rule 9

Plugin 不允许绕过 Permission / Audit / Execution

Rule 10

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

---

72. Zcode 实现要求

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

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

以及：

apps/api
apps/worker
apps/scheduler

---

必须实现的 API

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 至少提供：

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

Executions

Jobs

Schedules

Workflows

Task Detail：

Overview
Progress
Executions
Logs
Events
Children
Input
Output
Error

---

74. 最终目标

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

Durable Execution Foundation

从此以后：

SEO
DevOps
Content
CRM
Monitoring
Deployment
Agent
Plugin
MCP

都不应该自己重新实现：

Queue
Retry
Scheduler
Worker
Progress
Cancellation
Execution
Task
Workflow
Audit

而应该直接使用 DevOS Runtime。

最终形成：

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

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