Các bài trước trong module đã giới thiệu cơ chế và cách gắn Sequential Thinking MCP vào từng agent cụ thể (Claude Code, OpenCode, Gemini CLI, Cursor). Bài này đóng vai trò tổng kết bằng một case study end-to-end: đi từ một đề bài mơ hồ ("hệ thống chậm khi tải cao, cần cải thiện") tới một kế hoạch thực thi cụ thể, có thể giao cho agent code trực tiếp — thể hiện toàn bộ vòng đời dùng structured reasoning trong một workflow kỹ thuật thật, không phải ví dụ minh hoạ đơn lẻ như các bài trước.
Tổng Quan Workflow: Từ Đề Bài Mơ Hồ Đến Kế Hoạch Có Thể Thực Thi
Bài toán xuất phát điểm (nguyên văn từ một báo cáo incident): "Hệ thống checkout bị chậm nghiêm trọng vào giờ cao điểm (Black Friday), có lúc timeout hoàn toàn, cần fix trước campaign tiếp theo trong 3 tuần." Đây là một đề bài kinh điển của thực tế engineering — không có root cause rõ ràng, không có scope cố định, và có deadline áp lực thật.
Workflow tổng thể khi dùng Sequential Thinking cho loại bài toán này gồm 3 giai đoạn tương ứng với 3 phần tiếp theo của bài:
- Đóng khung bài toán: biến một câu than phiền mơ hồ thành danh sách câu hỏi cụ thể cần trả lời và giả thuyết cần kiểm chứng — đây là giai đoạn dễ bị bỏ qua nhất khi engineer (và agent) vội vàng nhảy vào "sửa" ngay.
- Rẽ nhánh và chấm điểm trade-off: với mỗi giả thuyết/hướng fix, so sánh chi phí-lợi ích, và quan trọng là sửa lại khi bằng chứng mới xuất hiện giữa quá trình phân tích.
- Chuyển thành task list và thực thi: kết quả suy luận phải "đóng băng" lại thành các task cụ thể, có thứ tự, giao được cho agent hoặc con người — nếu không, toàn bộ suy luận chỉ nằm trong log chat mà không tạo ra giá trị thực.
Điểm mấu chốt cần nhấn mạnh: Sequential Thinking không thay thế việc bạn (engineer) phải hiểu hệ thống — nó là công cụ giúp tổ chức lại việc suy luận của agent (và gián tiếp, của chính bạn khi review) một cách có kỷ luật, tránh tình trạng agent (hoặc con người) chọn giải pháp đầu tiên nghe "có vẻ đúng" mà không xét các khả năng khác.
Mẹo: Trước khi giao bất kỳ bài toán mơ hồ nào cho agent, tự viết ra 2-3 câu hỏi bạn nghĩ agent cần trả lời trước khi hành động, rồi đưa thẳng câu hỏi đó vào prompt. Việc này không chỉ giúp agent lập luận đúng hướng mà còn buộc bạn — người giao việc — phải hiểu rõ vấn đề trước khi delegate, tránh tình trạng "giao việc mơ hồ, nhận kết quả mơ hồ".
Bước 1: Đóng Khung Bài Toán và Liệt Kê Các Yếu Tố Chưa Biết
Prompt mở đầu workflow, cố tình không gợi ý sẵn giải pháp để tránh dẫn dắt agent (và cả bản thân bạn) tới một kết luận sớm sai:
Hệ thống checkout bị chậm nghiêm trọng vào giờ cao điểm, có timeout hoàn toàn.
Có 3 tuần trước campaign tiếp theo. Dùng sequential thinking để:
1. Liệt kê các thành phần trong luồng checkout có thể là nguyên nhân
(dựa vào code trong src/checkout/ và src/payment/).
2. Với mỗi thành phần, nêu rõ cần dữ liệu/log gì để xác nhận hoặc loại trừ nó
là nguyên nhân — KHÔNG kết luận nguyên nhân khi chưa có bằng chứng.
3. Đề xuất thứ tự thu thập bằng chứng theo độ ưu tiên (thành phần nào dễ kiểm tra
trước, ít tốn thời gian).
Chuỗi thought thực tế cho giai đoạn này tập trung vào việc liệt kê giả thuyết kèm cách kiểm chứng — không nhảy vào kết luận:
{"thought": "4 điểm nghi vấn trong luồng checkout: (1) gọi đồng bộ tới payment gateway ngoài, (2) query kiểm tra inventory real-time trên DB chính, (3) tính toán giá/discount có thể có N+1 query, (4) session lock khi nhiều request cùng user (double-click submit).", "thoughtNumber": 1, "totalThoughts": 8, "nextThoughtNeeded": true}
{"thought": "Để xác nhận (1), cần log latency p50/p95/p99 của call tới payment gateway trong giờ cao điểm gần nhất — nếu p99 tăng vọt đúng lúc traffic cao, khả năng cao đây là bottleneck. Đây là bằng chứng dễ lấy nhất (đã có trong APM/observability tool), nên kiểm tra đầu tiên.", "thoughtNumber": 2, "totalThoughts": 8, "nextThoughtNeeded": true}
{"thought": "Để xác nhận (2), cần EXPLAIN ANALYZE query inventory check dưới tải cao — nhưng khó tái tạo tải cao ở môi trường test, nên ưu tiên thấp hơn (1), chỉ kiểm tra nếu (1) bị loại trừ.", "thoughtNumber": 3, "totalThoughts": 8, "nextThoughtNeeded": true}
Kết quả giai đoạn 1 không phải là "giải pháp" mà là một danh sách giả thuyết đã được xếp hạng theo độ dễ kiểm chứng — đúng với tinh thần debug có phương pháp (không đoán bừa, không sửa mù). Đây chính là điểm khác biệt lớn nhất so với việc hỏi thẳng agent "sửa sao cho checkout nhanh hơn", vốn thường khiến agent đoán một nguyên nhân và code fix ngay mà không kiểm chứng.
Mẹo: Luôn cấm agent (bằng câu lệnh rõ trong prompt) đưa ra kết luận nguyên nhân ở giai đoạn đóng khung bài toán — chỉ cho phép liệt kê giả thuyết và cách kiểm chứng. Kết luận sớm ở bước này là nguồn sai lầm phổ biến nhất khi debug production issue, dù là agent hay con người thực hiện.
Bước 2: Rẽ Nhánh Các Phương Án, Chấm Điểm Trade-off và Sửa Lại Giả Định
Sau khi thu thập log thực tế (giả sử kết quả: p99 latency của payment gateway tăng từ 200ms lên 4.5s đúng lúc traffic cao — xác nhận giả thuyết (1)), giai đoạn 2 chuyển sang so sánh các hướng fix bằng branching:
Đã xác nhận: payment gateway call đồng bộ có p99 4.5s khi traffic cao (bình thường 200ms).
Dùng sequential thinking, rẽ nhánh so sánh 3 hướng fix:
A. Thêm timeout ngắn + retry với backoff cho call payment gateway.
B. Chuyển xác nhận payment sang async: nhận order trước, xác nhận payment qua webhook.
C. Thêm circuit breaker, fallback sang gateway backup khi gateway chính chậm.
Chấm điểm mỗi hướng theo: thời gian implement trong 3 tuần, mức độ thay đổi UX
người dùng, rủi ro về tính đúng đắn giao dịch (consistency).
{"thought": "Nhánh A (timeout+retry): implement nhanh (2-3 ngày), nhưng không giải quyết root cause — nếu gateway chậm kéo dài, retry chỉ tăng thêm tải, có thể làm tệ hơn.", "thoughtNumber": 4, "totalThoughts": 9, "nextThoughtNeeded": true, "branchFromThought": 3, "branchId": "timeout-retry"}
{"thought": "Nhánh B (async qua webhook): giải quyết root cause thật, nhưng thay đổi UX đáng kể (user không thấy kết quả payment ngay) và rủi ro consistency cao nếu webhook bị trễ/mất — cần thêm cơ chế reconciliation, ước tính 2-3 tuần, sát deadline, rủi ro không kịp test kỹ.", "thoughtNumber": 5, "totalThoughts": 9, "nextThoughtNeeded": true, "branchFromThought": 3, "branchId": "async-webhook"}
{"thought": "Nhánh C (circuit breaker + fallback gateway backup): implement trong ~1 tuần nếu đã có sẵn tài khoản gateway backup (cần xác nhận), giữ nguyên UX đồng bộ, giảm rủi ro consistency vì vẫn là luồng đồng bộ — nhưng cần gateway backup đã test kỹ trước campaign.", "thoughtNumber": 6, "totalThoughts": 9, "nextThoughtNeeded": true, "branchFromThought": 3, "branchId": "circuit-breaker"}
Giả sử khi kiểm tra, phát hiện công ty chưa có hợp đồng với gateway backup nào — đây là bằng chứng mới buộc phải revise:
{
"thought": "Phát hiện công ty chưa có gateway backup nào được tích hợp sẵn — nhánh C không khả thi trong 3 tuần vì cần thời gian tích hợp + test một gateway mới. Cần revise: kết hợp A (timeout+retry hợp lý, không retry vô hạn) làm giải pháp tạm ngay, và lên roadmap riêng cho nhánh C sau campaign này.",
"thoughtNumber": 7,
"totalThoughts": 9,
"nextThoughtNeeded": true,
"isRevision": true,
"revisesThought": 6
}
Đây chính là khoảnh khắc thể hiện rõ nhất giá trị của Sequential Thinking so với một prompt đơn: bằng chứng thực tế (không có gateway backup) xuất hiện giữa quá trình suy luận, và agent sửa lại kết luận của nhánh C thay vì âm thầm bỏ qua mâu thuẫn hoặc phải làm lại toàn bộ phân tích từ đầu.
Mẹo: Luôn cung cấp thông tin ràng buộc thực tế (có sẵn hạ tầng gì, chưa có gì) ngay khi phát hiện ra trong quá trình trao đổi — đừng đợi tới cuối mới cung cấp. Sequential Thinking xử lý tốt việc chèn thông tin mới giữa chừng và revise, đó là lý do bạn nên tận dụng nó real-time, không cần chờ "hỏi đủ hết rồi mới bắt đầu".
Bước 3: Chuyển Chuỗi Suy Luận Thành Task List và Thực Thi
Chuỗi thought, dù chất lượng tốt, vẫn chỉ là văn bản trong log chat — giá trị thực chỉ hiện ra khi nó được "đóng băng" thành task cụ thể. Prompt kết thúc workflow:
Dựa trên toàn bộ phân tích trên, chuyển thành task list cụ thể để thực thi trong
3 tuần, có thứ tự ưu tiên, mỗi task ghi rõ: file/module liên quan, tiêu chí hoàn thành
(definition of done), và ai nên làm (agent tự code được, hay cần con người quyết định).
Kết quả mong đợi (ví dụ rút gọn) mà agent nên tổng hợp lại từ toàn bộ chuỗi thought phía trên:
## Task List — Fix Checkout Timeout Trước Campaign (3 tuần)
### Tuần 1 — Giải pháp tạm, triển khai ngay
- [ ] Thêm timeout 3s + retry tối đa 2 lần (backoff 500ms/1500ms) cho call payment
gateway trong `src/payment/gateway_client.py`.
DoD: load test giả lập p99 4.5s vẫn trả response cho user trong <5s, không retry vô hạn.
Người thực hiện: agent tự code + viết test, engineer review trước merge.
- [ ] Thêm alert khi latency payment gateway p95 vượt 1s, báo ngay qua Slack on-call.
DoD: alert bắn thử được trong staging bằng cách giả lập delay.
Người thực hiện: agent tự code phần alert rule, DevOps xác nhận kênh Slack đúng.
### Tuần 2 — Chuẩn bị dữ liệu cho quyết định dài hạn
- [ ] Nghiên cứu 2 gateway backup khả thi, so sánh chi phí + thời gian tích hợp.
DoD: bảng so sánh có ít nhất 2 gateway, kèm ước tính effort tích hợp.
Người thực hiện: CON NGƯỜI quyết định (liên quan hợp đồng/chi phí, agent chỉ hỗ trợ research).
### Tuần 3 — Kiểm thử tải trước campaign
- [ ] Load test lại toàn bộ luồng checkout với traffic giả lập gấp 3 lần giờ cao điểm gần nhất.
DoD: không còn timeout hoàn toàn, p99 dưới 5s.
Người thực hiện: agent tự chạy test suite, engineer review kết quả trước go-live.
Lưu ý cách task list phân biệt rõ "agent tự làm được" và "cần con người quyết định" — đây là chi tiết quan trọng thường bị bỏ qua: không phải mọi kết luận từ Sequential Thinking đều nên giao thẳng cho agent thực thi tự động, đặc biệt các quyết định có ràng buộc kinh doanh/hợp đồng (như chọn gateway backup) vẫn cần con người quyết định cuối.
Mẹo: Luôn yêu cầu agent phân loại rõ mỗi task thành "agent tự thực thi được" hay "cần con người quyết định/duyệt" ngay trong bước chuyển đổi thành task list — nếu không, dễ xảy ra tình trạng agent tự tiện thực thi luôn cả những quyết định có tác động kinh doanh mà lẽ ra bạn phải là người approve trước.