Framework xây dựng EA từ Zero đến Hero #15

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ư, công thức strategy hoặc hướng dẫn bật EA trên tài khoản thật.

Trả lời ngắn: Framework xây dựng EA là khung ra quyết định gồm chín giai đoạn: xác định vấn đề, đặc tả, thiết kế, xây dựng, xác minh, thẩm định, phát hành, vận hành và cải tiến. Mỗi giai đoạn tạo một hồ sơ, có bằng chứng để qua cổng và có điểm dừng khi chưa đủ.

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

• Vì sao bắt đầu từ code thường làm dự án đi vòng.
• Sáu hồ sơ tối thiểu giữ strategy, risk, test và vận hành.
• Cách một EA demo đi qua thang bằng chứng.
• Khi nào phải HALT, rollback hoặc quay lại đặc tả.

1. Framework là bản đồ quyết định, không phải công thức lợi nhuận

a. Vấn đề thật của người mới

Người mới thường mở MetaEditor, viết điều kiện if, rồi mới hỏi EA phải giải quyết việc gì. Khi robot compile, cảm giác “đã xong phần khó” xuất hiện. Nhưng compile chỉ cho biết source phù hợp cú pháp và kiểu dữ liệu trong phạm vi compiler kiểm được. Nó không chứng minh giả thuyết strategy đúng, volume hợp lệ, kết quả giao dịch được xử lý, hay EA biết làm gì sau restart.

Framework trong bài này là chuỗi stage có đầu vào, artifact — hồ sơ giữ quyết định — và gate — cổng chỉ mở khi có evidence. Nó nối kiến thức từ CFD, MT5, cấu trúc EA, backtest tới quản trị rủi ro.

b. Ví dụ xưởng nhỏ

Hãy hình dung xưởng đóng chiếc bàn: bản vẽ nói kích thước, phiếu nói vật liệu, người kiểm đo độ phẳng, biên bản nói cách bàn giao. Bàn nhìn đẹp không bù chân lỏng. Tương tự, equity curve đẹp không bù source mơ hồ; mỗi evidence trả lời một câu hỏi khác.

c. Chín giai đoạn

PROBLEM → SPEC → DESIGN → BUILD → VERIFY → VALIDATE → RELEASE → OPERATE → IMPROVE

• PROBLEM: việc gì cần tự động hóa, cho ai, trong phạm vi nào?
• SPEC: rule, dữ liệu, trạng thái, failure và acceptance được viết ra sao?
• DESIGN: module, quyền sở hữu state, risk boundary và observability nằm ở đâu?
• BUILD: code/config được tạo với version nào?
• VERIFY: hệ thống có làm đúng đặc tả không?
• VALIDATE: đặc tả có đủ phù hợp với dữ liệu và mục tiêu đã khóa không?
• RELEASE: artifact nào được phép đi vào môi trường vận hành?
• OPERATE: ai theo dõi, halt, reconcile và recover?
• IMPROVE: thay đổi nào được học từ incident/evidence mới?

MQL5 tách các event handler như OnInit, OnTick và OnTradeTransaction; điều đó cho thấy lifecycle kỹ thuật không chỉ có một hàm “mua/bán”. MQL5 Reference — Event Handling Functions

Hình 1 — Chín stage tạo đường đi; evidence tại từng gate quyết định đi tiếp hay quay lại.

d. Framework không có nghĩa là gì

Framework không phải mẫu code, preset “chuẩn”, strategy chắc lời hay giấy chứng nhận production-ready. Một cá nhân có thể viết một trang thay sáu tài liệu dài, nhưng không bỏ sáu loại quyết định. Indicator không gửi action có gate execution nhẹ hơn EA được tạo, sửa hoặc đóng vị thế.

2. Sáu hồ sơ giữ hệ thống khỏi sống bằng trí nhớ

a. Mandate: bài toán và ranh giới

Mandate là bản mô tả vấn đề, user, phạm vi và quyền. Ví dụ:

Theo dõi breakout sau khi nến đóng trên một symbol demo; chỉ tạo candidate. Không tự gửi order trong bản đầu.

Một câu như vậy chặn scope creep. Nếu sau này yêu cầu auto-order, đó là thay đổi mandate, không phải “thêm vài dòng”.

b. Strategy card: hợp đồng giả thuyết

