大模型面试宝典

Appearance

Loop Engineering 面试高频题 ​

第一部分：基础篇（1-50题） ​

模块一：Loop Engineering 基础概念（1-15题） ​

1. 【⭐】什么是 Loop Engineering？和 Prompt Engineering 有什么区别？

  • 考察点：对 Loop Engineering 核心概念的理解，以及 AI 工程范式演进的认识
  • 得分项：能清晰定义 Loop Engineering、能对比 Prompt Engineering 的差异、能说明两者是叠加关系而非替代关系
  • 回答：Loop Engineering（循环工程）是指设计一套让 AI Agent 能够自主发现任务、分配任务、执行任务、验证结果、记录状态的持续运行系统。Prompt Engineering 是「教 AI 怎么做一件事」，而 Loop Engineering 是「设计一套系统，让 AI 自己反复做，直到做完」。两者的关系不是替代——Prompt Engineering 没死，它是地基，一个 Loop 本来就是由一堆 Prompt 组成的。Loop Engineering 是盖在 Prompt 上面的楼层。

2. 【⭐】Loop Engineering 是在什么背景下兴起的？

  • 考察点：对 AI 工程演进历程的理解
  • 得分项：能说出 AI 工程范式演进脉络、能提及关键人物和事件、能理解范式迁移的驱动力
  • 回答：Loop Engineering 的兴起有明确的引爆点。第一把火是 Claude Code 负责人 Boris Cherny 公开表示「我已经不直接给 AI 打字下指令了，我有一堆循环在跑」。第二把火是 OpenClaw 作者 Peter Steinberger 说「你不该再手动提示编程 AI，你该去设计那个让 AI 自己提示自己的循环」。随后 Google 工程师 Addy Osmani 正式把这套实践系统化命名为 Loop Engineering。从演进脉络看，AI 工程经历了 Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering 四个阶段，是层层叠加的抽象升级。

3. 【⭐】Loop Engineering 的核心组件有哪些？

  • 考察点：对 Loop 系统架构的掌握
  • 得分项：能列出 5-6 个核心组件、能解释每个组件的作用、能说明组件之间的关系
  • 回答：一个完整的 Loop 系统通常包含六个核心组件：①自动化/触发器——Loop 的心跳，定时或事件触发启动；②工作树（Worktree） ——并行隔离，让多个 Agent 互不干扰地工作；③Skill——沉淀项目知识、规范、踩坑经验，让 Agent 每次开工先读；④连接器（MCP） ——让 Agent 连接真实工具，如 GitHub、数据库、API 等；⑤子 Agent——把做事的人和检查的人分开；⑥跨会话记忆层——记录做过什么、卡在哪、下一步是什么。

4. 【⭐】一个 Loop 到底在「循环」什么？

  • 考察点：对 Loop 运行机制的理解
  • 得分项：能说清循环的对象、能列举循环中流转的关键要素、能理解循环的本质
  • 回答：Loop 循环的是五个关键要素：上下文（每轮携带的历史信息）、状态与记忆（当前进度和过往记录）、预算（Token 消耗和步数限制）、可用工具集（Agent 能调用的工具范围）、终止与收敛判断（何时停止）。本质上，Loop 循环的是一段不断增长和演化的「工作流状态」——每跑一轮，系统根据上一轮的观察结果决定下一步，直到任务完成或达到终止条件。

5. 【⭐】Loop Engineering 和 ReAct 是什么关系？

  • 考察点：对 ReAct 的理解以及 Loop 与 ReAct 的区分
  • 得分项：能准确解释 ReAct、能区分 ReAct 和 Loop 的本质差异、能说明两者如何配合
  • 回答：ReAct（Reasoning + Acting）出自 2022 年 Google 的论文，本质是一个 Prompt 范式——让模型按「思考→行动→观察」的格式输出。它的全部「魔法」在于用一段提示词诱导模型按格式输出，外面再写个循环把观察结果拼回上下文。而 Loop Engineering 是一套系统架构，不仅包含 ReAct 的推理-行动循环，还包含自动化触发、并行隔离、技能沉淀、工具连接、子 Agent 分工、跨会话记忆等完整的基础设施。可以把 ReAct 理解为 Loop 内部的一个执行模式，而 Loop Engineering 是让这个模式能够长期、稳定、规模化运行的系统工程。

6. 【⭐】为什么 Agent 需要 Loop？

  • 考察点：对 Agent 执行机制的理解
  • 得分项：能说明 Agent 任务的多步特性、能解释为什么一次性生成不够、能理解迭代的价值
  • 回答：Agent 需要 Loop，因为它不是一次性生成答案，而是要在目标、环境反馈和工具结果之间不断迭代。典型流程是：读取任务 → 规划 → 调用工具 → 观察结果 → 根据结果调整 → 继续下一步。单次问答只能处理简单任务，真实项目中的 Agent 需要读代码、搜调用链、改文件、跑测试、看日志、继续改。如果没有 Loop，Agent 就无法根据环境反馈持续调整自己的行为。

7. 【⭐】Loop Engineering 中的「自动化」指什么？

  • 考察点：对 Loop 触发机制的理解
  • 得分项：能解释自动化的含义、能列举几种触发方式、能理解自动化的价值
  • 回答：自动化是 Loop 的「心跳」或「定时任务」，让 Loop 真正成为一个自行运转的系统而非一次性执行。常见触发方式包括：定时触发（如 cron 调度）、事件触发（如 GitHub hook）、持续目标模式（/goal——一直运行到目标完成为止）。没有自动化，Loop 就只是「手动跑了一次」，不叫循环。

8. 【⭐】Loop Engineering 中的「Skill」是什么？

  • 考察点：对知识沉淀机制的理解
  • 得分项：能解释 Skill 的定义、能说明其作用和价值、能举例
  • 回答：Skill 是把项目相关的知识、规范、架构、踩过的坑等打包成一份文件，让 Agent 每次开工前先读取。它解决了「每次从零推导」的问题——没有 Skill，Loop 每一轮都要从零理解项目该怎么做；有了 Skill，每一轮都能吸取上一次的经验。Skill 本质上是一种上下文缓存机制，让项目知识在 Loop 的各轮之间得到沉淀和复用。

9. 【⭐】Loop Engineering 和 Context Engineering 是什么关系？

  • 考察点：对 AI 工程范式演进的理解
  • 得分项：能区分两个概念、能说明它们的层次关系、能理解演进逻辑
  • 回答：Context Engineering 关注「模型能看到什么」——把任务所需的全部背景塞进模型的上下文窗口。Loop Engineering 则是在 Context Engineering 之上，进一步关注「模型持续做什么」——让系统自动决定何时需要什么上下文、如何在不同轮次之间传递状态、如何根据反馈调整策略。Context Engineering 解决的是「信息够不够」的问题，Loop Engineering 解决的是「活儿能不能持续干完」的问题。

10. 【⭐】什么是 Harness Engineering？和 Loop Engineering 什么关系？

  • 考察点：对 Harness 概念的理解及其与 Loop 的关系
  • 得分项：能定义 Harness、能说明它与 Loop 的层次关系
  • 回答：Harness（挽具/治理框架）是围绕模型运行的整套脚手架——测试工具、输入输出约束、格式校验、评估框架。它的核心是「怎么判断答得对不对」。Harness Engineering 关注的是单次执行的质量控制，而 Loop Engineering 关注的是多轮持续执行的整体治理——不仅要判断单次对不对，还要决定不对之后怎么办、怎么恢复、怎么终止。

