从 0 构建 AI Workload Platform一为什么做、做什么、与现有产品有什么不同摘要我正在从零开发一个名为AI Workload Platform的新项目。它不是一个只会生成文本的聊天工具也不是把多个智能代理Agent强行并行起来的演示框架而是一个面向 AI 和数据任务的可靠工作流编排与执行平台。它要解决的问题是当一项后台工作由多个步骤组成、会持续较长时间并且执行过程中可能失败时怎样让这些步骤按照依赖关系运行保存清晰的状态在合适的情况下重试、取消或恢复并让人能够知道现在发生了什么。本文先回答产品层面的几个问题为什么要做它、它具体做什么、谁会使用、用户怎样使用以及它和成熟工作流产品是什么关系。本文写作时项目还处于定义和技术学习阶段因此文中提到的部分能力是待验证的设计目标不能当作当时已经实现的功能。目录我要开发什么产品为什么要开发它产品到底做什么用户怎样使用谁会使用哪些场景适合与成熟产品的关系希望验证的差异化方向技术路线和推进顺序当前边界和进度总结一、我要开发什么产品先用一个具体例子说明问题。假设要把一批文档处理成可搜索的数据流程可能是读取文档 - 清洗内容 - 生成向量 - 更新搜索索引这里的“任务”是可以单独执行并记录结果的步骤“工作流”是为了完成一个目标而组织起来的一组任务及其关系“依赖”表示一个任务开始前必须满足的条件。例如生成向量依赖清洗内容成功。如果这些步骤只是临时运行一次几条脚本也许就够了。但当任务数量增加、某一步需要调用模型、过程运行数小时或者中间一步失败后不能从头重跑时脚本本身就不再能清楚回答这些问题哪些任务已经成功哪些任务还没有开始失败是暂时的网络问题还是输入本身有错误这次重试会不会把已经写入的数据重复写一遍控制程序重启之后能不能继续上一次工作用户发出取消请求时正在运行的任务和后续任务应该怎样处理AI Workload Platform 的目标就是把这些问题变成平台负责的明确行为。一句话定义AI Workload Platform 是一个接收多步骤工作流、按依赖调度任务、持久化执行状态并管理失败、资源和执行过程的可靠后台工作平台。这里的“AI Workload”可以包含三类任务调用模型或工具的 Agent 任务、确定性更强的普通程序任务以及把两者组合起来的多步骤流程。项目正在从零开始设计和实现所以本文描述的是产品方向和待验证的工程假设。二、为什么要开发它2.1 多步骤任务很容易超出脚本的舒适范围脚本的优点是启动快、编写简单、适合一次性工作。问题通常出现在它需要长期运行之后日志格式不统一错误处理散落在各个脚本里重试规则靠个人约定状态可能只存在进程内存中。例如第三步生成向量时网络暂时不可用。如果脚本没有记录每一步的状态操作者只能重新运行全部流程。这样不仅浪费已经完成的工作还可能重复更新外部系统。2.2 AI 任务增加了不确定性普通程序通常对同样的输入产生相对确定的结果Agent 可能需要调用模型、搜索服务或其他工具耗时和输出都更难预估。模型服务可能限流工具可能超时输出也可能需要校验。这不意味着所有 AI 任务都必须使用复杂平台。一次性的短调用、失败后可以安全重跑的脚本仍然可以直接运行。平台真正适合的是具有依赖关系、状态要求、资源约束或恢复需求的后台工作。2.3 可靠执行是一组相互关联的能力只增加一个“重试按钮”并不能解决可靠性问题。重试需要知道任务是否真的执行过超时需要考虑远端操作可能已经完成取消需要区分“收到请求”和“执行节点已经停止”恢复需要依赖持久化状态重复执行还需要幂等设计。因此本项目的重点不是再写一个脚本库而是建立一套统一的工作流状态、调度和执行边界。三、产品到底做什么3.1 定义和校验工作流用户可以描述一个由多个步骤组成的目标。平台需要把任务、输入、输出和依赖关系表示成可检查的工作流定义。项目也计划支持使用自然语言生成工作流草稿但草稿不能直接执行。平台需要检查依赖是否形成环、参数是否完整、权限和资源是否满足最后由用户确认后才进入执行阶段。3.2 统一管理不同类型的任务平台不会把“多 Agent”当成默认答案而是根据任务特点选择合适的执行方式普通程序任务例如解析文件、计算校验和或运行数据转换程序单 Agent 任务由一个 Agent 根据目标和上下文选择工具并完成工作多 Agent 任务只有在任务能够独立并行或确实需要不同能力和独立审查时才采用。统一管理的含义不是让三类任务拥有完全相同的实现而是让它们都能被平台描述、调度、记录状态并接受一致的失败处理规则。3.3 管理从提交到结束的生命周期一次执行至少需要经历这些阶段定义 - 校验 - 用户确认 - 调度 - 执行 - 上报结果 - 完成或处理失败在执行过程中平台还需要支持重试、超时、取消和恢复。后续设计会进一步明确每个状态的转换条件例如运行中的任务收到取消请求后可能先进入“取消中”等待执行节点确认停止后才变成“已取消”。3.4 让执行过程可观察、可审计平台需要保存任务状态、输入输出引用、日志、失败原因和关键操作记录。这样用户不仅能看到“失败”还可以知道失败发生在哪一步、已经尝试了几次以及恢复时会从哪里继续。指标、调用链和审计属于已批准的产品方向但具体数据模型和展示方式要在后续模块中通过代码和测试确定。四、用户怎样使用一个理想的使用流程如下用户提交任务目标或者提供一份工作流定义平台生成或读取工作流草稿校验器检查任务依赖、参数、权限和资源需求用户查看并确认执行计划调度器选择已经满足依赖的任务执行节点运行普通程序或 Agent并上报结果和日志控制面保存状态解锁后续任务或根据策略进行重试、暂停和失败处理用户查看进度必要时取消执行或在故障后恢复。这个流程中有一个重要边界自然语言只负责帮助生成草稿不能绕过校验和用户确认直接触发具有副作用的操作。五、谁会使用哪些场景适合5.1 目标用户AI 应用开发者需要把模型调用、工具调用和后处理组织成长期运行的流程数据处理和实验维护者需要重复运行清洗、特征生成、评估和结果整理任务后台任务的工程团队关心失败恢复、资源限制、日志和审计而不想让每个业务脚本单独实现一套。5.2 典型场景文档读取、清洗、向量化和索引更新搜索或推荐数据的定期处理模型评估、批量推理和结果汇总Agent 调用多个工具完成一个需要人工确认的后台流程。5.3 不适合的场景一次性的短脚本、没有依赖关系的简单命令以及失败后人工重新运行成本很低的任务不一定值得引入工作流平台。平台本身也会带来状态存储、调度、监控和运维成本。六、与成熟产品的关系AI Workload Platform 不是凭空替代现有产品。成熟产品已经在各自的场景中解决了大量问题本项目需要先理解它们的边界再验证自己的组合方式。产品类别代表方向擅长解决的问题本项目当前的关注点数据工作流平台Airflow、Prefect定时调度、批处理和数据管道依赖能否同时容纳普通程序、AI 任务和 Agent 任务可靠任务执行平台Temporal长时间运行、状态持久化和故障恢复学习 durable execution持久化执行的设计思想并控制早期复杂度容器化工作流Argo Workflows、Kubernetes Jobs在容器和集群中运行批量任务后续验证资源隔离和多节点执行不在早期重复实现 KubernetesAgent 工作流框架LangGraph 等表达带状态的 Agent 节点和工具调用研究如何把 Agent 纳入通用任务生命周期和可靠性边界这些产品的具体能力会随版本和部署方式变化表格只用于说明产品定位不是完整功能清单。本项目目前没有证据证明自己在性能、稳定性或功能覆盖上领先任何成熟产品。更准确的说法是它希望在 AI 任务、普通程序任务和可靠后台执行之间找到适合本项目的组合并通过后续实现和实验验证这个方向是否成立。七、希望验证的差异化方向下面是项目假设不是已经证明的优势。假设一不同类型的工作负载可以使用统一生命周期如果普通程序、单 Agent 和多 Agent 任务都遵循统一的提交、状态、日志、重试和取消接口用户可能不需要为每一类任务维护完全不同的后台系统。验证方式先用 Mock Executor模拟执行器和普通本地进程实现最小任务接口测试不同执行对象是否能被同一个调度器管理。这里的 Mock Executor 只模拟成功、失败、超时和取消不代表真实 Agent。失败条件不同任务的结果语义、权限边界或取消方式差异太大统一接口反而隐藏了重要风险。假设二自然语言草稿加校验和确认能降低工作流编写门槛自然语言适合表达目标但不适合直接承担依赖、权限和资源约束。项目希望让模型生成草稿再由规则校验器和用户确认把它变成可执行定义。验证方式构造包含依赖环、缺少参数和资源冲突的输入观察系统能否拒绝不完整草稿并给出可理解的原因。失败条件草稿格式不稳定或者校验器无法发现关键风险导致用户对自动生成结果产生错误信任。假设三Agent 任务可以纳入可靠执行边界Agent 的输出不确定但任务的外部边界仍然可以受到超时、权限、资源和审计规则约束。验证方式使用 Mock Executor 模拟成功、失败、超时、取消和重复上报逐项检查状态机和结果处理行为。失败条件工具副作用无法幂等、无法确认远端执行结果或者权限隔离不足。八、技术路线和推进顺序项目采用逐步增加复杂度的路线。结合后续的范围调整当前确认的先后关系是产品定义与术语 - 单机可靠工作流内核 - 控制面、事务持久化和故障恢复 - Agent Runtime 与自然语言工作流草稿 - 多 Worker、租约与心跳 - 可观测性、故障注入与性能验证 - 受限执行环境与 Kubernetes - 真实场景、最小控制台与开源发布这条路线不是把八组技术并排放在一起而是让下一阶段解决上一阶段已经暴露的问题。本文保留模块 0 当时的假设后来模块 1 至模块 5 已经形成代码、测试和实验模块 6、模块 7 仍属于后续计划。后续证据不会倒写成模块 0 当时已经掌握的事实但可以通过第九节的证据入口继续追踪。递进上一阶段还缺什么下一阶段怎样解决新增代价或仍然保留的边界模块 0 - 模块 1产品范围和概念只有文档没有可运行证据用 Go、模拟执行器和本地 JSON 快照实现单机内核验证状态、依赖、重试、取消和恢复只能证明单进程语义不能被多个客户端稳定调用模块 1 - 模块 2本地命令和 JSON 快照不适合多客户端访问、事务写入和条件查询用网络 API 建立调用契约用关系数据库保存运行事实用容器配置固定本地数据库环境增加网络、数据库迁移、认证和服务恢复问题仍然只有一个执行进程模块 2 - 模块 3用户仍要手写结构化定义模型和工具也没有受控边界增加 Agent 运行时、模型适配器、工具注册表、草稿校验、内容变更检查和人工确认模型仍有不确定性第一版也不能直接执行真实业务模块 3 - 模块 4任务仍在控制面进程内执行不能独立扩展执行能力或处理执行节点失联用数据库持久化分发、执行节点主动领取、限时执行权、存活报告和旧结果拒绝标识管理多个节点增加轮询、临时所有权和重复执行边界不能保证任务只执行一次模块 4 - 模块 5系统可以多进程运行但故障原因和容量边界仍难系统判断增加日志、指标、调用链、告警和可重复故障实验可观测数据会增加采集、存储和维护成本模块 5 - 模块 6能发现故障但任务还没有真实资源和权限隔离也未验证编排环境故障引入受限执行环境、Docker 和 Kubernetes验证资源限制与节点恢复部署层级和故障来源明显增加容器也不是绝对安全边界模块 6 - 模块 7技术能力尚未形成新用户可独立安装、演示和维护的产品用真实场景、最小控制台、自动验证与发布流程、开源文档完成交付增加用户界面、发布兼容和开源维护成本后一个模块不会替代前一个模块。例如关系数据库不会让本地文件存储的单机测试失去价值多执行节点也不能重新定义已经验证的任务状态机。每一步都应继承已有契约只为解决当前已经出现的问题而增加复杂度。第一阶段选择 Go。Go 是一种静态类型、编译型语言许多接口类型错误可以在编译阶段暴露标准库也适合并发任务、网络服务和测试。当前选择它还因为开发环境已具备 Go 基础和工具链。第一阶段选择本地进程和 Mock Executor。本地进程启动快、调试路径短适合先验证依赖、状态和恢复逻辑Mock Executor 能稳定模拟成功、失败和超时不需要网络、模型文件或 API 费用。真实 Agent Runtime 会在后续模块中通过独立接口接入。这意味着第一阶段不会急于引入数据库、消息队列、容器编排或真实模型。Docker 和 Kubernetes 适合后续验证隔离、多节点和资源调度但会增加部署和排查层级真实模型适合少量接入测试不适合作为核心单元测试的唯一依赖。九、当前边界和进度本文写作时项目处于模块 0项目定义、架构基线和学习资料正在完善尚无业务代码。后续实现已经改变了项目状态但本文仍保留当时的产品思考和验证假设因此下面这些内容在本文写作时只能作为目标或验证计划状态转换是否覆盖所有取消、超时和恢复边界重试是否能正确区分暂时性错误和不可重试错误重启后是否能避免无条件重复执行多节点执行、资源控制和故障转移是否可行性能、成本和生产可用性是否达到实际需求。文档和概念说明可以帮助建立共同语言但不能替代业务测试。真正的结论要等后续模块用代码、自动化测试和可复现实验逐条验证。为了保留“先提出假设再产生证据”的工程过程本文不把后续结果倒写成模块 0 当时已知的结论。继续阅读本系列时可以按下列关系追踪每类问题后来如何验证本文提出的问题后续证据入口尚未证明的边界状态、依赖、重试、取消和恢复能否形成一致语义系列第三篇的单机内核实现、自动化测试和性能基线生产环境的长时间稳定性控制面能否在提交后崩溃和数据库中断时恢复系列第四篇的 PostgreSQL 事务、启动恢复和真实停库实验多 Worker 和高可用自然语言草稿能否受到校验、权限和确认边界约束系列第五篇的 Agent Runtime、只读工具、内容哈希和确认流程真实模型质量和生产 Agent 任务执行多 Worker 的所有权与故障接管是否成立系列第六篇的租约、心跳、强杀 Worker 和迟到结果实验真实执行副作用、跨机器容量和控制面高可用可观测性是否能解释故障与性能系列第七篇的日志、指标、Trace、告警、故障注入和五轮对照尚无生产观测后台和跨异步阶段完整 Trace资源隔离和 Kubernetes 恢复是否成立后续模块的受限执行、容器和 Kubernetes 实验当前仍未实现和验证十、总结我正在开发的不是一个泛泛的 AI 概念展示而是一个从零开始构建的可靠工作流平台它接收由多个步骤组成的 AI 或数据任务按依赖调度保存执行状态并处理失败、重试、取消、恢复和审计。它会借鉴数据工作流、可靠任务执行、容器编排和 Agent 工作流产品的成熟经验但不预先宣称替代它们。本文写作时最重要的事情是先验证统一任务生命周期和可靠执行边界是否能够在简单、可测试的单机内核中成立。下一篇文章将从工作流、DAG、状态机和可靠执行基础讲起解释这些术语分别是什么以及它们为什么是这个项目的技术基础。参考资料Apache Airflow 官方文档What is Airflow?Prefect 官方文档IntroductionTemporal 官方文档Argo Workflows 官方文档Kubernetes 官方文档JobsLangGraph 官方文档Overview项目源码本文对应模块 0。完整源码、验证报告和后续模块见 AI Workload Platform GitHub 仓库。