Hoàn thiện cBot chuyên nghiệp: 4 module cốt lõi Strategy, Execution, Risk, Logging

Trong phòng thí nghiệm, một cBot chỉ cần "chạy được": build không lỗi, kéo lên chart là vào lệnh, backtest cho đường equity đẹp. Nhưng trên tài khoản thật — VPS chạy 24/7, những đêm thị trường đi ngược mọi dự đoán — tiêu chuẩn hoàn toàn khác. Ở đó, câu hỏi không phải "bot có vào lệnh không" mà là: bot có dừng đúng lúc không, có tự bảo vệ khi mọi thứ sai không, và sự cố lúc ba giờ sáng thì sáng mai bạn có tái dựng được nguyên nhân không?

Bài viết nhìn vấn đề dưới góc kỹ sư vận hành hệ thống (production engineer), đi qua bốn module — Strategy, Execution, Risk, Logging — theo tư duy xuyên suốt: tách bạch trách nhiệm, chặn lỗi sớm, mọi hành vi đều kiểm toán được. Khi bốn module đứng đúng vị trí, một hệ quả giá trị xuất hiện: Backtest và Optimization trở nên đáng tin cậy, vì bạn biết con số trên màn hình phản ánh điều gì.

Chạy được không có nghĩa là sẵn sàng vận hành: bốn câu hỏi kiểm duyệt

Ngành phần mềm có ranh giới mà dân trading bot thường bỏ qua: "nó chạy được trên máy tôi" khác hoàn toàn "nó an toàn để vận hành liên tục". Một chương trình chạy một lần trong một giờ chịu được code lộn xộn; hệ thống chạy không ngừng trên tài khoản thật thì không. Sự khác biệt không nằm ở việc bot thắng trong quá khứ, mà nằm ở bốn câu hỏi kiểm duyệt:

Nếu cBot của bạn là một class ôm hết — logic chiến lược, lệnh, khối lượng, rủi ro nằm lẫn trong OnBar — thì câu trả lời cho cả bốn câu hỏi gần như chắc chắn là "không" hoặc "không biết". Lưu ý về tư duy: ranh giới này không phụ thuộc số dòng code mà phụ thuộc khả năng chịu lỗi (fault tolerance) và phục hồi (recoverability). Chiến lược tệ trong kiến trúc tốt thì thay thế được; chiến lược tốt trong code rối thì một lần sửa sai chỗ cũng đủ gây thảm họa không truy ra nổi. Kiến trúc không làm chiến lược đúng hơn, nhưng quyết định bạn có sống sót để sửa sai hay không.

Kiến trúc bốn module: ống dẫn tín hiệu một chiều với các lớp van an toàn

Trong một cBot hoàn chỉnh, tín hiệu không được "nhảy cóc" giữa các phần — chúng chảy một chiều, qua từng lớp, và mỗi lớp có quyền chặn hoặc biến đổi trước khi chuyển tiếp:

1. Strategy đọc dữ liệu + indicator, tuyên bố một ý định (intent): mua, bán hay đứng ngoài. Strategy không gửi lệnh, không tính khối lượng.
2. Risk đứng ở cổng tiếp theo: kiểm tra spread, giới hạn thua ngày, số vị thế, circuit breaker — rồi định cỡ khối lượng theo rủi ro, đóng gói thành kế hoạch lệnh (order plan).
3. Execution là đôi tay cơ khí: đặt lệnh market kèm SL/TP, chống trùng, báo cáo kết quả.
4. Logging ghi toàn bộ hành trình — ý định gì, bị chặn vì sao, lệnh nào đã khớp — để tái dựng được.

Hãy hình dung một ống dẫn nước: Strategy là nguồn, Risk là van chặn chính, Execution là vòi xả, Logging là camera dọc đường. Nguyên tắc quan trọng nhất là chiều phụ thuộc: Risk không cần biết Strategy hoạt động ra sao, Execution không tự quyết định, và class Robot không còn là "nơi chứa mọi thứ" — nó chỉ điều phối, gọi đúng module vào đúng thời điểm.

