Bản gốc tiêu đề: Những gì cần học, xây dựng và bỏ qua trong AI Agents (2026)
Tác giả gốc: Rohit
Dịch: Peggy, BlockBeats

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 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ệ 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à chạy theo framework mới nhất, mà là các năng lực nền tảng hơn: 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, 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ơ không còn là bằng chứng duy nhất. Bạn đã làm gì, đã giao nhữ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ề những gì cần học, dùng, bỏ qua trong AI Agent năm 2026, 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ì đáng để học, và liên tục tạo ra những thứ thực sự hữu ích.

Dưới đây là nguyên bản:

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 phải làm thế nào để theo kịp”, mà là: trong đó đâu là tín hiệu thật, đâu chỉ là nhiễu loạn mang vẻ 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ế. Trước đây, chúng ta được huấn luyện theo một con đường truyền thống: một hệ 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 câu lệnh prompt đúng, thẩm mỹ đủ tốt, một người có thể hoàn thành những công việc 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 kiên quyết chọn một giải pháp nhàm chán nhưng đúng đắn, rồi cuối cùng được chứng minh là đúng. Khả năng đánh giá này sẽ sinh lợi theo thời gian. Nhưng không còn như trước, là khả năng quen thuộc với “API framework hot nhất tuần” nữa. 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 ai đã chọn sớm các năng lực nền tảng bền vững, và để cho nhiễu loạn đ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 250.000 USD/năm, hiện đang phụ trách kỹ thuật tại một công ty bí mật. Nếu ai hỏi tôi: “Hiện tại nên tập trung vào gì?” thì đây chính là những gì 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 công khai thử nghiệm, đưa các vấn đề trở về cho hàng triệu người dùng, rồi viết lại, sửa lỗi trực tuyến. Nếu đội ngũ sau Claude Code có thể phát hành một phiên bản gây giảm hiệu suất 47% và chỉ nhận ra vấn đề sau khi cộng đồng phát hiện, thì ý tưởng “bản đồ ổn định phía dưới” chỉ 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 code đ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í thấp, cao, rồi cao cấp, và cấp bậc tích lũy chậm chạp. Khi lĩnh vực nền tảng không có biến động lớn, điều này hợp lý. 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 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 hệ công nghệ mười năm nữa. Người 22 tuổi đó và kỹ sư dày dạn đều đối diện với một bức tranh trống rỗng như nhau. Đối với họ, thứ thực sự sinh lợi theo thời gian là ý chí liên tục giao hàng, và một phần nhỏ các 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ộ 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ỏ qua.

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 là dòng thông tin vô tận, 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ệ công nghệ 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 nó 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ì khả năng cao là có. Các sản phẩm đóng gói chỉ tồn tại ngắn hạn, còn nguyên thủy nền tảng có thể tồn tại theo năm.

Có người bạn tôn trọng đã dựa vào nó để tạo ra sản phẩm thực, và đã viết về kinh nghiệm một cách trung thực chưa?
Bài viết marketing không tính, chỉ tính các bài review, phân tích. 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à…” có giá trị hơn mười bài thông báo chính thức. 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 đã mất một cuối tuần để thử nghiệm.

Việc áp dụng nó có nghĩa là bạn phải bỏ đi các hệ thống tracing, retry, cấu hình, xác thực hiện có không?
Nếu có, thì đó là framework cố gắng trở thành nền tảng. Framework cố gắng trở 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, phiên bản thành công 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 nhiều người vẫn từ chối, vì bỏ qua thứ gì đó 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 nó có thực sự làm agent của bạn tốt hơn không?
Nếu không, thì đó chỉ là đoán mò. Nhóm không có eval sẽ dựa vào cảm tính, cuối cùng đưa vấn đề trở lại môi trường trực tuyến. Nhóm có eval thì có thể để dữ liệu nói cho họ biết: trong 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ó câu trả lờ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 tín hiệu đằng sau các câu hỏi này thực sự là năng lực khó gọi tên nhất. Đó là khả năng “không chạy theo mốt”. Tuần này, các framework hot trên Hacker News sẽ có đội nhóm hâm mộ trong vòng mười bốn ngày, nghe có vẻ rất thông minh. Nhưng sau sáu tháng, một nửa trong số đó đã 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 giữ được “sự nhàm chán” sau khi các phát hành 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ự của lĩnh vực này. Mọi người đều đọc thông báo, nhưng í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ứ thực sự mang lại lợi nhuận theo thời gian chính là những thứ này. Chúng có thể vượt qua các thế hệ mô hình, framework và các chuyển đổi tư duy. Hiểu sâu 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ề mặt.

Kỹ thuật 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 chỉ cần viết một lệnh thông minh cho nó nữa. Nó trở thành thứ bạn cần phải lắp ghép ngữ cảnh phù hợp ở mỗi bước để nó hoạt động hiệu quả. Ngữ cảnh này gồm có 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ị nhiễu loạn là một lỗi thực sự trong sản xuất. Ở 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ị che khuất 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, rồi ngữ cảnh 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, và cùng một agent mà không cần đổi mô hình, không đổi 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 xem lại các phân tích về hệ thống nghiên cứu multi-agent của họ, bài viết dùng số liệu để chứng minh tầm quan trọng của cách 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ẽ chọn công cụ dựa trên tên và mô tả của nó, và quyết định retry dựa trên thông báo lỗi. Khả năng phù hợp của công cụ với cách thể hiện của LLM quyết định thành bại của mô hình.

Năm đến mười công cụ đặt 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ả rõ 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 “Error: 400 Bad Request”. Một nhóm nghiên cứu đã báo cáo rằng, chỉ cần viết lại thông báo lỗi, họ đã giảm 40% vòng retry.

“Writing tools for agents” của Anthropic là điểm khởi đầu tốt. Sau khi đọc, hãy thêm các quan sát về cách gọi API thực tế của bạn. Độ tin cậy của agent gần như luôn tăng lên khi tối ưu công cụ. Nhiều người cứ chỉnh prompt mà 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ề multi-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. Các hệ thống agent nhiều, đơn giản là nhiều agent cùng ghi vào trạng thái chung, sẽ thất bại thảm khốc do lỗi tích tụ. Mức mở rộng của vòng lặp single agent thường còn xa hơn bạn nghĩ. Chỉ có một dạng hệ thống multi-agent thực sự hoạt động 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 subagents 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 nhận do orchestrator đảm nhiệm.

Các bài “Don’t Build Multi-Agents” của Cognition và “How we built our multi-agent research system” của Anthropic dường như trái ngược, nhưng thực ra chỉ là cách dùng từ khác để nói cùng một chuyện. Cả hai đều đáng đọc.

Mặc định dùng một agent duy nhất. Chỉ khi agent đơn thực sự gặp giới hạn, mới xem xét dùng mô hình orchestrator-subagent: như giới hạn của 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ụ mang lại lợi ích 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 phức tạp này, vì nó chỉ mang lại sự phức tạp 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.

Thực hành hiệu quả là: thu thập trace môi trường sản xuất, đánh dấu các trường hợp thất bại, xem chúng 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 đối chiếu 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ử toàn bộ bộ test. Blog của Spotify Engineering cho biết, hệ thống judge của họ có thể chặn khoảng 25% output của agent trước khi ra mắt. Nếu không có, cứ 4 kết quả xấu thì có 1 kết quả đến tay người dùng.

Ý tưởng cốt lõi để thực sự làm cho eval trở thành thói quen là: eval như một bài kiểm tra đơn vị, để đả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ó thay đổi lớn, nhà cung cấp bỏ endpoint. Eval của bạn là thứ duy nhất có thể nói cho bạn biết agent còn hoạt động đúng không. Không có eval, bạn đang xây dựng một hệ thống phụ thuộc vào mục tiêu di động và thiện chí.

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

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

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 lưu trữ hoặc file 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ướng tới điều 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 thực sub-agent, sandbox execution.

Điều sâu hơn là: trong bất kỳ agent sản xuất nào đáng bỏ tiền ra, harness làm 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, thu output, quyết định phản hồi, quyết định dừng, checkpoint, tạo subagent. Thay mô hình bằng mô hình khác cùng chất lượng, harness tốt vẫn có thể giao hàng. Thay harness bằng cái kém hơn, dù là mô hình tốt nhất thế giới, cũng sẽ tạo ra agent dễ 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 lẻ, thì nơi bạn nên đầu tư 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ó tạo ra 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ẽ chỉ là phiên bản rút gọn của MCP, và bạn sẽ tiết kiệm thời gian đánh giá từng cái một.

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ợ. Hãy xem nó như “USB-C của AI”, giờ đây đã gần như đúng hơn là châm biếm.

Sand-boxing như một 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 về quyền hạ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 tảng: cách cô lập tiến trình, kiểm soát ra vào mạng, quản lý phạm vi khóa bí mật, xác thực giữa agent và công cụ. Những nhóm chỉ làm sau khi khách hàng kiểm tra an toàn mới bổ sung, thường sẽ mất cơ hội. Những nhóm làm từ đầu, đưa vào từ tuần đầu, sẽ dễ dàng vượt qua quy trình mua bán doanh nghiệp.

Bạn nên xây dựng gì

Dưới đây là các lựa chọn cụ thể đến tháng 4 năm 2026. Những lựa chọn này sẽ thay đổi, nhưng không quá nhanh. Ở cấp độ này, nên chọn những thứ “nhàm chán nhưng ổn định”.

Lớp điều phối

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 thực của hệ thống agent: 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 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 sản xuất, bạn cần kiểm soát những thứ này, và chính sự 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, thực sự có tiềm nă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 orchestrator đa hệ thống. Chúng tối ưu cho các kịch bản riêng của mình.

Giao thức

Chỉ có MCP.

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á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, trước khi bạn tự xây, đã có sẵn server phù hợp. Đế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.

Giao diện ghi nhớ

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 dạng chat: sở thích người dùng, lịch sử nhẹ. Zep phù hợp cho hệ thống đối thoại sản xuất, đặc biệt khi trạng thái liên tục biến đổi, 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, 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 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 một vector database. Chỉ khi rõ ràng biết 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ý phiên bản prompt, và evals cơ bản của LLM. 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 workflow 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 mắt. Ngay từ đầu, hãy thiết lập chúng, chi phí thấp hơn nhiều so với chạy ẩu rồi sửa sau.

Thời gian chạy và sandbox

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

Không bao giờ chạy mã chưa sandbox. 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

Chạy theo 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à. Với đa số workload, 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 các tác vụ đòi hỏi khả năng suy luận CLI / terminal mạnh nhất, hoặc khi bạn đã quen sống trong hạ tầng của OpenAI.

·Gemini 2.5 và 3 phù hợp cho các nhiệm vụ có độ dài ngữ cảnh cao, hoặc đ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 các nhiệm vụ rõ ràng, giới hạn, có thể xem DeepSeek-V3.2 hoặc Qwen 3.6.

Hãy 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 evals để 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 những 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ể dùng để nghiên cứu, nhưng đừng đặt niềm tin vào sản phẩm.

CrewAI, không dùng để xây dựng sản phẩm mới.
Nó xuất hiện khắp nơi vì phù hợp làm demo. Các kỹ sư xây dựng hệ thống thực sự đã bắt đầu rút khỏi. 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 Microsoft, và khách hàng của bạn cũng quan tâm.
Nó không phải là 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.
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.

Đưa agent code-writing độc lập làm 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ụ, an ninh, còn đối thủ của bạn có thể không cần xử lý.

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

Cửa hàng ứng dụng agent và marketplace.
Từ 2023 đã có người hứa hẹn, 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. Đừng dựa vào ý tưởng về app store để định hình doanh nghiệp.

Chọn các nền tảng “xây dựng agent bất kỳ” một cách cẩn trọng.
Ví dụ 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, ra mắt 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 trong hệ thống workflow của bạn.

Đừng theo dõi bảng xếp hạng SWE-bench và OSWorld.
Năm 2025, các nhà nghiên cứu Berkeley ghi nhận hầu hết benchmark công khai đều có thể bị “làm đẹp” mà không thực sự giải quyết nhiệm vụ nền. Hiện tại, các nhóm thường dựa vào Terminal-Bench 2.0 và evals nội bộ như tín hiệu chân thực hơn. Nghi ngờ các bước nhảy số trong benchmark đơ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, và không chỉ rõ ranh giới đọc ghi, đừng triển khai.

Không dùng mô hình agent mới với giá theo chỗ ngồi 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, mà còn gửi tín hiệu rằng bạn không tin sản phẩm có thể giao kết quả.

Chờ framework mới trên Hacker News tuần này.
Chờ sáu tháng. Nếu đến lúc đó 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, thứ tự sau đây là hợp lý. Nó có vẻ nhàm chán, nhưng rất hữu ích.

Bước đầu chọn một kết quả đã quan trọng. Đừng chọn mục tiêu xa vời, đừng bắt đầu bằng một dự án “nền tảng agent” toàn diệ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.

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

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

Trước khi ra mắt bất cứ thứ gì, 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, xây dựng 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ứ bạn không đo lường được. Sau này, bổ sung hệ thống này sẽ tốn gấp 10 lần so với làm ngay từ đầu.

Bắt đầu từ vòng lặp single agent. Chọn LangGraph hoặc Pydantic AI. Mô hình chọn Claude Sonnet 4.6 hoặc GPT-5. Cung cấp cho agent từ 3 đến 7 công cụ thiết kế tốt. Để agent dùng hệ thống file hoặc database làm trạng thái. Triển khai cho nhóm nhỏ dùng thử, 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 những 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 prompt, thay mô hình, thay công cụ, đều phải qua evals 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 ngữ cảnh bị giới hạn, mới dùng subagents. Khi nội dung cần vượt quá giới hạn khung, mới dùng hệ thống ghi nhớ. Khi API nền tảng chưa đủ, mới dùng computer use hoặc browser use. Đừng làm trước, để các mô hình thất bại kéo chúng vào.

Chọn hạ tầng nhàm chán. Công cụ dùng MCP. Sandbox dùng E2B hoặc Browserbase. Trạng thái dùng Postgres hoặc hệ thống dữ liệu hiện có. Xác thực và quan sát theo hệ thống hiện tại. 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 action, 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 100 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 cuộc họp CFO không mong muốn.

Mỗi quý, đánh giá lại mô hình, không phải mỗi tuần. Chốt một 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 thấy đ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 phân tích có số liệu, 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, hạ tầng, chứ không phải là lớp vỏ; nó có thể tương tác với hệ thống của bạn đã vận hành, không phải thay thế; pitch của nó nói về cách giải quyết các lỗi thất bại, chứ không phải mở ra khả năng mới; đã 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 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 quá mức hợp lý; pitch 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 có; star tăng nhanh nhưng commits, releases, contributors không theo kịp; tốc độ Twitter nhanh, nhưng GitHub không theo kịp.

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

Điều gì đáng theo dõi tiếp theo

Trong hai quý tới, 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ật” vẫn chưa rõ ràng.

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

Độ trưởng thành của mô hình giá dựa trên kết quả.
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 không, hay chỉ phù hợp với các lĩnh vực chuyên biệt.