Sổ tay học AI năm 2026: Học gì, dùng gì, tránh gì

Tiêu đề gốc: Những gì cần Học, Xây Dựng và Bỏ Qua trong AI Agents (2026)Tác giả gốc: RohitBiên dịch: Peggy, BlockBeats

Tác giả gốc:律动BlockBeats

Nguồn gốc:

Truyền tải: Mars Finance

Lời người biên tập: Lĩnh vực AI Agent đang bước vào giai đoạn bùng nổ công cụ, thiếu sự đồng thuận.

Mỗi tuần đều xuất hiện các khung framework mới, mô hình mới, benchmark mới và các sản phẩm “10 lần hiệu quả” mới, nhưng vấn đề thực sự quan trọng không còn là “làm thế nào để theo kịp tất cả các thay đổi”, mà là “những thay đổi nào thực sự đáng để đầu tư”.

Tác giả cho rằng, trong bối cảnh hệ sinh thái công nghệ liên tục bị viết lại, khả năng thực sự có thể sinh lợi lâu dài không phải là theo đuổi framework mới nhất, mà là các năng lực nền tảng: kỹ thuật ngữ ngữ cảnh (context engineering), thiết kế công cụ, hệ thống đánh giá (eval), mô hình orchestrator-subagent, tư duy sandbox và harness. Những năng lực này sẽ không nhanh chóng trở nên lỗi thời theo từng thế hệ mô hình mới, ngược lại, chúng sẽ trở thành nền tảng xây dựng AI Agent đáng tin cậy.

Bài viết còn chỉ ra rằng, AI Agent đang thay đổi ý nghĩa của “thâm niên”. Trước đây, bằng cấp, chức vụ và thời gian làm việc là giấy thông hành vào ngành; nhưng trong một lĩnh vực mà cả các ông lớn còn đang thử nghiệm công khai, hồ sơ cá nhân không còn là bằng chứng duy nhất. Bạn đã làm gì, đã giao hàng gì, ngày càng trở nên quan trọng hơn.

Vì vậy, bài viết không chỉ bàn về việc năm 2026 AI Agent cần học gì, dùng gì, bỏ qua gì, mà còn nhắc nhở: Trong thời đại ngày càng nhiều nhiễu loạn này, năng lực quý giá nhất là khả năng đánh giá xem điều gì thực sự đáng để học, và liên tục tạo ra những thứ thực sự hữu ích.

Dưới đây là nội dung gốc:

Mỗi ngày đều xuất hiện một framework mới, một benchmark mới, một sản phẩm “10 lần hiệu quả” mới. Vấn đề không còn là “tôi nên làm thế nào để theo kịp”, mà là: trong số đó, đâu mới là tín hiệu thực sự, đâu chỉ là nhiễu loạn khoác áo cảm giác cấp bách.

Mỗi lộ trình, sau một tháng ra mắt có thể đã lỗi thời. Framework bạn mới nắm vững trong quý trước, giờ đã trở thành cũ kỹ. Benchmark bạn từng tối ưu hóa, bị người khác vượt mặt rồi nhanh chóng bị thay thế bằng cái mới. Trước đây, chúng ta được huấn luyện theo một con đường truyền thống: một hệ sinh thái công nghệ, tương ứng một nhóm chủ đề và cấp độ; một chuỗi kinh nghiệm làm việc, tương ứng thời gian và chức danh; từng bước chậm rãi leo lên. Nhưng AI đã viết lại bức tranh này. Ngày nay, chỉ cần dùng đúng prompt, có khả năng thẩm mỹ đủ tốt, một người có thể hoàn thành công việc mà trước đây cần một kỹ sư có hai năm kinh nghiệm làm trong một sprint.

Năng lực chuyên môn vẫn còn quan trọng. Không có gì thay thế được việc bạn đã từng chứng kiến hệ thống sụp đổ, chỉnh memory leak lúc 2 giờ sáng, hay đã từng dũng cảm chọn một giải pháp nhàm chán nhưng đúng đắn, rồi cuối cùng chứng minh là đúng. Những khả năng phán đoán này sẽ sinh lợi theo thời gian. Nhưng không còn như trước, khả năng quen thuộc với “API framework hot nhất tuần” chỉ mang tính phù phiếm. Sau sáu tháng, nó có thể đã thay đổi. Sau hai năm, người chiến thắng thực sự là những người đã chọn sớm các năng lực nền tảng bền vững, và để các nhiễu loạn trôi qua xung quanh họ.

Trong hai năm qua, tôi đã xây dựng sản phẩm trong lĩnh vực này, nhận được nhiều offer lương trên 25 nghìn USD/năm, hiện đang phụ trách kỹ thuật tại một công ty ẩn danh. Nếu ai hỏi tôi: “Hiện tại nên tập trung vào gì?” thì đây chính là nội dung tôi sẽ gửi cho họ.

