Cách viết agent instructions: 7 phần để AI agent làm việc rõ ràng hơn

Agent instructions nên có những gì?

Trả lời ngắn: Một bộ agent instructions (chỉ dẫn vận hành cho AI agent) nên làm rõ bảy phần:

1. Purpose: kết quả cần tạo ra và cho ai.
2. Allowed inputs: dữ liệu nào được dùng, dữ liệu nào không.
3. Workflow: các bước và nhánh quyết định.
4. Tools and permissions: tool nào được gọi, với quyền gì.
5. Output contract: đầu ra phải có cấu trúc và tiêu chí nào.
6. Guardrails: giới hạn, điều cấm và yêu cầu phê duyệt.
7. Exceptions and handoff: khi nào phải hỏi thêm, dừng hoặc chuyển cho người.

Sau đó, đừng chỉ đọc lại instruction. Hãy kiểm tra nó bằng tình huống bình thường, thiếu đầu vào, chỉ dẫn xung đột và hành động có tác động lớn.

Đây là khung thực hành của bài viết, không phải tiêu chuẩn ngành. Một instruction tốt không tự làm cho agent an toàn, chính xác hay tuân thủ. Kết quả còn phụ thuộc vào model, tool, dữ liệu, quyền truy cập, kiểm soát ở tầng ứng dụng và cách đánh giá.

Hình 1. Bảy phần biến một yêu cầu chung chung thành tài liệu vận hành có thể xem xét và kiểm tra.

Ngày rà soát nội dung: 06/09/2026. Bài viết là hướng dẫn thực hành chung, không phải tư vấn pháp lý, bảo mật hoặc cam kết về sản phẩm. Nếu phát hiện điểm cần sửa, vui lòng gửi qua trang Liên hệ.

Prompt và agent instructions khác nhau thế nào?

Prompt có thể chỉ là một yêu cầu cho một lần tương tác. Agent instructions cần mô tả cách hệ thống xử lý một công việc qua nhiều bước, dùng tool và phản ứng trước tình huống ngoài dự kiến.

Ví dụ:

Hãy đọc ghi chú cuộc họp và viết email tổng kết.

Câu này cho biết tác vụ, nhưng chưa trả lời:

• ghi chú nào được phép đọc;
• ai là người nhận hợp lệ;
• thông tin nào phải được kiểm chứng;
• agent chỉ tạo draft hay được gửi email;
• đầu ra cần định dạng gì;
• phải làm gì nếu có hai phiên bản ghi chú;
• khi nào agent cần dừng.

OpenAI mô tả ba thành phần nền tảng của agent là model, tools và instructions. Hướng dẫn này khuyến nghị chuyển quy trình thành bước nhỏ, gắn mỗi bước với hành động cụ thể và viết nhánh cho các edge case (tình huống ngoại lệ). Đây là practitioner guidance, không phải một chuẩn bắt buộc cho mọi hệ thống.

Bảy phần của một bộ agent instructions

1. Purpose: agent phải tạo ra kết quả gì?

Purpose không nên chỉ nêu một động từ như “phân tích” hay “tóm tắt”. Hãy ghi rõ đầu ra, người sử dụng và ranh giới của công việc.

Mơ hồ:

Phân tích tài liệu khách hàng.

Rõ hơn:

Tạo bản nháp tóm tắt tối đa 800 từ cho chuyên gia phụ trách, chỉ bao gồm quyết định, bằng chứng được trích dẫn và câu hỏi còn bỏ ngỏ trong bộ tài liệu của đúng dự án.

Purpose tốt giúp bạn phân biệt “xong việc” với “đã tạo ra nhiều chữ”. Nó cũng giúp nhận ra khi một workflow cố gắng giải quyết quá nhiều mục tiêu cùng lúc.

2. Allowed inputs: agent được đọc gì?

Allowed inputs nên chỉ rõ nguồn được phép, phiên bản, phạm vi khách hàng và dữ liệu bị cấm.

Ví dụ:

• Được dùng: biên bản được gắn nhãn approved-for-summary của dự án hiện tại.
• Không được dùng: email cá nhân, thư mục dự án khác, bản ghi chưa có quyền sử dụng.
• Nếu thiếu: không tự tìm nguồn thay thế; yêu cầu đúng tài liệu hoặc dừng.

Danh sách này không thay thế cơ chế phân quyền. Instruction nói agent nên làm gì; hệ thống truy cập phải quyết định agent có thể làm gì.

3. Workflow: agent đi qua những bước nào?

Workflow nên thể hiện trình tự, điểm kiểm tra và nhánh quyết định — không chỉ là đoạn văn mô tả kết quả mong muốn.

