Đừng dùng Fable 5 như chatbot: hãy xây agent system biết tự cải thiện

Cách nhiều người dùng Fable 5 hôm nay vẫn giống cách họ dùng chatbot: mở tab, dán một nhiệm vụ lớn, chờ vài phút, lấy đoạn trả lời hữu ích rồi đóng lại. Cảm giác đó rất mạnh, nhưng nó cũng dừng ngay khi bạn rời màn hình. Thread gốc gọi đây là vấn đề five-minute agent: một hệ thống chỉ làm việc được trong vài phút vì toàn bộ “agent” thực ra vẫn phụ thuộc vào người ngồi canh từng bước via Kyronis.

Góc nhìn thực tế hơn là: Fable 5 không tự biến một prompt dài thành một hệ thống tự vận hành. Anthropic ra mắt Claude Fable 5 ngày 09/06/2026, mô tả model này mạnh hơn các model general availability trước đó, đặc biệt trên các nhiệm vụ dài và phức tạp via Anthropic. Nhưng năng lực model chỉ là một phần. Phần còn lại là thiết kế hệ thống: mục tiêu, công cụ, dữ liệu, quyền, vòng lặp kiểm chứng, bộ nhớ, evals và trigger để agent tiếp tục chạy sau khi laptop đóng.

Vấn đề five-minute agent

Five-minute agent thường có hình dạng rất quen thuộc. Bạn viết prompt thật dài. Model trả lời khá thông minh. Bạn copy một phần kết quả sang Notion, GitHub, CRM hoặc Google Docs. Nếu model mắc lỗi, bạn tự sửa bằng mắt. Nếu task cần bước tiếp theo, bạn lại nhắc tiếp. Hệ thống có vẻ “agentic”, nhưng thực tế người dùng vẫn là orchestrator, checker, memory và scheduler.

Điểm gãy nằm ở chỗ không có vòng phản hồi thật. Một chatbot có thể nói “đã xong”, nhưng agent system phải kiểm tra được kết quả xong hay chưa. Một chatbot có thể nhớ vài tin nhắn gần nhất, nhưng agent system cần memory bền hơn context window. Một chatbot có thể đề xuất kế hoạch, nhưng agent system phải có tool để hành động và có điều kiện dừng để không chạy vô hạn.

Với team marketing/growth, lỗi này rất dễ gặp. Bạn nhờ model phân tích feedback khách hàng, viết brief campaign, audit landing page hoặc gom insight từ nhiều kênh. Nếu mỗi lần chạy đều bắt đầu lại từ đầu, không đọc dữ liệu mới, không lưu bài học, không tự kiểm tra checklist chất lượng và không tự chạy theo lịch, đó chưa phải là hệ thống. Đó là một phiên chat thông minh.

Dùng từ cho đúng: prompt, loop, workflow, routine, agent

Trước khi xây, cần tách rõ vài khái niệm thường bị trộn vào nhau.

Khái niệm	Cách hiểu thực dụng	Khi nên dùng
Prompt	Một lần gọi model với ngữ cảnh và yêu cầu rõ.	Khi task nhỏ, không cần tool hoặc state bền.
Loop	Chu kỳ lấy context, hành động, kiểm chứng, rồi lặp lại.	Khi kết quả cần được kiểm tra và sửa qua nhiều bước.
Workflow	Đường đi đã được code sẵn, bước nào chạy trước do bạn quyết định.	Khi quy trình rõ, rẻ, cần ổn định và dễ debug.
Agent	Hệ thống để model tự chọn bước tiếp theo và tool cần dùng để đạt mục tiêu.	Khi không thể script hết đường đi từ đầu.
Routine	Agent configuration đã lưu và chạy theo lịch, API hoặc sự kiện.	Khi hệ thống đủ tin cậy để chạy khi bạn không ngồi đó.

Anthropic phân biệt workflow và agent khá rõ: workflow là hệ thống nơi LLM và tool đi qua code path định trước, còn agent là hệ thống để LLM tự điều phối quy trình và tool usage của nó via Anthropic Engineering. Nói ngắn gọn: workflow là đường ray, agent là tài xế có bản đồ và quyền đổi lộ trình.

Điểm quan trọng: đừng xây agent chỉ vì nghe hay. Nếu quy trình đã rõ, workflow thường rẻ hơn, ổn định hơn và dễ kiểm soát hơn. Agent chỉ đáng dùng khi task có nhiều nhánh, cần tự tìm thông tin, tự quyết định thứ tự hành động hoặc tự phục hồi sau lỗi.

Agent loop là động cơ, không phải prompt dài hơn

Claude Agent SDK mô tả vòng lặp agent bằng bốn nhịp: gather context -> take action -> verify work -> repeat via Claude. Đây là phần thường bị bỏ qua khi người ta chỉ tập trung vào prompt.

