跳到主要内容

架构

1. 产品思路​

A2E 当前阶段的产品目标，是把“AI 对话式请求”转换为“可治理的工作流执行过程”，并在执行过程中保留足够的工程控制能力，而不是仅返回一次性结果。

围绕这个目标，当前实现采用了一个最小闭环：

  • 定义：以 workflow 作为执行蓝图，描述节点、连线和输入输出约束。
  • 执行：以 run 作为一次执行实例，支持创建、取消、恢复等生命周期操作。
  • 观测：以 event 作为执行事实记录，支持增量查询与状态追踪。
  • 人工介入：以 review 作为审核机制，在关键节点暂停并等待决策，再继续执行。

在交互入口上，A2E 提供两条并行路径：

  • Web 入口：面向可视化编辑、运行监控和审核处理。
  • MCP 入口：面向 Codex/CLI 等 AI 客户端，以工具调用方式访问同一套引擎能力。

这意味着 A2E 不是“仅 UI 的流程工具”或“仅 CLI 的自动脚本集合”，而是一个以统一语义（workflow / run / review / event）连接 Web 与 AI 协作端的执行内核。当前版本标记为 Experimental，重点验证架构可行性与工程闭环。

2. 技术架构总览​

当前实现可从“组件关系”和“运行时执行流”两个视角理解。

2.1 组件关系​

结合当前实现，主要组件职责如下：

  • Web
    • 提供工作流编辑、运行监控、审核处理、设置与 Codex 交互界面。
    • 通过 HTTP 与 WebSocket 访问 Server 暴露的统一服务能力。
  • MCP Server
    • 以 STDIO 方式向 Codex/CLI 等 MCP Client 暴露工具接口。
    • 内部不直接处理工作流状态，而是通过 loopback HTTP 调用 A2E Server。
  • A2E Server
    • 负责工作流、节点、运行、审核、事件与 AI 节点相关服务。
    • 同时承担 Codex 登录、模型查询、PTY 会话与运行目录管理能力。
  • Codex CLI
    • 作为 AI 节点的实际执行运行时，由 Server 在受控目录中启动。
    • 执行结果以结构化输出、日志和产物文件形式回写到运行目录。
  • SQLite + 文件系统
    • SQLite 保存 workflow / run / node_run / review / event 等结构化状态。
    • 文件系统保存 AI 节点定义、运行输入输出、日志、产物与异常线索。

当前版本未引入独立队列或 Worker。工作流调度、状态推进、审核协同与 AI 节点控制均由 Server 进程直接承担。

2.2 运行时执行流​

该执行流体现了当前版本的最小闭环：以 agent.codex 负责自动执行，以 human.review 负责人工把关，并通过统一的 run / review / event 语义把 Web 与 MCP 两类入口收敛到同一套执行内核。

3. Workflow​

3.1 生命周期​

工作流执行的生命周期可以用五步理解：

  1. 创建：收到执行请求后创建一次独立运行。
  2. 启动：引擎接管任务并按节点依赖顺序推进。
  3. 执行：逐个节点处理，必要时生成中间产物和事件记录。
  4. 暂停：遇到需要人工判断的场景，流程会暂停等待决策。
  5. 结束：根据执行结果进入完成、失败或取消，并产出总结信息。

该生命周期的核心价值是把“AI 自动执行”变成“可控、可解释、可回放”的工程过程。

3.2 状态机​

状态机采用统一语义，主要状态包括：

  • 排队中
  • 执行中
  • 暂停中
  • 已完成
  • 已失败
  • 已取消

典型流转逻辑：

  • 排队中 -> 执行中：引擎开始处理。
  • 执行中 -> 暂停中：触发审核或人工接管。
  • 暂停中 -> 执行中：审核通过并继续执行。
  • 执行中 -> 已完成：流程按预期结束。
  • 执行中 -> 已失败：关键节点失败且未被接管恢复。
  • 任意活跃状态 -> 已取消：用户或系统主动终止。

状态变化会被记录成事件，用于观察、审计和故障排查。

3.3 输入输出契约​

输入输出契约用于保证“流程可连通、结果可复用”，分为两层：

  • 运行前校验：检查流程输入、节点输出声明是否完整，提前拦截明显错误。
  • 运行时校验：节点执行后检查输出结构是否符合约定，避免坏数据继续向下游传播。

每个节点的输入都来自两部分：

  • 流程入口输入
  • 上游节点产出

结果会同时以结构化数据和文件产物落盘，保证后续可查看、可复盘、可追责。

4. AI节点​

4.1 执行模型​

AI 节点负责完成自动化内容生成与执行决策，是流程中的主要“生产节点”。

当前执行模型的特点：

  • 异步执行：节点由后台任务驱动，避免阻塞整条流程。
  • 配置驱动：执行策略由节点模板统一管理，例如模型、超时和权限范围。
  • 结果回收：执行结束后，系统会回收状态、输出和产物并写入统一记录。

4.2 输入输出与产物​

AI 节点的数据表现分为三类：

  • 输入：来自流程上下文与上游节点结果。
  • 输出：结构化结果与可消费内容（供后续节点继续使用）。
  • 产物：执行日志、生成文件、异常线索等运行证据。

当主输出不可用时，系统具备兼容回退机制，尽量保证流程可继续观测与处理。 这些信息会统一沉淀，供 Web 页面和 MCP 工具共同使用。

4.3 失败与恢复​

AI 节点失败后的处理思路是“先收口、再恢复”：

  • 收口：记录失败原因与上下文证据，防止问题被静默吞掉。
  • 接管：在高不确定场景自动转入审核，避免错误继续扩散。
  • 恢复：审核通过后可继续流程，不必整条流程从头重跑。

同时保留调试能力，便于在不破坏主流程的前提下复现问题并验证修复。

5. 审核节点​

5.1 主动审核​

主动审核是设计时就明确配置的“人工把关点”。

在流程运行到该节点时，系统会自动暂停并生成审核任务，等待审核人基于上下文做决策，再决定是否继续执行。

5.2 被动审核​

被动审核是在运行中动态触发的“兜底机制”。

当系统发现异常结果、风险信号或执行不确定性时，会自动把流程切换到人工判定模式，优先保证安全与可控。

5.3 中断与恢复​

审核节点支持“中断-决策-恢复”的闭环：

  • 审核通过：流程恢复并继续向下执行。
  • 审核拒绝：流程进入失败收口。
  • 审核取消：流程终止并关闭未完成审核，避免悬挂状态。

这种机制让自动化执行与人工判断可以平滑切换，而不是互相割裂。

6. 模块关系与数据流​

模块关系可以简化为两条入口、一个内核：

  1. Web 入口
    • 面向人类用户，用于配置流程、观察执行、处理审核。
  2. MCP 入口
    • 面向 AI 客户端，用于以工具方式调用同一套能力。
  3. 统一内核
    • 两个入口最终都进入同一执行内核，由它负责状态推进、事件记录、审核协同和结果沉淀。
    • 当前内核能力主要包括工作流管理、运行调度、审核协同与 AI 节点执行。

最终形成统一的数据语义：流程定义、执行实例、节点状态、审核记录和事件轨迹。
这也是 A2E 能同时支持“人机协作”和“多入口一致性”的关键。