中文EN

搜索文章

输入关键词开始搜索
↑↓ 选择Enter 打开Esc 关闭

如何实现长程自动化任务

长程任务的关键，不是让 Agent 一直跑，而是把任务变成一个 可量化、可拆解、可验证、可恢复、可迭代 的闭环系统。

目标可量化 + 过程可分解 + 状态可恢复 + 结果可验证 + 失败可回滚

长程自动化任务的规格、执行、验收与恢复

1. 为什么长程任务容易失败？

很多人使用 CodeX 或 Claude Code 时，会直接给出类似这样的指令：

帮我重构一下这个项目，让代码更优雅。

这类任务很容易失败，因为它存在几个问题：

  • “更优雅”不可量化；
  • 任务范围不清楚；
  • Agent 不知道先做什么、后做什么；
  • 中途失败后无法恢复；
  • 最终结果缺少明确验收标准。

所以，长程自动化任务不能只靠一句 prompt，而应该设计成一套工作流。

2. 核心公式

一个稳定的长程任务系统，可以理解为：

Long-running Task
= Task Spec
+ Skill
+ Harness
+ Quality Gate
+ Checkpoint
+ Iteration Loop

其中：

模块作用
Task Spec定义目标、范围、验收标准、禁止事项
Skill固化这类任务的执行方法和检查清单
Harness驱动 Agent 按流程执行任务
Quality Gate判断每一步是否合格
Checkpoint保存当前进度，防止上下文丢失
Iteration Loop失败后自动修正、重试、回滚

如何实现长程自动化任务细节图

3. 第一步：写清楚 Task Spec

长程任务的起点不是 skill，而是 Task Spec。

Task Spec 要回答五个问题：

  1. 要完成什么？
  2. 不做什么？
  3. 涉及哪些文件或模块？
  4. 怎么判断完成？
  5. 失败后怎么处理？

示例：

## Goal
将旧图表组件迁移到 StandardChart v2。

## Scope
只处理 src/pages/report 和 src/components/charts。
不改动后端接口协议。

## Acceptance Criteria
- pnpm typecheck 通过
- pnpm test 通过
- pnpm build 通过
- 所有 ChartLegacy import 被移除
- E2E 截图 diff < 2%
- hover、legend toggle、resize 行为保持一致

## Out of Scope
- 不做 UI 风格重设计
- 不优化无关接口
- 不重构无关组件

一句话总结：

Task Spec 负责定义“什么叫做完成”。

4. 第二步：用 Skill 固化方法论

Skill 不应该负责临时制定目标，而应该负责沉淀一类任务的执行方法。

例如可以定义一个 chart-migration.skill：

# Chart Migration Skill

## When to use
当任务涉及旧图表组件迁移到 StandardChart / HiVis / LlmVis-Core 时使用。

## Procedure
1. 扫描旧组件引用
2. 建立 migration map
3. 一次只迁移一个页面或一个组件
4. 每次修改后运行 typecheck
5. 每迁移一个模块生成 checkpoint
6. 最后运行完整测试和截图 diff

## Checks
- 禁止直接改业务数据结构
- 禁止删除 fallback 逻辑
- 禁止跳过 error boundary
- 禁止在没有截图验证的情况下声称 UI 等价

一句话总结：

Skill 负责定义“这类任务应该怎么做”。

5. 第三步：用 Harness 驱动执行

Harness 可以理解为 Agent 的工作流控制层。

它不只是一个工具，而是一套流程：

读取任务
→ 制定计划
→ 拆分子任务
→ 执行修改
→ 运行检查
→ 记录结果
→ 判断是否继续
→ 失败后修复或回滚

对于 CodeX / Claude Code，可以在 prompt 中明确要求它按这个流程工作：

Read .agent/tasks/task-001.md.
Use .agent/skills/chart-migration.md.
After each subtask, update .agent/checkpoints/task-001-progress.md.
Do not proceed to the next module unless all quality gates pass.
If a gate fails, fix the issue and rerun the gate.
At the end, generate .agent/reports/task-001-final-report.md.

一句话总结：

Harness 负责定义“Agent 如何持续执行”。

6. 第四步：建立 Quality Gate

长程任务不能只靠 Agent 自己说“我完成了”。

必须有强制质量门：

