wiki/looping_data/looping_data.md

Looping Data 文章合集

来源：子凡AI（微信公众号），作者：子凡

• 原文1：https://mp.weixin.qq.com/s/SWCjMsUW98H0_Xdkg1vFGg
• 原文2：https://mp.weixin.qq.com/s/gtH8FQv_0DVJH2rE6v5abw

---

第一篇：如何用 Loop Engineering 建设数据分析智能体

零、产品目标

从一次性问答，演进为可复用、可治理、可沉淀的组织级分析能力。

一、Loop Engineering 是什么

Loop Engineering 不是一个单纯的技术架构，而是一种围绕真实任务持续建设系统能力的产品与工程方法。它关注的不是一次回答是否漂亮，而是系统能否在每一次任务中完成：

执行 → 反馈 → 修正 → 沉淀 → 复用

对数据分析智能体来说，loop 的对象不是单条聊天消息，而是一个完整的 Analysis Case，包括业务问题、分析路径、语义缺口、数据和权限边界、人工确认、经营动作、可沉淀资产。

1. 核心定义

Loop Engineering 是一种让系统在真实业务任务中持续进化的方法。它不是先建设一个大而全的系统，再等待用户使用；而是从一个具体任务开始，边分析、边发现缺口、边补齐能力、边沉淀资产。因此，系统每完成一次任务，都应该回答三个问题：

• 这次任务解决了什么问题？
• 这次任务暴露了什么缺口？
• 这次任务沉淀了什么能力？

2. 一句话理解

普通智能体是：

用户问一次，系统答一次。

基于 Loop Engineering 的智能体是：

用户问一次，系统不仅回答，还发现自己缺什么、补什么、沉淀什么。

它的目标不是替代分析师，而是把组织里的分析经验、指标口径、业务规则、判断过程和行动机制持续工程化。

3. 三条设计原则

任务驱动

从真实业务问题出发，而不是先做大而全的数据治理或语义建模。

缺口显性化

系统必须说明哪些问题能够可靠回答，哪些问题因为数据、语义、规则或权限不足不能可靠回答。

能力沉淀

每次分析结束后，都应沉淀指标、规则、模板、Skill、案例和行动复盘。

二、为什么用 Loop 理念解决数据分析智能体问题

数据分析智能体真正难的不是生成 SQL 或画图，而是如何在企业复杂语义、权限边界和业务判断中持续可靠地工作。

1. 普通 ChatBI / 数据问答的问题

普通 ChatBI 往往解决的是"能不能回答当前问题"。但在企业场景中，真正影响可信度的是这些问题：

1. 只回答当前问题，分析经验无法沉淀；
2. 指标口径、业务规则、权限边界经常隐含在人的经验里；
3. 系统容易把"不确定"包装成确定结论；
4. 数据分析结果和经营动作脱节；
5. 每次复杂分析都像一次重新开始的项目。

这些问题会导致数据分析智能体停留在"问数工具"层面，很难成为组织级分析能力。

2. Loop Engineering 的解决方式

Loop Engineering 不是让智能体一次性变得无所不能，而是让它在真实任务中持续进化。具体来说，它通过以下方式解决问题：

1. 先检查语义、数据、规则、权限和可信度，再执行分析；
2. 把缺口分派给业务专家、数据团队、语义管理员和权限管理员；
3. 让专家确认关键归因，让管理者把建议转成行动；
4. 把结果沉淀为下一次可复用的指标、规则、模板和 Skill。

3. 关键变化

从问答到能力建设

分析结果不是终点，系统能力提升才是闭环终点。

从黑箱到可治理

每个结论都要能看到数据来源、统计口径、权限范围和确认记录。

从个人经验到组织资产

专家修正、业务规则和行动复盘被结构化保存，形成组织级分析能力。

三、Loop Engineering 总流程

Loop Engineering 在数据分析智能体中的完整过程，可以拆成两条相互嵌套的线：这两条线不是分开的，而是在同一个 Analysis Case 中循环发生。

1. 业务分析流

2. 能力建设流

四、角色如何在 Workspace 中协作

每个分析任务都是一个 Analysis Case。智能体负责拆解和编排，不同角色围绕缺口、结论和资产进行协作。协作过程不是围绕聊天消息展开，而是围绕三个对象展开：

