基于 AgentScope 的金融数据平台 Agentic 进化之路

01

数据领域的 Agentic 演进

数据领域正从 Copilot 式辅助走向 Agent 自主完成任务。阿里云 DataWorks Data Agent、Databricks Agent Bricks 等产品已商业化，能力也从代码补全演进为“推理—调工具—执行—纠偏—记忆”的闭环。

但“能跑”只是入场券。Databricks 在 DAIS 2026 提到，核心 Agent Loop 约占 1% 的工作量，其余主要集中在部署、安全、评估、监控和上下文等工程体系。

金融数仓面临全球化部署、协作链路长、表多且口径不容错等复杂性。我们将生产级要求归纳为三点：一是“喂得准”，做好元数据规范化、口径统一和历史数据治理；二是“改得对”，做到可观测、可评测、可回归；三是“敢执行”，通过高危拦截、权限前置和全链路审计守住边界。这些能力更多来自企业自身的数据和工程积累，而非通用框架本身。

02

方案选型与 DataAgent 整体架构

年初我们横向比较了 Spring AI、LangChain、LangGraph、Google ADK 和 AgentScope。Spring AI 更侧重接入抽象；AgentScope 更聚焦 Agent 运行时，原生支持 ReAct、Hook 门控和 PlanNotebook。数据团队又以 Java 为主，现有部署、CI/CD、监控体系可以直接复用。经过半年左右实践，AgentScope Java 基本稳定支撑了平台化 Agentic 落地。

DataAgent 采用严格单向依赖的六层架构：接入层负责 REST、SSE 和鉴权；编排层承载意图、Memory、Checkpoint；上下文工程层管理 Prompt 与 Token；业务 Agent 层通过 Tools、Skills、RAG 扩展场景；集成层对接模型与平台 OpenAPI；存储层负责结构化、向量和缓存数据。安全与质量护栏横切请求前和行动前两个阶段。

我们并不把 Agent 做成外挂聊天窗口，而是让它逐步介入建模、开发、校验、发布、质量和运维全过程。整体由上下文工厂、DataAgent 内核和评测观测体系组成，分别对应“喂得准、敢执行、改得对”。

服务层进一步拆成 DataPilot、DataAgent 和 DataBench。DataPilot 作为数据平台基座，经 OpenAPI 提供知识与执行能力；DataAgent 专注意图、Plan、上下文和编排；DataBench 接收 Trace，承担观测、评测与回归，形成"OpenAPI 供给—Trace 上报—评测回归”的闭环。

03

落地挑战与解决思路

落地生产主要遇到三类问题：一是 ReAct 可靠性，模型可能虚构表名、字段，跳过工具或遇到越权、Prompt 注入；二是工程集成，需要处理流式中断、跨线程上下文及 Plan 跨请求恢复；三是效果量化，Prompt、Tool 或 Skill 调整后，需要有可信标尺判断效果变化。

对应这些问题，我们仍沿“敢执行、喂得准、改得对”展开：前者解决意图、生成执行、门控和 Plan；中间解决上下文工程与上下文工厂；后者通过评测飞轮和 LLM 评委量化效果。

意图识别采用“先便宜后贵、逐层短路”。前端已指定意图或业务域时直接路由，否则依次经过 L1 规则、L2 LLM 分类和 L3 安全护栏。目前已支持任务开发、数据地图两个业务域，覆盖 20 个一级意图；新增能力只需在路由表注册处理器。

代码生成后，系统会强制校验 SQL 语法、表字段真实性及相关口径，异常则回流模型重新纠偏。Agent 只修改开发版草稿，与生产版本隔离；每轮对话通过 Checkpoint 保存任务和代码状态，支持随时回退。涉及权限、澄清或需人工介入的操作，通过结构化交互卡完成。

实际界面支持 Agent Window 与编辑模式，可通过对话完成 SQL 生成、数据探查和结果质量对比。

工具执行前必须经过质量门和安全栅栏。SQL 类型采用白名单，允许 SELECT、开发环境下受控的 INSERT 等操作；DDL、DELETE、UPDATE 等明确禁止的指令直接拒绝。其他请求按风险进入“直接拒绝、改写自愈、交互卡、安全放行”四种出口。核心原则是：能不能执行，要沉淀成工程规则，而不是依赖模型自觉。

当 SQL 开发遇到权限不足等情况，系统会自动弹出权限申请或确认卡，把人工判断嵌入 Agent 工作流。

Plan 模式由运行模式决定，而非模型自行判断。流程采用“规划—硬停确认—自动执行”两阶段机制，同时持久化对话记忆、会话快照和计划状态。AgentScope 管运行时，Plan 真值由业务系统保存。

Plan 以结构化草稿呈现背景目标、关键参数和执行步骤，用户可在线修改，确认后再执行。

每个子任务完成后都会进行偏差评估，符合预期则继续，出现问题则回退修正，形成“执行—评估—修正”闭环。

上下文不能无限装填。我们采用两层装配：编排阶段优先放入代码、摘要和引用表；Schema 与 RAG 知识留到 ReAct 阶段按 Token 预算动态获取。超预算时依次裁剪 RAG、对长 SQL 做语义占位，最后才整体截断；历史对话通过滑动窗口和摘要压缩独立治理。

上下文工厂先做数据探查，再由 LLM 推荐元数据描述，最后交给领域人员复核。表、字段、指标、枚举值按业务域沉淀，并随 Schema 变化增量同步到 Agent RAG。核心原则是“数仓定义知识，Agent 消费知识”，业务真值始终掌握在业务侧。

字段元数据可结合枚举值、分布占比和字段特征由 LLM 自动生成推荐备注，再由人工确认后同步知识库。

针对海量元数据，我们通过批量生成和人工复核工作台，让各领域数仓同学集中审核，持续补充高质量上下文。

每次 Agent 调用都会产生 Trace，记录工具调用、模型调用及输入输出。典型线上问题可一键转成评测用例，并以用户最终采纳的 SQL 作为标准答案。模型、Prompt 或工具调整后，通过回归重放验证效果，形成持续迭代的数据飞轮。

评测包括确定性与主观两类指标。确定性部分进行 SQL 语法校验和结果集行级比对；意图理解、SQL 质量等维度则通过 LLM-as-a-Judge 量化。执行架构按“评测方案—回归批次—单用例—单次执行”四层解耦，并通过快照锁定中间两层，使历史结果可复现。

评测工作台支持维度、Prompt 和 Trace 变量动态配置，可针对不同业务问题灵活设置评估逻辑。

线上沉淀的高价值 Case 最终进入评测集，成为后续版本回归的标准样本。

04

未来演进与总结

这套系统不是平台研发单独完成的。平台团队更擅长架构、工程和护栏，指标口径、隐性业务知识、标准答案和历史样本则主要来自数仓团队。因此，我们形成了“数仓管真值、标准与知识，平台管编排、工程与护栏”的协作方式，并将数仓沉淀的 SOP 逐步转化为可动态加载的 Skills。

目前，分层架构、全链路 Harness，以及“喂得准、改得对、敢执行”三条主线已初步跑通，但仍需继续补齐 Prompt 多版本与灰度评估、百级工具下的动态治理，以及复杂数仓开发中的长程任务和多层 DAG 影响面分析。

横向上，在已上线的开发 Agent、数据地图 Agent 基础上，我们还将规划运维、质量等场景，并探索 A2A 多 Agent 协作。总体原则仍是：AgentScope 管运行时，业务管真值与边界。

点个在看你最好看

SPRING HAS ARRIVED