meeting-scheduler

会议安排

此技能可让 AI agent 端到端处理会议协调。收到自然语言请求后，agent 会识别参与者、处理时区差异、查询日历空闲时间、提出无冲突的时间段、发送日历邀请并跟踪回复。它集成了 Google Calendar、Microsoft Outlook 和 Calendly，涵盖最常见的企业及自由职业日程安排工作流。

工作流

1. 解析会议请求 从用户的自然语言输入中提取结构化数据。识别所有必需参与者（姓名、电子邮件或团队别名）、会议主题或议程、期望时长，以及日期或时间限制，例如“下周二下午”或“本轮迭代结束前”。继续之前，标记任何含糊不清的指代并请求澄清。

2. 处理时区 从每位参与者的日历资料或联系人记录中查找其配置的时区。将所有备选时间段转换为每位参与者的当地时间，以确保比较准确。如果不知道某位参与者的时区，请提示组织者确认。显示所有建议时间时，明确标注时区（例如，“3:00 PM EST / 12:00 PM PST”），避免产生混淆。

3. 检查日历空闲时间 通过相应集成（Google Calendar API、Microsoft Graph API 或 Calendly 空闲时间端点）查询每位参与者的日历。收集所请求日期范围内的忙碌时段，并计算空闲时段的交集。遵守每位参与者的工作时间偏好，以及已配置的专注时间或禁止安排会议的时段。在相邻会议之间应用可配置的缓冲时间（默认 10 分钟），以便留出过渡时间。

4. 提出最佳时间段 使用评分规则对可用时段排序：优先选择所有参与者都处于标准工作时间内的时段，尽量减少清晨或深夜的当地时间，并在有紧急需求时优先选择较早的日期。向组织者展示排名前三的选项，并汇总每位参与者的当地时间。

5. 发送日历邀请 组织者确认时间段后，通过相应 API 创建日历事件。附上议程、视频会议链接（Zoom、Google Meet 或 Teams）及任何相关文档。向所有参与者发送邀请邮件。对于未集成日历的外部参与者，发送附有 .ics 文件的独立邮件。

6. 跟踪回复并处理变更 收到邀请回复后进行跟踪。通知组织者接受、暂定和拒绝情况。如果关键参与者拒绝，自动根据剩余空闲时间提出备选时段，并启动重新安排流程。对于周期性会议，跟踪出席情况，并标记经常存在时间冲突的参与者，以便组织者调整频率。

用法

提供一条自然语言请求，其中包含参与者、主题、大致时长以及任何日程安排限制。agent 会处理其余事项。

"Schedule a 30-minute meeting with John and Jane to discuss the Q3 report sometime next week. Prefer mornings."

你也可以请求安排周期性会议、改期或取消会议：

"Reschedule tomorrow's design review to Thursday. Same time if possible, otherwise find a new slot."

"Set up a weekly 15-minute standup with the backend team every Monday at 9:30 AM ET starting next week."

示例

示例 1 — 跨时区会议与空闲时间矩阵

用户输入：

"Schedule a 1-hour architecture review with Priya (IST), Marcus (CET), and Li (CST, China) this Thursday or Friday. Avoid early mornings for everyone."

Agent 输出：

I checked calendars for Priya, Marcus, and Li. Here is the availability matrix:

                        Priya (IST)    Marcus (CET)    Li (CST)
Thu 10:00–11:00 UTC     3:30 PM        11:00 AM        6:00 PM
Thu 12:00–13:00 UTC     5:30 PM        1:00 PM         8:00 PM ⚠️
Fri 09:00–10:00 UTC     2:30 PM        10:00 AM        5:00 PM  ✅ Best

Recommended: Friday 09:00–10:00 UTC
 — Falls within working hours for all three participants.
 — No conflicts detected.

Shall I send the invitation for Friday 09:00–10:00 UTC with a Google Meet link?

示例 2 — 解决冲突并重新安排会议

用户输入：

"The Wednesday product sync conflicts with Alice's dentist appointment. Move it to another day this week. Bob and Carol also attend."

Agent 输出：

Current meeting: Wednesday 2:00–2:30 PM ET (Alice, Bob, Carol)

Alice is unavailable Wednesday 1:00–4:00 PM ET (personal appointment).
Bob is unavailable Thursday all day (PTO).
Carol has no additional conflicts this week.

Available alternatives:
  1. Tuesday  2:00–2:30 PM ET  — all three free ✅
  2. Friday   10:00–10:30 AM ET — all three free
  3. Friday   3:00–3:30 PM ET  — all three free

Recommendation: Option 1 (Tuesday 2:00 PM ET) keeps the same time of day.

Shall I reschedule to Tuesday and notify all participants?

最佳实践

• 始终显示带时区标注的时间。 切勿只写“下午 3:00”这样的时间而不注明时区。这可以避免最常见的日程安排错误。
• 在会议之间留出缓冲时间。 默认留出 10 分钟。会议无缝衔接会导致疲劳和迟到。允许组织者按日历配置此项。
• 遵守工作时间边界。 除非参与者明确将这些时段标记为可用，否则不要建议上午 7:00 或晚上 9:00 的时段。
• 发送前先确认。 始终先将建议的时段和参会者名单提交给组织者审批，再发送邀请。仅在用户主动选择启用时，才自动发送。
• 妥善处理外部参与者。 如果参与者没有关联日历，则改用基于电子邮件的可用时间收集方式，或附上可供对方手动导入的 .ics 文件。
• 跟踪周期性会议的状况。 对于周期性活动，定期报告出席率；如果出席率低于阈值（例如 60%），则建议调整频率。

边缘情况

• 没有找到重叠的可用时段。 如果日历在请求的日期范围内没有共同的空闲时段，则将搜索范围延长至下一周，并告知组织者。或者，建议拆分为两场较短的会议，允许部分人员参加。
• 时区未知或不明确。 如果无法从参与者的个人资料中确定其时区，则在建议时段前请组织者确认。切勿默默假定默认时区。
• 未找到参与者。 如果无法将姓名对应到日历或电子邮件地址，则列出可能匹配的对象，并请组织者确认具体是哪一位。
• 日历 API 速率限制或服务中断。 如果可用时间检查失败，则使用指数退避重试，最多三次。如果服务仍不可用，则告知组织者，并询问是稍后重试，还是根据部分可用时间数据继续安排。
• 临时取消。 如果参与者在会议开始前一小时内拒绝参加，则立即通知组织者，并询问是继续、取消还是重新安排。
• 全天活动和专注时段。 除非全天日历活动明确标记为“忙碌”，否则将其视为暂定安排。默认将专注时段视为不可用，但允许组织者覆盖此设置。