AI、Agent 与场景题

1. 多 Agent 之间如何通信？

答案：

多 Agent 通常通过共享状态、消息队列或点对点 RPC 通信。消息应包含任务 id、发送者、接收者、类型、载荷、版本和超时信息，结果与错误都结构化传递。生产环境还要处理幂等、重试、顺序、循环调用、权限和链路追踪，避免只靠自然语言拼接上下文。

2. Executor Agent 的职责是什么？

答案：

Executor Agent 负责把计划转换为实际动作：读取任务输入，选择并调用允许的工具，执行代码、查询或接口操作，校验结果并回报结构化状态。它不应擅自改变目标或越权调用工具；高风险写入、发布、删除等操作应暂停等待审批，并支持超时、重试、回滚和幂等。

3. Planner Agent 的职责是什么？

答案：

Planner Agent 负责理解目标、拆解任务、确定依赖和执行顺序，并为每一步指定输入、输出、工具及验收条件。它输出的是可执行计划，不直接承担所有副作用；遇到信息不足、执行失败或约束变化时应重新规划，同时限制深度、成本和循环次数。

4. Supervisor Agent 是什么？

答案：

Supervisor Agent 是多 Agent 系统的协调者，负责选择或创建子 Agent、分派任务、汇总结果、处理失败并决定是否结束。它维护全局上下文和权限边界，但不应替代专业执行者；必须定义超时、最大迭代次数、冲突处理、人工审批和最终验收规则。

5. 多 Agent 的常见架构有哪些？

答案：

常见架构包括 Supervisor 集中调度、层级式分解、固定流水线、黑板共享状态、点对点协作、辩论或评审，以及按能力竞选的路由架构。实际系统常混合使用：外层统一调度，内部流水线执行，关键节点引入 Reviewer。选择取决于任务依赖、可控性、延迟、成本和权限隔离。

6. 为什么需要多个 Agent 协同工作？

答案：

多个 Agent 的价值在于按职责拆分复杂任务，让不同角色并行处理、互相校验，并缩小每个 Agent 的上下文和工具权限。例如规划、实现、测试和审查可以分开。代价是通信、编排、状态同步和冲突处理更复杂；任务简单或强串行时，单 Agent 往往更高效。

7. 什么是 Multi-Agent？

答案：

Multi-Agent 是由多个具有不同角色、上下文或工具权限的 Agent 组成的协作系统。它们通过调度器、消息或共享状态共同完成一个目标，而不是简单地并行调用多个模型。设计重点是职责边界、通信协议、状态一致性、失败恢复和最终验收，否则只会增加成本与不确定性。

8. MCP 为什么被认为是 AI 时代的 USB-C？

答案：

MCP 被比作 AI 时代的 USB-C，是因为它为模型与外部工具、资源、提示模板之间定义了通用协议。应用只需接入 MCP Client，服务方按统一方式暴露能力，就能减少每个模型、平台与工具之间的定制适配。但它只解决互操作，不自动解决权限、安全、质量和业务语义。

9. MCP 与传统 REST API 有什么区别？

答案：

REST API 面向业务服务与程序调用，通常由开发者固定设计资源、路径和参数；MCP 面向 AI Host 与工具生态，除了调用，还标准化能力发现、输入输出描述、资源和提示模板。MCP 可在底层使用 HTTP 或 stdio，因此二者不是替代关系：MCP Server 常常只是对 REST、数据库等能力的适配层。

10. MCP 如何实现权限控制？

答案：

MCP 权限控制应由 Host、Client、Server 和底层业务系统共同完成。先认证连接并按用户、租户、环境筛选可发现的工具，再在服务端重新鉴权、校验参数和资源归属；采用最小权限、只读默认、短期凭证和审计日志。写入、删除、发布等高风险调用要显式确认，不能把工具描述当作安全边界。

11. MCP 出现之前 Agent 是如何接入工具的？

答案：

MCP 之前主要靠定制化集成：开发者在 Agent Runtime 中把函数、插件、REST API、数据库或脚本包装成工具，手写名称、描述、参数 Schema、鉴权和执行逻辑，再把工具定义交给模型。模型返回工具名和参数后，运行时执行并把结果回填上下文。优点是直接，缺点是复用差、耦合高、治理分散。

12. Agent Workflow 如何进行监控？

答案：

监控 Agent Workflow 要围绕一次 run 建立可关联的结构化事件：节点开始、模型调用、工具调用、输入输出摘要、重试、审批、错误和结束。记录耗时、Token、费用、成功率和队列延迟，并用 traceId 串联跨 Agent 链路。生产环境应脱敏并设置告警、采样、重放和审计，避免记录完整敏感提示或隐私数据。

13. 如何实现 Agent 的断点续执行？

答案：

断点续执行的关键是把工作流拆成可恢复节点，在每个有副作用或重要状态变化的节点完成后持久化 checkpoint，包括 runId、节点位置、输入、输出、上下文版本和重试信息。恢复时校验版本并从最近成功节点继续；工具调用必须幂等或记录执行凭证，避免重启导致重复扣款、写入或发布。

14. 如何实现 Agent 的状态持久化？

答案：

状态持久化不只是保存聊天记录，还要保存任务目标、计划、当前节点、消息、工具结果、变量、记忆、错误和外部副作用记录。可采用事件日志加 checkpoint：事件用于追溯，checkpoint 用于快速恢复；写入需原子化并带 schema 版本、租户隔离和加密。恢复时校验一致性、过期时间和权限。

15. Agent Workflow 如何实现重试机制？

答案：

重试应按错误类型设计，而不是无条件重跑。对网络抖动、限流、临时服务故障使用有上限的指数退避并加入随机抖动；参数错误、权限拒绝等永久错误直接失败。工具调用要设置超时、熔断和幂等键，记录每次尝试；超过预算后进入补偿、人工处理或明确失败状态，避免无限循环。

16. 如何设计一个企业级 AI Agent 平台？

答案：

企业级 AI Agent 平台应分层建设：模型网关与路由、Prompt/版本管理、工具和 MCP 注册、Workflow 编排、记忆与知识库、权限审批、观测评估及成本治理。运行时要支持租户隔离、密钥托管、超时重试、状态持久化和人工接管；上线前用离线评测、回归测试和灰度发布控制质量与风险。

17. 如何实现 Agent 的 Memory 可视化？

答案：

Memory 可视化应先区分短期上下文、摘要、长期事实、向量检索结果和用户偏好，并展示来源、时间、置信度、命中原因及过期状态。前端通过结构化事件或查询接口按会话和记忆类型展示，支持搜索、编辑、删除和纠错；敏感内容要脱敏并遵守权限，不能把内部推理链当作可展示记忆。

18. 如何实现 Agent 的 Token 实时统计？

答案：

Token 实时统计应以 runId 和每次 model call 为维度。流式阶段根据已收到文本和 tokenizer 做估算，及时展示输入、输出、总量和费用；请求结束后读取模型接口返回的 usage 做最终校准，并处理重试、工具结果、缓存命中和不同模型价格。前端显示应注明估算状态，服务端记录才是计费依据。

19. 如何设计 Agent 的会话历史管理？

答案：

会话历史应把消息按角色、时间、run 和版本存储，并区分用户可见内容、工具事件和系统元数据。构造上下文时采用截断、摘要、最近消息与相关记忆检索的组合，按 Token 预算动态取舍；支持分页加载、分支会话、重新生成和删除。必须防止跨租户串话，并对历史中的提示注入和敏感信息做处理。

20. 前端如何实现多 Agent 协作界面？

答案：

前端应以一个会话时间线承载用户消息、Agent 状态、工具调用和最终结果，并用 Agent 列表或泳道区分角色。通过 SSE 或 WebSocket 接收结构化事件，展示排队、执行、等待审批、成功、失败和重试；支持展开详情、取消、重试、人工接管和权限提示。状态更新要按事件序号去重，避免并发渲染错乱。

21. 如何实现 Agent Workflow 的流程图展示？

答案：

流程图应先定义统一的 nodes 和 edges 数据模型，节点包含 Agent、模型、工具、条件、状态和耗时，边包含依赖或分支条件。运行时通过事件更新节点状态、当前路径和失败原因，前端支持缩放、拖拽、自动布局、节点详情和历史回放。大图应按层级或子流程折叠，不能只画静态拓扑而看不到实际执行轨迹。

22. 如何实现 Agent 的工具调用可视化？

答案：

工具调用可视化应展示工具名、所属 Agent、调用状态、参数摘要、耗时、结果摘要、错误、重试次数和审批记录，并用 traceId 关联上下文。参数和结果要脱敏、截断，支持展开原始结构化数据及复制诊断信息；高风险操作应突出确认状态。展示层只消费事件，不直接执行工具，避免把调试界面变成越权入口。

23. Agent 应用中的消息状态有哪些？

答案：

消息至少应区分 queued（排队）、streaming（生成中）、tool-calling（调用工具）、waiting-approval（等待审批）、completed（完成）、failed（失败）、cancelled（取消）和 retrying（重试中）。状态应由服务端事件驱动，带消息或 run id、版本和时间序号；前端要处理乱序、重复、断线恢复，避免用单一 loading 布尔值覆盖真实流程。

24. 如何实现 Agent 的思考过程展示？

答案：

不应直接展示模型的原始逐字 CoT。更合适的做法是输出经安全过滤的过程事件，例如当前阶段、任务计划摘要、工具调用、结果摘要、校验和下一步状态，并允许查看可审计日志。采用流式事件驱动更新，敏感提示、凭证、内部策略和隐藏推理必须脱敏或不返回，且前端应明确区分过程状态与最终答案。

25. 如何实现 ChatGPT 类似的流式输出？

答案：

服务端通过 SSE 或 fetch 的 ReadableStream 持续发送事件，前端按协议分隔符缓存不完整片段，逐段解析并追加渲染，而不能假设一个网络 chunk 就是完整 JSON。事件至少包含 delta、工具状态、错误和 done；用 AbortController 支持取消，服务端同步停止模型和工具，并处理断线、重连、重复事件和最终 Markdown 收敛。

26. Vibe Coding 与 Spec Coding 有什么区别？

答案：

Vibe Coding 以模糊目标和即时反馈驱动生成，适合探索想法、原型和 UI 试验；Spec Coding 先明确功能边界、接口、状态、异常、验收标准和测试，再让 AI 按约束实现。前者速度快但一致性和可维护性不稳定，后者准备成本更高却更适合生产交付。实际可先 Vibe 探索，再沉淀为 Spec 验收。

27. Prompt Injection 是什么？

答案：

Prompt Injection 是攻击者把指令伪装在用户输入、网页、文档或工具结果中，诱导模型忽略原有目标、泄露信息或执行越权操作。防御不能只靠 Prompt：要隔离不可信内容与系统指令，限制工具权限，服务端重新鉴权，校验输出，对高风险动作要求确认，并记录审计和异常检测。

28. MCP 如何实现工具发现（Discovery）？

答案：

MCP 工具发现通常是 Client 完成 initialize 后调用 tools/list，从 Server 获取工具名称、描述和 inputSchema，必要时按 cursor 分页拉取。Client 可缓存目录，并根据 listChanged 通知刷新，再把经过权限筛选和 Schema 校验的工具提供给模型；发现只是能力声明，不代表工具可信或已获授权。

29. MCP 与 Function Calling 的关系是什么？

答案：

Function Calling 是模型输出结构化函数名和参数的一种调用能力，解决“模型如何提出调用”；MCP 是连接 Host、Client 与外部 Server 的标准协议，解决“工具如何发现、描述、调用和返回结果”。二者可以组合：MCP Client 发现工具后，把 Schema 转成模型可用的 Function Calling 定义，再将模型选择转为 tools/call。

30. MCP 的通信流程是什么？

答案：

MCP 通常以 Host 创建的 Client 连接 Server，先通过 initialize 协商协议版本和能力，再发送 initialized。之后 Client 可用 tools/list、resources/list、prompts/list 发现能力，并分别用 tools/call、resources/read、prompts/get 执行或读取。消息遵循 JSON-RPC 2.0，支持 request、response、notification 和进度；传输可为 stdio 或 Streamable HTTP。

31. MCP Client 与 MCP Server 的职责分别是什么？

答案：

MCP Client 位于 Host 一侧，负责建立和维护连接、完成初始化、发现能力、校验 Schema、转发调用、处理结果与通知，并落实用户确认和本地权限策略。MCP Server 负责实现并暴露工具、资源和提示模板，校验输入、执行后端业务、返回结构化结果和错误。Server 不应信任模型，Client 也不能绕过服务端鉴权。

32. MCP 的核心价值是什么？

答案：

MCP 的核心价值是用统一、可发现、可组合的协议连接 AI 应用与外部能力，降低工具接入和迁移成本。它把能力描述、参数 Schema、资源、提示和调用结果标准化，使同一 Server 可被不同 Host 复用，并便于权限、审计和生命周期治理。但协议本身不保证业务正确性、安全性或模型决策质量。

33. SSE 与 WebSocket 在 Agent 应用中如何选择？

答案：

文本类 Agent 通常选 SSE：客户端发起请求，服务端持续推送 token、工具状态和最终结果，接入 HTTP 鉴权、代理与断线重连都较简单；要注意关闭代理缓冲。需要客户端持续上行的语音、实时控制或协作场景选 WebSocket，但要自行处理心跳、重连、背压、鉴权续期和会话恢复。

34. Hybrid Search（混合检索）是什么？

答案：

Hybrid Search 是把关键词检索与向量语义检索结合起来。前者擅长专有名词、编号和精确匹配，后者擅长同义表达和语义相关性；系统分别召回结果，再用加权融合或 RRF 合并排序，必要时交给 rerank。它通常比单一检索更稳，但会增加索引、调参和查询成本。

35. Rerank 的作用是什么？

答案：

Rerank 是对初步召回的候选文档进行二次相关性排序。向量检索适合从大规模库中快速找 TopK，但排序较粗；Reranker 逐条或成对比较查询与文档，通常更准确，再截取少量上下文交给模型。代价是额外延迟和算力，因此应先召回适中数量，并设置超时与降级。

