Phần 2 — 8 khối chuẩn của một prompt cho agent (2026)

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

← Chương trước: Phần 1 — Prompt Standard là gì và vì sao team nên quan tâm? (2026) | Mục lục Series | Chương tiếp theo: Tách Role, Rules, Workflow và Skill trong Thiết Kế Prompt Lớp (2026) →

Answer-first: Tám khối cấu trúc chuẩn bắt buộc của một agent prompt gồm Identity, Mission, Scope, Context, Tools, Execution, Constraints và Output. Cấu trúc này ngăn chặn hiện tượng trôi ngữ cảnh và khuếch đại nhiễu, bảo đảm agent thi hành đúng nhiệm vụ với định dạng đầu ra chuẩn JSON Schema được kiểm thử tự động. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Đừng bắt đầu bằng prompt dài, hãy bắt đầu bằng khung

Answer-first: Khối hoá giúp prompt parse rõ ràng hơn, review theo khối được, và mỗi khối trả lời đúng một câu hỏi mà đồng nghiệp mới sẽ hỏi. Golden rule của Anthropic: “Show your prompt to a colleague with minimal context… If they’d be confused, Claude will be too.” Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Một prompt dễ quản lý thường được chia thành các khối nhỏ. Bạn không nhất thiết phải dùng đủ tất cả ngay ngày đầu, nhưng đây là bộ khung rất thực dụng.

Tại sao là khối thay vì văn xuôi dài? Ba lý do có bằng chứng:

1. Parse rõ ràng: hướng dẫn chính thức của Anthropic khuyến nghị bọc mỗi loại nội dung trong tag riêng (<instructions>, <context>, <input>) — “reduces misinterpretation”, đặc biệt khi prompt trộn lẫn hướng dẫn, ngữ cảnh, ví dụ và input biến đổi.
2. Review được: 8 khối có nhãn diff sạch — “đổi Scope, giữ Workflow” — còn monolith văn xuôi không có đơn vị review.
3. Mỗi khối chặn một lớp lỗi đo được: generic → thiếu Identity/Mission/Output; nhồi nhàng → thiếu tách khối; confident-wrong → thiếu Fallback.

Và golden rule của Anthropic chính là test cho khung: đưa prompt cho một đồng nghiệp ít context và bảo họ làm theo — nếu họ còn bối rối thì model cũng vậy. Khối hoá giúp prompt pass bài test này một cách kết cấu — mỗi khối trả lời đúng câu hỏi mà “nhân viên mới” sẽ hỏi.

graph LR
    B1["1. Identity<br/>chặn identity drift"] --> B2["2. Mission<br/>chặn goal ambiguity"]
    B2 --> B3["3. Scope<br/>chặn scope creep"]
    B3 --> B4["4. Context<br/>chặn context rot"]
    B4 --> B5["5. Tool Policy<br/>chặn tool misuse"]
    B5 --> B6["6. Workflow<br/>chặn sai thứ tự thao tác"]
    B6 --> B7["7. Output Contract<br/>chặn format regression"]
    B7 --> B8["8. Fallback<br/>chặn confident-wrong"]

    style B1 fill:#e8f4f8,stroke:#2a7da0
    style B8 fill:#e8f8e8,stroke:#2a7da0

1. Identity

Answer-first: Identity là một đến ba câu định hình góc nhìn và giọng điệu — “Even a single sentence makes a difference” theo Anthropic. Đây là đòn bẩy rẻ nhất để lái hành vi. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Agent là ai?

Ví dụ:

• Bạn là Senior Backend Engineer
• Bạn là QA Reviewer
• Bạn là Technical Writer

Phần này giúp định hình góc nhìn và cách ra quyết định.

Một identity tốt kèm cả lý do tồn tại: Anthropic khuyến nghị giải thích động cơ đằng sau chỉ dẫn — model “smart enough to generalize from the explanation”. Và identity không nên dài: một câu của Anthropic (“You are a helpful coding assistant specializing in Python”) đã đủ để thấy sự khác biệt.

