門店服務漏接感知 Agent

2026 Agentic AI on the Edge 黑客松決賽作品說明。隊伍：老闆好痛。實證場域：自家的拉麵店（台北市文山區），實際營業中。內容更新到 2026-10-22，數字都是在真實營業的店裡量的，每一節標了出處文件。

一句話

在店裡既有的監視器上，加一層不用 AI 模型的影像算法整天守著；有可疑狀況時，才叫醒關在沙箱裡的 Nemotron Agent，讓它查 POS、查現場訊號，再決定要不要通知人。

它盯的是「客人有沒有被照顧到」，不是「哪個員工在偷懶」。老闆接到客訴時，也可以打一句話問它，它會從一整天的紀錄裡找出那一刻。

整套系統 10-21 在主辦現場的 DGX Spark 上裝好、跑通：模型、沙箱、即時判定、看片網頁都在這台機器上。

出處：企劃書草稿、交接-2026-10-21、部署-2026-10-21

評分項對照

這張表照主辦的評分項排列。「證據」欄的數字都是實測，括號裡是出處文件。

第一階段企劃書評分

第二階段決賽評分要件

NeMo 框架我們用的是 NeMo Guardrails。工具迴圈是自己寫的，沒有用 NeMo Agent Toolkit。Jetson 沒有測過；NVFP4 需要 Blackwell 架構，Orin 跑不了。

Agent 的四項能力：真實發生的例子

主辦列的四項能力，每一項舉一個系統裡真的發生過、有紀錄的例子。

誠實的一點：模型這一半不穩定。同一筆候選，重啟後有時不呼叫 notify、只把分級寫在文字裡，分級也會在店長和前場之間變。詳見〈已知限制〉。

用了哪些技術

模型是 VL（看圖）版本，但回查層和客訴 agent 只送給它文字和數字。原本讓它看畫面判斷「有沒有人招呼客人」的那一層，兩次驗證都沒通過（招呼判定和亂猜差不多），所以第一版沒有啟用。

出處：企劃書草稿第 7–9 頁、測試報告、部署-2026-10-21

系統架構與資訊流

結論：影像只在最前面那一段。從常駐層往後，模型和工具看到的只有數字、時刻和文字。一張影格有三條路：回查層（有候選才跑）、每日摘要（一天一次，給網頁和客訴 agent）、即時（影格一進來就判定）。三條路用的是同一套判定程式。

flowchart TD
  subgraph STORE["店裡 既有設備 不改動"]
    CAM["既有監視器 四路"] --> DVR["既有 DVR 快照網址 352x240"]
    POS["POS 結帳紀錄 匯出檔"]
  end
  subgraph REC["錄影主機 DGX Spark"]
    ING["每 0.4 秒取一張"] --> ENC["加密後才寫硬碟"]
    ENC --> DIG["每日摘要 常駐層算法"]
  end
  subgraph SITE["現場 DGX Spark"]
    LIVE["即時判定 無網路容器 常駐層算法"]
    WEB["看片網頁 要登入 有期限"]
    subgraph SB["NemoClaw OpenShell 沙箱 零外部端點"]
      RES["常駐層找候選"] --> TRI["回查層 Agent"]
      CA["客訴 agent"]
    end
    LLM["vLLM 加 Nemotron Nano 12B v2 VL NVFP4"]
    GR["NeMo Guardrails"]
    TIER["分級 前場 店長等確認 只記錄"]
  end
  KEY["金鑰 只在記憶體"]
  DVR --> ING
  ENC -- "加密影格 唯讀拉取" --> LIVE
  ENC -- "加密影格" --> RES
  DIG -- "數字和遮過頭的縮圖" --> WEB
  DIG -- "數字" --> CA
  POS --> TRI
  POS --> CA
  LIVE -- "警示 遮過頭的畫面" --> WEB
  WEB -- "老闆打的一句客訴" --> CA
  CA -- "結論 附相關照片" --> WEB
  TRI -- "受控推論路徑" --> LLM
  CA -- "受控推論路徑" --> LLM
  TRI -- "notify" --> GR --> TIER
  KEY -.-> ENC
  KEY -.-> LIVE
  KEY -.-> RES

三條路

