Orkas（Orkas-AI/Orkas）：本地优先多智能体桌面团队，用宿主侧硬闸门管住 Commander 与十六个专家

一、导读

在「一个对话框里养一支 AI 团队」这件事上，2026 年 10 月的开源圈给出了一个值得逐行读源码的新样本：Orkas。它把指挥官（Commander）、十六个具名专家、以及你本机已经装好的编码 CLI，塞进同一个桌面应用，并且用确定性宿主代码而不是提示词去管并发、预算与收尾。本文拆解它的编排内核、上下文预算体系与自演化机制，给出五类可复现场景，并如实标注它不做 worktree 隔离、自动化依赖机器开机等边界。

二、项目速览

项	值
仓库	`Orkas-AI/Orkas`
定位	本地优先（local-first）多智能体桌面工作台
主语言	TypeScript / JavaScript（Electron）
Star 总数	6,093（GitHub API 读取，2026-11-01）
当日涨星	1,118（daily 榜，2026-10-30 抓取，该榜第 5 位）
License	MIT
首次开源	2026-04-29（仓库 `created_at`）
最新发布	v2026.10.27（2026-10-27）；近 90 天约 8 个 Release
运行要求	Node 22.12+；macOS / Windows 有安装包，Linux 仅源码运行（glibc 2.34+，不支持 musl/Alpine）

数据获取日期：2026-11-01（GitHub REST API 与 Trending 页面）。第三方站点 explainx.ai 在 2026-10-31 读到约 5,900 star、355 fork、820 commits，与本次 API 读数的时间差相符。

三、为什么是它：问题背景与定位

多智能体桌面工具在 2026 年下半年扎堆出现，但绝大多数项目停留在「提示词里写一句你是团队负责人，然后靠模型自觉分派」的阶段。这种做法的通病是：并发不可控、预算不可测、失败不可归因。Orkas 的差异点在于它把编排的每一步都落到宿主代码的确定性约束上，并且把源码公开到可以逐文件核对。

第二个差异点是它对开源生态的姿态：它不重新实现编码智能体，而是把你机器上已经装好的 claude、codex、opencode、openclaw、hermes 二进制当本地子进程来跑，用的是你已经在这些 CLI 里登录好的凭据。Orkas 官方博客在 2026-10-20 记录了一次实测：Claude Code 写完一个小型 Python 工具的前一半（含测试）后因用量上限停下，留下一份进度笔记；Codex 在同一文件夹里全新启动，读到该笔记、沿用其中的决定写完剩余部分并跑通全部 14 个测试，全部通过。

