1688 Multi-Agent 超级组织实践
1688 Multi-Agent 超级组织实践
来源： 从超级个体到超级组织：1688 数据中心 Multi-Agent 研发小队实录（阿里技术公众号）
核心命题： 将个人用 Agent 提效（超级个体）升级为团队级 Agent 协作体系（超级组织），让知识在组织内流转、复用、自进化。
要解决的三个根本问题
| 问题 | 描述 |
|---|---|
| 语义资产无法系统化沉淀 | 指标口径、维度定义、表关系散落在个人脑子里，NL2SQL 准确率天花板受限于知识质量 |
| 本地 Agent 回收不了经验 | 每个人在本地跑 Agent，经验不共享，新人反复踩相同的坑 |
| Multi-Agent 冷启动成本太高 | 配置完整流水线对大部分人来说认知门槛过高 |
KST 三层知识工程体系
核心设计：按知识性质分层治理，三种不同性质的知识必须分治。
K 层：领域知识（让 Agent 理解业务）
| 资产类型 | 解决什么问题 | 内容示例 |
|---|---|---|
| 业务规则库 | 口径不一致 | 指标计算公式、业务逻辑定义 |
| 元数据知识库 | Agent 找不到正确的表 | 表名、字段含义、血缘关系 |
| SQL 规范库 | 交付物质量参差不齐 | 分区过滤、NULL 处理、DDL 命名规范 |
| Multi-Agent 配置 | 流水线行为不稳定 | Agent 角色定义、协作规则、交接标准 |
| Skill 原子能力 | Skill 调用失败率高 | 找表、指标查询等接口与契约 |
| 经验沉淀库 | 同一个坑反复踩 | CR 翻车教训、Bad Case（24 条真实记录） |
关键点： “经验沉淀库”是最有差异化价值的一类——24 条 SQL CR 记录是从每一次真实代码审查中自动沉淀的，不是人工整理出来的。
S 层：行为规范（让 Agent 行为可预期）
定义 NL2SQL 流水线中每个节点的：
- 输入（标准化需求文档 + 语义资产包）
- 输出（DDL + DML + 规范自检报告）
- 验收标准（命名规范、分区字段约束、禁止 SELECT *、自检 0 ERROR 等）
小队指令已迭代到 v5 版本，每版都是实战中踩坑后的修正。
T 层：工作流配置（让流水线能跑）
定义 Multi-Agent 协作方式：
- 顺序协作： Agent 按预定义顺序执行，每步有明确交付物
- 反馈循环： CR 发现问题打回返工，最多循环 3 次
- 人工审批卡点： 每个阶段正向流转前，必须真人 “approved”
语义资产管理
冷启动：以 Agent 养 Agent
用 Agent 扫描已有 SQL 脚本、DataWorks 节点、报表、钉钉文档，自动抽取指标名称、计算公式、维度定义、表血缘关系，生成知识草稿。审核 Agent 修正口径错误后注册到知识库。
- 效率： 人工录入 200+ 指标需数周 → Agent 扫描 + 审核只需数小时
- 数据： 分销域冷启动产出 13 个规则文件、40+ 表描述文件、1 本 SQL 编码规范手册
- 坦诚： 80% 通用知识可自动化，20% “潜规则”（如字段实际含义与命名不符）仍需人工沉淀
持续回流：三条路径
| 路径 | 机制 | 关键设计 |
|---|---|---|
| 路径一：需求交付中自动回流 | 口径补充/修正 → K 层更新；CR 发现问题 → SQL 规范库；Agent 行为修正 → S 层 Spec 升级 | 同学不需要额外做一步，平台后台自动捕获 |
| 路径二：冒烟测评驱动 | 每次冒烟失败 → 补一条 K 层知识 或 升级一版 CLAUDE.md 指令 | 一次失败两个输出同步走 |
| 路径三：知识过时检测（探索） | 时间戳 + 消费标记 + 疑似过时复核 | 当前阶段优先跑稳路径一二 |
Loop Engineering 四层循环
| 层级 | 做了什么 | 关键设计 |
|---|---|---|
| Agent Loop | 小队端到端执行，reassign 驱动流转 | 需求澄清→建模→SQL→CR→测试 |
| Verification Loop | 全自动冒烟测评 | 统一用例 + 四维度评分（准确率/完成率/规范性/清晰度） |
| Event-Driven Loop | Autopilot 定时触发 | 不用人启动，平台自动批量创建冒烟任务 |
| Hill Climbing Loop | 失败→改 Harness→重跑验证 | 定位根因（K/S/T 哪层问题）→ 改写 → 重跑 |
其中 数字人审批 是冒烟能全自动的关键——正常需求要真人审批保住底线，冒烟场景用数字人替代，帮助分辨是 Agent 自身能力问题还是基础设施问题。
三道安全网
| 安全网 | 拦截什么 | 实际做法 |
|---|---|---|
| 知识校验 | ”知识缺失导致的瞎编” | 生成 SQL 前检查语义资产覆盖，缺口直接阻断 |
| SQL CR 独立审查 | ”语法对但逻辑错的 SQL” | CR Agent 独立查询源表交叉验证（百万级数据精确匹配） |
| 小验数据验证 | ”SQL 能跑但数据不对” | Dev 环境实际执行 + 行数比对 + 数据交叉比对 |
Squad 小队组织模式
市场模式
- 模板小队 → Fork → 自主迭代
- 每个人 fork 一份，挂载自己业务域的知识包
- 迭代产生的知识自动回流到公共知识库，所有小队受益
- 每次迭代后跑冒烟测试确保不 regression
5 阶段流水线
需求澄清 → 数据建模 → SQL 研发 → SQL CR → 测试发布核心规则
- 正向流转必须经老架验收 + 真人 “approved”
- 打回路径不需要人工审批，直接返工快速迭代
- 每环节最多返工 3 次，超次数人工介入
实际效果数据
- 18 支研发小队，指令从 v1 迭代到 v5
- 一次冒烟 7 支小队一次性通过
- 一个需求从约 3 小时 走完全流程（4 张 ADS 层分区表）
- E2E 耗时关键变量：人工审批的响应速度，而非 Agent 执行速度
硅基员工
探索性地申请了真集团工号的 AI 需求分析师，面向业务同学做需求澄清把关，在入口处就用 AI 分析师把需求质量兜住。这是对 A2A（Agent to Agent）协同的实践——当 Agent 有了工号、有了角色、有了职责，就从”工具”变成”组织成员”。
三个未解决的问题
- 知识冷启动的”最后一公里”： 20% 潜规则依赖老司机，激励机制效果一般，CR 顺便沉淀最有效但覆盖率不够
- AI 的能力悬崖： 复杂需求（超多表 JOIN、跨域口径）仍需大量人工介入，置信度评估本身可靠性有限
- 冷启动成本分摊： “会用”和”会调”之间还有距离，目前靠先孵化超级个体带动
总结
从超级个体到超级组织的三层转变
- 人用 Agent → A2A（Agent to Agent 协同）
- 知识在脑子里 → 知识在平台上，AI 可消费
- 每次从零开始 → 站在前人肩膀上
角色变化
SQL 写手 → 知识工程师 / 解决方案 Owner
“你的价值不再是 SQL 写得多快，而是你能让多少经验被组织复用”
参考价值
这是一份经过 18 个小队、v1→v5 迭代检验的实战总结，对任何想做组织级 Agent 协作体系的团队都有参考价值。其 KST 三层分治和 Hill Climbing Loop 的设计思想尤其值得借鉴。