夜雨聆风凌晨三点，没人加班，活却干完了
凌晨三点。
办公室没人；电脑暗着；群里安静得像没人存在。
但你早上打开系统，会发现活儿已经往前走了一大截：一条需求走完了评审和分发，进到实现和验收入口；一个测试提的 Bug 被接手修完，回到测试侧等验收；连平台自己积压的能力改进项，也跑完了分析、修改和验证，等人确认；历史问题池里那些过去永远排不上期的小毛病，开始被定期捞出来处理。
干这些的不是人，是 Agent。
但真正吓人的，不是"某个 Agent 半夜多跑了一次"。
是这件事一旦进系统，就不再需要人一步步叫醒下一个角色。系统自己找下一步、自己找合适的 Agent、带着上下文往下推，一直推到通知、验收、返工的位置才停。
绝大多数团队搞错了方向。
过去这一年，我们其实攒了不少 Agent：会评审需求的、会分发任务的、会改配置的、会修 Bug 的、会写代码的。单点能力都不弱——像一群刚入职的尖子实习生：让他干手上的活，干得漂亮；但你不能指望他知道自己什么时候该开工、干完该交给谁、卡住了该找谁兜底。
更糟的是，这些"实习生"分散在不同人手里。产品用自己的 AI，研发用自己的 AI，测试用自己的 AI，运营用自己的 AI。每个角色都变强了，可一件完整的事，依然要靠人一步步看、一步步转、一步步推。
所以瓶颈从来不是"你会不会用 AI"。
是"你有没有为 AI 的模式，重新设计一套工作方式"。
超级个体的幻觉：节点提效 ≠ 链路提效
每个角色都配上 AI 之后，组织效率为什么没发生质变？
回到那条最常见的工作流：产品理解需求 → 评审判断合理性 → 负责人分发 → 研发实现 → 测试验证 → 负责人验收 → 发布或关闭。
AI 出现后，最自然的做法是给链路上的每个节点都配 AI。这当然有效。但改变的只是每个节点的效率，没改变整条链路的协作方式。工作仍然要等人看到、等人判断、等人分发、等人转述、等人验收。很多时候真正消耗时间的，不是某一步执行本身，而是中间的等待、交接、确认、返工。
旧模式有三处典型卡点。
第一，工作推进依赖人的在线状态。 Agent 会干活，但要等人叫它。需求来了要有人看到，评审完要有人转述，该谁执行要有人分发，做完还要有人通知负责人验收。只要人不在，链路就停。这也是"人下班，Agent 也下班"的本质——不是 Agent 没能力，是旧模式里它的启动、衔接、推进、验收全拴在人身上。
第二，旧角色边界把 AI 的能力重新压回格子里。 AI 已经放大了每个人能做的事：研发更快理解需求，测试更快定位问题，运营更快分析规则。可如果协作仍按老角色边界走，放大的能力又被旧流程压回原格。AI 扩大了个体，旧流程却要求每个人只接自己那一段。
第三，关键上下文丢在角色交接里。 评审时真正担心的风险、分发时为什么判给这个模块、执行时发现的边界条件、Agent 输出里哪些可信、验收不通过的真实原因——这些信息在一次次转述中流失。而 Agent 要连续干完一件事，最缺的恰恰是这些上下文。如果上下文还靠人读、人解释、人转述，Agent 就很难真正接力，它们只是各自完成一小段，链路仍靠人粘起来。
一句话：AI 提效了节点，没提效整条协作链路。
三条路，腾讯选了最务实的那条
要让一组 Agent 协作，路不止一条。动手前，腾讯在三个方向权衡过：
路径 A：造一个更强的"超级 Agent"。 让一个端到端 Agent 自己看懂需求、拆解、执行、验收。最酷，但问题最直接——单一 Agent 的可控性、可观测性、责任边界都不好处理，中间错了几乎没有干预点。对一件涉及多角色、多外部系统的真实工作，这一步迈得太大。
路径 B：直接设计 AI 原生的协作流程。 不参考人类现有流程，从 AI 协作特性出发重组"目标→计划→执行→验证→验收"。最有想象力，但有个现实问题：没人能拍脑袋设计出最优 AI 原生流程。没真实运行数据，"AI 原生"容易变成另一种凭直觉的设计。
路径 C：先把人类验证过的流程 Agent 化。 选一类边界清晰、已被人类跑通的工作，把每个角色背后的执行者换成 Agent，让工作流组织它们接力。
腾讯选了 C。不是因为它最理想，是因为它最务实：足够接近原流程、易落地、责任边界清晰、业务好验收；同时它真把多个 Agent 串了起来，逼出协作系统该有的所有边界问题。
第一阶段要回答的真问题就一个：一条原本需要多人接力的链路，能不能被一组 Agent 接起来跑？
指挥中枢的三根骨架
底座没从零搭，而是选了开源项目 Multica 作为起点，把它从一个偏"Agent 任务管理"的系统，扩展成支撑"多 Agent 协作工作流"的指挥中枢。核心补三根骨架：
骨架一：把分散 Agent 变成平台可调度的能力池。 之前 Agent 散在个人电脑、云主机、外部平台、各业务专项里。平台不知道有哪些、能干什么、现在能不能用、该怎么调、这一步该派谁。第一步不是画工作流，是让 Agent 进平台视野。调度策略覆盖"指定 Agent / 上一步指定 / 能力匹配 / 兜底解析"四种，从静态到动态都能落。这一步把散点能力变成平台可调度的执行能力。
骨架二：把人的流程经验变成可运行工作流。 光有 Agent 不够。如果还靠人决定什么时候评审、评审完找谁、分发完谁执行、执行完谁验收、失败回哪里，模式没变。于是补出工作流运行时：Workflow Template、Node、Edge、Step Instance、节点状态流转、End Node、Acceptance。它们把过去人脑里的流程经验，变成系统能运行、追踪、恢复的流程结构。这一步让"人知道下一步怎么走"，变成"系统知道下一步怎么走"。
骨架三：让真实工作进来，状态能出去。 平台不替代外部系统。需求、缺陷、验收、发布系统已经存在。要做的不是把所有工作搬进新平台，而是让外部系统在合适状态把工作交给平台，平台组织 Agent 执行，完成后把结果或状态交回去。以需求系统为例：需求进入可执行状态后，外部系统触发 Hook，把标题、描述、负责人、来源链接和 template_key 推给平台；平台建工作对象启流程；走完通知负责人验收；通过则关闭，驳回则回指定节点返工。
走到这，Multica 不再是分发任务的看板，而是一支 AI 军团可以排兵、接力、验收、返工的指挥中枢。
光有骨架还不够。真实场景很快暴露：Agent 输出不稳定、复杂工作不线性、Agent 完成 ≠ 业务完成、流程会静默卡死、验收不通过不能靠人重解释、跑完一批还得知道哪里该优化。于是又补了六类能力：准出字段与 Verdict（下游只消费结构化裁定）、Fan-out 并行与收敛、通知/验收/返工闭环、自愈与显式阻塞（Sweeper）、错误诊断、指标看板。
正向链路跑通只证明"能跑"，失败路径能处理才证明"可用"。
一个 Bug 的真实闭环：测试侧自己跑完
说"闭环"太虚，看一个具体场景。
过去：测试发现 Bug → 提交给研发 → 等研发看到、理解、修复 → 再回测试侧验收。问题本身可能不复杂，但中间全是等待、转述、排期。
现在：测试提交 Bug → 触发 Agent 修复（S1 调起合适的修复 Agent，S2 按模板跑"定位→改码→自测"子流程，S5 并行拉起单测和集成验证）→ 状态回写 → 测试验收。研发从大量逐单处理里释放出来，只留在复杂问题、代码边界和兜底判断上。
这不是让某个 Agent 做了一个单点任务，是让一组 Agent 围绕同一个 Bug 接力。它解决的不是"某一步更快"，而是原来要跨两个角色流转的过程，开始在测试侧形成闭环。
更有意思的是，平台开始"给自己干活"：它自己的能力缺口、待办、历史问题，也进同一套机制。Agent 分析、改、验证，最后交人确认。一套协作系统如果只能处理外部任务，它只是执行工具；如果它自己的建设也能进环路，它才开始具备持续进化的可能。
浚枢的对应物：我们已经把它做成了 Skill
看到这，浚枢的人应该会心一笑。
腾讯用一篇文章讲清了指挥中枢该长什么样。而我们，已经把这套方法论沉淀成了一个可复用、可迁移的技能包——浚枢-协同循环操作指挥（LoopOrchestrator），里面是 S1~S9 九个协作技能的合集。这个 Skill 本身就是用 WorkBuddy 的 SkillManage 工作流创作出来的：先有方法论，再抽成可一键安装的技能，谁装谁就能拥有自己的指挥体。它不绑定任何具体平台，Multica 也好、你自研的也罢，S1~S9 这套控制循环都能直接套上去。
它解决什么
把「人下班 Agent 也下班、节点提效但链路不提效、上下文在交接中丢失、流程静默卡死、优化靠感觉」升级为：一段边界清楚、可验收的工作进入系统后，由 Agent 持续接力推进至验收/返工，人只定目标、守边界、做最终验收。
目录结构
浚枢-协同循环操作指挥/├── SKILL.md # 入口：精简系统提示词 + Skill Registry + 原则├── config.json # 运行时可调参数（状态集合/优先级/旁路开关）├── requirements.txt # 依赖说明（仅 Python 标准库）├── README.md # 本文件├── references/│ ├── agent-system-prompt.md # 完整系统提示词全文（部署时加载）│ ├── skill-callbook.md # S1~S9 调用指令手册│ └── control-loop.md # 控制循环决策树 + 优先级表└── scripts/ ├── route_skill.py # 路由决策器（配置驱动、类型安全、可测试） └── tests/ └── test_route_skill.py # 单元测试（覆盖四类场景 + 边界）
快速使用
对话中触发：
@skill:浚枢-协同循环操作指挥 <任务描述 + 验收标准>或 /浚枢-协同循环操作指挥 <任务>。
对着看，你会发现几乎是逐条对齐：
| 腾讯指挥中枢 | 浚枢 LoopOrchestrator |
|---|---|
| 能力池（分散 Agent 收编） | S1 agent-capability-pool |
| 可运行工作流（流程经验落地） | S2 workflow-orchestration |
| 外部可交接（事件进、状态出） | S3 external-handoff |
| 准出字段 + Verdict | S4 structured-verdict（下游只消费 Verdict，不通过打回重填） |
| Fan-out 并行与收敛 | S5 fanout-convergence |
| 通知 / 验收 / 返工 | S6 acceptance-rework（驳回带 reject_reason 回指定节点，不全跑） |
| 自愈与显式阻塞 | S7 self-healing-sweeper（只可见可恢复，恢复不了显式通知人） |
| 错误诊断 | S8 error-diagnosis |
| 指标看板 / 持续改进 | S9 metrics-improvement（每次执行后跑分防漂移） |
这不是巧合。是同一套第一性原理，在不同团队各自长出了相同的骨架。
差别在交付形态：腾讯是"先干出来，再写文章"；浚枢是"把干法抽成 Skill，装好就能直接调"。文章看完你还得自己搭，Skill 装完就能让一组 Agent 围绕目标接力。
控制循环一句话概括：外部事件(Hook) → C1 接入调度 → C2 编排/并行 → Agent 执行 → C3 结构化准出(Verdict) → (C4 验收返工 / C5 自愈诊断 / C6 观测进化) → Callback 状态回写 → 下一轮优化
凌晨三点还在交付的那套机制，本质就是这个循环在没人盯的时候自己转。
小团队的现实：3个人也能养一支AI军团
大厂有几十人搞平台，小团队怎么办？
恰恰因为人少、没专职运维，才更该用 Loop。浚枢自己就是 3 人团队，开发、运维、售后全链路一人分饰几角。过去一个线上问题要等人上班、等人定位、等人修；现在一部分边界清楚的问题（配置异常、已知 Bug、历史积压项）进环路，凌晨触发、早上人来看结果就行。
关键不是"养多少 Agent"，是"把哪类工作定义清楚、交给环路"。小团队优先挑高频、低风险、可验收的活进系统，复杂的留人。先跑通一条短链路（比如 Bug 修复闭环），再慢慢扩。别一上来就想造超级 Agent，那是大厂烧钱玩的。
三步起步：今天就能搭你的第一支AI军团
想动手？别想复杂。三步就够：
第一步，挑一条最短的闭环。 别从需求交付这种长链路起步。选 Bug 修复、配置检查这类"一个问题进、一个结果出"的短链路。浚枢第一支环路，就是历史问题池的定期清理——边界清楚、风险低、结果好验收。
第二步，先建能力池，再画流程。 把你已经有的 Agent（不管散在本地、云还是第三方平台）先收编进一个统一视图，标清"它能干什么、现在能不能用、怎么调、这一步该派谁"。没有能力池，工作流就是空壳。这一步对应浚枢 S1。
第三步，给每个节点加 Verdict。 别让下游去猜自然语言。每个 Agent 产出先过结构化校验——业务产物 + pass/fail/blocked 裁定 + 根因解释 + 置信度，不通过就打回重填。这一步最烦，但少了它，环路跑三天就乱。对应浚枢 S4。
跑通这三步，你凌晨三点就不用再盯屏了。至于 Fan-out 并行、自愈 Sweeper、指标看板，等第一条链路稳了再叠。先有，再好。
对抗式审查：别高兴太早
到这里必须泼冷水。腾讯那篇文章理想化了，真实跑起来远没这么顺。五个盲区你现在就得想清楚：
盲区一：Agent 输出不稳定是常态。 格式飘、漏字段、自然语言说了一堆系统却消费不了——所以才要 Verdict 和准出字段。但加这些本身是成本，而且不是所有任务都好结构化。浚枢 S4 的做法是"不过滤就打回重填"，这能挡住污染下游，可也意味着上游 Agent 要反复重跑，token 在烧。
盲区二：责任边界。 Agent 干了活，出错了算谁的？验收驳回回到哪一步？文章里说"人守验收"，可真到半夜三点系统自作主张改了生产配置，早上谁来担？Loop Engineering 把人上移到"控制面"，但控制面的责任定义，比写代码难得多。
盲区三：算力成本。 凌晨三点还在跑，不是免费的。浚枢自己的商业模式就是"免费开发、只收算力费"——多 Agent 并行跑，账单按调用量走。一支 24 小时不休的 AI 军团，电费和 token 费得先算清楚，否则省下的人力成本被算力吃掉。
具体点：一个 Bug 修复闭环，S1 调度 + S2 编排 + S5 并行 3 路验证 + S4 校验 + S6 验收，一轮下来可能调用 6~8 次 LLM。如果半夜批量跑 50 个历史积压项，token 消耗是白天人工处理时的数倍。所以浚枢在 LoopOrchestrator 里把"哪些场景值得进环路"做成 config 开关——低频高成本的任务默认不自动触发，留给人白天处理。凌晨跑的，只挑高确定性的活。
盲区四：AI 原生流程还是没走。 腾讯自己也说第一阶段只是"把人类流程 Agent 化"。最长期的问题——如果工作从一开始就由 AI 协作完成，它该长什么样——还没答案。路径 B 被暂时搁置，因为没数据。现在的成功，是模仿人类协作，不是重构协作。
盲区五：不是所有工作都该进环路。 目标模糊、风险过高的，必须留人主导。判断"哪些值得进、哪些不进"，恰恰是人和系统分工里最难、也最值钱的那部分。 Loop 不是万能药，乱用反而把简单事搞复杂。
盲区六：环路会悄悄退化。 Agent 模型一升级、外部工具一变，昨天跑通的流程今天可能就偏了。浚枢在 S9 里接了自家的「浚枢-监测SKILL」做五维指标基线回归——每次执行后跑分，偏离基线就告警。没有这层，环路跑久了你以为它还行，其实早歪了。防漂移不是可选项，是长期运行的前提。
从 Prompt 到 Loop：范式升级
说到底，这次实践不是把 Prompt 写复杂了。
Prompt 是典型个人工作方式：人提问，模型给结果。高效，但启动、组织上下文、判断结果、下一步动作，还都在人手里。所以 Prompt 适合个人单点提效。
Loop Engineering 关心的是另一层：怎么设计一套让 Agent 持续推进、验证、纠偏、停止的系统。
一个普通 coding agent 的 loop 是：改代码 → 跑测试 → 看错 → 再修复。组织工作里的 loop 是：工作事件进入 → 工作流接手 → Agent 协作执行 → 状态判断 → 验收或返工 → 指标沉淀 → 下一轮优化。
这两者关注的不是一个层级。
凌晨三点还在交付的，从来不是某个 Agent。是一套围绕目标持续运行的 AI 协作系统。
回到你自己的团队，问三个问题就够了：第一，你们现在卡住的工作，是真的"某一步慢"，还是"一直在等人和人交接"？第二，散落各处的 AI 工具，有没有一个统一视图能随时调得动？第三，Agent 干完的活，是人一句句复查，还是系统按 Verdict 自动往下推？
三个问题里只要有一个答案是"靠人"，那你用的就还是超级个体，不是超级组织。凌晨三点的交付，差的从来不是模型够不够强。
从超级个体，到超级组织
腾讯这篇文章最值钱的一句话：AI 进入岗位之后，下一步应该进入协作链路。
浚枢做的事更往前一步：把这条链路做成了 Skill，让任何团队都能一键拥有自己的 AI 军团——而且这个 Skill 本身，就是用 WorkBuddy 的 AI 协作环路创作出来的，等于用 Loop 造 Loop。
中间差的不是更强的模型。
是"把工作设计成会自己跑的循环"这件事本身。
觉得有用，点个赞让我知道 👍关注收藏，一天一个小技能。
本文由「AI浚枢」原创，基于腾讯技术工程公开文章与浚枢-协同循环操作指挥（LoopOrchestrator）Skill 实践撰写。转载请注明出处。
数据来源：腾讯技术工程公开文章
64个Agent一起想，1小时搞定数学家想了50年的题——GPT-5.6干了件大事（附中文Prompt）
