工作狀態（Working State）

每個 AI 員工一份跨喚醒持續有效的唯一權威狀態：每次喚醒自動注入提示詞，變更只走可稽核的專屬工具。

問題：一天三條停損線

一個長駐的 AI 員工不是只有「對話」：排程巡檢、心跳、目標迴圈、九個通道的訊息，每一次喚醒都是一次全新的呼叫，彼此不共享對話歷史。這帶來一個真實事故等級的問題：員工自己訂下的操作規則，下一次喚醒可能就忘了，或讀到另一份筆記裡的另一個版本。

自主投資實驗第三天，操盤員工一天之內寫下三條互相矛盾的停損線：

09:04 盤前策略：262（「跌破即出場不猶豫」）
盤中十幾次巡檢：254（「策略文件的 -5%」）
收盤覆盤：257（「明天跌破就認錯」）

當天股價最低 261，照第一條規則早該出場，但後續喚醒根本不記得那條線存在。根因不是模型「紀律渙散」，是架構缺陷：規則只存在於它當下讀到的筆記裡，而筆記（日誌、策略文件）天生是流水帳，同一件事可以有 N 筆矛盾記錄並存。研究文獻稱這個病為 ghost memory（過時與現行的事實並存、檢索時混合）。

運作方式

每個 AI 員工有一份跨喚醒持續有效的「工作狀態」：鍵值化的現行規則與承諾（例如 stop_loss.2317 = 262）加一段「交接註記」。閘道在每一次喚醒自動把它注入提示詞尾端，標明這是唯一權威的現行值；員工要變更任何一項，必須呼叫專屬工具並附理由，舊值進入可稽核的取代鏈。沒設定過任何狀態的員工零注入、零成本。

注入的內容長什麼樣子

每次喚醒，員工的提示詞尾端會多出這一段（自動、不用員工去讀任何檔案）：

## 工作狀態（唯一權威 · 由你自己以 working_state_set 維護）
以下鍵值是你跨喚醒持續有效的工作狀態與承諾，為唯一權威的「現行值」；
筆記、日誌、策略文件裡與此矛盾的數字一律是歷史值（已作廢），不得採用。……
- stop_loss.2317 = 262（08-13 09:04 設；理由：跌破即出場不猶豫；有效至 08-13 13:30）
- position_cap = 96%（08-12 08:42 設；理由：留最低手續費緩衝）
交接註記（08-13 09:36 留）：盤中每 3 分巡檢中；帳務已核對。

工具（MCP，五種執行環境通用）

工具	用途
`working_state_set`	設定/更新一個 key（`reason` 必填；可選 `ttl_hours` 讓當日規則自動到期；可選 `expected_value` 做並發保護，與現值不符即拒寫並回報現值）
`working_state_clear`	作廢一個 key（`reason` 必填）
`working_state_handoff`	覆寫「交接註記」：下一次喚醒的自己需要知道的事（純文字，或見下方「結構化交接」）
`working_state_get`	讀全量：所有 key（含已到期的，會標記）、交接註記、近期取代歷史

設計要點

只收顯式工具呼叫：絕不從員工的回覆文字自動抓「看起來像規則的句子」（自述不可信）。每次變更都進稽核日誌與取代鏈，改停損線這個動作本身也會出現在下一輪的「近期自身行動」區塊裡。
並發保護（CAS）：兩個同時進行的喚醒（例如每 3 分鐘的排程巡檢）不能互相蓋寫：帶上 expected_value，別的喚醒已改過就會被拒絕。
TTL：盤中停損線這種「當日規則」設 ttl_hours，明天它就不再是權威（檔案裡留著可查，但不再注入）。
上限逼收斂：最多 32 個 key；到頂時新增會被拒絕並列出現有 key，狀態表膨脹成第二座筆記山就失去意義了。
成本：注入放在提示詞快取分層之後的動態尾巴，不打斷快取前綴；區塊上限 3KB；空狀態零注入。

結構化交接（Ralph 式，可選）

純文字交接（只給 note）完全不受影響：照舊靜默收合空白、超過約 1200 字元靜默截斷。

想要更硬的交接，working_state_handoff 可以額外帶四個欄位：status（continue／complete／blocked）＋next_steps／evidence／blocker。一旦帶了其中任何一個，就必須同時帶 status，並且會依 status 強制校驗，不合規則直接拒絕整次呼叫：

status	要求
`continue`	`next_steps` 必填非空；不能有 `blocker`
`complete`	`evidence` 必填非空；不能有 `blocker` 或 `next_steps`
`blocked`	`blocker` 必填非空

背後的道理：「已完成」不能是自稱的：沒有具體證據就不准標 complete；還在做的交接也不能沒有下一步，否則下一次喚醒的自己等於白紙一張。

超長整筆拒絕、絕不截斷：note＋next_steps＋evidence＋blocker 合計位元組數（CJK 安全計算）超過 config.toml [memory] working_state_handoff_max_bytes（預設 16384）會直接回錯誤，交接完全不會寫入。這點特意跟純文字模式的「靜默截斷」不同：結構化交接一旦被截斷，可能剛好削掉那段讓交接可信的證據或下一步，卻仍然看起來像一份完整、可信的交接，這比直接拒絕還危險。

帶了 status 之後，注入到下一次喚醒的區塊也會多帶這些欄位：

交接註記（08-13 09:36 留）：盤中每 3 分巡檢中；帳務已核對。（狀態=continue；下一步：核對完後回報總額；證據：帳務表已比對三次）

上限可調（見下方「設定」的 working_state_handoff_max_bytes）。

與其他機制的分工

機制	回答的問題
工作狀態（本功能）	我現在承諾/有效的規則是什麼？
近期自身行動（稽核 feed）	我做過什麼（含被攔的）？
目標任務 `<state>` 區塊	這個任務進行到哪？
記憶／經驗法則	我學到什麼？
共享 wiki	團隊共同的 SOP／參考文件

設定

config.toml：

[memory]
working_state_enabled = true             # 預設開；只關「注入」，工具與檔案不受影響
working_state_handoff_max_bytes = 16384  # 結構化交接（見上方「結構化交接」）的總位元組上限，CJK 安全計算；純文字交接不受此限

狀態檔在 <員工目錄>/state/working_state.json，取代歷史在同目錄 working_state_history.jsonl，都是人可讀的檔案，出問題直接打開看。

給員工的使用慣例（建議寫進員工的 CLAUDE.md）

決策參數（停損/停利/部位上限/目前階段）一經決定，立刻 working_state_set，當日規則帶 ttl_hours。
巡檢時以注入的工作狀態區塊為準，禁止臨場重算另立新值。
每次收工前 working_state_handoff 留交接：context 隨時會結束，沒寫回的決定等於沒做過。

總結

長駐員工需要一個「現行規則」的唯一棲身處，而那個地方不能是散文。工作狀態給每個員工一張唯一權威的狀態表：每次喚醒自動注入、變更只走可稽核的工具、舊值進取代鏈退場而非留下來打架。筆記照樣有用，它是歷史，只是不再與權威競爭。