Reliable Before Profitable: QuantHarness for Governing Financial Strategy Development with LLM Agents
Organizations: ShanghaiTech University, Shanghai, China
Abstract
LLM agents can turn natural-language financial research requests into executable and backtested strategies, but a successful run may still implement the wrong rule, use information unavailable at decision time, or obscure how repairs and candidate selection changed the strategy. Because these failures arise throughout development, final code and performance metrics alone are insufficient to establish either fidelity to the request or the validity of the development process. We therefore address the reliability of financial strategy development at the trajectory level: the system must control how intermediate outputs become downstream state and preserve the evidence needed to justify the terminal outcome. We introduce QuantHarness, a two-layer agent harness in which a finance-specific Workflow structures specification, data grounding, construction, testing, and review, while Harness Core enforces stage-specific information, action, and commitment boundaries. We also introduce FinRelBench, a benchmark that evaluates strategy-development reliability through execution success, requirement satisfaction, and runtime evidence. QuantHarness achieves the highest Task Success at 90.72%, compared with 74.23%--84.54% for the comparison systems. Controlled stress tests show that its boundaries contain targeted violations, while structured run records improve evidence retrieval and support decision replay under the evaluated protocol.
Figures & tables
| Main measure | Mechanical diagnostics | Requirement diagnostics | |||||
|---|---|---|---|---|---|---|---|
| System | Task Success | Data Pipeline Success | Strategy Run Success | Data Requirement Satisfaction | Data Runtime- Evidence Coverage | Strategy Requirement Satisfaction | Strategy Runtime- Evidence Coverage |
| QuantHarness | 90.72% | 100.00% | 98.97% | 98.97% | 98.28% | 98.71% | 96.07% |
| Codex CLI | 81.44% | 96.91% | 91.75% | 97.59% | 96.56% | 97.50% | 91.11% |
| OpenHands | 74.23% | 86.60% | 84.54% | 84.54% | 84.54% | 85.38% | 81.40% |
| SWE-agent | 84.54% | 94.85% | 93.81% | 94.85% | 94.50% | 94.44% | 92.85% |
| Aider | 79.38% | 98.97% | 94.85% | 96.91% | 99.31% | 99.09% | 92.64% |
| A. Normal runs | |||
|---|---|---|---|
| Boundary | Successful outcome | On | Off |
| Information | Initial implementation succeeds | 25/30 | 23/30 |
| Action | Workflow completes correctly | 30/30 | 23/30 |
| B. Controlled stress tests | |||
| Boundary | Observed failure | On | Off |
| Information | Invalid information used | 0/30 | 11/30 |
| Evidence view | Exact evidence | Replay |
|---|---|---|
| Organized artifacts | 100.0% | 44/44 |
| Same artifacts, unorganized | 43.2% | 0/44 |
| Final artifacts only | 27.6% | 0/44 |
Appendix figures & tables15 assets
Supplementary material from the paper’s appendix.
Appendix
| Origin | Daily scores | Intraday orders | Total |
|---|---|---|---|
| Original reliability-oriented tasks | 14 | 3 | 17 |
| Adapted QuantCode-Bench tasks | 50 | 30 | 80 |
| Total | 64 | 33 | 97 |
| System | Output type | Task origin | ||
|---|---|---|---|---|
| Daily scores | Intraday orders | Original | Adapted | |
| QuantHarness | 60/64 | 28/33 | 14/17 | 74/80 |
| Codex CLI | 54/64 | 25/33 | 12/17 | 67/80 |
| OpenHands | 49/64 | 23/33 | 12/17 | 60/80 |
| SWE-agent | 56/64 | 26/33 | 14/17 | 68/80 |
| Aider | 52/64 | 25/33 | 14/17 | 63/80 |
| Generation/ data pipeline | Strategy execution | Unmet/unverifiable requirements | Runtime evidence only | Evaluation incomplete | |
| QuantHarness | 0 | 1 | 1 | 6 | 1 |
| Codex CLI | 3 | 5 | 5 | 5 | 0 |
| OpenHands | 13 | 1 | 4 | 5 | 2 |
| SWE-agent | 5 | 1 | 5 | 4 | 0 |
| Aider | 1 | 4 | 10 | 5 | 0 |
| System | Complete panels | Exact agreement | Any arbitration | Cross-wording |
|---|---|---|---|---|
| QuantHarness | 96 | 98.2% | 25/96 | 8/96 |
| Codex CLI | 95 | 97.5% | 30/95 | 12/95 |
| OpenHands | 83 | 98.3% | 20/83 | 9/83 |
| SWE-agent | 92 | 99.4% | 17/92 | 7/92 |
| Aider | 97 | 98.1% | 33/97 | 15/97 |
| Boundary | Endpoint | Full | Off |
|---|---|---|---|
| Information | Initial mechanical execution | 29/30 | 30/30 |
| Public-obligation conformity | 26/30 | 23/30 | |
| Initial implementation success | 25/30 | 23/30 | |
| Terminal completion | 30/30 | 30/30 | |
| Action | Admissible Workflow completion | 30/30 | 23/30 |
| Observed unauthorized behavior | 0/30 | 0/30 |
| Boundary | Starting condition and intervention | Evidence and denominator |
|---|---|---|
| Information | A revision handoff contains accepted, superseded, and rejected decisions. Full receives the currently accepted version; Off receives the raw versions and governance events without an explicit current-version answer. | Execution evidence must show use of an obsolete or rejected value. Invalid information is used in 0/30 Full and 11/30 Off cases. |
| Action | A provisional binding passes mechanical checks but substantive review and approval are pending. Building early uses a temporary opportunity for parallel work; waiting costs one synthetic scheduling cycle and remains feasible. | The agent chooses early construction in 22/30 cases. The same request is replayed against both guards: 0/22 Full and 22/22 Off requests produce unauthorized persistent files. |
| Commitment | After a real Judge approval, the candidate implementation is replaced in 14 prespecified cases; 16 cases retain the approved candidate. Off removes the targeted identity enforcement. | Compare the hashes of the approved source, the source presented for freezing, and the frozen source. Full blocks freezing of all 14 modified candidates, whereas Off freezes them; all 16 unchanged controls commit in both conditions. |
| View | Exact audit evidence | Acceptance packet | Commitment packet | Acceptance executed | Commitment executed | Verified replay |
|---|---|---|---|---|---|---|
| Organized | 100.0% | 44/44 | 44/44 | 44/44 | 44/44 | 44/44 |
| Flat | 43.2% | 0/44 | 6/44 | 0/44 | 6/44 | 0/44 |
| Final only | 27.6% | 0/44 | 0/44 | 0/44 | 0/44 | 0/44 |
| Phase | Dates | Universe | Use |
|---|---|---|---|
| Training | 2025-01-02–2025-08-29 | CSI 500 (2024-12-31) | Fitting/construction |
| Optimization | 2025-09-01–2025-12-31 | CSI 500 (2025-08-29) | Candidate selection |
| Final | 2026-01-05–2026-05-29 | CSI 500 (2025-12-31) | One-time reporting |
| System | Completed tasks | Mean ann. return | Mean Sharpe | Mean max drawdown | Mean turnover |
|---|---|---|---|---|---|
| QuantHarness | 10/10 | 33.06 | |||
| Codex CLI | 10/10 | 51.63 | |||
| OpenHands | 10/10 | 59.75 | |||
| SWE-agent | 9/10 | 59.90 | |||
| Aider | 9/10 | 62.26 | |||
| RD-Agent(Q) | 10/10 | 57.31 |
| System | Completed tasks | Positive returns | Mean total return | Mean Sharpe | Mean max drawdown | Mean generalization gap (pp) |
|---|---|---|---|---|---|---|
| A. ModelBench-5: specified model families | ||||||
| QuantHarness | 5/5 | 3/5 | ||||
| Codex CLI | 5/5 | 2/5 | ||||
| OpenHands | 5/5 | 2/5 | ||||
| SWE-agent | 3/5 | 0/3 | ||||
| Aider | 0/5 | – | – | – | – | – |
| System | Completed tasks |
|---|---|
| QuantHarness | 2/2 |
| Codex CLI | 0/2 |
| OpenHands | 1/2 |
| SWE-agent | 1/2 |
| Aider | 0/2 |
| Total (system–task runs) | 4/10 |
| Stage | Stage inputs and permitted actions | Required evidence and authority |
|---|---|---|
| Task understanding | Public request and operating mode; structured extraction of intent, missing fields, conflicts, and assumptions; no strategy-code generation. | Task contract. Intake policy determines whether the task is ready to proceed or needs clarification; the runtime checks the associated state transition. |
| Planning and data grounding | Public task and stage-specific Runtime Card. Catalog listing and asset inspection precede binding; only authorized data tools are exposed. | Specification, planning blueprint, data binding, and field contract. Deterministic catalog/schema checks verify the proposed sources and fields. |
| Construction | Accepted specification, bound fields, implementation plan, and required output interface. Code generation uses the established data binding rather than choosing new data sources. | Candidate source and implementation metadata; model paths additionally produce training/inference artifacts. Stages pass candidates to checks, not directly to acceptance. |
| Validation and backtest | Deterministic services validate and backtest the candidate under the configured data and execution protocol; they do not redesign the strategy. | Validation checks, execution outputs, and backtest reports. Failed checks block normal progression; recovery requires authorization. |
| Recovery | Public failure feedback and the current candidate, with stage-limited repair/replan/rebind authority and bounded attempts. | Proposed change, guard result, revised candidate, and renewed checks. Recovery cannot silently weaken the task to make execution pass. |
| Judge and commitment | Judge reads a compact evidence bundle and recommends acceptance, recovery, or stopping; it does not execute its own recommendation. | Judge report, policy/guard decision, and approved candidate identity. The guarded runtime authorizes transitions. Before saving the frozen artifact, the freezer checks required evidence and, when seal enforcement is enabled, verifies that the files match their approved versions. |
| System | Implementation / release | Native limit within the process cap |
|---|---|---|
| QuantHarness | Native Workflow | 20 turns; one repair allowance |
| Codex CLI | exec 0.144.1 | No comparable turn cap exposed |
| OpenHands | agent-server 1.8.0 ( de4e2eb ) | 80 native iterations |
| SWE-agent | runner 1.1.0 ( abd7d69 ) | 2.00 per-instance cost limit |
| Aider | CLI 0.86.3.dev53 ( 5dc9490 ) | No comparable turn cap exposed |
| Operation | Daily-score task | Intraday-order task |
| Whole generation process | 1,200 | 2,400 |
| Individual model request | 300 | 600 |
| Agent stage, including request retry | 660 | 1,260 |
| Data-binding stage | 660 | 1,260 |
| Independent dataset construction | 300 | 600 |
| Independent strategy execution | 150 | 300 |
LLM Agent Harnesses
LLM agent harnesses are the software and runtime systems that organize an agent’s tools, context, state, execution, and safeguards.
See all 357 papers