Nếu bạn đã quen với ý tưởng context window (bộ nhớ làm việc của LLM — large language model, mô hình ngôn ngữ lớn) có hạn, câu hỏi tiếp theo gần như luôn là: "Vậy tôi nên nhồi cái gì vào đó?" Rất nhiều kỹ sư và cả agentic engineer (kỹ sư xây dựng AI agent) mắc lỗi coi context giống như một cái thùng chứa — càng nhét nhiều thông tin liên quan, agent càng "hiểu" vấn đề tốt hơn. Thực tế hoàn toàn ngược lại.

Context không phải là kho lưu trữ, nó là băng thông chú ý (attention bandwidth). Mỗi token bạn đưa vào không chỉ tốn tiền và tốn thời gian xử lý, nó còn cạnh tranh sự chú ý với những token khác. Một tài liệu 50 trang nhét thẳng vào context không giúp model "biết nhiều hơn" — nó làm loãng tín hiệu quan trọng giữa hàng ngàn từ không liên quan, khiến model dễ bỏ sót chi tiết then chốt, dễ bị "lost in the middle" (hiện tượng model quên thông tin nằm ở giữa context dài), và tốn một khoản token khổng lồ cho mỗi lượt gọi.

Context selection (lựa chọn context) là kỹ năng xác định chính xác — không hơn không kém — những gì model cần để hoàn thành nhiệm vụ hiện tại. Đây là bài học quan trọng nhất trong module Context Engineering, vì nó là nơi phần lớn ngân sách token bị lãng phí trong thực tế: không phải vì prompt dài, mà vì chúng ta đưa vào quá nhiều thứ "có thể liên quan" thay vì chỉ thứ "cần thiết".

Bài này dành cho mọi vai trò trong vòng đời phát triển phần mềm — developer debug với agent, QA viết test case bằng agent, product manager dùng agent để phân tích yêu cầu. Nguyên lý chọn context là như nhau, chỉ khác ở loại context cần chọn.

The Context Selection Mental Model

Câu hỏi cốt lõi: "cần" hay chỉ "có thể liên quan"?

Trước khi đưa bất kỳ đoạn thông tin nào vào context, hãy tự hỏi một câu duy nhất:

"Model có thực sự cần thông tin này để hoàn thành nhiệm vụ hiện tại không, hay tôi chỉ đang đưa vào vì nó liên quan đến chủ đề?"

Đây là ranh giới giữa hai khái niệm mà rất nhiều người nhầm lẫn:

• Relevant (liên quan): thông tin có chủ đề gần với việc đang làm. Ví dụ, toàn bộ file UserService.ts liên quan đến việc sửa bug trong hàm validateEmail().
• Necessary (cần thiết): thông tin mà nếu thiếu, model sẽ không thể hoàn thành nhiệm vụ đúng, hoặc phải đoán. Trong ví dụ trên, chỉ có hàm validateEmail(), định nghĩa type liên quan, và có thể 1-2 test case hiện có mới là cần thiết.

Rất nhiều context "liên quan" không bao giờ được model dùng tới trong câu trả lời, nhưng vẫn chiếm chỗ, vẫn bị tính phí, và vẫn góp phần làm loãng attention. Nguyên tắc thực dụng: mọi token đưa vào context phải trả lời được câu hỏi "nếu bỏ dòng này ra, agent có làm sai việc không?". Nếu câu trả lời là "không, chắc vẫn làm đúng" — bỏ ra.

Ba câu hỏi để lọc context trước khi đưa vào

1. Nhiệm vụ cụ thể là gì? Không phải "làm việc với module thanh toán" mà phải cụ thể tới mức "sửa lỗi tính sai phí giao dịch khi số lượng item bằng 0".
2. Thông tin nào là bằng chứng trực tiếp để giải quyết nhiệm vụ đó? Đây là core context.
3. Thông tin nào chỉ là bối cảnh nền, có thể tóm tắt bằng một câu thay vì đưa nguyên văn? Đây là phần cần compress (nén) hoặc loại bỏ hoàn toàn.

Ví dụ minh họa mental model

Giả sử bạn giao cho agent nhiệm vụ: "Sửa lỗi API trả về 500 khi user gửi request tạo đơn hàng với quantity: 0".

