大模型只是现代 AI 应用的推理核心，并不等于一个完整的智能体。真正能够在企业中持续完成任务的 AI Agent，还需要外部知识、工具调用、上下文与记忆、工作流编排、协议连接、安全控制和运行评测共同支撑。

如果只想先记住一句话，可以这样理解：LLM 负责理解和决策，RAG 负责补充知识，Function Call 负责表达工具调用意图，MCP 负责连接工具与数据，Skill 负责复用专业方法，Workflow 负责约束执行路径，Agent 负责动态决定下一步，A2A 负责多个 Agent 之间的协作。

这也是当前 AI 技术从“模型能力竞争”转向“系统工程竞争”的关键变化。本文按从底层模型到上层应用的顺序，建立一张完整的 AI 技术地图，并说明这些概念分别解决什么问题、如何协同，以及企业落地时应该怎样选型。

图1：从模型、知识、工具到智能体和业务应用的 AI 技术体系。

一、为什么需要先建立一张 AI 技术地图

过去几年，LLM、RAG、Agent、MCP、Skill、A2A、微调和模型蒸馏等概念陆续流行。它们经常被放进同一份产品介绍，却不属于同一技术层级。

例如，LLM 是模型；RAG 是给模型补充外部知识的方法；Function Call 是模型输出结构化工具调用参数的能力；MCP 是 AI 应用连接工具和资源的协议；Skill 是一套可复用的任务方法；Agent 则是围绕模型建立的自主运行系统。

从工程视角看，一套完整的企业 AI 应用通常可以拆成六层。

层次	典型概念	主要解决的问题
业务应用层	智能客服、研发助手、数据分析、流程自动化	AI 最终为谁提供什么价值
智能体与编排层	Agent、Workflow、Multi-Agent	任务由谁规划、按什么路径执行
能力与协议层	Function Call、MCP、Skill、A2A	能力如何描述、复用、连接与协作
知识与记忆层	RAG、向量库、知识图谱、长期记忆	如何获取模型参数之外的信息
模型层	LLM、VLM、OCR、ASR、TTS、Embedding	如何理解、推理、识别和生成
训练与推理层	预训练、微调、蒸馏、量化、推理服务	模型如何获得能力并低成本运行

权限、审计、评测、安全、成本和人机协同并不是单独的一层，而是贯穿整个系统的治理能力。

二、LLM 是什么：为什么它会回答，却不等于真正“知道”

LLM 是 Large Language Model，即大语言模型。它最基本的任务，是根据已有上下文预测下一个 Token 的概率：

P(x[t+1] | x[1], x[2], ... , x[t])

模型先把文本切分成 Token，再把 Token 转换为向量，经过多层 Transformer 的注意力计算，得到下一个 Token 的概率分布。输出一个 Token 后，模型把它加入上下文并继续生成，直到遇到停止条件。

图2：LLM 提供推理能力，知识、工具、状态和运行时共同把它扩展为 Agent。

这种机制决定了 LLM 的三个重要边界。

第一，模型输出具有概率性。即使输入完全相同，只要采样参数或运行环境不同，结果也可能变化。

第二，模型参数中保存的是压缩后的语言和知识模式，而不是可以逐条核对的业务数据库。模型可能给出语言上合理、事实却不准确的答案。

第三，模型只能生成内容。它可以描述如何创建工单，却不能在没有外部工具的情况下真正操作工单系统。

因此，一个可上线的 AI 应用不能只依赖“更大的模型”，还必须增加知识获取、工具执行、状态管理和结果验证。

三、OCR、VLM、ASR、TTS：AI 模型不只有大语言模型

题目中常见的“ORC”通常是“OCR”的误写。OCR 是 Optical Character Recognition，即光学字符识别。

现代 AI 应用一般会组合多种模型，而不是让一个 LLM 包办所有任务。

模型类型	输入与输出	典型用途	主要边界
LLM	文本到文本或结构化数据	对话、代码、分析、推理	不天然具备实时知识和执行能力
VLM	图片与文本到文本、坐标或判断	图片理解、视觉问答、界面操作	成本较高，精细识别仍可能出错
OCR	图片到文字与版面结构	发票、合同、扫描件识别	主要识别内容，不等于理解业务含义
ASR/STT	语音到文字	会议转写、语音客服	受噪声、口音和专业词影响
TTS	文字到语音	语音播报、数字人	需要控制音色、情绪、延迟和合规
Embedding	文本或图片到向量	语义搜索、聚类、RAG	只表示相似性，不直接生成答案
Reranker	查询与候选文档到相关性分数	RAG 重排序	增加一次推理成本，但常能提升召回质量
Diffusion	文本、图片或噪声到图片、视频	图像生成、视频生成	生成稳定性与可控性依赖工作流约束

