Thủ thuật
Anthropic công bố hướng dẫn xây dựng AI Agent cho thương mại điện tử
(giờ Việt Nam)
Tóm tắt AI
Anthropic chia sẻ lộ trình tối ưu hóa kiến trúc, chi phí và vận hành cho AI Agent trong ngành thương mại điện tử, kèm mã nguồn mở giúp doanh nghiệp tăng hiệu suất vận hành và trải nghiệm mua sắm.
Bản dịch AI

Trong suốt năm qua, chúng tôi đã làm việc với các đội ngũ trong ngành thương mại — bao gồm các nhà bán lẻ, sàn thương mại điện tử, du lịch, giải trí và các nhà cung cấp viễn thông — để xây dựng các commerce agent (tác nhân thương mại) sử dụng Claude.
Các tác nhân này đã được đưa vào vận hành thực tế, và các khách hàng doanh nghiệp đã ghi nhận giá trị đơn hàng lớn hơn cùng hiệu suất vận hành của người bán tốt hơn khi sử dụng chúng. Chúng cũng chia sẻ một kiến trúc đơn giản: Claude nằm trong một vòng lặp tác nhân (agent loop) được trang bị các kỹ năng, công cụ và bộ đánh giá (eval suite) mạnh mẽ.
Bài viết này dành cho các kỹ sư và lãnh đạo kỹ thuật đang xây dựng các tác nhân này (hoặc các tác nhân hướng tới người tiêu dùng khác). Phần 1 đề cập đến kiến trúc, thứ mà bạn chỉ cần quyết định một lần. Phần 2 đề cập đến độ trễ và chi phí. Phần 3 đề cập đến việc vận hành thực tế: bộ nhớ, tính an toàn, đánh giá và mở rộng quy mô công việc trong toàn tổ chức.
Triển khai tham chiếu
Chúng tôi cũng cung cấp một bản thiết kế (blueprint) để giúp xây dựng các commerce agent trên Claude. Nó chứa các bộ khung (harnesses), mô hình (patterns) và các rào cản kỹ thuật (guardrails) mà một đội ngũ kỹ thuật cần để đưa một commerce agent vào hoạt động chỉ trong vài ngày, cùng với các triển khai tham chiếu cho tác nhân mua sắm và tác nhân người bán dành cho các nền tảng bán lẻ, du lịch, viễn thông và đặt vé.
anthropics/commerce-agents →
Trong hướng dẫn này
Phần 1: Kiến trúc
Phần 2: Tối ưu tốc độ và chi phí
Phần 3: Vận hành thực tế
01
Kiến trúc
Một mô hình trong vòng lặp tác nhân tiêu chuẩn, với các kỹ năng cho các trường hợp ít phổ biến (long tail) và các công cụ gọi đến những hệ thống bạn đang vận hành. Bạn chỉ cần quyết định điều này một lần.
Commerce agent là gì?
Chúng tôi định nghĩa commerce agent là một tác nhân giúp đơn giản hóa việc mua và bán trên một danh mục trực tuyến.
Một số tác nhân hướng tới người tiêu dùng: chúng tìm kiếm, so sánh, thay thế và tập hợp đơn hàng. Đó có thể là giỏ hàng bán lẻ, hành trình du lịch, thay đổi gói cước di động hoặc giữ chỗ cho một buổi biểu diễn. Một số tác nhân hướng tới doanh nghiệp: chúng trả lời các câu hỏi về doanh số, chạy các chương trình khuyến mãi và chiến dịch, cũng như quản lý hàng tồn kho và định giá.

