继续当前 Agent 对话，还是另开一个任务？

目标没有改变，下一条请求只是细化当前工作时，继续原来的 Agent 对话。当目标、交付物或工作边界变化到需要独立负责时，另开任务。如果上一项任务的状态还不清楚，就先查明状态，再要求作出新的变更。

仅凭对话长短作决定，并不可靠。长对话里可能恰好有一个小修正必须遵守的约束；短对话也可能已经不适合处理一项无关功能。先问：下一条请求要完成什么，它真正依赖哪些已有事实？

以下三个情景均为虚构。文件、任务编号和输出都是教学示例，没有通过这些示例创建或修改任何实际任务。它们展示的是怎样表述下一条请求。

根据工作本身作决定

选择把请求发到哪里之前，先问这些问题：

这是一条实用的编辑决策规则，不是对某个 Agent 产品的承诺。Anthropic 的上下文工程文章把指令、工具、外部材料和消息历史都视为上下文，并主张主动选择相关信息。另开对话，只改变了这幅更大图景中的一部分。

情景一：同一个目标，需要一处修正

情况。 虚构工作列表界面的任务 T18 正在修改空状态文案，草稿涉及 ui/EmptyList.tsx。你发现，当筛选器只是隐藏了已有条目时，“Create your first item”并不合适。目标仍然是帮助用户理解为什么列表为空。

选择：继续当前任务。 新请求是在纠正现有交付物的含义，需要保留“工作区确实没有条目”和“筛选结果为空”这一区别。若另开一个独立运行的任务，可能会让同一组件出现两个负责人。

发送下面这条后续请求：

继续 T18 在 ui/EmptyList.tsx 中的空状态文案修改。

目标仍然是解释列表为什么为空。调整草稿，让以下状态使用不同文案：

- 没有任何条目："No items yet. Create an item to get started."
- 应用的筛选条件没有匹配项："No items match these filters. Try
  changing or clearing the filters."

如果组件已经区分这两个状态，就使用现有区分。
如果没有，增加逻辑前先指出缺少什么信息。
保持在 T18 的文件归属和既有交付边界内。

返回修订后的差异和实际做过的检查。
不要仅因本地文件改变，就把文案标为已发布。

这条后续请求重述了要改什么，没有重新开启整场设计讨论。它也没有猜测实现：组件也许已经接收到表示筛选结果为空的标记，也许还无法区分这两种情况。这个问题应由当前任务检查源码来回答。

如果同事已经在修改这个组件，继续原任务仍需协调。保留同一个对话，并不会自动解决文件归属冲突。

情景二：目标不同，值得独立建任务

情况。 T18 的空状态文案草稿已经交付。现在你需要工作列表的 CSV 导出功能，并涉及筛选和权限规则。虽然界面有关联，结果却已经从解释一种状态，变成了交付一个文件。

选择：另开任务。 CSV 导出有自己的验收标准、数据处理和实施问题，不应由文案对话里的零散历史悄悄决定。

下面是这项新工作的完整说明：

# 新任务：调查筛选后工作列表的导出

## 目标

为具备相应权限的工作区成员，确定把已应用筛选条件下、跨分页的结果
导出为 CSV 所需的最小适当设计。

## 相关背景

列表已经区分没有条目和筛选后没有匹配项。T18 处理了这一区别的文案。
那项文案工作并不能证明导出语义、权限或实施准备已经确定。

阅读当前列表查询、已应用筛选条件的表示，以及权限检查。
开始前，核对所选仓库中的相关路径。
不要假定上一段对话里的文件位置仍然有效。

## 需要解决的验收问题

- 哪些行应该属于导出，包括其他分页上的行？
- 在什么时点确定筛选值与行数据？
- 必须包含哪些列？
- 没有结果或权限变化时怎样处理？
- 适合采用什么规模限制和完成行为？

## 第一份交付

一份关联源码的调查及拟议实施计划。
区分已确认行为和待定的产品决定。
列出可能改动的文件，以及与列表界面当前工作有何重叠。

## 工作边界

仅调查。本阶段不修改文件、不创建服务、不导出真实工作区数据、
不开拉取请求，也不部署。
实施将在审阅后，作为另行明确范围的下一步。

这份说明只带入 T18 与新任务相关的那一部分，不承接所有曾被放弃的措辞建议。它也不会把旧任务获准修改文案，理解成获准建立导出服务。

此时单独建对话有价值，是因为目标和第一份交付物可以独立判断，而不只是界面看起来更整洁。

情景三：上一项工作的状态未知

情况。 Agent 原先在处理导出变更，最后一条消息说“updated the selector”，但你无法确认改了哪些文件、是否有其他任务负责同一文件，或是否已经提交、部署。你接着想说“加一个下载按钮”。

选择：先确认已有状态。 此时启动新实施任务，可能会重复尚未完成的工作；直接继续“加按钮”，也可能是在只有摘要、没有实际材料的变更上继续建设。

向原任务发送下面的状态核对请求：

继续导出工作前，先查明当前任务状态。

上一条消息说选择器已更新，但我还没有一份经过核实的交付清单。
检查当前工作状态并报告：

1. 原始目标，以及哪些部分已完成、仍待处理或未知。
2. 实际改动的文件，以及所属版本或工作目录。
3. 运行过的检查、结果和对应证据。
4. 分别报告提交、合并和部署状态；未知继续保持未知。
5. 能够确认的其他活跃负责人，或相互重叠的变更。

本轮只核对状态，不加按钮、不重复实施、不提交、不回退、
不发布，也不部署。状态明确后，再建议下一项界面变更
属于这个任务，还是应另行限定范围。

这条请求解决的是“继续还是新建”之前的一个前提，并不要求重建一份完整的中断任务交接材料。只要有足够的已核实状态，能够判断下一个目标是延伸现有工作，还是形成另一份交付物即可。

如果原任务无法访问，也许需要另行限定范围的调查。给它同样窄的目的：检查实际材料、查明状态。对话无法访问，并不会让其中未完成的修改可以被放心替换。

新任务不等于重置记忆

新对话仍可能接收账号层面的指令、项目规范、检索到的文档或其他已提供的上下文，也可能操作相同文件、使用相同外部账号。“新建”不能证明记忆为空、工作区没有改动，或权限重新开始。

普通开发中，应决定保留什么上下文，而不是让 Agent 忘掉一切。保留当前目标、约束、权威材料、未决事项和工作边界，省去过时猜测及无关历史。

如果任务明确要求首次接触或盲测，就核验运行环境实际提供的隔离控制。“忽略前文”的请求，并不能证明先前消息或外部记忆不存在。本文的任务选择规则，不能替代那套单独的评估设置。

复用这份简短的上下文选择模板

预期结果：
[本请求必须产生的结果。]

与此前工作的关系：
[同目标下的一处修正／新交付物／状态尚未查明。]

需要承接的事实：
[已核实的约束、当前材料路径，以及仍有效的决定。]

需要重新核验的事实：
[工作版本、归属、可变配置，或未决状态。]

下一步：
[一项具体交付物及其完成条件。]

权限边界：
[本步骤可以改变什么，以及必须在哪里停止。]

下一条请求仍服务于同一个结果时，就继续原任务；需要独立目标和交付边界的工作，则分开处理。状态不确定时，先把状态查明，再在两条路线之间作选择，让下一条指令有真实起点。