岗位说明细项
AI 开发工程师岗位项目说明
MizukiBot 的 Agent workflow、Prompt、API、RAG 能力与真实运行经验,按岗位要求逐项展开。
岗位匹配结论
MizukiBot 可作为应聘 AI 开发工程师岗位的主项目。它不是简单的"调用大模型接口",而是一套长期运行的 QQ 场景 AI Agent Runtime,覆盖 Agent 工作流编排、Prompt 工程、平台 API 对接、RAG/记忆系统、工具调用、异步后台任务与运行诊断。
| 岗位要求 | 项目对应能力 |
|---|---|
| Agent 工作流搭建与调优 | 基于 LangGraph / Runtime V2 拆分 route、planner、dispatch、validate、persist 等节点 |
| 编写和优化 Prompt | prompt manifest、persona worldbook、runtime prompt、角色协议与 prompt 检查脚本 |
| 对接平台 API,采集和处理数据 | NapCat / OneBot / 模型 API / 本地工具,处理 QQ 消息、图片、引用、转发、JSONL 日志 |
| 搭建和维护 RAG 知识库 | Memory V3、LanceDB、SQLite、短期上下文、会话摘要、本地知识库分层召回 |
| Python 基础、API、JSON 数据处理 | 主项目用 Node.js,但 HTTP API、JSON/JSONL、任务队列、数据清洗、诊断脚本与 Python 后端同构 |
| 用过 Dify / Coze / FastGPT / Flowise | 未依赖低代码平台,但手写同类 Agent workflow、工具编排与知识召回,可迁移 |
| 用过 LangChain / LangGraph 做编排 | 用 LangGraph 思路组织 Runtime V2,结合自研路由、工具策略与回复校验 |
| 做过真实 AI 项目 | 覆盖真实 QQ 消息、长时间运行、重启恢复、延迟诊断、记忆污染治理、多模型适配 |
能力细项展开
Agent 工作流搭建
项目不是把所有逻辑塞进一个 prompt,而是把运行链路拆成多个阶段:
core/router/index.js—— 消息意图与回复路线判断core/routeExecution.js—— 执行策略与工具开放范围api/runtimeV2/host/index.js—— 主 Runtime 入口api/runtimeV2/nodes/—— prepare、planner、dispatch、validate、draft、humanize、persist 各阶段
这与 Dify / Coze / Flowise 的 workflow 思路一致,只是项目选择了更可控的代码实现。
Prompt 优化
Prompt 不是散落在代码里的字符串,而是按职责管理:
prompts/prompt-manifest.json—— prompt 入口与注入顺序prompts/SYSTEM.txt/prompts/admin.txt—— 主系统提示词与管理员提示词prompts/runtime/—— 运行时协议、回复风格、安全边界、reasoning 展示prompts/persona_worldbook/—— 角色世界书与触发片段npm run check:prompts—— 检查 prompt 装配是否有效
优化方向:输出风格、一致性、安全边界、token 预算、缓存命中、多链路复用。
API 与数据处理
- NapCat / OneBot —— 接收 QQ 消息事件,发送文本、合并转发、表情反馈、戳一戳等 action
- 模型 API —— 适配 Anthropic Messages、OpenAI-compatible、Gemini-style provider
- 本地工具 API —— 命令桥、诊断脚本、知识库检索、图片处理、后台任务
- 数据格式 —— JSON、JSONL、SQLite、LanceDB、本地分片文件、运行 trace
虽未直接对接 Amazon SP-API,但平台 API 接入是同类问题:鉴权、分页、限流、结构化清洗、错误重试、落库、诊断、对 Agent 暴露工具能力。
RAG 知识库与向量数据库
项目中的 RAG 不只是一张向量表,而是分层召回:
- 短期上下文 —— 近期对话连续性
- 会话摘要 —— 压缩长期多轮上下文
- 用户画像 —— 稳定偏好与关系信息
- Memory V3 —— 事件、版本、冲突、可召回状态
- LanceDB —— 向量召回,本地知识库补充文件型资料
- 诊断命令 —— 审计召回质量、污染样本、记忆覆盖率
这能支撑岗位中"让 AI 能调用公司专属业务知识"的需求。
可迁移到岗位业务的方案
把 MizukiBot 经验迁移到电商或广告业务,落地路径:
- 把 Amazon、广告平台或内部系统 API 封装成工具,统一处理鉴权、分页、限流、错误重试与字段标准化。
- 把商品、订单、广告计划、关键词、投放效果等数据写入结构化存储,按业务实体建索引。
- 对规则说明、运营 SOP、FAQ、历史案例建 RAG 知识库,让 Agent 检索公司专属知识。
- 用 workflow 编排"识别问题 → 拉取数据 → 检索知识 → 生成建议 → 校验输出"的业务流程。
- 用 Prompt 约束输出格式:表格、行动项、风险提示、可执行 SQL/API 参数或运营建议。
- 用 trace 与评测集持续检查输出质量,避免 Agent 给出无法执行或无依据的建议。
面试讲法
我做的项目是一个真实运行的 QQ AI Agent,不是只调用一次模型接口。消息进来后,系统先做连续消息聚合与上下文整理,再进入路由层判断是否需要回复、是否需要工具、是否属于管理员任务或普通聊天。Runtime 根据路由结果选择直接回复、planner、工具调用、回复校验与持久化。回复完成后,后台 worker 异步抽取记忆和维护画像,主链路不会被学习任务拖慢。
重点做了三类事:一是 Agent 工作流,拆成 route、planner、dispatch、validate、persist 等节点,通过测试和诊断保证每段可定位;二是 Prompt 和角色一致性,用 manifest、worldbook、运行时协议控制输出风格,给普通用户和管理员设不同安全边界;三是 RAG/记忆系统,组合短期上下文、会话摘要、长期记忆、向量召回和本地知识库,让 Agent 不只看当前一句话。
若岗位需接 Amazon SP-API、广告平台 API 或内部业务知识库,我会把它们当作新的工具和知识源接入现有框架:数据先结构化清洗和落库,再通过工具策略或 RAG 召回暴露给 Agent,最后用诊断日志和测试保证请求参数、数据质量和模型输出稳定。