跳到主要内容

简历前段

核心优势​

  • Agent 系统架构与工程化落地：2 年前端经验，4 年全栈开发经验，具备从 Prompt 工程、上下文工程、RAG 全链路、工具调用、多 Agent 状态机编排、Temporal 确定性工作流、状态持久化到评测回归的完整落地经验，能够将大模型从"对话能力"升级为"可编排、可管控、可观测"的企业级 Agent 系统。
问题：你的项目中 prompt 工程怎么做的

Situation：我们做的智能评标系统，需要让大模型理解几百页的招标文件和投标文件，然后自动完成合规审查、数据提取、评分计算。纯靠手写 prompt 根本管不过来。

Task：我需要设计一套 prompt 工程体系，让几十个 LLM 调用场景的 prompt 可管理、可迭代，而且输出的结果必须是结构化的、可溯源的，不然专家没办法复核。

Action： 第一，所有 prompt 都不硬编码。我们搭了一个 prompt 管理平台，prompt 存在数据库里，代码通过 API 按 name 拉取。要改 prompt 直接改数据库就行，不需要发版上线。

第二，给每个 prompt 定了标准格式。分成角色、任务说明、输出格式（强制 JSON 带示例）、上下文注入、注意事项五个板块。所有 prompt 都要求 LLM 输出必须引用来源（引用的是第几段原文），不满足就重试，JSON 坏了自动修复。

第三，按内容长度自动切换策略。短的直接让 LLM 全文理解，超过 11 万 token 的文字自动走 RAG 检索，先搜再回答。针对复杂的评审问题，我们还做了多轮 Agentic RAG——读完回答、反思不够、再追问、再综合，最多 4 轮。

第四，编排了 7 个专用 Agent 的流水线。要点提取、财报抽取、合规审查、数据提取、代码生成、代码执行、评分解释，每个 Agent 的 prompt 独立管理，前几个步骤还能并行处理多家公司。

Result：

  • Prompt 迭代效率大幅提升，改 prompt 不需要走发版流程
  • 所有模型的输出都是结构化 JSON（坏了自动修复），可直接入库
  • 每个评审结论都能追溯到原文（哪个文档、哪个段落），专家可以逐条复核确认
  • 支持并行处理多家公司的投标文件，评分通过自动生成 Python 代码执行计算，保证可复现

核心就是一句话：把 prompt 从"写一段话给模型"变成了可管理、可编排、可审计的工程资产。

问题：上下文工程怎么做的

Situation：我们评标要处理的标书短的几十页、长的几百页，格式五花八门——PDF、OFD（一种国产版式文件）、Word、Excel，还有扫描件。模型上下文窗口有限，不可能把整本标书一次性塞进去，必须解决"怎么把有用的信息高效地送到模型面前"这个问题。

Task：设计一套上下文工程体系，解决三个核心矛盾：①文档格式杂，要统一解析成模型能理解的文本；②内容太长，塞不进上下文窗口；③多条上下文怎么组织、怎么避免模型混淆。

Action：

第一，统一文档解析管线。我们自己搭了一套解析引擎（knowdoc），PDF 走 MinerU 解析、OFD 先转 PDF 再解析、Office 文档先转 PDF 再走同一套管线、Excel 单独走结构化提取。不管原始格式是什么，最终都落到统一的 Document → Page → Node → Fragment 实体模型，上层 LLM 调用完全不感知原始格式。

第二，分两层做上下文准入。短文本（少于 11 万 token）直接全文喂给模型；长文本走 RAG 先检索再注入。我们甚至对超长财务报告做了"精确定位"——通过文档树结构先锁定目标目录（比如"近年财务状况表"），再在目录内检索，而不是在整个知识库里模糊搜索。

第三，支持三种上下文获取模式，按场景切换：

  • 全文模式：短文件直接读全文，适合完整提取所有要求
  • 单轮 RAG：检索+生成，适合事实查询
  • 多轮 Agentic RAG：检索→回答→反思→追问→综合，最多跑 4 轮，适合需要逐步推理的复杂问题

第四，多 Agent 流水线中的上下文传递。我们把评标拆成 7 个 Agent 的流水线——要点提取 → 财报抽取 → 合规审查 → 数据提取 → 代码生成 → 代码执行 → 评分解释。每个 Agent 产出的结构化数据就是下一个 Agent 的上下文——不是原始文档的堆砌，而是经过提炼的中间结果。

第五，结构化输出约束。所有 prompt 都要求模型按 JSON 格式输出，并且每句话都要标注引用的原文来源（reference_ids）。输出坏了有 json_repair 自动修复，确保下游流程拿到的永远是合法数据。

