AI基础概念扫盲:从会聊天到会办事,一图串起大模型、RAG、Skills、MCP 与 Agent

你让 AI 写三条会员召回文案，它一分钟就能交稿。

但如果你把任务换成：

这时，单纯会聊天的 AI 很快就会露馅。

它可能写出一份很像样的分析，却没有真正读取会员后台。

也可能言之凿凿地说"用户是因为权益吸引力不足而流失"，但这只是一个合理猜测。

它甚至可能告诉你"任务已经完成"，实际上并没有创建人群包，更没有进入发送系统。

为什么同样叫 AI，有的只能写几句话，有的却能查资料、读数据、调用系统，甚至连续推进一项工作？

差别不只是模型聪不聪明。

更大的差别在于：模型外面有没有接上正确的任务、资料、方法、工具、流程、反馈和安全边界。

这也是很多 AI 扫盲文章最容易让人困惑的地方。

它们会分别解释 LLM、Prompt、RAG、Memory、Skills、MCP、Workflow 和 Agent。每个词单独看，好像都懂；把文章关掉以后，却仍然不知道它们是什么关系，更不知道自己的业务到底需要哪一个。

所以，这篇文章不准备带你背一串英语缩写。

我们只做一件事：跟着"召回 30 天未活跃会员"这项运营任务，从头到尾走一遍。

接下来，我们只追问四件事：

• AI 怎样知道今天要做什么？
• 它怎样拿到公司的真实资料和成熟方法？
• 它怎样从"提出建议"走到"真的执行"？
• 当它可以自己推进任务时，谁来限制权限和风险？

每遇到一个具体问题，我们再认识一个必要概念。

走完整个任务，你会发现：

现在，先不钻进任何一个名词。先把整张地图摊开。

可以把一套业务 AI 系统拆成五类职责。它们不是先后五步，更像一支围绕同一目标协作的临时项目组。

第一类：任务职责

回答的是：

这里包括业务目标、Prompt、成功标准和失败边界。

第二类：思考职责

回答的是：

这里的核心是大语言模型，也就是 LLM。

第三类：能力职责

回答的是：

这里又分为几种互不替代的能力：

• Skills 提供成熟方法；
• Knowledge、RAG 提供当前证据；
• Memory 保存并取回历史状态；
• Tools 负责查询、计算和执行；
• API、MCP 负责把外部能力接进来。

第四类：编排职责

回答的是：

这里包括 Workflow 和 Agent。

第五类：治理职责

回答的是：

这里包括权限、Guardrails、人工审批、预算、频控、日志、评估、停止和回滚。它们共同构成 AI 系统的安全与治理外壳，也是 Agent Harness 的重要部分。

还有一个贯穿全程的共享工作台：Context。

Prompt、对话历史、RAG 找到的资料、Memory 取回的状态、工具说明和工具返回结果，都可能在运行中进入 Context。

本次新增的外部事实，只有进入 Context 后，模型才能直接据此作答。模型也会依赖训练时写入参数的通用知识与能力，但这些内容可能过时或不准确。

所以，Context 不是固定的一层，也不是永久档案库；它是各个部件在当前这一轮协作时共用的桌面。

把整张图压缩成一句话：

注意，这句话是"角色说明"，不是固定执行顺序。

一次任务里，Agent 可能查两次资料、调用三次工具，再回头补 Context；一个简单任务也可能只需要 LLM 和 Prompt，根本不需要 Agent。

真正专业的做法不是把所有部件都装上，而是先判断业务缺什么。

"AI"是一个很大的总称。

国际上常用的定义是：AI 系统根据输入，推断如何产生预测、内容、建议或决策，并可能影响现实或数字环境。

这把范围说得很宽。销量预测、垃圾邮件识别、商品推荐、语音识别、图像质检、自动驾驶、内容生成，都可以属于 AI。

几个常见词，可以这样区分：

人工智能（AI）

最大的伞。只要机器表现出识别、预测、生成、推荐或决策等能力，都可能被归入 AI。

机器学习（Machine Learning）

实现 AI 的一种常见方法。传统规则系统是人把"如果 A，就做 B"一条条写进去；机器学习则是让系统从大量样本中学出规律。

比如，不是人工写出"什么样的会员会流失"的全部规则，而是给模型历史会员数据，让它学习哪些行为组合更可能对应流失。

深度学习（Deep Learning）

机器学习中的一大类方法，通常使用多层神经网络，从大量数据中学习复杂模式。图像识别、语音识别和现代大模型，大多与深度学习有关。

生成式 AI（Generative AI）

强调"生成内容"这一类能力。它可以生成文字、图片、音频、视频、代码，或者这些形式的组合。

销量预测主要是在预测一个数，不一定属于生成式 AI；写一份活动方案、生成一张海报、把会议录音整理成纪要，则是典型的生成式 AI 应用。

大语言模型（LLM）

生成式 AI 中专长于语言的一类模型。很多今天的 AI 产品以 LLM 为语言核心，并接入图像、音频或视频能力；当同一模型或系统能够处理多种模态时，才称为多模态模型。不过，"能处理多种模态"和"能稳定完成业务任务"仍然是两回事。