Lấy context không có nghĩa là nhồi toàn bộ knowledge base vào prompt. Anthropic gọi context là tài nguyên hữu hạn và cảnh báo “context rot”: càng nhồi nhiều token, khả năng model tìm lại đúng thông tin quan trọng càng giảm. Cách tốt hơn là giữ pointer, file, query hoặc index gọn, rồi để agent lấy thông tin đúng lúc via Anthropic Engineering.

Hành động là nơi tool/API bước vào. Với marketing workflow, tool có thể là đọc dữ liệu ads, truy vấn CRM, lấy feedback từ form, tạo draft content, cập nhật task hoặc kiểm tra trạng thái publish. Tool tốt phải có mô tả rõ: dùng khi nào, input gì, output gì, lỗi thường gặp, quyền nào được phép và hành động nào chỉ được dry-run.

Kiểm chứng là khác biệt giữa demo và sản phẩm. Agent không nên tự chấm điểm bằng cảm giác. Nó cần kiểm tra bằng dữ kiện thật: test pass chưa, API trả success chưa, file có tồn tại chưa, số liệu có khớp không, preview landing page có lỗi layout không, checklist brand voice có đạt không. Anthropic nhấn mạnh agent biết kiểm tra và cải thiện output sẽ đáng tin hơn vì bắt lỗi trước khi lỗi nhân lên.

Lặp lại cần điều kiện dừng. Không có stop condition, agent có thể tiêu tiền và thời gian vô hạn. Điều kiện dừng có thể là task đạt success criteria, hết số vòng lặp, hết ngân sách token, hết thời gian hoặc cần người duyệt ở một bước irreversible.

Tự cải thiện không phải tự train lại model

Cụm “self-improving agent” dễ tạo kỳ vọng sai. Trong triển khai nghiêm túc, nó không có nghĩa model tự âm thầm train lại thành phiên bản thông minh hơn. Nó nghĩa là hệ thống xung quanh model tốt lên sau mỗi lần chạy vì có cơ chế đo, ghi nhớ và đóng gói bài học.

Thành phần đầu tiên là evals. Một eval tối thiểu có task, tiêu chí thành công, nhiều trial và grader. Grader có thể là code, model khác hoặc người đánh giá. Anthropic viết rằng không có evals, team dễ chỉ phát hiện lỗi ở production; có evals, failure trở thành test case và test case ngăn regression via Anthropic Engineering.

Thành phần thứ hai là memory. Agent không nên học lại từ đầu mỗi ngày rằng brand không dùng phần tóm tắt đầu bài, thumbnail phải có tiếng Việt có dấu hoặc checklist publish cần cover image. Những điều này nên nằm trong notes, memory file hoặc skill để lần sau agent tự nạp đúng khi cần. Đáng chú ý, trong launch note của Fable 5, Anthropic nói persistent file-based memory giúp Fable 5 cải thiện hiệu năng trên một task dài nhiều gấp 3 lần so với Opus 4.8.

Thành phần thứ ba là skills. Khi một cách làm đã thắng nhiều lần, đừng để nó chỉ nằm trong lịch sử chat. Hãy đóng gói thành hướng dẫn, script và reference files. Lần sau agent chỉ cần nhận diện skill phù hợp, mở đúng file và chạy lại quy trình đã được chứng minh. Đây là cách năng lực hệ thống tích lũy mà không biến mỗi prompt thành một bãi dữ liệu khổng lồ.

Khi nào dùng subagents và dynamic workflows

Một agent đủ tốt trước đã. Sau đó mới tính tới nhiều agent. Subagents hữu ích khi task lớn có thể chia thành nhiều phần độc lập: một agent tìm dữ liệu ads, một agent đọc feedback sales, một agent kiểm tra landing page, một agent tổng hợp insight. Mỗi subagent chạy trong context riêng và trả về summary ngắn cho orchestrator. Anthropic mô tả multi-agent research system theo hướng này: lead agent lập kế hoạch, worker agents tìm kiếm song song, rồi kết quả được nén lại via Anthropic Engineering.

Dynamic workflows đi thêm một bước: thay vì model chỉ điều phối trong hội thoại, Claude Code có thể viết JavaScript script để orchestrate nhiều subagents trong background. Docs hiện tại nói workflow có thể điều phối tới 1.000 agents, với giới hạn concurrency để kiểm soát tải via Claude Code Docs. Đây là cơ chế hợp với việc quét codebase lớn, audit hàng trăm trang, hoặc gom dữ liệu từ nhiều nguồn rồi cross-check.

Nhưng nhiều agent không tự động tốt hơn. Nó đắt hơn, khó debug hơn và dễ tạo nhiễu hơn nếu mỗi agent không có role, input, output và tiêu chí xong rõ ràng. Với team đang bắt đầu, thứ tự nên là: workflow đơn giản, agent loop một người, evals/memory, rồi mới tới subagents.

