多身份企业邮箱日历管家

基于 Microsoft Graph API 的企业级多账户 Office 365 连接器，支持邮件、日历、联系人管理，采用 OAuth 2.0 设备流认证与令牌隔离存储，适合跨组织身份管理场景。

基本信息

• 技能名称?office365-connector
• 中文名称?多身份企业邮箱日历管家
• 作者?tirandagan
• 分类?办公
• 版本?v2.0.0
• 标签?office, productivity, api, automation, backend, email, calendar, microsoft-365, oauth

使用方法

使用说明
核心用法
Office 365 Connector 是一款面向 Microsoft 365 生态的集成型 Agent Skill，通过 Microsoft Graph API 实现与 Outlook 邮件、日历及联系人的深度交互。v2.0.0 版本引入的多账户架构是其最大亮点，用户可在单一技能实例中配置并切换多个 Microsoft 365 身份（工作、个人、咨询客户等），通过 --account 参数或默认账户设置灵活调用不同身份的数据与发送权限。
使用流程分为三步：首先在 Azure AD 完成应用注册获取 Tenant ID、Client ID 和 Client Secret；随后通过 accounts.js add 添加账户并执行 auth.js login 完成 OAuth 设备流认证；最后即可通过 CLI 命令执行邮件检索、日历查询、事件创建等操作。技能内置自动令牌刷新机制，支持从 v1.0.0 单账户配置的无缝迁移。
显著优点
多账户隔离架构 是核心竞争力。每个账户拥有独立的令牌存储路径（ ~/.openclaw/auth/office365/ .json ），配合 0600 文件权限实现严格的访问控制，从根本上避免了跨账户数据混淆风险。对于顾问、自由职业者及跨组织协作人员，这一设计大幅简化了多身份管理复杂度。
零第三方依赖 降低了供应链攻击面。技能完全基于 Node.js 标准库（https/fs/path）构建，无需引入任何 npm 包，消除了依赖混淆、恶意包注入等常见风险。同时，OAuth 2.0 Device Code Flow 的采用避免了在自动化环境中处理浏览器交互的脆弱性，更适合服务器/CLI 场景。
完善的文档与错误处理体系 提升了生产可用性。从 Azure 应用注册的分步指南到权限范围的详细说明，从速率限制的处理策略到常见 AADSTS 错误码的排查建议，文档覆盖完整。代码层面实现了指数退避重试、令牌自动刷新、权限错误友好提示等机制。
潜在缺点与局限性
Client Secret 明文存储 是主要安全隐患。尽管文件权限设置为 0600，但凭据仍以明文形式持久化于 office365-accounts.json ，在共享主机或容器逃逸场景下存在泄露风险。建议用户结合操作系统级加密（如 macOS Keychain、Linux libsecret）或定期轮换密钥缓解。
功能边界受限于 Microsoft Graph API 本身 。附件大小上限 4MB、邮件收件人上限 500、日历事件仅支持未来 1095 天等限制无法通过 Skill 层突破。批量操作仅支持 20 请求/批次，大规模数据迁移场景效率受限。
被动式速率限制处理 可能导致体验波动。代码未实现主动令牌桶或请求队列，完全依赖 Microsoft Graph 返回 429 状态码后的退避重试，在高频调用场景下可能出现不可预测的延迟。
适合的目标群体
跨组织顾问与自由职业者 ：需要同时管理多个客户 Microsoft 365 租户，保持身份隔离
企业 IT 自动化团队 ：构建内部邮件通知、日历同步、联系人备份等自动化工作流
开发与运维人员 ：将 Office 365 数据集成至 CI/CD 通知、值班排班、会议提醒等 DevOps 场景
隐私敏感型个人用户 ：希望将个人 Outlook 与工作日历分离管理，避免数据混杂
使用风险
权限滥用风险 ：Mail.Send 权限允许 Skill 代表用户发送邮件，若账户凭证泄露，可能被用于钓鱼或垃圾邮件传播。建议启用 Azure AD 条件访问策略（如 MFA、IP 白名单）并监控"已发送邮件"文件夹异常。
令牌生命周期管理 ：虽然自动刷新机制减少了人工干预，但长期未使用的账户可能因刷新令牌过期（默认 90 天无活动）导致认证中断，需建立定期健康检查机制。
数据驻留与合规 ：Microsoft Graph API 数据流经微软全球基础设施，对数据主权有严格要求的组织需评估是否符合 GDPR、等保等合规框架。
配置复杂度门槛 ：Azure AD 应用注册流程对非技术用户存在学习曲线，Tenant ID/Client ID/Secret 的获取与保管需要一定的安全运维意识。