企业官网建设流程全解析

最近不管是刷技术社区还是看朋友圈，你大概都会有一种感觉：好像一夜之间，所有人都在聊Agent。GitHub Trending上Agent项目快占掉一半，开源社区隔三差五冒出新的Agent框架，昨天的热搜词是Agent，今天又变成Agent开发、Agent记忆。如果你之前只做过普通的大模型应用，或者还在“聊天机器人”阶段，这会儿很容易被铺天盖地的概念砸得有点慌。

我先说结论：Agent不是一个玄学概念，也不是某个公司的产品特供，它是大模型应用进入“系统化”阶段后自然而然出现的程序范式。过去我们做AI应用，重点是让模型“生成内容”；现在做Agent，重点变成了让模型“完成任务”。注意，这里的差别不是一两个字，而是从“脑”到“脑+手+眼睛+记事本”的完整模型转变。

这篇文章，我会从最基础的概念讲到主流架构，再到实操搭建，最后把很多人关心的Agent开发面试考点、Harness与Agent框架的关系都梳理一遍。目标很明确：让你看完之后，能跟同事讲清楚Agent到底是个什么东西，也知道如果自己要动手做一个，第一行代码应该写在哪。

1. Agent到底是什么，它跟普通程序有什么区别

1.1 先用生活例子把它说清楚

拿“做一顿晚饭”打比方。

传统程序就像一篇菜谱：先切菜，再热油，再下锅，顺序固定，参数写死，中间任何一步如果情况变了，程序不会自己调整，只能报错或者等着人来改。

大模型聊天机器人像个“美食顾问”：你问它“茄子怎么做”，它能给你讲得头头是道，但它自己不上灶台，也不洗菜。

Agent就不一样了，它更像你雇了一个会做饭的帮厨。你跟它说“今晚想吃鱼香肉丝，冰箱里有茄子、肉和青椒，你看着做”，它会自己翻冰箱、查菜谱、决定先热油还是先腌肉，遇到“青椒没了”这种突发情况，它还会主动改成用胡萝卜替代，做完之后把菜端上桌，再告诉你它改了哪些配料。

这个类比里藏着Agent的四个核心特质：明白目标、能拆解步骤、能调用工具（冰箱、菜刀、灶台）、能根据过程中的反馈调整行为。也正是这四点，把Agent和传统程序、普通聊天机器人彻底区分开。

1.2 Agent的六个核心特征

如果你去看不同公司的Agent白皮书，会发现大家对Agent的定义不完全一致，但核心特征基本绕不开这六点：

• 自主性：不需要每一步都被人指挥，你给出目标，它自己规划后续动作。
• 目标驱动：执行的是“目标”而不是“固定步骤”，完成任务的过程可以动态变化。
• 规划能力：能把大任务拆解成若干小步骤，并且对步骤排序、去重、回退。
• 工具使用：能调用外部API、函数、数据库、浏览器等，不只是“输出文字”。
• 记忆能力：能记住关键信息，至少能在多轮交互中不丢失上下文，最好能长期保存。
• 反思与修正：发现当前路径走不通时，能回顾之前的决策并调整策略。

这六条不是说每个Agent都要百分之百具备，但它们共同构成了大家口中的“Agent能力”。一个只做了工具调用包装、但完全没有规划循环的应用，严格来说算不上Agent，顶多算“带插件的聊天机器人”。

1.3 澄清一个常见的搜索误区

很多人刚搜Agent这个词时会迷茫，因为“Agent”在IT领域已经被用了几十年，含义有好几层。比如qemu guest agent、监控Agent、运维Agent，这些是传统意义上的“代理进程”或者“守护程序”，和现在聊的AI Agent完全是两回事。现在这个火出圈的Agent，更准确的说法是“AI Agent”或者“智能体”。

所以如果你去搜索引擎里直接搜“agent是什么”，出来的结果里一半是传统IT领域的含义，一半是AI领域的新含义，很容易让人头大。这篇文章聊的是后者——以大模型为大脑、具备自主规划和工具调用能力的智能体。

