Microsoft Graph 日历冲突解决器

要解决的问题

发起跨团队会议时最常见的失败模式是：发起人凭感觉挑一个时间，邀请发出去之后才发现与已有日程相撞，只能临时改期或接受缺席。根因在于信息是分散的——忙闲状态躺在每个与会者的日历里，而发起人手里只有自己 /me/events 的快照，看不到别人的安排。

换成 Agent 场景，问题是一样的，只是代价更高：Agent 需要在一次推理里拿到可比较的冲突证据——谁在忙、忙在哪个时间段、约束条件是什么——然后才能给出「改到几点」的建议，而不是盲目写入一个很可能撞车的日程。

技能如何工作

核心依赖 Microsoft Graph 的日历端点：

• /me/events：读取当前用户的已有事件，作为冲突检测的基线输入。
• /calendarView：按指定时间窗口拉取日历视图，用来做时间段级别的忙闲比对，而不是逐条事件翻页。
• findMeetingTimes：在给定约束（与会者、时间窗、所需时长、限制条件）下产出候选时段。

典型流程：

1. 从待改期的会议中提取与会者列表与时长约束；
2. 用 /calendarView 按时间窗拉取与会者的忙闲；
3. 与现有 /me/events 比对，定位冲突的确切时段；
4. 调用 findMeetingTimes 生成候选时段；
5. 把候选时段连同冲突证据一起返回，由上层 Agent 决定是否发出更新。

这个技能固化的是「比较与会者、约束与可用性」这一步，输出的是可解释的建议，不是直接改写日历。

适用边界与注意点

• 端点调用依赖有效授权（例如 Calendars.ReadWrite），权限不足时冲突检测会退化成不完整的结果，而不是显式报错。
• /calendarView 只返回窗口内的数据，窗口选得太窄会漏掉紧邻的冲突。
• findMeetingTimes 返回的是建议，不保证与会者接受；它也不会代发更新邀请。
• 忙闲信息的粒度取决于各邮箱在 Graph 中实际共享的内容，域内与跨域行为可能不一致。
• 涉及代理发送、资源账户（如会议室）时，需要额外的委托配置与筛选条件。