02 业务Agent需要的四层能力：从技术栈到运营体系

这是专栏系列的第二篇。第一篇讲了Agent系统怎么建，这篇讲需要掌握什么能力。
这篇文章的目标：帮你搞清楚从Demo到生产，思考的事情有什么变化，讲一讲”在生产环境里你到底要干什么”。

目录

1. 一个常见的误区
2. 先从招聘市场来看
3. 第一层：技术能力：从”能回答”到”能回答对”

• 评测：证明Agent回答对了
• Prompt：决定Agent输出质量
• RAG：让Agent有据可依
• Agent编排：处理复杂任务
• 其他技术：按需学习

第二层：设计能力：从”一个人用”到”一群人用”

• 语义层：指标口径不统一怎么办
• 意图消歧：用户问的不清楚怎么办
• 结果可信度：凭什么信Agent的回答
• 人机协作：什么时候需要人工介入
• Workflow vs Agent：流程确定用哪个

第三层：工程化能力：从”能跑”到”稳定跑”

• 成本：token费用怎么控
• 监控：出了问题怎么定位
• 错误处理：工具调用失败怎么办
• 上下文管理：对话太长Agent”变笨”怎么办

第四层：持续运营能力：从”上线”到”越用越好”

• 评测体系：生产级
• A/B测试：改了Prompt效果变好还是变差
• 用户反馈：怎么收集和处理
• 知识沉淀：历史结论怎么复用

总结

一个常见的误区

很多人学Agent的第一步是学框架：LangChain怎么用、CrewAI怎么搭、Dify怎么拖。

说实话，我一开始也这么想。

框架是工具，不是能力。你会用LangChain，不代表你能搭建生产级Agent。就像你会用IDE，不代表你能写出好代码。

真正决定你能不能做出生产级Agent的，是四层能力：技术能力、设计能力、工程化能力、持续运营能力。

先从招聘市场来看

用Hermes Agent采集了82份AI Agent岗位的JD，从技术词频统计来看：

评测排第一不意外。企业最缺的不是”会做Agent”的人，而是”能证明Agent有效”的人。Prompt和RAG紧随其后，这两块是Agent的基本功。

但岗位需求只是冰山一角。真正做生产级Agent，需要的能力远不止这些，比如性能、稳定、大数据量等等，这里我们聚焦agent部分。我把这些能力分为四层，每层对应一个核心问题。

第一层：技术能力：从”能回答”到”能回答对”

做Demo时，你想的是”怎么让Agent回答”。做生产时，你想的是”怎么让Agent回答对”。

这两个问题看起来只差一个字，但背后需要的技术完全不同。Demo阶段用一个Prompt+一个LLM就能跑，生产阶段要用评测来证明回答对了、RAG来保证回答有依据、编排来处理复杂任务。

这层有四个核心技术，是绕不开的。

评测：证明Agent回答对了

评测是Agent系统的”测试”。没有评测的Agent系统，就像没有测试的代码，你不知道它什么时候会出问题。

很多人觉得评测不重要，上线前跑一下Demo觉得效果还行就发布了。但生产环境需要的是：自动化评测、回归测试、评测集管理。这也是为什么评测在岗位需求中排第一（89次出现）。

评测的核心是用数据说话，不是”感觉还行”。LLM-as-Judge是目前最主流的评测方式：用大模型自动评分，成本低、可规模化，但有局限性：模型有偏见、存在自评偏好（详见Zheng et al., 2023, “Judging LLM-as-a-Judge”）。

RAG系统有四个核心指标（来自RAGAS框架）：忠实度（回答是否基于检索文档）、答案相关性（回答是否切题）、上下文精度（检索结果是否相关）、上下文召回（是否检索到所有相关信息）。RAGAS是一个开源的RAG评测框架，提供了标准化的指标定义和计算方式。

评测集构建是最容易被忽视的。尽量别自己造评测集，从生产环境采样。真实用户的问法和你想象的不一样。评测集写的是”公司的报销政策是什么？”，真实用户问的是”出差打车能报吗？”。

怎么上手：用DeepEval写3道评测题（输入问题→检查输出是否包含关键词），跑一遍看结果，逐步扩展到10道覆盖正常/边界/异常场景。

学习资源：DeepEval Quickstart（写第一道评测用例）、RAGAS文档（RAG评测四指标）、Judging LLM-as-a-Judge（理解LLM评LLM的局限性）

Prompt：决定Agent输出质量

Prompt是Agent系统的核心接口。所有工具调用、任务规划、结果生成都依赖Prompt。Prompt写得好不好，直接决定Agent的输出质量。

