Graph Engineering 与动态工作图：AI Agent 如何组织任务依赖

图 1：动态工作图把任务依赖、责任和交付状态放在同一张可读视图中。图中为示例工作图。

Graph Engineering 可以理解为：用图来表达复杂工作中的关系，再让这些关系参与执行，而不只是把节点画在页面上。

在 AI Agent 系统里，图通常要回答工作之间的关系问题：这项工作依赖什么，谁负责，结果交给谁，失败后回到哪里，什么条件满足后才能进入下一阶段。

Nexus 把这类结构称为动态工作图（WorkGraph）。它是一张持久化的责任图，随着计划修订、工作返工、协作接管和交付验收继续演化，同时保留历史。

从产品页面看，动态工作图不是一张需要用户手动拖拽维护的流程图。用户看到的是当前责任和运行事实的只读投影：节点说明交付责任，连线说明依赖，状态说明是否正在执行、等待提交、等待验收或已经被退回；展开执行记录后，才能看到对应的 Agent、Subagent 和工具过程。真正改变责任、提交结果或验收结论的动作，仍然通过会话中的受检查操作完成。

这层区别很重要。画布适合回答“现在发生了什么”，宿主状态适合回答“这次变化是否真的成立”。如果直接让前端点击一个节点就把它改成完成，界面会有进度，系统却没有交付证据。

动态工作图到底记录什么？

一条完整的责任链可以写成：

Goal → Execution → Plan → Work Item → Assignment → Attempt
                                                     ↓
                                  Submission → Review → Acceptance

这些对象不是同义词：

• Execution 是一次受管执行的容器，保存范围、会话和运行历史。
• Plan 是当前责任结构的版本，描述工作项、父子关系和依赖。
• Work Item 是稳定的业务责任，拥有交付物和验收条件。
• Assignment 记录当前由谁负责这项工作。
• Attempt 记录一次真实执行，失败或重新运行时会产生新的 Attempt。
• Submission 是一份可以被检查的交付。
• Review 和 Acceptance 把“交过”与“被接受”分开。

如果只有运行日志，系统知道 Agent 调过什么工具，却不知道哪个结果可以解锁下游。静态 DAG 则只记录先后关系，无法说明中间哪次尝试被退回。

工作图和普通任务列表有什么区别？

待办列表关心有没有勾选；工作图关心一份交付能不能被别人安全依赖。

动态工作图也不同于 Agent Skill。Skill 保存做事的方法，工作图保存这一次任务的责任和证据。两者可以一起使用：Work Item 规定交付范围，Skill 提供实现方法。

“动态”不是每次重新画图

动态工作图的变化有两种：

责任不变，执行重试。 例如中文乱码被退回，但仍然属于“验证中文兼容”这项工作。工作项和依赖不必改变，只需要保留第一次 Attempt，创建新的 Attempt 和 Submission。

责任结构改变，计划换版本。 例如上线前新增独立安全复核，原有结构里没有这个 Work Item。系统应保存新的 Plan revision，旧版本仍然作为历史存在。

把这两种变化混在一起，会产生两个问题：每次失败都重新画图，历史会变得无法比较；或者一直在旧图上追加节点，导致当前责任和旧责任混在一起。

从一句需求到一张可执行的工作图

工作图建模需要判断交付责任，不能把自然语言里的动词逐个变成节点。建模时，需要先找到最终交付，再把交付拆成可以独立负责、独立检查的责任，最后才决定哪些边是硬依赖。

以批量 CSV 导出为例，Nexus 可以按下面的顺序形成一次计划建议：

1. 先找最终交付。 结果要让用户能够在权限、规模、编码和失败反馈都成立的情况下完成一次导出。
2. 再区分责任。 权限边界、服务端接口、客户端交互、兼容性验证和发布准备分别需要不同的交付物。
3. 为每项责任写通过条件。 例如，兼容性工作不能只写“测试 CSV”，还要说明目标软件、中文样例、空数据和中断场景。
4. 只把真正的前置条件画成边。 服务端和客户端可以并行时，不要为了看起来整齐而把它们排成顺序。
5. 把最终验收放在交付之后。 集成验收依赖已接受的前置结果，而不是依赖 Agent 曾经运行过。

