繁體
作者提供的 Kiki 貓咪圖片之透明臉部衍生圖
返回展廳

Kiki

工作訊號與代理執行

讓提議化為負責人的執行。

協助團隊運作 AI 代理的 Paperclip 外掛與 Slack 收集器。

2026.04 — 2026.05

pinxlab AI R&D 自由接案 · 工作流程規劃與開發、調查停滯的執行並設計復原路徑

  • 外掛已實作 · Paperclip
  • MCP 伺服器已實作 · Slack 收集器

在指派與實際執行之間，設置觀測與復原的路徑。

工作訊號轉為簡介與代理指令，維護提議的核准與其執行的指派分開。已指派議題的活動停止時，帶著議題與負責人再次請求；重複無回應則交由上限、cooldown 與人的判斷處理。

它將工作訊號轉為代理指令，並把維護提議、人工核准、指派與停滯執行的復原，作為各自獨立的步驟串接起來。這個流程由我規劃與開發。

儲存庫首筆記錄 April 3, 2026 · pinxlab 參與至 May 26, 2026

在團隊的 Paperclip 內以外掛執行；由 MCP 伺服器負責 Slack 收集。

執行流程架構圖 · 依據非公開實作記錄
Kiki 訊號 · 核准 · 執行復原從可存取的 Slack 頻道記錄中萃取工作模式，製成公司簡介與各代理指令。維護分析代理檢視目標專案，將提議留作未指派的 backlog 議題；每項提議都會張貼到 Slack，由人以表情回應核准或拒絕。核准的議題指派給代理後，由外部執行系統完成工作，stage reaper 則監看近期活動。活動停止時，帶著議題與負責人再次請求指派；連續無回應達到上限時，停止重新呼叫，交給 Lead 或維運人員。Slack 訊號可存取的頻道記錄受指派代理外部執行目標專案不顯示內容人 · 核准、拒絕Slack 表情回應Lead · 維運人員重新指派 · 通知訊號收集模式萃取 · 排除 bot公司狀態公司簡介合併代理狀態各代理指令執行觀測近期執行 · 活動維護分析PO 呼叫 · 限定範圍的提示詞議題追蹤系統提議 · backlog執行議題 · todo提議張貼訊息 ↔ 議題對應Stage reaper停滯檢查 · heartbeat復原呼叫議題 + 負責人無回應狀態無回應次數 · 各議題上限停止重新呼叫 · cooldown訊號 → 指令外部執行提議 → 人工核准復原 · 升級處理1頻道記錄2簡介合併3重新產生4注入指令1目標範圍2提議議題3張貼提議4Slack 訊息5表情回應6核准 → todo7拒絕 → cancelled8指派1執行記錄2最後活動3無回應 +14新活動 → 重設5重新呼叫6議題 + 負責人73 次後8重新指派 · 通知9僅警告

訊號 → 指令

從 Slack 記錄建立簡介與代理指令。指令是代理的上下文，不畫成任何提議的原因。

  1. Slack 訊號頻道記錄模式萃取 · 排除 bot訊號收集

    收集可存取的頻道記錄，並濾除 bot、加入與離開訊息。本頁不顯示原始訊息。

  2. 模式萃取 · 排除 bot訊號收集簡介合併公司簡介合併公司狀態

    萃取的模式成為簡介 patch，合併到公司簡介中。這些是啟發式模式，不是員工績效分數。

  3. 公司簡介合併公司狀態重新產生各代理指令代理狀態

    以合併後的簡介重新產生各代理指令並儲存。

  4. 各代理指令代理狀態注入指令受指派代理

    代理建立時，指令進入其上下文。這不代表特定提議來自特定的 Slack 訊號。

提議 → 核准 → 指派

提議先以未指派的 backlog 議題存在，人的表情回應請求狀態變更，指派與執行則屬於外部系統。

  1. 目標專案目標範圍PO 呼叫 · 限定範圍的提示詞維護分析

    維護作業以限定於目標專案的提示詞呼叫 PO 代理。不顯示原始碼內容。

  2. PO 呼叫 · 限定範圍的提示詞維護分析提議議題提議 · backlog議題追蹤系統

    提示詞要求只以已驗證的路徑提出提議，作為未指派的 backlog 議題，並禁止執行 DB migration。這是給產品代理的指示，不是確定性的強制機制。

  3. 提議 · backlog議題追蹤系統張貼提議訊息 ↔ 議題對應提議張貼

    每項提議張貼到 Slack，並儲存訊息與議題的對應。已張貼的提議不會再次張貼，儲存的對應只保留最新 50 筆。

  4. 訊息 ↔ 議題對應提議張貼Slack 訊息人 · 核准、拒絕

    人在 Slack 中看到張貼的提議。

  5. 人 · 核准、拒絕表情回應訊息 ↔ 議題對應提議張貼

    對訊息的表情回應會透過對應找到議題。沒有自動核准。

  6. 訊息 ↔ 議題對應提議張貼核准 → todo執行議題 · todo議題追蹤系統

    核准時，送出將待處理提議議題改為 todo 的請求，並更新對應與討論串通知。此處理不檢查回應碼就將對應標記為已核准，因此不是 fail-closed 的交易。

  7. 訊息 ↔ 議題對應提議張貼拒絕 → cancelled提議 · backlog議題追蹤系統

    拒絕時，送出將同一議題改為 cancelled 的請求。議題在核准前就已存在；核准並不會建立它。

  8. 執行議題 · todo議題追蹤系統指派受指派代理

    todo 議題的指派與執行屬於外部執行系統。將議題改為 todo 並不保證工作已開始。

停滯 → 復原 → 人

活動停止的已指派議題，會帶著議題與負責人再次請求；連續無回應達到上限時，交給人處理。

  1. 受指派代理執行記錄近期執行 · 活動執行觀測

    受指派代理的執行與近期訊號記錄為觀測。活動不是完成的證據。

  2. 近期執行 · 活動執行觀測最後活動停滯檢查 · heartbeatStage reaper

    reaper 只看非 done、cancelled 或 blocked 且有負責人的議題，並計算最新訊號與 stage 的經過時間。

  3. 停滯檢查 · heartbeatStage reaper無回應 +1無回應次數 · 各議題無回應狀態

    依代理與議題計算連續無回應次數，並儲存在狀態中。

  4. 近期執行 · 活動執行觀測新活動 → 重設無回應次數 · 各議題無回應狀態

    新活動會重設次數。

  5. 停滯檢查 · heartbeatStage reaper重新呼叫議題 + 負責人復原呼叫

    若超過 heartbeat 且次數低於上限，就發出復原呼叫。

  6. 議題 + 負責人復原呼叫議題 + 負責人執行議題 · todo議題追蹤系統

    帶著議題、受指派代理與說明留言再次請求指派，並檢查 HTTP 回應。legacy 路徑則改用單次喚醒呼叫。

  7. 無回應次數 · 各議題無回應狀態3 次後停止重新呼叫 · cooldown上限

    連續無回應達到上限（預設 3 次）時，停止重新呼叫。上限只在狀態 hook 讀寫次數時成立，儲存失敗可能削弱它。

  8. 停止重新呼叫 · cooldown上限重新指派 · 通知Lead · 維運人員

    可行時改指派給 Lead，且只在該功能啟用時才將 in_progress 改回 todo。否則留下留言與盡力而為的通知，並在達到上限後記錄 cooldown。

  9. 停滯檢查 · heartbeatStage reaper僅警告Lead · 維運人員

    stage 持續過久時，只為維運人員留下警告留言。狀態不會自動變更。

所有連線以相同粗細顯示。選擇一個流程，即只突顯其路徑，並標出步驟編號。

  • 實線 · 輸入、結果與記錄的流向
  • 虛線 · 執行、判定、請求
  • 長點劃線 · 觀測與回報，與判定分開
  • 短虛線 · 失敗、停止、上限
  • 粗黑線 · 所選流程；數字表示順序
  • 方框 · 程式碼或狀態邊界，名稱在標題列
  • 內層小框 · 該邊界的元件
  • 虛線框 · 該邊界之外
  • 橘色外框 · 模型做出判斷之處
  • 代理呼叫 · 復原呼叫
  • 狀態 · 記錄
  • 停滯檢查 · 上限
  • 收集 · 張貼

依據非公開的實作與開發記錄繪製。不顯示團隊、議題與 Slack 識別碼及原始訊息；部署、容器與認證資訊屬於此外掛以外的負責人。

一次觀測
2026年4月28日報告：在變更前的手動診斷中，一個已 67 小時未執行的議題，帶著議題與負責人再次請求指派後，5 秒內就有新的執行進入佇列。未測量完成、平均復原時間與部署後效果。
核准處理的限制
與復原呼叫不同，核准處理不檢查回應碼就將對應標記為已核准。不將其描述為原子性或 fail-closed 的核准交易。
上限成立的條件
3 次上限是在有狀態 hook 時才成立的實作。不保證每種失敗下都恰好升級一次。