這支影片在講：Developer Relations 沒死，只是 agent 也成了使用者
當 AI agent 會搜尋工具、讀文件、呼叫 API、踩到錯誤並向人推薦產品，開發者關係的工作不再只是「被找到」；而是把 agent 的實際任務路徑變成可量測、可改善的產品體驗。
搜尋排名看不到採用摩擦
問 agent「比較 code intelligence 工具」會提到 Sourcegraph；描述「改 shared library 會不會弄壞下游服務」卻沒有。購物語言和受傷語言之間有一段看不見的落差。
Agent 同時是使用者與推薦者
它會讀 docs、打 API、遇到錯誤並形成建議。這使 developer experience 直接進入 agent 的工具選擇與人類的採購路徑。
跑任務、讀 trace、縮短距離
以數百個 lifecycle 任務 benchmark 有無工具的表現，再從 trace 找到模糊描述、陳舊內容和多餘步驟，逐一收斂。
影片中最重要的四個訊號
把 developer relations 改成 agent experience 的三個轉向
從「是否被提到」改問「能否解決正在發生的痛」
泛用比較 prompt 容易出現在答案裡，卻未必能連到真實工作情境。應蒐集使用者自己的任務敘述，測試 agent 是否能把痛點、工具能力與正確的下一步接起來。
從成功率改看成功的 token 與延遲成本
對 agent 買家而言，「能不能用」不夠；每一次猜錯、recover 或繞路都會消耗 token 和時間。產品文件與錯誤訊息因此成為成本結構的一部分。
從內容行銷改成可觀測的採用路徑
把 agent trace 當成使用研究：它怎麼理解工具、在哪個參數卡住、如何從錯誤回復。每個 trace 都能指出應改善的描述、範例、registry 入口或 onboarding 摩擦。
不要只把文件寫得更長；要讓 agent 下一步更明確
trace 裡 agent 假設了不存在的參數名。更清楚地說明輸入、適用時機和失敗條件，就可能省下一次呼叫與一次 recovery。
agent 會吸收 docs、API 回應與網路內容；過期資訊不只是舊頁面，而會持續污染它後續的建議與操作。
MCP registry 與可被工具讀取的入口，是 agent 的 distribution surface；讓發現、理解、試用之間少一層人工轉譯。
清楚的錯誤、短的採用路徑與可驗證範例，對 agent 有用，也會讓新進開發者更快成功。
若你的產品想被 agent 正確採用，先做這五件事
原影片與章節
0:00 背景 · 4:19 agent 是使用者與推薦者 · 5:36 有無工具的 benchmark · 7:42 65%→0% 的發現落差 · 10:29 陳舊內容會複利 · 12:12 registry 與採用摩擦 · YouTube 原始影片