NeMo Agent Toolkit HITL + por_to_jiratickets 完整指南：中小企業「AI 不敢全自動就把人放回去」需求審批採購 5 個訊號

你確定全自動的 AI 才是先進嗎？2026 年最會省錢的 AI 系統，反而是讓人類在關鍵節點重新拿回方向盤的那種。

最近我們在自己的開發流程裡發現一件事——客戶問「我想要一個 AI 幫我做 X」時，最後真的能上線的，幾乎全部都長同一個樣子：「AI 跑前面 80%、人在最關鍵那一步按 yes / no」的設計。完全沒人留在迴圈裡的全自動版反而上線後撐不過 30 天。我們公司自己每天就在跑 20+ 個 AI 流程，會留下來的也都是這種。

有一個數字很值得注意——根據 Gartner 2025-08 預測，到 2026 年底，40% 的企業應用程式會嵌入 task-specific AI agents（2025 年僅 < 5%）；但 Gartner 同時警告「40% 的 agentic AI 專案會在 2027 年底前被取消」，而 Hacker News 2026-05 報導 的數據更直白——80.9% 的技術團隊已經把 agent 推進測試或生產，但只有 14.4% 是完整通過資安與 IT 審批上線的。落差不在於「AI 不夠強」，而在於「沒有把人留在迴圈裡」。

這篇講的東西就是補上那個缺口。NVIDIA 在 2025 年底開源、2026 上半年快速更新的 NeMo Agent Toolkit（前身 NVIDIA Agent Intelligence Toolkit），把 HITL（Human-in-the-Loop）做成一個 framework-agnostic 的原語——你不用改 agent 程式碼，只要把 hitl_approval_function 接到任何工具呼叫前面，AI 跑到那一步就會停下來等人類按 yes。用 por_to_jiratickets 跟 simple_calculator_hitl 兩個官方範例，就能拼出中小企業 80% 的「需求單審批 / 合規關卡 / 客服回應前先讓人確認」需求。

接下來會帶你看 5 個訊號——如果你公司中了任何 2 個，HITL agent 比全自動 agent 更值得做；然後拆 NeMo Agent Toolkit 的 HITL 怎麼設計、何時觸發、給合規 / 客服 / 採購誰看；最後給一份決策表，讓你判斷「自己接 HITL」還是「直接外包」更划算。

自我檢測：5 個訊號告訴你「該做 HITL agent、不是全自動 agent」

先不講技術。我們把客戶問「AI 要不要全自動」時，會直接反問的 5 個問題列出來——中了 2 個以上，就該走 HITL 設計（人在迴圈裡），不要硬塞全自動。

訊號 1：AI 做錯一次，外部會有人付出代價

客服 AI 對客戶說錯了話、採購 AI 真的下了單、合規 AI 漏了一張發票——這些「對外發生」的決定，全自動 = 出事就是真的出事。中小企業沒有大型法務團隊兜底，這類流程 HITL 是底線。實務上的觀察：「會引起客訴、會牽涉合約、會動到錢」的這三類流程，老闆問「能不能全自動」99% 的時候答案是不能，但 AI 可以把工作做完 80%、留最後一道按鈕給人。

訊號 2：法規或內規要求「決定要可追溯、要有人簽字」

台灣《人工智慧基本法》2026 年 1 月已上路、EU AI Act Annex III 高風險 AI 強制 human oversight 條款 2026-08-02 生效。如果你做的是金融、醫療、人資、教育、客服紀錄，「AI 做了 → 沒有人簽字」基本上就是違規。HITL 對這類產業已經是硬性合規義務，不再是錦上添花。

訊號 3：AI 容易在這個流程裡出幻覺、但你又看不出來

「AI 把 PRD 拆成 Jira ticket」、「AI 從文件抽合約條款」、「AI 用客戶資料寫郵件」——這類「輸入是 free-form 文字、輸出是結構化動作」的工作，幻覺率比想像中高。我們在公司內部跑的 PRD-to-Jira 自動化流程也走過這條路。最早是全自動，跑了兩週發現大概 1/15 的 ticket 會把 epic 拆成完全不存在的 sub-task（AI 自己腦補需求）。後來改成 NeMo Agent Toolkit 的 por_to_jiratickets 風格——AI 把候選 ticket 列出來、PM 看一眼按 approve / reject 才真的進 Jira。錯誤率掉到 0，PM 也只多花了原本估的 5% 時間。

