Quản lý công việc cho agent AI: vòng nhận việc là một hợp đồng, không phải một câu lệnh

Quản lý công việc cho agent AI hiệu quả khi chính cái bảng, chứ không phải câu lệnh, nắm vòng lặp: agent hỏi nên làm gì, nhận một công việc với lease sẽ hết hạn nếu nó im lặng, chỉ hỏi người dùng những quyết định thuộc về họ, và kết thúc bằng một biên nhận mà người khác kiểm tra được. Trong Weft, mỗi bước đó là một công cụ MCP được máy chủ kiểm tra, nên một agent bỏ qua một bước sẽ bị từ chối hoặc mất công việc, thay vì âm thầm lệch khỏi thực tế.

Chúng tôi là người làm ra Weft. Thông tin về sản phẩm khác lấy từ trang chính thức của họ, kiểm tra ngày 27/10/2026.

Vì sao danh sách công việc dán vào chat lại ngừng hiệu quả?

Dán công việc vào một cuộc chat là điều ai cũng thử đầu tiên, và nó hiệu quả được một buổi chiều. Rồi cuộc chat kết thúc, và trạng thái cũng kết thúc theo. Agent từng biết mục nào nó đã xong, mục nào nó bỏ dở và điều gì nó còn chưa chắc. Giờ thì không ai biết nữa.

Người đã dán danh sách trở thành trạm trung chuyển, chép kết quả ngược về bảng thật và làm lại những việc mà một phiên thứ hai đã nhặt lên vì không có gì cho biết việc đó đã có người nhận.

Cho agent truy cập bảng giải quyết được vấn đề ảnh chụp trạng thái, nhưng không giải quyết phần còn lại. Nếu công cụ duy nhất là “di chuyển thẻ” và “thêm bình luận”, vòng lặp vẫn phụ thuộc vào việc agent làm theo một quy ước viết trong chỉ dẫn của nó. Quy ước vỡ đúng lúc mọi thứ trục trặc: agent sập giữa chừng, hoặc hai agent bắt đầu cùng một lúc.

Vòng nhận việc trông thế nào khi là một hợp đồng?

Trong Weft, vòng lặp có năm bước, và mỗi bước là một công cụ riêng trên cùng một endpoint MCP, https://letsweft.com/api/mcp. Máy chủ giữ trạng thái giữa các bước, nên vòng lặp sống sót qua việc bất kỳ cuộc chat nào kết thúc.

1. get_my_work: hỏi trước khi chọn. Câu trả lời gồm những gì ứng dụng này đang giữ, những gì đang chờ người dùng, những gì quá hạn hoặc sắp đến hạn, và còn chỗ để bắt đầu việc gì không.
2. start_task: nhận việc kèm lease. Quyền nhận việc kéo dài 20 phút và chuyển công việc sang Doing. Phản hồi mang theo runId, leaseToken và renewEverySeconds: 300. Một ứng dụng thứ hai thử nhận cùng công việc sẽ nhận already_claimed kèm gợi ý đừng làm trùng.
3. report_progress: tín hiệu nhịp. Mỗi lượt gọi kèm run id và lease token gia hạn lease. Nếu agent chết, tín hiệu nhịp dừng, và 20 phút sau lượt chạy bị đánh dấu là cũ và công việc trở về trạng thái chưa giao để ai cũng nhận được. Một lease đã mất trả về lease_lost, để agent biết nó không còn sở hữu công việc.
4. request_input: chỉ cho những quyết định thuộc về người dùng. Một câu hỏi tối đa 500 ký tự, kèm tối đa 10 phương án. Quyền nhận việc được giữ trong lúc agent chờ.
5. complete_task: kết thúc bằng biên nhận. outcome, artifacts (bằng chứng như URL, commit hoặc mã băm file), notDone, unknowns và nextStep.

Vì sao là lease mà không phải một trạng thái? Vì im lặng là tín hiệu duy nhất mà một agent đã sập có thể gửi. Một thẻ trong Doing nói rằng ai đó từng làm nó. Một lease nói rằng ai đó đang làm nó ngay bây giờ, và tự ngừng nói như vậy khi điều đó không còn đúng.

Bản thân việc nhận việc là một lệnh insert duy nhất vào cơ sở dữ liệu, được bảo vệ bằng một unique index. Khi hai agent tranh nhau, cơ sở dữ liệu quyết định ai thắng, nên cả hai không thể cùng có công việc. Ngược lại, hai bình luận “Đã nhận” đăng cách nhau một giây thì đều là bình luận hợp lệ.

Khi nào agent nên gọi request_input?

Khi nó gặp thứ chỉ người dùng quyết định được: bất cứ điều gì không đảo ngược được như tiền, xuất bản, production hay pháp lý, hoặc một ngã rẽ thật không có mặc định hợp lý. Không phải để xin phép làm tiếp.

Sự kiềm chế đó quan trọng vì một câu hỏi tốn của người dùng sự chú ý bằng một công việc đã xong, và trong Weft nó tính vào cùng một giới hạn. Câu hỏi rơi vào Hộp thư, kèm thông báo đẩy trên điện thoại và, với mục chờ từ 20 phút trở lên, một email nhắc. Weft không bao giờ gọi ngược agent: câu trả lời tới vào lần start_task hoặc get_my_work tiếp theo của nó. Trong lúc câu hỏi còn mở, agent giữ công việc trong 60 phút; sau đó lease hết nhưng câu hỏi vẫn còn.

Một lượt gọi complete_task gồm những gì?

Một kết quả ngắn, bằng chứng, và một lời kể trung thực về các phần rìa. Đây là một payload thực tế cho việc sửa lỗi:

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

Artifacts là những thứ người dùng kiểm tra được mà không phải tin lời agent. notDone và unknowns không phải lời thú tội; chúng phân biệt một kết quả bạn tin cậy được với một kết quả bạn phải dựng lại từ diff. Lượt gọi này không bao giờ thất bại vì thiếu bằng chứng, vì mất công việc đã xong còn tệ hơn ghi nhận nó khi chưa kiểm chứng. Đọc thêm về cách xem các biên nhận này trong bài agent AI của tôi đã làm gì.

Điều này khác gì so với di chuyển thẻ và đăng bình luận?

Hướng dẫn của Hypertask về cùng vòng lặp này (nhận, cập nhật, báo cáo, đóng) mô tả thói quen đó rất tốt. Phiên bản MCP của việc nhận việc ở đó là tải công việc, chuyển nó sang mục đang làm và đăng một bình luận nhận việc, theo một câu lệnh mà đội viết vào chỉ dẫn của agent. Đây là cùng vòng lặp, từng bước một:

Công bằng với Hypertask: họ có lease thật. Tài liệu của họ liệt kê các endpoint nhận lease, tín hiệu nhịp và giải phóng, và bảng Known limitations nói lease công việc, bằng chứng và chuyển cấp chỉ là endpoint REST, có chủ đích (tổng quan MCP của Hypertask). Tham chiếu công cụ của họ không có công cụ lease nào trong 21 công cụ MCP (tham chiếu công cụ). CLI của họ cũng nhận việc được, như một lệnh tùy chọn (nhật ký thay đổi, tham chiếu CLI). Vậy một agent chạy script trên Hypertask có thể giữ lease; còn một agent làm việc qua MCP trong Claude Code hay Cursor chỉ có phiên bản thẻ-và-bình-luận, trừ khi ai đó nối thêm các lượt gọi REST.

Nếu agent của bạn chạy dưới dạng script và job CI, CLI và REST API của Hypertask là một lợi thế thật, và Weft không có cả hai: không CLI, không REST API công khai, không webhook. Weft dành cho agent sống bên trong một ứng dụng MCP và cần vòng lặp đứng vững ở đó.

Người dùng nhìn thấy gì?

Phần lớn thời gian là một thẻ trong Done: mặc định công việc đã hoàn thành đi thẳng vào đó, kèm kết quả và bằng chứng.

Một công việc dừng lại trong Hộp thư của người dùng khi nó được đánh dấu là cần xem xét, hoặc khi một bước kiểm chứng thất bại. Ở đó người dùng chọn một trong bốn câu trả lời:

• Chấp nhận: kết quả được giữ nguyên. Nếu agent đã truyền nextStep, người dùng thấy nó ở trên nút (“Nếu bạn chấp nhận, agent sẽ …”), và chấp nhận chỉ phê duyệt đúng bước đó, không gì rộng hơn. Sự phê duyệt có hiệu lực 72 giờ và quay về agent qua get_my_work hoặc start_task.
• Làm lại: trả lại, kèm ghi chú nói rõ sai ở đâu.
• Để sau: không phải bây giờ. Bỏ: ngừng làm việc này.

Hộp thư có trên web, và khi có gì đó vào Hộp thư, người dùng cũng nhận thông báo đẩy trên ứng dụng di động Weft. Cơ chế bắt tay qua nextStep ngăn agent coi “trông ổn đấy” là sự cho phép để merge, deploy và gửi đi: nó chỉ được làm đúng một bước đã duyệt, rồi hoàn thành công việc lần nữa.

Vì sao agent bị từ chối thay vì bắt đầu thêm việc?

Vì sự chú ý, chứ không phải công việc, mới là nguồn lực khan hiếm. Một agent có thể bắt đầu mười việc trong thời gian một người xem xét xong một việc.

Weft đếm những gì đang chờ con người: công việc chờ xem xét cộng câu hỏi đang mở. Khi con số đó chạm 5 mục trong không gian làm việc một người, 10 trong đội, hoặc khoảng 45 phút xem xét ước tính, tùy cái nào tới trước, start_task từ chối với attention_queue_full. Giới hạn phụ thuộc vào số người trong không gian làm việc, không phụ thuộc vào gói.

Lời từ chối là một chỉ dẫn, không phải ngõ cụt. Nó cho biết kích thước hàng chờ, tuổi của mục cũ nhất và các lượt gọi vẫn được phép: report_progress, get_my_work, get_board_state và search. Một bước mà người dùng đã phê duyệt trên thẻ đó được miễn, nên một “merge PR #418” đã được chấp nhận không bị hàng chờ chặn lại.

Thiết lập thế nào?

Kết nối ứng dụng của bạn và đăng nhập qua trình duyệt; không có key nào phải sao chép. Weft cấp refresh token, nên ứng dụng tự gia hạn đăng nhập. Trong Claude Code đó là một lệnh, claude mcp add --transport http weft https://letsweft.com/api/mcp (trang thiết lập). Cursor có cài đặt một cú nhấp (Cursor), Codex cần một mục cấu hình và codex mcp login weft (Codex), còn ChatGPT có ứng dụng Weft đã phát hành trên mọi gói kể cả Free (ChatGPT). Máy chủ tự mô tả vòng lặp cho agent, nên không cần câu lệnh nào về vòng đời công việc.

Để xem hướng dẫn từng bước cho Claude Code, đọc bài bảng công việc cho Claude Code. Với nhiều agent trên một bảng, nơi lease và already_claimed quan trọng nhất, xem bài nhiều agent AI, một bảng. Bản thân giao thức được ghi tài liệu tại modelcontextprotocol.io, và các bảng MCP khác được so sánh ở trang trình quản lý công việc MCP.

Weft không làm gì ở đây?

• Không CLI, REST API công khai hay webhook, nên cron job và pipeline CI không thể điều khiển vòng lặp bên ngoài một ứng dụng MCP.
• Không tích hợp GitHub hay Slack. Bằng chứng là bất cứ gì agent đính kèm trong artifacts.
• Không có AI tích hợp. Phần suy nghĩ diễn ra trong ứng dụng AI của chính bạn, và đó cũng là lý do Weft không cần tín dụng AI.

Free gồm 50 công việc và 200 lượt gọi AI mỗi tháng. Pro có giá $7 mỗi chỗ mỗi tháng hoặc $60 mỗi chỗ mỗi năm (bảng giá).

Một câu lệnh tốt chẳng phải đủ để agent theo đúng vòng lặp sao?

Câu lệnh mô tả vòng lặp; nó không thực thi được vòng lặp. Nó không ngăn hai agent nhận cùng một công việc, và không giải phóng được công việc đang bị giữ bởi một agent đã sập. Trong Weft, quyền nhận việc là một lease do máy chủ sở hữu, nên những trường hợp đó được xử lý dù agent có nhớ chỉ dẫn của nó hay không.

Chuyện gì xảy ra nếu agent của tôi sập giữa chừng?

Tín hiệu nhịp của nó dừng. Hai mươi phút sau lần report_progress cuối, lượt chạy bị đánh dấu là cũ, lease token bị xóa và công việc lại chưa được giao, nên một agent khác hoặc một người có thể nhận nó. Thẻ không nằm trong Doing cả tuần.

Mọi công việc đã xong đều chờ tôi xem xét sao?

Không. Mặc định công việc đã hoàn thành đi thẳng vào Done kèm kết quả và bằng chứng. Nó chỉ dừng lại trong Hộp thư để chọn Chấp nhận, Làm lại, Để sau hoặc Bỏ khi công việc cần xem xét hoặc một bước kiểm chứng thất bại.

Vì sao tôi lại muốn agent của mình bị từ chối việc?

Vì nếu không, nó cứ tiếp tục tạo ra những thứ bạn không có thời gian kiểm tra. Khi có 5 mục (10 với đội) hoặc khoảng 45 phút xem xét đang chờ con người, start_task trả về attention_queue_full và chỉ cho agent những gì nó vẫn làm được. Dọn hàng chờ sẽ mở khóa cho nó.

Hypertask cũng có lease. Vậy vì sao MCP lại quan trọng?

Lease của Hypertask là endpoint REST, theo chính tài liệu của họ (tổng quan MCP), và CLI của họ cũng nhận việc được. Điều đó hợp với agent chạy script. Một agent làm việc qua công cụ MCP trong trình soạn thảo hay chat thì không có chúng ở đó, còn trong Weft thì có: start_task, report_progress và complete_task là công cụ MCP.