在一个真实项目中把 DeepSeek Harness 委派为 iPolloWork 子代理
Devin-AXIS/iPolloWork 容易在第一眼被理解错：站点把它归到「视觉能力」分类，但它的真实身份是一个多引擎智能体工作台。如果你已经在用 dsh，值得判断的不是「它会不会取代 dsh」，而是「在 dsh 之上再挂一层工作台，值不值」。
底子先摆出来：Star 6,547，综合分 72.5，最近提交 0 天前，已提供中文文档。信任档位是已验证——本站于 2026-09-16 真实安装成功（L4 · 真实安装）；安装检查结论为「需源码安装」，因为缺少 main/exports/bin 入口声明，且 package.json 标记 private、未发布到 npm。Node 要求 >=22。
它真正想解决的问题
README 的定位是「面向个人与智能体团队的企业级、本地优先的多引擎智能体工作台」，为 Codex Harness、DeepSeek Harness 和 OpenCode 打造统一工作空间：统一的插件与 Skills、多智能体项目与任务，以及可编辑的代码、文档、演示文稿、设计和视频。
核心主张在最后一条：当产出是演示文稿、网页、视觉设计或视频时保持可编辑，不会变成成品文件或聊天记录。它明确说自己不是替代单一编码智能体，而是通过明确的兼容边界连接 Codex、DSH、OpenCode 以及未来的运行时，同时保留各生态的原生优势。所以别拿它跟 dsh 做功能对位，要看它作为「调度层」是否解决你的问题。
认知一：DSH 不是默认运行时（P2-A）
按 README：OpenCode 是当前默认的本地执行运行时；DeepSeek Harness 是作为可选的对等运行时和子智能体委派目标集成的；Codex 则通过 ipollowork-ui-mcp 控制界面连接。
所以 DSH 在这里的角色有三种可能：可选的对等运行时，与 OpenCode 平级但需主动选；子智能体委派目标，任务在需要时把限定范围内的工作委派给 DSH 子代理，再把结构化的进度与结果带回同一项目；独立演进的组件，README 明确 OpenCode 与 DSH 保持独立组件，不会使 iPolloWork 成为任一运行时的分支。
对我项目真正有用的是第二种：原来一个 dsh 会话从头干到尾，上下文越滚越长，中途换方向很痛；改成委派后边界清楚了，外层管项目结构、产物和跨引擎视图，内层 DSH 子代理只负责被限定的那块工作。
但必须接受一个现实：每个运行时都保留自己的代理、Skills、插件和执行模型，这些路径共享同一工作台，而不假装每个运行时都具有相同的原生能力。「OpenCode 能做，DSH 也一定能做」并不成立。
如果目标只是在 DSH 里跑它的创意插件，不必先装工作台本体：
npx @deepseek-ai/dsh plugin --profile web add deepseek-idesign deepseek-ippt deepseek-ivideo
npx @deepseek-ai/dsh web
打开 http://127.0.0.1:3080，开始对话，然后选择 Design、PPT 或 Video。
认知二：Codex 走的是 MCP，不是第四个引擎（P2-B）
关键一句：MCP 是该路径的集成协议，而不是与 Codex、DSH 和 OpenCode 并列的另一个智能体引擎。README 同时写明：Codex 兼容性目前使用 MCP 控制接口，而不是声称拥有原生 Codex 引擎适配器。
后果很实际：界面里的 Codex 连接，本质是「用 MCP 去控制这个工作台的界面」，而不是「工作台内置了一个 Codex 引擎」，期待后者的人会失望。反过来，对已有 MCP 客户端习惯的人是加分项——你的 MCP 客户端可以直接驱动桌面/UI 这一层。代理执行、任务状态和流式传输在共享引擎边界处规范化，而引擎原生行为保留在各自适配器内部，这就是它能既统一、又不假装统一的原因。
认知三：Cloud 可选，但边界明确（P2-C）
README 的措辞是：Cloud 连接是可选的。本地 iPolloWork 无需账户或商业服务即可运行。 对个人开发者这是实打实的优惠——整套东西可以完全在本地跑起来，不注册、不登录。
但如果你要连 Cloud，就需要账户：
./ipollowork dev:cloud http://localhost:3100
它会创建隔离的开发配置文件，把身份验证与 Cloud API 指向给定 URL，并要求 Cloud 登录，不会更改正常的本地 iPolloWork 配置文件；远程或自托管同理，把地址换成自建 URL 即可。iPolloCloud 承担的是身份、组织、权益、托管工作器生命周期、管理和商业 Apps，所以判断标准很简单：你需不需要组织与商业治理。
落地时撞上的几个现实
安装有两条路：桌面应用直接用 GitHub Releases 上的官方安装程序（按系统与 CPU 架构选 .dmg / .exe / .AppImage），或者从源码起。
走源码则是 corepack enable 后执行 ./ipollowork setup 与 ./ipollowork dev：前者安装锁定版本的工作区依赖，后者准备 OpenCode 与 Orchestrator sidecar、启动 UI 并打开 Electron 桌面客户端。开发模式使用隔离的 iPolloWork/OpenCode 状态，不会覆盖用户正常的 OpenCode 配置，这点比我预期的重要。
依赖也偏重：Git、Node.js 22 或更高、pnpm 11（通过 Corepack 启用）、Bun 1.3.10 或更高（用于构建本地 Orchestrator sidecar），平台侧还需各自的桌面构建工具链。另外 OpenCode 在首次桌面构建期间作为独立 sidecar 下载并准备，iPolloWork 不 fork 也不重写它，因此首次构建必须出网。
总结
如果你已经在用 dsh，痛点又确实是「项目层面的产物、结构、跨引擎视图没人管」，那么 DeepSeek Harness Hub 插件清单 里收录的这个工作台值得试一次；但如果痛点只是「dsh 的界面不够顺手」，多加这一层只会增加变量。
适合与不适合
适合：已经在用 dsh、需要把限定范围的工作切出去委派给子代理的人；产出含演示文稿、网页、视觉设计或视频、且要求结果保持可编辑的团队；要在一个项目里同时对接多个运行时、又不希望共享状态被污染的开发者；只想在 DSH 里体验 Design/PPT/Video、暂时不想动源码构建的人。
不适合：把 dsh 当唯一引擎的人——DSH 只是可选的对等运行时，默认运行时是 OpenCode，指望它变成「dsh 专用外壳」会落空；期待界面里内置 Codex 引擎的人——那条路是 MCP 控制界面，不是原生引擎适配器；打算以三人以上规模在组织内使用、或作为商业服务对外提供的人——这需要事先书面授权，不是装完就能用。
标签：iPolloWork、DeepSeek Harness、多引擎工作台、子代理委派
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。