Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Agent Planning là quá trình biến mục tiêu thành đồ thị hành động có trạng thái, ràng buộc, cổng kiểm soát và cách xác minh kết quả. Nó cần thiết vì agent phải biết bước tiếp theo, khi nào được hành động, khi nào dừng, và cách cập nhật kế hoạch khi tình hình đổi.

Đọc xong, bạn sẽ hiểu:

  • Cách viết một plan quan sát được thay vì danh sách việc chung chung.
  • Cách tách dependencies, bước song song, approval gate và side effect.
  • Cách execute, checkpoint, verify, replan hoặc handoff khi dữ liệu lệch.

1. Agent Planning là gì, và khác checklist ở đâu?

Một action plan là artifact quan sát được mô tả agent sẽ làm gì, theo thứ tự nào, với điều kiện nào và kết quả nào phải xuất hiện. Nó không phải bản chép toàn bộ reasoning nội bộ của model. Người vận hành cần thấy hợp đồng hành động đủ để duyệt, chạy, kiểm tra và phục hồi; họ không cần một đoạn độc thoại dài để đoán agent định làm gì.

Checklist thường chỉ nói “đọc hóa đơn, kiểm tra, tính tổng, submit”. Plan tốt phải nói thêm:

  • Đọc ba file nào và có quyền đọc không?
  • Có thể extract song song hay phải chờ bước trước?
  • Hóa đơn thiếu trường bắt buộc được xử lý ra sao?
  • Cái gì được coi là duplicate?
  • Tổng nào được đưa vào draft?
  • Ai được phép approve?
  • Retry có tạo hai lần submit không?

Giống như nấu ăn, shopping list chỉ cho biết cần mua gì. Công thức thực thi còn có định lượng, thứ tự, nhiệt độ, dấu hiệu món đã chín và lúc phải bỏ mẻ hỏng. Agent cũng cần các điều kiện tương tự.

Hình 1 — Plan là hợp đồng hành động để kiểm soát; nó không phải bản chép suy nghĩ riêng của model.

Planning cũng khác execution. Planning tạo action graph và gates; execution mới gọi tool, ghi file hoặc gửi request. Tách hai phần giúp dry run trước khi gây side effect. Planning cũng khác reasoning: reasoning có thể giúp model chọn bước, nhưng artifact cần kiểm soát là goal, state, action, dependency, gate và verifier.

Plan-and-Solve nghiên cứu cách lập plan chia bài toán thành subtasks rồi thực hiện lần lượt trên các reasoning benchmarks. Ý tưởng decomposition hữu ích, nhưng kết quả paper không tự chứng minh một production agent đã an toàn. Tool permissions, side effects và rollback là những lớp triển khai riêng.

Khi nào không cần một planner phức tạp? Một phép biến đổi cục bộ, dễ đảo ngược và chỉ có một bước có thể dùng flow cố định. Thêm agent planning vào mọi câu hỏi sẽ tăng độ trễ và thêm điểm lỗi. Độ phức tạp của plan phải tương xứng với số bước, độ bất định và hậu quả của hành động.

2. Bản hợp đồng của một plan có thể thực thi

Plan chạy được bắt đầu bằng current state: những gì đang đúng tại thời điểm bắt đầu hoặc tiếp tục. Nó giống bảng điện sân bay; không thể dùng lịch ban đầu nếu chuyến đã trễ hoặc hủy. State phải tách điều đã quan sát khỏi điều đang giả định.

Hình 2 — Một plan chạy được phải nói rõ trạng thái vào, điều kiện hành động và cách xác nhận kết quả.

Một plan tối thiểu nên có tám phần:

  1. Goal: kết quả người dùng thực sự cần.
  2. Current state: việc đã làm, dữ liệu đã thấy, bước đang blocked.
  3. Constraints: quyền, budget, thời gian, scope và hành động cấm.
  4. Actions: bước nhỏ có owner hoặc tool rõ.
  5. Dependencies: bước nào phải chờ, bước nào độc lập.
  6. Pre/Postconditions: điều kiện trước và bằng chứng sau mỗi action.
  7. Success criteria: trạng thái nào mới được gọi là hoàn tất.
  8. Rollback/Handoff: quay về đâu hoặc giao ai nếu không thể tiếp tục.

