Harness Agent Là Gì? Giải Phẫu Thành Phần & Cách Tự Host Trên Máy Chủ

Harness agent là gì mà developer, AI engineer nào cũng nhắc nhưng ít người giải thích rõ? Nếu bạn đang xây AI Agent và thắc mắc vì sao agent của mình gọi tool sai, mất ngữ cảnh giữa chừng hoặc chạy không kiểm soát — vấn đề thường nằm ở harness, không phải model. Bài viết từ InterData sẽ mổ xẻ từng thành phần của agent harness, phân biệt rõ với AI agent và framework, đồng thời hướng dẫn cách tự host trên máy chủ riêng.

1. Harness Agent Là Gì? Phân Biệt Ngay Với Harness.io DevOps Agent

Agent harness (hay harness agent) là lớp phần mềm bao quanh một LLM (Large Language Model), cung cấp mọi thứ mà model không tự có: vòng lặp thực thi, truy cập tool, bộ nhớ, quản lý ngữ cảnh, xử lý lỗi và cơ chế kiểm soát an toàn. Nói ngắn gọn, harness là phần biến một model “chỉ biết sinh text” thành một agent có khả năng hành động.

LLM về bản chất là stateless — nó nhận input, sinh output, rồi quên. Harness chính là bộ khung giữ cho agent nhớ được ngữ cảnh, gọi được API, lưu được trạng thái và biết dừng khi cần dừng.

Disambiguation: Agent Harness ≠ Harness.io DevOps Agent

Nếu bạn tìm “Harness agent” và đang nghĩ đến nền tảng Harness.io — đó là sản phẩm DevOps CI/CD khác hoàn toàn. Harness.io có “AI DevOps Agent” và “Worker Agent” chạy trong pipeline CI/CD, dùng Delegate để triển khai trên Kubernetes. Bài này không nói về sản phẩm đó. Toàn bộ nội dung bên dưới tập trung vào agent harness theo nghĩa kiến trúc AI agent — lớp hạ tầng phần mềm bao quanh LLM.

2. Công Thức Agent = Model + Harness — Harness Agent Là Gì Trong Phương Trình Này?

Công thức được cộng đồng AI sử dụng rộng rãi: Agent = Model + Harness. Trong đó, Model là bộ não suy luận (GPT-4o, Claude, Gemini, Llama…), còn Harness là toàn bộ cơ sở hạ tầng phần mềm xung quanh — từ vòng lặp thực thi, gọi tool, quản lý bộ nhớ đến kiểm soát quyền và xử lý lỗi.

Cách hiểu đơn giản: model cung cấp khả năng suy luận, harness cung cấp khả năng hành động. Thiếu harness, model chỉ là một hàm sinh text. Thiếu model, harness chỉ là một vòng lặp trống.

Một điểm quan trọng mà nhiều người bỏ qua: model mạnh với harness thiết kế kém sẽ cho ra agent tệ hơn model vừa phải với harness chặt chẽ. Harness quyết định agent có gọi đúng tool không, có nhớ được ngữ cảnh giữa các bước không, có dừng lại khi gặp lỗi không — tất cả những thứ model không tự xử lý được.

Nói cách khác, khi bạn nghe ai đó nói “tôi đang build một AI Agent“, phần lớn công việc họ làm chính là thiết kế harness: viết execution loop, cấu hình tool, xây memory pipeline, đặt guardrails. Chọn model thường là bước cuối.

3. Giải Phẫu 9 Thành Phần Của Một Agent Harness

Một harness đầy đủ gồm chín khối chức năng. Không phải agent nào cũng cần đủ cả chín, nhưng hiểu từng khối sẽ giúp bạn biết agent đang thiếu gì khi nó hoạt động không như mong đợi.

3.1. Execution Loop (Vòng lặp thực thi)

Đây là trái tim của harness. Vòng lặp hoạt động theo chu trình Think → Act → Observe → Repeat: model suy luận bước tiếp theo, harness thực thi hành động (gọi tool, ghi file, query database), lấy kết quả trả về cho model, rồi lặp lại cho đến khi task hoàn thành hoặc đạt giới hạn bước.

Nếu vòng lặp không có điều kiện dừng rõ ràng, agent sẽ chạy vô hạn và đốt token. Harness tốt luôn có max_steps, timeout và điều kiện thoát sớm khi task đã xong.

3.2. Tool Access (Truy cập công cụ)

Agent cần gọi tool bên ngoài: search API, đọc database, gửi email, chạy code. Harness quản lý danh sách tool khả dụng, cách gọi (function calling, MCP protocol), phân quyền tool nào agent được dùng và tool nào bị chặn.