訊號 4：流程「決策成本 vs 操作成本」差距 100 倍以上

有些工作是「判斷只要 5 秒，但收集資料、排版、寫文要 30 分鐘」——這種情況讓 AI 跑 30 分鐘的雜工、讓人做那 5 秒的決定，是 ROI 最好的 HITL 設計。報價、採購簽核、客戶回信、合約審閱都吃這條。

訊號 5：你的老闆／客戶就是不放心讓 AI 自己跑

這條最直白。如果現在跟老闆說「AI 自動回客戶信」，老闆說「啊我自己看一眼比較安心」——那不要硬說服他。HITL 設計反而是把老闆的「不安心」變成一個可量化、可追溯、會自動逐步放寬的旅程：先 100% 都要按按鈕、跑 30 天看錯誤率、再放寬到只審某類 ticket、最後可能變成只審被 AI 自己標紅的少數案件。

5 個訊號決策對照表

NeMo Agent Toolkit 的 HITL 是什麼：跟「在 prompt 裡叫 AI 問你」差在哪

最常見的誤會是——「我寫個 prompt 叫 ChatGPT 每次都先問我可不可以，不就是 HITL 了嗎？」不是。prompt 級的「問你」會被 AI 自己決定要不要問、會被 context window 擠掉、會在跑 multi-agent workflow 時直接忽略；最重要的是——它沒有 audit trail，AI 自己問完自己回了你也不知道。NeMo Agent Toolkit 把 HITL 做成框架層的硬性中斷，是另一回事。

三個原語：hitl_approval_function、user_input_manager、WebSocket interactive mode

根據 NVIDIA 官方文件 與 GitHub examples/HITL/ 目錄，三個核心原語：

• hitl_approval_function：一個 reusable function，可以掛在任何 tool call 前面。觸發時，agent 暫停、user 看到 prompt（「我要 create 5 個 Jira ticket，准嗎？」）、user 回 yes/no 或正則匹配的關鍵字，agent 才往下走。por_to_jiratickets 範例直接示範了它怎麼套在 create_jira_tickets_tool 前面。

• user_input_manager：context-based input collector，負責在 runtime 動態收 user 回應。重點是「動態」——你不用在 agent 程式碼裡 hard-code 互動點，可以靠 config 決定哪些 tool call 要過 HITL、哪些直接放行。

• WebSocket interactive mode：HITL workflow 必須跑在 WebSocket 模式（不是傳統 REST），因為傳統 request/response 沒辦法在中間插入 user 回覆。NeMo Agent Toolkit-UI 就是搭配這個跑的官方前端。

por_to_jiratickets 拆給你看

這是官方 examples/HITL/por_to_jiratickets/ 的工作流程。中文翻譯成「把產品需求文件（POR）變成 Jira ticket，但每張 ticket 進 Jira 前要 PM 按按鈕」。

• Stage 1：extract_from_por_tool 讀 POR 文件，AI 抽出 epics / tasks / features / bugs

• Stage 2：LLM 自動估 story points（complexity + effort）

• Stage 3：hitl_approval_tool 跳出來——「以下 5 張 ticket 要進 Jira：[列表]，按 'yes' 確認」

• Stage 4：PM 在 UI 上看 ticket 列表 + 內容、按 yes / no

• Stage 5：approve → create_jira_tickets_tool 真的呼叫 Jira API；reject → return「denied」並終止

• Stage 6：回報 ticket ID 給呼叫端

config.yml 範例（用 NeMo Agent Toolkit 自己的 syntax）

# config.yml — por_to_jiratickets 風格
functions:
  hitl_approval:
    _type: hitl_approval_function
    description: "Ask user to approve before creating Jira tickets."
    prompt: "Confirm creation of the above tickets (yes/no):"
    approval_pattern: "^(y|yes|approve)$"

  create_jira_tickets:
    _type: jira_ticket_creator
    pre_call: [hitl_approval]   # ← 關鍵：在 create 之前強制過 hitl_approval

workflow:
  _type: react_agent
  tool_names: [extract_from_por, create_jira_tickets, get_jira_tickets]
  llm_name: nim_llm
  max_iterations: 10

