Human-in-the-Loop Automation with n8n — Liam McGarrigle

• NADN là một công cụ mạnh mẽ, kết hợp giao diện trực quan cho quy trình làm việc với khả năng mở rộng linh hoạt bằng mã nguồn JavaScript, cho phép người dùng xây dựng và điều phối các tác nhân AI mà không cần chuyên sâu về code.
• Workshop tập trung vào việc tạo tác nhân AI quản lý Gmail và lịch, nhấn mạnh khả năng quan sát và kiểm soát chi tiết các hoạt động của tác nhân trong NADN để dễ dàng điều chỉnh và khắc phục lỗi.
• Nền tảng này giải quyết vấn đề bộ nhớ cố hữu của tác nhân AI thông qua các giải pháp tích hợp như "Simple Memory" hoặc kết nối cơ sở dữ liệu, giúp tác nhân duy trì ngữ cảnh trò chuyện hiệu quả.

• NADN cho phép xây dựng quy trình làm việc và tác nhân AI bằng giao diện trực quan, đồng thời hỗ trợ mở rộng logic bằng JavaScript ngay trong các trường hoặc thông qua các "node code" chuyên biệt.
• Mọi quy trình làm việc trong NADN đều bắt đầu bằng một bộ kích hoạt (trigger) như biểu mẫu, lịch trình, webhook, gọi API, hoặc bộ kích hoạt trò chuyện (chat trigger).
• Khi tích hợp tác nhân AI, hãy sử dụng nút tác nhân AI và kết nối với một Mô hình Ngôn ngữ Lớn (LLM) được hỗ trợ (ví dụ: OpenRouter, OpenAI) hoặc cấu hình base URL cho các nhà cung cấp khác.
• Để tác nhân AI có bộ nhớ (memory) và duy trì ngữ cảnh trò chuyện, hãy kích hoạt tab "memory" trong nút tác nhân AI, thường dùng "Simple Memory" với cửa sổ ngữ cảnh có thể cấu hình (mặc định 5 tin nhắn).
• Sử dụng biểu thức (expressions) với cú pháp {{ JavaScript_code }} để chèn logic động hoặc truy cập dữ liệu vào bất kỳ trường nào trong NADN.
• Tận dụng chat hub tích hợp trong NADN để kiểm tra, debugging và tương tác trực tiếp với các quy trình làm việc đã xuất bản có bộ kích hoạt trò chuyện.
• NADN hỗ trợ chia sẻ quy trình làm việc dễ dàng bằng cách sao chép và dán JSON của quy trình làm việc.

• workflow — quy trình làm việc
• AI agent — tác nhân AI
• low-code — mã hóa thấp
• orchestration — điều phối / điều hành
• trigger — bộ kích hoạt
• LLM (Large Language Model) — Mô hình Ngôn ngữ Lớn
• memory — bộ nhớ (trong ngữ cảnh AI)
• context — ngữ cảnh
• expression — biểu thức
• credentials — thông tin xác thực

Giới thiệu và Khởi động Workshop

Chào mọi người! Đây có phải là workshop đầu tiên của các bạn trong ngày không? Hay các bạn đã tham gia trước đó rồi? Có vẻ các bạn bận rộn hơn tôi đấy! Rất tốt. Tôi là Liam, một developer advocate tại NADN, có nghĩa là tôi được bay khắp thế giới để làm những điều thú vị như thế này và chia sẻ với những người có lẽ thông minh hơn tôi rất nhiều về những thứ thực sự hay ho. Hôm nay chúng ta có một workshop khá ngắn. Đây có phải là lần đầu tiên mọi người tiếp xúc với NADN không? Mọi người đã từng sử dụng NADN trước đây chưa? Giơ tay lên nào. Mọi người đều đã dùng rồi. À, có người chưa dùng.

Đối với những người đã sử dụng, các bạn tự đánh giá mình ở cấp độ nào? Người dùng mới bắt đầu hay người dùng thành thạo?

>> Luôn là người mới bắt đầu.

>> Được rồi, chúng ta sẽ bắt đầu từ những điều cơ bản ở đây. Về cơ bản, chúng ta sẽ xây dựng như thể đây là quy trình làm việc đầu tiên của bạn. Chúng ta sẽ bắt đầu từ tác nhân cơ bản đó, sau đó thêm yếu tố human in the loop vào. Bạn sẽ được trang bị để mở rộng nó để làm được nhiều việc hơn. Về cơ bản, bạn sẽ tạo một tác nhân quản lý Google Gmail và lịch rất đơn giản, có thể sắp xếp lịch trình cho bạn.

Tôi muốn hỏi về trình độ kỹ thuật của mọi người trong phòng, chỉ ở mức độ khái quát: Bạn có thể viết code được không? Bạn có biết JavaScript không?

>> Có. Không. Có thể. Có.

>> Được rồi.

>> JavaScript.

Sức mạnh của NADN: Công cụ trực quan và khả năng mở rộng bằng mã nguồn

Một trong những điều tuyệt vời về NADN là bạn không cần phải biết viết code để sử dụng. Đây là một công cụ trực quan, nhưng bạn có thể chuyển sang code bất cứ khi nào bạn cần. Ngay cả trực tiếp trong mỗi trường, bạn có thể viết một phương thức JavaScript đơn giản như toUppercase() và nó hoạt động ngay lập tức, phải không? Vì vậy, bạn thậm chí không cần phải tạo một nút code đầy đủ hay mở một file riêng. Bạn có thể làm mọi thứ một cách trực quan, và nếu bạn cần thêm một chút sức mạnh ngay tại chỗ, bạn chỉ cần viết code ngay đó.

Tôi chắc rằng tất cả chúng ta đều có thể thấy bối cảnh hiện tại: vì bạn đang ở đây, bạn có thể đi bất cứ đâu và xây dựng một tác nhân. Việc xây dựng các tác nhân rất dễ dàng, phải không? Một trong những vấn đề chúng ta đang thấy, và cũng là nơi những người chiến thắng sẽ tỏa sáng, là khả năng nhìn thấy tác nhân của bạn có thể làm gì, biết nó đang làm gì, xem xét những gì đã xảy ra sai sót và có thể điều chỉnh, sửa chữa nó. Tôi nghĩ đó thực sự là nơi chúng tôi nổi bật và cũng là nơi chúng tôi bắt đầu, điều này mang lại cho chúng tôi một điểm khởi đầu rất mạnh mẽ với tư cách là công cụ xây dựng và orchestration tác nhân mà bạn có thể nhìn thấy và kiểm soát những gì đang diễn ra.

Tài nguyên Workshop và Hướng dẫn Thiết lập

Tôi xin hứa, tôi ghét slide. Tôi đã xóa gần hết các slide từ template. Đây là những slide duy nhất chúng ta có. Nếu ai đó có thể truy cập liên kết này trên máy tính của mình, nếu bạn bị tụt lại phía sau hoặc muốn thực hiện lại, hoặc đối với những người đang xem video, đây là một trang Notion chứa toàn bộ workshop và thực sự còn giao bài tập về nhà sau đó. Vì vậy, nếu bạn muốn tiếp tục, có những lời nhắc ở đó về cách tiếp tục tác nhân của bạn sau này để giữ cho nó hoạt động, vì chúng ta chỉ có một giờ ở đây, không phải là quá nhiều thời gian.

Có ai còn đang chờ liên kết này không? Được rồi. Tôi luôn có thể quay lại đây nếu cần. Trong đó, bạn sẽ có trang này. Và các bạn có một chút việc phải làm ban đầu để có thể thực sự sử dụng NADN. Vì vậy, bạn có thể truy cập liên kết này ngay tại đây, đăng ký tài khoản NADN Claude. Bạn sẽ tự động nhận được bản dùng thử miễn phí 14 ngày. Thế là đủ cho bây giờ. Bạn không cần phải nâng cấp ngay. Nhưng hãy đảm bảo bạn làm điều này, bạn biết đấy, hôm nay hoặc ngày mai, vì tôi sẽ xóa các code này sau. Tôi đã cấp cho các bạn một năm Claude Pro, trị giá 600 đô la, điều mà chúng tôi không làm thường xuyên. Tôi thích rộng rãi. Vì vậy, các bạn có thể sử dụng nó. Bạn nhận được một năm miễn phí.

Tôi sẽ dành cho các bạn một phút. Nếu bạn đã có phiên bản NADN instance riêng, ví dụ như bạn đã sử dụng nó, nếu bạn sử dụng self-hosted và đã thiết lập thông tin xác thực và mọi thứ, thì rất tốt. Chỉ cần đảm bảo bạn đang ở phiên bản ổn định mới nhất 214.2. Nếu bạn có phiên bản Claude riêng, hãy đảm bảo bạn đã nâng cấp lên đó. Nếu bạn có một hệ thống self-hosted mới và chưa sử dụng nhiều, chỉ cần biết rằng nếu bạn gặp vấn đề liên quan đến cấu hình của mình, tôi rất tiếc không thể thực sự giúp bạn trong phiên này. Nó hơi nằm ngoài phạm vi. Chúng ta phải đảm bảo di chuyển nhanh.

Vì vậy, tôi sẽ dành cho mọi người vài phút để thiết lập. Tôi biết có một bảng câu hỏi và mất một phút để tải.

Những người ở đây dùng NADN, bạn dùng nó ở nơi làm việc hay chỉ cá nhân, cho vui?

>> Cả hai.

Đây có phải là nhận định chung không? Các bạn có phải là những người mang nó đến nơi làm việc của mình không?

>> Đúng vậy.

>> Chẳng hạn.

>> Chẳng hạn.

Tuyệt vời. Tuyệt vời. Nếu các bạn cần giúp đỡ để sử dụng nó tại nơi làm việc, cần giúp thuyết phục sếp, chúng tôi có hai người ở đây chuyên về lĩnh vực đó. Vì vậy, bạn có thể tìm họ để hỏi những câu hỏi chuyên sâu. Bạn có thể hỏi họ những câu hỏi, bạn biết đấy, những câu hỏi "nhàm chán".

>> Chắc chắn rồi.

Một điều nữa tôi muốn đảm bảo là chúng ta không bỏ lại bất cứ ai. Ở đây có một ảnh chụp màn hình về những gì chúng ta sẽ xây dựng. Và ngay tại đây là JSON của quy trình làm việc mà bạn chỉ cần nhấn nút này để sao chép. Điều tuyệt vời, một trong nhiều điều tuyệt vời về NADN, là bạn có thể dễ dàng sao chép và dán mọi thứ vào đó. Vì vậy, bạn có thể sao chép cái này, dán thẳng vào canvas của mình và bạn sẽ có được thành phẩm hoàn chỉnh. Hãy cố gắng làm theo, nhưng bạn có thể quay lại và xem cái này, so sánh, xem tôi đã làm gì. Tôi chắc là tôi đã xây dựng nó tốt hơn ở đây so với khi tôi thực hiện trực tiếp trước mặt các bạn.

Và nếu bạn có câu hỏi, ngay cả khi nó không liên quan trực tiếp, hãy giơ tay hoặc nói to lên và tôi sẽ dừng lại. Tôi thực sự muốn tập trung buổi học này vào việc xây dựng nền tảng vững chắc, đảm bảo mọi người đều có thể tiếp tục và, bạn biết đấy, tự mình mở rộng nó sau này.

Tiến độ thiết lập thế nào rồi? Chúng ta đã gần hoàn thành chưa? Ai chưa thiết lập xong trong NADN, có thể cho tôi thấy cánh tay được không? Mọi người đều đã xong rồi à?

>> (Ví dụ) phiên bản local của tôi là 260.

>> Bạn nên ổn thôi. Chỉ là đã có lúc mọi người tụt lại 60 phiên bản trong một workshop, nhưng nếu bạn self-hosted, bạn có lẽ không cần phiên bản mới nhất.

Giới thiệu Giao diện NADN và Khái niệm Cơ bản về Quy trình làm việc

>> Được rồi, điều đó không sao cả. Tôi sẽ giới thiệu nhanh về NADN. Đây là bản demo. Đối với những người rất mới làm quen với NADN, màn hình này có khó nhìn không? Sẽ khiến tôi rất buồn nhưng tôi có thể bật chế độ sáng.

>> Kinh khủng quá!

>> Được rồi, xin lỗi những người đang xem trên YouTube. Tôi biết các bạn sẽ cảm thấy khó chịu, ít nhất tôi luôn cảm thấy như vậy.

Đây là NADN, đây là giao diện. Nếu bạn dùng self-hosted, bạn sẽ không có những dự án này ở đây. Bạn chỉ có không gian cá nhân của mình, điều đó không sao cả. Trên Claude và enterprise và tất cả những phiên bản đó, bạn sẽ có các dự án cụ thể. Điều thực sự hay về điều đó là bạn có thể có tất cả thông tin xác thực của mình tách biệt. Vì vậy, nếu bạn có một dự án đang làm một việc, một dự án khác đang làm một việc hoàn toàn khác, bạn sẽ không vô tình sử dụng các thông tin xác thực khác nhau và bạn có thể chia sẻ cho những người khác nhau giữa các dự án, bạn biết đấy, để có kiểm soát truy cập tốt.

Chúng ta có thể tạo một quy trình làm việc ở đây và chúng ta sẽ xây dựng nó thủ công. NADN bắt đầu vào năm 2019, trước khi ChatGPT ra đời, khi Trí tuệ nhân tạo còn nhàm chán hơn bây giờ rất nhiều. Và khi đó, nó chỉ là một công cụ tích hợp quy trình làm việc. Vì vậy, nó chỉ là một cách mã hóa thấp để nói: nếu điều này xảy ra thì làm điều đó, rồi làm một điều gì khác.

Ví dụ, bạn có thể có một biểu mẫu, có những bộ kích hoạt này, đúng không? Tôi đang nói trước. Mọi thứ bắt đầu bằng một bộ kích hoạt. Vì vậy, nó có thể là khi một biểu mẫu được gửi, chúng ta có thể nói là "khách hàng tiềm năng", và sau đó đó sẽ là tên. Sau đó, biểu mẫu NADN gốc sẽ hiện lên ở đây và nói: "Tên tôi là Liam," đúng không? Đó là một bộ kích hoạt. Cũng có những thứ như lịch trình và hàng trăm, hàng trăm bộ kích hoạt khác. Có webhook và gọi API và tất cả những thứ tương tự. Vì vậy, bạn có một bộ kích hoạt và sau đó có các hành động - những điều xảy ra trong các ứng dụng khác như Google: tạo một liên hệ, gửi email, và như Salesforce nếu bạn muốn tạo một liên hệ, chỉ đơn giản là kết nối mọi thứ lại với nhau.

Và một trong những điều thực sự mạnh mẽ là luồng kiểm soát, đúng không? Vì vậy, nếu điều này xảy ra thì làm điều đó, bạn có thể có các điều kiện khác nhau. Nếu đây là một liên hệ cá nhân (Google Contacts), một liên hệ kinh doanh, hãy chuyển thẳng vào Salesforce. Và điều này ở đây là thứ mà tôi và rất nhiều người khác đã yêu thích trước khi ChatGPT được phát hành, trước khi tác nhân AI có ý nghĩa gì. Đây là một nền tảng mà mọi người yêu thích để xây dựng mọi thứ và xây dựng các hệ thống tích hợp hoàn chỉnh. Và bạn có thể làm được nhiều hơn những gì bạn mong đợi với nó. Bất cứ ai là nhà phát triển hoặc bất cứ thứ gì, bạn sẽ biết rằng đây về cơ bản chỉ là một phiên bản trừu tượng hóa của việc kết hợp các gọi API. Bạn chỉ đang kết nối mọi thứ, chạy logic với nó.

Xây dựng Quy trình làm việc Tác nhân AI - Tích hợp Trò chuyện

Tất nhiên, bây giờ chúng ta làm điều đó hơi khác một chút. Và bây giờ chúng ta có thể bắt đầu làm theo nếu bạn chưa làm. Lần này chúng ta sẽ xây dựng quy trình làm việc của mình. Bây giờ, chúng ta gần như muốn trò chuyện với mọi thứ. Nó không thực sự là khi điều này xảy ra theo lịch trình hoặc bất cứ điều gì. Giao diện chính của chúng ta rất nhiều là một cuộc trò chuyện hoặc ít nhất là bằng cách nào đó để đưa nó đến Trí tuệ nhân tạo.

Vì vậy, trong một quy trình làm việc mới, chúng ta sẽ mở một bộ kích hoạt trò chuyện và với NADN, bạn có thể tích hợp với nhiều thứ khác nhau, ví dụ như bạn có thể thêm bộ kích hoạt Slack. Vì vậy, Slack, và sau đó trong bộ kích hoạt, ví dụ như khi nhận được tin nhắn, khi tin nhắn được đăng lên kênh, bạn có thể bắt đầu theo cách đó. Ở cuối tài liệu Notion đó, đó là bài tập về nhà của bạn để kết nối nó với hệ thống nhắn tin riêng của bạn. Nhưng hiện tại, chúng ta sẽ sử dụng chat tích hợp sẵn vì nó dễ dàng và đã được xây dựng.

Khi bạn thêm chat vào canvas của mình, bạn sẽ thấy hộp này ở dưới đây. Chúng ta có thể nhập một tin nhắn. Điều này rất tuyệt cho việc debugging và chỉ để kiểm tra khi bạn đang tạo nó vì nó sẽ khởi chạy ngay tại đó. Bạn thậm chí có thể khởi chạy một quy trình làm việc mà không có Trí tuệ nhân tạo nào trong đó.

Điều chúng ta cũng sẽ làm, nếu bạn nhấp vào bộ kích hoạt, có một hộp kiểm tra ghi "make available in chat hub". Điều này tương đối mới và miễn là quy trình làm việc được xuất bản. Khi chúng ta có điều đó, có biểu tượng chat nhỏ này ngay ở thanh bên. Nếu chúng ta nhấp vào đây và đi đến tab, chúng ta thực sự có một giao diện trò chuyện hoàn chỉnh ngay bên trong NADN. Vì vậy, bạn không phải kết nối nó với một công cụ bên ngoài nếu bạn không muốn. Nó chỉ dễ sử dụng hơn ngay tại đây. Tôi nghĩ đó là cái này ở đây.

Đây là bộ kích hoạt trò chuyện mà chúng ta đã đặt vào đó. Vì vậy, nếu chúng ta nói vào đây, "Hello from AI engineer" và gửi, nó không được kết nối với bất cứ thứ gì. Nhưng nếu chúng ta quay lại quy trình làm việc này và đi đến tab thực thi, đây chính là tin nhắn đó. Để tôi kéo cái này sang để bạn có thể thấy hoặc tôi chỉ cần nhấp vào. "Hello from AI engineer". Vì vậy, bạn có thể sử dụng nó ngay bên trong đây. Đó là những gì chúng ta sẽ thiết lập hôm nay trong phiên này, nơi bạn có thể trò chuyện với tác nhân của mình ở đây. Trong tương lai, sau phiên này, bạn có thể thiết lập nó với công cụ chat riêng của mình.

Kết nối Trí tuệ Nhân tạo với Quy trình làm việc

Và tất nhiên, chúng ta cần kết nối Trí tuệ nhân tạo vào đây, đúng không? Vì vậy, bạn có thể nhấp vào dấu cộng nhỏ ở đây, bạn có thể nhấn "N" trên bàn phím của mình hoặc biểu tượng này ở trên. Và chúng ta sẽ tìm kiếm "AI agent".

Và nút tác nhân AI là một loại nút đặc biệt. Bạn có thể thấy nó trông rất khác, với những "chân" nhỏ nhô ra từ phía dưới thay vì bên cạnh. Tác nhân AI cần ba thứ theo mặc định và chỉ một trong số đó là bắt buộc. Chúng ta cần một mô hình trò chuyện. Đây là Mô hình Ngôn ngữ Lớn (LLM). Một lợi ích rất lớn khác của NADN là bạn có thể kết nối bất kỳ Mô hình Ngôn ngữ Lớn nào bạn muốn. Nếu nó không có trong danh sách này, bạn thực sự có thể chọn mô hình OpenAI và thay đổi base URL thành một nhà cung cấp khác, và điều đó thường sẽ hoạt động. Nếu bạn sử dụng proxy hoặc thứ gì đó tương tự cho một doanh nghiệp lớn, đó là cách bạn thực hiện.

Lựa chọn và Cấu hình Mô hình Ngôn ngữ Lớn

Tôi sẽ sử dụng OpenRouter, một dịch vụ có lợi ích rất lớn là bạn có thể chọn bất kỳ mô hình nào bạn muốn. Bạn có thể dùng ChatGPT 3.5, Claude Opus 4.6, hoặc bất kỳ mô hình nào khác mà bạn muốn. Thậm chí còn có một lợi ích lớn hơn: tôi đã cung cấp cho bạn một API key để sử dụng. Tôi sẽ xóa API key này sau hôm nay, nhưng nếu bạn sao chép nó vào Notion (trang mà bạn nên mở), bạn có thể nhấp vào "setup credential" ngay trên tài khoản OpenRouter và dán API key vào, nó sẽ hoạt động.

Khi API key đã được thêm, các mô hình sẽ được tải. Tôi sẽ sử dụng Sonnet 4.6, bạn có thể dùng bất cứ mô hình nào bạn muốn. Hãy chọn một mô hình đủ thông minh để nó biết cách sử dụng các công cụ của bạn. Sau đó, bạn kết nối mô hình đó vào hệ thống. Lưu ý rằng bất kỳ node Mô hình Ngôn ngữ Lớn (LLM) nào bạn sử dụng, bạn phải dùng mã thông báo (token) dành riêng cho nhà cung cấp đó. Ví dụ, bạn không thể dùng mã thông báo của OpenRouter bên ngoài OpenRouter.

Vấn đề về Bộ nhớ của Tác nhân AI

Có ai có câu hỏi gì không? Tất cả đều ổn chứ? Mọi người đã thiết lập tác nhân đến bước này chưa?

Ở giai đoạn này, chúng ta có thể trò chuyện với tác nhân ngay tại đây. Chúng ta có thể nói "How are you?" hoặc bất cứ điều gì chúng ta muốn, và chúng ta sẽ nhận được phản hồi. Nhưng nếu chúng ta hỏi "What was my first message?" (tác nhân trả lời) "You don't have any previous messages." (Bạn không có tin nhắn nào trước đây.)

Có ai ở đây biết vấn đề là gì không? >> Nó không có bộ nhớ. OpenRouter không đủ "tử tế" để lưu trữ ngữ cảnh cho chúng ta. Chúng ta phải tự lưu trữ nó.

Có một tab "memory" (bộ nhớ) ngay đây với tất cả các tùy chọn khác nhau mà bạn có thể sử dụng. Tôi luôn dùng "Simple Memory" trừ khi tôi đang làm điều gì đó siêu phức tạp. Mặc dù nó ghi là dành cho người mới bắt đầu, nhưng không có gì phải xấu hổ cả. Nó chỉ làm cho mọi thứ dễ dàng và hoạt động ngay lập tức. Có ai giơ tay không?

>> Không. >> Vâng, có chuyện gì vậy? >> Các loại bộ nhớ khác nhau mà bạn sẽ sử dụng là gì và cho loại ứng dụng nào?

Các Loại Bộ nhớ và Ứng dụng

Chắc chắn rồi. Câu hỏi là các loại bộ nhớ khác nhau là gì và chúng được dùng cho các ứng dụng nào.

Với Simple Memory, chúng ta tự lưu trữ ngữ cảnh trong NADN. Chúng tôi xử lý tất cả cho bạn. Và bên trong nó, có một cửa sổ ngữ cảnh (context window) có độ dài là năm ở đây. Điều đó có nghĩa là nó sẽ chỉ nhớ năm tin nhắn trong ngữ cảnh của bạn và sẽ không nhớ bất cứ điều gì sau đó. Giá trị mặc định đó có lẽ nên cao hơn một chút, vì ngày nay mọi người có những cuộc trò chuyện dài hơn. Bạn có thể đặt nó là 50 hoặc gì đó. Chỉ cần nhớ rằng bạn đang phải trả tiền cho tất cả các mã thông báo (token) của những tin nhắn trước đó. Nhưng tất cả điều này đều được trừu tượng hóa cho bạn; nó chỉ hoạt động mà bạn không cần phải làm gì thêm. Loại bộ nhớ này hoạt động cho hầu hết mọi ứng dụng mà bạn đang xây dựng một hệ thống dựa trên trò chuyện.

Bạn sẽ sử dụng các giải pháp như PostgreSQL hoặc Redis hoặc một trong những giải pháp khác nếu bạn đang tích hợp nó vào một hệ thống hiện có. Ví dụ, với PostgreSQL, bạn có thể đặt ngữ cảnh vào một bảng, và sau đó nếu bạn có một ứng dụng khác, bạn có thể sử dụng PostgreSQL với ORM của bạn hoặc bất cứ thứ gì để lấy các tin nhắn đó và hiển thị chúng. Ví dụ, nếu bạn có một giao diện người dùng trò chuyện hoặc một bảng điều khiển do bạn tự phát triển, bạn có thể truy vấn PostgreSQL và hiển thị các tin nhắn đó lên đó như một ví dụ. Nhưng sự khác biệt lớn nhất là Simple Memory được trừu tượng hóa; chúng tôi làm mọi thứ trong NADN cho bạn. Với PostgreSQL, nó chỉ lưu các tin nhắn đó vào một bảng.

Và bây giờ với bộ nhớ ở đây, node trò chuyện sẽ cung cấp cho bạn một ID phiên và sau đó nó chỉ cần chuyển ID đó vào Simple Memory để ghi nhớ.

Sử dụng Biểu thức trong NADN

Tôi đoán đây là một thời điểm tốt để đề cập đến các biểu thức (expressions). Nếu bạn chưa từng thấy điều này trước đây, một số người đã tham gia sau khi chúng ta bắt đầu. Trang Notion này là nơi chứa tất cả những gì chúng ta đang làm bây giờ. Vì vậy, nếu bạn chưa truy cập được, tôi sẽ để nó ở đó thêm năm giây nữa. Vui lòng quét hoặc chụp ảnh.

Trong NADN, bạn sẽ thấy các dấu ngoặc vuông và phần màu xanh lá cây. Chúng ta gọi đó là một biểu thức. Bạn có thể nhập nội dung vào các trường, và đó chỉ là một giá trị tĩnh; nó sẽ luôn là đoạn văn bản đó. Nhưng nếu bạn chuyển nó thành biểu thức, đây vẫn là một giá trị tĩnh. Tuy nhiên, bất cứ thứ gì bạn đặt bên trong các dấu ngoặc nhọn là JavaScript. Và bạn sẽ thấy một số gợi ý ở đây. Chúng tôi cung cấp một số hàm tiện ích. Ví dụ, now sẽ hiển thị ngày giờ hiện tại. Thực sự thì bất cứ điều gì JavaScript đều hoạt động ở đây. Bạn có thể nói Math.random() và nó sẽ thực hiện chức năng đó.

Nhưng điều mà mọi người sử dụng nhiều nhất cho biểu thức tất nhiên là bạn có thể lấy một trường từ trigger node và chỉ cần kéo một giá trị rồi thả nó vào đó. Điều tuyệt vời về điều này là nếu chúng ta đang xây dựng thứ gì đó khác ngoài ID này, bạn có thể vào và nó sẽ nối tất cả lại, đặt vào một trường duy nhất.

Sử dụng Công cụ cho Tác nhân AI

Và bây giờ chúng ta có một tác nhân sẽ hoạt động. Bạn có thể trò chuyện với nó, và về cơ bản bạn chỉ đang trò chuyện với nhà cung cấp mô hình. Nhưng chúng ta muốn tác nhân này đặc biệt để quản lý bot email và lịch của chúng ta. Để làm điều đó, chúng ta cần thêm những node tương tự mà tôi đã đặt trên canvas đơn giản đó. (Bạn có câu hỏi không? Xin lỗi, tôi nghĩ bạn đã giơ tay.)

Hãy đặt những node tương tự đó để thực hiện các hành động. Nhưng sự khác biệt là với một tác nhân, thay vì đặt chúng ở cuối đây như một node riêng biệt, chúng ta có thể cung cấp chúng như các công cụ để tác nhân tự sử dụng. Mọi node mà chúng ta có trong NADN (ví dụ như Google Contacts, Gmail) đều có thể được sử dụng như một công cụ, biến nó thành một node hình tròn nhỏ, và sau đó tác nhân AI có thể sử dụng node này theo ý mình.

Ví dụ, chúng ta có thể nói "send a message" (gửi tin nhắn) và các nút nhỏ này cho phép Trí tuệ nhân tạo (AI) tự động điền vào.

Tích hợp Gmail và Google Calendar

Mọi người ở đây đều sử dụng Gmail cho công việc hoặc cá nhân phải không? Nếu không, Microsoft không dễ thiết lập bằng. Nhưng hãy cứ tiếp tục đăng nhập bằng Google. Tôi không có ý định để lộ tất cả thông tin của mình ở đó. Nhưng ôi trời, liệu việc tôi rút phích cắm máy tính trong giây lát có làm hỏng bản ghi không? Nó sẽ hỏng. Liệu tôi có thể cắm lại sau không? Được rồi. Tôi sẽ kết nối Google của mình thật nhanh.

Trong khi tôi đang làm điều này, bạn cũng có thể nhấp vào đó và thiết lập của bạn, đó chỉ là một thao tác cài đặt một lần nhấp. Và trình duyệt của tôi bị lỗi. >> Đó là điều tồi tệ nhất xảy ra hôm nay. Chúng ta vẫn ổn. Vâng, là tôi. Được rồi. Mọi người đã kết nối Google của mình chưa? >> Điều đó đã hoạt động cho mọi người. Chắc bạn mất ít thời gian hơn tôi. Được rồi, chúng ta ổn về việc ghi âm chứ. Được rồi, bây giờ bạn nên có... Ồ, nó đã kết nối ba lần. Tuyệt vời.

Điều khiến nhiều người bối rối về NADN nếu bạn chưa từng sử dụng nó trước đây là: nếu bạn nhấp vào đây, bạn sẽ chỉnh sửa kết nối cũ của mình. Nếu bạn muốn thêm một kết nối mới, bạn cần nhấp vào đây và chọn "add new credential" (thêm thông tin xác thực mới). Và chúng ta vừa xác thực Gmail. Chúng ta cũng sẽ sử dụng Google Calendar. Vì vậy, bạn cũng phải đăng nhập bằng Google cho cái đó. Và bây giờ chúng sẽ được kết nối và sẽ hoạt động cho mọi thứ chúng ta cần.

Cấu hình Công cụ và Kiểm soát Dữ liệu

Vì vậy, bây giờ chúng ta về cơ bản chỉ muốn vào và thiết lập các công cụ này. Chúng ta sẽ muốn tác nhân này có thể đọc email của chúng ta, tìm kiếm email của chúng ta, lưu trữ email, gửi tin nhắn. Vì vậy, về cơ bản, tôi sẽ tiếp tục làm điều đó. Các bạn cũng có thể tiếp tục làm điều đó. Nếu bạn có câu hỏi, gặp bất kỳ rắc rối nào.

Điều bạn cần biết khi làm điều đó là nút này cho phép AI thiết lập nó. Và tôi đoán điều này quan trọng cần phải đề cập, bởi vì trong nhiều trường hợp, ví dụ như Claude Code, nếu bạn cấp quyền truy cập vào Google Calendar của mình, nó về cơ bản có thể vào và làm bất cứ điều gì nó muốn. Nó phải thực hiện các cuộc gọi API đó.

Khi chúng ta cấp cho một thứ gì đó một công cụ trong NADN, nó có từng trường riêng lẻ. Vì vậy, nó chỉ có thể thiết lập những thứ mà chúng ta chỉ định cụ thể cho nó. Ví dụ, chúng ta có thể đặt chủ đề (subject), đặt tin nhắn (message), và chỉ cho phép nó đặt trường người nhận (to field). Và vì đó là điều duy nhất chúng ta có, bạn thực sự có thể thấy cách thiết lập này. Nó đặt biểu thức trợ giúp này vào đây. Đây là trường duy nhất nó có thể làm. Vì vậy, nó không bao giờ có thể thay đổi các trường khác. Đó là một mặt của con dao hai lưỡi.

