Điều phối đa tác nhân trên lớp tệp dùng chung Amazon S3 Files

Tổng quan

Điều phối đa tác nhân bắt đầu trục trặc khi các tác nhân chuyên biệt chuyển trạng thái cho nhau qua những payload API ngày càng phình to và cửa sổ ngữ cảnh đầy token, khiến pipeline chậm, tốn kém và khó gỡ lỗi. Ngày 14 tháng 8 năm 2026, AWS giới thiệu Amazon S3 Files, một lớp tệp dùng chung tương thích POSIX, nơi các tác nhân đọc và ghi vào những thư mục riêng thay vì truyền trạng thái qua prompt. Với đội marketing và sales, điều đó có nghĩa là việc bàn giao giữa các tác nhân gọn gàng hơn, và tại Vanaxity chúng tôi xem mô hình bộ nhớ dùng chung này là hạ tầng cốt lõi.

Bài viết này giải thích AWS đã ra mắt những gì, vì sao việc bàn giao qua cửa sổ ngữ cảnh gây hại cho các pipeline marketing và sales tự động, và lớp tệp dùng chung thay đổi việc điều phối đa tác nhân trong thực tế ra sao. Bài viết dành cho các nhà lãnh đạo marketing, growth, RevOps và MarTech đang vận hành hoặc lên kế hoạch cho các quy trình tác nhân như làm giàu dữ liệu khách hàng tiềm năng, phân loại ý định, viết nội dung động và kiểm tra tuân thủ. Các dữ kiện được nêu là của AWS; những hàm ý về MarTech là phân tích của Vanaxity, được trình bày như khuyến nghị chứ không phải điều chắc chắn.

Những điểm cốt lõi cần nắm vững

• Vào ngày 14 tháng 8 năm 2026, AWS công bố Amazon S3 Files, mang lại lớp tệp chia sẻ tương thích POSIX trên Amazon S3 phục vụ các đường ống AI đa tác nhân trên EC2, Lambda, EKS, ECS và Bedrock AgentCore.
• Các tác nhân chạy trên EC2, AWS Lambda, Amazon EKS, Amazon ECS và Amazon Bedrock AgentCore Runtime có thể đọc và ghi vào các thư mục tệp cách ly với cơ chế kiểm soát truy cập chi tiết, bằng các thao tác tệp tiêu chuẩn.
• Mô hình này thay việc truyền trạng thái qua các payload API ngày càng phình to và cửa sổ ngữ cảnh đầy token bằng cách bàn giao theo quy ước thư mục, nhờ đó có thể giảm phần prompt dư thừa.
• Giải pháp này bổ trợ, chứ không thay thế, Amazon S3 Vectors, cách tiếp cận bộ nhớ ngữ nghĩa mà AWS mô tả vào tháng 6 năm 2026; tệp lưu giữ trạng thái dùng chung và các tài sản đầu ra, còn vector lưu giữ những ký ức có thể tìm kiếm.
• Khuyến nghị của Vanaxity: hãy xem bộ nhớ dùng chung là hạ tầng cho các tác nhân marketing và sales tự động, đồng thời thiết kế cơ chế kiểm soát truy cập, cách ly và quy ước bàn giao trước khi mở rộng quy mô.

AWS đã thực sự cung cấp những gì với Amazon S3 Files?

AWS đã ra mắt một cách để nhiều tác nhân dùng chung một hệ thống tệp thay vì chuyển trạng thái qua lại bằng prompt. Trong bài viết có tiêu đề "Orchestrating multi-agent AI architectures with Amazon S3 Files" đăng ngày 14 tháng 8 năm 2026, AWS mô tả Amazon S3 Files là một lớp tệp tương thích POSIX đặt trên dữ liệu S3. Các tác nhân gắn kết (mount) lớp này và dùng các thao tác tệp thông thường, nhờ đó một tác nhân lập kế hoạch có thể ghi một thư mục để tác nhân ở bước sau đọc lại.

Ý tưởng then chốt là phối hợp thông qua hệ thống tệp. Các tác nhân chuyên biệt trên Amazon EC2, AWS Lambda, Amazon EKS, Amazon ECS và Amazon Bedrock AgentCore Runtime đọc và ghi vào các thư mục cách ly với cơ chế kiểm soát truy cập chi tiết.

