AI agent reasoning: mẫu decision trail 6 trường để kiểm soát quyết định

AI agent reasoning là gì?

Trả lời ngắn: AI agent reasoning là quá trình agent dùng mục tiêu, context và kết quả từ môi trường để chọn bước tiếp theo trong một workflow. Để kiểm soát quá trình này, đừng yêu cầu agent công khai suy nghĩ riêng tư từng token. Hãy yêu cầu một decision trail (dấu vết quyết định) ngắn gồm sáu trường có thể kiểm tra: Input → Evidence → Options → Decision → Action → Check.

Decision trail không chứng minh agent “suy nghĩ đúng”, không phải giải thích đầy đủ cơ chế bên trong model và không thay thế audit log kỹ thuật. Nó là một artifact vận hành: đủ để người chịu trách nhiệm biết agent đã dựa vào đâu, chọn gì, đã làm gì và kiểm tra kết quả thế nào.

Bạn có thể tải ba tài sản do Đũa Thần AI tổng hợp cho bài này:

• Mẫu decision trail AI agent — Markdown
• Rubric decision trail 30 điểm — CSV
• Run log cho từng lần chạy — CSV

Giới hạn: đây là mẫu thực hành v1.0, không phải standard, certification, benchmark hay bằng chứng production readiness. Hãy sửa trường, trọng số và lỗi chặn theo workflow, quyền truy cập và mức tác động thực tế.

Hình 1. Vòng lặp giúp tách việc thu nhận bằng chứng, lập kế hoạch, hành động và kiểm tra thay vì gom tất cả vào một prompt.

Ngày rà soát: 07/09/2026. Owner sửa nội dung: Nghiêm Xuân Hào. Gửi yêu cầu đính chính qua trang liên hệ.

Reasoning khác câu trả lời cuối như thế nào?

Một câu trả lời cuối chỉ cho biết agent nói gì. Một workflow có tool còn cần biết agent đã làm gì và trạng thái thật của môi trường là gì.

Anthropic phân biệt transcript/trace/trajectory — bản ghi các tương tác và tool call trong một trial — với outcome, tức trạng thái cuối trong môi trường. Một agent có thể nói “đã đặt vé” trong transcript nhưng outcome cần kiểm tra là booking có thực sự tồn tại hay không (Anthropic, 09/01/2026).

Vì vậy, một decision trail hữu ích phải nối ba lớp:

1. Bằng chứng đầu vào: agent đã thấy dữ liệu nào, từ nguồn nào, ở thời điểm nào?
2. Quyết định có giới hạn: agent chọn hướng nào và điều kiện nào khiến nó phải dừng hoặc xin duyệt?
3. Kết quả kiểm chứng được: tool trả về gì, trạng thái nào thay đổi, và ai xác nhận?

Nếu chỉ lưu câu trả lời tự thuật của model, bạn có thể có một bản giải thích trôi chảy nhưng không có bằng chứng rằng hành động bên ngoài đã xảy ra đúng.

Vòng lặp Sense–Plan–Act–Reflect

Bài viết sử dụng Sense–Plan–Act–Reflect như một khung biên tập để phân rã workflow, không phải kiến trúc bắt buộc hay thuật ngữ chuẩn hóa toàn ngành.

1. Sense: thu nhận đúng bằng chứng

Agent nhận mục tiêu, input, quyền và trạng thái môi trường. Record tối thiểu nên có:

• ID và version của task;
• nguồn dữ liệu cùng timestamp;
• phần dữ liệu còn thiếu hoặc mâu thuẫn;
• tool đang ở read-only hay có quyền ghi;
• điều kiện dừng trước khi agent bắt đầu.

Nếu input đến từ web, email, file hay một agent khác, hãy coi nội dung đó là dữ liệu chưa tin cậy cho đến khi policy cho phép dùng. OWASP khuyến nghị least privilege: chỉ cấp tool tối thiểu, giới hạn quyền theo từng tool và yêu cầu ủy quyền rõ cho thao tác nhạy cảm (OWASP AI Agent Security Cheat Sheet, truy cập 07/09/2026).

2. Plan: nêu route, không phơi chain-of-thought

Không cần buộc model in ra chain-of-thought chi tiết. Thay vào đó, yêu cầu plan summary có thể hành động:

• outcome cần đạt;
• 2–3 route khả thi khi thật sự có lựa chọn;
• tiêu chí chọn;
• checkpoint cần người duyệt;
• giới hạn số bước, retry, thời gian hoặc chi phí;
• bằng chứng phải có trước khi chuyển sang Act.

