輪詢的兩個問題
傳統做法是運維 Agent 定時讀取 SMART 日誌。週期設長會漏掉瞬時事件——一次溫度尖峰、一次介質錯誤可能在兩次取樣之間來去；週期設短則在上千盤的叢集裡製造可觀的管理面開銷，而且每次 Get Log Page 都要佔用佇列槽位，與業務 I/O 競爭。兩頭都不理想。
取走才復位的握手語義
AEN 的工作方式是主機預先向盤下發若干條 Asynchronous Event Request 命令，這些命令不立即返回而是駐留在盤上。盤檢測到事件時完成其中一條，返回事件類型和關聯的日誌頁標識。主機隨後必須去讀對應日誌頁把事件狀態清除，再補發一條新的 AER 重新武裝通道。這個語義意味著驅動若忘記補發，後續事件將靜默丟失——這是平臺整合階段最常見的問題，且症狀表現為告警變少而非報錯，很容易被誤認為一切正常。
哪些事件值得佔用這條通道
事件大致分三類：錯誤狀態（介質錯誤、內部錯誤）、健康狀態變化（可靠性降級、溫度越閾、備用塊低於閾值、進入只讀模式）、通知類（命名空間屬性變化、韌體激活完成、Telemetry 日誌更新）。企業級盤應完整支援這幾類，並允許主機通過 Set Features 逐位使能，讓不同角色的機器只訂閱自己關心的事件，避免噪聲淹沒真正需要響應的告警。
與 SMART、Telemetry、NVMe-MI 的分工
四者互補而非替代。AEN 負責有事快說，攜帶的資訊量很少；SMART 日誌承載定量健康指標，用於趨勢判斷；Telemetry 承載故障時刻的內部狀態快照，供離線失效分析使用；NVMe-MI 走帶外通道，在主機作業系統失效或盤無法響應帶內命令時仍能讀到基本狀態。只有 AEN 而沒有 Telemetry，運維知道出了事卻查不出原因；只有 SMART 而沒有 AEN，則永遠慢一拍。
抑制誤報與抖動
溫度在閾值附近來回穿越會造成告警風暴。韌體側需要遲滯窗口和最小上報間隔，同一類事件在窗口內合併，上行與下行使用不同門限。J750/J770 尚在產品定義/EVT 階段，這組參數與客戶機箱的實際溫度曲線相關，屬於平臺聯調時的標定內容；事件覆蓋清單與抑制門限正在內部工程平臺 JH-E4U-C 上逐條驗證，最終會與韌體版本一起進入發佈說明，讓主機側的訂閱配置有確定的對照物件。