Thay vì nhồi toàn bộ ngữ cảnh của một tác nhân khác vào payload API, mỗi tác nhân để lại kết quả của mình trong một thư mục đã thống nhất. Tác nhân tiếp theo sẽ lấy kết quả đó. AWS mô tả điều này là mang lại cho các tác nhân "lớp dữ liệu chung và cách bàn giao theo quy ước thư mục mà pipeline cần". Đó là toàn bộ sự thay đổi trong điều phối đa tác nhân: hệ thống tệp, chứ không phải prompt, là nơi các tác nhân gặp nhau.

Điểm vượt trội mang tính thực tiễn là đây là các thao tác tệp thông thường. Các tác nhân không cần phải học một giao thức mới phức tạp; chúng sử dụng cùng các lệnh quen thuộc như bất kỳ chương trình nào: liệt kê thư mục, mở tệp và ghi dữ liệu ra đĩa. Vì tương thích chuẩn POSIX, một hàm Lambda và một bộ chứa container có thể dùng chung một thư mục mà không cần lớp đồng bộ tùy biến.

Sự quen thuộc này chính là chìa khóa. Các đội ngũ kỹ thuật có thể xây dựng kiến trúc điều phối đa tác nhân từ chính những nguyên thủy hạ tầng mà các kỹ sư đã thuần thục, không phải học thêm một dịch vụ hoàn toàn xa lạ để vận hành.

Việc so sánh giải pháp này với một mô hình liên quan của AWS sẽ giúp làm sáng tỏ bức tranh: vào tháng 6 năm 2026, AWS đã công bố Amazon S3 Vectors như một bộ nhớ dài hạn cho các hệ thống đa tác nhân, lưu trữ các vector embedding phục vụ truy hồi ngữ nghĩa. Hai giải pháp này bổ trợ cho nhau chứ không cạnh tranh: S3 Vectors trả lời câu hỏi 'tác nhân nhớ được những gì tương tự với ngữ cảnh hiện tại?', còn S3 Files trả lời câu hỏi 'các tác nhân đặt trạng thái dùng chung và các tài sản chuyển giao ở đâu?'. Một hệ thống chuyên nghiệp hoàn toàn có thể kết hợp cả hai.

Tại sao cửa sổ ngữ cảnh phình to lại phá vỡ việc điều phối đa tác nhân?

Cơ chế chuyển giao qua cửa sổ ngữ cảnh bị phá vỡ vì từng tác nhân phải gánh lại toàn bộ những gì cả đường ống đã tích lũy từ đầu đến thời điểm đó. Khi một tác nhân làm giàu dữ liệu khách hàng tiềm năng chuyển giao kết quả cho một tác nhân phân loại ý định, và tác nhân đó lại chuyển tiếp cho một tác nhân viết nội dung, dung lượng prompt sẽ phình to sau mỗi bước. Số lượng token đầu vào tăng vọt, độ trễ kéo dài và chi phí leo thang, tất cả diễn ra trước khi một quyết định hữu ích thực sự được tạo ra. Toàn bộ đường ống phải trả tiền chỉ để đọc lại lịch sử của chính mình sau mỗi chặng chuyển giao.

Điều này còn gây thiệt hại nặng nề về độ tin cậy. Khi các tác nhân chỉ có thể nhìn thấy những gì nhét vừa trong một prompt, chúng dễ dàng mất dấu những gì các tác nhân đồng đội đã xử lý trước đó, dẫn đến việc trùng lặp công việc, đưa ra các kết luận mâu thuẫn hoặc hành động dựa trên dữ liệu cũ.

Một lớp tệp dùng chung thay đổi hoàn toàn mặc định này: các tác nhân đọc trạng thái mới nhất từ một thư mục xác định thay vì đặt niềm tin vào một bản tóm tắt được ai đó dán vào prompt. Đó là một thay đổi nhỏ nhưng mang lại tác động khổng lồ cho việc điều phối đa tác nhân: nguồn sự thật duy nhất không còn nằm trôi nổi bên trong một prompt tạm thời. Bảng dưới đây đối chiếu hai phương thức chuyển giao.

Điều phối đa tác nhân thay đổi hoạt động tiếp thị và bán hàng như thế nào?

