核心用法
Temporal Cortex 采用分层路由架构，将日历操作拆分为 5 个层级：
| 层级 | 功能 | 代表工具 |
|:---|:---|:---|
| Layer 0 | 身份发现 | `resolve_identity` |
| Layer 1 | 时间上下文 | `get_temporal_context`, `resolve_datetime`, `convert_timezone` 等 5 个工具 |
| Layer 2 | 日历操作 | `list_calendars`, `list_events`, `find_free_slots`, `check_availability` |
| Layer 3 | 可用性查询 | `get_availability`, `query_public_availability` |
| Layer 4 | 预订执行 | `book_slot`, `request_booking` |
标准工作流：Discover → Orient → Resolve → Query → Act。系统强制要求：必须先调用 list_calendars 发现日历，使用 get_temporal_context 获取当前时间（禁止假设），check_availability 冲突检查必须在 book_slot 之前执行。
双模式运行：
- Layer 1（时间工具）：零配置、纯本地计算、零网络请求，开箱即用
- Layer 2-4（日历工具）：需一次性 OAuth 配置，凭证本地存储于
~/.config/temporal-cortex/
---
显著优点
1. 多平台统一：原生支持 Google Calendar、Microsoft Outlook/Graph、标准 CalDAV，一套接口覆盖主流日历生态
2. 安全架构严谨：Rust 编译二进制、SHA256 校验链（GitHub Release 独立发布 checksums + npm 内嵌校验双重验证）、安装失败即中止执行
3. 隐私优先设计：OAuth Token 仅存本地，MCP Server 零回连 Temporal Cortex 服务器，Telemetry 默认关闭
4. 路由智能化：自动识别用户意图（"下周二下午 2 点开会"→自动链式调用 datetime → scheduling）
5. 容器化友好：官方提供 Docker 隔离方案，凭证通过 volume mount 隔离，无需宿主机 Node.js
---
潜在缺点与局限性
1. OAuth 配置门槛：Layer 2-4 功能需用户自行完成 Google/Microsoft/CalDAV 的 OAuth 应用注册，非技术用户可能受阻
2. Rust 二进制信任假设：虽然提供可审计源码与 CI 构建透明性，但多数用户实际依赖 npm 自动下载的二进制，独立验证率预计较低
3. 功能边界限制：不支持 Exchange On-Premises（仅限 Graph API）、不支持复杂会议室资源预订、无日历共享权限管理
4. 错误恢复机制：文档未明确说明网络中断或 API 限流时的重试策略
5. 生态锁定风险：MCP 协议虽开放，但深度依赖 Claude/Cursor 等特定客户端生态
---
适合人群
- 技术型知识工作者：需跨平台日历统一管理的开发者、产品经理、顾问
- 隐私敏感用户：拒绝 SaaS 日历中间商、要求凭证本地存储的个人或小型团队
- AI 工作流集成者：希望在 Claude/Cursor 中通过自然语言完成会议调度的高级用户
---
常规风险
| 风险类别 | 具体描述 | 缓解措施 |
|:---|:---|:---|
| **供应链攻击** | npm 包或 GitHub Release 被篡改 | 双重 SHA256 校验 + 建议独立验证 |
| **OAuth Token 泄露** | 本地凭证文件权限配置不当 | 目录权限限制 + Docker 隔离 |
| **Prompt Injection** | 恶意事件标题/描述注入 | 内置 prompt injection firewall |
| **误预订风险** | AI 自主执行未经确认的预订 | 强制确认流程（`confirm_before_booking`） |
| **时区错误** | 夏令时或跨时区计算偏差 | 强制 `get_temporal_context` 获取权威时间 |
总体评估：Temporal Cortex 是 MCP 生态中日历技能的安全标杆实现，适合具备基础技术能力、重视数据主权的用户。建议生产使用前执行文档推荐的「预运行验证」流程（npm pack --dry-run + 独立 checksum 校验）。