从超级个体到超级组织：1688 数据中心 Multi-Agent 研发小队实录

我们在做数据研发领域的 AI coding，在建设项目能力的过程中和集团很多的 BU 都有深入的交流，今年发现大家除了端到端的交付外，大家都在探索"超级组织"，我们通过「 Loop Engineering」和「知识工程」解决复杂工作流的稳定性与自动化问题，搭建了“数研超级组织”的雏形 ～ 

之前我们在本地用 OpenClaw 搭了一套 Multi-Agent NL2SQL 方案，跑通了端到端交付，验证了 Harness Engineering 的可行性。但要做到真正的团队提效，还有三个根本性的问题需要解决：

1. 语义资产无法系统化沉淀： 1688 经过业务高速发展，为了保障需求的上线速度，在数据资产的建设上做了很多的妥协。数据资产有很多不规范的地方，例如"商家会员 ID"，多个业务域，都有各自的命名方案，且分散在不同的表里。这些"语义资产"——指标口径、维度定义、表关系——散落在每个人的脑子里和本地配置里，NL2SQL 的准确率取决于这些东西的质量，但在本地 Agent 运行时里做语义资产的冷启动和持续更新，技术上非常难采集和管理。

2. 本地 Agent 回收不了经验：每个人的 Agent 都在本地跑，产出的知识留在个人电脑上。我调好了一组 NL2SQL 的 Prompt，你不知道；你踩过的口径坑，我还会再踩一遍。一个新的同学入职或是某个同学要接手另一个业务域的研发需求，就会有一个比较长的Landing的过程。

3. Multi-Agent 的冷启动成本太高：数据研发同学已经有各自习惯的 Agent 工具（Qoder、Qoder Worker 等），这些工具上手快、单点提效明显。但要配置一套 Multi-Agent 的端到端流水线（需求澄清→数据建模→SQL 研发→CR→测试），对大部分同学来说是有认知成本和配置成本的。如果这个成本得不到分摊和复用，就没人愿意迈出第一步。

趋势很明确：个体提效已经不是问题了——一个会用 Agent 的"超级个体"，产能可以超过一整个初级团队。

问题也很明确：每个人的 Agent 都跑在本地，经验不共享，知识不流转。老司机用 Agent 跑出了最佳实践，新人还在踩同样的坑。

没有高质量的语义资产，Agent 无论怎么调都是在凭空想象，NL2SQL 的准确率天花板由此决定。Harness Engineering 把知识系统化地注入到每一个执行环节，让 Agent 的行为可预期、失败可追溯，从 Demo 走向生产级。Agent 组织协作平台"怎么让更多人用起来"——让知识和 Harness 可被团队复用，使用过程中产生的新知识自动回流，飞轮才能真正转起来。数据研发提效不是一个点，是一个飞轮。飞轮的关键不是某个环节多强，而是闭环能不能转起来——知识让生产提效，用的过程再产生知识。这个飞轮，本质上就是一个 Loop。全自动冒烟测评 & 全自动复盘驱动知识回流，知识回流让小队持续变强，这个闭环每轮都在自转。

研发提效：通过「知识工程」和「Harness」实现研发提效飞轮 

飞轮迭代：通过Agent 组织化协作平台让个体的知识和最佳实践沉淀，实现「生产工作流」和「数据资产」的自迭代

业务吐槽数据不准，你遇到过么。 Agent 用了一个旧版的 GMV 口径生成 SQL，跑出来的数偏了不少，业务方直接反馈到主管那里，说数据不准，是模型不行么。NL2SQL 的准确率，很大程度上由输入端的知识质量决定。需求说不清楚、语义资产对不齐，模型再聪明也是白搭。这不是经验之谈，是我们踩了足够多的坑之后得出的结论。知识工程，是这套方案最值得投的地方，也是我们把它排在第一位的原因