2. 为什么偏偏是现在，Agent才火起来

2.1 模型能力：从“会聊天”到“会干活”

Agent这个概念其实不是2024、2025年才发明的。早在几年前，学术界就讨论过“智能体”的雏形，但当时大模型的能力支撑不起“自主干活”这件事，模型只会做单轮问答，你让它“帮我订个餐厅再规划路线”，它只能给你一段建议文本，无法真正动手执行。这时候做Agent就是一个概念玩物。

后来大模型的推理能力和指令遵循能力上来之后，情况变了。模型不再只会“接话”，它能理解“用户的真实意图”，能把一个模糊的需求拆成明确的步骤。给你感觉最明显的例子就是：以前你让AI“写一篇行业分析报告”，它给一坨泛泛而谈的文字；现在一个Agent可以先帮你查资料、整理数据、生成PPT大纲、再输出一份完整文档。这不是模型的“文笔”变好了，而是它开始具备“计划+执行”的行为能力。

2.2 工具调用标准化：Function Calling的出现

光有“大脑”还不够，一个Agent要完成任务，必须有“手”。这个“手”就是工具调用能力。如果你让模型自己去拼HTTP请求、生成URL去调API，既不安全也不稳定。业界做了一件非常关键的事，就是定义了一套标准化的工具调用协议，行业里通常叫Function Calling，也就是让模型在生成回答时，不只是输出纯文本，而是可以同时输出一个“意图表达式”。这个表达式告诉程序：去调用哪个工具、传什么参数，程序拿到后再真正执行，把结果返回给模型。

具体来说，它会这样流转：

1. 开发者把工具描述成一段JSON Schema，比如“获取天气：参数city, string, 必填”。
2. 用户在对话中说“北京明天冷不冷”。
3. 模型识别出意图，输出“调用get_weather，参数city=北京”这样的结构化指令。
4. 程序执行天气API，拿到结果。
5. 模型基于结果组织回答：“北京明天最低气温-5℃，比较冷，建议穿羽绒服。”

这一整套流程标准化之后，Agent的“手”就有了统一的接口，开发者不需要为不同模型写不同的调用方案。2023年左右，大模型厂商正式把Function Calling作为标准API能力开放，这也是Agent能大规模落地的一个引爆点。

2.3 开源与框架：把门槛打下来的“二传手”

还有一个不能忽视的因素是开源模型和开源框架的成熟。以前想做一个Agent，得自己处理模型部署、工具调用协议、状态管理、记忆管理，工程量大得吓人。现在有很多开源框架把Agent的骨架搭好了，你只需要往里面填自己的业务逻辑、注册工具、配置模型就可以。

像LangGraph、AutoGen这些框架，已经把Agent最重要的“循环”封装成了节点和边的图结构，你甚至不需要完全理解底层状态机，就能跑起一个多步骤Agent。还有不少开源项目把很多高频操作做成了“开箱即用”的形态，比如整合好的本地Agent运行环境，下载下来配置一下模型就能体验。这也是为什么你会看到很多热搜词里出现“hermes agent安装”“hermes agent本地部署”这类问题——基础设施齐全之后，大家饶有兴致地想把Agent跑在自己电脑上。

所以，Agent不是“突然冒出来”的，它是模型能力、工具协议、开源生态三股力量一起成熟的必然结果。本质上就像汽车工业：内燃机、变速箱、轮胎早就有了，但直到流水线完善，汽车才真正进入普通家庭。

3. Agent系统拆解：大脑、手、记忆和循环

3.1 大脑：LLM内核

Agent的大脑就是大语言模型，几乎所有Agent项目都会把一个LLM放在循环里反复调用。这里有个很重要的认知：模型在Agent里的角色不是“一次性生成答案”，而是“持续做决策”。每一轮循环，模型都要根据当前输入和历史信息判断下一步该干什么。

因此模型的选择直接决定了Agent的上限。推理能力强、指令遵循度高的模型，能减少很多不必要的回退和错误调用；反过来，如果一个模型连“三步以内该做什么”都分不清，再好的工具集也会被它用乱。你可能会遇到“Agent执行不下去”或者“Agent答非所问”的问题，很多次查到头来都是模型能力不够，而不是框架或者代码的问题。

3.2 手：工具层与Function Calling原理

工具层是Agent能“干活”的根本。一个Agent的工具集，可以包含任意东西：你可以注册一个网络搜索API，让Agent自己去搜新闻；可以注册一个数据库查询函数，让Agent根据用户问题自动生成SQL并查库；也可以注册一个画布绘制函数，让Agent在画布上画图。

设计工具集的时候有一个核心原则：每个工具最好只做一件具体的事情，参数定义要清晰，Description要写明白“什么时候用、什么时候别用”。这不是吹毛求疵。工具体系设计得越模糊，模型就越容易在多种场景下误调用。热搜里有“agent画图”这种词，其实画图本身不是Agent的自带能力，而是Agent调用了一个画图工具来完成任务，本质还是工具编排。

Function Calling实现上并不涉及特别高深的东西：程序先把工具列表放到请求里，模型根据用户的输入和工具描述决定要不要调用工具；如果调用，模型返回结构化参数，程序执行完把结果作为一条新消息放回对话记录，继续让模型做下一步决策。你可以把它理解为一个“内部循环的中间结果传递机制”。

3.3 记忆：工作记忆、长期记忆与向量检索

Agent的记忆分两个层次：工作记忆和长期记忆。

工作记忆就是上下文窗口里的对话内容。每一轮工具调用的结果都要往工作记忆里塞。所以上下文窗口长不长、会不会很快被塞满，直接决定了Agent能不能处理复杂任务。但窗口再大也会满，所以就要引入长期记忆。

长期记忆的做法也比较成熟：把重要信息做embedding向量化，存进向量数据库，需要的时候做相似度检索，把相关内容拉回工作记忆。这类Vector Storage（FAISS、Milvus、Chroma等）现在都是开源基础设施，直接接入就行。长期记忆的设计目标是让Agent在下一次任务中还能“想起”之前学过的偏好、历史结论、业务规则。

还有一个容易被忽略的“结构化记忆”：比如关键状态、已执行步骤的清单、任务进度标记。这类数据不一定塞进向量库，可能更合适放进关系型数据库或专门的Key-Value状态存储里。原因很简单，结构化数据可以精确查询，向量检索更适合做模糊语义召回。把记忆全部一股脑塞向量库，是一些新手项目经常踩的坑。

3.4 循环：ReAct模式是如何转起来的

当我们在图纸上画一个Agent，最核心的不是那些花花绿绿的功能模块，而是中间那个“循环”。目前最主流的循环模式叫ReAct，即Reasoning + Acting，推理和行动交替进行。

一个标准ReAct循环大概长这样：

1. 输入任务，模型根据任务和已有信息做推理，明确“现在我要解决什么”。
2. 模型决定是否调用工具。如果调用，会输出工具名和参数。
3. 程序执行对应工具，把执行结果返回给模型。
4. 模型看到结果，再次推理，判断是继续调用下一个工具还是结束了。
5. 循环往复，直到模型认为任务完成，输出最终答案。

这个循环里最关键的地方是“把每一步的思考和行动都记录下来”。每一轮的思考、调用、结果，都要作为消息重新进入上下文，让模型看到完整轨迹，而不是只给它最终答案。否则模型就会“失忆”，后面完全不知道之前发生了什么。很多框架帮你做的事情，本质上就是这个循环和记录机制的托管。

4. 三种主流架构模式与选型建议

4.1 ReAct：边想边做，灵活但容易跑偏

ReAct模式就是上面说的“思考+行动+观察结果”循环。它的优势非常明显：灵活。因为模型可以随时根据工具返回的反馈调整下一轮动作，能处理很多不确定性较高的任务。比如客服场景，用户需求千差万别，先查用户信息，再查订单状态，发现问题再查物流，每一步都是动态决策。