Mặt khác của con dao hai lưỡi là điều đó có nghĩa là chúng ta phải thiết lập tất cả các trường. Vì vậy, chúng ta phải vào và nói rằng chủ đề được định nghĩa, tin nhắn được định nghĩa, người nhận được định nghĩa. Bạn có thể nhấp vào nút đó, nhưng bạn cũng có thể nói "from AI" như thế này bằng cách sử dụng biểu thức này và nó sẽ hoạt động. Lý do tại sao bạn không phải lúc nào cũng nhấp vào nút "magic" nhỏ này là vì đôi khi bạn muốn kết hợp mọi thứ lại với nhau, phải không?

Ví dụ, hãy tưởng tượng tôi sẽ lấy một giá trị kiểm tra bằng cách nói một tin nhắn như "what's my latest emails?" (email mới nhất của tôi là gì?). Bạn phải đặt cái đó. "What's my latest emails?" Và tôi có thể dừng lại. Và bây giờ, không chỉ tôi có thể đặt "from AI" và sau đó đặt tên trường (điều này cho phép AI, mặc dù nó nói undefined, đó chỉ là vì nó không có giá trị). Bây giờ, khi nó chạy, AI sẽ cung cấp một giá trị. Bạn có thể mã hóa cứng một thứ gì đó khác vào đây, ví dụ bạn có thể nói "responding to message" và sau đó bạn có thể gõ bao nhiêu văn bản tĩnh tùy thích, nhưng bạn cũng có thể tham chiếu các trường khác như "chat input" ngay tại đây. Vì vậy, nếu bạn muốn thực sự minh bạch về những gì bạn đang làm, bạn có thể nói "this is an AI responding to message this." (đây là một AI phản hồi tin nhắn này.) Và sau đó bạn có thể đưa điều đó vào email của mình hoặc bất cứ thứ gì bạn đang thiết lập. Đó là lý do tại sao bạn sẽ sử dụng from AI nếu bạn muốn tạo template nó vào văn bản như vậy. Đối với chúng ta bây giờ, tôi chỉ muốn nó làm mọi thứ ở đây. Và hãy xem, cái này đã được thiết lập đúng chưa? "Send a message." Hoàn hảo.

Tối ưu hóa Lời nhắc cho Công cụ

Một điều nữa bạn cần biết khi thiết lập các công cụ của mình là thiết lập lời nhắc (prompting). Đây là điều mà tôi thấy mọi người thường làm sai trong NADN là bạn cần đặt tên node của mình thật tốt. Vì vậy, tên tự động này khá tốt: "Send a message in Gmail." Tôi thậm chí sẽ đổi tên nó thành "send an email." Và sau đó là mô tả công cụ (tool description), nơi nó được thiết lập tự động. Bạn luôn muốn thiết lập thủ công và mô tả công cụ, đồng thời tối ưu hóa lời nhắc (prompt it) ở đây. Điều này được truyền vào Mô hình Ngôn ngữ Lớn (LLM) để cho nó biết những công cụ nào có sẵn cho nó.

Vì vậy, về cơ bản, mọi cuộc gọi LLM – và đây là cách các công cụ hoạt động under the hood cho mọi nền tảng – AI có thể thấy danh sách tất cả các công cụ với tên và mô tả của chúng. Tên node là tên công cụ. Mô tả node là mô tả công cụ. Vì vậy, bạn thực sự có thể đặt toàn bộ lời nhắc ở đây.

Vì vậy, điều tôi thường làm là thay vì thêm lời nhắc hệ thống (system prompt) vào bên trong tác nhân AI này (xin lỗi, tôi chưa cho bạn thấy điều đó, tôi sẽ nói đến nó). Tôi chắc rằng tất cả chúng ta đều quen thuộc với lời nhắc hệ thống khi đang ở một hội nghị kỹ sư AI. Trong lời nhắn hệ thống đó là nơi bạn thường đặt tất cả các nội dung khác nhau của mình, nhưng tôi thích làm cho nó modular hơn bằng cách chỉ đặt các lời nhắc liên quan đến email của mình (ví dụ: "don't use em-dashes," "don't do whatever") vào mô tả thực tế. Có lẽ một số người sẽ không đồng ý với cách tiếp cận đó, nhưng tôi thực sự thích nó vì nó modular. Tôi có thể sao chép một công cụ từ các quy trình làm việc khác và nó sẽ hoạt động.

Tôi chắc rằng mọi người có lẽ đã đi trước tôi về mặt công cụ khi thêm chúng. Điều đó rất tốt. Và nếu bạn bị tụt lại phía sau như tôi ở đây, bạn có thể vào trang Notion này, và bên trong đó bạn có thể sao chép và sau đó bạn chỉ cần Command + V và nó sẽ dán mọi thứ vào.

Và trong khi tôi có cái này ở đây để các bạn không phải ngồi xem tôi viết một lời nhắc khổng lồ và đánh vần mọi thứ không chính xác. Tôi sẽ dán lời nhắc tôi đã viết tối qua vào đây và cùng xem xét cấu trúc của nó một chút trong khi các bạn điền vào các công cụ đó. Và tất cả các hộp khác nhau trong NADN, bạn luôn có thể mở rộng chúng ra toàn màn hình, điều này giúp dễ dàng hơn một chút.

Vì vậy, như tôi chắc rằng tất cả chúng ta đều biết, bạn muốn nói với AI trong lời nhắc hệ thống về cơ bản nó là ai và mục đích của nó là gì. Tôi thích giữ chúng khá đơn giản và chỉ thêm nội dung khi tôi cần. Vì vậy, nếu một công cụ không được gọi, có điều gì đó không xảy ra, bạn chỉ cần vào đây và yêu cầu nó thay đổi.

Tối ưu hóa Hành vi của Tác nhân AI và Ngăn chặn Ảo giác

Tôi đã đưa ra một danh sách ngắn gọn về cách hành xử cho tác nhân AI, ví dụ như "hãy hỏi thay vì tạo ra ảo giác", và những điều tương tự. Điều này thực sự quan trọng. Tôi chắc rằng tất cả chúng ta đều đã trải qua điều này: bạn không muốn gửi một email với tên khách hàng tiềm năng chưa đầy đủ tới một khách hàng tiềm năng thực sự. Điều đó rất đáng xấu hổ. Như chúng ta đã nói ở đây, đừng sử dụng các placeholder (phần giữ chỗ). Ngoài ra, các Mô hình Ngôn ngữ Lớn (LLM) thường không biết thời gian. Vì vậy, nếu bạn hỏi "email hôm nay là gì?", nó có thể trả lời "bạn không có email nào vào tháng 1 năm 2023", và bạn sẽ tự hỏi "cái gì?". Để khắc phục, bạn có thể sử dụng hàm tiện ích date time này, nó sẽ hiển thị kết quả đánh giá ở bên cạnh.

Có ai có câu hỏi nào không? Tôi biết mình đã đi vòng quanh một chút. Tất cả chúng ta vẫn đang cố gắng đặt các công cụ vào vị trí phải không? Tốt, tốt, tốt.

Mẹo Cấu hình và Tối ưu hóa Lời Nhắc

Sau đó, tôi sẽ "gian lận" một chút và sao chép những cái này. Tôi đoán tôi có thể đã kéo chúng, nhưng tôi sẽ dán chúng vào đây. Một mẹo hay khi bạn thiết lập một cái gì đó là: hãy thiết lập cái đầu tiên, thiết lập authentification (xác thực) của bạn, và sau đó thay vì tạo một cái mới và thiết lập lại các giá trị, chỉ cần sao chép và dán nó, vì trường đó đã được thiết lập sẵn bên trong. Điều này giúp tiết kiệm một chút thời gian khi không phải nhấp vào nút nhỏ mỗi lần.

Một mẹo tối ưu hóa lời nhắc khác là khi bạn thiết lập ở đây, có một nút "thêm mô tả" (add a description). Điều này đúng như tên gọi của nó: nó thêm một mô tả vào trường đó để Trí tuệ nhân tạo (AI) hiểu rõ hơn. Bạn sẽ nhận thấy đôi khi có một trường mà AI có thể chọn sai thứ. Ví dụ, trong Gmail thread ID (ID chuỗi thư Gmail), nó có thể đặt message ID (ID tin nhắn) hoặc thứ gì đó tương tự. Bạn có thể thêm một lời nhắc vào đây và có thể làm cho nó dài tùy ý, hàng tấn dòng, và nó vẫn hoạt động tốt. Vì vậy, nếu có điều gì đó xảy ra mà nó truyền sai giá trị, đây chỉ là một hộp khác để bạn có thể hướng AI đi đúng hướng.

Một điều khác bạn có thể làm nếu có điều gì đó như — hãy để tôi tìm một ví dụ tốt hơn thread ID... À, một ví dụ tuyệt vời là khi tạo một sự kiện trong Google Calendar, tên của — để tôi xem, nó ở đâu nhỉ? — summary (tóm tắt) thực ra là title (tiêu đề), điều này cực kỳ khó hiểu ngay cả đối với tất cả mọi người đang sử dụng Gmail. Chúng ta có lẽ nên đổi tên này thành title, nhưng chúng tôi chỉ làm theo tên API của Google. Khi bạn thiết lập điều này, bạn nên thêm một mô tả và nói "đây là tiêu đề của sự kiện", bởi vì summary (tóm tắt) thì tác nhân AI sẽ chỉ đặt một bản tóm tắt về sự kiện, đương nhiên rồi, nhưng điều này sẽ cho nó biết đây là title. Bạn thậm chí có thể làm tốt hơn nữa bằng cách nhấp vào đây và bạn sẽ thấy key (khóa) được tạo tự động ngay tại đây. Bạn có thể thay đổi nó từ summary thành chỉ title, và sau đó AI sẽ điền title từ đó.

Kiểm tra và Khắc phục sự cố Quyền truy cập Tác nhân

Bây giờ tôi sẽ kiểm tra xem nó có hoạt động không. Tôi có một số trường chưa được điền. "Không có quyền truy cập vào credential (thông tin xác thực)." Đôi khi, khi bạn đang làm việc trong một project (dự án) và tạo một credential trong project đó (hãy nhớ, các project là những thứ trên thanh bên), bạn sẽ gặp lỗi nói rằng nó không có quyền truy cập, điều này thực sự khó hiểu vì trông có vẻ như nó có. Nếu bạn gặp phải điều này, tất cả những gì bạn cần làm là về trang chủ và trong phần credentials, bạn có thể chia sẻ chúng. Vì vậy, hãy nói "chia sẻ" và sau đó bạn chia sẻ nó với project. Đây là một ví dụ khác về "thanh gươm hai lưỡi" khi bạn đang giữ nó. Được rồi, cái này đã bị kiểm soát rồi.