Đây không phải là một lộ trình rõ ràng. Lĩnh vực Agent vẫn chưa có đích rõ ràng. Các phòng thí nghiệm lớn cũng đang mở rộng công khai, đưa các vấn đề hồi quy trực tiếp cho hàng triệu người dùng, rồi viết lại các bài phân tích, sửa lỗi trực tuyến. Nếu đội ngũ đằng sau Claude Code có thể phát hành một phiên bản gây ra 47% giảm hiệu năng, và chỉ nhận ra vấn đề sau khi cộng đồng người dùng phát hiện ra, thì ý tưởng “bản đồ ổn định nằm dưới” là hư cấu. Mọi người vẫn đang mò mẫm. Các startup có cơ hội vì các ông lớn cũng chưa biết câu trả lời. Những người không biết lập trình đang hợp tác với agent, giao những thứ mà các tiến sĩ machine learning còn cho là không thể thực hiện vào thứ Ba, rồi giao vào thứ Sáu.

Điểm thú vị nhất của thời điểm này là nó thay đổi cách chúng ta hiểu về “thâm niên”. Con đường truyền thống tối ưu hóa thâm niên: bằng cấp, vị trí cấp thấp, cao cấp, senior, và cấp bậc tích lũy chậm chạp. Điều này hợp lý khi lĩnh vực nền tảng không có biến động lớn. Nhưng giờ đây, mặt đất dưới chân chúng ta đang dịch chuyển với cùng tốc độ. Một người trẻ 22 tuổi, công bố demo agent, và một kỹ sư dày dạn 35 tuổi, không còn chỉ khác nhau về độ thành thạo kỹ năng trong mười năm nữa. Người 22 tuổi và kỹ sư dày dạn đều đối mặt với cùng một bức tranh trống. Đối với họ, thứ thực sự sinh lợi theo thời gian là khả năng liên tục giao hàng, cùng với một phần nhỏ năng lực nền tảng không bị lỗi thời trong một quý.

Đây chính là cốt lõi của toàn bài viết. Tiếp theo, tôi sẽ cung cấp một phương pháp đánh giá: những năng lực nền tảng nào đáng để bạn đầu tư, những phát hành nào có thể bỏ qua. Phù hợp thì lấy, không phù hợp thì bỏ.

Bộ lọc thực sự hiệu quả

Bạn không thể theo kịp các phát hành mới hàng tuần, và cũng không nên. Điều bạn cần không phải dòng chảy thông tin, mà là bộ lọc.

Trong 18 tháng qua, có năm câu hỏi luôn hiệu quả. Trước khi đưa một thứ mới vào hệ sinh thái của bạn, hãy dùng qua năm câu hỏi này.

Nó còn quan trọng sau hai năm không? Nếu nó chỉ là lớp vỏ bên ngoài của một mô hình tiên tiến, một tham số CLI, hoặc “phiên bản Devin nào đó”, thì câu trả lời gần như luôn là không. Nếu đó là một nguyên thủy nền tảng, như giao thức, mô hình ghi nhớ, phương pháp sandbox, thì câu trả lời có thể là có. Các lớp vỏ bên ngoài có tuổi thọ rất ngắn, còn nguyên thủy nền tảng có thể tính theo năm.

Có người bạn tôn trọng đã dựa trên nó tạo ra sản phẩm thực, và đã từng viết chia sẻ kinh nghiệm chân thực? Bài viết marketing không tính, bài phân tích mới là có giá trị. Một blog có tiêu đề “Chúng tôi đã thử X trong môi trường sản xuất, kết quả là vấn đề xảy ra” còn giá trị hơn mười bài đăng thông báo. Trong lĩnh vực này, tín hiệu thực sự hữu ích luôn đến từ những người đã bỏ ra cuối tuần để thử nghiệm.

Việc sử dụng nó có nghĩa là bạn phải bỏ đi hệ thống tracing, retry, cấu hình, xác thực hiện tại? Nếu đúng, đó là framework cố gắng biến mình thành nền tảng. Framework cố gắng thành nền tảng có tỷ lệ thất bại khoảng 90%. Nguyên thủy nền tảng tốt phải có thể tích hợp vào hệ thống hiện tại của bạn, chứ không bắt bạn phải chuyển đổi toàn bộ.

Nếu bỏ qua nó sáu tháng, thiệt hại là gì? Đối với phần lớn các phát hành, câu trả lời là không có gì. Sau sáu tháng, bạn sẽ biết nhiều hơn, và phiên bản thành công sẽ rõ ràng hơn. Câu hỏi này giúp bạn bỏ qua 90% các phát hành mà không lo lắng. Nhưng cũng là câu hỏi khiến nhiều người từ chối sử dụng nhất, vì bỏ qua một thứ khiến họ cảm thấy bị tụt hậu. Thực ra không phải vậy.

Bạn có thể đo lường xem nó có thực sự làm agent của bạn tốt hơn không? Nếu không, đó chỉ là phỏng đoán. Nhóm không có eval sẽ vận hành dựa trên cảm giác, cuối cùng dẫn đến vấn đề hồi quy trực tuyến. Nhóm có eval thì có thể để dữ liệu nói cho họ biết: trong khối lượng công việc cụ thể tuần này, GPT-5.5 tốt hơn hay Opus 4.7 tốt hơn.

Nếu bạn chỉ rút ra một thói quen từ bài viết này, đó là: mỗi khi có thứ mới ra mắt, hãy ghi lại những gì bạn cần thấy sau sáu tháng để tin rằng nó thực sự quan trọng. Rồi sau đó quay lại kiểm tra. Phần lớn câu hỏi đã tự có lời giải, và sự chú ý của bạn sẽ tập trung vào những thứ thực sự có thể sinh lợi theo thời gian.

