原文標題：Học Gì, Xây Dựng Gì và Bỏ Qúa Gì trong AI Agents (2026)
Người viết bản gốc: Rohit
Dịch thuật: Peggy, BlockBeats

Chú thích biên tập viên: Lĩnh vực AI Agent đang bước vào một giai đoạn công cụ tràn lan nhưng thiếu sự nhất quán.

Mỗi tuần đều có framework mới, mô hình mới, benchmark mới và sản phẩm mới với "hiệu suất gấp 10 lần" xuất hiện, nhưng vấn đề quan trọng thực sự không còn là "làm thế nào để bắt kịp tất cả thay đổi" mà là "những thay đổi nào xứng đáng được đầu tư".

Tác giả cho rằng, trong bối cảnh ngăn xếp công nghệ liên tục bị viết lại, những khả năng thực sự có thể tích lũy lâu dài không phải là theo đuổi framework mới nhất, mà là những khả năng ở tầng dưới hơn: kỹ thuật xây dựng ngữ cảnh, thiết kế công cụ, hệ thống đánh giá (eval), mô hình người quản trị-phụ, tư duy hộp cát và sử dụng kỹ thuật harness. Những khả năng này sẽ không trở nên lỗi thời nhanh chóng theo sự thay đổi của mô hình, mà ngược lại sẽ trở thành nền tảng để xây dựng một 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 "kinh nghiệm". Trước đây, bằng cấp, cấp bậc và số năm kinh nghiệm là bằng chứng để gia nhập ngành; nhưng trong một lĩnh vực mà ngay cả các công ty lớn cũng đang công khai thử và sai, hồ sơ không còn là tấm vé duy nhất. Điều quan trọng là bạn đã làm được điều gì, đã giao hàng gì, đang trở nên quan trọng hơn.

Do đó, bài viết không chỉ thảo luận về điều gì nên học, xây dựng và bỏ qua trong AI Agent vào năm 2026, mà còn nhấn mạnh rằng: trong thời đại ngày càng nhiều tiếng ồn, khả năng quý giá nhất là đánh giá những điều xứng đáng học và tiếp tục tạo ra những điều thực sự hữu ích.

Dưới đây là bản gốc:

Mỗi ngày lại xuất hiện một framework mới, một benchmark mới, một sản phẩm mới với "hiệu suất gấp 10 lần". Vấn đề không còn là "làm thế nào để theo kịp" mà là: trong đó thực sự là tín hiệu đáng tin cậy, và đó chỉ là tiếng ồn che đậy cảm giác khẩn cấp.

Mỗi bản đồ đường đi, chỉ một tháng sau khi công bố, có thể trở nên lỗi thời. Framework mà bạn vừa nắm vững trong quý trước giờ đây đã trở thành hiếm có. Benchmark mà bạn từng tinh chỉnh, sau khi có người cải giỏi qua, sẽ nhanh chóng bị thay thế bằng cái mới. Quá khứ, chúng ta được huấn luyện để theo một con đường truyền thống: một ngăn xếp công nghệ, tương ứng với một nhóm chủ đề và cấp độ; một chuỗi kinh nghiệm làm việc, tương ứng với số năm làm việc và chức vụ; một bước một bước leo lên. Nhưng AI đã viết bài ca này lại. Ngày nay, chỉ cần gợi ý phù hợp, đánh giá thẩm mỹ đủ tốt, một người có thể giao hàng công việc mà trước đây cần một kỹ sư có 2 năm kinh nghiệm bỏ một sprint mới xong.

Năng lực chuyên môn vẫn rất quan trọng. Không có gì có thể thay thế cho việc bạn tự mình chứng kiến hệ thống sụp đổ, khuya lắm mới sửa lỗi rò rỉ bộ nhớ, cũng không có gì có thể thay thế việc bạn từng đề cao một giải pháp tẻ nhạt nhưng đúng và cuối cùng được chứng minh là đúng. Sự suy luận như vậy sẽ tích lũy lợi nhuận. Nhưng không phải là tích lũy lợi nhuận như trước đây, mà là sự quen thuộc với "Giao diện API Framework Hot tuần này". Sau sáu tháng, nó có thể đã thay đổi. Hai năm sau, người thật sự thành công là những người sớm chọn lựa năng lực cơ bản bền vững và để những tiếng ồn khác đi qua bên cạnh mình.

Trong hai năm qua, tôi luôn xây dựng sản phẩm trong lĩnh vực này, nhận được nhiều ký ức mời với mức lương hơn 250 nghìn USD mỗi năm và hiện đang làm việc trong một công ty ẩn danh chịu trách nhiệm về công nghệ. Nếu có ai hỏi tôi: "Bây giờ tôi nên tập trung vào điều gì?", đây chính là nội dung mà tôi sẽ gửi cho họ.

Đây không phải là một bản đồ đường. Lĩnh vực Agent vẫn chưa có mục tiêu rõ ràng. Cả phòng thí nghiệm lớn đều đang tiến hành cải tiến công khai, trực tiếp đẩy vấn đề hồi phục cho hàng triệu người dùng, sau đó viết bài hồi ký, vá lỗi trực tuyến. Nếu cả nhóm đứa sau Claude Code có thể phát hành một phiên bản gây ra suy giảm hiệu suất 47%, và chỉ khi cộng đồng người dùng phát hiện ra vấn đề thì họ nhận ra vấn đề, thì khái niệm "Có một bản đồ ổn định ở dưới" là hư cấu. Tất cả mọi người vẫn đang tiếp tục thử nghiệm. Cơ hội của các startup chính là vì các ông lớn cũng không biết câu trả lời. Người không biết lập trình đang cộng tác với agent, cung cấp những thứ vào thứ Sáu mà một tiến sĩ học máy nghĩ là không thể xảy ra trong ba ngày sau đó.

Điều thú vị nhất trong thời điểm này chính là nó đã thay đổi cách chúng ta hiểu về "Sự nghiệp". Con đường truyền thống đã tối ưu hóa là Sự nghiệp: bằng cấp, công việc cấp dưới, công việc cấp cao, công việc cấp cao, và cấp độ nghề nghiệp từng chậm rãi tích lũy lên. Điều này là hợp lý khi lãnh vực cơ bản không thay đổi nhiều. Nhưng bây giờ, mặt đất dưới chân đang di chuyển cùng tốc độ đó. Sự khác biệt giữa một người trẻ 22 tuổi, đã công bố demo agent công khai và một kỹ sư cao cấp 35 tuổi, không chỉ là sự tích lũy 10 năm kinh nghiệm công nghệ. Mà cô 22 tuổi và kỹ sư cao cấp đều đang đối mặt với một bức tranh trắng. Đối với họ, điều thực sự tích lũy lợi nhuận là sự sẵn lòng liên tục cung cấp và một phần nhỏ không bao giờ lỗi thời. năng lực cơ bản trong một quý.

Đây chính là lý do cốt lõi của toàn bài bài viết. Tiếp theo, tôi sẽ cung cấp một cách tiếp cận: những năng lực cơ bản nào đáng để bạn tập trung chú ý, những phát hành nào có thể đưa bạn qua. Chọn lọc những gì phù hợp với bạn và bỏ qua những gì không phù hợp.

Bộ lọc Thực sự Hiệu quả

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

Trong vòng 18 tháng qua, đã có năm câu hỏi kiểm tra nào đó vẫn hiệu quả. Trước khi cho một cái mới nào đó vào ngăn xếp công nghệ của bạn, hãy vượt qua năm câu hỏi đó trước.

Sau hai năm, điều đó còn quan trọng không?
Nếu nó chỉ là một lớp vỏ bọc của một mô hình đang thử nghiệm, một tham số CLI, hoặc "Phiên bản X của ai đó", thì câu trả lời hầu như luôn là không. Nếu nó là một ngữ cảnh cơ bản, như một giao thức, một mẫu nhớ, hoặc một phương pháp hộp cát, thì câu trả lời có khả năng là có. Tuổi thọ của sản phẩm vỏ bọc ngắn, tuổi thọ của ngữ cảnh cơ bản có thể được tính theo năm.

Có ai đó mà bạn tôn trọng đã xây dựng một sản phẩm thực sự dựa trên nó và đã trung thực khi viết về kinh nghiệm của họ không?
Bài viết tiếp thị không tính, chỉ có bài viết phân tích kỹ lưỡng. Một bài blog có tiêu đề là "Chúng tôi đã thử nghiệm X trong môi trường sản xuất và phát hiện ra vấn đề ở đây", có giá trị hơn là mười bản công bố. Tín hiệu thực sự hữu ích trong lĩnh vực này luôn đến từ những người đã phải hy sinh một cuối tuần vì nó.

Việc áp dụng nó có đồng nghĩa với việc bạn phải bỏ hệ thống theo dõi hiện tại, cơ chế thử lại, cấu hình, hệ thống xác thực không?
Nếu có, thì nó chỉ là một framework cố gắng tự biến mình thành một nền tảng. Tỷ lệ tử vong của các framework cố gắng trở thành nền tảng là khoảng 90%. Ngữ cảnh cơ bản tốt, nên có thể tích hợp vào hệ thống hiện tại của bạn, thay vì buộc bạn phải di chuyển sang hệ thống mới.

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

Bạn có thể đo lường xem nó có thực sự làm cho agent của bạn tốt hơn không?
Nếu không thể, thì bạn chỉ đang đoán. Một nhóm không có đánh giá sẽ hoạt động dựa vào cảm giác, cuối cùng sẽ đưa vấn đề regression lên production. Một nhóm có đánh giá, sẽ cho phép dữ liệu nói lên: trong bản công việc cụ thể của tuần này, liệu GPT-5.5 hay Opus 4.7 mới tốt hơn.

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

Khả năng thực sự đằng sau những thử nghiệm này, khó gọi tên hơn bất kỳ thử nghiệm nào khác. Đó là khả năng sẵn lòng "chậm lại". Framework nổ rần trong tuần này trên Hacker News sẽ có một đội hình cổ vũ trong vòng 14 ngày, họ nghe có vẻ rất thông minh. Nhưng sau sáu tháng, một nửa các framework đã không còn ai bảo trì, và những đội cổ vũ đó đã chuyển sang xu hướng mới. Những người không tham gia, để dành sự chú ý cho những thứ vượt qua được thử nghiệm "trở nên nhàm chán" sau khi làm sao. Kỷ luật, quan sát, nói "sau sáu tháng tôi sẽ biết" mới là kỹ năng chuyên nghiệp thực sự trong lĩnh vực này. Mọi người đều đọc thông báo phát hành, nhưng gần như không ai tốt khi không phản ứng lại chúng.

Phải Học Gì

Khái niệm, mô hình, hình dạng của vật. Những thứ thực sự mang lại lợi tức kép là những thứ này. Chúng có thể vượt qua việc thay thế mô hình, thay thế khuôn khổ và chuyển đổi mô hình. Hiểu sâu về chúng, bạn có thể nhanh chóng 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.

Context Engineering

Trong hai năm qua, sự thay đổi quan trọng nhất là việc "Prompt Engineering" đã trở thành "Context Engineering". Sự thay đổi này là thực sự, không chỉ là đổi cách nói.

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

Bạn cần nắm vững điều này: Ngữ cảnh chính là trạng thái. Mỗi mã token không liên quan sẽ làm giảm chất lượng suy luận. Sự phân hủy của ngữ cảnh là một sự cố sản xuất thực sự. Ở 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 lấp bởi kết quả công cụ. Một nhóm có thể giao phó Agent đáng tin cậy sẽ tự tổng kết, nén và cắt giảm ngữ cảnh. Họ sẽ quản lý phiên bản mô tả công cụ, đệm các phần tĩnh, và từ chối đệm các phần thay đổi. Cách họ nhìn vào cửa sổ ngữ cảnh giống như một kỹ sư có kinh nghiệm nhìn vào bộ nhớ.

Một cách cụ thể để cảm nhận là: lấy một agent trong môi trường sản xuất bất kỳ, mở file nhật ký trace đầy đủ. Xem xem ngữ cảnh ở bước đầu tiên, rồi xem xem ngữ cảnh ở bước thứ bảy. Đếm xem còn bao nhiêu token vẫn còn hoạt động. Lần đầu tiên làm điều này, bạn có khả năng sẽ cảm thấy ngượng ngùng. Sau đó, bạn sẽ vá nó, và cùng một agent sẽ trở nên đáng tin cậy hơn mà không thay đổi mô hình, không thay đổi chỉ thị.

Nếu bạn chỉ đọc một bài viết liên quan, hãy đọc bài viết "Effective Context Engineering for AI Agents" của Anthropic. Sau đó, hãy đọc lại bài viết của họ về hệ thống nghiên cứu nhiều agent, bài viết đó thông qua con số đã nêu rõ tầm quan trọng của cách ly ngữ cảnh khi quy mô hệ thống mở rộng.

Thiết Kế Công Cụ

Công cụ là nơi mà Agent tương tác với doanh nghiệp của bạn. Mô hình sẽ chọn công cụ dựa trên tên và mô tả của công cụ, và sẽ quyết định làm thế nào để thử lại dựa trên thông báo lỗi. Việc hợp đồng của công cụ có phù hợp với cách biểu diễn mà LLM giỏi không, sẽ quyết định xem mô hình có thành công hay không.

Năm đến mười công cụ được đặt tên cẩn thận vượt qua hai mươi công cụ không nổi bật. Tên công cụ nên giống như cụm động từ trong tiếng Anh tự nhiên. Mô tả nên rõ ràng về khi nào nên sử dụng và khi nào không nên sử dụng. Thông báo lỗi nên là phản hồi mà mô hình có thể hành động dựa vào. "Vượt quá giới hạn 500 token, vui lòng tổng hợp trước khi thử lại" tốt hơn hẳn so với "Lỗi: Yêu Cầu Xấu 400". Trong một nghiên cứu công khai, một nhóm báo cáo rằng chỉ cần viết lại thông báo lỗi đã giảm 40% vòng lặp thử lại.

Sách về công cụ cho điều phối của Anthropic là một điểm khởi đầu tốt. Sau khi đọc xong, hãy quan sát các công cụ của bạn để xem mẫu gọi thực tế. Sự cải thiện độ tin cậy của Agent thường xảy ra ở phần công cụ. Nhiều người liên tục điều chỉnh prompt, nhưng bỏ qua vị trí đòn bẩy thực sự.

Mô Hình Điều Phối-Phụ Đại Sử

Cuộc tranh cãi về nhiều Agent vào năm 2024 và 2025 cuối cùng đã hội tụ thành một giải pháp toàn diện mà mọi người đều đang áp dụng ngày nay. Hệ thống nhiều Agent ngây thơ, nghĩa là nhiều Agent ghi đồng thời vào trạng thái chia sẻ, sẽ gặp sự cố nghiêm trọng do lỗi liên tục. Khả năng mở rộng của chu kỳ đơn Agent thường lớn hơn so với bạn tưởng. Hình dạng nhiều Agent thực sự có thể hoạt động trong môi trường sản xuất chỉ có một loại: một Agent điều phối, giao các nhiệm vụ hẹp, chỉ đọc cho Phụ Đại Sử cô lập, sau đó tổng hợp kết quả của họ.

Hệ thống nghiên cứu của Anthropic hoạt động như vậy. Phụ Đại Sử của Claude Code cũng hoạt động như vậy. Spring AI và hầu hết các framework sản xuất hiện nay cũng đang tiêu chuẩn hóa mô hình này. Phụ Đại Sử có ngữ cảnh nhỏ và tập trung, không thể sửa đổi trạng thái chia sẻ. Việc ghi được quản lý bởi điều phối.

Sách "Đừng Xây Dựng Nhiều Agent" của Cognition và "Cách chúng tôi xây dựng hệ thống nghiên cứu nhiều Agent của chúng tôi" của Anthropic dường như là hai quan điểm đối lập, nhưng thực tế chỉ là cách diễn đạt khác nhau về cùng một vấn đề. Cả hai bài đều đáng đọc.

Sử dụng mặc định Một Agent. Chỉ khi Một Agent đúng sự giới hạn thực sự, hãy xem xét Điều Phối-Phụ Đại Sử: ví dụ, áp lực cửa sổ ngữ cảnh, độ trễ do gọi công cụ theo thứ tự, hoặc tính không đồng nhất của nhiệm vụ thực sự có thể hưởng lợi từ ngữ cảnh tập trung. Xây dựng hệ thống này trước khi cảm nhận được điểm đau, sẽ chỉ tạo ra sự phức tạp mà bạn không cần.

Evals và Bộ dữ liệu Vàng

Mỗi nhóm có thể cung cấp một agent đáng tin cậy đều có eval. Những nhóm thiếu eval thường cũng không thể cung cấp được agent đáng tin cậy. Đây chính là thói quen có đòn bẩy cao nhất trong lĩnh vực này, cũng là điều tôi thấy bị đánh giá thấp nhất ở mỗi công ty.

Cách thực hiện hiệu quả là: thu thập dấu vết môi trường sản xuất, gắn nhãn các trường hợp thất bại, xem chúng như tập hợp regression tests. Mỗi khi có trường hợp mới thất bại được triển khai, hãy thêm nó vào tập hợp đó. Phần chủ quan sử dụng LLM như một trọng tài, phần còn lại sử dụng khớp chính xác hoặc kiểm tra theo chương trình. Trước mỗi thay đổi ở prompt, mô hình hoặc công cụ, chạy một lượt bài kiểm tra. Bài viết trên blog kỹ thuật của Spotify cho biết, tầng trọng tài của họ thường ngăn chặn khoảng 25% đầu ra agent trước khi đi vào sản xuất. Nếu không có nó, mỗi bốn kết quả xấu sẽ có một kết quả đến với người dùng.

Mô hình tâm lí thực sự định hướng điều này là: eval chính là một bài kiểm tra đơn vị, giúp đảm bảo agent không trệch khỏi trách nhiệm khi mọi thứ khác đều liên tục thay đổi. Mô hình sẽ có phiên bản mới, framework sẽ phát hành thay đổi gây chấn động, nhà cung cấp sẽ ngưng hỗ trợ một điểm cuối nào đó. Eval của bạn là thứ duy nhất có thể cho bạn biết liệu agent có vẫn đang hoạt động bình thường hay không. Thiếu eval, bạn đang tạo ra một hệ thống mà tính chính xác phụ thuộc vào mục tiêu chuyển động của hiếu tâm.

Các framework Eval như Braintrust, Langfuse evals, LangSmith, đều tốt nhưng chúng không phải là rào cản. Rào cản thực sự, là việc bạn đã có bộ dữ liệu được gắn nhãn hay chưa. Bạn nên bắt đầu ngay từ ngày đầu tiên, trước khi mở rộng bất kỳ điều gì. 50 mẫu ban đầu, bạn có thể gắn nhãn thủ công trong một buổi chiều. Không có lý do nào để không làm.

Đối Xử Hệ Thống Tệp Như Trạng Thái, và Chu trình Think-Act-Observe

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

Chính bản thân mô hình không có trạng thái. Framework chạy phải có trạng thái. Hệ thống tệp là một nguyên lý cơ bản với trạng thái mà mỗi nhà phát triển đều hiểu. Một khi chấp nhận mô hình này, toàn bộ bộ đồng hồ harness sẽ tự nhiên mở rộng: checkpoint, khả năng phục hồi, xác nhận sub-agent, thực thi sandbox.

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

Nếu cái bạn xây dựng phức tạp hơn một lệnh gọi công cụ một lần, thì nơi thực sự bạn nên dành thời gian là harness. Mô hình chỉ là một phần của nó.

Hiểu MCP một cách Khái Niệm

Đừng chỉ học cách gọi máy chủ MCP. Hãy học 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 và cung cấp một giải pháp phân phối có thể mở rộng ở cấp độ thấp. Một khi bạn hiểu điều này, những "khung tích hợp agent" khác mà bạn thấy sẽ trông như phiên bản giảm cấp của MCP, và bạn cũng sẽ tiết kiệm thời gian phải đánh giá từng cái.

Linux Foundation hiện đang chịu trách nhiệm tổ chức MCP. Tất cả các nhà cung cấp mô hình lớn đều hỗ trợ nó. Hãy coi đó là "USB-C của AI", hiện nay nó đã gần với sự thật hơn cả sự châm biếm.

Sandboxing là Một Ngôn Ngữ Cơ Bản

Mỗi agent mã sản xuất chạy trong hộp cát. Mỗi agent trình duyệt đã gặp phải tiêm lời nhỏ giọt gián tiếp. Mỗi agent đa người thuê bao, ở một giai đoạn nào đó đã gặp lỗi quyền phạm vi. Bạn nên coi việc đặt vào hộp cát như một ngôn ngữ lập trình cơ bản, chứ không phải là tính năng được thêm vào sau khi khách hàng yêu cầu.

Để học kiến thức cơ bản: Tách quy trình, kiểm soát đầu ra mạng, quản lý phạm vi khóa, ranh giới xác thực giữa agent và công cụ. Các nhóm chỉ sau đó mới điều chỉnh bảo mật theo yêu cầu từ khách hàng thường mất giao dịch. Các nhóm đã tích hợp nó từ tuần đầu tiên sẽ dễ dàng vượt qua quy trình mua hàng doanh nghiệp.

Phải Dùng Cái Gì để Xây Dựng

Dưới đây là lựa chọn cụ thể tính đến tháng 4 năm 2026. Các lựa chọn sẽ thay đổi, nhưng không quá nhanh chóng. Tại cấp độ này, hãy chọn những thứ "nhạt nhẽo nhưng ổn định".

Kiến trúc Tổ chức

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 sử dụng agent đều đang sử dụng nó. Cách tiếp cận trừu tượng của nó phù hợp với hình dạng thực tế của hệ thống agent: trạng thái có kiểu, cạnh điều kiện, quy trình làm việc bền vững, và điểm kiểm tra human-in-the-loop. Nhược điểm là cách viết phức tạp; ưu điểm là khi một agent thực sự vào môi trường sản xuất, bạn thực sự cần kiểm soát những thứ này, và sự phức tạp của nó chính xác tương ứng với nhu cầu kiểm soát đó.

Nếu bạn chủ yếu sử dụng TypeScript, Mastra thực sự là lựa chọn. Đó là giải pháp có mô hình tư duy rõ ràng nhất trong cộng đồng.

Nếu nhóm của bạn thích Pydantic, và muốn đưa tính an toàn kiểu vào vị trí quan trọng, Pydantic AI là một lựa chọn greenfield hợp lý. Nó đã phát hành phiên bản 1.0 vào cuối năm 2025, và có sự bứt phá thực sự.

Nếu đó là công việc native của nhà cung cấp, chẳng hạn như sử dụng máy tính, âm thanh, tương tác trực tiếp, bạn có thể sử dụng SDK Agent Claude hoặc SDK Agent OpenAI trong nút LangGraph. Đừng cố gắng biến chúng thành bộ sắp xếp cấp cao của hệ thống dị nhân. Chúng được tối ưu hóa cho các tình huống mà mỗi cái sở trưng của chúng.

Tầng Giao thức

MCP, không có gì khác.

Hãy tạo máy chủ MCP từ bộ công cụ tích hợp của bạn. Tích hợp bên ngoài cũng sử dụng cùng cách này. Hiện MCP registry đã vượt quá điểm bão hòa: hầu hết các trường hợp, trước khi bạn cần phải xây dựng từ đầu, bạn đã có thể tìm thấy một máy chủ sẵn có. Việc viết mã tường minh cho công cụ tùy chỉnh của riêng mình vào năm 2026 cơ bản là việc trả thuế trắng.

Tầng Kiến thức

Khi chọn hệ thống kiến thức, đừng chọn theo độ hot mà hãy chọn theo mức độ tự chủ của agent.

Mem0 phù hợp cho cá nhân hóa theo kiểu trò chuyện: sở thích của người dùng, lịch sử nhẹ. Zep phù hợp cho hệ thống trò chuyện sản xuất, đặc biệt là các tình huống mà trạng thái sẽ tiếp tục tiến hóa, cần theo dõi thực thể. Letta phù hợp cho những agent cần duy trì tính nhất quán trong vài ngày hoặc thậm chí vài tuần. Đa số các nhóm không cần điều này; nhưng những nhóm thực sự cần, chính là những gì họ cần.

Một sai lầm phổ biến là: chưa gặp vấn đề về kiến thức mà đã triển khai hệ thống kiến thức trước. Bắt đầu bằng cách dùng một cơ sở dữ liệu vector hoặc thông tin cơ bản có thể chứa trong cửa sổ ngữ cảnh. Chỉ khi bạn có thể rõ ràng nêu rõ mẫu thất bại mà nó sẽ giải quyết, hãy thêm hệ thống kiến thức vào đó.

Khả năng Quan sát và evals

Langfuse là lựa chọn mặc định mã nguồn mở. Nó có thể tự lưu trữ, được cấp phép MIT, bao gồm theo dõi (tracing), quản lý phiên bản nhanh chóng, và evals cơ bản như trọng tài LLM. Nếu bạn đã là người dùng LangChain, tích hợp LangSmith sẽ gần gũi hơn. Braintrust phù hợp với quy trình công việc đánh giá học thuật (eval) đặc biệt trong các tình huống cần so sánh cẩn thận. OpenLLMetry / Traceloop thì phù hợp cho các công nghệ đa ngôn ngữ cần phải có sự đo lường độc lập với nhà cung cấp bằng cách cài đặt OpenTelemetry.

Bạn cần phải có cả tracing và evals. Tracing trả lời câu hỏi: "Agent đã làm gì?" Evals trả lời câu hỏi: "Agent đã cải thiện từ hôm qua, hay đã tồi tệ hơn?" Nếu không có cả hai, không nên triển khai. Hãy tích hợp ngay từ ngày đầu tiên, chi phí sẽ thấp hơn nhiều so với việc sửa sau khi triển khai mò lên.

Thời gian Chạy và Hộp Cát

E2B phù hợp cho việc thực thi mã chung trong hộp cát. Browserbase kết hợp với Stagehand, phù hợp cho tự động hóa trình duyệt. Anthropic Computer Use thì phù hợp cho các tình huống cần đối phó với vấn đề điều khiển máy tính cá nhân cấp hệ điều hành thực sự. Modal thì phù hợp cho các nhiệm vụ ngắn hạn đột xuất.

Không bao giờ chạy mã không được đặt trong hộp cát. Một agent bị xâm nhập thông qua tiêm prompt, nếu chạy trực tiếp trong môi trường sản xuất, bán kính vụ nổ của nó sẽ trở thành một câu chuyện mà bạn không bao giờ muốn kể cho người khác nghe.

Mô Hình

Theo dõi benchmark là công việc mệt mỏi, và hầu hết thời gian không đem lại lợi ích lớn. Hãy nhìn vào thực tế, tính đến tháng 4 năm 2026:

·Claude Opus 4.7 và Sonnet 4.6 phù hợp cho cuộc gọi công cụ đáng tin cậy, tính nhất quán qua nhiều bước, và khôi phục lỗi duyên dáng. Với hầu hết các công việc, Sonnet là sự kết hợp hoàn hảo giữa chi phí và hiệu suất.

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

·Gemini 2.5 và 3 phù hợp cho công việc tập trung vào ngữ cảnh dài hạn hoặc nhiệm vụ tập trung đa dạng.

·Khi chi phí quan trọng hơn hiệu suất cấp cao, đặc biệt khi xử lý các nhiệm vụ có ranh giới rõ ràng, xác định hẹp, bạn có thể xem xét DeepSeek-V3.2 hoặc Qwen 3.6.

Hãy coi mô hình là một thành phần có thể thay thế. Nếu agent của bạn chỉ hoạt động trên một mô hình cụ thể, đó không phải là một bức tường vững chắc, mà là một dấu hiệu xấu. Sử dụng các bài đánh giá để quyết định triển khai mô hình gì. Đánh giá lại mỗi quý, đừng nên thay đổi hàng tuần.

Những thứ có thể bỏ qua

Bạn sẽ liên tục được khuyên học và sử dụng những thứ dưới đây. Trên thực tế, không cần thiết. Việc bỏ qua chúng không tốn kém, nhưng sẽ tiết kiệm rất nhiều thời gian.

AutoGen và AG2, không nên sử dụng trong môi trường sản xuất.
Khung của Microsoft đã chuyển hướng sang bảo trì cộng đồng, tần suất phát hành gián đoạn, và cách trừu tượng không phù hợp với hình thái thực sự cần thiết của đội ngũ sản xuất. Có thể sử dụng cho mục đích khám phá học thuật, nhưng không nên đặt cược sản phẩm vào đó.

CrewAI, không nên sử dụng cho các dự án sản xuất mới.
Nó xuất hiện ở khắp nơi vì rất phù hợp với việc trình diễn. Những kỹ sư xây dựng hệ thống thực sự đã chuyển sang công nghệ khác. Bạn có thể sử dụng nó để tạo nguyên mẫu, nhưng đừng ràng buộc lâu dài.

Microsoft Semantic Kernel, trừ khi bạn đã sâu kết hợp với Microsoft Enterprise Tech Stack và người mua của bạn quan tâm điều này.
Không phải là hướng mà hệ sinh thái đang phát triển.

DSPy, trừ khi bạn đặc biệt chuyên sâu trong việc tối ưu hóa chương trình prompt quy mô lớn.
Nó có giá trị triết học, nhưng đối tượng mục tiêu hẹp. Nó không phải là một khung agent thông dụng, và đừng xem nó như một khung thông dụng để lựa chọn.

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

Quảng cáo theo kiểu "Autonomous agent".
Tuyến sản phẩm như AutoGPT và BabyAGI đã chết. Cách diễn ra chính trị cuối cùng mà ngành công nhận là "agentic engineering": có giám sát, có ranh giới, có đánh giá. Những người vẫn còn bán agent tự động hóa mà bạn không cần quan tâm sau khi triển khai từ năm 2026, về bản chất đều đang bán cái của năm 2023.

Cửa hàng ứng dụng và marketplace cho agent.
Từ năm 2023, đã có người hứa điều này, nhưng chưa bao giờ thực sự thu hút sự quan tâm của doanh nghiệp. Doanh nghiệp sẽ không mua agent đã được xây sẵn chung. Họ sẽ mua agent dọc theo kết quả cụ thể hoặc tự xây dựng. Đừng thiết kế kinh doanh của bạn xung quanh ước mơ về một cửa hàng ứng dụng.

Là khách hàng, hãy cẩn thận khi chọn một nền tảng doanh nghiệp ngang hàng "xây dựng bất kỳ agent nào".
Ví dụ như Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio và những cái khác. Chúng có thể hữu ích trong tương lai, nhưng hiện tại vẫn hỗn loạn, phát hành chậm, và quyết định mua hay xây dựng thường khuynh hướng về việc: tự xây dựng một agent hẹp hoặc mua một agent dọc. Salesforce Agentforce và ServiceNow Now Assist là ngoại lệ, vì họ đã tích hợp sẵn vào hệ thống lưu thông bạn đang sử dụng.

Đừng theo đuổi bảng xếp hạng SWE-bench và OSWorld.
Các nhà nghiên cứu từ Berkeley đã ghi chép vào năm 2025 rằng gần như mọi benchmark công khai đều có thể bị làm mờ, mà không cần phải giải quyết thực sự công việc cơ bản. Hiện tại, nhóm sẽ coi Terminal-Bench 2.0 và bản đánh giá nội bộ của mình là tín hiệu thực sự hơn. Hãy luôn nghi ngờ về sự nhảy vọt của một con số đơn trong benchmark.

Đừng mơ hồ với kiến trúc nhiều agent song song.
Năm agent xung quanh một cuộc trò chuyện bộ nhớ chia sẻ, trong bản demo trông rất ấn tượng, nhưng khi đưa vào môi trường sản xuất, nó sẽ sụp đổ. Nếu bạn không thể vẽ ra được một biểu đồ orchestrator-subagent rõ ràng trên một tờ giấy ăn, và chỉ rõ biên giới đọc và ghi, thì đừng triển khai lên production.

Không nên sử dụng giá cố định theo số người dùng cho sản phẩm agent mới.
Thị trường đã chuyển sang dựa vào kết quả và sử dụng dựa trên. Thu phí theo người dùng không chỉ làm cho bạn kiếm ít hơn, mà còn cho người mua một tín hiệu: bạn thậm chí không tin vào việc sản phẩm có thể giao hàng kết quả.

Cái khung công việc tiếp theo mà bạn thấy trên Hacker News trong tuần này.
Chờ thêm sáu tháng. Nếu đến lúc đó nó vẫn quan trọng, bạn sẽ rõ ràng thấy được. Nếu không quan trọng, bạn đã tiết kiệm được một lần di dời.

Cách tiếp cận 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ì thứ tự sau đây là hiệu quả. Nó tẻ nhạt, nhưng hữu ích.

Trước tiên, chọn một kết quả đã quan trọng từ trước. Đừng chọn những mục tiêu phi thực tế, đừng bắt đầu dự án toàn cầu về nền tảng "agent" ngay từ đầu. Hãy chọn một điều mà doanh nghiệp của bạn đã quan tâm từ trước, và có thể đo lường được: giảm số lượng ticket hỗ trợ, tạo ra phiên bản đầu tiên của bản kiểm tra pháp lý, lọc dữ liệu đến từ các lead đến, tạo ra báo cáo hàng tháng. Sự thành công của Agent phụ thuộc vào việc kết quả này có cải thiện hay không. Nó là mục tiêu đánh giá của bạn ngay từ ngày đầu tiên.

Điều quan trọng nhất về bước này so với bất kỳ bước nào khác chính là nó sẽ ràng buộc mọi quyết định tiếp theo. Với kết quả cụ thể, việc "chọn framework nào" không còn là vấn đề triết học nữa, bạn sẽ chọn framework nào có thể nhanh nhất đưa ra kết quả này. "Chọn mô hình nào" cũng không còn là cuộc tranh luận về benchmark, mà là chọn mô hình mà bằng chứng của bạn cho thấy hiệu quả trong công việc cụ thể này. "Chúng ta cần cần phải nhớ, subagents, harness tùy chỉnh không" cũng không phải là một thử nghiệm tư duy nữa, mà chỉ được thêm vào khi mẫu thất bại cụ thể đòi hỏi.

Các nhóm bỏ qua bước này thường cuối cùng sẽ tạo ra một nền tảng ngang hàng mà không ai muốn. Các nhóm coi trọng bước này thường sẽ cung cấp một agent hẹp nhưng có thể phục vụ lại chi phí trong một quý. Và agent thực sự đi vào hoạt động này sẽ dạy cho họ nhiều hơn so với việc đọc bài báo hai năm.

Trước khi đưa bất cứ thứ gì vào vận hành, hãy thiết lập theo dõi và đánh giá. Chọn Langfuse hoặc LangSmith, và kết nối nó. Xây dựng bộ dữ liệu vàng nhỏ nếu cần thiết. 50 mẫu dữ liệu được gán nhãn là đủ để bắt đầu. Bạn không thể cải thiện điều gì đó mà bạn không thể đo lường được. Sau này có thể cải thiện hệ thống này, chi phí khoảng gấp 10 lần so với việc thực hiện ngay bây giờ.

Bắt đầu từ một chu trình agent đơn. Chọn LangGraph hoặc Pydantic AI. Lựa chọn mô hình Claude Sonnet 4.6 hoặc GPT-5. Cung cấp ba đến bảy công cụ thiết kế tốt cho agent. Để nó sử dụng hệ thống tệp hoặc cơ sở dữ liệu làm trạng thái. Trước hết, triển khai cho người dùng phạm vi nhỏ, quan sát các dấu vết.

Đối xử với agent như một sản phẩm, chứ không phải là một dự án. Nó sẽ thất bại theo cách bạn không thể dự đoán, và những thất bại đó chính là bản đồ đường đi của bạn. Xây dựng bộ kiểm tra regression từ dấu vết sản xuất thực. Mỗi lần thay đổi biết bao, thay thế mô hình, chỉnh sửa công cụ, bạn đều phải kiểm tra qua đánh giá trước triển khai. Hầu hết các nhóm đều đánh giá thấp sự đầu tư tại đây, và đáng tin cậy của họ chính từ đây mà ra.

Chỉ khi bạn đã "đáng được" đến được quyền mở rộng phạm vi, hãy tăng sự phức tạp. Khi bối cảnh trở thành điểm nghẽn, hãy giới thiệu subagents. Khi cửa sổ ngữ cảnh đơn không thể chứa nội dung cần thiết, hãy giới thiệu khung nhớ. Khi API cấp thấp thực sự không tồn tại, hãy giới thiệu việc sử dụng máy tính hoặc trình duyệt. Đừng thiết kế trước những thứ này. Để phương pháp thất bại đưa chúng đến.

Chọn cơ sở hạ tầng nhàm chán. Sử dụng MCP cho công cụ. Sử dụng E2B hoặc Browserbase cho hộp cát. Sử dụng Postgres cho trạng thái, hoặc sử dụng hệ thống lưu trữ dữ liệu bạn đã chạy. Cố gắng giữ nguyên hệ thống xác thực và khả năng quan sát hiện tại. Các cơ sở hạ tầng kỳ quặc ít khi là dấu hiệu thực sự chiến thắng, điều thực sự chiến thắng là kỷ luật.

Từ ngày đầu tiên, hãy tập trung vào mô hình kinh tế đơn vị. Mỗi lần chi phí action, tỷ lệ hit bộ nhớ cache, chi phí vòng lặp thử lại, phân phối cuộc gọi mô hình. Agent trong giai đoạn PoC có vẻ rẻ, nhưng nếu bạn không theo dõi chi phí theo kết quả ngay từ đầu, khi quy mô mở rộng lên 100 lần, chi phí sẽ tăng đáng kể. Một PoC chạy với 0,50 đô la mỗi lần ban đầu có thể trở thành 5.000 đô la mỗi tháng ở quy mô trung bình. Những nhóm không nhìn thấy điều này từ trước sẽ phải đối mặt với một cuộc họp với CFO mà họ không thích.

Đánh giá lại mô hình mỗi quý, chứ không phải mỗi tuần. Cố định trong một quý. Kết thúc quý, chạy toàn bộ bộ kiểm tra đánh giá của bạn trên một phiên bản hiện tại của mô hình tiên tiến. Nếu dữ liệu cho thấy cần đổi mới, hãy đổi. Điều này sẽ giúp bạn hưởng lợi từ tiến bộ của mô hình mà tránh được sự hỗn loạn mỗi lần phát hành.

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

Dưới đây là một số dấu hiệu cụ thể, cho thấy một điều gì đó có thể là tín hiệu thực sự: một nhóm kỹ sư được tôn trọng viết một bài học dựa trên con số, không chỉ tuyên bố có bao nhiêu người sử dụng; nó là một nguyên tắc cơ bản, chẳng hạn như giao thức, mẫu hoặc cơ sở hạ tầng, chứ không phải là gói lởm hoặc đóng gói; có thể tương tác với hệ thống bạn đang vận hành, chứ không phải thay thế nó; lý do giới thiệu của nó nói về việc nó giải quyết mô hình thất bại nào, chứ không phải là nó mở ra khả năng gì; nó đã tồn tại đủ lâu, đến mức có người có thể viết một bài đăng trên blog về "những nơi nó không hoạt động".

Dưới đây là một số dấu hiệu cụ thể, cho thấy một điều gì đó có thể chỉ là tiếng ồn: 30 ngày sau khi phát hành vẫn chỉ có video demo, không có trường hợp triển khai; chỉ số benchmark tăng mạnh mà không sát với sự thật; trong pitch, không giới hạn sử dụng "tự động hóa", "hệ điều hành agent" hoặc "xây dựng bất kỳ agent nào"; tài liệu framework mặc định rằng bạn sẽ loại bỏ việc theo dõi hiện có, xác thực và cấu hình; số ngôi sao tăng nhanh, nhưng số commits, phiên bản và người đóng góp không tăng đồng đều; tốc độ trên Twitter rất nhanh, nhưng tốc độ trên GitHub không theo kịp.

Một thói quen hữu ích hàng tuần là: dành 30 phút vào thứ Sáu để theo dõi lĩnh vực này. Đọc ba điều: Blog Kỹ thuật Anthropic, Ghi chú của Simon Willison, Không gian ẩn. Nếu có bản chỉ trích sau sự cố trong tuần đó, hãy đọc một hoặc hai bài nữa. Cái khác bạn có thể bỏ qua. Những điều quan trọng thật sự, bạn sẽ không bỏ lỡ.

Cái gì đáng quan sát tiếp theo

Một số vấn đề đáng chú ý trong hai quý tiếp theo, không phải vì chúng chắc chắn sẽ chiến thắng, mà vì "liệu đây có phải là tín hiệu không" vẫn chưa được giải quyết hoàn toàn.

Mô hình fork song song của Replit Agent 4.
Đây là một trong những giải pháp đầu tiên nghiêm túc thử nghiệm "nhiều agent hoạt động song song" mà không bị cản trở bởi trạng thái chia sẻ. Nếu nó có thể tồn tại sau quá trình mở rộng, chế độ mặc định orchestrator-subagent có thể thay đổi.

Độ chín của mô hình định giá dựa trên kết quả.
Hành trình doanh thu của Sierra và Harvey đã xác minh mô hình này trong một lĩnh vực hẹp. Câu hỏi là, liệu nó có thể được mở rộng sang các lĩnh vực khác, hay chỉ áp dụng trong các tình huống dọc theo chiều dọc.

Kỹ năng như một lớp bao bọc cho khả năng.
Sự gia tăng của tập tin AGENTS.md và thư mục kỹ năng trên GitHub cho thấy một cách mới để bao bọc khả năng của agent đang nổi lên. Câu hỏi là liệu nó có thể chuẩn hóa lớp khả năng như MCP như một công cụ tiêu chuẩn, đây vẫn là một vấn đề mở.

Sự sụt giảm chất lượng và cuộc xem xét lại của Claude Code vào tháng 4 năm 2026.
Một agent hàng đầu trong ngành đã phát hành một phiên bản gây ra sự sụt giảm hiệu suất 47%, và đó là người dùng phát hiện trước, sau đó mới phát hiện thông qua giám sát nội bộ. Điều này cho thấy ngay cả ở những người đứng đầu ngành, thực hành đánh giá agent cấp sản xuất vẫn chưa chín chắn. Nếu sự việc này thúc đẩy việc đầu tư của cả ngành đổi mới đánh giá trực tuyến tốt hơn, thì sự điều chỉnh này là có lợi cho sức khỏe của ngành.

Âm thanh trở thành giao diện dịch vụ khách hàng mặc định.
Kênh âm thanh của Sierra đã vượt quá kênh văn bản vào cuối năm 2025. Nếu mô hình này tiếp tục trong các lĩnh vực dọc theo chiều dọc khác, thì trễ, gián đoạn, việc gọi công cụ thời gian thực và các hạn chế thiết kế khác sẽ trở thành vấn đề cấp một, nhiều kiến trúc hiện tại sẽ cần phải được thiết kế lại.

Khả năng của agent mô hình mã nguồn mở vẫn đang thu hẹp khoảng cách.
DeepSeek-V3.2 hỗ trợ tự nhiên chức năng "thinking-into-tool-use", Qwen 3.6 và toàn bộ hệ sinh thái mô hình mã nguồn mở đều đáng chú ý. Hiệu suất chi phí trên nhiệm vụ agent hẹp đang thay đổi. Tình hình mô hình đóng được mặc định ưu thế sẽ không tồn tại mãi mãi.

Mỗi trong những điều trong danh sách này có thể tương ứng với một câu hỏi rõ ràng: "Sau sáu tháng, tôi cần thấy điều gì để tin rằng nó thực sự quan trọng?" Đó chính là kiểm tra. Theo dõi câu trả lời, chứ không phải theo dõi thông báo.

Đánh Cược lạ lùng

Mỗi framework mà bạn chưa áp dụng, đều là một lần bạn không phải di dời trong tương lai. Mỗi bản đánh giá mà bạn không theo dõi, đều là một tháng tập trung vào. Các công ty đang thắng trong chu kỳ này — Sierra, Harvey, Cursor, mỗi người đã chọn mục tiêu hẹp, xây dựng kỷ luật nhạt nhòa, sau đó để tiếng ồn của lĩnh vực này quá cảnh bên cạnh họ.

Con đường truyền thống là: chọn một ngăn xếp công nghệ, dành rất nhiều năm để nắm vững nó, sau đó leo lên dọc theo cầu thang. Điều này hiệu quả khi ngăn xếp công nghệ có thể ổn định trong mười năm. Nhưng bây giờ, mỗi quý ngăn xếp công nghệ đều đang thay đổi. Người thực sự chiến thắng không còn tối ưu hóa khả năng "nắm vững một ngăn xếp công nghệ" nữa, mà đang tối ưu hóa về gu thẩm mỹ, nguyên tắc cơ bản và tốc độ triển khai. Họ xây dựng công khai những thứ nhỏ nhắn, học hỏi thông qua việc triển khai. Người khác chú ý đến họ vì những gì họ đã tạo ra, và mời họ vào trong.

Hãy cân nhắc điều này một cách nghiêm túc, vì đó chính là điều thực sự bài viết muốn truyền đạt. Mô hình làm việc mà hầu hết chúng ta chấp nhận giả định rằng thế giới này sẽ ổn định đủ lâu để khả năng nắm vững được tăng lên theo hình thức cộng gộp lãi. Bạn đi học, nhận bằng cấp, leo lên. Ở đây hai năm, ở đó ba năm, sơ yếu lẫn dần trở thành thứ mở cửa ra được. Tiền đề cho toàn bộ máy móc, là ngành đối diện nó đủ ổn định.

Nhưng trong lĩnh vực agent ngày nay không có một "đối diện" ổn định. Công ty mà bạn muốn tham gia có thể chỉ mới có sáu tháng tuổi. Cấu trúc mà họ dựng lên có thể chỉ có mười tám tháng lịch sử. Giao thức cơ sở có thể cũng chỉ hai năm tuổi. Một nửa bài viết được trích dẫn nhiều nhất trong lĩnh vực này, tác giả còn chưa tồn tại trong lĩnh vực đó ba năm trước. Không có cầu thang để leo, vì tòa nhà này luôn đang thay đổi tầng. Khi cầu thang không còn hiệu quả, chỉ còn cách cũ hơn: tạo ra một thứ, đặt lên internet, để công việc của bạn giới thiệu bản thân. Đây là một con đường chống lại logic, vì nó tránh xa hệ thống xác nhận năng lực. Nhưng trong một lĩnh vực luôn di chuyển, đây cũng là con đường duy nhất thực sự có thể tăng lãi cộng gộp.

Đó chính là bức tranh thời đại nhìn từ bên trong. Ngay cả các gigantosaurus cũng đang công khai cải tiến, phát hành và sửa chữa vấn đề, viết bản trả hồi, vá lỗi trực tuyến. Trong nhóm mà từng phát hành các sản phẩm thú vị nhất trong năm nay, một số người cách đây 18 tháng vẫn chưa có mặt trong lĩnh vực này. Người không biết viết code đang làm việc cộng tác với agent, triển khai phần mềm thực sự. Một người có tiến sĩ có thể bị những người xây dựng chọn nguyên liệu cơ bản đúng và bắt đầu triển khai nhanh chóng vượt mặt. Cánh cửa đã mở. Thành phần lớn nhất vẫn đang tìm kiếm mẫu đơn xin việc.

Kỹ năng thực sự bạn cần phát triển bây giờ, không phải là "agent". Mà là sự kỷ luật để đánh giá xem công việc nào sẽ tăng lãi cộng gộp trong một lĩnh vực bề mặt luôn thay đổi. Kỹ thuật ngữ cảnh sẽ tăng lãi cộng gộp. Thiết kế công cụ sẽ tăng lãi cộng gộp. Mô hình Orchestrator-subagent sẽ tăng lãi cộng gộp. Sự kỷ luật Eval sẽ tăng lãi cộng gộp. Tư duy Harness sẽ tăng lãi cộng gộp. API khung vừa được phát hành hôm thứ Ba không sẽ. Một khi bạn có thể phân biệt chúng, mỗi tuần một đợt đồn đoán mới sẽ không còn là áp lực mà sẽ trở thành tiếng ồn bạn có thể bỏ qua.

Bạn không cần học tất cả mọi thứ. Bạn cần học những gì sẽ tăng lãi cộng gộp, và bỏ qua những gì không tăng lãi cộng gộp. Chọn một kết quả. Sắp xếp xong theo dõi và đánh giá trước khi triển khai. Sử dụng LangGraph, hoặc công cụ tương đương trong nhóm của bạn. Sử dụng MCP. Đặt runtime vào hộp cát. Mặc định bắt đầu từ một agent. Chỉ khi mô hình thất bại kéo vào sự phức tạp, hãy mở rộng phạm vi. Đánh giá lại mô hình mỗi quý. Đọc ba tác phẩm vào ngày thứ Sáu.

Đây chính là playbook. Phần còn lại là sở thích, tốc độ triển khai và sự kiên nhẫn không theo đuổi những thứ không quan trọng.

Đi xây dựng điều gì đó. Đặt chúng lên Internet. Thời đại này thưởng cho những người tạo ra điều gì đó, chứ không phải là những người chỉ biết mô tả điều gì đó. Bây giờ là cửa sổ tốt nhất để trở thành người "thực sự tạo ra được điều đó".

[Liên kết Gốc]

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia