name: base-task-loop description: "通用任务执行手册：RESEARCH → PLAN → EXECUTE → VERIFY 四段式的每一步该产出什么、怎么流转、怎么自证做完。所有新本体从 _base 继承的默认主技能。" layer: 1 domain: general keywords:
- task-loop
- research-plan-execute-verify
- handoff
- self-verification
⚠️ 本文件仍是
_base通用骨架，还没有按角色填充过。 上面那行LEMONBOSS_BASE_SKELETON标记就是证据：它在，说明 agent-creator 还没把 这份定义改写成本角色专属的内容。标记被清除之前，这个本体不会从draft转正 （判据见server/services/agent-locator.js的missingBodyDefinition）， 也就不会被任何公司雇走。要让它上岗，就把本文件重写成这个角色真正的定义， 连同这段说明一起删掉 —— 保留它去补内容，等于告诉系统"我还没写完"。
Skill: 通用任务执行回路
这是
_base骨架自带的主技能，每个新本体出生时都带着它。 agent-creator 之后会用角色特化的技能覆盖或补充本文件；在被覆盖之前， 按本文件干活就能把一个任务从"收到"推到"可验收的完成"。
何时用
收到任何一个上级派发的任务时。跨度小到"改一行配置"，大到"实现一个子系统"， 四段式都不跳 —— 小任务的四段可以各只有几行，但不能没有。
先确认三个坐标（一次，30 秒）
提示词开头有一段运行时坐标声明。开工前先把它读明白，它决定了你后面每一次读写的落点：
| 坐标 | 是什么 | 规矩 |
|---|---|---|
| cwd（工作目录） | 本次任务的私有目录 | 草稿 / 日志放这儿，会被清理 |
| 本体目录 | 你自己的定义（agent.md / soul.md / 主技能） |
只读；从 cwd 数是 ../../（{任务ID} 一层、{公司ID} 一层） |
| 交付物落点 | 声明里明写的那个目录 | 只有写到这里的东西才算交付 |
坐标声明里没出现的路径一律不写，代码仓库根目录尤其不许写 —— 边界守卫会把越界
判成节点失败，而且归因常常落到别的节点头上，排查代价极高。
../../ 之外要读什么，先确认那是不是你的边界内。
四段式
阶段一：RESEARCH（调研）
目的：把任务从"一句话"变成"一组已知事实 + 一组待定问题"。
- 读任务本身：目标是什么、验收人是谁、有没有给参考物。
- 去磁盘上找背景：相关代码 / 文档 / 上一轮的产出 / 同类任务的历史结果。 不要凭记忆断言仓库里有什么，读一眼的成本远低于基于幻觉规划的返工。
- 列出空缺：口径没定的、落点没说的、两种解法差异很大的。 能自己拍板的写下"我按 X 处理，理由 Y"；真拍不了板的，这时候问上级（一次问全）。
产出 _research.md：已知事实（带出处路径）、空缺与处置、初步判断。
写给"失忆之后的你自己"看 —— 下一阶段你手上只有这份文件。
流转：
node bin/lemon.js task transition --agentId <你的ID> --phase plan --artifact <_research.md 路径>
阶段二：PLAN（规划）
目的：把事实变成一条可执行、可验收的步骤序列。
- 先写验收标准，再写实现步骤。验收必须是能跑的命令 + 能看的预期结果；
"应正确处理边界情况"是废话，
node cli.js < empty.txt && echo OK才是标准。 - 步骤切到"一步能做完、做完能立刻验"的粒度。一步超过五条验收，说明塞了两件事，拆开。
- 写明本次不做什么，以及每一步会写到哪个文件（落点按坐标声明）。
- 列出风险与回退：哪一步失败要怎么退回去，别把系统留在中间态。
产出 _plan.md。流转：
node bin/lemon.js task transition --agentId <你的ID> --phase execute --artifact <_plan.md 路径>
阶段三：EXECUTE（执行）
目的：按 _plan.md 落地，不夹带计划外的改动。
- 改已有文件前先完整读一遍现状；新建文件前先确认没有同名的既有实现。
- 一次一步，做完一步就地自查（文件真写出来了吗？内容是你以为的那份吗？）。
- 计划外发现的问题：记下来，不顺手改。顺手改会让验证阶段说不清是哪一处生效了。
- 交付物写进坐标声明给的落点；cwd 里只留中间草稿。
产出：实际交付物 + 一份改动清单（改了哪些文件、各自为什么）。流转：
node bin/lemon.js task transition --agentId <你的ID> --phase verify
阶段四：VERIFY（验证）
目的：自己证伪自己，而不是自己说服自己。
- 逐条跑
_plan.md的验收命令，把真实输出贴进验证记录 —— 不贴输出的验证不算验证。 - 回读一遍交付物的落点：路径存在吗？内容完整吗？别人按你写的路径能找到吗？
- 反向检查：如果我的改动没生效，哪一条验收会红？一条都红不了，说明验收写空了，回去补。
- 失败 → 把"试了什么 / 报什么错 / 判断的原因"写进
_lessons.md，打回上一阶段重来。 - 确实全过 →
report_task({status: "PASS"})，附上交付物路径与验收输出摘要。
硬规矩（违反即事故）
- 未走完四段直接汇报 PASS：严重违规。
- 交付物留在 cwd：等于没交付，下游读不到、索引指向空气且不会报错。
- 写坐标声明之外的路径（尤其仓库根）：节点会被判越界失败。
- 汇报里写"应该没问题 / 大概可以"：没跑过就是没做完，如实报 FAIL 更省事。