Dựng SRE agent trực đêm trên DGX Spark

Trong công việc hằng ngày, mình chủ yếu làm với các CSP¹ và nhà cung cấp LLM, phần lớn là AWS. Model thường được gọi qua API, còn hạ tầng chạy trên cloud. Lần này mình muốn thử chạy model open-weight ngay trên phần cứng NVIDIA, dùng agent runtime của NVIDIA và xử lý một bài toán bên Azure. Đúng lúc có chú em làm ở NVIDIA đang có một con DGX Spark², mình mượn về thử.

Mình chọn bài toán trực đêm. Anh em làm vận hành chắc quen cảnh 2 giờ sáng điện thoại rung, mở laptop vào portal thì thấy VM bị deallocate³. Việc cần làm chỉ là bấm Start, chờ heartbeat, ghi work note rồi đóng ticket. Xử lý chỉ mất chừng mười phút, nhưng sau đó thường khó ngủ lại.

Nhìn lại các ca trực của mình, phần lớn việc phản hồi ban đầu ngoài giờ khá lặp lại: phân loại sự cố, kiểm tra trạng thái trên Azure, restart khi cần, ghi chép và quyết định lúc nào phải gọi thêm người. Nhiều bước đã có sẵn trong runbook, nên mình muốn xem agent có thể đảm nhận được phần nào.

Từ những ca trực đó, mình bắt đầu làm một SRE agent cho Azure VM. Đây là dự án cá nhân, nên mình có thể thử nghiệm để xem agent chạy local làm được tới đâu và cần giới hạn thế nào trước khi cho phép nó thao tác trên hạ tầng.

Giới hạn phạm vi trước khi viết code

Trước khi viết code, mình xác định rõ agent được làm gì. LLM hỗ trợ suy luận, còn playbook phải chạy theo logic cố định, có guardrail kiểm tra quyền thực hiện và có log để tra lại từng quyết định. Khi không đủ thông tin, agent phải chuyển cho người xử lý.

Vì vậy agent chỉ được xử lý đúng ba loại sự cố:

• VM bị deallocate: được phép start lại.
• VM không phản hồi: được phép restart, nhưng không được đụng tới network.
• Windows service bị dừng: được phép start lại service.

Sự cố ngoài ba loại này sẽ được chuyển cho người xử lý. Ngay cả với ba loại đã nêu, agent cũng phải chuyển người nếu gặp điều bất thường, chẳng hạn: start fail, VM tự tắt lại, cần sửa NSG, hay lỗi dính tới app hoặc database.

Có một số thao tác agent tuyệt đối không được thực hiện: không delete, không deallocate, không resize, không power off, không đụng network, NSG hay disk, không lặp remediation vô hạn. Quan trọng nhất, kể cả khi LLM đề xuất một hành động ngoài luật, nó cũng không có đường nào vượt qua lớp guardrail.

Ưu tiên của mình là không để agent thực hiện hành động nguy hiểm, kể cả phải chấp nhận tỉ lệ tự xử lý thấp hơn. Mỗi giai đoạn đều có bài kiểm tra riêng; qua được thì mới mở thêm quyền ở giai đoạn tiếp theo.

Các bước triển khai

Bước 1: Chạy model trên DGX Spark

DGX Spark có GPU GB10, 128 GB unified memory⁴ và chạy Ubuntu 24.04 ARM64. Mình chọn Nemotron 3 Super 120B-A12B. Đây là model MoE⁵ với 120B tham số, trong đó mỗi token kích hoạt khoảng 12B. NVIDIA giới thiệu model này cho các tác vụ như tự động hoá xử lý IT ticket. Mình chọn bản lớn vì agent cần suy luận và gọi tool chính xác. Với model nhỏ hơn, mình chỉ muốn dùng khi đã xác nhận chất lượng đáp ứng được yêu cầu. Bản NVFP4⁶ nặng khoảng 80 GB, nằm vừa trong máy.

