本篇属于 智能体面试与工程基础 系列。
从一次请求的执行链路出发，理解模型、工具和运行程序各自承担的责任。先练口述，再用追问检查理解是否完整。
A01｜P0：介绍项目与完整请求链路
口述： 先讲用户任务和成功标准，再沿鉴权、会话加载、路由/规划、工具执行、结果校验与响应说明链路。指出我负责的部分、为什么选择动态Agent，以及当前不足。入口和最终响应不一定各需要一个独立Agent。
追问： 画出一次实际请求的 trace；用哪个基线证明Agent值得引入？
A02｜P0：什么时候用ReAct，什么时候用固定工作流或Plan & Execute？
口述： 输入充分且流程固定时先用普通调用或工作流；反馈会改变下一步时考虑ReAct；复杂任务可先做有依赖的计划，再边执行边修订。规划和执行不必是两个独立模型，简单任务可以直接走短路径。
追问： 计划过时如何重规划，已经成功的副作用如何避免重做？
完整循环： 加载目标与状态→模型提出下一步或最终答案→运行程序校验工具、参数及权限→真实执行→把结果或结构化错误关联到该调用→更新状态再决策→验收后结束。Thought 是推理轨迹的一种表达，不是执行结果；工具 Observation 由执行层提供。支付、审批等固定规则可以放在工作流中，检索探索部分再交给 Agent。
A03｜P0：规则、分类模型和LLM如何做意图路由？
口述： 确定、风险高的业务条件可用规则约束；稳定标签和足够数据适合分类模型；开放意图可由LLM结构化解析。保留原始请求，检查槽位与权限，缺信息时澄清。多意图要拆成子任务并明确依赖。
追问： “查工单并约周末取车”需要哪些槽位？模型自报置信度是否经过校准？
防意图漂移： 保存原请求及结构化约束（主体、时间、否定条件、目标动作），每次改写或重规划检查这些约束。Few-shot 示例应包含相近意图、反例和“不支持/需澄清”，并用独立样本看混淆矩阵及误路由成本。模型口头说“90%确定”不能直接用作可靠阈值。
A04｜P0：Agent、Skill、MCP、CLI、Function Calling分别是什么？
口述： Agent执行目标导向的决策循环；Skill通常封装可复用说明、资源和可选脚本，具体格式依实现；Function Calling表达结构化调用；MCP连接应用与工具/资源提供方；CLI是命令行入口。它们可以组合，不能把协议或说明文件当作权限控制。MCP架构
追问： 一个Skill包装多条CLI命令时，参数、输出和失败边界在哪里？
再区分两层： Tool Calling 规定模型怎样表达调用；MCP 规定宿主应用如何与服务端发现、访问工具和资源等。MCP client 获得工具定义后，宿主仍要把定义适配给模型、接收调用并处理权限与结果。把本地函数改成 MCP 服务，不会自动提高模型选工具的准确率。
A05｜P0：工具集很大或参数错误，怎么处理？
口述： 提供清晰且不重叠的工具说明，按任务选择相关工具子集；执行前校验schema、业务约束和权限。不存在的工具或错误参数返回结构化错误并有限修复。格式正确不代表调用被授权。
追问： 字符串类型合法，但传入的是另一个租户的订单ID，谁来拦截？
A06｜P0：工具超时、重试与幂等怎么设计？
口述： 分类处理临时错误、参数错误和权限错误；可重试操作设置总deadline、退避抖动和次数上限。副作用操作使用业务幂等键及执行记录，超时先查询结果，不能认定未执行。
追问： 幂等键绑定用户意图、请求还是某次模型调用？同键不同参数怎么办？
A07｜P0：如何检测死循环，何时结束？
口述： 同时限制步数、时间、token和工具成本；结合规范化动作参数、结果指纹及任务进展识别重复。无进展可调整查询、换策略、澄清或停止。结束状态区分完成、失败、取消、待审批与预算耗尽，模型说完成后仍按任务验收。
追问： 合法轮询也会重复同一动作，怎样避免误杀？
A08｜P1：为什么使用LangGraph或自研Harness？
口述： 先列需要的持久化、分支、恢复、人工介入和观测能力，再评估框架收益与复杂度。小循环可自研；框架的checkpoint能保存状态，但不会自动让外部副作用恰好执行一次。按实际安装版本解释恢复行为。LangGraph持久化
追问： worker写外部系统成功、checkpoint落盘前崩溃，恢复后如何判断？
A09｜P1：换模型要改多少，为什么不直接使用现成Agent？
口述： 用适配层统一调用、流式事件和错误，但上下文上限、工具支持、结构化输出与质量仍可能不同，换模型必须回归。现成Agent和自研方案按部署、权限、可观测性、定制、成本及维护评估，不为证明能力而重复造轮子。
追问： 哪一条真实需求让通用产品不适合？
A41｜P1：LangChain 组件与 AgentExecutor 的执行链路如何理解？
口述： Model 封装模型接口；Prompt 组织指令与变量；Chain 表达组合流程；Memory 管理需要延续的信息；Tool 暴露可调用能力；Agent 根据状态选择动作。这是概念分工，不应把旧教程的六类抽象当成所有版本不变的模块表。
传统 AgentExecutor 的典型循环是：调用 agent 规划→得到动作或结束结果→查找并执行工具→记录中间步骤→继续规划，直到结束或预算触发。参数 max_iterations 应由任务步数分布、耗时与成本预算决定，不存在通用最佳值；它也不等于每个工具的硬超时。
版本边界： 当前 LangChain 文档以 create_agent 为主要入口，Agent 构建于 LangGraph 之上；LangGraph 提供更底层的状态和图编排控制。因此“LangChain 不支持持久化，LangGraph 才支持”已经不是可靠的概括。比较旧 AgentExecutor 与显式 StateGraph 时，应说清依赖版本和需要自定义的分支、状态合并及恢复逻辑。LangChain 概览
追问： 达到上限时，返回部分结果、人工接管还是失败？单个工具一直阻塞，循环次数上限能否及时生效？
