Tách Role, Rules, Workflow và Skill trong Thiết Kế Prompt Lớp (2026)

📖 Bản tiếng Anh (English Edition)

← Chương trước: Phần 2 — 8 khối chuẩn của một prompt cho agent (2026) | Mục lục Series | Chương tiếp theo: Từ prompt cảm tính sang prompt có thể test và version (2026) →

Answer-first: Kiến trúc prompt 4 lớp phân tách Role toàn cục, Rules bảo vệ, Workflow quy trình và Skill tác vụ theo ranh giới bộ nhớ đệm. Thiết kế phân tầng giúp tăng tỷ lệ hit cache lên hơn 85%, giảm 70% chi phí gọi token và bảo vệ vững chắc các quy tắc an toàn cốt lõi. Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

Vì sao một prompt duy nhất thường trở nên quá tải?

Answer-first: Monolith prompt có 3 vấn đề cộng dồn: dài (context rot đo được trên 18 model — càng dài càng sai), khó sửa, và edit-coupling — sửa phần task dễ âm thầm gãy quy tắc an toàn cùng chuỗi. Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

Lúc mới bắt đầu, nhiều team hay gom mọi thứ vào một file:

• agent là ai
• phải cư xử thế nào
• quy định an toàn
• quy trình làm việc
• hướng dẫn cho từng loại task

Ban đầu có vẻ tiện. Nhưng càng dùng lâu, prompt càng có 3 vấn đề — và cả ba đều đo được:

1. Dài là tụt chất lượng: nghiên cứu context rot (Chroma, 7/2025, 18 model SOTA) cho thấy hiệu suất suy giảm phi tuyến theo độ dài input kể cả task trivial — chiều dài monolith tự nó là rủi ro chất lượng.
2. Khó sửa: không có đơn vị review — một khối văn xuôi 300 dòng không diff được theo từng concern.
3. Sửa chỗ này gãy chỗ khác: khi quy tắc an toàn và chỉ dẫn task chung một chuỗi, một lần chỉnh task-level có thể âm thầm phá hỏng quy tắc an toàn — đây là lý do tồn tại của lớp Rules tách biệt.

Giải pháp tốt hơn là tách lớp.

Mô hình 4 lớp rất dễ áp dụng

Answer-first: Bốn lớp tách theo tần suất thay đổi: Role (hiếm khi đổi), Rules (bất biến, security sở hữu), Workflow (mỗi họ task), Skill (chuyên sâu domain, load khi trigger) — mỗi lớp một owner, một file, một chu kỳ thay đổi riêng. Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

1. Role

Role trả lời: agent đang đóng vai gì?

Ví dụ: Backend Developer, Reviewer, DevOps, Technical Architect.

Role nên chứa: identity, trách nhiệm, quyền quyết định, phong cách giao tiếp.

2. Rules

Rules là các điều bất biến.

Ví dụ:

• không sửa file generated bằng tay
• không dùng lệnh phá huỷ
• không bịa test result
• không lộ secrets

Rules ngắn, rõ, ít thay đổi — và do security sở hữu riêng.

3. Workflow

Workflow là trình tự xử lý một loại công việc: debug-issue, architecture-planning, deep-review, quick-docs. Workflow giúp agent không bỏ sót bước.

4. Skill

Skill là hướng dẫn chuyên sâu cho một loại task/domain cụ thể: add-api-endpoint, add-event-handler, write-tests, review-service. Skill chỉ load khi task thật sự phù hợp — trigger words front-load, body load just-in-time.

Nếu nhìn từ góc độ kế toán:

• role giống vai trò “kế toán thanh toán” hay “kế toán tổng hợp”
• rules giống nguyên tắc không được bỏ qua chứng từ
• workflow giống quy trình chốt công nợ hay đối soát cuối tháng
• skill giống hướng dẫn riêng cho nghiệp vụ hoàn tiền, đối soát ví điện tử, hay kiểm tra VAT

Sơ đồ phân lớp và quyền sở hữu:

graph TD
    subgraph Stack ["Stack phân lớp (assembled theo thứ tự cố định)"]
        L1["L1 — Role<br/>identity, trách nhiệm<br/>owner: platform team<br/>đổi: hiếm"] --> L2["L2 — Rules<br/>bất biến, guardrails<br/>owner: security<br/>đổi: hiếm"]
        L2 --> L3["L3 — Workflow<br/>SOP per task family<br/>owner: team lead<br/>đổi: theo quý"]
        L3 --> L4["L4 — Skill<br/>domain sâu<br/>owner: domain owner<br/>đổi: liên tục"]
    end
    L4 --> T["Task input<br/>(volatile — sau breakpoint cuối)"]

    style L1 fill:#e8f4f8,stroke:#2a7da0
    style L2 fill:#e8f4f8,stroke:#2a7da0
    style T fill:#f8f8e8,stroke:#a0a02a

Bằng chứng mới: phân lớp là hợp đồng chi phí

Answer-first: Prompt caching của Anthropic định giá trực tiếp sự ổn định lớp: cache read = 0.1× giá input thường, write 1.25× (TTL 5 phút), tối đa 4 breakpoint, và invalidation cascade tools → system → messages — đổi tool definition làm vô hiệu toàn bộ cache phía sau. Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

Kiến trúc phân lớp từng là trực giác. Giờ nó là dòng chi phí:

Công thức break-even đơn giản: prefix ổn định tái sử dụng N lần thì chi hiệu dụng ≈ 1.25× + N×0.1× so với N×1.0× không cache — hòa vốn từ ~2 lần tái sử dụng, và tại 10 lần tái sử dụng, chi phí prefix giảm ~90%. (Suy luận số học từ pricing multiplier — tính lại theo giá model và hình thái conversation của bạn.)

Và bảng invalidation là lời cảnh báo lớn nhất: cache theo hierarchy tools → system → messages — “thay đổi ở mỗi tầng vô hiệu hóa tầng đó và mọi tầng sau”. Đổi tool definition = mất toàn bộ cache. Timestamp hay dữ liệu per-request đặt trong system = mất cache từ điểm đó. Nội dung volatile bắt buộc phải nằm cuối messages — đúng thứ tự assemble của stack: Role → Rules → Workflow → Skill → task input.

Anti-pattern được ghi chép chính thức: đặt cache_control trên block thay đổi mỗi request (timestamp, per-request context) — “No cache hit. You pay for a fresh cache write on every request.” Khắc phục: “Place cache_control on the last block whose prefix is identical across the requests” — breakpoint tại seam cuối cùng của lớp ổn định.

Lợi ích của cách tách lớp này

Answer-first: Bốn lợi ích có cơ chế: tái sử dụng (marginal cost của task thứ N chỉ còn phần skill), sửa cục bộ (một lớp một diff), đào tạo theo lớp (đọc Role trước), và chẩn đoán drift theo trục (role mơ hồ? rule thiếu? workflow thiếu bước? skill quá chung?). Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

Dễ tái sử dụng

Một reviewer role dùng chung cho nhiều repo; một Rules dùng chung cho mọi workflow — marginal cost của task thứ N chỉ còn viết phần skill.

Dễ sửa

Đổi quy trình review → sửa workflow, không đụng role hay rules — diff cục bộ, review một file, golden dataset chạy lại đúng phần ảnh hưởng.

Dễ đào tạo team

Người mới đọc theo lớp: Role trước, Rules thứ hai — thay vì đọc một file 300 dòng không có trục.

Dễ kiểm soát drift

Khi output lệch, bốn câu hỏi chẩn đoán: do role mơ hồ? do rule thiếu? do workflow chưa đủ? do skill viết quá chung? Mỗi câu trỏ về một file — bảng ánh xạ triệu chứng → lớp:

Một ví dụ gần gũi

Thay vì một prompt khổng lồ trộn mọi thứ, chia thành:

role/developer.md
rules/coding-safety.md
workflows/debug-issue.md
skills/add-api-endpoint/SKILL.md
skills/write-tests/SKILL.md

