Agent 和 Function Calling 是怎么回事？

2026年阅读约 9 分钟面试指南 · AI面试

AI 面试 Agent

AI开发面试题：AI Agent架构，Function Calling协议、ReAct模式、记忆系统、多Agent协作、MCP协议、护栏与可观测性、成本控制，分三层讲解。

一句话总结

Agent = LLM + 工具 + 循环：模型不再只输出文字，而是通过 Function Calling 输出结构化的"工具调用请求"，系统执行后把结果回填，模型再决定下一步——推理 → 行动 → 观察循环往复直到完成任务（ReAct 模式）。Agent 的工程难点不在"智能"，在可靠性：护栏、超时、成本和可观测性。

初级理解

Function Calling 四步流程（面试必背）：

① 开发者把工具清单（名称/描述/参数 Schema）随请求发给模型 ② 模型判断需要查订单 → 返回结构化调用： {"name": "query_order", "arguments": {"order_id": "123"}} ③ 系统执行真实函数，拿到结果 ④ 结果回填到对话上下文 → 模型继续生成最终回答

关键认知：模型不执行任何东西——它只输出"想调什么工具、传什么参数"，执行永远在你的代码里。所以工具描述（description）写得越清楚，模型选工具越准——工具描述就是给模型看的"API 文档"。

Agent vs 聊天机器人：聊天机器人一问一答；Agent 能自主拆解多步任务、调用工具、根据中间结果调整计划。核心差异是"决策循环"的存在。

中级深入

ReAct 模式：Reason + Act 交替——模型先输出思考（我要先查库存），再输出行动（调用工具），观察结果后再思考。相比一次性输出计划，ReAct 能根据每步结果动态纠偏，是目前 Agent 框架的默认范式。

记忆系统：

短期记忆：当前对话上下文（窗口有限，要管理截断/摘要）
长期记忆：跨会话持久化——对话历史/用户偏好向量化入库，需要时检索注入
工作记忆：任务状态、中间结果（通常落库或状态文件，别全塞上下文）

工具设计三原则：① 数量克制（工具太多选择准确率下降，10~20 个内）；② 描述精确（含参数含义、返回示例、何时该用/不该用）；③ 粒度合适（"查订单+查物流"合并成一个工具往往比两个更好——减少模型出错机会）。

注意：工具返回结果要截断/摘要后再进上下文——一个返回 5000 行日志的工具能把对话窗口撑爆。

高级拓展

多 Agent 协作：复杂任务拆给多个专职 Agent（规划者/执行者/审查者），通过消息传递协作。适用场景：单 Agent 上下文装不下、职责需要隔离（如"写代码的"和"审代码的"分开）。代价：通信成本、错误传播放大、调试复杂度——能单 Agent 解决就不要多 Agent。

MCP（Model Context Protocol）：Anthropic 开源的"工具接入标准协议"——工具提供方实现一次 MCP Server，任何支持 MCP 的模型/客户端都能直接用，避免每个应用重复写胶水代码。类比：USB 接口标准化。面试提 MCP 说明你跟到了 2025 年后的生态。

护栏（Guardrails）与可观测：

执行护栏：工具白名单、参数校验、危险操作（删数据/转账）强制人工确认
循环护栏：最大步数、最大 Token 预算、同一步骤重复 N 次强制终止
可观测：每步记录（思考/调用/结果/耗时/费用），链路追踪——不然线上排障是玄学
评估：任务成功率、平均步数、单位任务成本，用固定任务集回归

实战场景

场景一：运维助手 Agent 设计（设计题高频）

工具集：查告警 / 查日志（只读）/ 查指标 / 执行预案（写，需确认）流程：告警触发 → Agent 拉日志指标定位 → 输出诊断结论 → 给出修复预案 → 人工审批 → 执行 → 复查护栏：只读工具直接放行；写操作必须人工确认；每步落审计日志；Token 预算 50K 上限

场景二：Agent 死循环烧钱

// 现象：模型反复调用同一工具、任务永不结束 // 治理： // 1. 最大步数上限（如 15 步）+ 超限走人工兜底 // 2. 同参数重复调用检测：连续相同调用 → 注入提示"该方式无效，请换思路" // 3. 工具返回错误信息要"可行动"：告诉模型下一步该做什么

场景三：工具太多模型选错

// 20+ 工具后选错率明显上升 // 方案：工具分组路由（先让模型选"类别"再给该类工具清单） // 或 RAG over tools：按任务语义检索相关工具（大规模工具库的解法）

面试模拟

Q：Function Calling 和普通让模型输出 JSON 有什么区别？

A：本质都是结构化输出，但 FC 是模型厂商原生支持：参数 Schema 经过训练对齐、带"是否该调用"的判断、API 层面保证格式合法（失败重试由厂商处理）。自己正则抠 JSON 则全靠提示词硬约束。另外 FC 让"多工具选择"成为模型内建能力——这正是 Agent 循环的基础。没有 FC 能力的模型，用严格的 JSON Schema 提示词也能做，只是可靠性低一档。

Q：Agent 可靠性差的根源是什么？你们怎么保证线上可用？

A：根源是多步决策的误差累积——每步 95% 正确，10 步下来只剩 60%。所以工程上：① 缩短任务链（拆小任务、能单步不循环）；② 关键路径"生成建议 + 人工确认"而不是全自动；③ 强护栏（步数/预算/白名单/审计）；④ 用固定任务集持续测任务成功率，不达标不放量。核心理念：把 Agent 当"初级员工"管理——授权有限、汇报勤、有 mentor 兜底。

Q：MCP 解决了什么问题？

A：工具接入的碎片化——以前每个 AI 应用接每个数据源都要写一次胶水代码（鉴权、Schema、传输），MCP 把它标准化成协议：工具方实现 MCP Server（工具描述+执行），宿主应用实现 MCP Client，两边即插即用。生态意义类似数据库的 ODBC/JDBC。局限：协议还在演进、企业级鉴权与审计方案尚不成熟，核心敏感系统接入仍需自建网关层。