Tương lai AI Trading: từ bot tới hệ thống đa tác nhân #35

Nội dung này chỉ nhằm mục đích giáo dục, không phải lời khuyên đầu tư hay cam kết về khả năng của hệ thống AI trong tương lai.

Trả lời ngắn: Tương lai AI Trading không chỉ là một bot thông minh hơn, mà là hệ thống nhiều thành phần phân vai rõ: dữ liệu, nghiên cứu, rủi ro, thực thi, giám sát và con người phê duyệt. Mỗi vai cần hợp đồng, bằng chứng, quyền tối thiểu và dấu vết kiểm toán trước khi tự động hóa được mở rộng.

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

• Hệ thống đa tác nhân khác một nhóm chatbot ở đâu.
• Vì sao risk gate quyết định nên mang tính xác định.
• Cách xây lộ trình từ assistant tới bounded autonomy.

1. Từ bot đơn tới hệ thống phân vai

Bot truyền thống thường gom mọi việc vào một process: lấy dữ liệu, tính signal, kiểm risk, gửi order và báo cáo. Nó dễ làm demo nhưng khó kiểm tra khi lớn lên. Một lỗi parsing hoặc prompt có thể đi thẳng tới execution vì không có ranh giới quyền hạn.

AI agent trong bài này là một thành phần nhận mục tiêu giới hạn, đọc input, dùng công cụ được cấp và tạo output theo hợp đồng. Multi-agent system là nhiều agent hoặc service phối hợp qua message có schema. Số lượng agent không tạo ra chất lượng; thiết kế ranh giới mới tạo ra khả năng kiểm soát.

Một “research agent” có thể tóm tắt bằng chứng, nhưng không nên sở hữu API key gửi order. Một “execution service” có thể gửi order đã duyệt, nhưng không được tự sửa risk limit. Đây là nguyên tắc least privilege: mỗi vai chỉ có quyền tối thiểu để làm nhiệm vụ.

2. Agent Operating Model gồm sáu vai

Hình 1 — Các vai trao đổi evidence packet; không agent nào vừa đề xuất, tự duyệt, thực thi và tự tuyên bố thành công.

1. Data agent

Kiểm freshness, schema, missing value, provenance và point-in-time rule. Output là data snapshot có version cùng quality flags. Nó không kết luận hướng giao dịch.

2. Research agent

Tạo hypothesis, feature explanation, scenario và model proposal. Mọi kết luận phải trỏ tới snapshot, model version và assumption. Nếu không đủ bằng chứng, output hợp lệ là INSUFFICIENT_EVIDENCE.

3. Risk agent hoặc risk service

Tính exposure, limit, liquidity, drawdown state và eligibility. Phần giới hạn tiền/tỷ lệ nên là code xác định, được test và version-control; không nên phụ thuộc hoàn toàn vào câu trả lời tự do của mô hình ngôn ngữ.

4. Approval agent và con người

Approval layer kiểm policy, separation of duties và ngưỡng cần human review. Với thay đổi model, limit, venue, credential hoặc hành động có tác động lớn, con người vẫn là authority. NIST AI RMF nhấn mạnh cần định nghĩa vai trò, trách nhiệm và human oversight trong toàn vòng đời (NIST AI RMF Core).

5. Execution service

Nhận action đã ký/duyệt, kiểm idempotency key, pre-trade gate rồi gửi order. Nó trả acknowledgment và trạng thái ACKNOWLEDGED, REJECTED hoặc UNKNOWN; sau đó reconcile với venue/broker.

6. Monitoring và incident agent

Theo dõi drift, latency, cost, reject, policy breach và data gap. Agent này có thể đề nghị degrade hoặc kill switch, nhưng policy xác định ai có quyền kích hoạt và ai chịu trách nhiệm phục hồi.

3. Evidence Packet thay cho lời nói tự do

Hình 2 — Mỗi quyết định có input, phiên bản, assumption, test, limit và chữ ký; agent sau không phải đoán agent trước đã làm gì.

Một evidence packet tối thiểu gồm:

• decision_id và timestamp UTC.
• Data snapshot/version cùng quality flags.
• Model/version, output, confidence và calibration bucket.
• Assumptions và known limitations.
• Risk metrics, limits và reason codes.
• Approval record hoặc lý do không cần approval.
• Proposed action có expiry time và idempotency key.

Ví dụ giả lập: research agent đề xuất RISK_ON, confidence 0,76 cho instrument X. Data agent xác nhận freshness đạt nhưng volatility feature thiếu một nguồn dự phòng. Risk service tính exposure 78% limit. Policy yêu cầu hai nguồn cho feature trọng yếu, nên approval layer trả REJECT_DATA_QUORUM.

Không agent nào nên “tranh luận” để thay đổi rule trong runtime. Research agent có thể mở change request kèm evidence. Sau review, con người hoặc governance workflow mới thay policy version cho lần chạy sau.

Trace có thể replay

Khi incident xảy ra, đội vận hành phải replay được: agent thấy gì, tool nào được gọi, output nào được tạo, gate nào pass/fail và side effect nào đã xảy ra. Log hội thoại dài chưa đủ; cần structured event và correlation ID.

4. Failure modes của hệ thống đa tác nhân

Agent đồng thuận nhưng cùng sai

Ba agent dùng cùng một nguồn hoặc cùng model family không tạo độc lập thực sự. “Ba phiếu” vẫn có thể là một lỗi nhân ba. Quorum phải xét diversity của nguồn, phương pháp và failure domain.

Prompt injection và dữ liệu không tin cậy

News, filing hoặc webpage có thể chứa text cố điều khiển agent. Data từ bên ngoài là input, không phải instruction. Tool policy phải tách system instruction, sanitize content và chặn secret/credential khỏi context không cần thiết.

Quyền lan rộng theo chuỗi

Research agent gọi một tool có quyền ghi; tool lại gọi execution API. Quyền hiệu dụng lớn hơn sơ đồ. Cần capability allowlist, scoped token, approval trước side effect và kiểm tra quyền theo từng hop.

Loop và chi phí không giới hạn

Agent A hỏi B, B hỏi C, C quay lại A. Cần max steps, timeout, budget, deduplication và state machine kết thúc. “Cố đến khi xong” không phải policy an toàn cho runtime tài chính.

Automation bias

Con người có thể bấm approve vì hệ thống trình bày tự tin. Approval UI cần hiển thị evidence, missing fields, counterfactual và reason code; không chỉ một đoạn văn thuyết phục. NIST Generative AI Profile nhấn mạnh governance, provenance, pre-deployment testing và incident disclosure cho hệ thống gen-AI (NIST AI 600-1).

BIS cũng lưu ý gen-AI có thể làm tăng model risk, data governance, third-party và các rủi ro như hallucination/anthropomorphism trong tài chính (BIS FSI Insights 63).

5. Maturity Ladder: tự động hóa theo bằng chứng

Hình 3 — Quyền chỉ tăng khi test, giám sát và recovery cùng trưởng thành; không nhảy từ chatbot tới execution tự trị.

Level 0 — Manual notebook

Con người thu thập dữ liệu, viết thesis và quyết định. Mục tiêu là có schema và checklist ổn định.

Level 1 — Assistant

AI tóm tắt và đề xuất nhưng không có write tool. Người dùng kiểm nguồn và tự thực hiện hành động ngoài hệ thống.

Level 2 — Shadow agent

Agent chạy song song, tạo evidence packet và proposed action nhưng side effect bị khóa. So sánh với quyết định thực tế để đo lỗi, false positive và missing state.

Level 3 — Human-approved automation

Action chỉ thực thi sau approval có thời hạn. Deterministic risk gate chạy lại ngay trước side effect; proposal hết hạn phải tạo mới.

Level 4 — Bounded autonomy

Chỉ các action nhỏ, quen thuộc, trong limit chặt được tự động. Bất thường, model/policy change, degraded data hoặc incident lập tức quay về Level 2/3. Kill switch, reconciliation và recovery drill là bắt buộc.

