iPolloWork Docs

运行时生命周期

追踪 iPolloWork 任务从桌面端到本地服务、OpenCode sidecar、审批与会话归属产物的完整路径。

iPolloWork 不是只运行在浏览器里的聊天客户端。一个标准桌面任务会经过少量且明确的边界:Electron shell 提供工作界面,本地服务拥有面向工作区的 API,OpenCode 作为外部智能体 sidecar 运行。可选的 Cloud 控制平面提供组织能力,不会替代本地执行路径。

运行时归属一个任务经过四个有明确所有权的边界

每个边界都有不同的所有者、凭据形态与失败模式。适配器应保留在边缘,而不是让任何一层无声地模拟另一层。

01
工作界面

桌面端与浏览器 UI

Electron shell

负责原生生命周期与可见的桌面窗口。

会话界面

呈现聊天、Design、Video、文件与审核控制。

02
工作区运行时

本地 iPolloWork Server

工作区 API

负责工作区配置、文件会话、扩展、产物与审批。

本地状态

让文件系统驱动的工作贴近工作区所有者。

03
智能体 sidecar

通过受支持 API 接入 OpenCode

OpenCode runtime

通过受支持的服务端、CLI、插件与配置接口执行智能体任务。

工具与 Skill

为任务增加能力,不会变成第二个工作区数据库。

04
可选控制平面

iPolloWork Cloud / Den API

组织状态

负责身份、角色、共享模型、托管 Worker 与可复用组织配置。

不在本地环路中

未配置组织控制平面时,本地桌面任务仍然可用。

任务路径

执行追踪从目标到可检查产物

任务从执行、审核到后续修改始终保持会话范围。

  1. 01定义

    用户在指定工作区与工作界面中创建或继续一个有明确目标的会话。

  2. 02解析

    本地运行时解析项目上下文、已批准工具与当前会话归属产物。

  3. 03执行

    OpenCode 通过受支持的 sidecar 边界执行智能体任务,工具调用保持可观察。

  4. 04审核

    结果在对应的可编辑工作界面中打开,用户可修改、批准或继续。

会话拥有什么

会话是持续工作的最小单元。它持有任务上下文、活动、工具历史以及当前产物的关系。Design 与 Video 被刻意设计为会话归属:修改同一个交付物时应在原会话中继续;换仓库、换所有者或换权限边界时应新建会话。

运行时不应无声地把任务移动到其他工作区,也不应改写无关会话。尤其是 Video 合成会从会话对应的项目路径加载;Design 产物保持为可编辑的项目文件,而不是被压缩成截图。

按工作目标选择启动路径

需求应使用的真实边界原因
在桌面应用中工作Desktop shell 与本地服务原生生命周期与 UI 保持在同一应用版本中。
开发浏览器 UIpnpm dev:ui将循环限制在 React/Vite 工作界面。
无桌面端运行智能体 Hostipollowork startipollowork serveOrchestrator 同时启动并观察 Server 与 OpenCode sidecar。
维持多个工作区待命ipollowork daemon startRouter 保持一个 OpenCode 进程,并按目录切换工作区上下文。

项目 launcher 是开发时更安全的默认入口,因为它会准备相容的本地状态。需要 CLI-first 运行时而不是桌面窗口时,Orchestrator 才是明确的 Host 边界。

审批是运行时契约的一部分

本地服务将普通客户端访问与主机所有者操作区分开来。工作区写入必须经过审批。开发期间可以有意识地开启自动审批以缩短循环;真实的共享或远程工作区中,手动审批让操作员保持控制权。

审批边界先观察请求动作,再改变工作区状态

收到请求不等于已得到权限,也不等于写入已完成。

  1. 01请求

    桌面端或远程客户端请求本地服务执行一项面向工作区的操作。

  2. 02授权

    服务校验调用方 token 以及所需的 owner 或 collaborator 范围。

  3. 03审批

    手动模式等待 Host 决策;自动模式是明确的本地开发配置。

  4. 04记录

    客户端重新读取资源、事件流或产物,而不是假设写入已经成功。

Sidecar 与隔离

OpenCode 是外部运行时依赖。iPolloWork 通过文档化的 API、CLI、插件与配置集成,而不是修改 OpenCode 内部实现。Orchestrator 可从 bundled、downloaded 或显式 external 来源解析 iPolloWork Server 与 OpenCode sidecar。源码开发时,launcher 会启用隔离的 OpenCode 开发 profile,避免误复用个人配置、认证、缓存与状态。

因此 sidecar 变更必须端到端检查:验证真正消费它的 UI 或客户端路径,而不只是验证进程能启动。

读取正确的健康信号

先用 health 端点确认可达性,再通过 status 与 capabilities 理解服务实际解析出的能力。针对具体工作区,使用工作区专属的 health、配置、事件与扩展路由。使用 Orchestrator 作为 Host 时,可运行 ipollowork status 同时检查 iPolloWork Server 与 OpenCode sidecar。

有关运维命令、sidecar 来源、sandbox 选项和恢复证据,请继续阅读 Orchestrator 与 Sandbox可观测性与恢复