learn-harness-engineering

1. 安装并启动 DeepSeek Harness：npx @deepseek-ai/dsh web
2. 在终端执行上面的安装命令（CLI 会解析插件并核验来源）
3. 用 dsh plugins list 确认已安装，必要时重启 Harness 生效

插件以当前 dsh 进程的权限运行，安装时可能执行代码。请先通读仓库源码与许可证，确认无破坏性命令与越权访问；本站只做索引，不对第三方插件安全性作担保。

事实信息来自公开插件目录快照（2026-09-19），介绍文案由本站再加工。

以下为插件仓库 README 全文（原始内容，由公开目录抓取整理）。

[图片: English]

  [图片: 简体中文]

  [图片: 繁體中文]

  [图片: 日本語]

  [图片: 한국어]

  [图片: Español]

  [图片: Français]

  [图片: Русский]

  [图片: Deutsch]

  [图片: العربية]

  [图片: Tiếng Việt]

  [图片: Oʻzbekcha]

  [图片: Türkçe]

  [图片: Português-BR]

  [图片: Українська]

Learn Harness Engineering

A project-based course on building the environment, state management, verification, and control mechanisms that make AI coding agents work reliably.

  [图片: 14 Lectures]

  [图片: 8 Projects]

  [图片: 15 Languages]

  [图片: MIT License]

  [图片: Join the Discord community]

🌍 This course is available in 15 languages: English, 简体中文, 繁體中文, 日本語, 한국어, Español, Français, Русский, Deutsch, العربية, Tiếng Việt, Oʻzbekcha, Türkçe, Portuguese (BR), Українська. Choose your language from the badges above.

🆕 What's New — August 2026

Frontier Harness Design Breakdowns — new section (4 breakdowns)

What
Details

New section
Frontier Harness Design Breakdowns — Apply the course's five-subsystem framework (instructions, tools, environment, state, feedback) to reverse-engineer how four frontier products build real harnesses.

Pi
How Pi builds its harness — a minimal kernel, programmable expansion, and context engineering behind "ask Pi to build what you want."

Claude Code
How Claude Code builds its harness — four-layer memory, five-level compaction, hooks, and sub-agent isolation.

Codex
How Codex builds its harness — the repository as source of truth, AGENTS.md as a directory page, and worktree isolation.

DeepSeek
How DeepSeek builds its harness — "everything is a plugin," capability seams, and an event pipeline.

All 15 languages
Full translation coverage across all supported languages.

Key idea: The course gives you a framework; these breakdowns show you how the same principles actually play out in production harnesses.

Graph Engineering Update — 1 new lecture, 1 new project

What
Details

Lecture 14
From Single Loops to Graph Engineering — Why a single loop grows into a graph: the four stacked layers (prompt → context → loop → graph) and where harness sits in that stack, the four parts of a graph (nodes, edges, shared state, routing), why in-loop checkpoints can't fix the three structural failures at scale (Goodhart, blindness upward, conflict), a framework-agnostic six-step walkthrough for building your first graph, graph vs. workflow, anchors, which open-source "graph engineering" projects existed before the name vs. after it, the orchestration tax, and when a graph is actually worth drawing.

Project 08
Draw Your Workflow as a Graph — Three progressive experiments: draw your maker-checker loop as an explicit graph, add a parallel fan-out/fan-in node, then add a conditional rollback edge and a human-approval node.

Key idea: A loop is a graph with one node. When your task needs specialization, parallelism, shared state, verification, and recovery — it has stopped being a loop. It's a graph.

🆕 What's New — July 2026

Loop Engineering Update — 1 new lecture, 1 new project

What
Details

Lecture 13
Why You Need to Stop Prompting Your Agent — From /goal to the six primitives of loop engineering (automations, worktrees, skills, connectors, sub-agents, external state), the generator/evaluator split, four silent costs, and a step-by-step guide to building your first loop.

Project 07
Build Your First Automated Loop — Three progressive experiments: goal loop, timer loop, and maker-checker loop. Compare manual vs. automated, measure intervention reduction, and learn to step outside the loop.

Code templates
goal-template.md, loop-state-template.md, maker-prompt.md, checker-prompt.md — drop-in templates for building loops immediately.

All 15 languages
Full translation coverage across all supported languages.

Key idea: Harness engineering builds the vehicle. Loop engineering designs the road it drives on — and you design the road from outside the car.

