PilotDeck 2.0 用分层模型路由把复杂智能体任务成本砍去 83%

PilotDeck 2.0，一个来自清华大学 THUNLP 实验室、面壁智能、OpenBMB 和 AI9Stars 的开源智能体操作系统，于 2026 年 10 月 14 日发布，采用分层模型路由架构 —— 按开发者自己的基准测试 —— 把复杂多步任务的推理成本降低约 83%，同时基准表现高于单个 Claude Sonnet 4.6 实例或 Claude Code。在腾讯独立发布的 WorkBuddy Bench —— 一个覆盖编码、网页自动化、办公生产力和安全任务的多领域智能体评测套件 —— 上，该系统以 Qwen3.6-35B-A3B 为模型后端得到 79.1 分，高于 Claude Code 的 77.3 和腾讯自家 WorkBuddy 智能体的 74.7。

该系统针对的是一个阻碍企业更广泛采用长程智能体工作流的结构性成本问题：当多步流水线中的每个子任务 —— 无论是起草高管摘要、重排电子表格数据、翻译一段话，还是校验生成的文件 —— 都由同一个大型前沿模型处理时，每次运行的 token 开销随任务复杂度恶性增长。PilotDeck 2.0 的回答是把任务路由当作头等系统关切，把规划和推理工作分配给强大的模型，把执行和排版委托给更小、便宜得多的模型。

此次发布使 PilotDeck 成为少数拥有已公开基准数据、显示出对商业替代品有竞争力的表现、同时实质性缩小成本差距的开源智能体系统之一 —— 正是这道成本差距让重度使用前沿模型在高价值、低频任务之外变得贵得令人却步。

WorkSpace 隔离在文件系统和记忆层分离项目

PilotDeck 的基础架构概念是 WorkSpace —— 一个以项目为范围的运行时环境，为每个活跃工作负载提供自己专用的文件系统、向量记忆存储和技能注册表。不同于在所有用户活动间共享单一上下文窗口或记忆池的对话式 AI 工具，每个 PilotDeck WorkSpace 作为逻辑隔离的单元运行，其存储的记忆、检索的文档和工具权限对运行在其他 WorkSpace 中的智能体不可访问。

它解决的问题是上下文污染 —— 任何在同一会话中跨多个不相关项目使用过智能体工具的人都熟悉的一种退化模式。当共享记忆池先接收了一个正式技术架构任务的输入、紧接着又接收一个随意的内容营销任务的输入时，后续检索可能浮现不合适的上下文：架构任务的风格偏好渗进内容生成，或者一个客户项目的文件引用出现在智能体处理另一个项目时。靠提示工程修这个问题，要求开发者在每个任务边界构造繁复的清上下文指令；实践中依然不可靠。

PilotDeck 的 WorkSpace 设计把这一关切移入基础设施层。开发者给出的官方示例：一个在 WorkSpace A 处理音视频剪辑自动化、在 WorkSpace B 处理 iOS 游戏项目的智能体，为两者维护完全独立的记忆检索空间。在 WorkSpace A 生成的记忆无法被在 WorkSpace B 中运行的智能体检索到。智能体本身没有任何与这种分离相关的特殊指令；由基础设施强制执行。

2.0 版把每个 WorkSpace 内的文件操作能力扩展到端到端的 Office 文档处理。系统现在可以把 Word、Excel 和 PowerPoint 文件作为智能体任务的原生输出来创建、编辑和校验，补齐了早期版本中需要人工介入的环节。开发者称该系统针对这一功能通过了 2000 条消息的交互压力测试，不过他们没有公开描述该评测的具体通过/失败标准或失败率。

同样在 2.0 中新增的检查点恢复功能，允许长时间运行的任务保存中间状态，并在因系统错误、网络超时或手动停止而中断后从最近的检查点恢复。对耗时数十分钟的多步任务，这消除了重新处理已完成阶段的成本 —— 当这些阶段涉及昂贵的前沿模型调用时，这是一笔可观的节省。

白盒记忆与 Dream 模式让用户直接掌控智能体的回忆

多数商业智能体平台把记忆当作不透明的系统组件：智能体随时间积累上下文，检索在推理时发生，用户看不到系统保留了什么，也看不到各条存储信息如何影响输出。如果智能体学到了错误的偏好 —— 记错的参数、过时的流程描述、错误的 API 端点 —— 用户只有在错误信息浮现于智能体行为时才会发现，而此时通常的补救是一段可能成功也可能不成功的冗长纠正提示。

