Fable method: Dùng skill cho mọi model trên VPS

Phương pháp Fable thực sự tuyên bố điều gì

Phương pháp Fable là một tập hợp nhỏ các agent skill, ghi lại thói quen làm việc của một model thành một quy trình có thứ tự để một model khác có thể chạy cùng quy trình đó. Repo là Sahir619/fable-method, được cấp phép theo MIT. Mô tả một dòng của chính repo là “cách Claude Fable 5 đã làm việc, được cô đọng thành các skill mà mọi model đều có thể chạy, kèm eval để kiểm chứng”. Phần thứ hai của câu này là tuyên bố đáng kiểm tra.

Người bên ngoài Anthropic không thể kiểm chứng một file văn bản có thực sự ghi lại cách một model cụ thể suy nghĩ hay không. Nhưng bạn có thể tự kiểm tra xem một model rẻ hơn có hành xử khác đi khi đọc file đó hay không, chỉ với một VPS trong một buổi chiều. Đó là mục đích của toàn bộ phần bên dưới: thực hiện cùng một tác vụ hai lần, có và không có phương pháp này, rồi đếm số lần gọi tool và chi phí.

Nếu bạn chưa quen với từ skill, hãy bắt đầu với agent skill thực sự là gì: một thư mục chứa file SKILL.md có phần frontmatter description cho agent biết khi nào cần load phần nội dung. Model được dùng để đặt tên cho repo này được đề cập trong Claude Fable 5 có chi phí bao nhiêu và phù hợp với việc gì.

Cài các skill và cố định version đã kiểm thử

Có 2 cách cài đặt. Trong Claude Code, cách cài qua plugin gồm 2 lệnh:

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

Trên VPS, nếu muốn có một bản đã cố định version trên disk, hãy clone repo rồi checkout một tag trước:

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh không cần sudo vì chỉ ghi dữ liệu bên dưới $HOME/.claude/skills. Sau khi chạy xong, ls ~/.claude/skills sẽ liệt kê fable-judge, fable-loop và fable-method. Hãy xem những gì không xuất hiện. Repo cung cấp 4 skill nhưng shell installer chỉ sao chép 3 skill, nên người dùng chạy độc lập sẽ không có fable-domain nếu không tự sao chép:

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

Hãy cố định tag và ghi lại tag đó cùng với các kết quả thu được. Repo này đã phát hành 5 release trong khoảng từ 2026-07-06 đến 2026-07-15, từ v1.0.0 đến v1.4.0. v1.4.0 thay đổi chính method bằng cách thêm một routing gate mới. Tính đến tháng 8 năm 2026, v1.4.0 vẫn là tag mới nhất. Nếu control run đọc một version của bộ rule còn test run đọc version khác, bạn chưa đo được gì cả.

Bốn skill yêu cầu model làm gì

File giữ vai trò trung tâm là skills/fable-method/SKILL.md. File này có hai gate và bảy bước được đánh số. Các quy tắc đủ cụ thể để có thể kiểm tra và phản biện.

Gate xác định việc có tầm thường hay không được đặt trước: thực hiện trực tiếp, không cần nghi thức, khi thay đổi chỉ tác động đến một file, chạy trong khoảng dưới 10 dòng, không thêm hành vi mới và bạn đã biết chính xác cần thay đổi gì. Tiếp theo là fit gate, dùng vị trí chứa câu trả lời để định tuyến yêu cầu: nguồn mà bạn có thể mở, kỹ thuật cần nghiên cứu trước, hoặc suy luận của chính bạn. Trường hợp cuối phải được đánh dấu là độ tin cậy thấp, không được trình bày như sự thật.

Tiếp theo là vòng lặp: phân loại yêu cầu, xác định điều kiện hoàn tất, thu thập bằng chứng, quyết định, thực hiện, xác minh, báo cáo. Bước 2 yêu cầu định hướng bằng cách liệt kê directory trước khi chọn file, ưu tiên nguồn chính thay vì dựa vào trí nhớ, và dừng sau hai lần tra cứu liên tiếp không trả về thông tin mới. Bước 4 yêu cầu viết một dòng INTENT: trước bất kỳ lần chỉnh sửa nào. Dòng này phải nêu code đang làm gì, check bị lỗi mong đợi gì và spec nói gì. Không được chỉnh sửa khi ba nội dung đó không khớp, vì chính sự không khớp đó là phát hiện thực tế. Bước 5 giới hạn số lần retry: sau ba chu kỳ sửa và xác minh thất bại trên cùng một vấn đề, phải dừng và trả lại kết quả kèm output thực tế.