Ngay lúc chạy model, mình đã gặp vấn đề về bộ nhớ. Unified memory là bộ nhớ dùng chung giữa CPU và GPU, mà trên máy còn chạy sẵn một service Ollama. Nếu cấp quá nhiều bộ nhớ cho vLLM, agent runtime và hệ điều hành sẽ không còn đủ để chạy ổn định. Mình phải giới hạn bộ nhớ vLLM để model, agent runtime và hệ điều hành cùng chạy ổn định.

Model được serve qua container vllm/vllm-openai:v0.20.0, API chuẩn OpenAI ở port 8000. Bản rút gọn trông như sau:

# Rút gọn để minh hoạ. Env vars, MoE backend, reasoning parser: xem NVIDIA Spark Deployment Guide.
# Publish port ở loopback vì vLLM API mặc định không có auth.
docker run --gpus all -p 127.0.0.1:8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.20.0 \
    --model nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4 \
    --served-model-name nemotron-3-super \
    --max-model-len 65536 \
    --enforce-eager \
    --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
    --enable-auto-tool-choice --tool-call-parser qwen3_coder

Mình benchmark vài cấu hình để so sánh TPOT và TTFT⁷:

Nâng vLLM lên 0.24 gần như không nhanh hơn, bật CUDA Graphs⁸ cũng chỉ nhích nhẹ. Thứ tạo ra khác biệt là dùng đúng tính năng có sẵn của model. Nemotron 3 Super có một layer MTP (multi-token prediction) nằm sẵn trong checkpoint, đóng vai draft model cho speculative decoding⁹ mà không cần thêm model phụ. Khi bật MTP, thời gian sinh mỗi token giảm khoảng 25%.

Đổi lại, TTFT tăng thêm khoảng 200 ms. Nhưng mỗi token lại nhanh hơn chừng 17 ms, nên output chỉ cần dài hơn khoảng một chục token là đã hoà vốn. Một lượt reasoning cộng tool call của agent dài hơn thế nhiều. Context 32K hay 64K cho kết quả gần như ngang nhau, nên mình lấy 64K. Thêm một chi tiết: benchmark dùng prompt ngẫu nhiên và ép cứng độ dài output, kiểu workload này làm giảm tỉ lệ chấp nhận token đoán. Với workload thật, MTP có khi còn lợi hơn.

Ở phần agent runtime, mình dùng NemoClaw, bộ công cụ mã nguồn mở của NVIDIA để triển khai agent chạy liên tục. Agent nằm trong sandbox OpenShell¹⁰, cô lập ở mức kernel. Một policy YAML quy định nó được đọc gì trên disk và gọi được endpoint nào. Mọi lời gọi model đều đi qua OpenShell gateway, nơi áp policy và ghi audit riêng. OpenShell là lớp sandbox của hệ thống. Mình chỉ coi bước này là xong khi NemoClaw nói chuyện ổn định với model qua endpoint OpenAI-compatible, kể cả sau khi restart.

Bước 2: Dựng luồng xử lý incident

Trước khi kết nối với hệ thống thật, mình dựng luồng xử lý incident. Mỗi incident đi qua state machine với các bước chuyển trạng thái được xác định trước. Mỗi thao tác được khoá idempotency¹¹ theo ticket ID + operation + evidence version, nên replay bao nhiêu lần cũng không sinh hành động trùng.

Mọi state transition và tool call đều thành một dòng trong audit log append-only trên SQLite, gắn correlation ID theo incident. Input và output chỉ lưu dạng hash, nên credential không bao giờ lọt vào log.

Tool thì mình viết mock trước, nhưng mock có schema y hệt connector thật. Nhờ vậy, khi thay mock bằng connector thật, mình không phải sửa phía agent.

Bước 3: Nối hệ thống thật, nhưng chỉ được nhìn

