【免费下载链接】rocketride-serverHigh-performance AI pipeline engine with a C core and 50 Python-extensible nodes. Build, debug, and scale LLM workflows with 13 model providers, 8 vector databases, and agent orchestration, all from your IDE. Includes VS Code extension, TypeScript/Python SDKs, and Docker deployment.项目地址https://gitcode.com/gh_mirrors/ro/rocketride-server点击查看免费下载RocketRide 的tool_outlook_calendar工具节点源码位于 nodes/src/nodes/tool_microsoft_365/outlook_calendar把 Microsoft Graph 日历 API 的全部常用操作封装为 11 个 Agent 可直接调用的工具函数作用对象始终是当前操作者acting user的日历。本文以该节点的官方文档doc.md为主体结合 IInstance.py、client.py、共享的 graph_client.py 与 microsoft_access.py 源码以及 test_outlook_calendar.py 测试用例讲清每个工具的参数、Graph 调用、权限层级readonly/write、接线方式与底层安全机制。读完你可以直接在 RocketRide 管道里把 Outlook 日历能力交给 Agent让它查日程、建会议、约时间、增量同步并在出问题时用内置诊断工具定位权限故障。一、节点定位Agent 工具而非数据流节点tool_outlook_calendar是一个tool类节点没有数据 lane所有操作都是通过tool_function装饰器注册的、由 Agent 按需调用的函数见 IInstance.py 中outlook_calendar_check_connection的注册方式。它的能力面由两层访问层级access tier门控readonly只读 —— 列出/读取事件与日历、查询会议时间建议、忙闲日程、增量同步write默认在 readonly 之上追加创建/更新/删除事件、回复会议邀请、创建日历。日历事件删除不需要额外的硬删除开关不同于 Outlook Mail 的allowHardDelete门控write层级本身就足够这一点在 microsoft_access.py 的OUTLOOK_CALENDARAccessSpec 中可以看到该规格不声明任何 gate flags。二、完整工具面11 个 Agent Tools 与 Graph 调用映射下表完整继承自节点文档Graph 调用列给出真实请求端点工具Graph 调用用途层级outlook_calendar_list_eventsGET [/calendars/{id}]/calendarView在时间窗口内列出事件周期事件展开为单个 occurrencereadonlyoutlook_calendar_get_eventGET /events/{id}按 id 获取单个事件readonlyoutlook_calendar_create_eventPOST [/calendars/{id}]/events创建事件可选邀请与会者writeoutlook_calendar_update_eventPATCH /events/{id}更新事件——只改传入的字段writeoutlook_calendar_delete_eventDELETE /events/{id}删除事件writeoutlook_calendar_respondPOST /events/{id}/{accept\|decline\|tentativelyAccept}回复会议邀请writeoutlook_calendar_find_meeting_timesPOST /findMeetingTimes为一组与会者推荐会议时间readonlyoutlook_calendar_get_schedulePOST /calendar/getSchedule获取多个邮箱的忙闲日程readonlyoutlook_calendar_list_calendarsGET /calendars列出邮箱中的日历readonlyoutlook_calendar_create_calendarPOST /calendars新建日历writeoutlook_calendar_delta_syncGET /calendarView/delta通过 delta link 增量同步日历视图readonlyoutlook_calendar_check_connectionGET /calendar scope 报告诊断连接与 scope 覆盖情况诊断下面按功能域拆解每个工具的参数与返回全部以 IInstance.py 中注册的 input_schema 为准。2.1 事件读取outlook_calendar_list_events源码 IInstance.py#L185-L197必填参数start、endISO 8601 字符串如2026-08-11T00:00:00可选参数calendar日历 id缺省使用默认日历走 GraphcalendarView端点周期事件会被 Graph 展开为窗口内的单个 occurrence单次最多返回MAX_TOP 100条client.py#L41当窗口内事件更多时返回next_linkGraphodata.nextLink的续页 URL否则为null—— 返回结构{events, next_link}。测试 test_outlook_calendar.py 验证了next_link的暴露与末页为None两种行为。outlook_calendar_get_eventIInstance.py#L209-L214必填参数event_id直接GET /events/{id}返回经过清洗的事件对象。2.2 事件写入write 层级outlook_calendar_create_eventIInstance.py#L278-L286必填subject、start、end可选body正文文本、attendees邮箱地址数组、location地点显示名、calendar目标日历 id缺省默认日历start/end有两种合法形态见 schema 的oneOf普通 ISO 字符串YYYY-MM-DDTHH:MM:SS→ 自动包装为 UTC 的{dateTime, timeZone}已成形对象{dateTime, timeZone}→ 原样透传例如传America/New_York时不会被强制改成 UTCattendees会由 client.py#L70-L72 的attendee_list()映射为 Graph 收件人结构[{emailAddress: {address: e}, type: required}, ...]邀请由 Graph 自己发出write层级门控的是 Graph 调用本身不是独立的发送邀请步骤测试 test_outlook_calendar.py#L154-L180 断言了 POST 到/events、body 形状、UTC 包装、attendees 映射与 location 形状。outlook_calendar_update_eventIInstance.py#L340-L366必填event_id可选subject、start、end、body、attendees、locationPATCH 语义只修改传入的字段省略的字段保持不变attendees作为整体替换Graph 会向新名单重发邀请/更新若一个字段都没传会抛出ValueError: at least one field to update must be provided避免产生空 PATCH。outlook_calendar_delete_eventIInstance.py#L378-L385必填event_id成功后返回{deleted: event_id}。outlook_calendar_respondIInstance.py#L403-L414必填event_id、response枚举值限定accept/decline/tentativelyAccept可选comment请求路径为/events/{id}/{response}测试验证了非法枚举被拒绝、合法枚举请求/events/e1/accept以及readonly层级下被MicrosoftAccessError拦截test_outlook_calendar.py#L197-L220。2.3 会议时间建议与忙闲查询outlook_calendar_find_meeting_timesIInstance.py#L450-L469必填attendees邮箱数组可选duration_minutes默认 30取值范围 5–480、window_start、window_endwindow_start与window_end必须成对出现只传一个会被拒绝测试 test_outlook_calendar.py#L237-L246请求体attendees映射后的收件人数组、meetingDurationISO 8601 时长PT{duration}M、可选的timeConstraint.timeslots重要限制findMeetingTimes在 Microsoft 侧需要 delegated已登录用户上下文app-onlyclient-credentials认证下可能不被支持会收到 Graph 错误。这是节点文档和 README 都明确标注的前提。outlook_calendar_get_scheduleIInstance.py#L519-L530必填emails邮箱数组、start、endPOST /calendar/getSchedule返回{schedules: [...]}这是find_meeting_times在 app-only 场景下的替代方案。2.4 日历管理outlook_calendar_list_calendarsIInstance.py#L540-L546无参数GET /calendars$top100返回清洗后的日历数组outlook_calendar_create_calendarIInstance.py#L558-L565必填namePOST /calendars需要 write 层级。2.5 增量同步delta syncoutlook_calendar_delta_syncIInstance.py#L598-L614首次调用传start/endISO 8601 窗口走GET /calendarView/delta?startDateTime...endDateTime...后续调用把上次返回的delta_link传回只拉取自上次以来的变更返回{events, delta_link, next_link}测试验证了携带delta_link时直接 GET 该绝对 URL 而不是从 start/end 重建首次调用使用startDateTime/endDateTime查询参数三者都不传则报错test_outlook_calendar.py#L262-L291。2.6 连接诊断outlook_calendar_check_connectionIInstance.py#L152-L159做一次真实的GET /calendar探测并结合已授予的 OAuth scope 检查是否覆盖当前配置的 access tier返回connection_ok、accesstier、requiredScopes缺失时附missingScopes官方使用指引当任意日历操作报 scope 或权限错误时先调用它定位问题。三、在管道中接线把工具挂到 Agent 上节点文档给出了标准的tool节点接线方式通过control指定classType: tool并让from指向 agent 节点Agent 同时需要配套的memory节点{ id: tool_outlook_calendar_1, provider: tool_outlook_calendar, config: { type: tool_outlook_calendar }, control: [{ classType: tool, from: agent_rocketride_1 }] }接线完成后Agent 会在其指令上下文中发现全部outlook_calendar_*工具并按需调用。服务注册元数据定义在 services.outlook_calendar.jsonprotocol: tool_outlook_calendar://、classType: [tool]、prefix: outlook_calendar其中preconfig.default给出了节点创建时的默认配置authType: service、access: write其余凭据字段留空。四、配置参数与访问层级节点文档的配置表如下字段名按 RocketRide 的扁平化节点配置约定字段必填说明microsoft.authType是serviceEntra 应用client credentials或userOAuthmicrosoft.tenantId/microsoft.clientId/microsoft.clientSecretservice时Entra 应用注册凭据microsoft.userPrincipalNameservice时操作者 UPN —— app-only 调用目标为/users/{upn}microsoft.userTokenuser时由登录按钮填充broker 自动刷新outlook_calendar.access否readonly或write默认。由共享的OUTLOOK_CALENDARAccessSpec 解析scope从不手工填写4.1 访问层级 → Graph scope 映射定义在 microsoft_access.py#L178-L183 的OUTLOOK_CALENDAR AccessSpec(...)层级请求的 Graph scope能力readonlyCalendars.Read仅列表/读取事件与日历、会议时间建议、忙闲日程、delta-syncwrite默认Calendars.ReadWritereadonly 全部能力 创建/更新/删除事件、回复邀请、创建日历4.2 层级是如何强制生效的在节点生命周期里共享基类 IGlobal.py 的beginGlobal配置会被resolve_microsoft_access(cfg, spec)解析为一个不可变的MicrosoftAccess对象tier、scopes、can_write、flags。每个写工具在发起请求前调用self.IGlobal.access.require_write(op)若节点是readonly任何写工具都会抛出MicrosoftAccessError如...needs write access, but this node is read-only (accessreadonly)...提示提升 access 层级测试 test_outlook_calendar.py#L143-L150 正是用readonly层级验证create_event被拦截。同时validateConfig在保存配置时就会校验 tier 合法性未知 tier、非布尔 flag 都会告警并把 scope 覆盖检查与运行时检查统一到token_scope_report上避免三处检查漂移。五、凭据获取Entra 应用注册与用户 OAuth节点文档说明在Entra admin centerentra.microsoft.com→ App registrations注册应用授予 Graph 的Calendars.Read和/或Calendars.ReadWrite权限service用 application permissionuser用 delegated permission并完成管理员同意。完整的微软 365 工具服务共享配置教程见仓库内的 docs/docusaurus/apps/vscode/microsoft-oauth.md此处给出与 Outlook Calendar 直接相关的要点5.1serviceapp-onlyclient credentials按 microsoft-oauth.md 的注册流程注册单租户应用添加Microsoft Graph → Application permissionsreadonly层级授Calendars.Readwrite层级授Calendars.ReadWrite注意.All形式的 application permission 可满足同名 delegated scope 的检查对租户执行管理员同意application permission 是租户级的应用无法自我同意创建client secret并立即复制节点配置填入microsoft.authType: service、tenantId、clientId、clientSecret、userPrincipalName。userPrincipalName的作用非常关键application permission 本身不限定邮箱/日历节点的每个 Graph 调用都指向/users/{userPrincipalName}见 graph_client.py#L453-L462 的user_base()因此它决定了 app-only 凭据操作谁的数据。如需在 Microsoft 365 侧进一步收紧 app 的触达范围如用 Exchange Online 的New-ApplicationAccessPolicy把应用权限限制到特定邮箱安全组应在 Entra/Exchange 侧配置而非在 RocketRide 里配置。5.2user用户 OAuthmicrosoft.authType: user时节点配置面板的登录按钮microsoft.oAuthButton会把microsoft.userToken写入节点配置。该 token 由 RocketRide 的 OAuth broker 自动刷新broker 授予身份 scopeopenid email profile外加恰好等于所选层级的 Graph scopes最小权限原则授权后的 scope 固定在同意时刻如果事后把outlook_calendar.access从readonly提升到write需要断开并重新连接账户以重新同意新的 scope。5.3 安全底线绝不把凭据提交到仓库使用节点配置加密存储或 Entra 应用 secret 轮换运行时 token 端点被白名单约束为 Microsoft 自己的login.microsoftonline.comgraph_client.py#L179-L199token 中携带的 broker 刷新 URL 必须是https且 host 属于受信 broker内置oauth2.rocketride.ai/oauth.rocketride.ai自托管可用环境变量RR_OAUTH_BROKER_URL追加被篡改的存储 token 无法把凭据重定向到攻击者主机graph_client.py#L145-L176。六、底层实现共享 Graph 请求机制与安全边界所有微软 365 工具服务excel、word、onedrive、outlook mail、outlook calendar都通过 graph_client.py 这唯一一份凭据与请求机制执行调用outlook_calendar/client.py通过functools.partial绑定SERVICE GraphService(productOutlook Calendar, superset_scopes{Calendars.ReadWrite})client.py#L35。理解它有助于解释节点在真实 Graph 环境下的行为统一重试策略request()graph_client.py#L465429 与 5xx 指数退避最多 4 次尝试间隔 1s/2s/4s429 对所有方法重试Graph 未处理请求重放安全而5xx 只对幂等方法GET/HEAD/PUT/DELETE重试——因为 POST 可能在报错前已被执行重放可能重复创建事件/发送邀请服务端Retry-After会被采纳并钳制在 0–30 秒内防止 Graph 限流下发大数值把线程钉死失败快速暴露401/403 直接抛出GraphError错误信息点名 scope/application permission 与管理员同意AADSTS65001表示需要同意409/412 以冲突提示文件在编辑期间被改动需重读重试绝对 URL 白名单deltaLink / nextLink 这类调用方或 Graph 载荷带来的绝对 URL只有https且 host 为graph.microsoft.com时才允许携带 bearer token 发起graph_client.py#L499-L509凭据绝不会发往陌生主机两种认证实现AppOnlyAuthclient-credentials进程内缓存 token在过期前 60 秒刷新graph_client.py#L220与BrokerUserAuthbroker 签发的用户 token刷新协议为POST {oauth_server_url} {refresh_token: ...}→200 {access_token, expiry_date}任何非 200、200 但缺 access_token、expiry 畸形都会被当作合约违约并 fail loudgraph_client.py#L284。七、响应清洗Agent 友好的返回形状Graph 原生的 event/calendar JSON 字段繁多节点在返回前统一清洗成 Agent 真正需要的字段client.py#L79-L138事件id、subject、start、end、isAllDay、isCancelled、seriesMasterId周期系列的宿主 id、recurrence、webLink、bodyPreview外加展开的location仅displayName、organizer邮箱对象、attendees邮箱 出席状态、onlineMeeting仅joinUrl日历id、name、isDefaultCalendar、canEdit、ownerGraph 的 calendarowner本身已是emailAddress形态故原样透传与 event 的organizer深层嵌套不同见 client.py#L126-L139 的注释防漂移设计EVENT_SELECT/CALENDAR_SELECT这两个$select字符串由同一组字段元组拼接生成client.py#L94-L97保证线上请求选哪些字段与返回清洗哪些字段永远一致。八、测试与可验证性仓库为日历节点提供了专注的层级/请求形状测试 nodes/test/tool_microsoft_365/test_outlook_calendar.py仅 mock HTTP 层graph_client._urlopen真实执行IInstance方法readonly 拦截写工具create_event在 readonly 层级抛出MicrosoftAccessError创建事件请求形状POST 到/events或/calendars/{id}/eventsbody 含 UTC 包装的start/end、attendees邮箱映射、locationrespond 枚举校验非法值拒绝、合法值请求/events/e1/accept、readonly 拦截list_events 分页next_link存在与否两种分支find_meeting_times 窗口成对校验只传window_start或只传window_end都被拒绝且不发请求delta_sync携带delta_link时直接 GET 该 URL首次调用带startDateTime/endDateTime参数event_datetime助手普通字符串包装为 UTC、已成形 dict 原样透传非 UTC 时区不被覆盖、其他类型拒绝attendee_list助手邮箱数组 → Graph 收件人形状。九、常见问题排查综合节点 READMEoutlook_calendar/README.md与共享 READMEtool_microsoft_365/README.md的排查指引scope / 403 错误先调用outlook_calendar_check_connection若缺 scopeuser认证下断开重连微软账户service认证下补齐/同意 Entra 应用权限access是readonly但写操作报错每个写工具都会抛MicrosoftAccessError把outlook_calendar.access提升到writefind_meeting_times在 app-only 认证下失败该端点需要 delegated 上下文改用userOAuth或换用outlook_calendar_get_schedule获取忙闲信息创建/更新事件的时区陷阱需要非 UTC 时区时start/end传{dateTime, timeZone}对象而不是裸字符串裸字符串一律按 UTC 处理限流限流按 Entra 应用/租户维度计算节点对 429/5xx 自动指数退避重试。十、适用前提与边界节点操作的目标event id、calendar id永远是调用时参数不是节点配置——这是所有微软 365 工具服务共享的设计约定serviceapp-only认证下除findMeetingTimes外其余工具均可工作Calendars.ReadWrite这类 application permission 在租户内是全量的收紧到特定邮箱需在 Exchange Online 侧用应用访问策略完成RocketRide 本身只贯彻作用于/users/{upn}的约定限流与 Microsoft 侧能力如findMeetingTimes的 delegated 要求属于外部前提节点通过清晰的错误信息与诊断工具帮你快速归因。至此你已经掌握了tool_outlook_calendar节点的完整能力面11 个工具的调用方式与参数、readonly/write层级与 Graph scope 的对应关系、tool 接线方法、Entra 凭据配置流程以及底层共享 Graph 机制的可靠性设计。直接在 RocketRide 管道里把它接到 Agent 上就能让 LLM 安全地代管 Outlook 日历的读写、邀约与同步。赞分享【免费下载链接】rocketride-serverHigh-performance AI pipeline engine with a C core and 50 Python-extensible nodes. Build, debug, and scale LLM workflows with 13 model providers, 8 vector databases, and agent orchestration, all from your IDE. Includes VS Code extension, TypeScript/Python SDKs, and Docker deployment.项目地址https://gitcode.com/gh_mirrors/ro/rocketride-server点击查看免费下载相关推荐RocketRide 的 Outlook Calendar 工具节点基于 Microsoft Graph 的智能体日历编排实战指南RocketRide 的 Outlook Calendar 工具节点基于 Microsoft Graph 的智能体日历编排实战指南 本指南围绕 RocketR如何把 jcode 接入 AWS BedrockAPI key 与 IAM 凭据两种认证方式及最小 IAM 权限配置如何把 jcode 接入 AWS BedrockAPI key 与 IAM 凭据两种认证方式及最小 IAM 权限配置 如果你的 AWS 环境想直接用 jcodSmartDNS 3步本地DNS部署教程让家里所有设备自动访问最快IPSmartDNS 3步本地DNS部署教程让家里所有设备自动访问最快IP 你有没有觉得明明宽带是300兆打开某些网页还是要转好几秒很多时候锅不在带宽而在上一篇PHP Snowflake ID生成器常见问题解决方案下一篇es-optional-chaining与传统判空方式的性能对比谁才是效率之王创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考