类型示例
静态检查typecheck、eslint、dependency check
自动测试unit test、integration test、e2e test
构建验证build、bundle check
视觉验证screenshot diff、DOM snapshot
业务校验指标口径、聚合方式、时间范围、交互行为
LLM Judge代码解释、风险识别、规则对照

尤其在金融可视化项目中，只通过 build 远远不够，还要检查：

  • 图表是否真正回答了用户问题；
  • 聚合方式是否正确；
  • 指标口径是否一致；
  • 时间范围是否被误改；
  • tooltip、axis、legend 是否丢失关键信息。

一句话总结：

Quality Gate 负责定义“结果是否真的合格”。

7. 第五步：用 Checkpoint 保存进度

长程任务一定会遇到上下文丢失、执行中断、方向跑偏的问题。

所以每个阶段都要写 checkpoint：

# .agent/checkpoints/task-001-progress.md

## Current Goal
迁移 AInvest report 页面图表组件。

## Completed
- 已扫描旧 ChartLegacy 引用：23 处
- 已迁移 Overview.tsx
- typecheck 通过

## Pending
- 迁移 DetailChart.tsx
- 补充 tooltip snapshot test
- 运行 visual diff

## Risks
- DetailChart 使用了自定义 aggregation
- 不能直接替换为默认 StandardChart config

一句话总结：

Checkpoint 负责定义“现在做到哪一步”。

8. 推荐目录结构

可以在项目中建立如下结构：

.agent/
  tasks/
    task-001-chart-migration.md
  skills/
    chart-migration.md
    frontend-refactor.md
    ai-visualization-quality.md
  checkpoints/
    task-001-progress.md
  gates/
    chart-quality-checklist.md
    ui-regression-checklist.md
  reports/
    task-001-final-report.md

scripts/
  agent/
    run-quality-gate.ts
    run-visual-diff.ts
    check-chart-semantics.ts
    generate-task-report.ts

这样做的好处是：

  • 任务目标清晰；
  • 执行过程可追踪；
  • 中断后可以恢复；
  • 失败后可以定位；
  • 结果可以被自动验证；
  • 经验可以沉淀为下一次复用的 skill。

9. 最小可落地版本

如果不想一开始做得太复杂，可以先实现一个最小版本：

1. 一个 task.md：写清目标、范围、验收标准
2. 一个 skill.md：写清执行步骤和禁止事项
3. 一个 checkpoint.md：记录已完成、待完成、风险
4. 一个 quality-gate.sh：统一运行 typecheck、test、build
5. 一个 final-report.md：总结修改内容、验证结果、遗留风险

这已经足够支撑很多中等复杂度的自动化开发任务。

10. 最终结论

长程自动化任务的核心不是“让 CodeX 或 Claude Code 一直工作”，而是给它建立一个可控的闭环系统。

更准确地说：

目标可量化只是入口，验证可自动化才是闭环。

真正稳定的长程任务，需要同时满足：

  • 目标可量化；
  • 任务可拆解；
  • 过程可记录；
  • 结果可验证；
  • 失败可恢复；
  • 经验可复用。

Skill 负责沉淀方法，Harness 负责驱动流程，Quality Gate 负责强制验收，Checkpoint 负责防止任务跑丢。

只有这样，CodeX / Claude Code 才能从“临时帮手”变成真正可靠的长程自动化执行系统。

项目实战

Ziron

光是生成测试就花了一晚上。 我用了goal模式，中间还老是停下来。我感觉应该设置一个提示词，并且写到AGENTS.md里面，让每一轮对话都会去读一下。在这里面会给他指引，就是每一次都要去更新文档、更新进度，然后不断地自循环等等。否则模型不会遵循，中间总是会断掉或者停下来。

应该增加一个进度百分比统计功能，让我知道当前的完成度。

交接文档


You are continuing the Zircon-Cat long-running migration/refactor in the current
repository checkout.

User expectation:

- Work autonomously. Do not stop after each small task to ask for confirmation.
- Do not push to remote unless the user explicitly asks. Keep work local.
- Use local branches/worktrees, local commits, and local fast-forward merges into
  Main猫服S10.
- Use as many subagents/parallel workers as possible when tasks are independent or
  can be split (for example: packet extraction, fixture addition, doc updates,
  and quality scan/validation).
- Keep repo documentation updated frequently so context loss or AI-tool handoff
  does not cause goal drift.
