編碼智能體如何在上下文累積時避免偏離需求

You ask for one behavior: add a validation that rejects a malformed id before the request reaches the handler. The agent reads the route, finds the schema file, runs a couple of searches, edits two other call sites to match a style it saw nearby, and finishes with a green test. The validation you asked for is missing; it optimized the last thing it touched and called the task done. The requirement did not disappear, it just got buried under the working material.

Context fills, and the brief sinks

A coding agent does not keep a clean memory of your request. It carries a running transcript: fetched files, terminal output, rejected edits, summaries of those edits. As that transcript grows, the original one-line brief sits farther from the tokens the model samples next, and each new decision leans on recent material more than on the opening instruction. Nobody tells the agent to pause and re-check acceptance, so the last successful action quietly becomes the objective.

This is not a model that forgot; it is a context that rotated. The brief was never restated, the acceptance criteria were never pinned, and the intermediate output was never trimmed. Drift looks like competence because the diff compiles and the tests that happen to exist still pass.

The drift patterns to watch for

• Optimize-the-last-output: after fixing a nearby function, the agent keeps polishing that function instead of returning to the original target.
• Summary-takes-over: a recap block written midway through the task becomes the source of truth, and it states a slightly broader or narrower goal than you gave.
• Scope-creep-by-convenience: while editing, the agent fixes an adjacent rough edge because it was already in the file, and that detour pushes the real ask off to the end.
• Stale-tool-log: an early failed search or a rejected draft stays in the transcript and the agent treats it as a current constraint.
• Lost-initial-criteria: you described acceptance in prose at the start; by the end there is nothing to compare the diff against, so a subjective read wins.

Pin a short acceptance block

The cheapest anchor is a tiny block that never moves. Put it at the top of the task, in plain sentences the agent can quote back, and keep it separate from implementation notes. It should say what must change, what must stay unchanged, and the one check that proves it.

Acceptance for this task:
- Reject a malformed id at the route boundary, before the handler runs.
- Do not change existing valid-id behavior.
- Prove it with one negative-case test that returns the expected error.
Everything after this block is working material, not new requirements.

Restate and compare before done

Do not trust a done that arrived from a long transcript. Before accepting the work, ask the agent to restate the acceptance block and point to the exact diff hunk that satisfies each bullet. When a bullet has no hunk, that is an open item, not a detail to skip. One restatement pass catches most drift because it forces the model to measure the final diff against the opening brief instead of against its last edit.

Trim the transcript as you go too: drop early failed searches and superseded drafts rather than letting them ride along. A shorter, current context behaves like a focused engineer; a long muddy one behaves like someone reading from the middle of their notes.

Write a handoff between sessions

Context decays further when you stop and resume hours later. The new session opens cold, and without a handoff the agent reconstructs a goal from whatever is visible in the working tree. End a session with a short note: what was done, what is open, the acceptance block, and where the relevant files live. The next run starts from the anchor instead of re-deriving intent.

This is easier to hold when the anchor itself lives in the repo rather than only in the prompt. A checked-in contract or spec file the agent reads every session does not rot when the transcript does. That local-first, file-as-source-of-truth habit is the core of Powerduck; the same instinct applies to keeping a task brief from drifting.

Drift is invisible because the code still runs. The fix is not a bigger window; it is a fixed point the agent returns to, a periodic restatement, and a transcript that stays current instead of accumulating.