Skip to content

多智慧體團隊評估

按團隊結構而非扁平的對話記錄來標註多智慧體系統。Potato 提供可點選的智慧體互動圖、跨智慧體失敗歸因、交接審查、單智慧體與整隊評分卡、工具爭用時間線，以及湧現行為標記。

多智慧體系統的失敗方式與單個智慧體不同：故障發生在智慧體之間、在某次交接處，或源於團隊的組織方式。評估它意味著把結果歸因到是哪個智慧體、哪一步、哪次交接，而不只是給一段扁平的對話記錄打分。 Potato 為此提供了一組專門構建的標註介面：可點選的互動圖、失敗歸因、交接審查、單智慧體與整隊評分卡、工具爭用時間線，以及跨泳道的湧現行為標記。

這些都建立在智慧體軌跡檢視與 MAST 失敗分類體系之上。每個 schema 在渲染時都從軌跡本身推匯出其中的智慧體、步驟與交接，因此標註者只能從執行中實際發生的內容中進行選擇。

互動圖（agent_interaction_graph）

整次執行渲染為一張有向圖：節點是智慧體，邊是它們之間的訊息與交接轉移（邊越粗表示越頻繁），佈局根據軌跡自動生成。標註者點選節點以標記關鍵路徑，點選邊以在 正常 → 關鍵 → 有問題 之間迴圈切換。對於"我如何看清一次多智慧體執行的結構"這個問題，這是最清晰的答案，也是通用標註工具不提供的一種介面。

可點選的智慧體互動圖，帶關鍵路徑和被標記的交接Mark the critical path and flag problematic handoffs on a clickable agent-interaction graph

yaml
annotation_schemes:
  - annotation_type: agent_interaction_graph
    name: graph
    description: "Mark the critical path and flag any problematic handoffs."
    steps_key: steps
    agent_key: agent

儲存為 {"critical_nodes": [...], "edges": {"A->B": "problematic", ...}}。每個節點和邊都可通過鍵盤聚焦，並有一段即時文本摘要列出關鍵節點和被標記的邊，因此含義絕不會僅靠顏色來傳達。

跨智慧體失敗歸因（failure_attribution）

當一個團隊失敗時，有用的標籤是來自失敗歸因文獻的**（責任智慧體、決定性步驟、原因）**三元組（Zhang 等人，Which Agent Causes Task Failures and When?，ICML 2025，Who&When 資料集）。智慧體下拉框和步驟選擇器由軌跡自身的回合填充，因此標註者會把失敗歸因到一個真實的智慧體和一個真實的步驟上。

將一次多智慧體失敗歸因到某個智慧體、某一步驟和某個原因Attribute a multi-agent failure to the responsible agent, the decisive step, and why

yaml
annotation_schemes:
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent
    # agents: [Planner, Coder, Reviewer]   # optional static list instead of deriving from the trace

儲存為 {"responsible_agent", "decisive_step", "reason"}。將它與一個 radio 結果 schema（成功/失敗）搭配使用，使歸因只在失敗的執行上觸發。

交接審查（handoff_review）

每一次交接，即一個智慧體將控制權傳給另一個智慧體，都成為一個可標註的一等物件。只要行動智慧體在相鄰回合之間發生變化，Potato 就會生成一張交接卡片 A → B；標註者標記智慧體間的失配並評定交接品質。這些失敗模式以 MAST 的智慧體間類別和"回聲"現象為依據（Zhang 等人，2025）。

帶失配標記和品質評分的交接卡片Flag inter-agent misalignment on every handoff and rate its quality

yaml
annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

交接在渲染時從軌跡中推匯出來，因此無需手動設定。儲存為一個 {index, step, from, to, flags, quality} 列表。

單智慧體與整隊評分卡（agent_scorecard）

在兩個層級上同時為一次執行打分（MultiAgentBench，Zhou 等人，ACL 2025）：每個智慧體獲得各維度的分數（角色忠實度、貢獻度、協調性），團隊獲得共享維度的分數，並可選地勾選里程碑。智慧體的行來自軌跡自身的回合，因此該矩陣與實際參與者相匹配。

帶里程碑的單智慧體與整隊評分卡Score every agent on role fidelity, contribution, and coordination, plus the team and milestones

yaml
annotation_schemes:
  - annotation_type: agent_scorecard
    name: scorecard
    description: "Score each agent, the team, and which milestones were reached."
    steps_key: steps
    agent_key: agent
    scale: 5
    agent_dimensions: [role fidelity, contribution, coordination]
    team_dimensions: [coordination, communication, efficiency]
    milestones: [plan produced, task delegated correctly, result verified]   # optional

