Agent không chỉ là Model: Vì sao các hãng AI vẫn bán câu chuyện bằng benchmark?

September 5, 202615 min read

Model thường đứng trên sân khấu, còn harness nằm trong phòng máy. Bài viết phân tích vì sao OpenAI, Anthropic và Google luôn nhấn mạnh benchmark khi ra model mới, dù chính harness mới biến năng lực thô của model thành một agent hữu dụng.

Mỗi lần OpenAI, Anthropic hay Google ra mắt một model mới, kịch bản gần như quen thuộc:

model mới mạnh hơn;
biểu đồ benchmark xuất hiện dày đặc;
coding tốt hơn, reasoning tốt hơn, agentic hơn;
nhanh hơn, rẻ hơn hoặc hiệu quả token tốt hơn;
và tất nhiên: đứng trên hoặc vượt một số đối thủ ở một số bài đo.

Điều đó dẫn tới một câu hỏi khá thú vị:

Nếu Agent = Model + Harness, tại sao các hãng AI hàng đầu lại dành phần lớn sân khấu cho model? Họ có đang bỏ quên harness, hay đây đơn giản là một chiến lược kinh doanh?

Theo tôi, câu trả lời là: họ không hề bỏ quên harness. Ngược lại, các hãng đang đầu tư rất mạnh vào nó. Nhưng model là thứ dễ đóng gói, dễ đo, dễ định giá và dễ bán hơn.

Và nếu nhìn kỹ hơn vào cách các hệ thống agent hiện đại được xây dựng, công thức hợp lý hơn không phải là phép cộng.

Model ở trên sân khấu, harness ở trong phòng máy

Agent không phải chỉ là một model biết gọi tool

Một model tốt cho ta năng lực suy luận, hiểu ngôn ngữ, viết mã, nhìn hình ảnh hoặc lựa chọn hành động. Nhưng để biến năng lực đó thành một agent có thể làm việc nhiều bước, hệ thống còn cần rất nhiều thứ khác.

Tôi thường hình dung hiệu quả của agent bằng một công thức mang tính trực giác:

Agent effectiveness ≈ Model × Harness × Context/Data × Tools × Environment × Eval/Feedback

Đây không phải công thức toán học chính thức. Dấu nhân chỉ để nhấn mạnh một đặc điểm quan trọng: một mắt xích quá yếu có thể kéo cả hệ thống xuống.

Một model rất thông minh nhưng:

không tìm đúng tệp;
nhét quá nhiều thông tin rác vào context;
gọi tool sai tham số;
không biết retry khi lệnh thất bại;
không chạy test sau khi sửa code;
không có sandbox phù hợp;
không duy trì trạng thái qua một công việc dài;

thì trải nghiệm cuối cùng vẫn có thể tệ.

Ngược lại, cùng một model nhưng được đặt vào một harness tốt hơn có thể cho kết quả khác hẳn.

Các lớp tạo nên một agent

OpenAI cũng mô tả agent theo hướng tương tự. Trong tài liệu A practical guide to building agents, họ tách ba nền tảng cơ bản thành model, tools và instructions, sau đó mới đến orchestration, guardrails và vòng chạy agent. Nói cách khác, ngay từ định nghĩa chính thức của một hãng model, model cũng chỉ là một phần của hệ thống.

Vậy tại sao model vẫn luôn là nhân vật chính?

Có nhiều lý do, và phần lớn trong số đó rất hợp lý về mặt sản phẩm lẫn kinh doanh.

1. Model là một “SKU trí tuệ” dễ truyền thông

Một câu như:

Model X đạt 76% trên Terminal-Bench và tăng 12 điểm so với thế hệ trước.

rất dễ hiểu.

Trong khi một câu như:

Chúng tôi cải thiện context compaction, tool routing, sandbox lifecycle, retry policy, filesystem abstraction, checkpointing, state persistence và permission boundaries.

chính xác hơn về mặt hệ thống, nhưng khó trở thành tiêu đề của một buổi ra mắt.

Benchmark biến một thứ vô hình như “độ thông minh” thành một con số có vẻ so sánh được. Nó gần giống cách ngành phần cứng bán CPU bằng số lõi, xung nhịp và benchmark.

Nhìn vào các trang ra mắt model gần đây, mô thức này vẫn rất rõ. OpenAI dùng nhiều bảng benchmark cho GPT-5.6; Anthropic giới thiệu Claude Opus 5 bằng các kết quả coding và knowledge-work; Google cũng đặt các kết quả agentic/coding benchmark ở vị trí nổi bật khi giới thiệu các thế hệ Gemini mới.

Điều này không có nghĩa benchmark là toàn bộ sự thật. Nó có nghĩa benchmark là ngôn ngữ bán hàng rất hiệu quả.

2. Model gắn trực tiếp với thứ các hãng đang bán: compute