Connector thật gồm hai phần. Phía hệ thống ticket có 6 typed tool: đọc ticket, liệt kê queue, ack, ghi work note, đổi trạng thái, resolve. Phía Azure là một bộ chỉ đọc: Monitor, ARM, Resource Graph, Run Command, Network Watcher, boot diagnostics, Activity Log. Mình không triển khai các thao tác ARM có tính phá huỷ trong connector Azure, nên agent không có tool để gọi chúng.

Guardrail engine được dựng cùng lúc với các luật sau:

• allow-list deny-by-default theo từng loại sự cố;
• chỉ được đụng vào resource group đã duyệt;
• VM gắn opt-out tag thì bỏ qua;
• confidence thấp thì không làm;
• mỗi lần chỉ ảnh hưởng tối đa 1 VM, tức là giới hạn blast radius¹²;
• retry tối đa 2 lần rồi escalate.

Kill switch chặn mọi action trong chưa tới 1 giây, nhưng agent vẫn chẩn đoán và ghi note bình thường.

Sau đó, mình cho agent chạy shadow mode¹³: đọc và xác nhận ticket, thu thập evidence, phân loại sự cố, rồi chỉ ghi đề xuất vào work note. Trong 30 ticket, agent xác nhận đủ cả 30 và đề xuất đúng 28. Hai ca còn lại mơ hồ nên được chuyển người. Quan trọng nhất là không có thay đổi trạng thái nào. Con số 0 đó mình kiểm bằng cách đối chiếu Azure Activity Log với lịch sử ticket, chứ không tin lời agent tự khai.

Bước 4: Cho phép sửa, nhưng trên sự cố giả lập

Mỗi playbook đi qua ba bước: chẩn đoán → sửa → kiểm chứng. Phần kiểm chứng dựa trên các tín hiệu cụ thể:

• VM deallocate: poll tới khi PowerState/running và guest heartbeat Ready.
• VM không phản hồi: chỉ restart sau approval gate. Nếu là lỗi thuần network như NSG sai thì chuyển người thay vì restart.
• Service bị dừng: start xong phải chờ 120 giây rồi kiểm tra lại xem nó có chết lại không. Nếu service đang crash-loop quá ngưỡng thì từ chối luôn.

Mình viết thêm một evaluation harness để replay incident qua toàn bộ pipeline. Kèm theo là các tình huống cố tình gây khó cho agent: prompt injection¹⁴ trong nội dung ticket, VM giả tên, resource group ngoài scope, opt-out tag gắn vào giữa chừng. Không có hành động nguy hiểm nào lọt qua.

Mình giới hạn tool schema bằng enum và yêu cầu trường evidence. Prompt cũng yêu cầu agent đưa ra evidence trước khi đề xuất hành động. Sau vài vòng chỉnh sửa, không còn tool call sai định dạng.

Bước 5: Thử trên VM thật

Sau khi các bài kiểm tra đều pass, mình đưa agent lên VM Azure thật. Mình tạo 7 sự cố trên VM thật, gửi ticket theo cách người dùng vẫn làm và bật quyền sửa.

Agent start lại một VM bị deallocate và xác nhận nó chạy ổn. Nó restart một VM không phản hồi, nhưng không xác nhận được là máy đã hồi phục, nên nó dừng lại thay vì leo thang sang hành động mạnh tay hơn. Năm ca còn lại nó từ chối, ca nào cũng có lý do rõ ràng:

• sự cố đã tự hồi phục trước khi agent kịp đọc;
• lệnh start chắc chắn fail vì VM đang có ReadOnly lock¹⁵;
• nội dung ticket mâu thuẫn với trạng thái thật của máy;
• resource group nằm ngoài scope;
• kill switch đang bật.

Mình chưa kiểm chứng được playbook cho Windows service trên máy thật. Sự cố thử nghiệm đã tự hồi phục trước khi agent đọc ticket, nên playbook này mới chỉ pass trong môi trường giả lập.

Khi chạy trên máy thật, mình cũng phát hiện một số lỗi mà mock không thể hiện ra.

