Blog / Agents / Runtime / Frameworks

Agents SDK 2026: vì sao cuộc chiến framework đang chuyển từ abstraction sang harness, sandbox và khả năng chạy tiếp

Nếu bạn từng dựng một agent chỉ bằng prompt, vài tool và một vòng lặp tự gọi hàm, bạn sẽ thấy giai đoạn đầu khá ấn tượng. Agent biết đọc file, chạy lệnh, sửa patch, tạo báo cáo. Nhưng chỉ cần công việc dài hơn, đụng nhiều thư mục hơn, phải resume sau lỗi hoặc có phê duyệt giữa chừng, hệ bắt đầu lộ ra một sự thật khó chịu: framework đẹp chưa đủ, agent cần một runtime contract thật.

Đó là lý do chủ đề Agents SDK đang nóng. Đây không đơn thuần là thêm API. Nó phản ánh một dịch chuyển kiến trúc: từ mô hình “model + tool wrappers” sang mô hình “model + harness + sandbox + state ledger”. Góc này liên quan tới Agent Sandbox 2026, nhưng không trùng. Bài sandbox trước đó tập trung vào workspace chuẩn cho coding agent. Bài này đi sâu hơn vào lớp harness đứng giữa model và môi trường thực thi, thứ đang dần trở thành nơi quyết định agent có đi qua production nổi hay không.

Vấn đề thật: framework trừu tượng thường gãy ở đâu khi bước ra khỏi demo?

Phần lớn framework agent thế hệ đầu giải quyết khá tốt ba chuyện: định nghĩa tool, gọi model, và nối kết quả vào vòng lặp tiếp theo. Điều đó đủ cho các tác vụ ngắn. Nhưng khi agent phải xử lý việc dài hơi, các vấn đề thật xuất hiện ở tầng thấp hơn:

• agent không biết chính xác file đầu vào nào là nguồn sự thật,
• output bị ghi rải rác, khó nối vào bước sau,
• một command lỗi có thể làm mất cả tiến trình dài nhiều phút,
• quyền truy cập và secrets thường đi chung với môi trường chạy code do model sinh ra,
• đội vận hành không quan sát được agent đã làm gì ở mức đủ chi tiết để debug hoặc audit.

Nói cách khác, nhiều hệ agent không vỡ vì model quá yếu. Chúng vỡ vì không có một hợp đồng thực thi đủ rõ giữa model, tool, state và môi trường. Đây cũng là lý do các bài như Agent Reliability 2026 hay workflow, memory, approval ngày càng quan trọng: agent chỉ đáng tin khi mọi lớp xung quanh nó bắt đầu có cấu trúc.

Agents SDK mới nói lên điều gì về hướng đi của thị trường?

Theo thông báo chính thức của OpenAI, bản cập nhật Agents SDK thêm một model-native harness để agent có thể inspect file, chạy command, chỉnh sửa code, dùng MCP, nhận hướng dẫn theo skills/AGENTS.md và làm việc trong sandbox có manifest rõ ràng. Chi tiết đáng chú ý không nằm ở từng tính năng riêng lẻ. Điều quan trọng là chúng được gom lại như một lớp điều phối nhất quán.

Điều này đáng chú ý vì nó đổi trọng tâm cạnh tranh. Trước đây, đội ngũ thường so framework theo API elegance hoặc tốc độ tích hợp. Bây giờ, câu hỏi sắc hơn là:

• framework có hiểu cách frontier model thực sự làm việc hay không,
• runtime có tách harness khỏi compute để giảm blast radius hay không,
• run dài có snapshot, resume và artifact contract hay không,
• và observability có đủ sâu để đội ngũ biết agent thành công vì đâu, vỡ vì đâu hay không.

Đây là bước chuyển từ “framework như thư viện lập trình” sang “framework như hệ điều hành thu nhỏ cho agent”.

Một use case end-to-end: agent phân tích dataroom trước khi đội đầu tư đưa ra quyết định

Hãy lấy một bài toán thực tế hơn là demo sửa code. Một quỹ đầu tư hoặc đội M&A cần xem nhanh dataroom của một công ty phần mềm trước buổi họp IC. Bộ dữ liệu gồm báo cáo tài chính, hợp đồng khách hàng mẫu, ghi chú pháp lý, cap table, vài file CSV doanh thu và email tóm tắt từ nhóm phân tích.