Context "có thể liên quan" mà nhiều người có xu hướng đưa hết vào:
- Toàn bộ file OrderController.ts (800 dòng)
- Toàn bộ schema database
- README của toàn bộ service
- Toàn bộ lịch sử commit của file này
- Toàn bộ tài liệu API spec (OpenAPI 3000 dòng)

Context thực sự "cần thiết":
- Hàm xử lý request tạo đơn hàng (khoảng 40 dòng)
- Định nghĩa type/interface của OrderRequest
- Đoạn code validate input (nếu có, và nếu không có — đó chính là manh mối)
- Log lỗi 500 thực tế (stack trace)
- 1 test case hiện có liên quan đến validate quantity (nếu có)

Sự khác biệt về token giữa hai cách tiếp cận có thể là 10-15 lần, nhưng chất lượng kết quả từ cách thứ hai thường tốt hơn, vì agent không phải "mò" giữa hàng trăm dòng không liên quan.

Mẹo

• Viết nhiệm vụ ra thành một câu cụ thể (như ví dụ trên) trước khi bắt đầu chọn context — nhiệm vụ mơ hồ luôn dẫn tới context selection mơ hồ.
• Khi phân vân một đoạn context có cần hay không, thử bỏ nó ra và chạy thử. Nếu kết quả agent không đổi, đoạn đó không cần thiết — lần sau bỏ luôn từ đầu.
• Tập cho mình phản xạ hỏi "cần" trước khi hỏi "có ích" — "có ích" luôn đúng với hầu hết mọi context, nhưng không phải tiêu chí để đưa vào.

Context Selection by Task Type

Không có một công thức context chung cho mọi việc. Loại nhiệm vụ quyết định loại context cần ưu tiên. Dưới đây là phân tích theo các loại nhiệm vụ phổ biến nhất trong vòng đời phát triển phần mềm.

Debug một lỗi cụ thể

Khi debug, agent cần bằng chứng thực thi, không cần toàn bộ kiến trúc hệ thống. Thứ tự ưu tiên:

1. Thông báo lỗi / stack trace đầy đủ (đây là context quan trọng nhất, đừng bao giờ tóm tắt lại nó)
2. Đoạn code trực tiếp gây lỗi (function/class chứa dòng lỗi, không phải cả file)
3. Input thực tế gây ra lỗi (request payload, dữ liệu test)
4. Các hàm được gọi trực tiếp từ đoạn code trên (1 cấp, không cần đệ quy toàn bộ call stack)

Những gì không cần: kiến trúc tổng thể hệ thống, các module không liên quan, lịch sử thay đổi cũ (trừ khi nghi ngờ regression — lúc đó chỉ cần diff của commit liên quan, không cần cả lịch sử).

Viết feature mới

Ở đây context cần thiên về pattern và convention hiện có trong codebase, để code mới nhất quán với code cũ:

1. 1-2 ví dụ code tương tự đã có trong hệ thống (ví dụ: nếu viết thêm 1 API endpoint mới, lấy 1 endpoint tương tự làm mẫu)
2. Định nghĩa type/interface/schema liên quan
3. Convention đặt tên, cấu trúc thư mục (thường chỉ cần liệt kê đường dẫn file, không cần đọc hết nội dung)
4. Yêu cầu nghiệp vụ (business requirement) — phần này nên được viết cô đọng, không paste nguyên văn spec dài dòng

Những gì không cần: toàn bộ codebase, các feature không liên quan, tài liệu thiết kế của các module khác.

Code review

Context cho code review khác hẳn debug hay viết feature — ở đây agent cần đối chiếu 2 trạng thái: code trước và sau thay đổi, cùng với chuẩn chất lượng áp dụng:

1. Diff (chỉ phần thay đổi, có vài dòng context xung quanh — không cần cả file)
2. Coding convention / style guide của team (nếu có, chỉ phần liên quan đến loại thay đổi này)
3. Test case liên quan (để đánh giá độ phủ)
4. Mô tả PR / mục đích thay đổi (business context ngắn gọn)

Những gì không cần: toàn bộ file không thay đổi, lịch sử review của các PR khác.

Viết test case (dành riêng cho vai trò QA)

