Java Backend · Data Platform · Agent Engineering
做了十年 Java，
也在认真研究 Agent
我从统计数据库的开发维护起步，后来带团队做地市项目，参与 ISMP 产品和广东省平台落地。近两年，我又把 Dify、LangGraph 和 AI Coding 带进了这些真实项目。这一页，是我对十年工作的梳理。
A DECADE IN SYSTEMS
数据从哪里来，经过哪些计算，最后为什么会出现在这张报表里，这是我刚入行时每天都在弄清楚的事。后来做微服务、数据治理和 Agent，系统越来越大，但这几个问题一直没变。
珠海统计微观数据库
2016 年刚进项目时，系统已经到了开发后期。我接手的是一些很具体的工作：微观数据入库、查询、导出，以及上线后的问题处理。
那套系统的主线并不复杂：数据从直报系统、Excel 和 CSV 进来，存储过程负责校验和汇总，最后交给 BIRT 生成报表，或者导出成数据文件。
现在回头看，这段经历最大的价值，是让我很早就习惯顺着数据链路查问题。一个接口为什么这样写，通常要回到它前面的数据来源和后面的使用场景里找答案。
后来，我开始接手需求、设计、部署和维护，负责的事情不再只是一两个功能。
宏观库 · 四经普 · 元数据库
接下来的两年，我连续做了三个项目。团队从 3 人到 6 人，我负责的范围也从功能开发，逐步扩展到需求、设计、技术选型和交付。
这次不只写接口。我参与需求分析、ER 图和原型设计，也负责后面的编码、测试、部署、维护和文档，第一次完整走完一个项目周期。
3 人团队 · 多维查询 · 统计报表 · 快速发布项目基于原有微观库改造，我带着团队接入 KNIME，处理数据清洗、汇总和报表，也把一部分重复逻辑重新整理了一遍。
4 人团队 · 数据清洗 · 汇总分析 · 系统重构我参与前期需求、技术预研和架构设计，项目使用 Solr 做全文检索，并按 OData 规范提供查询接口。
6 人团队 · Solr · OData · 元数据项目做得越多，重复建设的问题越明显。采集、汇总、分析和发布各有一套系统，客户用着麻烦，我们维护起来也费力。
江门市“智慧统计”
江门项目要把数据采集、汇总分析和发布放进同一套平台。我和项目经理一起推进项目，负责技术方案，也要安排 6 人团队的任务，盯住进度和交付。
从业务调研开始，我参与架构和数据模型设计，负责核心功能研发，一直跟到测试、验收和上线。系统交付后，当地原来在线下完成的许多统计工作有了统一的线上入口。
也是从这个项目开始，我发现技术负责人最花时间的往往不是写难代码，而是尽早把需求讲清楚，把任务分明白，再让开发、文档和验收按同一个节奏推进。
江门项目做完后，我们把各地反复出现的需求放到一起，开始认真做一套可以复用的产品。
ISMP 智慧统计产品
ISMP 不是一开始就画好的大平台，而是从多个统计项目里逐步长出来的。我负责核心模块的架构和研发，带领 3 人小组做大数据存储、数据血缘、报表、报告和数据发布，也参与现场部署和问题处理。
这套产品要解决的是一整段工作：先把不同来源的数据收回来，再按指标、制度、标签和血缘整理好，经过报表和分析加工，最后通过报告、门户、查询或订阅交给业务人员。
采集、聚合、更新、生成报告和发布都可以编排成任务；业务人员再通过报表和报告编辑器，把数据做成日常使用的结果。
整个产品团队约 20—25 人，平台有 20 多个微服务模块。我负责其中一部分核心模块的架构和研发，带领 3 人小组，也长期参与详细设计和产品文档。
平台后端以 Spring Cloud 为主，数据侧用了 Hadoop、HDFS、YARN 和 HBase；消息与任务涉及 Kafka、RabbitMQ 和 XXL-Job，检索、缓存、文件分别使用 Solr、Redis、MinIO。Atlas 和图数据库主要用来维护指标、制度、报表、数据集与发布接口之间的关系。
我的工作不只在业务模块里。数据库设计、新技术预研、模块依赖梳理和部署问题都做过。到了多节点环境，故障很少只落在一段代码上，经常要把服务、中间件、缓存和数据存储放在一起排查。
我参与过后续版本规划，讨论过旧技术栈怎么升级、服务边界怎么调整、高可用怎么落地，以及 AI 能力从哪里接入。老系统不能一次推倒重来，这些改造都得按风险和收益分阶段排。
产品逐渐稳定后，广东省平台开始落地。用户和数据规模变大，我们也第一次把智能问数放进了实际业务。
广东省平台 · 珠海门户 · Dify 智能问数
广东省智慧统计平台是 ISMP 的省级落地。我继续参与架构、研发和交付，平台最终覆盖全省 21 个地市。另一边，我还负责珠海统计门户，把内部数据做成公众可以查询和浏览的服务。
21 个地市统一运行，报表汇总周期从周级缩短到天级，背后由20+ 微服务模块共同支撑。
第一次做智能问数
我们用 Dify 搭建知识库和问数流程，把用户的自然语言问题与统计指标、口径、报告期和报表文件匹配起来，再返回表格、图表和说明。
真正难的不是接上模型，而是处理相似指标、时间范围和统计口径。问题不够明确时，继续追问比猜一个答案更可靠。
我负责门户从需求到上线的研发工作。前后台包括文章和公告、指标查询、数据检索、序列数据、指标树、订阅和访问统计，也接入了多种政务 SSO。
2025 年下半年，我开始在日常开发中使用 Claude Code 和 Codex。小任务很快，但一进到 20 多个模块的老项目里，工具常常不知道历史背景，也容易漏掉验证。
Claude Code · Codex · 项目 Harness
我最初也是边说需求边让 AI 改代码。用了一段时间后，问题越来越具体：它不知道某个模块为什么这样拆，不清楚团队约定，跨模块修改做到一半也不容易交给下一个人。
先从日常任务用起。让 Claude Code、Codex 帮我读代码、分析方案、改功能，再由我看 diff、编译和回归。
开始整理固定做法。我陆续研究 Harness、Ralph Loop 和规范驱动开发，重点不是记概念，而是看哪些方法能放进现有项目。
先补上下文和验收标准。AI 参与复杂任务之前，至少要知道模块边界、编码约定、修改范围，以及做完后用什么证明结果没问题。
ISMP 是一个 Java 8 / Spring Cloud 老项目，有 20 多个模块。我给仓库增加了 AGENTS.md 和 .ai/ 协作目录，把架构、模块说明、编码规范、验证命令和任务包规则放进去。
复杂任务先建任务包：写清范围、现状和决定，再记录每一步进度。换工具或换人接手时，不用重新翻一遍聊天记录；做完之后，也能沿着编译、回归和现场验证结果复查。
ACTUAL MARKDOWN
下面的内容节选自 ISMP 现有文档。内部路径和业务字段做了省略，其余结构与实际记录方式一致。
# AGENTS.md - AI 协作入口
本文是任意 AI CLI 进入本仓库后的根入口。
详细协作规则、初始化流程、编码规范、验证命令
和任务包模式均维护在 `.ai/` 目录中。
## 1. 必读入口
开始任何工作前，先读 `.ai/README.md`，
并按其中导航继续读取任务相关文档。## 文档导航
| 文档 | 职责 |
| --- | --- |
| `arch.md` | 架构、模块职责、依赖与数据流 |
| `code-style.md` | Java/Spring 编码规范 |
| `workflow.md` | Maven 验证、提交与交付说明 |
| `taskpack.md` | 任务包判定、记录与交接 |
## 标准工作流
1. 判断是否启用任务包
2. 按任务类型读取上下文
3. 小步实施，避免无关重构
4. 执行验证并说明未验证项# 日志写出任务包
## 2. 目标
- 对齐客户日志规范与现有代码实现
- 补齐 DTO、切面填充、登录渠道缓存和埋点参数
- 区分门户操作与后台管理操作的事件上下文
- 建立可交接的子任务，每个任务都有 README 与 progress
## 5. 方案
| 子任务 | 目标 |
| --- | --- |
| 1-字段契约与DTO | 补齐字段、JSON 名称和类型 |
| 2-切面字段填充 | 完善用户、目标和持续时间 |
| 3-登录渠道缓存 | 在登录 token 生成点记录渠道 |
| 4-接口字段承接 | 接收前端目标信息并调整上下文 |
| 5-验证与交付 | 编译、样例检查、风险复核和交接 |# 日志写出任务包进度
| 日期 | agent | 动作 | 验证 / 下一步 |
| --- | --- | --- | --- |
| 06-15 | claude-code | 分析字段差距 | 只读分析，等待口径确认 |
| 06-15 | human | 确认字段口径 | 决策写入任务包 |
| 06-15 | codex | 复核并拆分任务 | 补充风险，建立 5 个子任务 |
| 06-15 | codex | 实施与校正 | Maven 编译通过 |
| 06-22 | human/codex | 现场日志复盘 | 定位无返回值接口误判 |
| 06-22 | codex | 修复并回归 | BUILD SUCCESS，待现场观察 |分析结论、人工确认、代码修改和现场回归都放在同一个任务包里。后来接手的人能看到结果，也能知道当时为什么这样决定。
以前做数据血缘，是为了知道一份数据从哪里来；现在记录任务过程，是为了让接手的人或 AI 知道代码为什么这样改。两件事其实很像。
AI Coding 解决的是怎么一起写代码。接下来我想弄清楚的是：如果 Agent 真能调用数据和工具，权限这条线该画在哪里。
Dify → LangGraph
第一版用 Dify，因为搭得快，适合先确认多 Agent 路由、工具调用和人工确认能不能跑通。真正用起来后，我想做循环补查和连续状态，画布上的分支越来越多，于是又用 LangGraph 做了第二版。
Dify 版先把想法跑通。总控可以分发任务，多个 Agent 可以并行处理，所有数据操作都经过 Tool Gateway。涉及写入时，先生成候选，等用户确认后再执行，并用 trace_id 留下调用记录。
LangGraph 版重新做运行层。内部数据走 DataCenter，外部 MCP 工具走 ToolCenter；固定 SQL、白名单、人工确认和审计仍由代码控制。前端用 SSE 接收运行过程，测试里加入行为级断言，检查 Agent 实际调用了什么。
现在迭代到了 2.1。2.0 把调度重构进 14 个固定节点的薄 StateGraph：主控有界多轮 ReAct，7 个业务节点 Send 并行，DataCenter/ToolCenter 落成确定性图节点，数据导入走“候选 → 人工确认 → 正式写入”三段链；2.1 补上联网搜索、模型 adapter、按节点模型绑定和主控思考展示。MAF 我还停留在资料阅读和小范围试验，没有把它算进现有成果。
14 个固定节点的薄 StateGraph、26 项数据能力、71 个 MCP 白名单工具，当前通过 860 项测试。
做完这两个版本后，我最在意的已经不是 Agent 有几个，而是哪些判断可以交给模型，哪些事实和操作必须由代码兜住。
THE THREAD
我喜欢先把业务和数据关系理清，再把分散的需求做成能上线、能维护的系统。现在工具里多了 AI 和 Agent，但核对事实、控制边界、把系统跑稳，仍然是每天要做的基本工作。
ABOUT
我做了十年 Java 后端，长期参与政务统计信息化项目。能自己下到代码和数据库里处理问题，也做过技术负责人，带团队从调研、设计一直走到上线验收。相比追新名词，我更愿意把一件事做实，再说它带来了什么。
我会继续在真实的 Java 项目里使用 AI Coding，完善项目上下文、任务拆分和自动验证。好不好用，不看一次生成了多少代码，而看复杂任务能不能稳定交付。
Agent 这边，个人项目已经迭代到 LangGraph 2.1 正式版并持续观察真实运行，下一步是补齐运行评测和更系统的记忆闭环。新的框架也会看，但会先做小实验，再决定值不值得放进项目。
数据平台仍然是我的基本盘。我希望把自己熟悉的数据治理、权限和审计经验带进 Agent 工程，让模型能做更多事，同时让每一次真实操作都有边界、记录和复核依据。