Và bây giờ, việc thu nhỏ của tôi đang làm cho điều này hơi lạ, nhưng khi chúng ta hỏi nó "có gì trên lịch của tôi hôm nay?", chúng ta có thể thấy chính xác những công cụ nào nó đã sử dụng. Nó đã sử dụng get many messages (lấy nhiều tin nhắn). Và sau đó, nếu chúng ta nhấp vào node (nút) đó cụ thể, chúng ta có thể thấy output (đầu ra) chính xác từ đó. Và ở phía dưới đây, chúng ta có các log (nhật ký) chi tiết về mọi thứ đã xảy ra. Vì vậy, get many messages: input (đầu vào) trong trường tìm kiếm là "sau 26/4/08 và trước ngày mai". Và sau đó trong message (tin nhắn), chúng ta chỉ nhận được một bản tóm tắt về những gì chúng đang nói, điều này khiến tôi lo lắng vì có rất nhiều người bị kẹt bên ngoài. Có một hàng dài người ở đó. Có lẽ các bạn đã vào sớm. Mọi người đã đến điểm này là có thể trò chuyện với nó chưa hay chúng ta vẫn đang đặt công cụ? Được rồi, được rồi, tuyệt vời.

Thêm Bước Đánh giá của Con người vào Quy trình làm việc

Tại thời điểm này, tôi đã hơi lo lắng khi kiểm tra điều này với tài khoản thực của mình vì tôi không muốn vô tình gửi email cho ai đó hoặc vô tình trả lời, phải không? Và tôi chắc rằng các bạn cũng nghĩ "tôi không muốn nói 'gửi email' và nó tự động làm điều đó". Đó gần như là toàn bộ ý nghĩa của buổi thuyết trình hôm nay: chúng tôi đã làm cho việc thêm sự an tâm ở đây trở nên rất dễ dàng.

Vì vậy, mọi thứ mà chúng ta coi là destructive (phá hoại) hoặc sensitive (nhạy cảm), chúng ta có thể thêm một bước human review (đánh giá của con người). Và hãy xem, đó sẽ là "gửi email" và "trả lời". Tôi sẽ kéo chúng ra để tách biệt. "Gửi email", "tạo sự kiện". Và sau đó tôi sẽ nói "lưu trữ email" sẽ là ranh giới. Tôi sẽ để nó lưu trữ email của tôi. Nếu tôi bỏ lỡ một email, đó không phải là vấn đề lớn.

Bây giờ tất cả những gì bạn làm trên nhánh này, có một thùng rác và một dấu cộng. Nếu bạn nhấn nút dấu cộng, nó sẽ hiển thị human review và bạn có thể sử dụng nền tảng chat mà chúng ta đang sử dụng. Chúng tôi đang sử dụng native NAN chat. Và sau đó, điều này tạo ra bước human review nhỏ này ngay tại đây. Và bây giờ, không thể nào. Nó không thể vượt qua lớp này. Nó không thể sử dụng công cụ này mà không thông qua cuộc trò chuyện này. Và chúng ta có thể cung cấp cho nó các tùy chọn như nút chấp thuận sẽ nói gì. Chúng ta có thể thay đổi cái này thành "gửi". Và chúng ta cũng có thể thêm nút "từ chối". Và sau đó chúng ta có thể chặn user input (đầu vào của người dùng). Nhưng tôi thích để nó tắt vì sau đó bạn có thể chỉ cần phản hồi lại nó và phản hồi lại message sẽ từ chối.

Khắc phục lỗi Chế độ phản hồi và Tối ưu hóa Chat Node

Và bây giờ chúng ta có thể xem điều này trông như thế nào và nói "gửi một email thử nghiệm tới" — hy vọng nó sẽ lắng nghe. Và chúng ta đã gặp lỗi khi nó chạm vào. Chúng ta có thể thấy nó đã đi và sử dụng nó, nhưng chúng ta đã gặp lỗi: "Chế độ phản hồi trong chat trigger phải được đặt thành using response nodes (sử dụng các node phản hồi)." Một mẹo khác, nhiều người thực sự khi họ thấy một cái gì đó màu đỏ bật lên thì họ kêu lên "ôi trời ơi!" nhưng nếu bạn đọc lỗi, nó thường cho bạn biết vấn đề là gì. Thật ra, rất nhiều công sức đã được đổ vào việc các kỹ sư tự viết những message này hoặc có lẽ Claude làm điều đó như thế nào ngày nay.

Nhưng hãy xem. Response mode trong chat trigger phải được đặt. Vì vậy, bên trong chat trigger, hãy xem, dưới options (tùy chọn), có response mode này. Theo mặc định, nó được đặt thành streaming (truyền trực tuyến). Và bạn sẽ thấy rằng các từ quay lại từng từ một trong màn hình chat đó. Nhưng để các chat node hoạt động, chúng ta cần đặt nó thành using respond nodes. Và điều đó về cơ bản làm đúng như những gì nó nói. Thay vì nó streaming trực tiếp từ Mô hình Ngôn ngữ Lớn (LLM), chúng ta đang kiểm soát những message nào đến nó bằng cách sử dụng các node trên màn hình. Vì vậy, đó sẽ là một node như human review này. Chúng ta cũng chỉ có những chat node thông thường này ở đây, nơi bạn có thể chỉ cần gửi một message. Đó là cái sai. Tôi sẽ cho bạn thấy điều này vì nó rất hay. Chat tool (công cụ trò chuyện) nơi bạn có thể chỉ cần gửi một message trong chat bằng một tool, mà bạn có thể làm một số điều thú vị với nó.

Nhưng bây giờ chúng ta thực sự, khi chúng ta thiết lập điều đó, chúng ta cũng cần phải — nó sẽ không phản hồi gì cả trừ khi thông qua một chat node. Vì vậy, chúng ta phải thêm một chat node sau tác nhân nữa. "Gửi một message." Và ngay bây giờ bạn có thể thấy nó trống. Tôi nghĩ đây là JSON.message. Nó có thể là chat output. Chúng ta sẽ kiểm tra nó. Nói "xin chào." Và nó sẽ quay lại. Và output là gì? Nó đang bị treo. Đó lại là một demo syndrome (hội chứng trình diễn). Được rồi, tôi sẽ vô hiệu hóa node này. "Gửi một message." Vì vậy, luôn tốt khi có dữ liệu thử nghiệm ở đó. Tôi nghĩ vấn đề là cái này không xác định. Được rồi, nó là output. Không phải message. Vì vậy, sau đó chúng ta có thể chỉ cần kéo cái này trực tiếp đến "gửi một message". Bây giờ, chúng ta có thể kiểm tra lại và đảm bảo chúng ta nhận được một message trả lời. Và sau đó chúng ta có thể thấy nó không stream (truyền trực tuyến) lại, nó gửi lại trong một chunk (khối). Điều đó có ý nghĩa không? Tôi biết điều đó có thể làm mọi người vấp váp. Bạn chỉ cần phản hồi bằng các node mọi lúc.

Một điều khác bạn có thể làm thú vị với điều đó là thiết lập các nhánh if (nếu), phải không? Vì vậy, bạn có thể kiểm tra điều gì đó trong message đó bằng một nhánh if và có các điều kiện khác nhau về cách phản hồi. Nhưng chúng ta không cần phải lo lắng về điều đó ngay bây giờ. Chúng ta chỉ cần phản hồi với điều đó. Và bây giờ cái này sẽ hoạt động trở lại. Chúng ta có thể quay lại kiểm tra và nói "gửi một email thử nghiệm tới".

Cải thiện Trải nghiệm Đánh giá của Con người

Được rồi. Và bây giờ chúng ta có thể thấy ở đây trong cuộc trò chuyện, nếu chúng ta có thể phóng to cái này lên, tác nhân muốn gọi send an email. Và nếu bạn đang nhìn nó trên điện thoại, bạn có thể sẽ nói "được rồi", bởi vì rõ ràng đó không thực sự cho chúng ta thấy bất cứ điều gì. Vì vậy, chúng ta sẽ nhấn từ chối vì tôi muốn xem message của mình. Và khi chúng ta nhấp vào human review node, bây giờ chúng ta đã có ví dụ đó, chúng ta có thể thấy nó đến từ đâu. Trong message này, tác nhân muốn gọi tool.name. Trong trường này, chúng ta có thể sử dụng hàm tiện ích tool này bằng cách nói $tool.parameters (tham số của công cụ), mà mọi trường trong NAND được gọi là một parameter (tham số) ngầm. Nếu bạn từng nhận được object object, những người làm việc với JavaScript sẽ biết đó là gì. Nhưng bạn có thể nói to JSON string như một mẹo để xem output là gì. Và thậm chí chỉ cái này thôi cũng sẽ cung cấp cho bạn thông tin mà bạn cần biết cho bước human review. Nhưng rõ ràng đó hơi xấu xí. Vì vậy, điều tôi muốn làm hơn là nói to và cái này có thể nói .message hoặc to, phải không? Và chúng ta không cần to JSON string nữa. from, à không from, subject, tool.parameters.subject, message, tool.parameters.message.

Và bây giờ chúng ta có thể thấy rằng message của tác nhân sẽ là một cái gì đó chúng ta thực sự có thể hợp lý chấp thuận hoặc từ chối. Và tôi thực sự sẽ đổi tên cái này thành "tác nhân muốn gửi một email". Tuyệt vời. Và bây giờ tôi thực sự sẽ xuất bản cái này để tôi có thể thấy nó trong chat hub. Tôi sẽ đến đây và tôi sẽ nói lại "gửi một email thử nghiệm tới" — tôi thực sự không thể mở email của mình không may là mcg — và nó quay lại và nói "tác nhân muốn gửi một email" và làm tất cả những điều đó và chúng ta có thể thấy nó và chúng ta có thể gửi nó hoặc từ chối nó. Và bạn cũng có thể từ chối nó bằng cách chỉ cần phản hồi. Vì vậy, chúng ta có thể nói "tôi muốn message là markdown. Viết một email có các tính năng markdown khác nhau." Và sau đó nó từ chối và nó sẽ khá nhiều chỉ thử lại. Nó không lắng nghe markdown vì nó lắng nghe mô tả công cụ nhiều hơn. Nhưng bạn có thể thấy điều đó hoạt động như thế nào. Và sau đó tôi có thể tiếp tục và gửi cho mình email rác này. Và đó là nó. Hy vọng điều đó cho thấy điều này mạnh mẽ và tuyệt vời đến mức nào, bởi vì công cụ đó không thể được gọi mà không thông qua điều đó. Nó chỉ chặn đường. Chúng tôi tại NAND đã tạo ra lớp đó để chặn nó ở giữa.

Và một trong những điều thực sự thú vị về nó là nó thậm chí không thực sự biết có một bước human review ở đó. Vì vậy, nếu bạn có các công cụ của mình hoạt động và bạn thêm một bước human review, nó không gọi bước human review đó. Nó đang gọi công cụ và chúng tôi đang chặn nó. Giống như nhiều thứ trong AI, đó cũng là một "thanh gươm hai lưỡi" vì các AI thường sẽ cảnh giác về điều đó. Bạn biết đấy, các AI thông minh hơn một chút, chúng thường sẽ không gửi email mà không hỏi trừ khi bạn nói cụ thể cho nó làm. Vì vậy, điều tôi thấy là đôi khi trong các mô tả trong các lời nhắc này, tôi sẽ nói "điều này sẽ không gửi tự động. Đừng ngại gửi một message. Message là có một con người trong vòng lặp (human in the loop)." Và điều đó thường khắc phục được vì nó sẽ như kiểu "được rồi, nó sẽ không bị gửi đi một cách vô tư. Nó sẽ được sử dụng, phải không?".