Strategy card ghi edge giả định, regime, signal, exit, sizing, cost, holding, failure và điều kiện đứng ngoài. Nó không chứng minh edge tồn tại; nó làm giả thuyết có thể bị phản bác.

Ví dụ breakout demo:

• Signal: candle M15 đóng trên high của 20 candle trước.
• Filter: spread không vượt ngưỡng đã định nghĩa theo point.
• Candidate invalid: dữ liệu thiếu hoặc session đóng.
• Failure: false breakout tăng khi spread/regime đổi.

Nếu đổi lookback từ 20 lên 35 sau khi xem holdout, card phải tăng version và holdout cũ không còn độc lập.

c. Component contract: module nói chuyện thế nào

Component contract mô tả input, output, state, error và owner của mỗi module. Signal engine xuất BUY_CANDIDATE, không trực tiếp mở order. Risk engine trả ALLOW, RESIZE, BLOCK hoặc HALT. Execution adapter gửi request, nhưng result handler mới reconcile kết quả.

Contract giúp phân biệt:

• “không có signal” với “không đủ quyền”;
• “request đã gửi” với “order đã được chấp nhận”;
• internal state trong bộ nhớ EA với account state trên server.

MetaTrader cung cấp nhóm trade functions để kiểm tra, gửi và đọc transaction/result; request thành công ở tầng gọi hàm không nên bị hiểu thành kết quả cuối cùng. MQL5 Reference — Trade Functions

d. Risk register và test passport

Risk register là bảng risk, trigger, control, owner, evidence và residual risk. Ví dụ:

Test passport là hồ sơ của một lần test: build hash, preset hash, symbol specification, data period, cost assumptions, test mode, acceptance, raw result và người duyệt. Hai report không cùng passport thì chưa chắc so được.

e. Runbook: lúc có chuyện thì làm gì

Runbook là hướng dẫn vận hành và phục hồi: health check, alert severity, HALT, snapshot, reconcile, restart, rollback, contact owner. Runbook phải dùng được lúc 2 giờ sáng, không phụ thuộc người viết code còn nhớ.

Một incident card ngắn có:

TRIGGER → CONTAIN → CAPTURE → RECONCILE → DECIDE → RECOVER

Nếu chưa biết account state, quyết định an toàn là SAFE/HALT, không auto-resume.

Hình 2 — Sáu artifact giữ giả thuyết, giao diện, rủi ro, bằng chứng và cách vận hành ở đúng chỗ.

3. Một EA demo đi qua framework như thế nào?

a. Khóa baseline trước khi test

Baseline là mốc build, config, data và acceptance đã khóa. Ví dụ giáo dục:

• Build: breakout-demo-0.3.0, hash A.
• Preset: m15-v2, hash B.
• Data: 2024-01-01 tới 2025-12-31.
• Development: 2024.
• Holdout: 2025, chưa mở trước khi freeze.
• Cost scenario: spread cơ sở và spread stress gấp 1,5.

Đây chỉ là số liệu demo, không phải setting khuyến nghị.

b. Verify khác validate

Verification hỏi: “Ta có xây đúng đặc tả không?” Ví dụ candle chưa đóng thì signal phải WAIT; volume invalid phải BLOCK; duplicate event chỉ tạo một candidate.

Validation hỏi: “Đặc tả đã khóa có phù hợp mục tiêu và dữ liệu chưa?” Backtest, holdout, cost stress và demo nằm gần câu hỏi này.

Nếu logic case fail, không chạy optimization để tìm bộ số “bù” lỗi. Nếu holdout fail acceptance, không gọi đó là bug code khi logic vẫn đúng. Hai loại thất bại dẫn về hai stage khác nhau.

c. Thang bằng chứng

Một evidence ladder tối thiểu:

1. STATIC: compile, lint, dependency/permission review.
2. LOGIC: Given/When/Then và simulator cho state machine.
3. BACKTEST: history với passport, cost và data quality.
4. HOLDOUT: sample chưa dùng để chọn rule/input.
5. DEMO: connection, reject, latency, restart, alert, operator.
6. RELEASE: manifest, approval, monitoring và rollback.

MetaTrader Strategy Tester hỗ trợ test/optimization trên dữ liệu lịch sử; report cung cấp metrics và graph. Công cụ không tự quyết định sample split, acceptance hay selection bias cho user. MetaTrader 5 Help — Strategy Testing, MetaTrader 5 Help — Testing Report

Hình 3 — Mỗi bậc kiểm một nhóm failure mode; pass ở bậc cao không xóa fail ở bậc thấp.

