AI代理与自动化：RAG、工作流与实战指南

你基于 OpenAI 把应用搭好，后来想试 Claude、比一比 Gemini——却因为每家提供商的 SDK、格式、错误处理各不相同而白白耗掉数小时。LLM 网关（AI 网关 / LLM 代理）是你塞在应用与各提供商之间的中转层：它对外暴露一个兼容 OpenAI 的 API 以触达所有模型，并接管那些横切性的杂活——回退、成本追踪、虚拟密钥、缓存、限流与可观测性。本指南讲清为什么需要它、网关到底是什么、三种类型（自托管代理 = LiteLLM / 托管 = OpenRouter / SDK = Vercel AI SDK）、如何在 LiteLLM、OpenRouter 和 Vercel AI SDK 之间取舍、只需换端点的最小配置代码，以及它的局限——一跳延迟、网关成为新的故障点、费用（OpenRouter 充值时收 5.5%）、功能损失与隐私。

当你构建完一个 AI 智能体后，总会撞上同一堵墙：“好了，但它真的能用吗？”用来凭数据而非凭感觉判断提示词或模型改动是变好还是变差的机制，就是 Evals。LLM 对同一个输入每次都可能产出不同的结果，所以精确匹配的单元测试并不契合。本文以实际动手搭建并跑通的步骤为主线，讲清衡量质量的五种方法（① 标准答案匹配 ② 基于规则的检查 ③ LLM-as-judge ④ 回归测试 ⑤ 生产环境监控）、面向智能体的专属评估（任务成功率、工具调用是否正确、执行轨迹、成本）、如何从 20 个失败样例开始从小做起、常见陷阱，以及主要工具（Anthropic Console/Evals、OpenAI Evals、LangSmith、Langfuse、Ragas）——写给实践者。

关于自动化的老问题：“用 AI 智能体还是 RPA？”答案不是二选一——按角色分工，而 2026 年的制胜模式是两者的混合。RPA 是确定性的“手”，快速精准地执行既定流程（但屏幕/规格一变就失灵）；AI 智能体是概率性的“脑”，解读情境并做判断（擅长应对模糊与例外，但并非每次都一样）。本文讲解工作原理的差异、对比表（可复现性与适应力的取舍）、如何选择（标准是“能否用规则完整写出来？”——能→RPA，写不全的判断→AI 智能体）、2026 年趋势（RPA 大厂 UiPath、Automation Anywhere、Blue Prism 纷纷智能体化——走向融合；问题不再是“选哪个”而是“把判断放在哪里”=编排优先），以及实战答案：混合方案，由脑（AI 智能体）负责判断/编排、手（RPA）执行确定性任务——不要在需要确定性的地方放智能体，委派判断时务必配套护栏与人工审批。基于各厂商官方信息，附常见问题。

能把 AWS 运维交给 AI 吗？2026 年你已经可以大量委派。AWS 自己推出了 Amazon Q Developer 和 Agent Toolkit for AWS（2026 年 5 月——40+ 个 agent skills + 托管的 AWS MCP Server + 插件），让 AI 从 IaC 生成延伸到资源操作。本文把“委派”拆成三个层级（① 代码/IaC 生成、② 以读取为主的运维/排查、③ 真正操作 AWS 的自主智能体），介绍主要工具（Amazon Q Developer、Agent Toolkit、AWS MCP Server、Terraform MCP、Bedrock AgentCore）——包括把 AWS CLI 交给 Claude Code 或 Codex、从 shell 运行“aws”的自带方案——讲清优点（IaC 更快、自动化定位、成本优化建议、知识民主化），再进入真正的重点即缺点（IAM 权限膨胀、过度授权成为失误/提示注入的爆炸半径放大器、比任务活得更久的权限、成本失控——并有 2025-26 年真实的生产 DB 删除事故），均基于 AWS 官方与安全厂商信息。关键转折在于：问题不是“能不能”，而是“如何委派才不会失控或账单爆炸”——而 AWS 自己把 IAM 护栏、CloudTrail 审计和沙箱内置进 Agent Toolkit，正勾勒出答案的形态。文末给出五条原则（IAM 最小权限、破坏性操作的人工审批、可观测性、JIT 短时效凭证、沙箱）及 FAQ。

把 AI 智能体接入实际工作时，第一道坎就是“到底用哪个框架来搭建”。本文站在开发者与技术选型者的视角，从编排方式（有向图/基于角色的 crew/对话型 GroupChat/交接/层级树/自主工具循环）、语言、学习曲线、可控性、生产成熟度、token 成本与适配用途，比较六大主流框架——LangGraph、CrewAI、AutoGen（已并入 2026 年 4 月 GA 的 Microsoft Agent Framework）、OpenAI Agents SDK、Google ADK 与 Claude Agent SDK。关键提醒：那个“最好试作”的框架（CrewAI）在生产环境里可能最贵——token 约为 3 倍（某基准测试中为 41k，而 LangGraph 为 18.5k），且非确定性，因此不适合金融与医疗。文中还说明 2026 年如何通过 MCP（工具）与 A2A（智能体之间）实现互操作，使不同框架的智能体如今能够协同工作、厂商锁定随之淡化。附带按用途的选型指南与 FAQ。

在《如何搭建多智能体系统》中我们说过，增加智能体前先为每次交接装上度量；支撑这种度量的技术正是 AI 可观测性。它让你看清 LLM 与智能体在生产环境中究竟在做什么，从而能回溯到原因。与普通应用监控的决定性区别在于：AI 可以返回 200 OK、50ms 却仍自信地产生幻觉，所以多数 AI 故障是质量故障而非基础设施故障。可观测性基于三大支柱：trace、metrics 与 logs。可观测性展示“发生了什么”，评估（evals）则衡量答案好不好，两者需成套使用。本文梳理关键指标与 LangSmith、Langfuse、Arize Phoenix、MLflow、AgentOps、OpenTelemetry 等主要工具，并讲解如何起步以及为何对智能体至关重要。

在掌握“什么是多智能体系统？”的概念之后，这是动手实践的续篇。以 2026 年事实上的标准——主管模式为题材，带初学者走完 5 步构建流程。核心原则：先用单一智能体构建，撞到瓶颈后再以最小配置增加（约 80% 的用途用一个就够；对简单的直线式流程使用多智能体会让成本膨胀 3-10x，据 Google 研究在顺序型任务上精度还会下降 -39-70%）。应转向多智能体的 3 个信号：专业性分离、并行性、判断分离。主管接收整体任务、分解、委派给专业工作者并汇总结果——Claude Code 子智能体、LangGraph Supervisor 与 OpenAI Agents SDK 的交接都收敛到了这一形态，因为它框架支持最广、失败模式已知、易于审计。5 步：①事先清晰分解；②定义工作者，一个角色+工具+输出格式（最多 3-5 个）；③设计主管，明确列出可调用名称（硬上限）并在此花最多时间；④确定交接与上下文共享，只传必要信息（标准是 A2A）；⑤增加前测量每次交接，给迭代/token/成本设上限，准备好 evals 与护栏。伪代码展示工作者定义、硬上限主管与带迭代上限的运行循环。共通教训：比起框架，提示词、工具设计与评估框架更能决定成败。小步构建、测量、只在划算时增加。图表引用自公开资料与研究，视条件而定。

AI 智能体已日益普及，下一个挑战是如何让智能体彼此协作。如果说 MCP 把智能体连接到工具，那么 A2A（Agent2Agent）就是把智能体连接到另一个智能体 —— 一套开放标准，让基于不同厂商和框架构建的 AI 通过共同约定相互发现、通信与协作。Google 于 2025 年 4 月发布，同年 6 月将其捐赠给 Linux Foundation，到 2026 年达到 v1.0。这篇初学者指南涵盖：A2A 是什么（用“企业间业务合作的礼仪”作比喻）、为什么需要它（各有专长的智能体接力工作 —— 规划智能体到酒店预订智能体再到支付智能体）、它与 MCP 有何不同（MCP 是纵向，智能体 ↔ 工具；A2A 是横向，智能体 ↔ 智能体；把两者叠加是标准的双层结构）、它如何运作（通过 Agent Card —— 位于 /.well-known/agent-card.json 的 JSON“名片”—— 来发现能力，然后用 Task 携带请求经过 working、input-required、completed 等状态，并以 Artifact 返回结果，全部基于 HTTP、Server-Sent Events 和 JSON-RPC 2.0，且智能体保持内部细节隐藏），以及现状与落地实现（截至 2026 年 4 月，150+ 家组织在生产环境使用，22,000+ GitHub stars，提供五种语言的 SDK —— Python、JavaScript、Java、Go、.NET —— Microsoft、Salesforce、SAP、ServiceNow 均有参与）。口诀：连接工具 = MCP，连接同伴 = A2A。