QA engineer dùng agent để sinh test case cần context khác biệt rõ rệt so với dev:

1. Đặc tả hành vi mong đợi (acceptance criteria, user story)
2. Interface/API contract (input/output, không cần implementation chi tiết bên trong)
3. Các edge case đã biết từ trước (nếu có tài liệu ghi nhận bug cũ)
4. Test case hiện có (để tránh trùng lặp và để agent theo đúng convention viết test của team)

Điều thú vị là QA thường không cần xem source code implementation — chỉ cần contract/behavior, vì mục tiêu là kiểm thử hành vi (black-box), không phải kiểm thử theo cách code được viết ra (điều này còn giúp tránh test bị "nhuốm màu" theo cách implement, một lỗi phổ biến khi để agent đọc cả code rồi viết test).

Phân tích yêu cầu (dành riêng cho vai trò PM)

Product manager dùng agent để phân tích, làm rõ requirement cần:

1. Yêu cầu gốc từ stakeholder (nguyên văn, không tóm tắt trước — để agent tự phân tích)
2. Các quyết định/ràng buộc kỹ thuật đã biết (nếu ảnh hưởng tới phạm vi)
3. Case tương tự đã làm trước đó (nếu có, để đối chiếu)

Những gì không cần: chi tiết implementation, code.

Mẹo

• Trước khi bắt đầu bất kỳ nhiệm vụ nào, tự phân loại nó vào một trong các nhóm trên (debug/feature/review/test/requirement) — việc phân loại này chỉ tốn vài giây nhưng định hướng toàn bộ chiến lược chọn context.
• Với vai trò QA, cưỡng lại thói quen đưa toàn bộ source code vào — nếu agent cần đọc code để viết test, đó là dấu hiệu contract/spec chưa đủ rõ, hãy làm rõ contract trước.
• Lưu sẵn "context template" cho từng loại nhiệm vụ lặp lại nhiều lần (ví dụ template debug luôn gồm: stack trace + function lỗi + input mẫu) để không phải nghĩ lại từ đầu mỗi lần.

Precision Context Extraction Techniques

Biết "cái gì cần" chỉ là nửa đầu vấn đề. Nửa còn lại là kỹ thuật để trích xuất chính xác phần đó ra khỏi một file lớn, một tài liệu dài, hoặc một codebase khổng lồ — mà không phải copy-paste tay từng dòng.

Kỹ thuật 1: Trích xuất function/class bằng script thay vì paste cả file

Thay vì mở nguyên file 2000 dòng và paste hết vào context, dùng công cụ dòng lệnh hoặc script nhỏ để lấy đúng function cần thiết. Với Python, ta có thể dùng module ast (Abstract Syntax Tree — cây cú pháp trừu tượng) để phân tích và trích xuất chính xác theo tên hàm:

import ast
import sys


def extract_function(file_path: str, function_name: str) -> str:
    with open(file_path, "r", encoding="utf-8") as f:
        source = f.read()

    tree = ast.parse(source)
    lines = source.splitlines()

    for node in ast.walk(tree):
        if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)):
            if node.name == function_name:
                start = node.lineno - 1
                end = node.end_lineno
                # Include decorators if present
                if node.decorator_list:
                    start = node.decorator_list[0].lineno - 1
                return "\n".join(lines[start:end])

    raise ValueError(f"Function '{function_name}' not found in {file_path}")


if __name__ == "__main__":
    file_path, function_name = sys.argv[1], sys.argv[2]
    # Now you have just the function, not the entire file
    print(extract_function(file_path, function_name))

Chạy python extract_function.py order_controller.py validate_quantity, ta chỉ nhận về đúng 15-20 dòng của hàm cần debug — không phải 800 dòng của cả file. Với TypeScript/JavaScript, có thể dùng công cụ như ts-morph theo cùng nguyên lý, hoặc đơn giản hơn là dùng grep/ripgrep kết hợp đếm dấu ngoặc để tìm block hàm khi codebase nhỏ và không cần độ chính xác AST tuyệt đối.

Kỹ thuật 2: Trích xuất một section cụ thể từ tài liệu Markdown lớn

