Agent 生产落地：10大核心问题深度解析
声明：📝 作者：甜城瑞庄的核桃（ZMJ）
原创学习笔记，欢迎分享，但请保留作者信息及原文链接哦～
目录
- Agent 架构模式：ReAct vs. Plan-and-Execute
- 工具调用参数校验：三层防护体系
- 大规模工具集的路由与选择
- 容错与错误处理：分类处理机制
- 长上下文中的记忆机制：三段式记忆法
- 决策安全与风险控制
- 模糊意图的处理：先猜后问策略
- Agent 量化评估体系
- 多模态信息处理：模块化 vs. 原生架构
- Agent 开发运维：AgentDevOps
1. Agent 架构模式：ReAct vs. Plan-and-Execute
1.1 核心区别：规划与执行的耦合方式
选择架构模式的本质不是"任务复杂度"，而是任务的不确定性。
ReAct（Reasoning + Acting）
ReAct 由 Yao et al.（谷歌大脑 + 普林斯顿，2022）提出，核心是将"推理"与"行动"紧密耦合在一个循环中。
【ReAct 循环】 用户输入 │ ▼ ┌─────────────────────────────┐ │ Thought（思考） │ ← LLM 推理当前状态，决定下一步 │ Action（行动） │ ← 调用工具 │ Observation（观察） │ ← 获取工具返回结果 └─────────────┬───────────────┘ │ 循环，直到任务完成或达到最大步数 ▼ 最终输出核心缺陷（工程视角）：
| 缺陷 | 说明 |
|---|---|
| 无全局视野 | 只优化"下一步"，无法做整体最优规划 |
| 上下文污染 | 每步累积历史导致 LLM “注意力稀释”，上下文越长模型越笨 |
| 链式崩塌 | 每步 95% 成功率，连续 10 步成功率仅约59%（0.95^10） |
| 成本失控 | 第 10 步的 prompt_tokens 可能是第 1 步的 5 倍以上 |
Plan-and-Execute
受 Wang et al.（2023）《Plan-and-Solve Prompting》启发，将系统划分为三个独立角色：
【Plan-and-Execute 架构】 用户输入 │ ▼ ┌──────────────┐ │ Planner │ ← 大脑：生成完整的多步计划（结构化 JSON 步骤列表） │ （大语言模型）│ └──────┬───────┘ │ 完整计划 ▼ ┌──────────────┐ ┌──────────────────────────────┐ │ Executor │ ───► │ Step 1 → Step 2 → Step 3 ... │ │ （执行引擎） │ └──────────────────────────────┘ └──────┬───────┘ │ 执行结果 + 异常 ▼ ┌──────────────┐ │ Replanner │ ← 复盘者：当执行结果与预期不符时，重新规划 └──────────────┘架构对比总览：
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 规划方式 | 逐步即时决策 | 全局提前规划 |
| 动态适应性 | ✅ 极强 | ⚠️ 需 Replanner 介入 |
| Token 成本 | ❌ 高，随步数指数增长 | ✅ 可控 |
| 适合场景 | 需要实时反馈、意图随时变化的开放任务 | 目标明确、步骤固定的复杂任务 |
| 典型应用 | 旅行规划、对话式助理 | 日报生成、数据分析、多阶段工作流 |
1.2 最优实践：混合模式
两种模式并非对立，生产环境中最优的工程实践是将二者结合：
Plan-and-Execute 宏观框架 + ReAct 微型检查点
在 Plan 的每个关键节点（如 API 调用后、文件写入后）嵌入一个微型的 ReAct 循环，用于：
- 检查执行结果是否符合预期；
- 若不符合（如 API 返回字段缺失），触发局部自我修复，而不让整个计划崩溃；
- 修复成功后继续执行下一步；修复失败则上报 Replanner。
【混合模式流程】 Planner 生成宏观计划 [Step1, Step2, Step3] │ ▼ 执行 Step1 ──► 微型 ReAct 检查点 │ 符合预期？ ├── ✅ 是 ──► 执行 Step2 └── ❌ 否 ──► 局部自修复 ──► 重试 Step1 │ 多次失败？ └── 上报 Replanner 重新规划1.3 2025 年 Agent 框架演进：四类阵营
| 阵营 | 代表框架 | 核心特点 |
|---|---|---|
| 基础认知架构 | ReAct、Plan-and-Execute | 单 Agent 推理范式 |
| 多 Agent 协作层 | AutoGen、CrewAI、MetaGPT | 多角色分工协作 |
| 图/状态编排层 | LangGraph | 从"概率提示流"转向"确定性状态流"，生产级首选 |
| 代码中心化层 | Smolagents | “代码即行动”，解决 JSON 解析脆弱性 |
📌LangGraph 的核心价值：将 Agent 执行流从不可预测的"概率提示流"转变为可控的"确定性状态机"，是 2025 年生产级 Agent 系统的关键架构演进方向。
2. 工具调用参数校验：三层防护体系
2.1 问题根源
"模型瞎传参数"是生产环境中最高频的故障类型之一。根本原因：大模型的统计本质使其在处理严格结构化参数时不够严谨，尤其在参数类型、枚举值、格式约束方面容易出现偏差。
解决方案不能只依赖 Prompt 优化，必须建立系统性的多层安全防线。
2.2 三层防护架构
【参数校验三层防护】 LLM 生成工具调用参数 │ ▼ ┌─────────────────────────────────────────────────────┐ │ 第一层：防御性 Schema（预防层） │ │ │ │ · 在 Prompt/JSON Schema 中加入"负面描述" │ │ 例："城市名必须从用户输入提取，禁止从地址解析" │ │ · 加入 Few-shot 示例，告知模型"不要做什么" │ │ · 明确枚举合法值范围 │ └──────────────────────┬──────────────────────────────┘ │ 参数输出 ▼ ┌─────────────────────────────────────────────────────┐ │ 第二层：硬校验 + 自动重试（拦截层） │ │ │ │ · 使用 Pydantic / JSON Schema Validator 严格校验 │ │ · 类型不匹配、枚举非法 → 构造清晰错误提示 │ │ · 引导模型自动修正参数并重试（最多 N 次） │ │ · 记录每次校验失败的原因，供后续分析 │ └──────────────────────┬──────────────────────────────┘ │ 校验通过 ▼ ┌─────────────────────────────────────────────────────┐ │ 第三层：业务兜底（安全阀） │ │ │ │ · 在执行前调用轻量级"存在性检查"接口 │ │ 例：传 order_id 前先验证该 ID 是否存在于数据库 │ │ · 对高风险操作（删除/支付）强制二次确认 │ │ · 业务逻辑层的最终兜底，不依赖 LLM 的自我判断 │ └─────────────────────────────────────────────────────┘2.3 Pydantic 校验 + 自动重试示例
frompydanticimportBaseModel,validatorfromenumimportEnumclass