一句话记忆：

先把 LLM 想成一位很会读、很会写、上手很快的临时专家。

你给它会员反馈，它能归纳问题；给它活动规则，它能起草策略；让它换一种语气，它也能马上修改。

但这位专家默认看不到公司后台，不会自动记住上一次项目，也不会因为语气自信就自动保证事实正确。

技术上，如果只保留一句话，可以这样理解：

这句话里有三个关键词：模式、上下文、概率。

它学到的是"模式"，不是一座可以翻阅的数据库

训练时，模型会接触大量文字、代码及其他数据，从中学习：

• 什么词经常一起出现；
• 什么问题通常对应什么回答；
• 一篇分析报告通常怎样展开；
• 某种代码结构通常怎样续写；
• 不同概念之间常见的联系是什么。

这些规律被压进模型内部的大量参数中。

所以你提问时，它通常不是像搜索引擎那样，打开某个网页并复制答案；而是根据训练时形成的模式和眼前材料，重新组织一个回答。

它根据"上下文"工作

同一句"帮我写一段召回文案"，放在不同背景下，答案应该不同。

如果当前材料里写着：

• 目标人群是高价值会员；
• 品牌语气克制；
• 不允许制造稀缺焦虑；
• 优惠上限是 30 元；
• 本周已经触达过一次；

模型就会据此生成。

如果这些信息没有出现在当前可见材料中，它只能依赖一般经验去猜。

它做的是"概率生成"，不是自动求真

对大多数自回归语言模型来说，生成文字时的基本动作，是根据已有内容预测下一个 Token，再把生成结果继续作为后文，反复向前。

这听起来像"高级文字接龙"，为什么却能写报告、做分析、解释代码？

因为它不是只学会"下一个字是什么"，而是在巨大数据和模型容量中学会了句法、语义、知识关联、文体、任务结构和解决问题的常见路径。

当这个过程连续发生很多次，就会表现出总结、翻译、规划、写作乃至一定程度的推理能力。

但这也解释了它的一个根本边界：

放进会员召回案例

你给 LLM 500 条会员反馈，它可以：

• 把相似意见归在一起；
• 提炼常见抱怨；
• 生成三种可能的沉睡原因；
• 为不同人群起草召回策略和文案。

但如果它没有读取真实行为数据，就不能把"权益吸引力不足"写成已证实的流失原因。

更准确的输出应该是：

这就是把"模型推断"与"业务事实"分开。

这些词很技术，但普通使用者只要理解它们会怎样影响工作，不需要先学公式。

可以把这一节当成"技术补给站"：赶时间时先看每段最后的大白话，再继续阅读第 06 节。

Token：AI 读写内容时使用的"计量格"

Token 不是严格意义上的"一个字"或"一个词"，而是模型分词器切出来的处理单位。一个 Token 可能是一个字、一个词、一个词的一部分，也可能是标点或其他片段；不同模型的切法并不完全相同。

它为什么重要？因为 Token 会影响三件很现实的事：

1. 一次能放进多少材料；
2. 处理速度和资源消耗；
3. 很多模型服务的成本。

不要死记"多少汉字等于一个 Token"。语言、内容和分词器不同，结果都会变化。真正稳妥的做法是使用具体产品的 Token 计数工具。

参数：训练后留下的"经验连接"

参数是模型在训练过程中学到的数值权重和偏置。

它们不是一条条可以打开查看的事实，也不能把"700 亿参数"理解成"记住了 700 亿条知识"。

参数多，通常意味着模型有更大的表示容量，但不等于任何任务都一定更强。实际效果还取决于训练数据、训练方式、后训练、推理方法、工具与具体任务。

Transformer：通过注意力机制建模不同位置关系的架构

2017 年的论文《Attention Is All You Need》提出了 Transformer 架构。它的关键机制之一是"注意力"：处理一句话时，模型可以给不同位置的信息分配不同权重，更有效地建模它们之间的关系。

例如"这个活动比上一个活动便宜，但转化更差"中，"更差"指向什么，要结合整句关系判断。

对业务人员来说，记住这一点就够了：

Context Window：这一次能摊开的"工作台"

上下文窗口通常指一次运行中输入与输出合计可使用的 Token 容量上限；具体产品还可能另设最大输出和计费规则。

工作台更大，确实可以放更多对话、文档、工具说明和返回结果；但"放得下"不等于"用得好"。

材料越多，通常也越慢、越贵，噪音越大。把几十份无关文档全部塞给模型，未必比只给它五份真正相关的资料更好。

所以真正要做的不是永远追求更大的窗口，而是做 Context Engineering，也就是：

• 该放什么；
• 以什么顺序放；
• 哪些内容要摘要；
• 哪些历史要删除；
• 哪些资料需要时再取回。

很多人会把"上传文档""写 Prompt""训练模型"混在一起。它们其实发生在不同层面。

预训练：形成通用底座