Đối với các quy trình tiếp thị và bán hàng tự chủ, lớp tệp dùng chung biến những lượt chuyển giao prompt lộn xộn thành các bước bàn giao thư mục ngăn nắp. Phần này là phân tích chuyên sâu từ Vanaxity: AWS cung cấp mô hình lưu trữ, và chúng tôi ánh xạ mô hình đó vào cách các chiến dịch tự động vận hành trong thực tế. Hãy xem xét một quy trình bốn tác nhân phổ biến: làm giàu dữ liệu khách hàng tiềm năng, phân loại ý định, soạn thảo nội dung và kiểm duyệt tuân thủ trước khi xuất bản.

Với một lớp tệp dùng chung, mỗi tác nhân chỉ ghi dữ liệu vào thư mục riêng của mình và đọc dữ liệu đầu vào từ giai đoạn liền trước. Tác nhân làm giàu dữ liệu ghi một hồ sơ khách hàng chuẩn hóa. Tác nhân phân loại ý định đọc hồ sơ đó và ghi ra điểm số đánh giá ý định mua hàng.

Tác nhân viết nội dung đọc cả hai tệp trên và tạo ra các phương án thông điệp. Tác nhân kiểm duyệt tuân thủ đọc các bản thảo và ghi kết quả phê duyệt hoặc từ chối. Không có tác nhân nào phải gánh toàn bộ lịch sử chiến dịch trong prompt của mình, và mỗi bước chuyển giao đều để lại một sản phẩm tệp cụ thể có thể kiểm tra được. Đó chính là yếu tố giúp việc điều phối đa tác nhân trở nên minh bạch và có thể kiểm toán thay vì là một chiếc hộp đen mờ mịt.

• Làm giàu dữ liệu khách hàng tiềm năng: ghi hồ sơ có cấu trúc vào thư mục riêng của từng khách hàng thay vì trả về một khối JSON khổng lồ nhồi vào prompt tiếp theo.
• Phân loại ý định: đọc hồ sơ, ghi nhận điểm số ý định và lý do đánh giá, giữ cho quá trình suy luận phức tạp không tràn vào các prompt phía sau.
• Soạn thảo nội dung động: đọc hồ sơ và ý định, ghi các biến thể nội dung vào thư mục bản nháp để tác nhân tuân thủ dễ dàng rà soát.
• Kiểm duyệt tuân thủ: đọc các bản nháp, ghi xác nhận phê duyệt hoặc ngăn chặn kèm lý do, lưu lại dấu vết kiểm toán đầy đủ cho các chiến dịch chịu sự quản lý chặt chẽ.

Tác động kinh doanh rất rõ ràng: việc loại bỏ các cửa sổ ngữ cảnh phình to giúp giảm mạnh chi phí token và hạ độ trễ suy luận, trong khi khả năng phân quyền thư mục chi tiết giúp giữ dữ liệu khách hàng nhạy cảm nằm đúng phạm vi của những tác nhân cần nó. Đó là cùng kỷ luật mà Vanaxity áp dụng cho AI tác nhân trong tiếp thị: hãy thiết kế các bước chuyển giao và ranh giới an toàn trước tiên, sau đó mới để các tác nhân tự do vận hành.

Ví dụ thực tế: Một chiến dịch tiếp cận khách hàng tự động

Dưới đây là cách mô hình vận hành trong một quy trình công việc thực tế. Giả sử một đội ngũ bán hàng triển khai một chiến dịch tiếp cận tự động: nghiên cứu một tài khoản doanh nghiệp, đánh giá mức độ phù hợp, soạn email tiếp cận đầu tiên và kiểm tra đối chiếu với quy định thương hiệu và pháp lý. Quy trình này gồm bốn tác nhân, và nếu chỉ dùng prompt đơn thuần, mỗi tác nhân sẽ phải gửi tiếp toàn bộ công việc của tác nhân trước, khiến bước kiểm duyệt cuối cùng phải suy luận trên một prompt chứa đầy mọi ghi chép trung gian.

Trên một lớp tệp dùng chung, cùng chiến dịch đó duy trì được sự tinh gọn tuyệt đối: mỗi giai đoạn sở hữu một thư mục riêng, ghi một tệp sản phẩm nhỏ gọn có tên định danh và phát tín hiệu hoàn tất. Tác nhân kiểm duyệt chỉ cần đọc bản nháp email và các dữ kiện doanh nghiệp cần thiết, chứ không phải một bản ghi dài dằng dặc về mọi suy nghĩ trước đó. Nếu chiến dịch gặp trục trặc, bạn không cần phải chạy lại một chiếc hộp đen bí ẩn; bạn chỉ cần mở thư mục và nhìn thấy chính xác tệp sản phẩm nào đã bị sai lệch. Khả năng thanh tra trực quan đó chính là thứ biến một bản demo công nghệ thành một hệ thống thực sự vận hành được cho đội ngũ doanh thu.