PilotDeck 的做法是把整条记忆链暴露为可检视、可编辑的产物。开发者描述了一条四阶段流水线：记忆生成（从已完成的交互中提取相关事实和偏好）、抽取（把这些条目结构化以便存储）、存储（写入 WorkSpace 范围的向量库）和检索（在推理时取回相关条目）。全部四个阶段都通过一个记忆管理面板对用户保持可见。

实践中，这意味着开发者可以打开某个 WorkSpace 的记忆面板，逐条查看智能体对其项目记录了什么 —— 记下了哪些编码风格偏好、记录了哪些架构决策、把哪些 API 凭据登记为上下文 —— 并直接编辑或删除单个条目。关键项目约束可以被固定，确保在记忆整合期间不会被较低优先级的信息挤走。面板还支持选择性的「加入对话」集成：用户可以高亮智能体生成文档的某一段，只把那个片段送入当前对话做有针对性的后续编辑。

Dream 模式通过后台维护扩展了这一架构。当智能体空闲时，系统自动运行一个整合作业，去重冗余的记忆条目、汇总相关条目，并压缩整体记忆存储。动机很实际：随着一个长期项目积累成百上千条单独的交互记忆，检索质量会退化，因为低信号记忆 —— 对无关话题的顺带提及、被丢弃的中间想法 —— 在检索时与高信号记忆竞争。

回滚能力是让 Dream 模式真正可用而不只是方便的特性。每次整合运行之前，系统对当前记忆状态做快照。如果整合删掉了某个事后证明重要的细节 —— 某项需求的细微之处、一条已弃用但有用的引用 —— 用户可以一步恢复到整合前的状态。没有这一保证，自动记忆整合带来的永久信息丢失风险足以让谨慎的用户理性地选择关闭它。

常驻执行在用户离开后继续长任务

PilotDeck 的常驻执行模式针对基于浏览器的智能体工具的一个基本约束：需要在较长时间内进行许多顺序工具调用的任务，传统上要求用户全程保持界面打开。关闭浏览器窗口或导航离开通常会中断执行，要求用户重新开始或手动恢复。

PilotDeck 把智能体任务作为持久后台进程运行，不论界面状态如何都继续执行。一项监控任务、一次多文档批处理运行，或一个多阶段的研究加写作工作流，可以排队后放着完成，用户同时去做别的工作。任务完成时，结果写入 WorkSpace 输出目录中的本地文件，并附一份进度摘要报告，描述完成了什么、调用了哪些工具、产出了哪些输出。

该系统还包含主动的候选任务发现：在执行排队任务时，智能体可能识别出能有用地承接当前工作的相关子任务，并把它们加入候选队列供用户审阅。这被描述为可选行为而非自主动作 —— 智能体浮现候选项，但未经用户授权不会启动它们。

原生的模型上下文协议支持意味着 PilotDeck 的工具使用行为在其网页界面、命令行客户端以及包括企业微信和飞书在内的企业消息集成中保持一致。扩展该系统自定义工具的开发者只需写一个 MCP 集成，就能统一应用于所有界面，而无需为每个客户端维护单独的集成。

强规划器/弱执行器架构如何把任务路由到不同模型层级

开发者报告的 83% 成本降幅来自一个围绕内置任务难度分类器构建的路由架构。当一个多步任务进入 PilotDeck，分类器分解整体工作负载，并按推理要求评估每个组成步骤。

需要复杂推理的步骤 —— 规划整体任务结构、决定调用哪些工具及顺序、从意外的工具输出中恢复、跨多个检索来源综合信息 —— 分配给高能力的前沿模型。无需大量推理即可执行的步骤 —— 把输出重排为指定模板、把一段文字翻译成另一种语言、在整篇文档中应用一致的风格修改、运行既定的数据提取模式 —— 分配给更小、更便宜的模型。开发者用中文把这一架构称为「主强子弱」：主模型强，子模型弱。用工程术语说就是强规划器/弱执行器模式。

经济逻辑取决于 token 消耗在任务步骤间的分布。在复杂的多步智能体工作流中，规划步骤往往很短：给规划器模型的指令通常是任务描述加当前上下文，规划器的输出是一个结构化的动作列表或单个下一步决策。相比之下，执行步骤可能处理长文档或生成大量格式化输出 —— token 量大，但推理复杂度低。如果典型工作流中多数 token 流经执行步骤而非规划步骤，把这些执行步骤路由到单位 token 价格低得多的模型，就能在对整体任务质量影响极小的情况下产生大幅的总体节省。

