当 LLM 能力渗入数据平台，一个绕不开的问题是：数据能力该封装成 Skill 还是 Agent？全做成 Agent 会带来成本失控与能力重复；全做成 Tool 又撑不起归因、洞察、SQL 生成等多步决策场景。我们提出 Skill（原子能力层）/ Agent（场景编排层）/ 项目空间（治理层）的三层抽象，通过统一接口契约让 Skill 在多个 Agent 间复用，通过项目空间实现个人 → 空间 → 平台的三级贡献分发。目前已支撑探索分析、归因、洞察、SQL 生成等多个场景 Agent，底层 Skill 跨 Agent 复用率显著提升，个人贡献的能力也能沉淀为平台资产。本分享将正面回答"Skill 和 Agent 到底怎么分"这一高频争论，并复盘真实的设计取舍与踩坑。

演讲提纲：

一、业务背景与问题定义
1. 数据平台面对探索性、诊断性需求的响应困境
2. LLM 引入后的两种极端：全 Agent 化 vs 纯 Tool Use，各自失效的原因
3. 数据领域的独特张力：确定性 × 决策性并存

二、方案选型与核心架构
1. 三层抽象：Skill（能力层）/ Agent（编排层）/ 项目空间（治理层）
2. Skill 的接口契约：输入输出 / 副作用 / 权限 / 幂等
3. Agent 的编排模式：ReAct、Plan-Execute、人工介入
4. 项目空间的治理职责：发布订阅、权限穿透、生命周期

三、边界辨析：Skill 与 Agent 的五维判据
1. 是否用 LLM / 是否多步规划 / 是否有状态 / 面向谁 / 失败语义
2. 真实争论：SQL 生成到底是 Skill 还是 Agent？
3. 反模式：什么能力不该做成 Agent，什么能力不该做成 Skill

四、落地挑战与实证案例
1. 探索分析 / 归因 / 洞察 / SQL 生成：Agent 共用 Skill 的复用图谱
2. 踩坑：Skill 粒度失控、命名语义重叠、质量参差、贡献动力不足

五、贡献机制、未来规划与总结
1. 个人 → 空间 → 平台的三级分发机制
2. Skill 自动评测、Agent 能力图谱、跨空间能力流转
3. 开放问题：私有 Skill 体系与 MCP / A2A 开放协议如何共处

听众收益：

1. 一套可迁移的双层抽象方法论：掌握 Skill 与 Agent 的边界判据，能在自己的数据平台中落地分层能力架构，避免"每个需求都做一个 Agent"的失控。
2. 数据领域 Skill 设计经验：针对归因、洞察、SQL 生成等复杂场景，理解哪些原子能力值得沉淀为 Skill、哪些应当封装为 Agent，以及标签系统在其中的定位。
3. 能力贡献生态的工程取舍：理解个人 → 空间 → 平台的三级分发机制，在质量、权限、复用之间取得平衡，避免"人人可建"沦为"无人敢用"。