36. TopK 参数如何影响检索效果？

答案：

TopK 决定初步检索返回多少候选。过小会漏掉真正相关片段，召回率不足；过大虽能覆盖更多信息，却会引入噪声、增加 rerank 和模型上下文成本，甚至稀释重点。应结合文档质量、问题类型和上下文预算评估，在离线指标与线上延迟之间调参，通常先扩大召回再精排。

37. Chunk 过大或过小会带来什么问题？

答案：

Chunk 过大，单段主题混杂、向量表示不聚焦，还会占用上下文，降低检索精度；过小则语义不完整，指代、条件和代码上下文容易被切断，召回后模型难以理解。应按标题、段落、句意或代码结构切分，并用适度 overlap 保留边界信息，同时受模型 token 预算约束。

38. Chunk 的切分策略有哪些？

答案：

常见策略有固定长度切分、按段落或句子切分、按 Markdown 标题的层级切分，以及按代码的函数、类和注释切分。实际项目通常采用结构优先、长度兜底，并设置少量 overlap；表格、列表和元数据要尽量保持完整。还应通过召回率、答案引用准确率验证切分，而不是只凭经验。

39. 向量数据库的作用是什么？

答案：

向量数据库用于存储 embedding 及其元数据，并按向量相似度高效检索相关内容。它通常支持近似最近邻索引、过滤、更新和分片，可作为 RAG 的召回层。它不等于完整知识库：仍需负责文档解析、权限过滤、混合检索、重排和数据更新，且索引参数会影响精度与延迟。

40. Embedding 是什么？

答案：

Embedding 是把文本、图片等对象编码成能表达语义关系的数值向量。语义相近的内容在向量空间通常更接近，系统可用余弦相似度、点积等指标进行检索。Embedding 不是生成答案的模型，效果取决于模型、语言领域、切分方式和查询文档是否使用一致的向量空间。

41. RAG 的整体架构是什么？

答案：

RAG 通常分为离线索引和在线问答两条链路：先解析、清洗、切分文档，生成 embedding 并写入向量或混合索引；用户提问后进行查询改写、召回、权限过滤和 rerank，再把高相关片段与问题组装进 prompt，调用模型生成流式答案，最后返回引用、日志和评估信息。

42. 为什么 Agent 经常需要结合 RAG？

答案：

Agent 需要 RAG，是因为模型参数中的知识可能过时、缺少企业私有内容，也无法可靠覆盖实时业务数据。RAG 在执行前检索授权的外部上下文，让 Agent 基于事实回答或决定调用工具，并可展示来源、降低幻觉。它不能自动保证正确，切分、召回、权限和引用校验仍是关键。

43. 什么是 RAG？

答案：

RAG 即检索增强生成：先从外部知识库检索与问题相关的片段，再把片段作为上下文交给大模型生成答案。典型流程是文档切分、Embedding、建索引、查询召回、过滤或重排、Prompt 组装和生成。它适合私有、实时知识，但检索错误会把错误上下文传给模型，不能替代质量评估。

44. 如何实现工具权限控制？

答案：

工具权限应在服务端以用户身份、租户、角色和资源范围为依据做鉴权，不能相信模型传来的权限参数。工具注册时声明所需权限，调用前校验 allowlist、参数和资源归属，对高风险写操作增加人工确认或审批；调用后记录审计日志，并配合最小权限、限流、超时和凭证隔离。

45. 工具调用结果过长时如何处理？

答案：

不要把完整结果直接塞进上下文。先按字段和任务需要做裁剪、分页、聚合或摘要，保留关键 ID、状态、错误和可追溯链接；大文件放对象存储，仅返回摘要与引用。可按 token 预算截断并提示不完整，敏感数据先脱敏，必要时让 Agent 分页调用，避免丢失关键结论。

46. 如何设计工具描述（Tool Description）？

答案：

Tool Description 要清楚说明用途、适用条件、输入字段含义、类型、必填性、单位、枚举和约束，并给出少量准确示例；明确返回结构、失败含义、副作用和权限要求。名称应具体、工具职责单一，避免多个工具描述重叠。Schema 做机器校验，描述做决策引导，二者必须保持一致。

47. Agent 如何选择最合适的工具？

答案：

Agent 先根据用户意图和当前状态判断任务是否需要外部能力，再比较工具的描述、参数约束、权限、成本和副作用，选择能完成当前子目标的最小工具集合。应通过结构化 tool schema、示例和路由器降低歧义，调用前校验参数，工具结果回来后再决定继续、改用其他工具或直接回答。

48. 如何避免 Agent 频繁调用无关工具？

答案：

可从三层控制：先用意图分类或工具路由器缩小候选集，再用清晰的工具描述、调用条件和负向示例约束模型，最后在服务端做权限、参数和状态校验，拒绝无关调用。为每轮设置最大步数、重复调用检测、预算和超时；记录调用轨迹，用评测集持续修正路由规则。

49. 一个 Agent 如何管理多个工具？

答案：

将工具按领域或风险分组，由统一注册表维护名称、Schema、权限、超时和版本；Agent 先规划任务，再按依赖顺序调用，工具执行器负责校验、重试、日志和结果标准化。可并行执行互不依赖的只读工具，写操作串行并确认。对工具数量较多的系统使用分层路由，避免一次暴露全部工具。

50. Agent 如何处理工具调用失败的情况？

答案：

先把失败分类为参数错误、权限问题、业务拒绝、限流、超时或服务故障：可修正的参数错误让 Agent 根据结构化错误重试，临时故障采用有限次数的指数退避，非幂等写操作必须配合幂等键，权限和业务拒绝不应盲目重试。超过预算后停止循环，向用户说明状态并提供降级或人工处理路径。

51. Tool Schema 为什么通常使用 JSON Schema？

答案：

JSON Schema 结构明确、语言无关，能描述类型、必填字段、枚举和嵌套约束，便于模型生成参数、服务端校验、跨语言调用和版本演进。它只是输入契约，不代表权限或业务规则；服务端仍要做二次校验、鉴权和资源检查。Schema 应尽量小而严格，避免模糊的自由文本字段。

52. Agent 调用外部工具的完整流程是什么？

答案：

流程通常是：服务端把工具名称、描述和 Schema 交给模型；模型返回普通文本或结构化 tool call；编排器校验名称、参数、权限和预算后执行工具；把标准化结果连同 call ID 写回会话，再次请求模型生成下一步或最终答案。全过程要有超时、幂等、审计、错误分类和循环次数限制。

53. Temperature 参数对 Agent 的影响是什么？

答案：

Temperature 调整采样随机性：较低时输出更稳定，适合工具选择、参数生成、分类和事实型回答；较高时表达更发散，适合创意任务，但可能增加格式错误、重复调用和幻觉。它不是准确率开关，实际还受模型、prompt、top_p 和约束解码影响；Agent 关键链路通常使用较低值并做结果校验。

54. Tool Calling 与 API Gateway 有什么关系？

答案：

Tool Calling 是模型提出调用意图，API Gateway 是承接和治理实际请求的基础设施。Gateway 可统一鉴权、路由、限流、熔断、超时、审计和协议转换，把模型与具体后端解耦；它不会替代 Agent 编排和业务授权。调用链应防止模型绕过网关直连内部服务，并对参数做服务端校验。

55. 如何降低 Agent 的幻觉率？

答案：

降低幻觉要让模型尽量基于可验证信息工作：使用高质量 RAG 或可信工具，优化切分、召回、重排和权限过滤；在 Prompt 中要求引用依据、区分事实与不确定性、证据不足时拒答；对工具和输出做 Schema 校验、事实核验和敏感操作人工确认。最后用真实数据集监控正确率、引用准确率和拒答质量。

56. 为什么 Agent 容易出现幻觉（Hallucination）？

答案：

模型本质上是在预测最可能的后续 token，并不天然具备事实校验能力；训练知识会过时，问题可能超出分布，检索结果或工具返回也可能错误。上下文过长、Prompt 歧义、采样随机性和 Agent 多步传递还会放大误差。因此幻觉既来自模型，也来自数据、编排和系统约束不足。

57. 如何解决 Agent 的上下文长度限制问题？

答案：

可按重要性管理上下文：保留系统约束、当前任务和最近交互，压缩较早对话为带结论的摘要；历史事实、文档和工具结果放入外部存储，按需通过 RAG 检索，工具结果只保留摘要和引用。还要控制 Chunk、设置 token 预算，分阶段执行长任务，并在截断时避免丢掉约束、状态和错误信息。

58. 什么是上下文窗口（Context Window）？

答案：

上下文窗口是模型一次请求可处理的 token 总量，通常包括系统 Prompt、历史消息、工具定义、检索内容和本轮输出，并受具体模型限制。超过窗口会报错、截断或导致有效信息被稀释。它不是永久记忆；多轮 Agent 需要通过摘要、外部存储和按需检索管理长期状态。

59. System Prompt 对 Agent 的行为有什么影响？

答案：

System Prompt 是对模型的高优先级行为约束，可规定角色、目标、输出格式、工具使用规则、安全边界和不确定时的处理方式，因而显著影响 Agent 的规划与调用行为。但它不是安全边界，不能替代服务端鉴权、参数校验和审计；还要防范用户输入或工具结果中的 Prompt 注入，并评测规则冲突。

60. Prompt Engineering 在 Agent 中起什么作用？

答案：

Prompt Engineering 是把任务目标、上下文、约束和决策流程表达清楚，帮助 Agent 稳定完成规划、工具调用和回答。常用做法包括明确角色与边界、结构化输入输出、少量高质量示例、工具调用条件、失败处理和自检要求。Prompt 不能弥补错误的权限和业务逻辑，效果应靠评测集与线上指标验证。

61. Agent 如何判断是否需要调用工具？

答案：

先判断问题是否需要实时、私有或可变信息，以及是否需要执行外部动作；若模型已有足够知识且只是解释、改写或计算，可直接回答。否则根据工具描述、权限和当前状态选择调用，并在调用前校验参数。生产系统可结合意图路由、规则门禁和模型判断，不能仅凭模型自由决定高风险操作。

62. Tool Calling 与 Function Calling 有什么区别？

答案：

Function Calling 通常指较早以函数名和参数 Schema 表达的调用机制；Tool Calling 是更宽的概念，可统一函数、搜索、代码执行、数据库等工具，并支持更丰富的调用类型。两者核心流程相同：模型生成结构化调用，应用执行后回传结果。实际含义以所用模型 API 的协议为准，不能只按名称判断能力。

63. Function Calling 的原理是什么？

答案：

调用前应用把函数名称、用途和参数 Schema 提供给模型，模型根据上下文输出函数名及结构化参数，而不是直接执行代码。应用收到后校验 JSON、权限、资源和业务规则，执行真实函数，再把结果作为新消息交回模型生成最终回答。模型只是提出意图，执行权、密钥和安全责任始终在服务端。

64. Agent 为什么需要状态管理（State）？

答案：

Agent 是多轮、可规划、会调用工具的过程，必须保存消息、任务目标、当前步骤、工具结果、权限和失败状态，才能在下一步保持一致，并支持暂停恢复、重试、并发控制和审计。状态应区分短期会话上下文与长期业务数据，采用持久化存储和版本化更新，避免把所有内容无结构地塞进 Prompt。

65. 短期记忆和长期记忆有什么区别？

答案：

短期记忆是当前会话中的上下文，如最近消息、任务步骤和工具结果，主要帮助 Agent 连贯完成眼前任务；长期记忆则跨会话持久化用户偏好、稳定事实或历史经验。短期记忆强调时效和上下文窗口，长期记忆强调可检索与可更新。两者都要处理过期、冲突、隐私和错误写入，不能把所有对话永久保存。

66. Agent 的记忆（Memory）机制有哪些？

答案：

常见机制包括：会话上下文记忆、摘要记忆、滑动窗口记忆、事实型长期记忆、向量检索记忆，以及任务状态和工作记忆。工程上通常先按重要性筛选，再压缩或写入存储，按需检索注入 Prompt；同时设置来源、时间、置信度、删除和权限策略，避免上下文过长、旧事实污染和敏感信息泄露。

67. 什么是 Reasoning（推理）能力？

答案：

Reasoning 是 Agent 根据目标、上下文和证据进行分解、比较、推导并作出下一步决策的能力，不等于简单生成一段流畅文字。它通常表现为识别约束、建立中间结论、选择工具、检查结果和修正判断。推理质量依赖模型、上下文和验证机制；复杂任务应通过结构化输出、工具结果和测试建立可验证的闭环。

68. 什么是 Planning（规划）能力？

答案：

Planning 是把目标转成可执行步骤、依赖关系、完成标准和终止条件的能力。Agent 先识别任务与约束，再拆解子任务，决定顺序和工具，并根据执行结果动态调整。简单任务可用固定计划，开放任务需要重规划。计划必须可观测、可恢复、有限步数，并对高风险动作设置审批，避免无休止循环。

69. Agent 的 ReAct 模式是什么？

答案：

ReAct 是 Reasoning 与 Acting 的交替模式：Agent 先基于当前观察判断下一步，再调用工具执行动作，读取返回结果后继续判断，直到达到目标或触发终止条件。它适合信息不完整、需要环境反馈的任务，比一次性生成计划更灵活；但工具权限、循环次数、超时、失败重试和结果校验必须受控，否则容易产生幻觉式行动或成本失控。

70. 为什么大模型需要 Agent，而不是直接回答用户问题？

答案：

直接问答适合一次性解释和生成；Agent 则把模型放进“理解目标、规划、调用工具、观察结果、修正”的执行闭环，能访问实时数据、操作文件或业务 API，并验证产出。例如修复 Bug 不只是给建议，还要读代码、修改、跑测试。简单问题使用 Agent 会增加延迟、成本和不确定性，因此应按任务复杂度选择。

71. AI Agent 与 Workflow 有什么区别？

答案：