真正的關鍵在 pre_call: [hitl_approval] 這一行——它把「人類審批」從 prompt 工程提升到 framework 層的硬性閘門。AI 想跳過？跳不過。這比寫在 prompt 裡靠 AI 自己記得問你穩太多了。

HITL 該放在工作流的哪一段？四個觸發點對照

這是設計 HITL 時最常踩坑的地方。放太多 → AI 沒效率（變成「AI + 一直按 yes」）、放太少 → 防不住風險。我們在客戶 AI 系統開發案裡反覆觀察出 4 個觸發點，每個對應一種風險：

觸發點 1：外部動作前（最常用）

這是 80% 的 HITL 場景。AI 在你公司內部跑都沒事，但只要要往外送（email、API call、Slack、Jira create、合約簽核），就插一個 HITL。por_to_jiratickets 範例完全是這個模式。設計重點：HITL 的 UI 要顯示「AI 想做什麼」+「為什麼」+「按 approve 後會發生什麼不可逆的事」。漏第三點是最常見的誤判來源。

觸發點 2：金額閾值

我們公司自己內部跑的採購流程是這樣：< 1,000 元 AI 全自動下單（軟體訂閱、雲端費用）、1,000-10,000 元 AI 列訂單 + 我看一眼按 approve、> 10,000 元 AI 草擬 → 我審 → 老闆再審。「金額閾值」的好處是規則化、不會 case by case 吵架。

觸發點 3：合規關鍵字

客服 AI 最危險的場景其實不是答錯一般問題，真正會出事的是它答到「我們保證」、「可以退費」、「沒關係不會被告」這種話。設計上就是在 AI 輸出前掛一個 keyword scanner，命中 → 強制 HITL（讓真人客服重寫）。這在 NeMo Agent Toolkit 裡，可以靠在 tool function 的 pre_call hook 加一個 compliance_filter function——掃完 AI output 後如果命中關鍵字、就強制跳 hitl_approval。

觸發點 4：AI 自評低信心

把「AI 自己說『我不確定』」也當成觸發訊號。這個比較進階——你要在 prompt 裡要求 AI 輸出 confidence score，並寫一條規則：confidence < 0.7 → 跳 HITL、要 SME 接手。這條被歸類「進階」的原因主要在於：AI 給出的 confidence score 本身就會幻覺——它有時候明明錯了還說「我超有把握」。我們的做法是用 confidence score 當其中一個訊號、不單獨依賴，搭配 RAG retrieval 結果為空、tool retry 次數等 hard signal 一起判斷。

simple_calculator_hitl 教你的事：iteration cap 也是一種 HITL

第二個官方範例 simple_calculator_hitl 看起來很簡單——問「2 × 4 是不是大於 5？」、AI 跑到 max_iterations 時 hitl_approval 跳出來「我達到迭代上限了，要再給我額度繼續嗎？」。但這個範例真正想教的，是 「成本控制也是 HITL 的合法用途」。中小企業跑 agent 最容易踩的坑就是—一個 bug 讓 agent 進 infinite loop、燒了 $200 的 token——iteration cap + HITL 是最簡單的保險絲。

simple_calculator_hitl 的 config 重點

workflow:
  _type: react_agent
  max_iterations: 3   # ← 故意設低，3 次後觸發 HITL
  retry_with_hitl: true

functions:
  hitl_approval:
    _type: hitl_approval_function
    prompt: "達到迭代上限。繼續嗎？(yes/no)"

跑「Is 2 × 4 greater than 5?」這種需要 multi-step reasoning 的問題、3 次跑不完就停下來問人。把這個 pattern 借去用：你的 AI agent 跑到「太久沒結果」、「retry 太多次」、「token 燒太多」時，自動丟一個 HITL 給技術 lead—「要不要再給它一次機會？要的話我會多花 $X」。比設定剛性的 hard cap 友善，比放任 agent 亂跑安全。

中小企業「需求審批採購」5 個訊號：要不要自己做 HITL agent

回到老闆視角。前面講完了 NeMo Agent Toolkit HITL 怎麼跑，但「要不要自己接、還是外包、還是先別做」這個決策，需要另一組訊號。

訊號 1：已經有人手動審批超過 20 次／週的同類流程