以发票报销为例，OCR 负责识别金额和日期，版面分析模型负责判断字段位置，VLM 负责理解票据类型，LLM 根据企业制度判断是否符合要求，工作流再决定自动通过还是交给人工审核。

这类组合式架构通常比“所有任务都调用同一个大模型”更稳定，也更容易控制成本。

四、RAG 如何让模型使用企业知识

RAG 是 Retrieval-Augmented Generation，即检索增强生成。它的核心不是训练模型记住更多资料，而是在回答之前，从外部知识库检索相关证据并放入上下文。

RAG 原始研究将这种模式描述为参数化记忆与非参数化记忆的结合：模型参数提供通用语言能力，外部索引提供可更新、可追溯的知识。

图3：企业 RAG 从文档解析、混合检索到重排序和引用生成的完整链路。

一个生产级 RAG 链路通常包括：

1. 使用解析器和 OCR 读取 PDF、Word、网页、图片与表格；
2. 按标题、段落、语义或版面结构切分文档；
3. 使用 Embedding 模型将文本转换为向量；
4. 把向量、原文和权限元数据写入索引；
5. 对用户问题进行改写、扩展或拆解；
6. 同时执行关键词检索和向量检索；
7. 使用 Reranker 对候选结果重新排序；
8. 把高相关证据送入 LLM，并要求附带来源。

RAG 不等于向量数据库。Milvus、Qdrant 等向量数据库负责存储与相似度检索，但文档解析、Chunk 切分、权限过滤、查询改写、重排和答案评测同样决定最终效果。

RAG、长上下文、微调和 Skill 也不能互相替代。

需求	优先方案	原因
使用最新制度、产品资料和业务数据	RAG 或工具查询	内容可以随数据源实时更新
一次分析少量指定材料	长上下文	实现简单，不必建立长期索引
固定输出风格、格式或专业行为	微调	改变模型的行为倾向
固化一套可重复的操作方法	Skill	方法可以被不同任务复用
创建订单、发送通知、查询实时库存	Tool Calling	需要真正读取或修改外部系统

五、Function Call：模型如何提出一次工具调用

Function Call，也称 Tool Calling，是模型输出结构化工具调用意图的能力。

应用程序首先把工具名称、用途和参数 Schema 告诉模型。模型判断需要使用工具时，不直接编造执行结果，而是返回工具名称和参数。应用程序校验参数后执行真实 API，再把结果送回模型生成最终回答。

例如，用户询问“明天深圳天气怎么样”，模型可能返回：

{
  "name": "query_weather",
  "arguments": {
    "city": "深圳",
    "date": "明天"
  }
}

这里最容易产生的误解是：模型并没有真正执行 query_weather。它只生成了一个候选动作，真正的执行者仍是应用程序或 Agent Runtime。

因此，结构化输出只能解决“参数格式是否符合 Schema”，不能保证业务含义一定正确。生产环境还需要权限校验、参数范围检查、幂等控制、超时重试和高风险操作确认。

六、MCP、Skill 和 A2A 分别解决什么问题

随着工具和智能体数量增加，仅靠每个应用单独维护 Function Call 定义会产生大量重复集成。MCP、Skill 和 A2A 分别从连接、复用和协作三个方向解决这一问题。

图4：Function Call 靠近模型，MCP 连接工具，Skill 封装方法，A2A 连接智能体。

MCP：标准化 Agent 与工具、资源的连接

MCP 是 Model Context Protocol。其核心架构由 Host、Client 和 Server 构成。MCP Server 可以向 AI 应用暴露 Tools、Resources 和 Prompts，Client 负责建立连接，Host 则负责会话、权限和用户体验。

MCP 并没有取代 Function Call。常见实现是：模型通过 Function Call 选择某个工具，Agent Runtime 再通过 MCP 调用对应 Server。

Skill：把经验和工具组合成可复用方法

Skill 可以理解为 Agent 的专业操作手册。它通常描述适用场景、输入输出、执行步骤、参考资料、可用工具、验证方法和停止条件，有时还会附带脚本与模板。

