Orkas：一个会自己排班的 AI 团队

先看一个具体的痛点。你让 AI 帮忙做市场调研，它交回一份报告；但接下来呢？做 PPT 的、写文案的是谁？这些活要不要你一项项派下去、盯进度、催交付、拼成一套完整方案？Orkas 的出发点正是这个断点——它不满足于"回答一个 prompt"，而是把 AI 组织成一个有岗位、有工单、有排班的团队。

图：Orkas 桌面端，任务会话与最终交付成果

Commander 与 16 个内置专家

Orkas 的核心角色是 Commander：你告诉它目标，它拆解成待办、挑选合适的 Agent、技能与连接器；当没有更好的专家时，它自己就把分析、写作、研究、文件处理做掉。应用内置 16 个专业 Agent，各有独立的技能、记忆与工具，覆盖研究分析（DeepResearcher 做有证据链的可溯源调研、SeoGeoAgent 做技术审计与 GEO 引用率分析、StockAnalyser 做股票研究与回测）、内容媒体（ContentWriter、PptMaker、ImageStudio、VideoStudio、VoiceStudio、UIDesigner）、工程与办公（ProductDeveloper 做仓库感知的工程实现、OfficeWorker 产出 Word/Excel/PPT/PDF）以及五个电商 Agent（选品、文案、评论分析、销售分析、运营）。市场里还有 30 多个 Agent 可浏览，你也可以描述一个角色让 Commander 现造一个。

VideoStudio 有个功能值得单说：给它一段参考视频，它分析出钩子、信息顺序、视觉节拍与行动号召，然后先给出"保留什么、替换什么"的方案再开工，用你自己的产品和素材复刻叙事结构。这个"先拆解后生产"的流程设计，比一键生成靠谱得多。

把已有 CLI Agent 编进同一个团队

这是 Orkas 与同类产品差异最大的地方：它不要求你放弃已有的 Claude Code、Codex、OpenCode，也不排斥 OpenClaw 与 Hermes-Agent。这些外部 CLI 以本地会话形式与内置专家并排运行，Commander 统一维护一份计划并把各环节分给最擅长的一方——一次对话里可以既修 bug、又做 code review、又起草 release note。HyperFrames 这类开源工具也以同样方式接入。

调度机制有三个工具：dispatch_to 运行指定 Agent 并返回结果（可等待也可异步完成时通知）、hand_off_to 移交剩余工作并结束当前轮次、run_worker 跑一个匿名的隔离子任务——不携带对话历史、不带具名 Agent 的技能，天然适合并行的脏活。具名任务与匿名 worker 有各自独立的并发控制。

让工作持续跑下去：项目、待办、自动化

Projects 持有目标、规则、记忆与文件，新对话直接从项目状态起步，不用每次重新交代背景。To-dos 与 Auto-advance 让团队自己认领下一项待办并把成品带回来给你审。Scheduled automations 支持按小时、日、周、月重复执行，v1.9 起在电脑唤醒或应用启动时会补跑最近 12 小时内错过的任务。Connectors 接 Gmail、Calendar、Sheets、Drive、Notion、Slack、Shopify、Stripe 等，默认在发送、发布、删除前先问一句。

上下文预算与记忆机制

这类 Agent 应用真正的技术门槛不在 UI，而在上下文治理。Orkas 的运行时按所选模型的可用输入容量做预算，把提示词、工具与持久状态都算进去；已完成的对话走有限近期窗口，长任务用 checkpoint 压缩早期过程消息但保留近期工作；文件读取、修改、命令执行都有结构化记录，能穿越上下文压缩存活。

记忆分三层：持久笔记保存用户偏好、项目事实与各 Agent 的可复用知识；Library 把文档切段后建本地 SQLite 向量索引，embedding 模型在你机器上跑；历史会话则通过 chat_history 单独检索。执行侧有会话锁、并发上限、工具轮次预算、进度检查点与重复调用检测，外加阶段感知的空闲看门狗，任务卡住或绕圈时能被收住。

还有一层"从活动中学习"：应用空闲时后台复盘新的 Agent 活动，可能更新该 Agent 的 COMPETENCE.md 自评、LEARNING_STRATEGIES.md 可复用方法或学到的技能——依赖的是新活动量而非任务数，也允许得出"没什么值得保存"的结论。

上手门槛

最省事是下载打包版：macOS 12+ 与 Windows 10+ 的安装包免费并送 500 积分，不用自己的 API Key 也能先试。源码运行是 Linux 目前唯一的方式，要求 Node 22.12+（推荐 24 LTS）、npm 11.11+，macOS/Windows/Linux glibc 2.34+ x64 或 arm64，Alpine 等 musl 发行版不支持。

./run.sh（Windows 用 run.cmd）会在首次启动时准备锁定的 npm 依赖树，并下载安装 Python、uv、Node、约 95MB 的 embedding 模型、OfficeCLI、FFmpeg、whisper.cpp 与多语种语音模型；Linux 启动还会在 Electron ABI 下校验平台原生模块与 Whisper 运行时。原生依赖出错时用 npm run native:repair 修复 SQLite、SQL、sqlite-vec 与 sharp。数据落在 ~/.orkas/（Windows 是非系统盘上最小的盘符的 .orkas\）。

争议与局限

首先要说明的是开源版与打包版的能力落差：共享项目、云同步、应用发布只在打包版提供，开源构建不支持。这在同类"开源 + 商业化"项目里常见，但对期待完全自托管的团队是硬约束。

其次是自托管的实际成本不低：一键脚本要下载并执行来自多个来源的二进制（Python、uv、Node、FFmpeg、whisper.cpp），供应链面比一般 npm 项目宽得多；模型也是二选一——自带密钥直连供应商，或用内置模型走 Orkas 托管服务，两条路径的数据流向和合规口径并不一致。

最后是自治的双刃剑：Auto-advance 与定时补跑机制让 Agent 在你不盯着的时候也在动手。设计上留了审批环节（连接器默认发送前询问），但这类"持续运行的自动化"天然要求用户理解并信任它的执行边界。仓库只有 7 个 open issue，看起来维护质量不错，但版本号已经走到 2026.10.27 这种日期式版本，迭代节奏很快。

行业意义

Orkas 的定位很有代表性：它不是又一个 Agent 框架，而是把"多 Agent 编排"做成一个面向业务人员的产品形态——Commander 是项目制里的技术负责人，16 个专家是岗位，To-do 是工单，Auto-advance 是排班表，Scheduled automation 是值班表。这个类比不是修辞，README 里"一个盒子里一个助手是错误的形状"的判断，指向的正是 2026 年多 Agent 产品的共同命题。

更值得注意的是它把外部 CLI Agent 纳入同一个团队的思路。当 Claude Code、Codex 这类命令行 Agent 已经很强大时，与其重造轮子，不如把它们当成已有员工编进组织。这可能是多 Agent 框架更现实的技术路线：不替代工具，而是调度工具。

6.1K star 与 MIT 许可的组合，说明"本地优先、可读无黑箱"这组卖点正在成为开源 Agent 桌面应用的标准叙事。