Triển khai kiến trúc Multi-Agent Intelligent Warehouse cho việc vận hành kho hàng hiện đại

by Bảo Nguyễn

Warehouse operation là một môi trường có nhiều hệ thống, nhiều nguồn dữ liệu và nhiều quyết định cần được đưa ra liên tục. Operator cần biết thiết bị nào đang hoạt động, tồn kho nào đang thiếu, task nào bị chậm, sensor nào phát cảnh báo, tài liệu nào cần xử lý và khi nào cần reorder hàng.

Đây là bài toán phù hợp cho kiến trúc multi-agent AI. Tuy nhiên, một hệ thống AI trong kho không nên được thiết kế như một chatbot đơn giản. Nó cần là một orchestration layer có kiểm soát, có khả năng hiểu yêu cầu bằng ngôn ngữ tự nhiên, chọn đúng agent, gọi đúng tool, truy xuất dữ liệu đáng tin cậy và tuân thủ các rule vận hành.

Nguyên tắc quan trọng nhất là: AI agent không thay thế hệ thống vận hành lõi. Agent có thể phân tích, đề xuất, điều phối và giải thích. Nhưng các trạng thái quan trọng như tồn kho, thiết bị, safety incident, task assignment, forecast, document approval và audit log vẫn phải nằm trong các service deterministic có schema, quyền truy cập, validation và observability.

1. Vấn đề kiến trúc trong warehouse AI

Một warehouse copilot thực tế không chỉ cần trả lời câu hỏi. Nó phải làm việc với nhiều nhóm dữ liệu và nhiều workflow khác nhau:

  • Inventory: số lượng tồn kho, movement history, reorder point, demand summary.
  • Equipment: asset status, telemetry, assignment, battery, maintenance schedule.
  • Operations: task planning, workforce coordination, SLA, throughput, bottleneck.
  • Safety: incident, checklist, compliance, policy, environmental monitoring.
  • Documents: invoice, packing slip, delivery note, maintenance form, safety report.
  • Forecasting: demand prediction, reorder recommendation, seasonal pattern, stockout risk.
  • Integrations: WMS, ERP, IoT, RFID, barcode scanner và attendance system.

Nếu đưa toàn bộ logic này vào một LLM duy nhất, hệ thống sẽ khó kiểm soát, khó audit và dễ tạo ra hành động sai. Kiến trúc phù hợp hơn là tách hệ thống thành nhiều agent chuyên biệt, được điều phối bởi planner và MCP/tool layer.

User request
  -> API Gateway
    -> Auth / RBAC / Rate limit
      -> Intent Router
        -> Planner
          -> Tool Discovery
            -> Specialized Agent
              -> Data / Integration / AI Service
                -> Validation
                  -> Response or Controlled Action

2. Kiến trúc tổng thể

Multi-Agent Intelligent Warehouse có thể được tổ chức thành các layer sau:

Layer Thành phần Trách nhiệm
Experience Layer React Web UI, dashboard, chat interface Cung cấp giao diện cho operator, supervisor và manager tương tác với hệ thống.
API Layer FastAPI Gateway Expose endpoint cho chat, inventory, equipment, document, forecasting và monitoring.
Security Layer JWT, RBAC, rate limiting, guardrails Xác thực, phân quyền, giới hạn request và kiểm soát output của AI.
Orchestration Layer Planner, reasoning engine, MCP/tool router Phân loại intent, chọn agent, bind tool và điều phối workflow.
Agent Layer Equipment, Operations, Safety, Forecasting, Document agents Xử lý các nhóm nghiệp vụ chuyên biệt trong vận hành kho.
Retrieval Layer SQL retriever, vector retriever, hybrid ranker Kết hợp dữ liệu có cấu trúc và tài liệu phi cấu trúc để tạo context.
AI Services Layer LLM, embeddings, OCR, document parsing, guardrails Thực hiện reasoning, embedding, extraction và validation.
Data Layer PostgreSQL/TimescaleDB, Milvus, Redis, Kafka, MinIO Lưu dữ liệu nghiệp vụ, telemetry, vector index, cache, event stream và object storage.
Integration Layer WMS, ERP, IoT, RFID, barcode, attendance Kết nối với hệ thống doanh nghiệp và thiết bị edge.
Observability Layer Prometheus, Grafana, logs, alerts Theo dõi health, latency, workflow execution, tool failure và system metrics.