11. 【⭐⭐】Loop Engineering 中的「子 Agent」模式是什么？为什么重要？

  • 考察点：对多 Agent 协作模式的理解
  • 得分项：能解释子 Agent 分工、能说明「写」与「检查」分离的价值、能理解防止「放水」的机制
  • 回答：子 Agent 模式的核心是把「写代码的 Agent」和「检查代码的 Agent」拆成两个独立的 Agent。让写代码的 Agent 自己给自己打分太容易「放水」了——第二个独立的 Agent 配不同的指令，甚至用不同的模型，专门负责检查前者的工作成果。这种「制衡」机制是 Loop 能无人值守运行的关键——开发者敢放开监管的最大底气就是子 Agent 的质量把关。

12. 【⭐】MCP（Model Context Protocol）在 Loop Engineering 中扮演什么角色？

  • 考察点：对 MCP 协议的理解及其在 Loop 中的定位
  • 得分项：能解释 MCP 是什么、能说明它在 Loop 中的作用、能理解连接器的价值
  • 回答：MCP 是连接器的底层协议，让 Agent 能读取 Issue Tracker、查数据库、调 API、发消息。在 Loop Engineering 中，连接器决定了 Loop 能不能碰到真实的工具——「一个只能看文件系统的 Loop 是个小 Loop，能操作工具干活才是真正的 Loop」。MCP 让 AI 从「说'这是修复方案'」变成「自动开 PR、关联工单、CI 过了通知群里」。

13. 【⭐】Loop Engineering 和传统的自动化脚本有什么区别？

  • 考察点：对 Loop 非确定性本质的理解
  • 得分项：能区分确定性与非确定性、能理解 LLM 带来的新挑战、能说明 Loop 的适应性
  • 回答：传统自动化是图灵完备的确定性程序，每一步都在预期内。而基于 LLM 的 Agent 是非确定性的概率程序——同样的问题，模型可能给出不同的答案和行动路径。Loop Engineering 不是简单地「把脚本循环跑」，而是设计一个能处理非确定性输出的系统：需要上下文管理、状态追踪、异常处理、终止判断等传统自动化不需要的组件。简单说，传统自动化是「写死流程」，Loop 是「设计一个能自己决定流程的系统」。

14. 【⭐】个人开发者使用 AI 编程和企业在生产环境使用 Loop Engineering 有什么本质区别？

  • 考察点：对 Loop Engineering 企业级应用场景的理解
  • 得分项：能识别个人效率与企业治理的差异、能说明组织层面的挑战
  • 回答：个人使用 AI 编程关注的是效率——一天写出更多代码、一个周末做出一个产品。而企业关注的是可控性——交付链路是否可控、风险是否可追溯、权限是否清晰、知识是否沉淀、成本是否可预算。一名工程师用 AI 提效 30%，不必然意味着团队交付效率提升 30%——更多代码可能带来更重的 Review 压力。Loop Engineering 本质上是在讨论一个更大的问题：当 Agent 具备持续循环执行任务的能力后，组织是否有能力重新设计自己的生产流程。

15. 【⭐】Loop Engineering 的「记忆层」解决什么问题？

  • 考察点：对跨会话记忆机制的理解
  • 得分项：能说明记忆层的作用、能理解长任务 Agent 的「失忆」问题
  • 回答：记忆层记录「做过什么、现在卡在哪、下一步是什么」。它的作用很朴素但关键——长任务 Agent 如果没有记忆层，很快就会开始「失忆」。记忆层可以是一个 Markdown 文件、一个 Linear Board 或其他状态记录系统。它让 Loop 的各轮之间有了状态的连续性，而不是每轮从零开始。

模块二：循环控制与终止机制（16-30题） ​

16. 【⭐】Loop 的终止条件有哪些？

  • 考察点：对循环控制机制的理解
  • 得分项：能列举多种终止条件、能理解每种条件的适用场景
  • 回答：Loop 的终止条件通常包括：①任务完成——目标达成，这是最理想的终止；②达到预算上限——Token 消耗或步数超限；③遇到不可恢复的错误——工具调用持续失败或陷入死循环；④需要人工介入——遇到需要人类判断的决策点。设计良好的 Loop 应该能区分「正常终止」和「异常终止」，并分别给出不同的输出。

17. 【⭐⭐】如何防止 Agent 陷入死循环？

  • 考察点：对循环检测与熔断机制的理解
  • 得分项：能提出多种防死循环策略、能理解每种策略的实现方式
  • 回答：防止死循环需要多层防御：①硬性约束——设置最大迭代次数（Max Iterations）和超时机制；②循环检测——如果 Agent 连续做出相同的 Action，强制触发反思或中断；③熔断机制——同一工具连续失败 3 次，立即终止当前推理链；④兜底方案——达到上限后返回当前阶段最接近的结果，标记为「未完成」。

18. 【⭐】Agent 陷入死循环时，如何在工程上解决？

  • 考察点：对工程化异常处理的理解
  • 得分项：能给出三层防御方案、能解释每层的实现细节
  • 回答：需要三层防御：第一层——工具层硬隔离：在 Agent 调用外部 API 时必须包裹 try-catch，返回结构化错误信息；第二层——推理层熔断：实现 Max Iteration Check 和 Loop Detection 模块；第三层——规划层自我修正：工具调用失败时让 Agent 反思「哪里做错了？是不是参数不对？要不要换工具？」。

19. 【⭐】什么是「反思节点（Reflection Node）」？如何实现？

  • 考察点：对 Agent 自我修正机制的理解
  • 得分项：能解释反思节点的概念、能说明触发条件和实现方式
  • 回答：反思节点是在 Agent 连续两次做出相同 Action 时，强制触发的一个反思 Prompt，提示模型「你已经尝试过此路径且失败了，请更换策略」。实现方式是在循环中维护一个「最近 Action 历史」，每次执行前检查是否与上一次相同，如果相同则插入反思指令。更高级的做法是微软《AI Agents for Beginners》中提到的 Reflection Pattern。

20. 【⭐】工具调用失败时，应该返回什么信息给 LLM？

  • 考察点：对错误信息设计的理解
  • 得分项：能说明结构化错误信息的重要性、能给出错误信息格式示例
  • 回答：不能只返回简单的「Error」，而应该返回结构化的错误信息，包含错误类型、原因和可操作的建议。例如：{"status": "failed", "error_type": "Timeout", "retry_after": 5}。如果是 SQL 报错，要把报错堆栈中最关键的信息塞回上下文，让 Agent 像程序员修 Bug 一样根据报错信息修正下一步。

21. 【⭐】Loop 的预算控制应该考虑哪些维度？

  • 考察点：对成本与资源管理的理解
  • 得分项：能列举多个预算维度、能理解各维度的控制策略
  • 回答：预算控制应考虑：①Token 消耗——每轮调用大模型的输入/输出 Token 数；②步数/轮数——Agent 最多执行多少步；③时间——单轮超时和总超时；④工具调用次数——尤其是调用外部 API 的次数（可能产生费用）；⑤子 Agent 数量——并行运行的子 Agent 数量限制。