涨星动因可以归纳为三点：一是「本地优先 + 自带密钥」在隐私敏感人群中的吸引力（README 声称自带密钥时模型调用机器直连供应商，不经 Orkas 服务器）；二是它同时提供了「自家专家」与「驱动别人的 CLI」两条路径，不必二选一；三是发布节奏稳定，README 与官网自述「每周发布，从未间断」，仓库 pushed_at 为 2026-10-31，最新一次提交是 Prevent lost edits during cross-Library moves (#144)。

四、架构原理（重点）

4.1 整体架构：三层，一个总线

Orkas 是一个 Electron 桌面应用，进程结构可以粗略分为渲染层（src/renderer）、主进程业务层（src/main）与一个可独立打包的智能体内核（src/core-agent）。真正承载编排的是主进程里的 features/group_chat/ 目录，而它的中心是一个 55 万字节的单文件 bus.ts——一个「每进程一个实例」的消息总线。

flowchart TB
  U[用户] -->|自然语言或 @具名 agent| R["router.ts<br/>解析 @ 与默认收件人"]
  R --> CS["ConversationScheduler<br/>准入：same-actor 串行 / 会话上限 / 具名任务门"]
  CS --> BUS["MessageBus（bus.ts）<br/>队列 + 活跃执行 + IPC 订阅者"]
  BUS --> CMD[Commander 回合]
  CMD -->|"dispatch_to（可等待或异步）"| A1[具名专家 Agent]
  CMD -->|"hand_off_to（转移并结束本回合）"| A2[具名专家 Agent]
  CMD -->|"run_worker（匿名、无历史、无专家技能）"| W[Ephemeral Worker]
  A1 --> SLOT["workerSlots 并发闸<br/>限嵌套派发的并发数"]
  A1 --> LN["本地 CLI 桥<br/>claude / codex / opencode / openclaw / hermes"]
  BUS --> TB[("tasks.json 任务板<br/>原子整文件快照")]
  BUS --> MEM[("Scoped Memory<br/>agent / project / shared / user")]
  BUS --> LIB[("Library<br/>本地 SQLite 向量索引")]
  REF["Reflection Orchestrator<br/>空闲时扫描脏信号"] -.->|反思与技能结晶| A1
  REF -.-> W

总线注释里写得很清楚：它只按 router.resolveRecipients 解析出的 to[] 路由；to[] 里含 user 的消息只写入会话 jsonl 并发给订阅者，永不入队——用户是人，UI 是唯一消费者。

4.2 分层拆解与关键接口

第一层：mention 解析与路由（router.ts，纯函数、无 IO）。 @token 的词法类显式包含 CJK 统一表意文字（[A-Za-z0-9_一-鿿-]+），且把 CJK 排除在「前导边界」之外——注释解释了原因：中文行文里 @ 前常不空格（如「然后@PptMaker」），若把 CJK 当作前导边界会静默吞掉 mention（2026-08-23 在真机上观测到）。多词显示名（如 Software Requirements Analyst）走「按已知名字长优先排序」的备选分支，避免短名前缀抢先匹配。

第二层：准入与并发（bus.ts + util/locks.ts）。 准入由 ConversationScheduler 负责：按队列顺序扫描，逐条应用确定性规则——同 actor 硬串行（因为每个 actor 是有状态会话）、会话级 agent 上限、以及按会话的具名任务门（D10）；Commander 的执行既占不到上限也占不到门（它本来就是 per-actor 串行）。locks.ts 提供两类原语：sessionLock(id) 保证同一会话不会在上一回合未结束时开新回合；globalSlots 全局并发上限为 10，注释说明这个容量「覆盖 worst-case group_chat 扇出（Commander + 若干并发 gmember actor）且不会饿死其它聊天 / KB 图片抽取 / 反思运行」。

第三层：派发三件套。 README 与源码一致地列出了 Commander 的三个委派工具：dispatch_to（非终止式委派，运行具名 agent 并把结果返回给 Commander 继续用，可等待或异步通知）、hand_off_to（把剩余工作转移给具名 agent 并结束当前 Commander 回合，可选 continuation 让 Commander 稍后继续）、run_worker（运行一个匿名隔离子任务并返回私有结果，不接收会话历史，也不带具名 agent 的技能）。三者的 executionMode 都标为 parallel——同一回合里多个独立派发会并发进行，由 workerSlots 限流。

第四层：任务板（task_board.ts）。 ConversationTask 精确命名「一次顶层 actor 执行」，它是一个可观测 + 可控实体：每一次状态跃迁都由确定性宿主代码驱动（路由、worker 循环、回合结果、用户 IPC），模型没有任何写板工具。注释特别强调 done 记录的是「回合正常结束」这一执行事实，stopped 记录宿主限定的终止，二者都不是质量判断。持久化到 <会话目录>/tasks.json，采用原子整文件快照，并且刻意不放进 state.json（后者是热更新、白名单重建的小状态记录，必须保持小）。

第五层：记忆与文档库。 cross_session_memory 工具把记忆分为四档作用域：agent（由宿主绑定到调用方自己，LLM 够不到别人的库）、project（绑定当前会话所属项目，只在项目会话里提供）、shared 与 user（全局）。与之并列但分离的是 Library：文档被抽取成段落并写入本地 SQLite 向量索引，嵌入模型在本机运行，library 工具提供 list / search / read 三个只读动作（列表默认 80 条、上限 300 条），因此不需要本地执行权限。

4.3 核心机制：把「软约束」换成宿主侧的硬闸门

(1) 规划由模型提议、由宿主裁定。 dispatch_planner.ts 处理「用户一条消息编排多个 actor」的情形：它让模型做一次结构化调用，提出「谁做哪部分、每部分要等哪些更早的任务」，然后由本模块确定性地校验——受派人只能是已被 @ 的 actor 或 Commander（不得凭空新增 actor）；每个被 @ 的 actor 要么被派活要么被列为参考；任务数在 1..8 之间（MAX_PLANNED_TASKS = 8），每段文本非空且不超 1000 字符；after 只能指向更早的任务，保证图无环。任意失败（模型不可用、超时 20 秒、JSON 畸形、或模型回了澄清问题）都会返回原因并让总线回退到 Commander。文件头一句话是全部设计哲学的浓缩：模型永远不自己写板（D12），它只返回宿主会检查的数据。

(2) 回合预算与「不许把排队当完成」。 actor-budgets.ts 把预算抽出来单独做单元测试，防止它与 schema 默认值悄悄漂移：COMMANDER_MAX_TOOL_LOOPS = 500、AGENT_MAX_TOOL_LOOPS = 500，匿名 worker 继承 schema 默认。MAX_WORKER_TURNS = 100。README 里那句「an admitted or queued task is not treated as a completed result」是这类系统里最容易踩的坑：收到 ack 不等于工作做完。

(3) 上下文预算：从一个数字推导出所有阈值。 context-budget.ts 是纯算术模块（无 Session、无 runner、无 IO），它从一个「可用输入容量」里逐层切分：先留 1/6 作为增长余量（INLINE_ROOM_SHARE = 1/6），剩余部分按 0.6 / 0.4 分给活跃进程层与历史层，活跃层再取 0.45 作为保留尾巴、其中 0.5 作为单步上限。当会话窗口小于 MIN_LAYERED_ROOM_TOKENS（= 1200×8 = 9,600 token）时，分层触发全部停摆，只保留应急层，避免为无意义的小窗口反复烧摘要调用。单条工具结果的准入上限是 10,000 token，而 Skill 文档单独给到 25,000 token「以便一次读完而不放进大块转储」。摘要目标从 1200 token 起步，随活跃触发线性增长到 6,000 上限，宿主侧存储硬顶按历史 5:3 比例同步放大。

(4) 工作区观测：让文件与命令在压缩后仍可追溯。 workspace-state.ts 用一组硬上限记录文件读取、文件改动与命令执行：观测条目上限 256，单快照 512,000 字符，总快照 8,000,000 字符，diff 默认 50,000、上限 120,000 字符，diff 路径最多 32 条，LCS 单元格上限 1,500,000（避免大 diff 把主线程拖死），文件、改动与命令执行都有能挺过上下文压缩的结构化记录。

4.4 性能与成本上的设计取舍

并发 10、worker 回合 100、工具回合 500、单结果 10K token、快照 8M 字符——这些数字都指向同一个取舍：把「显得聪明」让位给「可预测地不做蠢事」。代价也很直白：并发上限 10 意味着在几十个专家同时待命的场景里会出现排队；MODEL_ADMISSION 这类硬门会让一部分本可以由模型「灵活处理」的请求直接失败并回退。Orkas 的选择是让失败可见、可归因，而不是让系统在长尾里吞吐更难复现的成绩。

另一处值得注意的取舍是沙箱。sandbox/command-policy.ts 的注释自我限定得很清楚：默认拒绝规则匹配的是命令形状，不是任意参数里的词，而且这只是一个「有界准入检查，不是 shell 解释器，也不是操作系统沙箱」——不透明执行（sudo、bash、python、xargs 等可重新解释操作数的形式）继续采用保守匹配，宿主批准则是另一条独立通路。此外，run-program-vm.ts 显示它的程序化工具执行跑在 QuickJS（WASM） 虚拟机里：宿主初始化受墙钟截止时间约束，而 guest 的 CPU 配额只在真正开始求值用户程序时才启动，并区分「同步切片超限」与「墙钟超时」两种终止码——把「谁该被计时」这件事算清楚了。

4.5 与其他架构路线的差异

对比代码优先框架（LangChain / CrewAI / LangGraph）：那些是库，你写程序定义 agent、任务与图，并把它跑在自己的服务里；Orkas 是成品应用，编排内建，你用对话指挥。反过来，需要编程级控制或把编排嵌进自己产品时，框架仍然更合适——官网也是这么写的。
对比单编码智能体（Claude Code / Codex）：不是二选一，Orkas 把它们当作自己的 agent 之一来运行；它另外补上「代码之外」的那半条链（调研、内容、视频、办公文档）。
对比自托管网关（OpenClaw）与常驻服务器 Agent（Hermes-Agent）：前者强在渠道与系统级自动化，后者强在无人值守的后台定时；Orkas 的形态是「桌面 GUI + Commander + 可复用专家」。

4.6 自演化：反射调度器 + 技能结晶

Orkas 的「越用越强」不是营销词，它有一个独立的 reflection-orchestrator.ts（37,591 字节）作为唯一触发点。其设计注释几乎是一份失败复盘报告，值得完整复述：

单一调度器：在实测启动窗口之后触发，之后每 CYCLE_INTERVAL_MS 用 setTimeout 链再次触发。
逐 agent 门控：4 小时最小冷却 + 脏门（signals.jsonl 或 session jsonl 比上次检视更新）。注释点明了旧设计的教训——原来的「7 天最大间隔兜底」会强制对转写为空的空闲 agent 跑一轮，而失败又不推进时间戳，于是这些 agent 每个周期都霸占配额；在被诊断的机器上连续 21 个周期产出 0 次反思，五个名额全被同一批空闲 agent 占着。
每周期上限：至多 MAX_AGENTS_PER_CYCLE 个，合格但被推迟的 agent 等下一个周期，不丢人。
顺序执行 + 逐 agent 有界超时（PER_AGENT_TIMEOUT_MS），前台任务到达时立即让出；繁忙尝试 10 分钟后重试一次。
失败退避：瞬时失败不推进时间戳（下轮重试）但会记录尝试，冷却随连续失败翻倍，因此失败的 agent 无法每轮霸占队首；连续失败超过 MAX_FAILURE_STREAK 就让出该窗口。已检视的窗口一定推进基线——无论它产出了更新、结论是「无值得保存的内容」，还是根本没活动。

反思的实际产物是 agent 私有目录下的三份文件：COMPETENCE.md（自我评估，元工具限长 3000 字符）、LEARNING_STRATEGIES.md（可复用方法，限长 4000 字符）、以及 SKILLS/ 下结晶出的技能。技能存储 skill-store.ts 沿用一套与 Agent Skills 生态兼容的布局：每个技能一个目录、一个带 YAML frontmatter 的 SKILL.md（name / description / createdAt / updatedAt / patchCount / tags），name 上限 64 字符、必须匹配 ^[a-z0-9][a-z0-9_-]*$，描述上限 1024 字符；注释直言其参考了 Hermes-Agent 的 skill_manager_tool.py。反思本身用单一开放式提示词（REFLECTION_SYSTEM_PROMPT + buildReviewPrompt），没有 primaryFocus 分支——注释解释了原因：7 分支的 switch 会造成窗口聚合的歧义（多焦点运行需要互相矛盾的指令），而单一提示词还能让系统提示保持缓存稳定。

代价与风险：反思是后台 LLM 调用，会消耗额度；官方与第三方均把它标注为「早期机制，长期效果待验证」，可理解为「比一份 MEMORY.md 更结构化的 agent 自记笔记」，别指望一周就懂你。

五、应用场景（重点）

场景一：非开发者的「调研 → 报告 → 演示」流水线

痛点：市场/运营同学要交付一份竞品报告加一套幻灯，通常要在搜索、写作工具与 PPT 软件之间来回搬运，事实还容易在搬运中走样。解法：在一个会话里下达「调研前 5 名竞品、写成报告、做成演示文稿」。Commander 拆解后把取证交给 DeepResearcher（强调证据与出处、标注矛盾点）、把成稿交给 ContentWriter、把排版权交给 PptMaker（输出可编辑、可评审的 PPTX）。 最小可用示例（可复现）：

git clone https://github.com/Orkas-AI/Orkas && cd Orkas && ./run.sh
# first launch prepares npm deps, Node, embedding model (~95MB), OfficeCLI, FFmpeg, whisper.cpp
# then: Settings -> AI Providers -> add a provider key (or use the bundled 500 credits)

成功后在同一会话输入：「调研 XX 赛道前 5 名竞品，输出带出处的报告，并做成 12 页 PPTX」。 收益与量化：交付物直接落盘（消息附件 chip、任务详情-文件 tab、工作区目录三处可核对），一份事实源贯穿报告与幻灯，避免口径漂移。此处不宣称任何未经核实的速度提升数字——本文只把「产物落盘且可三处核对」当作可验证的事实。成本侧可参考官网口径：自带 key 时模型费用由你的供应商结算，官方托管模型按积分计费（打包版随附 500 积分）。

场景二：把编码工作分给两个 CLI，再交叉评审

痛点：同时开着 Claude Code 与 Codex 的人，最后往往自己成了「人肉消息总线」——手动复制计划、粘贴 diff、对齐结果。解法：把两个 CLI 各注册成一个 External agent（Orkas 只列出它在你 PATH 上探测到的 CLI），让 Commander 把「读懂并规划」派给一个、把「快速实现」派给另一个，结果是并发执行而非串行等待。上游步骤产出的文件，下游步骤能直接引用，链路由会话内的引用机制串起来。 最小可用示例：

npm install -g @anthropic-ai/claude-code   # then sign in to claude
npm install -g @openai/codex               # then sign in to codex
# in Orkas: new chat -> add agent -> External tab -> pick the detected CLI (do it twice)

收益与量化：官方博客记录的 2026-10-20 实测为——Claude Code 完成前半含测试，Codex 接力后跑通 14/14 测试。这是该团队自述的单次实验，非第三方复现，请按此权重看待。边界：Orkas 不会替你把 agent 隔离到各自的 git worktree；两个 agent 指向同一目录并并发运行会同时改同一批文件。要真正安全并行，请自己给每个 agent 各配一个目录或 git worktree。

场景三：带人工阻塞的输入表单与审批门

痛点：自动流程最怕在「需要用户拍板」的地方静默跑偏。解法：Orkas 支持带输入表单的 agent。计划中调度到这类 agent 时，会真实弹出表单（字段、默认值、必填标记、提交区），必填项留空给出不遮挡输入区的错误提示；提交后下游步骤继续，表单转为已提交态，刷新或重进会话也不会「复活」成可提交。OrkasOrchestrationLedger 还会记录 suspended_orchestration（waiting_for_agent / waiting_for_form / interrupted），把「被谁、因何挂起」显式化。收益：把「人机协同」变成有状态、可恢复的编排节点，而不是靠模型记住「我刚刚问过了」。

场景四：连接器驱动的办公与电商运营

痛点：改价、上架、发信这类动作风险高，全自动容易出事，全手动又没省事。解法：Connectors 覆盖 Gmail、Google Calendar、Sheets、Drive、Notion、Slack、Shopify、Stripe 等；默认在执行发送、发布、删除前先询问。例如 ECommerceOperator 的定位就是「规划目录、价格、促销与库存变更；只通过你连接的工具执行」。 收益与量化：权限被拆成三档账号级姿态——workspace_approval（谨慎，仅限活动工作区）、all_files_approval（默认，可访问工作区外路径但敏感操作仍需批准）、all_files_auto（不提示）。这个分层让「放手多少」成为一个显式配置项，而不是散落在提示词里的承诺。

场景五：定时自动化与「周一早上团队状态自动准备好」

痛点：周期性工作（周报、竞品追踪、数据核对）每次都从零发起。解法：任何任务都可设为每小时/每天/每周/每月运行。项目（Project）持有目标、规则、记忆与文件，因此每条新会话都从已确认的上下文起步；待办（To-dos）把工作分给人或 agent，Auto-advance 打开后团队自行接下一项并把成品交回评审。 边界（务必注意）：Orkas 跑在你自己的电脑上，自动化需要机器保持唤醒且 Orkas 在运行；自 v1.9 起，机器唤醒或 Orkas 启动后会补跑最近一次错过的运行（12 小时窗口内）。它不会因为你关机而继续工作，也没有云端执行兜底。

适用边界与不建议使用的场景

你只想要一个通用聊天机器人 → Orkas 明确自述「不适合」；
你想要的是一份可嵌进自己应用的代码库 → 同样不适合，请用框架；
你要求「模型权重必须留在本机」→ Orkas 做不到：它的模型调用会经网络发给供应商（官方托管模型或你自己的 key），官网的对比表里也是这么写的；
你要 Linux 原生安装包 → 今天只能源码构建（glibc 2.34+），Alpine 等 musl 发行版不受支持；
你需要团队级云端协作 → 共享项目、云同步、Web App 发布只在打包版提供，开源构建尚不支持。

六、快速上手

# installers: macOS (Apple Silicon / Intel) and Windows x64
# Linux: source only (glibc 2.34+; Alpine/musl unsupported)
git clone https://github.com/Orkas-AI/Orkas.git
cd Orkas
./run.sh            # macOS / Linux
run.cmd             # Windows

run.sh / run.cmd 会安装锁定的 npm 依赖树，并准备固定版本的 Python、uv、Node、嵌入模型（约 95MB）、OfficeCLI、FFmpeg、whisper.cpp 与多语言语音模型；随后打开应用。首次启动会在 ~/.orkas/（macOS/Linux）或 <最小的非系统盘>:\.orkas\（Windows）创建工作区。原生依赖报错时用 Node.js 24 LTS（最低 22.12.0）执行 npm run native:repair；只检查不安装用 npm run native:check。

最小可复现示例（一次跨 agent 的代码任务）：

# after configuring a model, start a new chat and just say:
# 重构 src/api/handlers/ 下所有 handler 的错误处理，统一为 try/catch + 结构化日志，最后给我一份变更总结
# Commander scans, splits, dispatches, merges; each worker's status is visible live in the UI

七、横向对比

下表中 Orkas 一列的性能/生态描述来自其 README 与官网；「对比」列的定位描述来自各项目公开材料。定价与套餐信息随版本变化，请以官方页面为准。

维度	Orkas	Claude Code / Codex	LangChain / CrewAI	OpenClaw / Hermes-Agent
形态	桌面 GUI 应用（含开源源码）	终端 / IDE / 云会话	代码优先库	自托管网关 / 常驻服务器
编排	Commander + 具名专家，对话驱动	单 agent，会话内自规划	你写程序定义	配置式 agent 与子 agent
复用	可复用 agent / skill / 市场角色	配置与提示词	你自己的代码资产	skills、脚本、配置
编码 agent	可把上述 CLI 当子进程驱动	本体	需自行集成	需自行集成
数据与密钥	默认留本机；自带 key 时机器直连供应商	依赖客户端/账号体系	自行实现	自行运维
成本	开源核心免费；打包版含 500 积分；有据可查的付费档从约 $11.99/月	订阅制	开源免费（模型费另计）	开源免费（模型费另计）

八、局限、风险与社区观察

打包版需要登录。打包后的桌面应用首次启动要求登录，这对一个自称 local-first 的产品是个反差；源码构建完全没有账号层。评估隐私时请把这条计入。
无 worktree 隔离。前文已述：并行多个编码 agent 时，冲突防护要你自己做。
QA 证据不均衡。仓库里有一批写得相当细的回归用例文档（docs/test/ 下 20 份，涵盖编排、连接器、知识库检索、Office worker、Windows 运行时等），同时官方博客给出的两个「已实测」数字（14/14 测试、handler 重构演示）都是自述而非第三方复现。按自述证据的权重看待它的效果声明。
权限默认值偏松。默认档 all_files_approval 允许 agent 访问工作区外的路径，all_files_auto 更是完全不提示。一个能编辑文件、执行命令、驱动编码 CLI 的桌面应用，请把它当成高权限进程来对待。
发布与维护活跃。近 90 天约 8 个 Release，最新提交 2026-10-31；但仓库 open issues 仅 7 个——这可能意味着质量稳，也可能意味着用户规模尚小（第三方核查者对此也提出了同样疑问）。待确认：真实的团队使用规模与生产环境案例，目前没有可核查的第三方数据。
第三方评测稀缺。检索到的主要是目录站与对比页，独立深度实测很少；有一条 dev.to 评测明确说明「作者尚未跑真实业务来评判输出质量」。这正是这类工具最关键、也最缺证据的一环。

九、小结与行动建议

想验证「多智能体是否真能交付」，先跑一条你已在做的工作流（例如一份周报），只看产出文件是否可用、是否可追溯，别先看 UI。
先固定模型与权限两个旋钮：Commander 用旗舰模型、worker 用便宜模型分摊成本；权限从 workspace_approval 起步，确认边界后再逐步放开。
驱动 CLI 时，给每个 agent 各配一个目录或 worktree，这是当前最便宜、最有效的冲突防护。
把关键交接写成文件里的进度笔记（完成什么、剩下什么、哪些决定要保留）——官方那次 Claude Code→Codex 交接之所以成功，靠的就是这份笔记，而不是任何魔法。
对效果声明保持「自述权重」：它的架构与约束是公开可读的，但它公布的加速与成功率数字目前基本是自述；在你自己的任务分布上复测一次，比读十篇评测更有用。