Thiết kế này giúp AI agent trở thành một lớp điều phối có kiểm soát thay vì một chatbot rời rạc. Agent có thể hiểu yêu cầu và chọn hành động phù hợp, nhưng mọi mutation vào hệ thống vận hành vẫn phải đi qua service có quyền kiểm soát rõ ràng.

3. Agent không phải “source of truth”

Trong warehouse system, các quyết định sai có thể gây lệch tồn kho, task bị giao nhầm, thiết bị bị sử dụng sai trạng thái hoặc safety incident bị xử lý không đúng. Vì vậy, boundary giữa AI và business system phải được thiết kế rõ ngay từ đầu.

AI Agent có thể làm Core System phải kiểm soát
Hiểu intent của user Xác thực user và kiểm tra quyền
Phân tích dữ liệu và tổng hợp context Truy vấn dữ liệu authoritative
Đề xuất reorder hoặc maintenance Ghi inventory movement hoặc maintenance record
Phát hiện rủi ro từ telemetry hoặc document Đóng incident, approve checklist hoặc update safety state
Chọn tool phù hợp Validate schema, permission và policy trước khi execute
Giải thích recommendation Lưu audit trail và correlation ID

Một nguyên tắc đơn giản: agent có thể đề xuất hành động, nhưng mọi hành động làm thay đổi trạng thái nghiệp vụ phải được backend validate và ghi log.

Agent recommendation
  -> Schema validation
    -> Permission check
      -> Business rule validation
        -> Idempotency check
          -> Controlled state mutation
            -> Audit log
              -> Response to user

4. Các agent chuyên biệt

Warehouse operation có nhiều domain nhỏ với logic khác nhau. Do đó, multi-agent architecture giúp hệ thống dễ mở rộng và dễ kiểm soát hơn so với một agent tổng quát.

Agent Phạm vi Ví dụ tác vụ
Equipment Agent Asset, telemetry, assignment, maintenance Kiểm tra forklift nào đang available, phát hiện thiết bị pin thấp, đề xuất lịch bảo trì.
Operations Agent Task planning, workforce, KPI, workflow Phân bổ task theo ca, theo dõi throughput, phát hiện bottleneck trong picking/packing.
Safety Agent Incident, checklist, policy, compliance Phân tích incident report, kiểm tra safety checklist, cảnh báo rủi ro môi trường.
Forecasting Agent Demand forecasting, reorder, BI Dự báo nhu cầu theo SKU, đề xuất reorder quantity, phân tích seasonality.
Document Agent OCR, extraction, validation, routing Trích xuất invoice, packing slip, delivery note, maintenance form hoặc safety report.

Planner quyết định agent nào cần được gọi dựa trên intent, entity và context. Trong các request phức tạp, planner có thể gọi nhiều agent theo chuỗi hoặc song song.

Example request:
"Check if we should reorder SKU-1024 and whether any open inbound shipment already covers it."

Planner:
  -> Inventory lookup
  -> Forecasting Agent
  -> ERP/WMS adapter
  -> Document Agent if inbound document exists
  -> Response with evidence and recommendation

5. Chat-to-action pipeline

Chat-to-action là pipeline quan trọng nhất trong warehouse copilot. Mục tiêu không chỉ là trả lời câu hỏi, mà là chuyển yêu cầu tự nhiên của user thành workflow có kiểm soát.

Natural language request
  -> Request validation
    -> Auth and RBAC
      -> Intent classification
        -> Entity extraction
          -> Planner
            -> Tool selection
              -> Context retrieval
                -> Agent reasoning
                  -> Action validation
                    -> Response or execution

Ví dụ user hỏi:

"Có forklift nào đang rảnh gần khu vực inbound không? Nếu có thì gán cho ca nhận hàng lúc 2 giờ."

Hệ thống không nên để LLM tự trả lời hoặc tự gán thiết bị. Flow đúng hơn:

  1. Xác thực user và kiểm tra quyền assign equipment.
  2. Trích xuất intent: tìm equipment available và tạo assignment.
  3. Truy vấn telemetry/location của forklift.
  4. Kiểm tra trạng thái thiết bị: available, battery, maintenance lock, safety restriction.
  5. Kiểm tra lịch vận hành và ca làm.
  6. Đề xuất thiết bị phù hợp.
  7. Nếu user có quyền và xác nhận, backend tạo assignment record.
  8. Ghi audit log với user, equipment ID, timestamp và reason.

