很早前写的那条 RAG 面试贴,这两天又开始有不少互动刷上来了。最近 Agent 招聘也明显升温,面试考察方向也逐渐清晰,是时候认真聊聊这块了。
我发现这个现象不但没有改善,反而更加明显。
因为 Agent 系统相比 RAG 更复杂,表面看起来只是“多个工具 + 几个大模型”的组合,
但底层其实要求的是对系统调度、上下文结构、推理链路、状态管控、模型行为边界的全面理解和工程性判断。
直白一点,Agent 的真正难度,在于能不能让它在稳定、连续的前提下,支撑起真实业务流程的正确性、可追溯性、可控性。
我这段时间在参与一些 Agent 岗位的面试,逐渐形成了一些判断候选人是否优秀的锚点(未必每项都要完全掌握,但能否系统思考、举一反三,是判断力的关键):
比如,是否能清晰区分并解释常见 Agent 设计模式的适用场景?
ReAct、CodeAct、Agentic RAG、Self-Reflection、Multi-Agent Planner,它们之间有哪些本质差异?又分别适合处理什么样的任务?有没有在实际项目中做过切换?有没有踩过错误选型的坑?
有没有理解 AutoGPT-style 与 Planner-style 的核心区别?是否意识到 Reflective Agent 模式会对链路结构带来怎样的影响?
在构建的 Agent 中,是否考虑过多 Agent 并发执行时的任务拆分、冲突协调、上下文隔离与结果融合策略?
是否设计过 DAG 式的任务调度流程?支持中断恢复吗?任务失败是否能精准回滚?在异步执行中有没有遇到 race condition 或状态错乱的问题,又是如何通过调度/隔离机制解决的?
当你说“挂了 memory”,你指的是哪种 memory?
是 scratchpad 式的上下文补全?embedding + search 的 semantic memory?还是具备写入、更新、清理能力的长期记忆系统?
有没有遇到 memory 与 tool 同时干扰上下文的情况?你是如何控制污染与冗余的——靠 prompt 工程?cache?embedding 过滤?还是独立的 memory controller?
有没有了解过 agentic memory、KV-based long-term memory 这样的记忆结构演进趋势?
还有,tools 是怎么注入的?
是静态 schema 定义?还是基于 LLM 推理的动态注册?
参数是 prompt 拼的,还是通过 structured output 与工具接口 schema 自动对齐?
工具调用失败时怎么处理?是否设计过 fallback 策略、调用优先级、输出结构比对?有没有构建过 tool selector 或工具路由模块,而非手动拼接?
调的是工具,还是构建了一套可插拔、可配置的工具执行系统?这本质不同。
现实问题也不能回避:有没有上线过 Agent 系统?
它的性能瓶颈出现在哪?token 消耗高?memory 检索慢?工具调用链路太长?
做过 tracing 吗?有没有用过 LangSmith、PromptLayer、OpenAgentMonitor 做链路诊断?
能不能说出“你的 Agent 为什么慢”,又是怎么让它变快的?
最后,是安全性与合规性。
在多 Agent 系统中,你没有考虑过 prompt 注入、数据越权、token 滥用、权限划分、执行日志?
是否设计过访问边界?有没有审计能力?是否能把 Agent 控制在业务授权范围内?
这些,才是现在企业在面试 Agent 工程岗位时真正关注的能力维度,候选人能不能设计一个有行为边界、结构清晰、状态稳定、可容错、能上线的智能系统。