Điểm mấu chốt: mỗi lỗi tiềm năng bị chặn ở đúng lớp của nó. Muốn thử chiến lược mới, chỉ thay Strategy — Risk và Execution giữ nguyên nên so sánh sạch sẽ. Muốn siết rủi ro, chỉ chỉnh Risk — không đụng logic vào lệnh. Đây là nền móng để Backtest và Optimization đáng tin, như ta sẽ thấy ở phần cuối.

Module Strategy: biến dữ liệu thành "ý định", và chỉ dừng ở đó

Nhiệm vụ của Strategy gói trong một câu: biến dữ liệu thị trường thành tuyên bố có cấu trúc về việc bot muốn làm gì. Tôi dùng từ "ý định" thay vì "tín hiệu", vì "tín hiệu" dễ khiến người ta nghĩ cứ có là phải vào lệnh ngay; ở đây ý định chỉ là đầu vào của chuỗi kiểm duyệt phía sau.

Một Strategy tốt trả về đối tượng bất biến (immutable) giàu thông tin: không chỉ "mua hay bán" mà còn vì sao, từ nến nào, gợi ý khoảng SL/TP. Đóng gói lý do ngay trong đối tượng trả về buộc chiến lược "giải thích" quyết định của mình; Logging cuối đường ống chỉ việc in ra:

using cAlgo.API;

namespace cAlgo.Robots.Strategy
{
    public enum IntentSide { None, Buy, Sell }

    // "Ý định": hợp đồng bất biến mô tả điều chiến lược MUỐN làm.
    // Không chứa khối lượng, không chạm lệnh, không biết đến Robot.
    public sealed class TradeIntent
    {
        public IntentSide Side { get; }
        public string Reason { get; }
        public int BarIndex { get; }
        public double? RefStopPips { get; }
        public double? RefTargetPips { get; }

        public TradeIntent(IntentSide side, string reason, int barIndex,
                           double? stopPips = null, double? targetPips = null)
        {
            Side = side; Reason = reason; BarIndex = barIndex;
            RefStopPips = stopPips; RefTargetPips = targetPips;
        }

        public static TradeIntent StandBy(string why) =>
            new TradeIntent(IntentSide.None, why, -1);
    }

    public interface ITradingStrategy
    {
        string Name { get; }
        TradeIntent Evaluate(int barIndex);
    }
}

Ví dụ cụ thể — thay vì lối "hai đường trung bình cắt nhau" kinh điển, ta dùng SMA cắt nhau có lọc xu hướng bằng ADX: chỉ mua/bán khi thị trường đang có xu hướng đủ mạnh, đi ngang thì đứng ngoài dù SMA có cắt:

using cAlgo.API.Indicators;

namespace cAlgo.Robots.Strategy
{
    // Mua khi SMA nhanh cắt lên SMA chậm VÀ ADX xác nhận xu hướng đủ mạnh.
    public class TrendMomentumStrategy : ITradingStrategy
    {
        private readonly MovingAverage _fast;   // SMA nhanh
        private readonly MovingAverage _slow;   // SMA chậm
        private readonly AverageDirectionalMovementIndex _adx;
        private readonly double _minAdx;

        public TrendMomentumStrategy(MovingAverage fast, MovingAverage slow,
                                     AverageDirectionalMovementIndex adx,
                                     double minAdx)
        { _fast = fast; _slow = slow; _adx = adx; _minAdx = minAdx; }

        public string Name => "Trend + Momentum (SMA/ADX)";

        public TradeIntent Evaluate(int barIndex)
        {
            double f0 = _fast.Result.Last(1), s0 = _slow.Result.Last(1);
            double f1 = _fast.Result.Last(2), s1 = _slow.Result.Last(2);
            bool trending = _adx.Index.Last(1) >= _minAdx;

            if (!trending)
                return TradeIntent.StandBy("ADX thấp - thị trường đi ngang");

            if (f1 <= s1 && f0 > s0)
                return new TradeIntent(IntentSide.Buy, "SMA vàng cắt + xu hướng mạnh",
                                       barIndex, stopPips: 30, targetPips: 60);
            if (f1 >= s1 && f0 < s0)
                return new TradeIntent(IntentSide.Sell, "SMA tử cắt + xu hướng mạnh",
                                       barIndex, stopPips: 30, targetPips: 60);

            return TradeIntent.StandBy("Xu hướng có, nhưng chưa có điểm cắt");
        }
    }
}