Điểm quan trọng là agent hỗ trợ lập kế hoạch và giải thích, còn backend chịu trách nhiệm mutation.

6. Hybrid RAG cho warehouse data

Dữ liệu kho thường nằm ở hai dạng: structured data và unstructured documents. Nếu chỉ dùng vector search, hệ thống có thể bỏ qua dữ liệu chính xác trong database. Nếu chỉ dùng SQL, hệ thống lại không khai thác được SOP, policy, invoice hoặc tài liệu scan.

Hybrid RAG kết hợp cả hai hướng:

Loại dữ liệu Retriever phù hợp Ví dụ
Structured data SQL Retriever Inventory count, task list, user role, equipment status, movement history.
Time-series data TimescaleDB query Battery level, temperature, location, utilization, environmental sensor.
Unstructured documents Vector Retriever SOP, policy, invoice, delivery note, maintenance manual, safety report.
Cross-domain workflow Hybrid Retriever Kết hợp inventory, inbound shipment, policy và document evidence.

Pipeline hybrid retrieval:

User query
  -> Query preprocessing
    -> Intent and entity detection
      -> SQL retrieval
      -> Vector retrieval
        -> Evidence scoring
          -> Hybrid ranking
            -> Context synthesis
              -> LLM response

Với cách này, câu trả lời của agent không chỉ dựa trên ngôn ngữ tự nhiên mà còn có evidence từ database và tài liệu liên quan.

7. MCP tool layer cho việc vận hành kho hàng

MCP/tool layer là nơi biến reasoning của agent thành hành động có kiểm soát. Layer này cần nhiều hơn một hàm gọi API. Nó phải kiểm soát tool discovery, schema binding, routing, permission và execution policy.

Agent task
  -> Tool discovery
    -> Tool binding
      -> Tool routing
        -> Parameter validation
          -> Permission check
            -> Business constraint validation
              -> Tool execution
                -> Result normalization
                  -> Agent synthesis
Tool group Ví dụ tool Kiểm soát bắt buộc
Inventory Tools Check stock, create movement, summarize demand RBAC, schema validation, idempotency, audit log.
Equipment Tools Read telemetry, assign asset, schedule maintenance Equipment state validation, maintenance lock, safety rule.
Safety Tools Create incident, check policy, complete checklist Role check, immutable log, compliance workflow.
Forecasting Tools Run forecast, recommend reorder, evaluate model Data freshness, model version, confidence score.
Integration Tools Call WMS, ERP, IoT, RFID, attendance APIs Credential isolation, retry policy, timeout, idempotency.

Tool execution cần được xem như một privileged operation. Agent không được bypass permission hoặc gọi trực tiếp external system mà không qua adapter có kiểm soát.

8. Document extraction pipeline

Warehouse thường xử lý nhiều loại tài liệu: invoice, packing slip, delivery note, purchase order, maintenance form, safety checklist và compliance report. Đây là nhóm dữ liệu có giá trị cao nhưng thường không được chuẩn hóa.

Một document extraction pipeline nên có các bước:

Document upload
  -> File validation
    -> OCR / layout parsing
      -> Text and table extraction
        -> Entity extraction
          -> Schema validation
            -> Confidence scoring
              -> Human review or auto-approval
                -> Index to vector store
                  -> Route to downstream workflow
Bước Trách nhiệm
File validation Kiểm tra định dạng, kích thước, malware scan và metadata.
OCR / layout parsing Trích xuất text, bảng, layout block và vùng thông tin quan trọng.
Entity extraction Lấy invoice ID, SKU, quantity, supplier, date, total, shipment reference.
Schema validation Đảm bảo dữ liệu trích xuất khớp với schema nghiệp vụ.
Confidence scoring Quyết định auto-approve, retry hoặc manual review.
Indexing Đưa nội dung đã xử lý vào vector store để phục vụ semantic search.
Workflow routing Gửi dữ liệu sang inventory, ERP, procurement hoặc compliance flow.