1. 回查層：常駐層在吧台畫面上找到候選（客人在結帳區超過 30 秒、收銀機前沒有店員），把候選的描述交給回查層 Agent。Agent 呼叫工具查 POS、桌況、現場訊號，最後經 notify 選一個固定句型和分級。提醒先過護欄，再分級。決賽 demo 用 9/13 那段的加密影格，傳進沙箱裡跑。
2. 每日摘要：在錄影主機上每天跑一次，產出一天的事件、候選、收桌、POS 和遮過頭的縮圖。看片網頁的日曆和單日頁、客訴 agent 的查詢，都讀這份摘要。客訴 agent 不碰影格，也不需要金鑰。
3. 即時：現場 Spark 每 2 秒從錄影主機拉一次新的加密影格（只能唯讀拉取），在沒有網路的容器裡解開、判定。滿 30 秒、收銀機前沒有店員，就跳一行警示。警示是規則判的，不經模型。

一筆候選進來之後（回查層）

sequenceDiagram
  participant C as 常駐層
  participant A as 回查層 Agent
  participant T as 工具
  participant G as 護欄
  participant P as 人
  C->>A: 候選 9/13 11:00:55 客人 132 秒 店員 p90 0.042
  A->>T: query_pos 查這 3 分鐘的結帳
  T-->>A: 1 張內用單
  A->>T: audit 寫下判斷理由
  A->>T: detect_entry 再查現場訊號
  T-->>A: 客人區動態可信
  A->>T: notify 店長級 固定句型
  T->>G: 檢查句子
  G-->>T: 放行
  T-->>P: 待人工確認 不自動送出

出處：企劃書草稿第 4 頁（9/13 逐字軌跡）、系統架構與資料流-2026-09-19、交接-2026-10-21

資料不落地：哪些離開、哪些不離開

結論：原始影格在硬碟上只有密文，解密金鑰不寫在任何一台 Spark 的硬碟上。模型和工具只拿到數字和時刻。但網頁上的照片是遮過頭的明文 JPEG，遮臉會漏，所以網頁一定要登入、有期限。

邊界：我們不說的話

下面這幾句我們不說，因為它們不成立：

• 「沒有任何影像離開」：網頁有遮過頭的縮圖和即時畫面。
• 「所有照片都已遮臉」「已去識別化」：青蛙會漏。9/20 那組照片裡就有清楚的臉沒遮到。
• 「機器上的照片都已加密」：只有原始影格是加密的，縮圖和即時畫面是明文。
• 「資料只在店內這台機器上」：見下面這一條。

開發期的錄影主機是一台借來的 DGX Spark，放在店外的機房，不在店裡。影格從店裡的監視器主機取來，加密後才寫進它的硬碟。設計上這台應該放在店裡；這一步還沒有在店內實裝。加密防的是有人翻硬碟，防不了有人在程式執行時讀記憶體。

出處：交接-2026-10-21〈晚間追記〉（網頁文字哪些成立）、測試報告第二節、README

為什麼放在邊緣、為什麼舊設備就夠

為什麼放在邊緣

延續舊設備就能用

結論：不換攝影機、不加感測器。常駐層只要每秒兩三張低解析度畫面，用很少的運算。

• 直接接店裡現有的監視器主機（DVR）。它沒有開串流，所以每 0.4 秒向它的快照網址要一張 JPEG，352×240 像素，四路各每秒 2.5 張。快照也省掉了影片解碼。
• 常駐層不用 AI 模型，是實測後的選擇。我們先試了 NVIDIA 的 PeopleNet 人物偵測模型：俯拍角度下不可靠（空桌也有 0.146 的底噪），而且四路跑 CPU 時每路只有每秒 1 張，跟不上取流。改用不需要人物偵測的影像算法之後：

CPU 成本差約 385 倍。模型叫醒幾次，由事件數決定，不由影格數決定：9/13 全天 71,817 張影格 → 43 個事件 → 7 個候選。

出處：測試報告第三、五節；企劃書草稿第 7、8 頁（記憶體 334 MB 是 9/21 含吧台背景相減重量的數字）

回查層 Agent

結論：模型決定查什麼、查幾次、選哪一級；程式決定它能做什麼、什麼時候算失敗。

五個工具

迴圈怎麼判斷失敗

