ChatGPT đã có thể theo dõi bảng dự án: Bước tiến tiếp theo cho các agent hướng sự kiện

Bản tổng kết DevDay của OpenAI vào ngày 29 tháng 9 đã đưa ra một ví dụ rất dễ hiểu: “bạn có thể yêu cầu ChatGPT theo dõi các tác vụ mới trên bảng dự án. Khi có tác vụ mới xuất hiện, ChatGPT có thể đọc các tài liệu đính kèm và lập kế hoạch sơ bộ, ngay cả khi bạn không có mặt ở đó.” Ẩn sau khả năng này là việc ChatGPT hỗ trợ đặc tả MCP Events mới được đề xuất trên tất cả các gói dịch vụ, cùng với hai tính năng dành cho đội ngũ: tác vụ nhóm (team tasks) chạy theo lịch trình hoặc theo sự kiện, và @ChatGPT trong Slack cũng như Teams.

Đối với một đội ngũ vốn đã sử dụng các agent lập trình, một bảng công việc được agent theo dõi sẽ thay đổi hoàn toàn ý nghĩa của một tác vụ mới. Trước đây, tác vụ phải chờ con người xử lý. Giờ đây, nó có thể đánh thức một hoặc nhiều agent cùng lúc. Nếu hai người cùng yêu cầu ChatGPT theo dõi cùng một bảng, trong khi chính bảng đó cũng có một Agent được chỉ định để nhận việc mới, thì một tác vụ mới có thể tạo ra ba bản kế hoạch sơ bộ ở ba nơi khác nhau, mà không ai biết bản nào mới là bản chính thức.

Tóm tắt nhanh

MCP Events mang đến cho ChatGPT một phương thức rõ ràng, có chữ ký xác thực để nắm bắt các thay đổi từ ứng dụng được kết nối, còn tính năng tác vụ nhóm của ChatGPT giúp các gói Business và Enterprise có thể xử lý công việc theo lịch trình và theo sự kiện. Việc kích hoạt một agent từ sự kiện là phần việc dễ dàng, và OpenAI đã triển khai nó rất cẩn trọng. Phần khó khăn hơn nằm ở những gì sự kiện đó tạo ra trên bảng công việc: ai sẽ chịu trách nhiệm cho công việc phát sinh, bản kế hoạch sơ bộ sẽ được lưu ở đâu, quy trình duyệt ra sao, và làm thế nào để hai agent không cùng xử lý một sự kiện. Hãy cụ thể hóa điều đó thành một quy tắc định tuyến: một loại sự kiện chỉ có một người phụ trách, kế hoạch phải được đưa về đúng Task, và luôn cần có người phê duyệt trước khi công việc được coi là hoàn thành.

Những điểm mới được công bố tại DevDay

MCP Events là một phần mở rộng được đề xuất cho Model Context Protocol, cho phép máy chủ MCP thông báo cho ChatGPT khi có sự kiện xảy ra trong một ứng dụng được kết nối, nhờ đó plugin có thể kích hoạt quy trình tự động hóa tương ứng. Tài liệu hướng dẫn về MCP Events của OpenAI mô tả chi tiết phần triển khai phía máy chủ. Máy chủ sẽ khai báo khả năng hỗ trợ sự kiện và thực thi ba phương thức: events/list, events/subscribe và events/unsubscribe. ChatGPT hiện chỉ hỗ trợ gửi dữ liệu qua webhook, có chữ ký bằng Standard Webhooks HMAC sau khi vượt qua thử thách xác thực HTTPS, với mỗi yêu cầu gửi một sự kiện có dung lượng tối đa 256 KiB. Khi sự kiện được gửi đến, như tài liệu mô tả, “ChatGPT sẽ nhận sự kiện trong phiên chat đã đăng ký và thực hiện theo hướng dẫn của người dùng về cách phản hồi.”

Các chi tiết kỹ thuật được thiết kế rất tỉ mỉ ở những khâu then chốt. Máy chủ phải gán cho mỗi sự kiện một ID duy nhất và giữ nguyên qua các lần thử lại (retry). Cơ chế đăng ký phải đảm bảo tính lũy đẳng (idempotent): định danh của lượt đăng ký được suy ra từ chủ thể (principal), URL callback, tên sự kiện và các đối số truyền vào, do đó việc đăng ký lại sẽ cập nhật gói đăng ký hiện có thay vì tạo thêm một gói mới. Máy chủ cũng phải chặn các địa chỉ callback cục bộ và riêng tư, đồng thời không được chuyển hướng HTTP (redirect).

Tổng hòa lại, những cập nhật này biến ChatGPT thành một nơi mà công việc có thể được khởi xướng từ bên ngoài cuộc trò chuyện. Đây là một bước tiến thực chất, và đối với nhiều tác vụ định kỳ, như vậy là quá đủ.

Bộ kích hoạt mới chỉ là phần dễ

