AI Agent 核心概念
1. 大白话:这是什么?解决什么痛点?
这是什么?
AI Agent 的核心可以用两个经典公式来定义和拆解:
- 理论学界公式:Agent = LLM + Planning + Memory + Tools(由 OpenAI 的 Weng Lilian 提出,侧重于系统能力要素的拆解)[1, 2]。
- 工程业界公式:Agent = Model + Harness(侧重于系统工程实现,常由 LangChain / LangGraph 等框架提出)。
- Model(大脑):负责纯粹的推理、语义理解和决策生成(即大模型本身)。
- Harness(系统容器 / 缰绳):包裹在大模型外侧的运行环境与工程装配线。它包括控制循环(Agent Loop)、上下文工程、工具真实执行器、状态持久化、以及安全熔断围栏(如拦截死循环)。
解决的痛点
- 传统编程与工作流(Workflow)的局限:传统编程和 Workflow 适合逻辑完全固定、路径清晰且能够提前设计好每一步的确定性场景(比如审批流、数据库更新)。但对于“排查系统变慢原因”这样无法提前穷举所有步骤的复杂问题,它们无能为力。
- Agent 的核心痛点解决:它解决的是应对不确定的复杂动态场景。你只需要给 Agent 设定终极目标,它能“走一步看一步”,通过分析实时的环境反馈(Observation)来动态调整自己的动作,省去了人工提前编排所有分支逻辑的麻烦。
- Harness 的工程痛点解决:大模型本质上是“静态且不可控的生成器”。Harness Engineering(缰绳工程) 解决的是如何通过外围的强类型代码把模型“拴住”,为其提供手脚(Tools)、记忆(Memory)和限流熔断保护,使其能在工业生产环境中安全、稳定、确定地运行。
2. 底层机制与高频考点
底层核心机制
- Agent Loop(自主循环):Agent 跑起来的核心是一个 While 循环。它在每一轮迭代中主要做三件事:模型推理(Decide)-> 工具调用(Act)-> 捕获工具返回结果写回上下文(Observe)。直到任务完成或触发最大迭代轮次限制(一般设为 4 至 10 轮以防死循环)。
- 系统三层架构:
- LLM Call 层:负责底层大模型的基础调用与流式响应处理。
- Tools Call 层:负责模型与外部世界交互(Function Calling / MCP 协议接入)。
- Context Engineering(上下文工程)层:负责 LLM 的“内存管理”(动态加载规则、记忆与工具描述描述)。
高频面试对比考点
考点一:Agent vs Workflow (工作流)
- 纯 Agent:LLM 是决策者。路径动态规划,灵活性高但极难控制、调试困难、Token 成本高。适合路径难以确定的开放性任务。
- Workflow:图结构是决策者。路径完全确定,LLM 仅是图中的一个处理节点,极其稳定可控。适合容错率低、逻辑固定的商业场景。
- Agentic Workflow:全局使用 Workflow 约束骨架,局部节点嵌入 Agent 探索,是工业落地的最佳实践。
考点二:Prompt Engineering vs Context Engineering
- Prompt Engineering(提示词工程):关注指令如何写得清晰(如写清角色、任务、规范)。
- Context Engineering(上下文工程):关注模型窗口的“内存管理”。在 Token 窗口有限且成本高昂的前提下,决定什么信息、在什么时机、以什么结构喂给大模型(如 LRU 内存置换策略、JIT 上下文卸载等),避免模型在中段信息利用率下降(Lost in the Middle)。
考点三:Function Calling vs MCP 协议 vs Agent Skills
- Function Calling:模型表达调用意图的能力(输出包含工具名和参数的 JSON)。
- MCP (Model Context Protocol):工具接入宿主的通信标准。让底层系统封装的工具能被 AI 应用自动发现和调用,实现工具开发与 Agent 层的解耦。
- Agent Skills:Agent 的任务 SOP 经验包。以
SKILL.md形式定义,采用延迟加载机制,指导 Agent 在特定场景下该怎么按步骤约束执行。
考点四:短期记忆 vs 长期记忆
- 短期记忆:会话级别的暂存信息,依赖于 Context 窗口,容易随时间截断。通过上下文缩减(滑动窗口)或上下文卸载控制膨胀。
- 长期记忆:跨会话持久化知识库。通过异步任务在后台提纯过滤写入,使用向量库语义检索(Vector)或 Markdown 配置(规则)进行加载。
3. 🎯 实战口径
TIP
面试官提问口径:“你在项目中是怎么理解和应用 AI Agent 架构的?遇到了什么痛点,如何解决?”
我的高分回答口径: “在我的【苍穹外卖AI客服】项目中,我基于 Spring AI 落地了完整的 Agent 架构。我对于 Agent 的理解是:它是 LLM、上下文管理与外部工具的闭环实体。 我们核心是通过 Spring AI Advisor 链 组装了 Agent 运行的主循环(Agent Loop)。在这套架构中,我们深刻体会到 Context Engineering(上下文工程)比 Prompt 工程更难也更核心: 为了控制 Token 消耗并降低大模型的工具幻觉,我们设计了两级工具过滤与计算模型(基于 UserContextAdvisor 提取意图动态下发允许的工具白名单,而不是把所有 API 喂给大模型)。 此外,为了防范 Agent Loop 的工具死循环,我们在最尾部装配了自研的 SafeToolCallAdvisor,通过为大模型生成的工具参数签名(Signature)做缓存,当发现重复签名或工具链运行超过 4 轮时进行强行 fallback 短路截断,从而把一个动态不可控的 Agent Loop 变为了工程上可用、确定性极强的生产级系统。”
相关链接:[[苍穹外卖AI客服]] | [[面试复习计划]]