Kiến trúc cốt lõi là một mô hình nằm trong vòng lặp tác nhân tiêu chuẩn: suy luận về mục tiêu, khám phá ngữ cảnh, thực hiện hành động thông qua các công cụ, học các quy trình thông qua kỹ năng, đặt câu hỏi làm rõ và quan sát kết quả cho đến khi mục tiêu hoàn thành.
Không có bộ định tuyến ý định (intent router) nào nằm phía trước để phân đoạn cuộc hội thoại và cũng không có tập hợp các tác nhân chuyên biệt theo lĩnh vực (domain specific agents) nằm phía sau nó.
Bối cảnh kỹ thuật
Kỹ năng, không phải tác nhân phụ (subagents)
Một commerce agent phải bao quát phạm vi năng lực rộng lớn trên nhiều danh mục và ý định, điều này khiến người ta dễ nảy sinh ý định tạo ra mỗi tác nhân phụ cho một lĩnh vực.
Trong thực tế, điều này tỏ ra không tối ưu, vì một cuộc hội thoại thương mại là một phiên làm việc gắn kết chặt chẽ xuyên suốt nhiều ý định và lượt tương tác, đòi hỏi sự chia sẻ ngữ cảnh đáng kể.
Trong kiến trúc tác nhân phụ, bộ điều phối (orchestrator) nắm giữ giỏ hàng hoặc các thay đổi tạm thời, sở thích của người dùng và lịch sử cuộc hội thoại.
Mỗi lần chuyển giao cho một tác nhân phụ là một thao tác gây mất trạng thái (state-lossy), thường ảnh hưởng đến chất lượng phản hồi của tác nhân phụ và kéo theo đó là chất lượng phản hồi tổng thể. Hơn nữa, mỗi lần chuyển giao có thể tiêu tốn lượng token gấp nhiều lần và làm tăng độ trễ thêm vài giây.
Các lĩnh vực cũng hiếm khi tách biệt hoàn toàn. Một quy trình trả hàng có thể cần lịch sử đơn hàng, giỏ hàng hiện tại và danh mục sản phẩm, nghĩa là cách tiếp cận mỗi lĩnh vực một tác nhân phụ sẽ dẫn đến việc hoặc là sao chép quyền truy cập đó ở khắp nơi, hoặc là phải chuyển giao giữa chừng khi đang thực hiện tác vụ.
Khi các mô hình trở nên thông minh hơn, chúng cũng xử lý ngữ cảnh dài hơn, nhiều kỹ năng hơn và nhiều công cụ hơn, vì vậy các giới hạn đằng sau các quy tắc phân bổ hiện nay đang dần nới lỏng theo từng thế hệ mô hình.
Thay vào đó, các kỹ năng của tác nhân (agent skills) mang lại cho bạn tính mô-đun và khả năng kiểm soát ngữ cảnh tương tự theo từng lĩnh vực mà không phải trả "thuế" chuyển giao, vì các hướng dẫn kỹ năng được tải vào tác nhân chính vốn đã nắm giữ toàn bộ lịch sử.
Trong các so sánh của chúng tôi trên nhiều triển khai doanh nghiệp, một tác nhân duy nhất với các kỹ năng luôn vượt trội hơn cả thiết kế "một prompt cho tất cả" và thiết kế tác nhân phụ về mặt chất lượng, đồng thời thường có chi phí và độ trễ thấp hơn trên mỗi tác vụ.
Tác nhân phụ chỉ thực sự phát huy tác dụng khi bộ điều phối có thể gọi chúng như một công cụ cho một tác vụ hẹp hoặc khép kín, vốn sẽ được hưởng lợi từ cửa sổ ngữ cảnh chuyên dụng của riêng nó.
Một ví dụ thực tế phổ biến là tác nhân phụ nghiên cứu chuyên sâu, nơi tác nhân phụ tìm kiếm và đọc tài liệu, viết và chạy mã, duyệt qua các mô hình dữ liệu và xử lý các ngõ cụt. Tất cả công việc diễn ra bên trong một hoặc nhiều tác nhân phụ, và chỉ một câu trả lời cô đọng được gửi ngược lại cho bộ điều phối.
Ngoại lệ khác là một lĩnh vực đã có sẵn tác nhân được xây dựng cho mục đích riêng. Nếu trải nghiệm dược phẩm hoặc dịch vụ tài chính của bạn đang vận hành một tác nhân chuyên dụng với bề mặt tuân thủ riêng, thì bước đi đúng đắn có thể là chuyển giao, nơi tác nhân đó tiếp quản tác vụ và làm việc trực tiếp với người dùng thông qua vòng lặp riêng của nó cho đến khi tác vụ hoàn tất.
Sự khác biệt nằm ở quyền sở hữu cuộc hội thoại. Việc chuyển giao (hand-off) biến tác nhân lĩnh vực thành đối tác của người dùng, trong khi việc ủy quyền (delegation) vẫn giữ bộ điều phối làm trung tâm, đẩy tác nhân lĩnh vực ra vào trong một lượt tương tác duy nhất và làm giảm chất lượng sau mỗi lần trao đổi.
System prompt hay kỹ năng: quyết định dựa trên tần suất
Yếu tố chính khi quyết định đặt một tập hợp hướng dẫn vào system prompt hay kỹ năng là tần suất tác nhân cần đến chúng. Việc tải một kỹ năng tiêu tốn một lượt gọi mô hình, vì vậy bất cứ thứ gì tác nhân cần trong hầu hết các lượt tương tác thường nên nằm trong system prompt.
Tuy nhiên, điều này phụ thuộc vào cách lưu lượng truy cập của bạn được phân bổ và hành vi tác nhân mà các đánh giá của bạn cho thấy. Một điểm khởi đầu tốt là bất cứ thứ gì liên quan đến một phần ba hoặc nhiều hơn lưu lượng truy cập của bạn, dù đã dự đoán trước khi ra mắt hay quan sát được trong quá trình vận hành, đều nên đưa vào system prompt, phần còn lại đưa vào các kỹ năng.
Nếu một kỹ năng có thể dự đoán được từ một tín hiệu bạn đã có, chẳng hạn như trang mà người dùng vừa truy cập, chúng tôi khuyên bạn nên đưa nó vào từ bộ khung (harness) trước lần gọi mô hình đầu tiên và bỏ qua lượt tương tác bổ sung để tải kỹ năng.
Các hướng dẫn quan trọng, chẳng hạn như quy tắc an toàn và pháp lý, các ràng buộc về thương hiệu và các thông tin chính của người dùng như dị ứng, luôn phải nằm trong system prompt.
Đối với các commerce agent, điều này có nghĩa là tìm kiếm sản phẩm sẽ nằm trong prompt, vì gần như mọi phiên làm việc đều cần đến nó, còn các kỹ năng sẽ đảm nhận các tính năng ít phổ biến hơn.
Bài viết được AI dịch và tổng hợp tự động từ Claude: Blog (Web). Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.