Precondition là điều phải đúng trước action. Ví dụ, trước khi extract I1, file phải thuộc read scope và có source ID. Postcondition là trạng thái quan sát được sau action: một record chứa amount, date, merchant và file hash; không phải câu mơ hồ “đã xử lý xong”.

Case giả xuyên suốt có goal CREATE REIMBURSEMENT DRAFT, không phải SUBMIT. State ban đầu:

I1: 480k, đủ date + merchant + source ID
I2: 320k, thiếu merchant
I3: 480k, cùng hash với I1
CAP: 1.000k
PERMISSION: read + local draft
FORBIDDEN: external submit

k là nghìn đơn vị tiền giả, không phải giao dịch thật. Success criteria là draft_ready, eligible total 480k, I2 nằm trong blocked list, I3 nằm trong duplicate list và next action là human review. Nếu agent tạo draft 1.280k, plan đã thất bại dù file được tạo đúng schema.

Plan phải ghi rõ câu nào chắc và câu nào có điều kiện. Chắc chắn: external submit là side effect nên phải có approval gate. Có điều kiện: extract I1–I3 có thể chạy song song nếu tool hỗ trợ concurrency và ba file độc lập. Chưa biết tool limit thì giữ chúng tuần tự hoặc đo trước, không hứa nhanh hơn.

3. Từ yêu cầu đến task DAG: case ba hóa đơn giả

Dependency graph, thường biểu diễn bằng DAG, là đồ thị cho biết task nào phụ thuộc task nào mà không tạo vòng vô hạn. Xây tầng hai phải chờ móng; sơn hai phòng có thể song song nếu không tranh cùng nguồn lực.

Hình 3 — Chỉ các bước độc lập mới chạy song song; submit vẫn bị khóa sau human approval.

Ta biên dịch yêu cầu thành bảy bước:

S1 INVENTORY
 ├─ S2a EXTRACT I1
 ├─ S2b EXTRACT I2
 └─ S2c EXTRACT I3
        ↓
S3 VALIDATE + DEDUP
        ↓
S4 CALCULATE ELIGIBLE TOTAL
        ↓
S5 CREATE LOCAL DRAFT
        ↓
S6 HUMAN APPROVAL GATE
        ↓
S7 EXTERNAL SUBMIT — OUT OF SCOPE

S1 kiểm kê và gắn ID; không đọc lén ngoài scope. S2a/b/c chỉ bắt đầu khi S1 xác nhận quyền. S3 cần đủ records và source IDs, rồi phát hiện I2 thiếu merchant, I3 trùng hash I1. S4 chỉ cộng eligible records nên 480k ≤ 1.000k. S5 tạo local draft, exception log và verifier report. S6 không phải ô để agent tự tick; đó là state awaiting_human_approval. S7 bị khóa trong demo.

Một gate là điều kiện cứng trước hành động rủi ro. Gate khác scoring: relevance 0,9 không thể bù cho permission sai. Với S7, preconditions phải gồm explicit approval, draft hash không đổi, destination đúng và idempotency key. Thiếu một điều kiện thì không gọi tool.

DAG cũng làm lộ critical path — chuỗi dependencies quyết định thời gian sớm nhất để hoàn tất. S2a/b/c có thể song song, nhưng S3 phải chờ cả ba nếu goal yêu cầu báo cáo đầy đủ. Nếu người dùng cho phép partial draft, plan có thể tách nhánh: xử lý I1 trước, giữ I2 blocked và I3 chờ dedup. Đó là thay đổi policy, không phải tối ưu ngầm.

LLMCompiler mô tả kiến trúc gồm planner, task-fetching unit và executor để điều phối function calls, bao gồm những call có thể chạy song song. Ta chỉ mượn cách nhìn dependencies. Không được suy ra mọi DAG sẽ giảm latency hoặc cost trong hệ thống của mình; rate limits, shared state và retries có thể làm ngược lại.

Trước execution, hãy dry run: đi qua graph mà không gọi side-effect tool. Dry run phải trả lời được input/output mỗi node, permission cần có, cách phát hiện success và nhánh failure. Nếu S3 chỉ ghi “validate carefully”, plan chưa đủ cụ thể để chạy hay test.