22. 【⭐】Loop 的「收敛判断」是什么？怎么实现？

  • 考察点：对任务完成判定的理解
  • 得分项：能解释收敛判断的含义、能说明实现方式
  • 回答：收敛判断是评估「任务是否已经完成」或「是否在朝着正确方向前进」的机制。实现方式包括：①规则检查——如测试全部通过、文件已修改、PR 已创建；②独立评估 Agent——用一个独立的 Agent（甚至不同模型）在每轮结束时检查目标是否达成；③阈值判断——如代码覆盖率提升到 X%、性能指标达到 Y。Claude Code 和 Codex 的 /goal 功能就是这种模式——每跑完一轮，由独立 Agent 判断是否完成。

23. 【⭐】设计 Loop 时，如何平衡「自动化程度」和「人工控制」？

  • 考察点：对 Human-in-the-loop 设计原则的理解
  • 得分项：能说明何时需要人工介入、能设计合理的控制点
  • 回答：关键操作（如删除数据、发版、修改生产配置）前应预留人工确认接口。设计原则是：①低风险操作——全自动，无需人工；②中风险操作——自动执行但记录日志，事后可追溯；③高风险操作——必须人工确认才能继续。Loop 不是要完全取代人，而是让人的精力从「频繁下指令」转移到「设定目标和验收结果」。

24. 【⭐】什么是「兜底方案」？在 Loop 中如何设计？

  • 考察点：对异常处理与优雅降级的理解
  • 得分项：能解释兜底方案的概念、能给出设计思路
  • 回答：兜底方案是当 Loop 达到最大迭代次数或遇到不可恢复错误时，返回「当前阶段最接近的结果」并标记为「未完成」。设计思路包括：①保存中间状态——每轮结束时持久化当前进度；②定义「最小可用结果」 ——即使未完成，也能输出有价值的信息；③清晰标记状态——让用户知道「完成了什么、没完成什么、为什么没完成」。

25. 【⭐】Loop 中的「状态管理」为什么重要？

  • 考察点：对状态管理在 Loop 中作用的理解
  • 得分项：能说明状态管理的重要性、能理解状态丢失的后果
  • 回答：Agent 的工作流不是线性的，而是一个状态机。Loop 的每一轮都依赖上一轮的状态——做了什么、观察到了什么、下一步计划是什么。如果状态管理不当，Agent 会「失忆」——不知道自己在哪、不知道已经尝试过什么、不知道下一步该做什么。状态管理还决定了 Loop 能否从中断处恢复（断点续传）。

26. 【⭐】Loop 的「工作树（Worktree）」解决什么问题？

  • 考察点：对并行隔离机制的理解
  • 得分项：能说明 Worktree 解决的问题、能解释其工作原理
  • 回答：当同时跑两个以上 Agent 时，经常出现两个 Agent 写同一个文件的「撞车」问题。Git Worktree 的思路是在同一个仓库历史上切出一个独立的工作目录，一个 Agent 的修改完全碰不到另一个的工作内容——等于给每个 Agent 配了独立工位，互不干扰。

27. 【⭐】Loop 中如何实现「断点续传」？

  • 考察点：对 Loop 可靠性的理解
  • 得分项：能说明断点续传的必要性、能给出实现思路
  • 回答：断点续传依赖状态持久化——把每轮结束时的状态（已完成步骤、当前上下文、中间产物）写入持久存储（如文件、数据库）。当 Loop 因故中断后，重启时从持久化存储中读取最后保存的状态，从中断处继续，而不是从头开始。Codex CLI 的 /goal 功能支持「跨会话保留状态」。

28. 【⭐】Loop 的「并行隔离」除了 Worktree 还需要什么？

  • 考察点：对并行执行完整基础设施的理解
  • 得分项：能识别 Worktree 之外的并行需求、能给出完整的并行方案
  • 回答：除了 Worktree（文件隔离），还需要：①资源隔离——每个 Agent 独立的 Token 预算和速率限制；②状态隔离——每个 Agent 独立的记忆和上下文；③结果合并——多个 Agent 完成后的结果汇总和冲突解决机制；④依赖管理——Agent 之间的任务依赖关系（哪些可以并行、哪些必须串行）。

29. 【⭐】什么是「Goal 模式」？和普通 Loop 有什么区别？

  • 考察点：对 Loop 不同运行模式的理解
  • 得分项：能解释 Goal 模式、能对比普通 Loop
  • 回答：Goal 模式是 Loop 的一种运行模式——不按时间触发，而是一直运行到最开始制定的标准真正完成为止。每跑完一轮，会有一个独立的 Agent 判断是否完成。普通 Loop 可能基于定时或事件触发，跑完预设轮数就停；Goal 模式则是「目标驱动」——目标是终止条件，没达成就不停。

30. 【⭐】Loop 的「自动化触发器」有哪些类型？

  • 考察点：对 Loop 触发机制的理解
  • 得分项：能列举多种触发器类型、能说明每种的使用场景
  • 回答：触发器类型包括：①定时触发——cron 调度，适合周期性任务（如每日报告）；②事件触发——GitHub hook、Webhook，适合响应外部事件；③持续目标模式（/goal） ——一直运行到目标完成为止；④手动触发——用户主动启动，适合需要人工判断的场景。

模块三：工具与集成（31-40题） ​

31. 【⭐】Loop Engineering 中「连接器」的作用是什么？

  • 考察点：对工具集成机制的理解
  • 得分项：能说明连接器的功能、能举例说明
  • 回答：连接器让 Agent 能连接到真实的外部工具——读 Issue、查数据库、调 API、发消息。没有连接器，Agent 只能「说」不能「做」。连接器通常基于 MCP 协议实现。它决定了 Loop 的「行动力」边界——能连接的工具越多，Loop 能完成的任务就越复杂。

32. 【⭐】MCP 和 Function Calling 是什么关系？

  • 考察点：对 MCP 协议与 Function Calling 的区分
  • 得分项：能区分两者的定位、能说明它们如何配合
  • 回答：Function Calling 是大模型调用工具的一种接口方式——模型输出结构化的函数调用请求。MCP（Model Context Protocol）是一个协议标准，定义了 Agent 与外部工具之间如何发现、连接和交互。可以这样理解：Function Calling 是「怎么调用」，MCP 是「调用谁、怎么发现、怎么标准化」——MCP 在 Function Calling 之上提供了服务发现和标准化的能力。

33. 【⭐】如何让 Loop 中的 Agent 安全地操作外部系统？

  • 考察点：对 Agent 安全性的理解
  • 得分项：能提出多层安全措施、能理解权限最小化原则
  • 回答：安全措施包括：①权限最小化——每个 Agent 只授予完成任务所需的最小权限；②操作审计——记录所有外部操作，可追溯；③危险操作拦截——删除数据、修改生产配置等操作需要人工确认；④沙箱隔离——代码执行在隔离环境中运行；⑤速率限制——防止 Agent 过快调用外部 API 造成破坏。