Các thử nghiệm này ẩn chứa năng lực thực sự, khó gọi tên nhất. Đó là khả năng “không chạy theo mốt”. Framework gây bão trên Hacker News tuần này sẽ có đội nhóm hâm mộ trong mười bốn ngày, họ nghe có vẻ rất thông minh. Nhưng sau sáu tháng, một nửa framework đã không còn ai duy trì, và những người hâm mộ đó đã chuyển sang xu hướng mới. Những người không tham gia sẽ tiết kiệm thời gian, dành cho những thứ vẫn còn “nhàm chán” sau khi cơn sốt qua đi. Kiềm chế, chờ đợi, nói “sau sáu tháng tôi sẽ biết” mới là kỹ năng nghề nghiệp thực sự trong lĩnh vực này. Mọi người đều đọc các thông báo phát hành, nhưng hầu như ít ai giỏi trong việc không phản ứng lại chúng.

Nên học gì

Khái niệm, mô hình, hình dạng của các thứ. Những thứ này mang lại lợi ích sinh lợi theo thời gian thực sự. Chúng có thể vượt qua việc thay thế mô hình, framework và chuyển đổi paradigm. Hiểu sâu sắc chúng, bạn có thể làm quen với bất kỳ công cụ mới nào trong một cuối tuần. Bỏ qua chúng, bạn sẽ mãi mãi phải học lại các cơ chế bề nổi.

Kỹ thuật ngữ ngữ cảnh (Context Engineering)

Trong hai năm qua, sự thay đổi quan trọng nhất là “Prompt Engineering” đã trở thành “Context Engineering”. Thay đổi này là thật, không chỉ là đổi tên.

Mô hình không còn là thứ bạn viết một lệnh thông minh nữa. Nó trở thành thứ bạn cần phải lắp ráp ngữ cảnh phù hợp để hoạt động ở mỗi bước. Ngữ cảnh này bao gồm chỉ thị hệ thống, schema công cụ, tài liệu truy xuất, kết quả công cụ trước đó, scratchpad, và lịch sử nén lại. Hành vi của agent là kết quả của tất cả nội dung bạn đưa vào trong khung ngữ cảnh.

Bạn cần thấm nhuần điều này: ngữ cảnh chính là trạng thái. Mọi token không liên quan đều làm giảm chất lượng suy luận. Ngữ cảnh bị mục nát là một lỗi thực sự trong sản xuất. Đến bước thứ tám của một nhiệm vụ mười bước, mục tiêu ban đầu có thể đã bị lấp đầy bởi output của công cụ. Nhóm có thể xây dựng agent đáng tin cậy sẽ chủ động tóm tắt, nén, cắt giảm ngữ cảnh. Họ sẽ quản lý phiên bản mô tả công cụ, cache phần tĩnh, và từ chối cache phần thay đổi. Cách họ nhìn nhận khung ngữ cảnh giống như một kỹ sư có kinh nghiệm nhìn nhận bộ nhớ.

Cách cảm nhận cụ thể là: mở trace đầy đủ của một agent trong môi trường sản xuất. Xem ngữ cảnh ở bước đầu tiên, rồi bước thứ bảy. Đếm xem còn bao nhiêu token vẫn còn phát huy tác dụng. Lần đầu làm việc này, bạn có thể cảm thấy ngượng ngùng. Sau đó, bạn sẽ sửa nó, và cùng một agent mà không cần đổi mô hình, không cần chỉnh prompt, sẽ rõ ràng trở nên đáng tin cậy hơn.

Nếu chỉ đọc một bài liên quan, hãy đọc “Effective Context Engineering for AI Agents” của Anthropic. Rồi sau đó đọc lại bài phân tích hệ thống nghiên cứu đa agent của họ, bài viết này dùng số liệu để chứng minh tầm quan trọng của việc cô lập ngữ cảnh khi quy mô hệ thống mở rộng.

Thiết kế công cụ

Công cụ là nơi agent tiếp xúc với công việc của bạn. Mô hình sẽ dựa vào tên và mô tả công cụ để chọn lựa, dựa vào lỗi để quyết định retry. Thỏa thuận của công cụ phù hợp với cách LLM thể hiện sẽ quyết định thành công hay thất bại của mô hình.

Năm đến mười công cụ có tên rõ ràng, tốt hơn hai mươi công cụ trung bình. Tên công cụ nên như các động từ trong tiếng Anh tự nhiên. Mô tả cần rõ ràng khi nào dùng, khi nào không. Thông báo lỗi nên là phản hồi mà mô hình có thể dựa vào để hành động. “Vượt quá giới hạn 500 token, vui lòng tóm tắt rồi thử lại” tốt hơn nhiều so với “Error: 400 Bad Request”. Trong nghiên cứu công khai, có một nhóm đã báo cáo rằng chỉ cần viết lại thông báo lỗi, họ đã giảm vòng retry tới 40%.