Các agent coding như Cline dùng harness để quản lý quyền đọc/ghi file, chạy terminal command theo whitelist. Nếu không có tầng tool access, agent có thể tự ý chạy lệnh nguy hiểm trên hệ thống.

3.3. Memory (Bộ nhớ)

LLM không có bộ nhớ dài hạn. Harness bổ sung hai loại: short-term memory (ngữ cảnh trong phiên, thường là conversation history) và long-term memory (lưu trữ qua nhiều phiên, dùng vector database hoặc key-value store).

Xu hướng 2026 là “memory-as-tool” — agent tự quyết khi nào đọc, ghi, cập nhật bộ nhớ thông qua tool call, thay vì chạy retrieval cứng ở mỗi bước. Cách này giảm token lãng phí và cho agent quyền kiểm soát bộ nhớ của chính nó.

3.4. Context Management (Quản lý ngữ cảnh)

Context window của model có giới hạn (4K, 32K, 128K, 200K token tùy model). Harness phải quyết định đưa thông tin gì vào prompt, bỏ gì ra, tóm tắt đoạn nào. Đây là bài toán context engineering — kỹ thuật quan trọng không kém prompt engineering.

Harness tệ nhồi hết history vào context rồi bị truncate giữa chừng, mất thông tin quan trọng. Harness tốt biết ưu tiên thông tin gần nhất, relevant nhất, và tóm tắt phần còn lại thay vì cắt bỏ.

3.5. State Persistence (Lưu trữ trạng thái)

Agent chạy qua nhiều bước, nhiều phiên. Harness lưu trạng thái hiện tại — đang ở bước nào, kết quả các bước trước, biến trung gian — để agent có thể tiếp tục nếu bị gián đoạn. Không có state persistence, agent restart là mất hết tiến trình và phải chạy lại từ đầu.

3.6. Error Handling (Xử lý lỗi)

Tool gọi thất bại, API timeout, model trả output sai format — harness cần bắt lỗi, retry có giới hạn, hoặc chuyển sang plan B. Agent không có error handling sẽ crash hoặc lặp vô nghĩa khi gặp lỗi đầu tiên.

Một pattern phổ biến: harness retry tối đa 3 lần với exponential backoff, rồi log lỗi và chuyển sang bước tiếp theo hoặc trả kết quả partial cho user thay vì treo.

3.7. Guardrails (Rào chắn an toàn)

Guardrails trong harness khác với guardrails của model. Model guardrails lọc nội dung đầu vào/đầu ra. Harness guardrails kiểm soát hành động: agent có được phép xóa file không? Có được gửi email thật không? Có giới hạn chi phí API call không? Có được truy cập dữ liệu nhạy cảm không?

Theo danh sách rủi ro OWASP ASI 2026, 8 trong 10 loại rủi ro liên quan đến agent nằm ở tầng harness, không phải tầng model. Điều này cho thấy bảo mật agent ngày nay chủ yếu là bảo mật harness.

3.8. Observability (Giám sát)

Logging từng bước agent làm gì, gọi tool nào, nhận kết quả gì, tốn bao nhiêu token, mất bao lâu. Không có observability, khi agent cho kết quả sai bạn không biết lỗi ở bước nào để sửa. Các công cụ như LangSmith, Braintrust, Helicone đều hoạt động ở tầng harness.

3.9. Sandbox (Môi trường cách ly)

Agent chạy code hoặc thao tác file cần được cách ly khỏi hệ thống chính. Sandbox có thể là Docker container, VM riêng hoặc chroot jail. Đây là lớp phòng thủ cuối cùng — nếu agent bị prompt injection hoặc chạy lệnh nguy hiểm, sandbox giới hạn thiệt hại trong phạm vi container, không ảnh hưởng đến host.

4. Agent Harness Khác Gì Agent Framework (LangChain, n8n)?

Đây là câu hỏi gây nhầm lẫn nhiều nhất. Framework và harness hoạt động ở hai tầng khác nhau, không phải hai lựa chọn loại trừ nhau. Hệ thống production thường dùng cả hai.

Tiêu chí	Agent Framework	Agent Harness
Vai trò	Cung cấp building blocks (chain, tool, memory, retriever) để bạn lắp ráp agent bằng code	Cung cấp runtime sẵn sàng chạy: execution loop, state, guardrails, sandbox đã được cấu hình
Ví dụ	LangChain, LangGraph, CrewAI, Mastra	Claude Code (Anthropic), Devin, Cline, OpenAI Codex agent
Người dùng chính	Developer muốn kiểm soát từng chi tiết kiến trúc agent	Người cần agent chạy được nhanh, ít cấu hình thủ công
Mức trừu tượng	Thấp–trung bình: bạn tự viết logic ghép nối	Cao: opinionated defaults, chạy out-of-the-box
Kết hợp?	Hoàn toàn được. Nhiều production agent dùng framework bên trong + harness bên ngoài. Ví dụ: dùng LangGraph để xây workflow, chạy trong một harness có sandbox Docker và guardrails riêng.