34. 【⭐】Loop 中如何管理多个工具的调用顺序和依赖？

  • 考察点：对工具编排的理解
  • 得分项：能说明工具调用的编排方式、能理解依赖管理
  • 回答：工具调用的管理方式包括：①LLM 自主决定——让模型自己决定调用什么工具、什么顺序；②预定义 DAG——提前定义工具调用的依赖图（有向无环图）；③混合模式——高层规划由人/系统定义，具体工具选择由 LLM 决定。依赖管理需要处理：工具 A 的输出是工具 B 的输入、工具调用失败后的回滚、并行工具调用的结果合并。

35. 【⭐】Skill 和 Prompt 有什么区别？

  • 考察点：对知识沉淀机制的理解
  • 得分项：能区分 Skill 和 Prompt 的定位、能说明 Skill 的复用价值
  • 回答：Prompt 是一次性的指令——每次使用都要重新输入或重新构造。Skill 是可复用的知识包——把项目技术栈、构建方式、踩坑经验等打包成一份文件，Agent 每次开工先读。区别在于：Prompt 是「这次怎么说」，Skill 是「这个项目长期怎么干」。Skill 让 Loop 每一轮都能吸取上一次的经验，而不是从零推导。

模块四：监控与可观测性（41-50题） ​

41. 【⭐】Loop 的可观测性面临哪些挑战？

  • 考察点：对 Loop 监控难点的理解
  • 得分项：能识别 Loop 可观测性的特殊性、能理解与传统监控的差异
  • 回答：传统 APM 监控的是确定性请求链路，而 Loop 的链路是动态生成的、非确定性的、跨多个 Agent 的。挑战包括：①链路不可预测——每次执行路径不同；②跨 Agent 追踪——多个子 Agent 之间的调用关系复杂；③状态难以重建——Loop 跑了 47 轮后出了问题，很难回溯当时的状态；④缺乏成熟方案——当下没有成熟的 Loop Observability 方案。

42. 【⭐】如何设计 Loop 的日志和追踪系统？

  • 考察点：对 Loop 可观测性设计的理解
  • 得分项：能提出日志设计思路、能理解追踪的关键信息
  • 回答：设计要点包括：①每轮记录——记录轮次、输入、输出、工具调用、耗时、Token 消耗；②状态快照——定期保存完整状态，便于问题复现；③结构化日志——JSON 格式，便于检索和分析；④链路 ID——一次 Loop 执行分配唯一 ID，所有子 Agent 的日志都带上这个 ID；⑤关键指标——轮数、成功率、平均耗时、Token 消耗趋势。

43. 【⭐】Loop 运行中如何发现「已经在错误方向上努力了很久」？

  • 考察点：对 Loop 健康检测的理解
  • 得分项：能提出多种异常检测策略
  • 回答：检测策略包括：①进度停滞检测——连续 N 轮没有实质性进展（如没有文件修改、没有新信息）；②重复行为检测——反复调用同一工具、输出相似内容；③质量阈值——如果评估 Agent 连续多轮给出低分；④预算消耗率——Token 消耗过快但产出有限。一旦检测到异常，应触发熔断或人工告警。

44. 【⭐】Loop 的「成本可预算」如何实现？

  • 考察点：对成本管理的理解
  • 得分项：能说明成本构成、能提出预算控制方法
  • 回答：成本可预算需要：①成本构成清晰——Token 费用、API 调用费用、子 Agent 数量×轮数；②实时成本追踪——每轮结束后累计成本；③预算预警——成本达到阈值时告警；④硬性上限——成本超限时强制终止；⑤成本分摊——按项目/团队/任务维度统计成本。

45. 【⭐】如何评估一个 Loop 的质量？

  • 考察点：对 Loop 评估体系的理解
  • 得分项：能提出多维度的评估指标
  • 回答：评估维度包括：①成功率——Loop 完成任务的百分比；②效率——平均轮数、平均耗时、Token 消耗；③稳定性——异常终止率、死循环发生率；④质量——输出质量（由评估 Agent 或人工判断）；⑤成本效益——完成任务的平均成本 vs 人工完成成本。

46. 【⭐】Loop 的「状态快照」应该包含哪些信息？

  • 考察点：对状态持久化的理解
  • 得分项：能列举状态快照的关键字段
  • 回答：状态快照应包含：①当前轮次——第几轮；②完整对话历史——所有 Thought/Action/Observation；③已完成的子任务列表；④当前任务进度——做到哪了；⑤中间产物——已生成的文件、数据；⑥元信息——开始时间、已耗 Token、已用时间。

47. 【⭐】Loop 的可观测性如何与现有监控系统集成？

  • 考察点：对系统集成能力的理解
  • 得分项：能提出集成方案、能理解现有监控工具的局限性
  • 回答：集成方式包括：①日志集成——将结构化日志接入 ELK/Loki；②指标集成——将关键指标接入 Prometheus/Grafana；③追踪集成——接入 Jaeger/Zipkin（需要适配非确定性链路）；④告警集成——接入 PagerDuty/Slack。但要注意，传统监控工具是为确定性系统设计的，直接套用在 Loop 上会有局限。

第二部分：进阶篇（51-80题） ​

模块五：架构设计与系统集成（51-65题） ​

51. 【⭐⭐】Loop Engineering 的三层技术栈是什么？

  • 考察点：对 Loop 分层架构的理解
  • 得分项：能说明三层架构、能理解每层的职责
  • 回答：Loop Engineering 的技术栈分为三层：Prompt 层——负责与 LLM 的交互指令设计；Context 层——负责上下文的构建、检索和管理；Harness 层——负责测试、校验、评估和质量控制。这三层不是替代关系，而是层层叠加——Prompt 层是地基，Context 层在其上构建，Harness 层在最外层做质量兜底。

52. 【⭐⭐】设计一个生产级 Loop 系统，技术选型应该考虑哪些因素？

  • 考察点：对系统设计和技术选型的综合能力
  • 得分项：能提出全面的选型考量、能权衡不同方案的优劣
  • 回答：技术选型应考虑：①LLM 选型——闭源（GPT/Claude）vs 开源（Llama/Qwen），考量能力、成本、延迟；②编排框架——LangChain/LlamaIndex vs 自研，考量灵活性和可控性；③记忆存储——向量数据库（Pinecone/Milvus）vs 传统 DB，考量检索效率和一致性；④工具协议——MCP vs 自定义，考量标准化和生态；⑤可观测性——现有 APM 工具 vs 自建，考量非确定性链路的适配；⑥成本控制——Token 缓存、模型降级策略。

53. 【⭐⭐】Loop 中的「规划器-执行器」模式是什么？

  • 考察点：对 Agent 架构模式的理解
  • 得分项：能解释规划器-执行器分工、能理解其优缺点
  • 回答：规划器-执行器模式把流程拆成两个角色：规划器一次性把任务分解成完整的步骤清单（Plan）；执行器按清单逐条执行，不再反复调用大模型做全局推理。这种模式解决了 ReAct「走一步想一步」的两个问题：①短视——容易陷入局部最优；②昂贵——每一步都要带着全部历史调一次大模型。缺点是规划器需要很强的全局推理能力，且 Plan 可能因环境变化而过时。

