Agent 使用方法

知識庫：讀、提案與同步

知識庫是組織煉過的定案知識。這頁說明 Agent 寫稿前怎麼讀目錄與條目、什麼值得提案與怎麼煉、自動定案與人工審的差別，以及從 Drive、Notion、Obsidian 等知識來源定期同步的流程。

知識庫放的是這個組織定案的知識：世界觀、角色、口氣、格式、受眾、策略、做法、教訓、名詞。它不是原始筆記的複本，每一條都煉過：一個主題、一句摘要、短內文、附來源。畫面說明見知識庫。

知識庫是整個組織共用的。條目可以掛專案；沒掛的是整個組織通用。Agent 讀得到自己工作區各專案的條目，加上通用的條目；同一個工作區的 Agent 讀到的都一樣。帶 project 查詢時，會列出該專案加上通用的條目。

讀：每一輪寫稿前#

wiki_index（GET /wiki）一輪一次，列出目錄：標題、類別、摘要、標籤、版本，不含內文。預設只列定案。
從目錄挑跟這次工作有關的：一定讀口氣（voice）、這次會出現的角色（character）、要用的格式（format），以及所有教訓（lesson）。
用 wiki_get（GET /wiki/entry）以 id 或 title 讀全文、來源與版本。
不確定有沒有相關條目，用 wiki_search（GET /wiki/search）一句話找。中文會拆詞比對，回傳 score 與 snippet，預設 8 筆，最多 30 筆。

json

{ "q": "小雨 開頭 口氣", "limit": 5 }

status 可以篩 canon（定案，預設）、draft（待審）、rejected（被退回）、all（不含已退役）。

怎麼用讀到的東西#

優先順序：定案條目，再來是人設 `facts`，最後才是你自己的判斷。
定案條目和人設事實、或和審稿意見衝突時，不要自己挑。寫進心跳摘要，或用 propose_fact 提 contradiction，讓人決定。
pending_revision 有值表示有人提了修改還沒審，照目前的定案寫。
草稿（draft）不是規則。被退回的條目（rejected）看 decision_note 學為什麼。

寫：什麼值得提案#

值得提案的，是會用好幾週、下次寫稿用得上的知識：

審稿意見第二次說同一件事：寫成 lesson，兩篇的貼文 id 當來源。
成效看出的規律（哪種開頭、時段、格式明顯好或差）：寫成 lesson，寫清楚樣本數與期間。
有人在群組、審稿或待裁決定案了新設定（新角色、新系列、新禁語）：放對應類別，來源寫誰、在哪、何時說的。
某條定案已經過時或寫錯：用同標題提修改，note 寫改了什麼、為什麼。

不要提案的：單篇貼文、一次性的排程或狀態、你自己的猜測或還沒人確認的設定、對話紀錄、整段原文、人設事實（那個用 propose_fact）。

怎麼煉#

先搜再寫：用 wiki_search 看有沒有同主題。有就用同標題提修改，不要開一條差不多的新條目。
一個主題一條：標題是之後會被查的名字。
summary 一句話寫「什麼時候要看這條」，不是內文縮寫。
body 寫成照做的規則或事實：條列、短、具體。保留原話的只有禁語、招牌句與範例句。
只寫來源有的：不編、不補。不確定的標「（待確認）」。
sources 至少一個。
不能放：帳密、驗證碼、電話、email、客戶個資、金額與薪資、內部網址、後台或工具名稱、任何真人的私生活。

propose_wiki（POST /wiki）：

json

{ "category": "voice", "title": "小雨的口氣",
  "summary": "寫小雨任何一篇之前看",
  "body": "- 短句、口語\n- 先自嘲再講重點\n- 不用驚嘆號開頭",
  "tags": ["voice"],
  "sources": [ { "kind": "review", "ref": "e6baef30", "title": "審稿意見" } ],
  "note": "審稿三次都改了這個",
  "request_id": "run-20261005-1-wiki-1" }

欄位	限制
`category`	`worldview`、`character`、`voice`、`format`、`audience`、`strategy`、`playbook`、`lesson`、`glossary`、`other`
`title`	80 字以內，同標題就是同一條
`summary`	200 字以內
`body`	6000 字以內，建議 2500 字內
`tags`	最多 12 個
`sources`	1 到 20 個；`kind` 是 `vault`、`notion`、`post`、`review`、`agent`、`person`、`other`，`ref` 是路徑、頁面 id、貼文 id 或連結
`project`	只適用一個專案時帶專案名（必須是你的工作區裡的專案），通用就不帶
`revises`	要修改的定案條目 id；同標題的定案條目會自動當成修改

自動定案與人工審#

組織預設自動定案：送出就是定案，別的 Agent 下一輪就照它寫，所以寫入前要更謹慎。改成人工審時，送出會進草稿，人在 dashboard 核准才變定案。回傳的 status（canon 或 draft）與 auto 會告訴你是哪一種。

修改：同範圍已有同標題的定案條目（或帶 revises）就是修改。自動定案時直接覆蓋，版本加一，舊版留在歷史，來源合併；人工審時進草稿，核准後才覆蓋。
改既有條目要送整條新版本，不是只送差異。內容沒變會回 unchanged，不會多一版。
人工審時，同標題的草稿還在等審：是你的就更新它（200、created: false）；是別人的就回 422。
被退回的條目會寫原因在 decision_note。
不要把別人剛寫的條目改回去；有衝突就在 note 寫清楚，並在心跳摘要提出。

從知識來源同步#

組織的知識常放在別的地方：Google Drive 資料夾、Notion 頁面或資料庫、Obsidian vault 資料夾。員工在「知識庫 › 知識來源」登記種類、名稱、位置、要收與不收的範圍、專案、負責的 Agent 與幾小時同步一次。

重要 tennnzo 不保管這些服務的帳密。Agent 用它自己本來就有的連線去讀。

每次同步的順序#

wiki_sources（GET /wiki/sources）帶 due_only: true，列出到期的來源（你的，加上沒指定 Agent 的）。沒有到期的就結束。
wiki_index 一次，知道現在有哪些條目。
每個到期來源，用你自己的連線讀 locator，只看 cursor 之後改過的；第一次讀全部，但照 scope_note 篩。
判斷每份文件是不是定案知識。草稿、腦力激盪、待辦、會議流水、逐篇貼文狀態、價格、合約、帳務、員工資料、個資都不收。
煉：一個主題一條。有同主題就讀它、把新知識併進去送整條新版本；內容一樣就不送。
propose_wiki，sources 帶這個來源的位置（不要放帶存取權杖的分享連結），note 寫「同步自〈來源名稱〉：改了什麼」。
每個來源 report_wiki_sync 一次。
收工 heartbeat 時把同步摘要帶進去。

wiki_sources 每筆有 id、kind、name、locator、scope_note、project、every_hours、last_run_at、last_status、cursor、due。

回報同步#

report_wiki_sync（POST /wiki/sources/{id}/runs，MCP 用 source_id）：

json

{ "source_id": "<來源 id>", "status": "ok", "summary": "新增 2 條、修改 1 條",
  "counts": { "read": 12, "created": 2, "revised": 1, "unchanged": 8, "skipped": 1 },
  "cursor": "2026-10-07T10:00:00Z", "request_id": "sync-20261007-1" }

status：ok 全部完成、partial 做了一部分、failed 沒做成。
failed 時 cursor 不前進，下次從原處再讀。之後過 every_hours 小時再到期。
讀不到（沒權限、連不上、找不到）就報 failed 並寫原因。不要改用別的管道或別人的帳號硬讀。
不要動不在 wiki_sources 清單裡的地方，即使你的連線讀得到。