用AI Agent为团队自动寻找最佳会议时间

为六位同事安排一场30分钟的会议，"周二行吗"的邮件链能拖上三天——这是很多团队协调者熟悉的场景。YouTube频道Edge的"Outlook Assistant"系列第二期展示了另一种可能：让AI Agent在几秒内完成可用性矩阵、按规则打分排序、生成热力图并起草邀请。整个流程建立在一套清晰的评分规则和Codex工具扩展之上，核心思路对于任何想用AI改造日程协调的人都有参考价值。

评分规则先行：把"谁有空"变成可计算的分数

在让AI写一行代码之前，视频作者先做了一件容易被忽略的事：定义评分规则。做法是把一周切分为30分钟粒度的时隙，对每个时隙统计参会者状态——空闲记1分，暂定记0.5分，忙碌或不在办公室记0分。该时隙的得分即所有参会者可得分数之和占满分（人数×1）的百分比，然后按时隙得分从高到低排序。

这个设计的关键在于"暂定算半个人"的处理。现实中很多会议协调之所以低效，正是因为暂定状态既不能直接排除、也不适合当作完全可用。把它折算成0.5分，等于在排序中给"可能来"的时间段一个合理的中间权重，而不是让它们和完全空闲或被占满的时隙混在一起。规则由人定，打分交给机器执行，这是后续所有步骤能够自动化的前提。

在日历系统中，参会者的时间状态通常分为几种标准类型：空闲（Free） 表示该时段完全可用；暂定（Tentative） 表示已接受邀请但可能更改；忙碌（Busy） 表示已有确定安排；不在办公室（Out of Office） 表示请假或出差。这些状态通过 Exchange/Outlook 的 API（如 Microsoft Graph 的 scheduleInformation）可批量获取，是构建可用性矩阵的数据基础。理解这些状态的语义差异很重要：忙碌和不在办公室通常不可协调，而暂定状态则存在协商空间，因此赋予中间权重是合理的工程折衷。

用Codex添加新工具：可用性矩阵与热度图

规则确定后，作者通过Codex向助手添加了一个新工具。请求包含两个部分：一是构建可用性矩阵，应用上述评分规则，返回前三名时隙以及无法参会的人员名单；二是在同一请求中把矩阵保存为一张热度图（heat map），输出为单个HTML文件，可直接在浏览器中打开，与系列前作中的仪表盘形态类似。

添加工具后需要关闭Codex并重新启动，让它加载新工具，再通过SlashMCP做一次检查确认工具已就位。这个"重启—验证"的步骤看似琐碎，但反映了一个实际约束：Agent的能力扩展不是热加载的，新工具生效需要显式确认。对打算照做的读者来说，这是容易踩坑的地方。

Codex 在此处指一个支持工具扩展的 AI 助手框架（类似 OpenAI Codex 的代理形态），允许开发者通过自然语言描述或代码片段注册新的可调用工具（function/tool）。SlashMCP 则是一种通过斜杠命令与 MCP（Model Context Protocol）服务器交互的检查机制，用于确认工具是否已被正确加载和暴露。MCP 是 Anthropic 提出的开放协议，旨在标准化 AI 模型与外部工具、数据源的连接方式，使 Agent 能够动态发现和调用新能力。这类工具扩展机制的核心价值在于：无需修改助手核心逻辑，即可按需增加领域专用功能。

自然语言提问：前三名时隙与完整热度图

工具就绪后，作者直接用自然语言提问："找下周最好的30分钟时隙。"助手面对的是Anna、Ben、Carla、David、Alaina、Farid六位同事的日历，返回了三个候选：周二10:00全员空闲，得分100%；周三15:30六人中五人可用；周四9:30得分75%。同时输出了无法参会者姓名，方便后续沟通。

你可能没注意到，热度图把整周的可视化一次呈现出来，让"哪个时段整体最优"不再依赖逐条比对日历。这种"排序结果+全局视图"的组合，比单纯给出一个推荐时间更实用——协调者可以在最高分时隙不可行时，迅速理解次优选项的代价是什么。

热度图（Heat map） 是一种用颜色深浅表示数值高低的二维可视化形式，在此场景中横轴为一天中的时隙、纵轴为一周的各天，颜色越深代表该时隙的可用性得分越高。相比表格逐行阅读，热度图能让协调者在一屏内快速识别"黄金时段"和"雷区"。将可视化输出为单个 HTML 文件的好处是零依赖、可离线打开、便于分享和存档，也避免了仪表盘服务部署的复杂性。

起草邀请与手动验证：AI结论仍需人工复核

选定最佳时隙后，助手起草了会议邀请，附带一段关于Q3投资组合回顾的简短议程。需要说明的是，视频中的演示服务器按设计不包含发送工具，因此输出停留在草稿阶段，不会真正发出邮件。这一设计既符合演示的安全边界，也提示了一个现实原则：让Agent起草、由人确认发送，是更稳妥的分工。

作者随后做了一个值得学习的动作——手动验证。他挑出热度图中的第三个时隙（周四9:30，75%），对照日历文件逐人核对：一人空闲、一人暂定、一人忙碌，恰好对应75%的得分。在把AI输出用于真实决策前，抽一个样本做人工复核，是低成本发现规则实现错误的有效手段。

从虚构数据到真实日历：边界与下一步

本期演示全程使用虚构数据，最后设置了"meeting finder view one"的存档点，便于后续迭代。作者预告下一期为系列终章，将讨论如何以正确的方式、在与IT团队协作的前提下，把这个助手接到真实的Outlook上。

这套方案的启发在于其结构而非具体工具：先定义可量化的评分规则，再把规则封装为Agent可调用的工具，用自然语言触发，用可视化辅助决策，最后保留人工验证与人工确认发送的环节。团队成员数量、时隙粒度和暂定权重都可以按团队习惯调整，而"规则—工具—验证"的骨架是通用的。

参考资料：YouTube频道Edge，"Outlook Assistant Part 2"视频。

将演示助手接入真实 Outlook 日历涉及若干生产环境问题：OAuth 2.0 授权与权限范围（如 Calendars.ReadWrite）、企业租户的管理员同意策略、数据隐私与合规审查、以及发送邮件所需的 Mail.Send 权限。通常需要 IT 团队评估安全风险，并可能要求在隔离的测试租户中先行验证。此外，真实日历数据比虚构数据更嘈杂（如重复会议、全天事件、时区差异），评分规则可能需要增加去重、时区归一化等预处理步骤。