Hai chi tiết đáng chú ý. Một: ngay cả khi "đứng ngoài", Strategy cũng giải thích vì sao (ADX yếu hay chưa có điểm cắt) — những lý do không hành động là dữ liệu vàng để hiểu bot. Hai: chiến lược thuần túy tính toán, cùng dữ liệu vào luôn cho cùng kết quả ra — nên unit-test được bằng dữ liệu giả và Backtest trở nên xác định, tiền đề cho tối ưu đáng tin. Trong Robot, gọi Strategy chỉ tốn một dòng rồi chuyển ý định cho Risk.

Module Execution: biến "ý định" thành lệnh sạch, không trùng, không lệnh trần

Execution là đôi tay cơ khí phải tuyệt đối kỷ luật: không tự hỏi "có nên vào lệnh không" (việc của Risk), chỉ nhận kế hoạch đã duyệt và thực thi chuẩn xác. Ba trách nhiệm bắt buộc: không để lệnh "trần" (không SL/TP dù một giây), chống trùng bền vững (kể cả khi bot restart giữa chừng), và báo cáo kết quả có cấu trúc.

Điểm mấu chốt: chỉ kiểm tra "có vị thế không" là chưa đủ — nếu bot treo rồi khởi động lại đúng lúc một nến đang hình thành, nó có thể tưởng "chưa có lệnh" và vào lệnh lần hai. Giải pháp là idempotency: gắn dấu vết (bar index đã xử lý + nhãn lệnh định danh) để dù chạy lại bao nhiêu lần, cùng một tín hiệu cũng chỉ sinh tối đa một lệnh:

using System.Linq;
using cAlgo.API;

namespace cAlgo.Robots.Execution
{
    public enum FillStatus
    {
        Accepted, BarAlreadyHandled, AlreadyInPosition,
        BrokerRejected, Error
    }

    // Đôi tay cơ khí: chỉ thực thi chuẩn xác.
    public class ExecutionManager
    {
        private readonly Robot _host;
        private readonly string _tag;      // nhãn định danh bot, dán lên mọi lệnh
        private int _lastHandledBar = -1;  // idempotency theo nến

        public ExecutionManager(Robot host, string tag)
        { _host = host; _tag = tag; }

        public FillStatus Place(OrderPlan plan, int barIndex)
        {
            // Chống trùng: một nến chỉ xử lý một lần, kể cả sau restart
            if (barIndex == _lastHandledBar) return FillStatus.BarAlreadyHandled;
            _lastHandledBar = barIndex;

            // Nhận lại vị thế của chính bot (theo nhãn)
            bool haveMine = _host.Positions.FindAll(_tag, _host.SymbolName)
                .Any(p => p.TradeType == (plan.Side == IntentSide.Buy
                                          ? TradeType.Buy : TradeType.Sell));
            if (haveMine) return FillStatus.AlreadyInPosition;

            // Market order kèm SL/TP NGAY lúc đặt - không lệnh trần
            TradeResult result = _host.ExecuteMarketOrder(
                plan.Side == IntentSide.Buy ? TradeType.Buy : TradeType.Sell,
                _host.SymbolName, plan.VolumeUnits,
                $"{_tag}:{plan.RefId}", plan.StopPips, plan.TargetPips);

            if (result == null || !result.IsSuccessful)
                return FillStatus.BrokerRejected;

            // Phòng xa: SL chưa gắn sau khi khớp thì gắn lại ngay
            if (result.Position != null && result.Position.StopLoss == null)
                _host.ModifyPosition(result.Position, plan.StopPips, plan.TargetPips);

            return FillStatus.Accepted;
        }
    }
}

Lưu ý Execution tự bảo vệ thêm một lớp: dù Risk đã kiểm duyệt, nó vẫn kiểm tra lại vị thế theo nhãn trước khi đặt lệnh — nguyên tắc defense in depth: một lớp có thể bị bỏ sót, hai lớp độc lập thì xác suất cùng sai gần bằng không. Lệnh trần là nguyên nhân số một của những tài khoản "cháy" sau một đêm tin lớn — giá vọt qua mọi mức chịu đựng mà bot vẫn đứng yên vì không có lệnh dừng lỗ ở server.