Learn Harness Engineering is a course dedicated to the engineering of AI coding agents. We have deeply studied and synthesized the most advanced Harness Engineering theories and practices in the industry. Our core references include:

OpenAI: Harness engineering: leveraging Codex in an agent-first world

Anthropic: Effective harnesses for long-running agents

Anthropic: Harness design for long-running application development

Awesome Harness Engineering

Quick start? The skills/harness-creator/ skill can help you scaffold a production-grade harness (AGENTS.md, feature lists, init.sh, verification workflows) for your own project in minutes.

Table of Contents

🆕 What's New

✨ Visual Preview

What Harness Engineering Actually Means

Quick Start: Improve Your Agent Today

Capstone Project: A Real App

Learning Path

Syllabus

Skills

Other Courses

✨ Visual Preview

🏠 Course Homepage

A comprehensive course outline and introduction to core philosophies, providing a clear path to get started.

[图片: Course homepage preview]

📖 Immersive Lectures

Deep dives into real-world pain points and hands-on projects (like Project 01) for an immersive learning experience.

[图片: Course lecture preview]

🗂️ Ready-to-Use Resource Library

Templates and reference configurations designed to solve common pitfalls in multi-turn AI agent development, such as context loss and premature task completion.

[图片: Resource library preview]

PDF Coursebooks

The repository now includes a PDF build pipeline for the course content.

Run npm run pdf:build to generate the currently configured PDF coursebooks locally.

Output files are written to artifacts/pdfs/.

Run npm run screenshots:readme if you want to refresh the README preview images.

GitHub Actions workflow release-course-pdfs.yml can build the PDFs and publish them to GitHub Releases.

The Model Is Smart, The Harness Makes It Reliable

There's a hard truth most people learn the hard way: the strongest model in the world will still fail on real engineering tasks if you don't build a proper environment around it.

You've probably seen this yourself. You give Claude or GPT a task in your repo. It starts well — reads files, writes code, looks productive. Then something goes wrong. It skips a step. It breaks a test. It says "done" but nothing actually works. You spend more time cleaning up than if you'd done it yourself.

This isn't a model problem. It's a harness problem.

The evidence is clear. Anthropic ran a controlled experiment: same model (Opus 4.5), same prompt ("build a 2D retro game editor"). Without a harness, it spent $9 in 20 minutes and produced something that didn't work. With a full harness (planner + generator + evaluator), it spent $200 in 6 hours and built a game you could actually play. The model didn't change. The harness did.

OpenAI reported the same thing with Codex: in a well-harnessed repository, the same model goes from "unreliable" to "reliable." Not a marginal improvement — a qualitative shift.

This course teaches you how to build that environment.

                    THE HARNESS PATTERN
                    ====================

    You --> give task --> Agent reads harness files --> Agent executes
                                                        |
                                              harness governs every step:
                                              |
                                              +--> Instructions: what to do, in what order
                                              +--> Scope:        one feature at a time, no overreach
                                              +--> State:        progress log, feature list, git history
                                              +--> Verification: tests, lint, type-check, smoke runs
                                              +--> Lifecycle:    init at start, clean state at end
                                              |
                                              v
                                         Agent stops only when
                                         verification passes

What Harness Engineering Actually Means

Harness engineering is about building a complete working environment around the model so it produces reliable results. It's not about writing better prompts. It's about designing the system the model operates inside.

A harness has five subsystems:

    ┌────────────────────────────────────────────────────────────────┐
    │                          THE HARNESS                           │
    │                                                                │
    │   ┌──────────────┐  ┌──────────────┐  ┌────────────────────┐   │
    │   │ Instructions │  │    State     │  │   Verification     │   │
    │   │              │  │              │  │                    │   │
    │   │ AGENTS.md    │  │ progress.md  │  │ tests + lint       │   │
    │   │ CLAUDE.md    │  │ feature_list │  │ type-check         │   │
    │   │ feature_list │  │ git log      │  │ smoke runs         │   │
    │   │ docs/        │  │ session hand │  │ e2e pipeline       │   │
    │   └──────────────┘  └──────────────┘  └────────────────────┘   │
    │                                                                │
    │   ┌──────────────┐  ┌──────────────────────────────────────┐   │
    │   │    Scope     │  │         Session Lifecycle            │   │
    │   │              │  │                                      │   │
    │   │ one feature  │  │ init.sh at start                     │   │
    │   │ at a time    │  │ clean-state checklist at end         │   │
    │   │ definition   │  │ handoff note for next session        │   │
    │   │ of done      │  │ commit only when safe to resume      │   │
    │   └──────────────┘  └──────────────────────────────────────┘   │
    │                                                                │
    └────────────────────────────────────────────────────────────────┘

    The MODEL decides what code to write.
    The HARNESS governs when, where, and how it writes it.
    The harness doesn't make the model smarter.
    It makes the model's output reliable.

