plan-for-agents · git:20260922.be19ce4 · 2026-09-22 · sha256 e0e47799936914ba
plan-for-agents git:20260922.be19ce4A
Immutable. This exact content never changes and is served at /api/v1/blob/e0e47799936914ba.
--- name: plan-for-agents description: 创建、修订或检查供 agent 执行的完整 plan,将需求和已确认决策落实为方案、步骤、产物与验收证据,适用于实施、调研、创作、数据处理等任务。 disable-model-invocation: true --- # 面向 agent 的完整 plan 让未参与前期讨论的 agent 读完计划及明确引用的材料后,能知道目标、依据、执行方式、决策权限和完成判据,无需从聊天记录中猜测关键约定。 完整性按有效要求与执行边界判断,不以篇幅、章节数量或模型意见一致为依据。保留执行所需的信息,合并重复表达;简单任务可以用短计划覆盖全部必要内容。 ## 1. 确定本次工作和依据 先区分用户要求的是创建计划、修订已有计划,还是只检查完整性。只检查时交付问题与依据;创建或修订时交付可独立使用的当前方案。编写计划本身不授权实施、发布或启动其他 agent;沿用会话中已有的授权。 读取用户指定的需求、已确认决定、现有 plan 和与执行相关的事实材料。明确权威来源及适用范围;需要固定版本时记录 commit、文档版本、数据时间范围等可复核标识。“最新”应核实后指向具体版本。 - 区分当前事实、目标要求、已确认决策、实现建议、假设和待决项。现状不能替代目标,助手建议不能自动升级为用户决定。 - 用户已裁决的事项直接承接。常规执行细节可由 agent 根据约束选择,避免把命名、文件划分等都变成用户问题。 - 材料冲突或缺口会改变范围、结果或重要取舍时,先查可取得的证据;仍无法确定的,列出影响和最小必要问题,并继续不受阻塞的部分。 完成条件:能说明本次计划的范围、依据和确认状态,并识别哪些工作受未决项阻塞。 ## 2. 写清通用核心内容 以下是内容要求,不是固定九章模板。沿用合适的已有结构,按任务规模合并章节;不适用的内容无需空占标题。关键规则在正文说明,来源链接用于核实,不能代替规则本身。 | 内容 | 必须明确的信息 | |---|---| | 目标与完成标准 | 预期结果、交付对象,以及可观察、可检查的完成条件。 | | 范围与约束 | 本次包含和排除的工作;用户要求、资源限制、权限边界和必须保持的行为。 | | 输入与事实依据 | 所需材料、已核实的当前状态、可复用能力、目标差距;来源版本、冲突处理依据和未核实信息。 | | 决策与待决事项 | 已确认选择及必要理由、接受的代价、可调整的执行细节;未决问题、决定者及受阻塞的步骤。 | | 总体方案 | 从当前状态到目标状态的方法;组成部分的职责、输入输出与协作关系;关键选择的理由。 | | 执行步骤与依赖 | 具体行动、前置条件、顺序、产物与完成判据;可独立推进的工作及交接条件。 | | 边界与异常处理 | 与任务相关的输入缺失、失败、冲突、打断等场景;重试、停止、回退、恢复或请求裁决的条件。 | | 验证与验收 | 各项要求对应的验证方法、预期结果、证据位置、失败处置,以及无法验证的范围。 | | 交付与接续 | 产物位置、格式、交付状态;发生中断或交接时,如何识别有效成果并继续剩余工作。 | 待决项存在时可以交付待确认稿,但受影响步骤必须保持阻塞状态。不得为了让 plan 看起来完整而填造事实、默选重要取舍或宣称已验证。 ## 3. 把方案展开到可执行粒度 按“可以独立执行并判断完成”的单元拆分步骤,给需要依赖或交接的步骤稳定标识。避免只有“分析、实现、测试”这样的阶段名称,也无需逐条预写普通机械操作。 每个实质步骤写清以下信息,简单步骤可以合并成一段: ```text 步骤 ID 与目标: 前置条件 / 依赖: 具体行动: 预期产物: 完成判据: 异常或阻塞时的处理: ``` 粒度是否足够,用这个问题判断:执行者是否仍需自行决定会改变目标行为、跨环节约定或正确性的事项?如果需要,就补足相关规则或标明待决;仅剩符合约束的常规实现选择时,留给执行者。 标明可并行不等于授权创建多 agent。只有任务需要时才指定执行角色;存在多人或多 agent 协作时,明确产物归属、共享修改边界和汇合条件,不预设模型或调度工具。 按任务补充会影响执行正确性的专业细节: - **软件开发:** 改动与复用范围、接口与数据约定、状态和关键时序;涉及迁移、并发、幂等、兼容或恢复时展开对应语义及验证。无需预写全部函数和代码。 - **调研分析:** 问题范围、资料获取方式、来源可信度、比较方法、证据冲突与不足时的结论边界。 - **文档或内容创作:** 受众、结构、事实来源、表达要求、审阅方式和成品格式。 - **数据处理:** 输入输出、转换规则、质量标准、异常数据处理;存在覆盖或损失风险时说明恢复方式。 - **外部操作:** 目标对象、执行权限、预览与提交边界;按实际风险确定结果核验及撤销或补救方式。 只写任务实际需要的内容,不为凑齐清单引入新机制、额外平台或假想风险。 ## 4. 修订时保持完整方案 以已有完整 plan 为修订对象,结合新的事实、用户裁决和有效 review 意见更新相关部分。用户只改变一个决定时,先检查该决定及其依赖,不把它解释为授权重写或压缩整份计划。 - 仍然有效的要求、接口约定、边界、步骤和验收细节保留。 - 被新结论推翻的设计,在对应位置替换,并同步依赖步骤、异常处理和验证要求。 - 重复内容合并到一个权威位置;读者通过明确引用找到它。 - 删除或合并实质内容时,在修订核对中记录原内容、处置理由和替代位置;确实不再需要时说明依据。记录默认留在工作过程中,有审阅或交接需要时另行交付。 摘要可以单独提供,不能替换完整正文。方案简化时写清取消哪些工作、为什么可以取消、留下什么代价,以及其余要求如何继续满足。原稿更长不是全部恢复的理由,但“保持精炼”也不是删除必要细节的理由。 已有评审流程时,评审对象应是实际修订后的完整文件与差异。对建议达成一致不代表修改后的文档已通过检查;修改发生在确认之后时,重新检查受影响部分并明确确认对应的版本。计划正文呈现当前有效方案,历史争论与 review 记录按需另存。 ## 5. 核对覆盖、可执行性和交付状态 对照原始有效要求与最终裁决,在工作过程中逐项建立: **要求 → 方案位置 → 执行步骤 → 产物 → 验收方式与预期证据。** 简单任务可逐项核对;复杂或跨环节任务可用映射表。只在交接或审阅确有需要时交付独立台账。 - **正向覆盖:** 每项有效要求、条件、例外和已接受代价都有落点;不能只核对主题标题或关键词。 - **反向核对:** 每项计划工作都服务于目标、要求或必要依赖;无依据的扩展删除或明确作为待选建议。 - **执行闭合:** 每个步骤具备输入、依赖、行动、产物和完成判据;关键交接没有缺失责任或互相等待。 - **边界一致:** 总体方案、具体步骤、异常处理和验收要求相互一致。检查是否存在符合计划文字却违反已确认要求的合理执行方式。 - **验证诚实:** 计划中的验证方法与执行后的证据分开。“待验证、已通过、失败、受阻”按事实记录;不能通过降低验收标准宣称完成。 执行中发现事实与计划不符时,记录差异、影响和调整理由。符合既定目标与约束的细节自行调整;超出已有授权、改变用户已确认决定或需要新的重要取舍时,请求最小必要裁决,同时推进不受影响的工作。 交付前回读最终产物。通过条件是:在声明的来源范围内,影响执行的遗漏、矛盾和歧义已解决,未决项及其阻塞范围清楚,执行者能定位所需信息。关键来源缺失时说明完整性检查的限制。 默认交付一份完整计划,使用用户指定路径或项目已有惯例。进度与执行证据放在明确区分的状态区或已有记录中;只在实际交接时记录当前成果、失败尝试、剩余工作和继续执行的入口。最终回复给出产物位置、核对范围与尚未解决的事项;计划通过检查不代表实际工作已经完成。