Những điều cần học, cần xây dựng và nên bỏ qua về AI Agents (2026)

Mỗi ngày lại có một framework mới, một benchmark mới, một bản phát hành "10x" mới. Câu hỏi không còn là "làm sao để theo kịp". Nó trở thành: đâu mới thực sự là tín hiệu, và đâu chỉ là nhiễu khoác lên mình lớp vỏ của sự cấp bách.

Mọi lộ trình đều trở nên lỗi thời một tháng sau khi ra mắt. Framework bạn đã làm chủ quý trước giờ đã là di sản. Benchmark bạn từng tối ưu hóa đã bị khai thác và thay thế. Chúng ta đã được định hình để đi theo một con đường truyền thống: một ngăn xếp với các chủ đề và cấp độ, một chuỗi các công việc và nhiệm kỳ, một sự leo lên chậm rãi. AI đã viết lại bức tranh đó. Bất kỳ ai có prompt phù hợp và gu thẩm mỹ phù hợp giờ đây có thể tạo ra công việc mà trước đây một kỹ sư có 2 năm kinh nghiệm phải mất một sprint mới làm được.

Chuyên môn vẫn còn quan trọng. Không gì có thể thay thế việc đã từng chứng kiến hệ thống sụp đổ, đã từng debug một lỗi rò rỉ bộ nhớ lúc 2 giờ sáng, đã từng tranh luận cho một lựa chọn nhàm chán hơn một lựa chọn thông minh và đã đúng. Loại gu thẩm mỹ đó cộng dồn theo thời gian. Điều không còn cộng dồn như trước nữa: đó là việc biết bề mặt API của framework trong tuần này. Sáu tháng sau nó sẽ khác. Những người chiến thắng trong hai năm tới đã chọn các nguyên tắc cơ bản bền vững từ sớm và để phần còn lại trôi qua.

Tôi đã dành hai năm để xây dựng trong lĩnh vực này, nhận được nhiều lời đề nghị trên 250.000 đô la, và hiện đang điều hành mảng kỹ thuật tại một công ty đang trong giai đoạn ẩn danh. Đây là những gì tôi sẽ gửi cho ai đó hỏi "thực sự tôi nên chú ý đến điều gì ngay bây giờ."

Nó không phải là một lộ trình. Lĩnh vực agent vẫn chưa có một đích đến. Các phòng thí nghiệm lớn đang lặp đi lặp lại một cách công khai, tung ra các bản hồi quy cho hàng triệu người dùng, viết các bài phân tích sự cố, vá lỗi trực tiếp. Nếu đội ngũ đứng sau Claude Code có thể tung ra một bản hồi quy hiệu suất 47% và chỉ phát hiện ra sau khi cộng đồng người dùng làm điều đó, thì ý tưởng rằng có một bản đồ ổn định bên dưới tất cả những điều này chỉ là hư cấu. Mọi người đều đang tìm ra cách. Các startup đang phát triển mạnh mẽ vì những gã khổng lồ cũng không biết. Những người không phải lập trình viên đang kết hợp với các agent và tung ra sản phẩm vào thứ Sáu mà các Tiến sĩ ML đã gọi là bất khả thi vào thứ Ba.

Điều thú vị về thời điểm này là những gì nó làm với câu hỏi về chứng chỉ. Con đường truyền thống đã tối ưu hóa bạn cho chứng chỉ: bằng cấp, vai trò junior, vai trò senior, vai trò staff, sự tích lũy chậm rãi về thứ hạng. Điều đó có ý nghĩa khi lĩnh vực bên dưới bạn không thay đổi. Lĩnh vực bây giờ thay đổi đồng đều dưới chân tất cả mọi người. Sự khác biệt giữa một người 22 tuổi tung ra các bản demo agent một cách công khai và một kỹ sư cao cấp 35 tuổi không còn là mười năm tích lũy thành thạo ngăn xếp nữa. Người 22 tuổi có cùng một bức tranh trống như người cao cấp, và thứ cộng dồn cho cả hai là sự sẵn sàng tung ra sản phẩm, cộng với một danh sách nhỏ các nguyên tắc cơ bản không trở nên lỗi thời trong một quý.

Đó là sự tái định hình mà toàn bộ bài viết này dựa trên. Những gì tiếp theo là một cách để suy nghĩ về nguyên tắc cơ bản nào đáng để bạn chú ý và bản phát hành nào nên để qua. Chọn những gì phù hợp. Bỏ qua những gì không.

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

Bạn không thể theo kịp các bản phát hành hàng tuần. Bạn không nên cố gắng. Thứ bạn cần là một bộ lọc, không phải một nguồn cấp dữ liệu.

Năm bài kiểm tra đã đứng vững trong suốt 18 tháng qua. Hãy chạy một bản phát hành qua chúng trước khi bạn để nó chạm vào ngăn xếp của mình.

Điều này có còn quan trọng sau hai năm nữa không? Nếu nó là một wrapper xung quanh một mô hình tiên tiến, một cờ CLI, hoặc "Devin nhưng cho X," câu trả lời hầu như luôn là không. Nếu nó là một nguyên tắc cơ bản (một giao thức, một mẫu bộ nhớ, một cách tiếp cận sandbox), câu trả lời thường là có. Chu kỳ sống của các wrapper rất ngắn. Chu kỳ sống của các nguyên tắc cơ bản là nhiều năm.

Có ai đó bạn tôn trọng đã xây dựng một thứ gì đó thực sự trên nó và viết về nó một cách trung thực không? Các bài đăng tiếp thị không được tính. Các bài phân tích sự cố thì có. Một blog có tiêu đề "chúng tôi đã thử X trong sản xuất và đây là những gì đã hỏng" đáng giá mười thông báo ra mắt. Tín hiệu tốt trong lĩnh vực này luôn được viết bởi một người đã mất một ngày cuối tuần vì nó.

