实践：把 WorkBuddy 接到办公软件：搭一个会读合同、能调度业务系统的 AI 数字员工

如果你只是想要一个能回答问题的 AI 助手，网上现成接口调用脚本随处可见：接收指令→组装 Prompt→调用大模型→返回结果，几十行代码就可以实现。

但企业真实办公场景里，单纯问答很快会遇到现实阻碍：合同生成完不能直接发起电子签章；产出的报告无法直接同步到文档平台；审批进度需要人工切换系统复制粘贴；AI 只能被动等待指令，没办法跟进业务节点。

我们可以基于WorkBuddy搭建一套私有化部署的企业 AI 数字员工：大模型负责内容生成，各类办公业务系统负责实际业务执行，中间由 WorkBuddy 完成意图解析、跨系统调度、业务记忆、任务自动跟进。

WorkBuddy 是腾讯推出的全场景 AI 办公 Agent 工作台，核心不是单纯对话，而是把不同办公软件串联起来，把 AI 生成的内容落地成真实业务动作WorkBuddy。

项目模式：基于 WorkBuddy 连接器、自定义 Skill 能力，对接契约锁电子签章、企业微信、飞书、钉钉、腾讯文档、Jira 项目管理系统，实现内容生成‑业务执行‑状态回传‑自动提醒完整办公闭环。

为什么不直接调用大模型 API 做办公自动化

网上很多 Demo，直接调用大模型 API，输入文字拿到输出文本，看着简单，落地企业会遇到四个硬伤：

1. AI 产出和业务系统割裂。AI 写好合同文本，还需要人工复制文件、登录签章平台上传、手动选择签署人发起签署；AI 输出周报，需要手动粘贴文档，整个流程 AI 只管写，不管执行。
2. 缺少业务上下文记忆。每次交互都是全新会话，上次发起的合同编号、待签署人员、项目节点全部丢失，需要员工反复复述业务背景。
3. 没有多软件协同调度能力。一个完整办公动作，经常跨多个系统：飞书接收需求 → WorkBuddy 生成合同 → 契约锁发起签章 → Jira 更新任务状态 → 企业微信推送通知。简单 API 脚本很难做多系统编排。
4. 只能被动应答，不会主动跟进。你不下指令 AI 就静止不动；而真实办公自动化核心价值，是主动跟进签署进度、到期提醒、任务超时告警，实现 “事找人” 而不是 “人找事”。

WorkBuddy 这套方案，本质就是补齐这四件事：业务连接器、长期业务记忆、多系统编排、主动任务推送。大模型只是负责思考生成内容，真正干活的是各个业务软件。

整体架构

员工端（飞书 / 钉钉 / 企业微信）
    │聊天消息、任务指令
    ▼
┌────────────────────────────────────┐
│ WorkBuddy（企业版Agent）           │
│ 意图解析｜业务记忆库｜Skill连接器  │
└───┬───────┬────────┬────────┬────┘
    │       │        │        │
    ▼       ▼        ▼        ▼
契约锁开放API  企业微信API   飞书/钉钉开放接口
腾讯文档API    Jira REST API  SQLite业务记忆库

• IM 端（企业微信 / 飞书 / 钉钉）：员工日常聊天入口，直接用自然语言下达任务；消息通过官方机器人接口推送到 WorkBuddyWorkBuddy。
• WorkBuddy 核心层：解析员工自然语言，读取历史业务记忆，调用不同 Skill / 连接器，组装参数调用下游业务系统；接收下游回调事件，处理完成后把结果推送回 IM。
• 业务系统集群
  1. 契约锁：电子签章能力，合同草稿创建、上传文档、发起签署、查询签署状态、下载签署完成文件，全部通过开放平台 API 完成契约锁。
  2. 协同办公套件：腾讯文档、飞书文档，实现文件读写、表格更新、报告存档。
  3. 项目管理 Jira：创建任务、更新状态、回填合同编号、记录业务备注。
• 业务记忆库：SQLite 存储业务上下文，保存合同 ID、签署人、项目编号、任务时间节点，不同员工业务数据互相隔离，不会串业务。

连接器解耦设计：今天对接契约锁，后续可以替换其他电子签平台；业务逻辑写在 WorkBuddy Skill，不需要大规模重写上层交互。

部署前需要准备什么

表格