Ở tầng API, doanh thu thường gắn rất trực tiếp với model:

Developer / Product
        ↓
Agent / Harness
        ↓
Model API
        ↓
Tokens + inference + compute
        ↓
Model provider

Model càng được xem là mạnh, càng nhiều workload được chuyển vào model đó.

Một model flagship còn tạo ra nhiều hiệu ứng phụ:

nâng giá trị gói thuê bao;
kéo thêm API usage;
tạo lý do để doanh nghiệp thử nghiệm hoặc chuyển workload;
tăng sức hút cho toàn bộ hệ sinh thái tool và agent đi kèm.

Vì vậy, PR model cũng chính là PR cho đơn vị kinh tế cốt lõi mà nhà cung cấp đang bán.

3. Model dễ tạo cảm giác “moat” hơn harness

Một frontier model cần dữ liệu, hạ tầng huấn luyện, post-training, reinforcement learning, inference stack, đội nghiên cứu và lượng vốn rất lớn.

Một ý tưởng harness tốt thì có thể bị sao chép nhanh hơn:

subagent;
memory;
skills;
MCP;
context compaction;
tool routing;
sandbox;
checkpoint;
planner/evaluator loop.

Không phải các kỹ thuật này dễ xây tốt. Nhưng ý tưởng kiến trúc thường lan nhanh giữa các sản phẩm.

Vì vậy về mặt định vị thương hiệu, thông điệp:

“Model của chúng tôi thông minh hơn.”

thường có giá trị chiến lược cao hơn:

“Chúng tôi có một vòng lặp retry và context manager tốt hơn.”

4. Benchmark model giúp cô lập biến số

Đây là lý do mang tính kỹ thuật hơn marketing.

Giả sử một hệ thống mới tốt hơn 30%, nhưng cùng lúc bạn thay:

model;
system prompt;
tool definitions;
context strategy;
retry policy;
số lượt chạy;
sandbox;
retrieval;
budget.

Vậy 30% đó đến từ đâu?

Nếu mục tiêu là chứng minh model mới tốt hơn model cũ, cách hợp lý nhất là giữ harness càng ổn định càng tốt rồi thay model.

Nói cách khác, benchmark model có một chức năng giống thí nghiệm kiểm soát: đóng băng phần còn lại của hệ thống để đo riêng thay đổi của model.

Vấn đề chỉ xuất hiện khi người đọc quên mất điều này và suy diễn:

“Model A đứng đầu benchmark agent ⇒ mọi sản phẩm dùng Model A sẽ là agent tốt nhất.”

Điều đó không nhất thiết đúng.

Các hãng có bỏ quên harness không? Hoàn toàn không

Nếu chỉ nhìn keynote ra mắt model thì dễ có cảm giác harness là phần phụ. Nhưng nhìn vào các bài kỹ thuật và sản phẩm agent của chính ba hãng lớn, bức tranh gần như ngược lại.

OpenAI: từ model sang “model-native harness”

Tháng 4/2026, OpenAI giới thiệu phiên bản mới của Agents SDK và dùng thẳng cụm từ “a model-native harness”. Hệ thống này bao gồm khả năng làm việc với tệp, tool, môi trường máy tính và sandbox cho các tác vụ dài.

Trước đó, OpenAI cũng công khai phân tích Codex agent loop: cách prompt được dựng, model được gọi, tool được thực thi rồi kết quả quay trở lại vòng suy luận tiếp theo.

Một bài kỹ thuật khác của OpenAI về việc đưa Responses API vào môi trường máy tính còn nói rất rõ: model chỉ đề xuất tool call; chính platform/harness mới thực thi command trong filesystem, container và network boundary phù hợp.

Đây chính xác là kỹ nghệ harness.

Anthropic: Claude Code là bằng chứng sống cho giá trị của harness

Anthropic thậm chí nói rõ hơn.

Trong bài Demystifying evals for AI agents, Anthropic phân biệt hai khái niệm:

agent harness/scaffold: hệ thống nhận input, điều phối tool calls và trả kết quả;
evaluation harness: hạ tầng chạy benchmark, ghi trace và chấm kết quả.

Và họ viết rất thẳng: khi đánh giá một agent, ta đang đánh giá harness và model hoạt động cùng nhau.

Claude Code cũng cho thấy cùng một model có thể được “nâng cấp” đáng kể bằng hệ thống xung quanh nó: tool use, permissions, hooks, subagents, background tasks, checkpoints và context management.

Anthropic còn có cả một chuỗi bài nghiên cứu về harness cho tác vụ dài. Trong Effective harnesses for long-running agents, họ chỉ ra rằng chỉ đặt một frontier model vào vòng lặp với prompt cấp cao vẫn không đủ để xây ứng dụng chất lượng production. Sang Harness design for long-running application development, họ tiếp tục cải thiện bằng kiến trúc planner – generator – evaluator và cơ chế bàn giao ngữ cảnh có cấu trúc.