Workflow 是步骤、分支和输入输出预先编排的确定性流程；Agent 是围绕目标在运行时自主选择步骤和工具，并依据反馈调整路径。Workflow 更易测试、审计、控成本，适合规则稳定的业务；Agent 更灵活，适合开放任务，但结果、耗时和成本波动更大。实际系统常让 Agent 负责决策，把关键动作封装为受控 Workflow。

72. Agent 的核心组成部分有哪些？

答案：

核心组成通常包括：模型与系统指令、目标和约束、上下文与记忆、工具及权限、规划与执行循环、环境观察、结果评估和安全控制。模型负责理解与决策，运行时负责状态、调用和重试，工具负责连接真实系统。生产实现还应支持日志、取消、超时、人工确认、幂等和可恢复，不能只依赖模型输出。

73. 什么是 AI Agent？它与传统 ChatBot 有什么区别？

答案：

AI Agent 是以目标为中心，能理解任务、规划步骤、调用工具并依据结果继续行动的系统；传统 ChatBot 主要根据对话上下文生成回复，通常停留在信息交互层。两者都可使用大模型，区别在于是否形成“感知、决策、行动、反馈”的闭环。Agent 能解决更复杂的任务，但也带来更高的权限、成本和结果不确定性。

74. 什么是 MCP？

答案：

MCP（Model Context Protocol）是让 AI 应用以统一方式发现并使用外部上下文和能力的协议。通常由 Host/Client 连接 MCP Server，Server 暴露 tools、resources、prompts，通信可采用 JSON-RPC 和本地或远程传输。它解决的是连接标准化，不会自动解决授权、参数校验、提示注入、数据泄露和审计问题，生产环境仍需严格隔离和审批。

75. 如何设计一个多步骤 Agent 工作流？

答案：

先定义目标、输入输出和验收标准，再把任务拆成边界清晰的步骤，标注依赖、可并行节点和失败策略。用状态机或 DAG 编排固定流程，让 Agent 只在需要判断的节点选择工具；每步记录状态、结果和幂等键，设置超时、重试、人工审批和最大步数。最后用真实样例、失败注入和成本耗时指标验证闭环。

76. 什么场景适合 Autonomous Agent？

答案：

Autonomous Agent 适合目标明确但路径不确定、需要多轮观察和工具协作的任务，例如代码排障、研究汇总、异常调查和跨系统运营。前提是动作可撤销、环境可隔离、权限可限制，且有可靠的完成标准。支付、删库、生产发布等高风险操作不宜完全自治，应设置审批或改用确定性 Workflow。

77. 什么场景适合 Workflow？

答案：

Workflow 适合步骤和规则稳定、输入输出明确、需要高一致性与可审计性的场景，如表单审批、订单处理、数据同步、内容审核和固定报表。它便于测试、监控、重放和估算成本。若任务需要频繁解释模糊意图或临时决定下一步，可在局部节点引入 Agent，而不必把整个流程都交给模型。

78. DAG 工作流是什么？

答案：

DAG（有向无环图）工作流把任务表示为节点和有向依赖边，节点完成后才能触发后继节点，且图中不能形成环。它能表达串行、并行、汇聚和条件分支，并据此做拓扑调度。设计时要定义输入输出、失败重试和幂等策略；需要循环或动态重规划的任务应由外层状态机或 Agent 负责。

79. 工作流（Workflow）与自主 Agent 的区别是什么？

答案：

Workflow 的执行路径由工程师预先定义，强调确定性、可测试和可审计；自主 Agent 只接受目标与约束，在运行时决定调用什么工具、执行几步以及是否调整计划。前者适合高风险、规则稳定的业务，后者适合开放且变化多的任务。成熟方案通常固定关键路径，把 Agent 限制在决策和异常处理范围内。

80. 什么是 Agent Workflow？

答案：

Agent Workflow 是把大模型的理解和决策能力嵌入可编排流程，让任务经过输入解析、规划、工具执行、结果观察和输出等阶段。它既不像普通 Workflow 那样完全固定，也不像完全自治 Agent 那样边界模糊。工程上应定义状态、工具契约、分支条件、重试与人工接管点，并记录每次运行，保证可观测、可暂停和可恢复。

81. Agent 与 RAG 结合时的典型流程是什么？

答案：

典型流程是：先识别问题并改写查询；再从知识库召回文档，必要时重排、过滤和压缩上下文；Agent 根据证据决定直接回答还是继续调用工具；模型生成答案并附带引用或证据；最后用事实性、相关性和权限规则校验。若证据不足应澄清或拒答，不能让模型用猜测补齐知识库空白。

82. 如何解决知识库内容更新问题？

答案：

建立文档版本和来源管理，内容变更后通过事件或定时任务增量解析、切分、嵌入并更新索引；删除或失效内容必须同步下架，避免旧向量继续召回。检索结果带上更新时间和版本，回答时可按时效过滤。上线前用新旧样本回归召回与答案质量，并保留重建索引和回滚能力。

83. 如何评估 RAG 的召回率？

答案：

先建立带有标准相关文档的评测集，对每个问题记录检索结果 Top-k。召回率可定义为：被召回的相关文档数 ÷ 相关文档总数；也可统计 Recall@k，观察不同 k 值的覆盖情况。评估时要区分文档级和片段级，结合 MRR、nDCG 判断排序质量，并按查询类型、更新时效和权限场景分层分析。

84. 前端如何实现 Agent 对话系统？

答案：

前端负责输入、会话状态和结果呈现，Agent 编排、模型密钥、工具权限应放在后端。通过 SSE 接收文本增量、工具调用、审批、产物、错误和完成等事件，前端按事件更新状态机，而不是只拼接字符串。还要支持取消、重连、刷新恢复和幂等；Markdown 需做 XSS 过滤，高风险动作必须二次确认，长文本渲染应批量更新。

85. AI Coding Agent 如何实现自主修复 Bug？

答案：

先收集复现步骤、错误日志和相关代码，生成最小复现，再由 Agent 提出假设并用测试或命令验证。确认根因后只修改必要文件，补充回归测试，运行类型检查、Lint、单测和受影响的 E2E；失败则根据结果继续迭代，直到满足验收标准。全过程需限制权限、保留 diff、设置步数和超时，无法确认时交给人工。

86. AI Coding Agent 如何实现自动测试？

答案：

自动测试应形成闭环：读取项目配置和变更范围，选择单元、组件或 E2E 层级，依据需求和行为生成断言，执行测试并解析错误，再修复后回归验证。不能只按实现细节生成脆弱测试；异步场景要使用稳定等待，外部接口用可控 mock，失败保留日志、截图或 trace。重试只能识别 flaky，不能掩盖真实失败。

87. AI Coding Agent 如何调用终端工具？

答案：

模型先输出结构化终端调用，包含命令、工作目录和超时等参数；宿主运行时进行权限、沙箱和命令策略检查后启动进程，再把 stdout、stderr、退出码或超时状态作为观察结果返回模型。模型据此决定继续修改、重试或总结。生产实现要限制目录和破坏性命令，隔离凭证，支持长任务会话、取消、资源配额与完整审计。

88. AI Coding Agent 如何进行代码审查？

答案：

先阅读需求、接口契约、变更 diff 和相关调用链，再从正确性、类型、异步竞态、边界状态、权限、安全、性能和可访问性检查。可运行 typecheck、Lint、单测及必要的浏览器验证，把发现按严重度输出，包含位置、触发条件、影响和建议。Agent 应基于证据审查，不能臆测业务规则，也不能把风格偏好当成缺陷。

89. AI Coding Agent 如何避免误修改代码？

答案：

通过明确任务范围和允许修改目录，先要求 Agent 读取现状并给计划，再执行小步、可审查的补丁。运行前保留 Git 状态和基线，修改后展示 diff，禁止无关重构；对删除、批量替换、依赖升级等操作要求确认。随后执行格式化、类型检查和测试，失败可回滚，最终由人工检查业务语义和文件范围。

90. AI Coding Agent 如何实现任务规划？

答案：

先把自然语言目标转成验收标准，再扫描项目结构、约束文档、Git 状态和测试入口，定位相关模块。随后拆成可验证的小任务，标记依赖、优先级、风险和预计验证命令；每完成一步就更新状态并根据结果调整计划。规划应可恢复、可取消并限制最大循环，遇到需求歧义或高风险修改要暂停请求确认。

91. 为什么 AI Coding Agent 需要 Git Worktree？

答案：

Git Worktree 能让每个 Agent 在独立工作目录和分支中操作，同一仓库可并行处理多个任务，避免互相覆盖未提交文件或频繁切换分支。它也便于隔离依赖、运行测试、查看 diff 和失败后清理。使用时仍需明确分支归属、避免共享运行端口，合并前解决冲突并重新验证，不能把隔离当成自动合并。

92. AI Coding Agent 如何实现代码修改？

答案：

代码修改通常经过读取上下文、定位符号、生成最小补丁、应用补丁和验证五步。优先使用结构化编辑或精确 diff，保持格式和既有抽象，避免整文件重写；修改后检查 diff、类型、Lint、单测及相关页面。工具层要校验路径和权限，对批量或破坏性改动先审批，并让每次修改可回滚、可审计。

93. AI Coding Agent 如何理解大型代码库？

答案：

采用分层、按需的代码理解：先读目录、包配置、入口、约束文档和 Git diff，再用符号索引、文本搜索、调用链和测试定位相关子图，避免把整个仓库塞进上下文。将发现摘要为模块职责、依赖和不变量，必要时分阶段探索并保留缓存。最终以编译、测试和运行结果校验理解，不能只依赖相似文件猜测。

94. Claude Code 的工作原理是什么？

答案：

Claude Code 可视为带工具执行层的编码 Agent：用户提出目标后，它读取代码和项目约束，模型决定搜索、编辑或运行命令，宿主执行这些操作，再把结果反馈给模型，循环迭代到完成或停止。能力来自模型推理、上下文管理、文件与终端工具及权限控制。它不是完全自动程序员，仍需 diff、测试、审查和人工验收。

95. Cursor 的 Agent 模式与 Chat 模式有什么区别？

答案：

Cursor 的 Chat 模式主要围绕问题解释、代码建议和局部生成，通常由用户决定改哪些文件、执行哪些命令；Agent 模式则能自主检索代码库、规划多步修改、调用终端和工具，并依据测试结果继续迭代。Agent 效率更高但权限、成本和误改风险也更大，简单问答用 Chat，跨文件任务应限制范围并审查 diff。

96. Agent 在企业落地时最大的安全挑战是什么？

答案：

最大挑战是把不确定的模型行为连接到真实数据和高权限操作：提示注入可能诱导 Agent 泄露上下文或调用危险工具，越权、敏感数据外泄、错误执行和供应链风险会被放大。应实行最小权限、工具白名单、输入输出过滤、沙箱隔离、敏感信息脱敏、高风险人工审批、全量审计和可撤销设计，并持续做红队与回归评测。

97. 如何设计 Agent 的人工审核机制？

答案：

人工审核应放在高风险、不可逆或影响外部用户的动作之前。先按风险分级，低风险自动执行，中风险需要用户确认，高风险由具备权限的人员审批；审批请求应展示参数、影响范围、证据和可回滚方案。系统要支持暂停、超时、拒绝、重新审批和审计记录，并通过幂等键避免恢复或重试时重复执行。

98. Agent 如何防止无限循环调用工具？

答案：

在 Agent 循环中同时设置最大步数、总耗时、Token 和费用预算，并为每个工具设置调用次数及相同参数的重复上限。每轮检查是否达到终止条件，记录 visited 状态或幂等键，失败采用有限退避重试；超过预算就返回可解释的中止状态。对固定流程优先使用状态机，避免让模型自由循环。

99. Agent 如何实现 RBAC 权限控制？

答案：

RBAC 应由服务端执行，模型只负责提出动作。先定义用户、角色、资源和操作权限，再在每次工具调用前依据用户身份、租户、资源归属和环境重新鉴权，采用最小权限的短期令牌。高风险操作增加审批，工具层拒绝越权参数，并记录授权决策；不能把角色说明只写在 Prompt 中。

100. 如何限制 Agent 的操作范围？

答案：

采用能力白名单限制 Agent：只暴露完成任务所需的工具、HTTP 域名、文件目录、数据库表和操作类型；工具参数用 Schema 校验，服务端再次校验租户、资源归属和数量上限。执行放入隔离沙箱，设置超时、预算、速率和并发限制。写操作先预览或审批，所有动作可审计、可撤销。

101. 如何避免 Agent 泄露敏感信息？

答案：

敏感信息保护要分层处理：数据进入模型前按字段分类、脱敏或最小化，密钥使用引用而不直接注入上下文；检索和工具服务按用户权限过滤。输出侧做 PII、密钥、内部提示词和越权内容检测，必要时阻断或替换。日志默认不记录原文，传输和存储加密，并设置访问审计、保留期限和删除机制。

102. Agent 调用工具时有哪些安全风险？

答案：

主要风险包括提示注入导致误调用、越权访问、参数篡改、命令或代码执行、敏感数据外泄、重复扣费以及工具副作用。防护应落在工具和服务端：白名单、强 Schema、身份鉴权、沙箱、超时和幂等控制，高风险动作人工确认；把外部内容当数据隔离，记录完整 Trace，并持续做红队测试。

103. Jailbreak 是什么？

答案：

Jailbreak 指通过角色扮演、伪造优先级、编码混淆或多轮诱导等方式，试图绕过模型原有的安全规则、权限边界或内容约束，让系统执行本不应执行的行为。它与 Prompt Injection 有交集，但前者更强调突破安全限制，后者更强调污染上下文、改变任务执行。防护不能只靠提示词，还要依赖权限隔离、输出检测、审批和审计。

104. 如何防御 Prompt Injection？

答案：

Prompt Injection 是不可信内容试图改变模型任务或指令优先级。防御要把系统指令、用户输入、检索结果和工具返回值分区，并明确后两者只能作为数据；工具采用最小权限，服务端独立鉴权，敏感动作要求确认。对输入和输出做安全检测，限制可外发数据，监控异常调用并保留审计，不能只依赖一句“不要听从”。