54. 【⭐⭐】什么是「评估者-优化者」模式？在 Loop 中如何应用？

  • 考察点：对 Agent 协作模式的理解
  • 得分项：能解释评估者-优化者模式、能说明其在 Loop 中的应用
  • 回答：评估者-优化者模式是 Anthropic 在《Building Effective Agents》中提出的——一个 Agent 生成方案，另一个 Agent 评估并给出改进建议，循环直到达标。在 Loop 中，这个模式体现为子 Agent 分工：写代码的 Agent 是「优化者」，检查代码的 Agent 是「评估者」。评估者给出反馈，优化者根据反馈修改，循环直到评估通过。

55. 【⭐⭐】Loop 中如何实现「上下文窗口溢出」的应对策略？

  • 考察点：对上下文管理的理解
  • 得分项：能提出多种应对策略、能理解每种策略的适用场景
  • 回答：策略包括：①摘要压缩——每 N 轮对历史对话做摘要，替换原始内容；②滑动窗口——只保留最近 K 轮完整上下文；③RAG 检索——把历史存入向量库，按需检索相关部分；④状态摘要——维护一个精简的「当前状态」摘要，而非保留全部历史；⑤分层记忆——短期记忆（最近几轮完整）+ 长期记忆（关键事件摘要）。

56. 【⭐⭐】Loop 中如何选择合适的模型？不同环节用不同模型可行吗？

  • 考察点：对模型选型和路由的理解
  • 得分项：能提出多模型策略、能理解不同任务的模型需求差异
  • 回答：完全可行，而且往往是更优解。不同环节对模型能力的要求不同：①规划器——需要强推理能力，用高端模型（如 GPT-4/Claude Opus）；②执行器——需要代码生成能力，用中端模型（如 GPT-4o/Claude Sonnet）；③评估者——需要判断能力，可以用不同模型甚至更便宜的模型；④简单任务——用轻量模型降低成本。这种「模型路由」策略可以在保证质量的同时控制成本。

57. 【⭐⭐】Loop 的「记忆层」和 RAG 有什么区别？

  • 考察点：对记忆机制与检索增强生成的理解
  • 得分项：能区分记忆层和 RAG 的定位、能说明它们如何配合
  • 回答：RAG 是从外部知识库检索相关信息，解决「模型不知道」的问题。记忆层是记录 Loop 运行过程中的状态和进度，解决「模型忘记了」的问题。区别在于：RAG 是「查资料」，记忆层是「记笔记」。两者可以配合——记忆层记录状态，RAG 在需要时检索相关知识来补充上下文。

58. 【⭐⭐】如何设计 Loop 的「错误恢复」机制？

  • 考察点：对容错设计的理解
  • 得分项：能提出分层错误恢复策略、能理解不同错误类型的不同处理方式
  • 回答：错误恢复应分层设计：①可重试错误（如网络超时）——自动重试，带指数退避；②可修正错误（如参数错误）——让 Agent 反思并修正；③不可恢复错误（如权限不足）——终止并通知人工；④部分失败——跳过失败子任务，继续执行其他任务。每层都需要明确的「错误类型识别」和「恢复策略映射」。

59. 【⭐⭐】Loop 中的「子 Agent」之间如何通信？

  • 考察点：对多 Agent 通信机制的理解
  • 得分项：能说明通信方式、能理解同步/异步的权衡
  • 回答：通信方式包括：①共享存储——通过共享文件或数据库交换信息；②消息队列——通过队列异步传递消息；③直接 API 调用——Agent 之间通过 HTTP/gRPC 同步调用；④A2A 协议——Agent-to-Agent 标准协议。设计时需要考量：同步 vs 异步、消息可靠性、状态一致性、循环依赖检测。

60. 【⭐⭐】如何检测 Loop 中的「循环依赖」？

  • 考察点：对循环检测算法的理解
  • 得分项：能提出检测方法、能理解不同方法的适用场景
  • 回答：检测方法包括：①调用图检测——构建 Agent/任务调用图，检测是否有环；②状态指纹——比较不同轮次的状态哈希，如果相同则说明在循环；③行为模式检测——检测重复的 Action 序列；④超时检测——如果 Loop 运行时间远超预期，可能陷入了循环。一旦检测到循环依赖，应触发熔断并通知人工。

61. 【⭐⭐】Loop 的「启动成本」和「运行成本」如何权衡？

  • 考察点：对成本效益分析的理解
  • 得分项：能分析两种成本、能给出决策框架
  • 回答：Loop 的搭建成本靠多次运行摊回来——一次性的任务，一个好的 Prompt 更快更省。决策框架：①一次性任务——不值得搭 Loop，写好 Prompt 即可；②低频重复任务（每周几次）——可以搭简单 Loop；③高频重复任务（每天多次）——值得投入搭建完整 Loop；④持续运行任务（24/7）——必须搭 Loop，成本摊薄最明显。

62. 【⭐⭐】Loop Engineering 中如何处理「幻觉」问题？

  • 考察点：对 LLM 幻觉问题的理解及其在 Loop 中的应对
  • 得分项：能提出多种防幻觉策略、能理解 Loop 中幻觉的特殊风险
  • 回答：Loop 中幻觉的风险更高——一个坏 Prompt 最多得到一段不靠谱的回答，一个坏 Loop 可能让 Agent 一直在错误方向上努力。应对策略：①验证节点——每个关键输出都经过验证（测试、lint、评估 Agent）；②事实核查——关键事实通过 RAG 或工具调用验证；③置信度标注——让模型标注输出的置信度，低置信度时触发人工；④多模型交叉验证——用不同模型对同一问题给出答案，比对一致性。

63. 【⭐⭐】Loop 中的「测试驱动」模式是什么？

  • 考察点：对 TDD 在 Loop 中应用的理解
  • 得分项：能解释 TDD 模式在 Loop 中的运作方式、能举例说明
  • 回答：测试驱动模式是 Loop Engineering 的经典应用场景：系统丢给大模型改代码 → 改完后自动运行单元测试 → 如果测试没过，把 Error 堆栈抓出来让大模型继续改 → 循环直到测试全部变绿，提交 PR。这个模式的关键是「有自动化的验证手段」——测试、类型检查、linter、构建脚本，随便哪个都行，但必须存在。

64. 【⭐⭐】Loop Engineering 中「跨会话记忆」如何实现？

  • 考察点：对持久化记忆机制的理解
  • 得分项：能说明跨会话记忆的实现方式、能理解其价值
  • 回答：跨会话记忆通过持久化存储实现——把 Loop 的状态、进度、经验写入持久存储（文件、数据库、Linear Board 等）。Codex CLI 的 /goal 功能支持「跨会话保留状态」——设定一个持久目标后，即使关闭会话再打开，Loop 也能从上次中断的地方继续。跨会话记忆让 Loop 从「一次性运行」变成了「长期运行」。

65. 【⭐⭐】Loop 的「Skill」如何版本化管理？

  • 考察点：对 Skill 生命周期管理的理解
  • 得分项：能提出版本管理方案、能理解 Skill 演进的需求
  • 回答：Skill 是项目知识的沉淀，需要像代码一样版本化管理。方案包括：①Git 管理——Skill 文件放在代码仓库中，随项目一起版本控制；②变更记录——每次 Skill 修改记录原因和影响；③兼容性——新旧版本 Skill 的兼容性管理；④A/B 测试——不同分支用不同 Skill 版本，对比效果。Skill 会随着项目演进而变化——新踩的坑、新加的规范都需要更新 Skill。

