12-Factor Agents – Các nguyên tắc xây dựng ứng dụng LLM đáng tin cậy

12-Factor Agents - Các nguyên tắc xây dựng ứng dụng LLM đáng tin cậy Với tinh thần của 12 Factor Apps. Mã nguồn của dự án này được công khai tại https://github.com/humanlayer/12-factor-agents, và tôi hoan nghênh mọi phản hồi cũng như đóng góp của quý vị. Chúng ta hãy cùng nhau tìm hiểu vấn đề này. Mẹo Bạn đã bỏ lỡ Hội chợ AI Engineer World's Fair? Hãy xem bài nói chuyện tại đây. Bạn đang tìm kiếm Context Engineering? Chuyển thẳng đến yếu tố 3. Bạn muốn đóng góp cho npx/uvx create-12-factor-agent - hãy xem chủ đề thảo luận. Xin chào, tôi là Dex. Tôi đã nghiên cứu các tác nhân AI (AI agents) một thời gian. Tôi đã thử mọi framework tác nhân hiện có, từ các công cụ plug-and-play như crew/langchains đến các smolagents "tối giản" và các công cụ "cấp độ sản xuất" như langraph, griptape, v.v. Tôi đã trò chuyện với nhiều nhà sáng lập rất tài năng, cả trong và ngoài YC, những người đang xây dựng những sản phẩm AI thực sự ấn tượng. Hầu hết họ tự phát triển toàn bộ hệ thống. Tôi không thấy nhiều framework được sử dụng trong các tác nhân hướng đến khách hàng trong môi trường sản xuất. Tôi ngạc nhiên khi nhận thấy hầu hết các sản phẩm tự quảng cáo là "AI Agents" lại không thực sự có tính tác nhân cao. Nhiều sản phẩm trong số đó chủ yếu là mã code mang tính xác định, với các bước LLM được lồng ghép vào đúng những điểm cần thiết để tạo ra trải nghiệm thực sự kỳ diệu. Các tác nhân, ít nhất là những tác nhân tốt, không tuân theo mô hình "đây là lời nhắc của bạn, đây là một bộ công cụ, lặp lại cho đến khi đạt được mục tiêu". Thay vào đó, chúng chủ yếu bao gồm phần mềm. Vì vậy, tôi đã đặt ra câu hỏi: Những nguyên tắc nào chúng ta có thể sử dụng để xây dựng phần mềm được hỗ trợ bởi LLM đủ tốt để đưa vào tay khách hàng trong môi trường sản xuất? Chào mừng đến với 12-factor agents. Như mọi thị trưởng Chicago kể từ Daley đã liên tục dán khắp các sân bay lớn của thành phố, chúng tôi rất vui khi bạn có mặt ở đây. Xin gửi lời cảm ơn đặc biệt đến @iantbutler01, @tnm, @hellovai, @stantonk, @balanceiskey, @AdjectiveAllison, @pfbyjy, @a-churchill, và cộng đồng SF MLOps vì những phản hồi sớm về hướng dẫn này. Phiên bản tóm tắt: 12 yếu tố Ngay cả khi các LLM tiếp tục mạnh mẽ hơn theo cấp số nhân, sẽ có những kỹ thuật kỹ thuật cốt lõi giúp phần mềm được hỗ trợ bởi LLM đáng tin cậy hơn, có khả năng mở rộng hơn và dễ bảo trì hơn. Chúng ta đã đến đây như thế nào: Lịch sử tóm tắt về phần mềm Yếu tố 1: Ngôn ngữ tự nhiên đến các lệnh gọi công cụ (Tool Calls) Yếu tố 2: Làm chủ các lời nhắc (prompts) của bạn Yếu tố 3: Làm chủ cửa sổ ngữ cảnh (context window) của bạn Yếu tố 4: Các công cụ chỉ là đầu ra có cấu trúc Yếu tố 5: Thống nhất trạng thái thực thi và trạng thái nghiệp vụ Yếu tố 6: Khởi chạy/Tạm dừng/Tiếp tục với các API đơn giản Yếu tố 7: Liên hệ với con người bằng các lệnh gọi công cụ Yếu tố 8: Làm chủ luồng điều khiển của bạn Yếu tố 9: Nén lỗi vào cửa sổ ngữ cảnh Yếu tố 10: Các tác nhân nhỏ, tập trung Yếu tố 11: Kích hoạt từ mọi nơi, tiếp cận người dùng ở nơi họ đang ở Yếu tố 12: Biến tác nhân của bạn thành một bộ giảm tốc không trạng thái (stateless reducer) Điều hướng trực quan Chúng ta đã đến đây như thế nào Để tìm hiểu sâu hơn về hành trình tác nhân của tôi và điều gì đã dẫn chúng ta đến đây, hãy xem Lịch sử tóm tắt về phần mềm - một bản tóm tắt nhanh tại đây: Lời hứa của các tác nhân Chúng ta sẽ nói nhiều về Đồ thị có hướng (Directed Graphs - DGs) và các đồ thị không chu trình (Acyclic friends - DAGs). Tôi sẽ bắt đầu bằng cách chỉ ra rằng... phần mềm là một đồ thị có hướng. Có một lý do tại sao chúng ta từng biểu diễn các chương trình dưới dạng sơ đồ khối. Từ mã code đến DAGs Khoảng 20 năm trước, chúng ta bắt đầu thấy các bộ điều phối DAG trở nên phổ biến. Chúng ta đang nói đến những công cụ kinh điển như Airflow, Prefect, một số công cụ tiền nhiệm và một số công cụ mới hơn như (dagster, inggest, windmill). Chúng tuân theo cùng một mô hình đồ thị, với lợi ích bổ sung là khả năng quan sát, tính mô-đun, khả năng thử lại, quản trị, v.v. Lời hứa của các tác nhân Tôi không phải là người đầu tiên nói điều này, nhưng điều tôi nhận ra lớn nhất khi bắt đầu tìm hiểu về các tác nhân (agent) là bạn có thể loại bỏ DAG (Directed Acyclic Graph - Đồ thị có hướng không chu trình). Thay vì các kỹ sư phần mềm phải mã hóa từng bước và từng trường hợp đặc biệt, bạn có thể giao cho tác nhân một mục tiêu và một tập hợp các chuyển đổi: Và để LLM đưa ra quyết định theo thời gian thực để tìm ra lộ trình. Lời hứa ở đây là bạn viết ít phần mềm hơn, bạn chỉ cần cung cấp cho LLM các "cạnh" của đồ thị và để nó tự tìm ra các "nút". Bạn có thể phục hồi sau lỗi, viết ít mã hơn và có thể thấy rằng LLM tìm ra các giải pháp mới lạ cho vấn đề. Các tác nhân dưới dạng vòng lặp Như chúng ta sẽ thấy sau này, hóa ra điều này không hoàn toàn hiệu quả. Hãy đi sâu hơn một bước – với các tác nhân, bạn có một vòng lặp gồm 3 bước: LLM xác định bước tiếp theo trong quy trình làm việc, xuất ra JSON có cấu trúc ("gọi công cụ"). Mã xác định thực thi lệnh gọi công cụ. Kết quả được thêm vào cửa sổ ngữ cảnh. Lặp lại cho đến khi bước tiếp theo được xác định là "hoàn thành". initial_event = {"message": "..."} context = [initial_event] while True: next_step = await llm.determine_next_step(context) context.append(next_step) if (next_step.intent === "done"): return next_step.final_answer result = await execute_step(next_step) context.append(result) Ngữ cảnh ban đầu của chúng ta chỉ là sự kiện khởi đầu (có thể là một tin nhắn người dùng, một cron được kích hoạt, một webhook, v.v.), và chúng ta yêu cầu LLM chọn bước tiếp theo (công cụ) hoặc xác định rằng chúng ta đã hoàn thành. Dưới đây là một ví dụ nhiều bước: 027-agent-loop-animation.mp4 Phiên bản GIF Tại sao lại là các tác nhân 12 yếu tố? Cuối cùng, cách tiếp cận này không hoạt động tốt như chúng ta mong muốn. Trong quá trình xây dựng HumanLayer, tôi đã nói chuyện với ít nhất 100 nhà phát triển SaaS (chủ yếu là các nhà sáng lập kỹ thuật) đang tìm cách làm cho sản phẩm hiện có của họ trở nên "agentic" hơn. Hành trình thường diễn ra như sau: Quyết định muốn xây dựng một tác nhân. Thiết kế sản phẩm, lập bản đồ UX, xác định vấn đề cần giải quyết. Muốn tiến độ nhanh, nên chọn một $FRAMEWORK và bắt đầu xây dựng. Đạt đến mức chất lượng 70-80%. Nhận ra rằng 80% là không đủ tốt cho hầu hết các tính năng hướng tới khách hàng. Nhận ra rằng để vượt qua 80% đòi hỏi phải đảo ngược kỹ thuật (reverse-engineering) framework, lời nhắc (prompt), luồng, v.v. Bắt đầu lại từ đầu. Tuyên bố miễn trừ trách nhiệm ngẫu nhiên TUYÊN BỐ MIỄN TRỪ TRÁCH NHIỆM: Tôi không chắc đâu là nơi thích hợp nhất để nói điều này, nhưng ở đây có vẻ tốt như bất kỳ nơi nào khác: điều này KHÔNG HỀ có ý chỉ trích các framework hiện có, hay những người rất thông minh đã làm việc trên chúng. Chúng cho phép những điều đáng kinh ngạc và đã thúc đẩy hệ sinh thái AI. Tôi hy vọng một kết quả của bài đăng này là...