以前，真人团队不好带，很容易领导变保姆；现在 Agent 团队带起来也不是那么轻松，人再一次成为“赛博保姆”。
平凯 Loop 推出的工作流，把繁琐的协调环节自动化，把经验和规范直接沉淀为工作流，真正释放精力。
程序员小明的“古法 vibe coding”日子，是从用 Codex 开始的。来个需求，切到 terminal 丢给 Codex，然后就可以喝杯茶等结果了。
后面有一天，他有了免费用的 GLM。本着物尽其用的心态，他琢磨着把两个模型凑一桌：Codex 负责写代码，Claude Code 加上 GLM 负责做 Code Review。
流程其实挺顺畅：需求发给 Codex，它提了 PR，再扔给 Claude Code 挑刺。有意见就打回去让 Codex 改，改完再验。一个闷头写，一个戴着眼镜查，小明就在中间当个无情的“消息转发器”，事情倒也能往前走。
但随着并行推进的需求越来越多，小明的电脑上同时开着 8 个 terminal。这个在敲代码，那个在 review，还有一个刚改完等着二审。他每天切来切去，得先看清当前窗口是谁、在干嘛，再把上一轮的意见精准投喂给对的人。
代码确实不用自己写了，但切窗口切得人眼晕。
终于，他发现了 Loop
配好环境、模型后，小明在 Loop 里建了一堆 Agent，全拉进同一个「频道」。
这下舒服了。需求往群里一丢，直接 @Codex 去干活，写完 @Claude 去看。修改意见也直接丢在频道里，小明顺手再 @Codex 接着改。不用再跨软件搬运聊天记录，也不用在满屏的面板里找迷失的窗口。
小明用着挺爽，顺手又多开了几个 feature。
结果渐渐地，群聊记录开始爆炸。某个功能的修改意见早就被顶上去了，下面全在聊别的。等小明想再跟进一下进度，得像翻垃圾堆一样往上爬楼，找回上次到底聊到了哪儿。他有点看不过来了。
一件事，一条话题
为了理清上下文，小明开始用「话题」隔离任务。每个 feature 或 bug fix 都单开一个话题，在里面 @Agent 讨论。有上下文依赖的几轮长线工作就扔进专属「任务」，代码改动和检查结果全沉淀在里面，主频道只留干净的阶段总结。
终于清爽了。想看哪个功能的进度，点进对应话题就行，开发、review、返工一目了然，都能顺着往下接。
但有个新问题：小明还得像个保安一样，天天盯着仓库看 CI 有没有报错、PR 有没有新评论。一旦有动静，就得手动复制链接扔进话题让 Agent 去处理。Loop 里的事理顺了，仓库里的消息还是得靠人力搬。
接入 Extension
为了干掉无聊的 Ctrl+C 和 Ctrl+V，小明把 Gitea App 接进了 Loop，配好了仓库和权限。
这回，每次 Agent 提完 PR 就会自己授权订阅消息，顺便领走一条嘱咐：CI 失败就去查，有 review 意见就去修，改完自己再推进。之后，CI 挂了或者同事留了评论，webhook 就会把消息自动推回 Loop。Agent 收到动静直接开干，不用再等小明复制过来补一句“你瞅瞅这个”。
小明觉得自己升华了，从代码工程师变成了“功能许愿池”。每天许个愿，剩下的就交给 Agent。他又愉快地许了几个愿。
AI 越来越强，怎么我还是那么忙
愿望许多了，小明发现自己还是很忙。
Agent 总是挂，上游总是断
明明交代了“继续 review”，半天没动静。跑去一看，这哥们儿已经挂机了，只好再敲一句“继续”。有时候上下文断了，还得把之前的材料扒出来重新喂一遍，免得它又从头开始看。
催一鞭子，它干一点。小明要是去忙别的没来得及催，这个 feature 就得原地卡死。结果就是，他养成了个强迫症习惯：隔三差五去巡视一圈，看看谁还在干活，谁已经悄悄停了。许愿一时爽，还愿全靠盯。
想派个活，还得等它忙完
有时候 Agent 没挂，只是单线程卡住了。刚搞完一份改动，想找最懂这段代码的那个 Agent 来看，结果人家还在忙上一个活儿。小明只能默默把这事记下来，过一会儿再来看它闲了没。等着送审的多了，还得在脑子里排个序，生怕把新活儿一股脑塞过去打断了旧活儿。有时不小心派了两活，它还容易串台。哪个在做、哪个在等、下一个轮到谁，全靠人脑调度。
Agent 多了，每次找谁又得挑
为了解决并发，小明又拉了几个 Agent，干活的、查代码的都有。能同时跑的任务确实多了，但每次来活，他都得对着名单“翻牌子”。虽说好几个都能干，但这个“随便挑一个”的动作，还是得他来点。以前管 8 个 terminal，现在管一群赛博打工人，名字还是得来回选。
活都干完了，还在跟着收消息
为了信息同步，小明让开发、Reviewer、修代码的 Agent 都关注了同一个「任务」。结果每次在流程里补一条要求，所有人都被炸出来了。已经做完自己那轮的也会跑回来重新读一遍，小明还得赶紧补一句：这次让现在改代码的那个处理就行。要么挨个调整关注名单，要么大家一起忍受消息轰炸，最后受累的都是小明。
他想了想，自己每天反复干的活其实毫无技术含量：停了就催，忙着就等，来活就挑个人，交接完再清个场。
偶尔还得做做赛博保洁：Agent 写的废话测试太多，得让它删；页面太丑，得让它改；文案“AI 味”太冲，得让它说人话。
发现 bug 找研发，写完找测试，测完找发布。谁做完了该喊谁，这套流程他熟得不能再熟。可既然开发都能交给 AI，这几件破事为什么还得天天自己来？
Loop 工作流，帮你带好 Agent 团队
后来，小明发现 Loop 上线了「工作流」。
他直接找一个 Agent，像倒苦水一样把自己每天的工作安排一口气告诉它：
“帮我设计一个工作流。以后每个需求建一个任务跑这个工作流。 先让一个 Agent 出方案，另一个 Agent review。没过就继续重写，通过了再弹给我审批。我不通过，就带着意见回去重新走设计和 review。 我批准之后，一个 Agent 写代码，另一个做 review。没通过继续改，通过了丢给 Agent 做端到端验收。验收没过打回去开发，改完重新走检查、review、验收。 前端页面有改动的话，截图发我。我看完批准了，再让 Agent 提 PR。PR 合并之后，安排个 Agent 把这趟活儿留下的临时资源全清理掉。”
终于，Agent 帮他生成了这套工作流。
现在，小明只要扔出需求，顺手 @agent 跑这套工作流就行。
Agent 挂了？工作流会自动尝试拉起，断点续传。
Agent 在忙？工作流会看着排班表自动派活，同一个任务按顺序乖乖排队，一次只派一个。
状态交接时，任务关注人也会跟着当前处理者自动流转。小明随时插嘴补要求，接手的 Agent 自动跟进。
再也不用挨个 @，返工也不用重新同步上下文。小明去忙别的，常规步骤自己全自动往下滚，只有到了需要拍板的关键节点，才会把材料端到小明面前。
想看进度，瞅一眼运行记录就知道卡在哪一步，不用再去聊天记录里拼凑线索。
换个新需求，直接套用同一套模板，不用把分工规矩重念一遍。
更妙的是，他开始往工作流里塞各种针对性插件：
- 想让几个 Agent 一起 review，就用 Fork-Join：各看各的，同时开工，等大家交齐结果再汇合，不用小明一份份转。
- 有个大 Goal，就让 Plan 找差距、Dev 做一批、Review 看一批，再回 Plan 继续找剩下的活。单轮过了不算完，围着同一个目标一轮轮推进。
- 需求每次都不一样，就用 Dynamic Workflow：先拆出这次的子任务，能并行的先开工；有依赖的等前置任务做完再接着干，最后汇总。比如接口和界面并行，联调等前两项都完成才开始。
- 发现 Agent 加了太多废话测试，就往流程里塞一个“测试 Reviewer”，专门删重复用例，只留核心回归测试。
- 发现 Agent 喜欢过度设计，就加个“防止过度设计 Agent”，把华而不实的预留抽象全砍掉。
- 发现 Agent Review 代码喜欢鸡蛋里挑骨头，就加个“反过度 Review Agent”，把“必须改的硬伤”和“个人代码洁癖”严格分开，不为了一句“我觉得”来回折腾。
终于，不用当“赛博保姆”
把你的监工套路提炼成工作流，恭喜你，你成功把最后一个繁琐的协调环节给“自动化”了。
与其每天当智能体的“赛博保姆”，不如把经验和规范直接沉淀为工作流，真正实现精力解放，把时间留给更有价值的创造。
Q&A
为啥不用 Skill？
当然可以用。
Skill 里的指示会作为 Prompt 塞进 Agent 的上下文。当一句话就能让 Agent 把事干完时，直接用 Skill 没毛病。但 Agent 的脑容量是有限的，当 Skill 里的规则多如牛毛时，它不一定能全盘记住并照做。
与其给它一本厚厚的员工手册，不如把复杂的规则拆成工作流里的几个具体步骤。每一步只让 Agent 专注眼前的规矩，按部就班往下走。工作流靠的是流水线一样的确定性编排，规范流程并自动尝试恢复异常；而 Skill 靠的是 Agent 自身的聪明才智。两者搭配，并不冲突。
为啥有 Leader 还需要工作流？
在平凯 Loop 的智能体团队中，Leader Agent 确实能像工头一样调度其他 Agent，但这完全依赖于 Leader 自身的智力水平。如果全靠 Leader 去死盯进度、反复检查、把自己唤醒去催活儿，系统迟早会累垮。
工作流提供的是一种物理层面的确定性流转，基于状态改变来触发通知和下一步。它就是一条全自动的履带，不需要派一个 Leader Agent 站在旁边死死盯着它转。