- If a task touches protocol, persistence, resource parsing, connection
  lifecycle, or server behavior, add/update characterization tests first.

Repository rules:

1. Start by reading AGENTS.md.
2. Read docs/migration/STATUS.md.
3. Read .docs4agents/codebase-inventory.md.
4. Read .docs4agents/implementation-rules.md.
5. Run git status -sb.
6. Use project skills under .agents/skills/ when they match the task.
7. Do not treat .worktrees/ as source truth.
8. Do not port from old master into S10 unless explicitly comparing evidence.
9. Do not commit real game assets, database dumps, secrets, credentials, or
   private local paths.

Strategic target:

- Active migration base: Main猫服S10.
- Client target: Godot, GDScript-first for scenes/UI/input/presentation.
- Server target: modern .NET headless C# process.
- TypeScript role: tooling, validators, import/export, dashboards, admin/GM
  surfaces, and automation.
- First migration cycle keeps authoritative game logic in C#.
- Strategy: characterization tests first, then refactor/extract/rewrite.

Current verified state after the latest local work:

- Main猫服S10 has local-only commits ahead of origin. Do not push without user
  instruction.
- Compatibility gate command:
  dotnet test tests/compatibility/Zircon.CompatibilityTests/Zircon.CompatibilityTests.csproj
- Shared gate script:
  scripts/verify-compatibility.sh
- Latest verified slice: ServerItemActionPackets.cs contains
  ItemMove, ItemSplit, ItemLock, ItemUseDelay, LifePotionUseDelay,
  ManaPotionUseDelay, and PowerPotionUseDelay. Final
  `scripts/verify-compatibility.sh` passed with 25 tests, 0 failures after docs
  updates.
- Recent work has been extracting low-dependency server packet classes out of
  Library/Network/ServerPackets.cs into small source files while preserving
  namespace and public properties.
- Packet byte fixtures and source manifest snapshots live under
  tests/fixtures/protocol/.
- Packet fixture tests live in
  tests/compatibility/Zircon.CompatibilityTests/Protocol/PacketByteFixtureTests.cs.
- Source manifest tests live in
  tests/compatibility/Zircon.CompatibilityTests/Protocol/PacketSourceManifest*.cs.
- Last continuity checkpoint: 2026-06-13 (local check) — handoff prompt currently
  reflects the latest completed slice (`ServerItemActionPackets`) and still points
  to item-scalar packets as the next low-dependency extraction target.

Already covered server packet slices:

- ServerUserLocationPacket.cs: UserLocation.
- ServerMapStatePackets.cs: MapChanged, MapTime, ObjectRemove.
- ServerObjectMovementPackets.cs: ObjectTurn, ObjectHarvest, ObjectMove,
  ObjectPushed.
- ServerObjectActionPackets.cs: ObjectMount, ObjectDash.
- ServerObjectCombatPackets.cs: ObjectAttack, ObjectRangeAttack, ObjectMagic.
- ServerObjectStatePackets.cs: ObjectEffect, MapEffect, ObjectBuffAdd,
  ObjectBuffRemove, ObjectPoison, ObjectNPC, ObjectSpell, ObjectSpellChanged,
  ObjectNameColour.
- ServerObjectDeltaPackets.cs: MagicToggle, DayChanged, LevelChanged,
  ObjectLeveled, ObjectRevive, GainedExperience, HealthChanged, ManaChanged,
  ObjectStruck, ObjectDied, ObjectHarvested.
- ServerStatsPackets.cs: StatsUpdate, ObjectStats. These fixtures cover
  production Stats class packet serialization and SortedDictionary<Stat, int>
  encoding through Stats.Values.
- ServerMagicPackets.cs: NewMagic, MagicLeveled, MagicCooldown. These fixtures
  cover ClientUserMagic DTO serialization, SpellKey, MagicAction, TimeSpan,
  IgnorePropertyPacket Cost, and CompleteObject resolution through
  Globals.MagicInfoList.
- ServerItemActionPackets.cs: ItemMove, ItemSplit, ItemLock, ItemUseDelay,
  LifePotionUseDelay, ManaPotionUseDelay, PowerPotionUseDelay. These fixtures
  cover GridType, Int64, Boolean, and additional TimeSpan delay packets without
  pulling in item DTOs.
- ClientUserMagic.cs is extracted from Library/Globals.cs with namespace and
  public members preserved.

Recommended next work:

