Trả lời ngắn: Planning Agent là agent tạo kế hoạch có cấu trúc cho goal nhiều bước, chọn bước khả thi tiếp theo rồi cập nhật kế hoạch theo observation. Plan tốt có dependency, điều kiện bắt đầu, tiêu chí hoàn tất, trạng thái và budget. Nó là state có phiên bản, không phải danh sách đóng đinh phải làm bằng mọi giá.

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

  • Planning Agent khác checklist và loop thông thường ở đâu.
  • Một plan step cần những trường tối thiểu nào.
  • Cách observation kích hoạt replan mà không xoá lịch sử.
  • Cách tự điền Plan Card bằng dữ liệu workshop giả.

Lưu ý giáo dục: Bài dùng plan summary và dữ liệu giả, không yêu cầu công khai private chain-of-thought. Hệ thật phải giới hạn tool, quyền, chi phí, số bước và side effect; bước nhạy cảm cần approval của người chịu trách nhiệm.

1. Planning Agent là gì?

a. Từ một goal đến đường đi có thể kiểm tra

Bạn muốn tìm một workshop diễn ra Chủ nhật, giá dưới 500k và còn chỗ. Goal nghe đơn giản nhưng chứa nhiều khoảng trống: workshop nào đúng ngày, giá bao nhiêu, trạng thái chỗ còn mới không, nguồn nào xác nhận? Nếu agent gọi tool ngẫu nhiên, nó dễ lặp tìm kiếm hoặc kết luận quá sớm.

Planning Agent tạo plan: bản đồ tạm thời nối goal với các bước có thể thực thi. Mỗi bước nói rõ nó phụ thuộc vào gì, dùng tool hay owner nào, khi nào được bắt đầu và evidence nào chứng minh đã xong. Sau mỗi action, observation cập nhật state. Nếu giả định đổi, agent tạo phiên bản plan mới.

Hình 1 — Plan là state sống giữa goal và hành động; observation có thể giữ đường đi, đổi đường hoặc kết thúc run.

b. Checklist, plan và private reasoning không giống nhau

Checklist chỉ liệt kê việc thường cần làm. Nó hữu ích khi đường đi ổn định, nhưng thường không biểu diễn dependency hoặc dữ kiện mới. Plan gắn từng step với state hiện tại và done rule. Private reasoning là quá trình nội bộ của model; hệ không cần lưu hay phơi toàn bộ quá trình đó để vận hành an toàn.

Nên log plan summary: goal, step ID, dependency, action dự kiến, evidence, trạng thái và lý do đổi. Như vậy đủ để debug mà không lưu dòng suy nghĩ dài.

c. Khi nào đáng dùng planning?

Với câu hỏi một bước, plan chỉ thêm độ trễ. Chỉ thêm planner khi decomposition và replan thật sự giảm lỗi.

2. Một plan tốt phải chứa gì?

a. Goal và acceptance test

Goal mô tả kết quả cần đạt. Acceptance test là phép kiểm bên ngoài cho biết kết quả có đạt hay chưa. “Tìm workshop phù hợp” còn mơ hồ; “trả về tên, ngày Chủ nhật, giá dưới 500k, trạng thái còn chỗ và source ID” có thể kiểm.

Một plan không có acceptance test dễ rơi vào plan theater: trông rất có tổ chức nhưng không ai biết khi nào xong. Agent có thể đánh dấu nhiều step completed mà output cuối vẫn thiếu bằng chứng.

b. Schema tối thiểu cho từng step

Hình 2 — Step đủ tốt phải có đầu vào, đường thực thi và phép kiểm hoàn tất; tên bước đẹp là chưa đủ.

Trường Câu hỏi cần trả lời Ví dụ
ID Theo dõi bước nào? S2
Dependency Cần step nào hoàn tất trước? S1
Precondition Điều gì phải đúng mới được chạy? Có candidate ID
Tool / Owner Ai hoặc tool nào thực thi? READ_ID
Done rule Evidence nào chứng minh xong? Có giá và timestamp
Status Chưa chạy, đang chạy, xong hay blocked? ready

Hệ thật còn cần side effect, approval, retry, timeout và cost estimate. Model không được tự đổi step read-only thành write action.

c. Dependency và bước khả thi tiếp theo

