1. 什么是智能体？它与普通聊天机器人、大语言模型有什么区别？【第1章】

智能体是能够感知环境、根据目标选择行动，并利用行动反馈继续调整行为的系统。判断一个系统是否具有智能体特征，关键要看它有没有形成“获取信息—决策—执行—反馈”的闭环。 大语言模型通常是其中的决策组件，负责理解任务、生成计划或选择工具。模型本身并不自动拥有文件访问、数据库查询、长期记忆等能力，这些需要外围系统提供。 普通聊天机器人主要完成输入到文本回复的映射；智能体还可以执行实际操作。例如，用户要求查询订单时，聊天机器人可能解释查询方法，智能体则能够调用订单工具，读取结果，再决定是否需要进一步查询物流。 不过，二者不是绝对互斥的类别。聊天界面也可以承载智能体系统，而传统的规则系统也可能构成智能体，并不是使用了 LLM 才叫智能体。第1章原文 2. 什么是 PEAS 模型？如何用它分析智能旅行助手？【第1章】 PEAS 是描述智能体任务环境的框架，分别代表性能度量、环境、执行器和传感器。 以旅行助手为例： Performance，性能度量：行程是否满足预算、时间安排是否可行、推荐是否符合偏好，以及完成任务的成本和耗时。 Environment，环境：旅游目的地、天气、酒店、交通、票务服务及其他用户的预订活动。 Actuators，执行器：搜索景点、查询路线、生成行程，以及获得授权后的预订操作。 Sensors，传感器：用户输入、天气 API 返回值、酒店查询结果、订单状态等信息来源。 这个环境通常具有部分可观察性、动态性和不确定性。例如，助手看到的酒店库存只是一段时间内的局部信息，用户确认时库存可能已经变化。 因此，系统不能只生成一次计划就结束，而应保存必要状态，并在关键操作前重新验证信息。PEAS 的价值是帮助开发者先明确“什么算成功、能看到什么、能做什么”，再选择模型和工具。 3. Workflow 和 Agent 有什么区别？应该如何选择？【第1章】 Workflow 的主要执行路径由开发者预先定义；Agent 则允许模型根据当前状态，在一定范围内决定下一步做什么、调用什么工具以及何时结束。 需要注意，Workflow 也可以包含条件分支、循环和 LLM 节点，因此不能简单理解成“固定直线流程”。真正的区别在于：执行路径主要由程序规则决定，还是由模型在运行时决定。 例如，格式固定的报销审批适合 Workflow，因为规则清晰、审计要求高；开放式资料研究更适合 Agent，因为需要根据搜索结果调整方向。 工程上通常采用混合方案：外层 Workflow 控制权限、状态和关键流程，内部 Agent 处理信息理解、搜索与计划生成。这样既保留灵活性，也能限制任务的不确定性。 面试中最好进一步说明选择依据：任务可预测性、错误成本、延迟要求、可审计性，以及是否真的需要动态规划。 4. 智能体为什么从符号主义发展到学习驱动？符号系统还有价值吗？【第2章】 符号主义通过显式知识和逻辑规则解决问题。典型专家系统由知识库和推理机组成，能够从事实出发进行正向推理，或从目标出发进行反向推理。 它的优势是规则清晰、结论可追溯，但知识获取成本很高。现实世界存在大量例外、模糊表达和隐含常识，很难全部编码成规则；规则增加之后，还会出现冲突和维护困难。 学习驱动的方法把一部分知识获取过程交给数据和训练。神经网络可以学习语言、图像等非结构化输入中的模式，LLM 则进一步提供较通用的语言理解和生成能力。 但学习方法没有消除规则的价值。实际系统可以让 LLM 理解用户意图，再由规则引擎检查权限、金额和业务约束。 因此，这段历史带来的工程启示是：**用学习系统处理开放信息，用明确规则约束必须可靠的行为。**并非所有问题都应该交给模型自由判断。第2章原文 5. “心智社会”对多智能体系统有什么启发？多智能体一定优于单智能体吗？【第2章】 “心智社会”强调，复杂智能可以来自多个相对简单机制之间的协作，而不一定依赖一个统一、全能的推理中心。 映射到多智能体系统，可以把研究、编码、测试、审查等职责分别交给不同角色。每个角色拥有更集中的任务、上下文和工具范围，通过交换结果完成整体目标。 但增加智能体数量并不保证效果提升。系统同时会增加通信开销、重复工作、上下文传递损失和协调难度。如果所有角色使用相同模型、相同信息，也可能重复相同错误。 因此，是否采用多智能体，应看任务是否存在清晰、相对独立的分工，以及这种分工是否能带来可测量的收益。 例如，多个研究员分别调查不同技术方案，再由协调者比较，通常比让多个角色反复讨论同一段材料更有意义。面试中应强调通过单智能体基线和消融实验验证收益。 6. Transformer 的自注意力机制是什么？为什么它适合构建大语言模型？【第3章】 自注意力让序列中的每个位置，根据内容相关性，从其他位置聚合信息。输入表示经过不同线性变换得到 Query、Key 和 Value，其基本形式为： \[ \operatorname{Attention}(Q,K,V) = \operatorname{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V \] 其中，Query 和 Key 用于计算相关程度，Value 提供被聚合的信息。除以 是为了控制点积数值规模，避免 Softmax 过度饱和。 多头注意力允许不同头在不同表示空间学习关系，例如指代关系、局部结构和长距离依赖。模型还需要位置信息，因为仅靠内容注意力不能充分区分词序。 与循环网络相比，Transformer 在训练阶段更容易并行处理序列位置，也有利于利用大规模数据和算力。 需要区分训练与生成：训练可以并行计算多个位置，标准自回归生成仍然需要逐步产生后续 token。第3章原文 7. Decoder-Only 模型如何生成文本？Token 与上下文窗口有什么关系？【第3章】 Decoder-Only 模型采用自回归方式，根据已有 token 预测下一个 token： \[ P(x_1,\ldots,x_T) = \prod_{t=1}^{T}P(x_t\mid x_{<t}) \] 训练时使用因果掩码，阻止某个位置读取后面的答案；生成时未来内容尚未产生，因此模型只能根据当前上下文继续生成。 Token 是分词器处理文本后的基本单位，不一定对应一个汉字、单词或字符。同一段文本在不同分词器下，token 数量可能不同。 上下文窗口约束模型一次调用可处理的信息量。系统指令、用户消息、历史记录、工具描述、工具结果，以及需要预留的输出空间，都要纳入预算管理。 对 Agent 来说，调用次数增加会使历史快速膨胀，因此需要摘要、检索和选择性保留。不能因为模型支持长上下文，就把全部日志无差别地塞进去。 8. 如何为智能体设计有效的提示词？Temperature、Top-p 分别有什么作用？【第3章】 有效提示词应明确任务目标、输入信息、约束、可用工具、输出格式和结束条件。角色设定可以辅助理解，但仅写“你是一位专家”通常不够。 对于复杂任务，可以提供少量示例，让模型理解工具参数、结果格式和异常处理方式。涉及外部事实时，还应说明信息来源要求，以及证据不足时如何表达不确定性。 Temperature 调整输出概率分布的平缓程度：较低时通常更集中，较高时通常更分散。Top-p 则选择累计概率达到阈值的候选 token 集合，再进行采样。 工具调用、结构化提取等任务通常更重视稳定性；创意生成可以容许更多变化。但参数应通过任务评估来选择，不能认为某个温度区间适用于所有模型。 尤其要注意：**降低温度不等于保证事实正确，也不一定保证完全可复现。**提示词和采样参数无法替代工具验证与程序校验。 9. 如何为 Agent 选择模型？为什么更大的模型也会产生幻觉？【第3章】 选模型应以任务表现为中心，综合考虑指令遵循、工具调用、推理能力、上下文处理、延迟、成本和部署条件。 例如，分类和字段提取可能不需要最强模型；复杂规划和跨文档分析则更依赖推理与上下文能力。可以采用分层路由，把简单步骤交给较便宜的模型，把关键决策交给能力更强的模型。 缩放法则说明，在一定条件和范围内，模型规模、数据量与计算投入和损失之间存在规律，但它并不意味着参数越多，所有任务就一定越好。 幻觉来自多种因素，包括训练数据问题、知识缺失、上下文误读以及生成目标与事实核验之间的差异。更大的模型仍可能给出流畅但错误的回答。 因此，应通过真实任务集比较模型，并配合检索、计算工具、结构化校验和事实核验。模型选择是系统设计的一部分，不能单独承担可靠性保证。 10. ReAct 的核心流程是什么？它为什么适合工具使用场景？【第4章】 ReAct 将推理与行动交替组织：模型根据当前信息决定下一步行动，系统执行工具，把真实观察结果交回模型，再进入下一轮。 以旅行推荐为例，系统先查询天气，获取结果后再选择景点搜索条件。如果发现下雨，就可以调整为室内活动。这种方式避免模型在缺少信息时一次性写完全部计划。 实现时通常包含模型调用、行动解析、工具执行、观察回填和结束判断。观察必须来自实际执行结果，不能让模型自行编造工具反馈。 ReAct 的优势是能够利用新信息调整路径，适合搜索、调试和信息不完整的任务。缺点是多轮调用带来延迟，也可能陷入重复搜索或局部决策。 教程中的 Thought 字段是教学性组织方式。生产系统可以保留简短决策摘要和工具轨迹，不必要求模型公开完整的内部推理过程。第4章原文 11. Plan-and-Solve 与 ReAct 有什么区别？静态计划失败时如何处理？【第4章】 Plan-and-Solve 先把目标分解为步骤，再按计划执行；ReAct 更强调根据当前观察逐步决定行动。 前者适合任务结构较清晰、步骤依赖较明确的场景，例如整理报告、分阶段分析数据。后者更适合执行过程中会不断发现新信息的任务。 静态计划的风险是，最初制定计划时信息不完整。例如，旅行计划安排了某个景点，但后续发现当天闭馆，继续严格执行原计划就没有意义。 工程上可以加入动态重规划：每一步执行后检查结果是否满足预期；如果前提失效，就保留已完成且仍有效的部分，重新生成剩余步骤。 计划最好具有任务编号、依赖关系、状态和验收条件。这样系统才能区分“没有完成”“执行失败”“已完成但结果无效”，避免从头重复全部任务。 12. Reflection 如何提升答案质量？它为什么不一定有效？【第4章】 Reflection 通常包含生成初稿、评审反馈和修改结果三个阶段。它让模型在首次完成任务后，再检查事实、逻辑、覆盖程度和实现质量。 例如，生成代码后，可以结合测试失败信息进行反思，再修改代码。相比只说“请检查一下”，具体的评审标准和外部反馈更容易带来有效改进。 它不一定有效，是因为评审模型本身也可能出错。同一个模型可能保留原来的盲点，也可能把正确答案改错。如果反馈只是“还可以更好”，修改过程可能只增加措辞，没有提高质量。 因此，应优先采用可验证信号，如测试结果、规则校验、引用检查和实际执行反馈，并保留历史最佳版本。 终止条件也应具体，例如关键检查通过、连续两轮没有收益、达到时间或调用预算。Reflection 是以额外计算换取潜在质量提升，需要评估收益是否超过成本。 13. 如何避免 Agent 无限循环、重复调用工具或在错误中卡死？【第4章】 应同时设置资源限制和行为检测。 资源限制包括最大步骤数、总耗时、token 预算和工具调用次数。行为检测则关注相同工具是否以相同参数反复调用、是否一直收到相同错误、任务状态是否长期没有变化。 错误处理需要分类： 临时网络故障可以有限重试，并使用退避策略。 参数错误应把结构化错误反馈给模型，促使其修改参数。 权限不足、资源不存在等错误，不应原样无限重试。 信息不足时可以提出明确问题，或结束并说明缺失条件。 对于有副作用的工具，还需要幂等控制。例如支付请求超时后，应该先查询订单状态，而不是直接再次扣款。 最终退出时应保留已完成内容、失败原因和未完成步骤。达到循环上限只代表执行被终止，不能被系统包装成任务成功。 14. 如何理解 Coze、Dify、FastGPT、n8n 的定位差异？【第5章】 按照教程的介绍，可以从应用构建方式和主要侧重点理解这些平台： **Coze：**偏向通过可视化配置、插件和发布渠道快速构建对话应用。 **Dify：**侧重整合模型调用、知识检索、应用编排等 LLM 应用能力。 **FastGPT：**教程重点展示知识库问答和可视化流程。 **n8n：**更强调连接外部系统、触发器和业务自动化，在流程中加入 AI 能力。 选型时应先列出需求，再检查平台能否满足：数据部署位置、权限管理、业务系统连接、流程复杂度、调试能力、成本和迁移难度。 不能仅凭“拖拽方便”决定是否适合生产，也不能把低代码理解为不需要工程能力。 平台功能变化较快，面试时更适合解释选型维度，不宜把教程某个时期的功能限制直接当作当前事实。第5章原文 15. 用低代码平台构建“每日 AI 简报”，如何保证流程稳定？ 可以把流程拆成定时触发、获取内容、清洗去重、筛选、摘要、格式化和发送几个步骤。 每个节点都应有明确的数据契约，例如新闻条目包含标题、来源 URL、发布时间和正文摘要，避免依赖前一个节点返回的随意文本。 可靠性方面，需要处理搜索失败、空结果、字段缺失、重复新闻以及模型输出格式错误。对摘要结果，应检查关键结论是否有来源支持，而不是只检查文字是否流畅。 发送环节尤其需要幂等性。例如，以日期和接收对象生成唯一任务标识，避免平台重试时重复发送同一份简报。 还应记录每个节点的耗时、输入输出摘要和错误信息。这样当简报缺少内容时，可以判断问题发生在抓取、筛选还是生成阶段。 这些是对教程案例的工程延伸，核心思路是把 AI 节点纳入可观察、可恢复的业务流程。 16. AutoGen、AgentScope、CAMEL 和 LangGraph 应该如何比较？ 可以从教程展示的主要抽象方式比较： **AutoGen：**以智能体之间的消息与对话协作为重要组织方式。 **AgentScope：**强调消息、工具、记忆及多智能体应用的工程组织。 **CAMEL：**通过角色扮演和任务约束，让具有互补职责的智能体协作。 **LangGraph：**将执行过程表示为状态、节点和边，显式控制分支与循环。 这些框架的能力存在重叠，不能理解为某个框架只能做一种任务。 实际选型应回答：业务更需要开放式协作，还是明确的状态迁移？是否需要中断恢复、人工介入、并发执行？团队是否能够定位框架内部问题？ 面试中比记忆功能列表更有价值的，是说明为什么某种抽象适合当前任务。例如，审批与异常分支较多的系统，通常更需要清楚表达状态和控制流。第6章原文 17. 如何用状态图实现 Agent？为什么状态管理很重要？ 状态图包含三个基本部分：State 保存任务信息，Node 执行计算或操作，Edge 决定下一步进入哪个节点。 例如，一个问答 Agent 可以包含“分析请求”“检索资料”“检查证据”“生成答案”节点。如果证据不足，条件边把流程送回检索；证据充分时进入生成。 State 可以保存用户目标、消息历史、检索结果、错误信息、调用次数和完成状态。节点通常返回状态更新，再由框架按约定合并。 设计时要明确每个字段的更新语义。例如，消息列表应该追加，当前状态字段通常应该覆盖；并发分支更新同一字段时，需要定义合并规则。 工程延伸中还应考虑检查点与恢复。但恢复到某个节点后，不能盲目重复已经发生的外部写操作，因此状态恢复必须与工具幂等性一起设计。 18. 多智能体系统如何防止职责重叠、消息混乱和无休止讨论？ 首先，为每个智能体定义明确的责任边界：接收什么输入、产出什么结果、能使用哪些工具，以及什么情况下必须交接。 其次，把交接信息结构化。例如，研究员输出结论、证据和待确认事项，审查员输出问题列表及严重程度。相比把完整对话历史转发给所有角色，这种方式更节省上下文，也更容易验证。 调度规则需要明确：谁有权分配任务、谁决定验收、谁可以结束流程。轮流发言本身并不能保证任务推进。 还应设置可检查的完成标准，比如测试通过、关键问题都有证据支持、审查没有阻断项，而不是让智能体仅凭“大家都同意了”判断完成。 最后，通过日志识别重复任务、相互等待和空转对话。多智能体架构的重点是职责与通信设计，角色名称只是表面。 19. 如果从零设计一个 Agent 框架，你会划分哪些核心模块？ 可以划分为模型适配、消息与配置、Agent 执行器、工具系统、上下文管理和运行观测几个模块。 模型适配层统一不同服务商的调用接口；消息与配置模块规范角色、内容和运行参数；Agent 执行器实现 ReAct、计划执行等控制逻辑；工具系统负责注册、发现、参数验证和执行。 上下文管理负责历史、记忆和检索结果的组织，运行观测则记录耗时、成本、错误及执行轨迹。 教程中的 HelloAgents 强调轻量设计、统一接口和工具抽象。其教学价值在于让开发者能够理解控制流，而不是只会调用高层 API。 工程上应避免过早设计过多抽象。先让一个完整任务可靠运行，再把稳定共性提取出来。同时保留服务商能力差异，不能因为统一接口就假设所有模型都支持相同功能。第7章原文 20. Function Calling 与用正则解析模型输出有什么区别？ 正则解析通常要求模型输出某种文本格式，例如 Action: search(...)，然后程序从字符串中提取工具名称和参数。 这种方案适合教学原型，但容易受到换行、引号、嵌套对象和额外解释文字影响。正则匹配成功，也不代表参数类型或含义正确。 Function Calling 通过工具 Schema 向模型声明可调用函数，模型返回结构化调用请求，通常更便于解析和校验。 需要强调，**模型只是提出调用请求，真正执行函数的是宿主程序。**应用仍然需要验证工具是否允许调用、参数是否合法、是否具有相应权限，并把实际结果返回模型。 即使使用结构化调用，也可能出现选择错误工具、填写错误业务值等问题。因此，Function Calling 改善了交互可靠性，但没有替代业务验证。 21. 一个好的工具接口应该如何设计？工具很多时怎么办？ 工具应具备清晰的名称、职责说明、输入 Schema 和输出契约。描述需要说明适用场景、必要参数、限制条件，以及是否产生副作用。 参数应使用明确类型，避免把多个含义塞进一个自由文本字段。输出最好区分成功、失败、可重试错误和业务错误，并保留必要的来源与时间信息。 工具粒度需要平衡。过细会导致模型频繁调用、增加协调成本；过粗则可能隐藏复杂行为，难以验证和恢复。 当工具达到几十或上百个时，不宜把全部定义放入每次请求。可以按任务类别筛选工具，再通过关键词或语义检索选择少量候选。 工具注册中心还可以统一处理参数校验、超时、权限和日志，让具体工具专注业务逻辑。对写操作，应额外考虑幂等性和审计。 22. 工作记忆、情景记忆、语义记忆和感知记忆分别是什么？ 教程将记忆分为四类： **工作记忆：**保存当前任务和最近交互，例如正在处理的问题、刚调用工具的结果。 **情景记忆：**保存具体事件和经历，例如某次任务的时间、过程及结果。 **语义记忆：**保存抽象事实、概念和关系，例如用户长期偏好、领域知识。 **感知记忆：**保存与文本、图像、音频等感知输入有关的信息。 这些分类描述的是信息功能，不等同于具体数据库。向量数据库可以支持多种记忆，结构化数据库也可以保存事件和偏好。 记忆管理还需要解决写入、检索、更新、遗忘和隔离。例如，用户的新偏好可能覆盖旧偏好，临时状态应过期，不同用户的信息不能混用。 面试中要避免把“保存全部对话”直接等同于良好记忆系统。真正的难点是让正确的信息在正确时间被取回。第8章原文 23. RAG、记忆系统和微调有什么区别？ RAG 在推理时从外部知识源检索相关材料，把材料提供给模型生成答案，通常不修改模型参数。 记忆系统主要保存智能体的历史交互、任务经验和用户状态。它可以借助与 RAG 相似的检索技术，但更关注信息何时产生、属于谁、是否仍然有效。 微调则通过训练改变模型参数，主要用于改善输出方式、任务行为和特定能力。它不是实时更新事实的理想替代品，也不保证模型准确记住所有训练信息。 例如，企业制度问答可以用 RAG 获取最新文档；用户偏好通过记忆系统保存；固定术语、输出格式和业务对话风格可以考虑微调。 三者可以组合使用。选择时先判断问题来自知识缺失、历史状态缺失，还是行为模式不符合要求，避免所有问题都用同一种技术解决。 24. 一个完整的 RAG 系统包含哪些环节？如何优化检索效果？ RAG 可以分成离线准备和在线问答两部分。 离线阶段负责文档解析、清洗、分块、添加元数据、生成向量和建立索引。在线阶段负责理解查询、检索候选片段、重排序、组装上下文，以及生成带依据的答案。 分块过小可能丢失语义，过大则会混入无关内容。因此应结合标题、段落、表格和文档结构切分，并保留来源与相邻关系。 检索方面，可以将关键词检索与向量检索结合：前者有利于精确匹配编号和专有名词，后者有利于处理不同表达。再通过重排序模型筛选更相关的候选。 优化时应分开检查检索和生成。若关键证据根本没有被召回，换一个更强的生成模型通常不能根治问题；若证据已经存在，则应检查上下文组织和回答约束。 25. MQE 和 HyDE 是什么？它们一定能提升 RAG 效果吗？ MQE，即多查询扩展，是让模型从原问题生成多种相关表达，再分别检索、合并和去重。它主要缓解用户措辞与文档措辞不一致的问题。 HyDE，即假设性文档嵌入，是先生成一段可能回答问题的文档，再利用这段文本的向量检索真实资料。它试图缩小短问题与长答案之间的表示差距。 例如，用户只问“Agent 为什么总忘事”，MQE 可以扩展为记忆持久化、上下文截断等查询；HyDE 则可能生成一段关于工作记忆和长期记忆的假设说明，用于召回相关文档。 但两者都会增加成本，也可能引入查询漂移。原问题已经明确时，扩展反而可能带来噪声。 尤其要注意：**HyDE 生成的假设文本不能当作事实证据。**最终答案必须以检索到的真实资料为依据。 26. 上下文工程与提示工程有什么区别？ 提示工程主要关注如何表达指令，例如角色、任务要求、示例和输出格式。 上下文工程关注模型一次调用能看到的全部信息，包括指令、历史消息、工具定义、工具结果、检索材料、记忆和当前任务状态。核心问题是如何在有限预算内提供最有用的信息集合。 一个 Agent 即使提示词写得很好，如果同时收到大量过期日志、重复材料和互相矛盾的历史，也可能做出错误决策。 因此，上下文工程需要解决信息获取、相关性筛选、结构组织、去重压缩和生命周期管理。 例如，代码维护助手不一定需要读取整个仓库，而可以先获得目录和搜索结果，再按需要读取少量文件。这样既降低成本，也减少无关信息干扰。 衡量上下文质量时，应关注任务效果和证据覆盖，不能只看窗口是否还有空余。第9章原文 27. 教程中的 GSSC 流水线是什么？如何落实 token 预算？ GSSC 包含四个阶段： **Gather：**汇集系统指令、历史、记忆、检索结果等候选信息。 **Select：**根据相关性、新近性和重要性选择内容。 **Structure：**按不同用途组织信息，明确来源和边界。 **Compress：**在超出预算时压缩冗余内容，保留关键事实。 实现时应先预留输出空间，再给不同上下文区域分配预算。用户最新要求、关键约束和未完成任务应优先保留，而重复工具输出通常可以更早清理。 不能只按相似度排序，因为有些不直接匹配当前问题的信息仍然是硬约束，例如禁止修改某个文件、预算上限或已经确认的决策。 压缩后还应检查重要实体、数字、否定条件和依赖关系是否保留。摘要更短并不代表更好，丢失关键条件可能导致后续任务偏离。 28. 长程 Agent 如何在多次上下文压缩后保持任务连续性？ 应把重要任务状态放到上下文之外，以结构化形式持久保存，而不是完全依赖对话历史。 需要保存的内容通常包括总目标、用户约束、已完成步骤、关键决策、证据位置、当前阻塞和下一步行动。教程中的 NoteTool 就提供了适合此类记录的思路。 每次恢复或进入新阶段时，系统先读取任务状态，再按需要检索详细材料。原始日志可以保留在外部，供核查使用，无需全部重新放入模型上下文。 即时文件访问工具也很有价值：当需要某个实现细节时，重新读取对应文件可能比长期携带整个文件内容更可靠。 工程上应为状态增加更新时间和版本，避免旧摘要覆盖新进度。完成与未完成必须清楚区分，尤其不能把“准备执行”记录成“已经执行”。 29. MCP 是什么？Host、Client、Server 分别负责什么？ MCP 用于标准化 AI 应用与外部工具、资源等能力之间的连接，降低为每个应用和服务重复编写适配器的成本。 Host 是承载模型交互的应用，负责会话和整体控制；Client 是 Host 内负责协议通信的组件；Server 则暴露具体能力，例如文件访问或数据库查询。 MCP 的核心服务端能力包括： **Tools：**可以调用的操作。 **Resources：**可以读取的上下文资料。 **Prompts：**可复用的提示模板。 MCP 与 Function Calling 位于不同层面：前者解决应用如何发现和访问外部能力，后者解决模型如何表达结构化调用意图。两者可以配合使用。 还应区分协议与 SDK。某个 SDK 提供的内存测试传输或便利封装，不等同于协议规定的独立标准传输。MCP 也不会自动保证工具可信或调用已获授权。第10章原文；MCP 官方核心能力说明 30. A2A 与 MCP 有什么区别？Agent Card、Task 和 Artifact 是什么？ MCP 主要关注外部能力的接入；A2A 主要关注智能体服务之间如何交换请求、委托任务、跟踪状态和交付结果。 A2A 中，Agent Card 描述一个智能体的身份、能力、端点及认证要求；Task 表示有状态的工作单元；Artifact 表示任务产出的成果，例如报告或结构化数据。 例如，主智能体可以通过 A2A 把“调查某个技术方案”的任务交给研究智能体。研究智能体内部再通过 MCP 调用搜索和文档工具，最终返回报告工件。 两种协议可以出现在同一个系统中，并不互相替代。 需要避免的误区是：使用 A2A 不代表系统天然去中心化，也不会自动消除单点故障。是否采用中央协调器、如何部署和容灾，仍然是架构层面的选择。A2A 官方核心概念 31. ANP 试图解决什么问题？为什么服务发现与身份验证很重要？【第10章】 当智能体跨组织、跨平台协作时，仅有一套调用格式还不够。系统还需要知道有哪些服务、各自能做什么、如何联系，以及对方身份是否可信。 ANP 探索面向智能体网络的标准化描述、发现和通信机制，并结合去中心化身份等技术，支持更开放的互联方式。 例如，旅行智能体需要找到具有某地区票务能力的服务，可以先发现候选服务，再检查能力描述和身份信息，最后建立调用关系。 需要区分三个概念：服务发现回答“在哪里”，身份认证回答“是谁”，权限控制回答“允许做什么”。验证了身份，也不能直接推断其有权访问用户的全部数据。 工程上还需要超时、版本兼容、速率限制及调用审计。面试时应把协议目标与具体部署能力分开，不能认为接入协议就自动完成了这些工作。ANP 官方项目 32. SFT 与 Agentic RL 有什么区别？为什么训练 Agent 要关注完整轨迹？ SFT 通过示范数据训练模型，提高目标输出在给定输入下的概率，适合学习任务格式、工具使用模式和基本行为。 Agentic RL 把模型视为策略，让它在多步交互中选择行动，并根据任务奖励优化行为。关注的对象可以包括工具选择、行动顺序、错误恢复和最终完成情况。 例如，代码维护任务不仅要求最终报告写得好，还要求正确读取文件、修改代码、运行检查，并根据失败结果修复。这些步骤共同构成执行轨迹。 多步任务的重要难点是信用分配：最终失败可能由很早的一次错误选择造成，而不是最后一步的问题。 SFT 经常用于建立良好起点，但不是所有 RL 方案的强制前置条件。还要注意，单纯在数学问答上做奖励优化，并不能自动证明模型具备完整的多工具交互能力。第11章原文 33. LoRA 的原理是什么？为什么能降低微调成本？ LoRA 冻结原始权重，仅训练一个低秩增量。对于权重矩阵 ，可以表示为： 若 的维度为 ，而低秩维度为 ，新增参数量是 ，通常远少于原来的。 成本降低主要来自可训练参数及其梯度、优化器状态的减少。对于兼容的线性层，实现允许时也可以把增量合并到原权重中。 但不能把“可训练参数减少很多倍”直接等同于“总显存也减少同样倍数”。基础模型、激活值、序列长度和训练批量仍会占用显存。 LoRA 的效果受秩、目标模块、数据质量和训练配置影响。它不保证一定优于或一定弱于全量微调，需要在具体任务和资源约束下验证。 34. GRPO 的核心思想是什么？它与 PPO 的主要区别是什么？ GRPO 针对同一个问题采样一组回答，根据组内奖励计算相对优势，从而减少对独立价值模型的依赖。 一种常见的结果奖励优势估计为： 高于组内平均表现的回答得到正向优势，较差回答得到负向优势。训练时再结合策略概率比、裁剪等机制控制更新。 需要区分旧策略与参考策略：旧策略用于采样和计算重要性比率；参考策略通常用于 KL 约束，限制当前策略过度偏离。两者作用不同，不能混用。 GRPO 省去了单独价值模型的一部分负担，但仍有多回答采样成本。如果一组回答奖励完全相同，该组就缺少相对区分信号。 它也不保证天然稳定，效果仍依赖奖励设计和训练配置。GRPO 原始论文 35. 如何为 Agent 设计奖励函数？什么是奖励投机？ 奖励函数应尽量反映真实任务目标。例如，代码任务可以奖励测试通过和需求满足，同时约束无效工具调用与过高成本。 仅奖励格式或调用次数很危险。模型可能学会输出漂亮的格式、频繁调用工具，却没有完成任务。这就是奖励投机：优化了代理指标，却偏离真实目标。 可以将结果正确性作为核心，再加入必要的约束项。过程奖励有助于缓解稀疏反馈，但必须避免把某种固定操作路径误当成唯一正确方式。 奖励函数不需要本身可微，策略梯度方法可以利用数值反馈更新模型。关键在于反馈是否可靠、是否有区分度、是否容易被利用。 评估时还要使用独立任务集检查泛化。如果训练奖励上升，但真实任务成功率没有提升，就应检查奖励漏洞、数据泄漏和过拟合。 36. BFCL 和 GAIA 分别评估什么？为什么不能只看工具调用格式？ BFCL 重点评估函数调用相关能力，例如选择工具、生成参数、处理多工具或多轮调用，以及判断何时不应该调用工具。 GAIA 更关注通用助手完成真实问题的综合能力，可能同时需要推理、浏览网页、读取附件和多模态理解。 调用格式正确只是局部条件。例如，模型可能生成合法的查询请求，却选择错误的城市或错误的日期，最终仍无法完成用户目标。 因此，评估需要结合参数语义、执行结果和任务完成状态。BFCL 的不同版本也包含不同评估方式，不能把它概括成仅比较字符串或仅做 AST 匹配。 工程上可以用 BFCL 类任务定位调用能力问题，再用 GAIA 类任务检查完整系统是否能把这些能力组合起来。第12章原文；BFCL 多轮评估说明 37. 如何设计一个完整的 Agent 评估体系？ 评估应同时覆盖结果、过程、成本和稳定性。 结果指标包括任务成功率、事实准确性和约束满足率；过程指标包括工具选择与参数正确性、无效调用次数及错误恢复率；成本指标包括 token 消耗、工具费用和耗时。 延迟除了平均值，也应关注较慢请求的分布，例如 P95。用户体验常常受到少数长时间卡住的任务影响。 测试集应覆盖正常、边界、信息不足和工具失败等场景，并固定模型、提示词、工具和数据版本。对具有随机性的系统，需要适当重复运行，报告波动而非只展示最好的一次。 还应做消融实验：移除记忆、重排序或某个智能体后重新评估，以判断复杂模块是否真正有价值。 离线评估通过后，再结合线上抽样与用户反馈，持续跟踪真实任务表现。 38. LLM-as-a-Judge 有哪些优点和偏差？如何提高可信度？ LLM-as-a-Judge 使用模型评价答案质量，适合难以用精确匹配衡量的内容，例如完整性、可读性和解释质量。它能够快速处理大量样本，并给出评分理由。 但它可能偏爱较长答案、某种表达风格或特定位置的选项，也可能对熟悉的模型风格产生偏好。评审模型还可能被答案中的指令性文本干扰。 改进方式包括：制定明确评分量表、提供评分示例、匿名化候选答案、交换 A/B 顺序，以及使用人工标注样本校准。 能通过程序检查的维度，应优先程序化处理，例如 JSON 合法性、数值计算、测试通过情况。LLM 负责更难形式化的维度。 成对比较的胜率可以辅助判断，但必须说明平局处理、样本量和比较条件。自动评审分数不能直接当作真实用户满意度。 39. 智能旅行助手为什么拆成多个 Agent？哪些步骤可以并行？ 教程将任务拆成景点搜索、天气查询、酒店推荐和行程规划四类职责。前三类获取不同领域的信息，规划 Agent 负责综合用户需求和查询结果。 这种拆分能够让提示词和工具范围更集中，也更容易定位错误。例如，天气数据错误与路线安排不合理，可以分别追踪到不同环节。 教程展示的是顺序执行流程。工程延伸中，如果景点、天气和酒店查询不存在相互依赖，可以并行获取，再交给规划器汇总。 但并行不是直接把所有调用同时启动。需要控制外部服务限流、并发数量和失败处理，并判断是否有步骤依赖前一步的结果。 此外，拆分后的收益应与额外调用成本比较。对于简单请求，单个 Agent 或确定性流程可能已经足够。第13章原文 40. 为什么旅行助手需要 Pydantic 数据模型？结构合法是否等于行程可靠？ Pydantic 数据模型可以明确请求与响应的字段、类型、默认值和校验规则。例如，位置包含经纬度，景点包含地址和游览时间，单日行程再组合景点、酒店和餐饮。 这种方式有利于前后端协作，也能尽早发现字段缺失和类型错误。相比随意传递字典，数据契约更清晰。 但结构合法不等于事实正确。经纬度在合理范围内，不代表它对应正确景点；日期格式正确，不代表景点当天营业。 因此还需要业务校验，例如检查交通时间、开放时间、预算总和与地点一致性。教程中预算由模型估算；生产改进可以把价格来源与算术计算分开，使用代码重新汇总。 估算价格、实时报价和已确认订单应明确区分，避免把模型生成的数字展示成确定事实。 41. 共享 MCP 实例有什么价值？如何进一步降低旅行助手成本？ 多个 Agent 使用同一外部服务时，共享 MCP 实例可以减少重复启动进程、建立连接和初始化资源的开销，也便于集中管理生命周期。 但共享实例本身不会自动保证不超限。仍然需要根据服务限制实现并发控制、速率限制和重试策略。 进一步优化可以从缓存、去重和模型路由入手。例如，相同城市和日期的天气查询可以在有效时间内复用；同一请求中的重复 POI 查询可以合并；简单数据整理可以由代码完成。 缓存键必须包含影响结果的条件，缓存时效也应随数据变化速度设置。不能把过期价格或库存长期复用。 共享还需要注意隔离：连接可以复用，但不同用户的授权、会话状态和私有数据不能混用。优化目标应是降低无效开销，同时保持结果新鲜和正确。 42. 深度研究 Agent 为什么采用 TODO 驱动的研究流程？ TODO 驱动把开放问题拆成显式子任务，让系统能够追踪研究覆盖范围和执行进度。 教程将流程分成规划、执行和报告三个阶段。规划阶段生成子任务，包含标题、研究意图和搜索查询；执行阶段获取资料并保存总结；报告阶段整合各子任务的证据和结论。 与一次性生成长报告相比，这种方式更容易发现遗漏、恢复失败步骤，以及判断哪些结论还缺少支持。 工程延伸中，TODO 还可以包含任务状态、依赖、证据列表和完成标准。当新资料暴露知识缺口时，应允许增加或调整子任务。 但子任务越多不一定越好。过细的拆分会增加重复搜索和整合成本，过粗又不利于检查覆盖。应围绕用户问题和交付要求进行拆分。第14章原文 43. 如何让研究报告的引用真正可追溯，而不是看起来有出处？ 应在资料获取时建立稳定的来源记录，包括 URL、标题、时间、相关片段和来源编号。总结阶段保存“结论对应哪些证据”，报告阶段再引用这些已经记录的来源。 不能让模型在最后凭记忆补参考文献。即使 URL 真实存在，也可能不支持紧邻的结论。 检查引用时至少要回答三个问题：来源是否可访问？内容是否支持该主张？引用是否遗漏适用条件或时间范围？ 教程的研究流程会处理搜索结果及来源。生产延伸中，对于重要事实，应打开原始页面核对，而不只依赖搜索摘要；对冲突信息，应保留差异并说明判断依据。 压缩资料时也要保留数字、日期和限定条件。否则原始证据虽然正确，经过多轮总结后仍可能被误写。 44. 深度研究任务如何展示实时进度？SSE 实现有哪些注意点？ 深度研究通常耗时较长，可以把规划开始、子任务完成、工具错误和报告完成等事件持续推送给前端。教程采用 SSE 展示这类单向进度信息。 后端应发送结构化事件，例如任务 ID、事件类型、当前阶段和完成数量。前端据此展示真实状态，而不是只用定时器模拟百分比。 需要区分 SSE 协议格式与浏览器 EventSource API：原生 EventSource 建立的是 GET 请求，不能直接给它设置 POST 请求体。 因此，可以先 POST 创建任务，再通过 GET 订阅事件；也可以使用 fetch 发起 POST，并自行读取流式响应。HTML EventSource 标准 工程上还应处理断线重连、事件去重、任务取消和错误通知。连接断开不一定代表后台任务停止，必须明确任务生命周期。 45. 如何让赛博小镇中的 NPC 保持角色一致性和长期记忆？【第15章】 NPC 需要稳定的角色设定，包括身份、性格、知识范围、表达方式和行为边界。这些设定应与动态对话信息分开管理。 对话时，把当前场景、最近交互和检索到的相关历史提供给模型。教程使用工作记忆保持短期连贯性，使用情景记忆支持对过往经历的回忆。 长期记忆不能只存文本，还应带有时间、参与者和事件类型。这样 NPC 才能区分“与当前玩家发生的事情”和“其他人的经历”。 还需要限制可见信息：某个 NPC 不应无条件知道自己未参与、未被告知的事件。否则虽然回答流畅，角色世界观却不一致。 角色一致性应通过多轮场景测试验证，而不只是检查首次对话是否符合口吻。第15章原文 46. 好感度和 NPC 状态为什么不应该完全交给 LLM 管理？【第15章】 LLM 适合理解对话中的态度和意图，但不适合作为唯一的权威状态存储。模型可能忘记旧值、重复计算，或被玩家语言诱导直接提高分数。 可以让模型输出友好、中立、不友好等分类，或给出受限的变化建议，再由服务端规则决定是否更新好感度。 服务端应保存分数、等级和事件记录，限制单次变化范围，并保证重复请求不会重复加分。这属于对教程好感度机制的可靠性改进。 并发场景还要处理同一 NPC 的状态竞争。例如，两个请求同时读取旧值后分别写回，可能丢失一次更新，因此需要事务、锁或版本检查。 此外，应区分 NPC 的全局状态与其和某个玩家的关系状态。不同玩家的好感度不应因为共享 NPC 实例而串在一起。 47. 批量生成 NPC 对话能节省多少成本？有什么局限？【第15章】 批量生成把多个 NPC 的部分对话合并到一次模型请求中，减少请求数量，并复用一部分公共场景信息。 它适合生成背景闲聊、环境对白或低时效要求的内容。教程中的轻负载模式体现了这种思路。 但请求次数减少，并不意味着 token 费用必然同比下降。批量提示需要包含多个角色，输出也会增加；实际成本取决于输入、输出、缓存和失败重试等因素。 批量生成还可能造成角色混淆、格式解析失败和内容过时。某个 NPC 的状态发生变化后，预先生成的对白可能不再适用。 因此，可以采用混合策略：背景对白批量生成并缓存，玩家触发的关键互动实时生成。缓存要绑定角色和场景状态，避免使用已经失效的内容。 48. 如果做一个 Agent 毕业项目，如何选题并控制范围？【第16章】 选题首先要对应真实问题，并具有明确输入、输出和成功标准。例如，“根据公司文档回答并引用依据”比“做一个万能助手”更容易实现和评估。 可以先限制用户群、数据范围、工具数量和任务时长，构建最小可用闭环。第一版只需要可靠完成一个核心任务。 开发前应建立简单基线，例如普通 LLM 调用、固定工作流或基础 RAG，再根据失败案例增加 Agent 能力。这样能够说明为什么需要规划、记忆或多智能体。 每增加一个模块，都应对应一个具体问题，而不是为了展示技术数量。 项目完成标准也要包含失败处理、可复现运行和基本评估。一个范围较小但证据完整的项目，通常比功能庞杂、只能偶尔演示成功的项目更有说服力。第16章原文 49. 一个可复现、可评审的 Agent 项目应该交付哪些内容？【第16章】 交付物应包含源码、依赖配置、环境变量示例、运行说明、输入输出示例，以及基本评估和异常处理说明。 README 要说明项目解决什么问题、如何安装、如何配置服务、如何运行，以及结果有哪些限制。配置示例只提供变量名和占位值，不放真实密钥。 Notebook 适合解释实验，但也应检查在干净环境中按顺序执行是否成功，避免依赖隐藏变量或本机残留文件。 测试需要覆盖关键路径和常见失败，例如模型返回格式错误、检索为空、工具超时和重复请求。外部服务不可用时，可以使用固定响应进行部分测试，同时保留真实联调记录。 评估报告应记录模型、提示词、数据集与关键参数版本。否则即使给出一个成功率数字，别人也很难复现或判断它的意义。 50. 面试时，如何完整介绍一个自己做过的 Agent 项目？【第16章·综合题】 可以按“问题—方案—关键难点—验证—局限”的顺序介绍。 先说明用户要完成什么，以及普通脚本、固定流程或单次 LLM 调用为什么不足。然后介绍系统中的模型、工具、状态和数据如何协作，不必一开始堆框架名称。 接着挑一个最有代表性的难点深入说明，例如检索遗漏、工具参数错误、长任务状态丢失或多智能体重复工作，解释你如何定位并修复。 验证部分应提供真实对照：在什么测试集、什么条件下，与哪个基线相比，成功率、成本和延迟发生了怎样的变化。没有测量过的数据就明确说尚未测量，不编造提升百分比。 最后说明系统仍然容易在哪些情况下失败，以及下一步如何改进。面试官最想判断的是：你是否理解系统为什么有效、如何证明它有效，以及它什么时候会失效。