代理式日历协调
构建能够协商会议、保护专注时间并从日历数据中推断上下文的AI代理。驾驭时区复杂性，实现代理间日程安排，并使用Google Calendar API和MCP构建自定义日历逻辑。
决策点
检测到冲突时
收到与现有事件冲突的会议请求
├─ 发送者 = 经理/高管 → 自动接受，建议移动现有事件
├─ 会议 = 一对一/紧急标记 → 在24小时内提议替代时间
├─ 专注块冲突
│ ├─ 块优先级 = 高（深度工作） → 自动拒绝
│ └─ 块优先级 = 中等 → 提议替代时间
└─ 与同级别会议双重预订 → 提供3个替代时段作为回复
自动拒绝与提议替代决策
因素：发送者层级（高管/经理/同级别/外部）× 会议类型（一对一/团队/全员会议）× 专注块优先级
如果 高管 + 任何类型 → 总是提议替代
如果 经理 +（一对一或紧急）→ 提议替代
如果 同级别 + 定期 + 低出席率 → 自动拒绝
如果 外部 + 无先前关系 → 自动拒绝并回复“请使用日历链接”
如果 处于高优先级专注块期间 → 无论发送者是谁，一律自动拒绝
时区感知时段选择
多参与者日程安排：
├─ 所有参与者同一时区 → 使用本地工作时段（9-17点）
├─ 2个时区，且小于6小时差距 → 寻找重叠窗口
├─ 2个时区，且大于6小时差距 → 早晚分拆（一方早8点，另一方晚6点）
└─ 3个及以上时区 → 提议异步替代方案或轮换安排
能量模型时段排名
时间段优先级（降序）：
1. 上午9-11点（认知高峰期）→ 保留给深度工作，拒绝常规会议
2. 上午11-12点（持续专注）→ 仅允许重要会议
3. 下午2-4点（协作黄金时段）→ 偏好用于团队会议
4. 下午4-5点（收尾时段）→ 适合一对一、状态更新
5. 下午1-2点（午饭后低谷期）→ 避免复杂会议
故障模式
时区感知的递归冲突
症状：每周上午9点会议冬季显示冲突但夏季不显示；跨时区递归会议在夏令时变更后失败
检测：if recurring_event && timezone_conversion && conflict_pattern_seasonal
修复：始终使用 singleEvents: true 展开递归事件，将每个实例转换为UTC进行冲突检查，并在夏令时过渡后重新评估
缓冲区强制执行抖动
症状：代理反复重新安排同一会议以创建缓冲区；会议在多个时段间来回跳动
检测：if same_meeting_rescheduled > 2 times in 24h for buffer_reasons
修复：首次重新安排后锁定会议，根据会议重要性动态调整缓冲区要求
能量模型冷启动
症状：新代理在用户认知能力最差的时间段安排会议；忽略已建立的行为模式
检测：if meeting_satisfaction_score < 3 for meetings_scheduled_by_agent
修复：使用明确的用户偏好进行引导，从拒绝模式中学习，需要2周观察期后才允许自动调度
架构膨胀与隐私泄露
症状：代理向外部系统分享过多日历细节；事件描述泄露给LLM
检测：if external_api_call contains event.description OR attendee.email
修复：实现数据最小化层，在外部调用前剥离个人身份信息，仅使用忙/闲状态进行调度
递归协商循环
症状：两个代理无休止地互相提出反提案；无法就会议时间达成一致
检测：if negotiation_rounds > 3 && no_accepted_slot
修复：在两次反提案后升级给人类，实施“足够好”接受阈值，为协商设定时间限制
工作示例
跨时区会议协商
场景：你的代理（芝加哥）需要与同级别代理（东京）进行30分钟的API审查。双方都有能量约束。
步骤1：初步分析
- 芝加哥：上午9点-下午5点CST = 次日上午12点-6点JST
- 东京：上午9点-下午6点JST = 前一天下午7点-次日上午4点CST
- 重叠窗口：CST下午7-8点 = JST上午9-10点
步骤2：能量模型检查
- 芝加哥下午7点 = 工作日结束（能量：6/10）
- 东京上午9点 = 认知高峰期（能量：9/10）
- 检测到不平衡 → 需要折衷
步骤3：提案生成
Agent Chicago → Agent Tokyo: PROPOSE
时段：[
"2024-03-19T01:00Z" (芝：晚上7点，东：上午10点)，
"2024-03-19T23:00Z" (芝：下午5点，东：上午8点)，
"2024-03-20T00:00Z" (芝：下午6点，东：上午9点)
]
优先级：普通
主题：“API审查 - 时区复杂性讨论”
步骤4：反提案
Agent Tokyo → Agent Chicago: COUNTER
理由：“更偏好东京晚些时候的上午来处理复杂技术讨论”
替代方案：[
"2024-03-19T02:00Z" (芝：晚上8点，东：上午11点)，
"2024-03-20T01:00Z" (芝：晚上7点，东：上午10点)
]
约束：“在JST上午11:30站立会议前需要15分钟缓冲区”
步骤5：解决 芝加哥代理接受CST晚上8点/JST上午11点的时段，在描述中创建包含两个时区的事件： “API审查 - 晚上8:00 CST / 上午11:00 JST+1”
新手与专家对比：
- 新手：在芝加哥方便的时间安排，而不检查东京的认知小时
- 专家：识别能量不平衡，提议芝加哥较晚的一天时间，此时东京精力充沛
质量门禁
- 所有时间戳内部以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
此技能专门关注日历数据结构、调度算法和会议协调逻辑。