4. Execute, observe và replan khi thế giới không đi đúng plan

Plan không phải đường ray bất biến. Sau mỗi action, agent phải đọc observation thật và so với postcondition. ReAct nghiên cứu việc xen kẽ reasoning và action để lấy thông tin từ môi trường, theo dõi và cập nhật plan. Đây là pattern nghiên cứu; production vẫn cần permission model, audit log và failure policy riêng.

Hình 4 — Replan bắt đầu từ state vừa quan sát, không quay lại giả định cũ hoặc retry mù.

Vòng điều khiển thực tế:

EXECUTE → OBSERVE → VERIFY → CONTINUE | REPLAN | ROLLBACK | HANDOFF

Sau S2, observation cho biết I2 thiếu merchant. Agent không được tự bịa tên cửa hàng để giữ plan “xanh”. Nó cập nhật state I2_BLOCKED_MISSING_MERCHANT, tạo request for information và tiếp tục nhánh hợp lệ nếu policy cho phép. Sau S3, I3 trùng I1; state ghi duplicate và provenance, không xóa file gốc nếu chưa có quyền.

Checkpoint là state đã lưu để resume hoặc recover: completed nodes, output hashes, exceptions và next eligible actions. Nếu process dừng sau S4, lần chạy sau bắt đầu từ checkpoint đã verify, không extract lại mù quáng.

Replan là cập nhật graph từ state/evidence mới. Nó không phải viết lại mục tiêu để che thất bại. Goal vẫn là create draft; graph thay đổi vì I2 blocked. Một replan hợp lệ phải ghi:

  • observation nào kích hoạt;
  • node nào bị vô hiệu;
  • dependencies nào đổi;
  • constraint nào vẫn giữ;
  • success criteria có cần user phê duyệt lại không.

Idempotency nghĩa là retry không nhân đôi side effect. Local draft có thể dùng deterministic filename hoặc draft ID. External submit cần idempotency key và kiểm tra receipt trước retry. Nếu không chứng minh được retry-safe, stop và handoff.

Rollback đưa hệ thống về trạng thái an toàn đã biết; handoff giao người có quyền hoặc phán đoán phù hợp. Ví dụ, draft tạo sai total có thể bị đánh dấu invalid và dựng lại từ checkpoint. Một khoản đã submit có thể không “undo” được bằng xóa local file; lúc đó cần quy trình nghiệp vụ, không giả vờ rollback kỹ thuật.

Sai khác giữa expected và observed không phải lúc nào cũng là lỗi tool. Nó có thể cho thấy giả định plan sai, dữ liệu đổi hoặc user intent chưa rõ. Khi đó, hỏi một câu hẹp tốt hơn retry năm lần cùng input.

5. Sai lầm, checklist và bài tập 15 phút

Sai lầm thứ nhất là lập plan theo happy path duy nhất. Nếu không có nhánh missing data, permission denied và partial failure, agent sẽ đoán hoặc mắc vòng retry. Sai lầm thứ hai là đặt approval sau side effect — giống khóa cửa sau khi đồ đã được gửi đi.

Sai lầm thứ ba là coi “tool trả 200” là task success. S5 có thể tạo file thành công nhưng total sai. Verifier phải kiểm schema, eligible set, phép cộng, exception log và forbidden actions. Sai lầm thứ tư là parallel mọi thứ: hai bước cùng ghi một state có thể race, còn S4 chạy trước S3 sẽ cộng duplicate.

Giới hạn quan trọng: plan không sửa được tool không đáng tin, permission model lỏng hay mục tiêu mơ hồ. Plan càng dài càng dễ stale. Với task nhiều bất định, loop ngắn observe–replan có thể hợp hơn một DAG khổng lồ dựng trước.

Checklist triển khai

  1. Viết goal bằng trạng thái kết quả, không bằng tên tool.
  2. Chụp current state và tách observation khỏi assumption.
  3. Khóa scope, permissions, budget và forbidden actions.
  4. Chia action đủ nhỏ để có pre/postcondition đo được.
  5. Vẽ dependencies; chỉ parallel node thực sự độc lập.
  6. Đặt approval trước side effect, không đặt sau.
  7. Dry run graph và inject ít nhất một failure.
  8. Lưu checkpoint cùng output hash và exception.
  9. Verify task result, không chỉ HTTP/tool success.
  10. Ghi stop rule, rollback và human handoff.

