国内办公 Agent 三强：Kimi Work、WorkBuddy、豆包工作，谁更接近“交付工作”
从知识研究、办公制品、本地电脑、企业连接、多模态、长期任务与安全治理出发，对比 Kimi Work、腾讯 WorkBuddy 与豆包工作，并解释它们为何不该简单复制 Claude Code 和 Codex。
阅读导航 · 本篇目录
办公 Agent 最容易被误解成“更强的聊天机器人”：多一个任务面板，回答结束时顺便生成 PPT。但真正的产品分水岭是，它能否从一个含糊目标出发，持续读取材料、调用工具、处理失败，最后交付人类可以直接验收的文件或系统状态。
截至 2026 年 9 月，国内最有代表性的三条路线已经相当清楚：
- Kimi Work 以研究、长材料和 Agent Swarm 为中心；
- WorkBuddy 以桌面工作台、腾讯生态和企业交付为中心；
- 豆包工作以大众入口、多模态内容和跨设备操作为中心。
[!IMPORTANT] **结论先行：**知识研究和高并行资料任务优先看 Kimi Work；国内企业办公、知识库与协作系统接入优先看 WorkBuddy；大众办公、多模态创作和手机—电脑连续体验优先看豆包工作。若任务的最终真相在 Git、测试与 CI 中，Claude Code 或 Codex 仍然更合适。办公 Agent 与 Coding Agent 的边界正在融合，但两者的“完成证明”仍然不同。
本文是AI Agent 八强竞品全景的第三篇。
一、三款产品争夺的不是同一个“办公”
Kimi Work：研究型知识工作站
Kimi Work 官方介绍将它定义为桌面上的本地 AI Agent，组合本地文档、开放网络、专业数据集、浏览器和 Agent Skills。最显眼的卖点是 Agent Swarm：系统可按任务复杂度组织最多 300 个子 Agent。
它最自然的任务是“资料空间很大、问题可拆分、最终需要综合”的工作，例如行业研究、尽调、长文档比对、批量实体收集与专题报告。
需要保持清醒的是，300 是并行上限和产品能力描述，不是质量保证。研究任务的瓶颈常常不是抓到更多网页，而是来源去重、口径统一、反例检索和最终论证。大量子 Agent 只有在证据合并机制足够好时才产生正收益。
WorkBuddy：企业工作台与腾讯生态入口
腾讯云官方产品页把 WorkBuddy 定位为覆盖日常办公、代码开发与设计创意的全场景 AI 工作台。用户从自然语言下达任务，Agent 自主拆解并交付结果；产品同时提供专家、Skills、连接器、自动任务和企业版。
WorkBuddy 的关键不是某个通用模型，而是“工作环境已经在腾讯体系中”的组织优势。企业微信、QQ、腾讯文档、腾讯会议、乐享知识库、身份和云资源可以被放进同一条交付链。它更像带有 Agent Runtime 的企业工作入口，而非单一聊天 App。
豆包工作：大众生产力与多模态工作入口
字节跳动 Seed 团队在Seed2.1 发布说明中，把豆包“办公任务”描述为可完成项目规划、文件处理和跨工具任务的通用 Agent，并把同一模型系列部署到豆包和 TRAE。
豆包工作的优势来自豆包既有用户入口，以及字节在图像、视频、内容理解和消费级产品体验上的积累。Mac App Store 的豆包产品说明已把工作任务、浏览器、Skills、定时任务、Office 套件和图片视频生成放进同一桌面产品。
它最有潜力的不是做另一个企业知识库，而是让普通用户第一次愿意把“整理材料—查资料—做文档—生成视觉内容—跨设备继续”当成一项连续任务。
二、六个维度，比“谁能生成 PPT”更有意义
| 维度 | Kimi Work | WorkBuddy | 豆包工作 |
|---|---|---|---|
| 核心工作对象 | 长材料、网页、数据集、研究问题 | 本地文件、企业知识、办公系统、项目任务 | 文档、网页、Office、多模态内容、电脑操作 |
| 核心差异化 | Agent Swarm 与研究综合 | 腾讯协作生态、企业管理与交付版本 | 大众入口、图像视频、手机—电脑连续性 |
| 典型制品 | 报告、资料汇总、分析结果 | 文档、表格、PPT、项目成果、业务流程结果 | 文档、PPT、表格、图片、视频、应用页面 |
| 扩展方式 | Skills、浏览器、数据集、Kimi Code 协同 | Skills、SkillHub、MCP/CLI 连接器、自定义专家 | Skills、浏览器、Office、字节多模态能力 |
| 企业治理 | 有团队与订阅能力，需按地区与版本核验 | SSO、组织、用量、工具权限、审计、VPC/私有化选项 | 消费产品体验领先，企业治理需看具体“豆包工作”版本 |
| 最大风险 | 并行规模大于证据治理能力 | 产品面宽、版本与能力边界复杂 | 平台能力演进快，企业控制面与稳定性仍需验证 |
三者都能生成内容，但它们的“默认上下文”不同：Kimi 默认从信息世界开始，WorkBuddy 默认从组织工作空间开始，豆包默认从个人设备与内容创作开始。
三、功能对比矩阵：区分核心、可用与套件协同
● 表示当前产品的核心内置能力，○ 表示可以完成但依赖特定版本、相邻产品或并非核心卖点，— 表示没有找到稳定公开的产品级支持。矩阵比较的是产品范围，不代表完成质量。
| 功能模块 | Kimi Work | WorkBuddy | 豆包工作 |
|---|---|---|---|
| 本地文件读写 | ● | ● | ● |
| 联网研究与浏览器 | ● | ● | ● |
| 文档 / 表格 / PPT 制品 | ● | ● | ● |
| 图片与视频创作 | ○ | ● | ● |
| 并行多 Agent / 专家协作 | ● | ● | ○ |
| 定时或自动任务 | ● | ● | ● |
| 企业知识、组织与 SSO | ○ | ● | ○ |
| 专享 VPC / 私有化交付 | — | ● | — |
| 手机侧继续或遥控电脑 | ○ | ○ | ● |
| 完整 Coding Agent 协同 | ●（Kimi Code） | ●（CodeBuddy） | ○（TRAE） |
这张表也说明“功能有无”不足以决定选型：三款产品都能读文件、搜网页和做 PPT，真正差异出现在并行结构、企业控制面、跨端入口，以及相邻产品能否共享上下文。
四、用户体验五要素：从战略层一路看到界面
用户体验五要素要求从抽象到具体逐层检查。对办公 Agent，战略层决定它接过哪类责任，范围层决定能做哪些动作，结构层决定任务如何推进，框架层决定用户如何监督，表现层最终决定产品是“可信工作台”还是“会动的聊天框”。
| 五要素 | Kimi Work | WorkBuddy | 豆包工作 |
|---|---|---|---|
| 战略层 | 服务研究者与知识工作者，把大规模信息处理变成长程任务 | 服务个人与企业，把分散办公、开发和设计任务收进统一工作台 | 服务大众生产力用户，把内容创作与跨设备操作变成自然语言任务 |
| 范围层 | 本地文档、网络、专业数据集、Skills、浏览器、Agent Swarm | 本地文件、办公制品、专家、Skills、连接器、自动任务、企业知识 | 浏览器、Office、Skills、定时任务、图像视频、电脑操作与跨端续跑 |
| 结构层 | 主任务按复杂度拆成大量并行子任务，再综合证据与制品 | 任务可由专家分工，连接企业数据与桌面工具，个人版和企业版形成多层结构 | 从对话进入工作任务，授权后操作本地或虚拟环境，并在手机继续控制 |
| 框架层 | 桌面 Work 模式强调任务计划、子 Agent 过程和研究结果 | 工作区、项目、专家、SkillHub、连接器和制品预览共同构成控制台 | 保留豆包熟悉对话入口，以技能栏、任务过程、Office 和多模态制品扩展 |
| 表现层 | 研究感、并行感强，容易产生“重任务能力”预期 | 工作台与专家团队感强，企业功能密度高 | 消费级表达、多模态反馈和跨端连续感更强 |
五层之间最关键的断点
- Kimi Work 的战略层是“复杂研究”，结构层就必须解决证据合并，而不能只展示子 Agent 数量；
- WorkBuddy 的战略层是“企业工作台”，框架层就必须让身份、权限、数据源和制品状态可见；
- 豆包工作的战略层是“大众跨端生产力”，表现层的简单不能以隐藏高风险授权为代价。
五要素的价值正是在这里：它把一句“体验不错”拆成可以定位的产品问题。
五、价值曲线：三款产品主动选择了什么
以下 1–5 分是对公开产品策略的编辑性编码，不是统一环境下的性能测试。1 表示非当前核心，5 表示已有高投入和鲜明产品表达。曲线用于看取舍，精确值应在企业 PoC 中由真实任务替换。
{
"title": {
"text": "国内办公 Agent 价值曲线",
"subtext": "相对策略投入，1=非核心，5=高投入；截至 2026-09-04",
"left": "center"
},
"tooltip": { "trigger": "axis" },
"legend": {
"top": 50,
"data": ["Kimi Work", "WorkBuddy", "豆包工作"]
},
"grid": {
"left": 40,
"right": 24,
"top": 96,
"bottom": 60,
"containLabel": true
},
"xAxis": {
"type": "category",
"boundaryGap": false,
"data": ["研究\n深度", "企业\n连接", "多模态\n创作", "并行与\n长任务", "跨设备\n连续", "企业\n治理"]
},
"yAxis": {
"type": "value",
"name": "相对投入",
"min": 1,
"max": 5,
"interval": 1
},
"series": [
{
"name": "Kimi Work",
"type": "line",
"symbol": "circle",
"symbolSize": 8,
"lineStyle": { "width": 3, "color": "#b84d2e" },
"itemStyle": { "color": "#b84d2e" },
"data": [5, 3, 4, 5, 3, 3]
},
{
"name": "WorkBuddy",
"type": "line",
"symbol": "diamond",
"symbolSize": 9,
"lineStyle": { "width": 2, "type": "dashed", "color": "#77736d" },
"itemStyle": { "color": "#77736d" },
"data": [4, 5, 4, 4, 4, 5]
},
{
"name": "豆包工作",
"type": "line",
"symbol": "emptyCircle",
"symbolSize": 9,
"lineStyle": { "width": 2, "color": "#9b756a" },
"itemStyle": { "color": "#9b756a" },
"data": [4, 4, 5, 4, 5, 3]
}
]
}
| 价值要素 | Kimi Work | WorkBuddy | 豆包工作 |
|---|---|---|---|
| 研究深度 | 5 | 4 | 4 |
| 企业连接 | 3 | 5 | 4 |
| 多模态创作 | 4 | 4 | 5 |
| 并行与长任务 | 5 | 4 | 4 |
| 跨设备连续 | 3 | 4 | 5 |
| 企业治理 | 3 | 5 | 3 |
三条曲线各自有清楚峰值：Kimi Work 抬高研究与并行，WorkBuddy 抬高企业连接与治理，豆包工作抬高多模态与跨设备。战略风险不是某项只有 3 分，而是为了追赶竞品把所有维度都拉成 5，最终失去用户选择它的理由。
用蓝海战略的四动作框架，可以把差异化翻译成资源选择：
| 产品 | 剔除 / 减少 | 增加 | 创造 |
|---|---|---|---|
| Kimi Work | 减少只展示并发数量的技术叙事 | 增加证据去重、冲突处理和研究审计 | 创造从研究结论到代码、表格与持续监测的连续工作状态 |
| WorkBuddy | 减少产品线与版本概念造成的认知负担 | 增加企业连接器的权限可见性和结果验证 | 创造可被组织复用、审计和计费的“数字专家工作包” |
| 豆包工作 | 减少低风险操作中的打断和传统聊天残留 | 增加跨端任务状态、关键动作确认和失败恢复 | 创造文字、Office、图片、视频与设备操作一体的个人工作流 |
六、逐个产品 SWOT：优势只有转成策略才有用
| 产品 | Strengths 优势 | Weaknesses 劣势 | Opportunities 机会 | Threats 威胁 |
|---|---|---|---|---|
| Kimi Work | 长材料与研究心智；Agent Swarm；自研模型、API、Work 与 Code 的纵向组合 | 多产品入口可能割裂上下文；企业治理与结果审计仍需验证；大并发成本难预估 | 建立中文研究、专业数据与代码分析的一体化工作站 | 并行能力快速商品化；错误证据被大规模聚合；订阅与算力压力 |
| WorkBuddy | 腾讯办公生态；企业身份、知识、连接器、审计与多种交付版本；办公制品覆盖广 | 定位横跨办公、开发、设计，认知与版本复杂；核心闭源；能力受套件边界影响 | 成为国内企业 Agent 统一入口和托管运行平台 | 企业担忧锁定与数据边界；竞品接入同类 MCP/Skills；席位成本需要持续 ROI |
| 豆包工作 | 大众用户入口；字节多模态资产；消费级交互与手机—电脑连续性 | 企业控制面公开信息较少；工作 Agent 品牌较新；跨应用稳定性受外部界面影响 | 把 Agent 下沉为大众生产力和系统级设备入口 | 第三方平台限制、隐私信任与误操作风险；通用办公功能快速同质化 |
对应的组合策略是：
- **SO：**Kimi 用研究与模型资产构建专业工作流；WorkBuddy 用组织连接拿下可复用企业场景；豆包用多模态和跨端入口创造新的个人任务频次。
- **WO：**Kimi 优先统一产品状态与证据治理；WorkBuddy 简化产品架构并明确能力继承关系；豆包补齐企业权限、审计和可恢复执行。
- **ST：**三者都应把本土工作流深度变成壁垒，而不是只比较通用模型分数。
- **WT：**在外部发送、支付、删除和生产系统写入上保持硬确认与回滚，避免一次高影响事故透支整个品类的信任。
七、第一回合：研究与资料密集型任务
这一回合 Kimi Work 占优。
Kimi 长期以长文本、搜索和研究建立用户心智；Kimi Work 又把本地文件、网络、专业数据集与并行 Agent 放在一个工作台里。对于“比较 50 家公司”“读取一批 PDF 并形成证据链”“跨多语言来源整理专题”这类可拆分任务，它的产品结构与问题结构天然一致。
WorkBuddy 也能做网络调研与报告，并且更容易把结果落进企业文档和后续流程；豆包则在最终内容表现和多模态包装上有优势。问题是，研究质量不能用报告长度评价。三款产品都应该接受同一套检查：
- 每个关键结论能否回到原始来源；
- 是否区分官方口径、媒体报道和模型推断；
- 多个 Agent 是否重复引用同一二手信息；
- 日期、币种、地域和统计口径是否统一；
- 反例和不确定性是否被保留。
如果产品只展示“调用了几百次工具”，却不能给出清晰证据账本，并行规模越大，错误聚合的风险越大。
八、第二回合：企业办公与系统连接
这一回合 WorkBuddy 的位置最好。
腾讯已经把个人工作台、企业版和 Managed Agents 放进一个产品矩阵。企业版文档提供组织、SSO、成员用量、企业知识、模型配置、安全审计和 OpenAPI，并提供共享 SaaS、专享 VPC 与私有化等交付方式，参见WorkBuddy Enterprise 版本说明。
更重要的是连接器：官方文档把 MCP + CLI、Skill + CLI 作为外部系统接入方式。对于大量工作沉淀在企业微信、腾讯文档、会议、邮箱和内部知识库的组织，连接成本可能比模型差距更影响落地速度。
但“接入系统”不是“自动获得业务权限”。企业 PoC 必须检查：
- Agent 代表谁访问数据，权限是否继承真实用户；
- 读取、写入、发送、删除能否分别控制；
- 子 Agent 与连接器能否越过主 Agent 的权限边界；
- 每次外部写操作是否有审计记录和幂等机制；
- 模型、插件、脚本和企业数据分别运行在哪里。
WorkBuddy Enterprise 的 CodeBuddy 子系统文档已经描述默认只读、Allow / Ask / Deny、Bash 沙箱和审计等机制，参见安全概述。这些能力不能自动视为个人版 WorkBuddy 每个工作模式的共同实现；采购方仍应在自己的租户、版本与交付形态中逐项验证，也不应把腾讯云整体认证自动等同于每条 Agent 数据流都满足要求。
九、第三回合：多模态创作与跨设备连续性
这一回合豆包工作最有差异化。
报告、PPT、表格只是办公的一部分。市场、运营、电商、教育和个人创作者的任务经常同时包含文字、图片、视频、网页与发布素材。豆包与字节 Seed 模型的多模态产品栈，使它更容易把“分析—写作—视觉生成”放在一次任务里完成。
豆包手机助手又提供了另一条延伸路径。其官方网站将产品明确标为早期探索，强调操作手机与合作硬件。它与豆包工作不是同一个产品，但共同指向字节的长期方向：Agent 不只住在聊天页，而是跨越手机和电脑，接近系统级入口。
这条路线的机会巨大，风险也更高。GUI 操作容易受到页面变化、弹窗、登录状态和风控影响；跨 App 行动涉及更复杂的授权与平台规则。消费者看到的是“替我点完”，产品团队必须处理的却是状态识别、误操作恢复、支付确认、隐私边界和第三方平台博弈。
因此，豆包工作的领先指标不该只是生成内容质量，而应包括跨端续跑成功率、关键动作确认准确率、失败恢复率和对外发送前的人工控制。
十、Kimi 的特殊位置：同时拥有 Work、Code 和模型
Kimi 是三者中产品纵深最特殊的一家：
- Kimi App / Agent 面向通用任务；
- Kimi Work 面向本地知识工作；
- Kimi Code 面向软件工程；
- Kimi 模型与 API 提供统一能力底座。
这种结构让一个研究任务可以自然过渡到数据处理或代码生成，也让 Agent Swarm 能在多个产品表面复用。官方帮助中心把 Agent、Deep Research、PPT、Docs、Sheets、Kimi Code 与 Kimi Work 放在同一积分池中，参见Kimi 计费说明。
但产品纵深也可能制造认知成本：用户该在 Agent、Work 还是 Code 发起任务？本地任务与云端任务如何迁移？不同入口的权限、历史与 Skill 是否一致？Kimi 能否把“多产品”收敛成“一套连续工作状态”，将决定垂直整合最终是优势还是菜单。
十一、Claude Code 与 Codex 为什么也会进入办公战场
把 Claude Code 和 Codex 叫做“纯编程工具”已经不准确。
Codex App 的官方定位明确提到文档、PDF、表格等 Skills 和非代码知识工作；OpenAI 公布的内部使用数据也显示非开发者正在用 Codex 做自动化、数据转换与结构化分析，见Agents 如何改变工作。
Claude Code 则在桌面端加入预览、Review、PR 跟踪和可分享 Artifacts。Artifacts可以把代码、连接器和会话上下文变成交互页面、Dashboard、Incident 页面或发布清单。
两者进入办公的方式与国内产品不同：它们不是先做 Office 套件，而是把“所有工作都可以通过文件、代码、浏览器和连接器表达”作为出发点。
这套方式对数据分析、技术运营、研究、财务建模和自动化很强，因为过程可脚本化、结果可版本化、验证可重复。对只想在熟悉 GUI 中完成中文材料、PPT 和内部协作的普通用户，WorkBuddy 与豆包的入口更自然。
十二、国内办公 Agent 的护城河与三道难题
护城河一：工作关系，而不是模型关系
谁能理解企业身份、文档权限、会议上下文、组织术语和审批流程，谁就更接近真实工作。模型可以替换，已经接通的工作关系很难替换。
护城河二：制品最后一公里
用户不会为“生成了 Markdown”长期付费，而会为一份格式正确的 Excel、可以汇报的 PPT、已经更新的项目计划或可直接发布的素材付费。办公 Agent 的质量标准是下游是否继续可用。
护城河三：中文与本土平台的异常处理
真正难的不是调用一次接口，而是处理二维码登录、权限过期、文档格式差异、企业自建系统、平台风控和中文非结构化材料。稳定处理这些边角问题，会比一次模型升级更持久。
同时，三款产品都要面对三道难题：
- **完成证明不足。**文档存在不等于内容正确，发送成功不等于发送给了正确对象；
- **权限范围扩大。**Agent 接入的系统越多，间接提示注入和凭证滥用的损失越大；
- **成本不透明。**积分、模型 Token、子 Agent 数量和工具调用共同决定成本，用户很难在任务前预测。
十三、个人与企业该怎么选
个人用户
- 经常做长资料研究、行业报告和批量信息处理：先试 Kimi Work；
- 经常处理中文办公文件，同时需要设计、开发等多种专家能力：先试 WorkBuddy；
- 经常做图片视频内容、希望手机与电脑连续操作：先试豆包工作；
- 任务最终要修改代码仓库并通过测试：直接从 Claude Code、Codex 或 Kimi Code 中选。
企业团队
不要先买全年席位。用四周完成三个步骤：
- 从真实部门收集 30 个高频任务，覆盖读、写、外部发送与高风险动作；
- 让候选产品在同一材料、同一权限边界下运行，记录完成率、人工修正时间和每任务成本；
- 对进入下一轮的产品做数据流、身份、沙箱、日志、删除、模型训练使用和退出迁移审查。
评分建议采用加权而非平均：
业务得分 = 35% 可验收完成率
+ 20% 人工节省时间
+ 15% 结果可追溯性
+ 15% 权限与安全
+ 10% 单任务总成本
+ 5% 用户满意度对包含外部发送、支付、删除、生产系统写入的任务，安全不应只是 15% 权重，而应设置为一票否决门槛。
十四、最后的判断：国产 Agent 的主场是“把工作接过来”
Kimi Work、WorkBuddy 和豆包工作都不应该只追求像 Claude Code 一样会调用 Shell。它们更大的机会，是把中文知识工作、国内协作网络、多模态创作和设备入口变成 Agent 可以持续操作的环境。
Kimi 当前最像研究与并行工作引擎，WorkBuddy 最像企业 Agent 工作台，豆包工作最像大众生产力入口。三者还没有出现一个在研究、企业治理、多模态和跨端执行上全面领先的统一产品，这反而说明市场仍在早期。
Claude Code 与 Codex 提供了一个值得借鉴的标准：完成不是生成一份看起来不错的结果，而是把上下文、行动、验证、权限和审查连成闭环。国内产品是否能够把入口优势变成这种闭环，将决定它们最终是下一代 Office，还是又一批更昂贵的聊天窗口。
资料截至 2026-09-04。文中关于并发规模、产品覆盖与效率的描述均来自厂商公开资料；本文将其作为能力范围或市场定位，而非独立实测成绩。企业功能会因个人版、团队版、专享版和私有化版本而不同，采购时应以合同、控制台和实际 PoC 为准。