做致远OA实施和二开的同行，是不是常听业务这么吐槽：

"查个待办要点三四层菜单！"
 "报销单字段太多，填错一次被打回重填……"
 "流程卡在谁手里？我哪知道，自己登系统去看啊！"

系统上线了，效率却没跟上。大家还在层层嵌套的菜单和繁琐表单里打转。

最近我们在几个项目试了个新组合：致远OA + WorkBuddy（腾讯智能体工作台）。效果出乎意料——业务人员用自然语言就能驱动OA，销售、行政、财务的重复工作量直接砍掉 60%+。

今天把这套「对话式OA」的落地思路，从场景到架构到避坑，全盘分享。

01 🎯 效果演示：一句话，干完半小时的活

场景一：语音/文字发起审批

Before（传统）： 进OA → 找财务模块 → 点报销单 → 填十几个字段 → 上传发票 → 提交 → 等打回 → 改了再提交……

After（接 WorkBuddy 后）：

用户：「帮我发起一张张三的出差报销，金额3800元，附上发票」
 WorkBuddy：「✅ 已识别发票信息，校验部门预算充足。报销单（编号：BX-2026-XXXX）已生成，请确认？」
 用户：点击「确认」
 WorkBuddy：「🚀 流程已启动，当前审批节点：部门主管李四」

全程不超过 10 秒。

场景二：智能待办督办

用户：「我这周还有哪些事没办？」
 WorkBuddy：「您目前有3项待办：
 ⚠️ ① 李总的合同审批（已超时2小时）
 🔵 ② 行政采购确认
 🔵 ③ 月度考勤核对
 需要我帮您催一下李总吗？」

场景三：OCR发票秒级识票

拍照 → 发到 WorkBuddy → AI 自动识别金额、税号、开票项目 → 直接回填到 OA 报销单 → 告别手动录入。

场景四：自然语言查数据

销售：「查一下XX客户今年的所有合同和回款金额」
 WorkBuddy：（3秒后返回结构化表格，可一键导出Excel）
 HR：「研发部上季度差旅报销合计多少？」
 WorkBuddy：（直接出数，不用进OA翻报表）

这些过去都要在OA里翻菜单、导Excel，现在一句话搞定。

02 🔧 技术揭秘：二开人员关心的「怎么连」

光有场景不够。做二开的同行，肯定更关心底层实现。我们采用 「API为主，数据库兜底，老系统RPA兜底」 三层架构，确保不同版本的致远OA都能覆盖。

架构总览

第一层：致远 V8/A8+ 的 REST OpenAPI（推荐）

利用致远三方互信机制，整体流程：

Step 1: POST /seeyon/rest/token/{user}/{pwd} → 获取Token
 Step 2: POST /seeyon/rest/token/channel → 校验通道
 Step 3: 后续所有API调用携带Token（默认23分钟过期，自动刷新）

关键设计点：

• 权限隔离
  ：WorkBuddy 调用的每个接口都遵循 OA 原生权限体系。张三只看张三的单据，销售看不到薪酬数据——权限判断放在 OA 侧，WorkBuddy 不缓存明文。
• 账号拆分
  ：建两个专用 REST 子账号——
• 🔍 查询账号：只读组织模型、表单数据、流程在途状态
• ✏️ 制单账号：仅允许 createForm、startWorkflow 发起草稿，禁止删除、禁止强制跳节点
• 模块分组管理
  ：组织/表单/流程/待办/消息，五组接口独立管理，互不干扰。

第二层：数据库只读（复杂查询场景）

有些需求 API 满足不了（如「跨20张表单做部门工时汇总」），走数据库：

-- 示例：只读视图封装（DBA创建） CREATE VIEW vw_workbuddy_todo AS SELECT m.name AS 处理人, f.form_name AS 表单名,         w.node_name AS 当前节点, w.create_time AS 到达时间 FROM wf_instance w JOIN ctp_org_member m ON w.current_user = m.id JOIN form_main f ON w.form_id = f.id WHERE w.status = 'running'; 

硬性底线：

• 只读账号，严格禁止 update/delete
• 只暴露必需表/视图，不全库开放
• 配置查询限流，避免大查询压垮 OA 生产库

第三层：RPA兜底（老版本A6）

遇到没有 OpenAPI 的老系统，在专用虚拟机上固定账号登录 OA，RPA 模拟「新建表单→填字段→提交」。

安全锁死： RPA 脚本层只允许发起指定模板、只允许导出待办 Excel，禁止反审核/删单。

🔑 核心组件：自建 MCP Server

我们在中间层封装了一个 「致远OA MCP Server」（Model Context Protocol），作为 WorkBuddy 和 OA 之间的「翻译官」：

WorkBuddy（企微端）→ 致远OA MCP Server（中间翻译层）→ 致远OA（REST/DB）

好处是 解耦——以后 OA 升级或换其他 AI 助手，中间层不用大改。

03 📋 八大业务协同场景（速查表）

以下场景均已在实际项目验证，可直接当 SOP：

04 🚧 落地实践：避坑指南

坑点一：字段映射是最大暗礁

致远OA的 CAP 表单字段名往往是 field0001、field0002 这种编码，一定要做好和业务名称的映射字典。

💡 建议：建 MCP Server 时维护一份 field_code ↔ 业务名称 ↔ 数据类型 三维映射表，前端用业务名，底层用编码。

坑点二：流程回写别忘了

AI 催办了流程，用户处理完之后，最好在 OA 流程意见里自动加一行小字：

「【系统提示】WorkBuddy于2026-08-02 14:30自动催办1次」

方便审计追溯，也避免「谁催的？不知道」的扯皮。

坑点三：异常熔断必须做

连续5条建单失败 → 终止队列 → 推送IT告警
 OA服务宕机 → WorkBuddy缓存待发任务 → 恢复后自动补发
 写入失败 → 异常工单精准推业务人 → 不甩公共群

原则：宁可停下来报错，也不要脏数据进OA。

坑点四：灰度上线有顺序

第1步：行政部（7天）→ 流程独立、不碰钱、出错了影响最小
 第2步：人事部 → 请假/考勤场景验证
 第3步：财务部 → 报销/预算场景（最敏感，放后面）
 第4步：全部门启用 → OA后台保留原生审批界面兜底

05 📅 标准实施排期（3周）

⚠️ 若客户是 A6 无 REST、或主数据混乱、或走集团审批流程，周期顺延 1-2 周。

06 🔒 安全红线（OA二开铁律）

写在最后

致远OA 的强大在于其严谨的流程引擎和表单建模，WorkBuddy 的优势在于自然交互和智能感知。二者结合，不是颠覆 OA，而是给 OA 装上了一个 「智能驾驶舱」。

让复杂的流程「隐形」，让员工专注于决策本身——这才是 To B 软件进化的方向。

AI 只是入口，数据还是在 OA 里。这套方案最大的价值是：保护客户已有的 OA 投资，同时大幅提升用户体验。

最后

这套「对话式OA」我们已经在几个项目跑通了。