模块六：性能与优化（66-75题） ​

66. 【⭐⭐】Loop 的延迟怎么优化？

  • 考察点：对性能优化的理解
  • 得分项：能提出多维度优化策略、能理解不同策略的 trade-off
  • 回答：优化策略包括：①减少轮数——用规划器一次性生成完整计划，减少每轮决策；②并行执行——无依赖的任务并行处理；③模型降级——简单任务用轻量模型；④Prompt 缓存——缓存系统提示词，减少重复传输；⑤流式输出——边生成边处理，减少等待时间；⑥本地化——尽可能用本地模型或边缘计算。

67. 【⭐⭐】Loop 的成本怎么控制？

  • 考察点：对成本优化的理解
  • 得分项：能提出多种成本控制策略、能理解成本与质量的权衡
  • 回答：成本控制策略：①模型路由——简单任务用便宜模型，复杂任务用高端模型；②Token 优化——精简 Prompt、压缩历史、使用摘要；③缓存策略——缓存常见查询结果；④步数限制——设置最大迭代次数；⑤早期终止——检测到不可能成功时提前终止；⑥成本预警——达到阈值时告警或降级。

68. 【⭐⭐】如何评估 Loop 的「投入产出比」？

  • 考察点：对 ROI 分析的理解
  • 得分项：能提出 ROI 评估框架、能理解不同场景下的差异
  • 回答：ROI 评估框架：①投入——搭建时间 + 运行成本（Token + API）+ 维护成本；②产出——节省的人力时间 × 人力成本 + 质量提升价值；③频次——任务执行频率越高，ROI 越高；④复杂度——任务越复杂、越容易出错，Loop 的边际价值越高。一次性的任务 ROI 为负，高频复杂任务 ROI 最高。

69. 【⭐⭐】Loop 中如何处理「长尾延迟」问题？

  • 考察点：对延迟分布和异常处理的理解
  • 得分项：能识别长尾延迟的原因、能提出优化策略
  • 回答：长尾延迟通常由以下原因造成：①LLM 推理时间波动——高峰期模型响应变慢；②工具调用超时——外部 API 响应慢；③上下文过长——每轮携带的历史越来越多；④循环次数过多——任务复杂导致轮数增多。优化策略：①设置单轮超时；②使用更快的模型处理简单轮次；③限制最大轮数；④异步处理非关键步骤。

70. 【⭐⭐】Loop 的「Token 消耗」如何优化？

  • 考察点：对 Token 优化的理解
  • 得分项：能提出多种 Token 优化策略
  • 回答：优化策略包括：①历史压缩——用摘要替代完整历史；②选择性上下文——只保留相关的历史片段；③结构化输出——用 JSON Schema 约束输出格式，减少冗余；④Prompt 缓存——缓存不变的系统提示词；⑤模型选择——在保证质量的前提下用 Token 效率更高的模型；⑥减少轮数——通过更好的规划减少迭代次数。

71. 【⭐⭐】如何设计 Loop 的「降级策略」？

  • 考察点：对优雅降级的理解
  • 得分项：能提出多级降级方案、能理解降级的触发条件
  • 回答：降级策略包括：①模型降级——高端模型不可用或用尽预算时，切换到中端模型；②功能降级——关闭非核心功能（如子 Agent 检查），只保证核心流程；③频率降级——从实时降到定时批处理；④人工接管——系统无法继续时，保存状态并通知人工。触发条件：成本超限、延迟超时、错误率过高。

72. 【⭐⭐】Loop 的「启动预热」有必要吗？

  • 考察点：对 Loop 启动优化的理解
  • 得分项：能判断预热的价值、能提出预热策略
  • 回答：有必要，尤其是对于：①Skill 加载——项目 Skill 可能需要从存储加载并预处理；②上下文构建——RAG 索引可能需要预热；③连接池——工具连接的连接池需要初始化；④模型缓存——系统提示词可以预计算并缓存。预热可以减少首次请求的延迟，让 Loop 从第一轮就开始高效运行。

模块七：生产环境挑战（76-80题） ​

76. 【⭐⭐】Loop 在生产环境中面临哪些独特的失败模式？

  • 考察点：对生产环境挑战的理解
  • 得分项：能识别 Loop 特有的失败模式、能理解与传统系统的差异
  • 回答：当 Agent 开始在生产环境自主运行，出现了传统系统没有的失败模式：①无限循环——Agent 反复执行相同操作直到烧光 Token；②误触生产数据库——Agent 调用了不应该调用的工具；③工具调用空转——调用 12 次工具却一无所获；④级联错误——一个 Agent 的错误被其他 Agent 放大；⑤状态漂移——长时间运行后状态与预期越来越远。

77. 【⭐⭐】Loop 上线前需要做哪些测试？

  • 考察点：对 Loop 测试策略的理解
  • 得分项：能提出全面的测试方案、能理解不同测试层次
  • 回答：测试应包括：①单元测试——每个组件（触发器、Skill 加载、连接器等）独立测试；②集成测试——组件间协作测试；③端到端测试——完整 Loop 在沙箱环境运行；④混沌测试——模拟各种故障（网络超时、API 报错、模型降级）；⑤压力测试——多 Loop 并行、长时运行；⑥回放测试——用历史真实任务验证。

78. 【⭐⭐】如何设计 Loop 的「人工介入」流程？

  • 考察点：对 Human-in-the-loop 设计的理解
  • 得分项：能设计合理的人工介入节点、能理解介入的触发条件
  • 回答：人工介入流程设计：①触发条件——达到最大迭代次数、检测到死循环、遇到不可恢复错误、高风险操作前、置信度低于阈值；②介入方式——通过 Slack/邮件通知、Web 控制台审批；③恢复机制——人工介入后 Loop 能从断点继续；④反馈闭环——人工判断结果反馈给系统，优化后续决策。

79. 【⭐⭐】Loop 的「可治理性」如何实现？

  • 考察点：对 Agent 治理的理解
  • 得分项：能提出治理框架、能理解治理的多个维度
  • 回答：可治理性需要多个维度：①权限治理——每个 Agent 能做什么不能做什么；②成本治理——预算上限、成本预警；③质量治理——输出质量标准、评估机制；④风险治理——危险操作拦截、操作审计；⑤知识治理——Skill 的版本管理和更新；⑥合规治理——符合组织规范和数据安全要求。

80. 【⭐⭐】Loop 的「长期运行」会带来哪些新问题？

  • 考察点：对长期运行系统挑战的理解
  • 得分项：能识别长期运行的特殊问题、能提出应对策略
  • 回答：长期运行带来：①状态膨胀——上下文和记忆不断增长；②模型漂移——LLM 的行为可能随时间变化；③外部依赖变化——工具 API 变更、数据源变化；④累积误差——小错误在循环中被放大；⑤疲劳退化——Agent 在长任务中可能「迷失」目标。应对策略：定期重置/压缩状态、健康检查、外部依赖版本锁定、人工定期审查。

第三部分：实战篇（81-100题） ​

模块八：经典场景与案例（81-90题） ​

