AI Agent 如何执行长任务：Nexus 的 Goal 与动态工作图设计

图 1：Nexus 的 Goal 与工作图组件演示。使用示例数据，按阅读尺寸重新布局；图中是任务结构，尚未执行。

让 AI Agent 做一个导出功能，写完代码之后，还剩下多少工作？

按钮能下载文件，字段未必正确。文件能打开，中文未必正常。正常路径通过了，空数据和失败提示也可能没有检查。

这些问题往往出现在第一轮实现之后。Agent 需要记住原始要求，接住验证反馈，继续修改，并判断什么时候可以交付。

Nexus 把这件事分成三个部分：Goal 保存目标，动态工作图组织工作，执行循环衔接行动与反馈。

我们的技术路线，是把目标、工作责任和执行结果保存下来，再让每一轮 Agent 围绕这些状态继续做事。模型负责理解问题、选择行动；Nexus 负责把多轮执行接起来，让分工、反馈和完成判断都有记录可查。

在 Nexus 里，用户实际会看到什么？

这套机制体现在用户的操作中。用户从会话输入区开始工作，后面的状态分别在 Goal 状态栏、工作图面板和执行记录中呈现。

这几个入口的职责不同。Goal 状态栏告诉用户“最终要完成什么、现在为什么继续或停下”；工作图面板告诉用户“谁负责什么、哪些前置交付还没有验收”；执行记录告诉用户“实际发生了哪些工具调用、子智能体和失败”。它们共同描述一次长任务，但不能互相代替。

例如，点击工作图中的一个节点，页面可以展示它当前的负责人和提交记录，但用户不能只靠拖动节点把验收状态改成通过。退回修改应当在会话中说明原因，由 Agent 产生新的 Attempt 和 Submission，再由相应的复核流程写入结论。画布负责让状态容易看懂，状态变化仍然来自受检查的执行记录。

Goal 也不会自动把一次需求拆成多人协作。只有当任务确实需要负责人、前置关系和交付验收时，才建立工作图；每天固定时间运行的事情使用定时任务；固定的做事方法和脚本则整理为 Agent Skill。这个分工能避免把一次简单修改包装成一套过重的流程。

下面用同一个任务，看看它们怎样配合。文中的任务与反馈均为讲解示例。

可以先记住这条主链：

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

它描述了一条可以保存、检查和恢复的责任链，模型回复本身无法替代这些记录：Goal 说明最终要交付什么，Execution 表示一次受管的执行，Plan 组织工作结构，Work Item 承接具体责任，Assignment 和 Attempt 记录谁在什么范围内执行，Submission、Review 和 Acceptance 负责证明交付是否成立。

为什么长任务需要一个 Goal？

为了先看懂最小结构，先给 Agent 一段具体要求：

为记录列表增加批量 CSV 导出。选中记录后可以下载文件，字段顺序正确，中文能正常打开，空数据和导出失败都有明确反馈。

这段输入包含三组可以检查的条件：

1. 内容正确：选中记录、字段和顺序都符合要求。
2. 文件可用：中文内容能在目标表格软件中正常打开。
3. 边界完整：空数据和失败路径有明确反馈。

在 Nexus 中，可以把这段要求设为 Goal。目标及其版本会独立保存。一轮实现结束后，下一轮仍然围绕这件事推进。

如果用户中途补充要求，Goal 的目标版本随之更新。旧轮次不能按原来的要求，替新的目标宣布完成。

Goal 还保存续跑状态。 目标仍可推进时，宿主可以安排后续执行；需要用户输入、达到限额或连续没有进展时，自动续跑会停下来。用户也可以暂停、恢复或调整目标。

长任务由此有了两个持续有效的参照：要交付什么，以及现在是否还能继续。

工作图怎样组织 Plan、Task 和 Subagent？

接下来，把目标拆成工作。

页首的工作图有四个工作项：实现导出 → 分别验证功能与中文兼容 → 整合交付。 两条验证路径可以分别组织；它们都要交出合格结果，整合工作才具备相应的前提。

这里的“动态”有一个具体含义：反馈没有改变责任结构时，原工作项可以产生新的执行尝试；反馈改变了工作结构时，系统保存新的计划版本。它不是每轮重新画一张图，也不是让模型随意改动依赖。

这里几个常见概念，各自承担不同的职责：

