Agent AI của tôi đã làm gì? Bốn câu hỏi cần trả lời bằng bằng chứng

Để biết agent AI của bạn đã làm gì, đừng bắt đầu từ bản tóm tắt của nó. Hãy kiểm tra bốn điều: kết nối nào đã làm việc đó, cái gì đã thay đổi (thể hiện bằng thứ bạn tự mở ra được), cái gì còn bỏ dở, và điều gì đã được quyết định cùng lý do. Nếu bất kỳ điều nào trong bốn điều đó chỉ dựa vào lời của agent, thứ bạn có là một lời kể, không phải một hồ sơ.

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 một bình luận “xong rồi” là chưa đủ?

Một bình luận là agent tự mô tả công việc của mình. Nó có thể rất chính xác, nhưng bình luận không chứng minh được điều đó, vì tác giả chính là bên bạn đang cần kiểm tra. Biết rằng một agent đã đụng vào công việc trả lời được câu hỏi ai. Nó không trả lời được công việc có đúng như bạn nghĩ hay không.

Bài viết của Hypertask về ghi nhận công việc AI nêu một ý đúng: công việc của agent nên nằm trên cùng bảng với công việc của con người, chứ không nằm trong một nhật ký terminal không ai đọc. Hypertask cũng cho agent danh tính riêng dưới dạng tài khoản dịch vụ, để thao tác ghi được ghi nhận cho agent chứ không cho bạn, và họ có bằng chứng công việc cùng lease, dù tài liệu của họ nói đó chỉ là endpoint REST, không phải công cụ MCP, có chủ đích. Chỗ chúng tôi khác là hồ sơ nên chứa gì. Một chuỗi bình luận với đầu ra của agent là nhật ký những gì agent đã nói. Chúng tôi muốn hồ sơ chứa bằng chứng.

Hướng dẫn này không có số liệu khảo sát nào. Bạn có thể thử bốn câu hỏi trên chính bảng của mình ngay chiều nay, và điều đó cho bạn biết nhiều hơn bất kỳ con số trung bình ngành nào.

Bốn câu hỏi đó là gì?

Chọn bất kỳ công việc nào agent đã làm xong tuần trước. Bạn phải trả lời được từng câu dưới đây trong chưa tới một phút mà không hỏi agent hay mở cuộc chat của nó:

1. Ai đã làm? Ứng dụng nào, trên kết nối nào, đã nhận và hoàn thành công việc.
2. Cái gì đã thay đổi? Kết quả, cùng artifacts bạn kiểm tra được mà không cần tin agent: một mã băm commit, một URL, một file, một id tin nhắn.
3. Cái gì chưa làm? Những phần nó bỏ qua, và những điều nó chưa chắc chắn.
4. Điều gì đã được quyết định, và vì sao? Mọi lựa chọn được đưa ra dọc đường, với các phương án đã cân nhắc, và mọi lần bạn trả công việc lại.

Làm sao biết agent nào đã làm?

Weft kết nối với các ứng dụng AI qua Model Context Protocol tại một endpoint, https://letsweft.com/api/mcp. Mỗi ứng dụng OAuth và mỗi token truy cập cá nhân là một tác nhân riêng. Một công việc ghi lại ứng dụng nào đã tạo ra nó, và bảng hiển thị tên ứng dụng đó đã đăng ký khi đăng nhập, kèm một biểu tượng. Mỗi sự kiện trong nhật ký của công việc lưu việc nó đến từ một người hay qua MCP, và ứng dụng nào đã gửi.

Nhật ký đầy đủ (get_task_history ở chế độ full) hiển thị id thô của ứng dụng cho từng sự kiện: một OAuth client id, hoặc mcp-token theo sau là id của token. Đó không phải tên thân thiện, nhưng nó chính xác, và nó phân biệt hai kết nối ngay cả khi chúng đến từ cùng một sản phẩm.

Quyền sở hữu trong lúc làm việc cũng rõ ràng. Agent gọi start_task, lệnh này nhận công việc với lease 20 phút và chuyển nó sang Doing. report_progress gia hạn lease. Agent thứ hai thử nhận cùng công việc sẽ nhận already_claimed, và một lease hết hạn sẽ trả công việc lại cho người khác. Hướng dẫn về vòng nhận việc đi qua từng bước, còn chạy nhiều agent trên một bảng bàn về trường hợp nhiều ứng dụng.

Một quy tắc thực tế: cho mỗi công cụ một kết nối riêng. Nếu hai ứng dụng dùng chung một token truy cập, bảng chỉ thấy một tác nhân, và câu hỏi “ai” mất câu trả lời.

Cái gì đã thay đổi, và tôi có kiểm tra được mà không hỏi agent không?