105. Agent 如何实现版本管理？

答案：

版本管理应覆盖 Prompt、模型与参数、工具 Schema、工作流、知识库索引和策略配置，并为每次 Agent 运行记录完整版本快照。发布采用不可变版本、评测门禁、灰度或 A/B，失败可一键回滚；数据结构用 schema version 迁移。线上需支持按版本追踪质量、成本和错误，避免只用一个可变的 latest。

106. Agent 如何实现会话恢复？

答案：

会话恢复的核心是持久化状态机，而不是简单重放聊天记录。以 sessionId 和递增 seq 保存用户消息、计划、工具调用及结果、审批和 checkpoint；恢复时从最近快照继续，已完成的副作用通过幂等键复用结果，失败步骤按策略重试。前端用 cursor 补齐事件，服务端校验用户权限，并对旧 schema 做迁移。

107. Agent 如何实现流式输出？

答案：

流式输出应把 Agent 运行拆成结构化事件，例如 message_delta、tool_call_start、tool_result、status、done 和 error，而不是只透传模型 Token。服务端可用 SSE 传单向事件，双向控制或实时协作再选 WebSocket；前端按事件更新状态并批量渲染。还要处理断线续传、取消、超时、乱序和错误，避免暴露内部思维链。

108. 如何实现 Agent 的缓存机制？

答案：

缓存分层设计：稳定的系统提示词使用前缀缓存，确定性工具结果和检索结果按规范化参数缓存，最终回答只在任务和上下文完全一致时缓存。缓存键应包含模型、Prompt 或数据版本、用户权限、租户和工具参数，并设置 TTL、容量和失效策略。副作用工具不能盲目缓存，写操作必须幂等；命中和失效都要纳入监控。

109. 如何降低 Agent 的推理成本？

答案：

降低推理成本应先减少不必要的模型工作：用规则或小模型做分类、参数校验和简单路由，复杂任务才升级大模型；压缩历史和工具结果，限制检索 top-k，合并可批量完成的工具调用。启用合适的缓存，减少无效循环和整段重试，并按输入、输出、缓存和推理 Token 分项计费。用质量、延迟、成功率和成本一起评估优化。

110. 如何优化 Agent 的响应速度？

答案：

响应速度可从模型、编排、网络和前端同时优化：使用更小或更快的模型做路由，压缩上下文并缓存稳定前缀；能并行的检索和工具调用并行执行，减少 Agent 轮次，设置合理超时和降级模型。接口采用流式事件，前端先展示可解释进度并批量更新。要用 Trace 分解首 Token、工具等待和总耗时，避免只看平均值。

111. Agent 的 Token 消耗如何统计？

答案：

按一次 Agent Run 建立成本边界，给每个模型调用和工具调用记录 model、input_tokens、output_tokens、cached_tokens、reasoning_tokens（若接口提供）、耗时、重试和分支。请求前可用 tokenizer 预估预算，请求后以模型 API 返回的 usage 为准，累计所有重试、并发分支和 fallback。最后按模型单价拆分成本，再聚合到用户、租户、任务和时间窗口。

112. Agent 的评测体系如何设计？

答案：

评测要覆盖离线质量、在线表现和安全。先建立含正常、边界、对抗和真实任务的固定数据集，定义任务成功率、事实准确率、工具选择、参数正确率、人工接管率、延迟、Token、成本和违规率。对关键样本做人工或模型辅助评审，但保留可复现的规则指标；上线前回归和灰度，线上持续抽样并按版本比较。

113. 如何定位 Agent 的错误决策？

答案：

先用 Trace 重建决策链：用户输入、检索片段、模型响应、工具参数与结果、状态变化和最终输出都要关联同一 runId。再把错误分类为理解、检索、规划、工具执行、权限、数据或编排错误，通过重放和最小化样本定位触发点。比较期望动作与实际动作，增加断言和回归用例，避免只依据最终答案猜原因。

114. Agent 的 Trace（链路追踪）如何实现？

答案：

Trace 以一次用户请求为根 Span，向下记录模型调用、规划节点、检索、工具调用、重试、人工审批和子 Agent，并用 parentSpanId、时间戳、状态和版本关联。每个 Span 记录耗时、Token、成本、参数摘要和错误，但对输入输出脱敏。采用 OpenTelemetry 等标准导出到追踪系统，支持按 runId 查看拓扑、采样和告警。

115. 如何设计 Agent 的日志系统？

答案：

日志系统应区分运行日志、审计日志和指标，采用结构化 JSON，统一记录 timestamp、runId、sessionId、userId、tenantId、节点、版本、状态、耗时、Token、工具和错误码。业务日志与安全审计分离并限制访问，敏感字段脱敏，保留链路关联信息。设置采样、保留期限、脱敏规则、告警和检索能力，避免把完整 Prompt 当普通日志保存。

116. FastGPT 的知识库架构是怎样的？

答案：

FastGPT 知识库通常由文档接入、解析清洗、分块、向量化、索引存储、检索召回和回答生成组成。文件上传后切成带元数据的片段，写入向量库，查询时可做向量检索、关键词或混合召回、重排，再把高相关片段交给模型生成。生产上还要支持知识库和文档版本、权限过滤、增量更新、引用来源及召回评测。

117. Coze 的 Agent 开发模式是什么？

答案：

Coze 更偏向配置化、低代码的 Agent 开发：组合模型、角色 Prompt、知识库、插件/API、工作流、变量、记忆和发布渠道，并在可视化界面调试。简单问答可由单 Agent 完成，复杂任务可拆成工作流节点或多个 Agent 协作。它的优势是接入和发布快，边界是复杂状态控制、深度定制、私有化治理和精细观测通常不如代码框架灵活。

118. Dify 的 Agent 编排能力有哪些？

答案：

Dify 的编排能力主要包括工作流和 Chatflow 节点、条件分支、循环、代码节点、模板转换、知识检索、工具/API 调用、变量与会话记忆，以及串行或并行连接。它支持模型供应商配置、结构化输出、调试、日志观测和发布为应用或 API。适合快速搭建 RAG、客服和自动化流程；复杂事务仍需外部服务补足权限、事务和可靠性。

119. OpenAI Agents SDK 的特点是什么？

答案：

OpenAI Agents SDK 的核心是用 Agent、工具、handoff 和运行器组合任务，并提供结构化输出、会话上下文、流式事件和 tracing 等能力。它适合把模型决策与业务工具、子 Agent 和人工接管连接起来，同时保留代码级控制。生产实现仍要自行负责身份权限、工具幂等、持久化、审批、成本预算和安全校验，SDK 不能替代这些边界。

120. AutoGen 的架构特点是什么？

答案：

AutoGen 以可对话的 Agent 作为基本单元，通过消息传递和协作模式组织多 Agent 任务，例如规划者、执行者、审查者和代码执行 Agent。它便于快速实验对话式协作、群聊和人机参与，也能接入工具与模型。工程上要控制消息轮次、上下文膨胀、循环和代码执行风险；复杂生产流程需要额外的状态持久化、权限和可观测性设计。

121. CrewAI 的核心能力有哪些？

答案：

CrewAI 以 Agent、Task 和 Crew 为核心，强调角色、目标、背景、工具及任务依赖的声明式协作。它支持顺序或层级流程、任务上下文传递、工具调用、记忆和结果输出，适合把研究、写作、审核等职责拆成角色明确的团队。使用时仍需明确任务边界和终止条件，并补充权限、重试、幂等、持久化和 Trace，避免多 Agent 互相空转。

122. 为什么 LangGraph 更适合 Agent？

答案：

LangGraph 把 Agent 建模为带状态的图：节点表示模型、工具或业务逻辑，边表示条件流转，因此能自然表达循环、分支、多 Agent、重试和人工审批。它提供 checkpoint、持久化和 durable execution，适合长任务中断后恢复，并便于流式输出和观测。简单 RAG 或单轮工具调用用普通 Chain 更轻；它的价值在复杂且需要可控恢复的流程。

123. LangGraph 与 LangChain 有什么区别？

答案：

LangChain 更像 LLM 应用组件与快速开发框架，提供模型、Prompt、Retriever、工具、结构化输出等抽象；LangGraph 则把执行过程表示为有状态的图，重点解决复杂 Agent 的循环、分支、持久化、恢复和人工介入。两者可以组合：在 LangGraph 节点中使用 LangChain 组件。稳定的简单链路选 LangChain，复杂长流程选 LangGraph。

124. 谈谈 LangChain 的核心设计思想。

答案：

LangChain 的核心思想是把模型调用、Prompt、解析器、检索器和工具等能力组件化，并通过统一的 Runnable 接口组合成链或 Agent。组件可以串行、并行、分支和流式执行，便于替换模型、复用流程、调试和观测；结构化输出与工具抽象降低了集成成本。它负责应用编排基础，不应把权限、事务和业务规则交给模型决定。

125. 了解哪些 Agent 开发框架？

答案：

常见框架可按抽象层选择：LangChain 适合组件化 LLM 应用，LangGraph 适合有状态、可恢复的复杂 Agent；OpenAI Agents SDK 提供 Agent、工具、handoff 与 tracing；AutoGen 偏多 Agent 对话协作，CrewAI 偏角色和任务编排；Dify、Coze、FastGPT 偏低代码、RAG 和快速发布。选型应看状态控制、部署、权限、观测、团队能力和长期维护成本。

126. 多 Agent 架构存在哪些挑战？

答案：

多 Agent 的挑战主要是通信成本和上下文膨胀、职责重叠、结果冲突、循环协商、错误传播与整体延迟成本上升。应先划清角色和输入输出契约，采用编排者或有限状态图控制流程，限制消息和轮次；共享状态要有版本和权限，结果要经过校验、投票或审查。每个子 Agent 都应可观测、可重试且具备明确终止条件。

127. 多 Agent 如何实现结果汇总？

答案：

先定义统一的结果协议，要求每个子 Agent 返回结构化结果、证据、置信度、状态和错误，而不是自由文本。编排层按任务依赖收集结果，可并行的分支用 join 等待，失败分支按策略重试或降级；对冲突结果按规则、置信度或审查 Agent 仲裁，最终再由汇总 Agent 生成答案。汇总前验证 Schema、来源和权限，并记录每个结论的贡献者。

128. 多 Agent 如何实现任务拆解？

答案：

任务拆解应先明确目标、约束、验收标准和不可并行的依赖，再由规划器输出带唯一 ID、输入输出契约、优先级、资源和截止时间的子任务图。能并行的任务并发执行，依赖完成后再调度后续任务；每个子任务设超时、重试和失败补偿。拆解结果要经过 Schema 校验和必要的人审，避免无限细分，并支持中途调整与恢复。

129. 多 Agent 如何避免任务冲突？

答案：

先按任务边界拆分职责，给每个 Agent 明确输入、输出和可写资源；共享状态采用版本号或乐观锁，写入前校验，冲突时重试、合并或交给协调 Agent 决策。对有副作用的操作设置唯一幂等键和审批点，再用任务队列、依赖图及超时重试控制执行顺序，避免重复写入和循环调用。

130. 多 Agent 如何共享上下文？

答案：

把上下文分成共享事实、任务状态和 Agent 私有记忆：共享事实放在带版本的状态库或事件日志中，私有推理不直接污染全局；通过协调器按需向各 Agent 注入摘要、相关检索结果和工具输出。上下文过长时做结构化摘要与分层检索，并记录来源、时间和版本，避免过期信息覆盖最新状态。

131. 现在大模型已经能高效生成界面代码，有人认为前端会被AI颠覆，也有人认为这只是工具革新。你更倾向哪种观点？你认为前端未来3-5年真正的机会点或转型方向是什么？

答案：

我更倾向于“工具革新会重塑前端，但不会消灭前端”。AI 擅长生成常规页面，却难以独立完成需求澄清、交互取舍、复杂状态建模、性能与安全治理。未来机会在于成为能驾驭 AI 的工程师：负责设计系统、跨端体验、数据与智能交互、质量验证及工程平台，把编码效率转化为可靠的产品交付能力。

132. 说说Agent应用的优缺点？

答案：

优点是能理解自然语言、拆解任务并调用工具，适合处理多步骤、信息不完整且需要一定自主性的工作，能降低重复操作成本。缺点是模型可能幻觉、误用工具或陷入循环，结果不稳定且难解释，还会带来权限、隐私和成本问题。因此应限制工具权限，设置超时、预算、人工审批、审计日志和可回滚机制，关键结果必须由规则或人工校验。

133. Vibe Coding 和 Spec Coding 分别是什么？

答案：

Vibe Coding 是以自然语言和快速试错为主，边描述边让 AI 生成代码，强调速度与探索，规范和设计可能在后面补齐。Spec Coding 则先把需求、接口、约束、验收标准和边界写成明确规格，再让 AI 按规格实现并测试，强调可复现、可评审和可维护。原型适合 Vibe，生产系统更应采用 Spec 或两者结合。

134. 如果公司想用大模型，但又担心暴露隐私数据，该怎么解决？

答案：

先做数据分级和用途评估，明确哪些内容禁止出域；敏感字段在网关侧脱敏、掩码或匿名化，并用最小权限、租户隔离、密钥管理和传输及存储加密保护。优先选择合规的企业版或私有化部署，关闭训练留存并签订数据处理协议；通过 DLP、审计日志、访问审批和供应商评估持续监控，不能把脱敏当成绝对安全。

135. 大模型的计费规则一般会区分“输入（命中缓存）”、“输入（未命中缓存）”、“输出”，它们有什么区别？

答案：

输入 Token 是发送给模型的上下文，包括系统提示、历史消息和工具结果；输出 Token 是模型生成的内容。命中缓存通常表示前缀上下文与缓存键一致，服务商可复用已处理结果，所以单价更低、延迟也可能更小；未命中则需完整计算，价格较高。缓存通常只覆盖稳定前缀，动态内容仍按未命中计费，具体规则以模型服务商定义为准。

