Agent、工具调用与工作流

Agent 执行循环

理解目标分析用户意图和约束

->

规划步骤决定是否需要工具或检索

->

调用工具生成结构化参数并执行外部能力

->

观察结果读取工具返回，判断是否继续

->

输出结果完成任务或请求用户确认

生产环境要给 Agent 加步骤上限、权限校验、日志和高风险操作确认。

Agent 是什么？

Agent 可以理解为具备一定自主决策能力的 LLM 应用。

它通常能：

• 理解用户目标
• 拆解任务
• 选择工具
• 调用工具
• 根据结果继续推理
• 最终给出答案或完成操作

和普通聊天不同，Agent 不只是生成文本，还会和外部工具或系统交互。

Agent 的核心知识点有哪些？

重点掌握：

• 任务规划：模型如何把复杂目标拆成步骤。
• 工具选择：什么时候调用搜索、数据库、代码执行、业务 API。
• 记忆机制：短期上下文和长期记忆如何区分。
• 观察反馈：工具返回后如何继续决策。
• 终止条件：什么时候停止调用工具并输出结果。
• 安全边界：哪些操作必须人工确认。

面试时可以强调：Agent 的价值是把 LLM 从“回答问题”扩展到“执行任务”，但工程落地必须限制权限、步骤和风险。

工具调用是什么？

工具调用是让模型在需要时调用外部函数或 API。

常见工具：

• 搜索知识库
• 查询数据库
• 调用订单接口
• 发送邮件
• 获取天气
• 执行计算

工具调用的关键是：模型生成结构化参数，系统负责真正执行工具。

{
  "tool": "search_orders",
  "arguments": {
    "userId": "123"
  }
}

Function Calling 是什么？

Function Calling 是让模型按照开发者定义的函数 schema，生成结构化调用参数。

模型不直接执行函数，而是告诉系统“应该调用哪个函数、参数是什么”。真正执行由后端完成。

典型流程：

1. 开发者定义函数名称、说明和参数 schema。
2. 用户提出问题。
3. 模型判断是否需要调用函数。
4. 模型返回函数名和结构化参数。
5. 服务端执行函数。
6. 把函数结果再交给模型生成最终回复。

常见面试追问：为什么不让模型直接拼接口 URL？因为结构化 schema 更可控，后端可以做鉴权、参数校验、审计和错误处理。

Function Calling 和 Agent 有什么区别？

Function Calling 更偏单次或受控的工具调用机制。

Agent 更偏多步骤任务执行，可以多次选择工具、观察结果、再决定下一步。

对比：

• Function Calling：更可控，适合明确工具调用
• Agent：更灵活，适合开放任务和多步骤规划

生产环境中，不一定要一上来就做 Agent。很多业务用受控工具调用和工作流就够了。

MCP 是什么？

MCP 是 Model Context Protocol，一个把 AI 应用连接到外部工具、数据源和工作流的开放协议。

可以把它理解成“AI 应用连接外部系统的标准接口”。它让 AI 客户端通过统一协议连接 MCP Server，访问文件、数据库、搜索、业务系统、工具和提示词能力。

核心角色：

• MCP Host：承载 AI 体验的应用，比如聊天应用、IDE、智能助手。
• MCP Client：Host 内负责和 Server 通信的客户端。
• MCP Server：暴露工具、资源、提示词或业务能力的服务。
• Tools：可执行动作，例如查询数据库、搜索、创建工单。
• Resources：可读取上下文，例如文件、文档、表结构。
• Prompts：可复用的提示词模板或工作流入口。

MCP 解决什么问题？

没有 MCP 时，每个 AI 应用都要为每个外部系统单独写连接器，形成 N 个客户端乘 M 个工具的集成复杂度。

MCP 的目标是标准化连接方式：

• 工具接入更统一。
• AI 客户端可以发现和调用外部能力。
• MCP Server 可以被多个客户端复用。
• 企业可以更集中地治理权限、审计和工具边界。

面试时可以用一句话概括：MCP 解决的是 AI 应用和外部工具之间的标准化集成问题。

MCP 和 Function Calling 有什么区别？

Function Calling 是模型 API 层面的“结构化工具调用能力”。

MCP 是应用集成层面的“客户端和外部工具服务通信协议”。

对比：

• Function Calling 关注模型如何决定调用哪个函数、传什么参数。
• MCP 关注工具如何被发现、连接、暴露和复用。
• Function Calling 偏模型接口能力。
• MCP 偏生态协议和工具连接标准。