“Writing tools for agents” của Anthropic là điểm khởi đầu tốt. Sau khi đọc xong, hãy thêm quan sát vào các công cụ của bạn, xem mô hình gọi như thế nào trong thực tế. Độ tin cậy của agent gần như luôn tăng lên khi tối ưu phần công cụ. Nhiều người cứ chỉnh prompt mãi, nhưng bỏ qua vị trí đòn bẩy thực sự.

Mô hình orchestrator-subagent

Trong năm 2024 và 2025, các tranh luận về đa agent cuối cùng đã hội tụ thành một giải pháp tổng thể mà mọi người đều đang áp dụng. Hệ thống đa agent ngây thơ, tức là nhiều agent cùng ghi vào trạng thái chung song thất bại thảm khốc vì lỗi tích tụ. Chu trình của một agent duy nhất có thể mở rộng xa hơn bạn nghĩ. Chỉ có một dạng đa agent hoạt động hiệu quả trong sản xuất: một orchestrator agent, giao nhiệm vụ hạn chế, chỉ đọc, cho các subagent cách ly, rồi tổng hợp kết quả.

Hệ thống nghiên cứu của Anthropic hoạt động theo cách này. Các subagent của Claude Code cũng vậy. Spring AI và nhiều framework sản xuất hiện nay cũng đang chuẩn hóa mô hình này. Subagent có ngữ cảnh nhỏ, tập trung, không thể sửa đổi trạng thái chung. Việc ghi dữ liệu do orchestrator đảm nhiệm.

Cognition trong “Don’t Build Multi-Agents” và Anthropic trong “How we built our multi-agent research system” có vẻ đối lập, nhưng thực ra chỉ là cách dùng từ khác để nói về cùng một vấn đề. Cả hai đều đáng đọc.

Chỉ sử dụng agent đơn. Chỉ khi agent đơn thực sự gặp giới hạn thực, mới xem xét mô hình orchestrator-subagent: ví dụ như áp lực khung ngữ cảnh, độ trễ do gọi công cụ theo thứ tự, hoặc tính đa dạng của nhiệm vụ thực sự có thể hưởng lợi từ ngữ cảnh tập trung. Trước khi cảm nhận rõ các điểm đau, đừng xây dựng hệ thống này, vì nó chỉ làm phức tạp thêm không cần thiết.

Eval và bộ dữ liệu vàng

Mỗi nhóm có thể giao agent đáng tin cậy đều có eval. Nhóm không có eval thường không thể giao agent đáng tin cậy. Đây là thói quen có ảnh hưởng lớn nhất trong lĩnh vực này, và cũng là điều tôi thấy bị đánh giá thấp nhất trong các công ty.

Cách hiệu quả là: thu thập trace trong môi trường sản xuất, đánh dấu các trường hợp thất bại, xem như bộ dữ liệu hồi quy. Mỗi khi có thất bại mới, thêm vào. Phần chủ quan dùng LLM làm judge, phần còn lại dùng so khớp chính xác hoặc kiểm tra lập trình. Trước khi cập nhật prompt, mô hình hoặc công cụ, chạy thử bộ test. Blog của Spotify Engineering báo cáo rằng, hệ thống judge của họ có thể chặn khoảng 25% output của agent trước khi ra sản phẩm. Nếu không có, cứ bốn kết quả xấu thì có một kết quả đến tay người dùng.

Ý tưởng cốt lõi để làm điều này bền vững là: eval chính là một dạng kiểm thử đơn vị, giúp đảm bảo agent không lệch khỏi nhiệm vụ khi mọi thứ liên tục thay đổi. Mô hình ra phiên bản mới, framework cập nhật thay đổi lớn, nhà cung cấp bỏ đi endpoint nào đó. Eval của bạn là thứ duy nhất có thể cho biết agent còn hoạt động đúng không. Không có eval, bạn đang xây dựng hệ thống phụ thuộc vào mục tiêu di động của đúng sai.

Các framework eval như Braintrust, Langfuse evals, LangSmith đều khá tốt. Nhưng chúng không phải là nút thắt. Thứ thực sự quyết định là bạn có bộ dữ liệu đã gắn nhãn chưa. Ngay từ ngày đầu, hãy bắt đầu làm. Trước khi mở rộng, chỉ cần 50 mẫu, một buổi chiều là xong. Không có lý do gì để không.

Xem như trạng thái là hệ thống file, và vòng lặp Think-Act-Observe

Đối với bất kỳ agent thực hiện nhiều bước nào, kiến trúc bền vững là: suy nghĩ, hành động, quan sát, lặp lại. Hệ thống file hoặc lưu trữ có cấu trúc là nguồn dữ liệu thực tế. Mỗi hành động đều được ghi lại, có thể phát lại. Claude Code, Cursor, Devin, Aider, OpenHands, goose đều hội tụ về điểm này, không phải vô cớ.

Mô hình không trạng thái. Khung chạy phải có trạng thái. Hệ thống file là nguyên thủy có trạng thái mà mọi nhà phát triển đều hiểu rõ. Khi chấp nhận khung này, toàn bộ quy tắc harness sẽ tự nhiên hình thành: checkpoint, khả năng khôi phục, xác minh sub-agent, sandbox thực thi.

Điều sâu hơn nữa là: trong bất kỳ agent sản xuất nào đáng trả tiền, công việc của harness còn nhiều hơn mô hình. Mô hình chọn bước tiếp theo, harness xác nhận, chạy trong sandbox, ghi nhận output, quyết định phản hồi, quyết định dừng, quyết định checkpoint, quyết định tạo subagent. Thay đổi mô hình thành mô hình khác cùng chất lượng, vẫn có thể tạo ra agent sản phẩm. Thay harness kém hơn, dù là mô hình tốt nhất thế giới, cũng sẽ tạo ra agent hay quên mất mình đang làm gì.

Nếu bạn xây dựng thứ phức tạp hơn một công cụ gọi đơn thuần, thì nơi bạn cần đầu tư chính là harness. Mô hình chỉ là một thành phần trong đó.

Hiểu concept MCP

Đừng chỉ học cách gọi MCP server. Hãy hiểu mô hình của nó. Nó đã thiết lập sự phân tách rõ ràng giữa khả năng của agent, công cụ và tài nguyên, đồng thời cung cấp các giải pháp mở rộng cho xác thực và truyền tải. Khi đã hiểu điều này, các “khung tích hợp agent” khác sẽ trông như phiên bản thấp của MCP, và bạn tiết kiệm thời gian đánh giá từng cái.

Linux Foundation hiện đang quản lý MCP. Tất cả các nhà cung cấp mô hình chính đều hỗ trợ nó. Hãy xem nó như “USB-C của AI”, và giờ đây đã gần như đúng hơn là châm biếm.

Sandboxing là nguyên thủy nền tảng

Mỗi agent coding sản xuất đều chạy trong sandbox. Mỗi agent trình duyệt đều từng gặp phải prompt injection gián tiếp. Mỗi agent đa thuê bao, ở một giai đoạn nào đó, đều gặp lỗi phạm vi quyền. Bạn nên xem sandbox như một nguyên thủy hạ tầng, chứ không phải tính năng chờ khách yêu cầu mới thêm vào.

Cần học các kiến thức nền: cách cô lập tiến trình, kiểm soát ra ngoài mạng, quản lý phạm vi khóa, xác thực giữa agent và công cụ. Những nhóm chỉ thêm sandbox sau khi khách hàng kiểm tra an toàn, thường sẽ mất cơ hội. Những nhóm làm từ tuần đầu tiên, sẽ dễ dàng vượt qua quy trình mua bán doanh nghiệp.

Nên xây dựng bằng gì

Dưới đây là các lựa chọn cụ thể đến tháng 4 năm 2026. Các lựa chọn này sẽ thay đổi, nhưng không quá nhanh. Ở tầng này, nên chọn “đều đều nhưng ổn định”.

Tầng điều phối (Orchestration)

LangGraph là lựa chọn mặc định trong môi trường sản xuất. Khoảng một phần ba các công ty lớn chạy agent đều dùng nó. Cách trừu tượng của nó phù hợp với hình thái hệ thống agent thực tế: trạng thái có kiểu, điều kiện biên, luồng công việc lâu dài, kiểm tra điểm có người trong vòng lặp. Nhược điểm là viết hơi dài dòng; ưu điểm là khi một agent thực sự vào môi trường sản xuất, bạn cần kiểm soát những thứ này, và độ dài dòng phù hợp với yêu cầu kiểm soát đó.

Nếu chủ yếu dùng TypeScript, Mastra là lựa chọn thực tế. Đây là giải pháp có mô hình tư duy rõ ràng nhất trong hệ sinh thái này.

Nếu nhóm bạn thích Pydantic, và muốn kiểu an toàn là ưu tiên hàng đầu, Pydantic AI là lựa chọn hợp lý cho greenfield. Phiên bản 1.0 của nó ra cuối 2025, có xu hướng rõ ràng.

Nếu là công việc native của nhà cung cấp, như sử dụng máy tính, thoại, tương tác thời gian thực, có thể dùng Claude Agent SDK hoặc OpenAI Agents SDK trong node của LangGraph. Đừng cố biến chúng thành bộ điều phối hệ thống dị thể. Chúng tối ưu cho các kịch bản riêng của mình.

Tầng giao thức (Protocol)

MCP, không gì khác.

Tích hợp công cụ của bạn thành MCP server. Việc tích hợp bên ngoài cũng dùng cùng cách này. Hiện tại, registry của MCP đã vượt qua ngưỡng quan trọng: trong hầu hết các trường hợp, đã có sẵn server để dùng, không cần tự viết. Đến 2026, còn viết thủ công các plumbing công cụ tùy chỉnh là gần như vô nghĩa.

Tầng ghi nhớ (Memory)

Chọn hệ thống ghi nhớ dựa trên mức độ tự chủ của agent, chứ không phải theo độ hot.

Mem0 phù hợp cho cá nhân hóa chat: sở thích người dùng, lịch sử nhẹ. Zep phù hợp cho hệ thống hội thoại sản xuất, đặc biệt khi trạng thái liên tục tiến hóa, cần theo dõi thực thể. Letta phù hợp cho các agent cần duy trì nhất quán trong vài ngày hoặc vài tuần làm việc. Phần lớn nhóm không cần, nhưng nhóm thực sự cần thì cần chính là nó.