Với tài liệu spec dài (ví dụ 50 trang), việc đưa cả file vào context chỉ để lấy một phần là lãng phí nghiêm trọng. Dùng script tách theo heading:

#!/usr/bin/env bash

FILE="$1"
SECTION_TITLE="$2"

awk -v title="$SECTION_TITLE" '
  function heading_level(line) {
    # Count heading level (number of # characters)
    match(line, /^#+/)
    return RLENGTH
  }
  BEGIN { found = 0; level = 0 }
  /^#{1,6}[[:space:]]/ {
    lvl = heading_level($0)
    if (found && lvl <= level) {
      exit
    }
    if (!found && $0 ~ "^#{1,6}[[:space:]]+" title "[[:space:]]*$") {
      found = 1
      level = lvl
      print
      next
    }
  }
  found { print }
' "$FILE"

Lệnh ./extract_section.sh api-spec.md "Authentication Flow" sẽ trả về đúng phần "Authentication Flow" — dừng lại khi gặp heading cùng cấp hoặc cấp cao hơn tiếp theo, không lấy dư sang phần khác. Kết quả: từ 50 trang, ta chỉ đưa vào context đúng 1-2 trang liên quan trực tiếp đến nhiệm vụ (ví dụ: đang debug lỗi refresh token thì chỉ cần phần Authentication Flow, không cần phần Rate Limiting hay Error Codes).

Kỹ thuật 3: Semantic search / embedding để tìm đoạn liên quan trong tài liệu không có cấu trúc rõ ràng

Hai kỹ thuật trên hiệu quả khi tài liệu có cấu trúc rõ (function name, heading). Nhưng với tài liệu tự do — ví dụ log chat hỗ trợ khách hàng, ghi chú cuộc họp, hay codebase không có convention rõ ràng — ta cần embedding (biểu diễn vector ngữ nghĩa của văn bản) và semantic search (tìm kiếm theo ngữ nghĩa, không phải theo từ khóa chính xác).

Ý tưởng: chia tài liệu thành các đoạn nhỏ (chunk), tính embedding cho từng đoạn và cho câu truy vấn, rồi chọn ra top-k đoạn có độ tương đồng cao nhất (thường đo bằng cosine similarity) để đưa vào context — thay vì đưa cả tài liệu.

from dataclasses import dataclass


@dataclass
class Chunk:
    text: str
    embedding: list[float]


def cosine_similarity(a: list[float], b: list[float]) -> float:
    dot = sum(x * y for x, y in zip(a, b))
    norm_a = sum(x * x for x in a) ** 0.5
    norm_b = sum(x * x for x in b) ** 0.5
    return dot / (norm_a * norm_b)


def top_k_relevant_chunks(query_embedding: list[float], chunks: list[Chunk], k: int = 3) -> list[Chunk]:
    scored = [(cosine_similarity(query_embedding, c.embedding), c) for c in chunks]
    scored.sort(key=lambda pair: pair[0], reverse=True)
    return [c for _, c in scored[:k]]

Trong thực tế, đây chính là cơ chế nền của các hệ thống RAG (Retrieval-Augmented Generation). Với đội ngũ agentic engineering, không cần tự xây dựng từ đầu — có thể dùng thư viện vector search có sẵn (ví dụ FAISS, hoặc dịch vụ vector database) kết hợp API embedding của nhà cung cấp model. Điểm quan trọng cần nhớ: chỉ đưa top-k đoạn liên quan nhất vào context, không đưa toàn bộ tập tài liệu gốc.

Mẹo

• Xây một bộ script trích xuất nhỏ (function extractor, section extractor) dùng lại được cho cả team — đây là khoản đầu tư một lần, tiết kiệm token dài hạn.
• Khi dùng semantic search, luôn kiểm tra lại top-k kết quả bằng mắt trước khi tin tưởng hoàn toàn — embedding có thể đưa ra kết quả "gần giống câu hỏi" nhưng sai ngữ cảnh nghiệp vụ.
• Với QA và PM không quen viết script, có thể yêu cầu chính agent viết sẵn hộ các script extractor này — đây cũng là một cách dùng agent tiết kiệm token cho những lần sau.

The Relevance Scoring Framework

