执行计划治理：以 PLANS.md 为纲构建 Agent 可接续的长期任务管理机制

【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载导读本指南以 PLANS.md执行计划策略定义文件为核心讲解在 Agent 优先的仓库模板中如何为跨会话、跨子系统的长期任务建立创建—更新—完成—归档的全生命周期管理机制。读完本文你将掌握执行计划的触发条件、目录规划、最小章节结构、运行规则以及如何借助docs/exec-plans/目录树与tech-debt-tracker.md让任何一个全新的 Agent 会话仅凭仓库即可无缝接续未完成的工作。为什么执行计划必须被治理在长期运行的编码 Agent 工作流中单个会话的上下文context是短暂的而任务往往跨越多个会话、涉及多个子系统。若任务进度只存在于对话历史中新会话将无从接续。PLANS.md 的核心主张是把执行计划持久化到仓库中使 Agent 在没有先前上下文的情况下也能接手任务。这正是本仓库所强调的仓库即系统之记录system-of-record思想在任务管理层的落地——进度本身成为可检索、可追溯的仓库资产。从模板整体结构见 repo-template/index.md可以看到该模板将명시적인 계획 라이프사이클显式的计划生命周期列为自身优化目标之一而 PLANS.md 正是定义这一生命周期的策略文件。它与 AGENTS.md 中세션 종료会话结束流程直接呼应会话结束前必须更新活跃计划、记录技术债、归档完成计划。何时需要创建执行计划PLANS.md 给出四条明确的触发条件满足其一即应创建执行计划触发条件典型场景任务跨越一个以上会话需要多轮开发、无法单次完成的特性任务变更一个以上子系统前后端、数据层、服务层联动修改存在不可忽视的验证或发布风险涉及部署、迁移、破坏性变更存在需要留档的未决决策方案尚未定论、需记录取舍过程这四条标准的意义在于防止无计划地盲目开工也防止为琐碎改动过度设计。简单、单会话、低风险的改动不需要执行计划直接把工作留在会话内即可。计划存放位置exec-plans 目录树PLANS.md 规定了三个存放位置对应计划的不同生命周期阶段docs/exec-plans/active/当前正在驱动工作的计划docs/exec-plans/completed/已完成、为未来 Agent 上下文而归档的计划docs/exec-plans/tech-debt-tracker.md被推迟的工作与后续跟进事项在仓库模板中这些目录已就位见 docs/exec-plans其中 active/index.md 明确了活跃计划的存放方式与命名规范每个活跃计划以独立的 Markdown 文件存放于active/目录推荐文件命名模式YYYY-MM-DD-short-topic.md如2026-09-23-agent-workspace-indexing.md以日期主题保证排序与辨识度每个活跃计划必须保持足够新使新 Agent 会话仅凭仓库即可恢复工作。这种活跃/完成分离的目录设计让进行中的工作与历史沉淀互不干扰同时保留全部上下文供未来检索。执行计划的最小章节结构PLANS.md 规定每个执行计划至少包含六个章节这是计划的最小骨架章节作用写作要点목표objective明确计划要达成的目标一句话可验证的目标描述범위 및 범위 외scope and out-of-scope界定做什么、不做什么防止 Agent 过度越界或遗漏검증 경로verification path如何证明工作完成可执行的验证命令或检查清单위험 및 차단 요소risks and blockers风险与阻塞项提前暴露依赖与不确定性진행 로그progress log进度日志记录每次会话的实际进展미결 결정open decisions未决决策留档待定方案与取舍其中검증 경로尤为关键——它呼应 AGENTS.md 中的완료 정의完成定义仅当目标行为已实现、所需验证已实际运行、证据已在相关计划或质量文档中链接时变更才算完成。验证路径写入计划等于把如何证明完成固化为可执行契约而不是靠 Agent 口头宣称。运行规则把计划当作活文档PLANS.md 最后给出四条操作规则定义了计划在运行期如何被维护一个活跃计划应有一个明确归属的当前步骤——避免多线程推进导致的混乱随着工作推进持续更新计划不将其视为静态文本——计划必须反映最新真实状态决策若改变实现方向须记录到计划中——让为什么这么做可追溯完成的计划移动到completed/——供 Agent 在未来继续发现先前的上下文。这四条规则与 AGENTS.md 的작업 계약工作契约和세션 종료会话结束流程构成完整闭环会话进行中持续更新计划会话结束前更新活跃计划、将完成的计划移入completed/、将推迟事项写入技术债追踪器。技术债追踪器被推迟工作的显式记录tech-debt-tracker.md 是执行计划体系的补充件用于记录确实存在、已被认知、有意推迟的技术债。其核心定义是技术债是明知有更优方案、但因时间、风险、优先级等原因有意选择的次优方案。该文件提供标准表格模板날짜日期영역领域부채债务미룬 이유推迟原因위험风险다음 트리거下次触发条件YYYY-MM-DD[area][debt][reason][risk][when to revisit]这种结构化记录让 Agent 与团队成员能一眼看出哪些区域需要改进、为何被推迟、何时应重新评估避免技术债沦为口头知识而随会话丢失。从 SOP 文档 encode-knowledge-into-repo.md 的视角看这正属于把 Agent 不可见的知识编码进仓库的执行状态execution state范畴——其完成定义是新 Agent 无需询问人类即可发现相关规则。与仓库整体工作流的衔接从源码结构看PLANS.md 并非孤立文件而是整条 Agent 工作流的枢纽开工时AGENTS.md 的시작 워크플로우开始工作流要求 Agent 在改代码前阅读 PLANS.md 并打开当前活跃执行计划过程中AGENTS.md 的작업 계약要求一次只处理一个受限的计划或功能切片且计划须随进展更新收尾时AGENTS.md 的세션 종료要求更新活跃计划、必要时更新QUALITY_SCORE.md、将推迟事项记入技术债追踪器、将完成计划移入completed/最终让仓库处于有明确下一步行动的可重启状态。同时repo-template/index.md 给出了接入模板的具体步骤将AGENTS.md与ARCHITECTURE.md复制到仓库根目录、复制整个docs/树、在docs/exec-plans/active/下添加第一个活跃计划。使用前需将占位符、示例与样例命令替换为实际项目内容。小结与落地清单执行计划治理的本质是把任务状态从易失的对话上下文迁移到持久的仓库结构。落实时可遵循以下清单满足四条触发条件之一时在docs/exec-plans/active/下创建YYYY-MM-DD-short-topic.md计划至少包含目标、范围、验证路径、风险、进度日志、未决决策六个章节每完成一个阶段即更新进度日志与状态绝不把计划当静态文本变更实现方向的决策必须回写到计划会话结束前将完成计划移入docs/exec-plans/completed/推迟事项记入docs/exec-plans/tech-debt-tracker.md确保任一新 Agent 会话仅凭仓库即可无外部提示地接手任务。如此执行计划便从一份文档升级为一套可接续、可验证、可追溯的长期任务治理机制。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐以 PLANS.md 为骨架的执行计划机制为 AI Agent 构建跨会话状态基础设施以 PLANS.md 为骨架的执行计划机制为 AI Agent 构建跨会话状态基础设施 在 learn harness engineering 仓库的 opeagent-skills以 notifications-spec 为例拆解规格到可执行任务计划的规划技能与行为评测机制agent skills以 notifications spec 为例拆解规格到可执行任务计划的规划技能与行为评测机制 本文以 notificationAI 技能开发工具AI 评测Benchmark用 PLANS.md 为 AI Agent 构建执行计划生命周期learn-harness-engineering 仓库模板实战指南用 PLANS.md 为 AI Agent 构建执行计划生命周期learn harness engineering 仓库模板实战指南 导读 本文以 learn上一篇抖音直播内容留存系统从技术实现到商业价值挖掘下一篇SEUThesis东南大学论文格式标准化的一站式解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考