d. Ví dụ decision record

Giả sử baseline chạy:

• 20/20 logic cases pass.
• History development đạt acceptance đã viết.
• Holdout fail cost stress vì spread cao làm candidate quality giảm.
• Demo chưa bắt đầu.

Decision đúng là STOP AT VALIDATE. Team có thể sửa strategy card/filter, tạo version mới, khóa holdout mới theo test design, rồi chạy lại từ gate bị ảnh hưởng. Không được ghi “5/6 gate pass nên cho demo”.

Một ví dụ khác: demo tạo action đúng nhưng alert channel chết trong drill 2/5 lần. Signal không sai, song release vẫn STOP vì operator không nhìn thấy incident đáng lẽ phải thấy.

e. Evidence phải đọc được và tái tạo được

Screenshot là phụ trợ, không phải passport. Evidence tốt trả lời được:

• phiên bản nào;
• dữ liệu/config nào;
• lệnh nào tái hiện;
• expected và actual;
• ai duyệt;
• artifact gốc ở đâu.

Câu chắc chắn: framework không biến test thành bằng chứng hoàn hảo.

Câu có điều kiện: nếu acceptance được khóa trước, artifacts có hash và reviewer kiểm độc lập, evidence đáng tin hơn việc nhớ miệng.

Chỗ cần nhận sai: khi result mới phủ định giả thuyết, hãy sửa version và ghi lý do. Đừng viết lại plan cũ để quá khứ trông có vẻ đúng.

4. Sai lầm, giới hạn và rủi ro của chính framework

a. Code-first và performance-first

Code-first biến lựa chọn kiến trúc thành sự đã rồi trước khi problem/spec rõ. Performance-first nhìn profit/drawdown trước logic correctness, data leakage và cost. Cả hai đều đẩy câu hỏi khó sang cuối, khi sửa đắt hơn.

Control: mandate/strategy card một trang phải được duyệt trước build; logic gate phải pass trước đánh giá performance.

b. Gate theatre

Gate theatre là có checklist nhưng evidence yếu: tick “backtest done” không kèm passport; tick “monitoring done” nhưng chưa drill alert; tick “recovery done” vì restart một lần khi account trống.

Control: mỗi ô phải link artifact cụ thể. Reviewer có quyền trả INSUFFICIENT, không ép chỉ chọn pass/fail.

c. Tách tài liệu khỏi hệ thống

Tài liệu nói volume step 0,01 nhưng runtime nhận 0,1; runbook nói alert A trong khi code gửi channel B. Artifact trôi khỏi software thì framework thành đồ trang trí.

Control: effective config/log, machine-readable manifest khi phù hợp, test cross-check docs và code. Mỗi release phải pin artifact cùng build.

d. Over-engineering

Dự án indicator demo không cần quy trình nặng như EA có side effect. Nhiều form làm team copy-paste.

Control: scale theo risk. Giữ câu hỏi, rút ngắn biểu mẫu. Một sheet có thể chứa mandate, risk và test passport nếu ownership rõ.

e. Giới hạn không thể xóa

Framework không chứng minh future market giống history; không tìm hết bug; không ngăn broker/specification thay đổi; không bảo đảm third-party binary an toàn. Observability — khả năng hiểu state qua log, metric và alert — chỉ thấy thứ đã instrument.

Vì vậy cần residual risk, change detection và điều kiện đứng ngoài. Khi source không rõ, data hỏng, ownership mơ hồ, permission quá rộng hoặc không có recovery path, dừng dự án là kết quả hợp lệ.

f. Con người vẫn là một phần của hệ thống

Operator có thể bỏ alert; reviewer có thể bị outcome bias; developer có thể bảo vệ code mình viết. Tách vai khi risk cao, chạy pre-mortem và giới hạn quyền. Framework chỉ làm quyết định nhìn thấy được, có timestamp và owner.

5. Checklist triển khai và bài tập 15 phút

a. Checklist 15 bước

1. Viết problem và user.
2. Chốt side effect được phép/cấm.
3. Viết strategy card.
4. Định nghĩa state và failure.
5. Tách component contract.
6. Lập risk register.
7. Chốt acceptance trước test.
8. Pin build/config/data baseline.
9. Pass static gate.
10. Pass logic/rejection/restart cases.
11. Chạy history bằng passport.
12. Mở holdout đúng một lần theo plan.
13. Demo connection/alert/operator.
14. Chuẩn bị release manifest/runbook/rollback.
15. Monitor, review incident và revalidate change.