我们踩过的坑告诉我们：业务知识、行为规范、工作流配置，是三种完全不同性质的知识，混在一起管会乱套，必须分治。我们设计了一套三层知识架构——K（Knowledge）+ S（Spec）+ T（Task）——分治不同类型的知识.

K 层：领域知识（让 Agent 理解业务）

Agent 经验沉淀库是目前最有差异化价值的一类，也是最难靠设计得到的。24 条 SQL CR 记录，是从每一次真实的代码审查里自动沉淀的 Bad Case 和翻车教训，不是人工整理出来的，是流程跑出来的知识副产品。这就是我们说的"以 Agent 养 Agent"最真实的载体。

S 层：行为规范（让 Agent 行为可预期）

有了业务知识，还需要告诉 Agent 怎么用。S 层不是业务知识，是 Agent 的行为 Spec——定义 NL2SQL 流水线中每个节点应该怎么做、输入是什么、输出标准是什么、验收条件是什么。不再是"跑一次看运气"，而是有明确的契约。我们的小队指令已经迭代到 v5 版本——每一版都是实战中踩坑后的修正。举个例子，我们的 SQL 研发节点（小研）的 S 层 Spec 包含：

输入：标准化需求文档（来自小需）+ 语义资产包（来自 K 层）输出：DDL + DML + 规范自检报告验收标准：  - DDL 命名符合团队命名规范  - 分区字段用 ds STRING COMMENT '业务日期yyyymmdd'  - 字段 COMMENT 必须包含中文说明 + 统计口径  - SQL 中禁止 SELECT *，必须显式列出字段  - 规范自检 0 ERROR  - ......  - ......

T 层：工作流配置（让流水线能跑）

知道做什么、知道怎么做，最后还差一件事：知道跟谁配合、按什么顺序做。T 层定义 Multi-Agent 的协作方式——"顺序协作 + 反馈循环"的组合：

• 顺序协作：Agent 按预定义顺序执行，每一步有明确交付物

• 反馈循环：CR 发现问题打回返工，最多循环 3 次

• 人工审批卡点：每个阶段正向流转前，老架验收 + 真人"approved"才能继续

为什么坚持人工审批卡点？因为 Multi-Agent 工作流很难一步到位。既然无法一步到位，关键节点让人来兜底。随着知识库变厚、流水线变稳，逐步减少人工介入。

知识工程的第一道坎是冷启动——上百指标、上千维度的口径，谁来梳理？

我们的答案是“以 Agent 养 Agent”：用 Agent 的能力，来加速 Agent 需要的知识建设。用 Agent 扫描已有的 SQL 脚本、DataWorks 节点、报表、钉钉文档，自动抽取指标名称、计算公式、维度定义、表血缘关系，生成知识草稿。语义资产审核 Agent  review 草稿，修正口径错误，补充 Agent 没抽到的隐性规则，标记置信度。通过审核的知识条目注册到 K 层知识库，被后续 NL2SQL 请求消费，消费过程中再通过使用的同学给的输入进一步复盘提高语义资产质量。

效率对比很直接：手工录入 200+ 指标需要数周，Agent 扫描 + Agent 审核 只需要数小时。以分销域知识库的冷启动为例，跑下来的结果是：13个规则文件、40+个表描述文件、1本 SQL 编码规范手册。Agent 扫描花了大约 2 小时产出初稿。

但有一个问题需要坦诚面对：80% 的通用知识（指标名称、计算公式、表结构）可以通过扫描自动化提取。剩下 20% 的"潜规则"——"这个字段虽然叫 buyer_id 但实际不写入数据"、"这个指标的分母需要排除测试商家"——还是得靠使用中发现经验才能沉淀到知识库里。

这 20%，是知识工程最费力的地方，也是最有价值的地方。因为这些"潜规则"恰恰是新人最容易踩坑、Agent 最容易出错的盲区，沉淀下来一条，就能替整个团队省掉一次返工。冷启动阶段收不全这些，没关系——它们藏在大家每天做需求的过程里，跟着用、跟着改，自然就浮出来了。 这就是我们设计持续回流机制的原因。

