代理化行事曆協調
建構能夠協商會議、保護專注時段並從行事曆資料推斷上下文的 AI 代理。導航時區複雜性，實現代理對代理排程，並使用 Google Calendar API 和 MCP 架構自訂行事曆邏輯。
決策點
偵測到衝突時
傳入的會議請求與現有事件衝突
├─ 發送者 = 主管/高階主管 → 自動接受，建議移動現有事件
├─ 會議 = 標記為 1:1/緊急 → 在 24 小時內提出替代方案
├─ 專注區塊衝突
│ ├─ 區塊優先級 = 高 (深度工作) → 自動拒絕
│ └─ 區塊優先級 = 中 → 提出替代時間
└─ 與同儕會議雙重預約 → 回覆 3 個替代時段
自動拒絕 vs. 提出替代方案決策
因素：發送者層級 (主管/經理/同儕/外部) × 會議類型 (1:1/團隊/全員) × 專注區塊優先級
如果是 主管 + 任何類型 → 始終提出替代方案
如果是 經理 + (1:1 或 緊急) → 提出替代方案
如果是 同儕 + 週期性 + 低出席率 → 自動拒絕
如果是 外部 + 無先前關係 → 自動拒絕並附上「使用行事曆連結」
如果在 高優先級專注區塊 期間 → 無論發送者為何都自動拒絕
時區感知時段選擇
多位參與者排程：
├─ 全部相同時區 → 使用本地工作時間 (9-17)
├─ 2個時區，相差 <6小時 → 尋找重疊時窗
├─ 2個時區，相差 >6小時 → 早/晚分開 (一方取早上8點，另一方取下午6點)
└─ 3個以上時區 → 提出非同步替代方案 或 輪換時間表
能量模型時段排序
一天中時間的優先級 (降序)：
1. 上午 9-11 點 (認知巔峰) → 保留給深度工作，拒絕例行會議
2. 上午 11 點 - 中午 12 點 (持續專注) → 僅允許重要會議
3. 下午 2-4 點 (協作最佳時段) → 偏好用於團隊會議
4. 下午 4-5 點 (收尾時段) → 適合 1:1、狀態更新
5. 下午 1-2 點 (午餐後的低迷) → 避免複雜會議
故障模式
時區感知的週期性衝突
症狀：每週上午 9 點的會議在冬季顯示衝突但在夏季卻沒有；跨時區的週期性會議在 DST 變更後失敗
偵測：if 週期性事件 && 時區轉換 && 衝突模式季節性
修正：始終使用 singleEvents: true 展開週期性事件，將每個實例轉換為 UTC 以進行衝突檢查，在 DST 轉換後重新評估
緩衝執行震盪
症狀：代理為了建立緩衝而反覆重新排程同一個會議；會議在時段之間來回跳動
偵測：if 同一個會議在 24 小時內因緩衝原因被重新排程 > 2 次
修正：在首次重新排程後鎖定會議，根據會議重要性動態調整緩衝需求
能量模型冷啟動
症狀：新代理在使用者認知最差的時間安排會議；忽略已建立的使用模式
偵測：if 對於由代理安排的會議，會議滿意度分數 < 3
修正：使用明確的使用者偏好進行引導，從拒絕模式中學習，在自動排程前需要 2 週的觀察期
結構膨脹與隱私洩露
症狀：代理與外部系統分享過多行事曆細節；事件描述洩漏給 LLM
偵測：if 外部 API 呼叫包含 event.description 或 attendee.email
修正：實作資料最小化層，在外部呼叫前剝離 PII，僅使用空閒/忙碌狀態進行排程
遞迴協商迴圈
症狀：兩個代理無休止地提出反提案；無法就會議時間達成一致
偵測：if 協商回合 > 3 且 無接受的時段
修正：在 2 次反提案後升級給人類，實作「夠好」的接受門檻，為協商設定時間限制
工作示例
跨時區會議協商
場景：你的代理 (芝加哥) 需要與同儕代理 (東京) 進行 30 分鐘的 API 審查。雙方都有能量約束。
步驟 1：初步分析
- 芝加哥：上午 9 點 - 下午 5 點 CST = 凌晨 12 點 - 早上 6 點 JST (隔天)
- 東京：上午 9 點 - 下午 6 點 JST = 下午 7 點 - 凌晨 4 點 CST (前一天)
- 重疊時窗：下午 7-8 點 CST = 上午 9-10 點 JST
步驟 2：能量模型檢查
- 芝加哥下午 7 點 = 工作日結束 (能量：6/10)
- 東京上午 9 點 = 認知巔峰時段 (能量：9/10)
- 偵測到不平衡 → 需要妥協
步驟 3：提案生成
代理芝加哥 → 代理東京：提案
時段：[
"2024-03-19T01:00Z" (芝加哥：下午7點，東京：上午10點),
"2024-03-19T23:00Z" (芝加哥：下午5點，東京：上午8點),
"2024-03-20T00:00Z" (芝加哥：下午6點，東京：上午9點)
]
優先級：正常
主題：「API 審查 - 時區複雜度討論」
步驟 4：反提案
代理東京 → 代理芝加哥：反提案
原因：「對於複雜技術討論偏好東京較晚的上午時段」
替代方案：[
"2024-03-19T02:00Z" (芝加哥：下午8點，東京：上午11點),
"2024-03-20T01:00Z" (芝加哥：下午7點，東京：上午10點)
]
約束條件：「在 JST 上午 11:30 站立會議前需要 15 分鐘緩衝」
步驟 5：解決方案 芝加哥代理接受下午 8 點 CST / 上午 11 點 JST 時段，在事件描述中使用兩個時區建立事件： 「API 審查 - 下午 8:00 CST / 上午 11:00 JST+1」
新手 vs 專家：
- 新手：在對芝加哥方便的時間進行排程，未檢查東京的認知時段
- 專家：識別能量不平衡，在東京精神飽滿時提出芝加哥的晚間時段
品質關卡
- 所有時間戳記在內部儲存為 UTC，僅在顯示/API 邊界進行轉換
- 整個過程使用 IANA 時區名稱 (不使用像是 "-05:00" 的 UTC 偏移字串)
- 空閒/忙碌查詢剝離事件詳細資訊，僅與外部代理共用時間區塊
- 緩衝執行在連續會議之間建立最少 10-15 分鐘
- 專注區塊標記為「忙碌」，但對於協商而言優先級低於實際會議
- 能量模型考慮使用者的認知巔峰時段和會議疲勞模式
- OAuth 令牌在靜止時加密，並實作自動重新整理流程
- 速率限制透過指數退避處理 Google Calendar API 配額
- 在衝突偵測前將週期性事件展開為單獨的實例
- 多行事曆合併需在具有不同權限的個人/工作日曆上進行測試
- 代理協商具有時間限制，在失敗回合後可升級給人類
- 稽核日誌記錄所有行事曆變更，並具有回滾能力
非此技能範圍的邊界
此技能並非用於：
- 建置行事曆 UI 元件 → 使用
form-validation-architect - 專案甘特圖或里程碑追蹤 → 使用
project-management-guru-adhd - 蕃茄鐘計時器或時間追蹤應用程式 → 使用
adhd-daily-planner - 通用代理架構模式 → 使用
agentic-patterns - 建置基礎代理框架 → 使用
agent-creator
當以下情況時委派給其他技能：
- 使用者需要 ADHD 特定的時間管理 →
adhd-daily-planner - 建置持久性代理記憶體 →
always-on-agent-architecture - 超出行事曆範圍的多代理協調 →
multi-agent-coordination - 背景守護行程架構 →
daemon-development
此技能專門專注於行事曆資料結構、排程演算法和會議協調邏輯。