Document Agent không nên tự ghi dữ liệu critical vào ERP hoặc inventory nếu confidence thấp. Các trường hợp mơ hồ cần được route sang manual review.

9. Gợi ý dự báo (forecasting) và sắp xếp lại (reorder)

Forecasting trong warehouse không chỉ là dự báo nhu cầu. Kết quả forecast cần được chuyển thành quyết định vận hành: có cần reorder không, reorder bao nhiêu, khi nào cần nhập hàng và rủi ro stockout là bao nhiêu.

Historical demand
  -> Feature engineering
    -> Lag features
    -> Rolling statistics
    -> Seasonality
    -> Event / promotion signals
      -> Model inference
        -> Forecast output
          -> Reorder logic
            -> Risk scoring
              -> Recommendation with explanation
Thành phần Vai trò
Historical demand Dữ liệu nhu cầu theo SKU, location và time window.
Feature engineering Tạo lag features, rolling average, seasonality và event signals.
Model inference Sinh forecast theo horizon cần thiết.
Reorder logic Kết hợp forecast, lead time, safety stock và service level.
Risk scoring Đánh giá rủi ro stockout hoặc overstock.
Explanation Giải thích lý do đề xuất reorder bằng dữ liệu và signal liên quan.

Forecasting Agent nên đưa ra recommendation có confidence, nhưng không nên tự động tạo purchase order nếu chưa có rule và approval workflow rõ ràng.

10. Dữ liệu từ thiết bị và IoT

Thiết bị trong kho tạo ra dữ liệu liên tục: battery, temperature, location, utilization, vibration, error code hoặc safety signal. Những dữ liệu này cần được ingest qua adapter, lưu vào time-series database và đưa vào agent workflow khi cần.

IoT / equipment telemetry
  -> Adapter ingestion
    -> Event stream
      -> Time-series storage
        -> Equipment Agent
          -> Safety Agent
            -> Alert / recommendation / workflow
Signal Ứng dụng
Battery level Cảnh báo thiết bị cần sạc hoặc thay pin.
Temperature Giám sát cold storage và phát hiện sai lệch môi trường.
Location Theo dõi asset, tối ưu routing và phát hiện thiết bị ở sai khu vực.
Utilization Đo hiệu suất sử dụng thiết bị và phát hiện underutilized assets.
Error code Kích hoạt maintenance workflow hoặc cảnh báo vận hành.
Safety signal Kích hoạt Safety Agent hoặc incident workflow.

Agent có thể diễn giải telemetry và đề xuất hành động, nhưng rule safety và maintenance workflow phải được kiểm soát bởi backend service.

11. Khả năng giám sát cho multi-agent warehouse system

Multi-agent system rất khó debug nếu không có observability tốt. Một câu trả lời sai có thể đến từ intent classification, retriever, planner, tool schema, external adapter, LLM hoặc dữ liệu nguồn.

Các signal cần theo dõi:

Layer Signal
API Gateway Request count, latency, error rate, auth failure, rate limit hit.
Planner Intent classification, selected agent, selected tools, execution path.
Agent Input context, output, confidence, reasoning summary, failure mode.
Retriever SQL query, vector query, top-k results, evidence score, empty retrieval.
Tool Execution Tool name, parameters, permission result, execution status, downstream latency.
External Adapter WMS/ERP/IoT API status, timeout, retry, data mismatch.
Data Layer DB latency, Kafka lag, Redis hit rate, Milvus availability, storage errors.
Business Workflow Inventory movement, equipment assignment, incident status, document approval.

Mỗi request nên có correlation ID đi xuyên suốt từ UI, API gateway, planner, agent, retriever, tool execution đến external adapter. Đây là điều kiện cần để debug và audit trong môi trường enterprise.

12. Deployment pipeline

Một pipeline triển khai local/dev có thể đi theo thứ tự sau:

Prepare environment
  -> Configure secrets
    -> Start infrastructure
      -> Run database migrations
        -> Seed demo data
          -> Start backend
            -> Start frontend
              -> Verify APIs
                -> Run smoke tests
                  -> Enable monitoring

12.1. Chuẩn bị môi trường

  • Python 3.11+.
  • Node.js 20 LTS.
  • Docker và Docker Compose.
  • NVIDIA API key nếu dùng hosted NIM.
  • GPU và local NIM configuration nếu chạy inference on-prem.

