ClawTeams 这类多 Agent 编排真正卡人的不是能力，而是先接哪条线。商品上架、客服问答、投放复盘这三条线，输入数据的可得性、产出物的形态、出错后的可见后果都不一样，接入顺序建议反过来按出错代价排，而不是按业务价值排。先做只读、内部消费、可回退的那条，把改价、发布、对外回复这类不可逆动作全部挡在人工确认之后，再用一周的产出与人工版本差异决定要不要放量。每条线的字段和阈值都要结合自己的平台接口能力确认，没有统一答案。

判断方向：先接投放复盘，再接客服问答草稿，最后接商品上架。投放复盘只读、产物内部消费，出错的可见后果最低；客服草稿对外但对单次会话，可撤回可纠正；上架涉及改价与发布，对外可见且难逆。三条线各写一份输入清单和产出物契约，改动价、改发布状态、发对外回复三处必须由人工点确认。放量与否不看感觉，看一周内 Agent 产出与人工终稿的差异条目数和差异类型。

给三条业务线各写一份输入清单

输入清单的作用是先回答“这份数据从哪来、多久更新一次、拿不到时怎么办”，而不是先把 Agent 提示词写好。商品线要的是商品资料与类目属性：商品资料通常从 PIM/ERP 或商家后台导出，按上架批次刷新；类目属性来自平台类目接口或类目模板文件，平台调整类目时会变，建议每次发布前重新拉一次。客服线要的是历史问答记录，来源是工单系统导出或客服渠道的会话日志，一般按天增量，入库前先做去重、剔除测试会话、脱敏手机号和订单号。投放线要的是报表与消耗数据，来源是广告后台导出，粒度到计划或素材，注意当天数据通常不完整，建议用 T+1 口径并和账户总消耗对一次账。

# line_input.yaml —— 三条线各一段，来源和刷新频率必须写死
product_line:
  source: pim_export            # PIM/ERP 或商家后台导出
  fields: [sku, title, brand, spec, price, stock, image_url]
  refresh: per_publish_batch    # 每次上架批次重新导出
  verify: 抽查必填字段空值，核对行数与导出记录一致

category_attrs:
  source: category_template    # 平台类目模板或类目接口
  refresh: before_each_publish
  verify: 属性名与当前类目模板逐项比对，缺项直接阻断

cs_history:
  source: ticket_export
  window: last_90d
  refresh: daily
  preprocess: [dedup, drop_test_sessions, mask_phone_and_order_id]
  verify: 抽若干条人工核对字段是否错列

ads_report:
  source: ads_console_export
  granularity: campaign/adgroup/creative
  refresh: t_plus_1            # 当天数据不完整，需结合后台口径确认
  verify: 分项消耗合计与账户口径对账

替换项就是 source 和 refresh 两行，接自己的数据源时改这两处即可；跑完校验先看 verify 那一步能不能过，过不了不要让下游 Agent 启动。

定义每条线的产出物形态

产出物形态不定义清楚，人工复核就变成“通读全文找问题”，成本会反噬收益。上架线应该交回结构化字段表，每个字段带来源和状态标记；客服线交回话术草稿加一份待确认项清单；投放线交回复盘要点加异常标注。三者的共同点是：机器产出负责“拟”，人负责“批”，所以产出物里必须留出标记位，而不是一段干净漂亮的成品文本。

// 上架线：结构化字段表，draft 状态，缺项进 blocked_by
{
  sku: 'A-001',
  title: {value: '...', source: 'pim', confidence: 'high'},
  price: {value: 0, source: 'pim', changed: true},
  attrs: {color: '...', size: '...'},
  status: 'draft',
  blocked_by: ['missing_category_attr']
}

// 客服线：话术草稿 + 待确认项
{
  cluster: '运费与时效',
  draft: '...',
  evidence: ['ticket_1024', 'faq_07'],
  needs_confirm: true,
  confirm_reason: '涉及时效承诺'
}

// 投放线：复盘要点 + 异常标注
{
  period: '...',
  highlights: ['某计划消耗上升但转化走低'],
  anomalies: [
    {type: 'conversion_zero', scope: 'adgroup-3', note: '核对埋点或落地页'}
  ],
  actions: []
}

投放复盘里的 actions 建议留空，由人填，避免 Agent 直接给出预算调整建议被误当成执行指令。

按出错代价排上线顺序

比较标准只有两条：出错的可见范围，和出错后能不能回退。投放复盘产物只在内部看，写错一条结论最多是当天复盘跑偏，改一版就行，可逆性最好。客服问答的草稿要对外发出，出错会被单个用户看到，但可以在后续会话里纠正，影响面通常限于当次沟通。商品上架里的改价和发布对外可见，直接涉及交易和资金，撤销往往需要下架重发，甚至产生价差，属于难逆动作。因此建议顺序是：投放复盘 → 客服问答草稿 → 商品上架。如果你的客服渠道是公开评论或直播公屏，回复的可见范围会显著放大，那就把客服线往后放，先跑一段时间只生成草稿不发送。

给每条线设定人工复核点

复核点要卡在“写入之前”，而不是出错之后。改价动作的确认位置放在 Agent 生成价格与回写接口之间，确认人建议是店铺运营负责人或定价岗；上架发布动作确认位放在 draft 转 published 的那一次点击，确认人是商品运营；对外回复的确认位放在消息发送前，确认人是客服组长，涉及价格、政策、承诺类内容强制人工，不允许自动发送。实现上不需要复杂机制，在工具调用前插一道审批，把待确认项落到一张表里即可。

# 审批位伪代码，插在写操作之前
before_write(action):
  if action.type in ['price_update', 'publish', 'send_reply']:
    create_ticket(action, required_role=ROLE[action.type])
    return PENDING          # 不落库、不发布、不发送
  return ALLOW

ROLE = {
  'price_update': 'pricing_owner',
  'publish': 'listing_operator',
  'send_reply': 'cs_lead'
}

验证方式很直接：触发一次改价，确认记录停在 PENDING 且后台价格未变；再人工批准，确认价格写入成功、日志里有审批人。

一周后比对产出与人工版本差异

放量与否不要靠主观感受。跑满一周后，把 Agent 产出和人工终稿逐条对，至少记三类信息：差异条目、差异类型、人工修改次数。差异类型建议分成事实错误、格式不符、遗漏字段、语气不当、越权承诺五类。事实错误和越权承诺出现频率高的线必须收紧，先缩小适用范围；格式和语气的差异占多数，说明提示词和输出契约还能再调，不必急着回退。一周样本量通常偏小，判断只作为方向，不要当成定论。

# diff_records.csv 逐条记录，便于按类型汇总
week,line,item_id,diff_type,human_edits,action
1,ads,plan_A,missing_field,1,keep
1,cs,ticket_1024,tone,2,keep
1,listing,sku_A001,factual,3,narrow_scope

# 对结构化产出做差异比对（先统一键序再比）
diff <(jq -S . agent_out.json) <(jq -S . human_final.json)

据此决定扩大或收紧：某条线连续记录里只有格式类差异、人工基本只改措辞，可以先放开内部试用范围；一旦出现事实错误或越权承诺，就把该条线退回草稿模式，等输入清单里的校验步骤补上再放。三条线的输入稳定性会随平台接口和业务节奏变化，建议每月重跑一次输入清单核对，别把一周的结论长期沿用。