代价是可控性比较差。模型在自由决策的时候容易“跑偏”，一个简单的活儿可能会被它绕一大圈。解决方法是设置最大步数上限，比如循环10次没完成就直接放弃，避免无限制烧钱和死循环。在代码里加上这个限制，你就不用怕Agent突然变成一匹脱缰野马。

4.2 Plan-and-Execute：先做计划，再按计划执行

Plan-and-Execute模式思路完全不同：它先把整个任务拆成一个“计划列表”，然后按部就班地执行计划里的每一步。规划和执行分离，通常有一个专门的规划器模型先生成计划，执行阶段逐个验证状态，从而让整个流程更可控。

这种模式适合任务边界清晰、步骤明确的场景。比如“生成一份数据周报”：先读取数据库数据，再做统计计算，再生成图表，最后拼装文档。这些步骤是固定的，完全可以通过先规划再执行来保证稳定性。缺点是遇到计划之外的情况时，可能没有ReAct那么灵活。所以实际落地时，很多系统做了折中：用Plan-and-Execute做整体框架，但允许每一步执行时做局部深度的循环修正。

4.3 多Agent协作：让一个团队来干活

多Agent协作设计的思路，一句话解释就是把一个大任务拆给多个各司其职的Agent，让它们模拟一个团队。比如一个“产品经理Agent”负责拆需求，一个“开发Agent”负责写代码，一个“测试Agent”负责跑用例查问题。

这种模式的好处是职责分离，单个Agent的Prompt和工具集可以做得更专注，系统整体更容易扩展。代价是Agent之间的通信会产生额外的Token开销，而且如果角色职责划分不清，多个Agent之间可能互相推诿或者重复劳动。对新手来说，我的建议是先不要把多Agent方案拆得太碎，能用单个Agent干完的事就先别上团队，不然排查问题排查到崩溃。

4.4 到底怎么选：一个需求对照表

我平时做方案时会用一个粗略的对照表来判断：

表格只是参考，真实项目里基本都是多种模式的混合。比如一个复杂的“数据分析Agent”，整体会先做计划，但分析过程中又会插入多轮ReAct去查数据、画图、验证结论。架构是工具，不是教条，能解决问题就行。

5. Harness、Skill、框架，这些概念到底什么关系

5.1 Harness不是Agent本身，而是运行容器

最近很多热搜都在问“harness和agent区别”，这确实是个值得搞清楚的概念。Harness翻译过来叫“缰绳”或者“控制台”，在实际Agent项目里，它指的是：“一套把模型、工具、记忆、循环逻辑装配起来并负责运行时调度的容器/环境”。你可以理解为Agent运行的一个“座舱”。

举个马上能明白的例子：一个人会开车，这是“能力”；一辆车拥有方向盘、油门、刹车和各种传感器，这是“载体”。Harness就是那辆车，它提供了Agent运行所需的全部基础设施。它本身不产生智能，但它把智能需要的零件都组装好，而且还在驾驶位帮你配了仪表盘。很多开源项目做成“下载即用”的形态，拉下来其实就是一个Harness加上几个默认技能。

所以，当你看到某个东西叫“某某Agent Harness”的时候，别误以为它是某个特定的Agent，它更像一整套Agent的“运行框架/模板”，装上模型和工具之后，才能变成一个真正干活的Agent。

5.2 Skill是给Agent的“技能包”

Skill在Agent生态里对应的是“某个特定任务的处理能力模板”。举个例子，你给Agent注册一个“文档摘要Skill”，它内部可能定义了一系列步骤：读取文档、分段、提取关键信息、输出摘要，还可能搭配了一个专用的提示词模板和输出校验逻辑。