如果 Tool 是一把锤子，Skill 就是“如何完成一套木工作业”的操作规范。一个月度经营分析 Skill 可以规定先查询销售数据，再计算同比环比，然后识别异常指标，最后按企业模板生成报告。

A2A：标准化 Agent 之间的任务协作

A2A 是 Agent2Agent Protocol，主要用于一个 Agent 发现并委派任务给另一个 Agent。它定义了 Agent Card、Message、Task、Artifact、Part、流式进度和异步通知等对象。

例如，旅行主管 Agent 可以通过 A2A 把机票、酒店和天气任务分别交给专业 Agent；每个专业 Agent 内部又可以通过 MCP 连接票务、酒店和天气服务。

一张表看懂四者的边界

概念	所处位置	回答的核心问题	不负责什么
Function Call	模型与应用之间	模型想调用哪个函数、参数是什么	不真正执行工具
MCP	Agent 与工具、数据之间	工具如何被发现、连接和调用	不负责复杂任务规划
Skill	Agent 能力组织层	一类任务应该按照什么方法完成	不等于一个远程服务协议
A2A	Agent 与 Agent 之间	多个智能体如何发现、委派和返回成果	不替代 Agent 内部工具协议

七、AI Agent 的核心理念：从生成回答到完成任务

AI Agent 是以模型为推理核心，能够理解目标、维护状态、规划步骤、调用工具、观察结果并持续行动的软件执行单元。

一个更完整的表达式是：

Agent = Model + Context + Memory + Planning + Tools + Runtime + Governance

普通聊天机器人的路径通常是“用户输入—模型回答”，Agent 则形成“观察—决策—行动—反馈”的闭环。模型不必一开始就生成最终答案，而可以在环境反馈中不断调整下一步。

上下文负责告诉模型当前目标、规则和证据；记忆负责保存任务状态和长期信息；工具负责读取或改变外部世界；Runtime 负责执行、暂停、恢复和限制权限；治理系统则负责日志、成本、评测和安全。

八、CoT、ReAct 和 Plan-and-Execute 有什么区别

Agent 需要解决的第一个问题，是如何组织模型的推理与行动。CoT、ReAct 和 Plan-and-Execute 分别代表三种常见思路。

图5：CoT 强调多步推理，ReAct 强调推理与行动循环，Plan-and-Execute 强调任务拆解。

CoT：把复杂问题拆成中间步骤

CoT 是 Chain of Thought。它适合数学、逻辑和多步分析，主要解决“怎样推理”，并不天然包含工具调用。

在工程系统中，更推荐让模型输出结构化计划、关键依据和可验证步骤，而不是把模型完整的内部思考过程直接展示给用户。

ReAct：边判断、边行动、边观察

ReAct 将 Reasoning 与 Acting 交替执行。模型先判断下一步，调用工具后读取 Observation，再根据新证据继续判断，直到满足完成条件。

它适合搜索、研究、排错和开放式任务，但循环过多会增加延迟、Token 成本和错误累积概率。因此 Runtime 必须设置最大步数、预算和停止条件。

Plan-and-Execute：先生成计划，再逐项执行

Plan-and-Execute 把 Planner 与 Executor 分开。Planner 将目标拆成任务清单，Executor 逐项执行；当环境发生变化或任务失败时，系统可以重新规划。

这种方式适合长任务，因为计划可以展示给用户、接受修改、分步审批、持久化为检查点，也可以分派给多个执行器。实际系统常用 Planner 生成全局计划，再让 Executor 在每个子任务中运行 ReAct。

框架	主要关注点	是否依赖工具	适合场景
CoT	多步推理	非必要	数学、逻辑、复杂分析
ReAct	推理与行动循环	通常需要	搜索、排错、探索任务
Plan-and-Execute	计划、进度和重规划	通常需要	研究报告、研发任务、复杂业务流程

九、Workflow 和 Agent 有什么区别

Workflow 是通过预先定义的节点和连接关系组织模型、工具与业务逻辑。Agent 则允许模型动态决定下一步行动。

二者最大的区别不是“是否使用大模型”，而是谁掌握控制流。

对比项	AI 工作流	AI Agent
执行路径	主要由开发者预先定义	主要由模型动态决定
可预测性	较高	较低
灵活性	适合固定流程	适合开放任务
调试方式	逐节点检查	需要检查完整执行轨迹
成本控制	比较容易	需要步数和预算限制
典型场景	合同审批、内容审核、数据同步	调研、编码、故障排查、复杂分析

