# Build self-improving agent system with Fable 5 in 14 steps : loops, dynamic workflows, routines
**作者**: Codez
**日期**: 2026-05-28T17:42:45.000Z
**来源**: [https://x.com/0xCodez/status/2065089060104720776](https://x.com/0xCodez/status/2065089060104720776)
---
Most people are using Claude Fable 5 like Sonnet 4.6 with a bigger context window. They prompt it. It works for 5 minutes. They close the tab.
9 out of 10 users have never run an agent system that compounds - where every run leaves the next run smarter, every state file accumulates, every skill sharpens.
Fable 5 was built to run for days. You’re using it for minutes. This is the 14-step roadmap to build the self-improving system Fable 5 was designed for.
> Follow my Substack to get fresh AI alpha: movez.substack.com
Claude Fable 5 launched June 9, 2026 - the first publicly available Mythos-class model, the tier Anthropic put one rung above Opus.
This is the 14-step roadmap to build the self-improving system Fable 5 was designed for - sourced from Anthropic engineering posts, the team’s public experiments, and verified against the launch documentation as of June 2026.
Three tiers: what Fable 5 actually unlocks, the three primitives that make it compound (loops, dynamic workflows, routines), and the self-improvement layer that turns it into a system.
14 steps. 3 tiers. Stop prompting. Start building a system that compounds.
PART 1 · What Fable 5 actually unlocks
## 01. Fable 5 is a Mythos-class model. Days-long autonomy is the headline.
Claude Fable 5 launched June 9, 2026 as the first publicly available Mythos-class model - the tier Anthropic introduced one rung above Opus.
Mythos Preview shipped in April through Project Glasswing to a handful of critical-infrastructure partners; Fable 5 is the version Anthropic considered safe for general release, with built-in safety classifiers that decline requests in high-risk areas.
Mythos 5 (without those classifiers) remains Glasswing-only.
What Fable 5 actually does that previous Claude models couldn’t sustain, from Anthropic’s launch documentation:
- Days-long autonomous sessions. Run inside an agent harness like Claude Code or Claude Managed Agents (CMA), Fable 5 can work for days - planning across stages, delegating to sub-agents, and checking its own work.
- Self-verification built in. Writes its own tests to check its work. Uses vision to check outputs against goals. Distills lessons into general rules. Tests its own assumptions.
- Most ambitious code work. Large migrations, complex implementations, multi-day autonomous coding sessions. The headline use case Anthropic puts forward is “hand off large projects and review completed deliverables.”
- Multi-stage knowledge work. Deep research and analysis to deliverables ready for review - with minimal oversight.
The pricing matches the tier: $10 per million input tokens, $50 per million output tokens, with the existing 90% input token discount for prompt caching.
Available on Claude API, AWS, Amazon Bedrock, Vertex AI, Microsoft Foundry, and the consumption-based Enterprise plan. This is not a subscription model. Heavy use earns its own bill.
## 02. Self-improving is not self-learning.
The phrase “self-improving agent system” gets thrown around carelessly. The version that’s real and the version that’s hype are very different things, and the gap is worth understanding before you build anything.
- Self-learning - the agent updates its own weights based on what it learns. Fable 5 does not do this. No publicly available model does this in production.
Recursive self-improvement (RSI) is the long-term direction Anthropic itself warned about in May 2026, not the capability shipping today.
- Self-improving - the system around the agent compounds. Each session writes lessons to memory. Skills sharpen as edge cases get added.
State files accumulate verified facts. Eval loops refine prompts and rubrics. The model stays the same; the environment it runs in gets sharper.
Self-improvement, in this sense, is a property of the system you build. Fable 5 has the raw capability - long context, sub-agent delegation, vision self-check, days-long stamina - that turns the environment-feedback loop into something that actually compounds run over run.
> Anthropic’s engineering team puts it directly:
“Rather than directly prompting and steering Fable 5, it’s often better to design loops that let the model self-correct in response to environment feedback (e.g., /goal or Outcomes) and manage its own context (e.g., via memory).”
## 03. The compound stack: four layers, one feedback loop.
Figure 1 at the top of this article shows the architecture in one diagram. Read it from the bottom up - that’s the order the system gets built, and the order the leverage compounds.
- Layer 1 · Primitives. Fable 5 itself, sub-agents, worktrees, the tools the agent reaches for. Raw capability with no system around it yet. This is what most people use today.
- Layer 2 · Orchestration. /goal and Outcomes for self-correcting loops. Dynamic Workflows for complex multi-step orchestration. Routines for laptop-off cloud runs. This is what turns the primitives into a workflow.
- Layer 3 · Memory. State files, Skills, Knowledge Bases, lessons written down. Memory is what makes tomorrow’s session resume instead of restart.
- Layer 4 · Self-improvement. Vision self-checks, eval loops, rule distillation. The agent grades its own output, refines the Skill that produced it, writes the lesson back to memory. The loop closes.
The reason this architecture compounds: every output from layer 1 flows up through layer 4, where it gets graded, distilled, and written back to layer 3. Tomorrow’s run at layer 1 inherits the sharpened memory and refined Skills from yesterday. The model is stateless; the system around it isn’t.
## 04. When to use Fable 5 vs Opus 4.8 vs Sonnet 4.6. The cost-capability matrix.
Fable 5 costs ~5× what Opus 4.8 does per token. Not every step in a self-improving system needs the top tier. The teams running this in production route by task complexity, not by default:
- Fable 5 for the heavy-lift orchestrator role: planning across days, delegating to sub-agents, checking work with vision, distilling rules from accumulated evidence.
Use Fable 5 where the “days at a time” capability earns its pricing.
- Opus 4.8 for hard-but-bounded subtasks the orchestrator delegates: architecture decisions, complex debugging, deep code reviews. Also the explicit fallback for any request Fable 5’s classifiers block (cyber, bio, chem, distillation).
- Sonnet 4.6 for high-volume worker tasks: lint passes, simple refactors, test scaffolding, doc updates. The bulk of fan-out work runs here.
- Haiku 4.5 for grader sub-agents and cheap classifiers. Independent context window, low cost - ideal for the verifier role Anthropic explicitly recommends.
The cost pattern that makes a self-improving system economical, used by teams running this in production: orchestrator on Fable 5, workers on Sonnet 4.6, graders on Haiku 4.5, fallback to Opus 4.8 on classifier blocks. Same pattern Anthropic engineers use internally.
PART 2 · The three Primitives
## 05. /goal vs Outcomes. Two implementations of the same idea.
The Anthropic Claude Code team publishes two near-identical primitives for goal-driven loops one in each harness.
They share the same shape: an independent grader checks the work, a not-met verdict starts the next iteration, the loop exits when the grader passes.
The implementations differ in surface details that matter for which you use.
The decision rule between them is short:
- Use /goal in Claude Code when the work happens at your machine and you want a quick, in-session loop with a measurable end state. Best for hands-on coding, debugging flaky tests, refining a single file. Plain text goal, model grader, in-terminal feedback.
- Use Outcomes in CMA when the work needs to run for hours or days on Anthropic-hosted infrastructure with a sandbox, GPUs, or a controlled environment. Best for ML training, long-running migrations, multi-day research. File-based rubric with gradable criteria, sub-agent grader, hard max_iterations bound.
Both share the structural move that makes them work: the agent that wrote the code is not the agent that grades it. We go deeper on why that matters in step 6.
## 06. Verifier sub-agent beats self-critique.
Anthropic engineer Prithvi Rajasekaran wrote a piece on the engineering blog showing models have a hard time self-critiquing their own outputs. The Claude Code team confirmed this empirically with Fable 5:
> “We’ve found that a verifier sub-agent tends to outperform self-critique with Fable 5"
The mechanism is structural, not about “trying harder.” A model evaluating its own output sees its own reasoning trail and prefers conclusions consistent with what it already wrote.
A separate model evaluating the same output sees only the artifact and the rubric. The verifier has no skin in the maker’s game.
What the chart actually shows, beyond the headline numbers:
- Fable 5 made larger structural changes - TRAIN_SEQ_LEN=2048 train+eval (−0.0179), overlapped sliding-window eval (−0.0207), int6 QAT + int6 expo (−0.0163). Each is an architecture-level move, not a constant tweak.
- Fable 5 pushed through a quantization regression to its biggest win - instead of reverting after a failed experiment, it continued investigating.
- Opus 4.7’s first experiment (QK_GAIN_INIT=5.0) produced a small win. Nearly everything that followed used the same template: adjust a scalar, measure, keep if positive. The shape is safer, not better.
The takeaway for system design: Fable 5 with an independent verifier explores larger hypothesis spaces and recovers from negative intermediate results. Without the verifier, the same model has nothing forcing it past the first “good enough.”
## 07. Dynamic Workflows compose self-correction patterns.
Dynamic Workflows shipped in Claude Code on May 28, 2026.
The idea: Claude writes its own JavaScript harness on the fly - a file with agent(), parallel(), and pipeline() primitives, plus standard JS to process the data flowing between them. The harness is custom-built for the task, not generic.
> **cat@_catwu**: [原文链接](https://x.com/_catwu/status/2060054180379689074)
>
> Excited to share our most powerful new Claude Code feature: dynamic workflows!
> Mention "workflow" in a prompt and Claude will dynamically create an orchestration plan that it strictly follows, allowing you to confidently trust that every stage happens in the right order even
>
> 
For self-improving systems with Fable 5, three of the six documented Dynamic Workflow patterns earn their place:
- Fan-out-and-synthesize. Split the work into N independent pieces, run an agent on each in parallel, synthesize results. Best when each step benefits from its own clean context window - e.g., evaluating each rule in a Skill against historical examples.
- Adversarial verification. For each maker agent, spawn an independent verifier with no exposure to the maker’s reasoning. The structural fix for self-preferential bias from step 6, applied per task.
- Loop until done. Loop spawning agents until a stop condition is met -no new findings, no more errors in the logs, theory verified. Pair with /goal to set a hard completion requirement.
The two patterns that don’t typically appear in self-improving systems but are worth knowing: classify-and-act (route the task to the right model based on a classifier) and tournament (pairwise comparison for taste-based ranking). The first is useful for model routing (step 4).
The second is rare in coding loops but useful for design or naming tasks.
## 08. Worktrees for parallel safety. Days-long Fable 5 sessions, no file collisions.
The moment a self-improving system spawns more than one agent, files start colliding. Two agents writing the same file is the same problem as two engineers committing to the same lines without talking first.
A git worktree fixes it - a separate working directory on its own branch sharing the same repo history, so one agent’s edits literally cannot touch the other’s checkout.
For self-improving systems where Fable 5 spawns sub-agents to verify or specialize, worktrees are non-optional:
- Maker writes in worktree A. Verifier reads in worktree B (or runs against the worktree A checkout with read-only filesystem). No risk the verifier’s exploration touches the maker’s state.
- Parallel structural experiments. If Fable 5 explores multiple architecture changes (like in Parameter Golf), each experiment runs in its own worktree. The orchestrator collects results from all of them; the best one merges.
- Days-long runs with checkpoints. Each major phase can be a separate worktree. A failed phase doesn’t poison the rest.
In Claude Code, worktrees are exposed three ways: git worktree directly, a --worktree flag to open a session in its own checkout, and an isolation: worktree setting on subagents so each helper gets a fresh checkout that cleans itself up after the session ends.
## 09. Routines for days-long orchestration. Laptop closed. Fable 5 working.
Routines launched April 14, 2026 in research preview. They’re saved Claude Code configurations - a prompt, repositories, connectors, permissions - that run on Anthropic-managed cloud infrastructure on a trigger.
Your laptop can be off. The run still happens.
For Fable 5 specifically, Routines are the trigger layer that earns the model’s capability. Anthropic measures Fable 5’s “days at a time” on Claude Managed Agents - a hosted sandbox with full tools and no local machine constraint.
The Parameter Golf experiment ran for up to 8 hours on 8×H100 GPUs. That class of run doesn’t happen on your laptop.
The three Routine trigger types, mapped to self-improvement patterns:
- Schedule triggers - the morning briefing pattern. Daily at 7am: re-run yesterday’s eval suite, distill any new failure modes into Skills, write the digest to Slack. The agent gets sharper while you sleep.
- API triggers - the “fire on event” pattern. CI fails → fire a Routine to investigate. Sentry alert → fire a Routine to triage. The self-improving system reacts to your real environment, not a fixed schedule.
- GitHub event triggers - the “learn from real work” pattern. On PR open, run an evaluation against the latest Skills. On merge, write any new patterns the PR introduced back to the Skill. Repository state and Skill state stay in sync.
```
> /schedule daily at 7am, use Fable 5 in CMA
Goal: Re-run yesterday’s eval suite against the latest skills.
Any test that newly passes → distill the pattern into the skill.
Any test that newly fails → investigate, document in STATE.md.
Post the digest to #engineering. /goal don’t stop until digest is
posted and STATE.md is updated.
▲ Claude
Creating routine: nightly-eval-compounding
- model: claude-fable-5
- harness: claude managed agent (sandbox)
- trigger: schedule (0 7 * * *)
- grader: independent Haiku sub-agent (Outcomes)
✓ Active. First run tomorrow 07:00 local. Skill set will compound.
```
PART 3 · The Self-Improvement Layer
## 10. The 5-stage memory progression.
The single most useful framing for what “agent memory” means in practice comes from the Anthropic team’s Continual Learning Bench 1.0 experiment. Effective use of memory requires a progression of five stages. Each stage is a structural move; each model exits the progression at a different point.
- 1. Fail - the agent gets something wrong and documents the failure with enough detail to be useful later.
- 2. Investigate — before moving on, the agent figures out why the failure happened.
- 3. Verify - the agent turns the diagnosis into a checked fact, not a guess.
- 4. Distill - the agent turns the verification into a general rule that applies beyond the specific case.
- 5. Consult - on the next task, the agent reads the rule instead of re-deriving the fact from scratch.
The measured difference between models on a SQL exploration task from the Continual Learning Bench, each model with memory provided:
- Sonnet 4.6 exits at step 1. Its memory store is a list of failure notes and open guesses (“maybe prc instead of prc_usd?”). It rarely consults prior notes. Memory exists but doesn’t compound.
- Opus 4.7 exits at step 3. It creates a schema reference with uncertainty flagged (“possibly prc in cents? Verify.”). Verification coverage runs 7–33% (median ~17%) of questions.
- Fable 5 tends to complete the progression. In its strongest runs, verification coverage reaches 73% (22 of 30), and it distills learnings into general rules that help with future tasks.
## 11. The state file. Where memory actually lives.
The 5-stage progression is the mental model. The state file is where the model writes each stage’s output. For Fable 5 running in Claude Managed Agents, memory is a mounted filesystem that survives between sessions; in Claude Code locally, a markdown file or a Linear board does the same job.
The structure of a state file that actually supports the 5-stage progression:
```
# Project memory · trading-platform
## Verified facts # stage 3 — stop guessing about these
- prc is in dollars, not cents. Verified via SELECT MIN(prc), MAX(prc) FROM trades.
- user_id matches auth_users.uid via JOIN, not auth_users.id. Confirmed 2026-06-09.
- Test database uses Stripe sandbox keys; production uses real keys via env.
## General rules # stage 4 — consult before re-deriving
- When querying time-bucketed metrics, always include timezone (default UTC mismatches).
- Auth middleware order matters: rate_limit -> jwt -> rbac. Reversing causes 401s.
- For migrations, never use ALTER on tables >1M rows without batching.
## Open failures (investigate next session) # stage 1 → 2
- 2026-06-09: tests/e2e/checkout flakes ~1 in 50 runs. Hypothesis: webhook race.
Reproduction steps in debug/checkout-flake.md.
## Lessons learned # stage 4 distillations
- PowerShell hits TLS 1.2 issue on Windows CI runners. Always shell out to bash.
- Stripe webhook tests require STRIPE_WEBHOOK_SECRET. Skip with clear message if missing.
## Last session # stage 5 — resume, don’t restart
2026-06-10 03:30 UTC · 7 failures classified, 3 fixes drafted (claude/fix-*), 4 escalated.
Next: verify the auth middleware fix in claude/fix-rate-limit-order against production load.
```
The file has five sections matching the five stages. Verified facts is stage 3 output - things the agent stopped guessing about. General rules is stage 4 - distilled rules that apply beyond the specific case. Open failures is stages 1–2 work in progress. Lessons learned is more stage 4 output.
Last session is the resume pointer for stage 5.
Two operational rules that decide whether this file actually compounds or just grows:
- Write before walking away. Every Fable 5 session ends by updating STATE.md - what was tried, what passed, what failed, what new rules survived. If the session doesn’t finish with a write, the next one restarts from zero.
- Read at session start. Every new session begins by reading STATE.md and the most relevant Skills. The Continual Learning Bench data shows that without this, Sonnet-class memory behavior shows up even in Fable 5.
## 12. Skills that compound. Write the lesson into the Skill, not just the chat.
STATE.md is for project memory. Skills are for procedural memory - the “how to do this kind of thing” that should apply across projects.
The compounding pattern: after any non-trivial failure, write the lesson into the Skill itself. The Skill gets sharper every time the system runs.
A Skill that’s been compounding for two weeks looks different from a fresh one. New sections appear: known failure modes, rules that came out of post-mortems, anti-patterns observed in production.
The Skill is no longer a static set of instructions; it’s an accumulating record of what the team has actually learned.
```
---
name: ci-triage
description: Classify CI failures, draft fixes for easy ones, escalate the rest.
Trigger on workflow_run.failure or on the morning triage routine.
---
# CI triage skill
## Classification rules
- env: missing secret, wrong env var. # escalate to human, never auto-fix
- flake: passes on retry without code change. # retry once, then file
- bug: deterministic failure tied to recent commit. # draft fix
- dependency: tied to version bump. # draft rollback
- infra: timeout, OOM, runner issue. # escalate
## Known failure modes # added by the loop over 14 days
- webhook-race: e2e checkout flakes when Stripe webhook arrives mid-test.
Fix: add 2s settle delay in tests/utils/webhook.ts.
- tls-handshake: Windows runners fail TLS 1.2 in PowerShell. Use bash.
- db-migration: ALTER on trades table >1M rows times out at 30s. Batch in 10k chunks.
## Anti-patterns (do NOT do) # added after real incidents
- Never disable a failing test to make CI green. File it instead.
- Never modify .github/workflows/ without human approval.
- Never touch src/payments/ or src/billing/ without security review.
## State
Update STATE.md after each run with classifications, fixes drafted, escalations.
## Eval suite # step 13 — the loop verifies the skill
Run against eval/ci-triage-cases.jsonl weekly. Any newly-failing case →
add to known failure modes after Outcomes verifier confirms.
```
The compounding contract: every confirmed lesson goes into a Skill, not just STATE.md. STATE.md is project-scoped and dies with the project. Skills live in ~/.claude/skills/ and travel with you.
Two weeks of disciplined writing produces a Skill that materially outperforms whatever Fable 5 would derive from scratch on a fresh project.
## 13. Self-verification via vision. Fable 5 checks its own UI against the goal.
One of the headline capabilities Anthropic ships with Fable 5 is “uses vision to check outputs against goals.” This sounds abstract until you see what it actually replaces: the human eyeballing a screenshot to confirm the UI looks right.
Fable 5 does that step itself, in the loop, before declaring done.
The pattern in production:
- Maker sub-agent writes the UI code. Renders the result to a screenshot.
- Verifier sub-agent reads the screenshot with vision, compares it against the goal description, against design tokens in the project Skill, and against the previous screenshot from STATE.md.
- Verdict goes back to the loop. Match → mark task complete. Mismatch → describe the gap, hand back to maker with a structured diff.
This pattern is what Anthropic measured in the Parameter Golf experiment under the same harness: Fable 5 looked at training charts (visual artifact) and decided whether the curve matched the criterion.
No human in the loop reading the chart. The verifier read the chart.
## 14. The Mythos safety boundary. What Fable 5 won’t do, and how to design around it.
he last step is the one most easily skipped on day one and most expensive to learn the hard way.
Fable 5 ships with built-in safety classifiers that decline to respond in specific high-risk domains - cybersecurity vulnerability research, biology, chemistry, and model distillation. In those domains, Anthropic falls Fable 5 back to Claude Opus 4.8 automatically. This is documented; it’s not a bug.
What this means for a self-improving system that runs autonomously:
- If your system touches security tooling (SAST scans, exploit research, penetration testing logic, even some classes of code review), expect classifier blocks. Architect for the fallback: route those tasks to Opus 4.8 explicitly, or surface the block to a human reviewer.
- Same for biology, chemistry, and distillation domains. The classifier is broad. A scientific computing workflow might trigger it; a code review of crypto primitives might trigger it.
- Design your Skills to surface the fallback gracefully. A Skill should know which kinds of tasks it produces that may hit the classifier and document the expected behavior. A loop that silently fails on a classifier block looks identical to a loop that fails on a real error — until you debug it.
- Audit the system card. Fable 5’s 319-page system card documents the classifier’s scope. The launch generated controversy in mid-June 2026 because some downgrade behaviors were discovered buried in the document. Read it before deploying to production.
The general design principle: treat the safety boundary as a known fallback, not as a failure mode. A self-improving system that ships with explicit handling of the boundary stays robust as the classifier evolves. A system that ignores it produces silent regressions when Anthropic updates the policy.
## § The mistakes that keep Fable 5 at 10% of its potential
- Using Fable 5 like Sonnet 4.6 with more context. A 5-minute prompt-and-close session burns Mythos-tier pricing for no compound effect.
- Self-critique instead of an independent verifier. The maker grades its own homework. Anthropic measured the difference; the team explicitly documents the verifier sub-agent pattern.
- No STATE.md. Every session restarts from zero. The Continual Learning Bench data shows this is where 70%+ of Fable 5’s memory advantage disappears.
- Skills that never get written to. A static Skill is fine; a Skill that doesn’t accumulate lessons after real failures is wasted scaffolding.
- Fable 5 on tasks Sonnet 4.6 would handle. Doc updates, simple refactors, lint fixes. Route by complexity; reserve Fable 5 for the orchestrator role.
- Running long sessions on a laptop. Days-long capability requires cloud infrastructure (CMA or Routines). A closed laptop kills the session.
- Ignoring the Mythos safety boundary. Classifier blocks on cyber/bio/chem produce silent regressions. Architect for the fallback explicitly.
- No vision-verify on visual tasks. UI, dashboards, design fidelity — checking these with text-only verifiers misses the failure mode that matters.
- Skipping /goal or Outcomes. Without an objective stop condition checked by an independent grader, loops stop at “handled enough” instead of done.
- No retention policy review. Sensitive data through a Fable 5 routine without checking the 30-day / 2-year terms creates compliance issues silently.
## Conclusion:
Fable 5 isn’t a faster chat tool. It’s the substrate for a system that compounds.
The first publicly available Mythos-class model didn’t ship to be prompted faster. It shipped to be the orchestrator of a self-improving system you build around it.
The capability headlines - days-long sessions, sub-agent delegation, vision self-check, accumulated memory - only earn their pricing if the system around the model is doing its job.
The Anthropic team’s own experiments make the gap visible. Parameter Golf: Fable 5 with an independent verifier explored larger architectural changes and pushed through negative intermediate results to land ~6× more improvement than Opus 4.7.
Continual Learning Bench: Fable 5 with memory completed the full 5-stage progression with 73% verification coverage, against Opus 4.7’s 17%. The model is the same in both halves of every comparison. The system around it is what changed.
Pick one layer of the compound stack you weren’t doing - probably the verifier sub-agent (step 6), the state file (step 11), or vision-verify (step 13) - and add it tomorrow. Then the next.
Self-improvement is a property of the system, not the model. Build the system.
## 相关链接
- [Codez](https://x.com/0xCodez)
- [@0xCodez](https://x.com/0xCodez)
- [297K](https://x.com/0xCodez/status/2065089060104720776/analytics)
- [movez.substack.com](https://movez.substack.com/)
- [May 29](https://x.com/_catwu/status/2060054180379689074)
- [1.6M](https://x.com/_catwu/status/2060054180379689074/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:09 PM · Jun 11, 2026](https://x.com/0xCodez/status/2065089060104720776)
- [297.2K Views](https://x.com/0xCodez/status/2065089060104720776/analytics)
- [View quotes](https://x.com/0xCodez/status/2065089060104720776/quotes)
---
*导出时间: 2026/6/12 12:09:06*
---
## 中文翻译
# 使用 Fable 5 在 14 个步骤中构建自我改进的智能体系统：循环、动态工作流、例行程序
**作者**: Codez
**日期**: 2026-05-28T17:42:45.000Z
**来源**: [https://x.com/0xCodez/status/2065089060104720776](https://x.com/0xCodez/status/2065089060104720776)
---
大多数人把 Claude Fable 5 当作带更大上下文窗口的 Sonnet 4.6 来用。他们向它发送提示词。它工作 5 分钟。然后他们关闭标签页。
十个人里有九个从未运行过具有**复利效应**的智能体系统——在这种系统中，每次运行都会让下一次运行变得更聪明，每个状态文件都在积累，每一项技能都在精进。
Fable 5 是为连续运行数天而构建的。你却只用它几分钟。这就是构建 Fable 5 所设计的自我改进系统的 14 步路线图。
> 关注我的 Substack 以获取最新的 AI alpha：movez.substack.com
Claude Fable 5 于 2026 年 6 月 9 日发布——它是首个公开可用的“神话级”模型，是 Anthropic 设定的比 Opus 高一个档位的级别。
这是构建 Fable 5 所设计的自我改进系统的 14 步路线图——素材来源于 Anthropic 工程博文、团队公开实验，并根据截至 2026 年 6 月的发布文档进行了验证。
三个层级：Fable 5 真正解锁了什么，使其产生复利的三个原语（循环、动态工作流、例行程序），以及将其转化为系统的自我改进层。
14 个步骤。3 个层级。停止单纯的提示。开始构建一个能产生复利的系统。
**第一部分 · Fable 5 真正解锁了什么**
## 01. Fable 5 是神话级模型。数天的自主运行是核心亮点。
Claude Fable 5 于 2026 年 6 月 9 日发布，作为首个公开可用的神话级模型——这是 Anthropic 引入的比 Opus 高一个档位的级别。
神话预览版于 4 月通过“玻璃翼项目”交付给了少数关键基础设施合作伙伴；Fable 5 是 Anthropic 认为可以安全公开发布的版本，内置了安全分类器，拒绝高风险领域的请求。
神话 5（不带那些分类器）仍然是玻璃翼项目独享。
根据 Anthropic 的发布文档，Fable 5 真正做到而以前的 Claude 模型无法长期维持的功能如下：
- **持续数天的自主会话**。在像 Claude Code 或 Claude 托管智能体（CMA）这样的智能体框架内运行时，Fable 5 可以工作数天——跨阶段规划、分派给子智能体，并检查它自己的工作。
- **内置自我验证**。编写自己的测试来检查工作。使用视觉模型检查输出是否符合目标。将经验教训提炼为通用规则。测试自己的假设。
- **最野心勃勃的代码工作**。大型迁移、复杂实现、持续多天的自主编码会话。Anthropic 提出的核心用例是“移交大型项目并审查完成的交付物”。
- **多阶段知识工作**。从深度研究和分析到准备好可供审查的交付物——只需极少的人工监督。
定价与该级别匹配：输入每百万 Token 10 美元，输出每百万 Token 50 美元，现有的提示词缓存可享受 90% 的输入 Token 折扣。
现已在 Claude API、AWS、Amazon Bedrock、Vertex AI、Microsoft Foundry 以及按量付费的企业计划中提供。这不是订阅模式。重度使用会产生独立的账单。
## 02. 自我改进不等于自我学习。
“自我改进智能体系统”这个词被随意滥用。真正的版本和炒作的版本是非常两回事，在构建任何东西之前，理解这种差距是很有价值的。
- **自我学习**——智能体根据学到的东西更新自己的权重。Fable 5 并不这样做。目前没有任何公开可用的模型在生产环境中这样做。
递归自我改进（RSI）是 Anthropic 自己在 2026 年 5 月警告过的长期方向，而不是今天发布的能力。
- **自我改进**——智能体周围的系统在复利。每次会话将经验教训写入记忆。随着边缘案例被添加，技能变得精进。
状态文件积累验证过的事实。评估循环优化提示词和评分标准。模型保持不变；它运行的环境变得更敏锐。
在这个意义上，自我改进是你构建的系统的一个属性。Fable 5 拥有原始能力——长上下文、子智能体分派、视觉自检、数天的耐力——这将环境反馈循环变成了真正能在运行中产生复利的东西。
> Anthropic 的工程团队直言不讳地指出：
“与其直接提示和引导 Fable 5，不如设计循环，让模型能够响应环境反馈（例如 /goal 或 Outcomes）进行自我纠正，并管理自己的上下文（例如通过记忆）。”
## 03. 复利技术栈：四层，一个反馈循环。
文章顶部的图 1 在一张图中展示了架构。从下往上读——这是系统构建的顺序，也是杠杆复利的顺序。
- **第一层 · 原语**。Fable 5 本身、子智能体、工作树、智能体调用的工具。此时还没有系统围绕的原始能力。这就是大多数人今天使用的状态。
- **第二层 · 编排**。用于自我纠正循环的 /goal 和 Outcomes。用于复杂多步骤编排的动态工作流。用于合上笔记本也能运行的云端例行程序。这是将原语转化为工作流的关键。
- **第三层 · 记忆**。状态文件、技能、知识库、记录下来的经验教训。记忆让明天的会话是恢复而不是重启。
- **第四层 · 自我改进**。视觉自检、评估循环、规则提炼。智能体给自己的输出打分，优化产生该输出的技能，将经验教训写回记忆。循环闭合。
这个架构之所以能产生复利的原因：第一层的每一个输出都会向上流动到第四层，在那里被评分、提炼并写回第三层。明天在第一层的运行继承了昨天经过优化的记忆和技能。模型是无状态的；它周围的系统则不是。
## 04. 何时使用 Fable 5 vs Opus 4.8 vs Sonnet 4.6。成本-能力矩阵。
Fable 5 的每 Token 成本大约是 Opus 4.8 的 5 倍。自我改进系统中的每一步并不都需要顶级配置。在生产环境中运行这项功能的团队是根据任务复杂度进行路由，而不是默认使用最高级：
- **Fable 5 用于重型编排角色**：跨天规划、分派给子智能体、使用视觉检查工作、从累积的证据中提炼规则。
在“数天持续运行”的能力足以证明其定价合理的地方使用 Fable 5。
- **Opus 4.8 用于编排器分派的困难但有界的子任务**：架构决策、复杂调试、深度代码审查。也是 Fable 5 分类器拦截的任何请求（网络、生物、化学、蒸馏）的显式后备方案。
- **Sonnet 4.6 用于大批量工作任务**：代码检查、简单重构、测试脚手架、文档更新。大部分并发工作都在这里运行。
- **Haiku 4.5 用于评分器子智能体和廉价分类器**。独立的上下文窗口、低成本——非常适合 Anthropic 明确推荐的验证者角色。
让自我改进系统具有经济效益的成本模式，被在生产环境中运行的团队所使用：编排器使用 Fable 5，工作代理使用 Sonnet 4.6，评分器使用 Haiku 4.5，在分类器拦截时回退到 Opus 4.8。这与 Anthropic 工程师内部使用的模式相同。
**第二部分 · 三大原语**
## 05. /goal vs Outcomes。同一思想的两种实现。
Anthropic Claude Code 团队发布了两种几乎相同的目标驱动循环原语——每种框架一个。
它们共享相同的形态：一个独立的评分器检查工作，“未达标”的判定开始下一次迭代，当评分器通过时循环退出。
实现在表面细节上有所不同，这决定了你应该使用哪一个。
它们之间的决策规则很简单：
- **在 Claude Code 中使用 /goal**：当工作发生在你的机器上，并且你想要一个快速的、会话内的循环且具有可测量的结束状态时。最适合动手编码、调试不稳定测试、优化单个文件。纯文本目标、模型评分器、终端内反馈。
- **在 CMA 中使用 Outcomes**：当工作需要在 Anthropic 托管的基础设施上运行数小时或数天，且需要沙箱、GPU 或受控环境时。最适合 ML 训练、长时间运行的迁移、多天研究。基于文件的评分标准带可评分标准、子智能体评分器、硬性 max_iterations（最大迭代次数）限制。
两者共享使其工作的结构性举措：编写代码的智能体不是给代码打分的智能体。我们将在第 6 步深入探讨为什么这很重要。
## 06. 验证者子智能体胜过自我批判。
Anthropic 工程师 Prithvi Rajasekaran 在工程博客上撰文指出，模型很难自我批判自己的输出。Claude Code 团队用 Fable 5 实证证实了这一点：
> “我们发现，对于 Fable 5，验证者子智能体往往优于自我批判。”
其机制是结构性的，与“更努力尝试”无关。评估自己输出的模型会看到自己的推理轨迹，并倾向于与其已编写内容一致的结论。
一个独立模型评估同一输出时，只看到工件和评分标准。验证者在这个制造者的游戏中没有利益瓜葛。
该图表实际上展示的内容，除了头条数字之外：
- Fable 5 做出了更大的结构性改变——TRAIN_SEQ_LEN=2048 train+eval (−0.0179)、重叠滑动窗口评估 (−0.0207)、int6 QAT + int6 expo (−0.0163)。每一个都是架构级别的变动，而非常量微调。
- Fable 5 穿过一个量化回归取得了其最大胜利——它在实验失败后没有回退，而是继续调查。
- Opus 4.7 的第一个实验（QK_GAIN_INIT=5.0）产生了小幅胜利。之后的几乎所有内容都使用了相同的模板：调整标量、测量、如果是正向则保留。其形态是更安全，而不是更好。
这对系统设计的启示是：带有独立验证器的 Fable 5 可以探索更大的假设空间，并能从负面的中间结果中恢复。没有验证器，同一个模型就没有任何力量迫使它越过第一个“足够好”。
## 07. 动态工作流组合自我纠正模式。
动态工作流于 2026 年 5 月 28 日在 Claude Code 中发布。
其核心理念是：Claude 动态编写自己的 JavaScript 框架——一个包含 agent()、parallel() 和 pipeline() 原语的文件，加上标准 JS 来处理在它们之间流动的数据。该框架是为任务定制的，而非通用的。
> **cat@_catwu**: [原文链接](https://x.com/_catwu/status/2060054180379689074)
>
> 很高兴分享我们要强大的 Claude Code 新功能：动态工作流！
> 在提示词中提及“workflow”，Claude 将动态创建一个严格执行的编排计划，让你可以自信地确信每个阶段都按正确的顺序发生
>
> 
对于使用 Fable 5 的自我改进系统，六个已文档化的动态工作流模式中有三个值得它们的一席之地：
- **发散并综合**。将工作拆分为 N 个独立的部分，在每个部分上并行运行一个智能体，然后综合结果。最适合每一步都从自己干净的上下文窗口中受益的情况——例如，根据历史示例评估技能中的每条规则。
- **对抗性验证**。为每个制造者智能体生成一个独立的验证者，该验证者未接触制造者的推理。这是第 6 步中提到的自我偏好偏差的结构性修复，应用于每项任务。
- **循环直到完成**。循环生成智能体，直到满足停止条件——无新发现、日志中不再有错误、理论得到验证。与 /goal 配对以设定硬性完成要求。
另外两个通常不出现在自我改进系统中但值得了解的模式：分类并行动（基于分类器将任务路由到正确的模型）和锦标赛（用于基于品味排序的成对比较）。第一个对模型路由很有用（第 4 步）。
第二个在编码循环中很少见，但对设计或命名任务有用。
## 08. 用于并行安全的工作树。持续数天的 Fable 5 会话，无文件冲突。
自我改进系统一旦生成不止一个智能体，文件就会开始冲突。两个智能体写入同一个文件，就像两个工程师在未沟通的情况下提交同一行代码一样是同样的问题。
git worktree 解决了这个问题——这是一个单独的工作目录，位于自己的分支上，共享同一个仓库历史，因此一个智能体的编辑从字面上看不可能触及另一个的检出状态。
对于 Fable 5 生成子智能体进行验证或专业化的自我改进系统，工作树是不可或缺的：
- 制造者在工作树 A 中写入。验证者在工作树 B 中读取（或针对工作树 A 的检出状态运行，且文件系统为只读）。验证者的探索不会影响制造者状态的风险。
- 并行结构实验。如果 Fable 5 探索多个架构变更（如参数高尔夫），每个实验在自己的工作树中运行。编排器收集所有实验的结果；最好的那个被合并。
- 带检查点的长时运行。每个主要阶段可以是一个单独的工作树。失败的阶段不会毒害其余部分。
在 Claude Code 中，工作树以三种方式暴露：直接使用 git worktree，使用 --worktree 标志在其自己的检出状态中打开会话，以及在子智能体上设置 isolation: worktree，这样每个助手都会获得一个全新的检出状态，并在会话结束后自动清理。
## 09. 用于长时编排的例行程序。合上笔记本。Fable 5 在工作。
例行程序于 2026 年 4 月 14 日在研究预览版中启动。它们是保存的 Claude Code 配置——包括提示词、仓库、连接器、权限——在触发器下运行在 Anthropic 管理的云基础设施上。
你的笔记本可以关机。运行仍在发生。
特别是对于 Fable 5，例行程序是让模型能力物有所值的触发层。Anthropic 在 Claude 托管智能体上衡量 Fable 5 的“数天持续运行”能力——这是一个拥有完整工具且无本地机器限制的托管沙箱。
参数高尔夫实验在 8×H100 GPU 上运行了长达 8 小时。这种级别的运行不会在你的笔记本上发生。
映射到自我改进模式的三种例行程序触发器类型：
- **定时触发器**——晨间简报模式。每天早上 7 点：重新运行昨天的评估套件，将任何新的失败模式提炼为技能，将摘要写入 Slack。智能体在你睡觉时变得更强。
- **API 触发器**——“事件触发”模式。CI 失败 → 触发例行程序进行调查。Sentry 警报 → 触发例行程序进行分诊。自我改进系统响应你的真实环境，而不是固定的时间表。
- **GitHub 事件触发器**——“从真实工作中学习”模式。PR 打开时，针对最新的技能运行评估。合并时，将 PR 引入的任何新模式写回技能。仓库状态和技能状态保持同步。
```
> /schedule daily at 7am, use Fable 5 in CMA
Goal: Re-run yesterday’s eval suite against the latest skills.
Any test that newly passes → distill the pattern into the skill.
Any test that newly fails → investigate, document in STATE.md.
Post the digest to #engineering. /goal don’t stop until digest is
posted and STATE.md is updated.
▲ Claude
Creating routine: nightly-eval-compounding
- model: claude-fable-5
- harness: claude managed agent (sandbox)
- trigger: schedule (0 7 * * *)
- grader: independent Haiku sub-agent (Outcomes)
✓ Active. First run tomorrow 07:00 local. Skill set will co