Result：

  • 几百页的不同格式标书都能统一处理，上层完全不用关心原始格式
  • 超长文档通过 RAG 降级，不会因为超长导致 LLM 调用失败
  • 多轮 Agentic RAG 能把复杂评审问题拆成逐步追问，质量明显优于一次性回答
  • 每个结论都带原文引用，专家可以逐条溯源复核
  • 流水线中各 Agent 间传递的是结构化中间数据，不是原始文本，减少了重复处理

核心思路就是：针对不同长度、不同复杂度、不同格式的上下文，动态选择最优的注入方式，并确保每个环节的输出是可解析、可溯源的结构化数据。

问题：多 Agent 状态机编排怎么做的

Situation：评标流程很复杂——先解析文档、再提取要点、然后拿要点去每家投标人的标书里查数据、做合规审查、最后还要算分排名。这些步骤有的可以并行（同时查多家公司），有的必须等上一步完成（要点没出来没法查），而且中间可能需要专家停下来看一眼确认一下。如果不用编排引擎，这些逻辑全写在代码里，改一个步骤顺序都很痛苦。

Task：设计一套多 Agent 编排体系，解决三个问题：①步骤间的依赖和执行顺序怎么声明、②长时间运行的任务崩溃了怎么恢复、③人工介入的点怎么插入。

Action：

第一，轻量级状态机用于单机流程。我们自己写了一个 PocketFlow——就 100 行代码，核心就是 Node 的三段式生命周期（prep 准备输入 → exec 执行 → post 写回结果），然后用 >> 运算符串联。对于财务评标这类不走数据库的纯计算流程，我们用 PocketFlow 编排了 7 个 Agent：要点提取 → 财报抽取（并行） → 合规审查（并行，不通过就终止） → 数据提取（并行） → 代码生成 → 代码执行 → 评分解释。

第二，Temporal 用于持久化工作流。评标主流程全程跑在 Temporal 上，每个步骤是一个 Activity，整个流程是一个 Workflow。好处是——Worker 挂了自动恢复，不会丢进度；每一步都有完整的事件历史，可以查"当时发生了什么"。

第三，用 Child Workflow 做阶段拆分。我们把技术评审拆成 5 个独立阶段，每个阶段是一个 Child Workflow：生成要点 → KV 提取 → 生成分析 → 生成排名 → 生成评分。后一个阶段必须等前一个阶段确认完毕才能开始，阶段之间靠 Temporal 编排天然保证顺序。

第四，并行 Fan-Out + 分批控制。对于 KV 提取这类"每个投标人 × 每个评审要点"的笛卡尔积任务，我们做了并行执行，但加了一个可配置的并行度控制（默认 5），避免一下子把下游 Dify 服务打爆。每个批次的失败不会影响其他批次，最终汇总成成功/失败计数。

第五，Signal 实现人工介入。专家确认要点这个环节，Workflow 执行到这一步会 await workflow.wait_condition()，等前端发 Signal 过来。如果专家 1 天没确认，就超时报错。确认后 Workflow 自动往下走。这套机制也支持"自动确认模式"——客户要求全自动时，不等人，直接过。

Result：

  • 流程编排与业务逻辑完全解耦，增删一个步骤只需要改 Workflow 定义，不需要改 Activity 代码
  • 长时间流程不会因为 Worker 重启丢失进度，Temporal 保证 Exactly-Once 执行
  • 7 个 Agent 的流水线跑下来，从提交到出评分结果，全程可观测、可中断恢复
  • 专家确认从"异步回调"变成了"Signal 驱动"，前端点了确认，Workflow 自动继续执行
  • 并行度可控，不会打爆下游服务

核心思路就是：用 PocketFlow 管单机内的小流程，用 Temporal 管跨服务的长期流程，用 Signal 插人工节点，用 Child Workflow 做阶段隔离。

  • Harness Engineering 实践能力：能够从工程视角设计 Agent Harness，包括结构化输出校验与 JSON-repair、YAML 版本化 Prompt 管理、失败重试与断点续跑、人工介入节点、LLM 网关全链路审计与溯源，提升 Agent 的稳定性、可控性与生产可用性。

  • 大模型与知识增强能力：熟悉 Agentic RAG、向量 + BM25 混合检索、Cross-Encoder 重排、动态知识库与多知识源路由，具备长文本分块策略优化、复杂文档结构化解析、多模态数据清洗、幻觉控制与复杂任务分解的实战经验。

  • 复杂系统架构与性能优化：深度参与多个大型全栈项目，熟悉 API/Worker 分离、BFF 架构、全异步后端、分布式任务编排；针对不同业务场景的前端复杂度（大数据量渲染、复杂交互状态机、多专家并发评审数据隔离等）有实际优化经验。

  • 云原生与 DevOps 能力：熟悉 Kubernetes、Docker、Helm，具备独立搭建与管理 dev/qa 环境 K8s 集群的能力；掌握 GitLab CI/CD 流水线配置，能够支撑日常开发部署与多环境管理。