Hãy thử áp dụng ví dụ trong bài tổng kết vào một đội ngũ thực tế. Một tác vụ mới xuất hiện trên bảng. ChatGPT đọc các tài liệu liên quan và phác thảo một kế hoạch. Bốn câu hỏi sẽ lập tức nảy sinh, và không câu nào trong số đó liên quan đến giao thức truyền tải.

Ai là người chịu trách nhiệm cho công việc được tạo ra? Một bản kế hoạch sơ bộ không đồng nghĩa với việc phân công công việc. Phải có người nhận trách nhiệm cho phần việc được mô tả, và ở hầu hết các nhóm, quyền sở hữu được ghi nhận ngay trên bảng: một cái tên gắn trên tác vụ cùng trạng thái công việc được cập nhật. Một bản phác thảo tốt tự thân nó không thể thay đổi hai yếu tố này.

Kế hoạch sẽ được lưu ở đâu? Sự kiện sẽ chuyển đến phiên chat đã đăng ký, và bản kế hoạch sẽ xuất hiện ở bất cứ nơi nào mà hướng dẫn của người đó chỉ định: một câu trả lời trong phiên chat, hoặc ghi ngược lại vào bảng công việc nếu plugin hỗ trợ tính năng ghi và hướng dẫn yêu cầu làm điều đó. Nhóm phải thống nhất rõ điều này, nếu không bảng công việc sẽ mãi ở trạng thái “mới” trong khi một kế hoạch rất tốt lại nằm chờ ở nơi chẳng ai đoái hoài.

Kế hoạch được đánh giá và phê duyệt ra sao? Kế hoạch chính là quyết định về phạm vi công việc. Cần có người khác ngoài tác giả đọc và duyệt trước khi bắt tay vào viết code, tại một vị trí mà người tiếp theo có thể dễ dàng tìm thấy.

Ai sẽ là người xử lý sự kiện? Tính lũy đẳng giúp một đăng ký không bị nhân bản chính nó. Nhưng nó không thể điều phối giữa hai người khác nhau, bởi danh tính chủ thể (principal) là một phần định danh của gói đăng ký, khiến đăng ký của mỗi người là hoàn toàn độc lập. Thêm vào đó, nếu bảng công việc có sẵn một Agent được phân công, cùng một tác vụ có thể bị lên kế hoạch nhiều lần. Việc khử trùng lặp ở tầng webhook không thể giải quyết bài toán phân định quyền sở hữu ở tầng quản lý công việc.

Đây là những bài toán về mặt quản trị. Chúng vốn đã tồn tại từ trước khi có agent — khi ba người có thể cùng nhận xử lý một ticket — và giờ đây chúng tái diễn với tốc độ nhanh hơn nhiều khi đối tượng tiếp nhận công việc là những cỗ máy không bao giờ ngủ. Về khía cạnh rà soát các tác vụ tự động chạy nền, bạn có thể tham khảo bài viết vận hành coding agent khi bạn vắng mặt.

Thiết lập quy tắc định tuyến trực tiếp trên bảng

Trên một bảng công việc nơi các agent đóng vai trò là Người thực hiện (Assignee), việc “theo dõi tác vụ mới” phần lớn đồng nghĩa với việc “phân công tác vụ”. Trong Sharkly, một Task được giao cho một Agent sẽ bắt đầu chạy khi nó rời khỏi danh mục Backlog và Máy tính (Computer) cùng Môi trường chạy (Runtime) của nó đã sẵn sàng. Vị trí Assignee thực thi chỉ chứa đúng một Agent hoặc Crew duy nhất, và Sharkly sẽ gộp các yêu cầu đang chờ xử lý để tránh tình trạng các bình luận dồn dập tạo ra nhiều lượt chạy trùng lặp cho cùng một Agent và Task. Quyền sở hữu ở đây là một trường dữ liệu rõ ràng, không phải là một quy ước ngầm định.

Đối với những sự kiện cần kích hoạt công việc mà không thông qua việc phân công, Sharkly Automations chính là giải pháp tương đương ở phía bảng công việc. Mỗi Automation là một quy tắc duy nhất: gồm câu lệnh hướng dẫn, một Agent hoặc Crew, một hoặc nhiều bộ kích hoạt (trigger), cùng lịch sử thực thi, đi kèm trạng thái Hoạt động (Active) hoặc Tạm dừng (Paused). Các bộ kích hoạt bao gồm: lịch biểu (cron kèm múi giờ), Task chuyển sang một trạng thái cụ thể, bình luận chứa cụm từ chỉ định, và webhook từ dịch vụ bên ngoài, bên cạnh nút Run now để kiểm thử. Mỗi lượt chạy sẽ bắt đầu trực tiếp và lưu lại lịch sử trên chính Automation đó, vì vậy phần hướng dẫn cần nêu rõ kết quả sẽ được ghi nhận ở đâu. Hiện tại, tính năng khớp trạng thái và bình luận được áp dụng trên toàn tổ chức, do đó tài liệu Automations khuyến nghị nên đưa vào hướng dẫn bước xác minh Task kích hoạt trước khi thực hiện hành động.

Dưới đây là bảng ánh xạ từ sự kiện sang tác vụ của một Space:

Và đây là quy tắc nền tảng phía sau, được văn bản hóa ở nơi toàn đội ngũ có thể cùng xem xét và phản biện:

Routing rule: new work in the ENG Space

1. One event type, one owner. Each event maps to exactly one
   Automation or one Agent Assignee. Personal watchers (a chat
   subscription, a dot) may read the board; they do not plan on it.
2. New requests enter Triage. A person accepts before any Agent runs.
3. Accepted work that needs a plan moves to "Needs plan", a status in
   the Backlog category. The "Draft plan" Automation runs the Planner
   Agent, which first checks the Task's Space and type and stops if
   the Task is not ours.
4. The plan returns to the Task as a comment. The Planner does not
   change status and does not assign anyone.
5. The Task's human assignee reads the plan, assigns the executing
   Agent, and moves the Task to Todo. That move starts the run.
6. Done means a person accepted the result. No Agent moves a Task
   into a Completed status.

Việc đặt “Needs plan” vào danh mục Backlog chính là chi tiết then chốt giúp bước 5 diễn ra an toàn: một Task được phân công khi còn ở Backlog sẽ ở trạng thái chờ, nhờ đó kế hoạch được rà soát kỹ trước khi quy trình chạy thực sự bắt đầu. Hãy nêu rõ trong hướng dẫn của Planner nơi bản kế hoạch sẽ được gửi tới, và nhớ kiểm tra bằng tính năng Run now trước khi hoàn toàn tin tưởng vào bộ kích hoạt. Khi một Agent cần xin ý kiến quyết định giữa chừng, Task sẽ hiển thị trạng thái chờ con người phản hồi và chuyển vào Inbox của người phụ trách — đây chính là lúc yếu tố “ngay cả khi bạn vắng mặt” cần có sự can thiệp trở lại của con người. Task là nơi yêu cầu từ nhóm chat biến thành công việc có thể theo dõi nguồn gốc, và nguyên lý tương tự cũng áp dụng khi giao một issue trên GitHub cho một agent.

Vị trí phù hợp cho trình theo dõi của ChatGPT

Hãy sử dụng đăng ký MCP Events khi một cá nhân muốn nhận thông báo và bản phác thảo đầu tiên ngay trong phiên chat riêng của họ: chẳng hạn như theo dõi một bảng công việc bạn không trực tiếp quản lý, bảng theo dõi của đối tác, hay bản tóm tắt công việc thứ Sáu cho chính bạn. Hãy dùng tính năng tác vụ nhóm khi công việc định kỳ là việc cập nhật tiến độ nhóm diễn ra trực tiếp trong ChatGPT và tổ chức của bạn đang sử dụng gói Business hoặc Enterprise, vì lúc này các thành viên có thể cùng nhau tinh chỉnh một bộ hướng dẫn chung thay vì mỗi người tự viết một kiểu. Và hãy sử dụng quy tắc định tuyến phía bảng công việc khi sự kiện đó tạo ra phần việc mà cả nhóm phải chịu trách nhiệm: một kế hoạch cần ai đó thực hiện, một bản sửa lỗi cần người xem xét, hay một Task bắt buộc phải xuất hiện trong số liệu báo cáo sáng thứ Hai.

Hiệu quả của các AI agent vận hành theo sự kiện hoàn toàn phụ thuộc vào quy tắc xác định xem agent nào sẽ phản hồi. Bản thân sự kiện chỉ là hạ tầng kết nối; việc định tuyến, phân định người phụ trách và quy trình xét duyệt mới là bài toán quản trị, và những yếu tố này phải thuộc về bảng công việc nơi mọi agent báo cáo về, bất kể bảng đó do nhà cung cấp nào phát triển. Để tìm hiểu cách quyết định xem agent nên nhận việc gì tiếp theo khi hàng đợi đã đầy, hãy xem bài viết về quản lý và phân loại backlog cho AI. Tính năng Dots — sản phẩm đầu tiên được giới thiệu trong bản tổng kết của OpenAI — cũng đặt ra vấn đề tương tự từ góc độ của agent.

Nếu bạn đã và đang vận hành nhiều agent, Sharkly sẽ mang đến cho bạn một không gian tập trung duy nhất để quản lý các tác vụ và kết quả công việc của chúng.

Tài liệu tham khảo thêm

• Sharkly Automations: bốn loại bộ kích hoạt, lịch sử thực thi và giới hạn của tự động hóa
• Từ nhóm chat đến các tác vụ lập trình có thể truy xuất nguồn gốc: biến tin nhắn trò chuyện thành công việc có người phụ trách
• Quản lý và phân loại backlog cho AI: cách quyết định nhiệm vụ tiếp theo cho các agent
• Giao issue trên GitHub cho AI agent: từ issue đến pull request sẵn sàng để review
• Vận hành coding agent khi bạn vắng mặt: các tiến trình chạy nền không giám sát và hàng đợi xét duyệt
• Tìm hiểu về OpenAI dots: các agent cá nhân luôn hoạt động, và những gì một đội ngũ vẫn cần trang bị xung quanh chúng