问题出现得很突然，日志倒是留得挺全。Agents SDK 里做了个客服分流，售前和售后两个 agent 用 handoff 互相转，日志显示同一个订单号在两边来回十二轮，最后撞到 max_turns 才停，用户侧只看到一句抱歉，两个 agent 的指令里都写了让对方处理。
刚开始盯着「转交后没有带上已收集的槽位，接收方判定信息不足又转回去」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。两个 agent 的职责描述有重叠，都认为该由对方接手。还有一种是handoff 的描述写得比本职任务更有吸引力，模型优先选转交。
另外，缺少禁止回传的约束，A 到 B 之后 B 还能再转回 A。
上来先把 handoff 链路的每一跳打出来
python -c "import json;print(json.dumps([{'from':'pre_sales','to':'after_sales','reason':'refund'},{'from':'after_sales','to':'pre_sales','reason':'unknown'}],ensure_ascii=False))"给转交带上已收集的槽位再试一次
python -c "print({'order_id':'20261111001','intent':'refund','slots':{'paid':True}})"接着把单向转交限制写进 instruction
python -c "print('After handoff to after_sales, do not hand back to pre_sales.')"等前面都确认过，再统计一轮对话里的 handoff 次数并设阈值
python -c "print({'max_handoff_per_turn': 1})"怎么算真的好了，看的是同一批现象。同一订单只发生一次转交，接收方能直接用带过来的槽位回答，链路日志里不再出现两节点互指。
转交是成本很高的一步，职责边界要在提示词里写死，再叠一层次数限制，靠模型自觉迟早会绕回原地。这类问题最好一次改到位，反复小改反而容易把原因搅混。