Phần dễ kiểm thử nhất của file là bốn report token. Thay đổi hành vi phải có một dòng INTENT:. Hành động hướng ra bên ngoài phải có AUTH: user said "<exact words>" và trích dẫn người dùng, vì repo nêu rõ rằng documentation không phải là quyền được phép thực hiện. Hành động được yêu cầu nhưng chưa thực hiện phải có một dòng PENDING:. Defect đã sửa phải có TWINS: searched <pattern> - found <N> other sites. Bạn không cần tin mọi điều về phương pháp này để kiểm tra xem bốn chuỗi đó có xuất hiện đúng lúc hay không. Vì vậy, toàn bộ phương pháp có thể đo lường được thay vì chỉ dựa vào cảm nhận.

fable-loop là cùng phương pháp đó, được chạy dưới dạng orchestration gồm bốn giai đoạn: lập kế hoạch bằng các evidence subagent chạy song song, thực thi trên main thread, xác minh bằng từ một đến ba attacker subagent với mỗi subagent sử dụng một góc nhìn khác nhau, sau đó audit và báo cáo. Phương pháp này giả định dùng model rẻ cho các role evidence và attacker, còn dùng model mạnh hơn cho việc quyết định và chỉnh sửa.

fable-judge là thành phần đáng cài đặt ngay cả khi bạn bỏ mọi thành phần khác. Quan điểm của nó là “một report là tập hợp các claim, không phải bằng chứng”. Nó thu thập các claim từ report đã hoàn tất, xác lập ground truth từ git diff và git status, chạy lại mọi bước xác minh mà report nói đã thực hiện, rồi tìm một danh sách gian lận được đặt tên: check bị làm yếu, hoàn tất giả, scope creep, hành động không được cấp quyền, phản bội spec và debris còn sót lại. Nó trả về VERIFIED, VERIFIED WITH CAVEATS hoặc REFUTED, đồng thời đánh dấu mọi nội dung không thể tái hiện là UNVERIFIABLE thay vì mặc định cho rằng nội dung đó đã pass. Dòng kết của installer cũng hướng đến thành phần này: “Hãy thử: mở Claude Code và nhập /fable-judge sau khi bất kỳ agent nào tuyên bố đã hoàn tất công việc.”

fable-domain tạo các domain adapter bundle có trap fixture và smoke eval. Tám adapter được phát hành: marketing, research, data analysis, business and ops, finance, legal and compliance, design and UX và devops. Medical và clinical được chủ ý để trống, không có adapter.

Những phần nào có thể chuyển sang model khác, và phần nào không

Repo trả lời trực tiếp điều này bằng AGENTS.md, mở đầu bằng câu: “Phiên bản portable cho mọi coding agent hoặc harness (Codex, Cursor, aider, raw system prompt). Phương pháp giống hệt SKILL.md; dán file này vào phần hướng dẫn của agent hoặc đặt nó ở root của repo với tên AGENTS.md.” File này dài khoảng 2,600 từ và giữ nguyên các bước kiểm soát, bước thực hiện và mode. Nếu bạn đã dùng các file hướng dẫn ở root của repo, quy ước AGENTS.md và HUMAN.md sẽ cho biết file đó đặt ở đâu và ai đọc nó.

Có 2 phần chuyển đổi khá dễ. Nội dung phương pháp là một prompt có thứ tự, không chứa code phụ thuộc model, nên mọi model làm theo instruction đều có thể thực hiện. Luận điểm được repo nêu ra là công sức cần bỏ ra tỷ lệ nghịch với tier của model. Judge cũng có thể chuyển đổi, miễn là agent có shell và một repository, vì mọi thao tác của nó chỉ là git diff cộng với việc chạy lại các command mà người đọc cũng có thể chạy.

Có 1 phần không chuyển đổi hoàn toàn được. fable-loop giả định harness có thể spawn các subagent song song và điều phối chúng đến những model khác nhau. Agent không có subagent sẽ chạy các stage tuần tự trên một model, làm mất tính song song và khoản tiết kiệm chi phí vốn là lý do thiết kế này được đưa ra. Phần còn lại chỉ là fable-method với thêm thuật ngữ.

Có 2 chi tiết nhỏ phụ thuộc vào harness và dễ bị bỏ sót. Trigger /fable-method là một slash command của Claude Code, nên trên harness khác, bạn phải gọi phương pháp này bằng cách mô tả nó. Còn phần mô tả frontmatter SKILL.md cho phép agent chỉ load phần body khi nó khớp với task, nghĩa là một skill đã cài gần như không tốn chi phí cho đến khi được kích hoạt. Nếu thay vào đó bạn dán AGENTS.md vào system prompt, 2,600 từ đó sẽ nằm trong mọi request bạn gửi, dù task chỉ là sửa một typo trên một dòng hay refactor. Đây là khác biệt chi phí thực tế, và cũng là phần lớn lý do skill được đóng gói theo cách này.

