Một release checklist bốn bước nghe không phức tạp: đọc changelog, chạy test, tóm tắt lỗi rồi soạn release note. Nhưng nếu mỗi lần lại copy bốn prompt, đầu ra rất dễ đổi định dạng, bỏ sót cổng kiểm tra hoặc đi tiếp khi test chưa đạt. GitHub Copilot dynamic workflows nhắm đúng khoảng trống đó: phần orchestration được định nghĩa bằng code, còn agent chỉ xử lý phần cần phân tích hoặc phán đoán.
Tính năng được GitHub công bố ngày 01/10/2026 và hiện vẫn ở public preview. Bài này là phần giải thích và decision guide dựa trên tài liệu hiện hành, không phải review trải nghiệm. Môi trường kiểm tra không có Copilot CLI nên không có run ID, số AI credit hay kết quả workflow thật để công bố.
Mục lục [Hiển thị]
- Dynamic workflow khác prompt thường và /fleet ở đâu?
- Một release checklist tối thiểu nên chạy thế nào?
- Phần nào để code làm, phần nào mới giao cho agent?
- Checkpoint, pause và resume giúp gì?
- Chạy từ CLI cần cẩn thận quyền và output
- Đặt giới hạn trước khi chạy, nhưng hiểu đúng “giới hạn”
- Khi nào đáng dùng dynamic workflow?
Dynamic workflow khác prompt thường và /fleet ở đâu?
GitHub Changelog mô tả dynamic workflow là một chương trình kết hợp bước tự động với công việc của một hoặc nhiều agent. Các bước có thể chạy tuần tự, song song hoặc trộn cả hai; workflow cũng có thể truyền kết quả có cấu trúc, dừng ở checkpoint và tiếp tục sau khi người dùng duyệt.
| Cách làm | Ai quyết định luồng? | Hợp với việc nào? |
|---|---|---|
| Prompt / autopilot | Copilot quyết định bước tiếp theo | Câu hỏi nhanh, thay đổi nhỏ, task một lần |
/fleet | Copilot tự chia và điều phối subagent | Công việc song song nhưng không cần flow cố định |
| Dynamic workflow | Tác giả định nghĩa bước, điều kiện và handoff bằng code | Quy trình lặp lại, cần checkpoint, schema và giới hạn |
Khác biệt chính không nằm ở số agent. Một dynamic workflow có thể chỉ dùng một agent; giá trị của nó là cùng một luật điều phối được áp dụng lại. Theo tài liệu khái niệm của GitHub, autopilot ưu tiên tính tự chủ, /fleet để Copilot quyết định cách chia việc, còn dynamic workflow để người viết workflow giữ quyền kiểm soát process.
Vì vậy, đừng biến mọi prompt thành extension. GitHub cũng nói prompt thường đã đủ cho câu trả lời nhanh hoặc thay đổi đơn giản. Code hóa một task chỉ chạy một lần thường tạo thêm việc bảo trì mà không thêm độ tin cậy đáng kể.
Một release checklist tối thiểu nên chạy thế nào?
Hãy lấy một fixture không có secret và không publish thật. Workflow đọc version cùng changelog từ file cố định, chạy unit test, yêu cầu agent phân nhóm failure thành JSON, sau đó dừng để người dùng duyệt. Chỉ sau checkpoint nó mới tạo release note giả trong thư mục tạm. Không push tag, không tạo GitHub Release và không đụng package registry.
- Kiểm branch sạch, đọc version và xác nhận changelog có section tương ứng.
- Chạy test; lưu exit code và đường dẫn artifact thay vì chỉ hỏi agent “test ổn không?”.
- Nếu test fail, đưa log đã giới hạn phạm vi cho agent phân nhóm; validate JSON trả về bằng schema.
- Pause ở checkpoint để người dùng xem failure, quyền và giới hạn.
- Resume để tạo release note nháp; dừng trước mọi thao tác publish.
Positive control là fixture pass, JSON đúng schema và note giả được tạo sau khi resume. Negative control quan trọng hơn: test fail thì flow phải dừng đúng chỗ; JSON sai schema phải bị từ chối; thiếu quyền không được âm thầm mở rộng; chạm timeout hoặc agent limit phải để lại trạng thái có thể đọc. Tư duy này cũng giống bài Laravel Boost: Test xanh chưa đủ cho code AI chất lượng: một kết quả “có vẻ đúng” chưa thay cho convention, kiểm chứng và review.
Phần nào để code làm, phần nào mới giao cho agent?
Những việc có câu trả lời nhị phân nên deterministic: file có tồn tại không, command trả exit code nào, branch có sạch không, JSON có khớp schema không. Agent phù hợp hơn với phần cần judgment như nhóm failure liên quan, giải thích rủi ro hoặc viết nháp release note từ dữ kiện đã kiểm.
Ranh giới này ngăn một lỗi khá nguy hiểm: agent tự diễn giải rằng một test “không quan trọng” rồi đi tiếp. Workflow code phải là nơi quyết định cổng chặn. Agent có thể đề xuất, nhưng không được tự bỏ test, thay schema hoặc mở rộng quyền. Với phần review cần suy luận, có thể tham khảo kết quả thực tế của lệnh Copilot /security-review trước commit; đó vẫn là một công cụ review, không phải bằng chứng rằng toàn bộ release flow đã an toàn.
Structured output cũng không tự biến nội dung AI thành sự thật. Schema chỉ bảo đảm hình dạng dữ liệu. Mỗi field quan trọng vẫn cần nguồn: tên test từ log, file từ diff, version từ manifest. Nếu agent trả một nguyên nhân không dẫn về artifact nào, workflow nên đánh dấu đó là nhận định cần duyệt thay vì fact.
Checkpoint, pause và resume giúp gì?
Trong Copilot CLI, /workflows hiển thị các run đang hoạt động và gần đây, gồm thời gian chạy, phase hiện tại, số subagent và AI credit đã dùng. Run có thể được pause hoặc cancel. Tài liệu lưu ý run bị cancel không resume được; run bị pause hoặc dừng do chạm limit có thể tiếp tục nếu còn ở trạng thái resumable.
Resume không đồng nghĩa mọi việc đều được khôi phục hoàn hảo. Kết quả đã lưu từ bước hoàn tất hoặc subagent có thể được dùng lại, nhưng phần chưa lưu có thể phải chạy lại. Nếu run dừng vì limit, mức limit mới là tổng của toàn run; lượng đã dùng trước đó vẫn được tính. Đây là lý do workflow nên có bước nhỏ, output rõ và thao tác idempotent thay vì một khối dài tới công chuyện.
Chạy từ CLI cần cẩn thận quyền và output
Hướng dẫn sử dụng dynamic workflows yêu cầu bật experimental features trong Copilot CLI. Một workflow đã có trong personal extension, project extension hoặc plugin có thể chạy bằng lệnh:
copilot workflow run release-check \
--args @workflow-input.json \
--result-file release-result.json \
--allow-tool=readĐiểm dễ bỏ qua: copilot workflow run không hiện permission approval prompt trong lúc chạy. Quyền phải được cấp trước bằng các option phù hợp; yêu cầu không thể tự duyệt sẽ bị từ chối. Với project extension, chỉ nạp code từ repo đã tin cậy. Đừng đưa PAT, API key hoặc nội dung repo private vào prompt, fixture, ảnh hay result file.
--result-file chỉ được ghi khi workflow hoàn tất thành công và có giá trị trả về. Run pause, fail hoặc bị ngắt không thay file kết quả cũ. Script tích hợp vì thế phải kiểm exit code và record trạng thái trước khi đọc file, kẻo lấy nhầm kết quả của lần chạy trước rồi tưởng là hàng mới.
Permission boundary cũng nên được review như một workflow CI bình thường. Bài GitHub Actions chặn workflow đáng ngờ là một checklist hữu ích: pin nguồn đáng tin, giới hạn token, kiểm code được nạp và không tự động hóa write action chỉ vì công cụ hỗ trợ.
Đặt giới hạn trước khi chạy, nhưng hiểu đúng “giới hạn”
Dynamic workflow hỗ trợ bốn nhóm limit: số subagent hoạt động đồng thời, tổng số subagent được tạo, active runtime và mức AI credit xấp xỉ. Giới hạn concurrent làm agent mới chờ chứ không dừng run; các limit còn lại có thể làm run dừng để resume sau.
AI credit limit không phải trần cứng. GitHub giải thích usage được ghi nhận sau khi công việc xảy ra, nên phần đang chạy có thể đẩy tổng vượt mức đặt trước. Cách an toàn là test scope nhỏ, xem usage thật rồi mới tăng phạm vi. Bài này không có dữ liệu billing hoặc latency thật, vì vậy không đưa ra con số “nên đặt” chung cho mọi đội.
Về availability, changelog ngày phát hành nói dynamic workflows có trên mọi Copilot plan. Tài liệu hiện hành bổ sung ngoại lệ cho một số thuê bao Copilot Pro và Pro+ gói năm còn dùng legacy premium request billing. Nếu không thấy feature, kiểm tra plan/billing hiện tại và client mới nhất trước khi kết luận workflow bị lỗi.
Khi nào đáng dùng dynamic workflow?
| Tín hiệu | Lựa chọn hợp lý | Lý do |
|---|---|---|
| Task ngắn, một lần, ít rủi ro | Prompt thường | Không cần thêm extension và test flow |
| Cần Copilot tự chia nhiều việc song song | /fleet | Delegation linh hoạt quan trọng hơn thứ tự cố định |
| Checklist lặp lại, có cổng chặn | Dynamic workflow | Giữ bước, điều kiện, schema và checkpoint trong code |
| Publish production hoặc dùng quyền rộng | Workflow scope nhỏ + duyệt người dùng | Preview churn và permission cần được kiểm soát |
Dynamic workflow đáng thử khi đội đã biết process nào cần lặp lại và phần nào bắt buộc deterministic. Nó không sửa được một checklist mơ hồ; chỉ làm sự mơ hồ chạy đều hơn. Bắt đầu bằng fixture nhỏ, read-only, có positive lẫn negative control, rồi mới cân nhắc repo thật.
Chốt lại, release checklist là ví dụ hợp lý vì có chuỗi bước rõ, artifact kiểm được và điểm dừng tự nhiên trước publish. Nếu chỉ muốn hỏi nhanh hoặc sửa một file, prompt thường gọn hơn. Nếu cần cùng một flow, cùng output và cùng ranh giới quyền qua nhiều lần release, code hóa orchestration mới bắt đầu đáng công bảo trì.
