Tác nhân chọn được nhánh tiếp theo: Dify 1.18 giúp quy trình dễ chuyển và kiểm tra hơn
Dify 1.18 thêm định tuyến đầu ra tác nhân, gói ứng dụng di chuyển được và khả năng quan sát sâu hơn. Ý nghĩa với nhóm muốn biến bản diễn thử thành quy trình kinh doanh tái sử dụng.
Bản diễn thử tác nhân có thể thuyết phục chỉ sau một yêu cầu thành công. Câu hỏi khó tới khi nhóm thứ hai muốn dùng lại: nó chọn nhánh nào, tệp nào đi cùng ứng dụng và xem được chuyện xảy ra trong quy trình lồng nhau ở đâu?
Dify 1.18.0, phát hành ngày 23 tháng 10 năm 2026, đặt các câu hỏi ấy cạnh nhau. Bản này giới thiệu Output Routes cho tác nhân, gói ứng dụng .ifpkg có thể chuyển và khả năng quan sát quy trình sâu hơn. Thay đổi không chủ yếu nhằm cho câu trả lời ấn tượng hơn, mà làm vai trò tác nhân trong ứng dụng đủ rõ để tái dùng. Bản phát hành chính thức.
Dify là nền tảng xây ứng dụng AI bằng quy trình trực quan, mô hình, kiến thức và công cụ. Nhóm dùng nó nối nhận định mô hình với các bước ứng dụng thay vì liên tục chép cùng lời nhắc vào trò chuyện. Điều thú vị là nó nối ba việc thực tế: chọn bước tiếp, chuyển ứng dụng và xem xét thực thi.
Giao diện quy trình của LangGenius / những người đóng góp tài liệu Dify, CC BY 4.0. Đã đổi kích thước và chuyển WebP, không cắt. Màn hình minh họa trình dựng trực quan, không phải mọi điều khiển mới phát hành.
Một nhánh là quyết định có điểm đến
Trong quy trình truyền thống, điều kiện thường kiểm tra giá trị đã biết: trạng thái đã duyệt, trường rỗng hoặc điểm vượt ngưỡng. Yêu cầu bằng ngôn ngữ ít gọn gàng hơn. Khách có thể trộn câu hỏi, phàn nàn và xin ngoại lệ trong một tin.
Output Routes mới của Dify cho tác nhân chọn giữa các tuyến đã cấu hình để quy trình tiếp tục theo nhánh tương ứng. Cách hiểu của tác nhân trở thành lựa chọn trong quá trình; bước tiếp hiện trong quy trình thay vì để hoàn toàn trong văn bản được tạo.
Ứng dụng nhờ đó dễ thiết kế và xem xét hơn. Người dựng quyết định các điểm đến tồn tại. Tác nhân chọn một điểm cho yêu cầu. Quy trình làm các bước được nối. Tuyến vẫn hữu ích dù lời giải thích ngôn ngữ của tác nhân không phải sản phẩm cuối.
Ranh giới quan trọng. Chọn tuyến “chuyển cấp” không chứng minh trường hợp cần chuyển cấp theo pháp lý hay tài chính. Chọn “soạn trả lời” không cho phép gửi. Quy trình vẫn phải quy định thao tác nào được phép sau lựa chọn và ai phụ trách ngoại lệ.
Ví dụ một: một tin khách hàng, ba đường khả dĩ
Xét nhóm hỗ trợ nhận cả câu hỏi sản phẩm lẫn yêu cầu ngoại lệ. Họ muốn ứng dụng phân biệt ba đường: trả lời từ tài liệu hỗ trợ đã duyệt, chuẩn bị nháp cho người hoặc chuyển cấp trường hợp bất thường.
Với tuyến rõ, các điểm đến hiện trong quy trình. Câu hỏi thiết lập đơn giản vào đường trả lời dựa trên kiến thức. Yêu cầu có điều chưa rõ riêng tài khoản vào đường xét duyệt. Yêu cầu vượt điều kiện thương mại tới nhóm chịu trách nhiệm quyết định.
Đó là lựa chọn ứng dụng minh họa, không phải chính sách hỗ trợ làm sẵn của Dify. Nhóm phải định nghĩa nội dung từng tuyến, cho ví dụ phù hợp và quyết định đầu vào mơ hồ xử lý thế nào. Lời giải thích thuyết phục không được xóa ranh giới thẩm quyền.
Lợi ích không phải mọi tin đều dễ phân loại, mà người dựng đánh giá được quyết định cụ thể. Nếu tác nhân gửi tin khó vào nhánh trả lời thường, kiểm thử thất bại rõ. Nếu gửi mọi yêu cầu cho người, quy trình có thể an toàn nhưng ít tự động hóa hữu ích.
Giữ bộ tin khó và nơi đến mong đợi. Có yêu cầu pha trộn, thiếu thông tin và biến thể ngôn ngữ giống lưu lượng thật. Quy trình chỉ thành công với mẫu sạch nhất vẫn là bản diễn thử, dù sơ đồ trông đã xong.
Tuyến cấu hình biến nhận định ngôn ngữ thành điểm đến thấy được. Mỗi nơi vẫn cần hành động được phép và quy tắc xét duyệt riêng.
Chuyển được không chỉ là sao chép lời nhắc
Ứng dụng AI có thể phụ thuộc chỉ dẫn, định nghĩa tác nhân, Skills, tệp và tham chiếu tài nguyên trong không gian làm việc. Sao chép lời nhắc nổi bật nhất bỏ lại phần lớn ứng dụng.
Dify 1.18 giới thiệu gói .ifpkg chứa được Agents nội tuyến, Skills và tệp của chúng. Khi nhập, thông báo mô tả tạo lại tài nguyên và ánh xạ lại tham chiếu. Nhập tệp và URL hỗ trợ YAML cùng định dạng gói, còn xuất YAML tường minh vẫn có. Thay đổi gói và nhập.
Đây là thay đổi có ý nghĩa cho tái sử dụng. Nhóm có cơ hội tốt hơn để chuyển những mảnh giải thích cách tác nhân cùng hoạt động, thay vì để đồng nghiệp dựng lại từ danh sách hướng dẫn thủ công.
Nó không chứng minh mọi phụ thuộc ngoài tự chuyển. Truy cập mô hình, thông tin xác thực, plugin, quyền mạng và tài nguyên kiến thức có thể tùy môi trường đích. Ứng dụng nhập vào có thể nguyên cấu trúc nhưng vẫn cần cấu hình mới chạy đúng.
Hãy coi gói là sản phẩm ứng dụng hữu ích cần kiểm tra. Tệp mang được chỉ dẫn và nội dung hỗ trợ do nhóm khác viết. Trước khi nhập vào không gian có quyền quan trọng, hiểu nguồn gốc và việc tác nhân, công cụ dự kiến làm.
Ví dụ hai: quy trình đề xuất chuyển sang nhóm khác
Hình dung công ty dịch vụ đã dựng quy trình chuẩn bị nháp đề xuất đầu tiên. Nó thu yêu cầu, áp dụng Skill viết, kiểm tra đủ mục bắt buộc và chuyển điều khoản thương mại chưa rõ cho người.
Nhóm thứ hai muốn cùng cách làm với danh mục dịch vụ khác. Chỉ bàn giao lời nhắc là thiếu: chỉ dẫn viết tái sử dụng, mẫu đính kèm và tham chiếu tác nhân là một phần hành vi. Định dạng gói được thiết kế giúp chuyển nhiều phần liên quan cùng nhau hơn.
Nhóm nhận vẫn có việc. Họ phải thay hoặc xác nhận thông tin dịch vụ, cấu hình mô hình và công cụ cho phép, xác minh ai được duyệt đề xuất. Nếu quy trình nhập tham chiếu tài nguyên không thuộc không gian mới, nhập thành công không phải lý do bỏ qua kiểm tra tham chiếu đó.
Chạy cùng ít yêu cầu mẫu trước và sau chuyển. So tuyến chọn, mục bắt buộc, truy cập công cụ và xét duyệt. Ứng dụng chuyển được nên giữ quá trình mong muốn, đồng thời cho phép đổi có chủ đích thông tin riêng môi trường đích.
Đây là lúc đóng gói thành tính năng vận hành. Nó giảm dựng lại, nhưng kết quả hữu ích là bàn giao lặp được mà nhóm khác hiểu và thử được. Số lần nhấp tiết kiệm khi nhập chỉ là một phần.
Thấy bên trong quy trình đổi cách gỡ lỗi
Bản phát hành còn nhấn mạnh khả năng quan sát quy trình sâu hơn, gồm thực thi lồng nhau. Điều này quan trọng vì lỗi có thể cách nhiều bước so với nơi người dùng nhận thấy vấn đề.
Bản nháp cuối kém có thể do định tuyến sai, thiếu nguồn kiến thức, kết quả công cụ chưa đầy hoặc chỉ dẫn trong quy trình con. Nếu chỉ xem câu trả lời cuối, nhóm có thể cứ sửa lời nhắc không gây lỗi.
Thực thi thấy rõ hơn giúp hỏi hẹp: đầu vào nào tới bước này, nó tạo kết quả gì và bước nào dùng tiếp? Câu trả lời hỗ trợ sửa chính xác hơn thay nhiều phần một lúc.
Quan sát không phải giải thích đầy đủ suy luận nội bộ mô hình. Thông tin thực thi cho thấy sự kiện ứng dụng và luồng dữ liệu nhưng không xác lập vì sao mọi token hoặc tuyến được chọn. Nó cũng không tự quyết nội dung dấu vết nào hợp mọi người xem.
Dùng khả năng quan sát để hiểu hành vi quan sát được. Quyết riêng giữ dấu vết bao lâu, tài liệu nhạy cảm nào có thể xuất hiện và ai được xem. Ứng dụng xử lý yêu cầu kín không nên biến tiện gỡ lỗi thành quyền đọc nội dung không giới hạn.
| Khả năng trong 1.18 | Cải thiện thực tế nên đánh giá | Ranh giới còn lại |
|---|---|---|
| Output Routes của tác nhân | Lựa chọn ngôn ngữ có bước kế rõ | Tuyến được chọn vẫn cần quyền và xử lý lỗi |
Gói .ifpkg | Tài nguyên tác nhân và Skill liên quan đi cùng nhau | Vẫn kiểm tra truy cập ngoài và cấu hình đích |
| Quan sát quy trình sâu hơn | Xem được lỗi trong quá trình lớn | Dấu vết không chứng minh đáp án hay quyết định đúng |
Phát hành phần mềm và nâng cấp là hai câu hỏi riêng
Bản chính thức GitHub là phát hành phần mềm có ngày. Tự nó không chứng minh mọi không gian Dify được lưu trữ có cùng tính năng bật cùng lúc. Người dùng dịch vụ quản lý nên xem không gian thực và tài liệu trước khi lập kế hoạch dựa vào điều khiển cụ thể.
Bản tự lưu trữ có trách nhiệm khác. Ghi chú Dify 1.18 mô tả thay đổi đồng bộ API, worker, Agent Backend và ảnh môi trường chạy, gồm giao thức chạy tác nhân đã đổi. Nâng một thành phần dễ thấy không phải cách đáng tin để dùng bản thay giao tiếp giữa nhiều thành phần.
Ghi chú còn nêu chi tiết cấu hình và di chuyển cho môi trường cách ly tác nhân cục bộ và công cụ. Chúng thuộc kế hoạch nâng dựa trên bản cài thật, không nên rút thành một lệnh phổ quát chép từ bài tổng quan.
Trước nâng, giữ cấu hình hiện tại và sản phẩm ứng dụng, xác định phiên bản thành phần hỗ trợ và thử di chuyển trong môi trường phù hợp. Đừng thay thiết lập xác thực lâu dài hoặc liên quan mã hóa chỉ vì cấu hình mẫu có giá trị trông mới. Theo đúng hướng dẫn di chuyển của bản phát hành.
Nhóm chỉ muốn đánh giá tuyến hay gói có thể bắt đầu bằng ứng dụng thử riêng. Như vậy học hành vi mới mà không biến thử nghiệm đầu thành di chuyển quy trình quan trọng nhất.
Đánh giá hữu ích có thể gói trong một trang
Không cần hàng chục tác nhân để biết tính năng giúp không. Một ứng dụng có quyết định thật và môi trường thứ hai để thử nhập đủ bộc lộ nhiều thuộc tính quan trọng.
- Chọn nhiệm vụ có giới hạn. Lấy quá trình có đầu vào, kết quả nhận ra được, như chuẩn bị trả lời hỗ trợ cần duyệt. Nêu người chịu trách nhiệm ngoại lệ.
- Định nghĩa ít tuyến. Cho mỗi tuyến ý nghĩa vận hành và thao tác theo sau. Có đường cho yêu cầu không xếp an toàn được.
- Thu ca đại diện. Dùng yêu cầu thường, tin nhiều ý và thiếu thông tin. Ghi tuyến mong đợi trước khi chạy.
- Xem thực thi, không chỉ câu cuối. Theo các bước lồng liên quan, tìm nơi đầu tiên xuất hiện giá trị hoặc lựa chọn bất ngờ.
- Xuất và nhập ứng dụng. Duyệt tài nguyên trong gói, kiểm tra tham chiếu, công cụ, mô hình và bí mật ở đích. Đừng mặc định quyền thiếu phải tự cấp.
- Lặp lại cùng ca sau chuyển. So tuyến, đầu ra rồi ghi khác biệt có chủ đích trong cấu hình nhóm nhận.
Chỉ số hữu ích cụ thể: bao nhiêu yêu cầu tới đúng nơi, bàn giao cần cấu hình bao nhiêu và người duyệt tìm lỗi được mà không dựng lại cả lượt chạy không. Không số nào đòi xem văn bản tạo ra là bằng chứng tự nó đúng.
Gói chuyển được cấu trúc ứng dụng. Nơi nhận vẫn cần kiểm tra quyền riêng và lặp các ca định nghĩa hành vi thành công.
Điều hứa hẹn hơn và điều cần thận trọng
Hướng đáng kỳ vọng là đơn vị ứng dụng dễ tái dùng hơn. Quy trình có điểm đến rõ, mang thêm tài nguyên tác nhân hỗ trợ và cho xem thêm thực thi khi lỗi. Tổ hợp ấy hữu ích với nhóm đã vượt lời nhắc đơn lẻ nhưng không muốn mọi ứng dụng thành dự án tích hợp riêng.
Lo ngại tương ứng là tính di chuyển lan sai lầm hiệu quả như lan cách tốt. Tuyến mơ hồ hoặc công cụ quá mạnh không trở nên phù hợp vì tới trong gói gọn. Duyệt hành vi đang nhập, không chỉ tệp có mở thành công.
Với Dify, bài thử có ý nghĩa tiếp là duy trì ứng dụng qua thay đổi: mô hình khác, Skill mới, chính sách sửa hoặc chuyển không gian. Nhập đầu thành công đáng khích lệ. Cập nhật có kiểm soát giữ được hành vi mong muốn là dấu hiệu trưởng thành mạnh hơn.
Dify 1.18 khiến thử nghiệm ấy thú vị hơn bằng nối quyết định tác nhân với cấu trúc quy trình thấy được. Bắt đầu nhỏ, giữ tuyến dễ hiểu và làm bàn giao lặp được. Đó là cách bản diễn thử triển vọng thành thứ nhóm khác dùng có trách nhiệm.
Nguồn
- Ghi chú phát hành Dify 1.18.0, phát hành ngày 23 tháng 10 năm 2026, 06:33 UTC.
- Tài liệu Dify chính thức, bối cảnh sản phẩm; cần kiểm tra tính năng khả dụng trong không gian thực tế.
Muốn nơi tìm kiếm được cho ghi chú quy trình, yêu cầu mẫu và quyết định sau sửa đổi? Gom tài liệu tham khảo trong Telli.sh để việc bàn giao luôn rõ ràng.