Một workflow ngắn có thể là:

1. Xác nhận có đúng tài liệu và đúng dự án.
2. Trích các quyết định cùng vị trí nguồn.
3. Gắn cờ điểm thiếu chủ sở hữu hoặc thời hạn.
4. Tạo bản nháp theo output contract.
5. Chạy kiểm tra trước khi bàn giao.
6. Dừng và chuyển người nếu gặp stop condition.

Anthropic phân biệt workflow có đường đi được định trước với agent tự quyết định quy trình và cách dùng tool. Bài viết này rút ra một nguyên tắc thiết kế: nếu đường đi có thể viết rõ và kiểm tra bằng code, đừng bắt model phải suy đoán mọi bước.

Hình 2. Chuyển policy thành routine: tách nguồn dày thành bước, nhánh, kiểm tra và điểm bàn giao.

4. Tools and permissions: agent được hành động đến đâu?

Với mỗi tool, hãy ghi:

• dùng để đọc dữ liệu hay tạo thay đổi;
• tham số nào bắt buộc;
• hệ thống hoặc đối tượng nào nằm trong phạm vi;
• hành động có đảo ngược được không;
• cần phê duyệt ở bước nào;
• kết quả tool phải được kiểm tra ra sao.

OpenAI khuyến nghị đánh giá tool theo các yếu tố như quyền đọc/ghi, khả năng đảo ngược, quyền tài khoản và tác động tài chính; hành động nhạy cảm hoặc khó đảo ngược nên kích hoạt giám sát của con người. Đây là heuristic thiết kế, không phải công thức rủi ro chung.

5. Output contract: “đúng định dạng” nghĩa là gì?

Output contract là mô tả có thể kiểm tra về đầu ra. Nó nên bao gồm:

• format: Markdown, JSON, bảng hay draft trong một hệ thống;
• trường bắt buộc;
• giới hạn độ dài;
• cách gắn nguồn;
• cách biểu diễn phần chưa chắc chắn;
• tiêu chí từ chối đầu ra;
• nơi lưu hoặc người nhận.

Ví dụ:

output:
  format: markdown
  required_sections:
    - decisions
    - evidence
    - open_questions
  every_decision_needs:
    - source_link
    - owner_or_missing_flag
  prohibited:
    - invented_deadlines
    - inferred_customer_intent

Một schema không bảo đảm nội dung đúng. Nhưng nó cho phép kiểm tra những lỗi như thiếu trường, sai kiểu dữ liệu hoặc không có nguồn trước khi một người phải đọc toàn bộ.

6. Guardrails: đâu là giới hạn và điểm phê duyệt?

Guardrails là lớp giới hạn và kiểm tra, không phải câu thần chú “hãy cẩn thận”.

Hãy ghi rõ:

• dữ liệu hoặc hành động bị cấm;
• phạm vi danh tính, khách hàng và hệ thống;
• hành động nào cần xác nhận;
• số lần thử tối đa;
• điều kiện dừng;
• kiểm tra deterministic nào chạy trước hoặc sau model;
• ai có quyền cho phép ngoại lệ.

OpenAI lưu ý guardrail nên đi cùng authentication, authorization, access control và biện pháp bảo mật phần mềm thông thường — không thay thế chúng. Ngoài ra, prompt injection có thể xuất hiện trong nội dung từ bên thứ ba và đánh lạc hướng model. Vì vậy, “chỉ làm theo instruction” không phải cơ chế bảo vệ đầy đủ khi agent đọc web, email hay tài liệu bên ngoài.

7. Exceptions and handoff: khi nào agent phải dừng?

Với agent gọi tool, hãy biến phần này thành failure policy có thể test: phân loại khi nào retry, fallback, stop hoặc bàn giao, đặc biệt khi timeout không cho biết action đã xảy ra hay chưa.

Một instruction hoàn chỉnh phải mô tả thất bại, không chỉ “happy path”.

Với mỗi tình huống quan trọng, hãy chỉ rõ:

1. Trigger: điều gì vừa xảy ra?
2. Safe state: agent phải giữ hệ thống ở trạng thái nào?
3. Evidence: log, nguồn hay thay đổi nào cần bàn giao?
4. Receiver: ai có quyền quyết định bước tiếp?
5. Resume rule: khi nào workflow được tiếp tục?

NIST AI RMF Core là khung tự nguyện và nêu việc cần định nghĩa, phân biệt vai trò cùng trách nhiệm trong cấu hình người–AI và hoạt động giám sát. Điều này gợi ý rằng “chuyển cho người” chưa đủ; instruction cần nêu người nào nhận và họ quyết định điều gì.