flowchart TD
  Q["候選加五個工具說明"] --> A{"模型這一輪回什麼"}
  A -- "工具呼叫" --> T["執行 結果加進對話"]
  A -- "純文字" --> U{"開頭是工具名接括號"}
  U -- "是" --> X1["降級 工具呼叫沒被解析"]
  U -- "否" --> OK["結論"]
  T --> P{"連續兩輪都沒成功"}
  P -- "是" --> X2["降級 沒有進展 安全中止"]
  P -- "否" --> R{"滿 6 輪"}
  R -- "是" --> X3["降級 輪數用完 不編結論"]
  R -- "否" --> A

• 溫度 0，最多 6 輪。
• 模型有時把工具呼叫寫成純文字，伺服器解析不到，看起來像「給了結論」。9/18 七筆裡有六筆是這樣。現在這種回答算失敗，不算結論。
• 任何一層失敗，都退回「只偵測、只記錄」，並在軌跡上標降級。

提醒與護欄

三個固定句型：「有客人進來了」「{桌} 桌等很久了，已經 {分鐘} 分鐘」「今天漏接 {次數} 次，集中在 {時段}…」。參數多一個、少一個都拒絕。句型合法不代表內容合規（欄位是模型填的），所以送出前再過 NeMo Guardrails。護欄在分級之前跑：店長級雖然只是掛起來，掛起來的內容一樣會被人看到。

10-21 現場四次 demo

四次都抓到同一筆：11:00:55–11:03:07，客人 132 秒，收銀機前店員訊號的第 90 百分位數 0.042，POS 證實晚結帳。不用模型的那一半，換到第三台機器，數字一個都沒變；用模型的那一半，重啟就會變。

出處：src/agent/loop.py、notify.py、guard.py；部署-2026-10-21 第六節；硬體測試報告-2026-10-13

客訴 agent 與規則試玩

結論：日期、時段、客訴類型用規則判，不交給模型。模型只決定查哪幾樣、怎麼寫結論。它在沙箱裡，只有四個唯讀的查詢工具，加上寫軌跡的 audit。

flowchart TD
  Q["老闆打的一句話"] --> S1{"規則 擋注入 擋離題"}
  S1 -- "擋下" --> B1["回說明 記一筆軌跡 不送模型"]
  S1 -- "通過" --> W["抓日期和時段"]
  W --> D{"有日期 也有這天的摘要"}
  D -- "否" --> NEED["請老闆補日期 不猜"]
  D -- "是" --> K["判客訴類型"]
  K --> H["提示加一行 先用哪個工具"]
  H --> L["模型 最多 6 輪 溫度 0"]
  L --> T["query_bar longest_visits query_tables query_pos audit"]
  T --> L
  L --> S2{"回答裡有程式碼"}
  S2 -- "有" --> B2["不給老闆看"]
  S2 -- "沒有" --> OUT["三段結論 附相關照片"]

為什麼用規則判

• 日期：模型會編時間。查錯一天就整個答錯，而這一步規則就做得到。抓不到日期就請老闆補。
• 類型決定查法：糾紛（態度、集點、付款）要找「客人在櫃台待最久」，等待要找「收銀機前沒有店員」，桌子沒收要查桌況。「結帳時很兇」是糾紛，不是等待，所以糾紛先比對。
• 擋輸入、擋輸出：送進模型前，用正規表示式擋「要求系統做別的事」和離題；回答裡有程式碼就不給老闆看。這是基本款，換個說法還是可能漏。

結論的格式

固定三段：【查到的】只能引用工具回傳的時刻和數字；【判斷】；【查不到的】寫出資料看不到的部分（態度、講了什麼、會員、集點、餐點品質）。不指名、不評價任何員工。

修掉的兩個錯

拿 9/20 那則真實負評測，抓到兩個錯。兩個都是改工具和規則修好的，不是靠提示詞求模型。

驗過的題目

都經「網頁 → 沙箱」。第一次問約 30 秒（模型暖機）。

出處：src/agent/complaint.py、bench/complaint.py；交接-2026-10-21 第 4 節；工作日誌-2026-10-21 第五節

9/20 那則客訴：28 秒找到

結論：9/20 吧台 9.5 小時、71,815 張加密影格，28.08 秒交出 4 個時刻，要找的那一次就在裡面。一個月後換一支程式重跑，4 筆數字完全一樣。