12.2. Cấu hình secrets

NVIDIA_API_KEY=<your_nvidia_api_key>
JWT_SECRET_KEY=<strong_random_secret>
POSTGRES_PASSWORD=<change_me>
REDIS_PASSWORD=<change_me>
MILVUS_URI=<milvus_endpoint>
KAFKA_BOOTSTRAP_SERVERS=<kafka_endpoint>

Không dùng giá trị mặc định như changeme trong staging hoặc production. Secrets nên được quản lý bằng secret manager hoặc cơ chế tương đương.

12.3. Start infrastructure

docker compose -f deploy/compose/docker-compose.dev.yaml up -d

Stack local/dev thường bao gồm PostgreSQL/TimescaleDB, Redis, Kafka, etcd, MinIO, Milvus, backend, frontend và nginx.

12.4. Chạy schema và seed data

python scripts/setup/create_default_users.py
python scripts/data/quick_demo_data.py
python scripts/data/generate_historical_demand.py

Với các module yêu cầu schema riêng, nên chạy migration trước khi start workflow nghiệp vụ.

12.5. Verify service

/api/v1/health
/api/v1/chat
/api/v1/mcp/status
/api/v1/metrics

Smoke test nên bao gồm các flow chính: chat-to-action, inventory lookup, equipment telemetry, forecasting, document upload và monitoring.

13. Production hardening

Warehouse AI system có rủi ro khác với các ứng dụng AI thông thường. Nếu agent gọi sai tool hoặc cập nhật sai trạng thái, hệ thống có thể gây lỗi vận hành thật. Vì vậy, production hardening cần được thiết kế ngay từ đầu.

Security and Governance

  • Dùng JWT secret mạnh và rotate định kỳ.
  • Thiết kế RBAC theo vai trò: admin, manager, supervisor, operator và viewer.
  • Không cho agent thực thi action vượt quyền user hiện tại.
  • Log toàn bộ tool execution có ảnh hưởng đến inventory, equipment hoặc safety.
  • Dùng secret manager cho credentials của WMS, ERP, IoT, RFID và attendance systems.

Data Reliability

  • Không ghi inventory movement nếu thiếu idempotency key hoặc audit metadata.
  • Đối chiếu dữ liệu từ WMS/ERP trước khi đưa ra quyết định critical.
  • Gắn timestamp và source cho mọi telemetry event.
  • Thiết kế reconciliation job cho dữ liệu lệch giữa warehouse system và external system.

AI Control

  • Không để LLM tự cập nhật tồn kho, đóng safety incident hoặc approve document rủi ro cao.
  • Validate output bằng schema trước khi gọi tool.
  • Dùng confidence score cho document extraction và forecasting.
  • Route các trường hợp confidence thấp sang human review.
  • Cho phép fallback sang deterministic rule khi LLM hoặc retrieval service lỗi.

Observability

  • Gắn correlation ID cho user request, planner run, tool execution và external API call.
  • Theo dõi latency của LLM, retriever, database và adapter.
  • Alert khi forecasting job lỗi, document queue bị nghẽn hoặc IoT telemetry mất kết nối.
  • Dashboard riêng cho inventory movement, equipment health, safety incident và agent tool failure.

14. Kết luận

Multi-Agent Intelligent Warehouse không nên được nhìn như một chatbot cho kho. Kiến trúc đúng là một AI orchestration layer đặt trên các hệ thống vận hành có kiểm soát. Agent giúp hiểu intent, điều phối workflow, truy xuất context, gọi tool và giải thích kết quả. Nhưng trạng thái nghiệp vụ vẫn phải thuộc về backend service, database, WMS, ERP, safety system và audit layer.

Pattern cốt lõi có thể tóm gọn như sau:

Agentic orchestration
  + Deterministic business services
  + Hybrid retrieval
  + Strict tool validation
  + RBAC and audit
  + End-to-end observability

Khi giữ được boundary này, AI agent có thể trở thành một lớp vận hành thực sự hữu ích cho warehouse: hỗ trợ operator ra quyết định nhanh hơn, giúp manager nhìn thấy rủi ro sớm hơn và kết nối dữ liệu phân tán thành workflow có thể kiểm soát.

____
Bài viết liên quan
TAG: , ,