1. Start a new local worktree from Main猫服S10 with branch prefix codex/.
2. Run scripts/verify-compatibility.sh before changes.
3. Inspect the remaining classes in Library/Network/ServerPackets.cs.
4. The next likely slice should still avoid the larger item DTO group at first:
   - Possible lower-dependency candidates: ItemChanged, RuneNameRefreshed,
     ItemDurability, or nearby scalar/string item packets.
   - Defer ItemsGained, ItemStatsChanged, ItemStatsRefreshed, and
     ItemInfoRefreshed until ClientUserItem, FullItemStat, ItemInfo, and
     Globals.ItemInfoList dependencies are intentionally isolated.
5. Before extracting the next slice, design the smallest characterization path:
   - Prefer one packet boundary group at a time.
   - Compile only the minimal production DTO files needed by the compatibility
     harness.
   - If CompleteObject hooks need Globals state, characterize that exact
     behavior with controlled fixture setup.
6. Follow TDD:
   - Add byte fixtures/readback assertions first.
   - Confirm RED failure is meaningful.
   - Move/extract the minimal production code.
   - Refresh snapshots only after documenting why.
   - Run filtered tests, then scripts/verify-compatibility.sh.
7. Update docs/migration/protocol-spec.md, docs/migration/test-strategy.md,
   docs/migration/legacy-risk-map.md, docs/ai-harness/README.md,
   .docs4agents/codebase-inventory.md, and docs/migration/STATUS.md.
8. Run git diff --check, scripts/verify-compatibility.sh, harness validation,
   and the codebase audit scan before committing.
9. Commit the completed slice locally, fast-forward merge into Main猫服S10,
   rerun scripts/verify-compatibility.sh on Main猫服S10, remove the worktree,
   and continue to the next slice without asking the user.

Quality/audit loop:

- Treat green executable gates separately from scanner risks.
- Existing scanner risks include large legacy files, fail-open/default-allow
  pattern hits, and a few silent-failure hits. These are not all blockers for
  packet fixture slices, but they should drive later quality-improvement tasks.
- The quality target remains high, but do not attempt broad rewrites before
  characterization coverage exists.

Loop Engineering


# Loop Engineering Plan: Server Packet Slice Migration

Created: 2026-06-13

## Goal

Design and run an automated loop system that extracts the remaining ~100+ packet classes from `Library/Network/ServerPackets.cs` without human babysitting. Each cycle: extract → fixture → test → verify → document → commit → merge.

## Architecture