Dependency là quan hệ “phải có A trước B”. Scheduler chỉ chọn step có dependency đã thỏa và precondition đúng. Next feasible step là bước hợp lệ theo state, không đơn giản là dòng kế tiếp. Plan cung cấp lựa chọn; vòng Think → Act → Observe #33 thực thi và trả evidence mới.

3. Ví dụ: lập kế hoạch rồi replan

a. Plan v1

Goal giả: tìm một workshop Chủ nhật dưới 500k, còn chỗ; chỉ đề xuất, không đăng ký. Agent có bốn thẻ dữ liệu T1–T4 và tool giấy SEARCH_CARD, READ_ID, ASK_HUMAN.

Step Nội dung Dependency Done rule Status
S1 Tìm thẻ có Chủ nhật — Có candidate IDs ready
S2 Đọc ngày và giá candidate S1 Có ngày, giá, source pending
S3 Kiểm tra còn chỗ S2 Có availability + timestamp pending
S4 So với acceptance test S3 Pass/fail từng điều kiện pending

S1 trả T2 và T3. S2 cho biết T2 giá 420k, T3 giá 450k; cả hai đúng Chủ nhật. Planner không cần viết lại toàn bộ plan: nó cập nhật candidates và đưa S3 sang ready.

b. Observation phá giả định

S3 đọc T2 trước và nhận SOLD_OUT, timestamp 10:05. Nếu agent cố bám kế hoạch “chọn T2 vì rẻ hơn”, nó đang ưu tiên văn bản cũ hơn môi trường. Observation phải cập nhật state: T2 bị loại, T3 chưa kiểm availability.

Đây là replan trigger: sự kiện cho biết một assumption, precondition hoặc đường đi cũ không còn đúng. Trigger có thể là dữ liệu mới, typed error, hết budget, approval bị từ chối hoặc acceptance test đã đạt.

c. Plan v2 giữ lịch sử

Hình 3 — Replan không xoá thất bại; nó giữ observation của T2 và chuyển phần chưa chạy sang T3.

Plan v2 ghi T2=rejected_sold_out; đổi S3 thành kiểm T3; S4 vẫn giữ nguyên. Khi T3 trả AVAILABLE lúc 10:07, S4 xác nhận đủ ngày, giá, availability và source. Run dừng ở complete. Không có bước đăng ký vì goal không cho phép side effect đó.

Log ngắn có thể ghi: version=2, trigger=T2_SOLD_OUT, preserved=S1,S2,evidence, changed=S3 target, next=S3(T3).

4. Khi planning làm hệ tệ hơn

a. Plan quá sớm hoặc quá chi tiết

Khi state còn ít dữ liệu, plan 30 bước chủ yếu là giả định. Dùng planning horizon ngắn: lên khung toàn goal nhưng chỉ chi tiết hóa vài bước gần nhất.

b. Những lỗi phổ biến

  • Plan theater: nhiều nhãn, không có acceptance test hay done rule.
  • Stale plan: observation đổi nhưng agent vẫn làm theo phiên bản cũ.
  • Replan thrashing: mỗi chi tiết nhỏ đều tạo plan mới, tốn token mà không đổi đường đi.
  • History rewrite: xoá step thất bại để log trông sạch.
  • Dependency giả: đánh dấu completed dù evidence đầu vào chưa có.
  • Side-effect creep: thêm gửi, mua, xoá hoặc publish ngoài goal và quyền.

Những lỗi này có thể cộng dồn thành rủi ro lớn trong run dài. Guardrail nên kiểm schema, permission, approval và transition trạng thái bằng code xác định thay vì chỉ nhắc trong prompt.

c. Điều kiện replan, stop và escalate

Không phải observation nào cũng cần replan. Nếu output đúng kỳ vọng, chỉ cập nhật status và tiếp tục. Replan khi đường đi tương lai đổi: assumption sai, step blocked, tool unavailable, budget sắp cạn hoặc có candidate tốt hơn theo tiêu chí đã định.

Agent hoàn tất khi tiêu chí đạt; thử lại có giới hạn khi lỗi tạm thời; hỏi người khi thiếu quyền hoặc mục tiêu mâu thuẫn; dừng khi lỗi không thể khắc phục hoặc hết ngân sách. Agent cũng phải dừng nếu cứ lặp một hành động mà kết quả không đổi.

5. Bài tập 20 phút: Plan Card có phiên bản

a. Chuẩn bị

