1. 从一份面经里拆出来的Agent学习路线

第一次看到"从面经开始的agent开发学习"这个标题，我脑子里冒出来的不是某个具体框架，而是一堆散落的关键词：agent、codex、protobuf、json、上下文管理。这几个词凑在一起，其实勾勒出了一条非常真实的入门路径——很多人不是从系统课程进场的，而是从面试题、面经、别人的项目复盘里，一点点把agent开发的知识拼图拼起来的。

我自己也是这么过来的。最开始接触agent，纯粹是因为看到面经里反复出现"你了解agent的上下文管理吗""agent和普通LLM调用有什么区别""你怎么处理工具调用的返回结果"这类问题。当时我连agent是什么都说不清楚，只能硬着头皮去查，查着查着就发现，这东西不是背几个概念就能糊弄过去的，它背后是一整套工程化的东西：协议怎么定、上下文怎么裁、工具怎么调、错误怎么兜底。

这篇内容适合两类人：一类是正在准备面试、被agent相关问题问懵了的朋友；另一类是想动手搭一个能跑起来的agent、但不知道从哪下手的开发者。我不会给你画一张特别漂亮的大图，而是按照我自己踩过的顺序，把agent开发里最容易被面经带偏、又最需要真正搞懂的几个点讲透。核心关键词会自然穿插在每一段里，你读的时候可以对照自己的理解查漏补缺。

先说一个反直觉的结论： 面经里问得最多的，往往不是最难的，而是最容易在工程里翻车的 。比如"json格式怎么处理"这种看起来像八股的问题，实际写agent的时候，十次报错有六次跟它有关。所以别轻视这些基础点，它们才是agent能不能稳定跑起来的地基。

2. Agent到底是什么：先把概念里的水分挤干

2.1 从"会聊天的模型"到"会干活的agent"

很多人对agent的第一印象是"更聪明的聊天机器人"，这个理解不算错，但太浅了。普通的大模型调用，本质是"你问一句，它答一句"，模型本身不记得上一轮发生了什么，也不会主动去查东西、调工具、改自己的计划。而agent的核心区别在于： 它有一个循环 。

这个循环大概是这样的：接收目标 → 思考下一步做什么 → 选择一个工具或动作 → 执行 → 拿到结果 → 把结果塞回上下文 → 再思考下一步 → 直到任务完成或触发终止条件。你看，这里面出现了几个关键词：上下文管理、工具调用、终止条件。面经里问的"agent和普通调用的区别"，答案就在这个循环里。

我习惯用一个生活化的类比：普通模型调用像你去餐厅点菜，你说"来个宫保鸡丁"，服务员记下来传给厨房，厨房做完端上来，结束。而agent像你雇了一个助理，你说"帮我安排一顿适合四个人的晚饭"，助理会先问你口味、预算、时间，然后去查餐厅、打电话订位、确认菜单、最后把结果告诉你。助理会自己决定中间要做哪些事，这就是agent。

2.2 Agent、Harness、框架：三个容易混的概念

热词里有个"harness和agent区别"，这个问题其实挺关键的。我自己的理解是： agent是"决策者"，harness是"执行环境" 。Agent负责想"下一步干什么"，harness负责"把这一步真正跑起来"，包括管理工具注册、处理输入输出、捕获异常、控制循环次数。

打个比方，agent是司机，harness是车。司机决定往哪开，车负责把方向盘、油门、刹车这些底层操作执行到位。你换一个harness，司机还是那个司机，但车的性能、仪表盘、故障提示可能完全不一样。很多agent框架其实同时包含了agent逻辑和harness能力，所以初学者容易把它们混为一谈。

至于"agent框架与编排"，编排（orchestration）更多是在多agent场景下出现的概念。单个agent自己循环就够了，但当你需要多个agent分工协作——比如一个负责查资料、一个负责写代码、一个负责审核——就需要编排层来决定谁先谁后、结果怎么传递。面经里如果问到"多agent怎么协作"，你至少要能说出"编排层负责调度和状态传递"这个层面。

2.3 为什么面经爱问agent安全

"agent安全"这个词在热词里出现得不少。原因很简单：agent能调工具、能执行动作，一旦被恶意输入带偏，后果比普通聊天严重得多。比如一个能读写文件的agent，如果被诱导去读取敏感文件，那就是实打实的安全问题。

我在实际项目里总结了几条底线：第一，工具权限要最小化，agent不需要的能力就别给它；第二，对工具调用的参数要做校验，不能模型说什么就执行什么；第三，要有终止条件，防止agent陷入死循环把资源耗光。这三点听起来简单，但真到写代码的时候，很多人会图省事全放开，后面出问题再补就麻烦了。

3. 上下文管理：Agent开发里最容易被低估的硬骨头

