你的 Agent 不是谨慎，是在防不存在的贼（中英切换）

You ask it to change one function. Dependency versions in the repo are pinned, that path has a single writer, and the artifact can be regenerated from versioned inputs. The task states three facts: this is the final version; you will add the tests; verification is one run of one test file.

What comes back in the diff is not the function. It is a blanket except Exception with a default return, a shim for the old call, and a question asking whether it should confirm before it touches the code. The tests are green.

My take: Your agent isn't careful. It's guarding against burglars who don't exist. Wrapping everything in try/except, falling back to a default, leaving a compatibility shim, asking before it touches the code: the moves people praise as safe are a separate failure. The evidence already says the failure cannot occur, that someone else owns it, how far treatment should go, or that you have accepted the risk. The agent treats it anyway. Getting better at the task does not fix this. The tests still pass. You spend the review taking the extra code back out.

The evidence is Hanjun Luo, Xiucheng Zhang, and Zhuoning Xu (New York University; Luo also at NYU Abu Dhabi), Zhimu Huang and Hanan Salam (NYU Abu Dhabi), Yingbin Jin and Xinfeng Li (The Hong Kong Polytechnic University), "ParanoiaEval: Benchmarking Unnecessary Defensive Work in Agentic Coding" (arXiv:2610.08662). The code and the 200 task pairs are at ZhuoningXu/ParanoiaEval_release.

The frame is the four risk treatments from software risk management: avoidance, transfer, mitigation, acceptance. NIST treats these four as the complete set of responses to negative risk. The benchmark is 200 repository-level task pairs on 50 repositories. The 44 situations were consolidated from 18,922 deidentified real coding sessions. Each pair differs by a single fact that settles how the risk should be treated. The fact is stated as a fact, never as an order: "this is the final version," not "do not add checks." The side with the fact is E+. The side that removes or reverses it is E−. Eight configurations run in their native harnesses: Opus-5, Sonnet-5, Sonnet-4.6, and Haiku-4.5 in Claude Code; GPT-5.6 Sol, Terra, Luna, and GPT-5.5 in Codex. Three runs per condition, 9,600 runs in total. A read-only judge labels violations. On 200 held-out human-consensus labels it reaches accuracy 0.965 and Cohen's κ of 0.93.

The evidence is in. 11.2% to 58.7% still guard.

The number worth forwarding: with the treatment-defining evidence explicit, unnecessary treatment still shows up in 11.2% to 58.7% of E+ runs. The floor is Claude Sonnet-4.6. The ceiling is Claude Opus-5. The four Codex models sit between 18.2% and 25.5%. Every configuration violates under all four treatments.

The evidence does move the rate. Paired against E−, every configuration treats the risk less often on E+ overall, with Holm-adjusted p-values of at most 0.012. Pooled, E− is 48.4%, E+ is 24.2%, and evidence responsiveness (ER) is 50.0%. Half of the excess treatment comes out. Half stays.

A low violation rate is not the same as reading the evidence. Sonnet-4.6's 11.2% is mostly that it rarely applies the treatment even on E−, where the rate is only 30.0%. When the evidence is absent, it often does not act either. The configuration that actually stops when the evidence appears is Haiku-4.5: violation rate 17.7%, ER 65.5%, the highest of the eight. Opus-5's ER is 25.4%, the lowest.

Better at the task does not mean less defense

Task success across the eight configurations runs from 88.3% to 97.6%. The highest is GPT-5.6 Sol, at 97.6%, with a violation rate of 21.0%. The strongest Claude Code configuration is Opus-5, at 95.8% success and 58.7% violations, the highest violation rate of the eight. Sonnet-4.6's task success is 90.3%, and its violation rate is the lowest.

Across the eight, the Spearman correlation of task success and violation rate is ρ = 0.55 (p = 0.17), not significant. Inside each harness, the order by task success does not match the order by violation rate. Stronger does not turn into less unnecessary defense.

A green check hides most of it. Of the E+ runs that contain an excess treatment, 92.7% still pass an oracle that only checks whether the task is done. Pass rate does not measure this. The pass rates on the AI topic do not include it.

Four treatments. Transfer barely hears the evidence.

These are not four flavors of caution. They are four places to stop. The evidence says a different thing in each. The rates below are means over the eight configurations.

Avoidance: the repository state already rules the failure out. Dependencies are pinned, the path has a single writer, the artifact can be regenerated, a type or a schema already guarantees the property. Guards, fallbacks, locks, and backups have nothing left to do. With the evidence present, excess treatment is still 30.2% (39.2% without it, a drop of 9.0 points, ER 21.3%). The burglar cannot come in that way. The agent is still at the door. Situations that recurred in real sessions include broad except around controlled outputs, and a silent default when that output fails. Haiku-4.5 is the most responsive configuration overall, and its avoidance ER is 0.0%, with a violation rate of 28.7%. The repository has already ruled the failure out. The guard does not come down.

