import lark_oapi as lark
from volcengine.engines import maas

1. 初始化飞书客户端（用于消息/文档操作）

lark_client = lark.Client.builder() \
.app_id("cli_xxxxx") \
.app_secret("xxxxx") \
.build()

2. 初始化豆包大模型客户端（火山引擎 MaaS）

maas_client = maas.MaasService(
'maas-api.ml-platform-cn-beijing.volces.com',
'cn-beijing'
)
maas_client.set_ak("your_access_key")
maas_client.set_sk("your_secret_key")

3. 调用豆包模型生成文档摘要

req = maas.ChatRequest(
model="doubao-pro-256k",
messages=[{"role": "user", "content": "帮我总结这篇会议纪要的3个关键决策"}],
temperature=0.3,
max_tokens=500
)
resp = maas_client.chat(req)
print(f"豆包生成结果: {resp.choices[0].message.content}")

4. 将结果写入飞书文档（原生集成）

飞书API直接调用，无需额外认证

doc_content = resp.choices[0].message.content

create_doc(lark_client, title="AI生成摘要", content=doc_content)

### 7.2 WorkBuddy：自定义 Skill + MCP 风格扩展示例

```python
# WorkBuddy 企业版：自定义 Skill + MCP Connector 集成
# WorkBuddy 支持通过 MCP 协议接入企业内部系统

import json
from typing import Any, Dict

# 1. 定义自定义 Skill（WorkBuddy 的扩展单元）
class CRMDataSkill:
    """从企业 CRM 系统拉取客户数据，供 WorkBuddy Agent 调用"""

    def __init__(self, crm_api_url: str, api_key: str):
        self.crm_api_url = crm_api_url
        self.api_key = api_key

    @property
    def name(self) -> str:
        return "fetch_crm_customers"

    @property
    def description(self) -> str:
        return "从CRM系统获取客户列表，支持按区域、行业筛选"

    def get_parameters(self) -> list:
        return [
            {"name": "region", "type": "string", "description": "客户所在区域"},
            {"name": "industry", "type": "string", "description": "客户所属行业"},
            {"name": "limit", "type": "int", "description": "返回条数", "default": 50}
        ]

    def execute(self, params: Dict[str, Any]) -> str:
        import requests
        resp = requests.get(f"{self.crm_api_url}/customers",
            headers={"Authorization": f"Bearer {self.api_key}"},
            params=params, timeout=10)
        return json.dumps(resp.json(), ensure_ascii=False)

# 2. 注册到 WorkBuddy Skill 配置
skill_config = {
    "skill_name": "crm_customer_fetch",
    "skill_class": "CRMDataSkill",
    "permissions": ["read:crm", "network:internal"],
    "timeout_seconds": 30,
    "rate_limit": "100/hour"
}

# 3. 通过 MCP Connector 接入 OA 审批流
oa_connector = {
    "connector_type": "dingtalk_approval",  # 也支持 wecom/feishu
    "approval_code": "xxxxx",
    "auto_submit": True,
    "agent_id": "workbuddy_agent_001"
}

print("Skill 注册完成，WorkBuddy 可在对话中直接调用 CRM 数据")

7.3 QwenWork：钉钉 + Qwen API 示例

# 千问办公 QwenWork：通过钉钉开放平台 + DashScope API 调用
# 环境依赖：pip install dingtalk-sdk dashscope

import dingtalk.api
import dashscope
from dashscope import Generation

# 1. 初始化钉钉客户端（25项原生能力）
dingtalk_client = dingtalk.api.DingTalkClient(
    app_key="dingxxxxx",
    app_secret="xxxxx",
    agent_id="xxxxx"
)

# 2. 初始化 Qwen3.8 模型
dashscope.api_key = "sk-xxxxx"

# 3. 场景：会议结束后自动提取待办并分发到钉钉
def process_meeting_and_assign_tasks(meeting_transcript: str):
    """从会议纪要提取行动项 → 创建钉钉待办 → 分发责任人"""

    # Step 1: Qwen 提取行动项
    prompt = f"""从以下会议纪要中提取所有行动项，输出JSON格式：
    {{
      "tasks": [
        {{"title": "任务标题", "assignee": "负责人姓名", "deadline": "YYYY-MM-DD"}}
      ]
    }}

    会议纪要：{meeting_transcript}
    """

    resp = Generation.call(
        model="qwen-max",
        prompt=prompt,
        result_format="message",
        temperature=0.1  # 低温度保证格式稳定
    )

    tasks = eval(resp.output.choices[0].message.content)

    # Step 2: 通过钉钉API创建待办并分发
    for task in tasks["tasks"]:
        dingtalk_client.todo_create(
            title=task["title"],
            assignee=task["assignee"],
            deadline=task["deadline"],
            source="AI会议纪要"
        )
        dingtalk_client.send_group_message(
            msg_type="text",
            content=f"📋 新任务分配：{task['title']} → {task['assignee']}，截止 {task['deadline']}"
        )

    return f"已提取 {len(tasks['tasks'])} 个行动项并分发完成"

# 4. 利用 Night Plan 夜间错峰执行批量任务
def nightly_batch_report():
    """凌晨2点执行，享受夜间折扣"""
    import schedule
    schedule.every().day.at("02:00").do(generate_daily_reports)
    # Night Plan: 22:00-08:00 积分消耗降低60%

在生产环境代码中，应避免对模型生成的输出使用 eval()。应改用经过验证的 JSON 解析，并在触发企业操作前执行模式校验。

8. 生态对比

原文认为，选择企业级 AI 办公工具，某种程度上也是在选择一个生态。

更加谨慎地概括，三种生态策略可以表示为：

• 豆包／飞书： 最适合已经以飞书协作和火山引擎服务为中心的组织。
• WorkBuddy／腾讯云： 提供广泛的企业部署选择、本地文件操作、编码集成和大型 Skills 生态。
• QwenWork／钉钉／阿里云： 在企业即时通信集成、可编辑交付成果，以及支持的工作流中访问阿里巴巴相关业务数据源方面具有优势。

原图中的部分生态数量自发布后已经发生变化，因此应将该图片视为带有时间标记的快照。

9. 安全与合规

安全是最需要谨慎核验营销说法的领域。

腾讯当前官方文档确认，WorkBuddy 企业版提供 SaaS、专属 VPC 和私有化部署版本。

这使 WorkBuddy 成为需要灵活部署的组织特别值得考虑的选项。但这并不意味着它自动成为唯一合规选择；实际合规性取决于数据分类、区域要求、行业规则、网络架构和合同条款。

10. 部署场景示例

原文按照生态对现实使用场景进行了归类。

实际规律是：

• 以飞书为主的团队最能从低摩擦的协作上下文中受益。
• 以腾讯为主的工程组织可以在共享企业层下组合使用 WorkBuddy 和 CodeBuddy。
• 以钉钉为主的组织可以利用 QwenWork 的 25 项企业即时通信能力，连接会议、消息、审批、日程、文件和任务。

对于零售和电子商务，QwenWork 官方网站目前宣传可访问包括 1688 在内的业务数据源，以及其他受支持的商业／社交数据源。

11. 优势与不足

豆包企业版

优势

• 非常适合以飞书为中心的组织。
• 协作数据可以贴近 AI 工作流。
• 背靠字节跳动的豆包模型和火山引擎基础设施。
• 对现有飞书用户而言迁移摩擦较低。

不足

• 当企业不使用飞书作为主要协作层时，吸引力较弱。
• 产品边界高度依赖字节跳动企业生态。
• 与面向开发者的腾讯工具相比，编码并不是最明确的差异化能力。

WorkBuddy 企业版

优势

• 桌面原生智能体工作流，能够直接访问本地文件。
• 与 CodeBuddy 和腾讯开发技术栈连接紧密。
• Skills 生态规模较大；当前官方页面宣传已有 70,000+ Skills。
• 官方记录了 SaaS、专属 VPC 和私有化部署方式。
• 官方记录了企业身份、安全、审计和 OpenAPI 支持。

不足

• 桌面原生部署可能需要更多终端管理工作。
• 深度协作工作流可能需要通过集成实现，而不是原生存在于某一即时通信套件中。
• 对个人重度用户而言，高阶套餐可能价格较高。

QwenWork

优势

• 深度集成钉钉，支持 25 项企业即时通信能力。
• 支持网页端、桌面端和钉钉访问。
• 支持可编辑的 PPTX、Word、Excel 和 HTML 交付成果。
• 支持多模态理解和内容生成。
• 适合阿里巴巴生态及受支持的商业数据工作流。

不足

• 产品能力和套餐在发布后仍处于快速变化阶段。
• 企业私有化部署选项应直接确认，不应自行假定。
• 已经使用其他即时通信生态的团队可能需要更多集成工作。

12. 选型决策树

对原始决策表进行更保守的整理如下：

13. 总结与趋势展望

三款产品之间不存在适用于所有企业的绝对赢家。它们的价值高度取决于企业现有工作流所在的位置。

豆包／飞书是已经标准化使用飞书团队最自然的选择。WorkBuddy在本地文件、编码、跨应用工作、部署灵活性和企业智能体治理都很重要时更具优势。QwenWork则在钉钉集成、可编辑交付成果和阿里巴巴生态工作流方面表现突出。

原文更广泛的判断仍然具有参考价值：竞争正在从功能清单转向工作流闭环。重要指标不是 AI 能够谈论多少事情，而是它能否在可接受的安全性、可审计性和成本条件下，端到端完成多少业务任务。

版本与环境说明

原文使用了以下 2026 年 8 月 10 日参考环境：

由于这些产品发展迅速，实施前应核实模型名称、API、软件包名称、价格、额度和产品边界。

常见问题

豆包企业版、WorkBuddy 和 QwenWork 的主要区别是什么？

主要区别在于产品架构。豆包与飞书工作流联系最紧密，WorkBuddy 是桌面原生的企业级 AI 工作台，而 QwenWork 覆盖桌面端、网页端和钉钉，并重点关注企业交付成果。

已经使用飞书的企业应该优先选择哪款产品？

豆包和飞书 AI 技术栈是最自然的起点，因为协作数据和工作流已经位于同一生态中。主要收益是迁移和集成成本更低。

哪款产品支持私有化部署？

腾讯官方记录了 WorkBuddy 企业版的 SaaS、专属 VPC 和私有化部署版本。对于豆包和 QwenWork，具有严格部署要求的企业应直接向供应商确认当前企业选项。

WorkBuddy 适合开发者团队吗？

适合。腾讯将 WorkBuddy 与 CodeBuddy、Managed Agents 一起定位为企业级 AI 产品矩阵的一部分。因此，对于希望在同一治理层下实现办公自动化和软件开发辅助的组织而言，WorkBuddy 尤其值得考虑。

QwenWork 是否真正深度支持钉钉？

是。QwenWork 当前官方网站宣传支持 25 项企业即时通信能力，包括消息、群聊、考勤、审批、会议、日历、文档、知识库以及相关企业工作流。

QwenWork 可以处理本地文件吗？

可以。其官方快速入门文档表示，桌面客户端可以直接分析和处理本地文档、表格、图片和视频。

本文中的代码示例可以直接用于生产环境吗？

不可以。这些代码示例是从原始 CSDN 文章中保留的说明性集成示例。其中多个 API 和类名都应根据当前官方 SDK 文档进行核对，模型生成的 JSON 也应经过验证，而不应使用 eval() 执行。

哪款产品最便宜？

没有稳定且适用于所有情况的答案，因为个人订阅、企业席位、促销额度和私有化部署合同都会频繁变化。应根据实际使用量、所需部署模式、智能体额度、集成需求和支持服务比较总成本，而不能只看月费这一项。

相关工具

• 腾讯 WorkBuddy：WorkBuddy 官方产品页面，介绍桌面 AI 办公工作流、本地文件操作、Skills 和自动化能力。
• WorkBuddy 企业版：企业官方产品页面，介绍部署模式、管理、安全和 OpenAPI。
• QwenWork：阿里巴巴 QwenWork 官方网站，介绍企业协作、可编辑交付成果、多模态工作和 Skills。
• QwenWork 文档：官方使用、产品、桌面端、网页端和企业工作流文档。
• 飞书开放平台：飞书应用、机器人、API 和企业集成的官方开发者平台。
• 阿里云百炼：访问和集成通义千问模型的阿里云官方平台。

相关链接

• WorkBuddy 官方网站：当前个人产品套餐、下载和功能概览。
• WorkBuddy 企业版指南：SaaS、专属 VPC 和私有化部署版本的官方文档。
• QwenWork 产品介绍：官方平台说明，介绍支持的交付成果、企业管理和基于 Qwen 的能力。
• QwenWork 快速入门：钉钉、网页端和桌面端使用的官方说明。
• 飞书开放平台：飞书生态的官方 API 和应用集成门户。
• 火山引擎：字节跳动旗下云服务和 AI 基础设施平台。
• 钉钉开放平台：企业集成的钉钉官方开发者平台。
• 原始 CSDN 文章：原始中文对比文章，采用 CC BY-SA 4.0 许可协议。

总结

豆包企业版、WorkBuddy 和 QwenWork 代表了三种不同的企业级 AI 路径：协作套件原生 AI、桌面原生智能体，以及多端企业生产力智能体。

在采购决策中，最可靠的方法是从企业现有的协作技术栈、部署要求、本地文件需求、编码强度和治理模式出发。功能数量本身不如实际测试重要：企业需要验证智能体能否安全地从头到尾完成真实工作流。

选择适配现有工作流的平台，然后在正式承诺之前，核实准确的 2026 年价格、API、部署模式和安全控制。

来源说明

原文于 2026 年 8 月 10 日发布在 CSDN，并明确采用 CC BY-SA 4.0 许可协议。本英文版本是基于原文改编的衍生版本，保留了原文主题、主要结构、对比顺序、表格、技术示例和高度相关的示意图，同时提升了可读性并增加了核验说明。上文已包含原始来源署名，本衍生版本也应依据相同的 CC BY-SA 4.0 条款进行再分发。

本文保留了八张高度相关的来源图片：时间线、架构对比、能力雷达、评分拆解、价格图、生态示意图、部署／使用场景对比和选型决策树。CSDN 宣传图、头像、二维码、互动元素和无关装饰图片均未保留。

原文包含若干具有时效性或属于编辑判断而非独立基准测试的说法。尤其需要注意：六维评分是作者自行建立的评分框架；生态数量和价格截至 8 月 10 日；“最强”“唯一”或“市场领先”等说法，除非另有来源，不应被理解为独立基准测试结果。

发布前重新核对了若干官方事实。腾讯当前记录了 WorkBuddy 的本地文件操作、70,000+ Skills、企业治理、OpenAPI，以及 SaaS／专属 VPC／私有化部署版本。QwenWork 当前记录了网页端、桌面端和钉钉访问；25 项企业即时通信能力；可编辑 PPTX、Word、Excel 和 HTML 交付成果；多模态能力；桌面端本地文件处理；以及 Skills／专家套件。

由于用户要求保留代码块，本文保留了原文的三个 Python 示例。它们应被视为来源中的说明性示例，而非经过验证的可运行 SDK 示例。当前 SDK 方法、模型标识符、身份验证流程和软件包版本必须根据官方文档进行核对。QwenWork 示例对模型输出使用 eval() 的方式不适合生产环境，应替换为经过验证的 JSON 解析。