3.1 上下文不是越多越好

面经里问上下文管理，很多人第一反应是"把历史对话都塞进去不就行了"。这个答案在demo阶段能跑通，但一上真实场景就崩。原因有两个：一是模型的上下文窗口有上限，塞太多会截断；二是就算窗口够大，无关信息太多也会稀释模型的注意力，导致它抓不住重点。

我踩过的坑是这样的：早期做一个客服agent，我把用户过去三十轮对话全塞进上下文，结果模型经常答非所问，因为它被前面一堆无关的闲聊带偏了。后来改成"只保留最近五轮 + 一个摘要"，效果立刻好转。这就是上下文管理的核心思路： 不是保留全部，而是保留最相关的 。

具体怎么做？我一般分三层处理。第一层是系统提示词，固定不变，放角色设定和规则；第二层是近期对话，保留最近若干轮原文；第三层是长期记忆，用摘要或者向量检索的方式按需召回。这样既控制了token量，又保证了关键信息不丢。

3.2 上下文裁剪的几种常见策略

裁剪策略没有银弹，得看场景。我整理了几种常用的，你可以对照自己的需求选：

策略	适用场景	优点	缺点
滑动窗口	对话类agent	实现简单，保留近期信息	早期关键信息会丢
摘要压缩	长对话、任务型	保留主线，token可控	摘要本身可能丢细节
向量召回	知识密集型	按相关性取信息	需要额外检索组件
分层保留	复杂任务	兼顾规则与历史	实现复杂度较高

我个人的经验是， 大多数场景用"滑动窗口 + 摘要"就够了 ，别一上来就上向量库，那是给自己找麻烦。等你发现摘要确实不够用、需要精确召回某条历史信息时，再引入检索也不迟。

3.3 上下文里的"污染"问题

有个坑面经里很少提，但实际开发中特别常见： 上下文污染 。什么叫污染？就是前面某一步工具调用返回了错误信息或者无关内容，你没清理干净，它就一直留在上下文里，影响后面每一步的判断。

我遇到过一次典型情况：agent调用一个接口失败了，返回了一大段错误堆栈，我没处理就直接塞回上下文。结果后面几轮模型一直在纠结那个错误，反复尝试修复一个根本不存在的问题。后来我加了一条规则：工具返回的错误信息，要么转成简短提示，要么直接丢弃，绝不原样塞回上下文。

提示：每次往上下文里追加内容前，先问自己一句"这条信息对完成当前目标有帮助吗"，如果答案是否定的，就别加。

4. JSON与Protobuf：Agent数据交换的两套语言

4.1 为什么agent开发绕不开JSON

热词里json相关的词特别多：json格式、json数组、json转换、json查询函数、json用什么打开……这说明什么？说明大量开发者在处理agent的数据交换时，第一选择就是JSON。原因很直接： JSON可读性好、语言无关、几乎所有编程语言都原生支持 。

Agent和工具之间的通信，本质上就是"agent说我要调用某个工具，参数是这些"，工具执行完"返回结果，格式是这些"。这个"说"和"返回"的过程，用JSON来描述是最自然的。比如一个查天气的工具调用，请求可能是这样的：

{
  "tool": "get_weather",
  "parameters": {
    "city": "杭州",
    "date": "2026-01-15"
  }
}

返回可能是：

{
  "city": "杭州",
  "date": "2026-01-15",
  "temperature": 8,
  "condition": "多云"
}

你看，结构清晰，人也能看懂，机器也能解析。这就是JSON在agent场景里流行的原因。

4.2 JSON处理的几个高频坑

但JSON也不是没坑。我列几个实际开发中经常遇到的：

第一个坑是 格式不合法 。模型生成的JSON经常带一些多余的东西，比如前后有解释性文字、用了单引号、多了个逗号。这时候直接解析就会报错。我的做法是加一层容错解析：先尝试标准解析，失败就用正则提取最外层的花括号内容再解析，还失败就让模型重新生成。

第二个坑是 类型不一致 。比如某个字段有时候是字符串"8"，有时候是数字8。下游代码如果没做类型判断，就会出问题。解决办法是在工具定义里明确字段类型，并在解析后做一次校验。

第三个坑是 嵌套过深 。有些工具返回的JSON嵌套了五六层，取值的时候一层层点下去，代码又长又容易错。我一般会用jsonpath或者类似的查询方式，直接定位到需要的字段。

import json

def safe_parse(text):
    try:
        return json.loads(text)
    except json.JSONDecodeError:
        # 尝试提取最外层花括号
        start = text.find('{')
        end = text.rfind('}')
        if start != -1 and end != -1:
            try:
                return json.loads(text[start:end+1])
            except json.JSONDecodeError:
                return None
        return None