而且Prompt是可以快速迭代的。改Prompt比改模型成本低得多，效果提升却可能很明显。这也是为什么Prompt Engineering在岗位需求中排第二（47次出现）。

在Agent开发中，Prompt不只是”写一句好的提示词”。它涉及几个方面：设计System Prompt来定义Agent的角色和约束，写工具调用Prompt告诉Agent有哪些工具可用，控制输出格式让Agent返回结构化的JSON，以及防注入防止用户通过输入控制Agent行为。

Prompt模式有几种常用套路：Few-shot（给几个例子让模型学会格式）、CoT（让模型一步步推理）、ReAct（让模型先想再做，做完再想）。System Prompt设计是关键，要定义Agent是谁、能做什么、不能做什么、输出什么格式。

防注入基础策略：用户输入中可能包含”忽略之前的指令”之类的恶意指令。基础防护：①输入过滤，检测常见注入模式（如”忽略指令”“系统提示”等关键词）；②角色隔离，System Prompt和用户输入用明确的分隔符区分；③输出校验，检查Agent是否泄露了System Prompt内容。这些不是万能的，但能挡住大部分低级攻击。

怎么上手：写一个System Prompt（角色定义+能力范围+输出格式+禁止事项），用Few-shot给3个输入输出示例，测试10个真实用户问题，根据bad case迭代。

学习资源：OpenAI Prompt Engineering Guide（基础模式）、Anthropic Prompt Engineering（Claude系技巧）

RAG：让Agent有据可依

RAG（检索增强生成）是Agent获取外部知识的主要方式。没有RAG，Agent只能靠训练数据回答问题，容易产生幻觉。有了RAG，Agent可以基于真实文档回答，准确性大幅提升。

以我实际做的政务类系统为例，RAG的完整链路是：

用户提问 → 查询增强（LLM改写） → 语料路由（决定搜哪些库） → 多路并行召回（全文检索 + 向量检索 + 表格检索） → RRF排名融合 → Rerank重排序 → 证据组装 → LLM生成回答

关键设计决策有三个：

混合检索：纯向量不够（政策标题、地名需要精确匹配），纯全文也不够（用户说法和文档用词不一致），所以两路都走，RRF融合。RRF（Reciprocal Rank Fusion，倒数排名融合）是一种多路检索结果的合并算法，公式是score = Σ 1/(k + rank)，k=60，直觉是”多路都靠前的文档胜出”。如果一个文档在全文检索和向量检索中都排在前几名，它大概率就是最相关的。

Rerank重排序：在初步检索结果出来后，用一个专门的模型（如BGE-Reranker）对结果重新打分排序。初步检索用的是粗粒度的相似度匹配，Rerank用的是细粒度的语义理解，能把真正相关的文档提到前面来。代价是多了一次模型调用，延迟增加几百毫秒。

显式档位：在我做的系统里分三档。fast跳过查询增强和rerank，1-2秒；standard开embedding rerank，2-3秒；deep开LLM rerank，5-10秒。根据场景选档位，不是所有问题都需要deep。

语料路由：不同场景搜不同库，避免混库干扰。比如申报助手只搜政策库，课堂学习搜政策+案例库。

RAG的核心流程是：文档解析→分块→向量化→检索→生成。

分块策略决定了检索质量。固定长度分块简单但可能切断语义，语义分块按段落标题分割，Parent-Child分块小块检索大块返回。

怎么上手：用LangChain的RAG Tutorial跑通最简单的流程（文档加载→分块→向量化→检索→生成），加上BM25关键词检索实现混合检索，用RRF融合两路结果，测试5个真实问题看检索质量。

学习资源：LangChain RAG Tutorial（完整流程）、苏剑林的博客（RRF融合的数学原理）

Agent编排：处理复杂任务

单Agent只能处理简单任务。一旦任务涉及多步骤、多工具、多数据源，就需要编排。

编排模式有三种常用套路。ReAct是边想边做（Reasoning + Acting交替），适合通用Agent。Plan-and-Execute是先规划再执行，适合复杂任务，通常比ReAct更省token（因为规划阶段减少了无效的工具调用）。Reflection是做完再检查，双Agent对话迭代，适合高质量输出。

LangGraph是目前最主流的Agent编排框架，基于状态图。用节点定义执行步骤，用边定义流转关系，用条件分支处理不同情况。它还支持人机协作，关键节点可以暂停等人工确认。

