大家好，我是浩哥，本专栏第一篇，后续总结10篇关于ai agent面试题，感兴趣可以点点关注。

导语：本题型是 P7 / Agent 架构师面试的第一道分水岭。面试官真正考察的不是"背定义"，而是你对 Agent 的系统边界、能力来源与工程取舍是否想得清。常见失分点集中在三处：①把 Agent 等同于「大模型 + 一个 Prompt」，说不清它相对纯 LLM 到底多了什么；②分不清 Tools / Workflow / Agent 三者的粒度关系，把它们当成"三选一"而非"可嵌套的三层结构"；③只背过 ReAct，一旦被追问 Plan-and-Execute、Reflection、CoT/ToT/GoT 的区别与选型依据就卡壳。下面的整理按面试题源顺序、合并重复变体后形成 7 道题，每道题都给出"架构级答案 + 展开要点 + 常见追问 + 延伸"。

Q1. Agent 的基本架构由哪些核心组件构成？［来源：小红书］

• 核心答案：
  一个完整的 Agent 是一套以 LLM 为决策中枢、能自主逼近目标的闭环系统，而不是"调一次大模型"。它的基本架构由四个不可替代的核心组件构成：LLM、工具（Tools）、记忆（Memory）、规划（Planning）。

  • LLM 是大脑/决策中枢：所有用户输入、工具返回结果、记忆召回内容，最终都汇聚到 LLM 做理解与决策——下一步该思考、调哪个工具、还是已可收尾，全部由它拍板。没有 LLM，其余三个组件只是一堆零件。
  • 工具是 Agent 与外部世界交互的唯一入口：LLM 本身是"纯语言处理器"，不能联网、读文件、执行代码，这些限制都靠工具（搜索、代码执行器、数据库、API）突破。
  • 记忆让 Agent 在任务过程中保持状态、不"失忆"：区分短期（当前轮上下文，任务结束即清空）与长期（向量库语义检索，跨任务保留）。
  • 规划把复杂目标拆成可执行步骤：决定 Agent 能否应对复杂任务。

  可以类比一家公司：LLM 是老板（拍板），工具是外包执行团队（干活），记忆是公司档案室（存/调档），规划是项目经理（拆任务单）。四角色各司其职，才撑起 Agent 的自主运行。

• 关键点 / 展开：

  1. 工具的标准定义（function calling 范式）：只告诉模型三件事——name、description、parameters，没有一行执行逻辑。模型读"说明书"后决定调哪个、参数填什么，把决策以 JSON 返回，由你的代码真正执行，结果再回填。核心原则：模型负责"决定做什么"，程序负责"真正执行"（决策—执行分离）。
  2. 记忆的双层结构：

     层级	载体	类比	特点
     短期记忆	Context Window	工作记忆	容量有限、任务结束清空、承载中间状态
     长期记忆	向量数据库	长期记忆	容量大、跨天保留、需主动语义检索召回

  3. 规划的两种形态：要么让 LLM 先输出完整计划再逐步执行，要么边执行边规划、根据每步结果动态调整。
  4. 核心运行 Loop（架构级数据流）：规划(plan) → LLM 决策(decide：结合 step + 短期 memory + 长期 vector_db 召回) → 工具执行(tools.execute) → 结果存入短期记忆 → 再决策，循环至 final_answer。LLM 始终做决策，工具是执行者，记忆防失忆，规划拆目标。
  5. 框架定位：LangChain、LlamaIndex、AutoGen 等主流框架本质都围绕这四组件封装，只是侧重点与封装粒度不同。

• 常见追问：

  1. 工具层现在有了 MCP（Model Context Protocol）这类标准化协议，它对"工具系统"这一组件带来了什么改变？（指向工具定义的统一化、可插拔）
  2. 多 Agent 协作时，记忆系统应如何设计——是共享一个全局记忆，还是每个 Agent 私有、按需共享？

• 2026 延伸：Anthropic《Building Effective Agents》强调 Agent 不必"全闭环"，大多数生产场景应从确定性 Workflow 起步，仅在必要节点引入 LLM 决策；Google ADK、OpenAI Agents SDK 也都将"LLM + Tools + 记忆/会话状态"作为 Agent 的一等公民抽象。

Q2. 既然大模型已经这么强了，为什么还要做 Agent？它与大模型本质区别是什么？［来源：美团］