Anthropic khuyên ưu tiên thiết kế đơn giản, minh bạch và chỉ tăng độ phức tạp khi có bằng chứng rằng nó cải thiện outcome (Anthropic, 19/12/2024). Điều này không có nghĩa mọi agent phải công bố reasoning nội bộ; trong bài này, “minh bạch” được triển khai bằng route, evidence, action và check có cấu trúc.

3. Act: hành động trong permission envelope

Permission envelope là phạm vi tool, tài nguyên và hành động đã được cho phép. Mỗi action record nên có:

• tool và operation;
• target;
• input đã khử dữ liệu không cần thiết;
• trạng thái phê duyệt;
• idempotency key hoặc cơ chế chống chạy lặp khi có;
• response ID hay receipt;
• thay đổi có thể rollback hay không.

OpenAI mô tả agent là hệ thống dùng model để quản lý workflow và dùng tool để tương tác với hệ thống bên ngoài; hướng dẫn của OpenAI cũng khuyên đặt giới hạn retry/action và chuyển cho người khi gặp thao tác nhạy cảm, khó đảo ngược hoặc high-stakes (OpenAI, truy cập 07/09/2026).

4. Reflect: kiểm tra outcome và quyết định bước kế

Reflect không phải câu “tôi đã làm tốt”. Đây là một phép kiểm:

• so outcome với success criteria đã khóa;
• đối chiếu receipt hoặc trạng thái hệ thống;
• ghi failure class và correction;
• quyết định ACCEPT, RETRY, HANDOFF, ROLLBACK hoặc STOP;
• đưa failure mới vào regression test nếu phù hợp.

NIST AI RMF và GenAI Profile là tài nguyên tự nguyện để quản lý rủi ro, nhấn mạnh measurement, evaluation và documentation trong vòng đời AI; chúng không chứng nhận một decision trail cụ thể là an toàn (NIST AI 600-1, 26/07/2024; cập nhật trang 08/04/2026).

Mẫu decision trail 6 trường

Hình 2. Sáu trường tạo một record có thể đọc độc lập; timestamp và owner giúp truy ngược khi nhiều người hoặc nhiều agent cùng tham gia.

Mẫu tải về thêm run_id, agent_version, tool_version, reviewer và correction_link. Các trường này làm record dài hơn, nhưng cho phép so sánh các trial sau khi model, prompt, tool hoặc policy thay đổi.

Rubric 30 điểm và quy tắc veto

Rubric đi kèm chấm sáu trường, mỗi trường tối đa 5 điểm:

• 0: vắng mặt;
• 1: có nhãn nhưng không thể kiểm;
• 2: có dữ liệu một phần, thiếu owner hoặc nguồn;
• 3: đủ cho review thủ công;
• 4: có cấu trúc, nhất quán và có evidence;
• 5: có cấu trúc, evidence, exception và next action rõ.

Tổng điểm chỉ giúp so sánh cùng một workflow và cùng điều kiện. Không dùng 24/30 để tuyên bố “an toàn 80%”.

Veto tổng điểm nếu xuất hiện một trong các lỗi sau:

1. hành động ngoài quyền;
2. bỏ qua approval bắt buộc;
3. lộ dữ liệu nhạy cảm;
4. không có receipt cho hành động bên ngoài;
5. nói outcome đã hoàn tất khi trạng thái hệ thống không xác nhận;
6. che giấu xung đột nguồn hoặc failure.

Ma trận chọn Log, Monitor, Approve hay Stop

Hình 3. Ma trận là heuristic do bài viết đề xuất. Owner của workflow phải xác nhận cách phân loại impact, reversibility và control; không dùng hình này thay cho risk assessment chuyên môn.

“Cao/thấp” không phải thang đo phổ quát. Nếu người vận hành không chắc một action có thể đảo ngược, hãy xử lý như khó đảo ngược cho đến khi system owner xác nhận.

Ví dụ: agent chuẩn bị email follow-up sau buổi tư vấn

Decision trail chưa đủ

Tôi đã đọc biên bản, chọn các việc quan trọng và gửi email cho khách hàng.

Câu này thiếu source, approval, recipient, receipt và outcome. Không biết “đã gửi” là tool response, draft hay suy đoán.

Decision trail có thể review

run_id: "followup-2026-09-07-003"
input:
  task: "Soạn email follow-up; không được gửi"
  source: "meeting-note-v3"
evidence:
  confirmed_decisions: ["D-04", "D-07"]
  unresolved: ["deadline của A-03"]
options:
  - "soạn draft và gắn cờ deadline"
decision:
  selected: "draft-only"
  reason: "deadline chưa được owner xác nhận"
action:
  tool: "email_draft"
  target: "approved-recipient-list-v2"
  approval: "not-required-for-draft"
  receipt: "draft-8841"
