---
name: base-task-loop
description: "通用任务执行手册：RESEARCH → PLAN → EXECUTE → VERIFY 四段式的每一步该产出什么、怎么流转、怎么自证做完。所有新本体从 _base 继承的默认主技能。"
layer: 1
domain: general
keywords:
  - task-loop
  - research-plan-execute-verify
  - handoff
  - self-verification
---

<!-- LEMONBOSS_BASE_SKELETON -->
> ⚠️ **本文件仍是 `_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（调研）

**目的**：把任务从"一句话"变成"一组已知事实 + 一组待定问题"。

1. 读任务本身：目标是什么、验收人是谁、有没有给参考物。
2. 去磁盘上找背景：相关代码 / 文档 / 上一轮的产出 / 同类任务的历史结果。
   **不要凭记忆断言仓库里有什么**，读一眼的成本远低于基于幻觉规划的返工。
3. 列出**空缺**：口径没定的、落点没说的、两种解法差异很大的。
   能自己拍板的写下"我按 X 处理，理由 Y"；真拍不了板的，这时候问上级（一次问全）。

**产出** `_research.md`：已知事实（带出处路径）、空缺与处置、初步判断。
写给"失忆之后的你自己"看 —— 下一阶段你手上只有这份文件。

**流转**：
```bash
node bin/lemon.js task transition --agentId <你的ID> --phase plan --artifact <_research.md 路径>
```

### 阶段二：PLAN（规划）

**目的**：把事实变成一条可执行、可验收的步骤序列。

1. 先写**验收标准**，再写实现步骤。验收必须是能跑的命令 + 能看的预期结果；
   "应正确处理边界情况"是废话，`node cli.js < empty.txt && echo OK` 才是标准。
2. 步骤切到"一步能做完、做完能立刻验"的粒度。一步超过五条验收，说明塞了两件事，拆开。
3. 写明**本次不做什么**，以及每一步会写到哪个文件（落点按坐标声明）。
4. 列出风险与回退：哪一步失败要怎么退回去，别把系统留在中间态。

**产出** `_plan.md`。**流转**：
```bash
node bin/lemon.js task transition --agentId <你的ID> --phase execute --artifact <_plan.md 路径>
```

### 阶段三：EXECUTE（执行）

**目的**：按 `_plan.md` 落地，不夹带计划外的改动。

- 改已有文件前先完整读一遍现状；新建文件前先确认没有同名的既有实现。
- 一次一步，做完一步就地自查（文件真写出来了吗？内容是你以为的那份吗？）。
- 计划外发现的问题：**记下来**，不顺手改。顺手改会让验证阶段说不清是哪一处生效了。
- 交付物写进坐标声明给的落点；cwd 里只留中间草稿。

**产出**：实际交付物 + 一份改动清单（改了哪些文件、各自为什么）。**流转**：
```bash
node bin/lemon.js task transition --agentId <你的ID> --phase verify
```

### 阶段四：VERIFY（验证）

**目的**：自己证伪自己，而不是自己说服自己。

1. 逐条跑 `_plan.md` 的验收命令，把**真实输出**贴进验证记录 —— 不贴输出的验证不算验证。
2. 回读一遍交付物的落点：路径存在吗？内容完整吗？别人按你写的路径能找到吗？
3. 反向检查：如果我的改动没生效，哪一条验收会红？一条都红不了，说明验收写空了，回去补。
4. 失败 → 把"试了什么 / 报什么错 / 判断的原因"写进 `_lessons.md`，打回上一阶段重来。
5. 确实全过 → `report_task({status: "PASS"})`，附上交付物路径与验收输出摘要。

## 硬规矩（违反即事故）

- 未走完四段直接汇报 PASS：严重违规。
- 交付物留在 cwd：等于没交付，下游读不到、索引指向空气且不会报错。
- 写坐标声明之外的路径（尤其仓库根）：节点会被判越界失败。
- 汇报里写"应该没问题 / 大概可以"：没跑过就是没做完，如实报 FAIL 更省事。