Cách A/B trên VPS: cùng một tác vụ, chạy hai lần

Thiết lập hai bản sao làm việc giống hệt nhau để lần chạy này không nhìn thấy các chỉnh sửa của lần chạy kia. Thay YOUR_ORG/YOUR_REPO bằng repository bạn muốn kiểm thử; hai bản clone phải bắt nguồn từ cùng một commit.

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

Chọn một tác vụ có kết quả quan sát được mà không phụ thuộc ý kiến: một test đang fail và phải pass, hoặc một script phải thoát với mã 0. Tác vụ mơ hồ sẽ cho kết quả so sánh mơ hồ, vì bạn sẽ phải chấm phần mô tả thay vì kết quả.

Chạy nhánh control bằng --bare. Tùy chọn này bỏ qua việc tự động phát hiện hooks, skills, plugins và CLAUDE.md. Đây là yếu tố biến nó thành control: các skills bạn đã cài trước đó không thể bị nạp vào. Chế độ bare không dùng thông tin đăng nhập subscription của bạn, nên trước tiên hãy đặt API key từ Claude Console.

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

Nhánh method dùng cùng command nhưng thêm một flag để nạp method portable dưới dạng phần bổ sung của system prompt:

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

Cùng binary, cùng model, cùng tools, cùng cây thư mục ban đầu. Chỉ khác một flag. Đây là điều kiện duy nhất để phép so sánh có ý nghĩa.

Thiết kế này đo lường nội dung của method. Nó không đo lường cách đóng gói skill, vì đó là một vấn đề riêng. Để đo cách đóng gói, bỏ --bare, cài các skills như trên và đặt tên skill bên trong chuỗi prompt, vì các skills do người dùng gọi sẽ được mở rộng ở chế độ print: claude -p "/fable-method $task". Hãy dự kiến profile chi phí sẽ khác với nhánh dùng system prompt, ngay cả khi hành vi quan sát được trông giống nhau.

Đếm số bước và chi phí

Cả hai lần chạy đều ghi một chuỗi sự kiện JSON. Dòng cuối là một thông báo result chứa văn bản cuối cùng, chi phí và metadata của session. Hãy in dòng này một lần và đọc nó trước khi viết script xử lý, vì tên field thay đổi giữa các bản phát hành của Claude Code.

tail -1 ~/ab/control.jsonl | jq .

Chi phí mỗi lần chạy lấy từ dòng đó. Đây là giá trị cần dùng để so sánh:

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

Số bước thực hiện được tính bằng cách đếm các lần gọi tool trong cùng file:

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

Chạy lệnh đó cho cả hai file. Hình dạng của chênh lệch cho bạn nhiều thông tin hơn tổng số. Nếu một lần chạy theo method đọc nhiều file hơn và sửa ít file hơn, nó đang làm đúng theo yêu cầu của method; đó là đánh đổi bạn đang chấp nhận. Nếu một lần chạy theo method tạo ra cùng số thay đổi nhưng tốn thêm 40% chi phí, thì task đó không nhận được lợi ích gì.

Có 2 lưu ý về các con số. Thứ nhất, đừng cộng các giá trị output_tokens trong transcript của session dưới ~/.claude/projects/ rồi coi đó là tổng chi phí: các block usage theo từng message là snapshot được ghi trong quá trình streaming và đã có các báo cáo cho thấy chúng bị đếm thiếu. Dòng result là giá trị cần tin cậy. Thứ hai, chạy mỗi bên 1 lần chỉ là một quan sát đơn lẻ, vì vậy hãy chạy mỗi bên 3 hoặc 4 lần trên cùng một task trước khi kết luận về một chênh lệch; ngay cả 2 lần chạy của cùng một agent trên cùng một task cũng đã có thể khác nhau. Để theo dõi chi phí trong thời gian dài hơn, các tool theo dõi chi phí Claude Code và cách Claude Code đếm token giải thích vì sao các dòng cache chi phối tổng số thô.

Đảm bảo agent không thể truy cập bất kỳ tài nguyên nào bạn cần bảo vệ khi chạy unattended. chạy Claude Code an toàn trên VPS trình bày về user account và các permission flag.

Đánh giá của chính repo, đọc một cách thẳng thắn