Module Risk: van chặn, bộ định cỡ, và circuit breaker

Đây là module quan trọng nhất và là nơi phân biệt rõ nhất giữa người viết bot nghiệp dư và người vận hành chuyên nghiệp. Risk không phải một câu "nếu" lồng trong code — nó là lớp kiểm soát tập trung, có trạng thái, đứng bắt buộc giữa ý định của Strategy và hành động của Execution, làm ba việc theo đúng thứ tự:

1. Gác cổng trước lệnh: kiểm tra spread, giới hạn thua ngày, số vị thế tối đa, trạng thái khóa. Đủ điều kiện thì ý định mới thành kế hoạch lệnh.
2. Định cỡ: quyết định khối lượng từ rủi ro chấp nhận được (ví dụ 1% vốn mỗi lệnh). Risk là nơi duy nhất tính khối lượng.
3. Giám sát liên tục: theo dõi drawdown so với đỉnh equity, số lệnh thua liên tiếp — sẵn sàng kéo circuit breaker đóng toàn bộ vị thế, khóa giao dịch.

using cAlgo.API;

namespace cAlgo.Robots.Risk
{
    public class RiskSettings
    {
        public double RiskPercent { get; set; }     // % vốn mỗi lệnh
        public double MaxSpreadPips { get; set; }   // spread tối đa
        public double MaxDailyLossPct { get; set; } // thua tối đa trong ngày
        public double MaxDrawdownPct { get; set; }  // drawdown tối đa từ đỉnh
        public int MaxPositions { get; set; }       // số vị thế tối đa
        public double DefaultStopPips { get; set; } // SL mặc định
    }

    // Ý định đã được duyệt + định cỡ xong, sẵn sàng cho Execution
    public sealed class OrderPlan
    {
        public IntentSide Side { get; }
        public double VolumeUnits { get; }
        public double StopPips { get; }
        public double? TargetPips { get; }
        public string RefId { get; }
        public OrderPlan(IntentSide side, double volumeUnits, double stopPips,
                         double? targetPips, string refId)
        { Side = side; VolumeUnits = volumeUnits; StopPips = stopPips;
          TargetPips = targetPips; RefId = refId; }
    }

    public class RiskController
    {
        private readonly Robot _host;
        private readonly RiskSettings _cfg;
        private double _dayStartEquity, _peakEquity;
        private bool _locked;
        private DateTime _lockUntil;

        public RiskController(Robot host, RiskSettings cfg)
        {
            _host = host; _cfg = cfg;
            _dayStartEquity = _peakEquity = host.Account.Equity;
        }

        public void OnNewSession()
        {
            _dayStartEquity = _host.Account.Equity;
            if (_host.Server.Time >= _lockUntil) _locked = false;
        }

        // Bước 1+2: gác cổng rồi định cỡ. Trả null khi bị từ chối.
        public OrderPlan Approve(TradeIntent intent)
        {
            if (_locked) return null;
            double spreadPips = _host.Symbol.Spread / _host.Symbol.PipSize;
            if (spreadPips > _cfg.MaxSpreadPips) return null;      // spread nổ

            double dayLoss = (_dayStartEquity - _host.Account.Equity)
                             / _dayStartEquity * 100.0;
            if (dayLoss >= _cfg.MaxDailyLossPct) { _locked = true; return null; }

            if (_host.Positions.FindAll(_host.SymbolName).Count >= _cfg.MaxPositions)
                return null;
            if (intent.Side == IntentSide.None) return null;

            double stopPips = intent.RefStopPips ?? _cfg.DefaultStopPips;
            double riskCash = _host.Account.Equity * _cfg.RiskPercent / 100.0;
            double volume = _host.Symbol.VolumeForFixedRisk(
                                riskCash, stopPips * _host.Symbol.PipSize);
            return new OrderPlan(intent.Side, volume, stopPips,
                                 intent.RefTargetPips,
                                 $"{intent.BarIndex}-{Guid.NewGuid():N}");
        }

