1. 先搞清楚：AI Agent 到底是什么？
1.1 一句话分清：模型、大语言模型、Agent 三者关系
这几天热搜词里反复出现一个很有意思的提问：“Agent、LLM 和 AI 模型之间有什么区别？比如常说的 DeepSeek 到底是属于哪一种？”这个问题问得特别基础，但也特别关键。很多朋友一上来就急着写代码、调接口，结果连最基本的“自己在造什么”都没想明白，后面必然会走弯路。
先把这三层关系捋清楚。AI 模型（Model）是最大的范畴，指的是用数据训练出来的数学函数，能完成识别、分类、生成等任务。大语言模型（LLM）是 AI 模型里专门处理文本的那一类，它读进去一串文字，吐出来一串文字，本质上是做“下一个 Token 预测”。而 DeepSeek、GPT、Claude、Qwen 这些名字，指的都是具体的 LLM 产品或者模型权重。它们就像发动机，很强，但是如果没人把它装进车架、接上方向盘，它就只是一台孤零零的机器。
Agent 则完全不同。Agent 不是模型，而是跑在模型之上的一整套程序。它把 LLM 当作“大脑”，在外面包上了“记忆系统”“工具调用模块”“任务规划逻辑”和“执行反馈回路”，让它能自主完成一个相对完整的任务。打个比方，LLM 是一个知识渊博但只会坐在那里等问题的顾问，而 Agent 是那个知道什么时候该问、什么时候该查资料、什么时候该动手写代码、甚至能自我纠错的“同事”。
所以答案很明确：DeepSeek 属于“大语言模型”这一层，它不是 Agent。你可以用 DeepSeek 的 API 去搭一个 Agent，也可以不搭——直接用对话界面提问，那它就是一个聊天机器人，而不是一个 Agent。ChatGPT 官网里的默认对话窗口，很多场景也只是 LLM，不是 Agent；只有当它在背后调用了浏览器工具、代码解释器、文件读写能力时，它才以 Agent 的形态在工作。
1.2 Agent 的四个核心部件：大脑、记忆、工具、行动
理解了 Agent 不是模型之后，下一个问题就是：一个能被称为“Agent”的系统，内部到底由什么组成？互联网上关于 Agent 组成结构的文章很多，各家说法略有差异，但拆到底，逃不开四个核心部件。
大脑。这是 Agent 的推理中枢，也就是 LLM 本身。它负责理解用户的意图、拆解任务步骤、决定下一步该调用哪个工具、评估执行结果是否满足要求。选什么样的模型做大脑，直接决定了 Agent 的智商上限。逻辑推理类的任务用推理强的大参数模型，简单分类整理类的任务用小参数模型，成本和速度差异非常大。
记忆。这个太好理解了——你招一个新同事，他不可能每次都让你从头交代所有背景。Agent 也是一样，需要短期记忆（当前对话上下文）和长期记忆（跨会话保存的偏好、历史结论、业务知识）。完全没有记忆的 Agent 就像一个失忆症患者，每次对话都从零开始，实用性大打折扣。
工具。这是 Agent 和普通聊天机器人拉开差距的关键。工具可以是一个函数、一个 API、一个数据库查询接口、一段 Shell 命令、一个浏览器操作动作。Agent 通过“函数调用（Function Calling）”来决定什么时候调用什么工具，拿到结果之后再把结果喂回大脑做下一步判断。没有工具的 Agent 只能纸上谈兵，有了工具的 Agent 才能动手干活。
行动。行动是把决策落到现实世界的最后一环。它可能是执行一行 Python 代码、发送一封邮件、提交一个订单、在工业设备上改写一段 PLC 程序。行动的闭环还包括“反馈”——执行完之后结果要能传回给大脑，大脑根据结果判断是已经完成任务，还是需要调整策略再来一次。
这四个部件缺一不可。我在实际项目里见过很多“半成品 Agent”，要么只有大脑和对话界面，没有工具调用，本质上还是个聊天机器人；要么有工具但没记忆，每次请求都要重新灌一堆背景信息；要么有记忆有工具，但缺少行动反馈闭环，任务做到一半卡住了也不会自救。所以后面我们聊“从 0 到 1 搭建”，本质上就是在把这四个部件一个个拼起来。
2. 开始造“同事”：从 0 到 1 的路线图
2.1 定岗位：你的 Agent 要干什么活？
我在给团队做分享时最喜欢问一个问题：你要造的这个“同事”，岗位职责是什么？很多人回答不上来，只说要做一个 Agent。那就相当于你去人才市场说“我要招一个人”却不写岗位 JD，HR 根本没法帮你。
先定岗位，再谈技术。常见的 Agent 岗位有以下几种：
客服/答疑类 Agent。负责回答用户问题，核心能力是检索知识库、理解用户情绪、给出合规答案。这类 Agent 的技术难度较低，重点是知识库整理和提示词设计。
代码开发类 Agent。负责写代码、改 Bug、做 Code Review。核心能力是理解代码仓库结构、调用编译/测试工具、读取上下文文件。这类 Agent 是当前最火的方向，也是难度较高的一类，需要和 IDE、CI/CD、代码仓库深度集成。
数据分析类 Agent。负责人查数、做报表、写分析结论。核心能力是操作数据库、调用可视化组件、生成结构化文档。
业务流程自动化 Agent。负责处理表单、审批、通知、跨系统数据流转。核心能力是调用多个业务系统 API，维护状态机，处理异常分支。
工业控制辅助 Agent。比如热搜词里提到的“AI Agent 与 PLC 编程”，这类 Agent 负责根据自然语言描述生成 PLC 程序框架、检查梯形图逻辑、辅助生成设备文档。这类场景很专业，需要把行业知识沉淀到提示词和知识库中，而且因为涉及工业安全，通常只做“辅助生成+人工审核”，不允许全自动下发控制指令。
岗位定义越清晰，后面的框架选型、模型选型、工具设计就越轻松。我见过特别多“什么都能干”的通用 Agent 项目，最后全都死在“什么都干不好”上。Agent 的能力边界越明确，表现越稳定，用户口碑越好。
2.2 选框架：从代码到低代码的选择
定好岗位之后，就要选开发路径。市面上有几种做法，各有利弊。
直接调 API 手写 Agent。用 Python 或 Java 写一个主循环，自己管理 LLM 调用、工具注册、对话历史。优势是完全可控，没有框架黑盒，适合深度定制；劣势是开发量大，轮子都要自己造，而且容易在工具调用解析、错误处理等细节上踩坑。适合学习原理和做 PoC。
用成熟 Agent 框架。目前比较主流的开源自部署方案有 LangChain、LlamaIndex、AutoGen、CrewAI 等，Java 生态里有 Spring AI。这些框架帮你封装了 Agent 循环、工具调用、记忆管理、多 Agent 协作等通用能力。优势是开发效率高，社区方案多；劣势是抽象层级多，出了问题要翻框架源码，调试难度不低。适合有一定基础、追求交付速度的团队。
用平台型产品。各云厂商都推出了 Agent 搭建平台，主打可视化编排、拖拽式工作流。优势是上手快，业务同学也能参与；劣势是平台绑定、灵活度低、私有化部署成本高。适合政企客户或业务验证阶段。
我个人对学习路径的建议是：第一步一定要手写一个最小的 Agent 主循环，把原理吃透；第二步再引入框架提升效率。直接上手框架写业务，遇到问题容易两眼一抹黑，因为你不知道框架底下发生了什么。
2.3 推荐一个快速起步的技术栈
如果你现在带着一个小团队，想在两周内做一个能内部使用的 Agent 平台，我会推荐这样的技术栈组合：
后端用 Python FastAPI（或者 Spring AI 如果你偏 Java 生态），模型接口层封装成统一的 Gateway，支持切换不同的 LLM。框架层建议直接用 LangChain 的 LCEL 表达式语法来串联简单链路，复杂交互场景拆成多个独立 Agent。
前端可以用 React + Next.js，或者干脆先用 Gradio / Streamlit 做一个内部演示版。记住，Agent 平台的用户界面不是重点，重点是后台的任务调度和工具调用链路。工具层准备好一套标准接口，让 Agent 能调用内部 API、数据库、文件系统、搜索服务。记忆层建议先用向量数据库 + Redis，向量库存长期记忆，Redis 存短期会话缓存。部署用 Docker Compose 起步，跑通了再考虑 Kubernetes。
这个组合的好处是：每层技术都是行业主流，遇到问题社区资料非常多；组件之间耦合度低，后面想换任何一层——换模型、换向量库、换前端——都不会伤筋动骨。
3. 动手实操：5 步搭一个能干活的最小 Agent
3.1 第 1 步：搭建模型接入层
万事开头难，模型接入是最简单也最容易被忽视的一步。很多人觉得“不就是调 API 吗”，结果一上来就踩坑：上下文长度不够、返回格式不稳定、并发控制缺失、模型版本突然变化导致输出格式崩掉。
我建议一开始就把模型接入层设计成独立模块，用工厂模式+适配器模式。核心思想就是：你的业务代码不直接依赖任何具体模型 SDK，而是依赖你自己定义的一个接口。这样以后想从模型 A 换到模型 B，只需要新增一个适配器，业务代码完全不用动。
做这层时要特别注意两个点。第一，统一处理 Token 计数和上下文截断逻辑，不同模型的上下文窗口不一样，截断策略也不一样，必须在我的“Memory 层”里统一处理，而不是散落在各处。第二，给每个模型配好独立的超参数，比如 temperature、top_p、max_tokens，因为不同模型对同样参数的表现差异其实很大，复制粘贴别人的配置往往不出效果。
3.2 第 2 步：实现工具调用
工具调用是整个 Agent 里最有“智能感”的一环，也是工程上最容易翻车的一环。它的基本原理是这样的：你把一堆工具的“说明书”以 JSON Schema 的格式发给 LLM，LLM 判断当前任务需要哪个工具、参数是什么，然后返回一个结构化的工具调用请求；你的程序去执行真正的工具函数，把结果再传给 LLM，LLM 基于结果继续推理。
说得直白点，LLM 本身不执行任何工具，它只负责“点菜”，真正“做菜”的是你的代码。
下面是一个最小实现的伪代码，我用 Python 写，核心逻辑看注释就能懂：
def run_agent_turn(user_query, tools, model_client): # 第一轮：把用户问题 + 工具说明发给 LLM response = model_client.chat( messages=[{"role": "user", "content": user_query}], tools=tools, # tools 是 JSON Schema 列表 ) # LLM 如果决定要调用工具，会返回 tool_calls if response.tool_calls: tool_results = [] for call in response.tool_calls: function_name = call.function.name arguments = json.loads(call.function.arguments) # 在代码库里找到对应函数并执行 func = resolve_tool_function(function_name) result = func(**arguments) tool_results.append({ "role": "tool", "tool_call_id": call.id, "content": json.dumps(result) }) # 第二轮：把工具结果喂回去，让 LLM 生成最终答案 final_response = model_client.chat( messages=[ {"role": "user", "content": user_query}, response, # 包含第一轮的 assistant 输出 *tool_results, ], ) return final_response.content # 不需要调用工具，直接返回 return response.content这段代码看起来简单，但工程化时要做的细节非常多。比如函数参数校验做没做？如果 LLM 生成的参数是字符串但是函数需要整数，怎么转换？有些格式不兼容怎么处理？错误信息能不能回传给 LLM 让它自主修复？超时机制有没有？工具执行时间太长怎么中断？调用失败后应该告诉用户失败还是重试一次？
我踩过最经典的坑是：LLM 连续两次调用同一个工具拿到同样结果后开始“原地打转”，陷入死循环。解决方法是在循环里加最大迭代次数，比如说 10 轮，超过就强制停止并返回已获得的信息。
3.3 第 3 步：加入记忆机制
记忆机制分两块：短期记忆和长期记忆。短期记忆相对简单，就是当前会话的消息列表。长期记忆就比较复杂了，通常有两种实现方式：向量检索式记忆和结构化摘要式记忆。
向量检索式记忆的思路是：把用户的历史提问、偏好、重要结论，全部做向量化，存进向量数据库。当新对话进来时，把当前问题向量化，检索出最相似的历史记录，把它们塞进上下文。这种方式的优点是不用做太多结构化设计，缺点是有时检索出来的内容并不相关。
结构化摘要式记忆的思路是：每轮对话结束后，用 LLM 自动生成一段摘要，包括“用户是谁”“用户偏好”“当前任务进展”“已知结论”，存成结构化 JSON。新对话开始时，直接读取这些摘要。优点是精准，缺点是设计成本高，摘要本身也有延迟写入的问题。
比较稳妥的做法是两者结合。用短期上下文管理当前任务，用结构化摘要管理用户级偏好，用向量检索做补充记忆。另外提醒一句：记忆机制会显著增加 Token 消耗，做之前先算清楚成本。
3.4 第 4 步：挂上知识库（RAG）
RAG（检索增强生成）是让 Agent 学会“查资料”的最基础手段。核心逻辑是：用户提问进来，先从知识库中检索出相关的文档片段，拼到提示词里，再让 LLM 基于这些片段回答。这样做的目的是让模型在回答时能有依据，而不是凭空瞎编。
但很多人把 RAG 想得太简单了，觉得装一个向量数据库、分个块、做个相似度检索就完事。实践过就会知道，真正的难点在“知识入库”这一侧。文档格式多种多样（PDF、Word、HTML、Excel），不同格式的解析策略完全不同。表格要转成什么文本格式才能让 LLM 看明白？长文档怎么切块才能保证语义完整？切得太大浪费 Token 且检索不精准，切得太小语义破碎，检索效果反而差。
我的个人习惯是：先用“结构感知切块”，保留 Markdown 标题层级或 PDF 的自然段落结构；再为每一块生成一个简短摘要，作为检索的“路由索引”；最后把原块作为“参考答案”拼进提示词。即检索时用摘要匹配，回答时读原文块，这个小技巧能显著提升命中率。
3.5 第 5 步：让 Agent 学会“技能”和 MCP
“技能（Skill）”是现在 AI Agent 圈特别火的概念。热搜词里也出现了“ai agent skill memory mcp”这种组合词——Skill、Memory、MCP 被并列讨论，说明大家都在关心同一件事：怎么让 Agent 拥有可复用的能力包。
Skill 本质上是一组预置的提示词模板 + 工具脚本 + 示例数据的组合。举个例子，如果你想造一个“会议纪要 Agent”，一个完整的 Skill 应该包括：会议记录整理提示词、录音转文字工具调用脚本、待办事项提取规则、周报同步格式模板。有了 Skill，你不需要每次开会前从头写提示词，直接唤起这个技能包就行。
MCP（Model Context Protocol，模型上下文协议）是最近讨论热度很高的开放协议。它想解决的核心问题是：Agent 要对接各种外部数据源和工具，如果每个源都单独开发一套接口，就是“N 方对接 N 倍的复杂度”。MCP 提出一种标准化协议，让模型、Agent 框架和数据源之间的连接方式统一起来。
打个比方，没有 MCP 的时代，你家里每个电器都要自带专用的遥控器；有了 MCP 之后，你有了一个万能遥控器，电器只需要遵守同一个通信协议。目前各大模型厂商和框架都在积极推进 MCP 支持，做新项目时建议优先支持 MCP，避免重复开发已经有人做过的工具适配。
4. 平台化：从单个 Agent 到 Agent 平台
4.1 Agent 平台该有哪些模块？
单 Agent 能干活之后，下一个阶段一定是平台化。“平台”这两个字意味着它不是跑一次就结束的脚本，而是能持续运行、多人使用、不断迭代的系统。一个合格的 Agent 平台至少要包含六个模块：
模型管理模块。统一管理多个 LLM 的接入、配额、密钥、版本切换。线上环境不能把 API Key 写死在代码里，必须有独立的配置中心和密钥管理。
Agent 编排模块。支持像画流程图一样把多个 Agent、工具、知识库串联起来，支持条件分支和循环。
工具体系模块。提供工具注册中心，让开发者可以上传新工具，并设置工具权限，哪些 Agent 能用哪些工具需要管控。工具必须有版本管理和调用审计。
知识库模块。管理文档上传、切块、向量化、权限控制。知识库是企业 Agent 平台最容易出问题的地方，权限一不小心就会造成数据泄露。
记忆与状态模块。管理会话状态、用户画像、长期记忆。跨 Agent 的记忆共享也要在这里统一设计，不能每个 Agent 各存一套。
运营与审计模块。记录每一次 Agent 调用的输入、输出、耗时、费用，支持告警和人工介入。企业落地时这个模块几乎是第一个被要求做的，合规审计都靠它。
4.2 多智能体：让同事们协作起来
单打独斗的 Agent 能力有限，多智能体协作是平台化的高级形态。热搜词里有“多智能体 ai agent coding 协助开发规范”，说明很多人已经在研究怎么让多个 Agent 分工协作。
多智能体有三种典型协作模式。第一种是“主管-下属”模式，一个主 Agent 负责拆解任务，把子任务分发给多个专业 Agent，然后汇总结果。第二种是“流水线”模式，Agent A 的输出作为 Agent B 的输入，按固定顺序处理，比如先搜索、再分析、后写报告。第三种是“辩论/评审”模式，多个 Agent 从不同角度分析同一个问题，互相质疑，最后综合结论。
协作模式的选型要看任务类型。流水线适合流程固定、步骤清晰的任务；主管模式适合目标开放、需要动态规划的任务；辩论模式适合高风险决策，比如代码评审、方案评审。很多人在这个阶段会过度设计，我建议一开始先用主管模式跑通，后面根据业务反馈逐步演进。
这里也顺带回答热搜词里另一个问题：“Codex 可以直接读取其他 AI Agent 会话内容吗？”如果你用的是同一平台内的服务，通过 API 按会话 ID 去读取，在权限允许的前提下是可以做到的。但跨平台、跨厂商的代理工具空间，目前还没有统一的协议去强制开放。在自建平台上，我一般会把跨 Agent 会话读取做成显式的授权接口，谁读谁的会话要留有审计记录。
4.3 场景实战：企业内部 Java 平台上怎么落地
搜索引擎的数据显示，最近“企业级 Java AI Agent 应用平台”以及“Spring Cloud + Spring AI 开发自己的 Agent”的搜索量涨得很猛。这背后是大量传统 Java 技术栈企业的共同诉求：不是所有团队都愿意为了 Agent 换语言换生态，在现有 Java 体系里把事情做成就够了。
Spring AI 是 Spring 生态官方推出的 AI 应用开发框架，目前已经支持 OpenAI、Azure OpenAI、Ollama、Qwen 等多种模型接口。它把 ChatClient、PromptTemplate、EmbeddingModel、VectorStore 这些常用组件都封装成了 Spring Boot 的 Starter，Java 工程师上手几乎没有门槛。
在企业级落地时，最大的优势不是写 Agent 逻辑有多快，而是能和现有的 Spring Cloud 微服务体系无缝整合。你可以把 Agent 做成一个独立的微服务，用 Nacos 做注册发现，用 OpenFeign 调用内部业务接口，用 Sentinel 做流量控制和熔断，用 Seata 处理分布式事务——只不过这里的“事务”已经变成一个任务的多个工具调用步骤。这种整合能力是 Python 系框架很难直接提供的。
我的建议是：如果你们团队以 Java 为主，不要强行上 LangChain，直接用 Spring AI 加上代码自研状态机。宁可自己多写几行代码，也不要引入一个团队里没人能维护的复杂框架。另外提醒一句，Spring AI 迭代速度很快，API 在不同版本之间变动较大，项目开始时要锁版本，不要用最新发布的功能直接上生产。
4.4 场景实战：CI/CD 流程里的 AI Agent
“Jenkins AI Agent”这个热搜词很有意思。CI/CD 和 AI Agent 的结合，是当前最贴近实际生产力提升的落地场景之一。我见过不少团队已经在尝试，效果参差不齐，但方向是对的。
Jenkins 流水线里的 AI Agent 可以做几件事：首先是构建失败的智能分析，以前 Jenkins 构建挂掉，要人工翻日志找原因，现在可以让 Agent 读取构建日志，定位错误原因，甚至直接给出修复建议；其次是自动化代码评审，PR 提交后触发 Agent 做静态分析、逻辑审查和代码风格检查，输出评审意见到评论里；再就是自动化测试用例生成，Agent 读取方法源码，生成单元测试用例，提交回仓库。
我前阵子做了一个 PoC：给 Jenkins 挂了一个 Agent 节点，构建失败时自动触发一个“诊断 Agent”，它会读取构建日志、对比上一次成功构建的变更、分析最近提交的代码，最后在工单里生成一个带修复方案的报告。实测下来，对于常见依赖冲突、语法错误、单测失败这三类问题，它的准确率相当高，能直接给出可用的修复补丁。对逻辑性强的业务 Bug，它只能给出方向性建议，但这也已经能帮开发者节省大量排查时间了。
4.5 场景实战：和 PLC 编程结合的工业场景
“AI Agent 与 PLC 编程”是热搜词里特别有行业特色的一条。PLC（可编程逻辑控制器）是工业自动化控制的核心设备，传统 PLC 编程要求工程师熟悉梯形图、结构化文本等专业语言，门槛不低。
AI Agent 进这个领域，核心价值是降低编程门槛和辅助诊断。入门级用法是用自然语言描述控制逻辑，Agent 生成对应的结构化文本（ST）或指令表代码。高阶用法是让 Agent 分析现有 PLC 程序的逻辑，生成说明书、排查故障点。更进一步的设想是，巡检 Agent 读取设备运行数据，判断异常状态，给出处理建议。
但工业场景有一条底线必须守住：Agent 的输出永远只能作为“辅助”，不能直接下发到设备执行。控制系统的安全性是生命线，Agent 生成代码后必须经过资深工程师审核，在仿真环境验证，然后才能下载到 PLC。我在项目里给 Agent 设定了严格的输出边界：它只能写代码建议、只能出诊断报告、只能做自然语言与代码的翻译，任何写回控制器的操作都需要人工确认。这套约束在系统设计上写死了，谁也不能绕过。
5. 常见问题与排查技巧实录
5.1 Agent“胡说八道”怎么办？
幻觉问题排在所有 Agent 实践问题第一位。原因无非几种：模型本身能力不足、上下文里没有足够依据、提示词让模型自由发挥、检索到的知识本身就是错的。
排查时我一般按这个顺序走。第一，检查上下文里有没有引用真实内容——如果回答不是基于检索结果生成的，那就是 API 在自由发挥，需要改成强制引用模式。第二，换更强的模型对比测试，经济允许的情况下，同一任务用小模型和大模型跑一遍，能快速判断是模型能力上限还是工程问题。第三，在提示词里给模型“认怂”的选项，明确告诉它：“如果信息中不包含答案，直接说不知道，不要编造。”这一条对缓解幻觉非常有效。
5.2 工具调用老是失败？
工具调用失败是工程问题最多的环节。常见场景包括：LLM 返回的 JSON 参数格式不合法、参数类型对不上、工具函数内部抛异常、超时、权限不足。
最有效的排查方法是“分阶段日志法”。在 LLM 返回 tool_calls 之后、执行工具函数之前、工具返回之后三个阶段各打印一条详细日志，记录完整请求和响应。这样一旦出问题，你立刻能判断是模型生成参数的问题，还是工具函数本身的问题。
另外要说一个经验：不要完全信任 LLM 生成的参数。在执行工具函数之前，先用 JSON Schema 校验参数格式，不合法就让 LLM 重新生成一次。重试超过两次还不行，就停止调用，返回错误提示。
5.3 上下文一长就“失忆”？
Agent 一次会话中处理的内容越来越多时，效果会急剧下降。核心原因是 LLM 的注意力机制对长上下文中关键信息的感知能力有限，越靠中间的内容越容易被忽略，专业上叫“迷失在中间（Lost in the Middle）”。
解决办法有两个方向。一是压缩上下文，把不重要的历史对话替换成摘要，把大段知识替换为检索命中片段，只保留关键信息在上下文中。二是把 Agent 的“记忆”外置，重要信息写入长期记忆库，下一轮工作时通过检索拉回，而不是把全部历史都塞进去。很多人的误区是觉得上下文越长越好，其实上了 10 万 Token 之后，模型的有效理解能力断崖式下降，做 Agent 架构时一定要控制上下文质量大于数量。
5.4 成本失控怎么办？
有朋友说做了一个 Agent 平台，跑了一个月，模型 API 账单出来差点吓到自己。原因几乎都是同一个：没有做 Token 成本预算和配额管理。
从第一天就要做三件事。第一，给每个 Agent 设置单次调用 Token 上限和月度费用上限。第二，任务能用小模型的绝不用大模型，比如简单的意图识别、分类任务，用参数量小的模型完全够用，成本能省下 80%。第三，缓存命中率要做好，同一类问题如果知识库内容没变，可以用语义缓存直接返回，不再调用模型。这三点做完，整体成本能控制在预期的十分之一到二分之一之间。
5.5 面试视角：一个 Agent 题目的标准回答思路
热搜词里有“ai agent 面试题”，顺便说两句。现在越来越多后端岗位面试会问 Agent 相关问题，考察的重点通常不是你会不会用某个具体框架，而是“组成结构”和“设计取舍”。
标准的回答思路是：先讲清楚 Agent 的四个核心部件——大脑（LLM）、记忆（短期+长期）、工具调用（Function Calling）、行动反馈闭环；然后讲清楚 LLM 和 Agent 的区别——模型是被调用的能力，Agent 是组织这种能力的系统；再结合你做过的最简单例子，讲一次完整的工作循环；最后提一嘴当前框架的优缺点、你想怎么改进。这套回答下来，面试官基本能判断你不是“背了概念”而是真做过。
最后再分享一点个人经验
做 AI Agent 这一年多的体会是：技术难点从来不在“跑通一个 Demo”，而在“让它稳定地跑一百次”。一次两次效果好不叫好，一百次里能有九十五次稳定输出，才算一个合格的 Agent。所以我在项目里坚持做两件事：一是给每一次 Agent 调用记录完整轨迹，方便事后复盘；二是把“输出结构化”当成硬指标，无论哪个环节，都要求模型返回可解析的 JSON，而不是自由文本。
另外，如果你也是半路出家开始做 Agent，别急着追新框架新协议。踏踏实实把模型接入、工具调用、记忆管理、RAG 这四件事吃透，你已经能超过多数只会套模板的开发者了。Agent 的边界其实就是你的想象力加上工程能力，前者大家都有，后者练一练，一定会到。