Vì vậy, bạn cũng có thể, nếu bạn thực sự lười biếng như tôi đôi khi, bạn có thể đặt nhiều công cụ dưới một human in the loop. Vì vậy, chúng ta có thể đặt cái draft dưới đây nữa và sau đó nó sẽ chặn nó cho cả hai mà không cần bất kỳ thay đổi nào. Chỉ là các trường khác nhau và chúng ta đã tạo một message tùy chỉnh cho nó. Vì vậy, chúng ta sẽ viết, chúng ta sẽ thêm một cái khác. Nhưng sự lười biếng vẫn thắng thế. Vì vậy, tôi sẽ thử một cái gì đó.

Thiết lập và Tối ưu hóa Quy trình làm việc

Chúng ta sẽ xem liệu hội chứng demo có làm khó chúng ta ở đây không. Và tôi sẽ nói thêm human in the loop (con người trong vòng lặp) giống như nó đang ở trên phần "gửi email tới" và đây là NAD AI builder. Để xem. Hãy để tôi đảm bảo lời nhắc này là tốt. Thêm human in the loop giống hệt như vậy. Đặt tên các params và mọi thứ để khớp với các công cụ.

Tôi nhận thấy điều giúp ích rất nhiều là nếu bạn có nhiều thứ lặp lại, bạn có thể tạo một cái và sau đó chỉ cần nói, "Được rồi, hãy làm điều này ở đó nữa." Và bạn không cần phải thực sự nhấp qua từng bước. Nó thực sự sẽ làm điều đó nhanh hơn bạn có thể.

Và chúng tôi có tính năng này trên Claude (điện toán đám mây) và enterprise (doanh nghiệp). Nó chưa có trên self-hosted (tự lưu trữ). Chúng tôi đang nỗ lực để đưa nó lên đó, nhưng chúng tôi vừa phát hành một tính năng MCP mới, nơi bạn có thể kết nối nó với Claude Code hoặc bất kỳ tác nhân nào bạn có và nó có thể thực hiện các chức năng tương tự như thế này chỉ thông qua CLI (giao diện dòng lệnh) với MCP.

Và nó có hoạt động không? Có vẻ như đã hoạt động. Đang xác thực quy trình làm việc. Chúng ta có thể nhấp vào. Có vẻ như nó đang hoạt động. Tuyệt vời. Bây giờ tôi sẽ xuất bản cái này. Hãy quay lại chat hub vì ở đó dễ nhìn hơn một chút.

À, thêm một lời mời lịch cho bữa trưa hôm nay lúc trưa và gửi email. Ôi trời, tôi không biết email của mình, hỏi xem anh ấy có muốn đi không. Gửi. Tôi thấy ổn. Muốn tạo một sự kiện lịch. Bữa trưa. Ồ, trông hơi xấu. Được rồi, tôi sẽ tạo nó vì nó sẽ không thay đổi những gì thực sự có trong đó. Nhưng chúng ta có thể sửa lỗi đó. Hãy làm cho nó tốt hơn.

Kiểm thử và Gỡ lỗi Hiệu quả

Và điều này làm cho việc kiểm thử trở nên rất tiện lợi vì bạn có thể tạo các dummy events (sự kiện giả) và thực sự xem liệu nó có gửi nhầm người hay làm sai việc không, và bạn có thể từ chối nó, để bạn biết mình sẽ không làm gì đó một cách tình cờ. Bạn còn nhớ lúc đầu tôi nói, "Ồ, bạn có thể thấy mọi thứ sai ở đâu và mọi thứ khác" không? Trong tab executions (các lần thực thi) này, bạn sẽ thấy tất cả các lần nó được thực thi. Nó đánh dấu các lần kiểm thử bằng biểu tượng flask (bình tam giác), nhưng chúng ta sẽ thấy lần execution (thực thi) đó từ chat ngay tại đây; chúng ta có thể thấy nó đã đi vào human in the loop và sau đó xuống và tạo sự kiện.

Nếu bạn nhấp vào copy to editor (sao chép vào trình chỉnh sửa), chúng ta có thể làm việc với dữ liệu này ở đây. Vì vậy, nếu chúng ta nhấp vào công cụ, chúng ta sẽ thấy những định dạng ngày tháng rất xấu ở đây. Và bây giờ, đây là lúc JavaScript thực sự hữu ích. Nếu bạn không biết JavaScript, bạn có thể chỉ cần hỏi một chat để nó cho bạn biết cách định dạng ngày này. Nhưng chúng ta có thể chỉ cần nói to date time và sau đó .format. À, và tôi nghĩ tôi có thể làm dd t. Không thể chuyển đổi. Ồ, tại sao không? Để xem. Ôi trời ơi, tôi đã cố gắng chuyển đổi "lunch" thành một date time. Chúng ta, tôi, chúng ta không thể đổ lỗi cho demo luck (vận may demo) cho việc đó. Được rồi. Và sau đó, bây giờ nó biết rằng đây là tương thích. Vì vậy, khi bạn nhấn dấu chấm, to date time đã tự động hiện ra. Và nếu chúng ta nhấn dấu chấm một lần nữa, format cũng đã hiện ra. Và các kỹ sư rất tốt bụng tại NAN đã thêm docs (tài liệu) cho chúng ta vào đây. Vì vậy, chúng ta có thể thấy tất cả những thứ này làm gì, và bạn thậm chí có thể nói như C và minus, họ hiển thị các code examples (ví dụ mã) và mọi thứ. Rất hay khi đi vào đọc nó. Tôi biết chúng ta đang bị cám dỗ chỉ muốn hỏi Claude mọi thứ ngay bây giờ, nhưng nếu bạn đọc những thứ trên màn hình, tôi hứa nó rất hữu ích.

Nhưng nếu chúng ta định dạng cái này và nói D viết hoa, tôi nghĩ vậy. Vâng, đó rồi. Hay đấy. Nếu bạn thêm vài chữ D nữa, nó sẽ càng đẹp hơn. D và sau đó T T. Và đây là, nếu bạn thắc mắc đây là gì, đây chỉ là các Luxon date functions (hàm ngày Luxon). Nó chỉ là date library (thư viện ngày) mà chúng tôi sử dụng, đó là ddt này. Tôi đã viết nó đủ nhiều lần để nhớ, nhưng bạn có thể chỉ cần hỏi Claude để định dạng nó cho Nad và nó sẽ làm. Vì vậy, bây giờ trông đẹp hơn nhiều. Điều đó dễ dàng hơn nhiều để chúng ta chấp thuận mà không phải đọc một UTC timestamp (dấu thời gian UTC). Vì vậy, chúng ta sẽ xuất bản lại và nói hãy đặt bữa tối vào cal cho 7. Đó rồi. Nó đã được sửa. Và chúng ta có thể thấy việc đi vào điều chỉnh và thử nghiệm mọi thứ dễ dàng như thế nào.

Tất cả những điều này có hợp lý không? Có câu hỏi nào không? Không nhất thiết phải liên quan cụ thể. Ồ, và có một email đang đến, tôi đoán vậy.

Chỉ một tháng. Ồ, thật sao? Chỉ một tháng. Bạn có đang dùng Claude pro khi chọn không? Vâng, khi tôi chọn, tôi chỉ có thể cho một tháng. Tôi sẽ đi tạo một cái mới ngay bây giờ hoặc... kiểm tra sau, tôi sẽ tạo một cái mới để không làm lộ cách tạo coupons (mã giảm giá). Vâng. Vậy tôi sẽ đăng nó lên, tôi sẽ để nó trong 24 giờ... và sau đó tôi sẽ gỡ xuống. Xin lỗi về điều đó.

Một điều thú vị là tôi thực sự đã tạo toàn bộ một discount system (hệ thống giảm giá), giống như coupon generator (trình tạo phiếu giảm giá) của chúng tôi tại NADEN được tạo hoàn toàn trong NANE, và nó trừu tượng hóa tất cả các coupon systems (hệ thống phiếu giảm giá) khác nhau mà chúng tôi có trên merch (hàng hóa), enterprise (doanh nghiệp), giveaway (quà tặng), Claude (điện toán đám mây). Tất cả đều có một entry point (điểm vào) duy nhất với một REST API đi qua Nadn và nó có tất cả audit logs (nhật ký kiểm toán) và mọi thứ. Nó thực sự thú vị và tôi đã xây dựng toàn bộ hệ thống chỉ trong khoảng sáu giờ. Vì vậy, đây là những thứ thực sự, thực sự mạnh mẽ.

Vâng. Vâng.

Hỏi đáp về MCP và Quy trình làm việc Tùy chỉnh

Ồ, bạn có ngại chờ mic không? Cảm ơn. Bạn có nhắc đến MCP server (máy chủ MCP). Bởi vì cho đến gần đây có một cái unofficial one (phiên bản không chính thức) trên GitHub mà tôi thực sự đã sử dụng cho đến nay và nó hoạt động rất tốt với cloth code (mã nguồn cloth). Bạn có thể chia sẻ thêm một chút về native MCP server (máy chủ MCP gốc) mà bạn có và liệu nó có sẵn không?

Vâng, chắc chắn rồi. Vậy, đây thực sự rất thú vị. Bạn chỉ cần vào settings (cài đặt) và ngay tại đây, instance level MCP (MCP cấp độ instance). Nếu bạn nhấp vào đây, bạn có thể chỉ cần bật nó lên và cấp quyền truy cập vào các quy trình làm việc. Vậy, hãy xem chúng ta có gì ở đây: các quy trình làm việc đã được xuất bản hoặc có một web hook (webhook), form schedule (lịch biểu mẫu), hoặc chat trigger (kích hoạt trò chuyện). Vậy đó nên là của chúng ta. Email và calendarbot (bot lịch) được bật. Bạn phải cấp quyền truy cập cho từng quy trình làm việc, điều mà bạn cũng có thể làm ở trên này và nói settings available in MCP (cài đặt có sẵn trong MCP). Điều đó chỉ để nếu bạn kết nối nó với thứ của bạn, nó sẽ không vô tình thay đổi sai quy trình làm việc. Nó phải được bật. Và bây giờ trong cái MCP đó, bạn có thể nói connected clients (khách hàng đã kết nối) hoặc, làm thế nào bạn, connection details (chi tiết kết nối). Bạn chỉ cần đặt server URL (URL máy chủ) của mình vào OAuth. Vậy, trong Claude (điện toán đám mây), tôi gần như sợ phải mở Claude của mình, nhưng chúng tôi là một official connector (trình kết nối chính thức) trong Claude. Vì vậy, bạn chỉ cần nói connect nad. Bạn đặt URL đó vào. Nó sẽ kết nối với OAuth. Bạn chỉ cần nhấn log in (đăng nhập). Hoặc nếu bạn đang sử dụng access token (mã truy cập), bạn có thể sao chép nó ở đây và bạn sẽ sao chép cái này, dán nó vào configuration file (tệp cấu hình) của bạn và thay thế access token của bạn bằng cái này. Và nó làm tất cả những điều tương tự mà MCP đó làm, ngoại trừ chúng tôi không bị hạn chế bởi việc phải làm việc với API hiện có của chúng tôi. Chúng tôi đã xây dựng nó ngay vào. Vì vậy, nó làm tất cả những điều tương tự. Tôi sẽ nói bạn có thể thử cả hai và xem, nhưng của chúng tôi sẽ ngày càng bổ sung nhiều hơn theo thời gian. À, điều đó có trả lời câu hỏi của bạn không? Tôi đoán tôi không đi sâu vào chi tiết lắm, nhưng về cơ bản, nó có thể tạo, đọc, làm tất cả những điều đó. Nó thực sự cũng có thể thực thi. Vì vậy, bạn có thể nói với Claude, "Chạy email and calendarbot của tôi," và nó sẽ gửi một chat message (tin nhắn trò chuyện) đến nó và nó có thể tương tác với nó. Vì vậy, đó là một điều khác mà tôi không nghĩ MCP của Roman có thể làm. Vâng. Vậy đó là điều mà MCP của chúng tôi có thể làm.