Skill的意义在于它会沉淀“经验”。同一个任务，如果每次都让模型从零开始规划，结果肯定不稳定；但如果把它封装成一个Skill，Agent遇到对应场景时直接“调用”，效率和稳定性都会更好。所以你可以把“Skill”理解成给Agent准备的预制工具包：需要画图就加载画图Skill，需要翻译就加载翻译Skill，Agent本身不用把每种能力的实现细节都记在脑子里。

5.3 框架是房子，Harness是装修，Skill是家具

把这三者的关系用一句话概括：框架相当于毛坯房，给了你结构骨架和空间规划（节点、边、状态），Harness相当于装修好的房子，水电、插座、空气开关都装好了，你拎包入住；Skill则是房子里已经备好的家具，住进来直接能用。

实际开发中，你是可以完全不碰“Agent”概念，直接基于框架手写一个循环的；也可以直接基于现成Harness快速体验Agent效果；还可以只给Agent配一堆Skill做垂直场景落地。这三层并没有“谁更高级”之分，只是抽象层级不同。选哪条路，取决于你有没有时间“装修”。

5.4 从专用Agent看未来方向

你可以关注到目前特别火的一类“专用Agent”，比如编程Agent（如Codex这类coding agent），它的目标非常聚焦——把代码写对、把测试跑通。这类Agent内部设计了代码沙箱、测试反馈、代码搜索等一系列专用工具，并把“跑通测试”作为整个循环的终止条件，效果往往比通用Agent强得多。

这个现象给了一个重要启发：Agent的能力边界很大程度上取决于“你对任务的理解深度和工具集设计”，而不是模型本身。通用Agent问题在于“什么都能干，但什么都不是特别专”；专用Agent把所有规划都押注在一个方向，自然能把执行链路打磨到极致。未来Agent生态肯定不是“一个通用Agent打天下”，而是几十上百个专用Agent各管一摊，彼此通过标准协议协作。

6. 实操：手把手搭一个最小可用的Agent

6.1 第一步：明确边界

不管你用哪个框架，动手前都要先想清楚一个问题：这个Agent要解决什么问题？

以“信息收集与整理Agent”为例，任务定义为：用户给定一个主题，Agent自动搜索相关信息，最终输出一份带来源的整理报告。边界划清楚之后，Agent该做什么就一目了然：搜索、阅读、总结、输出。如果这个任务用固定脚本也能做，那就没必要上Agent；但如果你希望它能根据搜索结果动态调整关键词、深入挖掘，那就适合用Agent。

6.2 第二步：准备模型环境和工具

代码层面，你需要先准备好以下基础环境：

• 一个大模型API，支持Function Calling（目前主流模型基本都支持）。
• 一个网络搜索接口或文档检索工具。
• 程序运行环境（Python即可）。

工具可以自己定义成函数，再用Function Calling标准化描述。我现在用一个极简例子说明，把搜索工具描述成一段JSON Schema：