Assembly bằng code, không phải copy tay trong chat — một assembler nhỏ (script vài chục dòng) nối các lớp theo thứ tự cố định và inject biến {task_input} sau breakpoint cuối. “Biến prompt từ ‘đoạn chat tạm thời’ thành ‘hệ thống vận hành’.”

Luồng assemble và cache như vận hành thật:

graph LR
    subgraph Files ["Layer files (repo, versioned)"]
        R["role/developer.md"]
        U["rules/coding-safety.md"]
        W["workflows/debug-issue.md"]
        S["skills/add-api-endpoint/SKILL.md"]
    end
    A["Assembler<br/>(thứ tự cố định)"] --> P["Prefix ổn định<br/>tools → system → messages<br/>cache_control tại seam cuối"]
    R --> A
    U --> A
    W --> A
    S --> A
    P --> C[("KV cache<br/>read 0.1× / write 1.25×")]
    P --> M["Messages (volatile)<br/>{task_input}, timestamp<br/>— sau breakpoint cuối"]

    style C fill:#e8f8e8,stroke:#2a7da0
    style M fill:#f8f8e8,stroke:#a0a02a

Ba quy ước khi triển khai thật:

1. Thứ tự assemble là hợp đồng — cache yêu cầu prefix byte-identical: đổi cả whitespace ở một lớp cũng break hash phía sau.
2. Mọi biến per-request inject sau breakpoint cuối — timestamp, user input, retrieved data không bao giờ chạm system.
3. Mỗi file mang version riêng — stack ghi lại tuple phiên bản các lớp mỗi lần chạy; bisect hồi quy = diff tuple.

Recipe di cư từ monolith (mỗi bước một diff test riêng):

1. Cắt Role + Rules lên đầu file (phần ổn định nhất) — chạy parity so với monolith trên golden dataset.
2. Chuyển chi tiết task vào các file Skill, thu hẹp trigger words cho từng skill.
3. Giữ Workflow ở giữa; chỉ thêm breakpoint khi hai vùng ổn định đã đủ dài vượt ngưỡng cache tối thiểu.
4. Chạy song song monolith ↔ stack một tuần, cắt cutover khi parity giữ vững — strangler-fig pattern cho prompt.

Khi nào KHÔNG nên phân lớp

Answer-first: Anti-doctrine: team 2 người với 3 loại task không cần L1–L4 — một file 8 khối per task là đủ. Ngưỡng phân lớp là sự phân kỳ ownership: hai vai trò chỉnh nội dung prompt ở tần suất khác nhau → tách; không → giữ một file. Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

Phân lớp có giá thật: debug gián tiếp (hành vi trải nhiều file), đường cong onboarding (khái niệm lớp/trigger/assembly), overhead thiết kế. Quy tắc ra quyết định:

• Câu hỏi ngưỡng: “Hai vai trò có chỉnh nội dung này ở tần suất khác nhau không?” Có → tách lớp. Không → giữ một file.
• Đường lối di cư: monolith → 8 khối trong một file → tách Role+Rules khi xuất hiện task thứ hai → tách Workflow khi các họ task phân kỳ → skills khi domain sâu dần. Mỗi bước tách được trigger bởi đau, không phải bởi giáo điều.
• Cache không phải lý do phân lớp khi nhỏ: dưới 512–4,096 token (tùy model) prefix không cache được — phân lớp vì maintainability trước, vì chi phí cache khi đủ quy mô.

Và chuẩn công bố của series nói thẳng: “không nhất thiết phải dùng đủ tất cả ngay ngày đầu” — khung là checklist, không phải nghi lễ.

Production failure: lớp đổi, cache mất

Answer-first: Mode thất bại đo được: một bản cập nhật Rules với “chỉ sửa wording” làm mọi conversation trong 5 phút mất hit prefix — chi phí cache write 1.25× nổ lên mà không ai nhìn usage fields. Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

Scenario: security team “improve wording” trong file Rules — diff nhỏ, review nhanh, merge. Trong 5 phút tiếp theo, mọi request viết lại cache prefix mới ở giá 1.25× thay vì đọc 0.1×. Không ai nhìn cache_creation_input_tokens cho tới cuối tháng — hóa đơn token tăng 20% không giải thích được.

