openKylin 软件商店现已上架腾讯 WorkBuddy。使用 openKylin 2.0 及以上版本的用户，可以直接在软件商店搜索“WorkBuddy”并一键安装。这次上架值得关注的地方，不只是 Linux 桌面多了一款 AI 应用，而是办公交互正从“问一个问题、得到一段回答”转向“描述目标、交付结果”。
AI 智能体与聊天机器人的差别
传统聊天机器人通常围绕单轮或多轮问答工作：用户提问，模型生成文本，后续整理、校对和执行仍由用户完成。
WorkBuddy 被定位为“全场景 AI 智能体工作台”，强调的是从指令到交付。对办公用户而言，这种变化可以理解为三层能力的组合：
- 理解目标：识别任务对象、格式、期限和约束条件。
- 拆解步骤：把模糊需求转换为可执行的子任务。
- 生成交付物：输出邮件、报告、计划或其他可继续编辑的工作成果。
需要注意的是，来源摘要并未披露 WorkBuddy 在 openKylin 上可以调用哪些本地应用、文件权限或外部服务。因此，不能仅凭“智能体”这一定位假设它一定能自动操作所有桌面软件。实际能力和权限边界，应以安装后的产品界面、授权提示及版本说明为准。
在 openKylin 上安装前先确认版本
图形化安装路径很直接：打开软件商店，搜索“WorkBuddy”，进入应用详情页后安装。由于当前支持范围是 openKylin 2.0 及以上版本，安装前可以先在终端检查系统信息。
下面的命令可直接运行，不会修改系统：
set -e
if [ ! -r /etc/os-release ]; then
echo "无法读取 /etc/os-release"
exit 1
fi
. /etc/os-release
printf '系统名称: %s\n' "${PRETTY_NAME:-$NAME}"
printf '系统版本: %s\n' "${VERSION_ID:-未知}"
printf '处理器架构: %s\n' "$(uname -m)"
case "${VERSION_ID:-}" in
2.*|[3-9].*|[1-9][0-9].*)
echo "版本检查通过：可以前往软件商店搜索 WorkBuddy。"
;;
*)
echo "请确认系统是否为 openKylin 2.0 或更高版本。"
;;
esac
这段脚本只做初步判断。发行版版本号并不总是简单的小数格式，因此最终仍应以 /etc/os-release 的实际内容和软件商店展示的兼容信息为准。
安装完成后，如果不确定桌面入口是否已经注册，可以搜索应用菜单文件：
find /usr/share/applications "$HOME/.local/share/applications" \
-maxdepth 1 -type f -iname '*workbuddy*.desktop' 2>/dev/null
命令返回 .desktop 文件，通常意味着桌面环境已经识别应用入口。没有输出则不一定代表安装失败，应用名称、安装方式或入口文件名也可能不同，此时应回到软件商店查看安装状态。
把一句话写成可执行任务
智能体的效果不仅取决于模型，也取决于指令是否包含足够的业务信息。与其输入“帮我写周报”，不如明确材料、读者、输出格式和限制条件。
下面是一份可以直接改造的办公任务模板：
任务：根据我随后提供的项目记录，生成本周项目周报。
读者：研发负责人和产品负责人
输出结构：
1. 本周完成事项，按模块分组
2. 未完成事项及原因
3. 风险与依赖，标明负责人和期望解决日期
4. 下周计划，使用可检查的动作描述
约束：
- 不补充材料中不存在的事实
- 无法确认的信息标记为“待确认”
- 总字数控制在 800 字以内
- 先列出缺失信息，得到确认后再生成最终稿
原始材料：
[在这里粘贴会议记录、任务列表或工作日志]
这类提示词把“写周报”转换成了带验收条件的任务。对于会议纪要、邮件草稿、需求梳理和数据说明，也可以沿用同一结构：任务、受众、输入、输出格式、约束和确认节点。
上线使用时别忽略权限与复核
AI 智能体可能接触工作文档、会议记录和业务信息。正式用于生产办公前，建议检查以下事项：
- 确认应用来源、版本以及软件商店中的权限说明。
- 弄清文件或文本是否需要上传，以及组织的数据合规要求。
- 对外发送的邮件、报告和合同内容保留人工审批环节。
- 要求智能体标记不确定信息，避免把推测写成事实。
- 先用非敏感任务测试，再逐步扩大使用范围。
WorkBuddy 上架 openKylin，降低了 Linux 桌面用户体验 AI 智能体的安装门槛。但“从一句话到交付”并不等于取消人的判断。更稳妥的采用方式，是让智能体负责整理、拆解和生成初稿，让人继续掌握授权、事实核验与最终发布。