工具调用是Agent的核心能力。Function Calling让LLM能告诉外部程序”我想调用某个函数，参数是这些”。具体流程：定义工具的参数和描述，解析LLM返回的函数名和参数，调用外部API执行，把结果返回给LLM。

怎么上手：用LangGraph写一个2节点的Agent（输入→LLM思考→工具调用→输出），加一个条件分支（如果工具调用失败，重试或降级），加一个人机协作节点（关键操作暂停等确认）。

学习资源：LangGraph Quickstart（状态图编排）、LangGraph Tutorials（ReAct、Plan-and-Execute、Reflection三种模式）、CrewAI Quickstart（多Agent协作）

其他技术：按需学习

除了上面四个核心技术，还有几个技术点可能会遇到。这些不需要一开始就学，遇到问题再学。

MCP协议：Model Context Protocol，统一的工具调用标准。当Agent需要接入多个外部工具（数据库、API、文件系统）时，MCP提供了一套标准协议，避免为每个工具写适配代码。MCP官方规范

记忆系统：跨会话记忆。用户上次对话提到的信息，下次对话还能用。LangGraph的Memory模块支持短期记忆（当前会话）和长期记忆（跨会话持久化）。LangGraph Memory

可观测性：调试Agent行为。当Agent做出错误决策时，需要能看到完整的执行链路：调了哪些工具、每一步的输入输出、LLM的推理过程。Langfuse提供了trace、span、evaluation的完整链路。Langfuse

语义缓存：相似问题命中缓存，避免重复调用LLM。传统缓存是精确匹配（完全相同的输入才命中），语义缓存是语义匹配（”报销政策是什么”和”公司的报销规定”会命中同一条缓存）。用向量相似度判断两条问题是否语义相同。GPTCache

模型选型与路由：当系统需要接入多个模型（便宜的、贵的、擅长不同任务的）时，用LiteLLM统一API接口，根据任务复杂度自动路由到合适的模型。LiteLLM

第二层：设计能力：从”一个人用”到”一群人用”

做Demo时，你一个人测试，问什么答什么。做生产时，1000个用户同时提问，每个人问法不同、需求不同、期望不同。

这时候会发现：技术问题好解决，设计问题才难。比如”上个月的销售额怎么样”，这句话至少有5种理解：要趋势？要同比？要分区域？要异常检测？要排名？GPT-4o也猜不到用户到底要什么。

这层有四个设计问题，是上线前值得花时间想清楚的。

语义层：指标口径不统一怎么办

Agent需要理解业务指标的含义。”活跃用户”在不同业务线定义不同：电商是”30天内有下单”，内容平台是”7天内有登录”，SaaS是”本月有核心操作”。这不是写个Prompt就能解决的，需要构建一套独立的语义层系统。

语义层的难点在”怎么定义”。要和业务方对齐每个指标的计算逻辑、数据来源、更新频率。一个指标可能有3种口径，决定用哪种，然后在系统里固化下来。

生产中的典型场景：用户问”上个月的销售额”，要先确认是下单口径还是支付口径，含不含退货；用户问”华东区的业绩”，要先确认华东区包含哪些省，是按发货地还是收货地。

怎么上手：先建一张指标口径表（指标名、计算逻辑、数据来源、口径说明），和业务方对齐后再考虑自动化。

学习资源：dbt Metrics（指标定义的标准方式）

意图消歧：用户问的不清楚怎么办

用户说不清楚时，有几个选择：不追问，用最常见的理解；给用户2-3个选项让用户选择；先给一个粗略回答，再追问细化；根据历史对话推断用户意图。

消歧策略直接影响用户体验。追问太多，用户烦；追问太少，答非所问。关键是在”追问次数”和”答对概率”之间找平衡。

怎么上手：先实现”默认理解”（不追问，用最常见的理解），再根据bad case逐步加追问。观察ChatGPT和Claude怎么处理模糊问题，学习它们的追问策略。

结果可信度：凭什么信Agent的回答

Agent查出来一个数字：”上月销售额1.2亿”。业务人员凭什么信？不是返回一个数字就行的。需要追溯：数据从哪来？经过什么处理？统计时间是什么？

可信度的实现，要设计一套完整的追溯链路。大多数业务场景需要返回数据来源和时间范围；金融、医疗等高风险场景还需要返回查询逻辑和数据质量评估。

怎么上手：先实现”数据来源+时间范围”（最基础的可信度），再根据业务需求加查询逻辑和置信度标注。

学习资源：LangChain Retrieval QA with Sources（在回答中附带来源）

人机协作：什么时候需要人工介入

Agent不是完全自主的。关键节点需要人工介入：Agent不确定时暂停等确认，关键操作需要人工审批，人工反馈怎么影响Agent行为。

人机协作的难点在于”什么时候暂停”。暂停太多，效率低；暂停太少，风险高。要设计一套规则，定义哪些操作需要人工确认。

高风险操作（退款、删除、修改）用确认模式：Agent执行前暂停，等用户确认。跨部门操作（提交报告、发送邮件）用审批模式：Agent执行后暂停，等审批人确认。低风险但需要监督的操作用旁路模式：Agent执行，同时通知人工，人工可以随时中断。

怎么上手：先实现”确认模式”（高风险操作暂停），再根据业务需求扩展。

学习资源：LangGraph Human-in-the-Loop（怎么实现暂停和确认）

Workflow vs Agent：流程确定用哪个

大多数生产场景，流程是确定的，用Workflow比用Agent更合适。Agent是LLM自主决策，灵活但不可控；Workflow是预定义流程，可控但不灵活。

判断标准：流程固定用Workflow，流程不确定用Agent；错误容忍度低用Workflow，错误容忍度高用Agent；输入格式固定用Workflow，输入是自然语言用Agent。

大多数生产系统是Workflow+Agent混合：主流程用Workflow（确定性高、可控），子任务用Agent（需要灵活决策）。比如数据分析系统：数据查询用Workflow（SQL固定），报告生成用Agent（需要理解用户意图）。

怎么上手：先用Workflow跑通主流程，再在需要灵活决策的环节引入Agent。

学习资源：Prefect或Airflow（Workflow编排）、LangGraph（Agent编排）

第三层：工程化能力：从”能跑”到”稳定跑”

做Demo时，跑通了就成功了。做生产时，还要考虑：token成本怎么控？出了问题怎么定位？对话太长怎么处理？

这层的能力往往被低估，但上线后最先遇到的问题都在这层。关于Prompt注入和防攻击，第一层的Prompt部分已经讲了基本防护策略，这里聚焦工程化落地的其他关键问题。

成本：token费用怎么控

Agent的token消耗比传统系统高很多。一个复杂任务可能调用5-10次LLM，每次消耗几千token。不控制的话，一个月的token费用可能比服务器还贵。

成本控制的主要策略是多模型路由：简单任务用便宜模型，复杂任务用贵模型，平均成本可以降到1/5到1/10。配合语义缓存（相似问题命中缓存，避免重复调LLM）和Prompt压缩（减少不必要的上下文），成本还能进一步降低。

怎么上手：先建一张成本监控表（每次调用记录模型、token数、耗时、成本），再根据数据优化（通常是LLM调用占比最大）。

学习资源：LiteLLM（统一API网关和成本追踪）、GPTCache（语义缓存）

监控：出了问题怎么定位

Agent系统比传统系统更难监控。传统系统同样的输入走同样的代码路径，Agent系统不一样，LLM可能做出你预期之外的决定。

监控要做三件事：结构化日志（JSON格式，包含trace_id、step_name、input、output、duration）、链路追踪（每个Agent调用生成trace_id，记录完整的执行链路）、指标监控（成功率、响应时间、token消耗、工具调用成功率）。

怎么上手：用Langfuse接入Agent监控（trace、span、evaluation），测试一个完整请求看trace是否清晰，设置关键指标告警（成功率下降、响应时间超限）。

学习资源：Langfuse（Agent监控）、OpenTelemetry（通用trace标准）

错误处理：工具调用失败怎么办

Agent系统比传统系统更容易出错。LLM输出不确定，工具调用可能失败，多步执行中一步错步步错。

错误处理有四种机制：重试机制（工具调用失败时自动重试，用指数退避）、降级策略（主模型挂了切备用模型）、兜底方案（Agent不知道怎么回答时转人工）、超时控制（单步超时和总执行时间都设上限）。

怎么上手：先实现重试+降级，再根据业务需求加兜底方案。

学习资源：LangChain Retry Output Parser（输出重试）、LiteLLM Fallbacks（模型降级）

上下文管理：对话太长Agent”变笨”怎么办

Agent的对话历史是累积的，不管理会越来越脏。用户第一轮问的是”A产品”，第五轮问的是”B产品”，但上下文里”A产品”的信息还在，Agent被旧信息干扰，回答就偏了。用户不会说”你的上下文脏了”，只会说”感觉Agent变笨了”。

上下文管理有四种策略：滑动窗口（只保留最近N轮对话）、上下文压缩（用LLM把旧对话总结成短摘要）、话题检测（用户换了话题时清空旧上下文）、关键信息提取（从旧对话中提取关键信息，结构化存储到长期记忆）。

