更佳阅读效果，请移步关注我的公众号
WorkBuddy 是腾讯推出的桌面 AI Agent 工作台。它的目标不是“回答你一个问题”，而是接收一个工作目标后，自动理解需求、拆分步骤、调用文件与工具、生成产物，并把结果交付出来。
例如，你说：根据这份销售数据，生成一份带图表的经营分析报告，并输出 PPT。
传统聊天机器人通常会给你一份分析思路或一段文字。WorkBuddy 则更像一名初级分析师：读取文件、分析数据、生成图表、组织文档、输出 PPT，并在任务页面中展示产物、文件变化和执行过程。
它可以理解为：大模型 + 本地电脑操作能力 + 工具生态 + 工作上下文 + 权限控制 + 任务交付界面。
需要说明的是，腾讯公开资料重点披露的是产品能力、组件边界和使用方式，并未完整公开其内部的模型调度、任务编排和执行运行时。因此，下面讲的是基于公开能力整理出的“产品逻辑架构”，而不是对内部实现细节的猜测。
从产品能力看，WorkBuddy 可以拆成六层。
约束与保护
① 任务入口桌面输入 · 文件/截图 · IM 指令 · 定时任务
② 任务与上下文Task · Workspace · Project · Memory
③ Agent 编排与推理理解需求 · 拆解规划 · 模型/专家协作 · 结果检查
④ 执行能力本地文件 · Skills · MCP/CLI · 浏览器与第三方服务
⑤ 数据与交付任务产物 · 文件变更 · 报告/表格/PPT · 分享同步
⑥ 横向治理：贯穿全程权限控制 · 高风险确认 · 连接器授权与审计
这六层并不是六套独立系统，而是一条连续的 Agent 工作链路：接收目标 → 补齐上下文 → 规划 → 调工具执行 → 生成产物 → 检查与继续迭代。
官方将其描述为“自主规划执行”和“交付可验收结果”。对于复杂任务，WorkBuddy 会先理解目标，再安排搜索、整理、生成、校验等步骤。
WorkBuddy 不只有一个聊天输入框，而是提供了多个任务触发入口。
这是最常见的方式。用户在 WorkBuddy 中输入目标，补充文件、截图、工作目录和输出要求。任务描述最好包含四类信息：
• 要解决什么问题；
• 输入文件或资料是什么；
• 希望输出什么格式；
• 有哪些约束，例如风格、篇幅、时间范围或模板要求。
例如：“读取当前目录中的会议纪要和产品需求文档，整理为一份 V1.0 立项 PPT，风格偏企业汇报，输出 PPTX 和 PDF。”
WorkBuddy 会把当前目录作为任务工作目录，用于读取输入文件和保存生成结果。
WorkBuddy 支持 PDF、Word、Excel、CSV、PPT、图片、压缩包和代码文件等输入。它的关键不是“上传一个文件”，而是把文件变成 Agent 可以理解的任务上下文。
WorkBuddy 可以接入微信、企业微信、QQ、钉钉、飞书等即时通信工具。用户在手机上发出指令，桌面端 WorkBuddy 接收后执行任务，并把结果回传。
这更像“远程遥控桌面 Agent”，而不是云端独立运行的机器人。因此，电脑需要保持开机，且 WorkBuddy 需要处于运行状态。
自动化任务适合日报、周报、资料整理、周期性数据导出等场景。
官方说明中，自动化可以配置工作空间、提示词、模型、Skill 和定时规则，结果保存到指定目录。
WorkBuddy 中最容易混淆的几个概念是：任务、工作空间、项目和记忆。
Project（可选）
团队共享的规则、资料与能力
│
│ 在项目内发起任务时，自动注入
▼
Task
一次具体工作与对话会话
│
├── Workspace：本次任务的文件与产物
├── Skill：完成任务可调用的方法与工具包
└── Connector：任务可连接的外部系统
Memory：个人层能力，跨 Task 保留偏好与习惯
一个任务会经历规划中、进行中、待处理、已完成、失败、已归档等状态。
任务可以持续追问和迭代。也就是说，用户不需要每次重新描述全部背景，而可以在同一个任务中继续说：
“把刚才的报告再补一页竞品分析。”“重新生成，数据图表改成柱状图。”“导出 PDF，同时保留源文件。”
这就是任务状态和会话上下文的价值。
工作空间是本次任务读取和保存文件的目录。
它既是效率机制，也是安全边界。把资料集中放进一个独立工作目录，可以减少 Agent 在不相关目录中误读、误改或误删文件的风险。
例如，不建议直接让 Agent 操作“桌面全部文件”；更好的方式是新建：
2026Q3_经营分析/
├── 原始数据/
├── 参考资料/
├── 输出产物/
└── 备份/
然后只授权该目录。官方同样建议重要资料先建立独立目录，并优先处理副本，而不是直接处理唯一原件。
项目不是简单的文件夹，而是团队协作配置中心。一个项目可以统一配置：
• 全局指令；
• 可用连接器；
• 专家；
• 技能；
• 团队资料与标准。
项目成员在项目内创建新任务时，这些配置会自动注入到任务上下文中，不需要每个人、每次任务都重复设置。例如，一个“市场分析项目”可以预置：
• 输出必须包含执行摘要、市场规模、竞品对比、风险提示；
• 默认使用研究类 Skill；
• 默认连接知识库和腾讯文档；
• 默认调用“行业研究专家”；
• 默认输出企业汇报风格。
这意味着 Project 承担的是“团队标准化上下文”，而不是单纯存资料。
Memory 用于保存用户个人偏好、习惯、人物关系和近期跟进事项。官方说明中，WorkBuddy 会定期从会话历史中抽取相关信息，并在后续任务中把相关记忆作为背景参考。
例如：
• 用户偏好“汇报先给结论，再给过程”；
• 用户常用企业汇报风格；
• 用户关注 AI、安防、边缘计算；
• 用户近期在推进某个项目。
Memory 更接近“个人长期上下文”。而项目规则、团队标准、业务资料，应该放在 Project、知识库或 Skill 中，而不是完全依赖个人记忆。
从官方描述看，WorkBuddy 的核心运行机制可以概括为一个 Agent Loop：
理解目标
↓
补齐上下文
↓
规划步骤
↓
调用工具执行
↓
检查中间结果
↓
生成交付物
↓
根据用户反馈继续迭代
这不是一次性生成，而是多步骤循环。
系统首先识别用户真正想要的结果，而不只是字面问题。
例如用户说：“帮我把这些资料整理成领导能看的方案。”
Agent 需要进一步理解：
• 输入文件有哪些；
• 领导关心什么；
• 是 Word、PPT 还是表格；
• 是否需要结论、成本、风险、排期；
• 是否需要企业汇报风格。
因此，任务描述中的目标、范围、输出格式和验收标准，会直接影响 Agent 的结果质量。
复杂任务通常不是一步完成，而是拆成多个子步骤。
例如“生成市场调研报告”可能拆为：
官方“AI 自驱动”实践中明确建议用户说明目标、约束和完成标准，并允许 WorkBuddy 自主规划、执行和检查。
WorkBuddy 的“专家”可以理解为预设的专业角色。一个专家通常由三部分构成：
角色定位 + 方法论 + 工具链
例如：
• 产品经理专家；
• 数据分析专家；
• 行业研究专家；
• PPT 设计专家；
• 代码审查专家。
“专家团”则是多个专家协作。官方描述中，专家团由团长自动拆解任务，安排成员并行执行，并整合成最终交付结果。
需要区分两件事：
• 多任务并行：同时运行多个不同任务；
• 专家团协作：一个复杂任务内部，由多个角色分工完成。
前者提升吞吐量，后者提升复杂任务的专业分工质量。
WorkBuddy 更像一个 Agent Runtime，而不是单一模型。
它可以使用内置模型，也支持配置第三方模型。自动模式会根据任务类型选择模型；用户也可以为不同场景指定不同模型，例如更偏推理、多模态或速度优先的模型。
因此，可以把关系理解为：
• 大模型负责：理解、规划、推理、生成
• WorkBuddy 负责：上下文组织、工具调用、文件操作、权限控制、任务管理和交付
模型决定“脑力上限”，WorkBuddy 决定“能否进入真实工作环境并稳定完成任务”。
这是 WorkBuddy 架构中最关键的一层。
Skill 可以理解为“技能包”。它通常包含：
• 适用场景说明；
• 工作流程；
• 工具使用规则；
• 脚本或模板；
• 输出格式要求；
• 权限范围。
例如，一个“数据分析 Skill”可能规定：
官方将 Skill 定义为一组可执行脚本和工作流，用于让 WorkBuddy 在用户授权下完成文件读写、第三方 API 调用、邮件发送等具体动作。
从技术形态看，CodeBuddy 官方文档展示的 Skill 常以 SKILL.md 为核心，结合说明、工具白名单、脚本、参考资料和模板组织。Skill 的作用不是单纯“给模型更多提示词”，而是把流程、知识和执行方式一起固化。
Connector 是 WorkBuddy 与外部服务之间的桥梁。它解决的是：Agent 能不能进入我的邮箱、知识库、文档系统、会议系统、项目管理系统？
目前官方说明明确 Connector 用于把外部服务能力引入工作流，并支持 QQ 邮箱、腾讯乐享、腾讯文档、TAPD、微云及自定义连接器。例如：
用户：整理本周项目邮件，并生成待办清单
↓
邮箱 Connector：读取邮件
↓
Agent：筛选、归类、提取事项
↓
Skill：按项目模板生成任务清单
↓
文档 Connector：写入腾讯文档
MCP 可以简单理解为“让 AI 以统一方式调用外部工具和数据源的协议”。过去，每接一个系统，都要单独开发一套接口。MCP 的价值是让不同工具、知识库、数据库和服务，以更统一的方式暴露给 Agent。
在 WorkBuddy 中，MCP 的角色主要是：把外部世界的能力变成 Agent 可发现、可调用、可授权的工具。
例如知识库检索、邮件查询、会议管理、项目数据读取，都可以通过 MCP 连接器进入 Agent 工作流。
一句话概括：模型负责思考，专家提供视角，Skill 固化流程，Connector 接入系统，MCP 统一工具协议。
很多人会问：WorkBuddy 是本地运行，还是云端运行？ 更准确的说法是：WorkBuddy 是“本地桌面执行 + 模型服务推理 + 外部系统连接”的混合架构。
本地客户端主要承担：
• 文件读取与写入；
• 工作空间管理；
• 本地目录操作；
• 任务历史与产物展示；
• 自动化任务配置；
• 远程助理接收与执行；
• 本地权限和风险确认；
• 一部分脚本与工具运行。
官方说明中，文件默认在本地处理，WorkBuddy 只能访问用户授权的文件夹；系统敏感目录会被拦截，高风险操作需要二次确认。
当 WorkBuddy 调用内置模型、第三方模型、联网搜索、外部知识库、邮件或文档服务时，任务相关数据会按需要进入模型或第三方服务链路。
特别是自定义模型场景，官方明确说明：用户配置的 API Key 保存在本地，WorkBuddy 会把输入转发给所配置的第三方模型，输出再返回给用户。
因此，不应把“支持本地文件操作”误解为“所有数据永远不会离开电脑”。更准确的理解是：
文件读写与工作空间：主要在本地
模型推理：可能使用内置或第三方模型服务
外部业务数据：由 Connector 按授权访问
对外写操作：应由用户明确确认
Agent 的能力越强，风险也越大。WorkBuddy 的安全设计核心是：默认最小权限，高风险操作二次确认。
WorkBuddy 提供默认权限和完全访问权限两种模式。日常使用建议保持默认权限。此时，Agent 在工作空间内执行常规任务，但遇到以下动作通常需要用户确认：
• 写入敏感路径；
• 删除重要文件或目录；
• 批量删除；
• 执行脚本、命令或外部程序；
• 网络访问或敏感能力调用。
官方还说明，命令会优先在沙箱约束下执行，删除操作会尽量通过安全删除或回收站机制降低误删风险。
连接器不应该“一次授权所有能力”。
官方要求连接器独立授权，不主动定时抓取数据，也不应超出用户已有权限范围。涉及发送邮件、创建文档、修改外部内容等写操作时，应由用户明确指令确认。
Skill 可能包含脚本、网络请求和第三方 API 调用，因此它不只是“提示词模板”。
官方建议优先使用官方推荐 Skill；安装第三方 Skill 前，应检查来源、权限范围和脚本内容。
市面上专门为AI Agent Skill设计的扫描工具有：agent-skill-scanner、Snyk Agent Scan、SkillScan、Claude Skill Antivirus 等，各有侧重。
用过 AI 助手的人常有这种体验：换个设备，它就不认识你了；换个任务，它把上回的偏好带过来捣乱。WorkBuddy 分层上下文体系—从跨设备的账号记忆，到跨任务的长期偏好，再到聚焦当下的任务上下文，各司其职。
这一层用来识别当前用户身份，并延续跨设备的个性化协作体验，同时管理模型、连接器等授权配置。
可以把账号层理解成 AI 的“身份证和通行证”——它决定了你是谁、能用哪些模型和连接器。这部分由云端托管，用户无需关心底层细节；本章仅从产品作用角度说明，不对实现机制作进一步推断。
账号级上下文：这个用户是谁、可访问什么
├─ 云端记忆（云端 Memory）
│ 跨设备、跨 Session 的用户画像与长期偏好
│ 由云端侧处理和托管；具体存储与同步机制对用户不可见
├─ 账号设置与授权
│ 登录身份、模型配置、连接器授权、同步范围
WorkBuddy 围绕当前 Task工作；将 Task 内连续的对话与执行过程称为 Session。
当前 Task / Session：这次正在做什么
├─ Session 上下文
│ 当前目标、对话、执行步骤、中间结果
├─ Task 历史
│ 已发生的讨论、状态与执行记录
│ 本地底座：~/.workbuddy/workbuddy.db
├─ 跨 Session 的用户级上下文
│ ├─ 用户长期 Memory
│ │ 从历史协作中提炼的偏好、习惯与结论
│ │ 典型载体：~/.workbuddy/memory/xxx_memory.md
│ └─ 用户级显式规则
│ USER.md、SOUL.md、IDENTITY.md
├─ Workspace 记忆
│ 当前项目的每日进展、决策与待办
│ 典型载体：<Workspace>/.workbuddy/memory/YYYY-MM-DD.md
├─ 工作空间资产
│ 文件、模板、历史产物与输出目录
├─ Skill / Expert
│ 方法、检查项、工具规则与输出规范
└─ Connector / MCP
外部文档、知识库、邮箱、项目系统等实时信息
• workbuddy.db：本地任务、会话、状态与历史记录的持久化底座，不等于长期 Memory。
• Workspace 下按日期的 .md：项目级工作日志，避免项目上下文混入其他项目。
• USER.md / SOUL.md / IDENTITY.md：用户可显式维护的长期规则，比自动摘要的 Memory 更可控。
• 云端 Memory：适合跨设备的个性化延续，但底层保存位置、提炼逻辑及精确注入范围对用户不可见。
• 云端账号 Memory： 解决跨设备延续；
• 用户级 Memory：解决跨 Session 的协作；
• Workspace Memory：记录当前项目进展；
• Task / Session：专注当前这件事。
四层各司其职，共同构成 WorkBuddy 的上下文体系，让 AI 既记得住你，也分得清场景。
以“生成经营分析报告”为例。
用户提交销售数据和需求
↓
WorkBuddy 创建 Task 和 Workspace
↓
读取文件、识别表头、检查数据质量
↓
结合项目规则、个人偏好、专家方法论
↓
规划任务：清洗 → 分析 → 图表 → 结论 → PPT
↓
调用数据分析 Skill、本地文件工具、图表工具
↓
生成 Excel、图表、Word 或 PPT
↓
在结果区展示产物、文件和变更
↓
用户检查并继续追问修改
↓
最终分享、上传云端或归档
WorkBuddy 的右侧结果区可以展示工作空间文件、浏览器预览、文件变更和最终产物。对于代码、脚本、文档等任务，用户可以先查看变更，再决定是否接受结果。这使它比纯聊天产品多了一层“交付与验收”能力。
以下比较基于三者当前公开能力，重点讨论用户可感知的产品定位与交付方式，不代表模型能力、性能、安全性或成熟度的绝对优劣。
WorkBuddy 的主要入口是桌面工作台，适合围绕本地文件、工作目录、文档、表格和办公产物发起任务；同时也支持通过微信、企业微信、飞书、钉钉、Slack、Telegram 等即时通信工具，远程控制运行在电脑上的 WorkBuddy。它的特点是“任务仍在桌面端执行，但用户可以从手机或消息平台发起指令”。
OpenClaw 更像一个自托管的 Agent Gateway。它强调把 Agent 接入消息渠道、定时任务、Webhook 与本地工具环境，使用户可以持续通过聊天入口与 Agent 协作，并让 Agent 在后台执行自动化工作。
Hermes 则更偏通用 Agent Runtime：同一套 Agent 核心可运行在 CLI、消息网关、桌面端和 API 服务中，也可以部署在本地电脑、VPS 或云端环境。它更适合希望把 Agent 作为长期运行能力来部署的技术用户。
WorkBuddy 的重点是办公任务的“可验收产物”。它更适合处理文档、表格、PPT、数据分析、文件整理、日报周报和项目材料等任务，并围绕工作目录保存输入文件和输出结果。
OpenClaw 更偏个人自动化与系统协作。例如，它可以通过消息渠道接收任务，通过 Cron、Heartbeat、Webhook 和后台任务机制持续推进提醒、通知、检查、整理或跨系统操作。它的交付物不一定是正式文档，也可能是一条消息、一项提醒、一次自动执行结果或一个外部系统变更。
Hermes 更偏持续运行的通用 Agent。除了处理文件、终端、浏览器和代码任务外，它还强调把执行经验沉淀为 Memory 和 Skill，使后续类似任务可以继续复用已有经验，而不只是完成一次性结果。
三者都支持工具、Skill 和 MCP，但扩展重心不同。
WorkBuddy 更强调降低办公用户的使用门槛：通过 Expert、Skill、Connector 和 MCP，把文档处理、数据分析、PPT、邮箱、腾讯文档、TAPD、微云等能力接入任务工作流。
OpenClaw 更强调工程化组合：用户可以通过 Gateway 配置、消息渠道、插件、工具、Cron、Heartbeat 和 Sub-agent，搭建贴近个人工作流、信息处理与跨系统自动化的 Agent 系统。
Hermes 更强调“能力会积累”。它将 Skill 视为可复用的过程性记忆，支持管理和更新 Skill，同时通过插件、MCP、Memory Provider 等可选模块扩展运行环境。
WorkBuddy 的自动化更贴近日常办公，例如定时生成日报、周报、资讯简报、数据汇总和文件整理。它适合“规则明确、周期稳定、最终需要交付文档或消息结果”的办公类工作。
OpenClaw 的优势在于 Gateway Cron、Heartbeat 和 Hook 等持续运行机制。Cron 适合精确定时和独立执行，Heartbeat 则在主 Session 中周期性运行，更适合持续检查邮箱、日历、通知或待办事项。
Hermes 同样支持 Cron，可以执行一次性或周期性任务，并将结果发送到聊天渠道、本地文件或其他配置目标。其 Cron 通常会以新的 Agent Session 运行，因此更适合明确、独立的自动化任务；需要长期偏好时，则应依赖 Memory、Skill 或任务提示词补充上下文。
并行解决的是“能不能同时推进多件事”，跨 Session 记忆解决的是“下次还能不能接着做”。
WorkBuddy 当前更明确的能力是多任务并行：不同任务分别维护独立的工作空间与上下文，适合同时推进多个相对独立的办公任务，例如一边整理会议纪要，一边生成经营分析报告。至于一个复杂任务内部是否会像工程化多 Agent 系统一样自动拆成多个子任务并发执行，桌面端公开文档尚未给出明确的配置与运行说明，因此不宜直接等同于“任务内多 Agent 并行”。
OpenClaw 的并行机制更偏工程化编排。主 Agent 可以启动后台 Sub-agent，每个子 Agent 都运行在独立 Session 中，适合拆分多个相互独立的执行分支、处理长耗时操作或调用不同工具，完成后再将结果回传给主任务。它的 Cron、Hook、Heartbeat 和 Sub-agent 也有不同的 Session 继承方式，因此用户可以更精细地决定哪些任务沿用主会话上下文，哪些任务以隔离方式执行。
Hermes 同样支持通过子 Agent 拆分任务，并可将并行执行、会话检索、长期 Memory 和 Skill 沉淀组合为持续学习闭环。它的重点不只是“并行完成任务”，还包括把经过验证的方法沉淀为可复用 Skill，并在后续 Session 中通过记忆和检索继续利用。需要注意的是，新 Session 并不会天然携带全部历史，特别是 Cron 任务通常以新的 Session 运行，相关上下文仍需要通过 Memory、Skill 或任务提示词显式带入。
因此，三者可以概括为：
• WorkBuddy 更像面向办公交付的桌面 Agent 工作台；
• OpenClaw 更像面向个人自动化与消息驱动场景的自托管 Agent Gateway；
• Hermes 更像强调跨 Session 学习、Skill 沉淀和长期运行的通用 Agent Runtime。
WorkBuddy 的核心不是再做一个聊天机器人，而是尝试把 Agent 放进真实办公环境。
它把几个原本分散的能力组合到一起：
• 大模型：负责理解与推理；
• 工作空间：负责文件与任务边界；
• Skill：负责流程复用；
• Connector 和 MCP： 负责系统连接；
• Expert： 负责专业角色与协作；
• Memory： 负责长期个性化上下文；
• 权限、沙箱和确认机制：负责降低风险；
• 结果区：负责交付、检查和迭代。
因此，WorkBuddy 可以被理解为一种面向知识工作的桌面 Agent Runtime：它不只回答问题，而是把“理解需求—执行操作—生成产物—等待验收”连成一条工作链。
真正决定它能否在企业里长期创造价值的，不是 Agent 会不会“说得像人”，而是企业是否能够持续沉淀三类资产：
当这些资产建立起来后，WorkBuddy 才会从“一个效率工具”，逐渐变成团队可复用的数字执行能力。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。