跳到正文
DEV Community· Shaan·· 1 天前AI 評分62

智能體故障多數並非模型幻覺

Most agent failures are not hallucinations

AI 導讀

Shaan解讀 Tommy Tran 在 ACM Queue 的研究,指出智能體故障多數源於工具邊界、回傳資料、副作用或循環,而非模型幻覺。在固定故障設定下,基礎智能體任務完成率為 33.3%;只加入重試升至 83.3%,但出現重複記錄;加入七種模式後達 89.6%,且沒有重複記錄或孤立寫入。研究使用注入故障的玩具智能體;隨機故障下,斷路器反而降低任務成功率,只有真實依賴服務故障時才有作用。

正文

When an agent does something dumb, the usual reaction is "the model hallucinated" and a new line in the system prompt. A paper from this month argues that is usually the wrong diagnosis.

Tommy Tran's "Failure Is a Feature" in ACM Queue (October 15, 2026) starts from a plain observation. An agent is a loop. The model proposes an action, a harness runs it against some tool, the result goes back to the model. That is a coordinator making remote calls to services it does not control, over networks that drop things. It is a distributed system, with a nondeterministic part in the middle.

Distributed systems already have 40 years of answers for this. We just keep reaching for prompts instead.

Where agents actually break

The paper sorts failures by where they enter the loop:

  • Tool boundary: timeouts, 429s, dropped connections.
  • Payload: the call "works" but returns truncated JSON, an HTML error page, or a schema that drifted.
  • Model: wrong tool, invented arguments, declaring success without checking.
  • Side effects: the write went through, the acknowledgment got lost, the step was retried.
  • The loop itself: two tools ping-ponging, retrying a dead API all night, running out of context.

Only one of those is a model problem. The rest have boring, known fixes. A truncated response that says "balance": 1 instead of 1000 will happily get reasoned about by a model, because models parse everything. Nothing in the pipeline said no.

The experiment

The paper ships a small open harness so you can check the claims. Under a fixed fault profile, here is what happened:

Setup Tasks completed Side effects
Bare agent 33.3% not stated
Retries only 83.3% duplicate records created
All seven patterns 89.6% no duplicates, no orphaned writes

Retries alone look great until you notice the duplicates. A retry on a write that already succeeded gives you two refunds. The extra 6 points from the other patterns matter less than the cleanup they prevent.

Where faults enter the agent loop and which pattern covers each one

Three things worth stealing

1. The harness owns the idempotency key, not the model.
If you let the model fill in an idempotency_key argument, a retried step may come back with a different key and the dedup quietly stops working. Derive the key from something the harness controls:

def run_side_effect(task_id, step_id, tool, args):
    key = f"{task_id}:{step_id}:{tool}"  # same on every retry of this step
    return call_with_retries(tool, {**args, "idempotency_key": key})

If the model replans and proposes the action again, that gets a new step id, which is correct. That is a new decision, not a resend.

2. Treat the token budget like a deadline.
Give every task a time limit, a token limit and a step limit, and check them before each new step. The paper calls the step cap the cheapest insurance in the article. A few lines turn "the agent looped all night against a dead API" into "the task failed at step 20 with a clear reason".

3. Keep the model out of the retry loop.
Let the harness retry transient errors with backoff and jitter, and show the model only the final result or a typed failure. Otherwise you pay tokens for every attempt and fill the context window with failure narration. For dead dependencies, a circuit breaker should return something the model can plan around, like {"error": "circuit_open", "retry_after_s": 30}.

The honest caveats

The paper is upfront that this is a toy agent with injected faults. Circuit breakers actually lowered task success when faults were random, and only pay off when a real dependency goes down. So this is not a recipe to paste in. It is a way to stop guessing.

The bigger point matches what the paper says about benchmarks like tau-bench. Single-run success rates flatter agents. An agent that works most of the time per attempt fails a lot more often when you need it eight times in a row. Reliability, more than raw capability, is what stands between a demo and something you can leave running.

If you are building agents, my suggestion is to read the paper and run the harness before you write your next prompt fix. The link is below.

Source: Tommy Tran, "Failure Is a Feature: Engineering Fault-Tolerant AI Agents", ACM Queue, October 15, 2026. https://queue.acm.org/doi/10.1145/3841558

Disclosure: I wrote this with AI assistance (research and drafting), and checked the figures against the source paper.

來源:DEV Community · dev.to