它们可以一起使用：模型通过工具调用决定动作，应用通过 MCP Server 真正访问外部系统。

Agent 为什么容易不稳定？

常见原因：

• 任务目标不清晰
• 工具描述不准确
• 工具返回信息太乱
• 缺少步骤限制
• 缺少失败处理
• 模型选择了错误工具
• 检索或外部接口结果有噪声

优化方法：

• 写清楚工具名称和参数
• 限制最大步骤数
• 给工具结果做结构化
• 对关键操作加确认
• 增加日志和 trace
• 为常见流程设计固定工作流

Agent 面试常见问题有哪些？

Agent 和普通 Chatbot 有什么区别？

普通 Chatbot 主要负责对话生成，输入问题后直接回答。Agent 更强调“目标驱动”，它可以规划步骤、调用工具、观察结果并继续执行。

工程上不要把所有对话都做成 Agent。确定流程适合工作流，不确定、多步骤、需要工具探索的任务才适合 Agent。

Agent 如何选择工具？

Agent 选择工具依赖工具描述、参数 schema、当前任务目标和上下文。工具名称和描述要清晰，参数要结构化，避免让模型猜接口。

更稳定的做法是限制工具集合，只给当前任务需要的工具，并在后端做参数校验、权限校验和审计。

如何避免 Agent 无限循环？

可以限制最大步骤数、最大工具调用次数、最大耗时和最大 token。还要让 Agent 在多次失败后停止，并返回可解释的失败原因。

工程上可以识别重复调用同一工具、重复得到相同结果、计划没有推进等信号，触发降级或人工接管。

如何限制 Agent 的权限？

遵循最小权限原则，只给 Agent 当前任务需要的工具和数据。高风险操作如删除、付款、发消息、改权限必须二次确认。

后端要校验用户身份、业务权限、参数范围和操作审计，不能只依赖模型“自觉”不越权。

Agent 失败时如何降级？

常见降级方式包括返回人工入口、切换固定流程、只给检索结果不执行动作、使用更保守的模型或缩小任务范围。

关键是让失败可控：用户要知道失败原因，系统要记录 trace，工程团队能复盘是检索错、工具错、权限错还是模型规划错。

如何评估 Agent 是否真的完成任务？

评估不能只看回答是否流畅，要看任务结果是否达成。可以用任务完成率、工具调用准确率、步骤数、错误率、人工接管率、耗时和成本来衡量。

对于关键任务，还可以设计自动检查器或业务校验，例如订单是否真的创建、邮件是否真的发送到正确对象。

Function Calling 和 MCP 的关系是什么？

Function Calling 是模型调用工具的一种接口形式，重点是让模型输出结构化参数。MCP 更像工具和上下文的标准协议，用来统一连接不同工具、资源和服务。

可以理解为：Function Calling 解决“模型如何调用函数”，MCP 解决“工具和上下文如何以统一方式接入应用”。

工具返回错误时应该怎么处理？

工具错误要结构化返回，包括错误码、错误原因、是否可重试和建议动作。Agent 可以根据错误类型决定重试、换工具、补参数或停止。

对权限不足、危险操作、参数非法这类错误，不应该让模型无限重试，而应该明确失败并给用户可操作的提示。

回答时不要只说“让模型自己规划”。更成熟的答案是：开放规划只用于不确定任务，确定流程应该用受控工作流，关键操作要有权限校验和人工确认。

ReAct 思路是什么？

ReAct 是 Reasoning + Acting 的思路。

模型在任务中交替进行：

• 思考
• 行动
• 观察
• 再思考

这个模式适合需要多步推理和工具调用的任务。

在工程实践中，不一定要让模型输出完整思考过程，但可以保留“计划、调用工具、观察结果、继续执行”的结构。

多 Agent 是什么？

多 Agent 是把复杂任务拆给多个角色或多个执行单元。

例如：

• 规划 Agent
• 检索 Agent
• 代码 Agent
• 审核 Agent
• 总结 Agent

优点是职责更清晰，缺点是链路更复杂、延迟更高、评估更难。

面试时可以说：多 Agent 不是越多越好，简单任务用单 Agent 或固定工作流更稳定。

Agent 如何做安全控制？

关键控制点：

• 工具权限最小化
• 高风险操作需要用户确认
• 限制工具调用次数
• 参数校验
• 敏感信息脱敏
• 操作日志审计
• 防止 Prompt Injection

例如删除数据、发邮件、支付、改权限这类动作，不能只靠模型自己判断，必须有业务规则和确认机制。