agent-">Agent核心架构与落地实操对比：从面试题看生产级选型逻辑

一、对比背景

当前AI应用开发面试中，一个普遍现象是：候选人能聊不少理论概念，但一旦问到Agent落地架构就接不上。企业真正看重的是能否把模型、工具、RAG、状态和业务串起来，出问题能不能查、能不能优化。这背后反映的是同一个核心问题——不同技术方案之间的边界与选型依据不清晰。

本文围绕Agent落地过程中最常被考察的25道实操题，从对比视角系统梳理各组技术方案的差异、适用场景与选型逻辑，帮助开发者和架构师建立清晰的判断框架。

二、Agent核心架构对比

2.1 ReAct vs Plan-and-Execute

两者都是Agent的推理范式，但核心差异在于推理与执行的时序关系。

维度	ReAct	Plan-and-Execute
推理方式	边想边做，交替进行	先规划完整步骤，再逐步执行
灵活度	高，可根据中间结果调整	低，计划一旦生成较难变更
Token消耗	较低，每步只推理当前	较高，需先生成完整计划
可控性	较弱，路径不稳定	较强，可审计计划合理性
适用场景	探索型任务、信息检索	流程明确、步骤可预定义的任务

选型依据：如果业务任务的步骤边界清晰、可提前枚举，优先Plan-and-Execute以提升可控性；如果任务需要根据中间结果动态调整路径，ReAct更合适。实际生产中常见做法是两者结合——用Plan-and-Execute做顶层规划，子步骤用ReAct执行。

2.2 单Agent vs 多Agent

多Agent并非越多越好。核心判断标准是：任务是否可以清晰拆分为独立子领域。

• 单Agent适用：任务链路短、工具数量可控、上下文不需要严格隔离。
• 多Agent适用：任务涉及多个专业领域、需要不同系统提示词约束、子任务间可并行。

多Agent的代价是通信开销、状态同步复杂度和调试难度成倍增加。如果单Agent加工作流约束能解决，不建议引入多Agent。

2.3 复杂任务为何不能只靠Prompt

Prompt的本质是软约束，模型不保证100%遵循。当业务要求确定性执行路径、高危操作需审批、失败必须回滚时，必须引入工作流约束（硬编码的状态机或流程引擎）。判断标准：如果某步骤出错会导致不可接受的业务后果，就不应只依赖Prompt。

2.4 工具循环调用与死循环

常见原因包括：工具返回结果不满足模型预期导致反复重试、工具描述模糊导致模型反复选择同一工具、缺少终止条件判断。

解决手段：

• 设置最大循环次数硬限制
• 工具返回中明确标注“成功/失败/需终止”
• 引入状态去重，相同参数重复调用直接拦截
• 高危操作强制人工确认节点

三、工具调用落地对比

3.1 Function Calling vs 模型直出JSON

维度	Function Calling	模型直出JSON
可靠性	高，由模型侧保证格式	依赖Prompt约束，可能格式错误
灵活度	受Schema限制	可自由定义结构
多工具选择	原生支持	需自行解析和路由
适用场景	生产环境、工具数量多	原型验证、结构简单场景

生产环境优先Function Calling，因为格式可靠性直接决定系统稳定性。

3.2 工具Schema设计要点

Schema参数模糊是线上问题的高发区。典型问题包括：

• 参数类型不明确，模型传字符串而系统期望数字
• 缺少枚举约束，模型自由发挥
• 必填/选填标注不清
• 参数描述含歧义，模型理解偏差

设计原则：参数名自解释、类型严格、枚举封闭、描述包含示例。

3.3 多相似工具的区分

当存在多个功能相近的工具时，模型容易调错。解决思路：

• 在工具描述中明确写出“何时用A、何时用B”的边界条件
• 减少相似工具数量，能合并则合并
• 在系统提示词中给出选择决策树

3.4 工具失败的处理策略

重试、熔断、降级需要分层设计：

• 重试：仅对幂等操作、瞬时故障重试，设置指数退避
• 熔断：连续失败达阈值后暂停调用，避免雪崩
• 降级：切换到备用工具或返回缓存结果，保证主流程可用

3.5 工具持续超时的决策

等待、切换还是终止，取决于业务容忍度：

• 若该工具是核心路径且无备选，设置合理超时后终止并告知用户
• 若有备选工具，超时后切换
• 若可异步，转为后台任务，先返回中间状态

四、记忆与状态管理对比

4.1 短期记忆 vs 长期记忆

维度	短期记忆	长期记忆
存储内容	当前会话上下文	跨会话的用户偏好、历史事实
存储介质	内存或会话缓存	向量库或结构化数据库
生命周期	会话结束即清除	持久化
访问方式	直接拼接进Prompt	检索后注入

4.2 为什么不能全量存对话

全量存对话的问题：Token溢出、检索噪声大、成本高、隐私风险。正确做法是分层存储：原始对话归档，提取关键事实和摘要进入长期记忆，检索时只取相关片段。

4.3 已有向量库为何不能全存

向量检索的质量取决于信噪比。全量存入会导致：

• 相似片段过多，检索结果冗余
• 过时信息与最新信息混杂
• 检索延迟随数据量增长

应做写入前过滤：只存经过提取、去重、时效性标注的内容。

五、效果优化与问题排查对比

5.1 任务完成率 vs 工具成功率

工具成功率高不等于效果好。可能的情况：工具都成功调用但组合逻辑错误、任务目标未达成。量化Agent效果需要端到端指标：任务完成率、用户满意度、平均交互轮次、人工介入率。

5.2 卡顿定位方法

分段埋点：模型推理耗时、RAG检索耗时、工具调用耗时分别记录。通过链路追踪快速定位瓶颈环节。

5.3 Token消耗优化

核心手段：精简系统提示词、压缩历史上下文、工具返回结果截断、按需检索而非全量注入。

5.4 Bad Case溯源

建立分类框架：Prompt问题、模型能力问题、工具问题、流程问题。逐层排除，避免盲目调Prompt。

rag-vs-rag">六、Agent-RAG vs 普通RAG

维度	普通RAG	Agent-RAG
检索时机	固定，每次问答必检索	动态，Agent判断是否需要检索
检索次数	单次	可多轮、可迭代
查询构造	用户原始问题	Agent改写、拆解后的问题
适用场景	简单问答	复杂推理、多跳问答

检索不准的优化手段除调Prompt外，还包括：查询改写、混合检索（向量+关键词）、重排序、元数据过滤。

保证可溯源的核心是：检索结果带出处、生成时强制引用、输出后校验一致性。

七、选型建议总结

Agent落地没有万能方案，选型应基于以下判断链：

1. 任务步骤是否可预定义 → 决定ReAct还是Plan-and-Execute
2. 是否需要多领域隔离 → 决定单Agent还是多Agent
3. 格式可靠性要求 → 决定Function Calling还是JSON直出
4. 检索复杂度 → 决定普通RAG还是Agent-RAG
5. 业务容错度 → 决定重试、熔断、降级策略

生产级Agent的核心不是堆砌能力，而是让每个环节可观测、可控制、可回滚。这25道题的价值不在于背答案，而在于建立这套判断框架。