AI 应用人工智能AI Agent本地部署前端后端工作流自动化【免费下载链接】ekko-studioEkko Studio is a local-first AI workspace for multi-agent chat, coding, and visual workflows, available on desktop and the web.项目地址https://gitcode.com/gh_mirrors/he/ekko-studio点击查看免费下载导读本文围绕 Hermes StudioEkko Studio 的桌面/Web 本地优先 AI 工作区中的移动端授权卡片超时机制展开聚焦移动日历与提醒Mobile Calendar Reminder同意等待时长这一变更将原本 30 秒的设备端硬上限统一为与 App 通用同意卡片一致的5 分钟300,000ms默认值并使服务端与设备端 deadline 保持一致。读完本文你将理解 MCP/OpenAPI 对超时参数的约束、服务端如何对timeout_ms做边界钳制clamp、expires_at_ms如何在事件中随卡片刻画 deadline以及过期删除保护与未过期响应放行的完整链路并可通过仓库中的测试用例进行验证。本文的技术依据为仓库文档 docs/chat-chain-changes/2026-09-05-mobile-consent-timeout.md变更记录以及服务端源码 chat-run.ts 与对应测试 run-chat-mobile-calendar.test.ts。变更背景30 秒设备端上限带来的不一致此前移动日历与提醒calendar / reminder类请求的设备端同意等待被限制在 30 秒内而 App 中其他通用同意卡片generic consent card则采用 5 分钟等待时长。这种不一致会造成两类问题用户体验不一致用户在同一 App 内处理不同授权卡片时等待规则完全不同日历/提醒卡在 30 秒后即失效服务端与设备端 deadline 错位设备端按 30 秒兜底而服务端任务可能仍在等待或按其他规则判定导致卡片已过期但后端仍挂起或后端已超时但卡片仍展示的竞态。本次变更的核心诉求见文档 front-matter 的impact字段即默认改为 5 分钟与 App 通用同意卡片保持一致并让服务端与设备端 deadline 相匹配取代原先 30 秒的设备端上限。超时参数的三重约束MCP、OpenAPI 与服务端钳制文档指出MCP and OpenAPI allow 3–300 seconds and advertise a five-minute default.这句话揭示了移动端同意超时的完整参数契约层允许范围默认值说明MCP 工具契约3–300 秒即 3000–300000ms300000ms5 分钟Agent 调用移动日历/提醒工具时的timeout_ms参数约束OpenAPI 描述3–300 秒300000ms面向 App/第三方集成的接口文档同步声明服务端实现3–300 秒钳制300000msboundedMobileCalendarTimeout兜底与边界钳制在服务端源码 chat-run.ts 中这一契约被落实为三个常量与一个钳制函数const MOBILE_CALENDAR_MIN_TIMEOUT_MS 3_000 const MOBILE_CALENDAR_MAX_TIMEOUT_MS 300_000 const MOBILE_CALENDAR_DEFAULT_TIMEOUT_MS 300_000 function boundedMobileCalendarTimeout(value: unknown): number { const numeric Math.round(Number(value)) if (value null || !Number.isFinite(numeric) || numeric 0) return MOBILE_CALENDAR_DEFAULT_TIMEOUT_MS return Math.max(MOBILE_CALENDAR_MIN_TIMEOUT_MS, Math.min(MOBILE_CALENDAR_MAX_TIMEOUT_MS, numeric)) }该函数的行为可以归纳为非法/缺省回退默认值timeout_ms为null、undefined、非有限数值或 ≤ 0 时直接采用 5 分钟默认值上限钳制超过 300000ms 的显式值会被压回 300000ms例如调用方传入 600000ms 时实际生效 300000ms下限保护小于 3000ms 的值会被提升到 3000ms避免过短的同意窗口导致用户来不及操作取整非整数毫秒数会被Math.round归一。文档特别强调Explicit shorter waits remain supported显式更短的等待仍然受支持——即 3–300 秒区间内的自定义值如 3000ms、15000ms 依然可以生效只有越界与缺省才被钳制到边界或默认值。服务端请求链路timeout_ms 与 expires_at_ms 如何随事件下发requestMobileCalendar与requestMobileHealth是服务端发起移动端同意等待的两条核心路径chat-run.ts二者共享同一套超时逻辑const requestId randomUUID() const timeoutMs boundedMobileCalendarTimeout(options.timeoutMs) const event request.capability reminder ? reminder.requested : calendar.requested const idKey request.capability reminder ? reminder_request_id : calendar_request_id return new PromiseMobileCalendarResponse((resolve) { const timer setTimeout(() { this.finishMobileCalendarRequest(requestId, { status: error, error: { code: calendar_failed }, }) }, timeoutMs) timer.unref?.() this.pendingMobileCalendar.set(requestId, { sessionId, profile, target, request, resolve, timer }) this.emitMobileCalendarEvent(profile, sessionId, event, { event, [idKey]: requestId, ...request, target_device_id: target.deviceCode, target_user_id: target.userId, target_profile: target.profile, timeout_ms: timeoutMs, expires_at_ms: Date.now() timeoutMs, }) })关键设计点单一超时源timeoutMs只计算一次同时驱动服务端定时器、事件里的timeout_ms与expires_at_ms从源头杜绝三者不一致绝对 deadline 优先expires_at_ms Date.now() timeoutMs以绝对时间戳形式下发设备端/App 只需与本地时钟比对即可判定过期无需自行换算相对时长请求去重同一会话已存在 pending 的日历/提醒请求时新请求会被拒绝A mobile calendar or reminder request is already pending配合单会话单卡片语义避免同意风暴定时器不阻塞退出timer.unref?.()使该定时器不阻止进程退出属于后台等待型定时器设备路由隔离事件通过target_device_id / target_user_id / target_profile精确投递到对应移动设备房间见 mobile-device-target.ts 的mobileDeviceRoom命名空间mobile-consent:deviceId:profile非目标设备的迟到响应会被mobileEventAllowed拒绝。移动健康health请求路径requestMobileHealth采用完全相同的boundedMobileCalendarTimeout钳制逻辑超时时返回status: error与error.code: health_timeout仅额外要求目标平台为 iOSiPhone/iPad。过期删除保护与未过期响应的放行语义文档强调 Expired delete protection remains过期删除保护保持不变。这在 run-chat-mobile-calendar.test.ts 的用例 requires fresh deletion confirmation and rejects late responses 中得到了完整验证1. 发起 reminder delete 请求timeoutMs: 3000事件携带 expires_at_ms now 3000 2. 设备在过期前回复 status: denied → 请求正常 resolve 为 denied 3. 同一会话再次发起删除请求推进 3001ms 后 → 请求 resolve 为 status: error 4. pending 表清空pendingMobileCalendar.size 0 5. 此时设备端再以第一次的 reminder_request_id 回复 success → 因请求已过期删除响应被丢弃pending 表仍为 0这说明删除类敏感操作要求新鲜确认一旦卡片超时服务端立即清理挂起状态迟到响应无法再提交删除动作——这是对删除等不可逆操作的关键安全护栏。与之相对未过期的响应无论 accept 还是 denied都可在剩余窗口内正常放行。默认值与边界的可验证行为测试用例视角测试 run-chat-mobile-calendar.test.ts 直接对应本次变更的验收标准覆盖了文档描述的五分钟后端默认it.each([undefined, null, 0, 600000, 300000])(uses a matching five-minute card/server deadline for %s, async timeoutMs { const promise server.requestMobileCalendar({ sessionId, profile, capability: reminder, action: list, purpose: test, timeoutMs }) const event emitted.find(entry entry.event reminder.requested)!.payload expect(event.timeout_ms).toBe(300000) expect(event.expires_at_ms).toBe(Date.now() 300000) await vi.advanceTimersByTimeAsync(60001) expect((server as any).pendingMobileCalendar.size).toBe(1) // 60s 后仍存活 await vi.advanceTimersByTimeAsync(239999) await expect(promise).resolves.toMatchObject({ status: error }) expect((server as any).pendingMobileCalendar.size).toBe(0) // 300s 整到期清理 })该用例用参数化方式断言无论调用方传入undefined、null、0、600000还是300000服务端最终下发的timeout_ms一律是300000expires_at_ms一律是now 300000。这正对应boundedMobileCalendarTimeout的三类行为——缺省/非法回退默认、上限钳制、默认值直通。时间推进验证还精确刻画了生命周期60 秒时挂起请求仍在印证从 30 秒放宽到 5 分钟后的存活区间推进满 300 秒后请求以error收尾并清理。App / 原生侧兼容性无需重建文档明确指出Current App already consumes timeout_ms/expires_at_ms so no App/native rebuild is required.即服务端下发协议字段timeout_ms/expires_at_ms早已被现有 App 消费本次变更纯粹是服务端默认值与钳制逻辑的调整无协议破坏字段名与语义未变App 无需改版即可识别新的 5 分钟窗口无原生重建成本iOS/Android 端只需按其既有逻辑渲染卡片倒计时依据expires_at_ms计算剩余时间即可无缝获得更宽松、与通用卡片一致的等待体验兼容旧行为显式传入更短超时的调用方如 Agent 侧指定 3000ms依然按原样工作符合 Explicit shorter waits remain supported。与同类等待机制的横向对照移动端同意超时并非孤立设计仓库中还存在多个共享5 分钟语义的等待/授权机制可作为理解本机制的参照机制常量/默认值位置移动日历/提醒同意MOBILE_CALENDAR_DEFAULT_TIMEOUT_MS 300_000chat-run.tsAgent 澄清请求CLARIFICATION_TIMEOUT_MS 300_000clarification-runs.ts设备配对请求 TTLREQUEST_TTL_MS 5 * 60 * 1000devices.tsApp 授权码 TTLAPP_AUTHORIZATION_CODE_TTL_SECONDS 5 * 60app-connections-store.ts群聊上传会话 TTLGROUP_CHAT_UPLOAD_SESSION_TTL_MS 5 * 60 * 1000chunked-upload.ts从源码结构看这些机制普遍采用服务端定时器 绝对过期时间戳 挂起表清理的同一模式本变更把移动日历/提醒对齐到这一既有节奏属于一致性收敛而非引入新范式。可以推断统一 5 分钟窗口也有助于用户在锁屏/切后台后仍有余裕完成授权同时绝对时间戳语义天然免疫相对计时的漂移误差。总结与排查建议本次变更最终落地为三点默认统一移动日历/提醒同意等待默认 5 分钟与 App 通用同意卡片一致取代旧的 30 秒设备端上限边界钳制timeout_ms允许 3000–300000ms越界钳制、缺省回退默认值显式短等待仍受支持协议兼容服务端下发timeout_ms与expires_at_ms供卡片渲染 deadlineApp 无需重建过期删除保护语义不变。实际排查移动端同意失效问题时建议按以下顺序核对事件负载中的expires_at_ms是否等于Date.now() timeout_ms单点计算正常应恒等timeout_ms是否落回 300000ms先确认调用方是否传入了越界值如 600000ms其会被钳制为 300000ms 而非直接生效设备端是否基于绝对时间戳而非相对时长计算剩余时间避免时钟偏差导致提前过期删除类操作的响应是否在超时后到达——按设计会被静默丢弃属预期安全行为。如需深入验证或复现可直接阅读服务端实现 chat-run.ts 与 L560-L676并运行测试 run-chat-mobile-calendar.test.ts关键用例位于 L124-L166。赞分享AI 应用人工智能AI Agent本地部署前端后端工作流自动化【免费下载链接】ekko-studioEkko Studio is a local-first AI workspace for multi-agent chat, coding, and visual workflows, available on desktop and the web.项目地址https://gitcode.com/gh_mirrors/he/ekko-studio点击查看免费下载相关推荐Hermes StudioEkko Studio移动端日历与提醒MCP 一次性授权访问机制深度解析Hermes StudioEkko Studio移动端日历与提醒MCP 一次性授权访问机制深度解析 本文围绕 Hermes StudioEkko StuAI 应用人工智能AI Agent本地部署前端后端工作流自动化Hermes Studio 移动设备目标绑定将日历与提醒授权锁定到经过验证的发起设备Hermes Studio 移动设备目标绑定将日历与提醒授权锁定到经过验证的发起设备 导读 本文基于 Hermes Studio 变更记录 docs/chatAI 应用人工智能AI Agent本地部署前端后端工作流自动化Hermes StudioEkko Studio移动端日历/提醒「单条确认删除」契约详解精确身份校验、deletedtrue 回报与有界确认期限Hermes StudioEkko Studio移动端日历/提醒「单条确认删除」契约详解精确身份校验、deletedtrue 回报与有界确认期限 本文围AI 应用人工智能AI Agent本地部署前端后端工作流自动化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