• Plan（计划）：保存当前的工作结构，描述有哪些工作、怎样依赖。
• Work Item（工作项）：承接一份具体责任，记录工作要求、依赖与交付。
• Task（局部任务）：Agent 或 Subagent 在本轮执行中安排的步骤，例如查看数据结构、修改导出函数、运行一组测试。它说明“这次准备做什么”，本身不是一份持久化的业务责任。
• Subagent（子智能体）：承担需要委派的调查或处理任务，结果交回负责人判断和采用。

把局部 Task 勾选完成，说明 Agent 推进了自己的步骤。工作项还要拿出对应的结果，经过提交与验收，才能满足下游依赖。

一个 Agent 可以承担多个工作项。需要独立调查或并行处理时，再使用 Subagent。子任务返回结果，不会自动替父任务完成验收。

把“做个导出”变成真正的交付任务

前面的 CSV 例子只展示了一个切面。真实产品需求往往还包括权限、性能、兼容性、文档和发布。比如，把批量导出做成可以交给客户使用的能力，至少要回答这些问题：谁可以导出？导出的字段和审计记录是什么？十万条数据会不会卡住界面？不同表格软件打开是否一致？失败后用户能不能知道发生了什么？文档和版本说明是否已经跟上？

这时，任务可以展开成一条更接近真实交付的工作图：

这些工作不是简单地排成六步。需求与权限边界先解锁服务端和客户端；两边的交付又共同解锁兼容性验证；文档、验证记录和实现结果最后汇入集成验收。某个 Agent 说“代码写完了”，只能结束自己的 Attempt，不能直接解锁整条链。

这也是工作图和 Agent Skill 的分界。

如果只是“读取一个 CSV 并转换格式”，一个 Skill 加一次模型运行可能已经足够。只有当任务出现并行分工、硬依赖、独立复核、跨会话续跑或需要对外发布时，工作图才开始承担不可替代的作用。Skill 让 Agent 知道怎么做，WorkGraph 让整个交付过程知道谁在做、做到哪一步、哪份结果可以被别人依赖。

下游到底在等什么？

假设实现 Agent 已经退出，代码也已经提交。兼容性验证能否认为前面的工作完成了？

需要区分三种事实：

工作图中的硬依赖，等待的是已验收的交付。 上游的一句“完成”，不能代替这条记录。

这也让等待变得具体：下游可以确认自己缺少哪份交付，负责人可以确认哪项工作还在验收中。

Nexus 的执行器具体做了什么？

前面描述的是工作怎样组织。实现时，我们还要解决一个问题：上一轮结束以后，下一轮怎样知道自己该从哪里接手？

为此，Nexus 在模型运行之外增加了一层程序，负责保存状态、检查变更和安排续跑。文中说的“宿主”，指的就是这一层。

从一句需求到一条可执行的责任链

一张工作图不是模型输出的一段 JSON，也不是前端先画出几个节点。Nexus 会先把用户的自然语言要求整理成计划建议，再由宿主检查并写入真正受管的执行记录。

1. Goal 保存目标、完成条件和目标版本。用户后来补充要求时，系统知道哪些旧判断已经不能继续沿用。
2. Execution 把一次围绕这个目标展开的执行装起来。它关联当前会话、责任范围和执行状态，方便后续轮次从同一份事实继续。
3. Plan 描述工作项、依赖和交付关系。模型可以提出计划，但计划建议只有经过检查并写入版本后，才会成为执行依据。
4. Work Item 把计划变成一份清楚的业务责任，例如“实现导出”或“验证中文兼容”。负责人接手后，宿主会为这份责任建立精确的 Assignment 和 Attempt。
5. Submission、Review 和 Acceptance 把“做过一次”与“交付成立”分开。只有对应提交通过验收，依赖它的下游工作才可以解锁。

有了这条链，下一轮可以读取当前目标与计划版本，核对责任、尝试、提交和验收结果，再决定下一步，不必从聊天记录里猜测“已经做到哪里”。

工作图里有两种信息

动态工作图同时呈现两类事实，但它们解决的问题不同：

产品界面把两类记录合成一个便于阅读的视图。责任图决定依赖和验收，运行图补充过程证据；普通的文件读取、搜索等成功操作会留在详情里，失败、返工、重要产出和阻塞则提升到主图。画布本身是展示结果，分配、重试和权限变化仍然要经过宿主的结构化操作。

把进度保存成可以直接读取的数据

我们把 Goal、计划版本、分工、每次尝试、提交和验收分别保存到数据库。每份记录都有明确的归属，能查到它对应哪个目标、哪项工作和哪一次执行。

