SocialHub.AI
新增功能 · 依工作區逐步推出

人工智慧治理:反思與審批

Flash 將每個 AI 啟動的操作置於每個操作授權裝置之後 - auto、review 或 forbidden - 在 AI 活動和核准控制台中為每個工作區配置。對於 MCP 上的 AI 用戶端,這意味著兩件事:您可以發現業務物件以及在行動之前允許您執行的操作,並且您的寫入呼叫返回結構化結果 - 已執行、等待人工批准或因機器可讀原因而被拒絕。

本指南涵蓋了自省工具、審查機制下的寫入語意以及審批生命週期。它基於相同的受管控機制建構。 MCP 伺服器文件已記錄在內 MCP 整合指南有關業務概覽,請參閱… AI治理與審批產品頁面. 設備路由是逐步啟用的-以下行為將隨著受控操作逐步部署到您的工作區而生效。

業務-object 內省 (範圍 introspection:read)

三個讀取工具讓 AI 用戶端在接觸業務之前就能了解其結構:哪些物件存在(包括工作區本身的自訂欄位和自訂物件)、每個屬性的含義、物件之間的關係以及哪些操作可執行——包括它們的前提條件和目前狀態。一個行為良好的代理會先呼叫這些工具,並且只提出狀態實際允許的操作。

list_objects讀取

發現鍵的工作區中可用的業務對象:會員、訂單、優惠券、活動、門市、產品、細分、標籤——以及工作區定義的任何自訂對象。傳回每個 object 的鍵、標籤和一行意義說明。先打電話了解狀況,再閱讀或採取行動。

參數: (none)
describe_object讀取

一個 object 的完整結構:包括其屬性(含工作區的自訂欄位)及其類型和業務意義,以及與其他物件的關係(例如,訂單屬於某個成員;優惠券可以發放給某個成員)。 PII 欄位僅以元資料傳回-名稱、類型、語意和 PII 標誌-絕不傳回其值。

參數: object
list_actions讀取

AI 用戶端可以執行的操作,以及每個操作的前提條件和目前授權機制(自動/審核/禁止),均由工作區配置。按 object 篩選,僅查看與其相關的操作。此篩選結果正是治理層將強制執行的內容-利用此篩選結果可避免提出會被拒絕的操作。

參數: object?

個人識別資訊 (PII) 僅包含元數據,這是設計使然。 自省功能描述了包含個人資訊(名稱、類型、意義以及 pii 標誌)但從不傳回其值的欄位。讀取實際成員資料需要透過成員讀取工具及其各自的權限範圍。

例:描述一個 object,然後檢查齒輪。

請求/回應結構的描述性範例(簡略版 - 實際回應會列出所有欄位和操作):

// describe_object { "object": "member" }
{
  "object": "member",
  "label": "Member",
  "meaning": "A loyalty program member owned by this workspace.",
  "fields": [
    { "name": "email",            "type": "string",  "pii": true,
      "meaning": "Contact email. PII: metadata only — values are never returned here." },
    { "name": "tier",             "type": "string",  "pii": false,
      "meaning": "Current loyalty tier." },
    { "name": "membership_no",    "type": "string",  "pii": false, "custom": true,
      "meaning": "Workspace-defined custom field." }
  ],
  "relationships": [
    { "to": "order",  "kind": "has_many",  "meaning": "Orders placed by this member." },
    { "to": "coupon", "kind": "has_many",  "meaning": "Coupons issued to this member." },
    { "to": "tag",    "kind": "has_many",  "meaning": "Tags currently applied to this member." }
  ]
}
// list_actions { "object": "member" }
{
  "actions": [
    { "action": "issue_coupon",     "gear": "review",
      "preconditions": ["member has consent", "coupon pool has stock"] },
    { "action": "earn_points",      "gear": "auto",
      "preconditions": ["amount within the workspace cap"] },
    { "action": "assign_tag",       "gear": "auto",
      "preconditions": ["tag exists and is active"] },
    { "action": "add_member_note",  "gear": "auto",
      "preconditions": ["note passes server-side sanitation"] },
    { "action": "send_campaign",    "gear": "review", "locked": true,
      "preconditions": ["sending can never be auto — a human always approves"] }
  ]
}

您看到的 gear 是將會強制執行的齒輪——工作區會在控制台中為每個操作配置它,並且每個操作的斷路器可以隨時將操作降級到 review(它只會自動降級;只有人工才能恢復)。請使用 list_actions 重新檢查,而不是為長時間會話緩存齒輪。

工具正在審核中:待審核/已拒絕

當一個 MCP 寫入工具針對一個齒輪為 review 的操作時,該呼叫不會 執行副作用。它會回傳一個結構化的結果:要麼提案已排隊等待人工審批 (pending),要麼提案已被直接拒絕 (refused),並返回機器可讀的 reason_code 和 suggested_action。