136. 各种大模型场景给出的 Coding plan 套餐中，Tokens 和 Credits 分别是什么？

答案：

Tokens 是模型处理文本的计量单位，输入提示、历史上下文和输出都会消耗 Token，通常影响调用量和上下文上限。Credits 是套餐层面的额度或余额，平台会按模型、请求类型、Token 数及工具调用把消耗折算成 Credits。两者不是同一单位，Token 更接近用量，Credits 更接近套餐计费；实际换算必须看具体平台规则。

137. 项目中是否有必要自己封装请求库？

答案：

有必要，但应封装项目真正需要的边界，而不是重复实现 HTTP。统一请求入口可集中处理 baseURL、鉴权、超时、取消、重试、错误码、日志和类型约束；业务层只依赖领域 API，便于替换底层库。对上传、下载、流式响应等特殊场景保留独立适配。封装要避免吞掉原始错误、无脑重试非幂等请求或制造过深的抽象。

138. 如果在项目中需要使用到动态表单，你会怎么实现？

答案：

用后端或配置驱动的 schema 描述字段类型、布局、校验规则、默认值和联动条件，前端将 schema 映射为受控组件，并把表单值与错误状态统一管理。字段 key 必须稳定，联动变化时明确清理失效值，提交前做前后端双重校验；复杂控件通过扩展注册表接入。还要考虑异步选项、草稿恢复、权限只读、可访问性和 schema 版本兼容。

139. 如果页面含 100 个第三方资源，你会如何处理？

答案：

先盘点资源并按首屏关键性、依赖关系和第三方风险分级，首屏只加载必需资源，其余采用 lazy、async/defer、按需加载或交互触发。合并和压缩自有资源，启用 HTTP/2/3、缓存、预连接和 CDN；第三方通过隔离域名、超时、失败降级、CSP 和性能预算治理。用 Performance、Lighthouse 和真实用户指标验证，而不是只看请求数量。

140. 在前端项目中，如何设计前端与后端的数据交互机制？请说明数据传输格式、接口设计原则以及如何优化性能。

答案：

优先采用带版本的 JSON 接口，统一响应结构、错误码、分页和时间格式；接口按资源和业务语义设计，校验放在服务端，幂等写操作使用请求 ID，敏感数据全程加密并遵循最小返回原则。性能上用分页、字段裁剪、压缩、缓存、批量接口和请求合并，列表查询避免过度嵌套；前端统一处理 loading、重试、取消、竞态和降级。

141. 在即时通讯场景中，在同步消息时，如果出现网络延迟或部分设备未在线，你会如何确保消息的最终一致性？

答案：

每条消息由服务端生成全局唯一 ID、会话序号或游标，并持久化后再确认发送成功；客户端先本地落库并用临时 ID 展示，重连后按游标补拉，依据消息 ID 去重，按服务端序号排序。发送确认、失败重试和离线队列都要幂等。已读状态也用版本或序号同步，冲突以服务端规则为准，必要时提供撤回或重放。

142. 开发一个即时通讯系统的前端页面时，你会如何设计消息的存储和同步机制？如何处理用户切换设备后的消息同步问题？

答案：

前端采用本地数据库保存会话、消息、发送状态和同步游标，内存只维护当前窗口；消息发送先写入 outbox，再经 WebSocket 实时推送，断线用 HTTP 按会话游标增量同步。服务端按会话序列号持久化，客户端用唯一 ID 去重并处理乱序。新设备登录后先拉取最近消息和未读游标，再按分页加载历史，必要时校验快照版本。

143. 有了解 AI 的使用和一些前沿概念吗

答案：

了解一些。大模型通常基于 Transformer，用注意力机制处理上下文；应用层常见 RAG、函数调用、Agent、向量检索、Embedding 和多模态。工程上我更关注可验证落地：RAG 要评估召回与引用，Agent 要限制工具权限和循环，提示词要版本化，所有输出都要结合 schema 校验、离线评测和线上监控，不能把生成结果当作事实。

144. 有一个需要支持10万条数据渲染的表格组件，你会如何设计和优化？

答案：

核心是虚拟化：只渲染可视区域及缓冲区，固定或预估行高后通过滚动容器计算可见索引；复杂行高用测量缓存和增量修正。数据层采用分页或服务端筛选排序，避免一次性创建 10 万个响应式对象；表格列、单元格和事件处理要稳定并减少重复计算。再配合批量更新、Web Worker 处理重计算、回收 DOM 和性能监控，兼顾键盘导航与可访问性。

145. 如果需要做图片懒加载，并且图片数量很多，你会怎么做呢？

答案：

给图片设置稳定的宽高或 aspect-ratio，避免加载时布局偏移；使用原生 loading="lazy"，并用 IntersectionObserver 提前一个视口加载，离开视口可按场景释放。服务端提供缩略图、响应式尺寸和 WebP/AVIF，srcset/sizes 让浏览器选择合适资源。大量列表还应虚拟化、限制并发、缓存成功结果，并为失败提供占位和重试。

146. 怎么根据当前滚动位置，实现目录中对应节点自动高亮？

答案：

优先用 IntersectionObserver 观察所有标题，在带有固定头部偏移的有效区域内，把最靠近顶部的标题 ID 写入 activeId，再由目录状态驱动高亮；监听器初始化时立即执行，并在组件卸载时 disconnect。若需兼容旧环境，可用 passive scroll 加 requestAnimationFrame 和 getBoundingClientRect，避免每次滚动频繁触发状态更新；标题 ID 必须唯一，目录点击要同步处理锚点偏移。

147. 如果需要完成一个协同文档的系统，你会如何进行架构设计呢

答案：

采用客户端编辑器、协同服务和持久化存储分层。编辑操作表示为带客户端 ID、序列号和版本的增量更新，通过 WebSocket 广播；多人同时编辑用 CRDT 或 OT 合并，服务端负责鉴权、顺序、持久化和重连补偿。前端维护本地缓存、撤销重做、冲突状态和断线队列，文档内容与评论、权限、历史版本分开建模，并做好快照、审计、限流和大文档分页。

148. 平常你是如何进行代码调试的？

答案：

先稳定复现并记录环境、输入和预期结果，再把问题缩小到最小用例。调试时先看控制台、网络请求、断点和调用栈，必要时用条件断点、性能面板和内存快照；对异步问题重点检查时序、取消和竞态。修复后补回归测试，并用日志或监控确认线上影响。遇到不确定的第三方行为，会查源码或官方文档，而不是凭猜测改代码。

149. claude 中的 skills 和 mcp 有什么区别？

答案：

Skills 更像可复用的任务能力或操作规范，通常描述模型完成某类工作的流程、提示和约束，关注“怎么做”；MCP 是连接模型与外部资源、工具、提示模板的开放协议，关注“如何标准化通信”。Skill 可以指导模型调用工具，MCP 提供工具和数据的接入边界，二者可组合，不能把 MCP 简单理解为某个具体工具或技能。

150. 如何利用AI辅助进行前端性能优化

如何利用AI辅助进行前端性能优化

答案：

先把 AI 当作分析和验证助手：输入 Lighthouse、Performance、Web Vitals、打包分析和火焰图等真实数据，让它定位可能的 LCP、INP、CLS、网络或内存瓶颈，并提出可量化的改动。再让 AI 生成小范围补丁和测试，人工核对浏览器兼容性、业务语义与安全性，最后用基准环境和真实用户指标对比回归，避免只凭建议优化。

151. 如果让你设计一个支持AI功能（如智能对话）的前端应用架构，你会考虑哪些方面？

如果让你设计一个支持AI功能（如智能对话）的前端应用架构，你会考虑哪些方面？

答案：

架构上拆分展示层、会话状态、传输层和能力层。用稳定的消息模型管理会话、流式增量、重试、取消、错误和历史，采用 SSE 或 WebSocket 逐块渲染，并把 Markdown、代码高亮、引用和工具状态做成可扩展消息类型。还要考虑上下文裁剪、持久化、鉴权、敏感信息保护、请求幂等、成本限制、可观测性和降级；服务端负责密钥和模型编排。

152. 谈谈你遇到过AI生成代码的Bug，以及如何解决的。

谈谈你遇到过AI生成代码的Bug，以及如何解决的。

答案：

遇到过 AI 生成的异步请求在组件卸载后仍更新状态，偶发报错；原因是它遗漏了 AbortController 和生命周期清理。我先用复现用例和网络面板确认时序，再补充取消请求、finally 状态保护和卸载清理，并增加快速切换、超时和失败重试测试。经验是把 AI 代码当成初稿，必须经过类型检查、Lint、测试、代码审查和真实场景验证。

153. 写一个 prompt，让AI手写一个符合Promise A+规范的Promise

能否让AI手写一个符合Promise A+规范的Promise，并分析其代码？

答案：

可以这样写 Prompt：

请用原生 JavaScript 实现一个符合 Promises/A+ 规范的 MyPromise。要求支持 pending/fulfilled/rejected、then 链式调用、值穿透、异常捕获和 thenable 解析；先给出可运行代码，再逐条说明 2.2、2.3 的处理，并设计测试覆盖异步回调、自解析、循环引用和多次调用。不要声称实现了未要求的原生 Promise 静态方法。

关键验收点是 then 必须返回新 promise，回调异步执行，解析过程能递归处理 thenable，且 resolve/reject 只生效一次；最后用 Promises/A+ 测试套件验证，而非只看示例。

154. 在 AI 可以自动生成 80% 基础代码的今天，你认为前端工程师的核心价值在于哪里？

在 AI 可以自动生成 80% 基础代码的 2025 年，你认为前端工程师的核心价值在于哪里？

答案：

核心价值会从“写出代码”转向“定义并交付正确的软件”：理解用户和业务，拆解需求，设计可演进的架构与交互，处理复杂状态、性能、可访问性、安全和兼容性，并建立测试、监控和发布闭环。工程师还要会写清规格、评审和约束 AI 输出，对结果负责；真正稀缺的是判断力、系统思维、协作能力以及把技术转化为业务价值的能力。

155. 如何优化前端AI模型的推理性能，避免界面卡顿？

如何优化前端AI模型的推理性能，避免界面卡顿？

答案：

先判断模型是否适合端侧运行：通过量化、剪枝、蒸馏、较小模型和合适的 WebGPU/WASM 后端降低计算量，模型与词表按需加载并缓存。推理过程放到 Worker，分块处理输入，避免主线程同步计算；输出采用流式渲染并节流 UI 更新，限制上下文长度和并发请求。还要检测设备能力、内存和电量，必要时降级到服务端，并用真实设备测量首屏、响应延迟和帧率。

156. 如何保证AI生成代码的质量和符合项目规范？

如何保证AI生成代码的质量和符合项目规范？

答案：

先给 AI 提供项目级上下文：编码规范、目录边界、类型定义、设计系统和类似实现，并把需求写成明确的接口、约束与验收标准。生成后必须经过 TypeScript、Lint、格式化、单元和端到端测试，再由人工检查安全、性能、可访问性和异常分支；通过 CI 阻断不合规代码。对 AI 提交保留审查记录，敏感代码不直接发送到不受控服务。

157. 你平时使用哪些AI编程工具？

你平时使用哪些AI编程工具？

答案：

我会按任务选择工具：在编辑器中用 Copilot、Cursor 或 Claude Code 做代码补全、重构和测试草稿；用 ChatGPT 或 Claude 梳理方案、定位问题和解释陌生代码；需要快速验证界面时用支持原型生成的工具。工具只是效率放大器，我会限制上下文和权限，先写验收标准，再核对生成代码、运行测试和审查依赖，避免盲目接受建议。

158. 多个项目共用组件时，如何保证版本一致性？

答案：

把共享组件作为独立包发布，遵循语义化版本和变更日志，应用通过 lockfile 固定直接及间接依赖，并在 CI 中统一 Node、包管理器和安装策略。重大变更先提供迁移文档和 codemod，采用 peerDependencies 避免 React 等核心库重复；可用 monorepo、changesets 和依赖巡检自动生成版本。发布后做兼容矩阵、回滚和灰度验证，不能只依赖手工约定。

159. Prompt 是什么，比如要实现一个搜索表单页面，你会用什么样的 Prompt？

答案：

Prompt 是给模型的任务说明和约束，好的 Prompt 应明确角色、目标、输入、输出格式、技术边界、验收标准和异常处理。例如：

你是资深前端工程师，请用 Vue 3 + TypeScript + Element Plus 实现响应式搜索表单：关键词必填，日期范围可选，点击查询触发带参数的异步请求，支持加载、错误、重置和回车提交。请拆分组件，给出类型、校验规则和测试要点，不引入额外依赖，并说明关键取舍。

再根据生成结果补充真实接口和项目规范，分步评审。

160. 大家常提到的 Transformer 架构是什么？

答案：

Transformer 是以自注意力为核心的序列建模架构，不依赖循环就能并行处理序列中各位置，并通过多头注意力从不同子空间捕捉依赖关系。典型结构还包括位置编码、前馈网络、残差连接和层归一化；编码器适合理解，解码器适合生成，编码器—解码器适合转换任务。大语言模型多采用解码器式 Transformer，通过逐 Token 预测生成文本。

161. 你清楚 AI、AGI、AIGC、NLP、LLM 分别是什么吗？

答案：

AI 是让机器表现出感知、学习、推理或决策能力的总称；AGI 指跨任务、跨领域且接近人类通用能力的理想形态，当前没有公认的工程实现；AIGC 是利用 AI 生成文本、代码、图片、音视频等内容的应用范式；NLP 是处理和理解自然语言的研究与技术方向；LLM 是用大规模语料训练、以生成和理解语言为主的大语言模型。它们不是并列层级：LLM 属于 NLP 的重要模型，也常作为 AIGC 和 Agent 的基础。

162. 当需要更改组件库中组件的主题时，有哪些常见的方法？请以你熟悉的组件库为例，说明如何实现主题定制。

答案：