安全配置要点：服务器安全组只放开必要端口；业务系统回调接口只允许内网或者对应厂商出口 IP 访问，不要直接暴露全公网；API 密钥、密钥文件权限设置最小权限。

第一步：部署 WorkBuddy 企业版，开启自定义 Skill 能力

#拉取企业版部署包
git clone 企业部署仓库地址 /opt/workbuddy-enterprise
cd /opt/workbuddy-enterprise

#启动容器服务
docker compose up -d
docker compose ps

正常运行后，会出现核心容器：workbuddy-main主服务、skill‑gateway连接器网关、callback‑server回调接收服务。

如果服务器配置较低，构建部署容易 OOM，可以本地调试打包 Skill，再上传到服务器。

第二步：配置各个业务系统连接器与 Skill

进入部署目录复制环境配置模板

cd deploy/prod
cp .env.example .env
chmod 600 .env
vim .env

需要填入核心配置项示例：

#契约锁电子签章配置
QIYESUO_ACCESS_KEY=xxxx
QIYESUO_SECRET_KEY=xxxx
QIYESUO_API_HOST=https://openapi.qiyuesuo.com

#IM机器人配置，以企业微信为例
WECOM_BOT_CORPID=xxxx
WECOM_BOT_SECRET=xxxx

#Jira项目管理
JIRA_HOST=https://jira.xxx.com
JIRA_API_TOKEN=xxxx

#后台管理员密码，务必使用高复杂度随机字符串
ADMIN_PASSWORD=一串随机长字符

#可使用本机器人的员工白名单，填写企业IM用户ID，逗号分隔
USER_WHITELIST=user001,user002

注意：环境变量全部大写；不要写点号分隔配置；白名单为空会允许全部用户调用业务接口，生产环境严禁这么配置。

契约锁 Skill 核心能力说明

契约锁开放平台支持创建合同草稿、上传文档、指定签署方、发起签署、轮询 / 回调获取签署状态、下载签署完成文件契约锁。我们封装自定义 Skill，对外暴露自然语言可调用能力：

1. 根据 WorkBuddy 生成的合同文本，上传文件创建契约锁合同草稿；
2. 输入签署人列表，自动配置签署位置，发起电子签约；
3. 接收契约锁回调，识别签署完成、驳回、过期状态；
4. 签署完成自动下载已签章文件，保存至腾讯文档 / 微盘；
5. 签署异常、即将到期自动推送 IM 消息提醒负责人。

第三步：配置 IM 端接入（企业微信 / 飞书 / 钉钉）

打开 WorkBuddy 管理后台，填入.env中配置好的管理员密码登录。

进入「渠道接入」，选择对应 IM 平台：

• 企业微信：填入 corpid、secret，配置事件回调地址，开启 WebSocket 长连接；
• 飞书 / 钉钉：填入应用凭证，配置消息事件回调。

配置完成后，在 IM 内部就可以直接给 WorkBuddy 机器人发消息。测试指令示例：

“根据这份文档生成供应商采购合同，发起电子签，签署人为张三、法务李四，签完之后把文件存到合同归档文件夹，通知我结果。”

常见故障现象排查：

1. IM 发送消息，机器人没有回复：查看docker logs skill‑gateway --tail 100确认消息是否投递到 WorkBuddy；检查 IM 后台回调地址是否填写正确，权限是否开启。
2. WorkBuddy 提示调用契约锁接口失败：核对 accessKey、secretKey，确认契约锁企业账号已经完成实名认证、开放平台权限已经开通，测试环境与正式环境接口地址不要混用。

第四步：业务记忆与主动任务跟进配置

后台进入「业务记忆设置」：

• 开启业务实体抽取：每次完成签章任务，自动抽取合同编号、签署人、到期时间、关联项目 ID存入业务记忆库；不同用户业务数据隔离，不会混淆不同合同信息。
• 主动任务策略配置：
  • 静默时段：夜间 22:00‑08:00 不推送提醒消息；
  • 签署超时提醒：合同待签超过 24 小时自动推送 IM 提醒；签署到期前 3 天推送预警；
  • 回调触发：契约锁推送签署完成 / 驳回事件，立刻回推消息给发起任务的员工。

记忆不是存储完整大段合同文本，只存储业务关键实体，兼顾性能和隐私。

第五步：对接 Jira、腾讯文档等扩展系统

同样通过自定义 Skill 实现扩展：