冷启动只是第一步，更难的是让知识库持续更新，别变成"知识坟场"。我们的做法是把回流嵌进日常干活的流程里，正常做需求、正常纠错，定期复盘更新语义。

路径一：需求交付过程中的自动回流（主路径）

数据研发同学在平台上做需求的过程中会产生各种知识碎片：口径补充（"这个 GMV 不含退款订单"）→ 抽取为 K 层指标知识条目；口径修正（"buyer_id 是冗余字段，改用 buyer_name"）→ 更新 K 层 + 触发相关需求重新校验；CR 发现的问题（"分母需要加非零判断"）→ 沉淀到 SQL 规范库；Agent 行为修正（"不应该跳过数据建模直接写 SQL"）→ 更新 S 层行为 Spec + 小队指令升级。

关键设计：同学不需要"额外做一步"——正常做需求、正常纠错，平台在后台自动捕获并结构化。这也是我们坚持用Agent 组织化协作平台而不是本地 Agent 的核心原因：知识回流，必须建立在"所有人在同一个平台上"这个前提之上。

数据研发同学在平台上做需求  ├── 口径补充（"这个 GMV 不含退款订单"）  │     → 抽取为 K 层指标知识条目  ├── 口径修正（"buyer_id 是冗余字段，改用 buyer_name"）  │     → 更新 K 层 + 触发相关需求重新校验  ├── CR 发现的问题（"分母需要加非零判断"）  │     → 沉淀到 SQL 规范库  └── Agent 行为修正（"不应该跳过数据建模直接写 SQL"）        → 更新 S 层行为 Spec + 小队指令升级

路径二：冒烟测评驱动的知识补全与指令升级（被动补漏）

冒烟测试跑出来的失败案例，往往是 K 层知识缺失或 CLAUDE.md 指令漏洞的直接信号——

• Agent 选错了表 → 元数据知识库中缺少表的使用场景描述 → 补充 K 层元数据

• Agent 生成的 SQL 不符合 ODPS 团队规范 → SQL 规范库中缺少对应规则 → 补充 SQL 规范库

• Agent 遇到异常情况不知道如何处理（如需求澄清卡住后直接放弃而非升级） → CLAUDE.md 中缺少对应的异常处理分支 → 升级 CLAUDE.md 指令

一次冒烟失败，有两个输出：补一条 K 层知识，或升级一版 CLAUDE.md 指令。 两条线同时走，知识库和小队能力同步生长。

这条路径有真实数据支撑：平台上线约 6 周，18  支研发小队共跑了 v3、v4 多轮冒烟测评。小队指令从 v1 一路迭代到 v5——每一个版本的背后，都是一批冒烟失败案例指出的具体问题。

路径三：知识版本治理 + 过时检测（探索方向）

知识会过时，一条三个月前对的口径今天可能已经变了。设计思路已经有了——给每条知识条目打时间戳，超 N 天未消费标记"待确认"，消费后出错标记"疑似过时"再人工复核。但这套机制需要额外的工程投入，当前阶段我们优先把路径一和路径二跑稳，路径三列为下一阶段。这块真的很重要，也欢迎有在做的同学找我们多交流。

Harness 就是我们给 Agent 加的工程化约束——流程怎么走、质量怎么检、出错怎么兜底，都写在 CLAUDE.md 里。说白了 Harness 是我们给 Agent 团队划好的车道，Loop 是让这条车道不需要人去推、自己跑起来的机制——全自动冒烟测评驱动知识回流，知识回流让小队持续变强，这个闭环每轮都在自转。我们的 Loop 有两层，分别由平台和研发小队共同承担。宙斯 AperCoop 平台提供了一套搭建  loop 的"积木"，我们用这些积木拼出了数据研发流水线的约束体系。 别的团队拿到同一套积木，完全可以拼出不一样的东西。

Loop = Harness + 定时调度 + Sub-Agent并行 + 跨轮记忆, 没有 Harness，Loop 无法运转；有 Harness 不一定有 Loop。

第一层：平台层 Loop（宙斯 AperCoop 提供的 Loop 基建）

第二层：研发小队 Harness（CLAUDE.md 编码的约束）

数据研发同学不需要工程背景就能参与迭代，维护门槛从"会写代码"降到了"会写文档"。目前小队指令已从 v1 迭代到 v5，每一版背后都是生产问题倒逼出来的修正。一份完整的研发小队指令大致包含这些层次：

• 角色定义：老架负责调度验收、小需负责需求澄清、小研负责建模和研发、CR Agent 负责独立审查、小验负责测试发布，各干各的，不越权

• 流转规则：必须按"需求澄清→数据建模→SQL 研发→SQL CR→测试发布"顺序走，禁止跳步

• 验收标准：每个阶段的交付物 checklist，不达标不流转

• 人工卡点：正向流转必须经老架验收 + 真人"approved"

• 异常处理：打回直接返工（不需审批），每环节最多 3 次循环，超次数人工介入

• 闭环准则：所有操作限定在本小队内，禁止跨队 reassign

简单说：往前走必须有人点头，打回了就直接改，不用再走审批。打回路径不需要人工审批，直接返工——正向流转必须人把关，出了问题快速迭代。

Harness 最重要的设计原则：知识是变量，Harness 是常量。

同一套 CLAUDE.md 约束框架（需求澄清→数据建模→SQL研发→CR→测试），在分销域、用增域、商家域都能用——只要把 K 层的知识包切换成对应域的指标口径和表定义即可。

对团队的意义也很直接：新业务域的同学 fork 一份模板小队，挂载自己域的知识包，当天就能跑起来。不是从零搭，是站在验证过的起点上出发。（除此之外每个数研同学在使用过程中可以持续迭代自己小队的 harness 设计, 持续完善小队能力， 在使用的过程中迭代小队的harness 设计）

生产环境里，Agent 失败的成本很高。Harness 的价值不只是"让 Agent 做对"，更重要的是让 Agent 失败得有据可查，能快速定位到底是知识缺了还是规则没配好。我们给 NL2SQL 流水线加了三道安全网，各自拦截不同类型的问题：

第二道安全网要重点说一下。CR Agent 会在审查前独立查询源表做交叉验证，而不是直接信小研的自检报告。以供应链星级数据表为例，CR Agent 独立验证了字段唯一性（百万级数据精确匹配），这条过了才进入下一步。

第三道安全网同样如此：小验交付的不是"SQL 执行成功"，而是"数据验证报告"。4 张星级表交付时，小验逐一比对了行数和包含关系，关系不对就打回重做。

这个需求从 约 3 小时走完全流程。 三道安全网全部走了一遍，没有靠"运气"跑通，每一步都有验证记录可追溯。

三道安全网拦住的是"这一次"的问题。但拦住不够，得让"下一次"不再踩同样的坑。这就是 Loop 要做的事——把每一次失败，变成 Harness 的一次升级。我们的 Loop 是怎么转的？拆开来看，刚好对应四层循环：

这里有一个关键设计：冒烟场景下，真人审批由"数字人"替代。 正常做需求，每个阶段都要真人审批——这是质量的底线，不能省。但冒烟测试如果也等真人一个一个审批。所以冒烟场景专门用数字人（我的数字分身）来代替真人做审批判断——数字人阅读老架的验收意见，判断 Agent 能力是否正常运作，回复"可以继续"或"打回"。这是冒烟能做到"全自动"的关键。

数字人审批有一个重要原则：帮忙分辨是 Agent 本身能力不行，还是基础设施没配好。比如某支小队冒烟跑下来清晰度评分偏低，但仔细看是因为某个 Skill 的运行环境没配好——这不是 Agent 能力差，是环境问题，可以接受。

