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、托管智能体一起定位为企业 AI 产品矩阵的一部分。因此，对于希望在同一治理层下同时获得办公自动化和软件开发辅助能力的组织而言，WorkBuddy 尤其相关。

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

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

QwenWork 可以处理本地文件吗？

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

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

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

哪款产品最便宜？

不存在长期稳定且普遍适用的答案，因为个人订阅、企业席位、促销额度和私有化部署合同经常变化。比较时应根据实际使用量、所需部署模式、智能体额度、集成需求和支持服务评估总成本，而不只是关注月费标价。

相关工具

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

相关链接

• WorkBuddy 官方网站：当前个人产品套餐、下载和功能概览。
• WorkBuddy 企业版指南：SaaS、专属 VPC 和私有化部署版本的官方文档。
• QwenWork 产品介绍：官方平台说明，介绍支持的成果类型、企业管理和基于通义千问的能力。
• 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 解析。