Anti-pattern: “Bạn là một AI hữu ích” — fails golden rule: nhân viên mới chỉ được nói “hãy hữu ích” vẫn sẽ hỏi lại mọi câu hỏi mà các khối tồn tại để trả lời.

2. Mission

Answer-first: Mission nêu kết quả đo được, không phải hoạt động; và phải chọn stance hành động rõ ràng — suggest hay implement, vì model nghe đúng như động từ bạn dùng. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Agent tồn tại để làm gì?

Ví dụ:

• Viết code đúng, dễ bảo trì, có test
• Review thay đổi với ưu tiên bug và regression
• Viết tài liệu dễ hiểu cho người mới

Ba quy tắc từ hướng dẫn chính thức:

1. Nêu rõ “above and beyond” nếu muốn: “Tạo dashboard phân tích” ≠ “Tạo dashboard phân tích. Bao gồm nhiều tính năng và tương tác liên quan nhất có thể.” — nếu không nói rõ, đừng kỳ vọng model tự hiểu.
2. Động từ quyết định mode hành động: “Can you suggest some changes…” cho ra gợi ý; “Change this function to improve its performance” cho ra thay đổi thật.
3. Chọn stance mặc định: aggressive (<default_to_action> — “By default, implement changes rather than only suggesting them”) hay conservative (<do_not_act_before_instructions> — “default to providing information, doing research, and providing recommendations”). Không chọn = để model đoán.

Mission giúp agent hiểu mục tiêu tổng quát, thay vì chỉ xử lý câu lệnh từng lần.

3. Scope

Answer-first: Scope liệt kê quyền hạn kiểm tra được theo tiêu chí reversibility — hành động cục bộ reversible thì làm, hành động destructive / hard-to-reverse / visible-to-others phải xin phép. Đây là chuyển “cẩn thận đấy” thành bảng quyền. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Agent được làm gì và không được làm gì?

Ví dụ:

• Được đọc code, sửa code, chạy test cục bộ
• Không được tự ý đổi schema breaking
• Không được xoá file khi chưa có xác nhận

Đây là phần rất quan trọng để tránh vượt quyền. Tiêu chí phân loại lấy thẳng từ hướng dẫn agent của Anthropic:

Và một câu đáng treo tường: “When encountering obstacles, do not use destructive actions as a shortcut” — không được dùng thao tác phá huỷ để đi tắt khi gặp vướng mắc.

4. Context

Answer-first: Context chỉ nhận dữ liệu liên quan, version-pinned — và vị trí đặt cũng là quyết định đo được: data dài ở đầu prompt, query ở cuối (+30% chất lượng theo test của Anthropic), vì U-shape attention nhớ đầu-cuối, quên giữa. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Ngữ cảnh dự án là gì?

Ví dụ:

• Stack là Go, Kratos, PostgreSQL, Redis
• Kiến trúc là Clean Architecture
• Handler phải mỏng, logic nằm ở biz layer

Nếu thiếu context, agent có thể đề xuất cách làm đúng về mặt chung nhưng sai với codebase thực tế.

Hai quy tắc vị trí có số liệu:

1. Data dài ở đầu: “Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples. This improves performance across all models.”
2. Query ở cuối: “Queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs.”

Cơ chế nền: Lost in the Middle (TACL 2023) — recall cao ở đầu và cuối context, suy giảm ở giữa. Bố cục data-đầu/query-cuối đỗ mỗi loại nội dung đúng chỗ attention mạnh nhất.

Với tài liệu nhiều bản, bọc mỗi document trong <document index="n"> kèm <source> và <document_content> — provenance đi cùng dữ liệu.

Với kế toán, context cũng rất quen thuộc:

• đây là báo cáo nội bộ hay báo cáo gửi thuế
• số liệu lấy từ ERP, Excel hay sao kê ngân hàng
• kỳ đối soát là ngày, tuần hay tháng

Không có context, AI rất dễ “đúng câu chữ nhưng sai tình huống”.

5. Tool Policy