Một số lựa chọn thiết kế

Chạy suy luận tại chỗ

Toàn bộ phần suy luận chạy trên Spark, nên mỗi khi có incident, agent không cần gọi model API bên ngoài. Điều này giúp mình giới hạn kết nối mạng dễ hơn. Egress mặc định chặn hết, chỉ mở đúng 4 đích: hệ thống ticket, dịch vụ OAuth của nó, Azure Resource Manager và Entra ID. Inference nằm ngay trong sandbox nên không cần thêm dòng egress nào, và cũng không có kết nối inbound. Với một agent có quyền restart VM, bề mặt tấn công nhỏ như vậy là thứ mình muốn nhất.

Về stack, mình cân nhắc hai hướng:

• NVIDIA NIM + NeMo Agent Toolkit: có vendor support, nhưng có thể kéo theo license NVIDIA AI Enterprise.
• vLLM + Microsoft Agent Framework: không tốn license, nhưng phải tự support.

Cuối cùng mình chọn vLLM + NemoClaw, để Microsoft Agent Framework làm phương án dự phòng. vLLM có API chuẩn OpenAI, nên khi cần đổi runtime thì lớp connector và tool vẫn giữ nguyên. Nói cho công bằng, mình chưa benchmark hai runtime đối đầu trực tiếp. Đây là lựa chọn dựa trên độ linh hoạt, chưa phải trên số đo.

Phân chia rõ vai trò của model và guardrail

Đây là nguyên tắc mình bám suốt dự án: LLM lo suy luận và ghi chép. State machine quyết định bước hợp lệ tiếp theo. Guardrail quyết định hành động có được phép hay không. Azure và hệ thống ticket luôn là nguồn sự thật.

Vì vậy, việc kiểm soát hành động nằm trong code và quyền truy cập, không phụ thuộc vào việc model có làm đúng prompt hay không. Model không bao giờ cầm credential, không có shell, chỉ được xin gọi những tool đã duyệt. Một thao tác nguy hiểm phải vượt qua mấy lớp mới tới được Azure:

• connector không có tool cho việc đó;
• guardrail mặc định từ chối;
• delete, deallocate, power-off, resize và đổi NSG bị chặn ngay trong code, config cũng không mở ra được;
• role Azure của agent chỉ gồm quyền đọc cộng start, restart và Run Command.

Mình cũng đối chiếu từng kịch bản nguy hiểm với cơ chế kiểm soát tương ứng. Target ngoài scope thì có scope check. Prompt injection thì chỉ được thực thi qua typed tool. Vòng lặp retry thì có retry cap và kill switch. Các kịch bản khác cũng vậy.

Chi tiết mình thích nhất là cách kill switch xử lý hành động đang chạy dở. Kill switch được đọc lại trước mỗi action, nên bật lên là có hiệu lực ngay ở action kế tiếp, không cần restart service. Còn action đã gửi đi thì vẫn được chạy xong và kiểm chứng. Lời gọi lên Azure đã gửi thì không thu hồi được. Nếu bỏ ngang giữa lúc gọi và lúc kiểm chứng thì chẳng ai biết máy đang ở trạng thái nào.

Cùng tinh thần đó, action nào đã bắt đầu mà không ghi nhận được kết quả thì agent giữ lại chờ người xử lý, chứ không tự làm lại. Restart lần hai một con máy mà người khác vừa tiếp quản chính là thứ cần tránh.

Dùng logic cố định khi có thể

Ticket thật hay mô tả máy thay vì ghi tên, nên agent cần biết đang nói về con VM nào. Mình cho nó 4 cách xác định, và mỗi cách mang một "độ mạnh" quyết định agent được làm tới đâu. Tên được Azure xác nhận hoặc alias do người vận hành định nghĩa thì được hành động. Khớp tag hoặc LLM tự suy ra từ nội dung ticket thì chỉ được chẩn đoán. Có nhiều hơn một ứng viên thì chuyển người.