常见方式有：覆盖 CSS 变量、组件库主题配置、构建时预处理，以及运行时切换主题。以 Ant Design 为例，优先用 ConfigProvider 的 theme.token 统一设置 colorPrimary、borderRadius 等设计令牌，组件局部再用 className 或 CSS Modules 覆盖；需要暗色时切换算法或根节点主题属性。应保证令牌集中管理、样式优先级可控，并检查弹窗、Portal、动态加载组件和无障碍对比度。

163. 如果你有一个业务组件库，希望打包输出为 esm + cjs + dts，有什么思路？

答案：

用 TypeScript 源码作为单一入口，分别配置 ESM 与 CJS 输出，并用 tsc 生成声明文件。例如 Rollup/Vite library mode 产出 dist/index.js 与 dist/index.cjs，tsc 使用 declaration、emitDeclarationOnly 输出 dist/index.d.ts；package.json 用 exports 区分 import、require、types，并声明 sideEffects。还要处理 external 依赖、正确的 module/moduleResolution、路径别名和 sourcemap，最后用 Node 的 import 与 require 各跑一次，并用 tsc --noEmit 验证类型。

164. AI 工具中，经常提到的 mcp 是什么，有哪些与前端方向结合的场景？

答案：

MCP（Model Context Protocol）是让模型以统一协议发现并调用外部资源、提示词和工具的开放协议，典型结构是 Host/Client 连接 MCP Server。前端可用它接入设计稿、项目文件、接口文档和组件库，让 Agent 读取上下文、生成代码或调用测试工具；也可把页面操作封装成受控工具。生产中要做权限、参数 schema、超时、审计和用户确认，不能把任意 DOM 或密钥直接暴露给模型。

165. 请设计一个面向设计师的“AI 助手”前端界面，可以生成文本、图像并自动插入到设计稿中

答案：

我会做左侧会话与能力面板、中间画布、右侧图层和属性面板：用户选择文本或图片任务，填写 prompt、尺寸、模型和风格，生成过程显示进度、取消和重试，结果支持预览、版本对比、插入选中图层。前端通过任务 API 创建作业，以 SSE/WebSocket 接收进度和资源 URL，插入时校验尺寸、坐标和权限；图片用对象存储地址，文本保留结构化节点而不是只存 HTML，并处理失败、撤销、敏感内容和配额。

166. 如何保障前端调用 AI 接口时的安全性与权限控制？你是否考虑过代理服务或签名机制？

答案：

浏览器只携带用户身份凭证，绝不放模型密钥；请求先到后端代理，由服务端完成模型选择、额度、租户和 RBAC 校验，再调用供应商。可用短时 JWT 或一次性签名绑定用户、路径、请求摘要、时间戳和 nonce，服务端验签并防重放；全程 HTTPS，限制来源、输入长度、文件类型和速率，日志脱敏，错误不回传上游密钥。代理还应设置超时、内容审核、审计和按租户限流。

167. 假设要做一个 AI 语音生成工具（TTS），如何处理音频播放、缓存与断点续播？

答案：

音频生成采用任务 ID 和可取消请求，服务端返回可播放 URL 或分片流；前端用 Audio/AudioContext 控制播放，监听 canplay、waiting、ended，并维护 loading、playing、paused、error 状态。缓存键应包含文本、声音、语言、参数和版本，优先 Cache Storage/IndexedDB，设置大小与过期策略。断点续播保存 currentTime；下载支持 HTTP Range 和服务端 Accept-Ranges，恢复时从合法偏移请求，不能假设所有音频格式都支持任意切片。

168. 如何封装一个 AI 图片生成组件，支持选择模型、输入 prompt、展示图像并支持本地保存？

答案：

组件可拆为模型选择、prompt 表单、参数面板、任务状态和结果画廊。提交时生成 requestId，调用后端创建任务，再用轮询或 SSE 更新排队、生成、失败状态；结果用对象存储 URL 展示，设置懒加载、占位和重试。保存本地时优先用 fetch 获取 Blob，再创建 Object URL 触发下载，并在完成后 revokeObjectURL；要处理跨域、超大图片、移动端内存、敏感内容、配额和请求取消。

169. 如何在富文本中插入可控组件，如“可编辑 AI 卡片”、“模型输入块”等？会有哪些技术难点？

答案：

应使用富文本编辑器的自定义节点或原子节点表示 AI 卡片，不把它当普通字符串。节点保存 type、props、版本和可序列化数据，渲染器映射到受控 React/Vue 组件，编辑通过事务更新节点。难点在光标与选区映射、复制粘贴、撤销重做、序列化兼容、协同编辑、组件生命周期和 XSS；对模型输出必须做 schema 校验，未知节点降级为只读文本，并隔离第三方组件样式。

170. 如何基于现有富文本编辑器（如 Slate、TipTap、Monaco）扩展支持 AIGC 插件？比如一键生成段落或续写？

答案：

先抽象编辑器适配层，统一取得当前选区、上下文文本、插入内容和撤销事务；Slate 用 Transforms 插入节点，TipTap 用 command/transaction，Monaco 用 editor.executeEdits。调用后端生成或续写时带上选区、文档版本和取消信号，结果先在编辑区做 diff 预览，用户确认后提交，避免覆盖并发修改。模型输出应按纯文本或结构化格式解析，处理流式增量、失败重试、敏感信息和权限。

171. 当前主流大模型 API（如 OpenAI、Claude、文心一言）在前端调用时需要注意哪些问题？如何做统一封装？

答案：

不同供应商在鉴权、消息格式、流式协议、模型参数、错误码、上下文和多模态能力上都不同，不能在浏览器直接暴露密钥。统一封装应以内部接口定义 messages、model、temperature、signal 和 stream，后端 adapter 转换供应商格式，统一返回增量事件、结束和错误事件；同时做超时、重试、限流、成本统计、日志脱敏和能力声明。不要自动重试不可幂等的生成请求，也要保留原始 requestId 便于排障。

172. 你知道什么是 AIGC 吗，是否有参与过相关工具的研发？

答案：

AIGC 是 AI Generated Content，即利用模型自动或协同生成文本、代码、图片、音频、视频等内容的技术与应用方式。它的核心链路通常是输入 prompt/素材、模型推理、结果流式展示、人工编辑确认和发布，不等同于 AGI。研发时我会关注提示词模板、上下文检索、结构化输出、流式交互、内容安全、版权、成本和质量评估；若没有真实项目经验，应明确说明参与范围，不把调用 API 说成训练模型。

173. 请设计一个能自动生成产品文案的前端小工具，简述如何设计 UI ，以及与后端 AI 服务的交互流程。

答案：

UI 采用左侧场景与表单，中间生成预览，右侧历史版本和一键复制/导出；表单包含商品信息、受众、语气、长度和关键词，并提供模板与示例。点击生成后前端提交任务，显示流式文本、取消、重试和错误，完成后支持编辑、重新生成局部段落和保存草稿。后端校验权限和参数，调用模型并返回增量事件与 requestId；前端做 Markdown/XSS 清洗、版本管理、敏感内容审核和用量提示。

174. 你了解哪些 AI 前端工具或库？

答案：

常用基础库包括 OpenAI/Anthropic 等模型 SDK 的服务端封装，以及 LangChain/LlamaIndex 这类编排或检索框架；前端侧常见 Vercel AI SDK、assistant-ui、CopilotKit，用于流式消息、工具调用和聊天状态管理；编辑器场景会结合 TipTap、Slate，数据与文档检索可接向量库 SDK。选型要看协议兼容、SSR、流式取消、类型支持和社区稳定性，密钥、权限和业务规则仍应由后端掌控。

175. 如何在前端安全地使用大语言模型 API，比如调用 OpenAI 接口进行文本生成？

答案：

不要把 OpenAI key 放在前端代码、localStorage 或构建变量中。前端只调用自有后端，后端根据登录态做鉴权、配额、模型白名单和输入限制，再把请求转发给供应商；使用 HTTPS、短时会话、CSRF 防护和服务端限流，日志脱敏并设置超时。前端通过 SSE 接收结果，支持 AbortController 取消；输出要做渲染清洗，文件和 prompt 需校验，供应商错误只映射为安全的业务错误。

176. 假如要做一个类似 ChatGPT 的聊天 UI，前端如何处理流式响应？

答案：

后端以 SSE 返回 text/event-stream，事件至少区分 token、done、error，并带 messageId。前端用 fetch 读取 ReadableStream，按换行拆分 SSE 帧、解析 data，按 messageId 追加增量文本；不能假设一次 read 就是一条事件，要处理半包和多事件。用 AbortController 取消请求，维护发送中、重连、失败状态，完成后固化消息并支持 Markdown 安全渲染。代理、网关和服务端要关闭缓冲并设置心跳，避免连接被中间层断开。

177. 如何在前端项目中集成 AI 能力，例如实现智能对话、图像识别或推荐系统？

答案：

先明确业务目标和可衡量指标，再按能力接入：对话用后端会话、检索和流式接口；图像识别上传到受控对象存储，由后端调用视觉模型并返回结构化结果；推荐由后端特征、召回和排序服务提供分页结果，前端只负责展示。统一封装 loading、取消、重试、错误和埋点，做好权限、脱敏、限流、成本与缓存。模型输出必须 schema 校验，关键操作保留人工确认，不能让前端直接信任自然语言。

178. 前端实现的倒计时为什么会有误差？有什么减小误差的解决方案吗？

答案：

误差来自 setTimeout/setInterval 只是最早执行时间，主线程阻塞、渲染和后台限频都会延迟回调；若每次在上次时间上累加，还会把延迟不断积累。正确做法是保存截止时间 deadline，每次用 deadline - performance.now() 重新计算剩余秒数，显示层可用 requestAnimationFrame；后台恢复时立即校正，服务端倒计时应以服务器时间为准。它只能减小客户端显示误差，不能替代服务端的过期校验。

179. 对于 PC 端的 banner 组件，你会怎么适配超宽的屏幕？

答案：

先确定 banner 的内容安全区和最小可读宽度，主体用 max-width 居中，背景用 background-size: cover 或 picture 的裁剪策略，避免在超宽屏被简单拉伸。对关键文字和按钮放在独立内容容器内，设置 clamp、断点和安全边距；必要时提供超宽专用素材或 focal-point 定位。用 CSS aspect-ratio 固定占位，结合 srcset/sizes 选择资源，并在 1440、2560 及缩放场景检查裁剪、清晰度和性能。

180. ChatGPT 的对话功能实现，为什么选择 SSE 协议而非 Websocket ？

答案：

聊天主要是服务端到客户端的单向增量传输，SSE 基于 HTTP，浏览器原生支持 EventSource，接入代理、鉴权、重连和心跳较简单，文本流也容易按事件处理。WebSocket 是双向长连接，适合客户端高频实时发送、协同编辑或双向控制，但需要额外的连接管理、心跳、广播和扩展方案。SSE 不适合二进制和严格双向场景，且要处理代理缓冲、连接上限与重连去重；选择应以通信方向和部署环境为准。

181. 有一个新的前端项目需要部署到线上，你有什么思路？

答案：

先确认运行时、构建命令、环境变量、域名、接口代理和静态资源路径，提交代码后在 CI 做依赖锁定、类型检查、单元测试、构建和产物审计。部署采用预览环境验收，生产用对象存储/CDN 或容器平台，配置 HTTPS、缓存头、压缩、SPA fallback 和 source map 上报。发布采用不可变版本、灰度或蓝绿、健康检查和可回滚制品；上线后观察错误率、性能、接口可用性，密钥放在平台 Secret，不进入仓库。

182. 怎么在 react 技术栈的低代码平台中，实现组件的脚本注入？

答案：

把脚本设计成声明式事件扩展：低代码组件只暴露白名单 props、事件和受控 API，平台在 onMount、onChange 等时机调用沙箱执行器。不要在主页面直接 eval/new Function 执行不可信代码；可放入隔离 iframe/Worker，采用 CSP、通信 schema、超时、资源限制和权限审批，服务端也要校验与审计。React 状态通过消息或受控 setter 更新，脚本异常要隔离并显示错误，组件卸载时清理监听器和定时器。

183. 怎么实现表单项间的联动？

答案：

先建立字段依赖图，再把联动规则集中配置为 source、target、触发条件和更新策略。源字段变化时按拓扑顺序计算目标值，必要时清空失效值、重新请求选项并触发校验；异步请求用 AbortController 或版本号丢弃过期响应，避免循环依赖和重复触发。React 中可用表单库的 watch/subscribe，Vue 中用 computed/watch；规则应可测试，区分用户输入与程序回填，并保证服务端最终校验。

184. 现在要开发一个响应式的网站，怎么实现根据设备的尺寸和分辨率，加载不同尺寸的 banner？要求不使用 JavaScript

答案：

用 HTML 的 picture/source 配合媒体查询和 CSS 的 image-set，不需要 JavaScript。例如：

<picture>
  <source media="(min-width: 1600px)" srcset="/banner-wide.webp">
  <source media="(min-width: 768px)" srcset="/banner-desktop.webp">
  <img src="/banner-mobile.webp" alt="">
</picture>

浏览器依据 viewport 媒体条件选择资源；若还要按像素密度，可在 srcset 中使用 1x/2x。picture 适合 art direction，srcset/sizes 适合同构图不同分辨率，服务端仍需校验资源格式和缓存。

185. 如果想在小程序中嵌入 markdown 的文档，你有什么思路？

答案：

小程序不能直接照搬 Web 的 Markdown 渲染 DOM。先在服务端或构建阶段把 Markdown 解析为受控 AST/WXML，或使用适配小程序的 Markdown 组件；对代码块、表格、图片、链接和目录分别渲染，并做图片域名、链接跳转、懒加载和样式适配。不要用正则替代完整解析，也不能直接把未经清洗的 HTML 注入；限制节点类型和长度，远程文档要缓存、分页并处理版本更新。

186. 假如让你负责一个商城系统的开发，现在需要统计商品的点击量，你有什么样设计与实现的思路？

答案：