Answer-first: Tool Policy nói rõ tool nào, khi nào, với cap nào — vì “agents are only as effective as the tools we give them”: ít tool consolidate hơn nhiều tool rải rác, response cần cap token, và error message cũng là prompt engineering. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Nếu agent có tool, phải nói rõ:

• Tool nào nên dùng trước
• Tool nào chỉ dùng khi cần
• Trường hợp nào phải xin phép

Bằng chứng định lượng từ bài engineering “Writing effective tools for agents” (Anthropic, 9/2025):

1. Consolidate thay vì bọc API: thay vì list_users + list_events + create_event, làm một schedule_event; thay vì read_logs, làm search_logs chỉ trả dòng liên quan. “Too many tools or overlapping tools can also distract agents.”
2. Cap response: Claude Code giới hạn tool response 25.000 token mặc định — policy của bạn nên định cap, pagination, truncation kèm hướng dẫn.
3. Concise vs detailed: enum response_format — response chi tiết 206 token, concise 72 token ("~⅓ of the tokens").
4. Ngôn ngữ tự nhiên thay vì ID rác: giải UUID thành tên ngữ nghĩa “significantly improves Claude’s precision in retrieval tasks by reducing hallucinations”.
5. Error là prompt engineering: “prompt-engineer your error responses to clearly communicate specific and actionable improvements” — vụ web search: model gắn “2025” vào query cho tới khi tool description được sửa.
6. Namespacing: asana_search vs jira_search giúp agent chọn đúng tool; prefix vs suffix “non-trivial effects on our tool-use evaluations”.
7. Và chi phí refactor description: “Claude Sonnet 3.5 achieved state-of-the-art performance on the SWE-bench Verified evaluation after we made precise refinements to tool descriptions” — Tool Policy quality nhìn thấy được ở benchmark.

6. Workflow

Answer-first: Workflow là các bước đánh số khi thứ tự quan trọng, mỗi bước kết thúc bằng điều kiện kiểm tra được, và kết thúc bằng bước self-check — nhưng bound outcome thay vì over-specify reasoning, vì “Claude’s reasoning frequently exceeds what a human would prescribe”. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Đây là quy trình mặc định mà agent nên đi theo.

Ví dụ:

1. Hiểu hiện trạng
2. Xác định phạm vi ảnh hưởng
3. Chọn cách sửa nhỏ nhất
4. Thực hiện thay đổi
5. Kiểm tra
6. Báo cáo kết quả và rủi ro còn lại

Workflow giúp output bớt ngẫu hứng. Bốn quy tắc tinh chỉnh:

1. Đánh số khi thứ tự/quan trọng: “Provide instructions as sequential steps using numbered lists when the order or completeness of steps matters.”
2. Completion criteria mỗi bước: mỗi bước kết thúc ở điều kiện kiểm tra được (“mọi model đã đổi đều có trong danh sách” thắng “lập danh sách thay đổi”).
3. Bước cuối là self-check: “Before you finish, verify your answer against [test criteria]” — bắt lỗi đáng tin cho coding và math.
4. Bound outcome, không prescribe reasoning: “Prefer general instructions over prescriptive steps” — over-prescribe gây over-verification và tốn token trên model mới.

Với task dài: state có cấu trúc (JSON dạng tests.json với status/passing/failing) + progress note tự do (progress.txt) + git làm backbone state — “Claude’s latest models perform especially well in using git to track state across multiple sessions.”

7. Output Contract

Answer-first: Output Contract là parse contract: downstream đọc cấu trúc, không đọc văn xuôi. Nói positively (“hãy viết prose mượt”), match style prompt với style output, và nhớ: prefill đã chết từ model 4.6 (400 error) — contract là cơ chế duy nhất còn lại. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Agent phải trả kết quả theo format nào?

Ví dụ:

• Review thì findings phải đứng trước
• Coding task thì phải nêu file đã đổi và kết quả verify
• Extraction task thì chỉ trả JSON theo schema

“Rất nhiều lỗi tưởng là ‘model dở’ thật ra chỉ là vì team không nói rõ output contract.”

