ai-agent git:20260920.a4843f5A

Immutable. This exact content is served forever at /api/v1/blob/85e4521ff575d90d.

---
name: ai-agent
description: Agent 开发与运行时怎么面：循环与工具、RAG、上下文与记忆、评测、安全、成本。Agent 与 LLM 应用岗读。
keywords: [agent, agent开发, agent harness, agent infra, agent 运行时, llm应用, 大模型应用, rag, mcp, function calling, tool use, 提示工程, 上下文工程, langgraph, claude code, codex, tracing, eval pipeline, agentic coding, ai工程师]
layer: domain
---

## 面试官在意什么

Agent 开发工程师（也叫 LLM 应用开发、AI 工程师、Agent harness / infra / 运行时）做的是模型外面那一圈：把基座模型变成可上线的产品能力，并让它稳定、可控、可查、可付得起。往上是应用层：搭 RAG 链路、设计 Agent 的工具与状态、写和维护提示词、建评测集、处理安全与合规；往下是运行时层：循环怎么跑、工具怎么分级、上下文怎么控成本、跑到一半停了怎么续、跑完了怎么评、失败怎么回灌到下一版。2026 年这一层已经有公认的做法（Claude Code、Codex、Manus 的公开资料收敛到同一张表）：事件优先的循环、工具按读 / 写 / 需确认分级、执行类工具隔离、子 agent 有独立上下文与预算、缓存命中率当一等指标、记忆与技能外化到模型之外、长任务可停可续、评测看轨迹不只看结果。

这个方向简历注水率极高：很多"RAG 项目"只是教程改了数据源，很多"Agent 平台"只是框架调用。面试官最在意四件事：一是什么归代码什么归模型，说得出边界与理由；二是有没有评估闭环（评测集、指标、回归）和真实的失败案例（死循环、误调工具、上下文爆、缓存全失、召回失败）与修法；三是评测有没有轨迹级的指标而不只是成功率；四是能不能说清模型能力的边界、什么时候不该用大模型，以及对自己用的 coding agent 有没有切身体感。

校招侧重：注意力机制与 tokenizer 的基本概念、能用 API 搭一个带检索的问答并解释每一步、能把一次 agent 执行拆成步、写过带预算和终止条件的循环、能设计一个最小评测集。社招侧重：线上事故排查、成本账、评估体系设计、多 agent 与子 agent 的边界、沙箱与权限模型、durable execution、轨迹调试工具、把失败模式沉淀成技能或规则的机制。纯框架名词题（LangGraph 有哪些节点类型、最新模型是什么）越来越少，"给你一个故障现象或业务场景，现场设计并说清改哪一层"越来越多。

怎么问才像这个方向的面试官：
- 考"什么归代码什么归模型"的判断与理由，不考框架 API；候选人提到任何框架，追它替你做了什么、你自己写了什么。
- 每道题都要有"怎么验证"和"坏了怎么查"：候选人说了任何机制或优化手段，立刻追评测集、指标、前后对比、失败案例与回归用例。
- 简历上的 RAG / Agent 项目必须深挖到一次真实故障与归因链路；只有 demo 叙事、没有评测环节、没有预算与终止条件的标记为危险信号。
- 结合规模出题：日均几百次调用的项目不问集群调度与多租户，日均百万次的必须追成本账、缓存与降级。
- 不考名词时效：不问"最新模型是什么""某框架新版本改了什么"。
- 岗位 JD 强调 coding agent 体感的，至少一道题问他自己用 agent 翻车的经历。
- 2026 年这个岗位的叫法在收敛为"harness engineering"：提示词怎么写已经是最外层的小事，面试问的是这一次调用模型看到了什么（上下文工程）、循环怎么停、评测怎么进 CI、MCP 工具多了怎么治理。候选人只会谈提示词技巧、没谈过上下文预算与评测门禁的，按浅层处理。

## 项目 / 实习怎么深挖

简历上出现下面这类经历时从哪里切、追什么。追到候选人能说出机制、数字的来源与一次真实的故障或取舍才算实；只有框架名与结论、说不出自己那一段的，记为危险信号。通用的追问方法见 project-deep-dive。

