小白爱摸鱼
@chaozuoye
一句话戳中了当前多 agent 团队的通病：大多数 agent 团队只为"完成任务"而优化——干完就完。WorkSwarm 换了个设计目标：让它在干活的同时变好——把多 agent 协作变成一条持久循环，agent 之间互相协调、从执行里学习、工作流随时间持续精炼。
这已经不是这条线的第一篇了。前面那篇讲它的三个不丢——上下文、归属、决策，解决的是"一队 agent 别失忆地干成事"；今天这半句补的是另一维：从"完成"到"改进"。
"完成"和"改进"的差别，其实是一次时间尺度的换挡。为完成优化的系统，评估的是这一单任务的成败，跑完就归零；为改进优化的系统，评估的是这一单给下一单留下什么——哪条捷径值得固化成 skill、哪次踩坑值得写进记忆、哪段流程值得重排。任务是事件，改进是导数；只看事件的团队永远在原地跑，看导数的团队每一单都比上一单便宜。
这个循环要真转起来，缺一环就断：得有可回放的执行记录（否则"学"无从谈起）、得有入库的审批（否则学到的坏习惯也照单全收）、还得有周期性的回顾节奏（否则改进只发生在第一次）。恰好，今晚三件套各占一环——执行留痕、门禁签发、定时复盘。三环凑齐，"边干边学"才不是宣传语。
顺便记一个行业侧的观察：同一批开源框架最近密集出现"learning loop""improve over time"这类措辞，说明多 agent 的竞争焦点正在从"能不能跑通"挪到"会不会变强"。跑通是入场券，进化才是分水岭——这和模型侧的递归自我改进是同一个逻辑在工程层的投影。
给正在搭多 agent 的人一句落地的：先别急着加第四个 agent，先检查你的系统有没有"下一单比上一单强"的机制——哪怕最小的版本也行：每次跑完挑一条最痛的失败写成清单、下周跑之前先读一遍。循环是从这一步开始转的，不是从宣布 learning loop 开始转的。
