# `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 { id: string type: string version: number timestamp: string actor?: Actor organizationId?: string resource?: { type: string id: string } data: T metadata?: Record 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 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 { 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 cancel(jobId: string): Promise retry(jobId: string): Promise get(jobId: string): Promise } ``` 未来可以替换： ```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 的通用执行平台。**