81. 【⭐⭐】设计一个「代码修复 Loop」——当 CI 失败时，Agent 自动修复并重新提交

  • 考察点：对 Loop 实战设计能力
  • 得分项：能设计完整流程、能考虑异常处理和终止条件
  • 回答：流程设计：①触发器——CI 失败事件触发（GitHub hook）；②上下文构建——加载项目 Skill（技术栈、规范）、获取失败日志和报错堆栈；③执行——Agent 分析报错、生成修复方案、提交修复；④验证——重新运行 CI；⑤循环——如果 CI 仍失败，把新的报错反馈给 Agent；⑥终止条件——CI 通过、达到最大尝试次数（如 5 次）、人工介入；⑦输出——通过则自动提交 PR，失败则通知人工。

82. 【⭐⭐】设计一个「代码审查 Loop」——Agent 自动审查 PR 并给出修改建议

  • 考察点：对 Loop 在代码审查场景的应用能力
  • 得分项：能设计审查流程、能考虑质量和效率的平衡
  • 回答：流程设计：①触发器——新 PR 创建或更新；②上下文——PR diff、项目规范（Skill）、相关历史 PR；③执行——审查 Agent 分析代码变更、检查规范遵守情况、发现潜在问题；④输出——生成审查意见列表；⑤验证——用评估 Agent 检查审查质量；⑥循环——如果 PR 更新，重新审查；⑦终止——PR 合并或关闭。

83. 【⭐⭐】设计一个「数据分析 Loop」——Agent 自动完成数据提取、分析和可视化

  • 考察点：对 Loop 在数据分析场景的应用能力
  • 得分项：能设计完整的数据分析流程、能考虑代码执行安全
  • 回答：流程设计：①输入——用户提出分析需求（如「分析上月销售数据」）；②规划——Agent 将任务拆解：数据读取 → 异常清洗 → 统计分析 → 可视化 → 结论产出；③执行——Agent 写 Python 代码；④验证——代码在沙箱中执行；⑤反馈——如果执行失败，报错信息反馈给 Agent 修正；⑥循环——直到代码执行成功或达到最大尝试次数；⑦输出——生成图表和分析报告。关键设计：代码执行沙箱、结构化输出。

84. 【⭐⭐】设计一个「文档同步 Loop」——当代码变更时，自动更新相关文档

  • 考察点：对 Loop 在文档维护场景的应用能力
  • 得分项：能设计文档同步流程、能考虑变更检测和文档定位
  • 回答：流程设计：①触发器——代码 PR 合并事件；②变更检测——识别哪些文件变更了、影响了哪些模块；③文档定位——找到受影响的文档（通过 RAG 检索或元数据映射）；④执行——Agent 根据代码变更更新文档内容；⑤验证——检查文档格式、链接有效性、与代码一致性；⑥输出——提交文档更新 PR；⑦人工审核——文档更新需要人工确认。

85. 【⭐⭐】设计一个「安全扫描 Loop」——定期扫描代码仓库的安全漏洞

  • 考察点：对 Loop 在安全场景的应用能力
  • 得分项：能设计安全扫描流程、能考虑扫描效率和准确性
  • 回答：流程设计：①触发器——定时触发（如每日）或 PR 触发；②上下文——项目 Skill（已知的安全策略）、历史扫描记录；③执行——Agent 扫描代码（依赖检查、硬编码密钥检测、SQL 注入风险等）；④验证——用评估 Agent 确认发现的问题是否真实；⑤输出——生成安全报告，高风险问题自动创建 Issue；⑥循环——如果代码有变更，重新扫描。

86. 【⭐⭐】设计一个「性能基准测试 Loop」——自动跑 Benchmark 并追踪性能变化

  • 考察点：对 Loop 在性能测试场景的应用能力
  • 得分项：能设计基准测试流程、能考虑性能数据的分析和可视化
  • 回答：流程设计：①触发器——代码合并后或定时触发；②执行——Agent 自动部署、运行 Benchmark；③数据收集——收集性能指标（响应时间、吞吐量、资源消耗）；④分析——与历史基准对比，检测性能退化；⑤输出——生成性能报告，如果性能下降超过阈值则告警；⑥循环——持续追踪，形成性能趋势图。

87. 【⭐⭐】设计一个「知识库更新 Loop」——从对话和文档中提取知识并更新知识库

  • 考察点：对 Loop 在知识管理场景的应用能力
  • 得分项：能设计知识提取和更新流程、能考虑知识质量
  • 回答：流程设计：①触发器——新对话结束、新文档创建；②提取——Agent 从对话/文档中提取关键知识（FAQ、最佳实践、踩坑记录）；③验证——评估 Agent 检查提取的知识是否准确、是否与现有知识冲突；④去重——检查知识库中是否已有类似内容；⑤更新——将新知识写入记忆层/知识库；⑥输出——记录更新日志。

88. 【⭐⭐】设计一个「多项目并行 Loop」——同时管理多个项目的自动化任务

  • 考察点：对 Loop 规模化运行的设计能力
  • 得分项：能设计多项目管理方案、能考虑资源隔离和优先级
  • 回答：设计要点：①资源隔离——每个项目独立 Worktree、独立 Skill、独立记忆；②优先级管理——不同项目不同优先级，高优先级项目优先分配资源；③统一调度——中央调度器分配任务给各项目 Loop；④统一监控——所有项目的状态、成本、成功率统一 Dashboard；⑤共享基础设施——共享 MCP 连接器、共享模型池。

89. 【⭐⭐】设计一个「测试用例生成 Loop」——根据代码变更自动生成和更新测试用例

  • 考察点：对 Loop 在测试场景的应用能力
  • 得分项：能设计测试生成流程、能考虑测试质量和覆盖率
  • 回答：流程设计：①触发器——代码 PR 创建或更新；②分析——Agent 分析代码变更，识别需要测试的功能点；③生成——Agent 生成对应的测试用例；④执行——自动运行生成的测试；⑤反馈——如果测试失败，分析失败原因（是代码问题还是测试问题）；⑥循环——修正后重新运行；⑦输出——测试通过后提交测试代码。

90. 【⭐⭐】设计一个「依赖更新 Loop」——自动检测并更新项目依赖

  • 考察点：对 Loop 在依赖管理场景的应用能力
  • 得分项：能设计依赖更新流程、能考虑兼容性和安全性
  • 回答：流程设计：①触发器——定时触发（如每周）或安全漏洞告警；②检测——Agent 扫描依赖，发现有新版本或有漏洞的依赖；③评估——分析新版本的变更、兼容性风险；④测试——在隔离环境更新依赖并运行测试；⑤决策——测试通过则创建 PR，失败则记录并通知；⑥循环——如果 PR 被拒或测试失败，分析原因并调整。

模块九：思路题与开放题（91-100题） ​

