AI Agent 的 Goal 是什么？从目标、计划到可验证完成条件
AI Agent 的 Goal 是什么？本文解释 Goal、Task、Plan、Work Item 和 Agent Skill 的区别，以及 Nexus Goal 如何支持目标版本、续跑、阻塞和完成审计。
本文内容
图 1：Goal 负责保存长期目标和完成条件；界面中的任务与工作图状态来自示例数据，用于说明机制。
AI Agent 的 Goal 是什么？如果只把一段需求放进提示词里，Agent 当然可以开始工作，但它并没有一个可靠的答案来回答：这件事最终要交付什么，用户后来改过哪些要求，当前是否还可以继续，以及什么证据才足以宣布完成。
在 Nexus 中，Goal 是跨轮次保存最终目的、完成条件和继续规则的对象。它不等于一条聊天消息，也不等于 Plan 或待办列表。Agent 可以在一次运行中完成很多步骤，但 Goal 负责让这些步骤始终回到同一个可检查的目标。
这篇文章从一个生产级 CSV 导出需求出发，解释 AI Agent Goal 如何与动态工作图、执行循环和交付验收配合。
Goal 解决的不是“记住一句话”
假设需求是：
为客户上线批量 CSV 导出。用户需要有权限才能导出，十万条记录不能让界面失去响应，中文在目标表格软件中正常打开，失败和取消都要有明确反馈，审计记录要能追溯。
这句话里面有多个完成条件。Agent 可能先完成接口，再发现权限边界没有定义；也可能文件可以下载，但大数据量会超时；还可能功能通过了，失败提示和文档没有跟上。
Goal 的作用，是把“最终要交付什么”从一次性输入提升为可以持续核对的事实。
| Goal 保存的事实 | 它回答的问题 | CSV 导出中的例子 |
|---|---|---|
| 目标内容 | 最终要解决什么问题？ | 客户可以安全、稳定地导出记录 |
| 完成条件 | 什么结果才算完成？ | 权限、性能、编码、反馈和审计都满足 |
| 目标版本 | 用户后来改了什么？ | 增加取消操作和审计字段 |
| 续跑状态 | 现在是否应该继续？ | 等待用户确认目标软件时先阻塞 |
Goal 因此给长任务提供了一个持续参照，不会随聊天滚动消失，也无需靠多读一遍原始 prompt 来维持。
一个 Goal 至少要能回答哪些问题？
从使用者的角度看，一个可执行的 Goal 不需要把所有实现细节都预先写完，但至少要能回答四个问题：要交付什么，怎样判断交付成立，当前依据的是哪个版本，以及在什么情况下继续或停下。
可以把它看成一张面向执行器的目标卡片：
目标：上线可靠的批量 CSV 导出
完成条件：权限、规模、编码、取消、失败反馈、审计记录
当前版本：v3（新增目标软件与取消行为）
当前状态：等待兼容性验证
继续条件：目标软件和版本已确认，且没有未对账的外部结果
这段结构为宿主在下一轮提供稳定的读取入口，无需模型照着字段填空。模型可以根据目标选择先补接口还是先查兼容性，宿主则能判断这次行动是否仍然服务于当前版本，是否已经具备继续条件。
如果这些事实只存在聊天记录里，用户修改要求后，系统需要从一长串消息里重新推断哪些话有效；如果只保存一个布尔值 completed，系统又无法说明完成的是哪组条件。Goal 的价值就在这两个极端之间：保留目标的语义，又让关键状态可以被程序检查。
在 Nexus 里，设定 Goal 是什么操作？
从产品使用上看，设定 Goal 不是在普通消息里加一句“请一直做下去”。用户在输入区选择 设定 Goal，填写目标和完成标准；保存后，目标状态会出现在输入框上方，后续可以从同一个位置观察、暂停或继续。
| 用户操作 | 它改变的是什么 | 容易混淆的地方 |
|---|---|---|
| 填写目标与完成标准 | 建立当前 Goal 和第一版完成条件 | 不能只写一个没有停止条件的愿望 |
| 调整预算 | 改变 Goal 可以消耗的持续工作用量 | 预算不是模型账户充值，也不保证一定完成 |
| 暂停 | 停止自动续跑，保留已有进展 | 暂停不会撤销已经完成的动作 |
| 继续 | 在当前目标和已有状态上恢复推进 | 恢复前仍要确认材料和外部条件没有变化 |
| 清除 | 移除当前 Goal 的持续目标状态 | 清除不等于对已经交付的文件做回滚 |
目标输入和普通附件也有边界：需要处理的材料应先准备在当前工作区，再在 Goal 中引用。这样，下一轮 Agent 读取的是稳定的目标和工作区事实，而不是依赖一条可能已经滚出上下文的消息。
Goal 的状态栏解决的是“这项长期工作现在处于什么状态”，并不替代结果验收。目标显示完成后，仍然需要打开交付物、检查来源或运行验证；如果还需要多人分工和独立验收，再使用动态工作图。
Goal、Task、Plan 和 Skill 有什么区别？
这些词经常一起出现，但它们解决的层次不同：
| 概念 | 保存或描述什么 | 生命周期 |
|---|---|---|
| Goal | 最终目标、完成条件、版本与续跑状态 | 跨多轮执行 |
| Plan | 为一次执行组织哪些工作以及怎样依赖 | 随计划版本演进 |
| Work Item | 一份可交付的持久责任 | 直到交付、取消或替换 |
| Task | Agent 本轮内部要做的局部步骤 | 通常只在当前执行中有效 |
| Agent Skill | 做某类事情的方法、指令、脚本和资料 | 可被不同任务复用 |
比如“读取数据结构、修改接口、运行测试”是 Task；“实现服务端导出并提供审计记录”是 Work Item；“把客户交付的导出能力做到可发布”才是 Goal 的层次。
Skill 可以告诉 Agent 怎样实现流式导出或怎样检查 CSV 编码，但它不会自动成为这一次任务的完成凭证。需要了解 Skill 和工作图的边界，可以继续阅读工作图与 Agent Skill 有什么区别。
Goal 如何和动态工作图绑定？
Goal 负责最终方向，动态工作图负责一次执行中的责任链。它们的关系可以先记成：
Goal
↓ 明确绑定
Execution → Plan → Work Item → Assignment → Attempt
↓
Submission → Review → Acceptance
一个 Goal 可以只有续跑状态，没有持久工作图；这适合目标明确、但仍由单个 Agent 逐步推进的任务。也可以让 Goal 与一个 Execution 明确绑定，让工作图的验收结果参与 Goal 的完成审计。
绑定关系必须由系统明确确认。不能因为标题相同、消息挨得很近，或者某个 Agent 声称“这是这个目标的任务”，就自动把一份执行记录归到 Goal 上。
当 Goal 与工作图绑定后，结束任务要经过两层检查：
- 工作图中的必要 Work Item 已经交付，并且对应 Submission 通过 Acceptance。
- 当前 Goal 的完成条件与实际交付逐项对照，没有被旧版本或局部成功掩盖。
这解释了为什么“所有节点看起来完成”仍然不一定代表 Goal 完成。图检查责任，Goal 检查最终结果。
目标发生变化时，旧执行怎么办？
长任务中，用户可能在中途补充要求。比如原本只要求导出字段正确，后来又要求记录导出人、限制角色，并允许用户取消大文件导出。
Nexus 会把这看成目标版本的变化。新一轮要读取当前目标版本，旧轮次不能拿着旧完成条件宣布新目标已经完成。原有工作可以继续复用，但哪些交付仍然有效，需要回到当前版本重新核对。
这和“把新要求追加到聊天底部”不同。聊天可以记录变化，Goal 负责让变化成为执行器下一轮能读取的正式事实。
旧交付什么时候还能继续使用？
目标升级以后，已经完成的工作不必全部作废，但也不能默认继续有效。判断一份旧交付能否复用，至少要看三件事：它属于哪个目标版本，覆盖了哪些完成条件，以及新要求是否改变了它的前置假设。
例如，原版本只要求“有权限的用户能够导出”，服务端权限测试通过后可以保留；新版本又增加“导出动作必须写入审计记录”，这份旧交付就只能证明权限部分，不能直接覆盖新增的审计条件。系统可以让后续工作继续使用旧结果，但最终 Goal 审计仍要补齐新增要求。
这也是目标版本和工作图版本各自存在的原因：目标版本表达用户要求怎样变化，计划版本表达责任结构怎样变化。两者都保留历史，下一轮才知道哪些事实可以继承，哪些事实必须重新核对。
Goal continuation 怎样决定下一步？
续跑不是一个简单的定时器。Nexus 需要先读取当前 Goal、Execution 和工作图状态，再按顺序判断：是否已经完成，是否有可以推进的已验收交付，是否缺少用户输入，是否存在外部未知结果，以及是否碰到了用量或租约边界。
可以把这段判断理解为：
| 检查顺序 | 发现的事实 | 执行器的动作 |
|---|---|---|
| 完成审计 | 当前完成条件全部有证据 | 收口 Goal，不再启动新一轮 |
| 可推进 | 有新的 Acceptance 解锁下游 | 为对应责任安排下一轮 |
| 需要输入 | 缺少目标软件、权限或范围 | 记录 blocker，等待用户 |
| 状态未知 | 外部请求结果没有确认 | 进入 reconciliation，不重复副作用 |
| 达到边界 | 用量、期限或租约不允许继续 | 暂停续跑并说明原因 |
Goal continuation 因此更像一个有边界的控制回路。它不替 Agent 决定业务方案，但负责保证每次继续都有当前状态作依据，每次停下都有可以解释的原因。
Goal 什么情况下应该阻塞？
阻塞不是失败，也不是让 Agent 无限重试。以下情况都可能需要暂停续跑：
- 用户没有说明目标表格软件和版本，兼容性无法验收；
- 外部系统的提交结果未知，重复操作可能产生副作用；
- 目标已经达到用量、期限或运行租约边界；
- 当前执行需要人工确认权限、范围或发布结果；
- 连续几轮没有形成新的可验证交付。
阻塞状态应该说明停在哪里、缺少什么、谁可以解除。用户补充信息后，续跑从保存的 Goal 和工作图状态继续，而不是重新猜测整段历史。
什么时候只用 Goal，什么时候需要 WorkGraph？
| 场景 | 合适的结构 | 原因 |
|---|---|---|
| 单个 Agent 修改一个小函数 | 普通任务或 Skill | 工作范围短，结果可以一次验证 |
| 多轮研究，期间需要等待用户补充信息 | Goal-only | 需要保存目标和阻塞状态 |
| 多个 Agent 并行实现、验证和复核 | Goal + WorkGraph | 需要责任、依赖和验收证据 |
| 已完成的交付结构要反复复用 | Goal + 命名工作图 | Goal 保存本次目的，工作图提供抽象结构 |
Goal 不是把所有事情都变成长任务的理由。它适合有明确停止条件、需要跨多轮推进并且能够持续验证的工作。工作图则在任务出现多个责任、硬依赖或交付门槛时发挥作用。
下一篇讲Graph Engineering 与动态工作图如何组织 AI Agent 任务依赖，继续拆解工作图本身的结构。
本文讨论 Nexus 的 Goal 设计。任务、交付和反馈使用示例数据；产品界面用于说明组件关系，不代表一次真实客户运行。