        // Bước 3: giám sát mỗi tick/nến, kéo ngắt mạch khi có sự cố
        public void Monitor()
        {
            if (_host.Account.Equity > _peakEquity)
                _peakEquity = _host.Account.Equity;

            double dd = (_peakEquity - _host.Account.Equity) / _peakEquity * 100.0;
            if (dd >= _cfg.MaxDrawdownPct && !_locked)
            {
                _locked = true;
                _lockUntil = _host.Server.Time.AddDays(1);
                foreach (var p in _host.Positions.FindAll(_host.SymbolName))
                    _host.ClosePosition(p);
                _host.Print($"[RISK] KILL-SWITCH: drawdown {dd:F1}%, da dong toan bo");
            }
        }
    }
}

Hai quyết định đáng suy nghĩ. Một: Risk nên trả về đối tượng chứa mã lý do từ chối (SPREAD_HIGH, DAILY_LOSS, POSITION_LIMIT…) thay vì null trần, để Logging ghi vì sao bot đứng ngoài và bạn đếm được tần suất từng loại. Hai: cơ chế khóa kép — chạm giới hạn thua ngày thì khóa cứng, drawdown vượt ngưỡng thì khóa tới hết ngày cho con người xem xét. Đây là "hệ miễn dịch" của tài khoản: không ngăn bạn thua một lệnh, nhưng ngăn bot biến một ngày tệ thành tài khoản bốc hơi.

Module Logging & Param: hộp đen, thẻ chạy, và tham số để tối ưu được

Dưới góc vận hành, logging chính là thứ biến một sự cố từ "thảm họa không giải thích được" thành "bài học tái dựng được". Bí quyết không phải in thật nhiều mà là in có cấu trúc, đúng mức độ, đúng thời điểm sự kiện — thời gian, mức độ (Info/Warn/Error), danh mục (STRATEGY, RISK, FILL), nội dung dạng key=value — để về sau lọc, đếm và so sánh được giữa các lần chạy:

using cAlgo.API;

namespace cAlgo.Robots.Logging
{
    public enum LogLevel { Info, Warn, Error }

    public class BotLogger
    {
        private readonly Robot _host;
        public BotLogger(Robot host) { _host = host; }

        public void Write(LogLevel level, string category, string message)
        {
            _host.Print($"[{_host.Server.Time:HH:mm:ss}] [{level}] "
                        + $"[{category}] {message}");
        }

        // "Thẻ chạy" (run card): chụp toàn bộ ngữ cảnh lúc khởi động -
        // chìa khóa để TÁI LẬP một phiên backtest hay một sự cố live.
        public void WriteRunCard(double slPips, double riskPct, double maxSpread)
        {
            Write(LogLevel.Info, "RUN",
                $"symbol={_host.SymbolName} tf={_host.TimeFrame} " +
                $"server={_host.Server.Time:yyyy-MM-dd HH:mm:ss} " +
                $"equity={_host.Account.Equity:F2} sl={slPips} " +
                $"risk={riskPct} spread={maxSpread}");
        }
    }
}

Ý tưởng "thẻ chạy" gắn trực tiếp với độ tin cậy của kiểm định: backtest chỉ cho bạn đường equity, không tự động cho biết phiên đó chạy với bộ tham số nào, timeframe nào, spread bao nhiêu. In một thẻ chạy tại OnStart (snapshot tham số, symbol, timeframe, equity ban đầu) biến mỗi lần chạy thành một thí nghiệm có hồ sơ: tái lập được, so sánh được, nghi ngờ được khi cần.

Còn Param là mặt kia của cùng đồng xu: thứ không phải tham số thì không bao giờ tối ưu được. Đừng nhét cứng con số nào vào code. Mọi giá trị có thể đổi — chu kỳ SMA, ngưỡng ADX, % rủi ro — đều phải là [Parameter] có nhóm (Group), Min/Max/Step, vì chỉ tham số kiểu số khai báo chuẩn mới xuất hiện trong bảng Optimization của cTrader:

[Parameter("SMA nhanh", Group = "Strategy", DefaultValue = 20,
           MinValue = 5, MaxValue = 100, Step = 1)]
public int FastSma { get; set; }

[Parameter("ADX tối thiểu", Group = "Strategy", DefaultValue = 25,
           MinValue = 15, MaxValue = 40, Step = 1)]
public double MinAdx { get; set; }