Sai lầm phổ biến là: chưa có vấn đề ghi nhớ đã vội xây dựng framework ghi nhớ. Bắt đầu từ nội dung có thể chứa trong khung ngữ cảnh, rồi thêm cơ sở dữ liệu vector. Chỉ khi rõ ràng xác định được các mô hình thất bại cần giải quyết, mới thêm hệ thống ghi nhớ.

Quan sát và eval

Langfuse là lựa chọn mã nguồn mở mặc định. Nó có thể tự host, dùng giấy phép MIT, bao gồm tracing, quản lý prompt, và evals cơ bản của LLM-as-judge. Nếu đã dùng LangChain, tích hợp của LangSmith sẽ chặt chẽ hơn. Braintrust phù hợp cho các quy trình eval nghiên cứu, đặc biệt khi cần so sánh chặt chẽ. OpenLLMetry / Traceloop phù hợp cho các hệ đa ngôn ngữ cần instrumentation OpenTelemetry không phụ thuộc vendor.

Bạn cần có cả tracing và evals. Tracing trả lời câu hỏi: “agent đã làm gì?” Evals trả lời: “agent đã tốt hơn hôm qua hay tệ hơn?” Không có hai thứ này, không thể ra sản phẩm. Ngay từ đầu, hãy thiết lập chúng, chi phí thấp hơn nhiều so với làm sau khi chạy mù quáng.

Thời điểm chạy và sandbox

E2B phù hợp cho thực thi mã sandbox chung. Browserbase kết hợp Stagehand, phù hợp tự động hóa trình duyệt. Anthropic Computer Use phù hợp cho các kịch bản cần kiểm soát desktop hệ điều hành thật. Modal phù hợp cho các nhiệm vụ đột xuất ngắn hạn.

Không bao giờ chạy mã chưa sandbox hóa. Một agent bị tấn công bởi prompt injection, nếu chạy trực tiếp trong môi trường sản xuất, sẽ gây ra thảm họa mà bạn không muốn kể cho ai nghe.

Mô hình

Theo đuổi benchmark rất mệt, và phần lớn không mang lại lợi ích lớn. Thực tế đến tháng 4 năm 2026:

·Claude Opus 4.7 và Sonnet 4.6 phù hợp cho gọi công cụ đáng tin cậy, nhất quán nhiều bước, và phục hồi lỗi mượt mà. Đối với phần lớn khối lượng công việc, Sonnet là điểm cân bằng giữa chi phí và hiệu năng.

·GPT-5.4 và GPT-5.5 phù hợp cho khả năng suy luận CLI / terminal mạnh nhất, hoặc khi bạn đã sống trong hạ tầng của OpenAI.

·Gemini 2.5 và 3 phù hợp cho nhiệm vụ có khối lượng ngữ cảnh lớn, hoặc đa dạng đa phương thức.

·Khi chi phí quan trọng hơn hiệu năng tối đa, đặc biệt với nhiệm vụ rõ ràng, giới hạn, có thể xem xét DeepSeek-V3.2 hoặc Qwen 3.6.

Xem mô hình như một thành phần có thể thay thế. Nếu agent của bạn chỉ chạy trên một mô hình duy nhất, đó không phải là lợi thế cạnh tranh, mà là điểm yếu. Dùng eval để quyết định mô hình nào phù hợp để triển khai. Đánh giá lại mỗi quý, đừng đổi mỗi tuần.

Điều có thể bỏ qua

Bạn sẽ liên tục bị khuyên học, dùng các thứ sau đây. Thực ra, không cần thiết. Bỏ qua chúng có chi phí thấp, tiết kiệm thời gian lớn.

AutoGen và AG2, không dùng cho sản xuất. Framework của Microsoft đã chuyển sang cộng đồng duy trì, tốc độ phát hành chậm, cách trừu tượng không phù hợp với nhu cầu thực tế của nhóm sản xuất. Có thể làm nghiên cứu học thuật, nhưng đừng đặt cược vào đó.

CrewAI, không dùng để xây dựng hệ thống sản xuất mới. Nó phổ biến vì phù hợp làm demo. Các kỹ sư xây dựng hệ thống thực đã bắt đầu chuyển khỏi nó. Có thể dùng để prototype, nhưng đừng gắn bó lâu dài.

Microsoft Semantic Kernel, trừ khi bạn đã khóa chặt trong hệ sinh thái doanh nghiệp của Microsoft, và khách hàng của bạn cũng quan tâm. Nó không phải hướng đi của hệ sinh thái.

DSPy, trừ khi bạn chuyên tối ưu prompt programs quy mô lớn. Nó có giá trị triết lý, nhưng đối tượng rất hẹp. Không phải framework agent chung, cũng đừng chọn như framework chung.

Xây agent code-writing độc lập như một lựa chọn kiến trúc. Code-as-action là hướng nghiên cứu thú vị, nhưng chưa phải mô hình mặc định trong sản xuất. Bạn sẽ gặp nhiều vấn đề về công cụ và an toàn, đối thủ của bạn có thể không cần xử lý những thứ này.