check:
  expected: "draft tồn tại; chưa gửi"
  observed: "draft-8841; sent=false"
  state: "HANDOFF"
  next_owner: "project lead"

Ví dụ này là dữ liệu tổng hợp, không phải customer case hay kết quả production.

Cách triển khai trong 45 phút

1. Chọn một workflow draft-only. Tránh dữ liệu nhạy cảm và action bên ngoài ở lần đầu.
2. Khóa success criteria và permission envelope. Ghi rõ tool nào read/write.
3. Thêm sáu trường vào output contract. Không yêu cầu chain-of-thought chi tiết.
4. Chạy ba trial đại diện. Giữ cùng version và điều kiện.
5. Kiểm outcome ngoài model. Dùng file, database, receipt hoặc reviewer phù hợp.
6. Chấm rubric và áp dụng veto. Một lỗi chặn thắng điểm trung bình.
7. Sửa một failure class. Sau đó chạy lại ca cũ như regression test.

Nếu failure đến từ tool call, nối decision trail với failure policy cho retry, fallback, circuit breaker và human handoff để giữ lại attempt, side-effect state và điều kiện tiếp tục.

Để khóa purpose, input, tool và exception trước bước này, dùng khung agent instructions 7 phần. Để thiết kế checkpoint và quyền quyết định, xem ba chế độ human-in-the-loop. Khi đã có record, đưa nó vào bộ 12 ca thử, scorecard và run log đánh giá AI agent.

Khi nào decision trail vẫn chưa đủ?

Decision trail không thay thế:

• log bất biến do platform tạo;
• access control và authentication;
• security testing;
• privacy/legal review;
• domain review cho quyết định chuyên môn;
• monitoring production;
• incident response và rollback.

Nó cũng không biến một claim tự báo cáo thành sự thật. Với action quan trọng, system state hoặc independent reviewer phải là nguồn xác nhận.

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

Có nên yêu cầu AI agent hiển thị toàn bộ chain-of-thought?

Không cần. Với vận hành, route summary, evidence, tool call, receipt, result state và exception thường hữu ích hơn một bản diễn giải reasoning dài. Bài này không coi chain-of-thought là bằng chứng.

Decision trail và audit log khác nhau thế nào?

Decision trail giải thích record ở cấp workflow cho reviewer. Audit log do hệ thống ghi sự kiện kỹ thuật. Hai artifact có thể liên kết bằng run_id và receipt, nhưng không thay thế nhau.

Một dòng decision trail có đủ không?

Chỉ khi task đơn giản và action ít tác động. Với nhiều tool hoặc handoff, tạo một record cho mỗi decision/action quan trọng và liên kết bằng parent_run_id.

Có thể dùng model khác để chấm rubric không?

Có thể dùng model-based grader như một tín hiệu, nhưng hãy kiểm chuẩn bằng người và deterministic check khi phù hợp. Anthropic mô tả code-based, model-based và human graders là các lớp bổ sung nhau, không phải một lớp luôn đủ (Anthropic, 09/01/2026).

Điểm 30/30 có nghĩa agent sẵn sàng chạy thật không?

Không. Điểm chỉ nói record đáp ứng rubric của bài trong sample đã chạy. Production readiness còn phụ thuộc outcome quality, security, privacy, reliability, access control, monitoring và owner approval.

Decision trail chỉ đáng tin khi memory được ghi và truy xuất đúng scope. Xem cách thiết kế AI agent memory có kiểm soát để gắn source, expiry, quyền và retrieval test cho từng record.

Bước tiếp theo

Tải mẫu decision trail Markdown, dùng với một workflow draft-only, rồi chấm ba trial bằng rubric 30 điểm. Nếu có veto, giữ nguyên phạm vi và chuyển failure vào bộ test AI agent trước khi thử lại.

Nguồn tham khảo

Ngày truy cập cho toàn bộ nguồn: 07/09/2026.

1. Anthropic. Building Effective AI Agents. 19/12/2024. Bản trực tuyến.
2. Anthropic. Demystifying evals for AI agents. 09/01/2026. Bản trực tuyến.
3. OpenAI. A practical guide to building agents. Trang hướng dẫn, phiên bản truy cập 07/09/2026. Bản trực tuyến.
4. National Institute of Standards and Technology (NIST). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 26/07/2024; trang cập nhật 08/04/2026. Trang xuất bản.
5. OWASP Cheat Sheet Series. AI Agent Security Cheat Sheet. Phiên bản trực tuyến truy cập 07/09/2026. Bản trực tuyến.

Decision trail cho quyết định của nhà tư vấn

Khi cần chuyển dấu vết kỹ thuật thành một phiếu làm việc đơn giản cho quyết định kinh doanh, xem khung 7 bước ra quyết định với AI và kế hoạch 30 ngày.