把 LLM 评测的经验直接搬到 Agent 上，几乎一定会翻车。一个单轮的 Chat 模型，输入是 prompt、输出是文本，你可以用困惑度、ROUGE、人工打分甚至一次 API 调用的准确率来度量它。但一个 Agent 是"模型 + 工具 + 规划 + 记忆 + 环境"的复合系统，它的输出不是一段文本，而是一段轨迹：若干次模型调用、若干次工具调用、若干次状态变更，最终才收敛到某个结果。评测对象从"一句话"变成了"一个过程"，这意味着整个评测体系的底层假设都要重写。
本文不打算罗列 Benchmark 榜单，而是从我在生产环境落地 Agent 评测的几次返工出发，讲清楚端到端任务评测、轨迹追踪、可观测性埋点和回归评测集建设这四件事怎么做才不是"自嗨"。
在把大模型真正落到业务场景时，"用 API 还是自己微调"几乎是一个绕不开的决策点。Prompt Engineering 和 RAG 能解决知识注入问题，但解决不了"风格对齐、格式约束、指令遵循、领域术语一致性"这类需要改变模型行为的需求。本文从工程视角梳理一条可落地的 LoRA 微调路径：原理、参数选择、数据构造、训练流程与显存优化、效果评估，以及我在生产环境中踩过的坑。
全参微调（Full Fine-Tuning）意味着对模型的每一个权重都计算梯度并更新优化器状态。以 7B 模型为例，FP32 下权重约 28GB，Adam 优化器需要额外保存一阶矩和二阶矩，再乘以 2，加上梯度本身，训练态峰值显存轻松突破 120GB。这决定了全参微调基本只能在多卡集群上做，中小团队很难承受。
传统 Web 应用的安全边界相对清晰：请求经过认证、授权、输入校验、业务逻辑、输出编码这一条固定链路，攻击面基本可以被枚举。而 LLM Agent 彻底打破了这条链路——模型既是"大脑"也是"解释器"，自然语言本身成为了一种图灵完备的指令通道。这带来两个结构性变化：
第一，指令与数据不再可分。在 SQL 注入时代，我们的防御策略是"参数化查询"，把代码和数据严格隔离。但 Agent 系统里，用户输入、检索到的文档、网页抓取内容、邮件正文，最终都会拼进同一个 prompt，模型无法从语义上区分"这是我该遵守的系统指令"和"这是内容里夹带的恶意指令"。这构成了提示注入（Prompt Injection）的本质：攻击者不是在绕过某个过滤器，而是在污染模型的"世界观"。
在 RAG（检索增强生成）与 Agent 架构里，向量检索几乎成了所有“记忆”与“知识注入”环节的地基。但我在多个生产系统里反复看到同一个误区：团队把注意力全放在“哪个库跑分更高”上，却忽略了真正决定线上体验的，是索引结构、召回率与 QPS 之间的三角权衡，以及数据写入、压缩、过滤、版本治理这些看起来“不那么性感”的工程细节。
本文不打算罗列各家厂商的营销参数，而是从索引原理出发，讲清楚 HNSW 与 IVF 各自的适用边界，给出可复现的调优实验方法，最后落到一份可以直接照做的选型清单。
在 Agent 落地过程中，最容易被低估的往往不是模型能力，而是「输出是否可被程序可靠消费」。当你的下游是一段确定性代码、一个 JSON 解析器、一条数据库写入链路时，模型的「文笔好」「理解到位」统统要让位于一个朴素的标准：这次输出能不能被无脑解析。本文不讨论怎么写「更聪明的提示词」，而是从工程视角拆解一条可落地的管线：指令设计 → few-shot 示范 → 约束解码兜底 → JSON Schema 强制结构化输出。所有结论都来自真实生产环境里踩过的坑。
先说一个反直觉的事实：在绝大多数通用模型上，「请返回 JSON」只是一个概率性的软约束。模型不是为你生成 JSON，而是生成「看起来像 JSON 的文本序列」，其中每一个 token 都是在整个词表上的概率分布中采样出来的。这意味着两个问题：
在构建生产级 Agent 时，最容易被低估的往往不是模型能力或工具调用，而是记忆系统。一个没有记忆的 Agent 每次对话都从零开始，无法识别用户、无法复用已确认的偏好、无法从历史失败中修正策略；而一个记忆失控的 Agent 则会在上下文里堆积大量无关信息，导致成本线性上升、指令遵循能力急剧退化。本文从工程实现角度，拆解短期记忆（会话窗口）、摘要记忆、向量长期记忆，以及检索与遗忘机制的完整设计链路，重点放在真实生产环境中踩过的坑与可落地的调优方案。
在动手写代码之前，必须明确记忆系统的分层模型，否则很容易把"缓存""状态""记忆"混为一谈。我习惯将 Agent 的记忆按生命周期与访问延迟划分为四层：
当单个 LLM 调用无法可靠完成复杂任务时，工程师会本能地把问题拆成多个"专家"，让它们协作。这个直觉是对的，但也是最容易翻车的地方：多 Agent 系统的失败，很少来自某个模型不够聪明，而几乎全部来自协调（orchestration）层做得不严谨。上下文如何在 Agent 之间传递？谁有权决定下一步？失败了谁能兜底？这些问题如果不显式建模，最终得到的往往不是"协作"，而是一群各自为政的 Agent 把 token 和延迟烧光后返回一份缝合怪结果。
本文不打算再复述"多 Agent 很酷"的陈词滥调，而是从工程视角拆解两个本质问题：控制流应该由图来显式表达，还是让 Agent 自主协商；以及 LangGraph 如何把状态、条件边、人机回环这三件事落到可调试、可恢复的生产代码里。
Function Calling 常被误解为"模型替你调了个函数"。实际上，LLM 从头到尾没有执行任何代码：它只负责在给定工具描述（schema）与上下文的前提下，输出一段结构化的"意图"——通常是函数名与一组参数 JSON。真正调用函数、校验参数、捕获异常、把结果回灌给模型，全部由你这一侧的编排层完成。换句话说，Function Calling 的本质是一场"结构化输出 + 编排协议"的工程，而不是模型能力本身。
这篇文章不聊"什么是 Function Calling"的科普，而是从生产落地的角度，把工具描述如何写、参数如何校验、错误如何回传、并行与嵌套调用如何设计这几件最容易翻车的事讲透。
很多团队把 RAG 理解成"把文档灌进向量库、召回 Top-K、拼进 Prompt"，结果上线后幻觉率不降反升，用户反馈"答非所问"甚至"引用编造"。RAG 是一个典型的 Garbage In, Garbage Out 系统：检索质量决定了生成质量的上限。真正决定成败的，不是模型能力，而是文档切分、混合检索、重排、引用溯源与评估这五个环节的工程细节。
本文不重复讲"什么是向量检索"，而是聚焦我在生产环境踩过的坑与最终沉淀下来的流水线设计。文中代码均为可运行的简化实现，可直接作为脚手架。
单次对话式的 LLM 本质上是一个「无状态的文本映射函数」：输入一段 prompt，输出一段 token 序列。它没有外部记忆、不能主动获取实时信息、更不会在多次调用之间自我修正。把 LLM 直接暴露给生产环境，会立刻撞上三堵墙：