Each subsystem has one job:

Instructions — Tell the agent what to do, in what order, and what to read before starting. Not one giant file; a progressive disclosure structure the agent navigates on demand.

State — Track what's been done, what's in progress, and what's next. Persisted to disk so the next session picks up exactly where the last one left off.

Verification — Only a passing test suite counts as evidence. The agent cannot declare victory without runnable proof.

Scope — Constrain the agent to one feature at a time. No overreach. No half-finishing three things. No rewriting the feature list to hide unfinished work.

Session Lifecycle — Initialize at the start. Clean up at the end. Leave a clean restart path for the next session.

Why This Course Exists

The question isn't "can models write code?" They can. The question is: can they reliably complete real engineering tasks inside real repositories, over multiple sessions, without constant human supervision?

Right now, the answer is: not without a harness.

    WITHOUT HARNESS                            WITH HARNESS
    ==============                             ============

    Session 1: agent writes code               Session 1: agent reads instructions
               agent breaks tests                         agent runs init.sh
               agent says "done"                          agent works on one feature
               you fix it manually                        agent verifies before claiming done
                                                          agent updates progress log
    Session 2: agent starts fresh                         agent commits clean state
               agent has no memory
               of what happened before         Session 2: agent reads progress log
               agent re-does work                         agent picks up exactly where it left off
               or does something else entirely            agent continues the unfinished feature
               you fix it again                           you review, not rescue

    Result: you spend more time                Result: agent does the work,
            cleaning up than if you                    you verify the result
            did it yourself

The questions this course actually cares about:

Which harness designs improve task completion rates?

Which designs reduce rework and incorrect completions?

Which mechanisms keep long-running tasks progressing steadily?

Which structures keep the system maintainable after multiple agent runs?

Course Curriculum & Documentation

For the full course materials, please visit the Documentation Website.

The curriculum is divided into three parts:

Lectures: 13 conceptual units explaining the theory behind harness engineering.

Projects: 7 hands-on projects where you build an agentic workspace from scratch.

Resource Library: Copy-ready templates (AGENTS.md, feature_list.json, init.sh, etc.) to use in your own repositories today.

Quick Start: Improve Your Agent Today

You don't need to read all 14 lectures before you start getting value. If you're already using a coding agent on a real project, here's how to improve it right now.

The idea is simple: instead of just writing prompts, give your agent a set of structured files that define what to do, what's been done, and how to verify the work. These files live inside your repo, so every session starts from the same state.

    YOUR PROJECT ROOT
    ├── AGENTS.md              <-- the agent's operating manual
    ├── CLAUDE.md              <-- (alternative, if using Claude Code)
    ├── init.sh                <-- runs install + verify + start
    ├── feature_list.json      <-- what features exist, which are done
    ├── claude-progress.md     <-- session progress (historical filename; agent-agnostic)
    └── src/                   <-- your actual code

Grab the starter templates from the Resource Library and drop them into your project. That's it. Four files, and your agent sessions will already be significantly more stable than running on prompts alone.

claude-progress.md is a generic, repository-local session progress log; the
name is retained for compatibility with the course examples. It is not tied to
Claude Code and is not updated automatically by any agent. Codex, OpenHands,
Antigravity, and other coding agents can use the same file when their root
instructions tell them to read it at startup and update it before handoff.

Capstone Project: A Real App

