推理链专家
30cdaf8fb7
- 将 looping_data.md、screenshot1.png、screenshot2.png 移至 looping_data/ 文件夹 - 新增推理链分析文稿 looping_data_reasoning_chain.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>
251 lines
15 KiB
Markdown
251 lines
15 KiB
Markdown
# 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 的目标：每一次分析，都让下一次分析更可靠、更快、更可治理。
|
||
|
||
那产品设计就是几条可以逐步迭代优化的曲线：准确率、可信度起点、资产复用率等等。最终结果出来是什么样呢？请让我留给下一篇文章。
|