Bốn quy tắc từ hướng dẫn chính thức:

1. Nói điều nên làm: thay “Đừng dùng markdown” bằng “Trả lời bằng các đoạn văn xuôi mượt mà.”
2. XML format indicator: “Write the prose sections of your response in <smoothly_flowing_prose_paragraphs> tags.”
3. Prompt style lây sang output: “removing markdown from your prompt can reduce the volume of markdown in the output” — muốn output thế nào thì viết prompt theo thế đó.
4. Prefill đã deprecated: từ model 4.6, prefilled response trả lỗi 400 — migration path là Structured Outputs / enum trong tool; “newer models can reliably match complex schemas when told to.”

Với người làm kế toán, đây là phần cực kỳ quen:

• trả ra bảng 3 cột hay 5 cột
• có cần mã chứng từ không
• có cần ghi nguyên nhân chênh lệch không
• có cần tách “đã xác minh” và “chưa đủ dữ liệu” không

Và nhớ phát biểu cuối: kill preamble bằng chỉ dẫn trực tiếp — “Respond directly without preamble. Do not start with phrases like ‘Here is…’, ‘Based on…’, etc.”

8. Fallback / Uncertainty Policy

Answer-first: Fallback biến hành vi an toàn nhất đo được — abstention — thành điều khoản: thiếu dữ liệu thì hỏi, không đủ căn cứ thì nói mức chắc chắn, hành động rủi ro thì xin phép. Nhóm Claude ít hallucinate nhất chính vì biết chối trả lời khi mơ hồ (Chroma, 7/2025). Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Khi không chắc thì agent phải làm gì?

Ví dụ:

• Nếu yêu cầu mơ hồ và ảnh hưởng lớn, hãy hỏi lại
• Nếu thiếu thông tin nhưng có thể giả định an toàn, cứ làm và nêu giả định
• Nếu không đủ dữ liệu để kết luận, nói rõ mức độ chắc chắn

Phần này giúp giảm kiểu trả lời sai nhưng rất tự tin.

Cơ chế đo được: trong kiểm nghiệm distractor của Chroma (18 model), nhóm Claude có hallucination rate thấp nhất chính vì abstain khi mơ hồ; nhóm GPT hallucinate nhiều nhất vì trả lời bằng mọi giá. Fallback block biến hành vi an toàn đó thành nghĩa vụ hợp đồng.

Trong ngôn ngữ kế toán, phần này tương đương với quy tắc:

• thiếu chứng từ thì không kết luận
• không khớp số thì phải đánh dấu chờ đối soát
• chưa đủ căn cứ thì không tự hạch toán

Ba quy tắc fallback chốt toàn bộ không gian:

1. Thiếu dữ liệu bắt buộc → hỏi/flag, không đoán
2. Ngoài phạm vi → từ chối kèm lý do và route đúng chỗ
3. Không chắc chắn → ghi rõ mức confidence trong output (machine-parseable → downstream tự route sang human review)

Một prompt tối thiểu trông như thế nào?

Answer-first: Template 7 dòng dưới đây đủ cấu trúc cho task review — và quy tắc bỏ khối giữ cho nó tối thiểu: không tool thì bỏ Tool Policy, format rủi ro thấp thì bỏ Examples. Khung là checklist, không phải nghi lễ. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

# Identity
Bạn là senior reviewer.

# Mission
Ưu tiên phát hiện bug, regression và rủi ro production.

# Scope
Không nhận xét lan man về style nếu không ảnh hưởng chất lượng.

# Context
Đây là Go microservices theo Clean Architecture.

# Workflow
Đọc diff, xác định rủi ro, nêu findings theo severity.

# Output Contract
Trả findings trước, mỗi finding có file reference.

# Uncertainty
Nếu không đủ context để kết luận, nêu giả định rõ ràng.

Prompt này chưa dài, nhưng đã có cấu trúc.

Quy tắc bỏ khối (giữ tối thiểu đúng nghĩa):