在开发者的七任务复杂评测集 —— 涵盖多语言播客分发、多源数据分析报告、领域文献综述和代码库架构文档生成等任务 —— 上，这种分布看起来很强地成立。他们报告的结果：所有步骤都走单个 MiniMax-M2.7 模型，WorkBuddy Bench 子任务得分 37.1，每次运行成本 1.90 美元，低于有用的质量门槛。所有步骤都走单个 Claude Sonnet 4.6，得分 69.1，每次运行 18.36 美元 —— 质量有竞争力，但规模化后成本高。同样七个任务走 PilotDeck 的分层配置，以 Claude Sonnet 4.6 为规划器、MiniMax-M2.7 为子智能体执行器，得分 70.6，每次运行 3.15 美元。

从 69.1 到 70.6 的分数提升是边际性的 —— 对这类基准来说在噪声范围内。从 18.36 美元到 3.15 美元的成本降幅是 83%。如果这些数字在更广的工作负载分布上成立 —— 这需要独立验证 —— 它们表明，对于 Sonnet 4.6 级别质量可以接受的任务，分层配置以大约六分之一的推理开销交付同等结果。

另一项使用社交媒体内容自动化工作流的场景测试发现，把单个 Claude Opus 4.5 部署（成本：每次运行 12.58 美元）换成以 Opus 4.5 为规划器、Claude Sonnet 4.5 为执行器的分层配置，每次运行成本降到 2.83 美元 —— 降幅约 77.5%。所有这些数字都来自 PilotDeck 开发团队自己进行的测试；截至本文写作，尚未有独立第三方复现这些具体结果。

WorkBuddy Bench 结果的语境：分数能说明什么、不能说明什么

PilotDeck 以 Qwen3.6-35B-A3B 为模型后端取得的 79.1 分，是在 WorkBuddy Bench 上测得的；这是腾讯 2026 年 8 月发布的多领域智能体评测套件。该基准跨四个能力类别 —— 代码、网页、办公和安全 —— 评估智能体系统，所用任务需要真实世界的工具使用和多步推理，而非简单的文本生成。

Qwen3.6-35B-A3B 是阿里 Qwen3 家族的一个混合专家模型。命名约定表示总参数约 350 亿，推理时每次前向传播激活约 35 亿。混合专家架构为每个输入 token 选择性激活模型参数的子集，而不是每次计算都运行全部参数，使模型在保持高有效容量的同时，相对同等参数量的稠密模型降低单 token 推理成本。这一配置使 Qwen3.6-35B-A3B 的运行成本大幅低于 Claude Sonnet 4.6 或 Opus 4.5，而在 PilotDeck 的配置中它同时充当高能力层和执行层，不需要单独的廉价模型。

对比分数 —— Claude Code 77.3、WorkBuddy 74.7 —— 出现在 WorkBuddy Bench 的发布资料中，可独立核验。这与 PilotDeck 的 79.1 分有一个重要区别：后者由 PilotDeck 团队自己的评测运行产出，而不是通过共享榜单提交。三个系统的评测条件 —— 硬件、工具环境、MCP 配置、评测协议版本 —— 是否严格等同，从现有来源无法确认。

同样值得注意的是 WorkBuddy Bench 不比较什么。Claude Code 主要针对软件开发任务优化，有深度的 IDE 集成和代码专用的工具使用能力。一个在编码之外还包含办公和网页自动化任务的多领域基准，不是编码专项表现的干净代理。「PilotDeck 全面胜过 Claude Code」这一含义单凭这个基准并不成立；基准支持的是：在 PilotDeck 团队的评测运行中，搭配 Qwen3.6-35B-A3B 的 PilotDeck 在 WorkBuddy Bench 四个特定领域上取得了更高的总分。

在开源智能体编排版图中的竞争位置

PilotDeck 身处一个拥挤但碎片化的类别。开源智能体编排框架 —— LangChain、LangGraph、AutoGen、CrewAI、OpenAI 的 Swarm —— 提供多种多智能体协调和工具集成方法，但没有一个把 WorkSpace 隔离、白盒记忆、分层路由和常驻执行打包成一个带有文档化部署路径和基准结果的统一运行时环境。

