Agentic Safety Infrastructure

此目錄包含參考模板，可用來建立像人工調查人員一樣瀏覽組織資料的信任與安全 agent。目標是為安全團隊提供起點，讓他們可以 fork、自訂，再提供給正式環境、調查及助理 agent 使用。

這些內容是模板，並非 contract。每個安全團隊的資料模型不同，每個平台的實體階層也不同。真正驅動偵測的 Signal 分散在不同團隊擁有的資料儲存系統。模板不強迫所有組織採用共同 schema，而是統一資料的形狀，包括實體如何宣告 edge、Signal 如何宣告 binding，以及 key 如何在兩者間來回對應。如此一來，學會讀取其中一個 fork 的 agent，也能讀取其他 fork。

這項工作是 ROOST 社群建立開放網路安全基礎設施的其中一部分。較完整的動機說明位於 Agentic Safety blog post，本 README 則著重實際操作。

目錄內容

agentic_infrastructure/
├── entity_schema/
│   ├── abstract_entity_schema.yaml   # 實體與 edge，例如 Actor、Content、Space、Cluster、Case
│   ├── signals.yaml                  # 附加至實體的 Signal，例如 reputation、harm_labels
│   ├── discord_entity_schema.yaml    # Discord 平台 fork
│   └── youtube_entity_schema.yaml    # YouTube 平台 fork
├── harm_taxonomy.yaml                # 危害類別、嚴重程度、預設措施及路由 Queue
└── playbooks/
    ├── investigation_coordinated_commenting.yaml   # 調查 persona，只提出建議
    └── production_spam_autoaction.yaml             # 正式環境 persona，限縮自動處置範圍

實體具有識別資訊與生命週期。如果某個事物需要依 ID 跨時間參照，它就是實體。Signal 則由計算產生、可變動，並形成時間序列。如果某項資料由計算產生並覆寫，它就是 Signal。兩類檔案共用一項規則，每個參照都使用相同的 key 形狀 {platform, platform_id}。

同時讀取兩類檔案的 agent 可以走訪 graph，也就是在實體間移動，並在每一步補充 Signal，而不需猜測有哪些資料或應從何處取得。

Agent 瀏覽路徑

四種檔案各自回答一個問題。Playbook 是 agent 唯一的進入點，其餘內容都由它參照。

檔案	回答的問題
`playbooks/<name>.yaml`	應做什麼，順序為何？
`entity_schema/abstract_entity_schema.yaml`	存在哪些實體與 edge？
`entity_schema/signals.yaml`	每個實體可以附加哪些補充資料？
`entity_schema/<platform>_entity_schema.yaml`	平台資料如何對應至抽象實體？
`harm_taxonomy.yaml`	應建議什麼類別、嚴重程度、措施及 Queue？

調查路徑，以協同留言案例為例。

playbooks/investigation_coordinated_commenting.yaml      # 計畫與門檻
   │   trigger: Report
   ├──► entity_schema/abstract_entity_schema.yaml        # Report.target → Content
   │   走訪 Content.edges.author → Actor
   ├──► entity_schema/signals.yaml                       # Actor signals: reputation, cluster_memberships
   │   追蹤 cluster_memberships.returns_entity_ref → Cluster
   ├──► entity_schema/abstract_entity_schema.yaml        # Space.edges.child_content → siblings
   ├──► entity_schema/signals.yaml                       # Content signals: similarity_hash, near_duplicate_cluster
   └──► harm_taxonomy.yaml                               # category、default_severity、default_actions、default_queue
        → 建立 Case，路由至 needs_review

正式環境路徑，以高信心垃圾訊息自動處置為例。

playbooks/production_spam_autoaction.yaml                # trigger 與限制
   │   trigger: classifier_scores.spam ≥ 0.95 的 Content
   ├──► entity_schema/signals.yaml                       # classifier_scores、harm_labels、reputation、trust_tier
   ├──► entity_schema/abstract_entity_schema.yaml        # Content.author → Actor (is_verified, trust_tier)
   ├──► harm_taxonomy.yaml                               # forbidden_categories 檢查與 spam 預設值
   └──► entity_schema/abstract_entity_schema.yaml        # 寫入 ModerationDecision 並送出 Event

平台 fork（youtube_entity_schema.yaml 與 discord_entity_schema.yaml）保留抽象詞彙，因此相同 playbook 路徑可直接套用至任一平台，不需修改。

資料形狀

每個實體宣告以下內容。

具有型別的欄位
具名稱、目標實體與 cardinality 的 edge
附加至實體的 Signal，其 slot 名稱在 signals.yaml 解析

每個 Signal 宣告以下內容。

附加至哪一個實體
型別、cardinality 與 freshness window
來源，也就是 scorer、模型或 pipeline
semantics，也就是數值的實際意義

上游提到一份透過協同留言調查案例說明此模式的 entity_schema/BLOG_agent_schema.md，但該檔案未包含在目前固定的來源 commit 中。因此本譯本不建立無法解析的站內連結。

為您的平台建立 fork

將 abstract_entity_schema.yaml 與 signals.yaml 複製到組織的 repo。
重新命名或移除不存在的實體，並加入平台需要的實體，例如付款平台的 Transaction。
維持每個實體的 edges: 與 signals: block 完整。Agent 會依這些內容規劃走訪路徑。
將每個 Signal slot 綁定至實際 scorer 或儲存系統。Stub 只提供常見 slot 名稱，source 欄位須由採用者填寫。
以新增方式擴充 enum。移除既有值會破壞依賴該值的 agent。

不需要公開分享 fork。模板為開放內容，自訂內容可以保留在私有環境。

如何協助

我們選擇公開建立這套架構，因為沒有任何單一團隊掌握完整情況。缺口本身正是值得了解之處。

安全實務工作者：fork 模板，並告訴我們哪些地方無法對應您的平台。無法清楚對應的平台特有概念，正是我們需要的 Signal。
Agent 建立者：告訴我們哪些走訪方式常見到值得標準化為 playbook 模板。協同留言是一例，社群討論中也曾提到性勒索、盜刷測試及遊戲中的誘騙模式。
開發者：schema 是 contract。Adapter、走訪引擎、playbook runner 及 validator 都可以建立在其上，歡迎貢獻。

如想協助發展方向，可提出 issue、提交 PR 或發起 discussion。對手已經比我們更快地瀏覽基礎設施，讓 agent 取得相同地圖，是追上對手的方法。

正式環境 agent 可能讀取敏感資料或執行平台處置。採用前必須另行限制權限、核准 query、驗證門檻、保留稽核紀錄、建立停止與回復機制，並由人工審查高風險決定。