原文标题：Những điều cần học, xây dựng và bỏ qua trong AI Agents (2026)
原文作者：Rohit
编译：Peggy，BlockBeats

Chủ biên: 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 câu hỏi 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ữ (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 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 cũng đ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 hay 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ì 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à 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 số này, đâu mới là tín hiệu thực sự, còn cái nào chỉ là nhiễu loạn mang vẻ b urgency.

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 "xuyên thủng" 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ệ 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 một leo dầ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 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 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. Những khả năng phán đoán này sẽ sinh lợi theo thời gian. Nhưng điều không còn sinh lợi như trước nữa là mức độ quen thuộc của bạn với "API framework hot nhất tuần này" trên bề mặt. 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 lời đề nghị lương trên 25 nghìn USD/năm, và 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 điều gì?" thì đó 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 liên tục cập nhật, đư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 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 chính là 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. 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 mọi người đ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 hệ công nghệ trong mười năm nữa. Cả hai đều đối mặt với một bức tranh trống rỗng. Đố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ỏ 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 với bạn 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 làm vậy. Đ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 đó", 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ì 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 trên nó tạo ra sản phẩm thực, và đã từng chia sẻ kinh nghiệm chân thực không?
Bài viết marketing không tính, mà là các bài review thực tế. 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 đă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 đã 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 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 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 xem 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à phỏng đoán. Nhóm không có eval sẽ dựa vào cảm giác để vận hành, cuối cùng đưa vấn đề hồi quy ra trực tuyến. Nhóm có eval 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 đúng hạn. Trong phần lớn các trường hợp, câu trả lời đã có sẵn, 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.

Những năng lực thực sự đằng sau các câu hỏi này còn khó gọi tên hơn bất kỳ tiêu chí nào. Đó là khả năng "không chạy theo mốt". Những framework gây sốt trên Hacker News tuần này, trong vòng mười bốn ngày sẽ có đội nhóm ủng hộ, 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 đội nhóm đó đã chuyển sang hot trend tiếp theo. 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ơn sốt qua đi. Kiềm chế, chờ đợi, và nói "sau sáu tháng tôi sẽ biết" chính 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 phát hành, nhưng hầu như không ai giỏi trong việc không phản ứng lại chúng.

Điều cần học là 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à chúng. Chúng có thể vượt qua các thế hệ mô hình, framework và paradigm mới. 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ề mặt.

Kỹ thuật Context Engineering

Trong hai năm qua, sự thay đổi quan trọng nhất là việc "Prompt Engineering" đổi tên 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 cho nó nữa. Nó trở thành thứ bạn cần ghép các ngữ cảnh phù hợp để hoạt động ở mỗi bước. 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ị mục nát 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à: lấy một agent trong môi trường sản xuất, mở toàn bộ trace log. 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 sẽ rõ ràng trở nên đáng tin cậy hơn mà không cần đổi mô hình hay prompt.

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 bài review về hệ thống nghiên cứu multi-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ẽ chọn công cụ dựa trên tên và mô tả. Nó sẽ quyết định cách retry dựa trên thông báo lỗi. Khả năng mô hình thể hiện đúng hợp đồng của công cụ quyết định thành bại của nó.

Năm đến mười công cụ đặt tên tốt, sẽ hiệu quả 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ô hình hành động dựa trên đó. "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 vòng retry tới 40%.

"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ãi, 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 đơn giản, gồm 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 agent đơn thường 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: đó là 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 chép, cập nhật do orchestrator đảm nhiệm.

Các bài viết của Cognition ("Don’t Build Multi-Agents") và của Anthropic ("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 cùng một chuyện. Cả hai đều đáng đọc.

Mặc định dùng agent đơn. Chỉ khi thực sự gặp giới hạn của agent đơn, mới xem xét mô hình orchestrator-subagent: ví dụ như áp lực 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ụ cần tập trung ngữ cảnh. 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 trong môi trường sản xuất, gắn nhãn 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 hay công cụ, chạy thử toàn bộ bộ test. Blog của Spotify 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ứ 4 kết quả xấu thì có một kết quả đến tay người dùng.

Ý tưởng giúp việc này thực sự thành công là: eval như một bài kiểm tra đơn vị, dùng để đả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 phá vỡ, nhà cung cấp bỏ endpoint, eval là thứ duy nhất giúp bạn 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 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ực tế, giới hạn lớn nhất là bạn có bộ dữ liệu đã gắn nhãn chưa. Nên bắt đầu làm ngay từ ngày đầu, trước khi mở rộng quy mô. 50 mẫu đầu, có thể tự làm thủ công trong một buổi chiều. Không có lý do gì để không.

Xây dựng hệ thống lưu trữ như trạng thái, 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 lưu trữ hoặc bộ nhớ 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 có trạng thái. Khung chạy phải có trạng thái. Hệ thống lưu trữ 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 execution.

Điều sâu hơn 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, 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 thuần, thì nơi đáng đầu tư nhấ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ó 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 xác thực và truyền tải dữ liệu. Khi đã hiểu, các "framework tích hợp agent" khác sẽ giố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ợ. Hãy xem nó như "USB-C của AI", giờ đây đã gần như đúng hơn là đùa cợt.

Sandbox là 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 có 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, xác thực giữa agent và công cụ. Những nhóm chỉ làm thêm 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ừ đầu, tích hợp ngay từ tuần đầu, sẽ dễ dàng vượt qua quy trình mua bán doanh nghiệp.

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 thực tế hệ thống agent: trạng thái có kiểu, điều kiện biên, workflow lưu trữ, kiểm tra điểm có người can thiệ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ự đi vào 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 rõ ràng nhất về mặt mô hình tư duy 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 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ư computer use, voice, 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 dạng 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 chung cách này. Hiện tại, registry của MCP đã vượt qua điểm tới hạn: 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 biến là chuyện vô nghĩa.

Giao diện bộ nhớ

Chọn hệ thống 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 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 đề về nhớ đã vội xây framework 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 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 eval nghiên cứu, đặc biệt khi cần so sánh chính xác. OpenLLMetry / Traceloop phù hợp cho hệ thống đa ngôn ngữ, cần instrumentation OpenTelemetry không thương hiệu.

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ừ ngày đầu, hãy thiết lập, 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 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 hệ điều hành thực sự. Modal phù hợp cho 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 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 benchmark mệt mỏi, và phần lớn không mang lại nhiều lợi ích. 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, đa bước, và phục hồi lỗi mượt mà. Với đa số 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ó độ 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 nhiệm vụ rõ ràng, hẹp về phạm vi, có thể xem 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 chỉ hoạt động trên một mô hình, đó không phải là lợi thế cạnh tranh, mà là dấu hiệu xấ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ý, không phả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 thực tế 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 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.

Không dùng 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, còn đối thủ của bạn có thể không cần xử lý.

Quảng cáo kiểu "Autonomous agent".
AutoGPT và BabyAGI đã chết theo hướng sản phẩm này. 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" của autonomous agent vào 2026, thực chất đang bán thứ của năm 2023.

Cửa hàng và marketplace agent.
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 để thiết kế doanh nghiệp.

Chọn doanh nghiệp platform "build any agent" theo chiều ngang 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, phát hành chậm, và mô hình "mua hay xây" vẫn nghiêng về tự xây agent hẹp hoặc mua agent theo ngành. 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 hay 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ị "đổi điểm" mà không cần thực sự giải quyết nhiệm vụ nền. Hiện tại, các nhóm thường xem các benchmark như Terminal-Bench 2.0 và evals nội bộ là tín hiệu chân thực hơn. Nghi ngờ các bước nhảy số đơ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 có vẻ ấ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à chỉ rõ ràng 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 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 không tin tưởng vào khả năng giao hàng của sản phẩm.

Chương trình tiếp theo bạn thấy trên Hacker News.
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à hiệu quả. 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 đã rõ. Đừ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" rộng lớn. Chọn một việc 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ể, "chọn framework nào" không còn là vấn đề triết lý nữa, mà là framework nào nhanh nhất để giao kết quả đó. "Chọn mô hình nào" không còn là tranh luận benchmark nữa, mà là mô hình nào phù hợp để eval chứng minh hiệu quả trong nhiệm vụ cụ thể này. "Chúng ta có cần nhớ, subagents, harness tùy chỉnh" không còn là thí nghiệm tư duy, mà chỉ thêm khi các mô hình thất bại rõ ràng.

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, không ai dùng. Nhóm coi trọng bước này sẽ giao hàng một 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 viết.

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ự xây một dataset 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 agent đơn. Chọn LangGraph hoặc Pydantic AI. Mô hình chọn Claude Sonnet 4.6 hoặc GPT-5. Cung cấp agent 3-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. Ban đầu, thử nghiệm với 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 ngờ, và những thất bại đó 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 khung ngữ cảnh bị giới hạn, mới thêm subagents. Khi nội dung cần vượt quá khung, mới dùng hệ thống nhớ. Khi API nền tảng chưa đủ, 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 nhàm chán. Dùng MCP cho công cụ. 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. Những hạ tầng kỳ quặc ít khi quyết định thắng thua, chính là kỷ luật.

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 outcome, khi mở rộng 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ể lên đến 50.000 USD mỗi tháng. Nhóm không dự đoán được, sẽ gặp vấn đề lớn với CFO.

Mỗi quý, đánh giá lại mô hình, 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 rõ ràng 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 postmortem có số liệu, chứ 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, chứ không thay thế; pitch của nó nói về cách giải quyết các thất bại, chứ không mở ra khả năng mới; đã tồn tại đủ lâu để có thể viết blog "những chỗ không 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 một cách không tự nhiên; 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; Twitter tăng tốc, 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 để đọc về 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ó postmortem, đọc thêm một hai bài nữa. Những thứ khác có thể bỏ qua. Những điều thực sự quan trọng, bạn sẽ không bỏ lỡ.

Điều cần 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ực không" 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. Câu hỏi là, nó có thể mở rộng ra các lĩnh vực khác không, hay chỉ phù hợp cho các ngành dọc.

Kỹ năng như một lớp đóng gói năng lực.
Sự gia tăng của các file như AGENTS.md