Nhiệm vụ của agent không phải là viết một đoạn tóm tắt chung chung. Nó phải:

1. đọc hàng chục file với format khác nhau,
2. trích các chỉ số chính và đối chiếu chéo giữa tài liệu,
3. phát hiện chỗ số liệu mâu thuẫn giữa deck và CSV,
4. liệt kê câu hỏi đỏ cần con người kiểm tra thêm,
5. tạo một memo đầu ra có citation theo file nguồn.

Nếu hệ chỉ có một agent gắn vài tool rời, xác suất vỡ rất cao. Một file path sai, một command parse lỗi, hay một lần context trôi là đủ làm hỏng toàn bộ run. Còn nếu hệ có harness đúng nghĩa, flow sẽ khác:

• workspace được dựng từ manifest: thư mục dữ liệu chỉ đọc, thư mục output riêng, thư mục scratch tạm,
• agent có bộ tool chuẩn để đọc, tìm kiếm, chạy script phân tích CSV và ghi memo,
• mỗi chặng quan trọng như discovery, extraction, reconciliation, memo draft đều được snapshot,
• nếu sandbox chết ở bước 19 trên 30, run có thể tiếp tục thay vì làm lại từ đầu,
• mọi artifact cuối đều có nơi cố định để downstream workflow hoặc con người review.

Chính ở các use case kiểu này, bạn mới thấy sự khác biệt giữa “một agent biết gọi tool” và “một agent có môi trường làm việc đủ chuẩn để hoàn thành nhiệm vụ”.

Lớp hệ thống phía sau: năm thành phần quyết định agent có làm xong việc thật hay không

1. Harness nằm ngoài model

Đây là khác biệt lớn nhất. Harness không phải prompt. Nó là lớp đứng ngoài model để quản lý tool lifecycle, điều kiện vào ra, trạng thái run, approval và policy. Khi harness quá mỏng, model phải tự gánh nhiều thứ không nên gánh. Khi harness đủ dày, model chỉ tập trung vào quyết định cấp cao còn môi trường được vận hành bằng contract rõ ràng.

2. Workspace manifest

Manifest nói rõ đầu vào nào được mount, thư mục nào chỉ đọc, thư mục nào cho ghi, artifact cuối phải xuất ở đâu. Điều này nối rất chặt với bài sandbox. Không có manifest, “workspace” chỉ là một thư mục tạm. Có manifest, workspace trở thành một phần của hợp đồng thực thi.

3. State ledger và khả năng chạy tiếp

Một trong những chi tiết quan trọng nhất trong cập nhật Agents SDK là ý tưởng snapshotting và rehydration. Đây là chỗ nhiều đội ngũ bỏ qua nhất. Khi run kéo dài, container hết hạn, subprocess treo, hoặc task phải chờ approval, hệ không thể coi mọi run là bất tử. State phải được externalize để có thể dựng lại môi trường và đi tiếp. Đây cũng là lý do bài State of AI Agent Memory 2026 đáng đọc song song: memory không chỉ là nhớ cuộc hội thoại, mà còn là nhớ trạng thái công việc.

4. Tách harness khỏi compute để giảm rủi ro

Khi code do model sinh ra có thể chạy shell hoặc thao tác file, việc nhét secrets thật ngay trong cùng môi trường là một thiết kế nguy hiểm. Hướng đi mới tách harness điều phối ra khỏi compute sandbox, để credential, policy và approval logic không nằm chung blast radius với môi trường thực thi linh hoạt. Đây là nơi giao nhau tự nhiên với Agent Security 2026 và AI Agent Identity 2026.

5. Artifact contract

Agent production không nên kết thúc bằng một câu trả lời đẹp. Nó nên kết thúc bằng artifact có cấu trúc: memo, patch, test log, bảng đối soát, danh sách cảnh báo, hoặc tệp JSON cho hệ sau đọc tiếp. Khi artifact có contract rõ, bạn mới thật sự nối agent vào quy trình doanh nghiệp thay vì dùng nó như một lớp trợ lý chat nâng cấp.