真正有效的企业架构通常是混合模式：确定性操作交给工作流，不确定性判断交给模型，探索性任务交给 Agent，高风险动作交给人工审批。

十、上下文工程、记忆和可观测性为何越来越重要

早期 AI 应用强调 Prompt Engineering，现在的 Agent 系统更关注 Context Engineering，即如何在正确时机向模型提供正确的信息。

上下文不仅是提示词，还包括系统规则、用户身份、任务状态、RAG 证据、Skill、工具定义、历史摘要、执行结果、错误信息和检查点。上下文并不是越长越好，无关信息过多会增加成本，也可能干扰模型判断。

Agent 的记忆通常可以分为四类：

• 工作记忆：当前一次模型调用需要看到的信息；
• 任务记忆：任务计划、步骤、状态和检查点；
• 长期记忆：用户偏好、历史任务和沉淀事实；
• 程序记忆：Skill、模板和可重复执行的方法。

可观测性则负责记录一次任务的完整 Trace，包括每次模型调用、检索结果、工具参数、执行耗时、Token 成本、异常和最终结果。没有这些数据，Agent 一旦失败，团队很难判断问题来自模型、上下文、工具还是业务系统。

十一、模型预训练、微调、蒸馏和量化的区别

大模型从数据走向生产，通常要经历数据处理、预训练、指令微调、偏好对齐、领域适配、压缩和部署等阶段。

图6：预训练获得基础能力，微调改变行为，蒸馏迁移能力，量化降低部署成本。

预训练：让模型获得通用能力

预训练使用海量文本、图片、音频或视频，通过自监督任务学习语言和世界模式。从零训练通用大模型需要大量数据、算力和分布式工程能力，一般企业更适合基于现有模型开发应用。

微调：让模型适应领域和任务

微调是在预训练权重上继续训练。全量微调会更新大部分参数，能力调整空间大，但成本高，也可能破坏原有能力。

LoRA 等 PEFT 方法冻结基础模型，只训练少量新增参数，能够显著降低显存和模型存储成本。QLoRA 则把量化与 LoRA 结合，在低精度基础模型上训练适配器。

蒸馏：让小模型学习大模型

知识蒸馏使用 Teacher 模型为 Student 模型提供软标签、概率分布、中间表示或高质量生成数据，使较小模型学习较大模型的能力。

蒸馏适合高频、固定和对成本敏感的任务，例如分类、抽取、意图识别或垂直问答。但 Student 的能力上限仍受到模型容量、数据覆盖和 Teacher 质量约束。

量化：降低模型的推理成本

量化把 FP16、BF16 等高精度权重转换为 INT8、INT4 等较低精度表示，从而减少显存和推理成本。量化通常不增加新知识，精度过低还可能损害模型能力。

技术	是否学习新行为	是否需要训练	主要目的
预训练	是	是	获得通用基础能力
微调	是	是	适配领域、风格和任务
蒸馏	是	是	将能力迁移到更小模型
量化	否	通常不需要	降低显存、延迟和成本
RAG	不改变参数	否	动态补充外部知识

十二、主流开源软件分别适合做什么

AI 开源生态已经形成从训练、推理到 RAG 和 Agent 编排的完整工具链。选择开源项目时，应该关注其技术边界，而不是把 Star 数量当作唯一指标。

方向	代表项目	主要用途与特点
模型训练与加载	Transformers、PEFT	模型加载、训练、LoRA 和多模态任务适配
推理服务	vLLM、Ollama	高吞吐模型服务或本地模型运行
Agent 编排	LangGraph、AutoGen、CrewAI	状态图、长任务和多 Agent 协作
可视化 AI 应用	Dify、Flowise	快速搭建知识库、工作流和 Agent 应用
RAG 框架	RAGFlow、LlamaIndex、Haystack	文档解析、索引、检索和问答链路
向量数据库	Milvus、Qdrant	向量存储、过滤和相似度检索
Java AI 开发	Spring AI、LangChain4j	把模型、RAG 和 Tool Calling 接入 Java 应用
可观测性	Langfuse	Trace、Prompt、成本和评测管理

LangGraph 更偏底层的有状态编排，适合需要显式控制循环、状态和检查点的 Agent；Dify、Flowise 更适合可视化搭建和快速交付；RAGFlow 强调文档理解与 RAG 链路；Spring AI 和 LangChain4j 更方便 Java 团队复用现有工程体系。

