Thực hành tốt nhất

Bài này tổng hợp các "hố đã giẫm". Ai từng viết trên 10 workflow sẽ thấy đồng cảm; chưa viết thì cứ lưu lại, gặp phải quay lại xem.

I. cách viết một workflow "lên được production"

Chạy từ mẫu

Ngay cả khi trường hợp sử dụng của bạn có vẻ độc đáo, trong số những mẫu 240+ thường có một trong những bạn có thể "giữ một nửa, thay một nửa." Bắt đầu từ một mẫu tiết kiệm được rất nhiều thời gian để xây dựng bộ xương từ vết xước.

Ngay từ mẫu là nơi hầu hết người dùng bắt đầu.

Làm "phiên bản ngờ nghệch nhất" trước, rồi mới đến "phiên bản thông minh"

Phiên bản đầu tiên của quy trình làm việc mới:

• Giá trị mặc định được mã hóa cứng cho các biến
• Đừng thêm điều kiện, chỉ cần chạy tất cả.
• Sử dụng Khóa LLM hợp nhất của nền tảng, không cần lo lắng về BYOK
• Không treo cron, chạy thủ công

Chạy thông rồi mới "tinh chỉnh" từng thứ: biến hóa, phân nhánh, BYOK, cron, phê duyệt. Như vậy mỗi bước có vấn đề đều dễ khoanh vùng.

Chạy khô mỗi khi bạn thực hiện thay đổi

Đã thay đổi nội dung nào đó → chạy thử để xem cấu trúc DAG và luồng biến → chạy lại. Chi phí chạy thử bằng 0, đừng nhảy.

2. Lựa chọn loại bước

Ưu tiên là từ trên xuống dưới. Nếu bạn gặp khó khăn trong việc lựa chọn, hãy chọn thứ được xếp hạng cao hơn:

1. code — Nếu bạn có thể sử dụng logic xác định thì đừng sử dụng LLM. Nhanh, rẻ, có thể kiểm tra.
2. classifier — Sử dụng nó khi LLM được yêu cầu nhưng đầu ra là một danh mục; không sử dụng đơn để cho Agent chơi tự do.
3. single — Phần lớn các tác vụ "tóm tắt / trích xuất / viết lại".
4. sub_workflow — 同一段逻辑在多个 workflow 里复用，或单 workflow > 15 个 step。
5. group_chat — Hãy sử dụng nó khi một nhiệm vụ cần một số cách để giải quyết vấn đề, sử dụng độc lập khi một Agent có thể xử lý nó một mình.
6. agent_based — Nhiệm vụ có đặc điểm phân nhánh mạnh mẽ và mỗi nhánh yêu cầu LLM xác định nơi gửi nó.
7. state_machine — Có sự chuyển đổi trạng thái rõ ràng, chẳng hạn như nhiều vòng đời tương tác/lệnh công việc.
8. manual_approval — Nó phải được thêm vào trước bất kỳ bước nào ảnh hưởng đến trực tuyến / tiêu tiền / các bên bên ngoài.

3. Biến và luồng dữ liệu

Các trường lớn được trích xuất trước rồi mới được chuyển qua

Khi bước ngược dòng trả về 100KB JSON, đừng gửi trực tiếp nó đến tác vụ xuôi dòng. Sử dụng trích xuất để chọn các trường bạn thực sự cần:

- id: fetch_data
  type: code
  code: |
    // 返回一个很大的 JSON
    return await heavyFetch();
  extract:
    user_count: $.data.stats.total_users
    top_3: $.data.items[:3].name

Sử Dụng | mặc định (...) để tìm hiểu

Khi đề cập đến một biến có thể trống (đầu ra của một bước bị bỏ qua theo điều kiện), hãy thêm mặc định:

- id: summarize
  type: single
  agent: writer
  condition: "length({{steps.classify.categories}} | default([])) > 0"
  task: "{{steps.classify.output | default('无内容可摘要')}}"

condition Chi nhánh vs on_failure

Đừng trộn lẫn:

• condition quyết định "bình thường có đi qua bước này không" — bỏ qua = SKIPPED (không tính là thất bại)
• on_failure là "hành động bù sau lỗi" — gửi thông báo / hạ cấp sang nguồn dữ liệu dự phòng

Sử dụng on_failure dưới dạng thử bắt, nhưng không phải như một nhánh bình thường. Logic nghiệp vụ thông thường sử dụng điều kiện.

4. Đại lý và người mẫu

tool_set Càng nhỏ càng tốt

Các công cụ được cung cấp bởi cài đặt trước mặc định không được sử dụng trong hầu hết các bước. Cắt thành 2-3 miếng - tỷ lệ thành công tăng lên và mức tiêu thụ mã thông báo giảm.

Người mẫu được lựa chọn theo nhiệm vụ

• Lý luận / Đánh giá mã → Claude Opus 4 / GPT-5 / DeepSeek-Reasoning
• Tóm tắt ngắn / Danh mục → Haiku / GPT-4.1-mini / DeepSeek-V3.5
• Viết tiếng Trung → Claude Sonnet / Kimi K2
• Ngữ cảnh dài (32K+) → Kimi K2 / Claude 200K

Nhiệt độ Chọn theo nhiệm vụ

