1. 为什么“从面经开始”反而是学 Agent 开发的一条捷径很多人一听到“Agent 开发”这四个字第一反应是去啃论文、翻官方文档、从零搭一个 ReAct 循环。我一开始也是这么干的结果两周下来脑子里全是概念手上一个能跑的东西都没有。后来我换了个思路——从面经倒着学。面经里反复出现的那些问题其实就是这个领域真正的核心考点也是实际开发中最容易踩坑的地方。你顺着这些问题去补学到的不是“知识”而是“能干活的能力”。这个思路的本质是以输出倒逼输入。面经问题天然带着筛选属性能出现在面试里的一定是被行业反复验证过的关键点。比如“Agent 和 Workflow 的区别是什么”“工具调用失败怎么处理”“多轮对话里怎么管理上下文”这些问题背后对应的都是真实工程里绕不开的坎。你带着问题去学效率比漫无目的地读文档高得多。这篇文章适合三类人一是想转行做 Agent 开发但不知道从哪下手的初学者二是已经会调 API 但一写复杂逻辑就乱的开发者三是准备面试、想把零散知识串成体系的人。我会把面经里高频出现的考点拆开配上我实际写代码时的思路、参数选择和踩过的坑尽量让你看完就能动手复现。需要先说明一点Agent 开发这个方向变化很快不同团队的技术栈差异也大。我下面讲的是基于常见工程实践总结出来的一套通用打法不是唯一解但能帮你建立一个稳定的起点。2. 面经高频考点拆解与背后的真实需求2.1 Agent 到底是什么别被定义绕晕面经里第一个高频问题就是“你怎么理解 Agent”。标准答案通常会提到“感知、决策、行动”三要素或者搬出“自主性、反应性、社会性”这类学术定义。但面试官真正想听的是你有没有把它和普通程序区分开的能力。我的理解很朴素普通程序是你写死流程Agent 是它自己决定下一步做什么。你给它一个目标它自己拆解、自己选工具、自己判断什么时候停。这里的关键词是“自己决定”。一旦你承认这一点就会立刻意识到两个工程难题第一它怎么知道有哪些工具可用第二它怎么保证不跑偏。这两个问题几乎贯穿了所有 Agent 开发的核心工作。所以我在实际项目里从来不把 Agent 当成一个“更聪明的函数”而是当成一个需要约束的自主执行体。约束的手段包括工具描述要写清楚、系统提示词要限定边界、循环次数要设上限、关键节点要加人工确认。这些手段在面经里往往以“你怎么保证 Agent 稳定性”的形式出现本质是同一个问题。2.2 Agent 与 Workflow 的边界什么时候该用哪个这是面经里区分度很高的一道题。很多人答“Agent 更灵活Workflow 更可控”这话没错但太浅。我实际做项目时的判断标准是流程是否可枚举。如果一件事的步骤是固定的比如“收到邮件→提取关键信息→写入表格→发送通知”那这就是 Workflow用代码串起来最稳别硬套 Agent。反过来如果步骤取决于中间结果比如“根据用户问题决定查数据库还是查文档查完再决定要不要二次检索”这种分支无法提前写死才轮到 Agent 上场。我踩过的一个坑是早期为了“显得高级”把一个本来很固定的数据处理流程做成了 Agent结果它每次选的工具顺序都不一样调试成本翻倍最后又改回了 Workflow。所以我的经验是——能用 Workflow 解决的就别用 AgentAgent 是用来处理不确定性的不是用来炫技的。面经里问这个其实是在筛你有没有工程判断力。2.3 工具调用Agent 的手和脚工具调用是 Agent 开发里最核心也最容易出问题的环节。面经里常问“你怎么设计工具”“工具调用失败怎么办”。我先说设计。工具的本质是给模型一个它能理解的接口。这里有个反直觉的点工具的功能实现得好不好往往不是最关键的工具的描述写得好不好才是。模型是根据你给的名称、描述、参数说明来决定调不调的。我见过太多人把工具描述写成“查询数据”模型根本不知道查什么数据、什么时候该查。正确的写法应该像给新人写说明书“根据用户提供的订单号查询订单状态返回状态码和预计送达时间适用于用户询问物流进度时”。参数设计也有讲究。能用枚举就别用自由文本能拆成多个小工具就别做一个万能工具。我一般会把工具控制在 5 到 10 个之间太多了模型容易选错太少了又不够用。下面这张表是我总结的工具设计检查清单检查项合格标准常见错误工具名称动词名词语义明确用 query、do 这种模糊词功能描述说明用途、适用场景、返回内容只写一句“查询信息”参数定义类型明确枚举优先全用 string不给取值范围错误处理返回结构化错误信息直接抛异常或返回空数量控制单轮可用工具 5-10 个一次性塞几十个工具2.4 上下文管理Agent 的记忆难题面经里“多轮对话怎么管理上下文”几乎是必问。这个问题的难点在于模型的上下文窗口是有限的而 Agent 执行任务时产生的中间信息又特别多。你不可能把所有历史都塞进去那样既贵又慢还会让模型抓不住重点。我的做法是分层管理。第一层是系统提示词放角色设定和硬性规则这部分永远保留。第二层是任务状态用一个结构化的对象记录当前目标、已完成步骤、待办事项每次调用时序列化进去。第三层是原始对话历史只保留最近若干轮更早的做摘要压缩。这样既控制了 token 消耗又保证了关键信息不丢。这里有个实操技巧摘要不要用模型生成尽量用规则提取。比如把“已完成的工具调用及结果”直接结构化存下来比让模型写一段自然语言摘要更可靠也更省 token。模型摘要容易丢细节还可能引入幻觉。这个点在面经里很少被问到但实际项目里非常关键。3. 从零搭一个最小可用 Agent 的完整实操3.1 环境准备与技术选型先说选型。语言我用 Python生态最全。模型接口层我建议先直接用官方 SDK别一上来就上框架。原因很简单框架会帮你隐藏很多细节而学 Agent 开发恰恰要理解这些细节。等你把裸调 API 的流程跑通了再上框架提效也不迟。依赖方面最小集合是模型 SDK、一个 HTTP 请求库、一个用于校验参数的工具库。如果你要做检索类 Agent再加一个向量库。我个人的习惯是先用最少的依赖把主流程跑通遇到重复劳动再抽象。目录结构我一般这样组织agent-demo/ ├── main.py # 入口负责循环调度 ├── tools.py # 工具定义与实现 ├── memory.py # 上下文管理 ├── config.py # 模型参数、提示词 └── requirements.txt这个结构的好处是职责清晰。main 只管循环tools 只管工具memory 只管状态。后面要换模型、加工具、改记忆策略都只动一个文件。3.2 核心循环的实现思路Agent 的核心就是一个循环把当前状态发给模型 → 模型返回动作 → 执行动作 → 把结果塞回状态 → 再发给模型。听起来简单但每一步都有细节。第一步构造请求。系统提示词里要写清楚你是一个 Agent可以用哪些工具什么时候该结束。结束条件一定要明确比如“当你认为任务完成时调用 finish 工具并给出最终答案”。没有明确的结束信号模型可能无限循环。第二步解析模型返回。模型可能返回文本也可能返回工具调用请求。你要判断如果是工具调用就执行如果是纯文本且没有结束信号就把它当作中间思考继续循环。第三步执行工具。这里必须加异常捕获和超时控制。工具可能报错、可能卡住不能让整个 Agent 挂掉。我的做法是给每个工具调用包一层出错就返回结构化的错误信息给模型让它自己决定重试还是换方案。第四步更新状态。把工具结果追加到消息列表同时更新任务状态对象。然后检查循环次数超过上限就强制结束返回当前最好结果。下面是一个简化的循环骨架重点看注释里的判断逻辑def run_agent(user_input, max_steps10): messages build_initial_messages(user_input) state {goal: user_input, steps: [], done: False} for step in range(max_steps): response call_model(messages, toolsTOOL_SCHEMAS) if response.has_tool_call: tool_name response.tool_name tool_args response.tool_args # 关键工具执行必须包异常 try: result execute_tool(tool_name, tool_args) except Exception as e: result {error: str(e), hint: 请检查参数或换用其他工具} messages.append(response.raw) messages.append(build_tool_result(tool_name, result)) state[steps].append({tool: tool_name, result: result}) if tool_name finish: state[done] True break else: # 纯文本当作思考过程继续 messages.append(response.raw) return state这段代码里最值得说的是max_steps。我一般设 8 到 12具体看任务复杂度。设太小任务做不完设太大浪费 token 还可能跑偏。这个值需要根据你的实际场景调没有标准答案。3.3 工具定义的具体写法工具定义我推荐用 JSON Schema因为主流模型接口都支持这个格式。一个合格的工具体验是这样的TOOL_SCHEMAS [ { name: search_knowledge, description: 在内部知识库中搜索信息。当用户询问产品功能、操作步骤、常见问题时使用。返回最相关的三条内容及来源。, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词尽量具体比如退款流程而不是退款 }, top_k: { type: integer, description: 返回结果数量默认3最大5, enum: [1, 2, 3, 4, 5] } }, required: [query] } } ]注意 description 里我特意写了“什么时候用”和“返回什么”。这两点模型非常依赖。参数里top_k用了 enum就是为了防止模型传个 100 进来。这些细节看着小但能显著降低出错率。3.4 上下文与状态管理的落地前面说了分层管理这里给个具体实现。我用一个字典来存状态class AgentMemory: def __init__(self, max_recent6): self.system_prompt self.task_state {} self.recent_messages [] self.max_recent max_recent def add_message(self, msg): self.recent_messages.append(msg) if len(self.recent_messages) self.max_recent: # 超出部分做规则化压缩不调模型 old self.recent_messages.pop(0) self._compress(old) def _compress(self, msg): # 只保留工具名和结果摘要丢弃原始长文本 if msg.get(role) tool: summary { tool: msg[name], result_preview: str(msg[content])[:100] } self.task_state.setdefault(history, []).append(summary) def build(self): return [ {role: system, content: self.system_prompt}, {role: system, content: f当前任务状态{self.task_state}}, *self.recent_messages ]这个实现的关键是_compress不调模型纯规则截断。这样既省成本又稳定。max_recent我一般设 6 到 10对应大概 3 到 5 轮完整交互。任务状态单独作为一条 system 消息注入保证模型始终能看到全局进展。4. 实操中真正会遇到的坑与排查方法4.1 模型不调用工具怎么办这是新手最常遇到的问题。你明明定义了工具模型却只顾着聊天。原因通常有三个一是工具描述太模糊模型不知道什么时候用二是系统提示词没强调“优先使用工具”三是问题本身确实不需要工具。排查顺序我建议这样先看工具描述把“什么时候用”补上再看系统提示词加一句“当问题涉及具体数据时必须先调用工具获取不要凭记忆回答”最后看用户输入如果确实是个闲聊问题那不调工具反而是对的。我遇到过一个典型案例工具叫get_info描述是“获取信息”。模型十次有八次不调。改成get_order_status描述写“根据订单号查询物流状态用户问我的快递到哪了时使用”调用率立刻上来了。工具名和描述的信息量直接决定模型的调用意愿。4.2 工具调用参数错误怎么处理模型传错参数很常见比如该传数字传了字符串该传枚举传了别的值。我的处理原则是不直接报错而是把错误信息结构化返回给模型让它自己修正。具体做法是在工具执行层做参数校验校验失败就返回{ error: 参数 top_k 必须是 1-5 的整数你传的是 many, suggestion: 请重新调用top_k 传 3 }模型收到这种信息下一轮通常能自己改对。如果你直接抛异常中断循环任务就失败了。这个设计在面经里经常被问到本质是考察你有没有把模型当成一个“会犯错的协作者”来设计系统。4.3 循环停不下来怎么办Agent 陷入死循环是另一个高频问题。表现是它反复调用同一个工具或者在不同工具之间来回横跳。原因一般是任务目标不清晰、工具返回的结果没有推进任务、或者缺少终止条件。我的应对有三招。第一在系统提示词里明确终止条件比如“当你已经获得足够信息回答用户时调用 finish”。第二检测重复调用如果连续两次调用同一工具且参数相同就注入一条提示“你刚刚已经调用过这个工具结果是X请基于此继续或换方案”。第三硬性步数上限到了就强制结束并返回当前状态。下面这张表是我整理的常见问题速查现象可能原因排查动作解决手段不调工具描述模糊/提示词没强调检查工具 description补场景说明加优先调用指令参数错误类型/范围不明确看 schema 定义加 enum、加类型说明、结构化报错死循环无终止条件/结果无推进看调用序列加重复检测、加步数上限结果跑偏上下文太长/目标丢失看注入的状态压缩历史、强化任务状态注入响应太慢工具串行/上下文过大看耗时分布并行化独立工具、精简上下文4.4 几个容易被忽略的实操心得第一个心得日志要记全。Agent 的调试比普通程序难因为它的决策路径不固定。我习惯把每一轮的输入消息、模型返回、工具调用、工具结果全部落盘。出问题时回放日志一眼就能看出是哪一步跑偏的。没有日志你只能靠猜。第二个心得先用手动模式验证工具。在接入 Agent 之前我会先手动调用每个工具确认它们本身是好的。工具本身有 bug却让模型背锅是最浪费时间的排查方向。第三个心得提示词要版本化。系统提示词改一个字Agent 行为可能大变。我一般把提示词存在单独文件里每次改动记一笔出问题能快速回滚。这个习惯在多人协作时尤其重要。第四个心得别追求一次到位。Agent 的行为是概率性的同样的输入两次结果可能不同。我的做法是先让它跑通 80% 的常见情况剩下的边缘情况通过加规则、加工具、加校验逐步收敛。想一步做到 100% 稳定只会把自己耗死。5. 从能跑到好用进阶优化方向5.1 工具并行化提升响应速度当 Agent 需要调用多个互不依赖的工具时串行执行会很慢。比如同时查天气和查日程这两个没有先后关系完全可以并行。实现上就是把工具调用收集起来用并发的方式执行再统一返回结果。但要注意并行只适用于无依赖的工具。如果第二个工具的输入依赖第一个的输出那就必须串行。判断依赖关系可以靠人工标注也可以让模型在调用时说明。我一般对高频工具对做人工标注简单可靠。5.2 引入反思机制提升成功率反思机制说白了就是让 Agent 在失败后自己复盘。具体做法是当工具连续失败两次或者任务超时就注入一条提示“你之前的方案没有成功请分析原因并换一种思路”。这个机制能显著提升复杂任务的成功率。不过反思也有代价它会增加 token 消耗和响应时间。我的经验是只在失败路径上启用正常路径不加这样既提升了鲁棒性又不影响常规性能。5.3 评测体系的搭建Agent 做出来容易做好难。难就难在怎么衡量它好不好。我的做法是建一个小型评测集包含 20 到 50 个典型任务每个任务标注期望的工具调用序列和最终结果。每次改动提示词或工具后跑一遍评测集看通过率变化。这个评测集不需要很大但一定要覆盖你的核心场景和已知的坑。它最大的价值是防止你改好一个场景、弄坏另一个场景。没有评测集优化就是盲人摸象。5.4 成本与延迟的平衡Agent 的每一步都要调模型成本是普通对话的好几倍。控制成本的手段有几个一是精简上下文前面说的分层管理就是干这个的二是用小模型做简单决策大模型做复杂推理三是缓存高频工具的结果。延迟方面除了并行化还可以考虑流式输出。让用户先看到 Agent 的思考过程体感上会快很多。这个在交互式场景里特别有用。6. 关于学习路径的一点个人体会回到“从面经开始学”这个起点。我自己的路径是先把面经里的高频问题列出来每个问题逼自己写一段能跑通的代码去回答。比如问“上下文怎么管理”我就真的去实现一个分层记忆问“工具失败怎么办”我就真的去写异常处理和结构化报错。这样学下来每个知识点都是带代码的不是飘在空中的概念。面经的价值不在于背答案而在于它帮你划出了重点。Agent 开发这个方向核心就那么几块循环调度、工具设计、上下文管理、错误处理、评测优化。你把这几块吃透剩下的都是组合和调优。最后分享一个我一直在用的小技巧每学一个新概念就把它加进你的最小 Agent 里跑一遍。不要单独写 demo就在同一个项目上迭代。这样你的项目会越来越完整知识也会越来越成体系。等面试官问你“做过什么”的时候你拿出来的不是一个玩具而是一个真正跑过、调过、踩过坑的系统。这比任何标准答案都有说服力。