没有一个框架能自动解决所有问题。最终效果仍然取决于模型选择、数据质量、上下文设计、工具可靠性、安全边界和评测体系。

十三、企业落地真正困难的不是接入模型

完成一次模型 API 调用并不困难。真正困难的是让系统在权限、异常和成本约束下长期稳定运行。

图7：企业级 Agent 需要把动态推理放进权限、状态、验证与审计边界。

生产级 Agent 至少要解决以下问题：

1. 权限：模型不能绕过用户和业务系统的真实权限；
2. 安全：外部网页、文档和工具结果都可能包含提示注入；
3. 状态：长任务必须支持暂停、恢复、重试和取消；
4. 验证：任务完成应由业务规则或环境结果确认，而不是由模型自我宣布；
5. 幂等：重复调用不能导致重复付款、重复发信或重复写数据；
6. 可观测：必须记录完整执行轨迹、耗时、Token 和工具结果；
7. 评测：既要评最终结果，也要评工具选择、参数、权限和执行路径；
8. 人机协同：删除、付款、发布和修改生产配置等操作应默认进入审批。

智能体平台的价值，正是把这些分散的能力变成可编排、可复用和可治理的工程底座。例如，云程智能体开发平台可以将多模型、企业知识库、MCP 工具、Skill、工作流、人工审批和运行日志放入同一个开发与治理体系，让团队不必为每个 AI 场景重复建设基础设施。

这类平台不应替代企业原有业务系统，而应作为模型能力与业务系统之间的协调层：向上承接应用，向下连接模型、知识和工具，同时保留清晰的权限与审计边界。

十四、一个企业经营分析 Agent 是怎样运行的

假设用户要求“生成本月重点客户经营分析报告”，系统可以按以下方式运行：

1. 工作流读取用户身份、部门和数据权限；
2. Agent 加载经营分析 Skill，明确指标口径和报告模板；
3. RAG 检索企业制度、指标解释和历史报告；
4. 模型生成分析计划，并列出需要查询的数据；
5. 模型通过 Function Call 生成候选工具参数；
6. Runtime 完成权限校验后，通过 MCP 查询客户、订单和回款系统；
7. Agent 根据返回结果识别异常，并继续查询相关明细；
8. 程序化计算模块核对金额、同比和环比；
9. LLM 生成报告草稿和数据依据；
10. 工作流把高风险结论提交业务负责人审批；
11. 审批通过后输出报告，并保存 Trace、版本和数据来源。

如果分析任务进一步拆给财务 Agent、销售 Agent 和风险 Agent，主管 Agent 还可以通过 A2A 委派子任务并汇总 Artifact。

在这个例子中，没有任何一个组件可以单独完成全部工作。LLM 负责理解和判断，RAG 提供知识，Skill 提供方法，MCP 提供连接，Workflow 提供控制，Agent 提供动态决策，治理系统则确保结果可信。

十五、什么时候不应该使用 Agent

Agent 并不天然优于普通程序或固定工作流。

以下场景通常不适合首先使用高自主 Agent：

• 规则明确、步骤固定，可以用普通代码稳定完成；
• 对结果要求完全确定，无法接受概率性输出；
• 每个操作都具有高风险，却缺少人工审批机制；
• 没有可靠的 API、数据质量和权限体系；
• 无法建立评测集，也无法判断任务是否真正完成；
• 单次模型调用或简单 RAG 已经能够满足需求。

合理的技术路线是从最简单的方案开始：能用规则解决就先用规则，能用单次模型调用就不急于建立循环，能用固定工作流就不要过早引入多 Agent。只有当任务确实需要动态规划、环境反馈和异常恢复时，Agent 才能体现价值。

十六、如果只记住六句话

1. LLM 是推理和生成引擎，不是知识库、执行器或完整 Agent。
2. RAG 解决知识更新与溯源问题，微调解决行为适配问题，二者不能互相替代。
3. Function Call 描述调用意图，MCP 标准化工具连接，Skill 封装任务方法，A2A 连接多个 Agent。
4. CoT 用于多步推理，ReAct 用于边判断边行动，Plan-and-Execute 用于长任务拆解和重规划。
5. Workflow 追求可预测，Agent 追求灵活；生产系统通常需要二者结合。
6. 企业 AI 的最终竞争不是接入多少模型，而是能否把模型、数据、工具、流程、安全和评测组成可靠系统。