Quảng cáo “agent tự chủ” (Autonomous agent). Đường lối của AutoGPT và BabyAGI đã chết rồi. Ngành công nghiệp cuối cùng chấp nhận “kỹ thuật agentic”: có giám sát, có giới hạn, có đánh giá. Ai còn bán “triển khai rồi không cần quản lý” của autonomous agent vào năm 2026, về bản chất đang bán thứ của năm 2023.

Cửa hàng ứng dụng agent và marketplace. Từ 2023 đã có lời hứa, nhưng chưa bao giờ thực sự thu hút doanh nghiệp. Doanh nghiệp không mua agent chung chung, hoặc mua agent theo kết quả cụ thể, hoặc tự xây dựng. Đừng dựa vào ý tưởng về app store để thiết kế kinh doanh.

Chọn lọc các nền tảng doanh nghiệp “xây dựng agent bất kỳ”. Ví dụ như Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio. Chúng có thể hữu ích sau này, nhưng hiện tại còn rối rắm, phát hành chậm, và mô hình buy-vs-build vẫn nghiêng về tự xây agent hẹp hoặc mua agent chuyên biệt. Salesforce Agentforce và ServiceNow Now Assist là ngoại lệ, vì đã tích hợp sẵn vào hệ thống workflow của bạn.

Đừng theo đuổi bảng xếp hạng SWE-bench hay OSWorld. Năm 2025, các nhà nghiên cứu của Berkeley ghi nhận rằng hầu hết benchmark công khai đều có thể bị “đánh điểm” mà không cần thực hiện nhiệm vụ thực sự. Hiện tại, các nhóm thường coi Terminal-Bench 2.0 và eval nội bộ là tín hiệu chân thực hơn. Nghi ngờ các benchmark dựa trên số liệu đơn lẻ.

Kiến trúc đa agent song song ngây thơ. Năm agent trò chuyện dựa trên bộ nhớ chung trông rất ấn tượng trong demo, nhưng khi đưa vào sản xuất sẽ sụp đổ. Nếu không thể vẽ rõ sơ đồ orchestrator-subagent trên giấy ăn, và chỉ rõ ranh giới đọc ghi, đừng triển khai.

Sản phẩm agent mới không nên dùng giá theo chỗ ngồi (per-seat SaaS). Thị trường đã chuyển sang mô hình dựa trên kết quả và sử dụng. Phí theo chỗ ngồi không chỉ làm giảm lợi nhuận, còn gửi tín hiệu rằng bạn không tin vào khả năng giao hàng của sản phẩm.

Tuần này, bạn thấy framework mới trên Hacker News. Đợi sáu tháng. Nếu sau đó vẫn còn quan trọng, bạn sẽ rõ. Nếu không, bạn đã tiết kiệm một lần chuyển đổi.

Cách tiến hành cụ thể

Nếu bạn không chỉ muốn “theo kịp agent”, mà thực sự muốn áp dụng agent, theo thứ tự sau là hợp lý. Nó có vẻ nhàm chán, nhưng rất hữu ích.

Bắt đầu với một kết quả đã quan trọng. Đừng chọn mục tiêu moonshot, đừng bắt đầu bằng một dự án “nền tảng agent” rộng lớn. Chọn một thứ liên quan đến kinh doanh của bạn, có thể đo lường được: giảm ticket dịch vụ khách hàng, tạo bản pháp lý đầu tiên, lọc inbound leads, tạo báo cáo tháng. Thành công của agent phụ thuộc vào việc nó cải thiện kết quả này. Từ ngày đầu, đó đã là mục tiêu eval của bạn.

Điều này quan trọng hơn bất kỳ bước nào khác, vì nó định hướng mọi quyết định sau đó. Có kết quả cụ thể, “chọn framework nào” không còn là vấn đề triết lý nữa, mà là chọn framework nhanh nhất để giao kết quả đó. “Chọn mô hình nào” không còn là tranh luận benchmark, mà là chọn mô hình phù hợp dựa trên eval chứng minh hiệu quả trong nhiệm vụ cụ thể này. “Chúng ta có cần ghi nhớ, subagents, harness tùy chỉnh” không còn là thí nghiệm tư duy nữa, mà chỉ thêm khi thực sự gặp các mô hình thất bại.

Bỏ qua bước này, nhóm cuối cùng thường sẽ tạo ra một nền tảng rộng, không ai cần. Nhóm chú trọng bước này thường sẽ giao agent hẹp, có thể hoàn vốn trong một quý. Và agent thực sự ra đời sẽ dạy họ nhiều hơn đọc hai năm bài báo.

Trước khi ra sản phẩm, hãy thiết lập tracing và evals. Chọn Langfuse hoặc LangSmith, kết nối chúng. Nếu cần, tạo một bộ dữ liệu vàng nhỏ. 50 mẫu đã đủ để bắt đầu. Bạn không thể cải thiện thứ không thể đo lường. Sau này, bổ sung hệ thống này, chi phí gấp mười lần so với làm ngay bây giờ.

Bắt đầu từ vòng lặp đơn agent. Chọn LangGraph hoặc Pydantic AI. Mô hình chọn Claude Sonnet 4.6 hoặc GPT-5. Cung cấp agent từ 3 đến 7 công cụ thiết kế tốt. Để nó dùng hệ thống file hoặc database làm trạng thái. Triển khai cho nhóm nhỏ, quan sát trace.