Còn câu hỏi nào khác không? Nó cũng có thể là một câu hỏi ngẫu nhiên như vậy nếu bạn có bất kỳ điều gì liên quan đến MCP. Vâng.

Ồ vâng. Xin lỗi. Cảm ơn. Vậy, giả sử tôi muốn xây dựng một companywide workflow (quy trình làm việc toàn công ty), phải không? Và tôi muốn có human in the loop (con người trong vòng lặp) cụ thể từ các phòng ban cụ thể cho các hành động cụ thể, nếu điều đó có ý nghĩa. Có cách nào để tôi có thể log (ghi nhật ký) và xem toàn bộ quy trình làm việc bị chậm trễ ở đâu không? Giống như một heat map (bản đồ nhiệt) của logs (nhật ký) về việc ai mất nhiều thời gian hơn để phản hồi như vậy. Ai mất nhiều thời gian hơn để phản hồi? Đó là một use case (trường hợp sử dụng) thú vị. Tôi định nói chúng tôi có rất nhiều audit logging functionalities (chức năng ghi nhật ký kiểm toán) trong các enterprise plans (gói doanh nghiệp) của mình, nhưng đó sẽ không phải là thứ baked in (tích hợp sẵn), mà đó là thứ bạn có thể tạo với NAD vì điều gì xảy ra với cái này, tôi sẽ cho bạn xem rất nhanh. Cái này vẫn hiển thị waiting (đang chờ) mặc dù điều đó không đúng. Nhưng tôi sẽ nói gửi email đến cùng email khác đó. Làm bất cứ điều gì, chỉ cần test (kiểm thử). Vậy nếu chúng ta, được rồi. Vậy bây giờ điều gì xảy ra là quy trình làm việc này (đó là điều sai) quy trình làm việc này chuyển sang waiting state (trạng thái chờ), và bạn có thể thấy nó ở đây. Và sau đó một khi nó tiếp tục, nó hiển thị finished (đã hoàn thành). Bạn có thể sử dụng một N8N node (node N8N) để lấy execution (lần thực thi) và nó sẽ hiển thị khi nào nó bắt đầu waiting, khi nào nó ngừng waiting. Và sau đó nếu bạn có các Slack connections (kết nối Slack) và mọi thứ, nó sẽ hiển thị tất cả các chi tiết đó. Vì vậy, nó sẽ chỉ là vấn đề phân tích dữ liệu đó. Vì vậy, đó là thứ bạn có thể tạo riêng biệt trong NAD, aggregate the data (tổng hợp dữ liệu) lại với nhau. Đó là một use case thú vị. Tôi sẽ viết lại điều đó. Tôi sẽ nghĩ về điều đó vì audit logging human in the loop (ghi nhật ký kiểm toán con người trong vòng lặp) là điều mà chúng ta chắc chắn nên hoàn thiện. Để xem. Kiểm tra thời gian. Chúng ta đang ở 11:50.

Tích hợp và Khả năng Tự động hóa

Tôi muốn cho các bạn xem thêm một điều nữa cụ thể để giúp các bạn thiết lập, và đó là chuyển đổi cái này sang Slack, phải không? Vậy, nếu chúng ta lấy, có ai có câu hỏi nào khác trước khi chúng ta làm điều đó không? Được rồi.

Vậy, tôi sẽ thêm Slack vào đây. Mọi người ở đây có dùng Slack hay Google hay Microsoft Teams không? Hy vọng không ai dùng Teams. Slack. Vâng, tôi nghĩ phần lớn sẽ là Slack. Vậy, tác nhân cá nhân tôi dùng cho bản thân, tôi dùng Slack. Và nó thực sự rất hay. Tôi thậm chí còn thiết lập nó. Vậy, ngay tại đây, tôi đặt một Slack node (node Slack) để thêm một loading animation (hoạt ảnh tải), đó là một GIF (ảnh động) của một cái gì đó đang nhảy múa. Và sau đó ở cuối, sau khi nó phản hồi, nó sẽ gỡ bỏ cái đó đi. Vì vậy, nó thậm chí còn có một loading indicator (chỉ báo tải). Nó thực sự rất hay. Bạn có thể vào và chỉ cần thay thế trigger (kích hoạt) và response (phản hồi) này bằng Slack và làm điều tương tự ở đây nơi những thứ này đi qua Slack. Vì vậy, tất cả hoạt động giống như cách bạn thấy trên ChatHub. Nó sẽ hoạt động trong Slack.

Một điều thú vị hơn nữa, hoặc tùy thuộc vào điều bạn cho là thú vị, tôi cho rằng thay vì để nó chạy chỉ khi bạn nhắn tin, hãy tưởng tượng nếu chúng ta thêm một schedule trigger (kích hoạt theo lịch trình), và để nó chạy mỗi giờ, một lần mỗi giờ, và thêm một lời nhắc vào schedule trigger đó nói rằng, "Dọn dẹp inbox (hộp thư đến) của tôi," hoặc bất cứ điều gì. Sau đó, nó sẽ chạy một lần mỗi giờ, thực hiện các hành động đó, và những điều này có thể được kết nối với Slack để chỉ ping a channel (gửi thông báo đến một kênh) để nó vẫn có human in the loop (con người trong vòng lặp) cho mọi thứ nhưng chỉ chạy ở background (nền). Bạn thậm chí không cần phải khởi tạo nó. Vì vậy, bạn có thể tưởng tượng tất cả những điều trong background mà tôi sử dụng điều này cho: nếu có một GitHub issue (vấn đề GitHub) hoặc một PR (Pull Request) hoặc gì đó, tôi có nó đến, tôi có nó đi qua, scan the code (quét mã), làm bất cứ điều gì, và gửi tin nhắn cho mọi người hỏi họ chi tiết mà tôi biết khi tôi đọc qua, và sau đó tôi chỉ nhận được tin nhắn đến tôi vì tôi không muốn AI message (tin nhắn AI) cho đồng nghiệp hoặc khách hàng hoặc bất cứ ai mà không xem trước. Điều đó có hợp lý không? Vâng.

Và tất cả những điều đó thực sự có trong Notion document (tài liệu Notion) này như các bước tiếp theo ở đây. Trong bước tiếp theo, bạn có thể cung cấp cho nó memory (bộ nhớ) để nó có thể persist memory (duy trì bộ nhớ) xuyên suốt – ồ, xin lỗi, bạn khó có thể nhìn thấy điều đó – nhưng nếu bạn đang ở trong Notion document, bạn có thể thấy bạn có thể cung cấp cho nó persistent memory (bộ nhớ vĩnh viễn); nó sẽ ghi nhớ qua các sessions (phiên). Tôi cung cấp cho bạn mọi thứ bạn cần để thiết lập điều đó. Đây là các hướng dẫn để bạn đi qua và làm cho nó autonomous (tự chủ) nơi bạn vẫn có thể chat (trò chuyện) với nó qua Slack, nhưng nó cũng chạy hàng giờ và có mọi thứ được thiết lập. Và tất cả những điều đó đều ở đây để bạn thử nghiệm và mở rộng vượt ra ngoài điều này, mà tôi hy vọng đã thiết lập bạn khá tốt để có thể làm được điều đó. Chúng ta còn 10 phút, và thay vì bắt đầu điều tiếp theo, tôi chỉ muốn trả lời bất kỳ câu hỏi nào của mọi người hoặc chỉ trò chuyện về những gì sắp tới cho NAN, những gì bạn muốn nó trở thành, bất cứ điều gì như vậy. Vì vậy, bất kỳ câu hỏi nào tôi cũng sẽ vui lòng trả lời. Vâng.

Câu hỏi về Giới hạn Thực thi

Tôi muốn hỏi về các human in the loop executions (lần thực thi con người trong vòng lặp). Trường hợp của tôi là một self-hosted instance (phiên bản tự lưu trữ) trong đó chúng tôi có giới hạn về concurrent executions (số lần thực thi đồng thời).

Giới hạn thời gian chờ thực thi

Vì vậy, tôi đang hỏi liệu các lần thực thi đang chờ có được tính là các lần thực thi đang chạy hay không, bởi vì ví dụ, nếu bạn có giới hạn 10 lần thực thi đồng thời, bạn có thể bị kẹt do có thể 10 người dùng không phản hồi. Vâng, tôi không biết câu trả lời cho điều đó. Tôi không nghĩ là nó có tính, nhưng cũng có thể. Tôi sẽ gợi ý một điều bạn có thể làm để nếu nó được tính, thì điều này sẽ giảm bớt khó khăn một chút. Bạn có thể giới hạn thời gian chờ. Vì vậy, bạn có thể thiết lập là sau 10 phút, tự động từ chối nó, đúng không? Khi đó, bạn sẽ không để chúng cứ chất đống vô thời hạn nếu ai đó bỏ lỡ. Tôi biết điều đó đôi khi vẫn xảy ra. Và rồi chúng ta sẽ không đến cái điểm mà quy trình này bị cạn kiệt. Vậy bạn có thể đặt giới hạn thời gian. Bạn có biết câu trả lời cho điều đó không? Tôi không biết. Vâng. Vì vậy, chúng tôi chắc chắn có thể liên hệ lại với bạn. Tôi có thể tìm hiểu sau phiên này. Cảm ơn.

Quy trình phê duyệt trong làm việc nhóm

