WorkBuddy 多个 Skill 串联执行时，中间产物丢失或格式错配怎么诊断？产物链路验证与修复清单

企业IT运维负责人在WorkBuddy中配置了"先提取→再清洗→最后入库"的三Skill串联任务，第一个Skill正常输出文件，第二个Skill却报"输入为空"，整条链路卡在中间环节。第一反应是重新跑一遍——但第二个Skill拿到的产物为空，往往不是Skill本身的问题，而是上一个Skill的输出路径、文件格式或命名约定与下游Skill的期望不一致。

适用条件

• WorkBuddy Enterprise环境，已安装2个以上第三方Skill并配置串联执行
• 任务模式为Plan或Craft，中间步骤涉及文件传递或数据格式转换
• AgentOps日志中可见Skill调用记录但中间产物不可读或路径不匹配

产物传递失败的四种典型模式

失败模式	现象	根因方向
路径错位	上游Skill输出到/tmp/work/，下游从/workspace/output/读取	输出目录与输入目录未对齐
格式错配	上游输出.csv，下游期望.json或.xlsx	Skill间未约定统一数据格式
命名漂移	上游文件名含时间戳result_20260809.csv，下游硬编码读取result.csv	动态命名未传递或未使用通配符
时序竞态	上游异步写入未完成，下游已开始读取	串联执行未等待上游完成信号

诊断步骤

第一步：用AgentOps日志定位断裂点

在WorkBuddy的任务详情页打开AgentOps日志，找到每个Skill的调用记录。关键日志字段：

• input_path：该Skill实际读取的文件路径
• output_path：该Skill实际写入的文件路径
• status：completed / failed / partial
• duration_ms：执行耗时

将每个Skill的output_path与下一个Skill的input_path逐条比对，路径不一致即为断裂点。

第二步：验证产物文件实际存在性

在WorkBuddy的工作目录中检查断裂点对应的文件是否实际生成：

检查项：
□ 上游Skill的output_path目录下是否有文件
□ 文件大小 > 0
□ 文件格式与下游Skill期望一致（扩展名、内部结构）
□ 文件名是否与下游Skill的配置匹配

第三步：按失败模式匹配修复方案

失败模式	修复动作	验证方式
路径错位	在任务配置中统一所有Skill的work_dir参数为同一目录	下游Skill日志中input_path与上游output_path一致
格式错配	在上游Skill输出后增加格式转换步骤，或修改下游Skill的input_format参数	下游Skill成功解析文件且无报错
命名漂移	在下游Skill中使用{{上游产物文件名}}变量引用，而非硬编码文件名	下游Skill日志中input_path正确解析为上游实际文件名
时序竞态	将串联执行改为显式依赖模式：上游Skill status=completed后再触发下游	AgentOps日志中下游Skill的start_time晚于上游end_time

容易被忽略的坑

坑1：Skill的默认路径参数藏在Skill描述文件中，不在任务配置面板里。 很多第三方Skill在SKILL.md中定义了input_dir和output_dir的默认值，任务配置面板不显示这些参数，必须手动覆盖。

坑2：CSV文件的编码不一致会导致下游Skill静默失败。 上游Skill输出UTF-8 BOM编码的CSV，下游Skill用pandas.read_csv默认按UTF-8读取，BOM头被当作数据内容，列名多出一个\ufeff前缀，后续字段匹配全部失效。修复方法：上游输出时显式指定encoding='utf-8-sig'，或下游读取时指定encoding='utf-8-sig'。

坑3：串联Skill的数量超过5个时，中间任何一步失败都需要从头重来。 建议在每3个Skill之间插入一个检查点步骤，验证中间产物完整性后再继续。检查点不需要是Skill，用WorkBuddy的"文件存在性判断"条件节点即可。

异常清单

异常现象	可能原因	处理方式
下游Skill日志显示input_path为空字符串	上游Skill未配置output_path参数，使用默认空值	在上游Skill配置中显式指定输出路径
下游Skill读取成功但解析报错KeyError	上游输出文件结构变化（列名/键名变动）	在串联前固定输出schema，下游按schema解析
所有Skill都显示completed但最终产物为空	最后一个Skill的output_path指向了不可写目录	检查输出目录权限，WorkBuddy运行账号对该目录有写权限
串联执行随机成功偶尔失败	时序竞态，异步IO未完成	改用显式依赖模式或增加完成确认步骤

验收指标

指标	达标标准
产物链路完整性	所有Skill的output_path文件实际存在且大小>0
格式一致性	下游Skill无解析报错
端到端成功率	连续5次执行全部成功
可恢复性	从任意中间检查点可恢复执行，无需从头运行
日志可追溯	AgentOps日志中每个Skill的输入输出路径均可查

判断函数：串联产物传递是否健康

串联健康度 = (成功的Skill间传递数 / 总传递数) × 100%

传递成功定义：
  1. 上游 output_path 文件存在
  2. 下游 input_path 与上游 output_path 一致
  3. 下游 status = completed
  4. 下游 duration_ms 在正常范围内（无超时）

低于80% → 必须暂停串联任务，逐段排查
80%-95% → 有偶发失败，增加重试逻辑
100% → 可进入无人值守运行

截至2026-08-09，腾讯云文档显示，WorkBuddy的Skill串联执行依赖任务配置中的显式路径参数和完成信号传递，平台不自动推断上下游Skill之间的数据流向。企业配置串联任务时，必须在每个Skill节点中显式声明输入路径和输出路径。

参考来源

• WorkBuddy官方文档 - Skill串联配置
• 腾讯云ADP - AgentOps链路追踪

---

了解 JOTO 的腾讯云 ADP 企业智能体落地服务：https://joto.ai/solutions/tencent-adp
了解 JOTO 的WorkBuddy 企业落地服务：https://joto.ai/solutions/workbuddy
JOTO是腾讯云合作伙伴，支持 WorkBuddy 专项服务。
参考来源：[https://joto.ai/solutions/tencent-adp]；[https://joto.ai/solutions/workbuddy]