一、基础概念与架构Q1–Q8Q1AI Agent 和传统 Chatbot 的本质区别是什么面试官「先从基础的开始——你做了这么多 Agent 系统你觉得 AI Agent 和一个传统的 Chatbot本质区别到底在哪」高分回答「好这个问题我理解面试官想问的其实不是定义而是边界在哪。我从四个维度来拆。」第一决策模型不同。Chatbot 是『请求-响应』的被动模式——你问一句它答一句每一轮独立对话结束状态清零。Agent 是『目标驱动』的自主决策体——你给它一个目标它自己拆解任务、选择工具、根据中间反馈调整策略形成一个 Think → Act → Observe 的闭环。打个比方Chatbot 是客服接线员Agent 是项目经理。第二工具使用。Chatbot 的核心能力是语言生成它对外部世界的改变最多就是返回一段文本。Agent 的核心能力是『调用工具改变外部世界』——它可以调 API 创建工单、查数据库做决策、操作文件系统、甚至操控浏览器完成一个完整的业务流程。这也是为什么 2026 年 MCP 协议如此关键——它解决了 Agent 与外部工具的标准化连接问题。第三状态与记忆。Chatbot 最多把最近几轮对话塞进上下文窗口。生产级 Agent 需要三层记忆工作记忆是当前任务窗口里的即时上下文短期记忆用 Redis 存会话级状态让用户中断后能恢复长期记忆靠向量数据库 结构化存储实现跨会话的知识积累。这三层缺一层Agent 做不了长周期任务。第四终止条件。Chatbot 输出完就结束了。Agent 需要一个精心设计的终止策略——最大步数硬限制只是保底真正难的是让 LLM 准确判断『任务已完成』、超时熔断的阈值怎么设、以及如何识别 Agent 陷入无效循环后主动中断。这是生产环境里最常见的故障模式——Agent 既不能提前放弃也不能无限烧 token。」「所以总结一下Chatbot LLM 对话界面Agent LLM 自主决策 工具 记忆 循环 终止策略。给 Chatbot 套一个 while 循环不代表就成了 Agent——核心差距在每一步决策的质量和系统对失败的鲁棒性。」Q2Agent 的核心架构包含哪些模块面试官「那你画一下你心中一个生产级 Agent 的系统架构不用真画用语言描述清楚就行。」高分回答「我按六层架构来描述自底向上。」Layer 1 — 模型网关层。这是最底层负责 LLM 的统一接入和路由。包含模型池管理Opus / Sonnet / GPT-5 / DeepSeek / Qwen 混用、智能路由简单任务走便宜模型复杂推理走强模型、以及 fallback 链主模型挂了自动切备选。这一层直接决定成本结构——我们之前做过一个优化把 70% 的简单工具调用从 Opus 路由到 Haiku日均成本下降了 62%任务成功率只降了 2 个百分点。Layer 2 — Agent 运行时引擎。这是 Agent 的『操作系统』管理 Agentic Loop 的完整生命周期。核心包括状态机维护 Agent 的当前状态和状态转换、执行器调度工具调用并收集结果、上下文管理器管理 System Prompt、工具定义、历史消息的注入和裁剪、以及检查点机制每步快照支持暂停/恢复/回溯。Layer 3 — 工具与协议层。这是 Agent 的『手脚』。通过 MCP 协议连接外部工具——文件系统、数据库、API、浏览器等。通过 A2A 协议连接其他 Agent。这一层屏蔽了工具接入的复杂度让上层运行时只需面对统一接口。关键是每个工具要声明自己的能力边界——能做什么、不能做什么、副作用是什么——这样 Agent 才能做出安全的调用决策。Layer 4 — 记忆与知识层。三层记忆架构工作记忆在 Agent 运行时内存中当前任务上下文短期记忆在 Redis/PostgreSQL 中会话级别通常 TTL 24h长期记忆在向量数据库 结构化存储中跨会话持久化。另外还包括 RAG 检索管线——不是简单的『搜一下塞进去』而是 Agent 主动决策『现在需不需要检索、检索什么、检索结果如何验证』。Layer 5 — 安全护栏层。五道防线Pre-input Guard 拦截用户输入中的恶意指令 → Post-retrieval Guard 检查检索到的文档是否被投毒 → Tool-output Guard 校验 MCP 工具返回结果是否包含注入 → Pre-action Guard 对高危操作删库、发邮件、转账要求二次确认 → Post-output Guard 检测输出是否包含有害内容或幻觉。每层延迟控制在 40-200ms全链路不超过 600ms。Layer 6 — 观测与治理层。基于 OpenTelemetry 的全链路 TracingLangSmith/Langfuse 做执行轨迹分析。关键指标包括任务成功率、平均步数、工具调用准确率、Token 消耗、P99 延迟、幻觉率。还要有审计日志满足合规要求——EU AI Act 2026 年对高风险 AI 系统要求 10 年决策记录留存。」「六层架构的核心设计理念是每一层都可独立替换——模型网关可以换模型厂商工具层可以增删 MCP Server护栏层可以升级检测模型——而不影响其他层的运转。」Q3Agentic Loop 的完整流程与终止条件设计面试官「你提到了 Agentic Loop。能不能详细展开——一个完整的 Think → Act → Observe 循环里到底发生了什么以及你怎么设计终止条件」高分回答「Agentic Loop 本质上是一个有状态的决策循环。每一轮迭代包含四个阶段。」第一阶段上下文组装。运行时引擎把 System Prompt、工具定义JSON Schema、历史消息含之前轮次的 Thought-Action-Observation、以及从记忆系统检索到的相关上下文打包成一个完整的 messages 列表注入 LLM。这里有个工程细节——上下文窗口是有限的历史消息不能无限堆积。我们用的是『滑动窗口 摘要压缩』策略最近 N 轮保留完整消息N 通常 5-8更早的轮次用一个小模型做渐进式摘要压缩把 10 轮历史压成一段 200 字的摘要。这样既保留了关键决策脉络又不会撑爆窗口。第二阶段推理与决策Think。LLM 根据当前上下文进行推理决定下一步要做什么。输出可以是调用一个或多个工具并行或串行也可以是给出最终答案。这里有个关键设计我们要求 LLM 以结构化格式输出——不只是 function_call 的 JSON还要包含一个reasoning字段解释为什么要这么做。这个 reasoning 不仅方便调试更是后续 Reflexion 和错误分析的重要输入。第三阶段行动执行Act。运行时引擎解析 LLM 的工具调用请求进行参数校验和安全审查Pre-action Guard然后实际执行工具调用。如果是并行调用比如同时查三个数据源我们用 asyncio.gather 并发执行。执行结果会被包装成 Observation 消息返回。第四阶段观察与决策Observe。工具返回的结果经过 Tool-output Guard 安全扫描后注入到对话上下文中。同时检查是否满足终止条件。如果满足则跳出循环否则回到上下文组装阶段进入下一轮。终止条件我一般设计五层LLM 自主终止— LLM 判断任务已完成并返回最终答案最常见的正常退出路径最大步数限制— 硬保底通常在 15-30 步取决于任务复杂度超时熔断— 从第一轮开始计时超时如 5 分钟强制中断防止无限烧 token循环检测— 对最近 N 步的 Action 序列做指纹比对如果检测到重复模式连续 3 步调用相同工具且返回相同结果判定为死循环强制中断外部中断— 用户主动取消或系统管理员手动中止「实际生产里我一般把这五个条件组成一个优先级链循环检测和超时熔断优先级最高它们是保命机制LLM 自主终止是主路径最大步数是最后兜底。这五个条件缺任何一个你的 Agent 在某个极端 case 下就一定会出问题。」Q4Workflow 编排和 Agent 自主决策的边界面试官「很多人把 Agent 当成万能钥匙什么场景都想用 Agent 自主决策。你觉得 Workflow 编排和 Agent 自主决策的边界在哪什么时候该用哪个」高分回答「这个问题特别好面试官问到了 2026 年 Agent 工程化最核心的判断力问题。」我的核心判断标准就一条流程中的分支数量和可预测性。如果任务的步骤是确定的、分支是有限的、异常路径是可枚举的——用 Workflow。如果任务需要探索性决策、工具选择不确定、中间结果不可预测——用 Agent。具体来说Workflow 适合的场景比如一个客服退款流程——校验订单 → 检查退款条件 → 执行退款 → 发送通知。每一步的逻辑是确定的什么条件走什么分支是已知的异常情况订单不存在、已过退款期、金额超限是有限可枚举的。这种场景用 WorkflowLangGraph 的 StateGraph 或简单的 DAG 引擎最合适——确定性高、可测试、成本可控。一个退款 Workflow 每次都跑 4 步token 消耗是固定的。如果换成 Agent 自主决策它可能在『检查退款条件』这一步反复思考和调用工具烧 15 步才做决定——成本就炸了延迟也差。Agent 适合的场景比如『帮我研究一下竞品 X 最近三个月的产品动态写一份分析报告』。这种任务无法提前枚举所有步骤——你不知道要搜哪些关键词、访问哪些网页、提取哪些信息、如何组织报告结构。Agent 需要在每一步根据当前发现的信息动态调整策略——先搜产品名看结果中有没有相关链接→点进去提取内容→发现提到一个新功能→针对新功能继续深挖。这种探索性任务 Agent 是最佳选择。但在实际生产中最有效的做法是两者混合。比如一个退换货客服系统。主流程用 Workflow 保证确定性身份验证→订单查询→退换货资格判断但当 Workflow 遇到它处理不了的情况比如用户的诉求涉及多种商品的组合退换Workflow 把上下文打包交给一个 Agent子任务去处理。Agent 处理完后再把结果交回 Workflow 继续执行。这就是所谓的『Workflow 为主Agent 兜底』模式。「一个数据我们在实际系统里统计过大约 85% 的用户请求可以通过确定性 Workflow 处理剩下 15% 需要 Agent 的灵活性。如果你把这 15% 也硬写成 Workflow那维护成本是指数级的如果你把 85% 都交给 Agent 自主决策成本和安全风险也是不可接受的。关键就是找到这个边界。」Q5LLM 在 Agent 中扮演什么角色面试官「你觉得 LLM 在 Agent 系统中到底扮演什么角色有很多人说 LLM 就是 Agent 的『大脑』你认同这个类比吗」高分回答「我部分认同『大脑』这个类比但它过于简化了。我倾向于把 Agent 看作一个公司LLM 在其中扮演的是CEO 策略顾问的双重角色。」具体来说LLM 在 Agent 中承担四个核心职能第一推理与决策引擎。这是最核心的角色。LLM 负责分析当前状态、理解任务目标、决定下一步做什么——要不要调用工具、调用哪个工具、传什么参数、如何解读工具返回的结果。这个决策的质量直接决定 Agent 的成败。第二自然语言理解与生成。这是 LLM 的本职——理解用户的模糊意图『帮我看看最近有什么异常』以及把结构化的工具返回结果转化为人类可读的自然语言回复。这个能力目前其他任何技术都无法替代。第三非确定性路由。当 Agent 面对一个请求时它需要判断『这个请求我应该自己处理还是交给某个专门的子 Agent还是走一个确定的 Workflow』。LLM 天然适合做这种基于语义理解的路由决策——比规则引擎灵活得多比传统分类模型泛化能力强得多。第四元认知。这是高级 Agent 的关键能力——LLM 需要自我判断『我是否已经完成了任务』、『我的回答是否有足够把握』、『我是不是陷入了死循环』。Reflexion 和 Self-Critique 机制就是让 LLM 在输出最终答案前再『看一眼自己回答』发现逻辑漏洞或事实错误后自我修正。但 LLM 不是万能的Agent 的能力上限受四个因素制约上下文窗口— LLM 能同时『看见』的信息有限。窗口再大注意力也是稀释的。超过 50 步的复杂任务中间决策质量会显著下降。工具质量— Tools 是 Agent 的眼睛和手。工具 Schema 写得不好、MCP Server 返回格式不一致LLM 再强也没用。这条往往被低估。决策框架— 单靠 LLM 的 raw reasoning 不够。ReAct、Plan-Execute、Reflexion 这些决策框架本质上是在给 LLM 的推理过程加『脚手架』引导它更结构化地思考。模型的固有局限— 幻觉、推理错误、对长尾知识的缺乏。这些不是换个框架就能解决的。「所以我的观点是LLM 是 Agent 的决策核心但一个生产级 Agent 的能力下限由 LLM 决定能力上限由工程架构决定。就好比 CEO 再聪明如果公司的执行系统、信息收集系统和风控系统一塌糊涂公司也做不好。」Q62026 年主流 Agent 框架如何选型面试官「2026 年市面上 Agent 框架已经非常多了——LangGraph、CrewAI、OpenAI Agents SDK、Microsoft Agent Framework。你们在实际项目中是怎么选型的」高分回答「我先给一个前提判断AutoGen 在 2025 年 9 月已经进入维护模式不推荐新项目使用。微软已经把它合并进了新的 Microsoft Agent FrameworkMAF。这是选型的第一步——排除已停止演进的框架。」然后是四个框架的核心差异LangGraph~31k stars核心优势是显式状态图和可恢复执行。它的 StateGraph 模型让你精确控制 Agent 的每一步——节点是什么、边怎么流转、条件分支怎么判断。最 killer 的功能是时间旅行调试——你可以把 Agent 的执行过程回退到任意一步修改状态然后重新执行。对于需要精确控制和高可靠性的场景金融交易、企业审批流程这是首选。代价是学习曲线最陡——你需要理解 StateGraph 的 mental model代码量也比其他框架多。CrewAI~50k stars核心优势是最快的原型到生产速度。它的角色-任务-团队抽象Agent → Task → Crew非常直观——比如『定义三个 AgentResearcher、Writer、Reviewer分配各自的 Task按顺序执行』十几行代码就能跑起来。2026 年的 v1.14 版本新增了 checkpoint/resume 支持。适合团队需要快速验证想法、Agent 数量不多10 个的场景。代价是灵活性不如 LangGraph——对于复杂的分支和条件逻辑CrewAI 的抽象反而会成为限制。OpenAI Agents SDK核心优势是与 OpenAI 生态的最深度整合。它的 Agent、Handoff、Guardrail 三个原语直接映射到 OpenAI 的 API 能力工具调用和 Agent 间交接的延迟最低。如果你的技术栈完全在 OpenAI 上这是最自然的选择。代价是厂商锁定——换模型成本很高。Microsoft Agent Framework~10k stars增长中核心优势是企业级功能完备。它在 AutoGen 的对话模式基础上融合了 Semantic Kernel 的企业特性——内置持久化、可观测性、治理策略。配合 Azure AI Foundry企业可以一键部署。适合深度绑定微软/Azure 技术栈的团队。我的选型决策树需要一个什么样的 Agent 系统 ├── 精确控制 复杂分支 高可靠性 → LangGraph时间旅行调试无敌 ├── 快速验证 简单多 Agent 协作 → CrewAI最快出活 ├── OpenAI 全栈 最小化延迟 → OpenAI Agents SDK ├── 微软/Azure 企业环境 → Microsoft Agent Framework ├── TypeScript/Node.js 技术栈 → MastraTS-first2026 年值得关注 └── 自研决心大 长期投入 → 自研 Harness参考 LangGraph 的 StateGraph 思想「有一点特别重要框架选型的重要性远不如你的观测层选型。框架每 12-18 个月就会迭代一轮但 OpenTelemetry LangSmith/Langfuse 的 Tracing 基础设施应该保持框架无关。换了框架观测数据仍然连续可比——这才是长期工程竞争力的来源。」Q7为什么大厂倾向于自研 Agent Harness面试官「你刚提到自研 Harness。很多大厂确实在自研而不是用 LangChain你怎么看」高分回答「这个问题我体会很深因为我经历过从 LangChain 迁移到自研 Harness 的全过程。核心原因有五个。」第一抽象泄漏问题。LangChain 的 LCELLangChain Expression Language试图把所有东西都抽象成|管道操作但 Agent 的执行流程不是线性的——有分支、有循环、有条件跳转、有异常重试。当你试图用管道语法表达一个带重试和 fallback 的 ReAct Loop 时代码的可读性和可调试性急剧下降。等到你发现需要用RunnableLambda写一大段自定义逻辑时框架的抽象价值已经归零了。第二调试地狱。LangChain 的调用链极深——chain.invoke()进去要过 15-20 层框架内部调用才能到你的实际逻辑。抛一个异常堆栈有 200 行其中 180 行是框架代码。出问题时你花 80% 的时间在框架堆栈里找自己的代码。LangSmith 能缓解部分问题但根本矛盾在于框架越厚调试越难。而 Agent 系统恰恰是最需要快速定位问题的系统。第三版本依赖与碎片化。LangChain 的包拆分策略langchain-core、langchain-community、langgraph、langchain 本身导致版本兼容性问题频发。更新 langgraph 0.3.x 可能导致 langchain-community 的某个工具不可用。在一个 20 微服务的 Agent 系统中版本对齐本身就是一大运维负担。第四最核心的——Agent 的核心逻辑其实并不复杂。如果把 Agentic Loop 的本质抽象出来核心就是一个状态机 上下文管理 工具调度。这三块加起来如果用 Python asyncio Pydantic httpx 手写核心代码可能就 500-800 行。这 800 行你完全掌控没有任何黑盒行为调试时可以精确下断点。LangGraph 本质上就是帮你写了这 800 行——但代价是引入了一个庞大的依赖树和一个你必须学习的 DSL。第五定制化需求。大厂的 Agent 系统通常有一些『非标』需求。比如——你们可能有一个内部的特殊模型路由策略VIP 用户走 Opus普通用户走 Haiku或者一个自定义的安全审查流程在每一步工具调用前要调用内部的风控模型或者需要把 Agent 的状态持久化到公司内部的分布式存储而非简单的 SQLite checkpoint。用 LangGraph你得理解它的内部抽象才能做深度定制。自研的话这些就是最自然的功能扩展。「当然自研也有代价——你们需要自己维护文档、处理 bug、培训新人。我的建议是团队少于 3 个人不要自研用 LangGraph。团队有 5 个资深工程师且有长期 Agent 产品规划自研的长期收益远大于短期成本。」Q8Agent 状态管理 —— 可暂停、可恢复、可回溯面试官「那具体说一下自研 Agent 引擎的状态管理怎么做要做到可暂停、可恢复、可回溯。」高分回答「状态管理是自研 Agent 引擎最难的部分。我借鉴了 LangGraph 的 checkpoint 思想但实现得更轻量。」核心数据结构是 Checkpoint —— 一个包含以下字段的不可变快照dataclassclassCheckpoint:checkpoint_id:str# UUID全局唯一thread_id:str# 会话 IDstep_number:int# 当前是第几步messages:list[Message]# 完整消息历史含 Thought/Action/Observationtool_results:dict# 工具调用结果缓存agent_state:dict# Agent 自定义状态如已收集的用户信息pending_actions:list# 当前步骤待执行的工具调用created_at:float# 时间戳parent_checkpoint_id:str# 父检查点 ID形成链式结构暂停与恢复的机制暂停发生时把当前 Checkpoint 序列化存入 PostgreSQLJSONB 列方便查询 可选的 S3 冷存储用于长期归档。恢复时根据 thread_id 找到最新的 Checkpoint反序列化后恢复到 Agent 运行时。LLM 看到的是完整的消息历史就好像中间没有中断过一样。这里一个关键设计Checkpoint 写入是同步的、在每步工具调用之前执行——哪怕后续的工具调用失败我们至少有一个『调用前』的快照。这避免了『Agent 执行到一半崩了连恢复到哪一步都不知道』的情况。可回溯时间旅行的实现这是 LangGraph 最亮眼的功能我在自研引擎里也实现了精简版。所有 Checkpoint 通过parent_checkpoint_id形成一条链。当你发现 Agent 在 Step 7 做错了决策你可以通过 API 把状态回退到 Step 5 的 Checkpoint修改agent_state中的某个值比如纠正一个错误的事实判断然后从 Step 5 重新开始执行。实现上就是一个简单的数据库查询 状态赋值SELECT*FROMcheckpointsWHEREthread_id$1ANDstep_number$2ORDERBYcreated_atDESCLIMIT1;拿到 Checkpoint 后清空 Step 6 及之后的所有消息把修正后的状态注入然后继续执行 Agentic Loop。生产环境额外需要考虑的点Checkpoint 的大小控制— 消息历史可能非常大100 轮对话 大量工具返回结果。我一般设置消息历史的 soft limit如最近 50 条保留完整更早的做摘要压缩后再序列化控制单个 Checkpoint 在 5MB 以内。并发安全— 同一个 thread_id 不能同时有两个 Agent 在写入 Checkpoint。用 PostgreSQL 的 advisory lock 或 Redis 分布式锁保证。清理策略— 已完成任务的 Checkpoint 保留 7 天用于短期回溯超过 7 天的归档到 S3 冷存储30 天后删除。Checkpoint 的重放验证— 恢复时的状态必须和保存时完全一致。我们会在恢复后做一个轻量校验消息数量、最后一条消息内容 hash确认状态完整性。「总结状态管理的核心就是把 Agent 的每一步拍一个快照用数据库保证持久化和可追溯。代码量不大——核心实现大约 200 行 Python——但每个细节都需要充分考虑边界情况。」