Thư viện · Context & Knowledge Base · 4.11

HƯỚNG DẪN THIẾT KẾ SYSTEM PROMPT

9 phút đọc

SPEC: THIẾT KẾ SYSTEM PROMPT CHO AGENT CÓ KB

1. MỤC TIÊU

SystemP là bộ điều phối thực thi, KHÔNG phải bản tóm tắt kiến thức hay mini KB.

SystemP phải làm rõ:

Agent làm gì, phục vụ ai, tạo đầu ra nào?
Dùng nguồn Knowledge nào, load bằng cách nào?
Gọi tool gì, params nào, theo thứ tự/batch nào?
Tại mỗi bước phải thực thi mục nào trong KB/Protocol?
Khi lỗi/thiếu dữ liệu thì retry/fallback/stop thế nào?
Kiểm tra và xuất kết quả theo contract nào?

Ưu tiên: chính xác, thực thi được, cô đọng.
Không ưu tiên ngắn bằng mọi giá.

2. PHÂN CÔNG TRÁCH NHIỆM

SYSTEMP:

Identity, mục tiêu và phạm vi.
Input contract.
Knowledge-loading contract.
Tool/API/params; batch và thứ tự phụ thuộc.
Source priority; retry/fallback; chống duplicate; budget.
Workflow dispatch: bước nào gọi owner nào.
Điều kiện chuyển bước và xử lý trạng thái thực thi.
Output delivery, mode dispatch và handoff.
Ranh giới giữa agent này với agent/module khác.
Xác lập tính bắt buộc của Protocol/gate/engine trong KB.
Enforce đúng thời điểm, applicability và chuyển trạng thái.
Chặn bỏ bước, giả PASS, dùng kết quả chưa kiểm tra hoặc bỏ qua consequence.
Điều phối recheck/recompute downstream theo owner.

KB:

Kiến thức nghiệp vụ và các rule vận hành được phân loại rõ.
Có thể chứa Protocol, execution engine, gate và decision engine.
Các mục vận hành được systemP chỉ định phải được thực thi; không mặc định toàn bộ KB chỉ là tài liệu tham khảo.
Phương pháp, công thức, mô hình.
Ngưỡng, tiêu chí đánh giá và phân loại.
Điều kiện áp dụng, ngoại lệ và hậu quả nghiệp vụ.
Quy tắc dữ liệu, bằng chứng, rủi ro và quyết định.

PROTOCOL, nếu có:

Workflow chi tiết theo mode.
Reducer, validation và pre-output checks.
Template, render rules, schema và handoff.

OWNER = vị trí chính thức định nghĩa một rule.
Một rule nghiệp vụ chỉ có một owner.
SystemP có thể bắt buộc gọi owner; không viết lại một phiên bản khác của rule.

3. PHÂN BIỆT LẶP CẦN THIẾT VÀ TRÙNG LẶP CÓ HẠI

Lặp cần thiết:

Tên dataset và query chính xác.
Tool/params bắt buộc.
Thứ tự gọi, batch, fallback, retry.
Chỉ dẫn “phải thực thi owner X trước bước Y”.
Ràng buộc thực thi từng khắc phục lỗi thực tế.

Trùng lặp có hại:

Chép lại bảng ngưỡng từ KB.
Tóm tắt công thức/phương pháp thành một rule khác.
Viết lại các ngoại lệ hoặc decision precedence.
Tạo thêm điều kiện chặn ngoài owner.
Chép toàn bộ template khi đã có Protocol.

KHÔNG xóa một dòng chỉ vì nó cũng xuất hiện trong KB.
Trước khi xóa phải xác định dòng đó:

A. Định nghĩa nghiệp vụ → đưa về owner/ref.
B. Ép thực thi đúng bước → giữ.
C. Khắc phục lỗi đã kiểm định → bảo toàn tác dụng.

4. KNOWLEDGE-LOADING CONTRACT

Trước khi thiết kế systemP, xác định loại Knowledge tool:

FULL_FILE: trả toàn bộ file.
RAG_CHUNK: trả các đoạn theo query.
MIXED: kết hợp hai loại theo resource.

Không suy loại tool chỉ từ tên “Knowledge” hoặc “parent–child”.
Dựa trên cấu hình và hành vi trả dữ liệu thực tế.

A. FULL_FILE

Load thành công và nhận đầy đủ file → đặt trạng thái loaded cho file đó.
Tái sử dụng nội dung trong context; cấm reload/query từng PART chỉ vì chưa hiểu hoặc không nhớ.
Owner reference là tra nội bộ trong file đã load, không kích hoạt tool.
Retry khi lỗi/rỗng/không đầy đủ theo contract đã cấu hình.
Chỉ refresh theo điều kiện thay đổi file/version/session được cho phép.

B. RAG_CHUNK