91. 【⭐⭐⭐】如果让你从零设计一个 Loop Engineering 系统，你的技术选型和架构是什么？

  • 考察点：综合系统设计能力
  • 得分项：能给出完整的架构设计、能说明技术选型理由、能考虑生产环境挑战
  • 回答：架构设计：三层架构：①Prompt 层——用结构化 Prompt 模板，支持 Few-shot 和 Chain of Thought；②Context 层——用向量数据库（如 Milvus）做 RAG，用 Redis 做短期记忆缓存；③Harness 层——用 Pytest 做测试验证，用独立评估模型做质量把关。核心组件：触发器（cron + webhook）、Worktree 隔离、Skill 管理（Git 版本化）、MCP 连接器、子 Agent 编排、记忆层（PostgreSQL + 向量库）。模型策略：规划用 Claude Opus，执行用 GPT-4o，评估用 Llama 3。可观测性：结构化日志接入 ELK，指标接入 Prometheus/Grafana。

92. 【⭐⭐⭐】Loop Engineering 的未来发展趋势是什么？

  • 考察点：对行业趋势的洞察力
  • 得分项：能提出有深度的趋势判断、能理解技术演进的内在逻辑
  • 回答：趋势判断：①从「写 Loop」到「设计 Loop 模板」 ——Loop 本身会成为可复用的模板和模式库；②Loop 的可观测性标准化——会出现成熟的 Loop Observability 方案；③多模型、多 Agent 的深度协作——不同模型负责不同环节成为标配；④Loop 与组织流程的深度整合——Loop 不再只是技术工具，而是组织交付流程的一部分；⑤从「通用 Loop」到「领域专用 Loop」 ——针对特定场景（代码修复、数据分析、安全扫描）的专用 Loop 模板。

93. 【⭐⭐⭐】Loop Engineering 可能带来哪些「副作用」？如何应对？

  • 考察点：对技术风险的批判性思考
  • 得分项：能识别潜在风险、能提出应对措施
  • 回答：副作用包括：①思维退化——开发者变成只会点「开始键」的人，失去主动思考能力；②质量幻觉——Loop 跑得勤不代表产出质量高，可能在错误方向上持续努力；③技术债务堆积——AI 生成的代码多了，Review 压力反而更重；④责任模糊——Loop 出了错，谁背锅？；⑤过度自动化——本应人工判断的决策被自动化了。应对措施：保持人工审查节点、建立质量门槛、明确责任边界、定期人工复盘。

94. 【⭐⭐⭐】Loop Engineering 和「Vibe Coding」是什么关系？

  • 考察点：对 AI 编程范式演进的理解
  • 得分项：能区分两个概念、能说明演进关系
  • 回答：Vibe Coding（氛围编程）是 2025 年的概念——大家比拼谁 Prompt 写得溜。Loop Engineering 是 2026 年的演进——大家比拼谁的系统跑得稳。关系是：Vibe Coding 关注「单次对话的质量」，Loop Engineering 关注「持续运行的系统稳定性」。从 Vibe Coding 到 Loop Engineering，是从「让 AI 生成代码」到「让 AI 系统持续产出可靠结果」的范式跃迁。

95. 【⭐⭐⭐】Loop 适合所有任务吗？哪些任务不适合用 Loop？

  • 考察点：对 Loop 适用边界的理解
  • 得分项：能识别不适合的场景、能理解 Loop 的局限性
  • 回答：不适合的场景：①一次性任务——搭建 Loop 的成本远高于直接写 Prompt；②创意性任务——需要人类直觉和审美的任务（如 UI 设计、文案创作）；③高不确定性任务——目标模糊、无法定义「完成」的任务；④极低容错任务——医疗诊断、金融交易等不容许试错的场景；⑤强依赖人工判断的任务——需要人类价值观判断的场景。Loop 最适合：高频、可验证、有明确完成标准的任务。

96. 【⭐⭐⭐】如何判断一个 Loop 是「好 Loop」还是「坏 Loop」？

  • 考察点：对 Loop 质量判断标准的能力
  • 得分项：能提出多维度的判断标准、能理解好 Loop 和坏 Loop 的本质差异
  • 回答：好 Loop vs 坏 Loop：好 Loop——有明确的终止条件、有自动验证机制、有状态管理、有错误恢复、有可观测性、成本可控。坏 Loop——没有终止条件（可能无限循环）、没有验证（不知道什么时候算「完成」）、没有状态（每轮从零开始）、没有错误处理（一错就崩）、没有监控（出了问题不知道）、成本不可控。一句话：好 Loop 是「可终止、可验证、可观测、可恢复」的系统。

97. 【⭐⭐⭐】Loop Engineering 对工程师的能力要求有什么变化？

  • 考察点：对工程师角色演变的洞察
  • 得分项：能识别能力要求的转变、能理解新能力的内涵
  • 回答：能力要求从「写 Prompt」转向「设计系统」：①系统思维——从关注单次对话到关注整个循环的稳定性；②状态管理——理解如何在非确定性系统中管理状态；③异常设计——设计各种失败场景的恢复策略；④可观测性设计——让非确定性系统可被监控和调试；⑤成本意识——理解 Token 消耗和预算控制；⑥治理能力——设计权限、审计、合规机制。本质变化：从「AI 的使用者」变成了「AI 系统的架构师」。

98. 【⭐⭐⭐】Loop Engineering 是否会取代 Prompt Engineering？

  • 考察点：对技术演进关系的理解
  • 得分项：能辩证分析两者关系、能理解技术栈的分层沉淀
  • 回答：不会取代，而是叠加。Prompt Engineering 没死，它是地基——一个 Loop 本来就是由一堆 Prompt 组成的。Prompt 写得烂，扔进 Loop 里只会让烂活儿产出得更快。AI 工程的规律是分层沉淀：新范式不意味着旧范式消亡，而是整个技术栈的丰富和深化。工程师需要同时掌握 Prompt Engineering（单次交互质量）和 Loop Engineering（系统持续运行）。

99. 【⭐⭐⭐】Loop Engineering 和「Agentic Engineering」是什么关系？

  • 考察点：对 AI 工程最新概念的辨析
  • 得分项：能区分两个概念、能理解它们关注的侧重点
  • 回答：Agentic Engineering（智能体工程）关注的是让 AI Agent 自主行动的系统工程能力——包括工具调用、规划、记忆、异常处理等。Loop Engineering 是 Agentic Engineering 的一个核心子集——聚焦于「循环执行」这个维度。Agentic Engineering 的范围更广，还包括 Agent 的注册发现、任务分发、A2A 协议、状态共享等。Loop Engineering 回答的是「如何让 Agent 持续运行不出错」，Agentic Engineering 回答的是「如何构建一个完整的 Agent 系统」。

100. 【⭐⭐⭐】如果 Loop 在凌晨 3 点跑了 47 轮输出了一堆问题代码，你怎么 Debug？

  • 考察点：对生产环境故障排查的综合能力
  • 得分项：能提出系统的 Debug 方法论、能理解 Loop Debug 的特殊性
  • 回答：这是 Loop 可观测性的经典难题。Debug 步骤：①状态重建——从持久化存储中恢复第 47 轮的完整状态快照；②逐轮回放——从第 1 轮开始逐轮回放，找到问题引入的轮次；③差异分析——对比第 N 轮和第 N-1 轮的状态差异，找出变化点；④输入重放——用相同的输入重新跑有问题的轮次，确认是否可复现；⑤日志分析——查看结构化日志，分析每轮的 Thought/Action/Observation；⑥人工介入——如果无法定位，保存完整状态并通知人工。根本解决之道是预防——更好的可观测性设计、更完善的异常检测、更早的熔断机制。