AI Engineer onepage/ Agent Ops
Raphael Kalandadze, Wandero AI · 19:31
這支影片在講：Agent 上線後缺的營運層
Demo 能跑不代表 production agent 健康。Raphael Kalandadze 把問題拆成一個「meta harness」：用 agent 監看真實對話、分析 logs、寫 PR、審 PR、掃 session health，讓系統在上線後持續找到隱性失敗。
Published: 2026-07-05Video ID: kZsf_Sfm7RU
01 / 問題
失敗不會亮紅燈
Agent 可能完成流程、回傳答案、dashboard 看起來正常，但其實漏掉限制、算錯價格，或用幸運 workaround 撐過去。
02 / 反轉
Unit test 只看一片切面
非 deterministic、對話覆蓋無限、工具路徑變動大。很多該測什麼，只有 production 之後才會知道。
03 / 解法
用 agent 維運 agent
一組營運 agent 讀 logs、看 trajectories、分析 session、模擬使用者，再把問題轉成 PR、review 與 alert。
Watch for this
影片最值得抓的四個訊號
Production load
100s-1000s
要跨越數百到數千場真實對話看健康度，抽樣人工檢查不夠。
Code speed
100k lines
現在幾天到幾週就能堆出大量程式，上線後的迴路反而變核心。
Fast loop
15m-1h
Log monitoring agent 可每 15 分鐘或每小時跑一次，抓局部故障並送 PR / Slack alert。
Human load
10x PRs
PR agent 與 review agent 每天產出比三人團隊多十倍，必須重新設計審核邊界。
Core story
上線後最容易被低估的三個缺口
缺 1
你會失去對系統的手感
傳統軟體有比較固定的功能與流程；agent 面對的是開放式任務。使用者怎麼問、模型怎麼走、工具怎麼呼叫，都不可能在上線前完整列舉。
缺 2
「完成」不等於真的幫到使用者
影片舉旅遊 itinerary 的例子：流程跑完、行程產出，看似成功；但如果服務選錯、價格算錯，使用者仍然失敗。這種錯通常不會變成紅色 error。
缺 3
營運 agent 本身也要被校準
把 logs 丟給 agent 很直覺，但它需要判斷 bug 還是 noise、症狀還是 root cause。這套 loop 要花時間校準，才值得信任。
Operating loop
Wandero 的 agent ops 架構長這樣
Log monitoring agent讀 trajectories、logs 與 codebase，找出使用者是否卡住，判斷問題是否需要 PR 或 Slack alert。適合快速修局部問題。
PR + review agent一個 agent 診斷並開 PR，另一個用 fresh context 批判性 review、跑 focused tests、要求修改或關掉不可靠修補。
Session analyzer不是修單點 bug，而是替每段 conversation 打分，產出 health score、success rate、趨勢、AI insights、affected sessions 與建議修法。
Computer-use agent從使用者視角打開網站、登入、送訊息、檢查 UI 與 artifacts。當 code / logs 看不到前端體驗問題時，這層補上真實操作視角。
Chapters
章節脈絡
上線不是結束，而是工作開始影片從幾個 production 問題切入：怎麼知道 agent 真的運作？怎麼跨大量對話看健康？怎麼找未知洞？
為什麼 agent 比傳統軟體難維運非 deterministic、coverage endless、工具面巨大，讓 unit tests、regex、模擬腳本都只能覆蓋局部。
把營運交給 agent 做用 traces、trajectories 與 codebase 診斷問題、開 PR，再交給獨立 review agent 檢查 root cause 與風險。
兩種主要 flow：快修與鳥瞰第一層每 15 分鐘到每小時抓局部故障；第二層用 session analyzer 看整體健康與模式。
Session analyzer 看每段對話分析 score、success rate、tool calls、sub-agents、summary 次數、sentiment 與 session 細節，找高層次模式。
補上使用者視角Computer-use agent 透過 browser / DOM / 專用 skill 模擬客戶操作，檢查 UI 與 artifacts 是否真的可用。
Meta harness 是新的工程層模型本身不夠，還要把 trajectories、metrics、DB、UI 與工具接起來，讓系統能 watch itself、understand、improve。
Use this checklist
如果你正在做 production agent，先檢查這五點
你有沒有看「真實對話」而不是只看 logs？很多失敗發生在 conversation quality，不會變成 stack trace。要能判斷使用者是否真的達成目標。
你能不能把幸運 recovery 當成早期警訊？Agent 靠 workaround 撐過去時，dashboard 可能全綠，但那通常代表底層能力或工具流程有洞。
你的修補 agent 有沒有獨立 review agent？開 PR 的 agent 很容易急著修；review agent 要用不同角度檢查是否真的修 root cause，而不是只蓋掉症狀。
你有沒有分開「快修」與「健康度分析」？每小時抓 bug 和每週看整體 session patterns 是不同任務，不應該塞進同一個粗糙 dashboard。
你願意讓人先成為 bottleneck 嗎？講者的建議是先把 loop close 起來，就算人類仍在 merge / approval 邊界；等瓶頸清楚後，再決定哪些邊界可自動化。
Source video