点击量不能只在前端累加：前端在商品可见或点击时生成事件 ID，批量发送商品 ID、页面、用户/匿名标识、时间和实验信息，失败可短暂重试但要保证幂等。后端鉴权、校验和限流后写入消息队列或埋点表，消费者按分钟/小时聚合到统计表，商品 ID 与时间建立索引；高并发场景可用 Redis 计数再异步落库。区分曝光、点击和有效点击，去重、防刷，最终报表接受短暂延迟。

187. 前端如何实现即时通讯？

答案：

即时通讯通常由 WebSocket 提供双向长连接，连接建立后完成鉴权、心跳、断线重连和订阅；消息带 messageId、conversationId、序号和时间，前端按序渲染并用发送中、已送达、已读状态处理确认。断线后用 lastSequence 增量补拉，重连采用指数退避并避免重复连接；离线消息由服务端持久化。群聊、推送和多端同步需服务端路由/广播，生产还要考虑权限、限流、消息大小、加密与连接扩展。

188. 前端怎么做错误监控？

答案：

全局监听 window.onerror、unhandledrejection，框架用 Error Boundary 捕获渲染错误，并接入资源加载、接口失败和性能异常。上报内容包含错误类型、脱敏 URL、用户环境、release、source map 定位、面包屑和采样信息，网络失败可批量发送或用 sendBeacon。服务端聚合指纹、去重、告警和版本回归，生产关闭敏感数据与完整用户输入；错误监控应区分可恢复业务错误和真正异常，避免重复上报。

189. 如何给自己团队的大型前端项目设计单元测试？

答案：

先按领域划分测试边界和风险，优先覆盖纯函数、状态机、数据转换、权限规则和复杂交互，而非追求行覆盖率。统一用 Vitest/Jest、Testing Library 和 MSW，测试用户可见行为与无障碍语义，隔离时间、随机数和网络；组件测试验证 loading、错误、空态和键盘操作，公共包再做契约测试。CI 分层运行、报告覆盖率与变更覆盖率，禁止依赖实现细节，失败测试必须可复现且维护责任明确。

190. 如何做一个前端项目工程的自动化部署，有哪些规范和流程设计？

答案：

流程是提交代码触发 CI，安装锁定依赖，执行 lint、类型检查、单元/E2E 测试和构建，再生成带版本号的不可变制品；通过安全扫描和审批后部署预览环境，验收通过再灰度/蓝绿发布生产。配置与密钥由环境管理，构建与部署分离，缓存依赖但不缓存错误产物；设置健康检查、CDN 缓存失效、日志监控、回滚制品和数据库/配置兼容策略。分支保护、可追溯提交和最小权限是基本规范。

191. 怎么分析页面加载慢的原因？

答案：

先用 Chrome Performance、Network、Lighthouse 和 Web Vitals 定位：判断是 DNS/连接、TTFB、阻塞渲染、JS 执行、主线程长任务、图片字体、接口瀑布还是第三方脚本。检查 bundle 分析、缓存命中、压缩、预加载和布局抖动，并区分冷启动与缓存后体验。优化按收益验证：代码分割和懒加载、图片响应式压缩、减少同步 JS、优化关键 CSS/字体、CDN 与接口并行；用真实用户 LCP、INP、CLS 数据确认效果，避免只看本地分数。

192. 如何监控前端页面的崩溃？

答案：

“崩溃”要同时覆盖未捕获异常、Promise rejection、框架渲染错误和页面无响应。接入 Error Boundary、全局异常监听与监控 SDK，记录 release、设备、路由、错误指纹和脱敏面包屑；用 source map 还原堆栈，按会话去重告警。对卡死可用 Web Worker/主线程心跳、长任务监测和页面可见性信息辅助判断，崩溃后在下次启动上报崩溃标记。监控不能阻塞主流程，采样、隐私和告警阈值要可配置。

193. 实现 table header 吸顶， 有哪些实现方式？

答案：

常用方案是给 th 设置 position: sticky; top: 0; z-index，并给表头设置背景色；它依赖最近的可滚动祖先，祖先不能有不合适的 overflow，表格布局也要稳定。兼容性要求高时，可监听容器滚动，计算表头位置并用独立副本或 transform 固定；超大表格还应结合虚拟滚动。

194. 前端单页应用 History 路由模式， 需要如何配置 nginx？

答案：

History 路由刷新时，nginx 应把未知路径回退到前端入口，而静态文件和接口仍按原规则处理：location / { try_files $uri $uri/ /index.html; }。生产中还要配置正确的 root、缓存策略和 gzip；若接口与前端同域，需避免把 /api/ 错误回退到 index.html。

195. 前端如何实现截图？

答案：

截图要先明确范围：DOM 区域可用 html2canvas 等库，将节点绘制到 Canvas 后导出 Blob 或 PNG；整页、跨域图片、字体和视频需要处理资源 CORS、加载完成时机及滚动拼接。浏览器原生 getDisplayMedia 适合截取用户授权的屏幕。Canvas 跨域资源未通过 CORS 时会污染画布，无法导出。

196. Redux 和 Vuex 的设计思想是什么？

答案：

Redux 和 Vuex 都把共享状态集中到可预测的单一数据源，通过明确的状态变更流程降低组件间耦合，并支持调试、插件和时间旅行。Redux 通常以纯函数 reducer 处理 action，强调不可变更新；Vuex 按 state、getters、mutations、actions 分层，更贴合 Vue 响应式体系。两者都应避免把所有局部状态全局化。

197. 怎么实现同一个链接，PC 访问是 web 应用，而手机打开是一个 H5 应用？

答案：

通常使用同一个域名，根据 User-Agent、设备能力或服务端下发的路由策略区分入口：桌面返回 Web 构建，移动返回 H5 构建；也可让统一入口加载不同资源。不要只依赖 UA 做安全判断，关键权限必须由服务端校验。还要处理搜索引擎、缓存 Vary: User-Agent、重定向和深链回退，避免 CDN 缓存错版本。

198. 如何在前端团队快速落地代码规范

答案：

先统一规则和边界：选择 ESLint、Prettier、Stylelint、提交信息规范及目录约定，提供可继承配置和示例。把校验接入编辑器、lint-staged、Git hooks 和 CI，增量修复存量问题，禁止新增违规；通过 codemod、脚手架和文档降低使用成本。规则应有负责人、版本和豁免机制，避免只靠口头约束。

199. react 中怎么实现下拉菜单场景，要求点击区域外能关闭下拉组件

答案：

由受控状态保存 open，按钮点击切换；下拉层打开时在 document 上注册 pointerdown，判断 event.target 是否位于组件根节点内，外部则关闭，并在卸载或关闭时移除监听。可用 ref 包住触发器和菜单，优先用事件冒泡统一处理；还应支持 Escape、键盘焦点和无障碍属性，避免点击内部元素误关闭。

200. 如何解决 node_modules 中，同一个包安装了多个不同版本的问题？

答案：

先用包管理器的依赖树定位重复版本：npm ls、pnpm why 或 yarn why。优先升级依赖到共同兼容版本；可用 overrides、resolutions 或 pnpm 的 overrides 强制统一，并重新生成锁文件。若主版本确实不兼容，应保留隔离版本而不是强行覆盖，验证运行时单例要求、构建产物和测试后再清理 node_modules。

201. 如何解决页面请求接口大规模并发问题

答案：

先区分重复请求、并发批量和服务端瓶颈。前端可做请求合并、去重、缓存、分页、并发池和取消无效请求；批量接口应由后端提供，避免一次提交无限数据。用队列限制同时在途数量，例如维护计数器，完成一个再启动下一个；同时设置超时、重试退避和幂等键。不能只在前端限流，服务端仍需限流、分页和监控。

202. 如何设计一套统计全站请求耗时的工具

答案：

封装统一请求层，在发起时记录高精度时间，统一生成 requestId、URL、方法、状态、重试次数和网络类型；响应、异常、超时和取消都进入同一结束函数，计算 duration 后上报。上报应采样、批量、空闲发送并失败静默，过滤 token、姓名等敏感数据。指标按接口和状态分桶，结合长任务、页面路由与用户环境，才能定位端到端瓶颈。

203. 如果用户说 web 应用感觉很反应慢或者卡顿，该如何排查？

答案：

先复现并区分网络慢、首屏慢、交互卡顿和接口等待。用 Performance、Network、Lighthouse、长任务和内存快照看 LCP、INP、CLS、JS 执行、布局抖动及重复渲染；再检查包体、缓存、图片、接口瀑布和错误日志。优化可采用代码分割、懒加载、虚拟列表、减少主线程计算、批处理更新。低端设备和真实用户数据比只看开发机更可靠。

204. 站点一键换肤的实现方式有哪些？

答案：

推荐用 CSS 变量承载语义色：--color-bg、--color-text，切换根节点的主题属性或 class 即可，组件无需重渲染；主题配置可通过设计令牌统一管理。多套完全不同的资源可按主题动态加载 CSS。要处理首屏闪烁、持久化、系统偏好、对比度和第三方组件，切换时也要保证图标、阴影和图片资源同步。

205. 说说你对 package.json 中配置项的了解

答案：

package.json描述项目元数据、入口、脚本、依赖和发布行为。dependencies是运行时依赖，devDependencies用于开发构建，peerDependencies声明宿主必须提供的兼容范围；scripts定义命令，bin暴露 CLI，main、module、exports影响模块入口，type决定模块模式。版本范围和锁文件共同影响可复现安装，发布包还应检查 files、engines 与许可证。

206. 怎么实现扫码登录？

答案：

扫码登录通常分三步：页面向服务端申请一次性二维码和 sceneId，展示二维码；客户端通过 WebSocket、SSE 或轮询等待扫码、确认、过期状态；服务端确认后签发短期登录凭证，页面换取正式会话并跳转。sceneId必须随机、短时有效且只能消费一次，确认动作要绑定用户和设备，传输使用 HTTPS，并限制轮询频率。

207. 怎么在前端页面中添加水印？

答案：

可用固定定位的文本层作为可视水印，或把水印绘制到 Canvas，再通过 MutationObserver 监测节点被删除后恢复。更可靠的是服务端按用户、时间、订单号生成带身份信息的动态水印，并在导出文件时嵌入。前端水印只能提高移除成本，无法防止截图、开发者工具或图像编辑；敏感内容仍需权限、审计和访问控制。

208. 如何将JavaScript代码解析成抽象语法树(AST)？

答案：

使用 Babel parser、Acorn、Espree 或 TypeScript compiler API 读取源码并生成 AST，例如 const ast = parse(code, { sourceType: 'module', plugins: ['typescript'] })。解析器要按源码语法选择 JSX、TypeScript、装饰器等插件；之后用 visitor 遍历节点，进行分析或转换，最后用 generator 输出代码。AST 只描述语法结构，作用域、类型和运行时语义需要额外分析。

209. 前端项目里，一般对请求 request 做哪些统一的封装？

答案：

统一封装通常包括 baseURL、默认 headers、序列化和响应解析；请求拦截器注入认证信息、traceId，响应拦截器统一处理业务码、HTTP 错误、登录失效和提示。还应支持超时、取消、重试退避、幂等、文件上传下载、缓存、并发去重及 TypeScript 类型。错误要保留可诊断上下文，避免在底层强行弹业务提示，防止重复处理。

210. 如何封装一个请求，让其多次调用的时候，实际只发起一个请求的时候，返回同一份结果？

答案：

用 key 到 Promise 的 Map 做进行中的请求去重：首次调用创建 Promise 并缓存，后续相同 key 直接返回它；在 finally 中删除缓存，确保成功、失败和取消都能再次请求。key 必须包含会影响结果的参数，参数序列化要稳定；若要复用已完成结果，再增加带 TTL 的缓存。注意取消一个调用不应误伤共享 Promise 的其他调用者。

211. token过期后，页面如何实现无感刷新？

答案：

响应 401 后进入刷新队列：只允许一个 refresh 请求，其余失败请求等待同一个 Promise；刷新成功后更新内存凭证并重放原请求，刷新失败则清理会话并跳转登录。请求需携带重试标记，避免 refresh 自身递归；并发刷新要防竞态，刷新 token 使用安全的 HttpOnly Cookie 或受保护存储，并考虑多标签页同步和请求取消。

212. web 应用中如何对静态资源加载失败的场景做降级处理？

答案：

先捕获资源错误并区分脚本、样式、图片和字体。脚本可切换备用 CDN、按版本回退、动态重载一次或展示可恢复错误页；CSS 可加载备用样式，图片提供占位图，字体回退系统字体。资源地址必须带内容哈希，避免错误缓存；记录资源 URL、版本、网络和错误原因，设置重试上限，防止失败循环。关键静态资源应有多地域或本地兜底。

213. 如何搭建一套灰度系统？

答案：

灰度系统先定义目标、用户分群和成功指标，再由服务端或网关依据用户、租户、地域、设备、百分比等稳定规则生成版本路由，并保证同一用户粘性。前端只负责展示版本能力，权限和核心策略由服务端控制。配置中心需支持实时变更、审计、回滚和默认版本；发布前做兼容验证，线上监控错误率、性能和业务指标，异常自动收敛流量。

214. 你参与过哪些前端基建方面的建设？

答案：

我会从可复用和交付效率出发建设：统一脚手架、目录和工程配置，沉淀组件库与设计令牌；建设请求层、埋点监控、错误上报、权限路由和发布流水线；用 ESLint、测试、CI 和依赖治理保证质量。基建应有清晰 API、文档、示例和版本策略，先解决高频痛点，关注接入成本、稳定性和真实使用率，而不是只堆工具。

215. web 网页如何禁止别人移除水印

答案：

网页无法可靠禁止别人移除水印。可以把水印平铺到内容层、Canvas 或服务端生成的图片中，使用动态用户标识提高追责能力，并通过 MutationObserver 发现 DOM 删除后恢复；同时禁用部分选择、右键只能增加操作成本，不能阻止截图、禁用 JavaScript 或图像编辑。真正的保护依赖鉴权、最小权限、审计、限流和服务端输出控制。