儲存為 {"agents": {name: {dim: score}}, "team": {dim: score}, "milestones": {name: bool}}。

工具／資源爭用時間線（tool_contention）

跨智慧體的併發工具與資源使用會渲染在一條多泳道時間線上，每個智慧體一條泳道。兩次呼叫在重疊時間內觸及同一資源的區域會跨泳道高亮，並列出以供分類：死鎖、迴圈等待、競態條件或良性（DPBench，2026）。這就是你捕捉逐回合對話記錄所隱藏的併發故障的方式。

帶高亮爭用區域的逐智慧體工具呼叫時間線Spot deadlocks and race conditions on a per-agent tool-call timeline

yaml
annotation_schemes:
  - annotation_type: tool_contention
    name: contention
    description: "Classify each shared-resource contention region."
    calls_key: calls          # list of {agent, tool, start, end, resource}
    agent_key: agent
    resource_key: resource
    contention_labels: [deadlock, circular_wait, race_condition, benign]

爭用區域在渲染時計算得出（相同的 resource、重疊的區間）。儲存為 {"contentions": {idx: label}}。

跨泳道湧現行為（emergent_behavior）

有些失敗是集體性的：合謀、群體思維、級聯錯誤、角色漂移。一種湧現行為並不是一段連續的文本跨度；它是一個參與回合的集合，可能來自不同的智慧體。對於每一種行為，標註者勾選參與其中的回合並新增備註，即一個以回合集合表達的跨泳道跨度。

將跨智慧體的一組回合標記為級聯錯誤Tag collusion, groupthink, and cascading errors across agents and turns

yaml
annotation_schemes:
  - annotation_type: emergent_behavior
    name: emergent
    description: "For each collective behavior, check the turns (across agents) that participate."
    steps_key: steps
    agent_key: agent
    behaviors: [collusion, groupthink, cascading_error, role_drift]
    allow_note: true

儲存為 {behavior: {turns: [idx...], note}}，只保留非空的行為。

工具呼叫審查（tool_call_review）

逐一評判每次工具或函式呼叫：是否選對了工具，參數是否正確，順序是否得當（對標 BFCL v4 / MCPMark）？工具呼叫在渲染時從軌跡步驟中提取；每一步的 tool_calls、tool_call 或 action 都會成為一張帶工具名稱和美化列印參數的卡片。

對軌跡中每次工具呼叫的逐呼叫裁定Judge every tool call: right tool, correct arguments, right order

yaml
annotation_schemes:
  - annotation_type: tool_call_review
    name: tool_review
    description: "Judge each tool call: right tool? correct arguments?"
    steps_key: steps
    # verdict_options: [correct, wrong_tool, wrong_args, wrong_order]   # customizable

儲存為一個 {index, step, tool, verdict, notes} 列表。

步驟粒度的 MAST 標記

你無需新的 schema，就能把 14 種模式的 MAST 失敗分類體系（Cemri 等人，Why Do Multi-Agent LLM Systems Fail?，2025）繫結到失敗發生的確切步驟（因而也繫結到行動智慧體）。把現有的逐步 trajectory_eval schema 配置為以 MAST 模式作為它的 error_types，並按三個 MAST 類別分組。將它與 failure_attribution 和 handoff_review 搭配以實現完整覆蓋。

yaml
annotation_schemes:
  - annotation_type: trajectory_eval
    name: mast_steps
    description: "Tag each step with the MAST failure mode(s) it exhibits."
    steps_key: steps
    step_text_key: content
    error_types:
      - name: "Specification & System Design"
        subtypes: ["Disobey task specification", "Disobey role specification", "Step repetition", "Loss of conversation history", "Unaware of termination conditions"]
      - name: "Inter-Agent Misalignment"
        subtypes: ["Conversation reset", "Fail to ask for clarification", "Task derailment", "Information withholding", "Ignored other agent's input", "Reasoning-action mismatch"]
      - name: "Task Verification & Termination"
        subtypes: ["Premature termination", "No or incomplete verification", "Incorrect verification"]

選擇編排視角

編排架構往往主導一次執行的結果，因此值得將其作為一等標籤來捕獲。無需新的 schema：一個 radio 確認或糾正該執行的模式，進而引導評估視角以及軌跡的佈局方式（順序型 → 泳道，層級型 → 樹，群聊型 → 看板）。

yaml
annotation_schemes:
  - annotation_type: radio
    name: orchestration_pattern
    description: "Which orchestration pattern does this run actually follow?"
    labels: [single_agent, sequential_pipeline, hierarchical_manager, group_chat, blackboard, debate, hub_and_spoke]
    has_free_response: true

相關內容

如需實現細節，請參閱源文件。