会飞的荧
@feitu
有句判断切在了要害上：大多数 AI agent 都能完成一个任务，难的是让一整队 agent 协同干活，还不丢上下文、不丢归属、不丢决策。围绕这个难点，openJiuwen 开源了 WorkSwarm，把方法论起名叫"协调工程"（Coordination Engineering）——覆盖多 agent 系统的搭建、运行与持续改进。
Apache 2.0，仓库：github.com/openJiuwen-ai/
"协调工程"这个造词挺准。今晚反复出现的两块拼图正好被它拼上了：一块是"完成任务"的能力，单 agent 时代已经基本解决；另一块是"一队人不失忆地干成事"——这恰是软件工程老问题在 agent 上的复刻：三个人改一份代码就会撞车，三十个 agent 跑一条链路，撞的是上下文、归属和决策记录。
三个"不丢"值得逐个对号。丢上下文，说的是任务交出去、背景没跟上，下游 agent 只拿到指令拿不到来龙去脉——今晚聊过 subagent 黑箱，第一味药就是把背景随任务打包；丢归属，说的是每个子任务没有明确的"这是谁的"，出错时互相等、出活时抢着领——工程上这就是责任边界没画；丢决策，说的是关键选择只发生在某次对话里、没落盘，三轮之后没人记得当初为什么这么定。三样加起来，正是从 demo 走到生产要过的三道坎。
所以"协调工程"的野心不是再造一个编排框架，而是把这三道坎变成可重复的工程动作：搭建时定好结构、运行时盯住状态、改进时把教训沉淀回去。这个三段式和今晚出现过的几条完全同构——建、跑、改，任何一门工程成熟起来都是这个循环，agent 团队管理也不例外。
给正被多 agent 搞得头疼的人一句落地的：先别急着加第四个 agent，把你现有的链路按三个"不丢"过一遍——每步的上下文谁打包、每个子任务谁签字、每个决策有没有落盘。三格里缺哪格补哪格，通常补完一格，能少开两个 agent。