那天晚上約 20:41，Google 上出現一則 1 顆星評論：客人想用集點兌換飲料，店員要他反覆刷退 LINE 付款才換得到。老闆想知道當時櫃台發生什麼事。

當晚怎麼找到的

在錄影主機上找「客人在結帳區連續 120 秒以上」的時段。只輸出數字和時刻。

店家看畫面確認：19:59–20:05 那一組（後兩筆，中間只斷 31 秒）就是這則評論。畫面裡客人低頭反覆操作手機。20:05 結束，37 分鐘後貼出評論。

10-21 從看片網頁問客訴 agent

sequenceDiagram
  participant B as 老闆
  participant W as 看片網頁
  participant R as 規則
  participant M as 模型 沙箱內
  participant T as 工具
  B->>W: 9/20 集點換飲料被刁難
  W->>R: 擋輸入 抓日期 判類型
  R-->>W: 日期 9/20 類型 糾紛
  W->>M: 客訴加系統判讀 先用 longest_visits
  M->>T: longest_visits
  T-->>M: 第一名 19:59:35 到 20:04:58 323 秒 店員在場 100%
  M->>T: audit
  M-->>W: 三段結論 附相關照片
  W-->>B: 約 20 秒

最有意思的地方：那 5 分鐘裡店員全程在櫃台。系統找出來的是「客人卡在哪」，不是「誰偷懶」。該改的是集點流程和公告。這也是「收銀機前沒有店員」那一套查不到它的原因。

講這個數字時要準的地方

• 樣本只有 1 筆，不能說召回率 100%。
• 4 個裡另外 3 個不是這則客訴。回頭找只怕漏掉，不怕多看幾段；當下的提醒怕誤報。兩者的處置權限不同。
• 28 秒是在錄影主機上量的，不是現場 Spark。
• 「店員在場」是收銀機前那一小塊的訊號，看得出有沒有人，看不出在做什麼。

出處：決賽簡報素材-2026-10-22 第一到六節；原始紀錄 bar-誤報核對-2026-09-20 第七節

邊緣實測數字

量化前後

NVFP4 的延遲：8 張真實營業影格，在共用機上 4.64 秒（10 次）；10-13 在主辦的機器上獨占重量，4.34 秒（30 次）。早期用測試影像量的延遲比真實影格低很多，不引用。

速度、記憶體、斷網

斷網有三種保證，來源不同：沙箱外是程式自己攔截連線；沙箱內是 OpenShell 的政策代理照白名單擋；即時判定是容器根本沒有網路。沙箱和斷網的驗收都是我們自己跑、自己記的，沒有第三方驗證。

已知限制

1. 模型的判斷不穩定。同一筆候選，重啟後有時不呼叫 notify、只把分級寫在文字裡；分級會在店長和前場之間變。前場是不經人確認就送出的那一級。原因沒有驗證。
2. 有一種無聲失效還沒攔。模型把 notify 寫成純文字放在結論的結尾，程式只檢查開頭，會當成正常結論收下。
3. 遮臉會漏。俯拍鏡頭上，抓臉和姿勢模型都不能當隱私保護。所以網頁要登入、有期限，不對外說「已去識別化」。
4. 結帳區的候選不準。人工核對 10 筆：4 筆候選都不是客人在等（框裡有吧台座位）；6 筆 POS 證實的久候，收銀機前都有店員。所以候選只當線索、由人確認，不直接提醒。
5. 驗證樣本小。9/20 那則只有 1 筆；客訴 agent 驗過 3 題；回查層的結論對不對，沒有系統性驗證。
6. 桌況只涵蓋 A、B 兩張四人桌。
7. 模型寫的文字，只有 notify 的句子過護欄。軌跡和客訴結論只有基本的規則檢查。
8. 只在一家店、DGX Spark 上驗證過。NVFP4 需要 Blackwell 架構，Orin 這類機器跑不了；Jetson 沒有測過。
9. 開發期的錄影主機不在店裡（見〈資料不落地〉）。即時警示只顯示在網頁上，沒有接到店裡的裝置。

出處：交接-2026-10-21〈還沒決定的〉、工作日誌-2026-10-21〈未解決〉、部署-2026-10-21 第八節

用詞表

這一頁的每一個詞都照這張表的意思用。

評審最可能問的問題

點開看答案。答案都照實測和文件，沒驗過的直接說。