Tiêu đề README là “Mười lăm vòng eval, hơn 260 lần chạy agent, các LLM judge xác minh bằng cách diff và thực thi”. Đây là nhiều bằng chứng hơn hầu hết các skill repo cung cấp, và eval/RESULTS.md được ghi lại theo từng vòng, giữ nguyên cả các lần thất bại. Tuy vậy, khi xem từng ô dữ liệu phía sau các hàng được nêu trong tiêu đề, bạn sẽ thấy phần đánh giá này ít dày hơn con số tiêu đề gợi ý.

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

Hàng lớn nhất trong số 4 hàng đó dựa trên 4 lần chạy. Ba hàng còn lại mỗi hàng dựa trên 2 lần chạy. Chính repo cũng nói rõ điều này trong phần giới hạn cố định ở đầu log: “n nhỏ xuyên suốt (1-4 lần chạy mỗi ô), LLM judge (mù khi so sánh nhiều output, nhưng chạy trên cùng frontier model được dùng làm baseline), fixture tổng hợp, ground truth nghiên cứu chỉ cập nhật đến ngày chạy.” Và nói trực tiếp hơn: “Log này tồn tại để kiểm thử các thay đổi về phương pháp, không phải để ai đó nhầm nó với một benchmark.”

Hãy ghi nhận điểm này. Tác giả công khai n của mình và nêu rõ vấn đề judge được xây dựng trên cùng model đang đóng vai trò baseline. Đây là mức trung thực cao hơn thông lệ trong nhóm này. Hãy xem các con số là bằng chứng cho thấy tác giả thực sự đã chạy thử và giữ lại các lần thất bại. Chỉ A/B test trên codebase của bạn mới cho biết tình hình thực tế.

README cũng nói rõ phương pháp này không giúp được gì ở đâu, và đó là đoạn hữu ích nhất. README ghi nhận không có mức cải thiện nào đối với các tác vụ nhỏ thông thường trên những model đủ mạnh. README nêu rằng “phương pháp này không thể làm cho kiến thức của model mới hơn; frontier model vượt trội trong các tác vụ nghiên cứu nặng về kiến thức khi chạy trực tiếp”. README cũng xác định giá trị chỉ nằm ở “các tình huống dễ mắc lỗi (xung đột về authority, tuyên bố hoàn tất giả, executor yếu, các lần chạy không có người theo dõi), chứ không phải ở mọi nơi”. Nếu công việc với agent của bạn chỉ là các chỉnh sửa nhỏ trên một model mạnh và bạn đang theo dõi, hãy kỳ vọng không đo được bất kỳ khác biệt nào. Nếu đó là một model rẻ hơn chạy không có người theo dõi, khoảng cách mới có khả năng xuất hiện. Vì vậy, việc chọn giữa Opus, Sonnet và Haiku cũng là một phần của cùng quyết định đó.

Khi phần đóng gói mang tính sao chép máy móc

Có bốn điểm cần phê bình, nhưng không điểm nào là lý do để bỏ qua repo.

Cách đặt vấn đề đi xa hơn bằng chứng. “Claude Fable 5 hoạt động như thế nào” là tuyên bố về nội bộ của một model mà không ai bên ngoài Anthropic có thể xác minh. Chính câu cốt lõi trong repo cũng làm suy yếu tuyên bố đó: “Chất lượng nằm ở cấu trúc, bằng chứng và sự trung thực, không nằm ở model.” Nếu chất lượng nằm ở cấu trúc thì câu chuyện về nguồn gốc chỉ là phần trang trí. Quy trình này tự đứng vững và không cần một huyền thoại về nguồn gốc.

Bốn skill có phần bề nổi nhiều hơn nhu cầu thực tế của nội dung. fable-loop lặp lại phần lớn fable-method, chỉ thêm lớp orchestration, và trên một harness không có subagent thì nó rút gọn thành fable-method. Hãy đọc hai file cạnh nhau trước khi cài cả hai.

Tám domain adapter tạo ra độ bao phủ mà bài eval không kiểm tra. Chỉ có hai trong tám adapter xuất hiện trong log: marketing ở round 9 và devops ở round 12. Các adapter finance, legal, design và data được phát hành nhưng không có round nào đi kèm. Adapter cho lĩnh vực của bạn vẫn có thể tốt. Tuy nhiên, nó mới chỉ là bản nháp của tác giả, chưa phải thứ đã vượt qua một trap fixture.

Installer cũng không thống nhất với repo về những gì được phát hành: nó chỉ chép ba trong bốn skill vào ~/.claude/skills. Khoảng thiếu này nhỏ. Nhưng nó cho thấy phần đóng gói đã phát triển nhanh hơn tốc độ review, và bạn nên ghi nhớ điều đó khi quyết định áp dụng bao nhiêu phần trong một lần.

