Cursor 的智能體在同一工作流中重用過期 ID，可能導致後續 API 呼叫失敗或操作錯誤資源
When Cursor's Agent Reuses a Stale ID from an Earlier Step in the Same Workflow
Cursor 的智能體串接 API 呼叫時，可能沿用工作流較早步驟取得的過期 ID，導致後續請求失敗或操作錯誤資源。穩定的主鍵可沿用，但可能被替換、過期或版本化的 ID、token、ETag 等值，應在使用時重新讀取；過期 ETag 或版本可能引發 412 Precondition Failed。
Quick answer
When an agent chains API calls, it is tempted to reuse an identifier it captured earlier in the workflow rather than re-reading the resource. That is fine for a stable id, but when the value is a token, a version, a temporary record id, or an entity that a previous step replaced, the reused value is stale and the later call fails or mutates the wrong object. The agent reports a confident multi-step success while the final request is operating on an id that no longer represents the current state. Treat every value carried across a step as having a freshness assumption, force the agent to re-fetch identifiers that can change, and verify the full chain against the contract instead of trusting that a completed sequence was correct.
How the stale id enters the workflow
A typical workflow creates a temporary resource, then a later step replaces it and returns a new id. The agent holds the first one.
The agent saw the cart id in step 1 and treated it as a durable handle. It did not distinguish the stable user id from the ephemeral cart id, and never re-read the state after checkout to confirm what identifier a receipt should reference.
Why agents default to reuse
Reusing a captured value is the shortest path. Re-reading the resource adds a call and requires the agent to understand which identifiers are immutable and which are versioned. Trained to minimize steps, the agent generalizes "ids don't change" from its experience with primary keys and applies it to every handle, including temporary and replaceable ones. The failure is especially insidious because the first few steps genuinely succeed; only the final call reveals the assumption, and even then an agent may patch the symptom by retrying rather than correcting which value it carries.
| Carried value | Freshness assumption | Reuse risk |
|---|---|---|
| Primary key (user id) | Stable across the workflow | Low |
| Temporary record id | May be consumed or replaced | High |
| ETag / version | Changes on every write | Causes 412 when stale |
| Access token | Expires on a clock | 401 late in the chain |
| URL returned in a response | Specific to that resource state | Medium |
Making the chain verify its identifiers
Give the agent the rule that each carried value must be justified. Stable primary keys can be reused; anything that a prior step can replace, expire, or version must be re-read at the point of use. Where the API returns a fresh identifier in a response, that response value is authoritative for subsequent steps.
For tokens and versions, attach the current value immediately before the call rather than capturing it at the start of a long workflow. This is the same discipline as optimistic concurrency: the validator presented must match the resource's current state, not its state when the sequence began.
Catching it in review and tests
A multi-step agent workflow should be tested end to end against a stateful mock that actually models replacement and consumption, not a collection of static responses. Assert that the final request references the identifier produced by the preceding step, and include a case where the intermediate resource is replaced so a stale reuse produces a visible failure. During review, trace every identifier in the chain back to the response that created it. If a value appears without a provenance in the current state, that is the bug. The contract is the reference for which fields are stable and which are per-state, so the agent should not be left to guess.
FAQ
Why did the agent think the workflow succeeded?
Because each request it sent was valid at the moment it was constructed, and the agent judges success by completed steps. The reused id is only rejected on the final call, and without end-to-end verification the agent may report success based on the earlier green responses.
Is reusing any identifier unsafe?
No. Stable primary keys are designed to be reused and re-fetching them adds noise. The rule is to know the freshness assumption: immutable handles can be carried, while replaceable, expiring, or versioned values must be re-read from the current state.
How does this relate to 412 errors?
A stale ETag or version is the same class of problem and produces a 412 Precondition Failed. The shared fix is to present the value that reflects the current resource rather than the state captured at the start of the workflow.
Should the agent always re-read before every step?
Not every step; that would be wasteful. Re-read only values the contract marks as changeable or that a prior step can replace, and use the authoritative identifiers returned in responses rather than blindly holding the first value seen.
This is part of the Powerduck vs Cursor: API Contract Tools for AI Coding — start there for the full picture of keeping agent workflows accurate against the contract.
來源：DEV Community · dev.to