發送給房間中 agent 的每個任務都會變成一個請求，帶有一個公開 ID（例如 R20260906-07），以及七個狀態之一：pending、approved、running、done、failed、cancelled 或 expired。之所以需要這個 ID，是為了讓聊天串中的人、手機端的使用者，以及正在查看審批卡片的主人，都在討論同一件事。**繼續（resume）**意味著在中斷之後，以相同的 ID 延續同一個請求。
這是樸實無華的底層管線。它也是「agent 正在做某件事」與「agent 正在執行 R-07，那是 Sarah 提出的、你在 14:02 批准的、目前進度 60%」之間的差別。
ID
R + UTC 日期 + 每日計數器。短到可以用手機輕鬆輸入，又獨特到足以作為連結。它會出現在房間中、稽核日誌裡、聊天平台的討論串內以及審批卡片上。當使用 Feishu 或 Slack 連接器時，任務討論串會以它為標題。請參閱 Feishu 設計。
各個狀態
七個狀態及其流轉；琥珀色虛線路徑代表繼續執行。
主人的請求會跳過 pending；直接進入 approved。
取消、重試與繼續（resume）
**取消（Cancel）**會設定一個 flag，daemon 會在工具呼叫（tool calls）之間進行檢查。正在執行的請求會在下一個安全節點停止；排隊中的請求則會被移除。撤銷某人的權限或撤銷某台電腦，會取消所有為其排隊的項目。
**重試（Retry）**會建立一個帶有新 ID 的新請求，並引用舊請求。房間中會同時顯示兩者，以確保歷史紀錄的真實性。
**繼續（Resume）**則有所不同。當電腦在執行途中休眠或 daemon 重啟時，該請求仍會保留其 ID 和執行環境 session 參照。恢復時，daemon 會延續同一個 session，而不是從頭重放一次 prompt。時間線上會顯示一段間隔，而不是重複的項目。正因如此，即使筆電在下午 6 點闔上，也能成為讓他人倚賴執行 agent 的合理環境。
為什麼每個 agent 的佇列是循序執行的
每個 agent 一次只處理一個請求，依序進行。兩個人同時向同一個 agent 提出要求，會分別取得 R-07 和 R-08，而 R-08 會等待。同一台電腦上的不同 agent 則平行執行。每個 agent 循序執行能維持工作目錄的一致性：對同一個儲存庫進行兩次並行編輯，正是導致產出非預期狀態的根源。
審批 TTL
無人回應的審批將會過期（預設 24 小時後），請求會變成 expired，而不是在隔天大家都忘了上下文時才執行。請求者可以重試；主人則可在稽核日誌中看到過期紀錄。請參閱稽核日誌必須記錄的內容。
常見問題
我可以在新請求中引用舊請求嗎？ 可以。只要提及該 ID，agent 就會將該請求的結果納入上下文。引用訊息、輸出或請求，是後續追問時免於重新交代背景的方法。
如果我撤銷了請求者的權限，正在執行的請求會怎樣？ 它會執行完畢並保留在歷史紀錄中；來自該請求者所有排隊中的項目則會被取消。在執行中途強行停止，可能讓儲存庫陷入比執行完畢更糟的狀態。
ID 是全域唯一還是依每個房間劃分？
依每位主人、每天劃分。兩位主人都可以各自擁有一個 R20260906-01；在同一個房間內則絕無二義性。
繼續執行功能是否支援 Codex 和 Claude Code？ 兩種執行環境都提供 session 參照；daemon 會將其與請求一同儲存，並以此繼續執行。
為工作賦予名稱，大家才有名稱可以討論它。為你的 agent 提供一個房間]
發布於