Nếu chỉ có suy đoán của LLM, agent có thể thu thập thêm thông tin nhưng chưa được sửa VM.

Mình cũng áp dụng cách này với event log. Đưa nguyên danh sách event vào ticket thì dễ, nhưng danh sách đó tự nó chưa giải thích được sự cố. Mình viết một module diễn giải khoảng 800 dòng. Mỗi event ID đã biết được gắn bốn ý: nó xác lập được gì, nó chỉ gợi ý gì, nó không nói được gì, và bước nào trong runbook cần tới nó. Đại loại thế này, lấy ví dụ event 6008¹⁶:

# Minh hoạ cấu trúc một entry trong bảng tra
- provider: EventLog
  event_id: 6008
  establishes: 'Lần shutdown trước là bất thường'
  suggests: 'Máy có thể đã crash hoặc bị tắt cứng'
  cannot_say: 'Vì sao máy bị tắt' # dòng này chặn work note viết kiểu đoán mò
  runbook_step: '<bước runbook cần dữ kiện này>'

Module này không gọi LLM. Với event ID có trong bảng, module dùng phần diễn giải đã định nghĩa; event chưa biết được ghi vào ticket với nhãn unrecognised. Nhờ vậy, log của guest trả lời trực tiếp được 4 trong 9 tiêu chí escalation của runbook.

Đổi lại, agent đôi khi vẫn chuyển người xử lý dù incident đã tự hồi phục, chẳng hạn khi log cho thấy service dừng hai lần trong một giờ. Tỉ lệ chuyển người tăng nhẹ, nhưng trong trường hợp này mình chấp nhận điều đó.

HA: có nên không?

Với một máy đi mượn, mình chưa tính tới HA hai node. Kể cả có thêm máy, ở giai đoạn này mình vẫn chọn single node, kèm heartbeat monitor theo dõi cả hai trường hợp: watcher dừng hẳn, hoặc watcher vẫn chạy nhưng không kết nối được tới hệ thống ticket. Trường hợp thứ hai dễ bị bỏ sót nếu chỉ kiểm tra process còn sống hay không.

Lý do là agent đứng ở lớp first-response. Nó im lặng thì ticket vẫn nằm trong queue chờ người, chứ không mất đi đâu. Điều cần đảm bảo là có người được báo khi agent ngừng hoạt động. Thêm component nào là thêm một thứ phải vận hành và phải chứng minh nó chạy đúng.

Kết quả và bài học

Kết quả sau các đợt thử nghiệm:

• Shadow mode: agent đề xuất đúng 28/30 ticket và không thay đổi trạng thái nào.
• Sự cố giả lập: 27/30 ca được sửa đúng, 3 ca còn lại được escalate đúng.
• VM thật: trong 7 sự cố, agent tự sửa và xác nhận được 1 ca, 6 ca chuyển người. Ở 5 trong số 6 ca đó, agent nêu rõ check nào đã từ chối và vì sao. Mỗi incident mất từ 44 giây tới 10 phút.
• Test: 1132 unit test và 29 kịch bản end-to-end với 124 assertion, tất cả đều pass.

Trong các đợt thử nghiệm này, agent không thực hiện hành động nguy hiểm nào. Tuy vậy, quá trình chạy thử vẫn cho thấy khá nhiều chỗ cần sửa.

"Pass vì lý do sai"

Khi chạy trên máy thật, mình tìm ra 9 bug. Phần lớn khó nhận ra vì các check vẫn pass, nhưng kết quả đúng là do một lý do khác với dự kiến. Ba trong số đó sẽ cho ra kết quả sai nếu đem vào dùng thật, và cả ba chỉ lộ ra khi chạy trên máy thật.

