最近翻面经平台AI agent相关的帖子几乎隔几条就能刷到一条“agent是什么”“harness和agent区别”“ai agent怎么扛并发”“agent记忆怎么设计”。这些高频词背后是一大批正在准备agent开发面试的人也是一大批已经被项目逼着上手agent的工程师。我自己的经验是想学会agent开发最好的切入口恰恰就是面经。因为面经是你离“企业真实需求”最近的地方面试官问什么往往就说明企业在用什么、缺什么。这篇文章就用这些高频热词串起一条从零到能落地的agent开发学习路径把概念、架构、框架、记忆、工具调用、并发、安全、沙箱、实操和避坑一次讲透。适合正在准备面试的开发者也适合刚接手agent项目的后端或算法工程师哪怕你是零基础跟着路径走也能建立清晰的知识骨架。1. 先看面经agent开发到底在考什么1.1 高频问题分布企业真正在招什么把近半年的面经热词拉一个清单你会发现高度集中在几个方向方向高频问题背后考察点概念认知agent是什么、agent和普通程序的差别是否真的理解agent的本质而不是背概念架构设计ai agent主流架构、单agent vs 多agent系统设计与场景判断能力框架理解LangGraph、AutoGen、Spring AI、扣子Coze工程落地能力和工具链熟悉度运行时harness和agent区别、agent沙箱、agent scope对执行环境和作用域的理解性能ai agent怎么扛并发生产级思维有没有考虑过线上安全agent安全、沙箱隔离、工具权限风险意识能不能负责任地放agent上线工程细节codex无法发送消息、agent execution terminated due to error是否真正动手跑过还是只刷了文档这个分布很有意思纯概念题占比不高真正的大头是架构、框架、运行时、性能和安全。这说明市场早就过了“什么是agent”的科普期已经进入了“agent怎么稳定落地”的工程期。你如果只会说“agent就是大模型加工具”那大概率过不了第二轮但如果能聊清楚“我这个多agent架构为什么选编排模式而不是自由对话模式”“沙箱挂了怎么恢复”面试官反而会感兴趣。1.2 harness和agent的区别理解agent的执行外壳面经里有一个特别容易劝退新人的问题harness和agent有什么区别我第一次看到也愣了一下因为很多入门教程根本没提过harness这个词。简单说agent是“大脑加手脚”的业务逻辑而harness是装这套逻辑的“外壳”或“运行框架”。你在代码里写的模型调用、工具注册、上下文管理、重试策略、步数上限、沙箱执行都属于harness层的事情。换句话说同一个agent核心逻辑换一个harness可能表现完全不同。我用一个类比agent像是司机harness像是车。司机知道怎么踩油门打方向盘但车提供仪表盘、安全气囊、刹车辅助和限速逻辑。你问“harness和agent区别”面试官真正想听的是你知不知道agent不是凭空跑起来的它需要一个执行环境来约束、监控和兜底。实际项目里harness负责的往往是那些不出彩但极其重要的破事——比如模型返回格式不对时怎么重试、工具调用超时了怎么降级、上下文超出窗口时怎么截断。这些细节决定了agent在线上能不能活下来。1.3 一张技能地图直接当学习清单用我根据自己的项目和面试复盘整理了一张agent开发的技能地图优先级从高到低技能优先级说明大模型API调用必学基础中的基础OpenAI、Claude、国产模型都行提示词工程必学控制agent行为的最直接手段工具调用 / Function Calling必学让agent能行动的钥匙记忆设计高频面试几乎必问短期记忆和长期记忆要分清主流框架必学至少深耕一个LangGraph、AutoGen、扣子、Spring AI沙箱与安全进阶企业级落地刚需并发与性能进阶扛住生产流量的关键多agent与编排进阶区分初中高级的分水岭评测集构建进阶没有评测的agent就是玄学这张地图建议直接打印出来当学习清单学到哪勾到哪。后面几个小节我会把地图上最重要的节点展开讲。2. 搞懂agent内核原理与主流架构怎么选2.1 用“顾问配手脚”理解agent的本质很多人把agent理解得太玄。我用一个生活化类比普通的大模型调用相当于你雇了一个只动嘴的顾问你问一句他答一句他永远不会主动去查资料、不会动手做事agent相当于给这个顾问配了手和脚让他能查网页、敲代码、操作软件、调用内部系统最终把一个需要多步骤才能完成的任务跑完。技术上说agent 大模型大脑 规划决定先做什么后做什么 工具调用执行动作 记忆记住上下文和中间结果 环境反馈观察执行结果。核心循环永远是这样接收任务 - 模型决策下一步 - 调用工具或生成回复 - 观察结果 - 再次决策 - 直到任务完成这个循环里最容易被新手忽略的是“观察结果”这一步。很多人写agent只写了“调用工具”没写“把工具结果喂回给模型”结果agent永远在重复同一个错误动作。记住agent的本质是一个闭环不是一串单向调用。2.2 三大架构模式ReAct、Plan-and-Execute、多agent面经里问“ai agent主流架构”本质上是在问你对三种模式的掌握程度。ReAct模式Reasoning Acting边思考边行动。模型每走一步都先推理“我现在该做什么”然后调工具看到结果再推理下一步。优点是灵活适合探索性任务缺点是步骤多时容易失控、token消耗大。入门第一个agent建议用ReAct因为逻辑最直观。Plan-and-Execute模式先让模型把任务拆成一个计划列表然后按计划逐步执行执行完再汇总。优点是可控、省token适合流程清晰的场景比如定时报表生成、批量数据处理缺点是一旦计划有漏洞后面的步骤全崩。多agent协作模式不再是一个agent单打独斗而是多个agent各司其职比如一个负责拆解任务、一个负责写代码、一个负责审查、一个负责总结。多agent的编排方式又分两种一种是“编排者-执行者”模式有一个主agent调度其他agent另一种是“自由对话”模式多个agent互相协商。我的实际经验是自由对话模式看起来很酷但线上很容易跑偏生产环境优先用编排者模式至少有一个主agent在控制全局。还有个热词叫“agent框架与编排”其实就是讲这个。面试时你如果能说出“单agent适合目标明确的工具型任务多agent适合可并行或需要多角色协作的复杂任务”就已经超过大部分候选人了。2.3 框架选型对比LangGraph、AutoGen、Spring AI、扣子框架这块面经里出现频率最高的几个我列个表框架语言特点适合场景LangGraphPython图结构编排状态管理强可控性好复杂流程、多agent编排AutoGenPython多agent对话灵活研究属性强原型验证、多角色协作Semantic KernelC# / Python微软系企业集成友好.NET技术栈团队Spring AIJavaJava生态和Spring Boot无缝集成传统Java后端团队做agent扣子Coze低代码可视化编排内置大量插件快速上线业务智能体ADKadk.devPython / KotlinGoogle出品支持JVMKotlin可以快速在JVM上跑通agent多语言团队、JVM环境Hermes AgentPython轻量灵活可接入Obsidian等知识库个人知识库、本地工具型agent选型建议很简单如果你做的是企业级Java项目别硬上Python用Spring AI最省事我见过一个团队用Spring AI把agent接进了已有订单系统两天就出了内部demo如果你做的是复杂流程编排LangGraph的可控性远好过裸写循环如果你只想快速验证业务逻辑扣子这类低代码平台是最快的先把业务跑通再考虑自研。有个热词叫“基于rust语言ai agent”这个方向正在起来因为Rust的性能和内存安全特性很适合做agent运行时但生态还在早期我个人建议是主力语言还没精通前不要为了追热点去用Rust写agent先跑通业务再说。3. 逐项攻克关键技术点记忆、工具、沙箱、并发3.1 Function Calling让agent真正“动手”的关键面经里问“agent开发需要学什么”我第一个回答永远是Function Calling工具调用。没有工具调用agent只是加强版聊天机器人。Function Calling的原理一句话就能讲清楚你在API请求里声明“有哪些工具每个工具的参数长什么样”模型根据用户请求决定“这次调用哪个工具、参数是什么”然后由你的代码真正执行这个工具把结果返回给模型继续生成回复。关键点在于模型只是“决定调用”真正执行是“你的代码”所以工具函数的实现质量直接决定agent的效果。举个简单例子给agent加一个网页抓取工具from openai import OpenAI client OpenAI() tools [ { type: function, function: { name: fetch_webpage, description: 抓取指定网页并提取正文内容, parameters: { type: object, properties: { url: {type: string, description: 网页完整地址} }, required: [url] } } } ] def fetch_webpage(url: str) - str: # 实际实现请求网页并提取正文这里省略细节 return 网页正文内容... resp client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 帮我看看这篇文章讲了什么}], toolstools, ) # 判断模型是否请求调用工具 if resp.choices[0].message.tool_calls: tool_call resp.choices[0].message.tool_calls[0] if tool_call.function.name fetch_webpage: url json.loads(tool_call.function.arguments)[url] result fetch_webpage(url) print(result)这个例子里有三件事要注意第一工具的description一定要写清楚“什么时候该用这个工具”模型靠这个做选择第二参数定义要严格用JSON Schema语法参数名别缩写模型对模糊命名理解很差第三工具返回结果一定不要超过模型上下文限制太长的结果要截断或摘要否则下一次请求直接爆上下文。有人会问“agent skills”是什么可以把它理解为“可复用的工具包封装”。比如“将网页保存成markdown的skill”本质就是把“抓网页、转markdown、存文件”这几个动作封装成一个标准化的工具agent遇到相关需求时自动调用。学会封装skill是提高agent复用能力的关键一步。3.2 记忆设计上下文窗口装不下的部分怎么办“agent记忆”在面经里出现频率非常高因为这是工程上最绕不开的瓶颈。大模型上下文窗口是有限的哪怕号称百万token也不可能无限塞历史。记忆可以分三层短期记忆就是当前对话的上下文。你每次把历史消息塞给模型就是在用短期记忆。工程上要处理的是“怎么塞”是全量塞、截断塞还是摘要塞。我的实践是最近几轮全量保留更早的做摘要压缩两者拼在一起给模型。长期记忆跨会话保留的用户偏好、事实数据存在数据库或文件里需要时检索出来注入提示词。最简单的实现就是建一张表key是用户ID或会话IDvalue是记忆条目每次对话前查出来拼进system prompt。外部记忆向量数据库。当记忆量很大时用embedding把历史内容向量化需要时做相似度检索把最相关的片段取出来。这个方案适合“知识库问答型agent”。面试时我建议你主动说一个实践细节记忆一定要带“时间戳”和“来源”。否则模型很容易把过期记忆当成当前事实。我在项目里就踩过这个坑——agent一直推荐一个已经下架的活动查了半天发现是三天前的记忆还躺在长期记忆里。3.3 沙箱与安全代码执行必须隔离“agent安全”和“agent沙箱”是面经热词里特别能区分水平的两块。问法通常是“agent要执行代码你怎么保证安全”答案的核心就两个字隔离。agent生成的代码、调用的shell命令、下载的文件都不能直接跑在你的生产环境里。常见做法是用容器做隔离给每个任务起一个独立的沙箱容器限制网络、限制磁盘、限制CPU和内存任务结束后销毁。Docker是最常用的隔离手段Kubernetes可以管大规模沙箱集群。实操层面的注意点容器里禁止挂载宿主机的敏感目录比如/etc、/root/.ssh给沙箱配独立的网络策略至少要禁止访问内网元数据服务设定内存和CPU上限防止agent写了个死循环把宿主机拖垮沙箱镜像要定期更新依赖有漏洞就需要重建工具权限最小化一个agent只需要读文件就绝不给它删除权限有个热词叫“codex无法发送消息显示更新agent沙盒”我遇到过类似的场景。这类报错通常说明沙箱运行环境过期或状态异常常见排查路径是先看沙箱容器是否还活着再看沙箱镜像是否需要更新三看当前会话的沙箱目录是否被误删或权限不对。我有一回就是本地磁盘满了导致沙箱创建失败清理磁盘后就好了。遇到这类问题别慌按“环境-镜像-权限-资源”四个方向排查基本都能解决。3.4 并发与性能ai agent怎么扛住生产流量“ai agent怎么扛并发”是面经里最硬核的问题之一也是很多从没上线过agent的开发者最心虚的问题。我说说自己的做法。agent本质上是一个“慢”系统单次执行可能需要几十秒甚至几分钟因为它要多次调用模型、多次执行工具。所以扛并发不能像普通HTTP接口那样只盯着QPS要从架构上分层处理第一层任务队列化。用户请求不直接同步跑完而是先进入消息队列Redis Stream、RabbitMQ、Kafka都行后台Worker从队列里取任务执行。这样即使同时来100个请求也不会把模型API打爆。第二层模型调用限流与重试。给每个模型供应商的API配好速率限制超过限制就退避重试。这里有个关键参数重试要用指数退避重试次数的上限要设置防止雪崩。第三层超时控制与降级。agent的每一步都要有超时时间工具调用超过30秒就返回“工具超时”让模型换一种方式继续。整个agent也要有总步数上限比如最多跑20步防止死循环。第四层异步通知。任务跑完后通过Webhook或WebSocket通知前端。这是用户体验最好的方案。面试时如果能说出“agent不适合同步阻塞式接口应该用任务队列异步回调”面试官基本就会认定你有生产经验。顺便说一句如果你看到“agent anywhere”这种概念它指的其实是agent执行环境从云端扩展到本地和边缘的趋势这也意味着并发架构要考虑混合环境但核心思路不变队列、限流、超时、异步。3.5 多模态扩展agent画图与多模态输入“agent画图”是另一类高频需求。这里要区分两种一种是agent调用绘图API比如让模型生成图片一种是agent操作绘图软件比如控制设计工具自动出图。前者实现简单prompt里描述清楚风格、构图就行后者更像“操作型agent”本质还是工具调用只是把“画图软件”封装成了工具接口。我的建议是做画图agent先把“图片生成结果如何返回”设计好。是返回URL、返回本地路径还是返回base64这直接影响后续是展示、存储还是继续加工。实际项目里我通常让画图agent先把图生成到沙箱指定目录然后由harness统一处理文件持久化再回传一个可访问的文件URL。这样图片内容不会撑爆模型上下文也方便后续做图集管理。多模态输入同理如果agent需要看图回答问题先让模型描述图片内容再进入决策循环比直接把图片塞进每次请求要省token得多。4. 实操从零搭一个“网页转Markdown”的agent4.1 需求拆解为什么选这个场景理论讲再多不如动手跑一个。我选择“将网页保存成markdown的skill”这个场景有三个原因第一它完整覆盖了agent的核心链路——模型决策、工具调用、结果处理、文件持久化第二网页抓取结果不可控特别能锻炼“结果异常时模型怎么处理”的思维第三这个能力在知识库搭建、资料整理场景里非常实用做完不会白做。需求拆解成三步给定一个URLagent判断需要调用网页抓取工具工具抓取网页并转换为markdown把markdown保存到指定目录返回保存路径。4.2 工具选型与运行环境配置我用Python LangGraph来实现理由是这个组合的可控性好、教程多、调试方便。如果团队是Java技术栈用Spring AI的ChatClient加工具注册也能实现同样效果想快速验证的话扣子平台自带“网页抓取”插件十分钟就能搭完。这里我讲代码方案。环境准备pip install langgraph langchain-openai trafilatura我用trafilatura做网页正文提取因为它在“网页转干净文本/HTML/markdown”这个活儿上效果比requests加正则靠谱得多能自动去掉导航、广告、版权这些噪音。4.3 核心实现一个最小可跑的agent循环先定义一个工具函数负责抓网页并转markdownimport json import trafilatura from langchain_core.tools import tool tool def webpage_to_markdown(url: str, output_dir: str ./downloaded) - str: 抓取指定网页并转换为markdown文件保存返回保存路径。 适合在用户提供链接并要求保存网页内容时使用。 downloaded trafilatura.fetch_url(url) content trafilatura.extract(downloaded, output_formatmarkdown) if not content: return 抓取失败网页无正文内容 import os os.makedirs(output_dir, exist_okTrue) file_name url.split(//)[-1].replace(/, _)[:80] .md file_path os.path.join(output_dir, file_name) with open(file_path, w, encodingutf-8) as f: f.write(content) return f已保存到 {file_path}全文共 {len(content)} 字然后组装成agentfrom langgraph.prebuilt import create_react_agent from langchain_openai import ChatOpenAI model ChatOpenAI(modelgpt-4o, temperature0) tools [webpage_to_markdown] agent create_react_agent(modelmodel, toolstools) result agent.invoke({ messages: [{role: user, content: 把 https://example.com/article 这篇网页保存成markdown文件}] }) print(result[messages][-1].content)create_react_agent是LangGraph里现成的ReAct模式封装它会自动处理“模型决定调工具 - 执行工具 - 结果回填 - 继续决策”的循环。第一次跑通这个例子你就已经完成了一个真正的agent而不是一个聊天机器人。4.4 迭代调优让agent更稳的细节跑通只是开始上线前有几件事必须做给agent加步数上限和超时create_react_agent可以传recursion_limit参数我一般设20步防止模型反复尝试同一个失败工具。处理抓取失败的情况很多网页是JS渲染的trafilatura抓不到内容。我通常会再加一个“调用浏览器渲染”的工具作为备选一个不行就换另一个agent会自己尝试。加内容长度限制网页正文可能非常长超过模型上下文就会报错。工具返回前先截断或摘要让模型拿到的永远是“够用但不超限”的内容。验证保存结果让agent在保存后读一下文件头确认不是空文件。这个“验证环节”能省掉大量返工。还有一个非常实用的技巧把整个流程封装成一个标准化skill命名规范、描述清楚、参数明确以后任何会话里用户说“帮我保存一下这个网页”agent都能自动调用。这就是“agent skill教程”里反复强调的复用思想——把一次性的代码变成可复用的能力。5. 高频报错与面试坑位实录5.1 常见报错排查codex、execution terminated、沙盒更新我把实际开发中和面经里最常出现的几个报错整理成速查表报错现象常见原因排查方向agent execution terminated due to erroragent循环中某一步抛异常且未被harness捕获查看harness日志定位是模型层还是工具层给工具加try/except统一返回错误信息codex无法发送消息显示更新agent沙盒沙箱环境过期、磁盘不足、会话目录异常检查沙箱容器状态、镜像版本、磁盘空间、会话目录权限工具调用超时网络问题或工具本身执行慢缩短工具超时时间并让模型感知到“超时即失败”引导换方案上下文超长工具返回结果过大工具结果做截断/摘要历史消息压缩模型反复调用同一个失败工具错误信息不够具体模型不知道为何失败工具报错信息要写清原因比如“403无权限”而不是“失败”agent跑偏不按计划执行提示词约束不足、plan步骤过粗system prompt里明确输出格式和检查清单计划步骤拆细不夸张地说这些报错里我踩过至少一半。印象最深的是“agent execution terminated due to error”——在本地跑得好好的一上容器就崩最后发现是容器里没装工具依赖工具代码import直接失败了。从那以后我所有的agent工具函数都统一包一层错误捕获任何异常都转成一句明确的中文错误说明返回给模型。模型拿到“缺依赖”和拿到“异常”的反应是完全不同的前者它会尝试别的方式后者它只会懵。5.2 面试答题的正确姿势面经看得多的人容易犯一个毛病背术语。比如问“agent是什么”回答“agent是大语言模型驱动的自主智能体”这句话没错但没有任何信息量。面试官想听的是你的理解框架。我总结了一个三段式答题法实测效果很好第一段一句话定义。agent是“能感知环境、做出决策、执行动作并观察反馈的闭环系统”。第二段拆解要素。把定义拆成模型、规划、工具、记忆、反馈五个部分每个部分一句话说清楚“对应什么技术”。第三段举一个自己的实践。哪怕是一个很小的项目把“模型决策-工具调用-结果反馈”跑一遍的细节说出来比背十个概念都管用。比如被问“agent怎么扛并发”不要上来就背术语。你可以说我在某项目里直接用同步调用结果20个用户同时触发就把token额度打爆了后来改成任务队列加异步回调限流重试加超时控制才稳下来。这个“踩坑-改进”的故事比任何标准答案都有说服力。5.3 避坑清单我踩过你就别踩了最后分享几条独家避坑经验都是常规文档里不会写的不要把工具描述写成“调用这个函数”要写“在用户要求做某事时使用”。模型靠描述决定何时调用描述写得像API注释模型就容易乱调或不调。工具数量不是越多越好。我实测过工具超过10个模型选错工具的概率明显上升。能合并的工具尽量合并用参数区分行为。给agent起一个“角色人设”。system prompt里明确的角色定位比如“你是一名资深软件工程师助手”比没有角色定位时回答质量稳定得多。评测一定要有。这就是“agent评测集构建”为什么越来越火的原因。我给每个agent都建一个小评测集几十条典型输入加上预期输出每次改prompt就跑一遍通过率低于90%就不允许上线。没有评测集的agent就像没有测试用例的代码改一次崩一次。版本记录prompt。prompt改了以后agent行为变化经常是隐性的今天正常明天抽风。把prompt当成代码版本管理每次改动都留档出问题能快速回滚。6. 学习路线与我的个人体会6.1 分阶段的agent开发学习路线如果你是从零开始我建议按这个节奏走三个月基本能从小白到能独立上手项目第一阶段第1-2周打基础。学会调大模型API搞懂system/user/assistant消息结构掌握基本的提示词工程。目标能用API稳定完成一个带格式约束的问答。同时把“agent是什么”“爱agent和普通程序的区别”这类概念问题彻底想清楚。第二阶段第3-4周做第一个工具型agent。选一个简单场景比如“查天气”“算薪资”“保存网页”用Function Calling实现“模型决定调用工具-代码执行-结果返回”的最小闭环。这一阶段必须亲手跑通至少一个带工具调用的项目面经里的报错一半以上会在这时候遇到遇到一个解决一个。第三阶段第5-8周项目实战与框架选型。用LangGraph或你团队的技术栈做一个完整场景加上记忆、多轮对话、任务队列。重点练两件事一是结构化怎么拆解任务二是工具结果怎么处理和校验。可以尝试加一个“网页转markdown”“让小红书自动发消息”这类更完整的自动化项目把agent从“回答问题”推向“完成任务”。第四阶段第9-12周进阶与面试准备。研究多agent编排、沙箱安全、并发架构、评测集构建。用面经里的高频问题做自测每一个问题都要求自己能用“定义拆解实践案例”三段式回答。同时把你做过的项目整理成有数据、有结论的实践总结这是面试时最能拉开差距的东西。6.2 关于实操和面经最后说几句真心话我个人在实际操作中的体会是面经最大的价值不是让你背答案而是帮你发现“哪些问题我自己根本答不上来”。每次看到一条面经热词不用急着搜答案先停下来问自己这个问题我在项目里遇到过吗我当时的解决方案是什么如果答不上来说明这个知识板块是空的补上它而不是收藏它。另外agent开发和传统后端开发有一个很大的思维差异传统开发追求“确定性”同样的输入必须同样的输出agent开发要接受“概率性”同样的输入可能每次结果都不同。所以你不能只写逻辑还要设计“当模型行为不符合预期时系统怎么兜底”。这正是harness、沙箱、评测集存在的意义。理解了这一点你就不是在用写接口的思路做agent而是真正在做agent的工程化了。最后再分享一个小技巧开始学agent之前把你自己的学习过程也当成一个agent项目来管理——明确目标、拆分步骤、每步收集反馈、定期复盘。用学agent的方式学agent效率会高很多。祝你顺利跑通自己的第一个agent然后把踩过的坑变成下一次面试里的加分故事。 
长河君 · 2026/10/6 5:46:42 · 阅读 1.2k AI Agent开发进阶指南：从面试热词到企业级落地实战
最近翻面经平台AI agent相关的帖子几乎隔几条就能刷到一条“agent是什么”“harness和agent区别”“ai agent怎么扛并发”“agent记忆怎么设计”。这些高频词背后是一大批正在准备agent开发面试的人也是一大批已经被项目逼着上手agent的工程师。我自己的经验是想学会agent开发最好的切入口恰恰就是面经。因为面经是你离“企业真实需求”最近的地方面试官问什么往往就说明企业在用什么、缺什么。这篇文章就用这些高频热词串起一条从零到能落地的agent开发学习路径把概念、架构、框架、记忆、工具调用、并发、安全、沙箱、实操和避坑一次讲透。适合正在准备面试的开发者也适合刚接手agent项目的后端或算法工程师哪怕你是零基础跟着路径走也能建立清晰的知识骨架。1. 先看面经agent开发到底在考什么1.1 高频问题分布企业真正在招什么把近半年的面经热词拉一个清单你会发现高度集中在几个方向方向高频问题背后考察点概念认知agent是什么、agent和普通程序的差别是否真的理解agent的本质而不是背概念架构设计ai agent主流架构、单agent vs 多agent系统设计与场景判断能力框架理解LangGraph、AutoGen、Spring AI、扣子Coze工程落地能力和工具链熟悉度运行时harness和agent区别、agent沙箱、agent scope对执行环境和作用域的理解性能ai agent怎么扛并发生产级思维有没有考虑过线上安全agent安全、沙箱隔离、工具权限风险意识能不能负责任地放agent上线工程细节codex无法发送消息、agent execution terminated due to error是否真正动手跑过还是只刷了文档这个分布很有意思纯概念题占比不高真正的大头是架构、框架、运行时、性能和安全。这说明市场早就过了“什么是agent”的科普期已经进入了“agent怎么稳定落地”的工程期。你如果只会说“agent就是大模型加工具”那大概率过不了第二轮但如果能聊清楚“我这个多agent架构为什么选编排模式而不是自由对话模式”“沙箱挂了怎么恢复”面试官反而会感兴趣。1.2 harness和agent的区别理解agent的执行外壳面经里有一个特别容易劝退新人的问题harness和agent有什么区别我第一次看到也愣了一下因为很多入门教程根本没提过harness这个词。简单说agent是“大脑加手脚”的业务逻辑而harness是装这套逻辑的“外壳”或“运行框架”。你在代码里写的模型调用、工具注册、上下文管理、重试策略、步数上限、沙箱执行都属于harness层的事情。换句话说同一个agent核心逻辑换一个harness可能表现完全不同。我用一个类比agent像是司机harness像是车。司机知道怎么踩油门打方向盘但车提供仪表盘、安全气囊、刹车辅助和限速逻辑。你问“harness和agent区别”面试官真正想听的是你知不知道agent不是凭空跑起来的它需要一个执行环境来约束、监控和兜底。实际项目里harness负责的往往是那些不出彩但极其重要的破事——比如模型返回格式不对时怎么重试、工具调用超时了怎么降级、上下文超出窗口时怎么截断。这些细节决定了agent在线上能不能活下来。1.3 一张技能地图直接当学习清单用我根据自己的项目和面试复盘整理了一张agent开发的技能地图优先级从高到低技能优先级说明大模型API调用必学基础中的基础OpenAI、Claude、国产模型都行提示词工程必学控制agent行为的最直接手段工具调用 / Function Calling必学让agent能行动的钥匙记忆设计高频面试几乎必问短期记忆和长期记忆要分清主流框架必学至少深耕一个LangGraph、AutoGen、扣子、Spring AI沙箱与安全进阶企业级落地刚需并发与性能进阶扛住生产流量的关键多agent与编排进阶区分初中高级的分水岭评测集构建进阶没有评测的agent就是玄学这张地图建议直接打印出来当学习清单学到哪勾到哪。后面几个小节我会把地图上最重要的节点展开讲。2. 搞懂agent内核原理与主流架构怎么选2.1 用“顾问配手脚”理解agent的本质很多人把agent理解得太玄。我用一个生活化类比普通的大模型调用相当于你雇了一个只动嘴的顾问你问一句他答一句他永远不会主动去查资料、不会动手做事agent相当于给这个顾问配了手和脚让他能查网页、敲代码、操作软件、调用内部系统最终把一个需要多步骤才能完成的任务跑完。技术上说agent 大模型大脑 规划决定先做什么后做什么 工具调用执行动作 记忆记住上下文和中间结果 环境反馈观察执行结果。核心循环永远是这样接收任务 - 模型决策下一步 - 调用工具或生成回复 - 观察结果 - 再次决策 - 直到任务完成这个循环里最容易被新手忽略的是“观察结果”这一步。很多人写agent只写了“调用工具”没写“把工具结果喂回给模型”结果agent永远在重复同一个错误动作。记住agent的本质是一个闭环不是一串单向调用。2.2 三大架构模式ReAct、Plan-and-Execute、多agent面经里问“ai agent主流架构”本质上是在问你对三种模式的掌握程度。ReAct模式Reasoning Acting边思考边行动。模型每走一步都先推理“我现在该做什么”然后调工具看到结果再推理下一步。优点是灵活适合探索性任务缺点是步骤多时容易失控、token消耗大。入门第一个agent建议用ReAct因为逻辑最直观。Plan-and-Execute模式先让模型把任务拆成一个计划列表然后按计划逐步执行执行完再汇总。优点是可控、省token适合流程清晰的场景比如定时报表生成、批量数据处理缺点是一旦计划有漏洞后面的步骤全崩。多agent协作模式不再是一个agent单打独斗而是多个agent各司其职比如一个负责拆解任务、一个负责写代码、一个负责审查、一个负责总结。多agent的编排方式又分两种一种是“编排者-执行者”模式有一个主agent调度其他agent另一种是“自由对话”模式多个agent互相协商。我的实际经验是自由对话模式看起来很酷但线上很容易跑偏生产环境优先用编排者模式至少有一个主agent在控制全局。还有个热词叫“agent框架与编排”其实就是讲这个。面试时你如果能说出“单agent适合目标明确的工具型任务多agent适合可并行或需要多角色协作的复杂任务”就已经超过大部分候选人了。2.3 框架选型对比LangGraph、AutoGen、Spring AI、扣子框架这块面经里出现频率最高的几个我列个表框架语言特点适合场景LangGraphPython图结构编排状态管理强可控性好复杂流程、多agent编排AutoGenPython多agent对话灵活研究属性强原型验证、多角色协作Semantic KernelC# / Python微软系企业集成友好.NET技术栈团队Spring AIJavaJava生态和Spring Boot无缝集成传统Java后端团队做agent扣子Coze低代码可视化编排内置大量插件快速上线业务智能体ADKadk.devPython / KotlinGoogle出品支持JVMKotlin可以快速在JVM上跑通agent多语言团队、JVM环境Hermes AgentPython轻量灵活可接入Obsidian等知识库个人知识库、本地工具型agent选型建议很简单如果你做的是企业级Java项目别硬上Python用Spring AI最省事我见过一个团队用Spring AI把agent接进了已有订单系统两天就出了内部demo如果你做的是复杂流程编排LangGraph的可控性远好过裸写循环如果你只想快速验证业务逻辑扣子这类低代码平台是最快的先把业务跑通再考虑自研。有个热词叫“基于rust语言ai agent”这个方向正在起来因为Rust的性能和内存安全特性很适合做agent运行时但生态还在早期我个人建议是主力语言还没精通前不要为了追热点去用Rust写agent先跑通业务再说。3. 逐项攻克关键技术点记忆、工具、沙箱、并发3.1 Function Calling让agent真正“动手”的关键面经里问“agent开发需要学什么”我第一个回答永远是Function Calling工具调用。没有工具调用agent只是加强版聊天机器人。Function Calling的原理一句话就能讲清楚你在API请求里声明“有哪些工具每个工具的参数长什么样”模型根据用户请求决定“这次调用哪个工具、参数是什么”然后由你的代码真正执行这个工具把结果返回给模型继续生成回复。关键点在于模型只是“决定调用”真正执行是“你的代码”所以工具函数的实现质量直接决定agent的效果。举个简单例子给agent加一个网页抓取工具from openai import OpenAI client OpenAI() tools [ { type: function, function: { name: fetch_webpage, description: 抓取指定网页并提取正文内容, parameters: { type: object, properties: { url: {type: string, description: 网页完整地址} }, required: [url] } } } ] def fetch_webpage(url: str) - str: # 实际实现请求网页并提取正文这里省略细节 return 网页正文内容... resp client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 帮我看看这篇文章讲了什么}], toolstools, ) # 判断模型是否请求调用工具 if resp.choices[0].message.tool_calls: tool_call resp.choices[0].message.tool_calls[0] if tool_call.function.name fetch_webpage: url json.loads(tool_call.function.arguments)[url] result fetch_webpage(url) print(result)这个例子里有三件事要注意第一工具的description一定要写清楚“什么时候该用这个工具”模型靠这个做选择第二参数定义要严格用JSON Schema语法参数名别缩写模型对模糊命名理解很差第三工具返回结果一定不要超过模型上下文限制太长的结果要截断或摘要否则下一次请求直接爆上下文。有人会问“agent skills”是什么可以把它理解为“可复用的工具包封装”。比如“将网页保存成markdown的skill”本质就是把“抓网页、转markdown、存文件”这几个动作封装成一个标准化的工具agent遇到相关需求时自动调用。学会封装skill是提高agent复用能力的关键一步。3.2 记忆设计上下文窗口装不下的部分怎么办“agent记忆”在面经里出现频率非常高因为这是工程上最绕不开的瓶颈。大模型上下文窗口是有限的哪怕号称百万token也不可能无限塞历史。记忆可以分三层短期记忆就是当前对话的上下文。你每次把历史消息塞给模型就是在用短期记忆。工程上要处理的是“怎么塞”是全量塞、截断塞还是摘要塞。我的实践是最近几轮全量保留更早的做摘要压缩两者拼在一起给模型。长期记忆跨会话保留的用户偏好、事实数据存在数据库或文件里需要时检索出来注入提示词。最简单的实现就是建一张表key是用户ID或会话IDvalue是记忆条目每次对话前查出来拼进system prompt。外部记忆向量数据库。当记忆量很大时用embedding把历史内容向量化需要时做相似度检索把最相关的片段取出来。这个方案适合“知识库问答型agent”。面试时我建议你主动说一个实践细节记忆一定要带“时间戳”和“来源”。否则模型很容易把过期记忆当成当前事实。我在项目里就踩过这个坑——agent一直推荐一个已经下架的活动查了半天发现是三天前的记忆还躺在长期记忆里。3.3 沙箱与安全代码执行必须隔离“agent安全”和“agent沙箱”是面经热词里特别能区分水平的两块。问法通常是“agent要执行代码你怎么保证安全”答案的核心就两个字隔离。agent生成的代码、调用的shell命令、下载的文件都不能直接跑在你的生产环境里。常见做法是用容器做隔离给每个任务起一个独立的沙箱容器限制网络、限制磁盘、限制CPU和内存任务结束后销毁。Docker是最常用的隔离手段Kubernetes可以管大规模沙箱集群。实操层面的注意点容器里禁止挂载宿主机的敏感目录比如/etc、/root/.ssh给沙箱配独立的网络策略至少要禁止访问内网元数据服务设定内存和CPU上限防止agent写了个死循环把宿主机拖垮沙箱镜像要定期更新依赖有漏洞就需要重建工具权限最小化一个agent只需要读文件就绝不给它删除权限有个热词叫“codex无法发送消息显示更新agent沙盒”我遇到过类似的场景。这类报错通常说明沙箱运行环境过期或状态异常常见排查路径是先看沙箱容器是否还活着再看沙箱镜像是否需要更新三看当前会话的沙箱目录是否被误删或权限不对。我有一回就是本地磁盘满了导致沙箱创建失败清理磁盘后就好了。遇到这类问题别慌按“环境-镜像-权限-资源”四个方向排查基本都能解决。3.4 并发与性能ai agent怎么扛住生产流量“ai agent怎么扛并发”是面经里最硬核的问题之一也是很多从没上线过agent的开发者最心虚的问题。我说说自己的做法。agent本质上是一个“慢”系统单次执行可能需要几十秒甚至几分钟因为它要多次调用模型、多次执行工具。所以扛并发不能像普通HTTP接口那样只盯着QPS要从架构上分层处理第一层任务队列化。用户请求不直接同步跑完而是先进入消息队列Redis Stream、RabbitMQ、Kafka都行后台Worker从队列里取任务执行。这样即使同时来100个请求也不会把模型API打爆。第二层模型调用限流与重试。给每个模型供应商的API配好速率限制超过限制就退避重试。这里有个关键参数重试要用指数退避重试次数的上限要设置防止雪崩。第三层超时控制与降级。agent的每一步都要有超时时间工具调用超过30秒就返回“工具超时”让模型换一种方式继续。整个agent也要有总步数上限比如最多跑20步防止死循环。第四层异步通知。任务跑完后通过Webhook或WebSocket通知前端。这是用户体验最好的方案。面试时如果能说出“agent不适合同步阻塞式接口应该用任务队列异步回调”面试官基本就会认定你有生产经验。顺便说一句如果你看到“agent anywhere”这种概念它指的其实是agent执行环境从云端扩展到本地和边缘的趋势这也意味着并发架构要考虑混合环境但核心思路不变队列、限流、超时、异步。3.5 多模态扩展agent画图与多模态输入“agent画图”是另一类高频需求。这里要区分两种一种是agent调用绘图API比如让模型生成图片一种是agent操作绘图软件比如控制设计工具自动出图。前者实现简单prompt里描述清楚风格、构图就行后者更像“操作型agent”本质还是工具调用只是把“画图软件”封装成了工具接口。我的建议是做画图agent先把“图片生成结果如何返回”设计好。是返回URL、返回本地路径还是返回base64这直接影响后续是展示、存储还是继续加工。实际项目里我通常让画图agent先把图生成到沙箱指定目录然后由harness统一处理文件持久化再回传一个可访问的文件URL。这样图片内容不会撑爆模型上下文也方便后续做图集管理。多模态输入同理如果agent需要看图回答问题先让模型描述图片内容再进入决策循环比直接把图片塞进每次请求要省token得多。4. 实操从零搭一个“网页转Markdown”的agent4.1 需求拆解为什么选这个场景理论讲再多不如动手跑一个。我选择“将网页保存成markdown的skill”这个场景有三个原因第一它完整覆盖了agent的核心链路——模型决策、工具调用、结果处理、文件持久化第二网页抓取结果不可控特别能锻炼“结果异常时模型怎么处理”的思维第三这个能力在知识库搭建、资料整理场景里非常实用做完不会白做。需求拆解成三步给定一个URLagent判断需要调用网页抓取工具工具抓取网页并转换为markdown把markdown保存到指定目录返回保存路径。4.2 工具选型与运行环境配置我用Python LangGraph来实现理由是这个组合的可控性好、教程多、调试方便。如果团队是Java技术栈用Spring AI的ChatClient加工具注册也能实现同样效果想快速验证的话扣子平台自带“网页抓取”插件十分钟就能搭完。这里我讲代码方案。环境准备pip install langgraph langchain-openai trafilatura我用trafilatura做网页正文提取因为它在“网页转干净文本/HTML/markdown”这个活儿上效果比requests加正则靠谱得多能自动去掉导航、广告、版权这些噪音。4.3 核心实现一个最小可跑的agent循环先定义一个工具函数负责抓网页并转markdownimport json import trafilatura from langchain_core.tools import tool tool def webpage_to_markdown(url: str, output_dir: str ./downloaded) - str: 抓取指定网页并转换为markdown文件保存返回保存路径。 适合在用户提供链接并要求保存网页内容时使用。 downloaded trafilatura.fetch_url(url) content trafilatura.extract(downloaded, output_formatmarkdown) if not content: return 抓取失败网页无正文内容 import os os.makedirs(output_dir, exist_okTrue) file_name url.split(//)[-1].replace(/, _)[:80] .md file_path os.path.join(output_dir, file_name) with open(file_path, w, encodingutf-8) as f: f.write(content) return f已保存到 {file_path}全文共 {len(content)} 字然后组装成agentfrom langgraph.prebuilt import create_react_agent from langchain_openai import ChatOpenAI model ChatOpenAI(modelgpt-4o, temperature0) tools [webpage_to_markdown] agent create_react_agent(modelmodel, toolstools) result agent.invoke({ messages: [{role: user, content: 把 https://example.com/article 这篇网页保存成markdown文件}] }) print(result[messages][-1].content)create_react_agent是LangGraph里现成的ReAct模式封装它会自动处理“模型决定调工具 - 执行工具 - 结果回填 - 继续决策”的循环。第一次跑通这个例子你就已经完成了一个真正的agent而不是一个聊天机器人。4.4 迭代调优让agent更稳的细节跑通只是开始上线前有几件事必须做给agent加步数上限和超时create_react_agent可以传recursion_limit参数我一般设20步防止模型反复尝试同一个失败工具。处理抓取失败的情况很多网页是JS渲染的trafilatura抓不到内容。我通常会再加一个“调用浏览器渲染”的工具作为备选一个不行就换另一个agent会自己尝试。加内容长度限制网页正文可能非常长超过模型上下文就会报错。工具返回前先截断或摘要让模型拿到的永远是“够用但不超限”的内容。验证保存结果让agent在保存后读一下文件头确认不是空文件。这个“验证环节”能省掉大量返工。还有一个非常实用的技巧把整个流程封装成一个标准化skill命名规范、描述清楚、参数明确以后任何会话里用户说“帮我保存一下这个网页”agent都能自动调用。这就是“agent skill教程”里反复强调的复用思想——把一次性的代码变成可复用的能力。5. 高频报错与面试坑位实录5.1 常见报错排查codex、execution terminated、沙盒更新我把实际开发中和面经里最常出现的几个报错整理成速查表报错现象常见原因排查方向agent execution terminated due to erroragent循环中某一步抛异常且未被harness捕获查看harness日志定位是模型层还是工具层给工具加try/except统一返回错误信息codex无法发送消息显示更新agent沙盒沙箱环境过期、磁盘不足、会话目录异常检查沙箱容器状态、镜像版本、磁盘空间、会话目录权限工具调用超时网络问题或工具本身执行慢缩短工具超时时间并让模型感知到“超时即失败”引导换方案上下文超长工具返回结果过大工具结果做截断/摘要历史消息压缩模型反复调用同一个失败工具错误信息不够具体模型不知道为何失败工具报错信息要写清原因比如“403无权限”而不是“失败”agent跑偏不按计划执行提示词约束不足、plan步骤过粗system prompt里明确输出格式和检查清单计划步骤拆细不夸张地说这些报错里我踩过至少一半。印象最深的是“agent execution terminated due to error”——在本地跑得好好的一上容器就崩最后发现是容器里没装工具依赖工具代码import直接失败了。从那以后我所有的agent工具函数都统一包一层错误捕获任何异常都转成一句明确的中文错误说明返回给模型。模型拿到“缺依赖”和拿到“异常”的反应是完全不同的前者它会尝试别的方式后者它只会懵。5.2 面试答题的正确姿势面经看得多的人容易犯一个毛病背术语。比如问“agent是什么”回答“agent是大语言模型驱动的自主智能体”这句话没错但没有任何信息量。面试官想听的是你的理解框架。我总结了一个三段式答题法实测效果很好第一段一句话定义。agent是“能感知环境、做出决策、执行动作并观察反馈的闭环系统”。第二段拆解要素。把定义拆成模型、规划、工具、记忆、反馈五个部分每个部分一句话说清楚“对应什么技术”。第三段举一个自己的实践。哪怕是一个很小的项目把“模型决策-工具调用-结果反馈”跑一遍的细节说出来比背十个概念都管用。比如被问“agent怎么扛并发”不要上来就背术语。你可以说我在某项目里直接用同步调用结果20个用户同时触发就把token额度打爆了后来改成任务队列加异步回调限流重试加超时控制才稳下来。这个“踩坑-改进”的故事比任何标准答案都有说服力。5.3 避坑清单我踩过你就别踩了最后分享几条独家避坑经验都是常规文档里不会写的不要把工具描述写成“调用这个函数”要写“在用户要求做某事时使用”。模型靠描述决定何时调用描述写得像API注释模型就容易乱调或不调。工具数量不是越多越好。我实测过工具超过10个模型选错工具的概率明显上升。能合并的工具尽量合并用参数区分行为。给agent起一个“角色人设”。system prompt里明确的角色定位比如“你是一名资深软件工程师助手”比没有角色定位时回答质量稳定得多。评测一定要有。这就是“agent评测集构建”为什么越来越火的原因。我给每个agent都建一个小评测集几十条典型输入加上预期输出每次改prompt就跑一遍通过率低于90%就不允许上线。没有评测集的agent就像没有测试用例的代码改一次崩一次。版本记录prompt。prompt改了以后agent行为变化经常是隐性的今天正常明天抽风。把prompt当成代码版本管理每次改动都留档出问题能快速回滚。6. 学习路线与我的个人体会6.1 分阶段的agent开发学习路线如果你是从零开始我建议按这个节奏走三个月基本能从小白到能独立上手项目第一阶段第1-2周打基础。学会调大模型API搞懂system/user/assistant消息结构掌握基本的提示词工程。目标能用API稳定完成一个带格式约束的问答。同时把“agent是什么”“爱agent和普通程序的区别”这类概念问题彻底想清楚。第二阶段第3-4周做第一个工具型agent。选一个简单场景比如“查天气”“算薪资”“保存网页”用Function Calling实现“模型决定调用工具-代码执行-结果返回”的最小闭环。这一阶段必须亲手跑通至少一个带工具调用的项目面经里的报错一半以上会在这时候遇到遇到一个解决一个。第三阶段第5-8周项目实战与框架选型。用LangGraph或你团队的技术栈做一个完整场景加上记忆、多轮对话、任务队列。重点练两件事一是结构化怎么拆解任务二是工具结果怎么处理和校验。可以尝试加一个“网页转markdown”“让小红书自动发消息”这类更完整的自动化项目把agent从“回答问题”推向“完成任务”。第四阶段第9-12周进阶与面试准备。研究多agent编排、沙箱安全、并发架构、评测集构建。用面经里的高频问题做自测每一个问题都要求自己能用“定义拆解实践案例”三段式回答。同时把你做过的项目整理成有数据、有结论的实践总结这是面试时最能拉开差距的东西。6.2 关于实操和面经最后说几句真心话我个人在实际操作中的体会是面经最大的价值不是让你背答案而是帮你发现“哪些问题我自己根本答不上来”。每次看到一条面经热词不用急着搜答案先停下来问自己这个问题我在项目里遇到过吗我当时的解决方案是什么如果答不上来说明这个知识板块是空的补上它而不是收藏它。另外agent开发和传统后端开发有一个很大的思维差异传统开发追求“确定性”同样的输入必须同样的输出agent开发要接受“概率性”同样的输入可能每次结果都不同。所以你不能只写逻辑还要设计“当模型行为不符合预期时系统怎么兜底”。这正是harness、沙箱、评测集存在的意义。理解了这一点你就不是在用写接口的思路做agent而是真正在做agent的工程化了。最后再分享一个小技巧开始学agent之前把你自己的学习过程也当成一个agent项目来管理——明确目标、拆分步骤、每步收集反馈、定期复盘。用学agent的方式学agent效率会高很多。祝你顺利跑通自己的第一个agent然后把踩过的坑变成下一次面试里的加分故事。