模型从大规模数据中学习语言、图像、代码等模式，形成通用能力。这一步成本高、周期长，通常由模型公司完成。

后训练与对齐：让模型更会遵循指令

基础模型还需要经过指令训练、偏好优化、安全训练等过程，才会更像今天可对话、能协作的助手。

"对齐"不是让模型永远正确，而是让它的行为更接近设计者和用户期望。

微调（Fine-tuning）：调整模型的稳定行为

微调会使用一批任务样本继续训练模型，改变部分或全部参数，使它在某类任务、格式或风格上表现得更稳定。

它适合解决的是：

• 某种任务模式需要反复稳定执行；
• 已经有足够多高质量示例；
• 单靠 Prompt 和检索仍达不到要求；
• 收益足以覆盖训练、评估和维护成本。

推理（Inference）：模型真正开始干活

用户输入内容、模型生成回答的过程，叫推理或运行。

我们日常和聊天产品对话，通常是在"使用一个已经训练好的模型"，而不是现场重新训练它。

所以：

• 上传一份产品手册，不等于训练模型；
• 把手册相关段落检索出来给模型看，通常属于 RAG；
• 在 Prompt 里提供三个示例，属于上下文内示范；
• 用大量样本更新模型参数，才可能属于微调。

一个实用判断：

Prompt 是提供给模型的输入，用来说明要做什么、参考什么、遵守什么、怎样交付。

它不一定只是一句话，也可以包含背景、材料、示例、边界和验收标准。

一个更好用的业务 Prompt，通常包含六部分：

1. 背景
   ：为什么做这件事；
2. 目标
   ：希望改变什么结果；
3. 输入
   ：可以使用哪些材料；
4. 步骤或原则
   ：怎样分析、哪些方法必须遵守；
5. 边界
   ：不能做什么，哪些结论必须标注不确定；
6. 输出与验收
   ：交付成什么样，怎样算完成。

例如，下面这条任务单就比"帮我分析沉睡会员"清楚得多：

Prompt 为什么重要？因为模糊任务只能迫使模型猜。

但也别把 Prompt 神化。

如果系统没有真实会员数据，再漂亮的 Prompt 也不会凭空产生事实。

如果没有发送工具，写一百遍"请帮我群发"，模型也不能真的执行。

如果业务自己都不知道什么叫成功，模型也很难替团队补出一个稳定的验收标准。

Prompt 和 Context 到底有什么区别？

Prompt 是你主动交代的任务和输入。

Context 是模型在这一次运行中实际能够看到的全部材料，可能包括：

• 系统指令；
• 用户 Prompt；
• 对话历史；
• 上传的文件片段；
• RAG 检索结果；
• 工具定义；
• 工具返回数据；
• 当前任务状态。

所以，Prompt 是 Context 的一部分。

最容易记的区分是：

这就是大家常说的"幻觉"。

幻觉不是说机器真的产生了人的幻觉，而是：

它可能编出一个不存在的政策条款，也可能把两次活动的数据混在一起，还可能给一份没读过的报告总结出"第三章结论"。

为什么会这样？

因为模型生成的直接过程是预测什么内容在当前语境下更可能出现，而不是每写一句话都自动连接权威数据库做事实核验。

当问题含糊、资料缺失、主题冷门、要求过细或需要最新信息时，它仍然可能继续生成"像答案的话"。

哪些业务场景最危险？

• 精确金额、日期、比例和人名；
• 最新政策、价格、库存和系统状态；
• 公司内部口径；
• 需要可靠出处的报告；
• 医疗、法律、财务和安全判断；
• 会直接触发付款、删除、群发等动作的任务。

怎么降低幻觉？

不是只在 Prompt 里写一句"不要编造"，而是同时做几件事：

1. 让任务和问题更明确；
2. 提供高质量、相关的 Context；
3. 用 RAG 或搜索补充可核验资料；
4. 用 Tool 获取实时数据，而不是让模型猜；
5. 要求区分"事实、推断、假设"；
6. 对关键字段使用程序规则校验；
7. 让重要结论附来源；
8. 高风险结果由人复核；
9. 用真实案例持续做评估。

会员召回中，AI 可以说：

但在拿到数据前，不能写成：

两句话看起来只差几个字，责任边界却完全不同。

多数情况下，先不要。

企业里更常见的问题不是模型完全不会语言，而是它不知道你公司的最新规则、产品信息、历史决策和真实数据。

这时要认识四个概念：Knowledge、Embedding、RAG 和 Memory。

Knowledge：公司的"资料室"

Knowledge，也就是知识或知识库，是对系统可使用资料来源的统称。

里面可能放：

• 产品手册；
• 活动权益；
• 会员规则；
• 品牌规范；
• 历史复盘；
• FAQ；
• 数据库记录。

知识库不是一个统一技术标准。

更重要的是：把文件上传进去，不等于模型一定能找到；标着"内部资料"，也不等于访问权限天然安全。

一个可用的企业知识库，至少还要管理：