比如，“实现 CSV 导出”这项工作，可能已经运行两次，交过两份结果，其中第一份被退回。保存这些事实后，下一轮就能知道：第一份为什么被退回，第二份是否已经通过验收。

下一轮可以直接读取当前目标和工作状态。 交付要求、未完成责任、提交结果和退回意见都有各自的位置，模型可以据此继续判断。

计划也保留版本。如果中途增加独立复核，我们保存修订后的计划，旧计划继续作为历史记录存在。这样才能分清：哪些工作当时已经做过，哪些要求是后来加入的。

模型提出变更，宿主检查后写入

模型通过内置 Skill 了解怎样规划、分工和处理反馈。创建目标、修订计划、提交结果等操作，再通过本轮绑定的结构化控制命令交给宿主；在 Nexus 内部，这类命令属于 nexus.command。身份、执行范围和当前版本由宿主从运行上下文确定，不由模型在普通文本里自行声明。

例如，处理一份退回意见时，命令需要对应具体的工作项和提交。宿主会检查：本轮是否有权处理它，目标和计划版本是否仍然有效，当前状态是否允许这次变更。

检查通过，变更才会写入。 如果状态已经变化，模型需要读取最新结果，再决定接下来做什么。旧轮次发出的完成请求，不能直接结束已经修改过的目标。

这里也有明确的分工：代码该怎样修改、验证结果是否满足要求，需要 Agent 判断；这份判断属于哪项责任、是否可以生效、怎样保存，由宿主检查和记录。

把一轮内部的执行，和两轮之间的续跑接起来

一轮内部，Agent 会读取文件、调用工具、检查返回结果，必要时启动 Subagent。它可以在这一轮里完成多步工作。

一轮结束后，Goal 可能还没完成。宿主会核对目标状态、正在等待的协作、阻塞原因和运行限制，决定现在能否安排后续执行。

满足续跑条件时，Nexus 先保存“准备启动下一轮”的记录，再启动对应的运行，并记录它何时开始、何时结束。下一轮重新读取当前状态，继续未完成的工作。

我们把这两层循环接在一起：一层推进本轮行动，一层衔接跨轮次的任务。 因此，一次模型运行结束后，仍然有程序负责检查这件事是否需要继续。

让画布和执行器使用同一份记录

产品里的动态工作图，展示的是已经保存的责任与运行记录。节点之间的依赖来自计划，提交和验收对应具体交付，工具调用归到产生它的那次执行。前端拿到的是一个只读投影，不能因为画布上出现了“完成”就直接授予权限、重试工作或改写依赖。

第一次失败、第二次成功，会留下各自的记录。用户查看返工过程时，可以知道哪一份结果被退回，后面又发生了什么。

展示时，我们把工作责任、重要产出、失败和返工放在主图上，把普通成功的本地读取、查找等操作留在详情里。这样既能看清任务进展，也能在需要时继续追查过程。

动态工作图怎样处理一次返工？

现在给这个任务加一个问题：第一版 CSV 在目标软件里打开后，中文出现乱码。

一次普通返工，可以拆成下面几步。

步骤 1：提交第一版。

Agent 完成实现，提交可检查的结果。这时有了交付候选，验收尚未通过。

步骤 2：记录验证反馈。

兼容性检查发现问题，退回意见需要说明失败场景。例如：

示例反馈：目标表格软件中出现中文乱码。请修正导出实现，并补充该场景的复现与验证记录。

步骤 3：修正，再提交。

负责人根据反馈继续工作，形成第二份提交。第一份提交与退回意见仍然保留，不会被新的结果覆盖。

步骤 4：验收通过，推进下游。

新的提交经过检查后被接受，才满足对应的硬依赖。下游因此可以使用这份已验收的交付。

图 2：同一工作项的两次提交。每份提交保留自己的记录，验收结论对应具体提交。问题与结果为机制示意，并非实际测评。

这四步连起来，就是执行循环（Agent Loop）需要衔接的过程：读取状态 → 执行并提交 → 检查结果 → 根据反馈继续。

在这个例子里，负责人根据乱码反馈决定怎样修正；宿主保存新的尝试、提交和验收记录。下一步能否推进，就可以回到这些记录上核对。

哪些变化需要调整计划？

修复乱码通常可以在原工作项里返工。任务结构没有改变，就不必为了重试再画一张图。

