PilotDeck 2.0 开源：将办公交付置于聊天之上
PilotDeck 2.0 于 10 月 15 日开源，并提出了一个明确承诺：让智能体在 2,000 条交互消息中保持工作连贯，并交付完成的办公文件。该版本由清华大学 THUNLP、ModelBest、OpenBMB 和 AI9Stars 发布，旨在弥合“能够讨论工作”的助手与“能够可靠完成工作”的智能体之间长期存在的差距。
这一差异比又一份模型排行榜更重要。PilotDeck 押注于：AI 工作中真正有价值的单位，不是一条回复、一个提示词，或一次孤立的工具调用，而是一个可恢复的工作空间，其中包含指令、文件、记忆、执行记录和最终产物。
因此，这次发布挑战了两条既有路径。托管式助手通常在现有生产力套件中提供便捷访问；面向开发者的智能体，如 Claude Code 和 Codex，则偏向灵活、工具驱动的执行。PilotDeck 试图将后一种路径带入通用办公场景，同时保持运行层开放并允许选择模型。
这是一个有吸引力的设计，但目前仍只是设计主张。该项目尚未发布独立评估，以证明一场 2,000 条消息的会话能够稳定生成正确的文档、电子表格或演示文稿。近期办公智能体研究表明，最终交付物质量而非对话长度，仍是更困难的部分。
PilotDeck 2.0 开源改变了智能体工作的基本单位
PilotDeck 2.0 将持久化项目工作空间，而非单次聊天，视为智能体工作的基本容器。
项目的开源仓库将 PilotDeck 描述为一个面向任务的 AI 智能体生产力平台。其 10 月 15 日的公告重点提到了“一键安装”、可视化配置、长时任务连续性，以及面向 Word、Excel 和 PowerPoint 的新技能。
该软件本身已于 2026 年 5 月开源。相比将 2.0 公告理解为项目首次公开代码，更准确的说法是把它看作一次产品扩展：重心从开放的智能体界面转向旨在交付办公级文件的系统。
PilotDeck 将其核心组织单元称为 WorkSpace。每个 WorkSpace 以真实工作目录为中心，连接项目文件、会话、记忆、扩展和执行状态。不同会话可以共享相同的项目文件和长期上下文，同时追求不同目标。
这种结构解决了长任务中的一个实际问题。传统聊天在历史记录不断增长时，往往会丢失有用细节；它与对话之外文件的当前状态之间也缺乏紧密联系。
相较之下，PilotDeck 会记录消息、工具结果、任务状态和生成的产物。其文档称，历史会话可以恢复其设置和最近压缩过的上下文；智能体随后会重新读取真实工作目录，再继续执行。
这种分离十分重要。对过去操作的摘要，并不能证明该操作正确修改了文件。重新检查当前环境，使智能体更有机会发现实际发生了什么。
该版本还推广了用于创建 Word 文档、电子表格和演示文稿的技能。技能是一套可复用的任务指令与操作知识，可告知智能体如何检查源材料、构建产物并验证结果。
这种方法不同于为聊天机器人增加三个导出按钮。一项完整的办公任务可能需要阅读多个文件、提取事实、计算数值、起草内容、应用格式，以及检查完成后的文件包。PilotDeck 的目标是将这些步骤保留在一个可恢复的执行环境中。
对外公布的 2,000 条消息能力需要谨慎解读。它指的是系统声称可通过上下文预算和压缩来管理的交互历史，并不必然意味着在没有监督、错误或上下文丢失的情况下，能够连续执行 2,000 个自主操作。
这一差异构成了本文的核心张力。更长的连续性让智能体有更多空间完成真实工作，但也为错误假设、过时文件或失效工具结果影响后续所有步骤创造了更多机会。
尽管如此，这次发布仍改变了围绕办公智能体的讨论。它要求用户根据工作空间中留下的产物来评判软件，而不是根据其最新回答的流畅程度。
其机制是记忆、文件与可恢复执行
PilotDeck 的主要技术论点是：可靠交付需要存在于模型即时上下文窗口之外的持久状态。
模型无法永久携带此前的每一条消息、文档和工具输出。每个模型都有上下文窗口，即它在单次请求中能够处理的信息量上限。长时运行的智能体必须决定保留、压缩、检索或在其他位置存储哪些内容。
PilotDeck 的产品架构称，系统会为每次请求组装核心指令、项目指令、技能、历史消息、工具结果和长期记忆，然后根据所选模型的上下文容量分配这些材料。
大型工具结果可以作为文件存储，而非反复占用模型输入。历史消息可以被压缩为保留关键任务关系的摘要。长期记忆则与会话压缩保持独立。
这一区分减少了一种常见混淆。会话压缩帮助当前任务在原始记录过大后继续推进；长期记忆则在不同会话之间承载可复用知识。
这两种机制都不能保证准确性。压缩摘要可能遗漏后来变得重要的限定条件；存储的记忆也可能保留错误解读。其收益是运行连续性，而非自动获得真实准确的结论。
PilotDeck 还通过模型路由增加了一层能力。用户可以配置多个提供商，并针对不同复杂度的任务分配不同模型。较轻量的模型可以处理常规工作，而推理密集型步骤则交由能力更强的模型。
当模型请求失败时，路由器还支持回退链。PilotDeck 会记录使用统计，并可根据配置的基准估算差异。其文档警告，估算金额不等于实际的提供商账单。
因此，模型选择与工作空间本身是分离的。团队可以通过受支持的协议连接服务，而不必将每个项目绑定到某一家供应商的模型。这是 PilotDeck 与封闭式生产力助手之间最清晰的差异之一。
该系统还提供用于文件编辑、命令执行、网页访问和外部服务的工具。MCP，即 Model Context Protocol，可让兼容服务作为可调用工具出现在智能体的执行流程中。当特定工作空间需要不同访问权限时，项目级配置可以覆盖全局连接。
工具在权限边界内运行。PilotDeck 表示，参数和权限会在执行前接受检查，而文件访问取决于工作目录及其他已授权路径。这提供了一个可见的位置，用以界定智能体可以访问哪些内容。
运行时通过迭代循环协调这些部分：模型选择一个操作，工具修改或检查环境，结果再返回给模型。执行会在完成、取消、不可恢复的失败，或达到配置的循环上限后结束。
这听起来并不陌生，因为编程智能体已经采用类似模式。PilotDeck 的赌注在于，配合办公专用技能和产物检查后，同样的运行模型可以处理更广泛的知识工作。
演示文稿任务说明了这种差异。普通助手可能在聊天回复中起草幻灯片文本；工作空间智能体则可以检查源文档、创建演示文稿、检查其结构、修改内容拥挤的幻灯片，并在输入文件旁留下可编辑文件。
电子表格任务则提出了不同要求。智能体必须保留数据类型、公式、标签和工作簿结构。一段看似合理的文字说明，无法弥补交付文件中损坏的引用。
这正是可复用流程指令的重要性所在。构建AI 工作流的团队需要稳定输入、明确检查项和可审查输出。PilotDeck 将这些要素围绕项目目录打包，而不是让它们分散在各类提示词中。
其机制具有一致性：持久化文件锚定现实，会话记录保存执行历史，压缩限制上下文增长，技能指导重复性工作。尚未得到解答的问题是，在高要求任务中，这些层级抵抗累积错误的能力究竟如何。
办公智能体如今比拼交付物，而非回答
PilotDeck 对托管式办公助手和开发者智能体平台都提出了压力：它们必须证明自己能够完成多文件工作。
托管式助手的优势在于贴近人们已在使用的应用程序。Microsoft 和 Google 可以将 AI 功能放在文档、电子表格、电子邮件和日历旁边。这种分发方式降低了部署阻力，也使助手能够接入熟悉的工作流程。
但这一路径也将用户置于供应商控制的环境中。模型选择、编排细节和更深层的执行行为往往不那么开放，组织必须在各供应商提供的集成与控制范围内工作。
PilotDeck 则采取相反路线。其代码采用 GNU Affero General Public License 第 3 版。AGPL 条款允许检查和修改，同时在受涵盖的网络使用场景中施加源码共享义务。
这种开放性可能对希望检查智能体行为的开发者、研究人员和组织具有重要意义，但也带来额外工作：必须有人部署系统、配置提供商、管理凭证、定义权限、评估技能并维护更新。
仓库提供适用于 Windows、macOS 和 Linux 的桌面软件包及安装路径。公开的发布历史还显示，2.0 公告后仍持续有构建版本和修复发布。这些活动支持了该项目仍在维护的判断，但并不能衡量其生产环境可靠性。
面向开发者的智能体面临另一种压力。它们的工具驱动执行已经表明，模型可以导航代码仓库、编辑文件、运行命令，并在测试失败后修订工作。办公智能体正越来越多地借鉴这种运行模式。
PilotDeck 明确建立在与编程智能体界面、模型路由器、记忆系统、检索框架和技能相关的理念与组件之上。它的贡献在于尝试将这些部分转化为一个面向持续任务的通用工作空间。
这并不意味着 PilotDeck 可以直接替代每一种编程智能体。软件仓库提供了异常强的反馈机制：测试可能失败，编译器可以拒绝无效语法，版本控制能够展示精确变更。
办公文件往往缺少类似的检查机制。一份演示文稿可以成功打开，却包含缺乏依据的说法。一张电子表格可以含有有效公式，却套用了错误的业务假设。一份报告可以满足格式要求，却遗漏了决定性的来源。
因此，竞争分界线落在执行透明度与应用便利性之间。PilotDeck 提供对工作区、模型、工具和技能的控制权。托管式套件则与广泛部署的办公应用和身份系统实现了更紧密的集成。
两条路线都尚未解决最后一公里的验证问题。本地运行的开放代理仍可能生成精致但错误的文件。深度集成的商业助手也仍可能误解请求，或让重要工作半途而废。
这对企业买家很重要，因为模型质量只是系统的一部分。他们还必须评估权限设计、可审计性、文件兼容性、恢复行为、数据处理方式，以及维护任务专属指令所需的投入。
PilotDeck 的工作区模型让这些运营层面更易于检查。用户可以查看文件、执行记录、工具调用和已配置的扩展。这种可见性有助于调试和内部审查。
不过，可观测性不应与正确性混为一谈。完整日志可以解释代理如何得出错误结果，却无法阻止错误，除非有人、测试或第二套系统识别出它。
2.0 版本让竞争对手更难回避这一区别。如果办公代理承诺完成工作，供应商就需要展示的不仅是吸引人的聊天演示。他们需要证明，最终文件在漫长、分支繁多的工作流之后依然可用。
2,000 条消息的运行并非可靠性基准
只有当任务准确性能够在更长流程中保持，PilotDeck 的续航主张才有意义。
该项目表示，PilotDeck 2.0 可在 2,000 条交互消息中让长期任务保持正轨。这是一项明确的容量主张，但公开公告并未提供独立基准，将这一长度与成功交付办公文件联系起来。
交互次数也是衡量任务难度的不完美指标。两千次简短澄清所需的推理，可能少于一项涉及不一致源文件的 40 步任务。长篇记录可能代表富有成效的迭代、反复失败，或两者兼有。
更有力的测试，是最终产物是否满足详细评分标准。它应包含正确的信息，保留所需结构，保持可编辑，并能在预期软件中打开。同时也应避免加入缺乏依据的内容。
现有研究提供了谨慎对待的理由。2024 年的 OfficeBench evaluation 测试了代理在真实办公工作流及多个应用中的表现。GPT-4 Omni 取得了报告中最高的 47% 通过率，但仍低于可靠办公自动化所需的标准。
研究人员将失败与冗余操作、幻觉，以及在应用之间切换的困难联系起来。当代理必须协调文档、电子表格、演示文稿和外部信息时，这些问题尤其重要。
更新的研究则通过产物级评估得出了相关结论。2026 年的 office-agent benchmark 包含 100 项源自从业者请求的长周期任务。每项任务平均需要 2.32 小时人工劳动，并通过详细的代码检查进行评估。
该研究发现，接受评估的语言模型代理完成工作的速度更快，推理成本也低于人工工作人员。不过，没有任何一个接近人类基准的交付质量。
该基准还发现，人类耗时更长的任务往往对应更低的代理得分。研究人员将这一模式归因于持续规划需求、细致的文件操作，以及结构性错误累积的更多机会。
其中对运行方式的比较与 PilotDeck 尤其相关。纯编码配置在该基准中得分为 14.41，略高于编码与计算机使用相结合的混合配置的 13.77。纯计算机使用配置得分为 0.78。
这些数据属于该基准及其特定支架，不应被视为 PilotDeck 的性能数据。不过，它们支持了 PilotDeck 技能背后的更广泛观点：直接操作文件可能比长串视觉点击更可靠。
它们也揭示了尚存的问题。程序化编辑减少了一些界面错误，却无法保证语义质量。代码可以把错误结论放进恰好正确的单元格。
PilotDeck 需要与其主张相匹配的公开评估。有用的测试应从源文件和高层任务要求开始，然后对工作区中留下的实际 Word 文档、工作簿或演示文稿评分。
评估应报告彻底失败、部分完成、缺乏依据的主张、格式缺陷和人工修正时间。它还应将模型表现与代理支架带来的改进区分开来。
长会话测试值得进行专门的失败分析。研究人员应检查上下文压缩是否丢失要求、旧记忆是否覆盖新指令，以及恢复过程是否从正确的文件状态继续。
安全性又增加了一层不确定性。具备命令访问权限、外部工具和项目凭据的代理，比聊天机器人拥有更广的操作面。权限检查很有帮助，但管理员仍需测试系统如何处理恶意文档、提示注入和权限过宽的工具访问。
开放代码仓库让外部研究人员能够审查这些问题。这是实实在在的优势。然而，在项目关于续航能力的表述成为可靠无人值守工作的证据之前，独立测试仍必须开展。
目前，谨慎的解读很直接。PilotDeck 展示了一种可信的长期任务维护架构，而非证明这些任务必然能正确完成。
三项信号将决定 PilotDeck 2.0 是否重要
PilotDeck 的下一阶段取决于产物基准、可重复的生产使用，以及严格的扩展治理。
第一个信号是独立的办公交付评估。它应在相同模型、源文件、指令和评分标准下，将 PilotDeck 与其他代理支架进行比较。
这种比较能够揭示，工作区、记忆、路由和技能是否在底层模型之外带来改进。它应衡量完成质量和人工修复工作量，而不只是延迟或 token 使用量。
强劲的结果将支持 PilotDeck 的核心论点：持续执行架构能够改善长周期工作。较弱的结果则可能表明，该系统主要只是延长了代理持续作出不确定决策的时间。
第二个信号是来自重复性工作场景的证据。最具参考价值的案例将涉及具有明确验收标准的周期性任务，例如根据一组固定输入制作每周运营报告。
用户应跟踪产物无需修正便被接受的频率、会话需要救援的频率，以及反复出现的错误。公开汇集此类案例会比孤立演示更具说服力。
可靠使用还需要如实呈现失败状态。当关键信息缺失时，代理应停止；应呈现未解决的冲突；并区分已完成工作与部分输出。悄悄生成一份看似合理的文件，并不等于成功交付。
第三个信号是围绕技能和外部工具的治理。可复用技能可以编码有价值的工作流，但也可能携带薄弱假设、不安全命令或过时要求。
团队需要为所安装的扩展建立版本控制、审查、权限限制和测试用例。项目专属技能应始终让对结果负责的人能够理解。
同样的审查也适用于记忆。用户需要控制系统保留什么、如何更新存储知识，以及如何删除错误记忆。当没有人能解释代理为何不断重复错误决策时，持久上下文就会成为负担。
PilotDeck 2.0 的重要性在于，它将这些运营问题置于办公自动化的中心。它不把精致的回答视为最终产品，而是将工作区及其交付文件视为产品。
这一框架比普通助手软件要求更高。它要求代理保存状态、操作工具、从中断中恢复，并生成经得起检查的产物。
开源模式为 PilotDeck 提供了一条有用的前进路径。研究人员可以构建基准，开发者可以审计其行为，团队可以将技能调整为适配真实工作流。该项目约 2,000 条消息的连续性主张，也为测试人员提供了具体目标。
决定性问题不再是 PilotDeck 2.0 开源版本能否让代理持续对话，而是团队能否将复杂任务交给代理，稍后回来时信任它留下的文件。在扩大其权限之前，应先在一个周期性工作流上测试这一结果，对每个产物评分，并记录每一次人工修正。