Viết bốn thẻ workshop giả. T2: Chủ nhật, 420k, hết chỗ. T3: Chủ nhật, 450k, còn chỗ. Hai thẻ còn lại sai ngày hoặc vượt giá. Chỉ dùng tool giấy; không nhập dữ liệu cá nhân và không đăng ký thật.

b. Điền Plan v1

Ghi goal, acceptance test và budget tối đa 5 lần thực thi tool/step: S1, S2, S3(T2), S3(T3) và S4. Replan không đặt lại budget. Tạo bốn step S1–S4 như ví dụ, nhưng tự điền dependency, precondition, tool/owner, done rule và status. Đánh dấu riêng mọi step có side effect; trong bài này phải là none.

c. Nhận observation và tạo Plan v2

Chạy S1, S2 rồi cho S3 nhận T2=SOLD_OUT. Không xoá Plan v1. Tạo dòng change log gồm version, trigger, phần giữ nguyên, phần thay đổi và next feasible step. Sau đó kiểm T3 và chạy acceptance test.

d. Tự chấm

  • Goal có output kiểm được không?
  • Mỗi step có dependency và done rule không?
  • Observation có source/timestamp hoặc typed error không?
  • Plan v2 có giữ evidence thất bại của v1 không?
  • Agent dừng trước hành động ngoài quyền không?

Chỉ đổi “T2” thành “T3” mà không cập nhật state, reason và version thì chưa đủ audit. Tạo lại toàn plan khi chỉ target đổi cũng tốn context.

e. Mẫu đối chiếu

Trường Plan v2 mẫu
Trigger T2=SOLD_OUT
Giữ lại S1, S2 và evidence T2
Thay đổi S3 chuyển sang T3
Stop T3 đạt đủ ngày, giá, chỗ và source

6. Tổng kết: plan là state có thể sửa

a. Năm ý chính

  • Planning Agent biến goal nhiều bước thành plan có cấu trúc và acceptance test.
  • Step tốt có dependency, precondition, tool/owner, done rule và status.
  • Scheduler chọn next feasible step theo state, không mù quáng đọc dòng kế tiếp.
  • Replan giữ lịch sử và evidence, chỉ sửa phần tương lai bị observation tác động.
  • Budget, approval, stop và escalate là thành phần của plan, không phải phụ kiện.

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

  • Checklist khác plan ở điểm nào?
  • Vì sao done rule quan trọng?
  • Khi T2 hết chỗ, Plan v2 phải giữ gì?
  • Khi nào không nên dùng Planning Agent?

c. Gợi ý đáp án

Xem gợi ý câu 1Checklist thường là danh sách ổn định; plan gắn step với dependency, state, evidence, trạng thái và khả năng replan. → Xem mục 1–2.
Xem gợi ý câu 2Nó biến “đã làm” thành phép kiểm bằng evidence; thiếu done rule thì step có thể completed trên lời kể. → Xem mục 2.
Xem gợi ý câu 3Giữ Plan v1, observation `SOLD_OUT`, timestamp/source, các step đã hoàn tất và lý do đổi target; chỉ sửa phần chưa chạy. → Xem mục 3.
Xem gợi ý câu 4Khi task một bước, đường đi cố định hoặc chi phí planning lớn hơn lợi ích; dùng prompt hay workflow đơn giản hơn. → Xem mục 1 và 4.

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

Thuật ngữ Giải thích ngắn
Planning Agent Agent tạo, thực thi và cập nhật plan theo feedback.
Plan State có cấu trúc nối goal với các step.
Acceptance test Phép kiểm kết quả cuối đã đạt goal.
Dependency Điều kiện một step cần từ step khác.
Precondition Điều phải đúng trước khi step chạy.
Done rule Evidence chứng minh step hoàn tất.
Next feasible step Bước hợp lệ tiếp theo theo state hiện tại.
Replan trigger Sự kiện khiến đường đi tương lai cần đổi.
Planning horizon Phạm vi bước được chi tiết hóa trước.
Plan theater Kế hoạch trông đẹp nhưng không kiểm được.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại Think → Act → Observe #33 nếu chưa rõ cách observation cập nhật state. Học tiếp Reflection Loop #35 để đánh giá output bằng tiêu chí và sửa có mục tiêu thay vì tự phê bình mơ hồ.

Nhắc lại giáo dục: Plan không bảo đảm đúng. Giá trị của nó nằm ở chỗ làm đường đi, dependency, bằng chứng, quyền và lý do thay đổi trở nên kiểm tra được.