怎么上手：先用滑动窗口兜底（只保留最近5轮对话），测试长对话场景看是否出现”上下文污染”，按需加摘要压缩或话题检测。

学习资源：LangChain Summarization Middleware（自动摘要压缩）、LLMLingua（小模型压缩prompt）

第四层：持续运营能力：从”上线”到”越用越好”

做Demo时，上线就是终点。做生产时，上线才是起点。改了Prompt效果变差怎么办？用户投诉怎么收集？历史分析结论怎么复用？

这层的能力决定了Agent是”越用越好”还是”越用越差”。

评测体系：生产级

第一层的评测是”上线前能不能发布”，这里的评测是”上线后怎么持续监控”。

生产级评测要做四件事：自动化评测（每次发版自动跑评测，不需要人工介入）、回归测试（确保新版本没有退化，改了Prompt或模型后效果没有变差）、评测集管理（从生产环境采样构建评测集，定期更新，收集bad case）、评测Dashboard（可视化评测结果，让团队能看到Agent的质量趋势）。

怎么上手：建一个评测集（10道题覆盖正常/边界/异常场景），接入CI/CD（每次发版自动跑评测集），建一个Dashboard（可视化评测结果）。

学习资源：DeepEval CI/CD集成（GitHub Actions中跑评测）、Langfuse Analytics（可视化评测结果）

A/B测试：改了Prompt效果变好还是变差

改了Prompt或模型，怎么知道效果变好还是变差？A/B测试让新旧版本同时运行，对比关键指标。

核心是流量分配和指标对比：把用户分成两组，一组用旧版本，一组用新版本，对比任务完成率、响应时间、用户满意度等指标。判断差异是否显著，不能只看平均值，要看置信区间。灰度发布是最佳实践，先小流量验证，确认没问题再全量。

怎么上手：先实现简单的流量分配（用随机数决定用户用哪个版本）+指标收集（记录每个版本的任务完成率、响应时间），再根据需求加显著性检验。

学习资源：Statsig或LaunchDarkly（A/B测试平台）

用户反馈：怎么收集和处理

用户反馈是Agent优化的最重要来源。用户说”Agent回答不对”，要知道哪里不对、怎么改。

反馈收集有三种方式：显式反馈（点赞/点踩、文字反馈，直接记录人工分析）、隐式反馈（用户是否采纳建议、是否重新提问，自动收集统计分析）、业务反馈（业务方投诉、运营报告，定期review优先处理）。

怎么上手：先实现点赞/点踩（在回答下方加反馈按钮），再实现反馈记录（记录用户ID、问题、回答、反馈类型），最后实现Bad Case管理（定期review负面反馈，归类问题，优化Prompt/模型）。

学习资源：Langfuse User Feedback（收集和分析用户反馈）

知识沉淀：历史结论怎么复用

Agent分析一次数据，发现”Q3下降是因为华东区渠道调整”。这个知识下次遇到同类问题能不能复用？

知识沉淀要做四件事：知识结构化（把分析结论转成结构化数据，不是存原始对话）、知识检索（遇到类似问题时先检索历史结论，避免重复分析）、知识更新（新知识覆盖旧知识，保持知识的时效性）、知识关联（不同知识点之间的关系，形成知识图谱）。

怎么上手：先实现分析结论存储（把Agent的分析结论存成结构化数据），再实现知识检索（遇到类似问题时先检索历史结论），最后实现知识更新（新结论覆盖旧结论）。

学习资源：Mem0（构建知识图谱）

总结

这篇文章讲了四层能力，但真正的落点只有一个：Agent重构业务不是效率提升，是流程消灭。

很多人把Agent理解成”一个能回答问题的机器人”，然后堆功能、加工具、调Prompt。但生产级Agent的目标完全不同。它要替用户走完整个流程，从提问到拿到结果，中间的数据查询、逻辑判断、结果组装全部自动化。

四层能力是围绕这个目标展开的：

一个容易忽略的点：这四层之间有依赖关系。没有评测（第一层），A/B测试（第四层）无从谈起；没有可观测性（第三层），bad case定位就是大海捞针；没有语义层（第二层），RAG召回的内容可能答非所问。建议按顺序推进，每一层打扎实再进下一层。欢迎评论区交流。

关键词：Agent技术栈、生产级Agent、四层能力模型、Agent评测、RAG工程、Prompt Engineering、Agent编排、LangGraph、RAGAS、LLM-as-Judge、Agent工程化、Agent运营体系