演讲主题

AI 原生组织的工程实践：从 Loop Engineering 到 Graph Engineering

个人月耗 360 亿 token 之后，瓶颈不是模型能力，而是人的注意力。本次分享讲我在 QQ 飞车研发转型中亲自设计并落地的四层 Engineering Loop：一方面构建 Agent 友好的上下文，另一方面把 SDD 和需求绑定，把注意力切成事前决策、事中释放、事后审查，让单人并发从 5 提到 20。 Graph Engineering 回答「一个 Agent 做对，怎么变成一群人做对」。同时完整复盘三次失控——200K 上下文击穿、7,000+ 层递归烧掉 734M token 与 533 美元、一天 4.4 万行最终不合并——以及由此固化的六条刹车规则。 大纲： 一、为什么是 Loop：从 Prompt、Harness 到 Engineering Loop（5 分钟） 1. 四次抽象跃迁：手写 agent loop → 任务式 Agent → /loop 声明唤醒条件 → /goal 声明可验证终态，控制面从代码沉到 Harness 2. 半年前的起点：一句自然语言批量接管 issue → 工作日每 30 分钟排班巡逻 → 睡觉时自动建分支、修改、推 MR 3. 关键区分：Harness 内的 loop 纠正当前任务，Engineering Loop 让反馈改变下一轮系统 4. 工程四层框架：秒级 Hooks / 分钟级 CI Events / 小时天级 SDD / 组织级 Graph，以及每层「人只看什么、Agent 自转什么」 二、第一层 Loop Agent Context：让确定性错误活不过第二次迭代（6 分钟） 1. 用 AI 开发约束 AI 的工具：1 天做出 golangci-lint module plugin，把日志格式六条铁律编进二进制 2. 为什么用 linter 而不是写 rules：规则越多模型遵守率越低，检测—修复才能永久生效 3. PostToolUse Hook 三原则：跨 CLI 兼容（file_path 与 apply_patch 两种事件格式）、flock 排队防并发竞态、timeout 与 120s 超时对齐 4. pre-commit 的三个工程取舍：只扫暂存文件所在包、自动修复后必须复验、禁止 -n 绕过并留白名单痕迹 三、第二层 Loop CI Workflow：把红灯从「叫人」变成「叫 Agent」（7 分钟） 1. 一个 MR 的一生：push、建 MR、lint 自愈、review 评论、approve、rebase 合入、当晚 changelog 七个事件驱动节点 2. CI 故障自愈：failStages 回调 Agent，几千行日志压到几十行、修复直推分支、自动重跑直到变绿 3. Multi-Agent Review Loop：@oci 行内提问 → OpenCode 回到原线程作答 → --reject 自动建反馈 Issue 并关联评论锚点与构建日志 4. 真实数据与边界：153/1,616 个 MR 走 auto-approve（9.5%），平均 8.5 分钟、中位 2.2 分钟；Hard Gate 与置信度不足时人必须出现 5. 无人值守定时任务：工蜂 issue 自动复现修复、MR git 冲突自动 rebase 语义合并，解不开就把现场留在评论里 四、第三层 Loop Development Workflow：把人的注意力切成三种模式（8 分钟） 1. ~/workflow 的三次迭代：YAML 把状态搬出聊天、Mermaid 只维护流程骨架，clarify 的 SKILL.md 从 191 行降到 66 行 2. 事前决策模式：一句话需求缺的四样东西——边界、约束、验收标准、风险；设计没批准前不写一行代码 3. 事中释放模式：查杀分离提高测试有效性（风险驱动的 668 条用例，跨模型验证把「错法一致」错误集群从 31–49% 降到 6%） 4. 事中的并发工程：单人并发 5 → 20，P/A/T/B/G/R 六阶段 Prompt 生命周期；三种工作区模式（稳定会话 / 隔离并发 / 共享并发）与 /conflict 统一收口 5. 事后审查模式：同一句 Prompt 走 4 个模型 × 10 路 deep review，结论分成代码缺陷、测试不足、Harness 缺陷、设计讨论四类，分别回灌 linter、tester skill、skill constraints 和 clarify 模板 6. 怎么知道 loop 在变好：MR 评论数、重复评论占比、事前澄清耗时三个下降型指标，而不是「写了多少代码」 五、第四层 Graph Engineering：一个 Agent 做对，怎么变成一群人做对（8 分钟） 1. 借 LangGraph 的图工程语汇：State / Node / Edge / Runtime 四个显式工程对象，Agent graph 通常不是 DAG，恢复点、人工门与 trace 必须被显式设计 2. 复制 loop 只是 exercise，不是 productivity：把多人的 loop 连成图，要先划清文件所有权、隔离 worktree、统一 review 口径 3. 授人以鱼、渔、欲：给 SDD 框架是复制答案，开放 DSH 插件实现是复制方法（9 个仓库、三层插件组合），让人看见效果才会长出新的 loop 4. 反例即证据：feature-ugc 没有照抄 SDD，却独立收敛到 parallel_group、subagent 隔离、文件传递同一组概念，5 天 8 次提交、3 个业务域投产 六、失控与刹车：三次事故、六条门禁与受控 RSI（6 分钟） 1. 故事一，200K 装不下的 feature-SDD：单任务 explore 吃掉 270K 上下文、同类任务 670K token，按职责、阶段、触发三刀拆开 2. 故事二，同一套 SDD 的两个夜晚：正常 8 分钟跑完，失控递归 7,000+ 层烧掉 734M token / $533；差别不在任务复杂度，在有没有终止条件 3. 故事三，一天 4.4 万行：44% 是运行代码、56% 是防御性加固层，27 轮评审 193 findings 后决定不合并——loop 精确执行了我给的错边界 4. 六条写进流程的刹车：先写一页纸边界、3,000 行/40 文件变更预算门、工具与业务分家、并行先划界、先删再加、如实记 BLOCKED 5. 收口：内层 loop 交付任务，外层 loop 改进「产生改进的系统」；没有回灌的 loop 只是重复——human in the loop, human build the loop 听众收益： 1. 一套可直接照搬的四层 Engineering Loop 分层框架：秒级 Hooks、分钟级 CI 事件、小时天级 SDD、组织级 Graph，每层都给出「人只看什么、Agent 自转什么」的注意力分工表，听完能判断自己团队该先补哪一层。 2. 可落地的实现细节而非概念：PostToolUse hook 的兼容、排队、超时三原则，pre-commit 增量扫描的三个取舍，failStages 自愈配置写法，auto-approve 放行规则，以及 MR 评论自动回流成下一轮 Agent 输入的完整链路。 3. 一套不靠代码行数的度量口径：MR 评论数、重复评论占比、事前澄清耗时三个下降型指标，配合 9.5% 快线占比、8.5 分钟平均合入、单人并发 5→20、668 条风险驱动用例等真实基线，可用来对齐自己团队的现状。 4. 三次真实失控的完整复盘与代价：200K 上下文击穿、7,000+ 层递归烧掉 734M token / $533、一天 4.4 万行最终不合并，以及由此固化的六条门禁——这些是花钱买回来的教训，可以直接抄进别人的流程。 5. 从个人 loop 走向团队 Graph 的组织方法：文件所有权划分、worktree 隔离、统一 review 口径、/conflict 统一收口，以及把能力从提示词沉淀成插件（9 个仓库、可安装可组合可测试）的「鱼 / 渔 / 欲」三种复制策略。 6. 一个可复用的决策依据：什么时候 human in / on / out the loop，哪些工作区值得并发、哪些不该并发，以及给 loop 装刹车的时机——避免把 Token Maxxing 做成新的古德哈特指标。