This post is a Chinese-language deep dive into Anthropic's engineering work on harness engineering—the scaffolding that lets Claude agents work autonomously for hours instead of collapsing after one context window. Below is a structured English summary preserving the key findings, figures, and references.
The Problem: Long-Running Agents Break Down
A solo Claude agent given "build a clone of claude.ai" ran 20 minutes, cost $9, and produced broken core functionality. The same task run by a three-agent harness took 6 hours and $200, yielding a fully functional 2D game maker with AI-assisted generation, playable test mode, and shareable links.
Anthropic identified two failure modes when Opus 4.5 looped in the Claude Agent SDK with only a high-level prompt:
- Biting off more than it can chew: the agent tries to build everything at once, runs out of context mid-feature, and the next session inherits an undocumented half-finished mess.
- Premature victory declaration: later sessions see existing progress and declare the task complete while core features are missing.
init.sh— one-command dev server startupfeature_list.json— the user prompt expanded into 200+ concrete feature entries, all markedpasses: falseclaude-progress.txt— per-round progress log- Initial git commit as project anchor
- Design quality — cohesive visual identity, not assembled parts
- Originality — evidence of deliberate creative choices; unmodified stock components and purple-gradient "AI slop" count as failure
- Craft — typographic hierarchy, spacing consistency, contrast; a competence check
- Functionality — can a user accomplish the task without guessing?
- Planner: expands a one-line prompt into a full spec (e.g., "Create a 2D retro game maker" → 16 features, 10 sprints). Deliberately told not to specify implementation details so errors don't cascade.
- Generator: works sprint by sprint (React + Vite + FastAPI + SQLite), self-assesses, then hands off to QA.
- Evaluator: uses Playwright MCP against the running app, scores on the rubric with hard thresholds, and rejects sprints with concrete feedback.
- Planner: 4.7 min, $0.46
- Generator Round 1: 2h 7min, $71.08 → QA Round 1: 8.8 min, $3.24
- Generator Round 2: 1h 2min, $36.89 → QA Round 2: 6.8 min, $3.09
- Generator Round 3: 10.9 min, $5.88 → QA Round 3: 9.6 min, $4.06
- Total: 3h 50min, $124.70
- State transfer: structured files, not conversation summaries
- Task decomposition: feature lists and sprint contracts
- Quality control: an independent Evaluator with hard scoring criteria
- Environment reproduction: init.sh, git log, progress files, regression tests
- Effective harnesses for long-running agents: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
- Harness design for long-running application development: https://www.anthropic.com/engineering/harness-design-long-running-apps
- Building Effective Agents: https://www.anthropic.com/engineering/building-effective-agents
- Context engineering: https://www.anthropic.com/engineering/context-engineering
- Claude Agent SDK Quickstart: https://github.com/anthropics/anthropic-cookbook/tree/main/skills/agent-sdk
Both stem from the same root cause: no mechanism for understanding "current state" and "remaining work." Every restart is amnesia.
First-Generation Harness: Initializer + Coding Agent
From Justin Young's Anthropic engineering post:
Initializer Agent (first session, no feature work):
Key insight: lock the feature list on day one. JSON is deliberately chosen over Markdown because Claude has stronger "editing impulses" on Markdown—it rewrites and deletes sections; JSON's rigidity plus a system-prompt rule like "deleting or editing tests is unacceptable" holds better.
Coding Agent (every subsequent session) does exactly three things:
1. Read state: pwd → git log → claude-progress.txt → feature_list.json → init.sh
2. Pick the first feature with passes: false
3. Implement it, test, git commit, update the log, mark passes: true
Each session must end in a clean state—code ready to merge to main.
Testing fix: Anthropic attached Puppeteer MCP so the agent clicks, types, and screenshots like a real user. Limitation: Claude cannot see native browser alert modals, so features depending on them have higher bug rates.
Second-Generation Harness: Planner + Generator + Evaluator
Prithvi Rajasekaran's work, inspired by GANs, targets quality rather than session continuity. Core insight: generators don't criticize themselves—they rate mediocre work favorably, especially on subjective tasks. Separating maker and judge is the lever.
Four-dimension scoring rubric (from front-end design experiments):
Design quality and Originality are weighted highest; Craft and Functionality need less pushing because Claude is already strong there.
Division of labor:
Sprint Contract: Generator and Evaluator agree before coding on what will be built and how completion is verified—Sprint 3's level editor alone had 27 acceptance criteria.
The Brutal Cost/Quality Comparison
Same prompt: "Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode."
| Dimension | Solo Agent | Full Harness | |---|---|---| | Duration | 20 min | 6 hours | | Cost | $9 | $200 | | Core functionality | broken | working | | Features | basic editor | + AI-assisted generation, sound/music, shareable links | | UI quality | wasted layouts, rigid workflow | full-screen canvas, coherent visual identity |
The harness even produced things the Generator wouldn't have thought of on its own—AI-assisted sprite generation, level design, sound effects—because the Planner was told to "weave AI features into the spec."
Model Evolution Changes the Harness
Opus 4.5 exhibits context anxiety—it wraps up early near its perceived context limit—so the first harness required full context resets instead of compaction. Opus 4.6 plans more carefully and sustains agentic tasks longer; when Rajasekaran deleted the entire sprint structure and ran the Generator for two continuous hours, it succeeded. A once load-bearing component became unnecessary.
The Evaluator stayed. Within the model's capability boundary it's overhead; outside it, it's essential. Anthropic's conclusion: with every new model release, re-audit the harness—delete components that are no longer load-bearing, add capabilities newly within reach.
Case Study: Browser-Based DAW
Prompt: "Build a fully featured DAW in the browser using the Web Audio API."
QA caught what the Generator missed: Round 1 found clips couldn't be dragged on the timeline, no instrument UI panels (synth knobs, drum pads), no visual effect editors (EQ curves, compressor displays)—"these aren't edge cases, they're core DAW interactions." Round 2 found audio recording was still a stub and edge-drag clip resizing was unimplemented. The final DAW isn't professional grade but has a working arrangement view, mixer, transport, and can autonomously compose with tempo, key, melody, drums, and reverb.
What Harness Engineering Really Is
It is not better prompt engineering. Prompt engineering optimizes a single conversation; harness engineering optimizes continuity across conversations—an engineering problem, not a language problem:
Practical Takeaways for Developers
1. First session builds only foundations—no features. 2. Use JSON for feature lists, not Markdown. 3. One task per session: implement, test, commit, log, then continue. 4. Give agents real-user testing tools (Puppeteer/Playwright MCP); unit tests aren't enough. 5. Separate Generator and Evaluator for subjective quality requirements. 6. Re-audit the harness after every model upgrade.
Closing Thought
As models get stronger, the harness doesn't disappear—the combination space expands. Harnesses shift from "helping models do what they can't" to "helping models catch what they didn't notice they missed." Six hours, $200, three agents: not waste, but a paradigm shift from chatbot to engineering team.