说说数据：最近一轮冒烟一次性创建了全部小队的测试，7 支小队一次性通过。没通过的不是"废了"——定位问题、修知识库或改指令、重跑验证，小队指令就是这么从 v1 一路迭代到 v5 的。每次失败都会指向一个具体的根因——知识缺失、行为规范不够、还是流转规则有问题，修复完成后平台上所有使用同一套知识的小队都会在下一次使用时自动变得更准。

前面讲的知识工程和 Harness 都有一个前提：使用过程中的数据能被采集。在本地 Agent 运行时里这个前提不成立——每个人的配置不同，知识不共享，使用过程中的纠错留在本地。我们需要一个"团队级的 Agent 运行时"——大家在同一个平台上用，使用过程中的数据自动回流到知识库。1688 自建的 宙斯 AperCoop 平台（基于开源项目 Mutica）恰好补了这个空白。

数据中心-数据研发小队设计

每个数据研发同学独立小队

在宙斯 AperCoop 平台上，"小队"（Squad） 是 Multi-Agent 协作的组织单元。一个小队 = 一组 Agent + 一套协作指令 + 一套 AI 知识库知识包。小队的关键特性：

• 可 fork：团队成员可以 fork 一个模板小队，得到完整的 Agent + 指令 + 知识包副本

• 可独立迭代：fork 后的小队归个人所有，可以自由修改 Agent 配置、调整知识包

• 知识可回流：使用过程中产生的知识回流到公共知识库，所有小队受益

• 质量可测评：每个小队可以跑冒烟测试，确保迭代不引入 regression

我们设计的不是"一个固定的小队给大家用"，而是一个"小队市场"模式。为什么叫"市场"模式？因为未来不只有一个模板小队——不同类型的数据研发场景（ETL、报表、指标加工、数据质量）可以有不同的模板小队。

具体怎么运作的：我们先用大促需求打磨出一个经过验证的"数据研发小队"（包含 5 阶段流水线 + v5 协作指令 + 人工审批卡点），发布为模板小队。团队成员按自己的业务域 fork 一份，挂载自己域的 K 层知识包，配置运行时。用着用着发现 Agent 在自己场景下不好使？直接改协作指令、补充知识包——一线同学最懂自己的场景。迭代产生的知识不只留在个人小队里，口径修正、规范补充、翻车教训自动回流到公共知识库。每次迭代后跑冒烟测试确保没引入 regression。

每个人的小队配置的是他自己的运行时，他为小队负责，为小队的产出负责，也具有迭代自己小队的能力。

说流程不如看实战。同样是一个数据需求进来，有的 3 小时就交付完了，有的跑了大半天。一快一慢，差别不在 Agent 有多聪明，而在人工审批响应有多及时。以供应链星级数据表为例——这是一个典型的 ETL 建表需求，要交付 4 张 ADS 层分区表。从 15:49 需求进入，到 18:55 终审通过，约 3 小时走完了整条流水线。 拆开来看，Agent 的每一个阶段都没怎么停：需求澄清做完交给老架验收，建模设计完成等真人拍板，SQL 研发交由 CR Agent 独立做四维度审查，Dev 测试环境验证完比对数据。全程 4 次人工审批，每次 Agent 交卷，真人签字，下一棒继续跑。 节奏像接力赛，不是等待赛。

也跑过另一类需求——Agent 十几分钟就把测试报告写完了，基线预检、代码变更分析、数据对比一样不差，然后等真人回复，等了大半天。这不是系统慢，是人慢。两个案例放一起看：E2E 耗时的关键变量，是人工审批的响应速度，不是 Agent 的执行速度。

工作流程概览

核心设计原则：

• 一个端到端需求 = 一个 issue：整条流水线只用同一个 issue 承载，不拆子 issue，上下文完整

• 正向流转必须经过人工审批：Agent 之间不能直接 reassign，必须经老架验收 + 真人批准