Bài học vận hành: thay đổi lớp ổn định là sự kiện có giá, không phải cosmetic edit:

1. Usage fields (cache_creation_input_tokens, cache_read_input_tokens, input_tokens) là dashboards bắt buộc khi vận hành stack.
2. Thay đổi Rules lên lịch off-peak hoặc dùng chiến lược hai breakpoint (cũ + mới song song trong window chuyển tiếp).
3. Diff review lớp ổn định phải hỏi thêm: “sự thay đổi này có đáng làm invalidate toàn bộ prefix không?”

Quan sát stack bằng usage fields

Answer-first: Ba trường usage — cache_creation_input_tokens, cache_read_input_tokens, input_tokens — là dashboard vận hành của stack: tổng = read + creation + input, và hai trường cache cùng bằng 0 nghĩa là prompt không đủ ngưỡng cache (không có error nào báo trước). Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

Cách đọc ba con số này thành chỉ số lớp:

Cụ thể công thức xác minh của nhà cung cấp: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens — phần input_tokens chỉ đếm token sau breakpoint cuối, không phải toàn bộ input. Một request 100.000 token cache + 50 token message mới có input_tokens: 50 — hóa đơn rẻ vì prefix đã hit.

Đây cũng là lý do stack phân lớp cài đặt được câu trả lời cho câu hỏi quản trị “chi phí AI của team đi đâu”: hit rate prefix theo layer file, chi phí write theo lần đổi lớp, chi phí volatile theo task — ba dòng đúng ba owner.

Ý chính cần nhớ

Answer-first: Prompt nên được tổ chức như code: có module, có trách nhiệm rõ ràng, thay thế từng phần được — và giờ có cả định giá: lớp ổn định ở prefix cache 0.1×, nội dung volatile ở đuôi, breakpoint tại ranh giới. Điều kiện tiên quyết: Nắm vững 8 khối cốt lõi từ Phần 2 và hiểu cơ chế cache breakpoint (Anthropic / OpenAI) để thiết kế tiền tố tĩnh.

Nếu team muốn dùng AI agent nghiêm túc, prompt nên được tổ chức như code:

• có module (lớp theo tần suất thay đổi)
• có trách nhiệm rõ ràng (mỗi lớp một owner)
• có thể thay thế từng phần (blast radius một lớp)

Và mới trong bản cập nhật này: sự ổn định của lớp không chỉ dễ maintain — nó rẻ hơn đo được, khi prefix cache hit trả 0.1× giá input thường.

Ở phần tiếp theo, chúng ta sẽ đi từ kiến trúc sang vận hành: cách version prompt và test prompt để biết bản nào thực sự tốt hơn. (Part 4 — Versioning & Evals)*

🔗 Đọc thêm các chuyên đề liên quan:

• Nhìn nhanh về Prompt Standard: Ghi Chú & Kiến Trúc Hệ Thống (2026)
• Phần 2 — 8 khối chuẩn của một prompt cho agent (2026)
• Kiến trúc Microservices Golang & DDD
• Series: MCP Engineering In Production

❓ Câu Hỏi Thường Gặp (FAQ)

📚 Nguồn nghiên cứu (verification anchors)

Bản nghiên cứu đầy đủ 100 rounds: reports/research-prompt-standard-part-3-layered-prompt-design-100-rounds.{md,json} (dossier nội bộ series, mirror cả 2 repo). Ghi chú grounding: 36/100 rounds có URL nguồn bên ngoài; 61/100 rounds truy vết series-internal (files series + agent-skills pack); 3 rounds gắn nhãn [INFERENCE]. Bản đặc tả đầy đủ tiếng Anh (Track 2 deep-dive, kèm Go PromptStack compiler): Layered Prompt Architecture.

← Chương trước: Phần 2 — 8 khối chuẩn của một prompt cho agent (2026) | Mục lục Series | Chương tiếp theo: Từ prompt cảm tính sang prompt có thể test và version (2026) →