沒有重複量、HITL agent 沒意義（自動化省的時間都不夠 setup 成本）。20 次／週是粗略門檻——意味著一年 1,000 次，每次省 10 分鐘就是 166 小時。

訊號 2：流程已經有「可以驗收」的結構化輸入 / 輸出

如果你的「審批」現在還是電話一通搞定、沒有單據、沒有資料能讓 AI 解析—— HITL agent 沒辦法接。先把流程 onboard 到有結構的單據（哪怕是 Google Form）才有意義。

訊號 3：審批的人類成本可量化（時薪、決策延遲）

這條決定 ROI。如果做這個審批的是時薪 800 的工讀生、HITL agent 省下來的錢可能不夠付 token——但如果是時薪 3,000 的主管、就值得做。有一個粗略的公式可以快速判斷：每月節省成本 = 月審批次數 × (人類處理時間 - HITL 確認時間) × 時薪。把這個跟導入 + 運維成本比、看 payback period 是 3 個月還是 30 個月。

訊號 4：你願意花 6-8 週做第一版

HITL agent 的第一版不快。要設計觸發點、寫 hitl_approval_function、做 UI、串現有系統、跑 30 天 dogfood——比一般 SaaS POC 慢一倍。值得做的訊號是：你願意花 6-8 週把它做穩，後續每年省下的人力比 setup 多 5 倍以上。

訊號 5：審批內容會被法規檢查 / 客戶問起

這條最常被低估——但它是「該做」最強的訊號。如果你的審批決定會被金管會、衛福部、PCI-DSS、SOC2 audit 抽查，HITL agent 同時送你兩樣東西：①工作變快、② 每個決定都有完整 audit trail。光是後者就值得做。

5 個訊號採購決策表

自己接 NeMo Agent Toolkit vs 外包：四條決策線

如果你公司有 2 個以上工程師、且其中一個碰過 LangChain / LangGraph / CrewAI，自己接 NeMo Agent Toolkit 是合理的。如果沒有、外包通常會比較快。下面四條決策線：

決策線 1：你的後端棧是 Python 嗎？

NeMo Agent Toolkit 是 Python only。如果你公司主棧是 Node.js / Go / .NET、要嘛你接受多一個 Python service、要嘛先別做（等 NeMo 出多語言 binding，目前沒列在 roadmap）。

決策線 2：你能不能自己跑 NIM／NVIDIA API endpoint？

NeMo Agent Toolkit 預設用 NVIDIA NIM 推論 endpoint（可以雲端、也可以自架）。如果你只想用 OpenAI / Anthropic、可以——它 framework-agnostic、支援 LangChain、LlamaIndex、CrewAI、Microsoft Semantic Kernel、Google ADK。但你要自己設定 model adapter。

決策線 3：你的審批人需要什麼介面？

NeMo Agent Toolkit-UI 是官方 React UI、適合工程師審；但如果你的審批人是業務主管、客服主管、法務、老闆——他們不會去開瀏覽器 localhost:3000。實務上要把 HITL request 送到 Slack / LINE Notify / Teams / email，每個都要自己接 webhook。我們建議：自己跑公司內部、走 NeMo Agent Toolkit-UI 沒問題；要給非工程師審、要客製 Slack / LINE 對接介面，先把工作量算清楚再決定要不要自己做。

決策線 4：你需不需要把 audit trail 接到既有合規系統？

NeMo Agent Toolkit 內建 observability（OpenTelemetry compatible），可以匯出到 Datadog / Grafana。但如果你的合規系統是 SAP GRC、Workday、或自己的 internal compliance dashboard、要自己寫 adapter。這部分常被低估——audit 對接的工時往往跟 agent 本身一樣多。

自己接 vs 外包 ROI 對照（粗估）

跟著官方 README 跑一次 demo 不難，難的是「把這個變成公司每天真的在用的東西」。從『會用 NeMo Agent Toolkit』到『讓 HITL agent 真的省到主管時間』之間，通常差了一層客製——把它接進你的審批人實際用的介面（不是 localhost）、接進你的合規系統、接進你的業務 KPI。少了這一層，工具就只是工具；有了這一層，它才會變成槓桿。

HITL 跟採購總論、agent 資安、多框架整合怎麼配？

如果你已經讀過站內其他 AI agent 相關文章、會注意到我們把這個主題拆成幾條互補的線。先說每條的差異、再說怎麼配合著看：