Transfer: someone else already owns it. CI runs the suite, a maintainer will review, the library retries, version control can restore a tracked file. The agent should not do that job again. The evidence is barely heard: 21.8% to 20.9%, a drop of 0.9 points, ER 7.9%, p = 0.692. Some point estimates go the other way. Opus-5's transfer ER is −3.5%, Luna's is −23.6%, and GPT-5.5's is −30.2%. Pooled, there is no detectable drop. The authors flag a limit: mitigation and acceptance evidence sits in the instruction, while avoidance and transfer evidence mostly sits in the repository, so location itself may affect responsiveness. The tasks are built so the fact is encountered while completing the work. Even so, putting "CI owns this" in the repo did not produce a reliable drop.

Mitigation: the risk is still real, and the instruction sets a magnitude. How many runs, which files, how long a report. A stated magnitude is a place to stop. The mean falls from 78.5% to 26.4% (ER 67.4%). Leave the magnitude unstated and they do not stop. Removing a stated bound raises excess treatment in all eight configurations, by up to 68.7 percentage points. One recorded pair in the appendix: with the bound, one command, one test file, 10.3 seconds, 69 passing tests; without it, four commands, 44.6 seconds, a repository-wide test target, and 86 unrelated collection errors. Both sides can finish the task. What grows is the scope. The unbound side is not a violation by the paper's definition. It is the treatment the bound removes.

Acceptance: you have already decided. A final version, a deletion, an accepted compatibility break, tests you will write yourself. The agent should stop. The mean falls from 54.0% to 19.3% (ER 65.4%). Haiku-4.5's acceptance ER reaches 93.9%. Opus-5's acceptance violation rate is 70.7%, its highest of the four treatments. The paper is specific about what not-stopping looks like: it asks you to reconfirm a decision already made; after an accepted compatibility break it still adds a shim, a warning period, or a legacy branch; asked to delete, it deprecates or relocates instead.

Ordinary development is not a violation. A targeted test of the code you changed, and a final look at the diff, sit inside the minimal work that finishes the task. A violation is an action that treats the risk and goes past the treatment the evidence already set.

The tests are green. People send it back.

Twenty developers with at least five years of experience, and regular use of coding agents, rated 800 oracle-passing E+ runs, two ratings each. Model identity, judge labels, and variant roles were hidden. Because every run finished the task, satisfaction was scored on maintainability, runtime, and how much still had to be corrected, on a 5-point scale.

Runs with excess treatment scored 2.58. Runs without it scored 3.85. That is 1.27 points lower (95% CI 1.14–1.40, p < 0.001). Accepted as-is fell from 78% to 38%. Every treatment is penalized. Mitigation is the worst: 1.55 points lower, accepted as-is in 28% of cases against 80% without the excess. The 220 runs marked as clearly enlarging the task or its persistent artifacts scored 2.20, and 27% were accepted as-is. Krippendorff's α across raters is 0.76.

The bill has three lines. Accepted-as-is falls from 78% to 38%, so the extra diff comes back to you. A silent default and a broad except do not turn the oracle red: 92.7% of violating runs still pass. Shims, legacy branches, and widened verification stay in the repo, and the clearly enlarged runs are accepted as-is only 27% of the time. None of the three lines shows up on a green check.

Two steps you can run today

A prompt does not clear this. With the evidence explicit, the pooled violation rate is still 24.2%. For transfer, writing "CI already runs this" into the repo barely moves behavior. A person still has to read the diff. Two kinds of writing are what the paper shows actually move the rate: state a fact, not an order like "do not add checks"; and, for mitigation, state the magnitude.

Step one: write the facts that are already settled into AGENTS.md before the agent starts. Edit the block to match your repo. Every line is a fact, not an order.

## Settled facts
- Dependency versions are pinned. The supported runtime is the one declared in this repository.
- Continuous integration runs this repository's lint, build, and test matrix.
- Verification for a task stops at the scope that task names: the files, the count, or the single command.
- A deletion, an accepted compatibility break, a final version, or tests the user will write, when stated in the task, is the user's decision.

The magnitude belongs on this task, not in the standing file. For example: "Verification is this one command: pytest tests/test_event.py." In the recorded pair, that sentence is 10.3 seconds and one file. Without it, the same task spreads across the repository.

Step two: when it says done, read the diff before you read the green check. From the repo root:

git add -A
git diff -U0 --cached | grep -E '^\+' | grep -nE \
  'except[[:space:]]+(Exception|BaseException)|except:|fallback|shim|legacy|compat|deprecat|backup|Are you sure|请确认|要不要我' \
  || echo "no surface match; still read the diff against the four lines below"

No match is not a clean diff. Read every extra treatment against these four:

1. Avoidance: does the repository state already rule this failure out? If it does, a guard, a silent default, a lock, or a backup is extra.
2. Transfer: do CI, a maintainer, a library, or version control already own it? A second copy is extra. This is the class the evidence barely moves, ER 7.9%.
3. Mitigation: did it go past the count, the files, or the tier you wrote down?
4. Acceptance: a deletion, a compatibility break, a final version, or a next step you kept for yourself — did it become a shim, a deprecation, or another question?

One rule: a green oracle is not evidence for these four. Of E+ runs with excess treatment, 92.7% pass anyway.

In one line: Your agent isn't careful. It's guarding against burglars who don't exist. Write the facts and the bound before it starts, and delete the extra defense in the diff. The tests will not find it for you.