All six course projects revolve around the same product: an Electron-based personal knowledge base desktop app.

    ┌──────────────────────────────────────────────────────┐
    │             Knowledge Base Desktop App               │
    │                                                      │
    │  ┌──────────────┐  ┌──────────────────────────────┐  │
    │  │ Document List│  │       Q&A Panel              │  │
    │  │              │  │                              │  │
    │  │ doc-001.md   │  │  Q: What is harness eng?     │  │
    │  │ doc-002.md   │  │  A: The environment built    │  │
    │  │ doc-003.md   │  │     around an agent model... │  │
    │  │ ...          │  │     [citation: doc-002.md]   │  │
    │  └──────────────┘  └──────────────────────────────┘  │
    │                                                      │
    │  ┌─────────────────────────────────────────────────┐ │
    │  │ Status Bar: 42 docs | 38 indexed | last sync 3m │ │
    │  └─────────────────────────────────────────────────┘ │
    └──────────────────────────────────────────────────────┘

    Core features:
    ├── Import local documents
    ├── Manage a document library
    ├── Process and index documents
    ├── Run AI-powered Q&A over imported content
    └── Return grounded answers with citations

This project was chosen because it combines strong practical value, enough real-world product complexity, and a good setting for observing before/after harness improvements.

Each course project's starter/solution is a complete copy of this Electron app at that evolutionary stage. P(N+1)'s starter is derived from P(N)'s solution — the app evolves as your harness skills grow.

Learning Path

The course is designed to be done in order. Each phase builds on the last.

    Phase 1: SEE THE PROBLEM              Phase 2: STRUCTURE THE REPO
    ========================              ==========================

    L01  Strong models ≠ reliable         L03  Repository as single
         execution                              source of truth
    L02  What harness actually means
                                          L04  Split instructions across
         |                                     files, not one giant file
         v
    P01  Prompt-only vs.                       |
         rules-first comparison                v
                                               P02  Agent-readable workspace

    Phase 3: CONNECT SESSIONS             Phase 4: FEEDBACK & SCOPE
    ==========================            =========================

    L05  Keep context alive               L07  Draw clear task boundaries
         across sessions
                                          L08  Feature lists as harness
    L06  Initialize before every               primitives
         agent session
                                               |
         |                                     v
         v                                     P04  Runtime feedback to
    P03  Multi-session continuity                   correct agent behavior

    Phase 5: VERIFICATION                 Phase 6: PUT IT ALL TOGETHER
    =====================                 ============================

    L09  Stop agents from                 L11  Make agent's runtime
         declaring victory early               observable

    L10  Full-pipeline run =              L12  Clean handoff at end of
         real verification                      every session

         |                                     |
         v                                     v
    P05  Agent verifies its own work      P06  Build a complete harness
                                               (capstone project)

    Phase 7: AUTOMATE THE LOOP
    ==========================

    L13  Stop prompting your agent —
         design loops instead

         |
         v
    P07  Build your first automated loop
         (goal loop, timer loop, maker-checker)

    Phase 8: STRUCTURE THE SYSTEM
    =============================

    L14  Draw the system as a graph —
         nodes, edges, shared state, routing

         |
         v
    P08  Draw your workflow as a graph
         (explicit graph, parallel fan-out/fan-in,
          rollback edges, human-in-the-loop)

Each phase takes about a week if you're going part-time. If you want to go faster, phases 1–3 can be done in a long weekend.

Syllabus

Lectures — 14 conceptual units, each answering one core question

Read the full text for each lecture on the Documentation Website.

Session
Question
Core Idea

L01
Why do strong models still fail on real tasks?
The capability gap between benchmarks and real engineering

L02
What does "harness" actually mean?
Five subsystems: instructions, state, verification, scope, lifecycle

L03
Why must the repo be the single source of truth?
If the agent can't see it, it doesn't exist

L04
Why does one giant instruction file fail?
Progressive disclosure: give a map, not an encyclopedia

L05
Why do long-running tasks lose continuity?
Persist progress to disk; pick up where you left off

L06
Why does initialization need its own phase?
Verify the environment is healthy before the agent starts work

L07
Why do agents overreach and under-finish?
One feature at a time; explicit definition of done

L08
Why are feature lists harness primitives?
Machine-readable scope boundaries the agent can't ignore

L09
Why do agents declare victory too early?
Verification gaps: confidence ≠ correctness

L10
Why does end-to-end testing change results?
Only a full-pipeline run counts as real verification

L11
Why does observability belong inside the harness?
If you can't see what the agent did, you can't fix what it broke

L12
Why must every session leave a clean state?
The next session's success depends on this session's cleanup

L13
Why do you need to stop prompting your agent?
From manual driving to automated loops — goal loops, timer loops, and maker-checker separation

L14
Why does a single loop grow into a graph?
From single loops to graph engineering — nodes, edges, shared state, routing, and when a graph is actually worth drawing

Projects — 8 hands-on projects applying lecture methods to the same Electron app