你搭好了 RAG，但检索质量却平平——这正是重排序能派上用场的时候。重排序把嵌入（向量）检索粗略收集到的候选，按它们与查询的相关度重新打分并重新排序，只保留最前面的那些；仅这一步就能大幅改变 RAG 系统的回答质量。本初学者指南讲解重排序是什么（以“初筛加终面”作比），为什么需要它（嵌入检索把查询和文档分开向量化，因此只能粗略判断相关度，而糟糕的排序会直接拉低回答质量——研究报告称加入重排序约带来 40% 的 RAG 准确率提升，把它叠加到混合检索上已是 2026 年的标准做法），两阶段检索如何运作（先用快速嵌入检索“广撒网”求召回，再用重排序器“智能筛”求精度，然后把最前面的交给 LLM），为什么重排序器更准确（bi-encoder 把查询和文档各自向量化，快但近似；cross-encoder 把两者一起喂入并输出 0–1 的相关度分数，准确但开销大——所以用快速的 bi-encoder 收集，用准确的 cross-encoder 筛选），以及模型与实现（API 型如 Cohere Rerank、Voyage、Jina；开源型如 BGE reranker、mixedbread、FlashRank；以及基于 LLM 的打分如 RankLLM——只需检索 50–100 个再筛到前 5 个）。原则就是：广撒网、智能筛，并用 AI 评测来调整数量。

当你能够构建 AI 应用之后，下一阶段就是安全地运行它们。LLM 可能被恶意输入欺骗、泄露机密数据，或一本正经地胡说八道；防止这一切的安全机制就是 AI 护栏。随着 AI 智能体事故在 2026 年真实发生，护栏已成为生产环境运行不可或缺的一部分。护栏是拦住危险输入和不希望出现的输出的规则与过滤器，在用户输入到达 LLM 之前、以及回答返回之前都进行检查——这是独立于模型自身之外的安全层。主要威胁包括提示注入（最大的威胁）、越狱、数据泄露（机密数据、PII、系统提示），以及幻觉或有害输出。防护在两层进行：输入护栏（检测注入和越狱、检测/屏蔽 PII、限制话题、净化）与输出护栏（过滤有害内容、防止泄露、检查幻觉、验证格式）。提示注入在 OWASP LLM Top 10 中被列为最严重的一项，分为直接（用户输入“忽略之前的所有指令”）和间接（命令藏在网页或 RAG 文档中）两种形式；间接注入仅靠 RAG 挡不住，因此检索到的文档需要单独检查。本初学者指南还介绍了工具（LLM Guard、Guardrails AI、NeMo Guardrails、Llama Guard，以及 Azure、AWS、OpenAI 的云端安全功能），以及纵深防御、最小权限、人工审批和持续监控等实践原则。

RAG、语义搜索和推荐系统，背后都靠一个无名功臣：嵌入（向量）。嵌入就是把文本（或图像）的意义转换成一串数字，即向量。“狗”这个词会变成数百到数千个数字组成的列表，充当“意义的坐标”，于是意义接近的词语彼此靠近（“狗”和“小狗”很近，“狗”和“汽车”很远），其接近度可用余弦相似度等指标量化。著名的例子是“国王 − 男人 + 女人 ≈ 女王”。正因如此，即使字面不一致，机器也能判断意义是否接近。本入门指南讲解什么是嵌入（一张“意义的地图”）、为什么接近度能衡量意义（维度与余弦相似度）、能用来做什么（RAG、语义搜索、分类与去重、推荐及多模态）、如何选择嵌入模型（API 型如 OpenAI text-embedding-3、Cohere、Gemini、Voyage；开源型如 BGE-M3、Nomic、Qwen3；以及 Matryoshka，可把 3,072 维降到 1,024 维，仍保留约 95% 质量而成本约为三分之一），以及向量数据库（Pinecone、Weaviate、Qdrant、Chroma、pgvector）和三步上手法（选模型、把文档向量化并存储、把问题向量化并检索）。嵌入是实现 RAG 的根基。

你打磨了提示词，用 RAG 补充了知识，或许还做了微调——那么如何确认它真的变好了？这时 AI evals 登场，到了 2026 年，评估已不可或缺，人们甚至称它为“基础设施”。AI evals 就是系统化地衡量 LLM 输出的质量（准确性、幻觉、格式遵循、语气），用固定的尺子而非凭感觉来打分；没有它，改进就只是直觉。评估有两种方法：可机械衡量的项目用代码评估（完全匹配、格式、必需词/禁用词——快、便宜、稳定），主观项目用 LLM-as-judge（用强大的 LLM 当裁判，通过成对比较或单输出评分给输出打分）。原则是：凡是代码能衡量的就用代码衡量。LLM-as-judge 有冗长、位置和自我偏好三种偏见；应对方法是用不同系列的模型当评分者、交换顺序打两次分、把简洁性写进评分量规，以及用人工判断来校准。粗粒度刻度（pass/fail 或 1–3）优于细粒度的 1–10。实践中要跑三个层级——每次改动的即时代码检查、每晚的 LLM-as-judge 回归测试，以及持续的生产监控——CI 可用 DeepEval、Promptfoo、RAGAS，监控可用 Braintrust、LangSmith、Arize。先从收集 10 个好输出和 10 个坏输出并给它们打分开始。