Có câu hỏi nào khác không? Chào, vâng, trong một thiết lập nhóm nơi có nhiều người có khả năng làm việc trên cùng một workflow và những thứ tương tự, quy trình phê duyệt hoạt động như thế nào, và bạn có thứ gì đó tương tự như một PR flow (quy trình yêu cầu kéo) thông thường không, nơi có người phải vào và phê duyệt các thay đổi để đảm bảo nó phù hợp với ngữ cảnh? Vâng, bạn có thể có trong trigger (kích hoạt) và đây là điều tuyệt vời khi mọi thứ đều rất tùy biến. Bạn nói Microsoft Teams? Ồ, nếu bạn có các nhóm. Không, nhưng bên trong một nhóm. Vâng. Vì vậy, điều bạn có thể làm là trigger, giả sử đó là Slack, nó có thể lấy user ID (mã người dùng) và sau đó người phản hồi sẽ tham chiếu user ID đó để phản hồi. Nhưng sau đó, giả sử công cụ này đang yêu cầu ngày nghỉ phép. Rõ ràng, điều đó không nên gửi cho người đã hỏi, đúng không? Vì vậy, tin nhắn Slack đó bạn chỉ cần thay đổi trường người nhận thành bất kỳ người ra quyết định nào hoặc bất kỳ kênh nào, và sau đó họ có thể nhấn phê duyệt hoặc từ chối. Đó có phải là điều bạn muốn hỏi không? Không hẳn. Ồ, xin lỗi. Điều bạn muốn hỏi là gì? Nhưng đó là một điều bổ sung tốt. Không. Câu hỏi của tôi xoay quanh việc quản lý các workflow nói chung. Bạn có một dự án, có người ban đầu thiết lập nó, và sau đó bạn mời một số người khác vào gói nhóm của mình, những người cũng được cho là sẽ giúp đỡ, có thể thêm một số node (nút), tinh chỉnh, có thể khi bạn đang đi nghỉ mát, v.v. Bạn có một quy trình phê duyệt nào đó trong nền tảng NAD không, quy trình nói rằng "này, tôi đã thực hiện các thay đổi, tôi đã tạo một nhánh từ đây, đã thực hiện các thay đổi, tôi muốn đẩy chúng, ai có thể chấp nhận điều này", v.v.

Quản lý quy trình làm việc và phê duyệt

Vâng. Vì vậy, câu trả lời sẽ thực sự phụ thuộc vào việc bạn có phải là khách hàng doanh nghiệp (enterprise) hay không. Giả sử đó không phải là gói enterprise. Điều đó sẽ chỉ là vấn đề thiết kế workflow để thực hiện, và sau đó chỉ là quản lý nội bộ, ví dụ bạn tạo một bản sao của nó và sau đó người chịu trách nhiệm quản lý sẽ thay thế nó bằng những thay đổi đó. Nếu bạn đang sử dụng gói enterprise, có một tính năng environments (môi trường) và Git đầy đủ, đó chính xác là điều đó. Nó có tích hợp Git. Bạn có thể có nhiều môi trường. Vì vậy, bạn có thể có dev (phát triển), staging (thử nghiệm) và prod (sản xuất), và bạn có thể có những người quản lý điều đó cùng với những người phê duyệt cụ thể. Nhưng xét về việc nhiều người sử dụng, bạn có ý là nhiều người sử dụng cùng một workflow hay chỉnh sửa nó?

Cập nhật quy trình làm việc và chỉnh sửa cộng tác

Chủ yếu là chỉnh sửa. Vâng. Vâng. Đó là một điều có thể hơi phức tạp với các branch (nhánh). Ví dụ, nếu bạn muốn có một feature branch (nhánh tính năng) hoặc tương tự, đó sẽ là điều bạn cần phải sao chép, mang nó về, thực hiện các thay đổi hoặc sử dụng gói enterprise và sử dụng tính năng tích hợp Git. Điều đó đã tốt hơn rất nhiều gần đây vì hiện tại chưa có tính năng hai người chơi hoàn chỉnh nơi bạn có thể thấy hai người làm việc trên workflow cùng lúc, nơi bạn có thể làm việc trên workflow với người khác theo thời gian thực. Nhưng hiện có các bản cập nhật trực tiếp ở chế độ nền nhờ tính năng autosave (tự động lưu). Vì vậy, ví dụ, nếu bạn đang làm việc trên một workflow với người khác từ xa, bạn có thể thấy nhau di chuyển các thành phần xung quanh và những thứ tương tự.

Xử lý "Human in the Loop" không giao diện người dùng

Cảm ơn. Vâng. Được rồi, một vài câu hỏi cuối cùng nếu ai đó có. Vâng. Còn về human in the loop (con người trong vòng lặp) cho các trường hợp không có UI (giao diện người dùng) thì sao? Bởi vì tôi thấy nó hiển thị hai nút là chấp nhận và từ chối. Nhưng tôi đoán rằng nếu bạn chỉ phản hồi "chấp nhận" cho LLM, nó không thể tự thực thi công cụ. Chính xác. Vì vậy, trong các trường hợp như cuộc gọi điện thoại, không có nút để nhấp, bạn mong đợi tác nhân sẽ yêu cầu xác nhận. Ví dụ, trong một cuộc gọi điện thoại với một tác nhân đặt lịch hẹn cho bạn, và có thể nó chỉ hỏi xác nhận trước khi thực hiện điều đó. Vậy, nó có thể xử lý một tình huống như vậy trong đó lời nhắc nên gợi ý nút nào để nhấp không? Vì vậy, tôi không chắc liệu chúng ta có bao giờ có được... bởi vì điều đó sẽ yêu cầu LLM quyết định liệu nó có được phê duyệt hay từ chối, trong khi toàn bộ mục đích của điều này là đánh giá của con người. Nó không thể vượt qua nếu không có sự xem xét đó. Vì vậy, đó là một bức tường gạch. DMZ, không có gì có thể vượt qua, đúng không? Tuy nhiên, hiện tại nó chỉ hỗ trợ các nền tảng chat. Tôi muốn chúng ta cũng có khả năng nói custom (tùy chỉnh) và nó trả về các webhook vì về cơ bản, nó đang tạo ra một endpoint (điểm cuối) mà sau đó các nền tảng chat đó gửi các yêu cầu API đến. Tôi rất muốn nếu tôi chỉ có hai liên kết API đó, nơi nó chỉ đặt một token duy nhất để biết cái nào là cái nào và sau đó bạn có thể tự tích hợp nó. Hy vọng điều đó sẽ đến cuối cùng. Nhưng đối với trường hợp sử dụng cụ thể của bạn, tôi sẽ nói rằng bạn có thể sử dụng một subworkflow và thực hiện logic đó một cách thủ công. Vì vậy, bạn có thể tạo một subworkflow và bạn có thể có hành động nơi nó thực sự hỏi câu hỏi, bạn nhận được phản hồi và sau đó bạn chỉ cần sử dụng một if node (nút điều kiện) nếu nó được phê duyệt, nếu không, và sau đó bạn có hai nhánh dựa trên đó. Và bạn có thể làm điều đó trong một công cụ với execute subworkflow. Và bạn có thể đặt tên nó là confirm (xác nhận) và sau đó nó có thể phản hồi true (đúng) hoặc false (sai) hoặc bất cứ điều gì nó cần làm. Vì vậy, bạn có thể trừu tượng hóa điều đó thành một công cụ. Nó sẽ chỉ là thiết kế workflow thay vì bước đánh giá đơn vị. Điều đó có ý nghĩa không?

Triển khai quy trình làm việc dưới dạng API

Tuyệt vời. Cảm ơn. Được rồi. Một câu hỏi cuối cùng. Vâng. Giả sử bạn thiết kế một workflow trong... và bạn muốn sử dụng nó như một API và gọi nó từ một nơi khác, giống như trong công ty tôi, chúng tôi có thể triển khai các sản phẩm của Microsoft, phần còn lại thì phức tạp hơn, nhưng sử dụng nó như một engine (công cụ) và sau đó chỉ cần gọi nó và ẩn đi... điều đó có khả thi không? Tuyệt đối. Tôi thường xuyên tạo ra các REST API hoàn chỉnh trong NAND và tôi tạo ra những thứ phức tạp như Swagger docs và bất cứ thứ gì, giống như tôi đã đề cập với việc tạo mã giảm giá. Tôi đã tạo toàn bộ công cụ mã giảm giá đó. Đó là một REST API để những người khác trong nhóm của chúng tôi có thể tích hợp vào các workflow NAND của họ và vào các công cụ bên ngoài. Và tôi đã tạo tất cả những điều đó và sau đó chỉ cung cấp cho họ các REST API docs (tài liệu API REST), và tất cả đều nằm trong NAND và mọi thứ được quản lý trong đó, bao gồm cả human in the loop và mọi thứ. Vì vậy, tôi hy vọng điều đó trả lời câu hỏi của bạn. Hoàn toàn có thể. Bạn chỉ cần tạo một web hook trigger như thế này. Và sau đó bạn sẽ có một path (đường dẫn) ngay tại đây. Và bạn cũng có thể sử dụng các tên theo kiểu RESTful. Ví dụ, bạn có thể tạo user và sau đó là post để tạo một user chẳng hạn, nếu điều đó có ý nghĩa.

Tối ưu hóa tác nhân với Sub-Agent và Ngữ cảnh

Được rồi. Và tôi nghĩ đó là tất cả thời gian chúng ta có. Tôi hy vọng điều này hữu ích và cho bạn thấy những điều mới mẻ, và bạn đã học được nhiều điều, và sau này bạn sẽ mở rộng nó để có nhiều hơn chỉ Gmail và Google Calendar để làm tất cả những gì bạn muốn. Một điều tôi muốn nói là nếu bạn định thêm nhiều công cụ hơn vào đây, hãy sử dụng sub agent tool, tức là một tác nhân, và sau đó bạn có thể có một tác nhân gọi các tác nhân chuyên biệt khác. Vì vậy, tác nhân chúng ta vừa tạo có thể trở thành một sub-agent quản lý lịch và email. Và bạn có thể xây dựng bao nhiêu sub-agent tùy thích. Sub-agent này có thể quản lý các issue GitHub của bạn. Sub-agent này có thể là tác nhân quản lý Jira của bạn (chúa phù hộ), và danh sách cứ thế tiếp tục. Bằng cách đó, bạn sẽ không thêm quá nhiều ngữ cảnh vào tác nhân chính, và bạn có thể thay đổi mô hình giữa mỗi tác nhân. Mỗi tác nhân có thể có một Mô hình Ngôn ngữ Lớn (LLM) khác nhau được tối ưu hóa cho chức năng riêng của nó. Hy vọng điều đó có ý nghĩa và tôi rất mong các bạn sẽ thử nghiệm.

Lời kết

Nếu các bạn gặp bất kỳ ai trong chúng tôi hoặc tôi vào bất kỳ thời điểm nào khác trong hội nghị, vui lòng đến và trò chuyện. Và đừng quên đi và sử dụng thiết bị của bạn. Vâng, tôi đã liên tục nhấn "trì hoãn" cái này trong suốt tháng qua và tôi nghĩ rằng nó sẽ buộc cập nhật trong sự kiện. Vì vậy, nó xuất hiện chính xác vào 12 giờ. Vậy đó là phiên làm việc. Cảm ơn các bạn rất nhiều.