大模型应用工程师（Agent 方向） · 北京 · 6 年经验
jiangyuchuan@example.com · 139 0000 0000 · github.com/jiangyuchuan
工作经历
某云服务公司 · 大模型应用工程师
智能服务组负责客服和运维两条线的 Agent，团队 6 人（算法 2、工程 3、产品 1），服务约 1200 家企业客户。
- 工单 Agent：客服要在 5 个系统之间来回查订单、配额和告警记录。把查询拆成 9 个只读工具，Agent 负责规划调用顺序并汇总结论，写操作只生成待确认草稿。上线半年，一线客服平均处理时长从 14 分钟降到 6 分钟
- 检索质量：早期按固定 512 字切块，表格和步骤说明经常被切断。改为按文档结构切分，标题路径写进块的元数据，再加一层重排；评测集上答案引用正确率从 62% 提到 87%
- 评测体系：从线上差评和人工抽检里整理 600 条问题，按场景、难度和期望工具链路标注。搭建自动评分脚本，模型裁判与人工打分的一致率约 85%，每次发布前回归一遍，两次拦下了换模型后的效果回退
- 成本与延迟：简单问答走小模型，多步排查才走大模型；检索结果按文档版本缓存。首字时间 P50 从 3.1 秒降到 1.4 秒，月度模型费用下降约 40%
- 安全：工具调用按当前登录用户的权限执行，跨租户查询在网关层拦截；对文档里夹带的“忽略以上指令”类内容做过专项测试，相关用例纳入评测集
某 SaaS 公司 · Node.js 后端工程师
负责消息通知和开放平台，日均推送约 3000 万条，后端 8 人。
- 把通知服务从同步调用改为消息队列 + 重试 + 死信，渠道故障时消息不丢，高峰期接口 P99 从 1.2 秒降到 180ms
- 开放平台接口统一签名、限流和审计日志，第三方调用异常的定位时间从半天缩短到 20 分钟以内
- 2023 年起参与内部知识库问答的原型，负责文档同步和权限过滤，这段经历让我转到大模型应用方向
项目经历
运维排障 Agent
Python / LangGraph / FastAPI / Prometheus API / OpenTelemetry
值班工程师收到告警后要查指标、日志、最近发布记录，平均 25 分钟才能给出初步判断。
- 用状态图描述排障流程：先确认影响面，再按服务依赖查指标和日志，最后对照最近变更给出怀疑点，每一步都可以人工跳过或改写
- 每个工具调用记录输入、输出和耗时，整条链路接入 OpenTelemetry，值班同学能看到 Agent 查了什么、依据是什么
- 结论必须附上指标截图链接和日志片段，没有证据的推断标注为“待确认”；内部试用三个月，初步定位时间中位数降到 8 分钟
客服知识库检索改造
PostgreSQL / pgvector / Elasticsearch / Rerank
- 向量召回和关键词召回各取前 30 条，合并去重后重排取前 6 条，型号、错误码这类精确词靠关键词召回兜底
- 文档更新后只重建变化的块，全量 4 万篇文档的增量同步从每晚 3 小时缩短到 10 分钟级
- 对“查不到”的问题单独统计，每周把高频缺失内容反馈给文档团队，三个月内无答案比例从 18% 降到 7%
个人优势
- 6 年开发经验，前 4 年做 Node.js 服务端，近 2 年负责企业客服与运维场景的 Agent 落地，三个场景上线后稳定运行
- 做 Agent 先定边界：哪些步骤交给模型规划，哪些必须走确定的代码分支，退款、改配置这类操作一律人工确认
- RAG 链路从切块、召回、重排到引用都亲手调过，知道召回不准时先查数据和切块，而不是先改提示词
- 建过离线评测集和自动评分流程：600 条真实问题分场景标注，每次改提示词、换模型、调检索都先跑一遍再上线
- 工具调用做过完整的容错：参数校验、超时、幂等、失败重规划，单次任务工具失败不会让整个对话卡死
- 关注成本和延迟：按问题难度路由大小模型，缓存稳定的检索结果，月度模型费用下降约 40%
- 处理过提示词注入和越权：工具权限跟着用户身份走，模型输出里的指令不会被当成系统指令执行
- 能和产品一起定义“答对”的标准，把客服主管的抽检意见变成评测用例，而不是凭感觉调
- 技术栈：Python、TypeScript、Node.js、LangGraph、FastAPI、PostgreSQL / pgvector、Elasticsearch、Redis、OpenTelemetry