Việc áp dụng nó có yêu cầu bạn phải vứt bỏ hệ thống theo dõi, thử lại, cấu hình, xác thực của mình không? Nếu có, nó là một framework đang cố gắng trở thành một nền tảng. Các framework-cố-gắng-trở-thành-nền-tảng có tỷ lệ tử vong 90%. Các nguyên tắc cơ bản tốt sẽ nằm gọn trong hệ thống hiện tại của bạn mà không buộc bạn phải di chuyển.

Bạn phải trả giá gì nếu bỏ qua nó trong sáu tháng? Đối với hầu hết các bản phát hành, câu trả lời là không có gì. Bạn sẽ biết nhiều hơn trong sáu tháng nữa. Phiên bản chiến thắng sẽ rõ ràng hơn. Đây là bài kiểm tra cho phép bạn bỏ qua 90% các bản phát hành mà không lo lắng, và là bài kiểm tra mà hầu hết mọi người từ chối thực hiện vì bỏ qua có cảm giác như đang tụt lại phía sau. Nó không phải vậy.

Bạn có thể đo lường liệu nó có thực sự giúp ích cho các agent của bạn không? Nếu bạn không thể, bạn đang phỏng đoán. Các đội không có eval hoạt động dựa trên cảm tính và tung ra các bản hồi quy. Các đội có eval có thể để dữ liệu cho họ biết liệu GPT-5.5 hay Opus 4.7 thắng trên khối lượng công việc cụ thể của họ trong tuần này.

Nếu bạn áp dụng một thói quen từ toàn bộ bài viết này, hãy làm điều này: khi một thứ gì đó mới ra mắt, hãy viết ra những gì bạn cần thấy trong sáu tháng để tin rằng nó quan trọng. Sau đó quay lại và kiểm tra. Hầu hết thời gian, câu hỏi sẽ tự trả lời, và bạn sẽ dành sự chú ý của mình cho những thứ cộng dồn.

Kỹ năng nền tảng của những bài kiểm tra này khó gọi tên hơn bất kỳ bài nào trong số chúng. Đó là sự sẵn sàng trở nên không ngầu về những gì bạn không chọn. Framework trở nên lan truyền trên Hacker News trong tuần này sẽ có một đội quân cổ vũ trong mười bốn ngày, và tất cả họ sẽ nghe có vẻ thông minh. Sáu tháng sau, một nửa số framework đó không còn được bảo trì và những người cổ vũ đã chuyển đi. Những người không tham gia đã tiết kiệm sự chú ý của họ cho những thứ sống sót qua bài kiểm tra của việc trở nên nhàm chán sau khi cơn sốt ra mắt qua đi. Tư thế đó, giữ lại, quan sát, nói "tôi sẽ biết trong sáu tháng nữa," là kỹ năng chuyên nghiệp thực sự của lĩnh vực này. Mọi người đều có thể đọc các bản phát hành. Hầu như không ai giỏi trong việc không phản ứng với chúng.

Những gì cần học

Các khái niệm. Các mẫu hình. Hình dạng của mọi thứ. Đây là những ý tưởng mang lại lợi nhuận cộng dồn. Chúng sống sót qua các lần thay thế mô hình, thay thế framework, thay đổi mô hình. Hiểu chúng một cách sâu sắc và bạn có thể nắm bắt bất kỳ công cụ mới nào trong một ngày cuối tuần. Bỏ qua chúng và bạn sẽ liên tục học lại các cơ chế bề mặt.

Kỹ thuật ngữ cảnh

Sự đổi tên quan trọng nhất trong hai năm qua là "kỹ thuật prompt" trở thành "kỹ thuật ngữ cảnh." Sự thay đổi là thực tế, không phải hình thức.

Mô hình không còn là thứ bạn tạo ra một hướng dẫn thông minh cho nó. Nó là thứ bạn lắp ráp một ngữ cảnh làm việc cho nó ở mọi bước. Ngữ cảnh đó là hướng dẫn hệ thống, lược đồ công cụ, tài liệu được truy xuất, đầu ra công cụ trước đó, trạng thái bảng nháp và lịch sử nén cùng một lúc. Hành vi của agent là một thuộc tính nổi lên từ những gì bạn đặt vào cửa sổ.

Hãy thấm nhuần điều này: ngữ cảnh là trạng thái. Mọi token nhiễu không liên quan đều làm giảm chất lượng suy luận của bạn. Sự mục nát ngữ cảnh là một lỗi sản xuất thực sự. Đế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ị chôn vùi dưới đầu ra công cụ. Các đội tung ra các agent đáng tin cậy chủ động tóm tắt, nén, tỉa bớt. Họ quản lý phiên bản cho các mô tả công cụ của mình. Họ lưu vào bộ nhớ đệm các phần tĩnh và từ chối lưu vào bộ nhớ đệm các phần thay đổi. Họ nghĩ về cửa sổ ngữ cảnh giống như một kỹ sư giàu kinh nghiệm nghĩ về RAM.

Một cách cụ thể để cảm nhận điều này: lấy bất kỳ agent nào đang trong sản xuất và bật ghi nhật ký theo dõi đầy đủ. Nhìn vào ngữ cảnh ở bước một. Nhìn vào ngữ cảnh ở bước bảy. Đếm xem có bao nhiêu token trong số đó vẫn còn đáng giá. Lần đầu tiên bạn làm điều này, bạn sẽ xấu hổ. Sau đó bạn sẽ đi sửa nó, và cùng một agent đó sẽ trở nên đáng tin cậy hơn đáng kể mà không có bất kỳ thay đổi nào đối với mô hình hoặc prompt.