Không có Level “tự do hoàn toàn”. Autonomy là một envelope: phạm vi, công cụ, số tiền, thời gian, venue và điều kiện được phép. Mở rộng envelope cần evidence mới, không chỉ niềm tin.

Mỗi lần chuyển level nên có một promotion review tương tự phát hành phần mềm. Nhóm phụ trách ghi rõ use case, baseline, test set, incident đã biết, quyền mới, rollback path và owner trực. Sau khi nâng quyền, hệ thống chạy canary với phạm vi nhỏ; monitoring so sánh action được đề xuất, action bị gate chặn và kết quả reconciliation. Nếu latency, reject, data quality hoặc human override vượt ngưỡng, policy tự động hạ level.

Điểm trưởng thành quan trọng không phải số agent hay độ dài prompt, mà là khả năng chứng minh trạng thái. Một hệ thống tốt có thể trả lời ngay: phiên bản nào đang chạy, quyền nào đang mở, ai đã phê duyệt, side effect cuối cùng là gì và cách trở lại trạng thái an toàn. Nếu năm câu hỏi này chưa có câu trả lời máy đọc được, chưa nên tăng autonomy.

6. Bắt đầu từ đâu: Agent Contract Card 15 phút

Chọn một nhiệm vụ không có tiền thật, ví dụ tạo daily research brief. Vẽ sáu ô:

1. Vai trò và mục tiêu duy nhất.
2. Input schema và nguồn được phép.
3. Output schema cùng reason codes.
4. Tool/permission allowlist.
5. Stop conditions, timeout và budget.
6. Người phê duyệt, log và recovery owner.

Mẫu đối chiếu tham khảo

Sau đó tạo ba tình huống test: nguồn stale, proposal hết hạn và order timeout. Hệ thống phải dừng đúng reason code. Chỉ khi ba test có bằng chứng pass mới cân nhắc thêm tool hoặc quyền.

7. Tổng kết hành trình 35 bài

Năm ý chính

• Multi-agent là kiến trúc phân vai, không phải nhiều chatbot nói chuyện.
• Evidence packet và contract giúp quyết định kiểm tra, replay và audit được.
• Risk/permission gate quan trọng nên xác định, test và version-control.
• Human approval phải có authority, bằng chứng và expiry rõ.
• Autonomy chỉ mở rộng trong envelope khi monitoring/recovery đã chứng minh.

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

• Least privilege nghĩa là gì?
• Evidence packet tối thiểu chứa gì?
• Vì sao ba agent có thể cùng sai?
• Shadow mode giúp đo điều gì?
• Bounded autonomy khác tự trị hoàn toàn thế nào?

Gợi ý đáp án

Câu 1

Mỗi vai chỉ có quyền tối thiểu để làm nhiệm vụ. Xem lại mục 1.

Câu 2

ID, data/model version, output, assumption, risk, approval và proposed action. Xem lại mục 3.

Câu 3

Chúng có thể dùng cùng nguồn/model và chung failure domain. Xem lại mục 4.

Câu 4

Lỗi và decision quality khi side effect bị khóa. Xem lại mục 5.

Câu 5

Nó chỉ tự động trong phạm vi/limit/điều kiện đã định. Xem lại mục 5.

Thuật ngữ cần nhớ

Nguồn tham khảo

• NIST — AI Risk Management Framework
• NIST — Generative AI Profile NIST AI 600-1
• BIS — Regulating AI in the financial sector

Bạn có thể quay lại AI Trading là gì? để rà toàn bộ nền tảng, rồi dùng Quy trình xây một hệ thống AI Trading như checklist triển khai.

Chọn đúng bài trong lộ trình

Bài này tập trung vào tương lai AI Trading — hệ đa tác nhân, maturity ladder và quyền theo bằng chứng. Nếu bạn cần bức tranh chung trước khi đi sâu, hãy bắt đầu từ AI Trading là gì? Hướng dẫn từ nền tảng đến kiểm định. Các bước liên quan trực tiếp là AI Agent và Agentic Trading, Human-in-the-loop và Kill Switch và Quy trình xây một hệ thống AI Trading.

Nội dung chỉ nhằm mục đích giáo dục, không phải lời khuyên đầu tư.