Các nền tảng no-code/low-code như n8n nằm ở ranh giới giữa framework và harness. n8n cung cấp sẵn execution loop (workflow engine), kết nối tool (qua node), và giao diện kéo thả — gần với harness hơn framework thuần. Bạn có thể tạo chatbot AI bằng n8n mà không cần viết execution loop từ đầu, chỉ cần kéo node và cấu hình.

5. Vì Sao Harness Quyết Định Agent Chạy Tốt Hay Thất Bại?

Nhiều người đổ lỗi cho model khi agent hoạt động kém. Thực tế, phần lớn lỗi agent production nằm ở tầng harness, không phải tầng model.

Kịch bản 1 — Model mạnh, harness yếu: Agent dùng GPT-4o nhưng harness không retry khi tool call thất bại, không giới hạn bước, không tóm tắt context khi vượt window. Kết quả: agent chạy vài bước rồi lặp vô nghĩa hoặc trả hallucination vì context bị truncate mất phần quan trọng.

Kịch bản 2 — Model vừa, harness tốt: Agent dùng model nhỏ hơn (Llama 3.1 8B, Mistral) nhưng harness có execution loop chặt chẽ, tool routing chính xác, context window được quản lý bằng summarization + priority ranking. Kết quả: agent hoàn thành task ổn định, chi phí API thấp hơn rất nhiều.

Bài học rút ra: trước khi nâng cấp model (tốn thêm tiền API), hãy kiểm tra harness. Vòng lặp có điều kiện dừng chưa? Tool nào đang thiếu? Context có bị truncate không? State có được lưu giữa các phiên không? Những câu hỏi này giải quyết được phần lớn vấn đề mà không cần đổi model.

Các agent như Hermes Agent minh họa rõ điều này — được thiết kế với harness tích hợp sẵn tool routing, memory pipeline và function calling, giúp agent hoạt động ổn định ngay cả khi dùng model kích thước trung bình.

6. Tự Host Agent Harness Trên Máy Chủ Cần Những Gì?

Chạy agent trên máy tính cá nhân phù hợp để test. Nhưng khi cần agent chạy nền 24/7, xử lý nhiều phiên hoặc phục vụ người dùng thật, bạn cần một máy chủ riêng với quyền root. Dưới đây là checklist hạ tầng cụ thể.

Checklist hạ tầng tối thiểu cho self-host agent harness

• CPU: Agent harness chủ yếu I/O-bound (chờ API response từ model provider), không cần CPU khủng. 2–4 vCPU đủ cho 1 agent đơn luồng gọi API bên ngoài. Nếu chạy local model qua Ollama hoặc vLLM thì cần CPU mạnh hơn hoặc GPU.
• RAM: Tối thiểu 4 GB cho agent gọi API bên ngoài (OpenAI, Anthropic). 8–16 GB nếu chạy kèm vector database (ChromaDB, Qdrant) để lưu long-term memory. 32 GB trở lên nếu chạy local LLM 7B–13B parameter.
• Ổ cứng: SSD NVMe cho tốc độ đọc ghi log, state file, vector embedding. 40–80 GB đủ cho phần lớn setup. Thêm dung lượng nếu lưu conversation history dài hạn.
• Docker: Gần như bắt buộc để sandbox agent, cách ly dependency và dễ deploy/rollback. Cài Docker cần quyền root — đây là lý do máy chủ ảo VPS phù hợp hơn shared hosting cho việc host agent.
• Chạy nền: Agent cần process chạy liên tục hoặc trigger theo lịch. Dùng systemd, supervisor, hoặc Docker Compose với restart policy unless-stopped.
• Mạng: Băng thông ổn định để gọi API model provider (latency quan trọng hơn throughput). Port mở cho webhook nếu agent cần nhận event từ bên ngoài (Telegram bot, Slack event…).
• Bảo mật: Firewall, fail2ban, SSH key-only. API key lưu trong environment variable hoặc secret manager, không hard-code trong source code.

Ví dụ triển khai thực tế trên VPS

Một setup phổ biến cho agent chatbot hoặc automation: VPS 4 vCPU, 8 GB RAM, 80 GB NVMe → cài Docker → chạy n8n hoặc LangGraph agent trong container → kết nối OpenAI API → dùng ChromaDB container cho long-term memory → Nginx reverse proxy để expose webhook. Tổng cộng 3–4 container chạy song song, agent hoạt động liên tục, chi phí hàng tháng chỉ là tiền VPS cộng tiền API call.