• Tác nhân nghiên cứu: ghi tệp account_facts.json vào thư mục đầu vào của tài khoản.
• Tác nhân đánh giá: đọc các dữ kiện, ghi điểm số phù hợp và lý do ngắn gọn, đồng thời dừng chiến dịch nếu điểm số dưới ngưỡng.
• Tác nhân soạn thảo: đọc dữ kiện và điểm số, ghi một hoặc nhiều bản nháp email vào thư mục bản nháp.
• Tác nhân kiểm duyệt: đọc các bản nháp, ghi tệp approved.txt hoặc blocked.txt kèm lý do, lưu lại dấu vết rõ ràng để kiểm tra sau này.

Đâu là những lưu ý quan trọng về vận hành và chi phí?

Lớp tệp dùng chung loại bỏ một vấn đề nhưng đặt ra những quyết định mới. Hệ thống tệp trở thành trạng thái dùng chung, nên cấu trúc, quy tắc truy cập và việc giữ cho nó gọn gàng giờ đây quan trọng không kém bất kỳ lựa chọn mô hình nào. Hãy xem cách bố trí thư mục như một hợp đồng API giữa các tác nhân và quản lý phiên bản cho nó giống như một hợp đồng API.

• Kiểm soát truy cập: phân quyền cho từng tác nhân đúng các thư mục nó cần, để tác nhân viết bài không thể đọc các ghi chú tuân thủ nhạy cảm mà nó không có thẩm quyền.
• Tính cô lập: duy trì trạng thái của từng khách hàng tiềm năng hoặc chiến dịch trong các thư mục riêng biệt, đảm bảo lượt chạy này không thể làm hỏng hoặc rò rỉ dữ liệu sang lượt chạy khác.
• Quy ước chuyển giao: thống nhất rõ ràng về tên tệp, định dạng dữ liệu và dấu hiệu hoàn tất, vì thiếu quy ước sẽ biến sự phối hợp thành trò chơi phỏng đoán.
• Quản trị dữ liệu: áp dụng chính sách lưu trữ và xóa bỏ cho các tệp dùng chung, vì dữ liệu khách hàng giờ đây tồn tại lâu dài trên đĩa lưu trữ, không chỉ nằm trong các prompt tạm thời.
• Khả năng quan sát: ghi nhật ký mọi lượt đọc và ghi để bạn có thể truy vết chính xác tác nhân nào đã tạo ra tài sản nào khi một chiến dịch gặp lỗi.

Đây là các bài toán quản trị, không chỉ đơn thuần là kỹ thuật. Các tác nhân tự chủ ghi các tệp tồn tại lâu dài cần nhận được sự kiểm soát tương tự như bất kỳ hệ thống nào tiếp xúc với dữ liệu khách hàng, một nguyên tắc mà chúng tôi nhấn mạnh trong cẩm nang quản trị tiếp thị AI.

Khía cạnh chi phí cũng là điểm dễ bị bỏ qua: lớp tệp dùng chung loại bỏ sự lãng phí token, nhưng không làm chi phí biến mất hoàn toàn; nó chuyển một phần chi phí sang dung lượng lưu trữ và các thao tác đọc ghi I/O. Đây thường là một sự đánh đổi rất có lợi, vì chi phí thao tác tệp rẻ hơn nhiều so với việc gửi đi gửi lại một prompt ngày càng dài qua mô hình ngôn ngữ ở mỗi chặng.

Tuy nhiên, bạn nên đo lường cụ thể thay vì suy đoán cảm tính: theo dõi lượng chi phí token bạn đã cắt giảm được so với chi phí lưu trữ và I/O tăng thêm, và quan sát xem sự cân bằng đó thay đổi như thế nào khi nhiều đường ống cùng chạy một lúc. Mục tiêu của việc điều phối đa tác nhân trên lớp tệp không chỉ là một kiến trúc đẹp mắt; đó là chi phí trên mỗi chiến dịch hoàn thành phải thấp hơn và dễ dự đoán hơn, và bạn chỉ biết chắc mình đạt được điều đó khi đo lường đầy đủ cả hai mặt của bài toán.