Nếu bạn đọc một thứ về điều này, hãy đọc "Kỹ thuật ngữ cảnh hiệu quả cho các AI Agent" của Anthropic. Sau đó đọc bài phân tích sự cố nghiên cứu đa agent của họ, bài viết này đưa ra các con số về mức độ quan trọng của việc cô lập ngữ cảnh khi bạn mở rộng quy mô.

Thiết kế công cụ

Công cụ là nơi agent gặp gỡ doanh nghiệp của bạn. Mô hình chọn công cụ dựa trên tên và mô tả. Mô hình thử lại dựa trên thông báo lỗi. Mô hình thành công hay thất bại dựa trên việc hợp đồng của công cụ có phù hợp với những gì LLM giỏi thể hiện hay không.

Năm đến mười công cụ được đặt tên tốt đánh bại hai mươi công cụ tầm thường. Tên công cụ nên đọc giống như các cụm động từ tiếng Anh. Mô tả nên bao gồm khi nào sử dụng công cụ và khi nào không. Thông báo lỗi nên là phản hồi mà mô hình có thể hành động. "Đã vượt quá 500 token tối đa, hãy thử tóm tắt trước" đánh bại "Lỗi: 400 Bad Request" với một biên độ rất lớn. Một nhóm trong nghiên cứu công khai đã báo cáo giảm 40% số vòng lặp thử lại sau khi viết lại các thông báo lỗi của họ.

"Viết công cụ cho agent" của Anthropic là điểm khởi đầu phù hợp. Sau đó, hãy đo lường các công cụ của riêng bạn và xem xét các mẫu gọi thực tế. Những cải tiến lớn nhất về độ tin cậy của agent hầu như luôn đến từ phía công cụ. Mọi người cứ liên tục tinh chỉnh prompt và bỏ qua nơi mà đòn bẩy thực sự tồn tại.

Mẫu hình điều phối viên-agent phụ

Cuộc tranh luận về đa agent năm 2024 và 2025 đã kết thúc với một sự tổng hợp mà mọi người hiện đều tung ra. Các hệ thống đa agent ngây thơ, nơi nhiều agent ghi vào trạng thái dùng chung song song, thất bại thảm hại vì các lỗi cộng dồn. Các vòng lặp agent đơn lẻ mở rộng quy mô xa hơn bạn nghĩ. Có một hình dạng đa agent hoạt động trong sản xuất: một agent điều phối viên ủy thác các tác vụ chỉ đọc có phạm vi hẹp cho các agent phụ bị cô lập, sau đó tổng hợp kết quả của chúng.

Đây là cách hệ thống nghiên cứu của Anthropic hoạt động. Đây là cách các agent phụ của Claude Code hoạt động. Đây là mẫu hình mà Spring AI và hầu hết các framework sản xuất hiện đang chuẩn hóa. Các agent phụ có ngữ cảnh nhỏ, tập trung. Chúng không thể thay đổi trạng thái dùng chung. Người điều phối viên sở hữu các thao tác ghi.

Bài luận "Đừng xây dựng đa agent" của Cognition và bài viết "Cách chúng tôi xây dựng hệ thống nghiên cứu đa agent của mình" của Anthropic trông có vẻ đối lập nhưng đang nói cùng một điều bằng các từ vựng khác nhau. Hãy đọc cả hai.

Mặc định là agent đơn lẻ. Chỉ sử dụng mẫu hình điều phối viên-agent phụ khi agent đơn lẻ gặp phải một bức tường thực sự: áp lực cửa sổ ngữ cảnh, độ trễ từ các lệnh gọi công cụ tuần tự, hoặc sự không đồng nhất về nhiệm vụ thực sự được hưởng lợi từ các ngữ cảnh tập trung. Xây dựng điều này trước khi bạn cảm thấy đau đớn sẽ tạo ra sự phức tạp mà bạn không cần.

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

Mọi đội tung ra các agent đáng tin cậy đều có eval. Mọi đội không có, thì không. Đây là thói quen có đòn bẩy cao nhất trong lĩnh vực này, và nó là thứ ít được đầu tư nhất mà tôi thấy ở mọi công ty tôi đã xem xét.

Điều hiệu quả: thu thập các dấu vết sản xuất của bạn, gắn nhãn các lỗi, coi đó như một bộ hồi quy. Thêm vào đó bất cứ khi nào một lỗi mới xuất hiện. Sử dụng LLM-as-judge cho các phần chủ quan, so khớp chính xác hoặc kiểm tra theo chương trình cho phần còn lại. Chạy bộ kiểm tra trước bất kỳ thay đổi nào về prompt, mô hình hoặc công cụ. Blog kỹ thuật của Spotify báo cáo rằng lớp phán quyết của họ phủ quyết khoảng 25% đầu ra của agent trước khi chúng được tung ra. Nếu không có nó, cứ bốn kết quả xấu thì một kết quả sẽ đến tay người dùng.

Mô hình tinh thần làm cho điều này trở nên bền vững: một eval là một bài kiểm tra đơn vị giữ cho agent trung thực trong khi mọi thứ khác thay đổi bên dưới nó. Mô hình nhận được một phiên bản mới. Framework phát hành một thay đổi mang tính phá vỡ. Nhà cung cấp ngừng cung cấp một endpoint. Eval của bạn là thứ duy nhất cho bạn biết liệu agent của bạn có còn hoàn thành công việc của nó hay không. Nếu không có chúng, bạn đang viết một hệ thống mà tính đúng đắn của nó phụ thuộc vào thiện chí của một mục tiêu đang di chuyển.

Các framework eval (Braintrust, Langfuse evals, LangSmith) đều ổn. Không có cái nào là nút thắt cổ chai. Nút thắt cổ chai là có một bộ được gắn nhãn ngay từ đầu. Hãy xây dựng nó vào ngày đầu tiên, trước khi bạn mở rộng bất cứ thứ gì. Năm mươi ví dụ đầu tiên có thể được gắn nhãn thủ công trong một buổi chiều. Không có lý do gì để trì hoãn.

Hệ thống tệp như trạng thái và vòng lặp suy nghĩ-hành động-quan sát

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

Mô hình là phi trạng thái. Bộ khung phải có trạng thái. Hệ thống tệp là một nguyên tắc cơ bản có trạng thái mà mọi nhà phát triển đã hiểu. Một khi bạn chấp nhận khuôn khổ này, toàn bộ kỷ luật bộ khung (điểm kiểm tra, khả năng tiếp tục, xác minh agent phụ, thực thi trong sandbox) sẽ tự động xuất hiện từ việc thực hiện nghiêm túc mẫu hình này.

Điều sâu sắc hơn mà điều này đang dạy bạn: bộ khung đang làm nhiều việc hơn mô hình trong bất kỳ agent sản xuất nào xứng đáng với hóa đơn tính toán của nó. Mô hình chọn hành động tiếp theo. Bộ khung xác thực nó, chạy nó trong một sandbox, thu thập đầu ra, quyết định những gì để đưa trở lại, quyết định khi nào dừng lại, quyết định khi nào tạo điểm kiểm tra, quyết định khi nào tạo ra một agent phụ. Thay thế mô hình bằng một mô hình khác có chất lượng tương tự và một bộ khung tốt vẫn hoạt động. Thay thế bộ khung bằng một cái tồi tệ hơn và mô hình tốt nhất thế giới vẫn tạo ra một agent ngẫu nhiên quên mất nó đang làm gì.

Nếu bạn đang xây dựng bất cứ thứ gì phức tạp hơn một lệnh gọi công cụ đơn lẻ, bộ khung là nơi bạn nên dành thời gian của mình. Mô hình là một thành phần bên trong nó.

MCP, về mặt khái niệm

Đừng chỉ học cách gọi các máy chủ MCP. Hãy học mô hình. Một sự tách biệt rõ ràng giữa khả năng của agent, công cụ và tài nguyên, với một câu chuyện xác thực và vận chuyển có thể mở rộng bên dưới. Một khi bạn hiểu nó, mọi "framework tích hợp agent" khác bạn thấy sẽ trông giống như một phiên bản tồi tệ hơn của MCP, và bạn sẽ tiết kiệm được thời gian đánh giá từng cái.

Linux Foundation hiện đang quản lý nó. Mọi nhà cung cấp mô hình lớn đều ủng hộ nó. So sánh "USB-C của AI" chính xác hơn là mỉa mai vào lúc này.

Sandbox như một nguyên tắc cơ bản

Mọi agent viết mã trong sản xuất đều chạy trong một sandbox. Mọi agent trình duyệt đều đã từng bị tấn công bằng cách chèn prompt gián tiếp. Mọi agent đa người thuê đều đã từng có một lỗi phạm vi quyền hạn được tung ra vào một thời điểm nào đó. Hãy coi sandbox như cơ sở hạ tầng nguyên tắc cơ bản, không phải một tính năng bạn thêm vào khi khách hàng yêu cầu.

Học những điều cơ bản. Cô lập tiến trình. Kiểm soát egress mạng. Phạm vi bí mật. Ranh giới xác thực giữa agent và công cụ. Các đội gắn thứ này vào sau khi đánh giá bảo mật của khách hàng là các đội mất hợp đồng. Các đội xây dựng nó ngay từ tuần đầu tiên sẽ vượt qua quy trình mua sắm của doanh nghiệp mà không phải lo lắng.

Những gì để xây dựng cùng

Các lựa chọn cụ thể, tháng 4 năm 2026. Những thứ này sẽ thay đổi, nhưng chậm. Hãy chọn một cách nhàm chán ở đây.

Điều phối

LangGraph là mặc định sản xuất. Khoảng một phần ba các công ty lớn chạy agent sử dụng nó. Các trừu tượng phù hợp với hình dạng thực tế của các hệ thống agent: trạng thái được định kiểu, các cạnh có điều kiện, quy trình làm việc bền vững, các điểm kiểm tra có sự tham gia của con người. Nhược điểm là dài dòng. Ưu điểm là sự dài dòng phù hợp với những gì bạn thực sự cần kiểm soát khi một agent đã ở trong sản xuất.

Nếu bạn sống trong TypeScript, Mastra là lựa chọn thực tế. Mô hình tinh thần sạch nhất trong hệ sinh thái đó.

Nếu nhóm của bạn yêu thích Pydantic và muốn an toàn kiểu như một công dân hạng nhất, Pydantic AI là một lựa chọn greenfield hợp lý. Nó đạt v1.0 vào cuối năm 2025 và đà phát triển là thực tế.

Đối với công việc gốc của nhà cung cấp (sử dụng máy tính, giọng nói, thời gian thực), hãy sử dụng Claude Agent SDK hoặc OpenAI Agents SDK bên trong các nút LangGraph của bạn. Đừng cố gắng biến một trong hai thành người điều phối cấp cao nhất cho một hệ thống không đồng nhất. Chúng được tối ưu hóa cho lĩnh vực của chúng.

Lớp giao thức

MCP, dừng lại. Xây dựng các tích hợp công cụ của bạn dưới dạng máy chủ MCP. Tiêu thụ các tích hợp bên ngoài theo cùng một cách. Sổ đăng ký đã vượt qua điểm mà bạn hầu như luôn có thể tìm thấy một máy chủ trước khi bạn cần xây dựng một máy chủ. Việc đi dây các công cụ tùy chỉnh vào năm 2026 phải trả một khoản thuế chẳng vì lý do gì.

Bộ nhớ

Chọn theo mức độ tự chủ, không phải theo sự cường điệu.

Mem0 cho cá nhân hóa kiểu trò chuyện. Sở thích người dùng, lịch sử nhẹ. Zep cho các hệ thống đàm thoại sản xuất nơi trạng thái phát triển và bạn cần theo dõi thực thể. Letta khi một agent duy trì sự mạch lạc qua nhiều ngày hoặc nhiều tuần làm việc. Hầu hết các đội sẽ không cần điều này. Những đội cần, thì cần chính xác điều này.

Sai lầm là với lấy một framework bộ nhớ trước khi bạn có một vấn đề về bộ nhớ. Bắt đầu với bất cứ thứ gì cửa sổ ngữ cảnh của bạn có thể chứa cộng với một kho lưu trữ vector. Chỉ thêm một hệ thống bộ nhớ khi bạn có thể nói rõ chế độ lỗi mà nó giải quyết.

Khả năng quan sát và eval

Langfuse là mặc định OSS. Có thể tự lưu trữ, được cấp phép MIT, bao gồm theo dõi, quản lý phiên bản prompt và eval LLM-as-judge cơ bản. Nếu bạn đã là một cửa hàng LangChain, LangSmith tích hợp chặt chẽ hơn. Braintrust là lựa chọn phù hợp cho các quy trình công việc eval kiểu nghiên cứu với các so sánh chặt chẽ. OpenLLMetry / Traceloop là câu trả lời nếu bạn cần công cụ đo lường OpenTelemetry trung lập với nhà cung cấp trong một ngăn xếp đa ngôn ngữ.

Bạn muốn cả theo dõi và eval. Theo dõi trả lời "agent thực sự đã làm gì?" Eval trả lời "agent tốt hơn hay tệ hơn hôm qua?" Đừng tung ra sản phẩm mà không có cả hai. Chi phí chạy mù gấp mười lần chi phí kết nối thứ này đúng cách vào ngày đầu tiên.

Runtime và sandbox

E2B cho thực thi mã sandbox tổng quát. Browserbase (kết hợp với Stagehand) cho tự động hóa trình duyệt. Anthropic Computer Use khi bạn cần điều khiển máy tính để bàn cấp hệ điều hành thực sự. Modal cho các đợt bùng nổ ngắn hạn. Đừng bao giờ chạy thực thi mã không có sandbox. Bán kính vụ nổ của một agent bị chèn prompt duy nhất trong môi trường sản xuất của bạn là một câu chuyện bạn không muốn kể.

Mô hình

Cuộc đua benchmark thật mệt mỏi và phần lớn không hữu ích. Thực tế, vào tháng 4 năm 2026:

Claude Opus 4.7 và Sonnet 4.6 cho việc sử dụng công cụ đáng tin cậy, sự mạch lạc đa bước và phục hồi lỗi một cách duyên dáng. Sonnet là điểm ngọt ngào về chi phí-hiệu suất cho hầu hết các khối lượng công việc. GPT-5.4 và 5.5 khi bạn cần khả năng suy luận CLI/terminal mạnh nhất hoặc bạn sống trong cơ sở hạ tầng OpenAI. Gemini 2.5 và 3 cho các công việc nặng về ngữ cảnh dài hoặc đa phương thức. DeepSeek-V3.2 hoặc Qwen 3.6 khi chi phí quan trọng hơn hiệu suất cao nhất, đặc biệt là cho các nhiệm vụ hẹp được xác định rõ ràng.

Hãy coi các mô hình là có thể hoán đổi cho nhau. Nếu agent của bạn chỉ hoạt động với một mô hình, đó là một mùi, không phải một hào. Sử dụng eval để quyết định triển khai cái gì. Đánh giá lại mỗi quý, không phải mỗi tuần.

Những gì nên bỏ qua

Bạn sẽ được bảo học và xây dựng với tất cả những thứ này. Bạn không cần phải làm vậy. Chi phí bỏ qua là thấp. Thời gian tiết kiệm được là rất lớn.

AutoGen và AG2 cho sản xuất. Framework của Microsoft đã chuyển sang bảo trì cộng đồng, các bản phát hành bị đình trệ, các trừu tượng không phù hợp với những gì các đội sản xuất thực sự cần. Tốt cho khám phá học thuật. Đừng neo một sản phẩm vào nó.

CrewAI cho các bản dựng sản xuất mới. Nó có mặt ở khắp mọi nơi vì nó dễ demo. Các kỹ sư xây dựng hệ thống thực tế đã chuyển khỏi nó. Sử dụng nó cho các nguyên mẫu nếu bạn muốn. Đừng cam kết với nó.

Microsoft Semantic Kernel trừ khi bạn bị khóa trong ngăn xếp doanh nghiệp của Microsoft và người mua của bạn quan tâm rằng bạn đang ở đó. Đó không phải là nơi hệ sinh thái đang hướng tới.

DSPy trừ khi bạn đặc biệt tối ưu hóa các chương trình prompt ở quy mô lớn. Giá trị triết học, đối tượng thích hợp. Không phải là một framework agent tổng quát. Đừng chọn nó như một.

Các agent viết mã độc lập như một lựa chọn kiến trúc của bạn. Mã như hành động là nghiên cứu thú vị. Nó chưa phải là một mẫu hình mặc định sản xuất, và bạn sẽ phải chiến đấu với các trận chiến về công cụ và bảo mật mà các đối thủ cạnh tranh của bạn không có.

Các bài chào hàng "Agent tự trị." Dòng dõi AutoGPT và BabyAGI đã chết dưới dạng sản phẩm. Khuôn khổ trung thực mà ngành công nghiệp đã giải quyết là "kỹ thuật agentic": được giám sát, có ranh giới, được đánh giá. Bất kỳ ai vẫn bán các agent tự trị triển khai-và-quên vào năm 2026 đang bán cho bạn năm 2023.

Các cửa hàng ứng dụng và thị trường agent. Đã hứa hẹn từ năm 2023, chưa bao giờ đạt được sức hút doanh nghiệp. Các doanh nghiệp không mua các agent được xây dựng sẵn chung chung. Họ mua các agent theo chiều dọc gắn liền với kết quả, hoặc họ tự xây dựng. Đừng cấu trúc doanh nghiệp của bạn xung quanh một giấc mơ cửa hàng ứng dụng.

Các nền tảng agent doanh nghiệp "xây dựng bất kỳ agent nào" theo chiều ngang với tư cách là khách hàng (Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio tier). Chúng sẽ hữu ích vào một lúc nào đó. Hiện tại, chúng khó hiểu, chậm chạp trong việc tung ra sản phẩm, và phép tính mua-so với-xây dựng vẫn nghiêng về việc tự xây dựng agent hẹp hoặc mua agent theo chiều dọc. Salesforce Agentforce và ServiceNow Now Assist là những ngoại lệ vì chúng thắng bằng cách được nhúng trong các hệ thống quy trình làm việc bạn đã sử dụng.

Theo đuổi bảng xếp hạng SWE-bench và OSWorld. Các nhà nghiên cứu Berkeley đã ghi nhận trong suốt năm 2025 rằng hầu như mọi benchmark công khai đều có thể bị khai thác mà không giải quyết được nhiệm vụ cơ bản. Các đội hiện sử dụng Terminal-Bench 2.0 và eval nội bộ của riêng họ như tín hiệu thực sự. Hãy coi các bước nhảy vọt về điểm số đơn lẻ với sự hoài nghi theo mặc định.

Các kiến trúc đa agent song song ngây thơ. Năm agent trò chuyện qua bộ nhớ dùng chung trông ấn tượng trong một bản demo và sụp đổ trong sản xuất. Nếu bạn không thể vẽ một sơ đồ điều phối viên-agent phụ rõ ràng với các ranh giới đọc/ghi trên một tờ giấy ăn, đừng tung ra nó.

Định giá SaaS theo ghế cho các sản phẩm agent mới. Thị trường đã chuyển sang dựa trên kết quả và mức sử dụng. Định giá theo ghế để lại tiền trên bàn và báo hiệu cho người mua rằng bạn không tin tưởng vào sản phẩm của chính mình để mang lại kết quả.

Framework tiếp theo bạn thấy trên Hacker News trong tuần này. Hãy đợi sáu tháng. Nếu nó vẫn còn quan trọng, nó sẽ hiển nhiên. Nếu không, bạn đã tiết kiệm được một lần di chuyển.

Làm thế nào để thực sự tiến lên

Nếu bạn đang cố gắng áp dụng các agent, không chỉ theo kịp chúng, trình tự này sẽ hiệu quả. Nó nhàm chán. Nó hiệu quả.

Chọn một kết quả đã quan trọng. Không phải một cú đánh xa. Không phải một dự án "nền tảng agent" theo chiều ngang. Một thứ gì đó có thể đo lường được mà doanh nghiệp của bạn đã quan tâm. Chuyển hướng vé hỗ trợ. Soạn thảo đánh giá pháp lý sơ bộ. Đủ điều kiện cho khách hàng tiềm năng đến. Tạo báo cáo hàng tháng. Agent thành công khi kết quả đó được cải thiện. Điều này trở thành mục tiêu eval của bạn vào ngày đầu tiên.

Lý do bước này quan trọng hơn bất cứ thứ gì khác là nó ràng buộc mọi quyết định tiếp theo. Với một kết quả cụ thể, câu hỏi "framework nào" không còn là triết học nữa. Bạn chọn cái nào tung ra kết quả của bạn nhanh nhất. Câu hỏi "mô hình nào" không còn là một cuộc tranh luận về benchmark nữa. Bạn chọn cái mà eval của bạn nói là hiệu quả cho công việc cụ thể này. Câu hỏi "chúng ta có cần bộ nhớ / agent phụ / bộ khung tùy chỉnh không" không còn là một thí nghiệm tư duy nữa. Bạn chỉ thêm những gì các chế độ lỗi cụ thể của bạn yêu cầu. Các đội bỏ qua bước này kết thúc việc xây dựng các nền tảng ngang mà không ai yêu cầu. Các đội thực hiện nó một cách nghiêm túc kết thúc việc tung ra một agent hẹp duy nhất tự trả tiền cho chính nó trong một quý, và agent duy nhất được tung ra đó dạy họ nhiều hơn về lĩnh vực này so với hai năm đọc sách.

Thiết lập theo dõi và eval trước khi bạn tung ra bất cứ thứ gì. Chọn Langfuse hoặc LangSmith. Kết nối nó. Xây dựng một bộ dữ liệu vàng nhỏ bằng tay nếu bạn phải làm vậy. Năm mươi ví dụ được gắn nhãn là đủ để bắt đầu. Bạn sẽ không thể cải thiện những gì bạn không thể đo lường. Chi phí xây dựng thứ này sau này gấp khoảng 10 lần chi phí xây dựng nó ngay bây giờ.

Bắt đầu với một vòng lặp agent đơn lẻ. Chọn LangGraph hoặc Pydantic AI. Chọn Claude Sonnet 4.6 hoặc GPT-5 làm mô hình. Cung cấp cho agent ba đến bảy công cụ được thiết kế tốt. Cung cấp cho nó hệ thống tệp hoặc cơ sở dữ liệu làm trạng thái. Tung ra cho một đối tượng nhỏ. Xem các dấu vết.

Hãy coi agent như một sản phẩm, không phải một dự án. Nó sẽ thất bại theo những cách bạn không lường trước được. Những thất bại đó là lộ trình của bạn. Xây dựng bộ hồi quy từ các dấu vết sản xuất thực tế. Mọi thay đổi prompt, mọi thay thế mô hình, mọi thay đổi công cụ đều phải trải qua eval trước khi triển khai. Đây là nơi hầu hết các đội đầu tư dưới mức. Đây là nơi hầu hết độ tin cậy đến từ.

Chỉ thêm phạm vi khi bạn đã kiếm được nó. Các agent phụ xuất hiện khi ngữ cảnh là nút thắt cổ chai. Các framework bộ nhớ xuất hiện khi ngữ cảnh cửa sổ đơn lẻ không thể chứa những gì bạn cần. Sử dụng máy tính hoặc sử dụng trình duyệt xuất hiện khi các API cơ bản thực sự không có ở đó. Đừng tiền kiến trúc những thứ này. Hãy để các chế độ lỗi kéo chúng vào.

Chọn cơ sở hạ tầng nhàm chán. MCP cho các công cụ. E2B hoặc Browserbase cho các sandbox. Postgres hoặc bất kỳ kho dữ liệu nào bạn đã chạy cho trạng thái. Ngăn xếp xác thực và khả năng quan sát hiện tại của bạn. Cơ sở hạ tầng kỳ lạ hiếm khi là chiến thắng. Kỷ luật mới là.

Theo dõi kinh tế đơn vị của bạn từ ngày đầu tiên. Chi phí mỗi hành động. Tỷ lệ truy cập bộ nhớ đệm. Chi phí vòng lặp thử lại. Phân phối lệnh gọi mô hình. Agent trông rẻ trong PoC và bùng nổ ở quy mô 100x trừ khi bạn đo lường chi phí mỗi kết quả ngay từ đầu. Một PoC $0.50/lần chạy trở thành $50.000/tháng ở khối lượng vừa phải. Các đội không thấy điều đó đến sẽ có một cuộc họp với CFO mà họ không thích.

Đánh giá lại các mô hình hàng quý, không phải hàng tuần. Khóa trong một quý. Vào cuối quý, chạy bộ eval của bạn chống lại ranh giới hiện tại và chuyển đổi nếu dữ liệu nói nên chuyển đổi. Bạn có được lợi ích từ việc cải tiến mô hình mà không có sự hỗn loạn của việc theo đuổi mọi bản phát hành.

Đọc thủy triều

Các dấu hiệu cụ thể cho thấy một thứ gì đó là tín hiệu:

Một đội ngũ kỹ thuật được kính trọng viết bài phân tích sau sự cố (postmortem) với số liệu, chứ không chỉ là những tuyên bố về mức độ áp dụng. Đó là một nguyên thủy (giao thức, mẫu hình, hạ tầng), không phải một lớp bọc hay gói tổng hợp. Nó tương tác được với những thứ bạn đang chạy thay vì thay thế chúng. Lời giới thiệu mô tả một chế độ thất bại mà nó giải quyết, chứ không phải một khả năng mà nó mang lại. Nó đã tồn tại đủ lâu để có một bài blog "những gì không hiệu quả" viết về nó.

Những dấu hiệu cụ thể cho thấy đó là nhiễu:

Video demo không có case study thực tế sau ba mươi ngày. Bước nhảy vọt về benchmark quá sạch sẽ để có thật. Những lời chào mời sử dụng "tự động", "hệ điều hành agent", hoặc "xây dựng bất kỳ agent nào" mà không có giải thích. Framework mà tài liệu của nó giả định bạn sẽ vứt bỏ hệ thống tracing, auth và config hiện tại của mình. Số lượng sao tăng nhanh mà không có commit, release và contributor tăng theo. Tốc độ trên Twitter mà không có tốc độ trên GitHub.

Một thói quen hàng tuần hữu ích: dành ba mươi phút vào thứ Sáu để theo dõi lĩnh vực. Đọc ba thứ. Blog kỹ thuật của Anthropic. Ghi chú của Simon Willison. Latent Space. Lướt qua một hoặc hai bài postmortem nếu có. Bỏ qua mọi thứ khác trong tuần. Bạn sẽ biết những thứ thực sự quan trọng.

Những gì đáng để theo dõi

Những thứ đáng chú ý trong hai quý tới, không phải vì chúng chắc chắn thành công, mà vì câu hỏi "đây có phải tín hiệu không?" vẫn chưa được giải đáp hoàn toàn:

Mô hình fork song song của Replit Agent 4. Nỗ lực nghiêm túc đầu tiên về "nhiều agent làm việc song song" mà không vấp phải vấn đề trạng thái chia sẻ. Nếu nó hoạt động tốt ở quy mô lớn, mặc định về orchestrator-subagent có thể thay đổi.

Sự trưởng thành của định giá dựa trên kết quả. Quỹ đạo doanh thu của Sierra và Harvey xác nhận nó trong các ngành dọc hẹp. Câu hỏi là liệu nó có tổng quát hóa ra bên ngoài hay chỉ là mô hình dọc.

Kỹ năng như một lớp đóng gói. Sự gia tăng của AGENTS.md và các thư mục kỹ năng trên GitHub cho thấy một cách mới để đóng gói khả năng của agent. Liệu nó có chuẩn hóa giống như MCP đã làm cho công cụ hay không là câu hỏi mở.

Sự suy giảm chất lượng của Claude Code vào tháng 4 năm 2026 và bài postmortem của nó. Một agent hàng đầu trong ngành đã giảm 47% hiệu suất và bị người dùng phát hiện trước khi giám sát nội bộ kịp nhận ra. Đó là một bài học về việc thực hành đánh giá agent trong sản xuất vẫn còn non trẻ như thế nào, ngay cả ở những công ty dẫn đầu. Nếu điều này thúc đẩy đầu tư toàn ngành vào các đánh giá trực tuyến tốt hơn, thì sự điều chỉnh này là lành mạnh.

Giọng nói như bề mặt hỗ trợ mặc định. Kênh giọng nói của Sierra đã vượt qua văn bản vào cuối năm 2025. Nếu mô hình đó lặp lại ở các ngành dọc khác, các ràng buộc thiết kế (độ trễ, gián đoạn, sử dụng công cụ thời gian thực) trở thành ưu tiên hàng đầu, và nhiều kiến trúc hiện tại cần được thiết kế lại.

Khả năng agent của mô hình mở đang thu hẹp khoảng cách. DeepSeek-V3.2 với khả năng suy luận tích hợp vào sử dụng công cụ. Qwen 3.6. Bối cảnh mã nguồn mở rộng hơn. Chi phí-hiệu suất cho các tác vụ agent hẹp đang thay đổi. Mặc định đóng nguồn không phải là vĩnh viễn.

Mỗi thứ trong số này đều có câu trả lời rõ ràng cho "tôi cần thấy gì trong sáu tháng tới để tin vào nó". Đó là bài kiểm tra. Theo dõi câu trả lời, không phải các thông báo.

Cược phi truyền thống

Mọi framework bạn không áp dụng là một lần di chuyển bạn không phải thực hiện. Mọi benchmark bạn không theo đuổi là một quý tập trung bạn giữ lại. Các công ty đang chiến thắng trong chu kỳ này (Sierra, Harvey, Cursor trong lĩnh vực tương ứng của họ) đã chọn mục tiêu hẹp, xây dựng kỷ luật nhàm chán, và để nhiễu của lĩnh vực trôi qua.

Con đường truyền thống là: chọn một stack, làm chủ nó trong nhiều năm, leo lên một bậc thang. Điều đó hiệu quả khi stack ổn định trong một thập kỷ. Stack bây giờ thay đổi mỗi quý. Những người chiến thắng đã ngừng tối ưu hóa cho sự thành thạo stack và bắt đầu tối ưu hóa cho gu thẩm mỹ, nguyên thủy và tốc độ giao hàng. Họ xây dựng những thứ nhỏ một cách công khai. Họ học bằng cách giao hàng. Họ được mời vào các phòng nhờ những gì họ đã tạo ra. Chứng chỉ là sản phẩm.

Hãy ngẫm nghĩ về điều đó một chút, vì đó là điểm chính của toàn bộ bài viết này. Hầu hết chúng ta được nuôi dưỡng trong một mô hình làm việc giả định rằng thế giới đứng yên đủ lâu để chứng chỉ tích lũy. Bạn đi học. Bạn lấy bằng. Bạn leo thang. Hai năm ở đây, ba năm ở kia, và dần dần CV trở thành thứ mở ra cánh cửa. Toàn bộ cỗ máy đó giả định một ngành công nghiệp ổn định ở phía bên kia.

Không gian agent hiện tại không có phía bên kia ổn định. Các công ty bạn có thể muốn làm việc mới sáu tháng tuổi. Các framework chúng xây dựng trên đó mới mười tám tháng tuổi. Các giao thức bên dưới chúng mới hai năm tuổi. Một nửa số bài viết được trích dẫn nhiều nhất trong lĩnh vực được viết bởi những người không có mặt trong lĩnh vực ba năm trước. Không có bậc thang nào để leo vì tòa nhà liên tục thay đổi tầng. Những gì còn lại, khi bậc thang không hoạt động, là phương pháp cổ xưa hơn nhiều: tạo ra một thứ, đưa nó lên internet, để công việc giới thiệu bạn. Đó là con đường phi truyền thống vì nó bỏ qua hệ thống chứng chỉ. Nó cũng là con đường duy nhất tích lũy trong một lĩnh vực đang chuyển động.

Đây là những gì thời đại trông như thế nào từ bên trong. Ngay cả những gã khổng lồ cũng đang lặp đi lặp lại công khai, giao hàng có lỗi, viết postmortem, vá lỗi trực tiếp. Các đội giao hàng những thứ thú vị nhất trong năm nay bao gồm những người không có mặt trong lĩnh vực mười tám tháng trước. Những người không phải lập trình viên đang kết hợp với agent và giao hàng phần mềm thực sự. Các tiến sĩ đang bị vượt qua bởi những người xây dựng đã chọn đúng nguyên thủy và bắt đầu hành động. Các cánh cửa đang mở. Hầu hết mọi người vẫn đang cố gắng tìm đơn đăng ký.

Kỹ năng bạn thực sự cần phát triển ngay bây giờ không phải là "agent". Đó là kỷ luật để tìm ra công việc nào tích lũy trong một lĩnh vực mà bề mặt liên tục thay đổi. Kỹ thuật ngữ cảnh tích lũy. Thiết kế công cụ tích lũy. Mẫu hình orchestrator-subagent tích lũy. Kỷ luật đánh giá tích lũy. Tư duy khai thác tích lũy. Biết API của framework ra mắt vào thứ Ba thì không. Một khi bạn có thể phân biệt chúng, thủy triều ra mắt hàng tuần không còn là áp lực mà trở thành nhiễu bạn có thể bỏ qua.

Bạn không cần học mọi thứ. Bạn cần học những thứ tích lũy và bỏ qua những thứ không. Chọn một kết quả. Thiết lập tracing và đánh giá trước khi giao hàng. Sử dụng LangGraph hoặc tương đương của nhóm bạn. Sử dụng MCP. Sandbox runtime của bạn. Mặc định là single-agent. Thêm phạm vi khi các chế độ thất bại kéo nó vào. Đánh giá lại mô hình hàng quý. Đọc ba thứ vào thứ Sáu.

Đó là kịch bản. Phần còn lại là gu thẩm mỹ, tốc độ giao hàng và sự kiên nhẫn để không chạy theo những thứ không quan trọng. Xây dựng mọi thứ. Đưa chúng lên internet. Thời đại này thưởng cho những người tạo ra thứ hơn là những người có thể mô tả thứ. Chưa bao giờ có một khung cửa sổ tốt hơn để trở thành người tạo ra.