NVIDIA 這篇 NemoClaw 與 Hermes Agent 教學，最有價值的地方不是又多一個 agent demo，而是把企業最難處理的問題放到前台：agent 要同時用內部資料和公開資料時，安全邊界應該怎樣設計。文章以產品研究為例，把 Outlook、Slack、GitHub 和 NVIDIA developer forums 接入同一個 agent workflow。
架構分成三層：NVIDIA Nemotron 3 Super 負責推理與生成，Hermes Agent 負責 harness、skills、sessions、memory 和 bridges，NVIDIA OpenShell 負責 runtime policy、filesystem、network control 和 credential brokering。這個分層很重要，因為安全不靠 prompt 口頭承諾，而是由 runtime 實際限制網絡、憑證和工具使用。
OpenShell sandbox 的設計尤其值得留意。Hermes Agent 不直接看到 Slack 或 Outlook token，認證由 sandbox proxy 在請求離開時處理。agent 可讀內部訊息，但不能直接接觸公開互聯網；GitHub 和論壇資料則由另一條 ETL 流程拉回來，提供 read-only access。即使 agent 被錯誤指令帶偏，也不能任意把內部資料貼到外部網站。
文章另一個重點是 self-evolving。使用者可以在對話中教 agent 一個固定報告格式，Hermes 會把這個模式寫成 SKILL.md，之後新 conversation 或同事用 email 觸發同一需求時，也能套用相同格式。snapshot 流程會保存 skills、memories、sessions 和 scheduled jobs，同時過濾 .env、token、secret 等敏感檔案，讓學到的狀態可以跨部署延續。
這類設計比單純「長記憶」更接近企業需要。真正可用的 agent 需要有可遷移的工作格式、可審計的 execution trace、明確的 network allowlist、可重建的 sandbox，以及不暴露憑證的工具接駁。對 sales research、customer support、engineering triage、competitive analysis 和 internal knowledge discovery 來說，這些基礎設施比模型回覆是否漂亮更關鍵。
NVIDIA 的訊號很清楚：agent 能力正由 prompt engineering 走向 runtime engineering。當企業開始把 agent 放入真實資料和真實工作流，重點不是讓 agent 什麼都可以做，而是讓它在可驗證、可限制、可恢復的邊界內，把重複研究和整理工作越做越穩定。