[Parameter("Rủi ro mỗi lệnh (%)", Group = "Risk", DefaultValue = 1.0,
           MinValue = 0.1, MaxValue = 5.0, Step = 0.1)]
public double RiskPercent { get; set; }

[Parameter("Drawdown tối đa (%)", Group = "Risk", DefaultValue = 15,
           MinValue = 2, MaxValue = 50, Step = 1)]
public double MaxDrawdownPct { get; set; }

Gom tham số theo đúng module (nhóm "Strategy" tách khỏi "Risk") không phải chuyện thẩm mỹ — nó quyết định bạn tối ưu cái gì: quét từng miền không sợ "kéo theo" nhau, tránh cái bẫy kinh điển là tối ưu tham số rủi ro trên dữ liệu quá khứ để làm đẹp equity — chỉ là khớp nhiễu, không phải lợi thế thật.

Vì sao kiến trúc 4 module làm Backtest & Optimization đáng tin cậy hơn?

Chất lượng kiểm định phụ thuộc rất lớn vào kiến trúc bot, qua bốn cơ chế. Một — tính xác định: Strategy là hàm thuần túy, cùng dữ liệu vào cho cùng kết quả ra, nên bạn so sánh hai lần chạy công bằng và phát hiện nhiễu dữ liệu chứ không phải code "chạy lung tung". Hai — mô phỏng trung thực: vì Execution luôn gắn SL/TP ngay và Risk chặn spread cao, backtest phản ánh sát hơn điều xảy ra live; bot "một class" thường backtest trong thế giới không spread, không lớp chặn — nên profit factor là ảo ảnh. Ba — tối ưu sạch: tham số tách theo miền, bạn biết mình đang quét gì, thậm chí đo được "chi phí bảo hiểm" bằng cách bật/tắt Risk. Bốn — khả năng kiểm toán: nhờ thẻ chạy và log có cấu trúc, mỗi kết quả tối ưu đều đính kèm "hồ sơ nguồn" để đối chiếu và nghi ngờ có căn cứ.

Về quy trình, một giao thức "ba vòng quét" đáng tin hơn bấm một lần tối ưu khổng lồ. Vòng 1 — quét thô tham số Strategy tìm vùng tiềm năng (Genetic cho không gian lớn). Vòng 2 — tinh chỉnh quanh đỉnh với bước nhỏ. Vòng 3 — kiểm định độ bền: chạy Walk-Forward (chia In-Sample/Out-of-Sample), nhiễu loạn nhẹ tham số quanh điểm tối ưu — kết quả sụp đổ là dấu hiệu overfit — và luôn bật Spread & Commission. Bộ tham số sống sót qua cả ba vòng mới đáng mang đi demo.

Checklist hoàn thiện trước khi nghĩ đến live

Trước khi kéo bot lên tài khoản thật, hãy kiểm tra từng dòng dưới đây — còn một ô "chưa" là bot chưa sẵn sàng:

Một điểm chuyên nghiệp hay bị bỏ qua, nằm trong ô "chống trùng": hành vi của bot khi bị ngắt kết nối rồi khởi động lại. Khi VPS restart, lệnh đang mở vẫn nằm ở broker với SL/TP server-side — lý do SL/TP phải gắn ngay từ đầu. Khi bot chạy lại, nhờ cơ chế "nhận lại vị thế theo nhãn", nó biết mình đã có lệnh và không mở lệnh thứ hai. Thiếu cơ chế này, bot có thể "quên" lệnh cũ, vào thêm lệnh cùng chiều và phơi bày gấp đôi rủi ro ngoài chủ đích.

Câu hỏi thường gặp (FAQ)

Hỏi: Bot chạy VPS bị mất mạng giữa đêm, lệnh đang mở thì sao?

Đáp: Lệnh đã khớp nằm ở broker nên vẫn được bảo vệ bởi SL/TP server-side. Khi bot kết nối lại, nhờ cơ chế nhận lại vị thế theo nhãn, nó không mở lệnh trùng. Vấn đề chỉ phát sinh nếu bot tự quản lý trailing — cần kiểm tra kỹ hành vi sau reconnect.

Hỏi: Risk làm giảm lợi nhuận backtest, tắt đi cho "sạch" được không?

