多 Agent 协作：分工、交接、审查 几个Agent都说“完成了”，还得看它们是不是理解了同一件事。 最近我研究了架构师Carlos Kelkboom的公开访谈，觉得里面很值得学习的点是：把任务交出去的时候，之前确认好的边界和依据能不能一起同步传递过去；如果结果做偏了，有没有对应的办法及时发现、回头调整修正。 视频里拆解了他的交接与审查流程，也刚好讲到了我一直想补上的一步：让负责审查的Agent一开始就能拿到最开始确认好的要求。 放到真人的团队里看，还要让接手的人把目标和背后的理由复述回来，给质疑和学习多留一点空间。 #AI #Agent #多智能体 #我在抖音学ai #这才是ai该干的事

最近看到一位架构师分享他怎么用主 Agent 和子 Agent 的协作。有几个做法挺值得学，今天想分享给大家，自己用或者带团队都能参考。 他叫 Karlos Kalkboom，做过多人在线游戏 Copunk 的技术管理。他给主 Agent 定了条规矩，不直接改项目代码。有次他只想跟 Agent 聊聊创造力，Agent 却问要不要把这个想法做进游戏引擎。对我来说，提个想法不等于已经决定要做，聊到最后也可能觉得不值得做。他先把讨论和执行分开，让主 Agent 继续聊，确认要做再派子 Agent 的执行，免得还没想清楚项目就被改了。 我觉得有些 AI 爆款最大的作用就让大家知道，原来这事能做，项目是新的，背后的本事未必是新的。可把工作交出去以后，前面为什么这样定，后面怎么检查，仍然得有人接住。换个 Agent 光说按这个方案做新情况依赖，他还是得猜。 Karlos 在置顶评论里补充，他把项目决定和理由存进知识库。存之前先检查原因有没有说清，跟旧记录有没有重复和冲突。派任务时带上相关记录的链接，让子 Agent 他按需查。他也会先写清各部分负责什么、怎么连接，再让子 Agent 在独立的工作副本里改。目录里为这次实现写的简短说明，做完可以删，和长期保存决定理由的知识库分开。 他偏想交一个相对完整的功能，也强调少写代码，多做审查。我理解下来，得看这一轮还能不能查清他改了什么，查不过来就收小范围。做完另派A阵的审查，跑结构检查和安全测试，最后他自己复看，决定是否合金正式版本。如果中途认不出原先定的结构，他会暂停，必要时丢掉尚未合并的尝试，换干净上下文回头找。是不是结构安排有问题，或者知识库里的决定互相冲突。我看重的是出了偏差能回到前面找原因，否则再叫几个A阵他来补，也可能沿着同一个误解继续做。这是他的编程实践。 借到日常工作，假设我要做公司调研，我会先说清这轮先弄清公司披露了什么，只核对事实，没披露的营收写为支不估算。确定以后，把这个目的、研究范围和相关资料交给执行的A阵，他要分头查，就按能分别交回核对的部分。拆资料没回来，先别猜着写结论。交回来的不只是一篇报告，关键数字是哪一年的、原始出处在哪儿，哪些还没查清，也要一起回来。审查A阵也要拿到同一份目的和要求，再打开来源核对，才能指出哪一段有问题。如果把固出来的营收写成公司披露的数字，就退回去改。可如果审查A阵的觉得补个预测更有价值，那得回来跟我商量。这是在改我要做的事，不能因为两个A阵的都赞成，就替我决定。 真要改，我会更新共同纪录，写清替换哪条旧要求，让执行和审查的A阵都说。否则一个还按旧要求做，另一个已经拿新要求审，怎么改都对不上。 团队的也会这样。Karlos在采访里担心大家越来越习惯找AI聊，跟同事讨论、互相挑战的机会少了。 我觉得每个人跟自己的AI聊明白了，同事之间却未必知道彼此为什么这么想，接手时才发现理解不一样。 所以我会让接手的人用自己的话讲，讲目标哪里还不确定。出了问题，也得让团队知道这回改了哪个判断，别只把结果换掉。 模型越来越强，教他怎么操作的说明可能会过时。 但像刚才那份假设调研，为什么只核对事实、不加预测，是这项工作里刚定的事。 模型不会因为升级就知道我们商量过什么，得把这些理由交给后来接手的人和A阵。 一个A阵他就能做完，我也验得清楚，那就先用一个。真要一起干，我希望他们早点暴露分歧，别等一群A阵都说完成了，我才发现方向错了。