• 核心答案：
  普通大模型的本质是**“问答机器”：基于 next-token 预测，你给输入、它给输出，被动、无状态、每次独立，不知道自己上一步做了什么、下一步该做什么——它"只会答题，不会办事"。
  Agent 的本质区别在于"自主性"与"能行动"：它有一个核心运作闭环 感知 → 规划 → 行动 → 再感知，你给它一个复杂目标，它会自己拆解、调工具、访问记忆、感知环境，一步步执行直到完成。一句话概括本质区别：从"生成文字"到"执行任务"。
  这种能力由三件事支撑：①工具调用**（把"说话"变成"做事"，决策—执行分离）；②记忆机制（短期保持当前任务连贯、长期跨任务保留偏好与历史）；③多步推理与自我纠错（某步失败能感知、分析原因、换方式重试，而不是直接崩）。

• 关键点 / 展开：

  1. 普通 LLM 的硬局限：你让它"帮我发一封天气播报邮件"，它只能告诉你"你可以这样写代码……"；它不会主动查 API、组织内容、调发信接口。哪怕多轮对话，也只是在当前上下文里被动响应。
  2. Agent 三支撑之工具调用：配好 get_weather、send_email 两个工具后，Agent 会分两步真实执行（查天气→发邮件），而非"假装"。关键认知：模型只说"调哪个、传什么参"，真正执行的是你的代码。
  3. Agent 三支撑之记忆：传统 LLM 每次对话"失忆"，除非手动传上下文；Agent 显式设计短期（中间状态）+长期（用户偏好、历史操作），保证复杂任务中连贯不跑偏。
  4. Agent 三支撑之多步推理与自纠：执行中失败能感知并换路重试，像一个真正在"思考"的执行者，而非只背答案的系统。
  5. 场景对照：同一句"发天气邮件"，LLM 给教程，Agent 自动完成全流程——这就是价值落点。

• 常见追问：

  1. 那是不是"上下文超长的大模型 + 工具"就等同于 Agent？还差哪一层？（指向规划的显式化与自主闭环）
  2. 当 Agent 自主决策失败时，如何做可观测与兜底（human-in-the-loop / 回滚）？

• 2026 延伸：即便模型上下文与工具调用能力持续增强，"编排（orchestration）“与"目标驱动的自主闭环"仍是 Agent 不可替代的价值；Anthropic《Building Effective Agents》提出"workflow 与 agent"两类模式，主张先问"是否真的需要 agent 的自主性”，也正是本题的工程化延伸。

Q3. Tools、Workflow、Agent 三者区别是什么？Agent 和 Workflow 的本质区别是什么？［来源：阿里、腾讯］

• 核心答案：
  三者根本不是同一维度、也不是三选一的关系，而是粒度从小到大、可相互嵌套的三层结构：你在真实项目里通常三者同时存在，只是扮演角色不同。

  • Tools（最小能力单元）：封装好的可调用函数（搜索、执行代码、发邮件），只有"说明书"（名字/描述/参数），只负责执行，没有任何决策能力，甚至不知道自己"应该何时被用"。
  • Agent（完整决策系统）：以 LLM 为大脑，自己判断"什么时候调哪个 Tool、要不要继续、何时结束"，是主动的。
  • Workflow（上层编排框架）：把 Agent、LLM、Tools 组织成一条确定性流程，每个节点做什么、按什么顺序流转，都是开发者事先写死的。

  核心区别一句话：Tools 不做决策只执行，Agent 自己做决策，Workflow 是开发者替所有节点把决策提前写好。而 Agent 与 Workflow 最尖锐的区别是**“谁来决定下一步”**：Workflow 由开发者（代码）硬编码、完全可预测；Agent 把"下一步做什么"交给 LLM 在运行时动态决策、灵活但不可控。

• 关键点 / 展开：

  1. 三层粒度与决策权对照：

     维度	Tools	Agent	Workflow
     粒度	最小能力积木	完整决策系统	上层编排
     决策权	无（被动等待调用）	LLM 动态决策	开发者硬编码
     角色	瑞士军刀的刀片	拿刀的手	把工具按流程组装的人
     确定性	—	低（同输入可能走不同路径）	高（行为完全可预测）

  2. 代码结构对比（直观）：Workflow 每一行都是明确指令（search → rerank → generate），LLM 只是某节点的工具；Agent 的循环里只有 llm.decide()，所有路径运行时动态选。即**“开发者在驾驶” vs “LLM 在驾驶、开发者在副驾设安全限制”**。
  3. Workflow 的利弊：行为可预测、易测试、好排查；但灵活性低，遇到未预料情况易走入死胡同。
  4. Agent 的利弊：能处理未设计的情况；但行为不确定、难复现、线上出了问题难定位。
  5. 生产主流做法——Agentic Workflow：整体用 Workflow 框住主流程（可控），在需要灵活判断的节点嵌入 Agent 能力（局部灵活）。例如客服系统：意图识别→知识检索→回答生成 是固定 Workflow，但"知识检索"节点内部用 Agent 动态决定检索几轮、用哪些工具。既保整体可控，又有局部灵活性。