Nếu một hãng “bỏ quên harness”, họ sẽ không đầu tư nghiên cứu sâu tới mức này.

Google: model tốt vẫn chưa đủ cho production

Google ADK 2.0 có lẽ là tuyên bố rõ nhất về vấn đề này.

Trong bài Why we built ADK 2.0, Google viết rằng khi đưa agent từ prototype lên production, các phương pháp tập trung vào model như guardrails, skills và prompting chỉ có thể đi đến một giới hạn nhất định.

Lý do là LLM thường bị giao luôn cả những việc mà code truyền thống làm tốt hơn:

routing;
scheduling;
error handling;
các bước nghiệp vụ bắt buộc theo thứ tự.

ADK 2.0 vì thế đưa orchestration xác định trở lại code và chỉ dùng LLM cho các nút thật sự cần suy luận.

Đó là một thay đổi tư duy quan trọng:

Không phải cứ có model mạnh hơn là nên giao thêm mọi thứ cho model.

Đôi khi agent tốt hơn vì harness biết phần nào không nên để model quyết định.

Cái bẫy lớn: nhiều “model benchmark” thực ra đang đo cả hệ thống

Đây là chỗ tôi nghĩ developer cần cẩn thận nhất.

Có hai loại câu hỏi rất khác nhau:

Model này có năng lực thô tốt đến đâu?
Hệ thống agent dùng model này hoàn thành công việc tốt đến đâu?

Hai câu hỏi đó cần hai kiểu đánh giá khác nhau.

Model benchmark và Agent-system benchmark

Với benchmark suy luận thuần, ta có thể cố gắng giới hạn tool và scaffold để tập trung đo model.

Nhưng với benchmark coding hoặc computer-use hiện đại, kết quả thường chịu ảnh hưởng của:

agent scaffold/harness;
số lượt model được phép chạy;
tool được cung cấp;
cách đọc và tìm tệp;
context window và compaction;
retry strategy;
test execution;
budget token;
concurrency;
sandbox/environment;
thậm chí độ ổn định của chính hạ tầng benchmark.

SWE-bench là một ví dụ thú vị vì bản thân dự án cũng có một evaluation harness dùng Docker để dựng môi trường, áp patch và chạy test. Nhưng evaluation harness đó không phải agent harness. Một bên là máy chấm, một bên là hệ thống giúp model hành động.

Việc dùng chung chữ “harness” đôi khi khiến cuộc thảo luận trở nên mơ hồ.

Anthropic đã cảnh báo rất đúng ở điểm này: khi benchmark một agent, phải xem cả model lẫn scaffold đang chạy cùng nó.

OpenAI trong năm 2026 cũng công bố một cuộc kiểm tra lại SWE-Bench Pro và cho rằng một tỷ lệ đáng kể task có vấn đề. Dù đồng ý hay không với toàn bộ kết luận của họ, bài học chung vẫn rất rõ:

Benchmark không phải sự thật tuyệt đối. Benchmark là một phép đo, và chất lượng của phép đo phụ thuộc mạnh vào thiết kế thí nghiệm.

Khi đọc một benchmark agent, tôi sẽ hỏi 10 câu này

Thay vì chỉ nhìn con số cuối cùng, nên kiểm tra:

Model chính xác là phiên bản nào?
Harness/scaffold nào được dùng?
Model có những tool gì?
Có retrieval hay index codebase không?
Context được nén hoặc reset thế nào?
Có retry, reflection, verifier hoặc evaluator agent không?
Mỗi task được dùng bao nhiêu token/compute/thời gian?
Có chạy nhiều seed rồi lấy kết quả tốt nhất không?
Sandbox và quyền truy cập môi trường thế nào?
Benchmark đang đo model hay đo sản phẩm agent hoàn chỉnh?

Hai hệ thống cùng dùng một model nhưng trả lời khác nhau cho 9 câu còn lại có thể cho kết quả rất khác.

Vậy đây có phải chiến lược kinh doanh không?

Có. Nhưng không chỉ là marketing.

Tôi nghĩ các hãng frontier đang vận hành đồng thời ba tầng chiến lược.

Tầng 1 — Model: bán năng lực và compute

Đây là tầng dễ định giá nhất:

input token;
output token;
reasoning budget;
latency;
context;
benchmark;
performance per dollar.

Model là sản phẩm có thể đặt cạnh đối thủ trên cùng một bảng.

Tầng 2 — Harness/Product: biến năng lực thành trải nghiệm

Đây là nơi Codex, Claude Code, Antigravity, Agents SDK hay ADK tạo khác biệt thực tế.

Harness quyết định rất nhiều thứ người dùng cảm nhận trực tiếp:

agent có hiểu repo không;
có tự tìm đúng tệp không;
có giữ được mục tiêu qua hàng chục bước không;
có biết kiểm tra công việc của chính nó không;
có phục hồi sau lỗi không;
có an toàn khi được cấp quyền cao không.

Ở tầng này, “model tốt nhất” chưa chắc tạo ra “sản phẩm tốt nhất”.

Tầng 3 — Platform/Ecosystem: giữ workload ở lại

Khi một hệ sinh thái đã có:

SDK;
skills;
MCP/tool integrations;
evals;
tracing;
permissions;
sandbox;
memory;
workflow;
enterprise governance;

chi phí chuyển đổi của doanh nghiệp tăng lên đáng kể.

Vì vậy harness không chỉ là công cụ kỹ thuật. Nó cũng là lớp phân phối và giữ chân workload.

Nói ngắn gọn:

Model    → tạo nhu cầu và bán compute
Harness  → biến model thành sản phẩm hữu dụng
Platform → biến sản phẩm thành hệ sinh thái khó rời bỏ

Đó là lý do các hãng vừa cạnh tranh model, vừa âm thầm cạnh tranh rất mạnh ở agent runtime và orchestration.

Trong thời đại agent, moat sẽ dịch chuyển từ “model” sang “system”

Khi khoảng cách giữa các frontier model dần co lại ở nhiều tác vụ, khả năng đổi model cũng tăng lên.

Một hệ thống có thể dùng:

model mạnh nhất cho planning;
model rẻ hơn cho classification;
model chuyên coding cho implementation;
model khác cho vision hoặc research.

Lúc đó model bắt đầu giống một compute primitive hơn là toàn bộ sản phẩm.

Thứ khó thay hơn có thể là:

workflow của tổ chức;
dữ liệu riêng;
memory;
tool integrations;
permission model;
eval suite;
observability;
feedback loop;
cách agent tương tác với môi trường thật.

Nói cách khác, moat dài hạn của một sản phẩm agent có thể nằm ở systems engineering nhiều không kém model intelligence.

Điều thú vị là chính các model lab cũng đang di chuyển theo hướng này. OpenAI xây Agents SDK và computer environment; Anthropic mở rộng Claude Agent SDK, Managed Agents và Claude Code; Google biến ADK thành một runtime workflow ngày càng đầy đủ.

Họ không chỉ muốn bán “bộ não”. Họ đang xây luôn hệ thần kinh, tay chân và môi trường sống cho bộ não đó.

Điều này có ý nghĩa gì với developer?

Nếu đang chọn model cho một agent, tôi sẽ không bắt đầu bằng câu:

Model nào đang đứng đầu leaderboard?

Tôi sẽ bắt đầu bằng:

Với harness của tôi, tool của tôi, dữ liệu của tôi và workflow thật của tôi, cấu hình nào đạt task-success tốt nhất với mức chi phí và độ trễ chấp nhận được?

Một quy trình đánh giá thực tế nên đo ít nhất:

Thành phần	Câu hỏi cần đo
Model	Có suy luận đúng và ổn định không?
Tool use	Chọn đúng tool, đúng tham số không?
Context	Có tìm và giữ đúng thông tin quan trọng không?
Harness	Có orchestration, retry và recovery tốt không?
Environment	Có thực thi chính xác trong môi trường thật không?
Safety	Permission và sandbox có giới hạn blast radius không?
Evals	Có đo được task-success thay vì chỉ chấm câu trả lời đẹp không?
Economics	Tổng token, thời gian và chi phí cho một task thành công là bao nhiêu?

Đây là nơi benchmark nội bộ bắt đầu quan trọng hơn leaderboard công khai.

Kết luận

Các hãng AI không bỏ quên harness.

Thực tế, harness đang trở thành một trong những chiến trường quan trọng nhất của agent era.

Nhưng model vẫn luôn đứng trên sân khấu vì nó:

dễ truyền thông;
dễ benchmark;
dễ định giá;
gắn trực tiếp với compute revenue;
tạo định vị frontier mạnh hơn;
và cho phép nhà cung cấp kể một câu chuyện rất đơn giản: “thế hệ mới thông minh hơn thế hệ cũ”.

Trong khi đó, harness nằm trong phòng máy — ít hào nhoáng hơn, khó gói vào một biểu đồ hơn, nhưng lại quyết định rất nhiều việc model có thực sự làm được gì trong thế giới thật.

Nếu phải tóm lại bằng một câu, tôi sẽ viết:

Model là thứ các hãng muốn chúng ta nhìn thấy. Harness là thứ quyết định phần lớn cách chúng ta trải nghiệm năng lực của model.

Và có lẽ trong vài năm tới, cuộc đua đáng xem nhất không còn chỉ là Model War.

Nó sẽ là System War.

Tài liệu tham khảo