Java 后端开发工程师（大模型应用方向） · 深圳 · 6 年经验
hanqiming@example.com · 138 0000 0000 · github.com/hanqiming
个人优势
- 6 年 Java 后端经验，前 4 年做支付和账户系统，近 2 年负责把公司的业务能力接入大模型，搭建了 Agent 调用的工具平台和知识检索服务
- 把后端的稳定性经验用到 Agent 上：工具接口有幂等、超时、限流和审计，模型调用有熔断和降级，大模型服务故障时业务流程不受影响
- 熟悉 RAG 工程化：文档解析、切块、向量与关键词混合召回、重排和增量更新，知道召回不准时先排查数据和切块
- 做 Agent 先定边界：查询类操作交给模型规划，涉及资金和权限的操作必须走确定的代码分支并人工确认
- 建过评测与观测体系：离线评测集 + 线上链路追踪，每次提示词、模型或检索策略变更都能看到效果和成本的变化
- 技术栈：Java 17、Spring Boot、Spring AI、LangChain4j、MySQL、PostgreSQL / pgvector、Elasticsearch、Redis、RocketMQ、Kubernetes、OpenTelemetry
工作经历
某金融科技公司 · 高级 Java 开发工程师（大模型平台）
大模型平台组 8 人，为公司内部客服、风控和运营团队提供 Agent 能力，接入业务系统 20 多个。我负责工具平台和知识检索服务。
- 工具平台：各业务团队原来各自写接口给模型调用，权限和日志都不统一。设计统一的工具注册规范，每个工具声明参数结构、权限范围和是否为写操作，平台统一做鉴权、限流、超时和审计；已接入 140 多个工具，模型调用业务接口的异常定位时间从半天缩短到 15 分钟
- 写操作安全：涉及资金和客户信息修改的工具只生成待审批工单，由业务人员确认后经原有业务流程执行；上线以来没有出现模型直接修改业务数据的情况
- 知识检索服务：客服知识库约 6 万篇文档，原来按固定长度切块，条款类内容经常被切断。改为按文档结构切分并保留标题路径，向量召回和关键词召回合并后重排；评测集上引用正确率从 58% 提高到 86%，文档更新后 10 分钟内可被检索到
- 稳定性：模型服务偶发超时会拖垮调用方线程池。在网关层加入按模型分组的熔断、请求排队和小模型降级，高峰期模型调用的整体成功率从 96.5% 提高到 99.7%
- 评测与观测：和客服质检团队一起整理 800 条标注问题，发布前自动回归；整条 Agent 链路接入 OpenTelemetry，每轮对话的工具调用、耗时和 token 消耗可查
某支付公司 · Java 开发工程师
账户组 10 人，负责账户余额、冻结和流水服务，日均交易约 800 万笔。
- 账户余额更新从数据库行锁改为分段账户 + 异步汇总，热点商户账户的入账 TPS 从 600 提升到 3000
- 设计对账补偿任务，处理渠道回调丢失和重复通知，每月人工处理的差错单从 300 多笔降到 20 笔以内
- 参与账户系统迁移，负责双写比对和灰度切流，迁移期间无资金差错
项目经历
客服工单 Agent
Spring AI / LangChain4j / pgvector / Elasticsearch / RocketMQ
客服处理一张投诉工单需要查交易、账户、风控三个系统，平均耗时 18 分钟。
- Agent 只调用只读查询工具汇总交易链路和异常点，退款、解冻等操作生成审批单交给人工处理
- 长任务改为异步执行，通过消息队列回传每一步进度，客服可以同时处理其他工单
- 回答中的每条结论都附查询记录编号，质检抽查时可以复核；上线半年，工单平均处理时长降到 7 分钟，质检差错率没有上升