开源生态中最接近的同类是 MemGPT/Letta，它处理智能体的长上下文记忆管理，但不包含分层路由或 WorkSpace 隔离。阿里的 AgentScope 处理多智能体协调，但架构目标不同。PilotDeck 看起来是较早自称「智能体操作系统」、且功能集完整覆盖记忆、执行、路由和工具集成的项目之一 —— 不过这是一个新兴且仍在演变的领域。

该项目的 AGPL-3.0 许可证对商业部署是一项重要约束。在 AGPL-3.0 下，修改 PilotDeck 代码库并将其作为网络服务部署的组织，必须以相同许可证发布这些修改。这比多数竞争框架使用的 MIT 或 Apache-2.0 许可证更严格，会让在预期对智能体基础设施做专有修改的环境中部署变得复杂。评估把 PilotDeck 用于生产级企业用途的团队，应在投入定制之前评估这一许可要求。

局限、未经验证的说法，以及生产部署的开放问题

PilotDeck 2.0 带有几项生产部署应当考虑的重要注意事项。分层路由对比的成本和质量数字由开发团队自报；他们使用自己对基准任务的实现，而不是提交到 WorkBuddy Bench 榜单。在独立团队在受控条件下复现这些结果之前，83% 的成本降幅应被视为开发者的最佳情形估计，而非独立确立的性能特征。

任务难度分类器 —— 决定工作流中某一步该走前沿模型还是廉价模型的组件 —— 是路由架构中的关键依赖。如果分类器错误地把一个推理密集的规划步骤路由到廉价执行模型，质量会以用户可能不会立刻察觉的方式退化。开发者尚未发布关于该分类器架构、训练数据或失败模式的文档。这一组件的错误率和失败行为，是任何评估该系统用于生产的人面对的最重要未知数。

WorkSpace 隔离保证在产品文档中有描述，但未经独立安全审计。根据现有信息，隔离看起来是应用层的，而非操作系统级的进程或容器隔离。实际的安全属性 —— 具体说，一个 WorkSpace 中被攻陷的智能体能否访问另一个 WorkSpace 的记忆或文件 —— 尚未被独立评估。

开发者引用的 2000 条消息压力测试没有公开可得的方法、测试语料描述或通过/失败标准。该测试衡量的是质量、延迟、记忆稳定性还是它们的某种组合，以及遇到并处理了哪些失败模式（如果有的话），均不清楚。

MCP 集成把 PilotDeck 的触角延伸到外部服务，也造成了需要谨慎管理的安全面。通过恶意工具响应进行的提示注入 —— 外部服务返回旨在覆盖智能体指令的内容 —— 是 MCP 连接系统中有记录的攻击向量。把 PilotDeck 连接到敏感内部服务的组织应实施 MCP 工具白名单和输出校验。

GitHub 活跃度在本文写作时显示约 1800 个 star 和 150 个 fork。对一个处于早期采用阶段、源自学术的项目来说，这代表着可观的开发者兴趣，但尚未达到广泛部署的生产工具的规模。

一种值得在 PilotDeck 自身结果之外关注的路由模式

PilotDeck 2.0 在结构上最重要的方面不是具体的基准分数 —— 它们需要独立复现才有充分分量 —— 而是证明了强规划器/弱执行器模式可以在一个生产级开源系统中实现并得到可测量的结果。这一模式背后的推理不论哪些具体模型填充规划器和执行器角色都成立：如果执行步骤占复杂智能体工作流中 token 消耗的多数，且执行步骤的推理要求低于规划步骤，那么把执行路由到更便宜的模型应当能在对质量影响极小的情况下降低成本。这种影响的精确幅度取决于具体工作负载、所选模型层级之间的能力差距，以及任务分类器的准确性。

如果这些结果能经受独立复现并在多样的真实工作负载上成立 —— 这些条件尚未公开确立 —— 它们带有一个超出 PilotDeck 本身的含义：围绕单一前沿模型处理所有任务构建的企业智能体架构，可能对其实际计算负载中相当一部分系统性地过度设计了。对任何智能体平台，更高效的设计都会是带有智能逐步任务路由的异构模型舰队。

而 清华 THUNLP 和 OpenBMB 团队有产出在开源社区赢得严肃关注的研究到生产软件的记录 —— MiniCPM 下载量达到数百万，ToolBench 成了标准评测设施 —— 但研究基准演示与可靠生产部署之间的差距，一贯比发布公告暗示的更宽。PilotDeck 2.0 的分层路由架构是一个有说服力且动机充分的设计；下一个有意义的里程碑，是由一个在结果上没有机构利害关系的团队独立复现其成本-质量结果。