这篇文章就是我这一周的学习笔记,写给和我一样的产品经理——不是要成为技术专家，但至少要知道这些东西是什么、什么时候需要、怎么组合在一起。
先说清楚：这不是银弹
在聊技术之前，先泼个冷水。
不是所有AI需求都需要Agent。不是所有知识问答都需要RAG。不是所有场景都要上MCP。
我见过太多"为了用技术而用技术"的案例。老板说要AI客服，产品经理就去找Agent方案；老板说要智能问答，产品经理就去搞RAG。结果呢？开发成本高、效果不稳定、用户体验差。
技术是为业务服务的。 先想清楚要解决什么问题，再想用什么技术。
好，下面进入正题。
一、Agent：能自己干活的AI
什么是Agent？
如果你问我，我会说：Agent就是能自己干活的AI。
传统的AI模型是被动的——你问它答，像个知识渊博但行动力为零的顾问。Agent不一样，它能：
- 理解目标：知道你要干嘛
- 拆解任务：把大目标拆成小步骤
- 调用工具：查数据、发邮件、写代码
- 执行行动：不光说，还真的去做
- 反思调整：做错了会改
举个例子。你让ChatGPT"帮我订一张明天去北京的机票"，它会告诉你怎么订、在哪订。但你让Agent做同样的事，它可能真的就去查航班、比价、下单了（当然，前提是给它足够的权限和工具）。
Agent的核心能力
Agent的运行逻辑是一个循环：感知 → 决策 → 行动 → 反馈。
感知：接收用户的输入，理解意图。不仅是文字，也可能是图片、语音、传感器数据。
决策：根据目标，判断下一步该做什么。这里涉及规划、推理、工具选择。
行动：执行具体操作。可能是调用API、查询数据库、发送通知。
反馈：根据执行结果，判断是否完成目标，是否需要调整。
这个循环会一直转，直到任务完成或者超出限制。
什么时候需要Agent？
我踩过坑。第一次做AI产品，老板说"要智能"，我就上了Agent。结果开发了一半发现：用户的需求根本不需要Agent，一个简单的API调用就够了。
适合Agent的场景：
- 任务需要多步推理
- 需要调用多个工具
- 环境动态变化，需要实时决策
- 用户意图模糊，需要主动澄清
不需要Agent的场景：
- 简单的问答（FAQ）
- 单一API调用
- 规则明确的流程
- 用户意图清晰的一次性请求
产品经理的心法：能不用Agent就别用。Agent复杂度高、成本高、稳定性差。如果你的场景一个API就能搞定，为什么要上Agent？
二、RAG：给AI装个"外挂知识库"
什么是RAG？
RAG的全称是 Retrieval-Augmented Generation，检索增强生成。
说人话：给AI装个外挂知识库。
大模型的知识有截止日期，而且不可能知道你们公司的内部文档、产品资料、客户信息。怎么办？RAG的思路是：用户提问时，先去知识库里找相关内容，把找到的内容作为"上下文"喂给大模型，让它基于这些内容回答。
RAG的工作流程
RAG的核心流程分两步：索引阶段 和 检索阶段。
索引阶段（离线）：
- 把文档切成小块（Chunking）
- 把每个小块转成向量（Embedding）
- 把向量存到向量数据库
检索阶段（在线）：
- 把用户问题转成向量
- 在向量库里找最相似的内容
- 把找到的内容和用户问题一起发给大模型
- 大模型基于这些内容生成回答
RAG的坑
我第一次做RAG的时候，效果惨不忍睹。用户问A，它答B；用户问具体问题，它给泛泛而谈。后来复盘，发现这几个坑：
切分粒度不对：切太大，噪音多；切太小，上下文不完整。没有标准答案，得根据业务场景调。
检索不准确：向量相似度不等于语义相关性。有时候词对上了，意思完全不对。
上下文太长：塞给模型的内容太多，它反而不会回答了。大模型有输入长度限制，而且内容越长，越容易"走神"。
没有答案怎么办：用户问的问题库里没有，模型会硬编一个。这个最坑，需要设计兜底逻辑。
什么时候需要RAG？
适合RAG的场景：
- 知识密集型问答（企业文档、产品手册）
- 信息时效性强（新闻、政策）
- 专属知识库（内部资料）
- 需要引用来源（学术、法律）
不需要RAG的场景：
- 通用知识问答（模型本身就会）
- 创意生成（写文案、编故事）
- 简单的逻辑推理
- 不需要事实支撑的任务
三、Skill：AI的工具箱
什么是Skill？
Agent要干活，得有工具。Skill就是AI的工具箱。
比如你想让AI帮你查天气，它得有"天气查询"这个Skill；你想让它发邮件，它得有"邮件发送"这个Skill。
Skill的本质是对能力的封装。一个Skill可能对应一个API调用、一段代码、一个工作流。
Skill与Agent的关系
Agent是"大脑"，Skill是"手"。大脑决定要做什么，手去执行具体操作。
一个Agent可以有多个Skill。比如一个客服Agent，可能有：
- 知识库查询Skill（RAG）
- 订单查询Skill（调用订单系统）
- 退款处理Skill（调用退款接口）
- 转人工Skill（触发人工介入）
Agent根据用户意图，选择调用哪个Skill。
产品视角：如何设计Skill？
粒度要合适。太粗，不够灵活；太细，管理成本高。我一般按"一个完整动作"来设计Skill。
输入输出要明确。每个Skill要清楚接收什么、返回什么。这不仅是技术问题，也是产品问题——你要想清楚这个能力的边界。
要有失败处理。Skill调用失败怎么办？重试？降级？转人工？产品经理要设计这些兜底逻辑。
监控和迭代。哪些Skill用得多？哪些失败率高？这些数据要能看到，才能持续优化。
四、MCP：AI连接世界的"插座标准"
什么是MCP？
MCP的全称是 Model Context Protocol，模型上下文协议。
说人话：AI连接外部世界的插座标准。
你可能会问：这不就是API吗？有什么区别？
区别在于：API是给程序员用的，MCP是给AI用的。
传统的API集成，需要开发人员写代码、调试、上线。每个API都不一样，集成成本高。MCP的思路是：定义一套标准格式，让AI能"插上就用"，不需要每次都重新开发。
MCP解决了什么问题？
我举个真实场景。
你想让AI帮你查Notion文档、读GitHub代码、获取Figma组件。按传统做法，你需要：
- 开发Notion集成
- 开发GitHub集成
- 开发Figma集成
- 把这些集成接到AI系统里
每个集成都要写代码、调接口、处理异常。成本高、周期长。
有了MCP，平台方只需要按照MCP标准暴露接口，AI系统就能自动识别和调用。像USB接口一样——设备厂商按USB标准做接口，电脑插上就能用，不需要每次都装驱动。
产品视角的MCP
对平台方：如果你的产品想被AI调用，可以考虑支持MCP。这是未来AI生态的"入场券"。
对AI应用方：优先使用MCP生态里的工具，能大幅降低集成成本。
现状：MCP还在早期，生态不完善。目前主要是Anthropic在推，支持的工具有限。但这个方向我看好——标准化总是好事。
五、Harness：让AI稳定干活的"脚手架"
什么是Harness？
Harness这个词在AI领域还没有标准定义，我用它来指代：让AI稳定运行的工具链和框架。
Agent、RAG、Skill、MCP，这些都是"能力"。但能力要落地，还需要"保障"。
Harness就是这套保障系统，包括：
- 监控：AI在干嘛、调了什么、花了多少钱
- 日志：每次交互的完整记录，方便排查问题
- 调试：为什么输出这个结果？哪一步出了问题？
- 评估：效果好不好？怎么量化？
- 版本管理：Prompt改了、模型换了，效果怎么变化？
- 回滚：出问题了怎么快速恢复？
为什么需要Harness？
AI产品和传统软件不一样。
传统软件，输入确定、输出确定、流程确定。AI产品，输入一样，输出可能不一样；模型版本变了，行为可能全变了。
我踩过的坑：改了一个Prompt，看似没问题，上线后发现某类用户全挂了。因为没有足够的测试覆盖，也不知道会触发什么边界情况。
Harness就是来解决这些问题的。它让AI产品从"能用"变成"好用"再到"敢用"。
产品经理要关注什么？
监控指标：响应时间、成功率、Token消耗、成本。这些要有实时大盘。
评估体系：怎么判断AI回答得好不好？自动评估还是人工抽检？评估标准是什么？
迭代机制：发现问题后怎么快速修复？Prompt调整、模型切换、Skill更新，流程是什么？
成本控制：AI很贵。一次调用可能几毛钱，一天几万次调用就是几千块。要能算清楚账。
六、整体架构：它们怎么配合？
讲了这么多概念，最后串起来。
一个完整的AI产品，技术栈大概是这样的：
用户层：用户发起请求，接收响应。
Agent层：理解意图、规划任务、协调执行。这是"大脑"。
能力层：
- RAG：提供知识支撑
- Skill：提供工具能力
- MCP：提供外部连接
模型层：大模型本身，可以是自建的，也可以是调API的。
保障层：Harness，监控、日志、评估、迭代。
产品经理的技术选型清单
最后，给产品经理一个实用清单。接到AI需求时，按这个顺序想：
第一步：真的需要AI吗？
- 能用规则解决吗？
- 能用传统软件解决吗？
- AI能带来显著价值吗？
第二步：需要什么能力？
- 需要多步推理吗？→ 考虑Agent
- 需要知识支撑吗？→ 考虑RAG
- 需要调用工具吗？→ 考虑Skill
- 需要外部集成吗？→ 考虑MCP
第三步：如何保障稳定性？
- 怎么监控？
- 怎么评估？
- 怎么迭代？
- 怎么控制成本？
第四步：投入产出划算吗？
- 开发成本多少？
- 运行成本多少？
- 能解决多少问题？
- ROI是多少？
写在最后
这篇文章写完，我发现自己对AI技术的理解深了很多。
不是为了成为技术专家，而是为了做好产品决策。产品经理不需要会写代码，但要知道什么能做、什么难做、什么值得做。
技术日新月异，今天聊的Agent、RAG、MCP，可能明年就过时了。但背后的思维方式不会变：从问题出发，选择合适的工具，用工程化的方法落地。