Những điều cần giữ lại nếu không giữ gì khác

Loại bỏ phần nhận diện thương hiệu, còn lại bốn quy tắc vẫn có thể áp dụng độc lập, bất kể bạn chạy agent nào.

• Trích dẫn ủy quyền. Hành động không thể hoàn tác hoặc tác động ra bên ngoài cần chính lời của người dùng, được ghi rõ dưới dạng một dòng AUTH:. Agent không tìm thấy trích dẫn thì không được thực hiện hành động.
• Kiểm tra kép. Sau khi sửa một lỗi, hãy tìm trong toàn bộ project cùng cấu trúc sai đó và báo cáo số lượng, kể cả khi kết quả là zero.
• Xác minh bằng quan sát. Một targeted check báo xanh trên một bản build đang hỏng là xác minh thất bại, không phải đạt.
• Báo cáo ưu tiên kết quả, đồng thời nêu rõ những gì đã bỏ qua hoặc chưa được xác minh như một caveat, thay vì âm thầm loại bỏ.

Bạn không tốn gì để áp dụng bốn quy tắc này và có thể dùng grep để kiểm tra việc tuân thủ. Hãy bắt đầu từ đó, đo bằng harness ở trên, rồi quyết định phần còn lại của repo có xứng đáng chiếm một phần context budget của bạn hay không. Nếu muốn cung cấp cho agent context dự án cố định thay vì một phương pháp làm việc, một file DESIGN.md mà agent đọc trước khi chỉnh sửa là bước bổ sung phù hợp.

FAQ

Phương pháp Fable có hoạt động với các model khác ngoài Claude không?

Phần nội dung của phương pháp thì có. Đây là một prompt có thứ tự, không chứa code dành riêng cho model, và repo cung cấp AGENTS.md dưới dạng bản portable để dùng với Codex, Cursor, aider hoặc prompt hệ thống thuần. Có 2 thứ không dùng được ở nơi khác. Các trigger /fable-method và /fable-judge là slash command của Claude Code, nên ở môi trường khác bạn gọi phương pháp bằng cách mô tả nó. Còn fable-loop giả định harness có thể tạo các subagent chạy song song trên những model khác nhau; nếu không có khả năng đó, phương pháp sẽ chạy tuần tự và cho bạn fable-method với nhiều bước hơn.

Chạy các skill này có tốn thêm token không?

Có, và mức tăng phụ thuộc vào cách bạn load chúng. Khi được cài dưới dạng skill, phần nội dung chỉ được load khi description khớp với task, nên request không liên quan gần như không tốn thêm gì. Nếu dán vào system prompt, khoảng 2,600 từ của AGENTS.md sẽ đi kèm trong mọi request. Bản thân lần chạy cũng tốn thêm, vì phương pháp yêu cầu định hướng trước khi chỉnh sửa, thu thập bằng chứng trước khi quyết định và thực hiện verification thực tế sau đó. Hãy đo trực tiếp: chạy cùng một task với --output-format json ở cả 2 nhánh rồi so sánh trường total_cost_usd.

Tôi nên cài phiên bản nào của fable-method, và tại sao phải pin phiên bản?

Chạy git checkout v1.4.0 trước khi cài. Tag đó có ngày 2026-07-15 và vẫn là bản mới nhất tính đến tháng 8 năm 2026. Repo đã phát hành 5 release trong 9 ngày trước đó, và v1.4.0 đã thay đổi chính các routing rule. Nếu theo dõi main trong lúc đo, control run và test run có thể đọc các instruction khác nhau, khiến kết quả so sánh không còn giá trị. Hãy ghi lại tag cùng với kết quả.

Eval trong repo có phải là benchmark đáng tin cậy không?

Hãy xem nó là change log của phương pháp, đúng như tác giả gọi: "Log này tồn tại để kiểm thử các chỉnh sửa phương pháp, không phải để ai đó nhầm nó với một benchmark." Các giới hạn được nêu ở đầu file: 1 đến 4 lần chạy cho mỗi cell, fixture tổng hợp và các LLM judge được xây dựng trên cùng frontier model cũng được dùng làm baseline. Các round là có thật và những thử nghiệm thất bại vẫn được giữ lại, nhiều hơn mức mà phần lớn repo công khai. Tuy vậy, đây vẫn không phải phép đo cho biết điều gì sẽ xảy ra trên codebase của bạn, nên hãy tự chạy so sánh 2 nhánh.