4年AI Agent工程师面试复盘：10倍扩展时LangGraph、MCP与背压的崩溃点

AI Agent工程师这个岗位到底在做什么？一场模拟中级技术面试的播客给出了相当接地气的答案：大量工作其实是工具可靠性与状态管理——不断确认"Agent是否真的做了我们以为它做的事"。当一个Agent连续调用5个工具时，其中任何一个静默失败或陷入循环，都会烧掉token、烧掉钱。

这篇复盘以一位拥有4年经验、近两年专注于LangGraph、CrewAI与MCP（Model Context Protocol）的工程师Saket的面试为主线，拆解了生产级Agent系统在规模扩张时真正会崩溃的地方。正如面试官所言，没人能假装自己从2019年就在构建Agent系统，真正有价值的生产模式是近两年才沉淀下来的。

LangGraph的节点与边：静默失败从哪里漏掉

LangGraph中多步Agent的核心区别在于节点（node）与边（edge）。节点是工具实际执行的地方——调用API、解析响应、更新状态的Python代码；边则是执行之后的决策点，它查看工具返回了什么，决定是调用下一个工具、回环还是退出。

这个区分之所以关键，是因为当工具3静默失败时，节点本身可能不会崩溃。但如果边的条件没有检查状态中的失败信号，系统就会若无其事地路由到工具4，在错误数据上继续推进。排查token账单时，真正该看的不是每个节点是否运行，而是边条件是否在步骤之间校验了状态——边有没有检查工具返回错误？有没有检查响应是否为空？通常缺失的正是这类校验。

关于如何在账单爆表前发现循环，Saket的答案很诚实：第一次在生产环境遇到循环，正是从账单仪表盘发现的——这是最糟糕的起点。之后团队给Agent状态加了步数计数器，每次节点执行就发射一个指标，单次图运行超过约40步就触发告警。40这个数字来自一周运行的合法步数P99的大约2倍——最复杂的合法工作流大概16步，40步既留了余量又不至于频繁误报。

阈值法的失效边界

阈值告警也有盲区。如果新工作流合法需要50步而没人更新阈值，团队会被误报淹没，进而开始忽略告警。更隐蔽的是"慢循环"——Agent在两个看似合法的状态间每30分钟振荡一次，单会话永远碰不到40步，却能跨会话无限运行。对这种情况，需要的是另一类信号：每任务的墙钟时间预算，而非单纯的步数。

LangGraph是LangChain团队推出的有状态、多Actor应用构建框架，底层以有向图（DAG或带环图）建模Agent工作流。与直接链式调用LLM不同，LangGraph将每次工具调用或推理步骤封装为图中的节点，节点之间的路由逻辑由边承载。框架的核心抽象是"状态"（State）——一个在整个图运行生命周期内被节点读写的共享字典。每个节点接收当前状态、执行操作后返回状态更新；边则根据状态内容决定下一步跳转到哪个节点，或是否终止图运行。这种设计使得多步Agent可以在节点间传递上下文，但也意味着状态污染会像多米诺骨牌一样传播——一个工具将错误信息写入状态后，后续所有节点和边条件都会基于这个被污染的状态做判断。

MCP协议下的超时与循环放大

在MCP中，Agent通过JSON-RPC向工具服务器发送结构化调用请求，服务器本应返回结果对象。超时发生时，Agent运行时收到什么取决于传输超时的配置：未配置则Agent永久挂起等待；配置了则框架层抛出异常。

危险之处在于，很多LangGraph工具节点实现会捕获异常后静默重试，或把错误字符串塞进Agent状态。一旦"tool returned error connection timeout"进入状态，LLM看到后可能决定重试，再超时，再重试——循环形成，每次迭代都在烧token、冲击工具服务器。Saket团队就在一个第三方数据增强工具因负载变慢时踩过这个坑。

架构层面的修复有两层：一是"每节点工具调用预算"，每个工具节点跟踪特定工具在当前图运行中的调用次数，超限则返回结构化失败而非再次调用；二是在MCP传输层加入熔断器逻辑，当工具服务器错误率超阈值就断开电路、快速失败。后者是更重要的修复，因为它能普遍抵御第三方的不稳定性。

MCP（Model Context Protocol）是Anthropic于2024年末提出并开源的开放协议，旨在标准化LLM应用与外部工具、数据源之间的通信接口。其设计思路类似LSP（Language Server Protocol）之于代码编辑器：工具提供方实现MCP Server，Agent运行时作为MCP Client，双方通过JSON-RPC 2.0协议交换消息。MCP定义了三类能力：Tools（Agent可调用的函数）、Resources（Agent可读取的数据）和Prompts（可复用的提示模板）。传输层支持本地stdio和远程HTTP+SSE两种模式。MCP的价值在于解耦——同一工具服务器可被不同Agent框架复用，而不必为LangGraph、AutoGen等各写一套集成代码。然而这层抽象也带来了额外的网络边界：超时、连接中断、服务端错误都发生在框架可见性之外，若客户端未做妥善的错误处理，失败信号便会以难以追踪的方式渗入Agent状态。

从200到2000并发：什么会最先崩溃

当系统从200并发图运行扩展到2000时，第一个崩溃的是检查点（checkpointing）层。LangGraph用checkpointer在节点执行之间持久化状态，若后端是数据库，远在触及LLM速率限制之前就会先撞上连接池耗尽或写入争用。

这种争用的诊断信号很有特征：检查点写操作的P99延迟爬升，节点执行时间开始膨胀，但节点代码本身很快、LLM调用也很快——"图运行看着慢，但LLM调用很快"的错配。Saket团队在约600并发时就命中过这个版本，花了不少时间才意识到瓶颈是Postgres写延迟而非Agent逻辑。

第二个崩溃点是工具服务器容量。从200到2000图运行，每个运行可能多次调用工具，工具请求量可轻松增长10到20倍。问题出在很多团队用CPU做自动扩展——而工具服务器处理网页搜索、数据库查询、API调用，大部分时间在等待I/O，CPU很低而请求队列却在堆积。自动扩展器看到低CPU判断"不需要扩容"，等CPU真正飙升时损害已经造成。正确的信号是请求队列深度或活跃连接数。切换到基于队列深度的自动扩展后，扩展响应的滞后从大约3分钟降到了约30秒。

LangGraph的Checkpointer机制是其支持长时运行、可中断恢复工作流的关键。每当图中一个节点完成执行，框架会将当前完整状态序列化后写入持久化后端（官方支持PostgreSQL、SQLite及内存存储），记录"线程"（thread）维度的执行快照。这样即使进程崩溃，图运行也可从最后一个检查点续跑，而非从头开始。检查点的写入频率与节点执行频率完全一致——一个20步的工作流会触发至少20次状态写入。在低并发时这几乎无感知，但在高并发场景下，每个并发图运行都在争抢数据库连接和写入锁，写延迟迅速成为整条链路的瓶颈。Postgres的连接池上限（通常默认100）往往早于LLM API速率限制被突破，而连接等待时间会直接叠加进每个节点的表观执行时间，制造出"Agent变慢但LLM调用本身很快"的诊断迷雾。

多Agent内存与死锁的真实信号

在一个监督Agent协调研究员、编码员、审查员三个子Agent的场景里，有三种内存设计模式：共享状态（简单但并发写冲突、状态对象膨胀）、消息传递（黑板模式，避免写冲突但需要监督者显式聚合与超时处理）、外部内存（卸载到向量库或KV存储，支持最长任务但增加检索延迟且有陈旧检索的正确性风险）。

消息传递模式的真实死锁案例出现在代码审查流水线：编码员等审查员批准上一个diff才生成下一个，审查员等编码员产出完整文件才审查。编码员只产出了部分文件，审查员的验收标准要求完整文件——两个Agent都卡在等待态占着执行池槽位。因为有10分钟超时，这不是操作系统意义上的真死锁，但10分钟已足够让多对Agent同时卡住，饿死新任务进入系统。症状是吞吐骤降而队列里仍有工作：活跃图运行高、每分钟完成数趋近于零。"高活跃、低完成"的错配如今成了专门监控的告警。

背压如何贯穿整条流水线