Các đội ngũ nên bắt đầu điều phối đa tác nhân từ đâu?

Hãy bắt đầu với một đường ống duy nhất, không phải toàn bộ nền tảng. Chọn một quy trình tự chủ đơn lẻ nơi các tác nhân hiện đang chuyển giao công việc cho nhau, sau đó chuyển bước chuyển giao đó ra khỏi prompt và đưa vào một thư mục dùng chung. Chứng minh tính hiệu quả của mô hình trên một phạm vi khép kín và có thể đảo ngược trước khi xây dựng lại mọi thứ xung quanh nó.

• Lập bản đồ các bước chuyển giao hiện tại: liệt kê từng tác nhân, những gì nó cần làm đầu vào và những gì nó tạo ra làm đầu ra.
• Thiết kế cấu trúc thư mục: cung cấp cho từng giai đoạn một thư mục đầu vào và đầu ra riêng, đồng thời xác định rõ định dạng tệp và dấu hiệu báo hoàn tất.
• Thiết lập kiểm soát truy cập ngay từ đầu: chỉ cấp cho từng tác nhân phạm vi đọc và ghi hẹp nhất vừa đủ để hoàn thành nhiệm vụ.
• Đo lường trước và sau khi thay đổi: theo dõi chi phí token cho prompt, độ trễ từ đầu đến cuối và tỷ lệ lỗi trên cùng một khối lượng công việc.
• Bổ sung khả năng quan sát: ghi nhật ký mọi lượt đọc và ghi để bạn có thể tái dựng lại toàn bộ lượt chạy khi có sự cố phát sinh.
• Chỉ mở rộng khi quy trình đã ổn định: chuyển đường ống tiếp theo sang mô hình mới sau khi đường ống đầu tiên chứng minh được hiệu quả rẻ hơn, nhanh hơn và dễ gỡ lỗi hơn.

Mục tiêu không phải là tạo ra thêm nhiều hoạt động tác nhân vô nghĩa, mà là giảm bớt các bất ngờ rủi ro và hạ thấp chi phí trên mỗi chiến dịch hoàn thành. Đo lường chi phí trên mỗi kết quả kinh doanh cũng chính là lăng kính chúng tôi áp dụng trong nghiên cứu về FinOps cho tác nhân AI.

Cách Vanaxity đưa điều phối đa tác nhân vào vận hành thực tế

Vanaxity xem bộ nhớ dùng chung là hạ tầng cốt lõi cho tiếp thị và bán hàng tự chủ, không phải một giải pháp nghĩ đến sau cùng. Chúng tôi bắt đầu bằng việc lập bản đồ các luồng tiếp nhận, quyết định, công cụ và các điểm chuyển giao đang định hình quy trình của bạn. Sau đó, chúng tôi xác định rõ những gì từng tác nhân được làm, những gì bắt buộc phải ghi ra tệp, khi nào phải dừng lại và ai chịu trách nhiệm đánh giá trước khi kết nối hệ thống với lớp tệp chia sẻ.

Nếu bạn muốn đưa kiến trúc này vào vận hành thực tế, các dịch vụ của chúng tôi có thể cung cấp bản đồ chuyển giao, thiết kế cấu trúc thư mục và phân quyền truy cập, thiết lập đường cơ sở chi phí và độ trễ, cùng kế hoạch triển khai cụ thể cho đường ống tác nhân của bạn. Bạn cũng có thể tìm hiểu thêm các ghi chép thực tế trong thư viện góc nhìn. Mục tiêu là tạo ra một tập hợp các chiến dịch mà đội ngũ của bạn thực sự tin tưởng, vận hành ở quy mô doanh nghiệp mà không bị gánh nặng token cản trở.

Toàn bộ quy trình này không đòi hỏi bạn phải đập đi xây lại toàn bộ hệ thống ngay lập tức. Hãy bắt đầu từ đường ống đang gây tốn kém và nhức nhối nhất hiện nay, chuyển các điểm bàn giao của nó vào một thư mục dùng chung, và để số liệu thực tế quyết định bước đi tiếp theo. Đó là cách một kiến trúc điều phối đa tác nhân bền vững được tạo dựng: từng thay đổi được đo lường cẩn trọng, kiểm chứng trên các chiến dịch thực tế trước khi mở rộng phạm vi, thay vì một canh bạc công nghệ mạo hiểm không thể đảo ngược.

Câu hỏi thường gặp

Nguồn tham khảo