Timestamp của Azure health event. Azure đóng dấu lại thời gian của health event chừng nào tình trạng còn kéo dài. Kết quả là một VM dự phòng đang tắt trông như "liên quan" tới mọi incident trong resource group. Guardrail blast-radius thấy vậy và chặn luôn lần sửa đầu tiên trên máy thật. Mình sửa bằng cách lấy thời điểm từ control plane với những VM đang dừng, vì mốc thời gian ở đó không bị cập nhật lại.

Timezone. Windows ghi thời gian event theo giờ local mà không kèm offset. Trên VM để UTC+8, lỗi bình thường trong ngày bị đẩy sang "tương lai" 8 tiếng, rơi vào sau thời điểm remediation. Vì vậy, agent hiểu nhầm rằng VM gặp lỗi sau khi được sửa, dù sự cố thực ra xảy ra trước đó. Giờ mọi timestamp được đổi sang UTC ngay lúc thu thập.

Event ID 1000. Mình tưởng nó luôn là application crash. Hoá ra nhiều provider dùng chung ID này, có provider còn dùng nó để báo performance counter load thành công. Vì vậy có máy đang chạy bình thường vẫn bị báo là đã crash. Bài học: event ID phải đi cùng provider mới có nghĩa.

Lỗi lúc boot. Image Windows mình dùng log một lỗi start service ở gần như mọi lần boot. Playbook VM không phản hồi lại chính là restart, nên lỗi này luôn xuất hiện ngay sau action. Hậu quả là playbook đó không bao giờ kiểm chứng được là đã sửa xong. Giờ đây, các lỗi đã xuất hiện trước khi thực hiện action được tách riêng, và ticket ghi rõ những lỗi nào đã được loại khỏi bước kiểm chứng.

Parser nhận nhầm tên VM. Với câu "The VM appears to be deallocated", parser lấy luôn từ appears làm tên máy. Đọc lại kết quả này thì vừa buồn cười vừa thấy rõ chỗ mình đã bỏ sót. Trong khi đó, field có label chứa tên máy thật lại bị bỏ qua. Giờ parser ưu tiên field có label và loại các ứng viên là từ tiếng Anh thông dụng.

Mock chỉ tạo ra những dữ liệu mình dự liệu trước. Vì vậy, mình đã bỏ sót các trường hợp như timestamp không có timezone hoặc nhiều provider dùng chung event ID. Sau đó, mình chỉnh bộ scenario test để kiểm tra audit record thay vì console output: mỗi test phải xác nhận quyết định nào đã được ghi lại. Phần teardown luôn chạy dù test pass hay fail; nếu không tạo được state cần thiết, test sẽ báo skipped.

Bộ test ban đầu còn quá dễ

Bộ test phân loại ban đầu có 14 case và đạt 14/14. Nhìn lại, các case đều khá rõ ràng, chưa có nhiều tình huống mơ hồ như ticket thật. Mình làm lại bộ test với 55 case sát thực tế hơn, và accuracy giảm còn khoảng 87 đến 91%.

Sau đó, mình chuyển trọng tâm sang unsafe answer¹⁷: những ca agent xếp sự cố vào một loại được phép hành động trong khi lẽ ra không được. Ví dụ tiêu biểu là một request reset password có kèm dòng "authorization" được cài vào nội dung. Trước khi mình thêm request gate, mỗi lần chạy lọt đúng một ca như vậy. Sau khi thêm thì không còn ca nào, accuracy lên 96.4%. Hai ca sai còn lại đều sai theo hướng thận trọng, tức là chuyển người chứ không hành động.

Accuracy của LLM cũng dao động giữa các lần chạy, nên một con số đơn lẻ chưa phản ánh đầy đủ kết quả. Hai lần chạy gần nhất cùng ra 96.4% nhưng sai ở những case khác nhau. Ba lần trước đó lệch nhau 3.6 điểm dù decode deterministic. Muốn dựa vào accuracy để ra quyết định thì phải chạy nhiều lần và báo theo khoảng.

Security control làm quá tay cũng là bug