• 版本；
• 生效与失效时间；
• 负责人；
• 数据权限；
• 文档质量；
• 更新和下架机制。

Embedding：给内容标上"语义坐标"

计算机怎样知道"退款多久到账"和"款项将在 1—3 个工作日原路退回"说的是相近问题？

一种常见方法是 Embedding，也就是嵌入。它把一段文字转换成一串数字向量。意思相近的内容，在向量空间里通常也更靠近，于是系统可以做语义检索，即使两段文字没有使用完全相同的关键词。

但坐标接近只说明语义相似，不代表事实正确。

对数字、编号、商品名、法律条款、代码字段等精确内容，纯语义检索也可能不够。因此真实系统常把关键词检索、语义检索、条件过滤和重排序组合起来。

还要注意：Embedding 不是加密。敏感内容转换成向量后，仍然要按衍生数据做好权限和保护。

RAG：先找资料，再组织答案

RAG 的全称是 Retrieval-Augmented Generation，中文通常译作"检索增强生成"。

它的核心动作很朴素：

1. 用户提出问题；
2. 系统从指定资料源找到相关片段；
3. 把片段放进当前 Context；
4. LLM 根据这些材料生成回答。

最通俗的类比是"开卷考试"。

但严格一点说，RAG 不等于知识库，也不等于 Embedding，更不等于网页搜索。

• 知识库是资料放在哪里；
• 检索是怎样找资料；
• Embedding 是一种常见的语义检索手段；
• RAG 是"检索结果进入生成过程"的整体做法；
• 网页搜索是另一种信息工具，也可以为生成提供材料，但不是 RAG 的同义词。

真正做一套 RAG，难点往往不在最后"写答案"，而在前面"找对材料"。一条常见链路包括：

1. 清洗文档，并标注版本、权限和生效时间；
2. 把长文档切成大小合适、语义完整的片段，这叫 Chunking；
3. 建立关键词索引和向量索引；
4. 根据问题召回一批候选片段；
5. 用过滤和重排序，把真正相关的内容排到前面；
6. 将少量高质量片段放进 Context，让 LLM 回答并附来源；
7. 测试"有没有找对、有没有漏掉、回答是否忠于资料"。

为什么切块很重要？

假设制度第一段写"高价值会员可享额外权益"，第二段才写"仅限本季度且每人一次"。如果系统把两段切开，只找回第一段，AI 就可能漏掉限制条件。

所以，RAG 的质量不仅取决于模型，也取决于资料治理、切块、召回、重排序和评估。

RAG 有三个常见误区。

误区一：接了 RAG，答案就一定正确。

不一定。文档可能错，切块可能断，检索可能偏，模型也可能理解错。

误区二：RAG 天然知道最新信息。

不一定。它只会检索被连接、被索引的资料。资料一年没更新，答案也可能停在一年前。

误区三：知识库越大越好。

也不一定。资料越杂，错误版本越多，系统越可能找到似是而非的片段。

Memory：不是当前桌面，而是可以再取回的档案

Memory 是应用为后续运行保存并取回的任务或交互状态，例如：

• 上一次任务做到哪一步；
• 已批准了哪个方案；
• 负责人已经确认的品牌偏好；
• 工具此前返回的结果。

会员投诉、余额、标签、权益使用等业务事实，仍应以 CRM 或数据仓库等权威系统为准，不能只依赖 Memory。

基础模型的一次次调用通常是独立的。产品之所以看起来"记得你"，往往是应用保存了相关信息，并在下一次运行时重新放回 Context。

所以：

Memory 也不是越多越好。

保存错误、过期或未经同意的信息，会把旧错误带进新任务。企业系统应明确：

• 什么值得记；
• 谁能读；
• 保存多久；
• 如何修改和删除；
• 什么时候不得继续使用。

放进会员召回案例

• Knowledge 存放当前权益、触达频控、品牌规范和历史复盘；
• RAG 根据本次人群，找出真正相关的规则与案例；
• Embedding 帮助系统找到措辞不同但意思相近的内容；
• Memory 取回上轮已批准策略、任务状态和已确认偏好；业务结果仍由 Tool 从权威系统重新查询；
• LLM 结合这些材料完成分析。

这四者都在"补信息"，但角色完全不同。

Skill 这个词最近很常见，也最容易和 Tool 混在一起。

在不同产品里，"Skill"的实现会有差别。

按照当前较明确的一类定义，Skill 会把一类任务的指令、参考资料、模板和可选脚本打包，使 AI 能在相似任务中更一致地复用一套工作方法。是否真正稳定，仍需测试和评估。

假设团队已经有一套"沉睡会员诊断与召回 Skill"，里面可能写着：

1. 先检查数据日期、字段完整性和人群口径；
2. 再按会员价值、活跃度和历史权益使用情况分层；
3. 结论必须区分数据事实、合理推断和待验证假设；
4. 样本不足或规则冲突时停止，不得硬编；
5. 输出统一使用"人群—证据—策略—内容—风险—验证"模板；
6. 发送前检查优惠上限、触达频次和退订名单；
7. 完成后输出复盘和规则更新建议，由负责人审核、测试并发布新版本；不得让一次运行未经审核自动改写 Skill。