Trade-off: model-native harness mạnh hơn, nhưng cũng kéo theo rủi ro mới

Xu hướng này rất đáng mừng, nhưng không nên nhìn như marketing một chiều.

Lock-in tăng lên

Khi harness được tối ưu sát với một họ model, hiệu năng và độ ổn định có thể tăng. Nhưng đổi lại, portability giảm. Đội ngũ phải cân nhắc xem mình đang mua năng suất ngắn hạn hay đang dần khóa kiến trúc vào một nhà cung cấp.

"Phép màu" trong harness có thể che khuất lỗi thật

Nếu framework làm quá nhiều thứ ngầm bên dưới, đội ngũ dễ có cảm giác agent thông minh hơn mức thực. Đến khi gặp case biên hoặc compliance audit, họ mới phát hiện mình không hiểu rõ runtime đã quyết định điều gì thay model.

Khả năng chạy tiếp không miễn phí

Snapshot, rehydration và durable execution đều có giá của nó: lưu trạng thái, chi phí I/O, thời gian resume, và độ phức tạp khi state giữa tool với filesystem bị lệch. Không phải task nào cũng xứng đáng có một lớp durability dày như nhau.

Ranh giới trách nhiệm có thể mờ đi

Khi harness giỏi hơn, người dùng dễ đòi agent tự đi xa hơn. Nhưng càng tự động hóa nhiều bước, câu hỏi “ai chịu trách nhiệm khi outcome sai?” càng nóng. Đây là chỗ approval, audit trail và owner model không được phép vắng mặt.

Các failure modes nên nghĩ trước khi đưa vào production

• Harness theater: nhìn có vẻ chuẩn hóa nhưng thực tế policy vẫn nằm trong prompt, secrets vẫn trôi vào sandbox.
• Resume giả: hệ nói có resume nhưng chỉ khôi phục phần chat state, còn file system và tool state thì không đồng nhất.
• Artifact drift: output không có schema ổn định, khiến downstream pipeline vỡ âm thầm.
• Over-generalization: dùng cùng một runtime nặng cho mọi task làm chi phí và latency phình to không cần thiết.
• Observability mù: chỉ thấy token usage và final answer, nhưng không thấy các bước tool-use, command, file mutation và điểm ra quyết định thật.

Checklist rollout thực tế cho đội ngũ đang cân nhắc Agents SDK hoặc nền tảng tương tự

1. Bắt đầu từ task nhiều bước nhưng blast radius vừa phải, như phân tích dataroom, đối soát tài liệu, tạo báo cáo có bằng chứng.
2. Tách rõ harness contract với prompt contract: cái gì là policy thực thi phải nằm ngoài model.
3. Chuẩn hóa manifest workspace ngay từ đầu: input, output, read-only, read-write, artifact chính thức.
4. Thiết kế checkpoint theo chặng giá trị, không snapshot mù mọi bước.
5. Buộc output đi qua artifact schema để downstream system dùng được.
6. Gắn approval ở các điểm commit quan trọng, nhất là khi agent có thể sửa dữ liệu, gửi đi hoặc tác động hệ ngoài.
7. Đo thành công bằng outcome hoàn chỉnh, không chỉ bằng số run “không lỗi”.

Insight cuối cùng: agent framework mạnh nhất sẽ là framework biết tự hạ mình thành hạ tầng

Đây là điểm quan trọng nhất của làn sóng này. Trong giai đoạn đầu, framework agent được bán như một cách lập trình mới. Sang giai đoạn production, framework thắng cuộc có thể sẽ không phải framework nhiều abstraction nhất, mà là framework biết biến abstraction thành contract vận hành rõ ràng.

Khi đó, giá trị không còn nằm ở việc viết agent nhanh hơn trong ngày đầu. Giá trị nằm ở việc sau ba tháng, agent vẫn có thể đọc đúng file, ghi đúng artifact, sống sót qua lỗi hạ tầng, đi tiếp sau approval và để lại một đường audit đủ rõ cho con người tin dùng.

Nói ngắn gọn: cuộc chiến framework đang dịch từ API đẹp sang runtime đáng tin. Bản cập nhật Agents SDK chỉ là một tín hiệu, nhưng là tín hiệu rất mạnh cho hướng đi đó.