当Kafka主题给LangGraph执行器池喂任务，而上游LLM因速率限制在节流时，朴素实现根本不传播背压：消费者继续拉取，执行器池继续启动新图运行，这些运行撞上限制后变成一堆失败或重试的运行占着执行器槽位，而队列不断增长。

修复方式是让消费者感知执行器池压力——在执行器前放一个信号量，消费者只有拿到信号量槽位才提交Kafka消息并启动图运行。所有槽位占满时消费者暂停轮询，让Kafka消费滞后增长，这就是向上游传递的背压信号。此外加入显式的LLM速率限制检测：收到429就释放信号量槽位、以指数退避把消息退回队列，并临时降低信号量上限，让消费者主动减速而非持续冲击限制。背压正常工作时，滞后平滑上升并趋于平稳；失效时滞后陡升且持续攀爬，因为系统在空转重试而无实际进展。尝试启动数与成功完成数的比值能告诉你身处哪种情形。

背压（Backpressure）是流式处理系统中的核心流控概念，指下游消费者向上游生产者传递"我已饱和，请减速"信号的机制。在Kafka架构中，消费者拉取消息的速率默认由消费者自身控制，Kafka Broker本身不主动限速。这意味着如果消费者不主动暂停轮询，即使下游处理能力已耗尽，消息依然会被持续拉取并堆积在消费者本地缓冲区，最终导致OOM或大量任务在启动后立即失败。信号量（Semaphore）是实现应用层背压最直接的工具：用一个计数器表示可用的处理槽位，拿到槽位才能消费消息，槽位耗尽则阻塞拉取。这与操作系统中的资源限制原理相同，但发生在业务逻辑层，可以根据LLM速率限制等动态信号实时调整信号量上限，从而实现细粒度的自适应流控，而非单纯依赖重试来消化过载压力。

一次没有告警的成本激增事故

复盘中最精彩的是一场模拟事故：周四上午，Agent都成功完成，但每完成任务的成本在90分钟内翻了三倍，没有告警、日志无错误，只有LLM仪表盘显示token消耗偏高。

正确的第一步是看token消耗拆分——输入token正常，输出token约为基线2.5倍，这指向Agent每次任务做了更多工具调用。确认手段是查每图运行的步数计数器：平均步数从11跳到28，搜索工具的调用从每次运行2次升到7次。接下来的判断顺序很关键：先查部署变更而非分析搜索结果质量，因为部署历史是最快能确认的。结果发现当天早上有一次搜索工具服务器的"提升结果多样性"更新——多样化的结果个体相关性更低，触发Agent的"检索直到信息充分"判断反复进入。

回滚前的验证动作同样体现成熟度：用特性开关把约10%流量路由到旧版本，观察15分钟的平均步数与输出token，确认回滚修复的是根因而非症状。初级工程师会去追的"红鲱鱼"正是LLM仪表盘上的token激增——那是症状，不是原因，token激增是Agent行为变化的下游。

架构层面的修复是给工具服务器部署流水线加一道"Agent行为门"：上线前用代表性任务样本跑新版本，对比平均步数、各工具调用频率与任务完成率，若平均步数增幅超过约20%则阻断部署、需人工签字。这道门的失效模式也被诚实指出——若评估样本不能代表生产查询分布，或评估集随时间老化，门会漏掉本该拦截的问题。

从面试里能学到什么

这场对话给出了判断一名合格Agent工程师的清晰标尺。强信号是诊断方法论正确：观测优先、不臆断、从症状反向追溯根因；队列深度与背压思维明显来自真实负载下的运维；工具调用预算与熔断器模式只有撞过限制的人才会提。弱信号则在于对A2A（Agent-to-Agent协议）停留在评估阶段、成本分析依赖估算而非实际支出数据。

面试官最终的点评值得记住：到四年中级这个层级，最常见的失败模式是把故障当成假设而非真正调试并学到教训的经历。而区分中级与资深/staff的，是能否在事故发生前就设计观测策略、能否为某些组件争取专门的监控预算并在内部推动落地。这正是"2026年一名可信的四年期Agent工程师"该有的样子——不是假装做了十年，而是真正带着系统走过真实的失败模式，并知道下次该监控和防御什么。