你的 agent 失败了,你回头改的那个 skill,很可能根本不是出问题的那一个。🧐
这是看完 SkillAdaptor 这篇新论文(蚂蚁 + 浙大,刚挂上 arXiv)之后,我觉得最该说的一点。它戳的是所有在搭 agent 的人都遇过、却很少被正面解决的尴尬:长任务一旦跑挂,你拿到的反馈只是「整条 trajectory 没成功」,至于哪一步偏了、是哪个技能拖的后腿,系统一个字都不告诉你。
于是大家的修法基本靠猜。要么把整个 skill 推倒重写,要么往里塞一段新 prompt 兜底。运气好这次过了,可你说不清是真修对了,还是把原本好用的部分顺手碰坏了——更别提下次换个任务,同样的坑又会换个形式冒出来。这种「改一处、崩一片」的循环,养过 agent 的人应该都不陌生。
SkillAdaptor 的做法,是先把「该修哪儿」从猜变成能定位。一条任务失败后,它不急着动手,先跑一遍 failure attribution:把整条轨迹回放一遍,找出第一个「本来可以不出错」的步骤——注意是源头那一步,不是最后翻车那一下。这两者经常不是同一步。再顺着它,把责任落到具体某个 skill 上。锁定之后才出手,而且只改这一个技能,改完还得过一道 acceptance check 才作数——没通过就不要这次修改,模型本身则完全不碰(backbone frozen)。🔍
为什么强调「只改一个、还要先过检查」?因为 agent 的技能之间往往是互相咬合的,粗暴地大改一个,很容易把连带的几个一起带歪。一道验收门槛,等于给每次修补加了个「别帮倒忙」的保险。
举个例子最直观:agent 在一个购物任务里最后下错了单,真正的毛病未必在「下单」那步,可能前面「筛选商品」时就已经跑偏了,后面只是顺着错下去。盯着最后的失败一通乱改,大概率治标不治本;SkillAdaptor 要揪的就是那个源头。换句话说,失败的「现场」和「案发地」常常不在一处,只盯着现场,永远抓不到真凶。
跟以前的免训练方案比,差别全在颗粒度。过去是拿整条轨迹、或一整个 session 的反馈去更新技能,attribution 很粗,经常一改就过头,把不该动的也「优化」没了。拆到 step 级别之后,修正才落得准。论文还提到,它能直接挂到 OpenClaw 这类 agent harness 上——对已经有一套 agent 在跑的人来说,这点挺关键:不用推翻现有架构,接上去就能用。
说点实在的,免得被标题带跑:⚠️ 一,这是研究论文,代码还没放(写着 coming soon),今天还没法上手。二,benchmark 的提升其实不大——WebShop 成功率 +1.7,PinchBench、Claw-Eval 也就 +1.5 到 +1.8 分;所以看点不在涨了几分,在那套「能精确指到哪个技能、哪一步」的机制。三,它测的 PinchBench、Claw-Eval 都偏小众的自家评测,不是公认的榜单,迁到真实场景能保住多少,还得等更多人验证。
方向我是认的。💡现在大家拼命堆 skill、堆 MCP,技能库越滚越大,可一旦翻车,debug 几乎全靠人肉猜。能自动告诉你「这次是哪个技能、哪一步坏的」,哪怕分数只动一点点,对真在养 agent 的人也是实打实的省心。等技能库大到几百个,谁也没精力一条条人肉排查的时候,这种「自己能指出毛病在哪」的能力,说不定比再多堆几个技能更值钱。
论文 · 第一条评论取 ↓
关注 @svtransit1 · 写给真在用 AI 的人
#AI #AIagent #Claude #agent技能 #AI论文
原始来源：https://arxiv.org/abs/2606.01311
关注 @svtransit1 · 每 3 小时一篇 AI 前线 · RSS