Kanban mới của Hermes: bước tiến thực dụng cho agent workflow dài hơi

Hermes vừa có thêm Kanban, và điểm đáng chú ý không chỉ là giao diện kéo thả task. Nếu nhìn kỹ, đây giống một lớp phối hợp công việc bền vững cho agent: task có trạng thái rõ ràng, có lịch sử chạy, có phụ thuộc, và có chỗ để con người can thiệp khi cần.

Với anh em đang dùng agent để làm việc dài hơi, đây là thay đổi đáng để để ý.

Vì sao Kanban khác với việc giao task ngắn hạn

Trước đây, nhiều workflow agent thường xoay quanh kiểu: giao một việc cho subagent, chờ nó chạy, nhận kết quả, rồi tiếp tục. Cách này hợp với tác vụ ngắn, ví dụ:

• tóm tắt một tài liệu
• sửa một lỗi nhỏ
• tìm thông tin rồi trả về
• tạo một bản nháp nhanh

Nhưng khi công việc kéo dài qua nhiều bước, nhiều lần thử, hoặc cần người kiểm tra ở giữa, mô hình này bắt đầu lộ điểm yếu. Context dễ mất, trạng thái dễ mơ hồ, và rất khó biết lần trước agent đã kẹt ở đâu.

Kanban giải quyết một bài toán khác: giữ cho công việc còn tồn tại như một thực thể có thể quan sát, chuyển trạng thái, retry, giao tiếp giữa vai trò, và tiếp tục sau khi bị block.

Điểm hay: trạng thái không còn nằm trong “trí nhớ tạm” của agent

Theo chia sẻ từ cộng đồng Hermes, Kanban mới có các trạng thái như:

• triage
• todo
• ready
• running
• blocked
• done
• archived

Nghe đơn giản, nhưng với agent workflow thì đây là phần rất quan trọng. Một task ở trạng thái blocked khác hoàn toàn với một task “agent có vẻ chưa làm xong”. Một task ready khác với một ý tưởng đang nằm đâu đó trong chat log.

Khi trạng thái được lưu bền vững, mình có thể vận hành theo kiểu gần với production hơn:

• biết task nào đang chờ điều kiện trước khi chạy
• biết task nào đã từng thử và thất bại
• biết vì sao task bị block
• biết task nào cần người duyệt
• biết việc nào đã hoàn tất và có thể archive

Điểm này biến agent từ một phiên chat thông minh thành một hệ thống làm việc có dấu vết.

Phụ thuộc giữa task là mảnh ghép lớn

Một chi tiết đáng chú ý là child task có thể chờ parent task hoàn tất. Đây là thứ làm Kanban hữu ích hơn một board ghi chú thông thường.

Ví dụ một pipeline nghiên cứu có thể tách thành:

1. thu thập nguồn
2. lọc nguồn đáng tin
3. viết bản nháp
4. kiểm tra claim
5. biên tập giọng văn
6. chờ người duyệt
7. xuất bản

Nếu bước 3 chỉ được chạy sau khi bước 1 và 2 xong, agent không còn phải “tự nhớ” thứ tự bằng prompt dài. Trạng thái nằm trong hệ thống. Điều này giảm lỗi vận hành rất nhiều, nhất là khi task kéo dài qua nhiều phiên hoặc nhiều agent profile.

Dashboard, CLI và worker cùng nhìn vào một board

Một điểm thực dụng khác: dashboard, CLI và worker tools dùng chung một trạng thái board. Nói cách khác, đây không phải ba giao diện rời rạc với ba cách hiểu khác nhau về task.

Với đội vận hành, điều này quan trọng vì mỗi người có thể tương tác theo cách phù hợp:

• người quản lý nhìn dashboard để nắm tiến độ
• người kỹ thuật dùng CLI để kiểm tra hoặc thao tác nhanh
• worker chạy task thật ở tầng OS process
• agent ghi lại summary, metadata và lịch sử attempt

Khi mọi thứ cùng trỏ về một nguồn sự thật, handoff bớt phụ thuộc vào việc đọc lại cả đống hội thoại trước đó.

Nhưng đừng hiểu nhầm: đây chưa phải orchestration phân tán

Caveat quan trọng là Kanban hiện được mô tả theo hướng single-host. Board local SQLite, worker là OS process thật. Đây là thiết kế thực tế, không cố giả vờ là một hệ thống orchestration đa máy.

Theo mình, đây lại là điểm tốt ở giai đoạn hiện tại. Agent tooling thường dễ bị thổi phồng thành “hệ điều hành tự động hóa toàn cầu”, trong khi thứ người dùng cần trước tiên là:

• chạy ổn trên máy local
• dễ hiểu trạng thái
• dễ inspect khi lỗi
• có chỗ cho người dừng, sửa, duyệt
• không mất context sau mỗi lần retry

Nếu Kanban làm tốt phần này, nó đã giải quyết một nỗi đau rất thật.

Anh em có thể dùng Kanban cho gì trước

Một số use case hợp lý để thử:

Research pipeline

Tách quá trình research thành nhiều task nhỏ: tìm nguồn, đọc nguồn, tổng hợp, kiểm chứng, viết bài. Task nào thiếu nguồn thì block rõ ràng thay vì tạo ra bản nháp yếu.

Coding workflow

Dùng board để theo dõi bug, refactor, review, test, và chờ approval. Mỗi attempt có lịch sử riêng giúp debug tốt hơn khi agent sửa sai.

Vận hành nội bộ

Các việc kiểu tổng hợp báo cáo, kiểm tra inbox, chuẩn bị nội dung, cập nhật dữ liệu có thể chuyển qua board để tránh bị trôi trong chat.

Review loop có con người

Những bước cần người duyệt nên được đưa vào trạng thái riêng thay vì để agent đoán. Đây là điểm rất hợp với doanh nghiệp nhỏ đang thử agent nhưng vẫn muốn kiểm soát chất lượng.

Checklist khi thử Kanban trong Hermes

Nếu anh em định dùng tính năng này nghiêm túc, mình sẽ bắt đầu bằng checklist nhỏ:

• Chỉ đưa vào Kanban các việc cần theo dõi qua nhiều bước, đừng biến mọi tác vụ nhỏ thành board noise.
• Đặt tiêu chí rõ cho từng trạng thái, đặc biệt là blocked, ready, và done.
• Luôn yêu cầu agent ghi summary sau mỗi attempt.
• Với task có rủi ro, thêm bước human review thay vì cho chạy thẳng.
• Đừng thiết kế workflow như hệ thống phân tán nếu nó đang chạy single-host.
• Sau vài ngày, xem lại task nào hay bị block để sửa quy trình, không chỉ sửa prompt.

Kết luận

Kanban trong Hermes đáng chú ý vì nó kéo agent workflow về gần với cách vận hành thật: có hàng đợi, có trạng thái, có lịch sử, có phụ thuộc, có điểm dừng cho con người.

Nó không làm agent “ma thuật” hơn theo nghĩa hào nhoáng. Nhưng nó làm agent dễ quản lý hơn, dễ tin hơn, và phù hợp hơn với công việc kéo dài. Với mình, đó mới là hướng phát triển đáng giá cho agent trong thực tế.