• Tool Policy: chỉ thêm khi agent có tool
• Examples: thêm khi cần anchor format/tone — 3–5 ví dụ “for best results”, relevant + diverse, bọc trong <example> tags
• Identity/Mission: luôn có — đây là khung tối thiểu

Và theo thông lệ 2027: định nghĩa đày đủ mỗi khối bằng XML (<block_1_identity>…<block_8_fallback>) khi prompt vào production path — bản đặc tả đầy đủ với Go/Python struct nằm ở bản tiếng Anh: The 8 Core Blocks.

Production failure: khối nào gãy thì sửa khối đó

Answer-first: Khi output xấu, các khối cho phép chẩn đoán theo tầng: sai góc nhìn → Identity; làm quá/toàn quyền → Scope; sai format → Output Contract; đoán bừa → Fallback. Không có khối = chẩn đoán không thể, sửa mù. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Vòng chẩn đoán-hàn gắn đóng lại bằng eval, không phải bằng cảm giác “nhìn ổn”:

graph TD
    SYM["Output xấu:<br/>symptom cụ thể"] --> DIAG["Chẩn đoán theo bảng:<br/>symptom → khối thiếu/sai"]
    DIAG --> EDIT["Sửa đúng khối,<br/>diff một dòng"]
    EDIT --> RV["Prompt-PR review:<br/>ai đó kiểm tra khối đã sửa"]
    RV --> EVAL["Chạy golden dataset:<br/>pass-rate >95%?"]
    EVAL -->|"PASS"| SHIP["Merge vào production"]
    EVAL -->|"FAIL"| DIAG

    style SHIP fill:#e8f8e8,stroke:#2a7da0
    style EVAL fill:#e8f4f8,stroke:#2a7da0

Scenario: review bot đột nhiên bắt đầu nhận xét style lan man. Không có khối, team sửa mù — thêm “đừng nói lan man” vào giữa prompt. Có khối, chẩn đoán là 30 giây: Scope block thiếu câu chặn style-comment; sửa đúng khối, diff review một dòng, golden dataset xác nhận không hồi quy.

Cấu trúc này cũng là hướng dẫn debug: mỗi lớp lỗi có tên khối của nó.

Ý chính cần nhớ

Answer-first: Prompt tốt không cần phức tạp — chỉ cần đủ rõ, đủ trật tự, đủ nhất quán để agent biết cách làm việc; và 8 khối là bản đồ: mỗi triệu chứng output trỏ về đúng một khối. Điều kiện tiên quyết: Đã hoàn thành Phần 1 và hiểu nguyên lý vận hành của bộ nhớ đệm prompt (prompt caching) trên các mô hình ngôn ngữ lớn.

Một prompt tốt không nhất thiết phải phức tạp. Nó chỉ cần đủ rõ, đủ có trật tự, và đủ nhất quán để agent biết cách làm việc.

Ba con số đáng mang đi:

• 30% — mức cải thiện chất lượng khi query đặt cuối prompt với data dài (Anthropic test)
• 25.000 — token cap mặc định cho tool response (Claude Code)
• 3–5 — số ví dụ chuẩn cho Examples block (Anthropic: “Include 3–5 examples for best results”)

Ở phần tiếp theo, chúng ta sẽ bàn về một kỹ thuật rất thực dụng: tách prompt thành nhiều lớp để đỡ rối và dễ bảo trì hơn.

🔗 Đọ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 1 — Prompt Standard là gì và vì sao team nên quan tâm? (2026)
• Series: MCP Engineering In Production — nơi Tool Policy gặp hạ tầng MCP thật
• Kiến trúc Microservices Golang & DDD

❓ 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-2-core-blocks-100-rounds.{md,json} (dossier nội bộ series, mirror cả 2 repo).

← Chương trước: Phần 1 — Prompt Standard là gì và vì sao team nên quan tâm? (2026) | Mục lục Series | Chương tiếp theo: Tách Role, Rules, Workflow và Skill trong Thiết Kế Prompt Lớp (2026) →