很早前写的那条 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 工程岗位时真正关注的能力维度，候选人能不能设计一个有行为边界、结构清晰、状态稳定、可容错、能上线的智能系统。