The Agent Observability Stack: Watching Your Invisible Workforce
你有冇試過開咗五個 Claude Code session，然後喺 terminal 之間 Alt-Tab 到头晕，仲分唔清邊個 agent 做緊咩？或者更恐怖嘅：你以為某個 agent 做完嘢，結果佢早就好咗，白白烧咗兩個鐘 token？
呢個就係 2026 年 AI 開發者嘅日常困境。Agent 越開越多，但監控仲停留喺「自己睇 terminal」嘅階段。就好似你請咗十個員工，但冇打卡系統、冇日報、冇 KPI——你點知邊個偷懶、邊個做緊無用功、邊個等緊你嘅 permission 但你唔知？
呢篇文章想講嘅係：Agent observability 已經唔係一個 nice-to-have 嘅功能，而係你嘅 agent infrastructure 嘅底層基建。 從 pixtuoid 嘅 pixel-art 辦公室，到 amux 嘅 web dashboard，到 happy-next 嘅手機 remote control，我哋見證緊一個新工具品類嘅誕生。
點解 Agent Observability 突然變咗刚需？
兩年前，你可能只係開一個 Claude Code session 做嘢。一個 agent，一個 terminal，夠晒用。但而家呢？你可能同時跑緊：一個 agent 做 refactoring、一個做 test generation、一個做 code review、一個做 documentation——仲有一個喺 background 跑 migration。
問題嚟啦。呢啲 agent 唔會自己同你匯報進度。佢哋唔會話「我做到一半，仲需要多 15 分鐘」，或者「我卡住咗，等你 approve 個 permission prompt」。你唯一嘅選擇係不斷 Alt-Tab 去 check——但當你有八個 session 嘅時候，呢個做法根本唔 scale。
更深层嘅問題係：Agent 嘅行為係 non-deterministic。 同一個 prompt，可能 run 兩分鐘就搞掂，可能 run 廿分鐘都未完。你冇辦法靠估，只能靠睇。而「睇」嘅工具，就係 observability stack。
呢個需求其實唔新。Server 有 Datadog，前端有 Sentry，mobile 有 Firebase Crashlytics。但 Agent 嘅 observability 仲係一片荒蕪——因為呢個品類太新，仲冇人define清楚佢應該包含咩。
三個路徑，三種哲學
有趣嘅係，唔同嘅開發者用唔同嘅方式解決同一個問題。我哋可以從三個開源項目睇到三種截然不同嘅 approach。
pixtuoid：情感化嘅視覺監控
pixtuoid 嘅做法最有趣——佢將每個 agent session 變成一個 pixel-art 嘅辦公室角色。你打開 terminal，就會見到一個微型辦公室：有 desk、有椅、有 pantry、有 pet。每個 agent 係一個角色，坐喺自己嘅 desk 度做嘢。
最正嘅係佢嘅狀態表達方式：agent 做緊嘢嘅時候會打字、等 permission 嘅時候會舉 ?、做完嘢會瞓覺。你可以一眼就睇晒所有 agent 嘅狀態——唔使讀 log，唔使 Alt-Tab，淨係望一眼個 pixel 辦公室就知邊個忙、邊個閒、邊個卡住。
呢個 approach 嘅核心 insight 係：人腦處理視覺信息遠快過文字。 當你有十個 agent 同時跑緊，一個 dashboard 再詳細都唔夠一個一目了然嘅視覺化有用。pixtuoid 用咗 Black Mirror 同 The Sims 嘅美學，將枯燥嘅 log 變成一個你會想睇嘅畫面。
佢仲有一個 token meter 功能——每個 desk 上面嘅紙堆會隨住 token 消耗而疊高，250K、2M、16M 三個 tier。你唔使開 calculator 就知邊個 session 燒緊最多錢。
amux：操作系統級嘅控制平面
amux 嘅 approach 完全唔同——佢想做嘅唔止係監控，而係成個 agent 嘅操作系統。
amux 嘅核心係一個 kanban board。每個 agent session 係一個 card，有 status gate（todo → doing → done → verified），有 scheduler（cron-style 嘅排程），有 inter-worker messaging（agent 之間可以溝通），有 per-scope memory（唔同 agent 可以有唔同嘅記憶同 knowledge）。
呢個 design 嘅哲學係：Agent 唔止需要被睇住，仲需要被管理。 當你有十個 agent 跑緊唔同嘅任務，你需要一個中央系統去排程、去分配資源、去處理 agent 之間嘅依賴關係。amux 嘅 board system 就係為咗解決呢個問題。
佢仲有一個好正嘅功能叫 .mdai——computed markdown file。你可以將唔同嘅文件同 agent 輸出串連成一個 DAG（directed acyclic graph），每次 open 個 node 就會自動跑晒成個 chain。呢個其實係將 agent 嘅輸出當成 infrastructure 嘅一部分，而不只係一個 chat response。
amux 仲有 iOS app，你可以喺 phone 上面 control 你嘅 agent。呢個解決咗一個好實際嘅痛點：你出街嘅時候，仲想唔想 monitor 你嘅 agent？
happy-next：手機 remote control
happy-next 嘅 approach 最直接——佢想做嘅就係「用 phone remote control 你嘅 coding agent」。
你電腦上面跑 happy 而唔係 claude，然後 scan 個 QR code，就可以喺 phone 上面控制你嘅 agent。push notification 會話你知幾時需要 attention，voice assistant 可以用聲控制 agent，code browser 可以直接喺 phone 上面睇 diff、stage files、commit。
happy-next 嘅 insight 係：DevOps 嘅核心問題從來唔係「點 run」，而係「點 control」。 我哋唔需要更多嘅 agent，我哋需要更好嘅 control plane。而最好嘅 control plane 唔係喺你嘅 laptop 上面——而係喺你嘅 hand 上面。
佢仲有 E2E encryption，確保你嘅 code 同 prompt 唔會被 intercept。呢個對於處理 sensitive codebase 嘅開發者嚟講係 essential feature。
觀察：一個新品類嘅誕生
從呢三個項目我哋可以睇到幾個有趣嘅趨勢。
第一，Agent observability 正在從「日誌」進化到「界面」。 早期嘅 agent 監控只係 log file，但而家已經進化到有視覺化 dashboard、有 kanban board、有 mobile app。呢個其實係重複咗 Server Monitoring 嘅進化路徑——從 syslog 到 Datadog 到 Grafana。
第二，「狀態表達」比「數據展示」更重要。 pixtuoid 嘅成功唔係因為佢 display 咗更多 data，而係因為佢將 data 變成咗一個你一眼就明白嘅 visual metaphor。呢個 insight 對所有 dashboard design 都適用。
第三，Mobile-first 嘅 agent control 會成為標準。 amux 同 happy-next 都有 iOS app，因為開發者唔係 24 小時坐喺 desk 前面。你需要喺 phone 上面 approve 個 permission prompt，或者 check 個 agent 係咪仲跑緊。
第四，Agent 之間嘅 coordination 需要 infrastructure-level 嘅支持。 amux 嘅 board system 同 happy-next 嘅 orchestrator 都係為咗解決呢個問題。當你有十個 agent 同時做嘢，你需要一個中央系統去管理佢哋嘅依賴關係同資源分配。
實建議：點樣開始建立你嘅 Agent Observability Stack
如果你而家仲係用「開幾個 terminal Alt-Tab」嘅方式管理你嘅 agent，以下係一啲具體嘅建議：
第一步，揀一個可視化工具。 如果你鍾意 terminal-based 嘅 solution，試下 pixtuoid。佢安裝簡單（brew install pixtuoid），而且視覺反饋即時。如果你需要更全面嘅 orchestration，amux 嘅 board system 可能更啱你。
第二步，建立一個 notification system。 無論你用邊個工具，確保你會收到 agent 需要 attention 嘅通知。happy-next 嘅 push notification 係一個好嘅開始。
第三步，開始 track token 消耗。 唔係為咗 pinching penny，而係為咗了解你嘅 agent workflow 嘅 cost profile。邊個 task 係最貴嘅？邊個 agent 係最 efficient 嘅？呢啲 data 會幫你 optimize 你嘅 workflow。
第四步，考慮 mobile access。 你唔係 24 小時坐喺 desk 前面。確保你可以喺 phone 上面 monitor 同 control 你嘅 agent。
第五步，將 observability 當成 infrastructure 嘅一部分，而唔係事後補充。 就好似你唔會 run 一個 server without monitoring，你都唔應該 run agent without observability。
Agent 嘅時代已經嚟咗。但好多開發者仲係用緊「人肉監控」嘅方式管理佢哋嘅 agent。呢個 gap 就係機會——無論你係想 build 一個 observability tool，定係想 improve 你嘅 workflow，而家就係時候 invest in 你嘅 agent monitoring infrastructure。
因為當你嘅 invisible workforce 越來越多嘅時候，你就會發現：看得見，先管得好。