下一次再做相似任务，AI 就不必完全临场发挥。

Skill 不是什么？

Skill 不是 Prompt 的另一个名字。

Prompt 更偏向这一次任务；Skill 更偏向可复用的方法、材料和执行规范。

Skill 不是 Tool。

"查询 CRM""读取表格""发送消息"是工具能力；"在什么情况下查哪些字段、怎样分层、发送前检查什么"才属于工作方法。

Skill 也不会自动带来权限。

给 AI 一份"如何发送会员消息"的手册，不等于它已经获得消息平台账号，更不等于它有权对十万用户群发。

Skill 与 Workflow 也不是绝对互斥。

Skill 可以描述步骤、分支和检查清单；Workflow 则是系统在一次实际运行中真正执行的路线和状态控制。前者像标准作业书，后者像今天已经启动的生产线。

为什么 Skills 对企业很重要？

因为团队真正稀缺的，通常不是一句 Prompt，而是那些藏在优秀员工脑子里的判断：

• 先看哪个指标；
• 哪些例外最危险；
• 什么情况下必须停；
• 什么叫合格；
• 哪种失败以前发生过。

把这些经验写成可更新、可测试、可复用的 Skill，才可能从"某个人会用 AI"，走向"团队拥有一套 AI 能力"。

每次失败后，也不要只说"下次提醒 AI 小心一点"。

应该问：

这才是会复利的 AI 资产。

到这里，AI 已经有任务、有材料、有证据，也有方法。

但它仍然可能只会告诉你：

真正把查询做出来，需要 Tool。

Tool：AI 真正用来办事的"手和软件按钮"

Tool 是模型或 Agent 可以调用的可执行能力。例如：

• 搜索网页；
• 读取文件；
• 查询 CRM；
• 运行计算；
• 创建人群包；
• 写入工单；
• 发送消息；
• 操作电脑界面。

在 Agent 场景中，模型可以判断是否调用、调用哪个 Tool 以及提交什么参数；在固定 Workflow 中，也可以由规则或程序直接决定。真正的查询或修改，仍由工具背后的程序和系统完成。

这就是"建议"和"行动"的分界线：

工具也可能失败，可能超时、返回旧数据，或产生真实副作用。因此读和写最好拆开：

• 查询会员，属于只读工具；
• 修改标签，属于写入工具；
• 创建待审批人群包，是受限动作；
• 真正发送消息，是高风险动作。

它们不应该共享同一套宽泛权限。

API：一个系统自己的"办事窗口"

API 是软件之间约定好的调用合同。它通常规定：

• 可以办理什么；
• 要提交哪些参数；
• 用什么身份认证；
• 返回什么结果；
• 出错时怎样表示。

CRM、支付、地图、天气、消息平台，都可能有自己的 API。

API 本身没有智能，也不等于开放权限。知道银行柜台在哪里，不代表任何人都能从你的账户转账。

MCP：AI 连接外部系统的一种标准化接法

MCP 的全称是 Model Context Protocol，模型上下文协议。MCP 是连接 AI 应用与外部系统的开放标准。

按协议，服务器主要暴露 Resources（资料或数据）、Prompts（提示模板）和 Tools（可调用能力）。业务 Workflow 可以建立在这些能力之上，但不是与三者并列的核心服务器原语。

"USB-C 接口"是一个好类比：

过去，每接一个外部系统，都像重新焊一套线；采用统一协议后，AI 应用可以用更一致的方式发现有哪些能力、理解参数并发起调用。

但这个类比千万别理解过头。MCP 不代表：

• 所有软件已经自动兼容；
• 不再需要底层 API；
• 接上就能使用任何工具；
• 自动获得账号和权限；
• 第三方服务天然可信；
• 调用行为天然安全。

更准确地说：

MCP 也不是 AI 系统唯一的连接方式。内置工具、函数调用配合后端执行、直接 API 集成，都可以为模型接入外部能力。

函数调用本身只是模型发出的结构化调用请求，仍需应用校验参数、执行代码并把结果返回。

是否使用 MCP，要看生态、维护成本、安全要求和实际场景。

放进会员召回案例

• Tool：查询 CRM、计算分组人数、创建待审批人群包；
• API：CRM 和消息平台各自的办事窗口；
• MCP：让 AI 应用用更统一的方式接入某些外部数据与工具；
• 权限：查询可以自动，修改标签要受限，群发必须审批。

特别要记住：

很多自动化系统都被包装成 Agent，其实并不准确。

区分 Workflow 和 Agent，关键不是有没有使用 LLM，而是流程控制权主要在规则还是模型：

两者可以组合。

Workflow：提前铺好的轨道

Workflow 是系统预先定义的执行顺序、分支、状态和失败处理规则。

例如会员召回的正式主流程：

每一步做什么、成功后去哪、失败后怎么办，尽量提前确定。

固定工作流的价值不是"低级"，而是：

• 稳定；
• 可预测；
• 成本容易控制；
• 容易测试；
• 容易审计；
• 出错范围更小。

日报生成、发票识别、审批后发送、固定格式报表，往往更适合 Workflow，不必硬上 Agent。

Agent：会根据中间结果选择下一步的系统

截至本文核验日期，不同官方文档对 Agent 的表述略有差异，但共同点很清楚：

Agent 不是一个新模型名称，而是一种应用系统。它至少围绕模型和指令运行，并可配置工具、状态、Guardrails、MCP 和交接机制；运行时根据结果决定继续调用、调整、交接或停止。

可以把循环记成：

例如，会员召回活动上线后，某一组打开率异常低。

固定 Workflow 可能只会按预设步骤继续。

Agent 则可以在允许范围内判断：

• 先查发送时段；
• 还是查渠道偏好；
• 还是查权益领取历史；
• 证据不足时要不要换一种查询；
• 是否应该生成调整方案并请求负责人确认。

这正是"根据环境反馈动态选路"的价值。

Agent 不是"无限自主的数字员工"

它只能在系统配置的范围内工作：

• 能看到什么 Context；
• 可以使用哪些 Tools；
• 以什么身份访问；
• 哪些动作需要审批；
• 最多运行多少步；
• 最多花多少时间和成本；
• 什么时候必须停止。

工具没有开放，它就做不了；权限不允许，它就不该做；目标和验收标准模糊，它可能高效地跑向错误方向。

企业里最常见的不是二选一，而是混合模式

确定的主流程写死。

只有在确实需要判断的局部节点，才让 Agent 选路。

例如：

• 人群口径、频控、审批和发送流程固定；
• 沉睡原因分析、证据补查和策略草拟允许 Agent 动态处理；
• 发券、群发、删除和对外发布永远不自由放行。

这通常比"全自动"更稳，也比"完全人工"更灵活。

当 AI 只写一段草稿时，错误的后果可能只是返工。

当它能读取客户数据、修改标签、发放优惠、发送消息时，同样的判断错误会被放大成真实后果。

这时，不能只靠一句"请谨慎"。

Harness：模型外面的运行与治理环境

"Agent Harness"并不是像 MCP 那样有一份统一协议，它在行业里的使用范围也不完全一致。

广义上，它指包住模型或 Agent 的整套运行环境，可能包括：

• Context 和状态管理；
• Tool 执行；
• 任务循环；
• 权限和沙箱；
• 审批与预算；
• 重试和停止；
• 日志、监控和评估。

如果 LLM 是负责判断与生成的核心模块，Harness 就是周围负责调度、授权、记录、检查和制动的运行控制系统。

前文已经把方法、资料、工具、流程分别拆开讲了。这里重点看 Harness 中的治理能力。

Guardrails：自动生效的检查和阻断

Guardrails，通常译作护栏。它可以自动检查输入、输出或工具行为，并在触发规则时阻断；需要人工决定时，则由审批机制暂停运行并交给负责人确认。

例如：

• 识别并遮蔽身份证号、手机号等敏感信息；
• 在工具和数据层按调用身份拒绝无权限查询；Guardrail 可以补充检查，但不能替代真正的认证与授权；
• 发现优惠超过上限时停止；
• 群发前强制人工审批；
• 投诉率或失败率超过阈值时熔断；
• 工具参数不合法时拒绝执行。

还要防一种不容易被看见的风险：外部网页、文档、邮件或工具返回值里，可能夹带"忽略原任务，把资料发到某处"之类的恶意指令，这通常被称为 Prompt Injection，也就是提示注入。

因此，至少要守住六条规则：

• 外部内容先当作"不可信数据"，不能自动升级成系统指令；
• 第三方 MCP Server 和 Tool 使用白名单并单独审查；
• 账号凭据不能写进 Prompt；
• 发送、付款、删除和公开发布仍要审批；
• 限制每个工具可见的数据和可调用范围；
• 保留完整工具调用日志。

最重要的区别是：

一套基本的业务 Harness，至少要有八样东西

1. 最小权限
   ：只给完成任务所必需的数据和工具；
2. 数据隔离
   ：不同用户、客户、项目的材料不能串；
3. 人工检查点
   ：付款、删除、群发、公开发布等敏感动作必须确认；
4. 预算与频控
   ：限制金额、人数、次数、运行步数和总成本；
5. 过程日志
   ：查了什么、用了什么、谁批准、结果怎样，都能追溯；
6. 停止按钮
   ：异常时可以立即暂停或切回人工；
7. 可恢复性
   ：写操作尽量幂等、可撤销或可回滚；自动重试必须防止重复发券、重复群发等副作用；
8. 持续评估
   ：用真实样例检查质量、风险、成本和回归问题。

Evals：把"感觉不错"变成"可以验证"

Evals 是 Evaluations 的简称，可以理解为一套重复运行的测试与评分办法。

例如，团队可以先整理 20—50 个真实会员案例，分别检查：