这段代码不复杂，但能挡掉大部分格式问题。面经里如果问"你怎么处理模型返回的JSON"，能说出这层容错，基本就及格了。

4.3 Protobuf在agent场景里的位置

热词里出现了protobuf，还有"attempting uninstall: protobuf found existing installation: protobuf 5.29.6"这种典型的版本冲突报错。这说明什么？说明当agent系统规模变大、性能要求变高时，JSON就不够用了，很多人会转向Protobuf。

Protobuf的优势在于： 序列化后体积小、解析速度快、有强类型约束 。JSON是文本格式，传输和解析都相对慢；Protobuf是二进制格式，同样一份数据，体积可能只有JSON的三分之一甚至更少。在高频调用的agent系统里，这个差距会被放大。

但Protobuf的代价是：可读性差，调试不方便，而且需要先定义schema再生成代码。所以我的建议是： 内部高频通信可以用Protobuf，对外接口和调试阶段还是用JSON 。两者不是替代关系，而是分工关系。

至于那个protobuf版本冲突的报错，本质是环境里装了多个版本的protobuf，卸载旧版本时没卸干净。解决办法通常是先确认当前用的是哪个版本，然后统一到同一个版本，必要时用虚拟环境隔离。这类问题在agent开发里很常见，因为agent依赖的库多，版本冲突几乎是必修课。

5. Codex类工具接入Agent的实操路径

5.1 Codex在agent生态里的角色

热词里codex相关的词一大堆：codex安装、codex使用教程、codex cli、codex接入deepseek、codex无法发送消息……这说明codex已经成了很多人做agent开发时的常用组件。它的定位，简单说就是 一个能理解代码、生成代码、执行代码相关任务的agent能力模块 。

在agent系统里，codex通常承担"代码类任务"的处理。比如你的agent需要写一段脚本、修改一个文件、跑一个命令，这些都可以交给codex类能力去完成。它和通用对话模型的区别在于，它对代码结构、命令行、文件操作这些场景有更强的针对性。

5.2 接入时的环境准备

接入这类工具，环境准备是最容易翻车的地方。我按自己的经验列一下顺序：

第一步，确认运行环境。不同系统、不同版本，安装方式可能不一样。我一般会先确认基础运行时版本，避免后面因为版本不匹配反复折腾。

第二步，处理依赖冲突。前面提到的protobuf版本问题就是典型。我的习惯是 每个agent项目单独建虚拟环境 ，别在全局环境里装一堆东西，否则迟早冲突。

第三步，配置访问凭证。这一步经常出问题，比如"codex无法加载组织设置""codex登录失败"这类报错，多半是凭证配置不对或者网络环境有问题。我的做法是先用最小配置跑通一个hello world级别的调用，确认链路通了再往上加功能。

第四步，验证基础能力。别急着接复杂任务，先让它做一个最简单的代码生成或文件读取，确认输入输出都正常。

5.3 常见报错与排查思路

热词里有个报错很典型："cc switch local proxy failed while handling codex endpoint /responses"。这类报错通常出现在请求转发环节，可能是代理配置、端口占用、或者请求格式不对导致的。排查思路是：先看日志确认请求有没有发出去，再看响应有没有回来，最后看格式对不对。

还有"codex无法发送消息""agent execution terminated due to error"这类，多半是上下文超限、工具调用失败、或者终止条件触发导致的。我的排查顺序是：先看是不是上下文太长被截断，再看是不是某个工具调用返回了异常，最后看是不是循环次数到了上限。

注意：遇到报错别急着改代码，先把完整的错误信息和调用链看清楚。很多问题看一眼日志就明白了，盲目改代码只会引入新问题。

6. 从面经问题反推Agent项目该怎么搭

6.1 面经问题背后的真实考点

面经里关于agent的问题，表面看是考概念，实际考的是你有没有真正搭过。比如"ai agent怎么扛并发"这个问题，没做过的人可能答"加机器"，做过的人会告诉你：要考虑上下文隔离、工具调用的幂等性、以及状态存储的并发安全。

再比如"agent execution terminated due to error"这种，考的是你的错误处理能力。一个健壮的agent，不是永远不报错，而是报错之后能优雅降级或者给出有意义的提示。

我把常见面经问题归了几类，你可以对照准备：

问题类型	典型问法	考察点
概念理解	agent和普通调用区别	是否理解循环机制
上下文	上下文太长怎么办	裁剪与压缩策略
工具调用	工具返回错误怎么处理	容错与降级
并发	多用户同时用怎么扛	隔离与状态管理
安全	agent被诱导怎么办	权限与校验

6.2 一个最小可跑Agent的搭建顺序

如果你看完面经想动手搭一个，我建议按这个顺序来，别一上来就追求功能全：