216. 你是怎么理解前端架构的？

答案：

前端架构是围绕业务目标，对页面、状态、数据流、模块边界、工程流程和运行保障做出的长期约束与协作方式，不等同于目录结构或选型。好的架构强调高内聚低耦合、可替换、可测试、可观测和渐进演进；先识别规模、团队、性能与发布约束，再决定单体、模块化或微前端，避免为不存在的问题过度设计。

217. 用户访问页面白屏了， 原因是啥， 如何排查？

答案：

白屏可能来自入口资源 404、JS 语法或运行时异常、路由回退错误、接口阻塞、权限重定向、CSS 覆盖、兼容性和资源加载超时。先看监控与浏览器 Console、Network，确认 HTML、主脚本和接口，再用 source map 定位堆栈，检查首屏渲染和路由守卫。应增加全局错误边界、超时兜底、资源降级和白屏探针，并用真实设备复现。

218. React 如何实现 vue 中 keep-alive 的功能？

答案：

React 没有内置与 Vue keep-alive 完全相同的通用组件。简单场景可让页面组件始终挂载，仅用 CSS 隐藏；路由场景可用 react-router 配合缓存库，或实现按 key 缓存元素的容器，在切换时保留组件实例。缓存需限制数量并提供淘汰策略，处理滚动位置、数据刷新、定时器和副作用清理，否则会造成内存泄漏和过期状态。

219. 怎么使用 webpack，将 JS 文件中的 css 提取到单独的样式文件中？

答案：

使用 mini-css-extract-plugin 把 CSS 从 JS 依赖图中抽出：配置 MiniCssExtractPlugin.loader 替换 style-loader，再添加插件，例如 new MiniCssExtractPlugin({ filename: '[name].[contenthash].css' })；生产环境配合 css-loader、预处理器 loader 和 optimization.splitChunks。开发环境通常保留 style-loader 以支持热更新，生产需确保 CSS 文件被 HTML 引用并处理公共 chunk。

220. 低代码平台的页面数据结构该怎么设计？

答案：

页面数据应分为页面元信息、组件树、组件属性、布局约束、数据源、事件动作和版本信息。例如节点用稳定 id、type、props、children 表达，事件用受限 DSL 或 action 引用，不直接保存可执行代码。数据结构应可校验、可迁移、可撤销，区分设计态和运行态；外部数据源用 schema、变量和权限描述，避免把大数据结果固化进页面 JSON。

221. 低代码平台怎么设计渲染模块？

答案：

渲染模块应有组件注册表，把 schema 的 type 映射到受控组件；递归渲染节点，向组件传入校验后的 props、上下文和事件代理。未知组件显示可诊断占位，避免整个页面崩溃。设计态还要支持选中、拖拽、标尺和错误边界，运行态则去掉编辑能力；组件版本、异步加载、样式隔离、权限和性能缓存都应纳入协议。

222. 在前端应用中，怎么进行系统权限的设计？

答案：

权限应由服务端作为最终裁决，前端只做体验层控制。登录认证后获取用户、角色、组织和资源权限，路由守卫控制页面进入，菜单和按钮依据能力隐藏或禁用，接口响应仍必须鉴权。模型可采用 RBAC，复杂资源再结合 ABAC、数据范围和操作级权限；权限配置要可缓存但及时失效，默认拒绝，避免把敏感权限硬编码在前端。

223. 如果让你实现一个前端日志埋点 SDK，你会有什么样的设计思路？

答案：

SDK 分层设计：核心负责初始化、队列、采样、批量上报和公共上下文；插件分别采集页面浏览、点击、性能、错误、网络和自定义事件。提供稳定、异步、低侵入 API，事件带 schema、时间、版本、sessionId 和 requestId；用 sendBeacon 或 fetch keepalive 上报，失败重试并限额。默认脱敏、用户可关闭，避免采集密码等敏感数据，并通过 source map 和采样控制成本。

224. 在项目中封装组件时，你会有些什么样的原则？

答案：

组件边界应围绕稳定职责和复用场景划分，API 只暴露必要能力，优先组合而非大量配置分支；输入输出类型明确，受控与非受控模式约定一致。组件内部管理局部状态，不越权修改外部数据，样式隔离且支持主题和无障碍；处理加载、空态、错误和边界尺寸，提供文档、示例和测试。避免为一次性页面过早抽象，也避免通用组件绑定具体业务。

225. 前端系统中，怎么统一处理登录态过期的场景？

答案：

在请求层统一处理：识别 401 或约定的登录过期码，暂停后续请求并用 refresh token 静默换取新 token；刷新成功后更新凭证并重放队列，失败则清理登录态并跳转登录页。用单例刷新锁和 pending 队列避免并发刷新，跳转前记录 returnUrl，且避免对刷新接口本身重试。

226. 常见的登录鉴权方式有哪些？

答案：

常见方式有 Cookie-Session、JWT、OAuth 2.0、OIDC，以及基于 API Key 的服务鉴权。Session 通常由服务端保存状态，Cookie 自动携带并需配合 HttpOnly、Secure、SameSite；JWT 适合无状态校验，但要控制有效期和撤销策略；OAuth 解决授权，OIDC 在其上提供身份认证。

227. 如果需要使用 JS 执行 100 万个任务，如何保证浏览器不卡顿？

答案：

不能在一个长同步循环里执行 100 万次，否则会阻塞主线程。应分批处理，每批完成后通过 setTimeout、MessageChannel 或 scheduler.yield() 让出事件循环；纯计算可放入 Web Worker，结果用 transferable 或分片回传。任务应支持取消、进度反馈和异常隔离。总复杂度仍为 O(n)，但单帧工作量受控。

228. 对于分页的列表，怎么解决快速翻页场景下的竞态问题？

答案：

每次请求带上 page、filter 快照和递增 requestId；响应返回时只有仍匹配当前查询条件且 requestId 最大的结果才能写入状态。切换页或条件时用 AbortController 取消旧请求，减少无效流量。分页组件还应处理重复点击、请求失败、空页和总数变化导致的页码越界。

229. 如何检测网页空闲状态（即一定时间内无操作）？

答案：

维护一个 inactivityTimer，统一监听 pointerdown、keydown、scroll、touchstart 等实际活动事件；事件发生时更新 lastActiveAt，并清除后重新 setTimeout。定时器触发后再用 Date.now()-lastActiveAt 校验，避免后台标签页计时器降频造成误判。组件卸载时移除监听并清理定时器，页面切回前台可重新检测。

230. 前端应用上线后，怎么通知用户刷新当前页面？

答案：

构建时生成带 hash 的静态资源，并让 HTML 或 manifest 返回当前版本号。客户端启动时轮询版本接口；发现版本变化后提示“有新版本”，由用户确认后调用 location.reload()，或在安全时机自动刷新。刷新前保存表单和路由状态，避免直接打断编辑；同时配合 Service Worker 的 skipWaiting、缓存清理和回滚策略。

231. 如何从 0 到 1 搭建前端基建？

答案：

从规范、工程和交付三层搭建：先确定浏览器兼容范围、技术栈和目录规范；再统一 TypeScript、ESLint、Prettier、提交检查、环境变量、构建与 CI；抽取请求层、权限路由、错误处理、组件和工具库，并配套文档、脚手架和示例。基础设施应小步验证、可观测、可回滚，避免为了抽象而抽象。

232. 在表单校验场景中， 如何实现页面视口滚动到报错的位置

答案：

校验完成后拿到第一个错误字段的 DOM 引用，先确保其可见，再调用 element.scrollIntoView({ behavior: 'smooth', block: 'center' })；有固定顶部导航时通过 scroll-margin-top 或手动计算偏移。React/Vue 中要在错误状态更新后的 nextTick/useLayoutEffect 执行，滚动后再 focus，并处理字段尚未挂载、弹窗内滚动容器等边界。

233. 为什么在技术选型中选择了 webpack？

答案：

选择 webpack 通常是基于项目约束，而非工具优劣：它生态成熟、loader/plugin 丰富，能覆盖复杂资源处理、微前端、老浏览器兼容和定制构建流程；团队也更容易复用既有经验。代价是配置和构建速度较重。若项目追求极简配置和快速开发，也会评估 Vite、Rspack 等替代方案。

234. 如果公司要做一个低代码平台，你会怎么进行架构设计？

答案：

核心是 schema 驱动：用 JSON Schema 描述页面结构、组件属性、校验和事件，设计器通过拖拽生成 schema，渲染器按组件注册表映射到安全组件。配置与渲染解耦，状态、数据源、权限和联动通过受限 DSL 或表达式执行，禁止任意脚本。服务端负责版本、发布、审计和权限，前端还需撤销重做、校验、预览及性能隔离。

235. 如果想将一个前端项目中的 px 全部转为 rem，你有什么思路

答案：

先统一设计稿基准，例如将根字体设为 viewport 宽度的 1/10，再按 px/基准值换算为 rem；可用 PostCSS 或 Sass 函数在构建期自动转换，保留 1px 边框、第三方样式和需固定的媒体查询。移动端要结合 viewport、最大根字号和媒体查询，避免大屏无限放大，并用视觉回归检查换算误差。

236. 对于富文本编辑器中的划词交互（鼠标滑动选择一组字符， 对该组字符进行操作），你有什么实现思路？

答案：

利用 Selection/Range API：mouseup 或 selectionchange 时读取 window.getSelection()，确认 range 非折叠且选区属于编辑器，再通过 getClientRects() 定位浮动工具栏。操作前保存 range.cloneRange()，执行加粗、链接等命令时恢复选区并用编辑器事务更新模型。要处理跨节点选区、键盘选择、失焦、滚动定位和 XSS，不能只依赖 document.execCommand。

237. 如何在浏览器中实现 PDF 文件的预览？

答案：

最简单是让服务端返回正确的 application/pdf 和 Content-Disposition: inline，前端用 iframe、embed 或新窗口打开 PDF URL。若需要自定义分页、缩放和文本层，可使用 PDF.js，将 ArrayBuffer 交给 worker 渲染到 canvas，并销毁页面资源。要处理鉴权下载、跨域、超大文件、加载失败和 blob URL 的 revoke，避免把不可信内容直接当 HTML 执行。

238. 做前端错误监控时，有什么办法能将报错的源码地址，包括代码行数也进行上报吗？

答案：

生产构建开启 source map，但不要把未保护的源码地图公开到公网；错误上报 stack、文件 URL、行列号、版本号和构建 hash，服务端用对应版本的 source map 解析堆栈，得到原始源码位置。source map 需与发布版本严格绑定并限制访问权限，上传内容脱敏；同时采样、去重和限流，避免监控本身造成泄漏或流量压力。

239. 设计一个技术方案，能在排查问题时，还原用户的操作流程

答案：

在客户端建立轻量行为录制器，记录路由、点击目标、输入变化摘要、网络请求结果、控制台错误和关键性能指标，并附时间戳、会话 ID、版本及设备信息。敏感输入默认脱敏或只记录字段类型，使用 ring buffer 保存最近一段事件，出错时批量上报；服务端按会话重放时间线，必要时接入 DOM 快照或 rrweb，并设置采样、加密、权限和保留期限。

240. 前端渲染和后端渲染分别有什么优缺点， 为什么现在的技术大方向，又逐渐往“后端渲染”方向靠了呢？

答案：

前端渲染交互灵活、服务端压力较小，但首屏和 SEO 依赖下载、解析并执行 JS；后端渲染首屏和搜索抓取更友好，弱网体验较稳，却增加服务端计算、缓存和 hydration 成本。现在倾向 SSR/SSG、流式渲染与 Server Components，是为了降低首屏 JS 和提升可感知性能，并非所有页面都应后端渲染，强交互应用仍常用 CSR 或混合模式。

241. 如果你有一个内容站点，怎么防止其他人爬虫？

答案：

无法彻底阻止爬虫，只能提高滥用成本并保护资源。先区分公开内容与需授权内容，使用 robots.txt 表达规则但不当作安全边界；服务端做登录、权限、限流、IP/设备信誉和异常行为检测，配合 CDN/WAF、验证码、请求签名及分页上限。对版权内容加水印和追踪，监控日志并保留封禁、申诉和误伤恢复机制。

242. 业务需要实现前端项目的灰度发布，你会怎么设计？

答案：

按用户或特征做稳定分流：发布系统生成兼容的 hash 版本资源，网关依据账号、租户、地域或 cookie 将用户固定到灰度版本，并让 HTML、静态资源和 API 版本一致。前端上报版本、错误和核心指标，设置白名单、比例、开关、自动熔断和一键回滚；灰度期间处理缓存、长连接、数据结构向后兼容及刷新切换问题。

243. 一般怎么做代码重构？

答案：

先用测试、监控或复现步骤建立行为基线，明确重构目标和边界，再按模块小步修改，每步保持可运行并及时提交。优先消除重复、拆分职责、改善命名和依赖方向，必要时补类型与测试；不要同时改变业务规则。通过单测、集成测试、静态检查、构建和灰度验证，比较性能与错误指标，最后清理兼容代码并记录决策。

244. 请求失败会弹出一个 toast，如何保证批量请求失败时， 只弹出一个 toast？

答案：

把 toast 做成全局单例，并用消息去重或节流。请求层统一捕获错误，使用固定 errorCode、请求场景或文案生成 key；在一个短时间窗口内只展示一次，其余错误合并为“多个请求失败”或交给页面汇总。成功重试、用户主动操作可重置窗口；同时区分业务错误、取消请求和网络断开，避免把正常取消误报给用户。

245. 什么是单点登录，以及如何进行实现？

答案：

单点登录是用户登录一次后，在多个相互信任的系统间共享身份，不必重复输入凭证。常见实现是统一认证中心结合 OAuth 2.0/OIDC：业务系统把用户重定向到认证中心，认证成功后通过授权码换取 token，再建立本系统会话。各系统校验 issuer、签名、audience、过期时间和 nonce，并用 HTTPS、短时 token、PKCE、注销与撤销机制保障安全。