• 打回路径不需要人工审批：质量不达标时直接打回执行 Agent，快速迭代

• 单次 run 只发一条 comment：所有产出合并到一条评论中，保持 issue 时间线清晰

我们还做了一个探索——申请了一个真集团工号的硅基员工，专职做对外需求澄清。

它不是流水线内部的"小需"Agent，而是面向业务同学的需求质量把关者：

• 业务方提数据需求前，先跟这个硅基员工充分讨论

• 把需求聊清楚、口径对准确，再进入研发流水线

设计思考：数据研发的效率瓶颈很大一部分在需求端——"需求进来才发现讲不清楚"。与其让研发同学花时间反复拉通，不如在入口处就用一个不知疲倦的 AI 分析师把需求质量兜住。

这也是我们对"超级组织"形态的一个探索——当 Agent 有了工号、有了角色、有了职责，它就从"工具"变成了"组织成员"。A2A（Agent to Agent）协同不再是技术概念，而是组织设计的一部分，畅想一刻，未来有可能需求都是业务的 agent 提的，技术的 Agent 直接对接需求，咱们只要负责监工审核产出质量。

在做数据研发提效项目过程中，我们和集团的几个 BU 保持着持续紧密的交流，今年集团内 7-8 个团队在做类似的“超级组织”的探索。这说明一个趋势正在形成：

第一阶段：超级个体。 每个人用自己习惯的 Agent 工具，个人产能提升显著。但经验不共享，知识不流转。

第二阶段：超级组织。 通过团队级平台 + 知识工程 + Agent 协作流水线，把个体经验变成组织能力。关键转变：

• 从"人用 Agent"到"Agent 之间协同"（A2A）

• 从"知识在脑子里"到"知识在平台上，AI 可消费"

• 从"每次从零开始"到"站在前人的肩膀上"

我们的判断都高度一致：第二阶段的核心竞争力不在模型，在知识工程。

1.  知识冷启动的"最后一公里"：80% 的通用知识可以自动化沉淀，剩下 20% 的"潜规则"仍然依赖老司机。我们试过用激励机制推动大家主动贡献，说实话效果一般——大家都忙，没人愿意额外花时间把脑子里的东西写成文档。目前最有效的采集方式反而是 CR 过程中的顺便沉淀，但覆盖率还不够。

2. AI 的能力悬崖：简单需求可以快速跑通，复杂需求（超多表 JOIN、跨域口径、高阶衍生指标）仍需长周期人工介入。说"让 Agent 学会说不知道"容易，做起来很难——Agent 倾向于给你一个看似合理的答案，而不是承认自己不确定。我们目前用置信度评估做降级，但置信度本身也是模型评估的，可靠性有限。

3. 冷启动成本分摊：Multi-Agent 的配置对大部分同学仍有认知门槛。模板小队 + fork 模式已经降低了不少，但"会用"和"会调"之间还有一段距离。目前主要靠先孵化出几个超级个体，再让他们带身边的人。

当 Agent 能完成日常 SQL 研发的大部分工作，数据研发同学做什么？

方向是从"SQL 写手"变成"知识工程师"——往深走，维护知识库、训练 Agent、设计 Harness；或者变成"解决方案 Owner"——往宽走，沉淀 Skill、经营自己的小队、用 Agent 小队去交付业务价值。两条路都通向同一个目标：你的价值不再是"SQL 写得多快"，而是"你能让多少经验被组织复用"。

说实话，现在还在很早期，很多地方磕磕绊绊的。但有一件事让我觉得方向没错——一个同学踩坑后沉淀的口径修正，过了两周被另一个同学的 Agent 自动消费到了，两个人互相不知道。一支小队踩的坑，变成了所有小队的免疫力。

下一步要啃两个硬骨头：知识过时检测的工程化落地，和把复杂需求的人工介入比例降下来。有最佳实践容易，难的是让经验得到共享且能自进化。