Introduction Xin chào tất cả mọi người, tôi là Max Nechaev - giám đốc kỹ thuật tại Snoonu, người sáng lập và người đam mê AI. Tôi đã ở trong phát triển phần mềm trong một thời gian khá dài. Lúc tôi đang xây dựng các ứng dụng iOS, có rất nhiều mô hình kiến trúc ở đó. Họ cảm thấy vững chắc. Suy nghĩ qua. thử nghiệm chiến đấu trong nhiều năm. Lúc đó, tôi không bao giờ tưởng tượng rằng tôi sẽ là người tạo ra một kiến trúc mới - đặc biệt là không phải cho các hệ thống AI. Nhưng trước khi chúng ta đi đến giải pháp, hãy nói về vấn đề. Ngay bây giờ, AI đang trải qua một chu kỳ hype điên rồ. Các công ty khởi nghiệp bật lên và chết mỗi ngày. Ngày càng có nhiều người đang lặn vào các công cụ có mã thấp và không có mã như Make, n8n và những người khác. Và bạn biết điều gì? Tôi nghĩ rằng đó là tuyệt vời. Hàng triệu người đang bước vào một loại thực tế mới. Nó cảm thấy như những ngày đầu của Internet, khi các trang web chuyển từ tĩnh sang tương tác, và đột nhiên cảm thấy như mọi thứ đều có thể. Nhiều người đang xây dựng các đại lý AI. Và tôi yêu điều đó. Nhưng có một cái bắt. Vẫn không có sự hiểu biết chung về cách kiến trúc các hệ thống AI linh hoạt, có thể mở rộng. Không có mô hình thiết kế thực sự. Không có cấu trúc được áp dụng rộng rãi. Chỉ là rung động. Tôi càng nhìn xung quanh, tôi càng thấy nó. Các đại lý được xây dựng trong n8n trông giống như spaghetti. Không thể đọc, gỡ lỗi hoặc quy mô. Hướng dẫn về các đại lý xây dựng trong Python? Câu chuyện tương tự. Mọi thứ bị vứt vào một tệp, không có sự tách rời mối quan tâm. Chắc chắn, các nhà phát triển có kinh nghiệm có thể biết rằng họ nên tách mọi thứ ra - nhưng người mới bắt đầu không. Và họ kết thúc xây dựng các hệ thống hoàn toàn không thể duy trì. Vì vậy, hôm nay, tôi muốn chia sẻ giải pháp mà tôi đã dựa vào.Đây là cách tôi cấu trúc các hệ thống AI của mình.Làm thế nào tôi tách trách nhiệm.Làm thế nào tôi giữ cho mọi thứ linh hoạt, có thể mở rộng và thực sự lành mạnh. Hãy để tôi giới thiệu cho bạn khung của tôi, mô hình thiết kế, hoặc kiến trúc - gọi nó như bạn muốn - Agent Action Chains - Chuỗi hành động của đại lý AAC Meet AAC (Agent Action Chains) Vào một thời điểm nào đó, tôi nhận ra một cái gì đó đơn giản.Nếu sự hỗn loạn liên tục xảy ra một lần nữa và một lần nữa, có lẽ đó không phải là một tai nạn. Vì vậy, tôi bắt đầu thử nghiệm. Đầu tiên, với các khối bên trong n8n. Sau đó, tôi bắt đầu tách logic theo cách thủ công - đây là nơi tôi xử lý đầu vào, đây là nơi tôi xử lý, đây là logic cốt lõi. Cuối cùng, vai trò bắt đầu xuất hiện. Đó là cách AAC ra đời - Agent Action Chains. Nó không phải là một khung khác với một ngàn trang tài liệu. AAC là một cách để xây dựng các hệ thống AI giống như một kỹ sư trưởng thành, không giống như ai đó xếp mọi thứ lại với nhau và hy vọng điều tốt nhất. Ý tưởng cốt lõi là gì? Tôi chia hệ thống thành các đại lý có vai trò rõ ràng. Mỗi đại lý làm chính xác một điều. Tất cả họ nói chuyện thông qua các hợp đồng JSON - không đoán, không ma thuật, không hỗn loạn. Hãy nghĩ về nó như một đội. Một tay cầm đầu vào. Dữ liệu xử lý khác Một người thứ ba quyết định làm gì tiếp theo. Một nhân viên khác nói chuyện với trí nhớ. Một trong những thất bại Một người khác theo dõi và ghi lại mọi thứ. Mọi người đều biết công việc của họ.Và với nhau, hệ thống hoạt động như một chiếc đồng hồ Thụy Sĩ. Vẻ đẹp của AAC là nó là platform-agnostic. Bạn có thể triển khai nó trong n8n, trong , trong Python sử dụng FastAPI, ngay cả bên trong LangChain hoặc LangGraph nếu bạn dành thời gian để thiết lập nó đúng cách. Trang chủ Make.com Here’s How It Works (In Plain English) Không phải là một nhóm hỗn loạn nơi mọi người làm tất cả mọi thứ cùng một lúc, mà là một nhóm nơi mỗi người biết công việc của họ, sở hữu không gian của họ và cung cấp một kết quả rõ ràng. Đó chính xác là cách AAC hoạt động. Khi một đầu vào chạm vào hệ thống - cho dù từ người dùng hoặc dịch vụ bên ngoài - nó trước tiên đi qua một đại lý mà chỉ đơn giản là mở cửa và tắt nó. Sau đó đến xử lý cơ bản. Chúng tôi không vội vàng đến kết luận. Đầu tiên, chúng tôi cấu trúc đầu vào, làm sạch tiếng ồn, bình thường hóa nó. Bước đó một mình tiết kiệm hàng giờ xử lý xuống đường. Một đầu vào sạch là một nửa kiến trúc. Tiếp theo là nhà soạn nhạc. Đó là bộ não của hệ thống. Nó không thực hiện nhiệm vụ chính nó. Thay vào đó, nó tìm ra ai nên làm gì, theo thứ tự nào, với các thông số nào. vai trò của nhà soạn nhạc là lên kế hoạch, chỉ đạo và quản lý dòng chảy. Sau đó các chuyên gia tiếp quản. Những đại lý này được tập trung. Một phân loại, một tổng hợp, một thứ ba lấy dữ liệu bên ngoài, v.v. Mỗi người có một mục đích rõ ràng. Họ không trùng lặp, họ không chiến đấu về trách nhiệm, họ không viết lại đầu ra của nhau. Bạn có thể trao đổi chúng ra, cải thiện chúng, tái sử dụng chúng - giống như các mô-đun phần mềm tốt. Khi hệ thống cần ghi nhớ một cái gì đó, bộ nhớ đi vào chơi. Đó là tác nhân của nó. Nó không lưu trữ mọi thứ một cách mù quáng. Thay vào đó, nó biết làm thế nào để lấy lại những điều đúng vào đúng thời điểm - các cuộc trò chuyện trước đây, bối cảnh người dùng, sự kiện nội bộ. Đây là cách hệ thống của bạn ngừng là một con cá vàng và bắt đầu hành động như một trợ lý thực sự. Xử lý lỗi được xử lý nghiêm túc như nhau. AAC bao gồm một đại lý chuyên dụng cho điều đó - The Guard. Nó giám sát sự thất bại, bắt trường hợp ngoại lệ, hành động khi một cái gì đó bị phá vỡ. Nó không phải là một bản vá, không phải là một thử nghiệm ngẫu nhiên. Nó là một phần thực sự của kiến trúc. Và nó chịu trách nhiệm về khả năng phục hồi. Trong khi tất cả những điều này đang xảy ra, Người quan sát đang lặng lẽ theo dõi. Nó theo dõi những gì mỗi đại lý làm, mọi thứ mất bao lâu, những quyết định nào được đưa ra. Không chỉ vì niềm vui - điều này mang lại cho bạn khả năng hiển thị vào hệ thống. Không phải "có hiệu quả không?" nhưng Nó làm việc, Nó đã làm việc, và nơi nó có thể thất bại. Làm sao Tại sao Và cuối cùng, khi toàn bộ chuỗi đã làm công việc của mình, kết quả được định dạng và phân phối - trở lại người dùng, vào một phản ứng API, hoặc bất cứ nơi nào nó cần đi. sạch sẽ, có cấu trúc và dễ tiêu thụ. Đó là AAC. Một hệ thống được xây dựng không chỉ để hoạt động mà còn để phát triển, mở rộng và duy trì sự kiểm soát. All AAC Roles: Who Does What and Why It Matters AAC được xây dựng trên sự tách rời rõ ràng của trách nhiệm. Mỗi đại lý không chỉ là một khối kỹ thuật - nó là một đơn vị logic với một vai trò được xác định và một hợp đồng truyền thông. phần này phá vỡ những vai trò này là gì, làm thế nào họ tương tác, và tại sao bỏ qua ngay cả một trong số họ thường dẫn đến đau kiến trúc sau này. Ingress Agent: the Entry Point xử lý tín hiệu đến. Purpose: Đây có thể là một webhook, một mẫu đơn, một tin nhắn Telegram, một sự kiện Kafka - nó thực sự không quan trọng. Bởi vì pha trộn logic với các lớp tích hợp là bước đầu tiên để xây dựng một monolith. Trong n8n, đây thường chỉ là một nút webhook. nó nhận được yêu cầu, ghi nhật ký dữ liệu, và truyền tải JSON sạch vào hệ thống. Một ví dụ (pseudocode): { "source": "user", "payload": { "message": "I’d like to return my order" } } Preprocessing Agent: the Filter and Normalizer Chuyển đổi nguyên liệu thô thành một thứ gì đó hữu ích. Purpose: Công cụ này làm sạch tiếng ồn. Nó sửa chữa hộp, dải các biểu tượng kỳ lạ, xác nhận cấu trúc, và trích xuất các lĩnh vực chính. Nó đảm bảo rằng mọi thứ được truyền vào hệ thống là dự đoán và nhất quán. Rất nhiều người bỏ qua việc xử lý trước. Sai lầm lớn. Nó không chỉ là một "tốt để có" - đó là nền tảng. Đặc biệt là khi bạn đang đối phó với LLM, vệ sinh ngữ cảnh là tất cả mọi thứ. Một đầu vào hỗn loạn và toàn bộ chuỗi lý luận có thể bị phá vỡ. Trong n8n, đây thường là một nút chức năng. Trong mã, nó có thể là middleware, một handler, hoặc một lớp tiện ích nhỏ. const cleanInput = input.message.trim().toLowerCase() Orchestrator Agent: the Brain of the System Quyết định những gì cần xảy ra. Purpose: Nhà soạn nhạc không tự thực hiện công việc. công việc của nó là lập kế hoạch, ủy quyền và giám sát. Nó lấy đầu vào được làm sạch, xác định ý định của người dùng và kích hoạt các đại lý chuyên gia phù hợp. Trong các trường hợp đơn giản, đây chỉ có thể là một nếu/else khối. Trong các thiết lập tiên tiến hơn, nó là một LLM đầy đủ chạy với lời nhắc được thiết kế cẩn thận. Ví dụ, bạn có thể có GPT-4 trả về một kế hoạch thực hiện có cấu trúc trong JSON: { "steps": [ {"agent": "Classifier", "input": {...}}, {"agent": "Memory", "input": {...}}, {"agent": "Responder", "input": {...}} ] } Bạn thậm chí có thể thông qua nó một danh sách các đại lý có sẵn và để nó chọn con đường tốt nhất để tiến lên. Ý tưởng chính là điều này: nhà soạn nhạc không giải quyết vấn đề; nó xây dựng tuyến đường; nó quyết định ai cần phải làm gì và theo thứ tự nào. Specialist Agents: Focused Experts (TOOLS) Thực hiện một nhiệm vụ đơn lẻ, rõ ràng. Purpose: Những đại lý này không ở đây để giải quyết toàn bộ vấn đề - chỉ một phần cụ thể của nó, và làm tốt. Xác định một yêu cầu Tạo một câu trả lời Extract entities Các thực thể Gọi một API bên ngoài Dịch văn bản Bạn có thể kết thúc với hàng chục trong số này. Mỗi chức năng là một chức năng riêng biệt, một mô-đun sạch sẽ, hoặc một dòng phụ trong n8n. Và đó chính xác là những gì làm cho hệ thống linh hoạt và có thể mở rộng. Bạn muốn thêm một khả năng mới? Chỉ cần tạo một chuyên gia mới và đăng ký nó. Ví dụ về hợp đồng giữa nhà soạn nhạc và chuyên gia: { "agent": "Classifier", "input": { "text": "My order never arrived" }, "output_expected": { "label": "delivery_problem" } } Memory Agent: the Interface to the Past cung cấp bối cảnh thích hợp. Purpose: Đại lý này thu thập các sự kiện. Đó là nó. Nó truy vấn một cơ sở dữ liệu, một cửa hàng vector, một bộ nhớ cache Redis - bất cứ điều gì bạn có - và trả về chính xác những gì cần thiết. Nó không đưa ra quyết định, không đoán, không ảo giác. Bạn có thể sử dụng nó để lấy các lệnh trong quá khứ của người dùng, phù hợp với các nhúng vector từ cơ sở kiến thức hoặc nắm bắt các tương tác trước đó. Trong AAC, bộ nhớ luôn là thứ riêng của nó.Bằng cách đó, bạn có thể mở rộng nó, lưu trữ nó trong bộ nhớ đệm hoặc thậm chí kết nối nó vào nhiều hệ thống. SELECT * FROM orders WHERE user_id = "user_42" ORDER BY created_at DESC LIMIT 3 Guard Agent: Protection from Chaos Bắt và xử lý thất bại Purpose: Nếu một chuyên gia va chạm hoặc người phối hợp phá vỡ, người bảo vệ bước vào. nó ghi lại lỗi, gửi cảnh báo, và tùy chọn chạy logic fallback - chẳng hạn như lặp lại với một đại lý khác hoặc trả về một câu trả lời mặc định an toàn. Trong sản xuất, vai trò này là không thể đàm phán. Lỗi sẽ xảy ra. GPT có thể trở lại rác. API có thể mất thời gian. Bạn cần một lớp biết phải làm gì khi mọi thứ đi đôi bên. Ví dụ: GPT trả về JSON không hợp lệ. The guard catches it, logs the problem, notifies Slack, and sends a fallback message. { "error": "Invalid JSON from Summarizer", "fallback_response": "Sorry, I couldn’t process your request. Forwarding it to a human operator." } Observer Agent: the System’s Black Box Đăng nhập, phân tích và cung cấp cho bạn khả năng hiển thị về những gì thực sự đã xảy ra. Purpose: Cơ quan này không can thiệp - nó chỉ là đồng hồ. Bạn muốn theo dõi thời gian mỗi cơ quan trả lời? dữ liệu nào được thu thập bởi cơ quan bộ nhớ? Lực lượng bảo vệ phải kích hoạt phản hồi thường xuyên như thế nào? Người quan sát ghi lại tất cả mọi thứ vào bất kỳ công cụ nào bạn đang sử dụng - Supabase, Amplitude, Segment, hoặc một cái gì đó tùy chỉnh. Bạn hy vọng rằng bạn sẽ không cần nó, nhưng khi một cái gì đó bị phá vỡ, đó là cách duy nhất để hiểu những gì đã sai. Không có người quan sát, bạn đang bay mù.Với nó, bạn có được một bức ảnh đầy đủ. Egress Agent: the Final Touch Làm sạch quá trình sạch sẽ. Purpose: Đại lý này lấy đầu ra cuối cùng, định dạng nó, và cung cấp nó bất cứ nơi nào nó cần đi - cho người dùng, một API, một webhook, Slack, bất cứ điều gì. Một trong những sai lầm phổ biến nhất là quên bước này.Không có một đại lý egress chuyên dụng, bạn có nguy cơ gửi dữ liệu bị hỏng, nhật ký thô hoặc phản hồi đến nơi sai. { "status": "success", "reply": "We’ve reviewed your case. Thank you for reaching out!" } Mỗi đại lý này là một khối xây dựng. bạn có thể chạy chúng song song, thay thế chúng độc lập, tái sử dụng chúng trên các chuỗi. What’s Next? How to Start Using AAC in Your Projects Làm thế nào để bắt đầu sử dụng AAC trong dự án của bạn Nếu bạn đang đọc điều này, rất có thể bạn đã phải đối mặt với những vấn đề tương tự tôi đã làm. Dự án của bạn tiếp tục phát triển. Các trường hợp sử dụng nhân lên. Logic lan rộng hơn. Các đại lý trở nên “thông minh hơn” - nhưng hệ thống trở nên mỏng manh hơn. Những gì là một MVP gọn gàng ngày hôm qua bây giờ đã biến thành một mớ hỗn độn. Muốn thêm một chi nhánh mới? Đó là một rắc rối. Cố gắng giải quyết tại sao GPT trở lại một cái gì đó kỳ lạ? Không có ý tưởng nơi nó thậm chí đã xảy ra. Đây là thời điểm bạn bắt đầu hỏi - có cách nào khác không? Có có Thực hiện AAC có nghĩa là thay đổi cách bạn nghĩ, đó là một sự chuyển đổi từ ma thuật sang kỹ thuật. Và điểm khởi đầu không phải là mã. Nó nhìn vào hệ thống của bạn khác nhau. rõ ràng. không có ảo tưởng. Hãy thử tưởng tượng logic của bạn như một chuỗi các chuyên gia độc lập. Một người lấy đầu vào. Một người khác chuẩn bị dữ liệu. Một người thứ ba quyết định phải làm gì. Sau đó người thực thi đến. Sau đó - bộ nhớ. Sau đó ai đó bắt được những thất bại. Cuối cùng, ai đó ghi lại những gì đã xảy ra. Đó là đại lý tương lai của bạn, phong cách AAC. Ngay bây giờ, tuy nhiên, tất cả những vai trò đó đều ngụ ý hoặc nhầm lẫn với nhau rất nặng nề mà không ai biết những gì là gì. Bước đầu tiên thực sự là làm cho những vai trò đó rõ ràng. Thậm chí chỉ về mặt tinh thần. Vẽ ra chúng. Cho chúng tên. Bắt đầu đặt câu hỏi đúng: Ai chịu trách nhiệm về tổ chức ở đây? Nơi nào là trí nhớ? Làm thế nào tôi biết nếu mọi thứ thực sự hoạt động? Điều gì xảy ra nếu một khối thất bại? Một khi bạn làm điều đó, giá trị của tính mô-đun trở nên rõ ràng. Khi mọi thứ được kết hợp vào một nơi, một lỗi phá vỡ toàn bộ hệ thống. Nhưng khi mọi thứ được cấu trúc như các đại lý được ghép nối rời rạc, sự thất bại bị cô lập - và hệ thống tiếp tục chạy. Đó là lý do tại sao trong AAC, mỗi đại lý được cô lập, giao tiếp thông qua các hợp đồng và không có nhận thức về những người khác. Nó giống như các dịch vụ vi mô bên trong một đường ống. Chỉ đơn giản hơn. Và nhanh hơn. Và rồi niềm vui bắt đầu. Bạn đột nhiên nhận ra rằng bạn có thể tái sử dụng các mảnh của hệ thống. Các đại lý phân loại tương tự mà xử lý một dòng chảy có thể được sử dụng trong một khác. Các khối bộ nhớ có thể được chia sẻ trên nhiều chuỗi. Bạn thậm chí có thể làm cho các orchestrator thông minh hơn - để cho nó chọn các đại lý để kích hoạt. Đây không phải là tưởng tượng. Đây là sự trưởng thành cơ bản AAC mang lại. Trên các nền tảng không có mã như n8n, điều này trở thành một siêu cường thực sự. Bạn bắt đầu xây dựng một thư viện các đại lý. Mỗi một là một dòng phụ với một hợp đồng được xác định. Muốn xây dựng một bot mới? Chỉ cần gọi các đại lý bạn cần, theo thứ tự bạn cần chúng. Muốn thay thế một khối? Làm điều đó mà không sợ hãi. Muốn theo dõi hiệu suất hoặc theo dõi nơi mọi thứ thất bại nhất? Bạn đã có nó - Observer ghi lại mọi thứ, Guard nắm bắt mọi thất bại. Bạn bắt đầu nhìn thấy hệ thống như một kỹ sư, không ai sợ chạm vào mã. Bạn đang thiết kế. bạn đang biến một chuỗi các cuộc gọi GPT thành kiến trúc thực sự - một cái gì đó sống, quy mô, nhật ký, phát triển. Và nếu bạn không có thời gian để xây dựng lại mọi thứ ngay bây giờ - đó là tốt. Bắt đầu với một dòng chảy. Một điểm nhập cảnh. Một khoảnh khắc trung thực nơi bạn nói, "Được, hãy để tôi thử một cách tiếp cận mới ở đây. Hãy để tôi tách các vai trò. Thêm một số kiểm soát." Đó là thời điểm bạn bắt đầu xây dựng với AAC. Và cơ hội là - bạn sẽ không muốn quay trở lại.