[ { "type": "function", "function": { "name": "web_search", "description": "根据关键词在互联网上搜索相关信息，返回标题和摘要列表", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词" } }, "required": ["query"] } } } ]

描述越清楚，模型选错工具的概率就越低。这一步值得多花时间写Description，别偷懒。

6.3 第三步：写系统提示词

系统提示词承担了两个作用：给Agent定位角色、划清任务边界。比如这个信息收集Agent的提示词可以这么写：

你是信息收集助手。你的任务是根据用户给出的主题，通过web_search工具查找信息， 并在最后输出一份结构化的报告。要求： 1. 至少搜索3次，覆盖不同角度。 2. 每次搜索结果需要引用来源。 3. 如果第一次搜索不到有效信息，尝试换关键词再搜。 4. 最终报告用Markdown格式输出，包含概述、要点列表、来源链接。

注意，这里的重点是“约束行为”，而不是“约束回答风格”。Agent是来干活的，不是来写作文的，提示词里要把流程、质量要求、终止条件写清楚，后两者尤其重要。很多Agent跑偏，就是因为提示词里只写了“你要做一个聪明的助手”，却没告诉它什么时候应该停下。

6.4 第四步：搭一个极简ReAct循环

下面用一个极简代码展示ReAct循环的核心逻辑。这不依赖特定Agent框架，逻辑是通用的，换成任何支持Function Calling的模型都能跑：

import json def run_agent(task, messages, tools, max_steps=8): for step in range(max_steps): # 1. 把当前对话记录交给模型，让模型决定下一步 resp = client.chat.completions.create( model="deepseek-chat", messages=messages, tools=tools, ) msg = resp.choices[0].message messages.append(msg) # 2. 如果模型决定调用工具，就执行工具 if msg.tool_calls: for tool_call in msg.tool_calls: result = execute_tool(tool_call) # 根据工具名分发执行 messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result) }) else: # 3. 模型不再调用工具，说明任务完成，输出最终回答 return msg.content # 4. 到达最大步数，强制终止 return "Agent执行达到最大步数，任务未完成。"

这里execute_tool是一个分发函数，你在里面根据工具名去调用对应的Python函数即可。完整流程跑通之后，你可以试着调整max_steps、工具数量、提示词，观察不同配置对结果质量的影响。这个手写循环的价值在于，它能让你看清Agent每一步的决策过程，而不是把一切交给框架的黑盒。

7. Agent开发中的常见问题与排查技巧

7.1 死循环与执行终止，到底怎么排查

很多人在初跑Agent时都会遇到一类报错，比如“agent execution terminated due to error”或者“couldn't generate a response. please try again.”。

这类问题的本质原因通常有几种：模型输出格式异常导致工具调用解析失败、上下文超长、或者API服务端返回了限流/超时。排查路径我建议按顺序走：

• 先看日志里最后一次请求返回了什么。如果返回200但内容异常，问题在模型输出解析。
• 再看是不是重复执行同一步。如果模型一直在“调用同一个工具、得到同一个结果”，说明它没有办法从当前信息中收敛，这时候要检查上下文是否提供了足够的新信息。
• 最后看是不是达到了最大步数。很多框架默认限制步数，任务太复杂时直接终止是正常的，需要你适当调大上限或优化任务拆解。

有一个我长期在用的习惯：给Agent加上完整的trace日志。每轮记录模型输出、工具调用、返回结果、消耗Token。有了trace，任何问题都可以回溯到具体哪一步出的错，比瞎猜高效得多。

7.2 工具参数幻觉和越权调用

Agent在调用工具时不是绝对可靠的，它有可能“编造”参数。比如你有一个获取天气的工具，模型可能在没有用户提供城市的情况下，自己猜一个城市填进去。这会导致Agent拿着幻觉参数去执行，返回一堆没意义的结果。

解决这个问题有三个手段：

• 在工具Schema里，对每个参数写清楚“必填还是可选”，不要留模糊地带。
• 对缺失的关键参数，让Agent先向用户追问，不要自己乱猜。
• 在程序侧做参数校验和结果校验，工具执行前检查参数是否合法，执行后检查结果是否为空。发现非法参数直接返回错误信息，告诉模型“参数不合法，请重新提供”。

工具权限也要做最小化。Agent能调用“查询订单”工具，不代表它应该能调用“删除订单”工具。给Agent的工具越多，它犯错的概率越高。让Agent只访问它完成任务真正需要的资源，这是最基础的安全意识。

7.3 上下文爆炸与记忆损耗

Agent每调用一次工具，就会把结果塞进上下文。当一个任务步骤很多时，上下文很容易膨胀。上下文一旦太长，有两个后果：一是Token成本上升，二是早期的关键信息会被“挤出去”，模型记不住最初的目标。

处理这个问题的常用做法是“摘要压缩”。当上下文接近阈值时，把前面的对话记录交给模型生成一段摘要，替换掉原始内容。另一种做法是“关键信息抽取”，每轮结束后只保留重要的状态信息（比如用户目标、已完成的步骤、下一步要做的），忽略过程中的噪音。

说到底，Agent的“记忆”是需要你主动设计的，不能完全交给上下文窗口自生自灭。

7.4 Agent的安全与成本控制总结

我整理了一份常见问题的速查表，你可以把它当作开发时的检查清单：

成本控制是比较容易被忽略的问题。一个Agent任务动辄调用十几次模型接口，成本是普通问答的十倍以上。如果任务比较复杂，建议做“预算上限”，比如设定单次任务最大Token数，超出就强制结束，然后把中间结果缓存下来。这不是抠门，而是Agent工程化的基本素养。

8. Agent学习路线与面试考点速查

8.1 学习路线：从Demo到生产要过五关

如果你现在是从零开始学Agent开发，我建议按下面的路径走，这条路线我自己验证过，避开了不少弯路：

• 第一关：跑通一个现成框架的Demo。LangChain、LangGraph、AutoGen随便选一个，先把Agent跑起来，感受一下它怎么对话、怎么调工具。这个阶段别追求深入原理，目标是“建立体感”。
• 第二关：手写一个最小ReAct循环。不依赖框架，自己写几百行代码把“模型决策-工具执行-结果回填-再决策”这个循环跑通。这关过了，你就不会觉得Agent是黑盒了。
• 第三关：深入理解一个框架的源码。只看一个，别贪多，把循环调度、状态管理、工具注册机制搞清楚。框架能解决什么问题、不能解决什么问题，这个阶段你会有自己的判断。
• 第四关：做真实的业务需求。找一个小而完整的场景，比如“客服工单分类与自动回复”“行业资讯汇总Agent”，把从需求到上线的完整流程走一遍，包括prompt优化、工具设计、错误处理、成本控制。
• 第五关：选一个方向深耕。记忆系统、规划策略、多Agent协作、安全对齐，每个方向都有非常深的水，选一个做到别人一问你能讲透的程度。

这套路线最大的特点是慢就是快。跳过第二关直接学框架的人，很容易在排查问题时陷入“框架为什么这么跑”的迷茫；踏踏实实手写一遍，所有疑问都会变成你的知识。

8.2 高频面试考点与真题解析

“Agent八股”这词虽然有点戏谑，但确实说明Agent面试已经有了一些稳定考点。我把它们分成四类：

第一类：概念理解题。典型的像“Agent和传统聊天机器人有什么区别”“ReAct中Reasoning和Acting分别指什么”。这类题考察的是你能否把抽象概念具象化，能拿生活例子解释清楚会加分。

第二类：架构设计题。比如“如果让你设计一个客服Agent，你会用什么架构，为什么”“ReAct和Plan-and-Execute怎么选”。这类题核心不是考标准答案，而是考你在不同约束条件下做权衡的能力。建议准备一个自己真实做过的例子，用STAR法则讲出来。

第三类：工程实现题。比如“Agent的记忆如何实现”“上下文窗口快满了怎么办”“怎么防止Agent死循环”。这类题就是这篇第7章内容，你踩过的坑在这里反而成了优势，可以大方分享踩坑经历。

第四类：安全与成本题。比如“如何避免Prompt注入”“如何控制Agent的单次任务成本”。很多候选人答不好这类题，因为只关注了功能实现，没有关注工程落地。能主动提到工具权限最小化、Token预算上限的候选人，面试官一般会比较认可。

还有一些具体真题，比如“Skill和Agent的区别是什么”，上面第5章已经讲过；再比如“编程Agent为什么比通用Agent执行效果好”，可以从专用工具集和终止条件设计角度回答。

我个人最深的体会是：做Agent久了，你会越来越敬畏“边界”。它不是一个能完全撒手不管的工具，更像一个能力很强但需要盯着的实习生。你给它明确目标、合适工具、清晰边界，它能帮你干很多活；但你如果以为它无所不能，把关键决策完全交给它，它迟早会用一种你没想到的方式跑偏。这也是为什么现在越来越多人强调“Agent工程化”——真正的差异化不在于模型有多大，而在于你如何规划任务边界、设计工具、管理记忆、控制风险。至少从目前看，这就是Agent落地最实在的方向。