Project
What You Do
Harness Mechanism

P01
Run the same task twice: prompt-only vs. rules-first
Minimal harness: AGENTS.md + init.sh + feature_list.json

P02
Restructure the repo so the agent can read it
Agent-readable workspace + persistent state files

P03
Make the agent pick up from where it left off
Progress log + session handoff + multi-session continuity

P04
Stop the agent from doing too much or too little
Runtime feedback + scope control + incremental indexing

P05
Make the agent verify its own work
Self-verification + grounded Q&A + evidence-based completion

P06
Build a complete harness from scratch (capstone)
Full harness: all mechanisms + observability + ablation study

P07
Build your first automated loop
Goal loops, timer loops, maker-checker separation, loop state management

P08
Draw your workflow as a graph
Explicit nodes/edges/state/routing, parallel fan-out/fan-in, rollback edges, human-in-the-loop approval

    PROJECT EVOLUTION
    =================

    P01  Prompt-only vs. rules-first       You see the problem
     |
     v
    P02  Agent-readable workspace          You restructure the repo
     |
     v
    P03  Multi-session continuity          You connect sessions
     |
     v
    P04  Runtime feedback & scope          You add feedback loops
     |
     v
    P05  Self-verification                 You make the agent check itself
     |
     v
    P06  Complete harness (capstone)       You build the full system
     |
     v
    P07  Your first automated loop        You step outside the loop
     |
     v
    P08  Draw your workflow as a graph    You draw the system as a graph

    Each project's solution becomes the next project's starter.
    The app evolves. Your harness skills grow with it.

Resource Library

English — templates, checklists, and method references

简体中文 — 中文模板、清单和方法参考

繁體中文 — 繁體中文範本、清單和方法參考

日本語 — テンプレート、チェックリスト、方法リファレンス

한국어 — 템플릿, 체크리스트, 방법 참고 자료

Español — plantillas, listas de verificación y referencias

Français — modèles, listes de contrôle et références

Русский — шаблоны, чек-листы и справочники

Deutsch — Vorlagen, Checklisten und Referenzen

العربية — قوالب، قوائم تحقق ومراجع

Tiếng Việt — mẫu, danh sách kiểm tra và tài liệu tham khảo

Oʻzbekcha — andozalar, tekshiruv roʻyxatlari va maʼlumotnomalar

Türkçe — şablonlar, kontrol listeleri ve referanslar

Português (BR) — modelos, listas de verificação e referências de métodos

The Agent Session Lifecycle

One of the core ideas in this course: the agent's session should follow a structured lifecycle, not a free-for-all. Here's what that looks like:

    AGENT SESSION LIFECYCLE
    ======================

    ┌──────────────────────────────────────────────────────────────────┐
    │  START                                                           │
    │                                                                  │
    │  1. Agent reads AGENTS.md / CLAUDE.md                            │
    │  2. Agent runs init.sh (install, verify, health check)           │
    │  3. Agent reads claude-progress.md (what happened last time)     │
    │  4. Agent reads feature_list.json (what's done, what's next)     │
    │  5. Agent checks git log (recent changes)                        │
    │                                                                  │
    │  SELECT                                                          │
    │                                                                  │
    │  6. Agent picks exactly ONE unfinished feature                   │
    │  7. Agent works only on that feature                             │
    │                                                                  │
    │  EXECUTE                                                         │
    │                                                                  │
    │  8. Agent implements the feature                                 │
    │  9. Agent runs verification (tests, lint, type-check)            │
    │  10. If verification fails: fix and re-run                       │
    │  11. If verification passes: record evidence                     │
    │                                                                  │
    │  WRAP UP                                                         │
    │                                                                  │
    │  12. Agent updates claude-progress.md                            │
    │  13. Agent updates feature_list.json                             │
    │  14. Agent records what's still broken or unverified             │
    │  15. Agent commits (only when safe to resume)                    │
    │  16. Agent leaves clean restart path for next session            │
    │                                                                  │
    └──────────────────────────────────────────────────────────────────┘

    The harness governs every transition in this lifecycle.
    The model decides what code to write at each step.
    Without the harness, step 9 becomes "agent says it looks fine."
    With the harness, step 9 is "tests pass, lint is clean, types check."

Who This Is For

This course is for:

Engineers already using coding agents who want better stability and quality

Researchers or builders who want a systematic understanding of harness design