• 0,0 – 0,3 – Lý luận/Phân loại/Trích xuất (ổn định)
• 0,4 – 0,7 – tóm tắt/viết lại (cân bằng)
• 0,7 – 0,9 – Viết sáng tạo/ động não (hãy sáng tạo)

5. tiếp tục bình thường và tự động

Tất cả các bước của đường dẫn dữ liệu thuần túy đều thêm idempotent: true - dịch vụ có thể tiếp tục chạy sau khi khởi động lại. Không thêm các bước có tác dụng phụ (gửi tin nhắn/đặt hàng).

Xem chi tiết Đã Cập nhật.

6. Chia tách và mô đun hóa

1. Một workflow có hơn 15 bước - cần được chia nhỏ.
2. Logic 3-5 bước tương tự cần được sử dụng trong quy trình làm việc khác - logic này phải được tạo thành một mô-đun (sub_workflow).
3. Sau khi mô-đun được giải phóng, việc xóa đầu vào/thay đổi loại sẽ làm mất khả năng tương thích và phiên bản CHÍNH phải được nâng cấp.

7. Kiểm soát chi phí

• chạy khô trước — Như đã đề cập, một cuộc chạy thật lãng phí tốn kém nhất, vì vậy điều này tiết kiệm nhiều nhất.
• Phân loại bằng mô hình giá rẻ — Trình phân loại 9 trên 10 không yêu cầu Opus/GPT-5.
• Có giới hạn trên về sự đồng thời — Để xử lý hàng loạt, hãy sử dụng sub_workflow + max_parallel để kiểm soát đồng thời và đừng để TPM bùng nổ.
• Chỉ mục RAG bộ nhớ đệm — Việc nhúng lại cùng một kho văn bản mỗi lần và duy trì kết quả cho sản phẩm sẽ rất tốn kém.
• Báo động ngân sách ràng buộc — 在通知设置里加"单 execution cost > $1"或"当日累计 > $50"告警。

8. Bảo mật và tuân thủ

• Không bao giờ viết khóa vào YAML - hãy sử dụng Trung tâm thông tin xác thực.
• Danh sách thông tin xác thực của bước mã: phải rõ ràng - không cung cấp thông tin xác thực bước mà nó không cần.
• Thêm manual_approval trước khi thanh toán, giao tiếp bên ngoài hoặc ghi vào cơ sở dữ liệu khách hàng.
• Xem xét việc mở workflow liên quan đến dữ liệu người dùng chấp thuậnDanh sách người phê duyệt để nhóm tuân thủ nhập vào.
• Hãy thường xuyên xem lại cách chuyển đổi của trình duyệt Mạng Internet.

9. Quá trình thử nghiệm và ra mắt

1. Quy trình làm việc mới lần đầu tiên được chạy thử trên trang quy trình kiểm tra.
2. Chạy riêng tập lệnh bước mã trong nút/python cục bộ để xem kết quả.
3. Chạy hành vi của Agent bằng trình gỡ lỗi điểm dừng + mẫu nhỏ 10 lần để kiểm tra độ ổn định.
4. Trước khi đưa lịch vào chạy, dùng "Kích hoạt ngay một lần" để kiểm tra múi giờ / bộ tham số.

10. Hợp tác và phiên bản

• Trước thay đổi quan trọng hãy "xuất YAML" sao lưu cục bộ — dù đã có lịch sử phiên bản, một bản sao cục bộ vẫn yên tâm hơn.
• Chỉnh sửa nhiều người: một người lấy khóa, lưu các thay đổi, mở khóa và sau đó người tiếp theo sẽ lấy nó. Vui lòng chia thay đổi song song thành các workflow phụ.
• Đồng bộ hóa với nhóm trước khi có những thay đổi lớn về phiên bản - những người khác có thể đang dựa vào mô-đun của bạn.

11. Giám sát và cảnh báo

• Quá trình thực thi.không thành công của quy trình làm việc chính được gắn với thông báo Slack/Feishu - nếu thất bại, bạn sẽ biết ngay lập tức.
• Kiểm tra bảng điều khiển dữ liệu thường xuyên - workflow nào đắt nhất/chậm nhất/thất bại thường xuyên nhất? Tối ưu hóa bắt đầu với nó.
• Kiểm tra nhật ký kiểm tra mỗi tháng một lần - có ngoại lệ nào đối với quyền/người đã sử dụng thông tin xác thực hay không.

12. Tôi đã hoàn thành danh sách kiểm tra quy trình làm việc

1. chạy khô đã qua
2. Chạy thành công
3. Chiến lược bình thường/thử lại cho từng bước được xác nhận
4. Có các biện pháp kiểm soát rõ ràng về điều kiện hoặc phê duyệt thủ công trước các tác dụng phụ bên ngoài.
5. Tất cả thông tin xác thực được phân tích cú pháp từ Trung tâm thông tin xác thực, không có khóa văn bản gốc trong YAML
6. Gắn xong cron / webhook và xác nhận "thời điểm kích hoạt kế tiếp"
7. Thiết lập thông báo lỗi (ít nhất là đẩy exec.failed tới Slack)
8. Xuất bản sao YAML sang git để sao lưu bên ngoài trang web

Đề Nghị đọc thêm

• Tham chiếu cú pháp YAML — Các trường mờ không thể được kiểm tra chính xác
• @ Info: status — Một công cụ để xác định vấn đề trong các quy trình phức tạp
• Tên — So sánh triệu chứng cụ thể