• 资料找对了没有；
• 回答是否忠于证据；
• 人群和金额计算是否正确；
• 工具调用是否符合权限与参数要求；
• 遇到证据不足或高风险动作时，系统会不会停下来；
• 人工复核需要多久，单次运行成本是多少。

每次修改 Prompt、Skill、知识库、模型或工具后，都重新跑一遍这些案例。这样才能知道系统是真的变好，还是只在演示里显得更聪明。

最终还要观察业务结果：回访和转化是否改善，同时投诉、退订和成本有没有恶化。技术测试与业务指标，缺一边都不完整。

还有一个常见误区：本地部署不等于天然安全。

本地部署可能减少一部分外部传输风险，但内部越权、配置错误、敏感日志、恶意文档和错误工具调用仍然存在。无论模型运行在云端还是本地，最小权限、数据隔离、审批、日志、测试和应急处置都不能省。

安全不等于要求 AI 永不犯错。

更现实的目标是：

现在，不再解释定义。

我们把镜头拉回"30 天未活跃会员召回"。真实运行不是从 Skill 到 RAG、再到 Agent 的一次性直线，而是四个阶段和一个反复发生的工作循环。

阶段一：先把任务和边界准备好

业务目标不是"用 AI 做一次召回"，而是：

团队同时确定正向指标和风险指标：触达、打开、点击、回访、转化，以及退订、投诉、权益成本。条件允许时还要设置对照组或历史基线，否则指标变化不能直接归因于本次召回。

负责人再用 Prompt 交代本次任务：人群口径、可用材料、品牌语气、输出格式、证据要求，以及"不得直接发送"等边界。

系统加载"沉睡会员召回 Skill"。它规定先检查哪些字段、怎样分层、怎样区分事实与假设、什么情况必须停、最后按什么模板交付。

Harness 则在任务开始前就限制好权限：哪些数据只能读，哪些工具可以用，谁能批准建包和群发，预算与触达上限是多少。

阶段二：在共享 Context 中反复取证和判断

从任务启动开始，Workflow 或 Agent 就在控制路线，而不是等到最后才出现。

可以把运行过程简化成下面这个循环：

第一次进入 Context 的，可能只有任务说明、字段解释、Skill 和工具说明。

如果缺真实人群数据，系统先调用只读 Tool，从 CRM 查询 30 天未活跃会员，并校验人数、日期和字段完整性。Tool 可以通过直接 API、内置集成或 MCP 接入。

权威业务系统返回的查询结果，会连同数据口径、来源和时间戳进入 Context，供模型使用。Tool 返回结果也可能过期或有误，不能自动等同于真相。

如果缺当前规则，RAG 就从 Knowledge 中检索经过版本号和生效时间校验的当前有效权益、渠道频控、品牌禁用语和相似活动复盘。

如果需要历史状态，Memory 再取回上轮已批准策略、已否决方案和任务状态。历史投诉与权益使用记录，则由 Tool 从 CRM 或数据仓库重新查询。这些结果也会进入 Context。

LLM 读取眼前证据，尝试完成人群分层、原因分析和策略草拟。若证据不足，它不应强行下结论，而应提出下一项可验证的问题，再由编排系统决定是否继续检索或查询。

在这个过程中：

• Workflow 保证数据校验、规则检查、审批等必经节点不会被跳过；
• Agent 只在"下一步究竟查时段、渠道还是权益历史"这类岔路口动态选路；
• Context 会随着检索和工具结果不断变化；
• LLM、RAG、Memory 和 Tool 都可能被调用多次。

直到证据足够，系统才生成待审的人群包、策略、文案、风险和验证建议，并把每条关键结论标成"数据事实""模型推断"或"待验证假设"。

阶段三：敏感动作过闸门

草案生成后，系统不能直接群发。

Guardrails 先做自动检查：是否包含退订用户，是否超过优惠上限，是否违反频控，是否调用了超出范围的数据，人群规模是否异常。

检查通过后，Tool 只能创建"待审批"任务。负责人确认人群、内容、预算和发送时间后，发送权限才短时开放；没有审批，写入和发送动作就不执行。

这里再次体现了一个重要原则：

阶段四：让真实结果回到系统

发送后 72 小时，Workflow 按计划读取打开、点击、回访、退订、投诉和权益成本。

如果某一组打开率异常低，Agent 可以在限定范围内补查发送时段、渠道偏好和历史权益领取情况，形成调整建议；但扩大人群、提高预算或二次群发仍然需要人确认。

最后，真实结果会进入三处：

• 进入 Memory，保存本次任务状态和已确认结论；
• 进入 Evals，成为以后检验系统是否退步的真实样例；
• 形成 Skill 更新建议；经过人工审核、测试和版本发布后，再把有效方法、失败条件和检查规则沉淀进去。

这才是一套完整的业务 AI 系统。

遇到 AI 项目，不要先问"用哪个大模型"。

先用下面这组问题诊断。

如果输出总是不对题

先检查 Prompt：目标、输入、边界、输出和验收是否说清楚。