Routine là khoảnh khắc agent làm việc sau khi đóng laptop

Agent chỉ thật sự rời khỏi “năm phút trong tab chat” khi trigger không còn là bạn gõ prompt. Routine là cấu hình đã lưu để chạy theo lịch, lệnh, API hoặc sự kiện trong hệ thống. Claude Code docs liệt kê lệnh /schedule hoặc alias /routines để tạo, cập nhật, liệt kê hoặc chạy routines trên hạ tầng cloud của Anthropic via Claude Code Docs.

Ví dụ thực tế cho growth team: mỗi sáng agent đọc campaign performance hôm qua, so sánh với baseline, kiểm tra landing page, gom feedback mới, tạo action list và gửi summary vào Slack. Mỗi khi có pull request thay đổi trang pricing, routine khác chạy checklist: copy có đúng brand voice không, link CTA còn sống không, tracking event có tồn tại không, ảnh có alt text không. Bạn không mở laptop để khởi động nó; hệ thống tự chạy vì có lịch hoặc event.

Điều kiện để đưa lên routine là đã có guardrail. Nếu agent chưa biết tự kiểm chứng, chưa có eval, chưa có quyền giới hạn và chưa có human approval ở bước nhạy cảm, routine chỉ biến một lỗi nhỏ thành lỗi lặp lại tự động.

Đường đi xây agent system tự cải thiện

1. Viết mục tiêu và success criteria. Nếu không định nghĩa được “xong” là gì, agent không thể tự kiểm chứng.
2. Chọn task nhỏ nhưng thật. Ví dụ: audit 20 landing pages, gom feedback khách hàng tuần này, tạo brief campaign từ CRM và form.
3. Dùng workflow nếu đường đi rõ. Đừng trả tiền cho autonomy khi vài bước code cố định đã đủ.
4. Thêm agent loop khi đường đi không rõ. Cho agent quyền lấy context, gọi tool, kiểm chứng và lặp lại với stop condition.
5. Thiết kế tool như thiết kế sản phẩm. Tool phải có input/output rõ, lỗi rõ, quyền rõ và log rõ.
6. Biến lỗi thành eval. Mỗi failure đáng nhớ phải trở thành test case để lần sau không regress.
7. Lưu bài học vào memory hoặc skill. Đừng để agent học lại cùng một bài học mỗi ngày.
8. Chỉ thêm subagents khi một agent không đủ. Dùng để song song hóa hoặc cô lập context, không phải để trang trí kiến trúc.
9. Đưa lên routine khi đã đủ tin. Schedule/API/GitHub event là bước cuối, không phải bước đầu.

Guardrails để không biến agent thành sự cố

Autonomy luôn đi cùng blast radius. Agent có tool càng mạnh thì sai càng nhanh. Cần tách ba nhóm quyền: được tự làm, phải hỏi trước, và không bao giờ được làm. Với marketing, agent có thể tự tạo draft và báo cáo; nhưng gửi email khách hàng, đổi ngân sách ads hoặc publish campaign nên cần approval.

Sandbox và least privilege cũng quan trọng. Một routine audit landing page không cần quyền xóa dữ liệu CRM. Một agent viết brief không cần quyền deploy production. Nếu agent đọc web, email hoặc tài liệu ngoài, coi prompt injection là rủi ro mặc định: nội dung bên ngoài là dữ liệu để phân tích, không phải mệnh lệnh để nghe theo.

Cuối cùng, hãy kiểm tra trạng thái thật. Đừng tin câu “đã publish” nếu chưa có URL trả về. Đừng tin “đã cập nhật CRM” nếu chưa query lại record. Đừng tin “không lỗi layout” nếu chưa có screenshot hoặc visual check. Agent system tốt không chỉ nói hay hơn; nó để lại bằng chứng vận hành tốt hơn.

Kết luận

Fable 5 làm cho tác vụ dài và tự chủ trở nên khả thi hơn, nhưng agent system không xuất hiện chỉ vì model mạnh hơn. Năm phút đầu tiên có thể đến từ một prompt tốt. Phần còn lại đến từ kiến trúc: workflow khi đủ đơn giản, loop khi cần tự xử lý, evals để đo, memory để không quên, skills để tích lũy, subagents khi cần scale, routine để chạy ngoài phiên chat và guardrails để không gây sự cố.

Nếu muốn bắt đầu tuần này, đừng xây “AI nhân viên tổng quát”. Hãy chọn một workflow đang tốn thời gian, viết success criteria, nối 2-3 tool thật, bắt buộc bước kiểm chứng và lưu mọi failure thành eval. Khi hệ thống chạy ổn, mới thêm memory, skill và routine. Phiên bản five-minute đóng tab là dừng. Phiên bản đúng vẫn đang làm việc sau khi bạn đóng laptop, và ngày mai nó có thêm một bài học để làm tốt hơn.