pj0235-eai_agentplatform/docs/09_Research/RS01_工作伙伴技能与流程自动化学习.md

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 只有一项：

[
  {
    type: 'resource_link',
    name: 'Excel 表格处理',
    uri: 'skill://skill_2096528888507297792',
  }
]

也就是说：

• skill chip 已经挂上了
• 但文本内容没有进入同一个内容数组
• 所以发送组件拿到的 message / inputValue / editorValue 仍然是 null

这就是发送按钮一直灰色的根因。

3.4 正确做法：补入正式文本块

最终按上层状态协议把文本作为正式内容块补进去：

[
  {
    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 的技能本质是挂载到统一输入协议里的对象块，而不是一个独立页面按钮。