阶段	业务提问者	数据分析智能体	数据分析师	业务专家	数据/语义团队	权限管理员	管理者
1. 任务发起	创建 Analysis Case，填写对象/时间/问题	解析业务问题，生成任务理解卡	补充初始背景
2. 分析规划	确认或修改任务理解	生成分析路径，拆解指标与归因链路	审查分析路径，调整图表表达
3. 语义检查		检查语义缺口：指标/规则/权限/可信度；判断是否阻塞分析		识别业务规则缺失	识别数据和口径缺失	识别权限不足
4. 补齐缺口		分派缺口任务，更新 Case 状态；调整分析范围		提供补充材料	补充业务解释，提交候选规则	接入字段/审核口径，处理数据质量	授权/脱敏/审计
5. 执行分析	查看初步结果	调用数据与工具，生成图表/归因/建议	复核分析逻辑	确认数据可用性
6. 专家确认	确认是否满足问题	标注可信度，记录修正来源	确认图表和表达	确认/修正/驳回归因，沉淀候选规则	审核候选规则
7. 管理审阅	选择生成报告	生成报告草稿，形成建议动作	润色分析材料				确认建议可行性，审阅摘要判断优先级
8. 动作与沉淀	查看最终输出	沉淀候选资产，更新 Skill/案例库	保存分析模板	确认规则复用范围	发布正式语义规则	保留审计记录	转为行动项，分派负责人

图例：蓝色底表示智能体编排；橙色底表示语义缺口；绿色底表示确认、规则发布、资产沉淀或行动形成；红色底表示权限、脱敏与审计。

五、最终沉淀的资产

Loop 的价值在于，每次分析结束后，系统不仅留下报告，还留下下一次可复用的能力。

资产类型	示例
指标资产	吞吐量、单吨利润、预算完成率、租库成本率、客户贡献度
规则资产	异常阈值、业务归因规则、口径切换规则、可信校验规则
模板资产	经营分析模板、利润归因模板、客户结构分析模板、会议材料模板
Skill 资产	利润归因 Skill、量价分析 Skill、预算偏差分析 Skill
案例资产	专家修正记录、典型经营问题、行动项复盘、历史分析 Case

目标：每一次分析，都让下一次分析更可靠、更快、更可治理。

六、产品设计总结

基于 Loop Engineering 的数据分析智能体，不应被设计成"问一句答一句"的 ChatBI。它应被设计成一个企业级分析工作台。这个工作台围绕 Analysis Case 组织多角色协作：

• 围绕 Semantic Gap 驱动语义建设。
• 围绕 Human Review 沉淀专家判断。
• 围绕 Action Item 推动经营动作。
• 围绕 Analysis Asset 持续复用能力。

最终目标是：

每一次分析，都让下一次分析更可靠、更快、更可治理。

---

---

第二篇：（二）Looping Data 落地手记：数据分析智能体的产品设计

前言

上一篇《如何用 Loop Engineering 建设数据分析智能体》讲的是方法论：数据分析智能体不该是一句一答的 ChatBI，而应该围绕 Analysis Case 组织多角色协作，每次分析都沉淀能力。之后，我开始用 Fable 5 对其进行设计与实现。目前从一个单文件 HTML 原型到跑通工作台整个闭环：建 Case、语义检查、补缺口、分析、专家确认、报告、行动项、资产沉淀，再到下一个 Case 复用上一个 Case 沉淀的东西。因此，这一篇主要想先从产品设计上讲清楚几件事。

一、不做对话框

动手前我做了三个原型方案：

1. 方案 A：三栏 Case 工作台。左栏 Case 列表，中栏 Case 详情，右栏协作对象。
2. 方案 B：Loop 流水线看板。八个阶段横向排开，Case 像卡片一样在泳道里流动。
3. 方案 C：对话即编排。左边聊天，右边实时生成分析画布，最接近现在主流 AI 产品的形态。

C 是最先被淘汰的，原因是对话是好的入口，但却是个很差的工作台。一个 Analysis Case 里有理解卡、缺口清单、图表、归因链、确认记录、行动项，这些对象的生命周期长短不一。缺口可能挂三天等数据团队补口径，行动项可能在 Case 完结后才被管理者认领。如果把它们都塞进一条对话时间线，第三天你就找不到第一天的东西了。对话适合发起和追问，不适合承载状态。

B 虽然清晰把 Loop 的「阶段流转」过程展现了出来，但用户真正关心的是「这个问题分析得怎么样了」，而不是「卡片现在在第几列」。阶段是骨架，不是内容。

最后定的方案是 A 的三栏结构，加上 B 里我唯一舍不得的东西：一条横贯底部的资产带。

二、两条 Looping 主线

Looping Data 有两条相互嵌套的线：业务分析流（这次问题怎么解决）和能力建设流（系统这次沉淀了什么）。这个嵌套关系，体现在产品上是：

• 主体三栏承载业务分析流，右栏放的是协作中的三类对象：缺口、确认、行动项。
• 底部横向带承载能力建设流，独占资产这一类对象。

资产带放底部这个决定我有些犹豫，它吃掉了约 110 像素的高度，而且大部分时间用户的注意力不在那里。但我最后留下它，有两个理由：

1. 资产的积累是横跨阶段的。阶段 4 补缺口时产生候选规则，阶段 8 才正式发布，横向的进度条天然表达了这种时间上的累积，右栏的竖列表做不到。
2. 常设可见。中栏怎么滚动，资产带都在。这在反复使用后会形成一种产品心智：每次分析都在沉淀东西。这个心智恰好就是 Looping Data 产品想传达的核心主张。

同时，空间代价用一个收起开关兜底。小屏幕上收起来，不影响主流程。

三、Looping 如何闭环

做完第一版原型，我发现一个问题：界面上画出来的其实是一条直线。发起、分析、确认、沉淀，从左到右从上到下，走完就结束了。Looping 在哪？

因此我继续补了四个功能：

1. 资产带切成两段。左段是「⟲ 复用 · 来自历史 Case」，右段是「◆ 沉淀 · 供未来 Case 复用」。资产从案例 N 的输出段流进案例 N+1 的输入。
2. 完结的 Case 顶部放一张「Loop 三问复盘卡」，回答上一篇提出的三个问题：这次解决了什么、暴露了什么缺口、沉淀了什么能力。还有一行量化的循环收益，比如这次分析比上次同类分析快了多少、可信度起点高了多少。
3. 凡是引用了已沉淀资产的地方，打一个绿色的小标：⟲ 沉淀来自 XX Skill，都带上出处。
4. 资产库里已发布的资产带「⟲ 复用 ×N」的角标。资产被用过几次，是它价值的直接证据，也是治理时判断该不该继续维护它的依据。

BTW：谁能告诉我 AI 设计的数据样例为什么永远是华东区

这四项加上之后，产品才算完整了。

四、数据缺口显性化

「数据缺口显性化」是最难的一环。我的做法是把它做进状态机。领域层有一条控制链路：

• 阶段 3 没跑语义检查不能进阶段 4
• 存在阻塞性缺口不能进阶段 5
• 没执行分析不能进阶段 6
• 归因没经过专家评审不能进阶段 7
• 没生成报告不能进阶段 8
• 没完成资产沉淀不能完结

每个守卫都是领域层的纯函数，绕不过去。界面上对应的表达是：被缺口阻塞的 Case，图表区不是空着，而是显性地标注「暂缓执行」，旁边列出阻塞它的具体缺口和被分派的角色。系统不假装能算，也不偷偷少算，它明确告诉你卡在哪、等谁。

这样做有个额外的好处：可信度不再是一个贴在结论上的形容词，而是一条可以追溯的链。看到结论的人可以往回查，这个数字经过了语义检查、经过了专家确认、口径版本是哪一个。

五、治理要留出口

做权限审批时，我加了「挂起归因」：涉及权限缺口的归因行，在审批通过前挂起，不能被专家评审，也不进报告。逻辑上很正确，权限没批的数据当然不该出现在结论里。

但第一版实现里，一个带挂起归因的 Case 会永远卡在阶段 6：不能评审，也不能推进，死锁。

我的教训不在这个 bug 本身，而在它揭示的设计规律：每加一条治理约束，都要同时设计它的出口。审批可能被拒绝，缺口可能长期补不上，专家可能应接不暇。流程图上画「等待审批」很容易，但产品必须回答「一直等不到怎么办」。

挂起的归因现在有明确的语义：Case 可以带着未决问题继续走，未决本身被如实记录。同样的思路也用在权限审批上：审批必须指定审批人和脱敏方案，全程审计留痕。不是因为流程爱好，而是因为分析结论会驱动经营动作，出了问题要能回答「当时是谁、依据什么放行的」。

六、智能是不是地基

最后说一个架构层面的设计决定，它对产品设计的影响比看起来大。

Looping Data 里所有需要「智能」的地方，一共六处：任务理解、语义检查、分析引擎、报告组装、资产沉淀、复用匹配。这个结构也让「智能做得好不好」变成一个可以独立度量的问题：如果系统是模型判断和业务逻辑绞在一起，一次分析结果你是没法知道是模型判断错了，还是数据来源或业务分析错了。

这样，我下一步的计划是：搭一个智能体集群，六个角色智能体扮演提问者、分析师、专家、语义团队、权限管理员和管理者，然后用公开的分析类 Benchmark 测试：例如，InfiAgent-DABench 的 257 道数据分析题，加上横跨 18 个行业领域的 LongTableBench，逐题驱动整个生命周期。

七、最后

上一篇的结尾写过 Looping Data 的目标：每一次分析，都让下一次分析更可靠、更快、更可治理。

那产品设计就是几条可以逐步迭代优化的曲线：准确率、可信度起点、资产复用率等等。最终结果出来是什么样呢？请让我留给下一篇文章。