Khi có nhiều ứng viên context (nhiều đoạn code, nhiều đoạn tài liệu) và giới hạn token không cho phép đưa hết vào, cần một cách định lượng để quyết định giữ gì, bỏ gì — thay vì cảm tính.

Bốn tiêu chí chấm điểm

Dưới đây là khung 4 tiêu chí, mỗi tiêu chí có thể chấm điểm 0-3 (0 = không đạt, 3 = rất mạnh):

1. Độ gần chủ đề (topical proximity): Đoạn context này gắn trực tiếp tới nhiệm vụ đến mức nào? Ví dụ: hàm chứa dòng code lỗi = 3 điểm; file cùng module nhưng không liên quan trực tiếp = 1 điểm.
2. Độ mới (freshness): Thông tin còn đúng với trạng thái hiện tại của hệ thống không? Code vừa refactor tuần trước = 3 điểm; tài liệu thiết kế từ 2 năm trước chưa cập nhật = 0-1 điểm.
3. Tần suất tham chiếu (reference frequency): Đoạn này có được nhắc tới lặp lại trong nhiều nguồn khác (code, log lỗi, thảo luận) không? Được nhắc tới nhiều = độ tin cậy về mức độ liên quan cao hơn.
4. Độ tin cậy nguồn (source reliability): Nguồn thông tin đến từ đâu? Code chạy thật trên production = 3 điểm; comment cũ trong code hoặc README chưa cập nhật = 1 điểm; giả định miệng chưa xác minh = 0 điểm.

Tổng điểm tối đa 12. Ngưỡng gợi ý:

• 9-12 điểm: Bắt buộc đưa vào context, ưu tiên giữ nguyên văn.
• 5-8 điểm: Đưa vào dạng tóm tắt (compress lại) thay vì nguyên văn.
• 0-4 điểm: Loại khỏi context, chỉ nhắc tên/đường dẫn nếu cần agent tự tra khi thật sự cần.

Ví dụ áp dụng thực tế

Nhiệm vụ: debug lỗi tính sai phí vận chuyển khi đơn hàng có nhiều địa chỉ giao hàng.

Bảng này không cần làm phức tạp bằng công cụ riêng — có thể lập nhanh trên giấy hoặc trong đầu trong vài giây với nhiệm vụ nhỏ. Với nhiệm vụ lớn, phức tạp (ví dụ agent tự động chọn context từ một codebase hàng chục nghìn file), framework này có thể được code hóa thành một bước lọc tự động trước khi build prompt.

Vì sao cần chấm điểm thay vì "cảm thấy liên quan"

Con người có xu hướng đánh giá quá cao độ liên quan của thông tin mà mình vừa đọc gần đây (recency bias) hoặc thông tin quen thuộc (familiarity bias). Việc ép mình chấm điểm theo 4 tiêu chí cụ thể giúp tránh rơi vào bẫy "tôi cảm thấy cái này quan trọng" — một cảm giác thường sai khi liên quan tới context selection cho agent.

Mẹo

• Khi làm việc nhóm, thống nhất một bảng điểm chung cho các loại nhiệm vụ lặp lại (debug, review...) để cả team chọn context nhất quán, không phụ thuộc cảm tính từng người.
• Với các đoạn chấm điểm 5-8, đừng bỏ hẳn — hãy tóm tắt bằng 1-2 câu (ví dụ "Module này dùng pattern Repository, không có logic nghiệp vụ đặc biệt") thay vì im lặng bỏ qua, vì bỏ qua hoàn toàn có thể khiến agent hiểu sai bối cảnh.
• Định kỳ review lại các quyết định "loại bỏ" sau khi agent hoàn thành nhiệm vụ — nếu phát hiện agent bị thiếu thông tin quan trọng, đó là dấu hiệu tiêu chí chấm điểm của bạn cần điều chỉnh.

Context Freshness and the Recency Problem

Vì sao context cũ nguy hiểm hơn context thiếu

Context thiếu khiến agent nói "tôi không có đủ thông tin" — một thất bại rõ ràng, dễ phát hiện. Context cũ (outdated) nguy hiểm hơn nhiều, vì nó khiến agent tự tin đưa ra câu trả lời sai một cách thuyết phục. Đây là lỗi âm thầm, khó phát hiện, và tốn nhiều thời gian sửa hơn cả việc thiếu context ngay từ đầu.