Đáp: Không. Lợi nhuận giảm chính là "phí bảo hiểm" để không cháy tài khoản trong kịch bản hiếm nhưng có thật. Thay vì tắt, hãy đo lợi nhuận hiệu chỉnh rủi ro: so profit factor và max drawdown giữa hai lần chạy (Risk bật/tắt) để hiểu lớp an toàn "ăn" bao nhiêu.

Hỏi: Chống trùng chỉ cần kiểm tra "có vị thế hay không", đúng không?

Đáp: Chưa đủ. Kiểm tra vị thế chỉ chống được khi bot chạy liên tục; khi restart mà không "nhận lại" lệnh cũ theo nhãn, bot có thể vào lệnh lần hai. Cần kết hợp nhiều lớp: idempotency theo nến, kiểm tra vị thế theo nhãn, đối chiếu trạng thái khi khởi động lại.

Hỏi: Kiểm tra spread có khiến bot bỏ lỡ cơ hội tốt không?

Đáp: Có thể — và đó là điều tốt. "Cơ hội" xuất hiện đúng lúc spread nổ (tin lớn, thanh khoản mỏng) thường là bẫy: bạn trả chi phí rất cao ngay giây đầu và SL dễ bị quét. Lớp lọc spread là cách rẻ tiền nhất để tránh những lệnh tệ nhất.

Hỏi: Logging có làm chậm bot khi chạy nhiều cBot cùng lúc không?

Đáp: Ghi vài dòng tại điểm sự kiện (tín hiệu, bị chặn, lệnh khớp) là không đáng kể; chỉ cần tránh in log trong vòng lặp dày hoặc trong OnTick với tần suất vô nghĩa. Chạy nhiều bot thì gắn tag định danh (symbol + bot) vào mỗi dòng để lọc riêng.

Hỏi: Tối ưu bằng Genetic Algorithm trong cTrader có đáng tin không?

Đáp: Đáng tin nếu kiểm định chéo. Genetic quét nhanh không gian rộng, nhưng chính tốc độ đó dễ dẫn tới overfit — tìm ra bộ tham số "khớp nhiễu" quá khứ hoàn hảo. Hãy chạy tiếp Walk-Forward, chia In-Sample/Out-of-Sample và nghi ngờ bộ tham số đẹp đến mức khó tin.

Hỏi: Muốn chạy cùng chiến lược trên nhiều cặp tiền, kiến trúc này giúp gì?

Đáp: Rất nhiều. Bốn module tách rời, nhận symbol từ tham số nên bạn gắn cùng cBot lên nhiều chart, mỗi chart một bộ tham số riêng, dùng chung một khung code đã kiểm chứng. Tag trong Execution và Logging giúp phân biệt lệnh từng cặp; RiskSettings riêng cho từng symbol cho phép siết % vốn khác nhau theo độ biến động.

Kết luận

"Chạy được" chỉ là vạch xuất phát. Một cBot đáng gắn vào tài khoản thật — và đáng để bạn ngủ ngon — là hệ thống tách bạch trách nhiệm: Strategy chỉ tuyên bố ý định, Risk đứng ở cổng kiểm duyệt và sẵn sàng kéo ngắt mạch, Execution thực thi chuẩn xác không trùng lệnh không lệnh trần, còn Logging ghi lại toàn bộ để mọi sự cố tái dựng được. Khi bốn module đứng đúng vị trí, Backtest và Optimization đáng tin — vì con số trên màn hình được tạo ra bởi chính cơ chế sẽ chạy live, không phải phiên bản "lý tưởng hóa" chỉ tồn tại trong backtest.

Hãy bắt đầu từ việc nhỏ: tách logic chiến lược ra class trả về ý định, thêm lớp Risk kiểm duyệt trước khi vào lệnh, rồi đến log có cấu trúc. Mỗi lớp bảo vệ là một đêm bớt mất ngủ khi bot tự chạy. Nếu bạn muốn đi xa hơn — từ thiết kế kiến trúc cBot module hóa đến vận hành nhiều bot an toàn — DNT Digital sẵn sàng đồng hành cùng bạn trên hành trình đó.

▶️ Xem video: Hoàn thiện cBot — Strategy, Execution, Risk, Logging