Tech leads who need to understand how environment design affects agent performance

This course is not for:

People looking for a zero-code AI introduction

People who only care about prompts and don't plan to build real implementations

Learners not prepared to let agents work inside real repositories

Requirements

This is a course where you actually run coding agents.

You need at least one of these tools:

Claude Code

Codex

Another IDE or CLI coding agent that supports file editing, command execution, and multi-step tasks

The course assumes you can:

Open a local repository

Allow the agent to edit files

Allow the agent to run commands

Inspect output and re-run tasks

If you don't have such a tool, you can still read the course content, but you won't be able to complete the projects as intended.

Local Preview

This repository uses VitePress as a documentation viewer.

npm install
npm run docs:dev        # Dev server with hot reload
npm run docs:build      # Production build
npm run docs:preview    # Preview built site

Then open the local URL that VitePress outputs in your browser.

Prerequisites

Required:

Familiarity with the terminal, git, and local development environments

Ability to read and write code in at least one common application stack

Basic software debugging experience (reading logs, tests, and runtime behavior)

Enough time to commit to implementation-focused coursework

Helpful but not required:

Experience with Electron, desktop apps, or local-first tools

Background in testing, logging, or software architecture

Prior exposure to Codex, Claude Code, or similar coding agents

Core References

Primary:

OpenAI: Harness engineering: leveraging Codex in an agent-first world

Anthropic: Effective harnesses for long-running agents

Anthropic: Harness design for long-running application development

OpenAI: Unrolling the Codex agent loop

Anthropic: Demystifying evals for AI agents

LangChain: Improving Deep Agents with harness engineering

Thoughtworks / Martin Fowler: Harness engineering for coding agent users

Cursor: Continually improving our agent harness

See the full layered reference list in docs/en/resources/reference/.

Repository Structure

learn-harness-engineering/
├── docs/                          # VitePress documentation site
│   ├── lectures/                  # 14 lectures (index.md + code/ examples)
│   │   ├── lecture-01-*/
│   │   └── ... (14 total)
│   ├── projects/                  # 8 project descriptions
│   │   ├── project-01-*/
│   │   └── ... (8 total)
│   └── resources/                 # Multilingual templates & references (14 languages)
│       ├── en/
│       └── ... (14 total)
├── projects/
│   ├── shared/                    # Shared Electron + TypeScript + React foundation
│   └── project-NN/                # Per-project starter/ and solution/ directories
├── skills/                        # Reusable AI agent skills
│   └── harness-creator/           # Harness engineering skill
├── tools/                         # Zero-dependency shell utilities
│   └── audit-harness.sh           # Shell-based harness audit (L03–L12, no Node.js needed)
├── package.json                   # VitePress + dev tooling
└── CLAUDE.md                      # Claude Code instructions for this repo

How the Course Is Organized

Each lecture focuses on one question

The course includes 8 projects

Every project requires the agent to do real work

Every project compares weak vs. strong harness results

What matters is the measured difference, not how many docs were written

Skills

This repository also includes reusable AI agent skills that you can install directly into your IDE or agent workspace.

harness-creator: A skill that helps you scaffold a production-grade harness for your own project in minutes.

Tools

Zero-dependency utilities you can run without installing Node.js.

audit-harness.sh: A shell-based audit script that checks an existing repo against all five harness subsystems (L03–L12). Exits 0 when all CRITICAL items pass. No Node.js required — complements harness-creator's validate-harness.mjs.

# Run directly on any repo
curl -fsSL https://raw.githubusercontent.com/walkinglabs/learn-harness-engineering/main/tools/audit-harness.sh | bash -s -- /path/to/your/repo

# Or after cloning
bash tools/audit-harness.sh /path/to/your/repo

Other Courses

Our team has also created other courses! Check them out:

[图片: Hands-on Modern RL]

Hands-on Modern RL: An open-source, hands-on curriculum bridging the gap from basic RL concepts to LLM alignment, RLVR, and advanced Agentic systems.

[图片: Modern LLM Notebook]

Modern LLM Notebook: A hands-on course for building modern LLMs from scratch in PyTorch, with 23 runnable Jupyter Notebooks covering tokenizers, attention, MoE, RLHF, inference, evaluation, and distillation.

Acknowledgments

This course was inspired by and draws ideas from learn-claude-code — a progressive guide to building an agent from scratch, from a single loop to isolated autonomous execution.