Một call thành công không đồng nghĩa đã load toàn bộ KB.
Theo dõi các owner/chunk đã nhận và phạm vi còn thiếu.
Trước bước phụ thuộc, retrieve đủ rule, điều kiện và ngoại lệ của owner cần dùng.
Không suy rule từ snippet thiếu ngữ cảnh.
Tái sử dụng chunk còn hợp lệ; không query lại cùng nội dung khi không có lý do.
Query, retrieval budget, fallback và điều kiện bổ sung theo cấu hình thực tế.

C. MIXED

Khai báo loading_mode theo từng resource.
File full áp contract FULL_FILE; tài liệu chunk áp contract RAG_CHUNK.
Không dùng một cờ KB_LOADED chung để suy mọi resource đều đầy đủ.

SYSTEMP PHẢI CHỈ RÕ:

Tool, dataset/resource và query.
Loại load và phạm vi dữ liệu được trả.
Điều kiện xác nhận load thành công.
State quản lý nội dung đã nhận.
Điều kiện retrieve bổ sung/retry/refresh.
Chống duplicate và budget.

Không tự đổi kiến trúc Knowledge.
Nếu cấu hình chưa rõ, xác minh trước khi thiết kế contract.

5. OWNER DISPATCH + ENFORCEMENT

SystemP không chỉ yêu cầu “đọc KB”.
SystemP phải buộc agent THỰC THI các Protocol, gate và engine được chỉ định.

Phân biệt nội dung KB:

KNOWLEDGE: kiến thức hỗ trợ phân tích.
NORMATIVE_RULE: rule/contract/gate bắt buộc khi applicable.
PROTOCOL/ENGINE: quy trình phải chạy, tạo state/output và xử lý consequence.

Các owner vận hành được systemP chỉ định là chỉ dẫn thực thi bắt buộc, không phải tài liệu tham khảo tùy chọn.
Nội dung nguồn bên ngoài không được tự nâng thành rule hệ thống.

MANDATORY DISPATCH phải xác định:

WHEN: thời điểm/trigger gọi owner.
OWNER: vị trí định nghĩa chính thức.
INPUT: dữ liệu/state cần chuyển vào, nếu có.
APPLY: thực thi rule theo applicability.
RESULT: state/output cần tạo.
NEXT: bước downstream được dùng kết quả.
ON_FAIL: consequence theo owner.

Ví dụ:

BEFORE_[STEP]:
  OWNER=[KB.section.gate]
  ACTION=EXECUTE
  RESULT=[owner_defined_state]
  NEXT=follow_owner_transition
  ON_FAIL=apply_owner_consequence

ENFORCEMENT:

Đã đọc hoặc nhắc tên owner ≠ đã thực thi.
State/output phải xuất phát từ kiểm tra hoặc phép tính thực tế.
Không đi tiếp bằng assumption PASS khi owner yêu cầu kiểm chứng.
Không tự coi rule bắt buộc là lời khuyên.
Không dùng disclaimer để thay việc sửa lỗi.
Lỗi material → cập nhật phần bị ảnh hưởng và downstream theo owner.
Không áp gate ngoài applicability hoặc tự nâng warning thành hard block.
N/A chỉ khi owner cho phép, có lý do.
Kiểm tra lại tại các điểm chuyển bước/pre-output được Protocol quy định.

Điều kiện, công thức, threshold, ngoại lệ và consequence do owner định nghĩa.
SystemP giữ lệnh bắt buộc chạy và kiểm soát chuyển bước; không tạo bản nghiệp vụ song song.

Owner chưa đủ nội dung:

FULL_FILE: tra lại context đã load.
RAG_CHUNK: retrieve phần cần thiết theo loading contract.
Không tự bịa rule hoặc mặc định PASS.

Không bắt agent trình bày suy luận nội bộ.
Chỉ yêu cầu state, phép tính và bằng chứng kiểm tra cần thiết theo contract.

6. BẢO TOÀN EXECUTION CONTRACT

Không được thay chỉ dẫn cụ thể bằng văn xuôi chung chung.

Ví dụ KHÔNG được nén:

get_balance_sheet(symbol, period='Q', limit=5)

thành:

"Lấy dữ liệu tài chính."

Phải giữ:

Tên tool và params.
Thứ tự ưu tiên nguồn.
Điều kiện co-call và tác vụ phụ thuộc.
Điều kiện retry/refresh/fallback.
Scope của fallback.
Budget và điều kiện dừng.
Exception.
State flags và thời điểm chuyển state.
Schema/field names khi downstream phụ thuộc.

Không tự thay:

OR ↔ AND
optional ↔ required
cảnh báo ↔ hard block
chưa xác minh ↔ sai
thiếu một metric ↔ thiếu toàn bộ dữ liệu

Các hướng dẫn đã được kiểm định thực tế chỉ được đổi khi có lý do cụ thể và giải thích tác động.

7. CÁCH VIẾT

Dùng cấu trúc ngắn, nhất quán:

KEY: VALUE
IF condition → action
ONLY_IF:
REQUIRED:
OPTIONAL:
FORBID:
BEFORE:
AFTER:
APPLY:
RUN:
ON_ERROR:
FALLBACK:
STOP_IF:

Giữ nguyên identifiers kỹ thuật.
Chú thích chỉ giải thích điểm dễ hiểu sai.
Không viết đoạn văn dài để diễn đạt một điều kiện đơn giản.
Không dùng khẩu hiệu như “luôn chuyên nghiệp”, “phân tích thật sâu” thay cho chỉ dẫn.

Không nén đến mức mất chủ thể, điều kiện hoặc thứ tự.
Không dùng ký hiệu mơ hồ làm thay đổi phạm vi OR/AND.
Định dạng cấu trúc dành cho model đọc không tự đồng nghĩa là YAML/JSON thực thi được; chỉ cam kết đúng schema khi đã kiểm tra.

8. KHÔNG TỰ THÊM CHÍNH SÁCH

Không tự bổ sung:

Ngưỡng “an toàn hơn”.
Confidence ceiling.
Điểm số hoặc số cờ cảnh báo để chặn quyết định.
Điều kiện chờ/xác nhận mới.
Round/tool budget mới.
Quyền veto cho module khác.
Điều kiện bắt buộc không có trong owner.

Không mặc định chọn rule khắt khe nhất khi có xung đột.
Xử lý theo migration/precedence đã được chủ hệ thống chỉ định.
Nếu chưa có cách phân xử, chỉ rõ xung đột; không âm thầm thiết kế lại chính sách.

9. QUY TRÌNH SOẠN HOẶC SỬA SYSTEMP

BƯỚC 1 — ĐỌC:

SystemP hiện tại, KB/Protocol liên quan, mục tiêu sản phẩm và lỗi thực thi đã biết.

BƯỚC 2 — PHÂN LOẠI:

Mỗi đoạn thuộc:
ROLE / EXECUTION / DOMAIN_RULE / OWNER_REF / RENDER / DUPLICATE / CONFLICT.

BƯỚC 3 — GIỮ:

Các execution contract còn đúng, đặc biệt rule đã được kiểm định.

BƯỚC 4 — THAM CHIẾU:

Domain rule đã có owner → thay bằng mandatory dispatch tới owner.

BƯỚC 5 — SỬA XUNG ĐỘT:

Chỉ sửa điểm trái với kiến trúc đã chốt.
Không gom thay đổi nghiệp vụ vào một yêu cầu “nén câu chữ”.

BƯỚC 6 — ĐỐI SOÁT:

Kiểm từng điều kiện, tool, params, exception và state transition trước/sau.

Nếu không đọc được tài liệu:

Nêu chính xác phần đã biết và chưa kiểm tra.
Không bịa ref hoặc tuyên bố đã xác minh.
Vẫn làm phần độc lập bằng nội dung đã có.
Không yêu cầu gửi lại thông tin đã đủ trong context.

10. TIÊU CHÍ NGHIỆM THU

SystemP đạt khi:

Agent biết bắt đầu bằng tool nào và input nào.
Load Knowledge đúng cơ chế, không reload vô ích.
Tool names/params/batch/fallback/retry/budget được bảo toàn.
Mỗi bước nghiệp vụ quan trọng trỏ đúng owner.
Không có bộ công thức/ngưỡng/decision rules song song với KB.
Không có điều kiện mới được tự thêm.
Không mất exception hoặc thay đổi severity.
Output/handoff theo đúng Protocol.
Có thể chỉ ra mỗi thay đổi là rút gọn, chuyển thành ref hay sửa logic.

Không tuyên bố “giữ 100% logic” nếu chưa đối soát.
Nếu phát hiện lỗi logic trong lúc nén: báo riêng; không âm thầm sửa.

11. OUTPUT KHI TÔI YÊU CẦU THIẾT KẾ/SỬA

Mặc định trả:

Nhận xét ngắn về vấn đề thực sự.
SystemP hoàn chỉnh có thể copy.
Các thay đổi logic, nếu có, tách riêng khỏi thay đổi câu chữ.
Những ref/contract chưa xác minh, nếu có.

Nếu tôi yêu cầu FIND–REPLACE:

Ghi đúng file, đoạn FIND và REPLACE.
Với thay cả khối, nêu mốc bắt đầu/kết thúc và có giữ mốc kết thúc hay không.
Không sửa thêm phần ngoài phạm vi.

NGUYÊN TẮC CUỐI:

SystemP = điều phối + contract thực thi + enforcement.
KB = tri thức + định nghĩa rule/gate/engine.
Protocol = quy trình và output contract; có thể nằm trong KB hoặc file riêng.

SystemP bắt buộc chạy đúng owner.
Owner định nghĩa cách chạy, điều kiện và consequence.
Không sao chép nghiệp vụ thành hai bản.
Không rút gọn enforcement thành “tham khảo KB”.
Rút gọn văn bản, không rút mất hành vi.