好的，作为一名资深网站内容运营编辑，我已经根据您的要求，对原文进行了网页适配优化，使其更符合现代网页阅读习惯，同时严格保留了原文的核心信息和所有图片。 --- 作为一名在数据研发领域摸爬滚打多年的“老兵”，我看到这份方案时，感触颇深。 现在的AI Coding工具确实厉害。一个“超级个体”用上Agent，产能就能顶一个初级团队。但问题也随之而来：每个人的Agent都跑在本地，经验不共享，知识不流转。老司机用Agent跑出了最佳实践，新人还在踩同样的坑。 那么，Multi-Agent如何从“个人工具”升级为“团队大脑”？ 1688数据中心通过打造“数研超级组织”，让知识和经验在团队中自动流转。这篇文章，我将把背后的思考和工程实践与你分享。 **核心内容：** 1. 个体Agent时代面临的三大核心痛点 2. 构建“数研飞轮”的核心策略与工程实践 3. “超级组织”带来的团队提效与知识沉淀 ## 一、前言 我们在做数据研发领域的AI coding，过程中与集团很多团队都有深入交流。今年我们发现，大家除了端到端的交付，都在探索“超级组织”。我们通过“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。全自动冒烟测评 & 全自动复盘驱动知识回流，知识回流让小队持续变强，这个闭环每轮都在自转。 ### 三大核心选择 | 选择 | 解决什么问题 | 核心设计 | | :--- | :--- | :--- | | KST 知识工程体系 | 语义资产的系统化沉淀与消费 | K（领域知识）+ S（行为规范）+ T（工作流配置）三层分治 | | Harness Engineering | NL2SQL 从 Demo 到生产级 | 意图澄清→SQL 生成→多轮校验→置信度评估→降级兜底 | | Agent 组织化协作平台 | 知识回流 + 经验复用 + 冷启动分摊 | 研发小队 fork 模式 + 使用过程数据自动回流 | **研发提效**：通过「知识工程」和「Harness」实现研发提效飞轮 **飞轮迭代**：通过Agent 组织化协作平台让个体的知识和最佳实践沉淀，实现「生产工作流」和「数据资产」的自迭代 ## 三、知识工程：让 AI 有据可依 业务吐槽数据不准，你遇到过么？Agent用了一个旧版的GMV口径生成SQL，跑出来的数偏了不少，业务方直接反馈到主管那里，说数据不准，是模型不行么？ **NL2SQL的准确率，很大程度上由输入端的知识质量决定。** 需求说不清楚、语义资产对不齐，模型再聪明也是白搭。这不是经验之谈，是踩了足够多的坑之后得出的结论。知识工程，是这套方案最值得投的地方，也是我们把它排在第一位的原因。 ### 3.2 KST 三层架构 我们踩过的坑告诉我们：业务知识、行为规范、工作流配置，是三种完全不同性质的知识，混在一起管会乱套，必须分治。我们设计了一套三层知识架构——K（Knowledge）+ S（Spec）+ T（Task）——分治不同类型的知识。 #### K 层：领域知识（让 Agent 理解业务） | 资产类型 | 一句话定义 | 内容示例 | 解决什么问题 | | :--- | :--- | :--- | :--- | | 业务规则库 | 业务“是什么”、“怎么算” | “即时零售单产（单品日均GMV）= 单品日均GMV = 即时零售_gmv / 含已下架动销商品数。” | 口径不一致 | | 元数据知识库 | 数据“在哪里”、“长什么样” | 表名、字段含义、血缘关系 | Agent 找不到正确的表 | | SQL 规范库 | 代码“怎么写才合格” | 分区过滤规则、NULL 处理、DDL 命名规范、字段 comment 标准、验收标准 | 交付物质量参差不齐 | | Multi-Agent 配置 | Agent“怎么跑、跟谁配合” | Agent 角色定义、协作规则、交接标准 | 流水线行为不稳定 | | Skill 原子能力 | AI 提效技能资产 | 找表、指标查询等 Skill 的接口与使用契约 | Skill 调用失败率高 | | 经验沉淀库 | 踩过的坑“别再踩” | SQL CR 翻车教训、Bad Case 记录、可复用 SOP（如 LEFT_ANTI_JOIN 排除案例、ROW_NUMBER 去重案例） | 同一个坑团队反复踩 | **Agent经验沉淀库是目前最有差异化价值的一类，也是最难靠设计得到的。** 24条SQL CR记录，是从每一次真实的代码审查里自动沉淀的Bad Case和翻车教训，不是人工整理出来的，是流程跑出来的知识副产品。这就是我们说的“以Agent养Agent”最真实的载体。 #### S 层：行为规范（让 Agent 行为可预期） 有了业务知识，还需要告诉Agent怎么用。S层不是业务知识，是Agent的行为Spec——定义NL2SQL流水线中每个节点应该怎么做、输入是什么、输出标准是什么、验收条件是什么。不再是“跑一次看运气”，而是有明确的契约。我们的小队指令已经迭代到v5版本——每一版都是实战中踩坑后的修正。举个例子，我们的SQL研发节点（小研）的S层Spec包含： ```sql 输入：标准化需求文档（来自小需）+ 语义资产包（来自 K 层） 输出：DDL + DML + 规范自检报告 验收标准： - DDL 命名符合团队命名规范 - 分区字段用 ds STRING COMMENT '业务日期yyyymmdd' - 字段 COMMENT 必须包含中文说明 + 统计口径 - SQL 中禁止 SELECT *，必须显式列出字段 - 规范自检 0 ERROR - ...... - ...... ``` #### T 层：工作流配置（让流水线能跑） 知道做什么、知道怎么做，最后还差一件事：知道跟谁配合、按什么顺序做。T层定义Multi-Agent的协作方式——“顺序协作 + 反馈循环”的组合： * **顺序协作**：Agent 按预定义顺序执行，每一步有明确交付物 * **反馈循环**：CR 发现问题打回返工，最多循环 3 次 * **人工审批卡点**：每个阶段正向流转前，老架验收 + 真人“approved”才能继续 **为什么坚持人工审批卡点？** 因为Multi-Agent工作流很难一步到位。既然无法一步到位，关键节点让人来兜底。随着知识库变厚、流水线变稳，逐步减少人工介入。 ### 3.3 语义资产的冷启动 知识工程的第一道坎是冷启动——上百指标、上千维度的口径，谁来梳理？ 我们的答案是**“以Agent养Agent”**：用Agent的能力，来加速Agent需要的知识建设。 1. **Agent扫描**：用Agent扫描已有的SQL脚本、DataWorks节点、报表、钉钉文档，自动抽取指标名称、计算公式、维度定义、表血缘关系，生成知识草稿。 2. **Agent审核**：语义资产审核Agent review草稿，修正口径错误，补充Agent没抽到的隐性规则，标记置信度。 3. **知识入库**：通过审核的知识条目注册到K层知识库，被后续NL2SQL请求消费。 4. **持续提升**：消费过程中再通过使用的同学给的输入，进一步复盘提高语义资产质量。 **效率对比很直接：手工录入200+指标需要数周，Agent扫描 + Agent审核只需要数小时。** 以分销域知识库的冷启动为例，跑下来的结果是：13个规则文件、40+个表描述文件、1本SQL编码规范手册。Agent扫描花了大约2小时产出初稿。 但有一个问题需要坦诚面对：**80%的通用知识（指标名称、计算公式、表结构）可以通过扫描自动化提取。** 剩下20%的“潜规则”——“这个字段虽然叫buyer_id但实际不写入数据”、“这个指标的分母需要排除测试商家”——还是得靠使用中发现经验才能沉淀到知识库里。 **这20%，是知识工程最费力的地方，也是最有价值的地方。** 因为这些“潜规则”恰恰是新人最容易踩坑、Agent最容易出错的盲区，沉淀下来一条，就能替整个团队省掉一次返工。冷启动阶段收不全这些，没关系——它们藏在大家每天做需求的过程里，跟着用、跟着改，自然就浮出来了。这就是我们设计持续回流机制的原因。 ### 3.4 语义资产的持续回流 冷启动只是第一步，更难的是让知识库持续更新，别变成“知识坟场”。我们的做法是把回流嵌进日常干活的流程里，正常做需求、正常纠错，定期复盘更新语义。 **路径一：需求交付过程中的自动回流（主路径）** 数据研发同学在平台上做需求的过程中会产生各种知识碎片。这些碎片会被自动捕获并结构化。 * 口径补充（“这个 GMV 不含退款订单”）→ 抽取为 K 层指标知识条目 * 口径修正（“buyer_id 是冗余字段，改用 buyer_name”）→ 更新 K 层 + 触发相关需求重新校验 * CR 发现的问题（“分母需要加非零判断”）→ 沉淀到 SQL 规范库 * Agent 行为修正（“不应该跳过数据建模直接写 SQL”）→ 更新 S 层行为 Spec + 小队指令升级 **关键设计：** 同学不需要“额外做一步”——正常做需求、正常纠错，平台在后台自动捕获并结构化。这也是我们坚持用Agent组织化协作平台而不是本地Agent的核心原因：**知识回流，必须建立在“所有人在同一个平台上”这个前提之上。** **路径二：冒烟测评驱动的知识补全与指令升级（被动补漏）** 冒烟测试跑出来的失败案例，往往是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天未消费标记“待确认”，消费后出错标记“疑似过时”再人工复核。但这套机制需要额外的工程投入，当前阶段我们优先把路径一和路径二跑稳，路径三列为下一阶段。这块真的很重要，也欢迎有在做的同学找我们多交流。 ## 四、Loop Engineering：让 Agent 团队像真实研发团队一样干活 ### 4.1 Harness 是什么？Loop 是什么？我们是怎么实现的 **Harness就是我们给Agent加的工程化约束**——流程怎么走、质量怎么检、出错怎么兜底，都写在CLAUDE.md里。说白了Harness是我们给Agent团队划好的车道，**Loop是让这条车道不需要人去推、自己跑起来的机制**——全自动冒烟测评驱动知识回流，知识回流让小队持续变强，这个闭环每轮都在自转。我们的Loop有两层，分别由平台和研发小队共同承担。宙斯AperCoop平台提供了一套搭建loop的“积木”，我们用这些积木拼出了数据研发流水线的约束体系。别的团队拿到同一套积木，完全可以拼出不一样的东西。 > Loop = Harness + 定时调度 + Sub-Agent并行 + 跨轮记忆，没有Harness，Loop无法运转；有Harness不一定有Loop。 **第一层：平台层 Loop（宙斯AperCoop 提供的 Loop 基建）** | 平台能力 | 干什么用 | 我们用它搭了什么 | | :--- | :--- | :--- | | Squad（小队） | Multi-Agent 小队，Agent + 指令 + 知识包 + 运行时打包在一起，可 fork | Harness：组织 5 个 Agent 角色，一键 fork 给新同学 | | Agent 配置 | 自然语言指令文件 CLAUDE.md，Agent 按指令工作 | Harness：流转规则、验收标准、人工卡点全编进去——改文档就是改 Harness | | Issue + Reassign | 任务载体，Agent 之间通过 reassign 交接工作 | Harness：一个需求 = 一个 issue，reassign 驱动流水线流转 | | @mention 触发 | @Agent 直接触发一次执行 | Harness：@真人做审批通知，@老架做流转路由 | | Comment 时间线 | 产出自动记录为评论 | Loop：每个阶段的交付物天然形成可追溯的 E2E 记录，为冒烟测评和知识回流提供数据源 | | Skill + 知识库 | 挂载原子能力和知识包 | Harness + Loop：Agent 调用 Skill 执行任务（Harness），知识库在使用中持续更新（Loop） | | Autopilot | 定时/触发式自动化任务 | Loop：定期批量冒烟测评，自动验证小队质量，驱动 Harness 迭代 | **第二层：研发小队 Harness（CLAUDE.md 编码的约束）** 数据研发同学不需要工程背景就能参与迭代，维护门槛从“会写代码”降到了“会写文档”。目前小队指令已从v1迭代到v5，每一版背后都是生产问题倒逼出来的修正。一份完整的研发小队指令大致包含这些层次： * **角色定义**：老架负责调度验收、小需负责需求澄清、小研负责建模和研发、CR Agent 负责独立审查、小验负责测试发布，各干各的，不越权 * **流转规则**：必须按“需求澄清→数据建模→SQL 研发→SQL CR→测试发布”顺序走，禁止跳步 * **验收标准**：每个阶段的交付物 checklist，不达标不流转 * **人工卡点**：正向流转必须经老架验收 + 真人“approved” * **异常处理**：打回直接返工（不需审批），每环节最多 3 次循环，超次数人工介入 * **闭环准则**：所有操作限定在本小队内，禁止跨队 reassign | 约束类型 | 具体规则 | 解决什么问题 | | :--- | :--- | :--- | | 流水线顺序 | 需求澄清→数据建模→SQL研发→SQL CR→测试发布，禁止跳步 | 防止“跳过建模直接写SQL”导致的返工 | | 质量门禁 | 老架统一验收，每阶段必须“人工审批 approved”才能流转 | Agent 不做最终决策，关键节点留给人 | | 异常上限 | 每环节最多返工 3 次，超次数触发人工介入 | 防止无限循环，保证交付不卡死 | 简单说：**往前走必须有人点头，打回了就直接改，不用再走审批。** 打回路径不需要人工审批，直接返工——正向流转必须人把关，出了问题快速迭代。 ### 4.2 可复用设计：换场景不换 Harness，只换知识包 Harness最重要的设计原则：**知识是变量，Harness是常量。** 同一套CLAUDE.md约束框架（需求澄清→数据建模→SQL研发→CR→测试），在分销域、用增域、商家域都能用——只要把K层的知识包切换成对应域的指标口径和表定义即可。 对团队的意义也很直接：新业务域的同学fork一份模板小队，挂载自己域的知识包，当天就能跑起来。不是从零搭，是站在验证过的起点上出发。（除此之外每个数研同学在使用过程中可以持续迭代自己小队的harness设计，持续完善小队能力，在使用的过程中迭代小队的harness设计） ### 4.3 三道安全网：让 Agent 失败得有据可查 生产环境里，Agent失败的成本很高。Harness的价值不只是“让Agent做对”，更重要的是**让Agent失败得有据可查**，能快速定位到底是知识缺了还是规则没配好。我们给NL2SQL流水线加了三道安全网，各自拦截不同类型的问题： | 安全网 | 拦截什么 | 实际做法 | | :--- | :--- | :--- | | 知识校验 | “知识缺失导致的瞎编” | 生成 SQL 前，检查语义资产是否覆盖完整；缺口直接阻断，不让 Agent 凭空想象 | | SQL CR 独立审查 | “语法对但逻辑错的 SQL” | CR Agent 四维度审查（性能/正确性/规范/安全），独立查询源表进行交叉验证，不依赖小研自述 | | 小验数据验证 | “SQL 能跑但数据不对” | Dev 环境实际执行 DDL+DML，行数验证+数据交叉比对，确保“数据和生产对得上” | **第二道安全网要重点说一下。** CR Agent会在审查前独立查询源表做交叉验证，而不是直接信小研的自检报告。以供应链星级数据表为例，CR Agent独立验证了字段唯一性（百万级数据精确匹配），这条过了才进入下一步。 **第三道安全网同样如此：** 小验交付的不是“SQL执行成功”，而是“数据验证报告”。4张星级表交付时，小验逐一比对了行数和包含关系，关系不对就打回重做。 这个需求从约3小时走完全流程。三道安全网全部走了一遍，没有靠“运气”跑通，每一步都有验证记录可追溯。 ### 4.4 全自动冒烟：Loop 怎么让 Harness 自己进化 三道安全网拦住的是“这一次”的问题。但拦住不够，得让“下一次”不再踩同样的坑。这就是Loop要做的事——**把每一次失败，变成Harness的一次升级。** 我们的Loop是怎么转的？拆开来看，刚好对应四层循环： | Loop 层级 | 我们的落地 | 干什么 | | :--- | :--- | :--- | | Agent Loop | 小队端到端执行 | 需求澄清→建模→SQL→CR→测试，reassign 驱动流转 | | Verification Loop | 全自动冒烟测评 | 同一个标准用例驱动所有小队跑一遍全流程，四维度评分（准确率/完成率/规范性/清晰度） | | Event-Driven Loop | Autopilot 定期触发 | 不用人来启动，平台自动批量创建冒烟任务 | | Hill Climbing Loop | 冒烟失败→改 Harness | 定位根因（K 层知识缺失？S 层 Spec 不足？T 层流转有误？）→ 改写 CLAUDE.md 或补知识库 → 重跑验证 → Harness 升级一版 | 这里有一个关键设计：**冒烟场景下，真人审批由“数字人”替代。** 正常做需求，每个阶段都要真人审批——这是质量的底线，不能省。但冒烟测试如果也等真人一个一个审批，那效率就太低了。所以冒烟场景专门用数字人（我的数字分身）来代替真人做审批判断——数字人阅读老架的验收意见，判断Agent能力是否正常运作，回复“可以继续”或“打回”。这是冒烟能做到“全自动”的关键。 数字人审批有一个重要原则：帮忙分辨是Agent本身能力不行，还是基础设施没配好。比如某支小队冒烟跑下来清晰度评分偏低，但仔细看是因为某个Skill的运行环境没配好——这不是Agent能力差，是环境问题，可以接受。 **说说数据：** 最近一轮冒烟一次性创建了全部小队的测试，**7支小队一次性通过**。没通过的不是“废了”——定位问题、修知识库或改指令、重跑验证，小队指令就是这么从v1一路迭代到v5的。每次失败都会指向一个具体的根因——知识缺失、行为规范不够、还是流转规则有问题，修复完成后平台上所有使用同一套知识的小队都会在下一次使用时自动变得更准。 ## 五、研发小队：宙斯 AperCoop平台上怎么运作的 ### 5.1 为什么需要团队级平台 前面讲的知识工程和Harness都有一个前提：**使用过程中的数据能被采集**。在本地Agent运行时里这个前提不成立——每个人的配置不同，知识不共享，使用过程中的纠错留在本地。我们需要一个“团队级的Agent运行时”——大家在同一个平台上用，使用过程中的数据自动回流到知识库。1688自建的宙斯AperCoop平台（基于开源项目Mutica）恰好补了这个空白。 数据中心-数据研发小队设计 每个数据研发同学独立小队 ### 5.2 “小队”的概念：宙斯 AperCoop 上的 Multi-Agent 组织单元 在宙斯AperCoop平台上，“小队”（Squad）是Multi-Agent协作的组织单元。**一个小队 = 一组Agent + 一套协作指令 + 一套AI知识库知识包。** 小队的关键特性： * **可 fork**：团队成员可以 fork 一个模板小队，得到完整的 Agent + 指令 + 知识包副本 * **可独立迭代**：fork 后的小队归个人所有，可以自由修改 Agent 配置、调整知识包 * **知识可回流**：使用过程中产生的知识回流到公共知识库，所有小队受益 * **质量可测评**：每个小队可以跑冒烟测试，确保迭代不引入 regression ### 5.3 “市场”模式：模板小队 + fork + 自主迭代 我们设计的不是“一个固定的小队给大家用”，而是一个“小队市场”模式。为什么叫“市场”模式？因为未来不只有一个模板小队——不同类型的数据研发场景（ETL、报表、指标加工、数据质量）可以有不同的模板小队。 **具体怎么运作的：** 我们先用大促需求打磨出一个经过验证的“数据研发小队”（包含5阶段流水线 + v5协作指令 + 人工审批卡点），发布为模板小队。团队成员按自己的业务域fork一份，挂载自己域的K层知识包，配置运行时。用着用着发现Agent在自己场景下不好使？直接改协作指令、补充知识包——一线同学最懂自己的场景。迭代产生的知识不只留在个人小队里，口径修正、规范补充、翻车教训自动回流到公共知识库。每次迭代后跑冒烟测试确保没引入regression。 **每个人的小队配置的是他自己的运行时，他为小队负责，为小队的产出负责，也具有迭代自己小队的能力。** 宙斯平台小队市场 数据中心小队编排方案 ### 5.4 端到端全自动流程：一个需求是怎么跑完的 说流程不如看实战。同样是一个数据需求进来，有的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 时间线清晰 ### 5.5 硅基员工：有工号的 AI 需求分析师 我们还做了一个探索——**申请了一个真集团工号的硅基员工，专职做对外需求澄清。** 它不是流水线内部的“小需”Agent，而是面向业务同学的需求质量把关者： * 业务方提数据需求前，先跟这个硅基员工充分讨论 * 把需求聊清楚、口径对准确，再进入研发流水线 **设计思考：** 数据研发的效率瓶颈很大一部分在需求端——“需求进来才发现讲不清楚”。与其让研发同学花时间反复拉通，不如在入口处就用一个不知疲倦的AI分析师把需求质量兜住。 这也是我们对“超级组织”形态的一个探索——当Agent有了工号、有了角色、有了职责，它就从“工具”变成了“组织成员”。A2A（Agent to Agent）协同不再是技术概念，而是组织设计的一部分，畅想一刻，未来有可能需求都是业务的agent提的，技术的Agent直接对接需求，咱们只要负责监工审核产出质量。 钉钉服务需求澄清 硅基员工配置 ## 六、思考与挑战 ### 6.1 从超级个体到超级组织 在做数据研发提效项目过程中，我们和集团内的几个BU保持着持续紧密的交流，今年集团内7-8个团队在做类似的“超级组织”的探索。这说明一个趋势正在形成： **第一阶段：超级个体。** 每个人用自己习惯的Agent工具，个人产能提升显著。但经验不共享，知识不流转。 **第二阶段：超级组织。** 通过团队级平台 + 知识工程 + Agent协作流水线，把个体经验变成组织能力。关键转变： * 从“人用Agent”到“Agent之间协同”（A2A） * 从“知识在脑子里”到“知识在平台上，AI可消费” * 从“每次从零开始”到“站在前人的肩膀上” **大家的判断都高度一致：第二阶段的核心竞争力不在模型，在知识工程。** ### 6.2 三个还没解决的问题 1. **知识冷启动的“最后一公里”**：80%的通用知识可以自动化沉淀，剩下20%的“潜规则”仍然依赖老司机。我们试过用激励机制推动大家主动贡献，说实话效果一般——大家都忙，没人愿意额外花时间把脑子里的东西写成文档。目前最有效的采集方式反而是CR过程中的顺便沉淀，但覆盖率还不够。 2. **AI的能力悬崖**：简单需求可以快速跑通，复杂需求（超多表JOIN、跨域口径、高阶衍生指标）仍需长周期人工介入。说“让Agent学会说不知道”容易，做起来很难——Agent倾向于给你一个看似合理的答案，而不是承认自己不确定。我们目前用置信度评估做降级，但置信度本身也是模型评估的，可靠性有限。 3. **冷启动成本分摊**：Multi-Agent的配置对大部分同学仍有认知门槛。模板小队 + fork模式已经降低了不少，但“会用”和“会调”之间还有一段距离。目前主要靠先孵化出几个超级个体，再让他们带身边的人。 ### 6.3 数据研发同学的角色变化 当Agent能完成日常SQL研发的大部分工作，数据研发同学做什么？ 方向是从“SQL写手”变成“知识工程师”——往深走，维护知识库、训练Agent、设计Harness；或者变成“解决方案Owner”——往宽走，沉淀Skill、经营自己的小队、用Agent小队去交付业务价值。**两条路都通向同一个目标：你的价值不再是“SQL写得多快”，而是“你能让多少经验被组织复用”。** 说实话，现在还在很早期，很多地方磕磕绊绊的。但有一件事让我觉得方向没错——一个同学踩坑后沉淀的口径修正，过了两周被另一个同学的Agent自动消费到了，两个人互相不知道。**一支小队踩的坑，变成了所有小队的免疫力。** 下一步要啃两个硬骨头：知识过时检测的工程化落地，和把复杂需求的人工介入比例降下来。有最佳实践容易，难的是让经验得到共享且能自进化。如果你也在做类似的事情，欢迎交流。