// proposed — waiting for a human
{
  "status": "pending",
  "proposal_id": "prop_9f2c…",
  "action": "issue_coupon",
  "expires_at": "2026-07-10T00:00:00Z",  // 7 days
  "message": "Queued for human approval in
              AI Activity & Approvals."
}
// refused — with a reason and a next step
{
  "status": "refused",
  "action": "issue_coupon",
  "reason_code": "recently_rejected",
  "suggested_action": "A human rejected this
    proposal recently. Do not re-propose;
    consider a different action or ask the
    operator."
}
reason_code意義您的代理商應該做什麼
gear_forbidden此操作的齒輪圖示已設定為禁止在此工作區中使用(或此操作永遠無法自動執行——例如發送——並且是以需要自動執行的方式呼叫的)。不要重試。揭露拒絕;續。 suggested_action (通常是另一種操作,或「請人幫忙換檔」)。
recently_rejected最近有人拒絕了相同目標用戶的相同提案——平台不會重新提交。尊重人的決定。不要重新提議或改寫;遵照執行。 suggested_action.

每一次拒絕都伴隨著 reason_code 在這種形狀中加上一個 suggested_action — 將上述程式碼視為分支跳轉依據,並將欄位視為可擴充的。拒絕操作是對您而言的硬性邊界判定,而不是可以繞過的錯誤: 千萬不要為了蒙混過關而隨意修改提案。

審批生命週期

pending 提案只能以一種方式解決:approved、rejected 或 expired。使用者在 AI 活動與審批控制台中對其進行操作(按操作類型進行單次或批量操作);每日摘要郵件會顯示待處理事項。

狀態工作原理然後
pending在審查操作的設備時調用了寫入工具 - 該提案已排隊等候人工批准。已批准 · 已拒絕 · 已過期
approved經人工審核。執行前,平台會重新驗證人工智慧的判斷依據;如果判斷不再成立(例如,客戶已再次購買),則不會執行該操作。終端(結果記錄在決策日誌中;可單獨撤銷)
rejected有人拒絕了該提案,可以選擇附上備註。同樣的提案隨後又被拒絕了。 recently_rejected 如果重新提交。終端
expired7 天內未做出決定-提案將自動過期,且不會執行任何操作。終端

冪等性保證

  • 一次核准,一次執行。 核准提案只會執行一次操作;重複核准會重播已儲存的結果,不會產生任何其他副作用。
  • 重新提交不會重複。 在同一提案處於待處理狀態時再次呼叫寫入工具會傳回相同的 pending 結果和 proposal_id — 它不會將第二張卡片加入佇列。
  • 審核重新驗證,執行是有條件的。 在審批時,平台會重新檢查 AI 所述理由是否仍然成立;如果不再有後續操作(例如,客戶已再次購買),則不會執行任何操作-記錄的是結果而非操作本身。
  • 所有內容均經過審核,且可單獨撤銷。 提案、決策、授權路徑(auto 或指定人員)、執行和結果均記錄在決策日誌中,其中單一條目均可撤銷。

伺服器是邊界。 齒輪、重新驗證、過期和每次操作的熔斷機制均在Flash端強制執行-絕不依賴代理的推理或其客戶端確認。無論客戶端要求什麼,發送類型的操作都不能自動運作。

透明度圖元和玻璃盒模型庫存

同樣的「透明盒子」原則——所有自動化決策均被記錄並可解釋,個人資料與模型上下文隔離——不僅限於受控操作:還延伸至流量優化實驗、出站 LLM 提示,以及為整個產品提供排名、預測和檢測功能的傳統機器學習模型庫。

A/B流量自動優化:決策日誌

循環行銷活動(自動化流程和使用者旅程)可以選擇啟用 「隨時間自動優化流量」 功能,該功能會根據觀察到的點擊效果,在不同的實驗版本之間重新分配投放權重。每次重新分配都可審計:

  • 僅追加決策日誌。 每小時重新計算一次,寫入一筆記錄,其中包含應用的權重和易於理解的理由。記錄永遠不會被重寫-日誌完整地記錄了流量變化的原因。
  • 已配置的拆分永遠不會改變。 您實驗中配置的拆分將保持不變,作為基線;優化後的權重將與基線一起計算並記錄。
  • 探索底線:10%。 任何變體的權重都不會低於 10%,因此每個變體都能持續獲得流量,並且任何逆轉都可檢測。
  • 平均分配,直到每個變體的交付量達到 ≥100。 權重將保持在配置的分配比例,直到每個變體的交付量至少達到約 100 次——不會在數據稀疏時重新分配權重,並且此機制永遠不會宣布任何統計意義上的「贏家」。