Nếu agent phức tạp hơn — ví dụ chạy nhiều sub-agent, mỗi sub-agent gọi tool riêng, xử lý document lớn qua RAG pipeline — thì cần 16 GB RAM trở lên và nên xem xét Cloud Server để dễ scale khi tải tăng.

7. Chọn VPS Hay Cloud Server Để Chạy Agent Harness?

Phụ thuộc vào quy mô agent và cách bạn vận hành. Bảng dưới đây so sánh theo các tiêu chí thực tế khi host agent harness.

Tiêu chí	VPS	Cloud Server
Phù hợp khi	1 agent, ít user, tải ổn định, dev/test, bot Telegram, chatbot nội bộ, coding agent cho team nhỏ	Nhiều agent song song, nhiều user, tải biến động, cần scale nhanh không downtime
Tài nguyên	Cố định theo gói đã chọn. Nâng cấp cần đổi gói	Nâng/hạ CPU, RAM nhanh theo tải thực tế, không cần migrate
Chi phí	Thấp hơn, giá cố định hàng tháng, dễ dự toán	Cao hơn, nhưng trả đúng tài nguyên dùng thực tế
Quyền root	Có — cài Docker, cron, daemon tự do	Có — toàn quyền tương tự VPS
Khi nào chuyển đổi	Bắt đầu với VPS. Khi agent phục vụ trên 50 user đồng thời, chạy trên 5 tool song song với tải không dự đoán được, hoặc cần thay đổi cấu hình nhanh theo chiến dịch → chuyển sang Cloud Server.

Khuyến nghị cụ thể: Nếu bạn đang build agent chatbot nội bộ, bot Telegram, coding agent cho team nhỏ hoặc chạy n8n workflow tự động — VPS 4–8 GB RAM là đủ và chi phí dễ tiếp cận. Khi agent cần xử lý context lớn (RAG trên hàng nghìn document), chạy nhiều sub-agent song song hoặc phục vụ lượng user tăng đột biến — Cloud Server cho phép nâng RAM/CPU trong vài phút mà không cần chuyển máy hay mất dữ liệu.

8. Câu Hỏi Thường Gặp Về Harness Agent (FAQ)

Agent harness có phải là AI agent không?

Không. Agent harness là một phần cấu thành AI agent, không phải toàn bộ. Theo công thức Agent = Model + Harness, harness là lớp hạ tầng phần mềm bao quanh model — cung cấp vòng lặp thực thi, bộ nhớ, quản lý tool và guardrails. Agent là tổng thể hoàn chỉnh khi model và harness kết hợp với nhau.

Harness engineering khác gì prompt engineering?

Prompt engineering tập trung vào cách viết lời nhắc cho model suy luận đúng hướng. Harness engineering thiết kế toàn bộ môi trường vận hành agent: execution loop, tool access, memory pipeline, state persistence, sandbox, guardrails. Prompt chỉ là một phần nhỏ trong context management của harness — harness rộng hơn rất nhiều.

Có cần GPU để chạy agent harness không?

Phụ thuộc vào cách bạn dùng model. Nếu agent gọi API cloud (OpenAI, Anthropic, Google) thì không cần GPU — harness chỉ cần CPU và RAM để quản lý vòng lặp, state, tool call. GPU chỉ cần khi bạn chạy local LLM (Ollama, vLLM) trên chính máy chủ đó. Phần lớn agent hiện nay gọi API nên VPS CPU thường là đủ.

Có thể tự viết agent harness từ đầu không?

Hoàn toàn được. Một harness tối thiểu cần: vòng lặp while gọi model, parser cho tool call output, hàm thực thi tool và cơ chế dừng. Python là ngôn ngữ phổ biến nhất. Tuy nhiên, với hầu hết trường hợp, dùng framework có sẵn (LangGraph, OpenAI Agents SDK) rồi tùy chỉnh harness layer bên trên sẽ nhanh hơn viết mọi thứ từ đầu.

Harness agent là gì trong bối cảnh MCP (Model Context Protocol)?

MCP là giao thức chuẩn hóa cách agent kết nối với tool bên ngoài. Trong kiến trúc harness, MCP nằm ở tầng tool access — thay vì mỗi tool cần adapter riêng, MCP cung cấp giao diện thống nhất để harness gọi bất kỳ tool nào hỗ trợ protocol này. Harness tích hợp MCP có thể mở rộng tool mà không cần sửa code core của agent.

Nội dung mang tính tham khảo kỹ thuật. Kiến trúc harness, tool, cấu hình triển khai và hành vi agent có thể thay đổi theo model cụ thể, phiên bản framework (LangChain, LangGraph, n8n, OpenAI Agents SDK…), hệ điều hành và môi trường thực tế. Luôn kiểm thử kỹ, sao lưu dữ liệu và đánh giá rủi ro bảo mật trước khi đưa agent vào production.