如果每个人用 AI 的方法都不一样

把优秀做法沉淀成 Skill：步骤、模板、样例、异常处理和完成标准。

如果回答缺公司事实或最新规则

缺内部文档口径时，建设受控 Knowledge 与 RAG；缺实时余额、库存、标签或活动状态时，通过只读 Tool/API 查询权威系统。两者都要管理权限、来源、版本和时间。

如果 AI 只能建议，不能执行

判断是否需要 Tool，以及 Tool 背后的 API 或 MCP 连接。

如果固定步骤总被漏掉

把确定性部分固化成 Workflow。

如果任务中途经常出现无法预设的岔路

再考虑 Agent，并给它明确的工具、反馈、预算和停止条件。

如果最担心数据和动作失控

先补 Harness：最小权限、审批、日志、评估、熔断和回滚。

还有一个经常被忽略的前提。

一家公司是否适合做 AI，不只取决于模型，还要通过四项项目检查：

1. 要改善的业务结果能不能量化；
2. 当前由谁、按什么步骤完成，能不能画清楚；
3. 必要数据能不能合法、及时地获得；
4. 结果好坏能不能尽快回到系统，形成下一轮改进。

如果这些基础还没有理清，AI 只会把原有的不确定性扩散到更多环节。

不要从"做一个全自动 Agent"开始。

先找一个满足四个条件的任务：

• 高频；
• 费时；
• 结果可检查；
• 出错可恢复。

例如：

• 用户评论归纳；
• 活动复盘初稿；
• FAQ 草拟；
• 会议纪要结构化；
• 周报数据整理；
• 待审召回方案生成。

然后做一个两周实验。

第 1 天：选一个具体瓶颈

不要写"提升运营效率"，而要写：

第 2—3 天：写清任务规格

明确目标、材料、步骤、边界、输出和验收。

第 1 周：做人机对照

记录：

• 实际耗时；
• 一次通过率；
• 漏项和错误；
• 人工返工时间；
• 使用成本。

第 2 周：把有效做法固化

把成熟的 Prompt、步骤、参考资料、模板、工具依赖、检查清单和失败案例，整理成一个可复用的 Skill 或 SOP。

同时明确三个责任角色：

• 业务结果负责人：定义要改善的指标和验收标准；
• 系统运行负责人：准备任务、材料、工具和权限；
• 质量与风险负责人：检查事实、动作和业务后果。

小团队里可以是同一个人，但三个责任不能消失。

实验开始前就写下继续和停止条件。

例如：一次通过率达到目标、人工复核时间明显下降，才进入下一阶段；一旦出现越权取数、错误群发或严重事实错误，立即暂停。

两周结束后，只做三种明确决策：停止、维持人工辅助，或升级成受控 Workflow。不要因为演示效果漂亮，就直接跳到全自动 Agent。

真正值得积累的，不是某次生成出来的一篇漂亮文案，而是：

1. AI 是大类，不等于聊天机器人。
2. 生成式 AI 擅长生成内容，但"像真的"不等于"是真的"。
3. LLM 是理解和生成语言的模型核心，不是完整业务系统。
4. Token 是模型读写和计量内容的基本单位，不等于字数。
5. 参数是训练中学到的数值权重，不是可以翻阅的知识条目。
6. Transformer 擅长建模上下文关系，但不会自动提供事实和记忆。
7. Prompt 是本次任务单，Context 是当前工作台上的全部材料。
8. Knowledge 是系统可使用的资料来源；RAG 是先检索相关片段，再把它们带入生成过程。
9. Embedding 给内容标语义坐标，语义相近不代表事实正确。
10. Memory 是可保存、可取回的档案，不等于当前 Context。
11. Skill 是可复用的岗位手册，不是查询或发送工具。
12. Tool 负责真正办事，API 是具体系统的办事窗口。
13. MCP 是一种标准化连接方法，不替代认证、权限和审批。
14. Workflow 让规则控制主流程；Agent 让模型在授权范围内依据中间结果选路；真实系统通常把两者组合。
15. Harness 是模型外的运行与治理环境，Guardrails 是其中的自动检查和刹车。
16. Evals 用真实案例反复测试质量、风险和成本，让"好像可用"变成"可以验证"。
17. AI 能否落地，最终取决于目标、数据、方法、工具、反馈和责任是否被组织起来。

现在，再回头看最开始的会员召回任务。

LLM 加上 Prompt 和 Context，先从"会写"变成"知道这次该写什么"。

Knowledge、RAG、Memory 和 Skills 再补上公司的证据、历史和成熟方法；Tool 让它能够查询和执行，Workflow 与 Agent 负责控制路线。

Harness、Guardrails、人工审批和 Evals，则让整套系统有边界、能复查、可改进。

因此，团队开始做 AI 落地时，最重要的问题不是：

而是：

AI 不会因为接入了一个更大的模型，就自动成为数字员工。真正决定企业 AI 能走多远的，往往不是模型知道多少，而是组织能不能把自己的工作讲清楚、接起来，并且管得住。