Khi agent làm xong, nó gọi complete_task. Chỉ id công việc là bắt buộc; mọi thứ khác đều tùy chọn, và lượt gọi không bao giờ thất bại vì thiếu bằng chứng. Điều đó có chủ đích: mất công việc đã xong còn tệ hơn ghi nhận nó khi chưa kiểm chứng. Một biên nhận có thể mang:

• outcome: tối đa 1.000 ký tự về những gì đã làm và kết quả nằm ở đâu.
• artifacts: tối đa 20 mục, mỗi mục có một loại (url, file, message, commit, v.v.), một vị trí, và tùy chọn một chuỗi băm sha256.
• claims: những gì agent khẳng định đã làm, được lưu dưới dạng lời khẳng định chứ không phải sự thật đã kiểm chứng.
• notDone và unknowns: được bàn ở phần tiếp theo.
• nextStep: việc agent sẽ làm tiếp nếu bạn chấp nhận.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

Dòng outcome vẫn là lời kể. Artifacts mới là phần bạn kiểm tra được. Một mã băm commit hoặc có trong repository của bạn, hoặc không. Một URL hoặc tải được, hoặc không. sha256 của một file hoặc khớp, hoặc không. Nếu biên nhận có outcome mà không có artifacts, hãy coi đó là công việc do agent tự báo cáo, vì nó đúng là như vậy. Trên web, thẻ trong Done cho thấy công việc là Đã xác minh hay Theo agent.

Agent đã không làm gì?

Đây là câu hỏi mà phần lớn hồ sơ bỏ qua, và là câu hỏi gây hại hai tuần sau. complete_task có hai danh sách cho nó, mỗi danh sách tối đa 20 mục 500 ký tự: notDone cho những gì agent cố ý bỏ ra, và unknowns cho những gì nó chưa chắc. Chính mô tả của công cụ yêu cầu agent nói rõ những gì chúng không làm. Đó là điều 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 tự suy lại.

Hãy đọc những danh sách này trước. “Chưa chạy test với cơ sở dữ liệu staging” thay đổi việc bạn làm tiếp theo. Một biên nhận không có mục notDone nào trên một công việc lớn tự nó đã đáng để hỏi.

Điều gì đã được quyết định, và vì sao?

Quyết định đưa ra trong chat biến mất khi cuộc chat trôi đi. record_decision giữ chúng theo hai cách:

• Một hồ sơ quyết định độc lập: tiêu đề, kết quả, bối cảnh, các phương án thực sự đã cân nhắc, hệ quả, và điều kiện để xem xét lại. Hồ sơ là bất biến; muốn thay đổi thì ghi một quyết định mới thay thế nó, và quyết định cũ vẫn ở lại, được đánh dấu là đã bị thay thế.
• Chuyển tiếp phán quyết: khi bạn nói với agent trong cuộc trò chuyện “chấp nhận”, “làm lại với X”, “bỏ đi” hay “chưa phải lúc”, nó ghi phán quyết đó lên công việc, kèm ghi chú của bạn.

get_task_history đọc lại theo ba chế độ: summary (thẻ, biên nhận mới nhất và các con số), decisions (mọi quyết định về công việc, kể cả lý do nó bị trả lại, vẫn còn ngay cả sau khi được chấp nhận về sau) và full (nhật ký thô, tối đa 100 sự kiện). get_context trao các quyết định còn hiệu lực cho agent tiếp theo trong một ngân sách token, để lượt chạy tiếp theo bắt đầu từ những gì đã được quyết định thay vì từ con số không. Đọc thêm trong bài vì sao quyết định trong chat AI bị thất lạc.

Tôi xem xét ở đâu, và bấm vào gì?

Mặc định, công việc đã hoàn thành đi thẳng vào Done. Nó dừng lại trong Hộp thư của bạn khi công việc cần xem xét hoặc khi một bước kiểm chứng thất bại. Ở đó bạn thấy biên nhận và bốn nút: Chấp nhận, Làm lại, Để sau và Bỏ. Làm lại yêu cầu một ghi chú, và ghi chú đó được gửi lại cho agent.

Nếu agent đã truyền nextStep, nó hiện ở trên nút Chấp nhận, và chấp nhận là phê duyệt đúng bước đó. Sự phê duyệt có hiệu lực 72 giờ và quay về agent qua get_my_work hoặc start_task như bước duy nhất cần làm tiếp. Câu hỏi agent đặt bằng request_input rơi vào cùng Hộp thư, trên web và trong ứng dụng iOS và Android, kèm thông báo đẩy.

Hộp thư có giới hạn một cách có chủ đích: 5 mục đang chờ với không gian làm việc một người, 10 với đội, hoặc 45 phút xem xét ước tính, tùy cái nào tới trước. Khi đầy, start_task từ chối với attention_queue_full, nên agent hoàn thành hoặc làm rõ công việc thay vì chất thêm việc cho bạn kiểm tra.

Nên yêu cầu bằng chứng gì cho từng loại công việc?

Viết những điều này vào mô tả công việc để agent biết bạn chờ đợi bằng chứng gì:

• Code: mã băm commit và URL của PR làm artifacts. notDone nên nêu tên các test chưa chạy, migration chưa áp dụng và file cố ý để nguyên.
• Nội dung: URL đã xuất bản, hoặc file bản nháp kèm sha256 nếu chưa lên sóng. unknowns nên liệt kê những thông tin agent chưa xác nhận được.
• Nghiên cứu: một URL nguồn cho mỗi khẳng định quan trọng, và file ghi chú. unknowns nên tách điều nguồn nói khỏi điều agent tự suy ra.
• Tiếp cận khách hàng: id của từng tin nhắn đã gửi, và danh sách người nhận dạng file. notDone nên liệt kê ai chưa được liên hệ và vì sao.

Làm sao kiểm soát agent được làm gì ngay từ đầu?

Ghi nhận sau sự việc hiệu quả nhất khi có giới hạn từ trước. Trong Weft, mỗi kết nối OAuth có một trong ba mức quyền, đặt trên màn hình xin quyền hoặc sau đó trong Cài đặt, Client AI đã kết nối:

• full (mặc định): cả 32 công cụ.
• write: mọi thứ trừ ba công cụ phá hủy (trash_task, archive_done_tasks, complete_sprint).
• read: chỉ 11 công cụ chỉ đọc.

Phép kiểm tra chạy ở mọi lượt gọi. Ngắt kết nối sẽ thu hồi refresh token của kết nối đó và từ chối mọi token được cấp trước thời điểm cắt ngay ở lượt gọi tiếp theo. Token truy cập cá nhân, dành cho ứng dụng không có OAuth, không có phạm vi: một token chạm tới cả 32 công cụ, và thu hồi nó có hiệu lực ở lượt gọi tiếp theo. Agent có thể chuyển công việc vào thùng rác 30 ngày nhưng không xóa vĩnh viễn được; khôi phục từ thùng rác là tính năng của gói Pro.

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

• Weft không tích hợp GitHub hay Slack, nên nó không tra cứu commit hay tin nhắn giúp bạn. Bạn tự mở artifact.
• Weft không có REST API công khai, webhook hay CLI để đẩy biên nhận sang hệ thống khác. Có xuất JSON và Markdown.
• Weft không truy vết các bước của mô hình. Những công cụ ghi lại prompt, token và độ trễ ở tầng mô hình làm một việc khác, và có thể bạn cũng muốn dùng một công cụ như vậy.
• Agent tự viết biên nhận của mình. Weft làm lộ rõ khoảng cách giữa lời khẳng định và bằng chứng; nó không thể khiến một agent trung thực.

Nếu bạn muốn agent được quản lý như tài khoản dịch vụ qua REST API, một CLI cho script CI, hoặc tính năng AI tích hợp như viết công việc và phân loại, Hypertask hợp hơn. Trang lựa chọn thay thế Hypertask của chúng tôi so sánh hai bên cạnh nhau.

Lịch sử git chẳng phải đủ để biết agent đã làm gì sao?

Git cho thấy cái gì đã thay đổi trong code. Nó không cho thấy agent đã bỏ qua gì, chưa chắc điều gì, hay đã chọn phương án nào giữa hai lựa chọn. Hãy dùng mã băm commit làm artifact trên công việc, và giữ phần còn lại trong biên nhận và hồ sơ quyết định.

Agent chẳng phải có thể bịa ra một artifact sao?

Nó có thể gửi bất kỳ chuỗi nào. Ý nghĩa của artifact là bạn mở được nó: một mã băm bạn tra được, một URL bạn tải được, một id tin nhắn bạn tìm được. Một artifact bịa đặt sẽ lộ ngay lúc bạn kiểm tra, điều mà một bình luận không bao giờ làm được. Khi công việc có bước kiểm chứng và một bước kiểm tra bắt buộc thất bại, công việc không được vào Done.

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 vào Done. Nó chỉ chờ 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.

Những ứng dụng AI nào ghi được biên nhận vào Weft?

Mọi ứng dụng MCP. ChatGPT có Weft dưới dạng plugin đã phát hành trên mọi gói, kể cả Free. Claude Code kết nối bằng claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai và Claude Desktop dùng connector tùy chỉnh. Có trang thiết lập cho 33 ứng dụng, như Claude Code, ChatGPT, Cursor và Codex.

Chi phí bao nhiêu?

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. Weft không có tín dụng AI: phần suy nghĩ diễn ra trong ứng dụng AI của chính bạn. Xem bảng giá.