┌──────────────────────────────────────────────────────┐ │ Loop Controller │ │ (Claude Code /loop dynamic, STATUS.md driven) │ ├──────────┬──────────┬──────────┬──────────────────────┤ │ Slice │ Build │ Verify │ Merge & │ │ Worker │ Worker │ Worker │ Doc Updater │ │ (extract+ │ (compile+│ (gate+ │ (docs refresh+ │ │ fixture) │ red/green│ audit) │ commit) │ ├──────────┴──────────┴──────────┴──────────────────────┤ │ Memory Layer │ │ STATUS.md / NEXT_AI_HANDOFF_PROMPT.md / │ │ codebase-inventory.md / protocol-spec.md │ └──────────────────────────────────────────────────────┘


## Five Modules + Memory

### Module 1: Automated Scheduling (`/loop`)

- **Rhythm**: Each cycle executes one complete slice (extract → fixture → test → docs → commit → merge).
- **Mechanism**: `/loop` with dynamic pacing via `ScheduleWakeup`. Each round reads `Next recommended task` from STATUS.md.
- **Termination**: `ServerPackets.cs` remaining unextracted classes == 0, or unrecoverable blocker (high-dependency DTO).
- **Interval**: 60-270s between rounds to keep cache warm.

### Module 2: Worktree Isolation

Each slice runs in a git worktree:

1. Create worktree from `Main猫服S10` with branch `codex/slice-<group-name>`.
2. Complete all changes in worktree.
3. `verify-compatibility.sh` passes → fast-forward merge into `Main猫服S10`.
4. Rerun gate on `Main猫服S10`.
5. Clean up worktree.

**Note**: Slices are serial because they all modify `ServerPackets.cs`, `.csproj`, manifest, and fixture files.

### Module 3: Skill Reuse

Existing project skills:

| Skill | Role in Loop |
|---|---|
| `zircon-cat-router` | Route to correct verification flow at start of each round |
| `zircon-cat-quality-gate` | Run gate at end of each round |
| `zircon-cat-dev-doctor` | Diagnose build/test failures |
| `zircon-cat-audit-followup` | Periodic (every 5 rounds) audit check |

New skill created: `zircon-cat-packet-loop` — encapsulates the full TDD cycle for one packet slice.

### Module 4: Verification Sub-Agent (Execution/Review Separation)

- **Execution Agent**: Main loop agent — extracts, writes fixtures, updates docs.
- **Verification Agent**: Independent sub-agent that checks:
  1. `verify-compatibility.sh` actually passed
  2. Namespace consistency of moved classes
  3. No missing public properties
  4. Docs match actual changes
  5. Snapshots are reasonable

The verification agent reads from filesystem independently, does not trust the execution agent's claims.

### Module 5: Memory Layer

Persistent state files on disk (already exist):

| File | Purpose |
|---|---|
| `docs/migration/STATUS.md` | State machine: progress, next task, open risks |
| `docs/migration/NEXT_AI_HANDOFF_PROMPT.md` | Precise handoff context |
| `.docs4agents/codebase-inventory.md` | Code asset inventory |
| `docs/migration/protocol-spec.md` | Protocol specification |
| `docs/migration/legacy-risk-map.md` | Risk map |

**Every round must update**: STATUS.md Progress Log and Next recommended task.

## Slice Grouping Plan

### Wave 1 (Low dependency, immediately executable) — ~17 slices

| # | Slice | Classes | Dependencies |
|---|---|---|---|
| 1 | NPC Refine | `NPCRefine`, `NPCMasterRefine`, `NPCAccessoryLevelUp`, `NPCAccessoryUpgrade`, `NPCRefineRetrieve`, `NPCClose` | Int/Bool/String |
| 2 | NPC Craft | `NPCWeaponCraft`, `NPCBreakthroughEnhance`, `NPCBreakthroughReset`, `NPCDungeonSelect`, `NPCTechnologyClear` | Int/Enum |
| 3 | NPC Quench | `NPCQuench`, `NPCQuenchRetrieve`, `QuenchList`, `NPCRefinementStone` | Int |
| 4 | NPC Misc | `NPCResponse`, `NPCRepair`, `DKey`, `RefineList` | String/Int |
| 5 | Trade | `TradeRequest`, `TradeOpen`, `TradeClose`, `TradeAddItem`, `TradeAddGold`, `TradeItemAdded`, `TradeGoldAdded`, `TradeUnlock` | Int/Bool |
| 6 | Mail | `MailList`, `MailNew`, `MailDelete`, `MailItemDelete`, `MailSend` | Int/String |
| 7 | Market | `MarketPlaceHistory`, `MarketPlaceConsign`, `MarketPlaceSearch`, `MarketPlaceSearchCount`, `MarketPlaceSearchIndex`, `MarketPlaceBuy`, `MarketPlaceStoreBuy`, `MarketPlaceConsignChanged` | Int |
| 8 | Guild Basic | `GuildCreate`, `GuildInfo`, `GuildNoticeChanged`, `GuildNewItem`, `GuildGetItem`, `GuildUpdate`, `GuildKick` | Int/String |
| 9 | Guild Member | `GuildTax`, `GuildIncreaseMember`, `GuildIncreaseStorage`, `GuildInviteMember`, `GuildInvite`, `GuildStats` | Int |
| 10 | Guild Online | `GuildMemberOffline`, `GuildMemberOnline`, `GuildAllyOffline`, `GuildAllyOnline`, `GuildMemberContribution`, `GuildDayReset`, `GuildFundsChanged` | Int/String |
| 11 | Buff | `BuffAdd`, `BuffRemove`, `BuffChanged`, `BuffTime`, `BuffPaused` | Int/Bool |
| 12 | Rank & Observer | `Rankings`, `StartObserver`, `ObservableSwitch`, `Inspect` | Int/String |
| 13 | Companion | `CompanionUpdate`, `CompanionSkillUpdate` | Int |
| 14 | Marriage | `MarriageInvite`, `MarriageInfo`, `MarriageRemoveRing`, `MarriageMakeRing`, `MarriageOnlineChanged` | Int/String |
| 15 | Data Object | `DataObjectRemove`, `DataObjectPlayer`, `DataObjectMonster`, `DataObjectItem`, `DataObjectLocation`, `DataObjectHealthMana`, `DataObjectMaxHealthMana` | Int (verify DTO) |
| 16 | Block & Misc | `BlockAdd`, `BlockRemove`, `FortuneUpdate`, `TreasureChest`, `TreasureSel` | Int/String |
| 17 | Craft System | `CraftStartFailed`, `CraftAcknowledged`, `CraftResult`, `CraftExpChanged`, `BreakthroughStatInfoList`, `MaterialItemList` | Int |

### Wave 2 (Medium dependency, need 1-2 DTO isolations)

- `Login`, `StartGame`, `GameLogout` — need `StartInformation` DTO
- `ObjectPlayer`, `ObjectMonster`, `ObjectItem` — need multiple DTOs
- `Chat`, `NewCharacter` — partial fixtures exist
- `ToGetSortItem`

### Wave 3 (High dependency, systematic DTO extraction needed)

- `ItemsGained`, `ItemStatsChanged`, `ItemStatsRefreshed`, `ItemInfoRefreshed` — need `ClientUserItem`, `FullItemStat`, `ItemInfo`

## Single-Round Execution Flow

Loop Controller starts │ ├─ 1. Read STATUS.md → get Next recommended task │ ├─ 2. Read ServerPackets.cs → confirm target classes exist │ ├─ 3. Dependency check → evaluate if safe to extract │ ├─ Extractable → continue │ └─ Not extractable → update STATUS.md with reason, pick next candidate │ ├─ 4. Create worktree (codex/slice-) │ ├─ 5. TDD cycle (in worktree) │ ├─ a. Add fixture tests (RED) │ ├─ b. Run narrow filter → confirm failure │ ├─ c. Extract classes to new file │ ├─ d. Update .csproj │ ├─ e. Run narrow filter → confirm pass (GREEN) │ ├─ f. UPDATE_SNAPSHOTS=1 refresh snapshots │ └─ g. Run full gate │ ├─ 6. Dispatch verification Agent (independent sub-agent) │ ├─ Check namespace consistency │ ├─ Check public property completeness │ ├─ Check gate actually passed │ └─ Check docs consistency │ ├─ 7. Update docs │ ├─ STATUS.md (Progress Log + Next task) │ ├─ protocol-spec.md │ ├─ codebase-inventory.md │ └─ NEXT_AI_HANDOFF_PROMPT.md │ ├─ 8. Commit + Fast-forward merge to Main猫服S10 │ ├─ 9. Rerun gate on Main猫服S10 │ ├─ 10. Clean up worktree │ └─ 11. Report results → ScheduleWakeup → next round


## Risks and Safeguards

| Risk | Safeguard |
|---|---|
| Accidentally change packet binary format | Fixture snapshot comparison, gate tests |
| Miss public properties | Verification Agent compares independently |
| Context loss causing direction drift | STATUS.md as state machine, restore from disk each round |
| Concurrent worktree conflicts | Serial execution (shared ServerPackets.cs) |
| High-dependency DTO blocks | Auto-skip and log, never force extraction |
| Verification and execution agent collude | Verification Agent uses different model, reads filesystem independently |
| Infinite loop on failure | Max retry 3 per slice, then halt and log to STATUS.md |

## User Responsibilities

1. Review this plan (done).
2. Occasional STATUS.md progress checks.
3. Push to remote only when explicitly requested.
4. Review Wave 2/3 DTO extraction strategy when Wave 1 completes.

参考资料

Loop Engineering

https://addyosmani.com/blog/loop-engineering/ https://mp.weixin.qq.com/s/QR40uuNa1oxtV5ds3i3Ukw A loop needs five things and then one place to remember stuff. Let me list it first and then map it.

  1. Automations that go off on a schedule and do discovery and triage by themselves.
  2. Worktrees so two agents working in paralell dont step on each other.
  3. Skills to write down the project knowledge the agent would otherwise just guess.
  4. Plugins and connectors to plug the agent into the tools you already use.
  5. Sub-agents so one of them has the idea and a different one checks it.

Then the sixth thing, the memory. A markdown file, or a Linear board, anything that lives outside the single conversation and holds what’s done and what is next. Sounds too dumb to matter. But it’s the same trick every long running agent depends on and I went into it in long-running agents, the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesnt.