Gần đây, tôi có cuộc trò chuyện với một người bạn vốn không phải lập trình viên, nhưng đã bắt đầu sử dụng AI rất nhiều để tạo ra các agent phục vụ công việc hàng ngày. Cô ấy say mê khám phá Claude, xây dựng các luồng công việc tự động hóa cho bản thân và đội nhóm, và ngày càng hào hứng với những gì các hệ thống AI có thể làm.
Cuộc trò chuyện dần chuyển hướng sang các dự án của tôi xoay quanh hệ thống agentic: kiến trúc agent, kỹ thuật ngữ cảnh (context engineering), bộ nhớ dài hạn, điều phối đa agent, sub-agent, và các framework như Strands Agents. Phản ứng của cô ấy là:
“Tại sao bạn cần tất cả những thứ đó? Tôi đã tạo agent rồi mà.”
“Câu hỏi hay đấy,” tôi tự nhủ.
Điều khiến nó thú vị hơn nữa là tôi đã nghe gần như câu hỏi tương tự từ phía ngược lại. Sau khi thuyết trình về kiến trúc agentic và xây dựng harness với Strands Agents SDK, một lập trình viên junior lại đến hỏi:
“Tất cả những thứ này có ý nghĩa gì? Tại sao chúng ta không chỉ dùng Claude cho tất cả?”
Hai người tiếp cận vấn đề từ hai hướng hoàn toàn khác nhau, nhưng lại đến cùng một câu hỏi. Và tôi tin rằng câu hỏi đó phơi bày một điều quan trọng về vị thế hiện tại của chúng ta với agent: chúng ta đang dùng cùng một từ “agent” để mô tả hai hoạt động rất khác biệt với các trường hợp sử dụng hoàn toàn khác nhau.
Trong quan điểm của tôi, có sự khác biệt rõ rệt giữa tạo agent (Agent Creation) và kỹ thuật hóa agent (Agent Engineering).
Mục lục
Tạo Agent vs. Kỹ Thuật Hóa Agent: Hai Hoạt Động Không Phải Một
Các ứng dụng như Claude, ChatGPT, Amazon Quick và nhiều nền tảng khác ngày càng cho phép người dùng xây dựng các luồng công việc agentic khá phức tạp mà không cần tự thiết kế hạ tầng bên dưới.
Tuy nhiên, vẫn có một đường cong học tập. Bạn cần cung cấp chỉ dẫn, truyền tải kiến thức và ngữ cảnh vào hệ thống để kết quả nằm trong kỳ vọng (và hy vọng là không xảy ra hallucination!). Bạn cũng có thể cần tìm hiểu về các công cụ (tools), thiết lập tích hợp, lên lịch công việc, thậm chí tạo sub-agent để nhiều chức năng cùng hoạt động.
From phía người dùng, họ đã tạo một agent. Và quả thực là vậy! Nhưng khi một kỹ sư phần mềm nhìn vào cùng hệ thống đó, họ thấy một điều khác.
Họ thấy một ứng dụng cung cấp runtime agent được abstraction cao, hoạt động như một hộp đen (black box). Bạn có rất ít kiểm soát về cách thực thi diễn ra, cách ngữ cảnh được tổng hợp và duy trì, cách hệ thống mở rộng, hay thậm chí bộ nhớ nằm ở đâu, cùng nhiều quan ngại kiến trúc khác.
From góc nhìn người dùng ứng dụng, bạn đang tạo agent bên trong kiến trúc agentic của người khác.
Và điều đó không phải vấn đề. Thực ra, nó có thể chính xác là những gì bạn cần!
Các nhà phát triển và kiến trúc sư phần mềm liên tục cân bằng giữa abstraction và control. Chúng ta không chọn công nghệ cấp thấp nhất chỉ vì nó cho nhiều quyền kiểm soát nhất; chúng ta dùng abstraction vì nó loại bỏ các quyết định mà chúng ta không muốn đưa ra và sự phức tạp mà chúng ta không cần gánh.
Nguyên tắc tương tự áp dụng ở đây. Nếu Claude cung cấp mọi thứ bạn cần để tạo một agent, tại sao bạn không dùng nó?
Như thường lệ với thiết kế hệ thống, điều quan trọng là hiểu các trade-offs. Abstraction hoạt động vì ai đó đã đưa ra một tập hợp quyết định kiến trúc thay bạn. Nếu những quyết định đó phù hợp với yêu cầu của bạn, tuyệt vời. Nếu không, bạn có thể cần tự chịu trách nhiệm một số quyết định đó.
Đó là nơi tôi thấy sự phân biệt giữa Agent Creation và Agent Engineering thực sự hữu ích.
Có ba yếu tố làm cho sự phân biệt này đặc biệt rõ ràng.
Agent Là Một Tính Năng Hay Một Thành Phần Của Hệ Thống?
Đây có lẽ là cách suy nghĩ yêu thích của tôi về sự khác biệt.
Hãy giả định tôi tạo một agent trong Claude để nghiên cứu kỳ nghỉ cho tôi. Nó biết sở thích của tôi, tìm kiếm điểm đến, so sánh các lựa chọn và có thể dùng công cụ để xây dựng hành trình du lịch. Nó có thể rất phức tạp… nhưng Claude vẫn là ứng dụng. Tôi truy cập Claude, tương tác qua giao diện của Claude, và phụ thuộc vào hạ tầng của Claude để mọi thứ hoạt động.
Agent của tôi là một tính năng của ứng dụng mà tôi đang dùng.
Bây giờ hãy tưởng tượng tôi muốn cung cấp trải nghiệm tương tự thông qua trang web du lịch của riêng mình. Khách hàng đến ứng dụng của tôi và yêu cầu một kỳ nghỉ; ở đâu đó phía hậu trường, một agent nghiên cứu chuyến bay và khách sạn, áp dụng sở thích của họ, tương tác với hệ thống đặt chỗ, và trả về kết quả.
Khả năng nghe gần như giống hệt, nhưng về mặt kiến trúc, một điều gì đó nền tảng đã thay đổi. Agent giờ là một thành phần của hệ thống mà tôi đang xây dựng.
Bỗng chốc, tôi cần quyết định nó chạy ở đâu, ứng dụng của tôi giao tiếp với nó như thế nào, nó mở rộng ra sao, nó xác thực với các hệ thống khác thế nào, điều gì xảy ra khi nó gặp lỗi, nó hòa nhập vào luồng ứng dụng truyền thống ra sao, và tôi quan sát nó hoạt động thế nào. AI không còn là điểm đến; nó là phần của hệ thống mà tôi chịu trách nhiệm.
Đây rất rõ ràng là Agent Engineering.
Điểm mấu chốt thực ra nằm ở quyền sở hữu (ownership). Nếu agent là tính năng của Claude hoặc ứng dụng khác, bạn bị giới hạn — một cách hoàn toàn có chủ đích — vào những gì ứng dụng đó cho phép bạn làm. Nếu yêu cầu của bạn nằm trong những ranh giới đó, tuyệt vời. Khi chúng không nằm trong đó… bạn cần một abstraction khác.
Bạn Có Cần Kiểm Soát Kinh Tế Vận Hành Không?
Lý do khác khiến bạn có thể chọn kỹ thuật hóa agent là chi phí.
Có rất nhiều cuộc thảo luận hiện nay về việc các hệ thống agentic tiêu tốn bao nhiêu token, đặc biệt khi chúng ta xây dựng các luồng công việc chạy dài với context window lớn, tool calls và nhiều agent cùng lúc.
Chuyển từ Agent Creation sang Agent Engineering không tự động làm cho mọi thứ rẻ hơn, lưu ý vậy nhé. Kỹ thuật hóa có chi phí riêng, và sẽ khá hài hước nếu bạn bỏ 100.000 đô la thời gian của developer để tiết kiệm 500 đô la token.
Điều kỹ thuật hóa mang lại cho bạn là quyền kiểm soát.
Nếu bạn sở hữu harness quanh các agent của mình, các quyết định kiến trúc trở nên khả thi mà đơn giản không được tiết lộ khi bạn vận hành bên trong ứng dụng của người khác.
Bạn có thể quyết định rằng một tác vụ không cần toàn bộ lịch sử hội thoại, cache kết quả tốn kém, truy xuất bộ nhớ chỉ khi nó liên quan, tóm tắt ngữ cảnh giữa các bước, hoặc định tuyến các tác vụ đơn giản đến model rẻ hơn.
Bạn có thể bắt đầu xem ngữ cảnh và token như là tài nguyên mà bạn chủ động kỹ thuật hóa.
Có một cuộc thảo luận lớn hơn nhiều xoay quanh kỹ thuật ngữ cảnh (context engineering), nhưng đó là câu chuyện cho bài viết khác. Bây giờ, điểm quan trọng là abstraction quyết định những công cụ (levers) nào có sẵn cho bạn.
// Ví dụ: Kiểm soát chi phí trong Agent Engineering
if (task.type === "simple_classification") {
// Route đến model rẻ hơn
model = "model-tiên-giá";
} else if (context.size > THRESHOLD) {
// Tóm tắt ngữ cảnh trước khi gửi
context = await summarize(context, { maxTokens: 1024 });
}
// Chỉ truy xuất bộ nhớ khi thực sự cần
if (query.requiresMemory) {
memory = await retrieveRelevantMemory(query);
}Nếu bạn không cần những công cụ đó, ít giá trị khi tự gánh trách nhiệm cho chúng. Nếu kinh tế vận hành của hệ thống yêu cầu điều đó, Agent Engineering mang lại cho bạn quyền kiểm soát đó.
Bạn Có Cần Sở Hữu Dữ Liệu Của Mình Không?
Sau đó là câu hỏi mà nhanh chóng trở nên quan trọng trong môi trường doanh nghiệp: mọi thứ thực sự lưu ở đâu?
Khi tôi tạo một agent bên trong một ứng dụng, tôi đang chấp nhận kiến trúc của ứng dụng đó và cơ chế xử lý ngữ cảnh, trạng thái, bộ nhớ, tích hợp và dữ liệu. Lần nữa, điều đó có thể hoàn toàn chấp nhận được.
Nhưng nếu dữ liệu cụ thể không được rời khỏi một môi trường nhất định? Nếu tôi cần biết chính xác bộ nhớ dài hạn được lưu ở đâu, kiểm soát model nào nhận thông tin nào, duy trì nhật ký kiểm toán của riêng mình, hoặc đảm bảo dữ liệu nhất định không bao giờ vượt qua một ranh giới cụ thể?
Lúc này, hộp đen thực sự quan trọng.
Đây một phần là câu hỏi tuân thủ (compliance), một phần là câu hỏi sở hữu dữ liệu, và vâng, một phần là câu hỏi vendor lock-in. Càng xây dựng nhiều hành vi, kiến thức và trạng thái quanh abstraction của một ứng dụng, tôi càng phụ thuộc vào năng lực và giới hạn của nền tảng đó.
Nhưng vendor lock-in không phải, tự nó, là lý do để kỹ thuật hóa mọi thứ từ đầu. Chúng ta chấp nhận mức độ lock-in khác nhau trong suốt kiến trúc phần mềm hiện đại vì các abstraction được quản lý có thể mang lại giá trị khổng lồ.
Câu hỏi đơn giản là trade-off đó có chấp nhận được cho các yêu cầu trước mắt bạn hay không.
Vậy… Ta Không Thể Chỉ Dùng Claude Cho Tất Cả Sao?
Một bảng tính hữu ích có thể eventually trở thành một ứng dụng, nhưng điều đó không có nghĩa bảng tính là một lựa chọn sai lầm. Nó có thể đã là abstraction đúng đắn cho vấn đề tại thời điểm đó, và nó thậm chí có thể đã giúp chúng ta hiểu vấn đề đủ tốt để biết cái gì đáng kỹ thuật hóa sau này.
Tôi nghĩ Agent Creation và Agent Engineering nên được nhìn nhận tương tự: không phải như các cấp độ trên một thang trưởng thành, và chắc chắn không phải như một hành trình mà mọi agent cuối cùng đều phải trở thành agent được kỹ thuật hóa, mà là các lựa chọn kiến trúc khác nhau về mức độ sở hữu hệ thống bên dưới mà chúng ta cần.
Chúng ta có thể vui vẻ tạo một agent trong Claude cho một tác vụ trong khi kỹ thuật hóa một agent khác từ đầu, thậm chí có thể trong cùng hệ thống.
Đôi khi, một agent được tạo trong Claude, ChatGPT, Amazon Quick hoặc ứng dụng khác sẽ vẫn ở đó vì nó làm mọi thứ chúng ta cần. Đôi khi, yêu cầu của chúng ta sẽ đòi hỏi tự chịu trách nhiệm kiến trúc và chúng ta sẽ tìm đến Strands Agents SDK hoặc một agent harness khác.
Và có lẽ lần tới khi ai đó hỏi tôi: “Tại sao chúng ta không chỉ dùng Claude cho tất cả?”, câu trả lời của tôi sẽ đơn giản là:
Bạn có thể! Chừng nào các quyết định của nó tương thích với quyết định của bạn.
Kết Luận: Chọn Đúng Abstraction Cho Vấn Đế Của Bạn
Sự phân biệt giữa tạo agent và kỹ thuật hóa agent không phải là vấn đề đúng/sai. Đó là một quyết định kiến trúc có chủ đích dựa trên yêu cầu thực tế.
Hãy tự hỏi bản thân:
- Agent này là tính năng hay thành phần của hệ thống?
- Bạn có cần kiểm soát kinh tế (token, chi phí, model routing) không?
- Bạn có cần sở hữu dữ liệu và tuân thủ quy định không?
- Bạn có thể chấp nhận vendor lock-in của nền tảng đó không?
Nếu câu trả lời là không cho bất kỳ câu hỏi nào, bạn có lẽ nên cân nhắc Agent Engineering. Nếu tất cả đều phù hợp, Agent Creation hoàn toàn đủ và đó là lựa chọn thông minh.
Xây dựng benchmark. Chia sẻ những gì bạn học được.