LLM PII 在服務提供者之間的連接處進行屏蔽

在任何提示離開 Flash 並發送給外部 LLM 提供者之前,會員的個人識別碼都會被封鎖——此操作在提供者連接處進行,因此所有 AI 功能都會經過此連接:

  • 確定性化名。 電子郵件地址、電話號碼和類似卡片的數字序列將被替換為穩定的替代標記。相同的標識符始終映射到相同的化名,因此模型對相同提示的推理保持一致。
  • 遮罩適用於每個 AI 功能發出的每個出站提示-無需啟用,也無法從產品中關閉。
  • 僅掩碼,從不取消掩碼。 輸出邊界處的映射是單向的:模型輸出永遠不會被重寫以恢復真實標識符,因此原始 PII 無法透過 LLM 回應進行往返。

為什麼這在今天至關重要。 Flash 的 AI 提示是基於聚合數據和活動數據構建,而非個人記錄——這種掩蔽機制是隨著 AI 功能擴展而始終有效的強制性保證,而非對漏洞的修補。

玻璃盒式庫存模型

產品中的每項預測或統計能力都採用經典的確定性模型:不使用黑盒評分或隨機抽樣,相同資料始終得到相同模型。每項能力都有明確的可靠性門檻:未達門檻時,不輸出結果,而非猜測;每項評分都附帶可供重算的資料。目前能力清單如下:

模型權力誠信驗證
兩種模型提升(兩種確定性邏輯擬合)SoClaw 贏回工作清單排名 — 風險價值 × 提升,根據該計劃自己的始終堅持的 RCT 進行訓練僅啟動過去 ≥200 個成熟處理行、≥50 個保留行和 ≥20 個轉換,兩者擬合收斂 - 低於此值,排名將回落到純粹的風險價值。消極提升(請勿打擾)的成員會沉淪;每個任務都儲存其分數快照。
每位會員的購買間 Gamma 值(基於關鍵時刻的方法)個人資料中的預計下次購買日期 + 「預計下次購買剩餘天數」細分條件(負值表示已過期)需要至少 3 個觀察到的缺口(即至少 4 次購買)以及基於節奏規律性的變異係數閾值(≤1.5)——不規律的購買者將獲得 NULL 值,絕不會獲得虛構的日期。超過預期日期將作為真實的逾期信號發出。
基於團隊的 L2 正規化邏輯迴歸點擊傾向 (0–100),每晚根據團隊自己過去 90 天的發送情況進行調整僅點擊標籤(從不打開 - Apple MPP 使它們膨脹);防洩漏事先點擊功能;按固定時間表進行確定性全批次梯度下降。適合門≥500次發送/≥30次點擊/≥50名會員;會員需≥3次最近發送才能評分。
餘弦歸一化項-kNN在推薦介面上進行「還購買了」產品配對。co_count / √(買家(A) × 買家(B)) 修正了受歡迎程度偏差;配對需要 ≥2 個共同買家才能實現;原始共同購買計數與分數一起存儲,作為可檢查的證據。
關聯規則(支持度/置信度/提升)交叉銷售建議,每晚從商家自己的訂單行中挖掘規則需要 ≥3 個同時發生的訂單且置信度 ≥5%;每條規則都會儲存其所依據的原始訂單計數,因此任何數字都可以手動重新計算。會員資料介面會排除已擁有的商品,並且僅對活躍買家顯示。
穩健統計異常值(中位數/平均絕對偏差)這 behavior_outlier 積分詐欺偵測器穩健的 z ≥ 6 加上絕對下限(≥10 次收益交易;跳過 50 名活躍成員以下的團隊);按月分組每個成員去重;僅凍結——它會開啟審核,但永遠不會自行作廢。
Kaplan-Meier + Cox 比例風險(Nelder-Mead 部分似然)按月註冊用戶群劃分的留存率 + “留存率的相關性”面板視圖上的列印定義:流失用戶 = 90 天未購買,排除從未購買過的用戶,30 人以下的佇列隱藏和公開。 Cox 擬合需要觀察到 ≥30 次流失事件,且最多使用 3 個協變量;相關性標記為“相關性”,而非“因果關係”。
霍爾特-溫特斯模型(每週季節性,固定常數)儀表板上未來 14 天的收入前景固定平滑常數-沒有針對每個團隊的調整表面;讀取與其他螢幕相同的認證收入指標;虛線+誤差帶,並列印其美元基準;完全隱藏在 4 週的歷史記錄下;標記為預測,而不是承諾。

這些模型都不會獨立運作:它們會進行排名、評分和標記,所有涉及資金流動或與會員聯繫的行為仍然會經過上述受控機制的處理。

有關每個模型的完整工程細節(方法、輸入、輸出列、誠信門和消費面),請參閱 預測模型參考。