2_related_work · 完整稿件源码

\section{Related Work}
\paragraph{Direct decisions and lightweight classifiers.}
Typed outputs are an interface for integrating uncertain judgments into software. A binary or categorical prediction can be read directly from a classifier instead of generated as a string. GLiClass supports lightweight classification with flexible label descriptions and also studies reinforcement learning for classification \citep{stepanov2025gliclassgeneralistlightweightmodel}. This line of work establishes that direct probabilistic outputs and small models are not sufficient novelty by themselves. Our model uses a conventional open backbone and classification heads. Its research target is the supervision supplied by executed repair actions, rather than the output schema or the removal of JSON generation.

\paragraph{Trajectory monitoring and agent control.}
Fail-Fast, Restart-Smart trains a small monitor on observable software-agent prefixes and execution-derived supervision, then combines termination with an edit-preserving restart \citep{wang2026failfastrestartsmartearlyfailure}. This is a close comparator for any small-model recovery controller. Our first setting places a single decision after a candidate patch has been produced and evaluates a fixed menu of interventions. It distinguishes a continuation that retains the candidate and history from a restart that returns to the original repository. \citet{vasudev2026accuratefailurepredictionagents} directly distinguish accurate failure prediction from useful intervention through disruption and recovery effects. Our empirical question is whether action-conditioned outcomes provide information beyond a current-correctness predictor and a recovery rule.

\paragraph{Cost-sensitive verification.}
Bayesian Control formulates coding-agent orchestration as a sequential hypothesis-testing problem, maintaining a belief over correctness and choosing among critics, refinement, verification, and stopping \citep{papamarkou2026bayesiancontrolcodingagents}. It already provides a decision-theoretic account of costly verification and includes repository-level tasks. We build on that motivation. The distinguishing candidate contribution is a learned mapping from the concrete state and available diagnostic to the outcome of a bounded repair intervention. An empirical transition-kernel baseline tests whether a global model of repair and breakage is sufficient. That baseline is identified as a one-step adaptation, rather than a reproduction of the original dynamic program.

\paragraph{Patch reward models and learned feedback.}
SWE-RM studies execution-free feedback and separates ranking performance from classification accuracy and calibration \citep{shum2025swermexecutionfreefeedbacksoftware}. The distinction matters here: a model that ranks patches well does not automatically identify which action to take on a particular patch. ExecCritic separates test construction from repair, qualifies generated tests, and trains the two roles independently \citep{tao2026execcriticlearntesttest}. Our first experiment fixes the repair model and selects from existing public tests; it does not train a test generator. Both approaches require careful treatment of test validity, because an apparently informative failure can point the agent toward an incorrect behavioral target.

\paragraph{Test selection and evidence validity.}
Predictive Test Selection learns which tests are likely to expose regressions from historical changes and execution outcomes \citep{machalica2019predictivetestselection}. That objective differs from predicting how useful a test's feedback will be to a subsequent repair model. A failure-probability selector would test the narrower hypothesis that feedback value is explained entirely by failure detection. The first matched comparison instead isolates action-outcome supervision against current correctness; a direct failure-discovery comparator requires additional public-test labels and is reserved for the extended study. Work on state-bound evidence further shows why test results must refer to the exact program state on which they were obtained, and why continued revision can destroy a correct solution \citep{gao2026loopingreliabilitystateboundevidence}. We adopt exact-state restoration and fresh execution environments as experimental requirements. Their role is to support a valid comparison, not to serve as a separate architectural contribution.