Xem agent như một sản phẩm, không chỉ là dự án. Nó sẽ thất bại theo cách bạn không lường trước, và những thất bại này chính là bản đồ đường đi của bạn. Dùng trace thực tế để xây bộ dữ liệu hồi quy. Mỗi lần thay đổi prompt, thay đổi mô hình, chỉnh sửa công cụ, đều phải qua eval trước khi deploy. Nhiều nhóm đánh giá thấp bước này, nhưng chính nó tạo nên độ tin cậy.

Chỉ khi đã “đủ khả năng” mở rộng, mới tăng độ phức tạp. Khi khung ngữ cảnh bị giới hạn, mới thêm subagents. Khi nội dung vượt quá khả năng của khung, mới thêm hệ thống ghi nhớ. Khi API nền tảng không còn đủ, mới dùng computer use hoặc browser use. Đừng làm sớm, để các mô hình thất bại kéo chúng vào.

Chọn hạ tầng đơn giản, đều đều. Công cụ dùng MCP. Sandboxing dùng E2B hoặc Browserbase. Trạng thái dùng Postgres hoặc hệ thống lưu trữ của bạn. Xác thực và quan sát theo hệ thống hiện có. Các hạ tầng đặc biệt ít khi quyết định thắng thua, chính kỷ luật mới là yếu tố quyết định.

Từ ngày đầu, theo dõi mô hình kinh tế đơn vị. Chi phí mỗi hành động, tỷ lệ cache hit, vòng retry, phân phối gọi mô hình. Trong PoC, agent có vẻ rẻ, nhưng nếu không theo dõi chi phí theo kết quả, khi mở rộng gấp trăm lần, chi phí sẽ bùng nổ. Một PoC 0.50 USD mỗi lần chạy, quy mô trung bình có thể thành 50.000 USD mỗi tháng. Nhóm không dự đoán được, sẽ gặp vấn đề tài chính không mong muốn.

Mỗi quý, đánh giá lại mô hình, chứ không phải mỗi tuần. Chọn một quý, cuối quý chạy eval suite với mô hình mới nhất. Nếu dữ liệu cho thấy cần đổi, thì đổi. Như vậy, bạn sẽ hưởng lợi từ tiến bộ của mô hình, mà không bị rối loạn mỗi lần cập nhật.

Làm thế nào để nhận biết xu hướng

Dưới đây là một số tín hiệu cụ thể, cho biết điều gì có thể là tín hiệu thật: một nhóm kỹ sư uy tín viết bài có số liệu rõ ràng, không chỉ tuyên bố có nhiều người dùng; đó là nguyên thủy nền tảng như giao thức, mô hình hoặc hạ tầng, chứ không phải lớp vỏ hoặc đóng gói; nó có thể tương tác với hệ thống của bạn đã vận hành, chứ không thay thế; pitch của nó nói về các thất bại nó giải quyết, chứ không phải khả năng mới mở ra; nó đã tồn tại đủ lâu để có thể viết blog “những chỗ chưa hiệu quả”.

Ngược lại, các tín hiệu cho thấy đó chỉ là nhiễu loạn: sau 30 ngày ra mắt vẫn chỉ có video demo, chưa có case thực; benchmark tăng vọt một cách phi lý; pitch toàn dùng “autonomous”, “agent OS” hoặc “build any agent” không giới hạn; tài liệu framework giả định bạn bỏ các hệ thống tracing, auth, config hiện tại; star tăng nhanh nhưng commits, releases, contributors không theo kịp; Twitter nhanh, GitHub chậm.

Thói quen hàng tuần hữu ích là: cuối tuần dành 30 phút xem lĩnh vực này. Đọc ba thứ: blog kỹ thuật của Anthropic, ghi chú của Simon Willison, Latent Space. Nếu tuần đó có bài phân tích, đọc thêm một hai bài nữa. Những thứ quan trọng thực sự, bạn sẽ không bỏ lỡ.

Điều cần theo dõi tiếp theo

Trong hai quý tới, những điều đáng chú ý không phải vì chúng chắc chắn thắng, mà vì câu hỏi “đây có phải tín hiệu thực” vẫn chưa rõ ràng.

Mô hình phân nhánh song song của Replit Agent 4. Đây là một trong những thử nghiệm đầu tiên nghiêm túc về “đa agent cùng làm việc song song” mà không bị vướng bởi trạng thái chung. Nếu nó có thể mở rộng quy mô, mô hình orchestrator-subagent có thể thay đổi.

Độ trưởng thành của mô hình định giá dựa trên kết quả (Outcome-based pricing). Doanh thu của Sierra và Harvey đã chứng minh mô hình này trong các lĩnh vực hẹp. Vấn đề là, liệu nó có thể mở rộng ra các lĩnh vực khác hay chỉ phù hợp với các lĩnh vực chuyên biệt.

Kỹ năng như một lớp đóng gói năng lực. Số lượng các file AGENTS.md và thư mục skills trên GitHub cho thấy một cách đóng gói năng lực agent mới đang xuất hiện. Liệu nó có thể trở thành tiêu chuẩn như MCP, để chuẩn hóa năng lực hay không, vẫn