Các nguồn context cũ phổ biến nhất trong công việc phần mềm hàng ngày:

• Tài liệu thiết kế/README chưa cập nhật sau khi code đã refactor nhiều lần. Agent đọc README nói API nhận userId, nhưng thực tế đã đổi sang accountId từ 3 tháng trước.
• Code đã archive/deprecated nhưng vẫn còn nằm trong repo, agent nhặt nhầm làm ví dụ mẫu.
• Comment trong code lỗi thời — comment mô tả logic cũ, nhưng code bên dưới đã thay đổi mà comment không được cập nhật theo (một vấn đề rất phổ biến, gần như chắc chắn tồn tại trong mọi codebase đủ lớn).
• Kết quả tìm kiếm/tra cứu cũ được cache lại từ lần chạy agent trước, không phản ánh trạng thái hệ thống hiện tại.
• Test case cũ đã lỗi thời nhưng chưa bị xóa, khiến agent hiểu sai hành vi mong đợi hiện tại của hệ thống.

Cách phát hiện context cũ trước khi đưa vào

1. Kiểm tra timestamp/last-modified: với file code, dùng git log -1 --format=%cd -- <file> để biết lần sửa cuối. Nếu tài liệu tham chiếu tới file đó cũ hơn lần sửa cuối này nhiều, cảnh báo đỏ.
2. Đối chiếu với code thực tế: trước khi tin một đoạn tài liệu/comment, thử grep nhanh xem tên biến/hàm được nhắc tới còn tồn tại trong code không.
3. Ưu tiên nguồn "sự thật hiện tại" (ground truth) hơn nguồn "mô tả": code chạy thật, log thực tế, kết quả test hiện tại luôn đáng tin hơn tài liệu mô tả — vì tài liệu có thể lỗi thời nhưng code đang chạy thì không thể "nói dối" về hành vi thực tế của nó.
4. Đánh dấu rõ độ tuổi khi đưa context vào prompt: nếu buộc phải dùng tài liệu có khả năng cũ, ghi rõ trong context, ví dụ: "# NOTE: this design doc was last updated 8 months ago, verify against current code before relying on it". Việc gắn nhãn này giúp model tự điều chỉnh mức độ tin tưởng, giảm khả năng khẳng định sai dựa trên thông tin cũ.

Quy trình làm mới context (refresh routine)

Với các nguồn context được tái sử dụng nhiều lần (ví dụ tài liệu spec dùng cho nhiều task QA, hoặc file convention dùng cho nhiều task viết feature), nên có quy trình làm mới định kỳ:

• Gắn "ngày hết hạn tin cậy" theo cảm tính cho từng loại tài liệu (ví dụ: schema database — tin trong 1 tuần; API contract — tin trong 1 tháng; kiến trúc tổng thể — tin trong 1 quý).
• Khi agent phát hiện mâu thuẫn giữa tài liệu và code thực tế trong lúc làm việc, ghi nhận lại ngay (một dòng note) để cập nhật tài liệu gốc sau đó — tránh việc lỗi tương tự lặp lại ở lần dùng context tiếp theo.
• Với dự án dùng agent thường xuyên, khuyến khích để agent tự đối chiếu nhanh (cross-check) tài liệu với code trước khi dùng làm context chính, đặc biệt với các nhiệm vụ quan trọng.

Mẹo

• Đừng xóa hẳn tài liệu cũ — nhưng luôn kèm cảnh báo độ tuổi rõ ràng khi đưa vào context, để model tự cân nhắc mức tin tưởng.
• Coi mọi comment trong code là "có thể sai" cho đến khi đối chiếu với logic thực tế — comment lỗi thời là một trong những nguồn context cũ nguy hiểm và phổ biến nhất.
• Nếu phát hiện agent đưa ra kết quả sai do dùng thông tin lỗi thời, đừng chỉ sửa lần đó — cập nhật luôn nguồn tài liệu gốc, vì lỗi này chắc chắn sẽ lặp lại ở người/agent dùng context đó lần sau.

Context Selection for Multi-Persona Workflows

Vì sao một bộ context không phù hợp cho tất cả vai trò