Mẫu agent instructions có thể sao chép

Mẫu dưới đây cố ý ngắn. Chỉ thêm chi tiết khi chi tiết đó giúp agent hoặc người kiểm tra đưa ra quyết định rõ hơn.

# Identity
Bạn là [vai trò hẹp] hỗ trợ [người dùng/đội ngũ].

# Purpose
Tạo [đầu ra] để [người dùng] có thể [quyết định/hành động].
Hoàn thành khi [tiêu chí có thể kiểm tra].

# Allowed inputs
- Được dùng: [nguồn, phiên bản, phạm vi].
- Không được dùng: [dữ liệu/hệ thống bị cấm].
- Nếu thiếu đầu vào: [hỏi thêm hoặc dừng].

# Workflow
1. [Kiểm tra đầu vào].
2. [Xử lý và giữ liên kết về nguồn].
3. [Áp dụng nhánh quyết định].
4. [Tạo đầu ra].
5. [Tự kiểm tra và bàn giao].

# Tools and permissions
- [Tool]: dùng để [mục đích], trong [phạm vi].
- Không được [hành động].
- Cần phê duyệt trước khi [hành động có tác động].

# Output contract
- Format: [format/schema].
- Bắt buộc có: [trường/phần].
- Phần chưa chắc chắn: [cách gắn cờ].
- Không được: [nội dung hoặc suy diễn].

# Guardrails
- Giới hạn: [dữ liệu, hành động, thời gian, số lần thử].
- Kiểm tra: [rule/schema/policy check].
- Approval gate: [người có quyền và bằng chứng họ cần].

# Exceptions and handoff
- Dừng khi: [stop conditions].
- Giữ lại: [trạng thái/log/draft].
- Chuyển cho: [vai trò].
- Chỉ tiếp tục khi: [resume condition].

Ví dụ: agent chuẩn bị email tổng kết cuộc họp

Giả sử mục tiêu là tạo email nháp sau buổi tư vấn:

• Purpose: tạo draft tóm tắt quyết định và việc tiếp theo cho chuyên gia phụ trách.
• Allowed inputs: chỉ biên bản đã được đánh dấu dùng được của đúng cuộc họp.
• Workflow: xác nhận file → trích quyết định → gắn nguồn → nêu câu hỏi mở → tạo draft → kiểm tra.
• Tools: đọc thư mục dự án và tạo email draft; không được thêm người nhận hoặc gửi.
• Output contract: tiêu đề, ba phần Quyết định, Việc tiếp theo, Câu hỏi mở; mỗi việc có owner hoặc cờ chưa xác định.
• Guardrails: không suy đoán deadline, không dùng dữ liệu từ khách hàng khác, không tạo cam kết thay chuyên gia.
• Exceptions and handoff: dừng khi có hai biên bản xung đột, người nhận không khớp hoặc tài liệu chứa chỉ dẫn yêu cầu bỏ qua policy.

Điểm quan trọng không phải là instruction dài. Điểm quan trọng là mỗi lựa chọn vận hành có thể được nhìn thấy, kiểm tra và sửa.

Cách test agent instructions trước khi dùng thật

Đừng chỉ chạy một ví dụ đẹp. Hãy tạo một test set nhỏ nhưng có chủ đích.

Hình 3. Test matrix kiểm tra không chỉ chất lượng đầu ra mà cả hành vi dừng và bàn giao.

Bốn test case tối thiểu

1. Normal case: dữ liệu đầy đủ; agent có tạo đúng output contract không?
2. Missing-input case: thiếu một trường bắt buộc; agent có hỏi đúng câu hay tự đoán?
3. Conflict case: tài liệu chứa chỉ dẫn trái với instruction; agent ưu tiên đúng nguồn quyền lực và gắn cờ không?
4. High-impact case: yêu cầu gửi, xóa hoặc thay đổi dữ liệu; agent có dừng ở approval gate?

Với mỗi test, ghi:

• input và trạng thái ban đầu;
• hành vi mong đợi;
• hành vi thực tế;
• bằng chứng/log;
• mức tác động nếu sai;
• thay đổi instruction, tool hay application control cần thực hiện;
• người chấp nhận kết quả.

Nếu một lỗi có thể bị chặn chắc chắn bằng code, permission hoặc schema, đừng chỉ thêm một câu nhắc vào prompt. Nếu lỗi liên quan đến phán đoán nghề nghiệp, hãy định nghĩa bằng chứng người duyệt cần thấy và quyền quyết định của họ.

Dấu hiệu instruction đang quá dài nhưng vẫn thiếu