技术栈​

1. AI Agent / 大模型工程

  • 熟练掌握 Prompt 工程、上下文工程、结构化输出约束与 Token 预算裁剪策略
  • 熟练掌握 RAG 全链路（解析、分块、向量化、检索、重排、生成），具备 LangChain 生产级落地经验
  • 熟悉多 Agent 状态机编排与工具调用系统设计：工具注册、参数解析、失败重试、结果格式化
  • 熟悉 Agent 状态管理：执行历史、中间结果缓存、Signal 驱动断点续跑、LLM 调用全链路审计与溯源
  • 理解 Harness Engineering：围绕 Agent 构建约束、验证、人工接管与效果回归机制

2. 模型服务与推理框架

  • 熟练掌握 OpenAI API 与国产大模型集成，具备统一流式调用层（SSE）、超时重试、配额管理的工程实践
  • 熟练掌握 vLLM、SGLang、LiteLLM 等模型服务与代理框架，具备模型部署、统一路由、fallback 降级与调用审计的落地经验

3. 后端与平台开发

  • 熟练掌握 Node.js（主力语言），熟悉 NestJS、Koa、GraphQL
  • 熟练掌握 Python，熟悉 FastAPI、Litestar、SQLModel、SQLAlchemy
  • 熟悉 Temporal 分布式工作流编排（API/Worker 分离、parent-child workflow、fan-out 并行、Signal 人机协作）
  • 熟悉 Redis、PostgreSQL、MySQL、ClickHouse
  • 具备 BFF 架构、全异步后端、分布式任务调度等完整后端系统开发经验

4. 大数据与数据治理

  • 熟悉 ClickHouse 列式存储与亿级数据实时分析，具备 OLAP 查询优化与复杂报表开发经验
  • 熟悉多模态数据清洗流水线设计（图片 / 文本 / 音视频规则引擎、PII 脱敏、脏数据拦截）
  • 熟悉亿级文件哈希去重机制与高性能数据处理链路

5. 云原生与 DevOps

  • 熟练掌握 Kubernetes、Docker、Helm，具备独立搭建 K8s 集群与多节点运维经验
  • 熟练搭建 GitLab CI/CD 自动化流水线，实现 dev/qa/prod 多环境配置隔离与自动化发布

6. 前端开发

  • 熟练掌握 Vue、React、Angular，具备多框架组件库开发与跨框架工程化实践
  • 熟悉 Webpack、Vite 构建工具链，具备构建性能优化与打包体积调优经验
  • 具备前端性能调优经验：首屏加载优化、大数据量渲染优化（虚拟列表 / Canvas 增量渲染）、复杂交互场景下的渲染性能分析与优化；能够针对性能瓶颈引入 Rust/WASM、Web Worker等多线程并行方案

面试自我介绍​

面试官好，我叫张世冬，6 年开发经验，从 2 年前端起步，逐步延伸到全栈和 AI Agent 方向。在上一份工作中，我完整经历了 AI Agent 从 0 到 1 落地的全流程——从 Prompt 工程、RAG 到多 Agent 状态机编排、Temporal 长流程工作流，都有实际项目经验。

我很自豪的一个项目是国能的智能评标平台：我用 Temporal 替代传统任务队列，设计了多投标人并行评审的工作流；结合 Agentic RAG 做到评分依据可追溯，搭了 vLLM+LiteLLM+Langfuse 三层观测栈。最终效果是评审专家工作量降了 30% 以上，项目已经通过验收。另一个国网的样本中心项目，我主导了前端的工程化，还用 Rust 写图像算法编译成 WASM，结合 Web Worker 做并行处理——这也是我第一次把 Rust 真正用到生产里。

技术栈方面，主力是 TypeScript 和 Python，前端 Vue/React/Angular 都做过，后端 NestJS 和 FastAPI 比较熟，云原生这边能独立搭 K8s 集群和 CI/CD 流水线。我现在希望找一个 Agent 或者 AI 全栈方向的位置，把我这套从系统设计到工程落地的能力持续发挥出来。谢谢。