Trong một team phát triển phần mềm hiện đại, cùng một agent (hoặc cùng một hệ thống agentic) thường được nhiều vai trò khác nhau sử dụng: developer, QA engineer, product manager, đôi khi cả stakeholder không kỹ thuật. Mỗi vai trò có một câu hỏi khác nhau cho cùng một hệ thống, nên context cần khác nhau — dù đang nói về cùng một feature.

Ví dụ với feature "thanh toán bằng ví điện tử":

• Developer cần: implementation hiện tại, API contract, edge case kỹ thuật (timeout, retry, idempotency).
• QA cần: acceptance criteria, các luồng test đã có, danh sách bug đã ghi nhận trước đó liên quan tới thanh toán.
• PM cần: yêu cầu nghiệp vụ gốc, ràng buộc từ đối tác ví điện tử, ảnh hưởng tới các feature khác.

Nếu dùng chung một bộ context "đầy đủ mọi thứ" cho cả ba vai trò, ta lại rơi về đúng cái bẫy ban đầu: context quá tải, loãng, tốn token — mà từng vai trò vẫn phải tự lọc lại phần mình cần.

Thiết kế context theo persona (persona-based context selection)

Cách làm thực dụng là xây một "context profile" riêng cho từng persona, dựa trên đúng loại nhiệm vụ persona đó thường làm (xem lại phần "Context Selection by Task Type" ở trên) — về bản chất, persona chính là một lớp map giữa vai trò và loại nhiệm vụ.

Quy trình gợi ý:

1. Liệt kê các persona thực sự dùng agent trong dự án của bạn — không cần lý thuyết, chỉ cần nhìn ai đang dùng agent hàng ngày.
2. Với mỗi persona, xác định 2-3 loại nhiệm vụ lặp lại nhiều nhất. Ví dụ QA: viết test case, phân tích bug report.
3. Xây context template riêng cho từng cặp (persona, loại nhiệm vụ) — dựa theo khung đã trình bày ở phần Task Type, nhưng cụ thể hóa theo dự án thật (đường dẫn file cụ thể, tên tài liệu cụ thể).
4. Chia sẻ core context chung nếu có (ví dụ: coding convention chung áp dụng cho cả dev và QA khi viết test tự động) nhưng tách riêng phần đặc thù persona.

Ví dụ prompt template theo persona

Với vai trò QA khi phân tích bug report, context template có thể trông như sau (minh họa cấu trúc, không phải nội dung cần dịch nguyên văn):

## Required context (always include):
- Bug report (raw, as submitted)
- Acceptance criteria of the affected feature
- Existing test cases covering this area

## Optional context (include only if score >= 8 per relevance framework):
- Related bug history (last 3 similar issues)

## Explicitly excluded for this persona/task:
- Full implementation source code
- Unrelated modules' documentation

Với vai trò developer khi debug cùng một bug, template khác hẳn — thiên về implementation và stack trace như đã nêu ở phần Task Type, dù bug report gốc vẫn là điểm khởi đầu chung.

Quản lý chuyển giao context giữa các persona

Một điểm dễ bị bỏ qua: khi công việc chuyển từ persona này sang persona khác (ví dụ PM viết yêu cầu → dev implement → QA test), context không nên được "chuyển giao nguyên khối". Mỗi persona tiếp theo nên nhận một context đã được chọn lọc lại theo nhu cầu của họ, kèm một bản tóm tắt ngắn về quyết định của persona trước (ví dụ: dev tóm tắt "đã implement theo hướng X vì lý do Y" để QA biết mà không cần đọc lại toàn bộ code).

Mẹo

• Xây thư viện context template theo persona một lần, lưu lại dùng chung cho cả team — tránh mỗi người tự mò lại từ đầu.
• Khi thiết kế template cho một persona mới, hỏi trực tiếp người đảm nhiệm vai trò đó "bạn cần biết gì để làm việc này, và biết gì là dư" — họ thường biết rõ hơn ai hết.
• Định kỳ rà soát lại các template khi workflow thay đổi (ví dụ team đổi công cụ quản lý bug, đổi format acceptance criteria) — context template lỗi thời cũng là một dạng của vấn đề "recency" đã nói ở phần trước.