• 採購總論 → 看 NVIDIA Agent Toolkit 完整解析（#689）。這篇講 NeMo Agent Toolkit 整體在 H2 2026 中小企業採購地圖裡的位置、17 家軟體巨頭加入的訊號意義。本篇接力講 HITL 設計。

• AI agent 上線後的資安問題 → 看 中小企業 AI agent 部署資安完整指南（#649）。PraisonAI CVE 復盤 + 60 天止血行動清單，跟本篇 HITL 是兩件事——HITL 防 AI 做錯，資安防外部攻擊。兩個都要。

• 多框架整合 → 看本批同步發布的 NeMo Agent Toolkit 多框架整合（主題 A）。如果你已經有 LangChain / CrewAI 既有資產、想知道 NeMo Toolkit 怎麼跟它們共存而不重寫，看那篇。

• 告警分流場景 → 本批同步發布的 NeMo Toolkit alert triage 與 vulnerability blueprint（主題 B）。IT 維運 SOC / NOC 場景，HITL 是其中一個 layer。

• 企業 KB / RAG 場景 → 本批同步發布的 NeMo Toolkit RAG + Milvus 自動描述（主題 C）。把企業 KB 升級成 agent 友善的 RAG，跟本篇的「審批 ticket 生成」是不同 stage。

• Claude Managed Agents 怎麼選 → Anthropic Claude Managed Agents 與 MCP Server 採購完整指南（#727）。如果你已經選了 Claude managed agents，HITL 怎麼接？這篇也有對應段落。

• H1 2026 採購清算總表 → 2026 上半年 AI Agent 採購清算（#692）。Q3 續約前要砍 / 留 / 升的判斷線。

• Agent 自己造工具 → AI Agent 自己造工具：Skill Library 技能庫（#279）。HITL 跟 Skill Library 可以共存——AI 造新工具 → 人類審批要不要進入 library。

HITL 也會出錯：三個踩坑分享

不要把 HITL 浪漫化。我們自己跟客戶討論時看過的失敗案例：

踩坑 1：HITL 太頻繁，變成「AI + 一直按 yes」

最常見的失敗。新導入時太緊張、每一個 tool call 都加 HITL，結果主管整天在按 yes。三週後主管已讀不點、ticket 卡住、整套流程比沒導入還慢。解法：HITL 設計第一天就要規劃「逐步放寬」路徑——統計通過率，連續 N 次都通過的某類動作，自動降級成事後 audit。

踩坑 2：HITL request 沒設 timeout，agent 卡死

這個 GitHub 上 NVIDIA/NeMo-Agent-Toolkit issue #1579 也在討論——HITL prompt 不可關閉、但如果 user 不回應、agent 會一直等。中小企業常見的場景：主管午餐去了、agent 卡在 HITL、queue 後面所有 ticket 全部塞住。解法：每個 hitl_approval 都要設 timeout、timeout 後 fallback 規則（自動 reject / escalate 給另一個人 / 寫進待辦下班前處理）。

踩坑 3：HITL 介面沒讓人看到「會發生什麼不可逆的事」

第三個踩坑：UI 只顯示「create 5 tickets, approve?」、主管按 yes、結果發現原來那 5 個 ticket 都會自動 trigger CI、跑了 30 分鐘 build、燒了 cloud 額度。解法：HITL 的 UI 一定要顯示「按 approve 後會發生什麼」+「會不會自動觸發後續動作」+「能不能反悔」。這是 UX 不是技術問題，但被忽略最多。

我們怎麼看 HITL：3 年後企業會怎麼用

我們公司內部最有感的三個 HITL 流程是 PRD-to-Jira、採購簽核、客服初稿審閱，八成中小企業都用得上。你公司現在最頭痛的是哪一塊審批？可以把現況丟過來，我們陪你一起看看哪一條最值得先試。

如果你正在評估「公司的需求審批 / 客服回應 / 採購簽核流程，該不該導入 HITL agent」、或已經在用 LangGraph / LangChain 但想加 HITL 層做合規收尾——歡迎來 聊聊現況。我們很樂意聽你公司現在的審批流程長什麼樣、卡在哪、值不值得用 HITL agent 改造，會直接告訴你「這個值得做嗎、大概怎麼做最划算」。