阿里千问 Agent 开发二面

《面试题目》

1. 请做一下自我介绍。
2. 手写实现快速排序算法。
3. 详细介绍你技术难度最高、落地价值最大的一个项目，说明难点、优化点与个人核心贡献。
4. LangGraph 的全套核心架构组件有哪些，各自起什么作用？
5. 大模型工具调用常出现哪些问题？对应的工程解决方案是什么？
6. 大模型 Function Calling 工具调用的完整运行原理是什么？
7. 对话 Query 改写在 Agent 体系中的核心作用是什么？
8. 多轮对话 Agent 普遍存在哪些缺陷？如何系统性优化？
9. 你如何理解 Agent 体系中 Skills 的设计思想？
10. 常见的智能 Agent 架构有哪些分类？分别适合什么场景？
11. Agent 多轮 Prompt 拼装的最优顺序是什么？为什么？

《参考解析》

Function Calling 的完整运行原理

请求里带上 tools 数组，每个工具用 JSON Schema 描述名字、用途、参数类型与必填项；经过函数调用微调的模型不再只输出自然语言，而是输出结构化的 tool_calls（工具名加 arguments 的 JSON 串），并以 finish_reason=tool_calls 结束这一轮。客户端要自己解析 arguments、按 schema 校验、路由到真实函数执行，再把结果以 role=tool（带 tool_call_id）追加进消息列表发起下一轮请求，模型基于结果继续推理，直到给出自然语言答案。几个关键点：模型只生产「调用意图 + 参数」，执行永远在应用侧；一轮可以并行返回多个 tool_calls，应用要按依赖关系决定并发还是串行；arguments 是生成出来的，可能是幻觉工具名、越界枚举或非法 JSON，所以校验与自纠（把报错原文回灌给模型）是链路必需的一环，不能假设格式一定合法。

工具调用常踩的坑与对应解法

高频问题有六类：幻觉出不存在的工具或参数；格式崩坏，JSON 前后夹自然语言或 markdown 代码块、流式输出被截断成半个对象；工具集膨胀，数量到几十个之后模型的选择准确率明显下降；上下文被工具结果撑爆，一次检索几千 token，几轮就把窗口塞满、成本失控；有副作用的工具被重复调用，超时重试导致重复下单；异常处理缺失，工具抛错直接终止整条链路。对应的工程解法：服务端按 schema 严格校验，不合法就拒；用结构化输出或约束解码保证 JSON 合法；工具集做分组，或先按意图检索再暴露当前场景需要的几个；参数尽量用枚举、正则与数值范围约束；长结果先摘要或截断，原始结果落外部存储按需取回；副作用工具带幂等键、超时与熔断；把异常信息作为工具返回值回灌，让模型自己纠一次，比直接失败划算得多。

LangGraph 的核心组件

它的定位是把 Agent 循环显式建模成状态图。StateGraph 定义状态结构与节点；State 用带 reducer 的注解（消息列表常用 add_messages）决定并行分支如何合并；Node 是普通函数，负责读写状态；Edge 与条件边负责流转，条件边就是路由；Checkpointer 把每步状态持久化，换来断点续跑、human-in-the-loop（interrupt 暂停等人确认）、时间旅行与失败重放；Store 提供跨会话的长期记忆；Send 用来做 map-reduce 式的动态并行分支；子图把一段流程封装成可复用节点。相比裸写 while 循环，它的价值是可恢复、可观测、可审计——生产上的 Agent 出问题，多数出在循环终止条件与状态污染，而不是模型不够聪明。

Query 改写在 Agent 里的作用

多轮对话里的原始 query 几乎不能直接拿去检索或选工具：含指代、有省略、口语化，还混着上一轮的话题。改写要做四件事：指代消解与省略补全，把 query 还原成自包含的句子；意图识别与路由，判断该走知识库、数据库还是某个工具；查询扩展或分解，把多跳问题拆成可分别检索的子问题；面向检索器的改写，例如生成假设答案再检索、补同义词与领域术语。它决定的是后面所有环节的上限——召回错了，再强的生成也只能编。

多轮 Agent 的缺陷与优化

典型缺陷：上文污染，前面一个错误结论被后面当成既定事实；上下文膨胀带来 lost in the middle 与成本上升；系统约束被长对话稀释；工具结果堆积；同一工具被反复调用；摘要压缩时丢掉关键槽位。优化按层做：把关键事实与约束从自由文本里抽出来，存成结构化状态槽位，每轮显式带进 Prompt；记忆分层——固定指令、滚动摘要、最近 N 轮原文、可检索的长期记忆；工具结果只保留结论、原始结果落盘按需取回；给 Agent 一份显式任务清单并每轮复述目标，降低漂移；对终止条件、重复调用、约束违反做程序化校验，而不是指望模型自觉。

Prompt 拼装顺序为什么这样排

原则是稳定内容在前、易变内容在后，指令与数据分离。推荐顺序：系统角色与硬约束、工具与技能说明、长期记忆与用户画像、当前任务目标与计划、检索到的知识与工具结果、对话历史（越近越靠后）、本轮用户输入。三个理由：注意力的位置效应，长上下文中间的信息容易被忽略，关键约束要放头尾；前缀缓存，KV cache 命中要求前缀逐字节稳定，把每轮都变的内容放尾部才能吃到缓存，这直接决定成本；注入防护，用户输入放最后并用分隔符包裹，避免它被当成系统指令执行。同一份内容换个顺序，效果和成本都可能差出一截。

Skills 的设计思想

Skills 是按需加载的能力说明，核心是渐进式披露：模型平时只看到每个技能的一行名字与描述，判断相关才加载全文。它解决的正是工具与提示词全量塞进上下文的预算问题——几十个能力一次铺开，既贵又让模型选择困难。一个设计好的 skill 内聚三件事：什么时候用它、按什么步骤做、什么算做完，并可以把脚本、模板、检查清单一起打包，让流程可复用、可版本化，也能由模型之外的人维护。与 Function Calling 的分工是：工具描述「能执行的原子动作」，skill 描述「解决一类问题的流程与知识」，前者给手，后者给方法。

架构分类：先工作流，后自主

按执行逻辑分两大族。固定工作流把路径事先编排好，常见模式有提示链、路由分发、并行分支、编排者与工作者、生成与评审循环，优点是路径可预测、可测试、成本可控、失败能定位到具体节点。自主 Agentic 架构由模型自己决定下一步做什么、调什么工具（ReAct、先规划后执行、反思、多智能体协作），只在步数不可预知、下一步依赖上一步结果、且验证手段足够时才划算，代价是成本与延迟不可预测、评测与排障都更难。工程共识是能用工作流解决的不要上自主循环，两者也常混用——外层固定流程保证确定性，内层把某一步交给 Agent 自主发挥。