第一，先实现单轮工具调用。就是模型决定调一个工具，你执行，把结果返回，结束。这一步跑通，你就理解了agent的基本骨架。

第二，加上循环。让模型能根据工具返回的结果决定下一步，直到任务完成。这一步要特别注意终止条件，别让它无限循环。

第三，加上上下文管理。引入滑动窗口或者摘要，控制token量。

第四，加上错误处理。工具调用失败、格式解析失败、超时，都要有兜底。

第五，加上日志。这一步很多人省，但真出问题的时候，日志是唯一的救命稻草。

6.3 我踩过的几个真实坑

第一个坑： 工具描述写得太模糊 。模型选择工具是靠描述匹配的，如果描述写得含糊，它就会选错工具。我后来把每个工具的描述都写成"什么时候用、输入是什么、输出是什么"，准确率明显提升。

第二个坑： 没有限制循环次数 。有一次测试，agent陷入了一个"调用工具→失败→重试→再失败"的死循环，跑了几十次才被我手动停掉。后来我加了最大循环次数限制，超过就强制终止并返回当前结果。

第三个坑： 上下文里混入了调试信息 。开发阶段我习惯打一堆日志到上下文里，结果模型被这些信息干扰，输出质量下降。后来我把调试信息和上下文严格分开，上下文只放对任务有用的内容。

7. 并发、安全与工程化：Agent从demo到可用的距离

7.1 并发场景下的状态隔离

"ai agent怎么扛并发"这个问题，核心在于 状态隔离 。单个agent跑的时候，上下文、工具状态、中间结果都放在一起没问题。但多个用户同时用的时候，如果状态混在一起，就会出现A用户的上下文被B用户看到的情况，这是严重的问题。

我的做法是：每个会话分配独立的上下文空间，用会话ID做隔离。工具调用如果有状态，也要按会话区分。存储层如果用数据库，要注意并发写入的锁问题；如果用内存，要注意清理机制，别让废弃会话一直占着资源。

7.2 Agent安全的几条实操底线

前面提过agent安全，这里再展开说几条我实际执行的底线：

• 工具权限最小化：agent不需要的能力坚决不给，比如不需要写文件就别开写权限。
• 参数校验：模型给的参数不能直接执行，要过一层校验，比如路径不能越界、命令不能是危险命令。
• 输出过滤：agent的输出在返回给用户前，要过一层过滤，防止泄露敏感信息。
• 审计日志：所有工具调用都记日志，出问题能追溯。

这几条不复杂，但能挡掉大部分常见风险。面经里问安全，你能说出这几条，基本就够了。

7.3 工程化里那些"不性感但重要"的事

Agent开发里有很多不性感但特别重要的事，比如配置管理、日志规范、错误码定义、版本兼容。这些东西在demo阶段看不出价值，但项目一旦要长期维护，它们就是命脉。

我举个例子：错误码。早期我图省事，所有错误都返回一个笼统的"执行失败"，结果排查问题的时候完全不知道是哪一步出的错。后来我定义了一套错误码，工具调用失败、格式解析失败、超时、权限不足各有各的码，排查效率立刻上来了。

再比如配置管理。Agent依赖的外部服务、模型参数、工具开关，这些如果硬编码在代码里，改一次就要重新部署。我后来把它们抽到配置文件里，改配置不用动代码，灵活多了。

8. 学习路径复盘：从面经到能上手做项目

回到标题"从面经开始的agent开发学习"，我自己的路径大概是这样：先被面经问题问懵，然后去查概念，查着查着发现光看不行，得动手，动手之后踩了一堆坑，踩完坑再回头看面经，发现那些问题突然都能答上来了。

所以我的建议是： 别把面经当终点，把它当起点 。面经里的问题是一张地图，告诉你这个领域有哪些关键点，但真正的理解得靠你自己动手去走一遍。上下文管理、JSON处理、工具调用、错误兜底、并发隔离，这些点你只要亲手实现过一次，面试的时候就不用背答案了，因为你真的懂。

如果你现在正处在"看了一堆面经但还是不会做"的阶段，我的建议是先搭一个最小的agent，哪怕只能调一个工具、只能跑一轮，也比看十篇文章强。搭起来之后，再对照面经里的问题一个个去补，缺上下文管理就补上下文管理，缺错误处理就补错误处理。这样学下来，知识是长在你身上的，不是背在嘴上的。

最后分享一个我自己的小习惯：每踩一个坑，就在笔记里记一条"现象 + 原因 + 解决办法"。时间长了，这本笔记就成了我自己的面经，比网上任何一份都管用。Agent开发这个方向变化快，但底层的那些工程问题——上下文、数据格式、错误处理、并发、安全——是相对稳定的，把这些吃透，换什么框架你都能快速上手。