- 简历出现 RAG 项目 → 追检索评测集怎么建、召回率多少、最典型的失败案例和最终归因；答不出评测集的要深挖到底有没有量化过
- 简历出现 Agent 项目 → 追工具数量、终止条件、最长一次跑了多少步、最贵一次花了多少 token、出过什么事故、状态存在哪、能不能从某一步续跑
- 简历出现工具调用 / MCP / function calling → 追工具怎么分级、敏感操作怎么确认、误调过什么工具、错误怎么回给模型
- 简历出现多 agent / 子 agent → 追为什么需要多个而不是一个带工具的 agent、子 agent 的上下文与预算、协作失败时怎么定位是哪一个出错
- 简历出现"提示工程优化" → 追改动前后用什么评测集验证、提示词版本怎么管、换模型时重做了什么
- 简历出现 tracing / 可观测 / debugging 工具 → 追记了哪些事件、能不能按步回放、定位过什么具体故障、p95 延迟与每回合 token
- 简历出现 eval pipeline / 回归检测 / A/B → 追评测集来源、噪声底线、轨迹级指标、一次靠它拦下的坏改动
- 简历出现缓存命中率 / 成本优化 → 追上下文布局、前缀怎么保持稳定、改前改后的命中率与延迟；降本只换便宜模型的要标记
- 简历出现记忆 / 技能 / 渐进式披露 → 追记忆谁写谁读、有没有版本、技能什么时候加载、"给了工具模型不用"遇到过没有
- 简历出现 LangChain / LlamaIndex / LangGraph → 追框架里哪一部分你换掉了或自己写了，为什么
- 简历出现 Claude Code / Codex / Cursor 重度使用 → 追一次翻车经历、怎么发现、工作流改了什么
- 简历出现"准确率 / 成功率提升 X%" → 追指标定义、样本数、是不是自己标的、跑了几次、噪声多大、有没有对照

## 常见失守与危险信号

- Agent 架构与工具调用设计：把 LangGraph / AutoGen 框架名当能力；没有步数、预算、超时任何限制；agent 重复调同一工具、幻觉出不存在的参数没有防护；说不清什么该写成代码流程、什么交给模型
- MCP 与工具生态治理：认为接了 MCP 就万事大吉；工具数量多了选择准确率下降没有对策；没有调用日志
- 上下文工程与缓存：把上下文当"塞得越多越好"；无脑把全部历史塞进去；每回合改系统提示；用摘要压缩却没考虑摘要丢关键实体；不知道自己产品的缓存命中率是多少
- 记忆与技能外化：把"向量库"当记忆的全部答案；模型自由写记忆没有任何校验；技能全文常驻提示词
- 安全、注入与权限：认为"系统提示里写了不要泄露"就够了；没区分输入侧与输出侧护栏；不知道工具返回和检索到的文档也是不可信内容；所有工具一视同仁
- 成本与延迟治理：不知道自己系统每次调用的平均 token 数；降本只想到换便宜模型；没有按功能与用户维度的成本打点
- 人机协作与确认：确认框只有"是 / 否"没有影响范围；拒绝后模型不知道为什么；对话产品里挂起等确认没有超时处理
- 提示工程、结构化输出与多服务商契约：靠"多加一句请务必"解决问题；提示词没有版本、改了不回归；只会"加一句请输出 JSON"；不知道 schema 是否随请求下发；把服务商差异修在每个 agent 里而不是运行时
- 用 coding agent 工作的体感：只有"很好用"或"不靠谱"的笼统评价；没有具体的失败案例；不做审查全盘接受

## 常考主题清单

只列名字、阶梯与答实的标志，作"问到哪一层算实"的参考；问哪些、问几道由这份 JD 与这份简历定，不是配额。

### Agent 架构与工具调用设计
- 阶梯：Agent 和一次 function calling 的差别在哪 → ReAct 循环、工具 schema 设计、状态与记忆怎么组织 → agent 重复调同一工具、死循环、幻觉出不存在的参数怎么防 → 自主性与确定性的边界：什么该写成代码流程，什么交给模型决策
- 答实的标志：工具描述写法对调用准确率的影响；错误结构化返回并让模型可恢复；有终止条件、预算与人工介入点；能举例说明"这一段我用代码写死而不交给模型"

### MCP 与工具生态治理
- 阶梯：MCP 解决什么问题、和自定义工具层的差别 → 工具数量多了之后选择准确率下降怎么处理（分组、按任务挂载、索引 + 按需描述） → 第三方 MCP server 的信任边界：它返回的内容、它声明的权限 → 通用协议接入 vs 自定义工具层的取舍，什么时候不该用 MCP
- 答实的标志：工具子集按任务动态挂载；第三方工具返回当不可信内容；有调用日志与权限审计；能说出一次因工具描述不清导致误调的案例

### 上下文工程与缓存
- 阶梯：上下文窗口大了为什么还要裁剪（中间丢失、成本线性增长、缓存失效）→ 为什么前缀缓存命中率是一等指标（价差与延迟），系统提示整场不变、历史只追加、按块裁剪而不是逐条丢各自对缓存的影响 → 多轮对话历史膨胀后怎么压缩、哪些信息必须保留；工具结果、检索内容、技能全文放哪一层 → 换服务商后缓存与结构化输出行为不同怎么处理
- 答实的标志：能画出"稳定前缀 → 追加历史 → 当回合变动部分"的布局；知道按块裁剪让前缀每长 N 千字才变一次；结构化提取关键实体单独保存而不是只靠摘要；有命中率、每回合 token、p95 延迟三个数

### 记忆与技能外化
- 阶梯：工作记忆（一回合重写的笔记）、会话记忆（事件日志）、跨会话记忆（档案）各放哪一层 → 记忆是模型写还是代码从产物物化，两种做法各自的可信度与成本 → 技能（skills）怎么做渐进式披露：索引常驻、全文按需，谁决定加载 → 记忆有版本与差异的意义：错了怎么回退、怎么看它是怎么变的
- 答实的标志：区分三层记忆与各自的写入方；跨会话记忆是可读写的文档且有版本；技能索引在提示词、全文由工具加载；能说出"给了工具模型不一定用"的经验与对策

### 安全、注入与权限
- 阶梯：prompt injection 与传统注入的区别 → 间接注入（文档、网页、工具返回里藏指令）怎么防 → 敏感信息泄露、越权工具调用的检测与拦截；哪些动作必须人确认（不可逆、外发、花钱）→ 安全护栏的延迟与误拦成本，什么该用模型判断什么该用规则
- 答实的标志：分层防御（输入过滤、工具权限最小化、输出审查、人工确认）；对不可信内容做隔离标记；按动作的可逆性与外发性分级；有红队测试集

### 成本与延迟治理
- 阶梯：一次请求成本由什么构成 → prompt cache、模型路由（小模型先试）、批处理各省哪一段 → 成本突增怎么归因（哪个功能、哪类用户、哪段上下文膨胀）→ 质量、延迟、成本三角的产品级取舍
- 答实的标志：按功能与用户维度打点；系统提示复用命中缓存；路由与降级策略有评测支撑；能算每千 token 成本

### 人机协作与确认
- 阶梯：确认的四种模式（每次问、按类问、dry-run 后问、事后审计）各适合什么 → 对话产品里挂起等确认的用户体验：告诉用户在等什么、超时怎么办 → 人的反馈怎么回到系统：拒绝的原因要不要给模型看 → 自主程度怎么随信任度调（先全确认、再按类放行）
- 答实的标志：确认信息包含影响范围与替代方案；拒绝原因作为工具结果回给模型；有审计日志；能说出一次因确认设计不当造成的事故或摩擦

### 提示工程、结构化输出与多服务商契约
- 阶梯：few-shot 什么时候有效什么时候有害；区分指令、示例、上下文、输出约束四部分 → 结构化输出的可靠手段：schema 约束、JSON mode、收敛、修补、抢救三层各做什么，顺序为什么这样 → 换模型或服务商后同样提示效果大跌、结构化输出就坏（有的按 schema 约束、有的只保证是 JSON）、JSON 模式下不调工具或只吐空白怎么定位 → 提示词版本管理与回归测试；推理型模型的思考 token 算在输出上限里怎么统一处理
- 答实的标志：改提示前后跑固定评测集；能说出按 JSON Schema 收敛类型 → 带校验错误让模型改一次 → 抢救的顺序；输出上限加推理余量；用探针脚本隔离变量；修在统一的调用入口而不是每个 agent 里

### 用 coding agent 工作的体感
- 阶梯：Claude Code / Codex / Cursor 在什么任务上可靠、什么任务上翻车 → 你怎么给它上下文（项目手册、技能、任务拆分）→ 它改错了你怎么发现（测试、diff 审查、轨迹回看）→ "代码是给 AI 和人一起维护的"对你写法的具体影响
- 答实的标志：有具体的翻车案例与归因；有自己的上下文与任务拆分方法；用测试或评测把它的输出关进笼子；能说出为了让 agent 好维护而改的代码习惯