1. 腾讯文档：合同签署完成，自动将签章完毕 PDF 上传至指定归档目录；自动新建周报、会议纪要文档。
2. Jira 项目管理：发起合同的时候自动创建 Jira 任务；签署完成自动更新任务状态，回填契约锁合同 ID 作为任务备注。

整体流程示例完整链路：

员工企业微信发送指令 → WorkBuddy 生成采购合同文本 → 调用契约锁 Skill 上传文件创建草稿、配置签署人发起签约 → 契约锁开始签署流程，回调事件推送 WorkBuddy； 签署完成后 WorkBuddy 接收回调 → 下载签章 PDF 上传腾讯文档归档 → 更新 Jira 项目任务状态 → 在企业微信推送通知：“【合同完成】供应商采购合同已全部签署完成，归档文档链接：xxx”。

第六步：验证整套链路

白名单内用户，向 IM 机器人发送测试指令：

“生成一份简易保密协议，发起契约锁电子签，签署人是测试 A，签完通知我。”

预期效果：机器人会分步执行，返回多条状态消息，告知草稿已创建、已经发起签署；当测试账号完成签署后，自动推送签署完成通知，附带归档文档链接。

排查命令参考：

#查看skill网关调用日志，看各个业务系统接口调用情况
docker logs skill‑gateway --tail 80

#查看契约锁回调服务日志
docker logs callback‑server --tail 80

可选：扩展其他业务系统接入

WorkBuddy Skill 机制基于标准 HTTP 接口，只要业务系统提供开放 API 就可以快速接入：

1. 泛 OA 系统：发起审批流程，读取审批状态；
2. CRM 客户系统：合同签署完成，自动回写合同编号到客户档案；
3. 网盘存储系统：业务文件统一归档备份。

接入原则：业务系统负责实际业务操作；WorkBuddy 负责理解自然语言、串联流程、记忆上下文、推送通知；大模型仅负责内容生成。

部署踩过的真实坑

1. 区分契约锁测试环境与正式环境地址：测试环境openapi.qiyuesuo.cn，正式openapi.qiyuesuo.com，混用直接接口报错，合同无法发起契约锁。
2. 服务器内存要充足：WorkBuddy 主服务、skill 网关、回调服务，加上契约锁回调解析、文档处理，建议最低 4C8G；内存不足会出现接口调用随机超时，任务中途失败。
3. 回调接口务必 HTTPS：绝大多数 SaaS 业务系统，包括契约锁、飞书、钉钉，生产环境不支持 HTTP 回调；裸 HTTP 会接收不到业务状态变更事件，就没办法实现签署完成自动通知。
4. 业务记忆数据库定期备份：所有合同 ID、任务节点存储在本地数据库，定时配置 cron 任务备份 db 文件；服务器故障会丢失业务映射关系。
5. 权限最小化原则：契约锁开放平台，不要给过高权限；WorkBuddy 设置用户白名单，防止未授权用户随意发起电子合同。
6. 契约锁签署回调网络策略：契约锁回调出口 IP 固定，服务器防火墙需要放行对应 IP 段，否则回调请求无法抵达我们的 callback‑server 服务。

合规注意事项

1. WorkBuddy 企业版部署，遵循腾讯企业版许可协议；自定义 Skill 属于企业内部自用扩展；对外提供服务需要遵守产品授权条款。
2. 契约锁开放平台 API，仅限完成企业实名认证的企业账号调用，电子签章业务必须满足电子签名法相关合规要求，不可以用于伪造签章场景；商用业务严格遵循契约锁开放平台服务协议契约锁。
3. IM 平台机器人，遵循飞书、钉钉、企业微信开发者协议，仅用于企业内部办公，禁止批量营销消息。
4. 所有业务数据传输全程加密，合同、人员信息等敏感数据，做好权限隔离，严格管控访问范围。

最后

跑通整套流程之后最大的感受：大模型生成文字早已不是瓶颈，办公自动化真正的难点，是打通 AI 和现实业务系统。

AI 可以轻松写出一份采购合同，但是真正解放人力，是让 AI 写完之后自动上传签章平台、自动分配签署人、自动跟进签署进度、签完自动归档、自动通知相关人，整个流程不需要人工复制粘贴切换多个系统。

模型负责思考，业务系统负责落地，Agent 负责串联全部流程，这才是 AI 办公数字员工真正的价值。