Instruction có thể rất dài mà vẫn yếu nếu:

• lặp lại tính từ như “chính xác”, “chuyên nghiệp”, “cẩn thận” nhưng không có tiêu chí kiểm tra;
• chôn điều cấm trong đoạn văn dài;
• có nhiều mục tiêu xung đột mà không nêu thứ tự ưu tiên;
• liệt kê tool nhưng không nêu quyền và phạm vi;
• chỉ mô tả happy path;
• yêu cầu “hỏi người” nhưng không nêu hỏi ai, kèm bằng chứng gì;
• thay đổi liên tục mà không có version, test set và record lỗi.

Khi đó, hãy rút instruction về các quyết định vận hành. Đưa kiến thức tham chiếu dài sang nguồn riêng; dùng schema cho cấu trúc; dùng permission cho quyền; dùng test để kiểm tra hành vi.

Nếu chưa chắc công việc cần agent hay chỉ cần prompt/workflow, hãy điền rubric 20 điểm chọn cách làm đủ dùng trước khi viết instruction dài.

Những điều agent instructions không giải quyết thay bạn

Khung bảy phần không tự quyết định:

• dữ liệu nào hợp pháp hoặc phù hợp để xử lý;
• ai có thẩm quyền phê duyệt;
• tool nào đủ an toàn cho hệ thống cụ thể;
• mức lỗi chấp nhận được;
• yêu cầu bảo mật, quyền riêng tư hoặc ngành;
• cách theo dõi model, tool và dữ liệu sau thay đổi.

Chủ quy trình, chuyên gia lĩnh vực và các chủ sở hữu rủi ro phải quyết định những điểm này. Với tác vụ có tác động đáng kể, hãy bắt đầu bằng quyền read-only hoặc draft-only, dùng dữ liệu thử nghiệm và xác định rollback trước khi tăng quyền.

Câu hỏi thường gặp

Agent instructions có phải là system prompt không?

Không hoàn toàn. System prompt có thể chứa instruction, nhưng một hệ thống agent còn có tool definition, permission, runtime check, dữ liệu, memory, log và application control. Bài viết dùng “agent instructions” để nói về phần chỉ dẫn vận hành có thể được xem xét và version hóa.

Instruction càng dài thì agent càng tốt?

Không. Độ dài không phải tiêu chí chất lượng. Instruction nên đủ rõ về mục tiêu, đầu vào, workflow, tool, đầu ra, giới hạn và ngoại lệ. Phần không giúp đưa ra quyết định hoặc kiểm tra hành vi có thể làm tăng nhiễu.

Có nên đưa toàn bộ SOP vào prompt?

Không nhất thiết. Hãy tách SOP thành bước và nhánh liên quan, giữ nguồn tham chiếu có version, rồi chỉ đưa đúng ngữ cảnh cần cho bước hiện tại. Nếu quy trình có đường đi cố định, cân nhắc thực thi phần đó bằng code thay vì để model tự diễn giải.

Viết guardrail trong prompt đã đủ chưa?

Chưa. Prompt-level instruction chỉ là một lớp. Quyền truy cập, xác thực, phê duyệt, kiểm tra đầu ra, sandbox, log, giám sát và khả năng rollback cần được triển khai ở tầng phù hợp.

Khi nào nên sửa instruction?

Khi test hoặc vận hành cho thấy một pattern lỗi có thể diễn đạt rõ hơn. Mỗi lần sửa nên có version, lý do, test tái hiện lỗi và kết quả regression test; tránh sửa chỉ để phản ứng với một trường hợp không đại diện.

Bước tiếp theo: viết cho một việc, rồi thử bốn tình huống

Sau khi khóa bảy phần, hãy đưa instruction vào bộ đánh giá AI agent gồm test set, scorecard 100 điểm và run log để kiểm tra cả outcome, trajectory và ranh giới.

Trong Output contract, bạn cũng có thể gắn mẫu decision trail 6 trường để agent ghi route, evidence, tool receipt và kết quả kiểm chứng mà không yêu cầu công khai chain-of-thought chi tiết.

Chọn một công việc lặp lại, tác động thấp trong tuần này. Sao chép mẫu bảy phần, điền bằng câu ngắn, rồi chạy bốn test case: bình thường, thiếu dữ liệu, xung đột và hành động có tác động lớn.

Nếu bạn chưa viết được phần Tools and permissions hoặc Exceptions and handoff, hãy giữ agent ở chế độ draft-only. Để thiết kế điểm phê duyệt rõ hơn, đọc tiếp Human-in-the-loop cho AI agent: 3 chế độ phối hợp để giữ quyền quyết định.