用小龙虾构建Data Agent，聊聊天就把数据分析了！
企业为什么需要Data Agent
数据越来越多，而从数据中获取洞察的速度并没有变快。
想知道“ROI为什么下降了”，分析师需要先搞清楚数据在哪里：用户行为数据在数据湖里，产品数据在数据仓库里，渠道归因逻辑可能还散落在不同团队的文档中。光是找到正确的数据、理解字段含义，就可能花掉半天。而真正有价值的工作，即定义分析框架、验证假设、做出决策，反而被挤压到了最后。
而Data Agent正是要解决这个问题：让AI Agent理解业务语义、自主探索数据、执行分析并给出结论，把“从问题到洞察”从天级缩短到分钟级。分析师不再从找表开始，而是直接从问题开始。
您可点击回顾往期文章《从ChatBI到多Agent分析中台：亚马逊云科技与Snowflake的实战架构》，了解基于Amazon Quick Suite、Amazon Bedrock AgentCore与Snowflake Cortex AI的三层架构设计。Amazon Quick Suite已经提供了强大的标准化能力，包括自然语言查询、自定义Chat Agent、MCP工具集成、自动化工作流，能够覆盖大部分通用分析场景。而在实践中，团队也观察到一些企业希望在此基础上走得更远。
企业的个性化Data Agent构建需求
多Agent跨领域协同
企业数据分布在不同系统和平台，不同领域有不同的技术栈选择和业务语言。复杂分析往往需要多个领域的专家分工合作——有人拆任务、有人查各自领域的数据、有人汇总结论，形成完整闭环。
跨session长期记忆
Agent应该能积累业务经验——上次纠正过的指标口径、踩过的数据陷阱，下次不再犯，越用越懂业务。
领域知识的持续注入与更新
企业的数据结构和业务语义不是静态的，表会新增、字段会变化、口径会调整，Agent的知识库需要跟着业务变化自动刷新，而不是靠手工维护。
这些需求叠加，就是本文要展开的方案：基于OpenClaw构建可定制的多专家Data Agent团队，跨领域协同完成数据分析工作。
场景Demo
一个跨领域分析示例
在展开架构细节之前，先通过一个真实场景来感受多专家Data Agent的协作方式。
用户提问：“@pm ROI降低，是用户行为变了还是产品的问题？”
系统的处理流程如下：
1.PM Agent（Alex）接收问题，拆解为子任务分发给团队：Amazon专家（Nova）查询用户行为数据，Snowflake专家（凌）查询产品数据。
2.专家Agent并行执行，各自通过自己的工具链查询数据并返回分析结果。
3.PM汇总归因结论：如图所示，Alex综合两个领域的数据后给出结构化的归因报告——ROI下降的主因是产品维度（~75%贡献），包括生态渠道流量下滑、本地化不足、转化率偏低等；用户行为变化贡献约25%。每项结论标注了数据证据和影响评级。
整个过程对用户来说只是一句提问，背后是多个专家Agent协同完成分析。
架构介绍
整体架构
本方案在OpenClaw之上构建了个性化的前端和服务端（TeamAI）。OpenClaw部署在Amazon EC2上，作为多Agent运行时，每个专家Agent绑定独立的session。
TeamAI作为前端层，提供多Agent对话界面，对接Amazon OpenSearch和Amazon Bedrock Knowledge Base。
每个Agent在OpenClaw中配置了不同的Amazon Bedrock模型和Skill，如Amazon Athena+Amazon S3数据湖查询、Snowflake Cortex AI。
解决方案亮点
Open-Source & Self-Hosted
基于OpenClaw开源运行时，部署在Amazon EC2上，新增专家Agent只需编辑Markdown文件。
Adaptive Memory
后台自动从对话中提炼业务规则和查询经验，每个Agent独立记忆空间，越用越懂业务。
Multi-Expert Collaboration
同一问题可同时调动数据湖和数据仓库的专家并行分析，PM Agent拆解、分发、汇总。
Human-in-the-Loop
Agent先展示对需求的结构化理解并标注来源，用户确认后才执行，避免“问错问题跑错数”。
Unified Semantic Layer
跨数据平台构建统一语义知识图谱，Agent自动理解表关系和业务含义。
核心配置和设计
Agent配置范式
OpenClaw中每个Agent通过一组Markdown和目录结构来定义，不需要写代码。
以下是本方案中三个核心Agent的实际配置片段：
# agents/pm/SOUL_PRIVATE.md# Alex (PM) — 只负责协调和任务管理核心规则： - 收到业务问题 → 返回 JSON 指令分配给团队，不要自己回答 - 收到 "[团队反馈]" → 只基于消息内容汇总，不查历史、不用工具路由规则： - 查询团队成员描述 + Neptune语义判断数据归属，分配给 amazon-expert 或 snowflake-expert - 不确定数据在哪 → 同时分配给两个专家 # agents/amazon-expert/SOUL_PRIVATE.md# Nova — 资深 Amazon 解决方案架构师专长：Amazon 架构设计、成本优化、安全合规、数据分析工具：datalake_query (Athena + Glue) # agents/snowflake-expert/SOUL_PRIVATE.md# 凌 — 资深 Snowflake 数据架构师专长：Cortex AI / Cortex Agent / Semantic View、SQL 优化、数据建模工具：cortex-code左右滑动查看完整示意
系统支持两层SOUL合并，运行时自动合并：
全局GLOBAL_SOUL.md定义共享行为准则
SOUL_PRIVATE.md定义专家独有的领域知识
持续运营设计
Agent团队不是部署完就结束的，需要一套持续机制让系统保持持续进化，本方案对以下方向进行了探索。
Unified Semantic Layer
数据结构和业务语义不是静态的，Agent的知识需要跟着变化自动刷新。本方案通过定时任务将数据湖（Glue Catalog）和数据仓库（Snowflake Semantic Views）的表结构统一同步到Neptune Analytics语义图。
Agent查询时向量搜索定位相关表，图遍历发现JOIN路径，始终基于最新结构生成SQL。语义模型支持YAML和图形化双编辑模式。
语义管理界面
Adaptive Memory
Agent的记忆不是存储对话原文，而是经过结构化提炼后分类存储。查询快照由程序直接从工具调用日志提取（需求+SQL），业务规则和偏好由LLM严格筛选。记忆按类型分级——规则权重最高且永不衰减，快照30天降权。每次提问按权重×衰减排序召回，高价值认知始终优先注入。
记忆管理图
待改进与下一步计划
这套方案在实际使用中已经能够完成跨领域的协同分析，但距离完整的Data Agent还有一些需要持续迭代的方向：
代码级数据理解
目前Agent对数据的理解主要依赖元数据文档和知识库中的表结构描述。但一张表真正的含义——它是怎么生成的、更新频率是什么、数据范围有哪些隐含限制——往往藏在数据管道的代码里。
下一步希望能自动解析数据管道逻辑，让Agent不仅知道“表里有什么”，还知道“数据是怎么来的”。
系统化评估体系
目前回答质量主要靠人工抽检。
下一步需要建立一套标准化的评估机制——针对核心业务场景准备问答测试集，对比Agent生成的结果与预期答案，在每次迭代后自动回归验证。
结语
本文展示了一种基于OpenClaw构建企业级Data Agent的方案：通过多个领域专家Agent的分工协作，配合PM编排、记忆和知识库RAG，让企业能够以自然语言完成跨领域的数据分析。
这不是要替代Amazon Quick Suite这样的标准化产品，而是为那些需要更深度定制的企业提供一条可行的路径。
从“一个Agent回答所有问题”到“一组专家协同完成分析”，这个转变的核心不是技术复杂度的提升，而是让Agent的能力边界与企业数据的现实复杂度对齐。
您可参阅以下内容获取更多信息，即刻上手体验！
Introducing OpenClaw on Amazon Lightsail to run your autonomous private AI agents：
https://aws.amazon.com/cn/blogs/aws/introducing-openclaw-on-amazon-lightsail-to-run-your-autonomous-private-ai-agents/
Getting Started With Snowflake Cortex AI：
https://www.snowflake.com/en/developers/guides/getting-started-with-snowflake-cortex-ai/
本方案的需求文档已上传GitHub，您可以使用Kiro读取需求文档后进行个性化开发。
GitHub：
https://github.com/chawnsj-sys/teamai
本篇作者
沈金
亚马逊云科技高级伙伴解决方案架构师，专注数据及AI领域的解决方案。
新用户注册海外区域账户，可获得最高200美元服务抵扣金，覆盖Amazon Bedrock生成式AI相关服务。“免费计划”账户类型，确保零花费，安心试用。
星标不迷路，开发更极速！
关注后记得星标「亚马逊云开发者」
听说，点完下面4个按钮
就不会碰到bug了！