如果新信息改变了工作结构，例如必须增加一次独立复核，就需要修订 Plan。新版本在允许切换责任的边界上生效。

实现上，我们把计划中的依赖和执行中的返工分开记录。依赖说明一项工作开始前需要哪些交付；返工说明某次检查以后，工作回到了哪次尝试。

这样，图中可以呈现返回修改的过程，计划里的任务依赖仍然保持清楚。需要重试时保留新的执行记录，需要重新组织工作时再修订计划。

缺少信息时，怎么继续？

假如用户还没说明需要兼容哪种表格软件，Agent 无法据此完成验证。此时应当停下，记录缺少的信息。

图 3：Goal 的阻塞状态演示。状态栏说明停下的原因与所需输入。使用真实组件、示例数据；周围布局为本文演示编排。

阻塞原因和所需输入，也是任务进展的一部分。 它们让用户知道工作停在哪里，以及下一步需要补充什么。

断连和重启则需要核对已保存的运行记录。Nexus 区分续跑的安排、领取、启动和结束阶段，恢复时确认具体运行走到了哪里。

外部操作超时后可能已经成功，需要先核对结果，再决定下一步。恢复执行不能简单地变成重复所有动作。

把这套技术路线压成四个动作

如果不看对象名，这套执行器其实一直在做四件事：保存目标、安排责任、核对交付、决定是否继续。 对用户来说，它们对应的是几个很直观的问题：这件事要做到什么程度，当前谁在做，哪份结果可以使用，还需要不需要下一轮。

第一步，用户设定 Goal。Nexus 保存目标内容、完成条件和当前版本，避免目标随着聊天滚动而失去参照。第二步，模型提出工作结构，宿主把它检查后写成 Execution、Plan 和 Work Item，并按依赖分配责任。第三步，Agent 产生 Attempt 和 Submission，Reviewer 通过 Acceptance 把可用交付与普通运行结果区分开。第四步，宿主读取最新状态：已经闭合就进入完成审计，需要返工就安排新尝试，缺少信息就阻塞，外部结果不明就先对账。

这四步也解释了为什么 Nexus 不把所有东西都交给模型决定。模型最擅长理解需求、比较方案和根据反馈调整行动；宿主最适合保存身份、版本和状态，检查一次变更是否有权发生。两边接在一起，才既有模型的灵活性，又有长任务需要的可恢复性。

从产品界面看，用户不一定会看到每一个内部对象。画布展示责任和重要运行事实，详情保留普通工具过程，状态栏说明 Goal 是否继续、阻塞或等待验收。界面越简洁，背后越需要一份结构清楚的持久记录来支撑它。

工作图完成，为什么还要检查 Goal？

最后回到最初的要求。

假设实现、验证和交付都已验收，但计划里从未包含“导出失败时给出明确反馈”。这时，图上的工作完成了，用户的要求仍然有缺口。

工作图检查计划中的责任。
Goal 检查最终交付与当前目标。

当 Goal 与工作图明确绑定时，结束任务需要经过三步：

1. 收口图上的责任：必要的工作交付通过验收。
2. 对照当前目标审计：负责人检查完成要求与实际交付是否一致。
3. 请求结束 Goal：满足相应完成条件后，结束目标。

对于 CSV 导出，最终仍要拿出内容、中文兼容和边界反馈的验证结果。完成计划，不能替代检查目标。

系统可以检查版本、审计记录和未完成责任，内容质量仍依赖实际验证。测试可能漏场景，模型也可能误判，保存一条“通过”记录本身并不能保证结果正确。

Goal 和工作图也能独立使用。三种使用方式可以这样区分：

只有第三种方式下，工作图的收口和 Goal 的完成审计才会共同决定最终结束。两者的绑定必须由系统明确确认，不能根据标题、聊天内容或时间邻近关系推断。

完成之后，什么值得复用？

实现、验证、复核、交付的组织方式，可以整理成下一次工作的起点。Nexus 支持从完成态工作图提取草图，通过对话调整，再由用户确认保存。

复用的是工作结构。 新任务会创建自己的计划、工作项与执行身份，也需要产生自己的交付证据。旧文件、工具调用和验收结论留在原任务里。

这种复用与 Agent Skill 有什么关系？下一篇继续讨论工作图与 Agent Skill 的区别。产品入口与操作见 Goal 指南和工作图指南。

实现依据：执行编排规范、执行图规范。本文界面演示使用真实产品组件，任务、反馈与结果均为示例数据。