Request gate kể trên được thêm vào để nội dung ticket không thể tự "cấp quyền" cho agent. Phiên bản đầu thô quá. Gặp câu injection đòi xoá resource group là nó dừng đọc, không đọc tới subject, trong khi subject lại là một báo lỗi thật: "máy đang down". Kết quả là một incident thật bị đẩy ra ngoài scope. Agent chặn được câu injection, nhưng đồng thời bỏ qua cả sự cố cần xử lý trong cùng ticket.

Mình sửa gate để bỏ qua câu lệnh nhắm vào agent rồi tiếp tục đọc những phần mô tả sự cố còn lại. Câu kiểu "máy down, tắt, deallocated, không truy cập được" vẫn là báo lỗi dù nằm ở đâu. Gate được sửa lại chứ không nới ra: kiểu tấn công ban đầu vẫn bị chặn, và module đó từ 0 test lên 25 test. Bug này do chính bộ scenario test tìm ra, thêm một lý do để đầu tư vào test harness.

Chuyển người kèm đủ thông tin

Agent chuyển người xử lý 6 trong 7 sự cố thật. Tỉ lệ tự xử lý còn thấp, nhưng agent đã dừng lại khi chưa đủ căn cứ để tiếp tục. Mình đặt luật là mỗi lần chuyển người phải kèm tóm tắt, evidence, các bước đã thử và đề xuất bước tiếp theo. Ở 5 ca, agent còn chỉ ra được check nào đã từ chối và vì sao. Phần thông tin đó giúp người trực tiếp tục xử lý mà không phải thu thập lại từ đầu.

Nói rõ cái gì đã chứng minh, cái gì chưa

Mình chia các năng lực của agent thành bốn mức: đã chứng minh trên máy thật, chạy end-to-end nhưng chỉ trong môi trường giả lập, mới có unit test, và chưa chạy bao giờ. Lý do là kết quả 29/29 nhìn sạch sẽ rất dễ khiến mình tưởng mọi thứ đã được kiểm chứng. Thực tế, lượt chạy đó chỉ đụng tới một trong năm thay đổi lớn gần nhất.

Trong từng ticket cũng cần phân biệt nội dung nào do model tạo ra và có thể thay đổi giữa các lần chạy, nội dung nào được tạo theo logic cố định. Đây là điều cần thiết để người vận hành đánh giá một agent có quyền thao tác trên hạ tầng.

Sau lần thử này

Kết quả cho thấy agent có thể đảm nhận một phần công việc trực, miễn là phạm vi đủ hẹp và từng hành động đều được kiểm tra. Kết quả chưa đủ để giao hẳn ca trực: mới có một ca được tự sửa và xác nhận thành công trên VM thật, còn playbook service vẫn cần kiểm chứng thêm.

Nếu một ngày đem nó vào vận hành thật, mình sẽ đi từng nấc, và mỗi nấc chỉ cần thay đổi cấu hình:

1. Shadow mode trên queue thật.
2. Bật quyền sửa riêng cho VM bị deallocate.
3. Bật các playbook còn lại, có người ngồi quan sát.
4. Chạy trọn một ca trực có giám sát, rồi mới quyết định có tin nó hay không.

Nếu anh em cũng đang thử dựng agent cho ops, mình nghĩ nên dành thời gian xác định rõ những gì agent không được làm, rồi chạy shadow mode trước khi mở quyền sửa. Các lần thử có kiểm soát trên VM thật cũng rất cần thiết. Với dự án này, đó là lúc mình tìm ra những lỗi mà bộ mock ban đầu không có cách nào chỉ ra được.

Hẹn gặp anh em ở bài sau.

Tài liệu tham khảo

• NVIDIA NemoClaw (GitHub)
• Run NemoClaw with a Local LLM on DGX Spark
• Secure Long Running AI Agents with OpenShell on DGX Spark
• Nemotron 3 Super: DGX Spark Deployment Guide
• Model card: NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4
• Lock your Azure resources to protect your infrastructure