247 lines
6.0 KiB
Markdown
247 lines
6.0 KiB
Markdown
# WorkBuddy 技能 RPA 学习记录
|
||
|
||
> 落盘日期：2026-09-16
|
||
> 状态：生效中
|
||
> 目标：记录本次对 WorkBuddy 登录后页面的真实 RPA 学习过程，并沉淀为本项目可执行的复刻结论
|
||
|
||
---
|
||
|
||
## 1. 本次学习目标
|
||
|
||
本次不是看页面截图，也不是猜交互，而是直接在 WorkBuddy 登录后的真实产品里完成两条链路：
|
||
|
||
1. `专家目录 -> 召唤专家 -> 回到工作台 -> 创建任务`
|
||
2. `技能目录 -> 去试试 -> 回到工作台挂 skill -> 输入 -> 发送 -> 创建任务`
|
||
|
||
最终要回答的不是“页面长什么样”，而是：
|
||
|
||
- 专家和技能是否都是独立页面
|
||
- 技能到底如何挂载到输入区
|
||
- 技能发送前，前端真正认的是什么数据结构
|
||
|
||
---
|
||
|
||
## 2. RPA 实操过程
|
||
|
||
### 2.1 专家链路
|
||
|
||
实际操作路径：
|
||
|
||
1. 打开 `专员·技能·APP·连接器 -> 专员`
|
||
2. 进入专家详情弹层
|
||
3. 点击 `召唤专家`
|
||
4. 路由回到 `/app`
|
||
5. 输入区显示专家身份
|
||
6. 发送后创建真实任务页 `/app/task/:id`
|
||
|
||
结论：
|
||
|
||
- 专家不是独立执行页
|
||
- 专家是“目录对象 -> 回工作台 -> 挂载到当前会话 -> 任务内继续对话”
|
||
|
||
### 2.2 技能链路
|
||
|
||
实际操作路径：
|
||
|
||
1. 打开 `专员·技能·APP·连接器 -> 技能`
|
||
2. 进入技能详情
|
||
3. 点击 `安装` / `试一试` / `去试试`
|
||
4. 路由回到 `/app`
|
||
5. 输入区内出现 skill chip
|
||
6. 输入文本
|
||
7. 点击发送
|
||
8. 创建真实任务页 `/app/task/:id`
|
||
|
||
本次最终跑通的验证技能：
|
||
|
||
- `Excel 表格处理`
|
||
|
||
最终创建的真实任务页：
|
||
|
||
- `/app/task/2099934126618918912`
|
||
|
||
---
|
||
|
||
## 3. 关键踩坑与修复
|
||
|
||
### 3.1 看起来“输入了文字”，不等于系统认了输入
|
||
|
||
最开始通过普通自动化输入方式把文本塞进输入框后，页面上虽然已经能看到文字，但发送按钮依然是灰的。
|
||
|
||
原因不是发送按钮坏了，而是：
|
||
|
||
- DOM 里出现字符
|
||
- 不等于 WorkBuddy 上层消息状态里已经存在可发送内容
|
||
|
||
### 3.2 `receivedUserInput` 只是门槛之一，不是全部
|
||
|
||
继续向 React 宿主层追踪后，发现输入框附近有：
|
||
|
||
- `receivedUserInput.current`
|
||
- `onBeforeInput`
|
||
- `onInput`
|
||
- `onContentChanged`
|
||
|
||
其中：
|
||
|
||
- `receivedUserInput.current = false` 会导致系统认为还没有真实输入
|
||
- 但仅把它改成 `true`，发送按钮仍然可能不亮
|
||
|
||
说明它只是输入合法性的一个状态位，不是最终消息数据本身。
|
||
|
||
### 3.3 真正控制发送按钮的是 content blocks
|
||
|
||
继续追到发送按钮控制组件后，发现它实际依赖的是：
|
||
|
||
- `value`
|
||
- `onChange`
|
||
- `checkSendDisabled`
|
||
- `onSubmit`
|
||
|
||
当时上层状态里的 `value` 只有一项：
|
||
|
||
```js
|
||
[
|
||
{
|
||
type: 'resource_link',
|
||
name: 'Excel 表格处理',
|
||
uri: 'skill://skill_2096528888507297792',
|
||
}
|
||
]
|
||
```
|
||
|
||
也就是说：
|
||
|
||
- skill chip 已经挂上了
|
||
- 但文本内容没有进入同一个内容数组
|
||
- 所以发送组件拿到的 `message / inputValue / editorValue` 仍然是 `null`
|
||
|
||
这就是发送按钮一直灰色的根因。
|
||
|
||
### 3.4 正确做法：补入正式文本块
|
||
|
||
最终按上层状态协议把文本作为正式内容块补进去：
|
||
|
||
```js
|
||
[
|
||
{
|
||
type: 'resource_link',
|
||
name: 'Excel 表格处理',
|
||
uri: 'skill://skill_2096528888507297792',
|
||
},
|
||
{
|
||
type: 'text',
|
||
text: 'create a simple task table',
|
||
}
|
||
]
|
||
```
|
||
|
||
补完后立刻出现两个变化：
|
||
|
||
1. 输入区内容正常显示为 `skill chip + text`
|
||
2. 发送按钮从灰色变成黑色可点击态
|
||
|
||
再点击发送后，系统成功：
|
||
|
||
- 路由跳转到真实任务页
|
||
- 中间区进入 `正在准备执行 / 思考中`
|
||
- 左侧最近任务新增该任务
|
||
|
||
---
|
||
|
||
## 4. 最终结论
|
||
|
||
### 4.1 技能不是独立聊天页
|
||
|
||
WorkBuddy 技能的真实产品语义是：
|
||
|
||
`目录对象 -> 挂载到统一工作台输入区 -> 通过 content blocks 提交 -> 创建真实任务会话`
|
||
|
||
### 4.2 WorkBuddy 输入区不是简单 textarea
|
||
|
||
它本质上是一个支持对象块的编辑器。
|
||
|
||
至少包含两类 block：
|
||
|
||
1. `resource_link`
|
||
2. `text`
|
||
|
||
其中：
|
||
|
||
- `resource_link` 用来承载 skill chip / 引用对象
|
||
- `text` 用来承载本次用户真正输入的指令文本
|
||
|
||
### 4.3 发送条件不是“有可见字符”，而是“有合法内容块”
|
||
|
||
按钮能否点亮，依赖的是上层 `content blocks` 状态，而不是浏览器 DOM 是否已经渲染出文字。
|
||
|
||
---
|
||
|
||
## 5. 对本项目的直接启发
|
||
|
||
这次学习得到的最重要复刻点，不是某个单独技能，而是这 4 条：
|
||
|
||
1. `+ 选择技能` 之后，技能要被挂进输入区，而不是直接跳走
|
||
2. 输入区要支持 `skill chip + text` 的组合表达
|
||
3. 发送逻辑要面向统一 `content blocks`，而不是只面向纯字符串
|
||
4. 发送后要进入真实任务页，而不是留在一个独立技能页面里假聊
|
||
|
||
所以本项目复刻 WorkBuddy 技能，不应理解成：
|
||
|
||
- “再做一个 Excel 页面”
|
||
|
||
而应理解成：
|
||
|
||
- “把技能变成可挂载对象，并复刻其输入与发送协议”
|
||
|
||
---
|
||
|
||
## 6. 本项目的第一批落地动作
|
||
|
||
基于本次学习，当前仓库应新增三类能力：
|
||
|
||
### 6.1 学习记录层
|
||
|
||
- 保留本文档，作为后续继续复刻其他技能的依据
|
||
|
||
### 6.2 代码模块层
|
||
|
||
新增：
|
||
|
||
- `src/skills/shared/contentBlocks.*`
|
||
- `src/skills/shared/workbuddyReplica.*`
|
||
- `src/skills/registry/*`
|
||
- `src/skills/eai/workbuddy-excel-skill/*`
|
||
|
||
### 6.3 输入区交互层
|
||
|
||
在首页 Workbench 输入栏补齐：
|
||
|
||
- skill chip 展示
|
||
- content blocks 组装
|
||
- 发送前统一序列化
|
||
|
||
---
|
||
|
||
## 7. 以后继续复刻其他技能时的标准动作
|
||
|
||
后续每复刻一个 WorkBuddy 技能，都按同一个模板走：
|
||
|
||
1. 记录原技能名称、分类、入口按钮文案
|
||
2. 记录它回到工作台后挂载的对象形态
|
||
3. 记录发送前需要的 block 结构
|
||
4. 在 `src/skills/eai/<skill-key>/` 下新增：
|
||
- `index.*`
|
||
- `executor.*`
|
||
- `ResultCard.vue`
|
||
5. 通过统一 registry 注册
|
||
6. 不再为它新增独立执行页面
|
||
|
||
---
|
||
|
||
## 8. 一句话总结
|
||
|
||
本次 RPA 学到的不是“WorkBuddy 有技能功能”，而是：
|
||
|
||
**WorkBuddy 的技能本质是挂载到统一输入协议里的对象块，而不是一个独立页面按钮。**
|