这几个步骤的意义，是把“计划看起来合理”变成“下一步可以根据图做判断”。模型可以提出拆分方式，宿主仍然要检查节点归属、依赖方向、版本引用和验收条件，不能把未经检查的文本直接当成工作图事实。

一个更能体现工作图价值的例子：方案评审

CSV 导出适合说明工程交付，但工作图的价值并不只在写代码。比如，一次方案评审需要把两份原始方案整理成对照表，再交给另一位成员独立复核，最后由整理者根据意见修订。

这项工作可以写成三个 Work Item：

“整理 → 复核 → 修订”这条视觉顺序背后，关键依赖是已经保存的对照表和可以核对的复核意见：前者供复核使用，后者供修订使用。整理者说“我已经看过两份材料”，不能解锁复核；复核者说“整体没问题”，也不能代替一份可追踪的复核交付。

如果复核发现某一行的税费口径没有说明，工作图应该保留已经通过的比较项，只把相关责任退回修订。系统不需要重启整张图，也不能把一次局部退回写成“全部完成”。修订后形成新的 Submission，再由复核者检查受影响的内容，原始意见和新旧版本都保留在历史里。

这个例子说明，Graph Engineering 关注的是工作之间的可验证关系。它不要求每一步都由不同 Agent 完成，也不要求所有工作按单线顺序运行；它要求每个下游步骤知道自己在等哪份交付，失败时能沿正确的责任回到上游。

边为什么比节点更重要？

在普通流程图里，箭头经常只是阅读顺序。在动态工作图里，一条边要说明下游究竟在等待什么：是上游开始过，是有结果，还是已经有一份被接受的交付。

如果不把边的语义区分开，系统很容易出现一种假进度：每个节点都有绿色状态，但下游依赖的其实是“已验收交付”，而上游只有“执行成功”。Graph Engineering 的核心是让边携带足以支持执行判断的业务含义，不限定某一种图算法。

一张图里为什么有两层事实？

Nexus 的工作图视图会合并责任图和运行图，但两者不是同一份事实。

前端拿到的是只读投影。它可以让人看见责任和运行的关系，但点击画布不能直接修改依赖、授予权限或重试工作。真正的状态变化要通过宿主检查过的结构化操作写入。

普通的文件读取和搜索成功操作适合留在详情里；失败、返工、重要 Artifact、阻塞和外部动作会提升到主图。这样主图保持可读，细节仍然可追查。

下游等待的是哪一种完成？

假设服务端 Agent 已经退出，并且提交了一份代码。客户端工作能不能继续？答案要看它等待的是什么：

硬依赖等待的是已验收的交付，而不是一句“我做完了”。 这条规则让并行协作有了明确边界：下游不需要猜上游的聊天语气，而是读取对应的 Acceptance。

Graph Engineering 的价值在哪里？

图结构的价值体现在它支持的几类执行判断上，节点数量本身不能说明这些价值。

1. 当前工作是否已经有明确负责人；
2. 这次操作是否属于正确的 Execution、Work Item 和 Attempt；
3. 下游缺的是一份结果，还是一份已经验收的结果；
4. 返工应该沿原责任继续，还是需要新的计划版本；
5. 断连、重启或换 Agent 后，从哪个持久事实恢复；
6. Goal 是否可以根据当前交付进入完成审计。

Nexus 用 Graph Engineering 让图成为执行依据的一部分，图在执行过程中就参与判断，无需等到执行完成后再画。

继续阅读AI Agent 执行循环怎么运行，了解 Plan、Task、Subagent 和宿主如何沿着这张图推进工作。

本文对 Graph Engineering 的使用是 Nexus 的工程语境说明，不把它表述为一个已经统一定义的行业标准。