• 常见追问：

  1. 什么情况下才值得用纯 Agent（而非 Agentic Workflow）？有没有纯 Agent 更合适的真实场景？
  2. 在 Agentic Workflow 里，如何让嵌入的 Agent 节点"可控"（约束工具集、限制步数、输出 schema 校验）？

• 2026 延伸：Anthropic《Building Effective Agents》明确把 Workflow（确定性编排）与 Agent（LLM 驱动决策） 列为两类核心模式，并建议默认从 Workflow 起步、仅在收益明显处引入 Agent；Google ADK、LangGraph 的"图/状态机 + 条件分支"正是对 Agentic Workflow 的工程落地。

Q4. Agent 的推理/设计范式有哪些？ReAct、Plan-and-Execute、Reflection 核心区别？怎么选型？［来源：字节、快手］

• 核心答案：
  先厘清两个易混概念："设计范式"是顶层做事流程框架（公司管理制度），"推理模式"是每步干活时的底层思考逻辑（员工干活方法），两者一一对应。

  • 推理模式演进：直接给答案（无中间推理）→ CoT（先把推理链写出来再答）→ ReAct（在 CoT 的推理链里插入真实"行动"，让 LLM 交替思考与调工具）。
  • 设计范式三大主流：ReAct（边想边干，单步迭代实时调整）、Plan-and-Execute（先定完整计划再分步执行）、Reflection（不是独立流程，而是给前两者叠加的"质检 buff"）。

  选型三维度看任务复杂度 / 流程确定性 / 输出质量要求：新手入门与简单中等任务首选 ReAct；长流程、高复杂度、怕跑偏用 Plan-and-Execute；对严谨性要求极高（代码、报告、法律文书）再叠加 Reflection。切忌三者一股脑全堆上，否则系统又慢又贵又易出诡异 bug。

• 关键点 / 展开：

  1. ReAct（Reasoning + Acting）：核心循环 Thought → Action → Observation → 再 Thought，走一步看一步，无提前完整计划。
     • 优势：实现最简、灵活度最高、逻辑透明易排查，能应对流程不固定的突发场景；新手零门槛。
     • 短板：长流程多步骤易"走着走着跑偏"、忘目标、陷入无效循环、浪费 token。
     • 实现：靠 Prompt 约束输出结构（Thought/Action/Action Input/Observation/Final Answer），但循环由代码驱动——每轮调 LLM 输出 Thought+Action，代码解析 Action、执行工具、把结果填回 Observation，再调 LLM，直至 Final Answer。
  2. Plan-and-Execute（规划—执行解耦）：把 ReAct 里混在一起的"规划推理"和"执行推理"彻底拆开——专用一个 LLM 做规划（输出完整步骤清单），再用另一个 LLM/模块按清单执行。
     • 优势：解决长任务跑偏，结构清晰、链路可控、便于并行，大幅降长任务耗时。
     • 短板：灵活度低、遇计划外突发易卡壳，实现复杂度与 token 消耗更高。
  3. Reflection（反思，增强机制非独立流程）：在原本范式上叠加 生成 → 评估 → 改进 闭环，专门设检查环节判断输出是否达标，不达标则重试/调策略。核心是"把事做好"而非"把事做完"，可叠加在 ReAct（步骤级）或 Plan-and-Execute（任务级）之上。
  4. 选型决策表：

     场景	推荐范式
     流程不固定、需实时调整、简单/中复杂、新手入门	ReAct
     流程长、复杂度高、需整体结构清晰、怕跑偏	Plan-and-Execute
     输出严谨性要求极高、不能出错（代码/报告/法务）	前两者 + Reflection

  5. 关键提醒（快手踩坑点）：只死磕 Prompt、只会 ReAct 不够；要能讲透 ReAct 的 Prompt 结构、代码驱动 loop，以及它相对 CoT 多了"出去拿数据—回来继续推理"的闭环能力。