Điểm dừng: source, unit, data, owner hoặc expected behavior chưa rõ; logic case fail; holdout bị tune; alert/reconcile/rollback chưa drill. Không bù bằng size nhỏ.

b. Release, operate và improve

Release là phiên bản được duyệt cùng manifest, không phải file vừa compile. Rollback là quay về release đã biết; rollback cũng cần reconcile account state, không chỉ copy file cũ.

Sau release:

MONITOR → INCIDENT → REVIEW → CHANGE → REVALIDATE

Incident trước hết cần containment. HALT ngăn side effect mới nhưng không tự xóa position/order. Sau snapshot và reconcile, owner mới chọn recover, rollback hoặc giữ safe.

Change có impact map. Sửa label UI có thể chỉ cần gate hẹp; đổi sizing hoặc event/state ownership phải chạy lại logic, risk, history và demo liên quan.

Hình 4 — Cải tiến là vòng có containment và revalidation, không phải sửa nóng rồi tiếp tục chạy.

c. Bài tập 15 phút

Dùng giấy, Google Sheets hoặc LibreOffice. Không mở MT5, không dùng account và chưa dùng tiền thật.

Chọn demo: cảnh báo khi candle M15 đóng vượt high 20 candle. Điền STAGE / ARTIFACT / EVIDENCE / DECISION.

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

Sau đó thêm một risk: candle data thiếu. Trigger: bar count không đủ. Control: trả DATA_NOT_READY; evidence: case Given/When/Then; owner: signal module.

Kết quả mong đợi không phải EA. Kết quả là một decision record cho thấy dự án đang dừng ở BUILD và biết chính xác artifact nào còn thiếu.

d. Thẻ go/no-go

Cuối mỗi gate ghi:

• DECISION: PASS / STOP / INSUFFICIENT.
• EVIDENCE: link hoặc ID.
• OWNER: người/module chịu trách nhiệm.
• NEXT: hành động kế tiếp.
• REVIEW_AT: thời điểm evidence hết hạn nếu có.

Không có evidence thì không ghi PASS. Evidence thuộc baseline cũ thì đánh dấu stale. Khi uncertainty quan trọng chưa giải được, ghi INSUFFICIENT.

6. Tổng kết

a. Năm ý chính

• Framework nối chín stage từ problem tới improve.
• Sáu artifact giữ quyết định khỏi trôi theo trí nhớ.
• Verification khác validation; mỗi gate cần evidence riêng.
• Release gồm manifest, monitoring, reconcile, runbook và rollback.
• Dừng đúng lúc là một kết quả kỹ thuật tốt, không phải thất bại.

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

• Compile pass cho biết gì và chưa cho biết gì?
• Strategy card khác test passport ở đâu?
• Vì sao holdout fail không được “bù” bằng logic pass?
• Rollback có cần reconcile account state không?
• Khi nào decision nên là INSUFFICIENT?

c. Gợi ý đáp án

Xem gợi ý câu 1

Compile kiểm phần compiler thấy; chưa chứng minh logic, giả thuyết, execution hay vận hành. Xem lại mục 1.

Xem gợi ý câu 2

Strategy card giữ giả thuyết; test passport giữ baseline và kết quả một lần test. Xem lại mục 2.

Xem gợi ý câu 3

Hai gate kiểm failure mode khác nhau; fail validation phải xử lý đúng stage. Xem lại mục 3.

Xem gợi ý câu 4

Có. File cũ không tự khớp internal state với position/order trên account. Xem lại mục 5.

Xem gợi ý câu 5

Khi bằng chứng thiếu hoặc uncertainty material chưa được giải. Xem lại mục 4 và mục 5.

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

e. Nguồn tham khảo

• MetaTrader 5 Help — Algorithmic Trading
• MetaTrader 5 Help — Strategy Testing
• MetaTrader 5 Help — Testing Report
• MQL5 Reference — Event Handling Functions
• MQL5 Reference — Trade Functions

Bài trước: Những sai lầm phổ biến khi sử dụng EA #14. Xem lại toàn bộ lộ trình từ CFD là gì? #1 và dùng framework này như bản đồ thực hành, không phải giấy phép bật live.

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ư, công thức lợi nhuận hoặc xác nhận một EA phù hợp để vận hành thật.