完成率
交付前，品質等於零
Skywork 初期 PPT 品質已達 SOTA，但新用戶任務完成率低於 50%：使用者還沒看到結果，就因等待過久離開。
01｜Agent 度量為何比想像更難？
常見的六種數字都能解釋局部，卻沒有一個能獨立回答「好不好」。任務完成不等於品質達標、步數少不等於耗時短，Token 省了也可能犧牲產出。
耗時
速度是前提，不是終點
工程優化把 20 分鐘降到 5 分鐘，完成率大幅提升；但只追速度，又可能讓耗時功能被砍，反過來傷害品質。
行為
讚踩不是乾淨標籤
使用者可能對品質滿意，卻因點數太貴按踩；也可能因任務已交付而不回饋。顯性與隱性行為都受動機干擾。
Token
效率不能脫離產出
少用 Token 不代表更好；若換來重做、低品質或錯誤方向，只是把成本轉移到使用者身上。
步長
自主重試會增加步數
步數少但單步很慢，與步數多但能自主修正，不能直接相比。需要連結耗時、品質與修復效果。
正確率
問答正確 ≠ 任務正確
真實任務同時受目標、資料、工具、驗收與風險限制；單題答案正確，未必代表整個任務做對。
速度是品質被感知的入場券，不是最終答案。使用者等不到交付，再高的產出品質也等於零；因此先把等待時間從 20 分鐘壓到 5 分鐘，確實能明顯拉高任務完成率。但跨過「願意等」的門檻後，優化目標就必須從單純更快，轉為速度、品質與功能完整性的共同平衡。
20 → 5 分鐘
先消除交付前流失
速度優化首先解決的是「結果還沒出來，人就走了」。完成率是所有品質指標成立的前提，而不是與品質無關的另一條 KPI。
下一階段
從速度競賽轉向品質權衡
若為了繼續縮短時間而刪除必要的深度功能，完成率可能上升，成果價值卻下降。更合理的做法，是把耗時與完成率、品質、返工及功能覆蓋放在同一條任務 Trace 上判讀。
第二個陷阱：產品成本 ≠ 使用者感受到的成本
超過 20% 的點踩案例，同時伴隨品質好、速度快，甚至點踩後仍充值。問題不是「做得差」，而是使用者覺得這一單不值。
使用者性價比 = 產出品質 ÷ 積分消耗
產品團隊看產物
輸出是否專業、任務是否有效率、技術指標是否進步。
使用者算總帳
點數、等待、修改力氣、溝通成本，以及出錯後的心理與工作風險。
真正的問題
使用者不只問「做得好不好」，也在問「花這麼多，到底值不值」。
研究方法也要改：不要只當評測員。講者建議親自付費、帶著真實任務進賽道，再以競品完成同一任務；只有成本落在自己身上，才感受得到付費衝動、想切換與想分享的真實時刻。
02｜實戰中的三次認知升級
三次升級其實在回答同一件事：應該服務誰、用什麼單位定義成功，以及如何避免昨天正確的指標變成今天的誤導。
從一次性需求，轉向成長型任務
一次性需求目標明確、上下文少、交付邊界清楚，模型升級後容易被內化，使用者做完即走。真正能發揮 Agent 價值的是跨多場景、可累積上下文與偏好、合作成本持續下降的長期專案。
從產品交付，轉向任務閉環
早期用 PPT、文件、網頁入口要求使用者先分類需求，評估也停留在產物品質。Agent 的範圍更深更廣，標準應前移到「是否推進整體任務」，而不是「有沒有把某份 PPT 做完」。
從靜態功能判斷，轉向真實工作流
線上演示很漂亮，80%+ 使用者仍選擇匯出，原因可能是 2025 年組織尚未 AI 化、員工要向上彙報且不想暴露 AI 痕跡；到了 2026 年，HTML 展示成熟、組織加速 AI 化，線上演示重新獲得價值。不是功能突然變好，而是工作流變了。
終態參照：把 Agent 從工具看成工作夥伴
成長性
上下文累積後，單位產出價值上升，持續使用與協作成本下降，形成正向剪刀差。
邊界動態性
模型、工具與存取權限演進，會持續改寫可完成任務的範圍。
工作流嵌入性
價值不是產出一份文件，而是在真實環境中把任務推進到閉環。
短期指標是快照；終態參照才告訴團隊，Agent 應該往哪裡去。
以早期用戶行為為例：大量人購買小額 SKU、需求出現就訂閱、完成後退訂、下次再訂。這不是單純「不滿意」，而是產品被當成臨時工具。若目標是終態 Agent，核心用戶應是能持續獲益的重度使用者，而非只有一次性交付的人。
03｜六維「頂尖實習生」度量框架
框架不是一次性評分表，而是 Agent 長期工作能力的座標系。它來自一個直覺：人們判斷優秀實習生的標準，幾乎與判斷好 Agent 重疊。
能識別資訊缺口、主動取得與補充資料，最後把資訊真正用進判斷；衡量重點不是抓了多少，而是是否改變任務結果。
及格是聽懂字面；優秀是結合線索、語境與推理，理解未明說的真實意圖。例如「最近火爆的龍蝦」應推斷可能指 OpenClaw，而非真的做餐飲簡報。
記錄不等於記憶。必須經歷「記錄 → 理解穩定偏好與一次性脈絡 → 在下一任務主動應用」，而且要確實改變交付結果。
命令型需求容易完成；真正差距在祈願型需求。面對「做一份競品分析」，要先判斷分析目的，再拆成範圍、證據、維度、機會與建議。
以「做對」而非「完成」為目標。工具失敗時，替代路線必須重新驗證是否仍符合需求；不能為了完成狀態交付不可用結果。
知道何時請示、何時自主。資訊不足要指出缺口；權限不足要明說；能力不足要承認不確定並提供可驗證的下一步。
怎麼把六維框架變成可運作的評測？
每個維度都要落到可觀察的行為與結果，而不是形容詞。評測單位也要從單輪答案升級成多輪、跨任務、帶工具與限制的工作樣本。
| 維度 | 應觀察的證據 | 常見假陽性 | 較好的判定 |
|---|---|---|---|
| 基礎學識 | 缺口辨識、補充資料、引用於推理 | 搜尋很多、資料很長 | 新增資訊實際改變決策或交付 |
| 悟性理解 | 還原意圖、辨識語境、必要時確認 | 字面完全照做 | 既不腦補，也不漏掉明顯弦外之音 |
| 長記憶 | 跨任務調用穩定偏好與歷史依據 | 只把聊天記錄塞進上下文 | 記憶精準且可見地改善下一次結果 |
| 任務拆解 | 目標、路徑、證據與驗收可追蹤 | 列一份漂亮待辦清單 | 抽象需求被轉成可執行、可驗證閉環 |
| 自主糾錯 | 發現偏差、切換路徑、重新驗證 | 重試很多次就算自癒 | 修復後仍符合原需求與品質門檻 |
| 邊界自知 | 缺資訊、缺權限、缺能力時的決策 | 凡事詢問或凡事硬做 | 只影響局部可透明假設；會改變方向則停下請示 |
實務建議：把完成率、耗時、成本與六維能力放在同一條任務 Trace 上。先看是否交付，再看做對沒有、付出多少、如何修正，以及哪些能力正在跨任務成長。
04｜從實習生走向員工，還缺什麼？
目前 Agent 多半只能用使用者給的資料完成任務，無法取得第一手環境資訊，而且每次仍需被交代上下文。員工狀態則能持續沉浸在組織中，主動感知會議、專案與業務動態。
感知環境取得第一手脈絡
理解目標澄清意圖與限制
拆解任務規劃工具與路徑
交付結果端到端推進閉環
復盤變強沉澱偏好與經驗
今天的 Agent：每一步都依賴被餵資料
感知環境時需要使用者提供上下文與關聯文件；理解目標時要靠明確意圖與約束；拆解任務時依賴規劃工具與行動鏈；最後以端到端任務交付為終點，再把偏好、經驗與工作流記錄下來。它能完成閉環，但閉環通常從「有人交代」才開始。
優秀實習生：能力會沿著工作鏈逐步放大
剛進場也需要專案背景與交接材料，卻會追問「到底要什麼」、自己排步驟並拆解執行路徑；完成工作後，還會把經驗帶進下一次任務。隨著脈絡與責任累積，可承接的範圍會越來越大，這才是終態 Agent 應追求的工作能力。
因此，評測不能只看一次任務有沒有完成。還要觀察 Agent 是否逐次減少對人工交接的依賴、能否主動取得環境資訊、是否更準確地還原目標，以及復盤後能不能在下一次任務中承擔更大的範圍。
不要依賴單一指標完成率好看不等於 Agent 好用；單一數字只解釋局部，無法判斷方向。
不要忽視心理成本品質好、速度快仍可能「不值得」；成本感知會直接影響復購與長期關係。
不要用靜態指標量動態邊界今天有效的指標，明天可能只剩解釋次要問題；要持續把失敗需求與新能力重新入池。
度量的目的，不是替 Agent 打分；而是讓產品團隊持續知道：它更懂人了嗎？更能把工作往前推了嗎？更清楚自己做不到什麼了嗎？
PM 可直接帶走的操作清單
01
先定終態
寫下理想 Agent 的成長性、動態邊界與工作流位置，作為指標取捨的北極星。
02
再畫任務 Trace
把完成、耗時、成本、品質、重試、請示與結果串回同一個真實任務。
03
建立遷移池
保存「過去失敗但持續被嘗試」的需求；每逢模型、工具或權限升級就重測。
04
親自付費使用
帶真實專案跑自己與競品，記錄付費、想切換、想分享三個關鍵時刻。
Audio deep dive
Podcast｜如何打造好的 Agent 度量框架
NotebookLM 繁體中文深度對談
從成功定義、離線與線上評估到常見指標陷阱，建立可迭代的度量閉環。
雙人對談 · 繁體中文