• 常见追问：

  1. ReAct 的 Prompt 里为什么必须显式写 Observation 行"由系统填入"？如果让模型自己编 Observation 会怎样？（指向幻觉与真实工具结果的绑定）
  2. 如何防止 Reflection 陷入"为了改而改"的死循环？最大轮次设几轮合理？（指向硬性 max_steps + PASS 退出机制）

• 2026 延伸：Anthropic《Building Effective Agents》主张"从最简单可行的 workflow 起步"，与本题"够用就好、别堆范式"的工程哲学一致；OpenAI Agents SDK、Google ADK 均内置 ReAct 式循环与 handoff/子 Agent 编排，可作为选型时的现成基建参考。

Q5. Agent 的反思（Reflection）机制是什么？为什么要用？具体怎么实现？［来源：小红书］

• 核心答案：
  反思机制是让 Agent 在完成一个步骤或整个任务后，自我评估输出质量、判断是否有问题，不达标则重试或调整策略。之所以要用，是因为 LLM 单次"一口气"生成往往存在四类毛病——逻辑跳跃、遗漏细节、事实错误（幻觉）、表达含糊；给它一个"回头检查"的机会，它是有能力发现并修正的，相当于人写完东西过半小时再读一遍。代价是至少多一次 LLM 调用，token 与延迟线性增加，因此工程上只应在质量要求的"刀刃"上启用，而非每步都做。

• 关键点 / 展开：

  1. 核心循环（源自 Self-Refine 论文）：生成(Generate) → 评估(Evaluate) → 改进(Improve)，用"草稿 → 批阅 → 修改"类比，外层就是一个普通 for 循环，直到 PASS 或超 max 轮。
  2. 两个 Prompt 驱动：
     • 评估 Prompt：让 LLM 扮"检查者"，按明确维度（事实/逻辑/完整性/表达）逐项审查，并设 PASS 机制作为"足够好就停"的出口（否则易为反思而反思，把好东西改错）。
     • 改进 Prompt：必须同时传入原始任务 + 当前输出 + 评估意见三要素，缺任何一样都会改得盲目；三者齐全才能针对性修改而非重写。
  3. 两个粒度：

     粒度	时机	优势	代价	适用
     步骤级	每步后立即检查	错误早发现早纠，防层层放大	每步多一次调用（10 步可能 20 次）	步骤强依赖、前错后全错
     任务级	整体完成后一次评估	开销小（仅多一次）、能看整体矛盾	中途大错到最后才发现、前功尽弃	步骤相对独立、整体质量更重要（如报告）

  4. 多 Agent 互评（他人审视 > 自我检查）：设独立 Critic Agent 审查执行 Agent 的输出。原因：自我反思时评估者与生成者是同一模型，易沿用生成时的"内部逻辑"陷入自洽、对自己错误不敏感；独立 Critic 唯一职责是"找问题"，视角更客观。流程：执行 Agent 生成 → Critic 批注 → 执行 Agent 修改 → Critic 再确认。代价是多一个 Agent 与复杂度，仅在质量要求极高（代码验证、事实核查）时值得。
  5. 工程权衡（防踩坑）：①只在关键节点（最终报告、重要决策推理）或易遗漏细节的复杂任务开反思；②简单/实时性高场景（格式转换、1 秒变 3 秒不可接受）不开；③必设最大轮次 2–3 轮，绝不依赖 LLM 自判停止，防"为改而改"死循环；④清醒认知成本：3 轮反思 ≈ 3 倍 LLM 调用，用在刀刃上。

• 常见追问：

  1. 步骤级与任务级反思如何按任务特征组合使用？有没有"关键步骤任务级 + 普通步骤跳过"的混合策略？
  2. Critic Agent 的评估标准如何避免与主 Agent “同模型偏见”？是否该用不同模型/不同温度？

• 2026 延伸：反思思想源自 Self-Refine（Madaan et al., 2023），与 ReAct（Yao et al., 2022）共同构成 Agent 质量增强的两条主线；当前生产实践更倾向于"轻量自反思 + 关键节点独立 Critic"，而非无差别全链路反思。

Q6. 复杂任务怎么做拆解？如何赋予 LLM 规划能力？［来源：蚂蚁、百度］

• 核心答案：
  为什么要拆：LLM 的 Context Window 是有限"工作台"，任务越大、中间状态越多，“桌面越乱”——搜索结果、分析意见、半成品段落堆在一起，LLM 很难持续追踪"当前子目标"，出错率显著上升；拆成小步骤后每步只做一件事、注意力集中，质量提升，且每步独立可单独验证/重试。
  两种拆分思路：①静态拆分——开发者提前硬编码成确定 Workflow（顺序固定、可预测、好排查，但僵化）；②动态拆分——把"拆解"本身交给 LLM（即 Plan-and-Execute，灵活但规划质量不稳定）。
  如何赋予规划能力（推理方法演进）：CoT（把推理链显式写出，线性一步步行进）→ ToT（同时探索多条路径、评估剪枝，解决"走错方向全错"）→ GoT（图结构，允许中间结论合并复用，解决"路径不能互借"）。工程上 CoT 是零成本标配，ToT 准确率更高但成本 3–5 倍，GoT 偏学术、生产极少落地。
  并行提效：拆完要分析步骤依赖，把无依赖步骤并发跑（依赖图 + asyncio.gather），端到端延迟常降 40%–60%——降的不是"每步时间"而是"关键路径总时间"。

• 关键点 / 展开：

  1. 不拆的系统性失败：让 LLM 一次性写"竞品分析报告"，它常在搜索阶段掺杂分析、写表时引入新竞品、中途忘掉关键数据，输出结构混乱。拆分治的是"注意力分散 + 不可验证"。
  2. 静态 vs 动态拆分对照：静态=提前写死流程（如 搜索→大纲→撰写→润色），可控但僵；动态=LLM 出计划再执行（Plan-and-Execute 三阶段：规划→执行(带全流程 context 防失忆)→汇总），灵活但规划出错则全盘皆输。
  3. 规划能力三方法演进表：

     方法	结构	解决的核心痛点	代价
     CoT	一条链	隐式推理不显式、易跳步累积误差	极低（加一句话）
     ToT	一棵树	一条链走错方向全错，无纠偏	3–5 倍调用（多路径×多层×评估）
     GoT	一张图	树的分支独立、中间结论不能复用	极高，生产未成熟

  4. CoT 的本质与触发：利用 next-token 预测特性——先写出的推理进入上下文，成为后续生成依据，类比"纸上演算比心算稳"。分 Zero-shot（加"让我们一步步思考"）与 Few-shot（给带推理的例子，更稳定）。
  5. 并行优化（数据流）：依赖图决定关键路径；无依赖步骤并发。例：步骤1与2并行→3依赖1→4依赖2和3，串行 12s、并行 9s；步骤越多可并行越多，省时越可观。
  6. 粒度把握——原子操作：以"能否写出清晰函数签名"为判据。如"搜索竞品A信息"是原子的（单输入单输出）；"整理竞品分析"不是（含搜索/筛选/格式化三件事）。太细则调用次数与 token 升、各段衔接生硬；太粗则回到原问题。

• 常见追问：

  1. 动态拆分（Plan-and-Execute）规划质量不稳定，有什么兜底机制？（指向规划校验、人类确认、计划回滚、子目标失败重试）
  2. GoT 在生产环境几乎没落地，除了"实现复杂"，还有哪些真实障碍？（指向编排成本、评估难度、收益不显著）

• 2026 延伸：CoT（Wei et al., 2022）、ToT（Yao et al., 2023）、GoT（Besta et al., 2023）构成"显式化推理"的方法谱系；与 Agent 结合时，规划能力正逐渐下沉为"规划器 LLM + 执行器 LLM"的分工，被 LangGraph、Google ADK 等以"supervisor / planner 节点"形式工程化。

Q7. 为什么有时候选择"手搓" Agent，而不是直接用成熟框架？［来源：美团］

• 核心答案：
  框架（LangChain / LlamaIndex / AutoGen 等）的价值是把每个 Agent 项目都要重复做的脏活封装好——工具格式定义、工具调用结果解析、对话历史维护、失败重试、向量库接入等，POC 阶段能把"两周工作缩短到两天"。但痛点随项目推进分阶段暴露：①抽象层过多、排查黑盒（stack trace 几十层、问题在框架内还是自己代码里难辨）；②版本升级破坏性变更（breaking change 把线上跑坏）；③规模化后隐性开销（序列化、callback、日志在每次调用白跑）。
  手搓的本质优势是"完全掌控"：链路透明可观测、精确裁剪无冗余、稳定不受框架升级影响。务实的折中策略是**“核心逻辑手写、周边工具借框架”——调用循环/历史管理/错误处理/状态维护（Agent 的"心脏"）手写，tracing/文档解析/向量库客户端（“工具性周边”）用现成。手搓不是"比框架好"，而是在特定阶段（上生产、高流量、高度定制、高可观测）**有特定价值。

• 关键点 / 展开：

  1. 框架的真实收益：@tool 注册工具、AgentExecutor 封装 ReAct loop，内置 tracing/callback/记忆管理，探索期几乎零副作用。
  2. 痛点三阶段：探索期（爽）→ 第一个诡异 bug（黑盒排查，得一层层读框架源码或翻 GitHub issue）→ 版本升级（接口改、代码报错、十几处改动）→ 性能优化（profile 发现框架每次调用做了你不需要的通用逻辑，高流量下累积成真实延迟与费用）。
  3. 手搓三优势：①链路透明、可观测好（任意位置加日志/断点/监控，线上靠日志最快复现）；②精确裁剪、无冗余（只写需要的逻辑，性能优化空间在自己手里）；③稳定可控、不受升级影响（依赖只到底层 LLM SDK，可长期运行）。
  4. 取舍决策：用框架 = POC 快速验证、团队刚接触 Agent、核心逻辑不复杂；选手搓 = 准备上生产、流量上来、业务逻辑高度定制、需高可观测性。
  5. 折中方案（最务实）：核心手写（调用循环/历史/重试/状态），周边借用（LangSmith tracing、LlamaIndex 文档解析、向量库客户端）。类比盖房——承重墙与布局自己掌控，门锁插座买现成。
  6. 典型演进轨迹：框架起步验证方向 → 遇首批线上问题后替换关键部分为手写 → 流量上来核心逻辑全手写 → 框架仅留做得好的周边。判断信号：能说清"框架替我做了什么、内部发生了什么"就有掌控感；只调方法不知内部=黑盒，需警惕。

• 常见追问：

  1. 如何量化判断"框架隐性开销"是否到了必须手搓的程度？（指向 profiling 指标：单次调用框架开销占比、P99 延迟、单位请求成本）
  2. 团队从框架迁移到手搓，有哪些渐进式迁移策略以避免一次性重写风险？

• 2026 延伸：Anthropic《Building Effective Agents》隐含同样主张——优先用简单、透明的实现，框架的抽象在复杂场景反而成为负担；Google ADK、OpenAI Agents SDK 等新一代框架也在朝着"轻编排 + 低抽象、核心 loop 可被开发者完全接管"的方向收敛，正呼应"核心手写、周边借用"的折中哲学。

📌 本题型速记 Checklist

• Agent ≠ 大模型 + Prompt：它是「LLM（决策）+ 工具（执行）+ 记忆（状态）+ 规划（拆解）」四组件的自主闭环系统。
• Agent vs LLM 本质：LLM 是被动问答机；Agent 是「感知→规划→行动→再感知」的自主执行者，价值在"从生成文字到执行任务"。
• Tools / Workflow / Agent 是三层嵌套、非三选一：Tools 只执行、Agent 自决策、Workflow 开发者硬编码；核心区别在于"谁决定下一步"。
• 生产主流是 Agentic Workflow：主流程 Workflow 框住（可控），关键节点嵌 Agent（灵活），别一上来就纯 Agent。
• 区分"设计范式"与"推理模式"：范式=顶层流程（ReAct/Plan-and-Execute/Reflection），模式=每步思考（CoT/ReAct）。
• ReAct：Thought→Action→Observation 循环、代码驱动、灵活透明但长任务易跑偏。
• Plan-and-Execute：规划与执行解耦，治长任务跑偏，控但僵、贵。
• Reflection 不是独立流程，是质检 buff：生成→评估→改进（Self-Refine），步骤级/任务级两粒度，独立 Critic 比自反思客观，必设最大轮次防死循环。
• 规划能力三演进：CoT（一条链）→ ToT（多路径剪枝，3–5 倍成本）→ GoT（图复用，偏学术）；CoT 是零成本标配。
• 任务拆分两思路：静态（硬编码 Workflow，可控僵）/ 动态（LLM 规划=Plan-and-Execute，灵活但规划质量不稳定）；靠依赖图 + 并发降关键路径 40%–60%。
• 手搓 vs 框架：框架 POC 快但黑盒/易破改动/隐性开销；手搓完全掌控；务实=核心手写、周边借框架。
• 选型总原则：够用就好，别堆范式；先问"是否真需要 Agent 的自主性"，从最简单透明的实现起步（Anthropic《Building Effective Agents》）。