昨天，我們讓 Agent 根據情境選擇 Action。今天再往前一步：如果使用者沒有先開口，Agent 能不能判斷，現在適不適合關心一下？

這就是今天要設計的「主動關懷」。

為什麼不能永遠等使用者開口？

使用者不一定每天都會主動描述自己的狀況。有時候只是忙，有時候則是不知道該怎麼開始說。

如果 AI Companion 只能一問一答，就很難延續前幾天的對話。例如，使用者連續幾天提到睡不好，Agent 可以在適合的時間，簡短詢問近況。

但「記得使用者」不代表「隨時都能打擾使用者」。主動關懷也需要界線。

主動關懷和一般提醒有什麼不同？

一般提醒通常是執行已經設定好的任務：

每天晚上九點，提醒我記錄今天的睡眠狀況。

主動關懷則多了一層判斷：

最近幾天都提到睡不好，今天需要問候一下嗎？

提醒重視「時間到了沒有」，主動關懷還要考慮「有沒有必要，以及使用者願不願意」。

因此，Agent 的決策結果也可以是：先不打擾。

Agent 需要哪些 Context？

第一版可以整理五種資訊：

• Health Memory：最近提過哪些健康相關內容。
• Health State：從紀錄整理出的狀態與變化。
• 互動紀錄：今天聊過幾次、上次主動關懷是什麼時候。
• 使用者偏好：是否開啟關懷、能接受的頻率與時段。
• 目前時間：是否落在允許聯繫的時間內。

其中，Health Memory 是原始紀錄；Health State 是整理後的描述，例如「最近三天都有提到睡不好」。

這裡也要保留資料日期與來源。使用者沒有再提到某個問題，不代表問題已經改善。

設計第一版 Proactive Care Policy

第一版先用明確規則控制介入條件，再讓模型產生合適的文字：

未開啟主動關懷 → No Action
目前是勿擾時段 → No Action
距離上次關懷未滿冷卻時間 → No Action
今天互動已達設定門檻 → No Action
沒有新的變化或待追蹤事項 → No Action
其餘情況 → 評估合適的 Action

冷卻時間與互動門檻應依使用者偏好設定，也要提供暫停與關閉功能。

實作上，由排程或事件觸發這段流程；Agent 負責判斷這次是否介入。它不會只靠一段 Prompt 就自行定時醒來。

Health State → 主動關懷 Demo

假設這次輸入的 Context 是：

Health State：連續三天提到睡不好
今天主動關懷次數：0
目前時間：晚上 8 點，位於允許時段
使用者偏好：低頻率關懷
冷卻時間：已滿
待追蹤事項：睡眠近況

Agent Decision：

Action：ASK_CHECK_IN
Reason：有待追蹤事項，且符合聯繫條件

產生的訊息可以是：

你這幾天都有提到睡得不太好，今天感覺有好一點嗎？方便的話再跟我說就好。

若今天已經聊過很多次，也沒有新的健康變化，結果就應該是：

Action：NO_ACTION
Reason：目前沒有額外介入的必要

成功送出後，系統才更新關懷紀錄，並避免同一次事件重複發送。

除了詢問，Agent 也能選擇提供簡短衛教，或提出建立提醒的建議。真正建立提醒前，仍要取得使用者同意及明確時間。

今天遇到的設計問題與安全邊界

最難的地方，是區分「值得追蹤」和「需要立刻打擾」。

同一段睡眠紀錄，不應每次執行都觸發問候。因此，系統需要記住哪些事項已經問過，以及使用者是否希望之後再談。

另一個界線是：不能把趨勢直接說成疾病。「最近常提到睡不好」只是紀錄摘要，不能因此判定使用者有失眠症。資料不足時，也應保留不確定性。

下一步

接下來會加入 Tool Calling，讓通過 Policy 的決策能呼叫訊息、Reminder 或外部工具，並記錄執行是否成功。

Day 16 是讓 Agent 選擇做什麼；Day 17 則是讓 Agent 判斷什麼時候適合做。

好的陪伴不是一直主動，而是知道什麼時候該關心、什麼時候不要打擾。