Hãy đứng ngoài khi không rõ goal owner, data scope hoặc người có quyền approve. Dừng khi postcondition không khớp, retry không idempotent, verifier thiếu hoặc external state đã đổi ngoài plan.

Bài tập 15 phút

Mở một spreadsheet miễn phí. Không gọi API, không upload chứng từ thật và không dùng tiền thật.

  • 3 phút: ghi goal CREATE DRAFT; forbidden action SUBMIT.
  • 3 phút: nhập state I1 480k valid, I2 320k missing merchant, I3 480k duplicate.
  • 4 phút: vẽ dependencies và đánh read-only/side effect.
  • 3 phút: ghi pre/postconditions, approval gate và stop rule.
  • 2 phút: so expected state với kết quả mô phỏng.

Mẫu đối chiếu đã điền

Step Depends on Mode Precondition Expected postcondition
S1 Inventory — Read Có 3 fake files I1/I2/I3 có ID
S2 Extract I1-I3 S1 Parallel read Read scope hợp lệ Ba records
S3 Validate S2 Read Records có source ID I1 valid; I2 blocked; I3 duplicate
S4 Calculate S3 Read Chỉ dùng eligible Total 480k ≤ cap 1.000k
S5 Create draft S4 Local write Schema đạt Draft total 480k
S6 Approval gate S5 Human Draft + exception log Awaiting approval
S7 Submit S6 External side effect Approval + idempotency Không chạy trong demo

Mẫu đạt khi state cuối là draft_ready, total 480k, blocked [I2], duplicate [I3], next action human review. Nếu spreadsheet ghi submitted, bạn đã vượt scope.

6. Tổng kết và bài học tiếp theo

a. Năm ý chính

  • Agent Planning tạo action contract có state, gates và verifier.
  • Precondition bảo vệ trước action; postcondition chứng minh điều vừa xảy ra.
  • DAG làm rõ dependencies nhưng chỉ parallel bước độc lập.
  • Observation mới phải dẫn tới verify, replan, rollback hoặc handoff.
  • Task chỉ hoàn tất khi đạt success criteria mà không vi phạm constraints.

b. Câu hỏi tự kiểm tra

  • Vì sao checklist “đọc, tính, submit” chưa phải plan thực thi?
  • Trong case demo, tại sao eligible total chỉ là 480k?
  • Replan khác retry mù ở điểm nào?
  • Approval gate và idempotency bảo vệ hai rủi ro khác nhau ra sao?

c. Gợi ý đáp án

Xem gợi ý câu 1

Nó thiếu state, dependencies, pre/postconditions, gates và verifier. Xem mục 1–2.

Xem gợi ý câu 2

Chỉ I1 eligible; I2 thiếu merchant và I3 trùng I1. Xem mục 3.

Xem gợi ý câu 3

Replan dùng observation mới để đổi graph; retry lặp action cũ mà không đổi giả định. Xem mục 4.

Xem gợi ý câu 4

Approval kiểm quyền trước side effect; idempotency ngăn retry tạo bản ghi trùng. Xem mục 3–4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Agent Planning Biến goal thành action graph có state và gates.
Action plan Hợp đồng hành động quan sát và kiểm thử được.
Current state Điều đang đúng ở thời điểm hiện tại.
Precondition Điều phải đúng trước action.
Postcondition Evidence phải thấy sau action.
Dependency graph Đồ thị thể hiện thứ tự phụ thuộc giữa tasks.
Checkpoint State đã lưu để resume hoặc recover.
Replan Cập nhật graph từ observation mới.
Idempotency Retry không tạo side effect trùng.
Handoff Giao người có quyền hoặc phán đoán phù hợp.

e. Nguồn tham khảo

Bài trước, Context Optimization #12, đóng gói evidence cho một task. Bài này biến goal và evidence thành plan có kiểm soát. Bài sau, Multi-Agent Collaboration #14, sẽ tách ownership và giao tiếp khi nhiều agent cùng tham gia một graph.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.