大模型服务（LLM Service）**是“大脑”

Agent（智能体）**是“带了手脚、感官且有自主意识的人”。

1. 核心定义的区别

• 大模型服务 (LLM Service)： 提供的是预测能力。你给它一段文字（Prompt），它还给你一段概率上最可能的后续文字。它本质上是一个无状态的、被动的“文本补全”接口。
• Agent (智能体)： 提供的是任务达成能力。它以大模型为核心决策引擎，具备规划（Planning）、**记忆（Memory）和工具使用（Tool Use）**的能力，能够自主执行复杂的工作流。

2. 开发维度的对比

维度	大模型服务开发 (LLM Dev)	Agent 开发 (Agent Dev)
关注点	调优 Prompt、参数控制 (Temperature等)、模型微调 (SFT)、RAG (知识库检索)	任务拆解逻辑、工具调用策略 (Function Calling)、反思机制、长期记忆管理
交互模式	单次往复： 用户提问 -> 模型回答	循环迭代： 目标 -> 思考 -> 行动 -> 观察结果 -> 修正 -> 完成
工具能力	仅限于处理文本/多模态信息	可以操作外部系统（如发邮件、查数据库、运行 Python 代码、控制机械臂）
复杂度	相对较低，核心是提高回答的准确度和速度	较高，需要处理中间步骤的失败、逻辑死循环、Token 消耗控制

大模型服务开发（LLM）

Prompt（提示词）调优

是指导人工智能（AI）模型生成特定文本、图像或执行任务的指令、疑问或陈述。它涵盖了任务、指令和角色等关键元素，旨在清晰表达用户意图。优质的Prompt能极大提高大语言模型（LLM）回答的准确性和有效性。

参数控制(Temperature等)

是大语言模型（LLM）中用于控制生成文本随机性、创造性和多样性的超参数。它通过调整模型预测下一个词（Token）的概率分布来工作。

1. Temperature 温度系数

• 取值 0~1，控制输出随机性
• 0.1~0.3：代码生成、医疗诊断、数据提取，追求零差错案例：生成 Python 排序算法，低温度可保证代码语法正确
• 0.7~0.9：文案创作、故事编写，追求创意
• 1.0：极限发散，易出现幻觉，生产环境禁用

2. Top-P/Top-K

• Top-K：仅从概率最高的 K 个词汇中选择案例：Top-K=5，模型只会在概率前五的词汇里生成，杜绝生僻错误词汇
• Top-P 核采样：累计概率阈值，如 Top-P=0.8，筛选概率总和 80% 的词汇
• 组合用法：低 Top-K + 低 Top-P，适配金融、法律等严谨场景

模型微调（SFT）

Prompt 无法满足需求时，通过私有数据微调模型，重塑模型认知

适用场景

通用模型无法适配专业格式，如电子病历结构化、法律文书撰写

实战案例

医院需要模型输出标准化病历：收集 10 万条标注好的专属病历数据，对基座模型微调后，模型可自动匹配医院专属字段、专业术语，无需复杂 Prompt 约束，输出稳定性远超普通提示词。

—————————————————————————————————

—————————————————————————————————

随着通用大模型（如 deepseek、Qwen、Baichuan）的发展，语言理解和生成的能力大幅提升。但在金融、医疗、法律等专业场景中，直接使用通用模型往往效果不佳。常见问题包括：

• 理解专业术语不到位

• • 例如将 EBITDA 误判为“营业收入”或与“净利润”混淆。
  • 建议在数据预处理阶段做同义词标准化，以统一术语描述。

• 生成内容存在事实性错误

• • 如误报企业财务数据或法规条款；
  • 可通过“自动 redact（脱敏）敏感信息”模块，确保不泄露或误报关键数据。

• 无法满足行业合规性要求

• • 生成的表述可能不符合金融披露规范，或遗漏必要的风险提示。

究其原因，通用大模型虽然掌握了大量公共知识，但缺乏对特定领域细粒度知识的深入建模。因此，需要通过监督式微调（SFT, Supervised Fine-Tuning），在小规模、专业化的数据上进一步优化模型，使其在特定任务和领域表现更好。

知识库检索(RAG)(Retrieval-Augmented Generation，检索增强生成)

是当前解决大语言模型（LLM）“知识过时”、“幻觉”、“私有数据无法访问” 三大核心问题的主流技术。

一、RAG 核心原理（一句话）

LLM + 外置知识库 = 准确、可溯源、可更新的回答

• LLM：负责理解问题、组织语言、推理（大脑）
• RAG 检索：负责查资料、找证据、给上下文（图书馆 / 搜索引擎）

为什么需要 RAG？

传统 LLM 有三大死穴：

1. 知识截止：训练数据是旧的（如 GPT-4 截止 2024 年初），不知道后来的事
2. 幻觉（Hallucination）：不懂就瞎编，看起来很真但完全错误
3. 无法访问私有数据：读不了你的企业文档、本地文件

RAG 就是给 LLM 装了 “实时、可查、可更新的外置硬盘 / 知识库”。

Agent 开发 (Agent Dev)

任务拆解逻辑

工具调用策略 (Function Calling)

反思机制

长期记忆管理

总结

针对你上传的图片（关于 LLM 开发与 Agent 开发对比表），希望我针对其中的**“关注点”**这一维度提供更详细、更深层的细节介绍。

针对这一个问题，我们梳理了以下核心内容：

• LLM 开发的深层关注点： 聚焦于如何通过 Prompt 结构化设计、参数精调、SFT 微调以及 RAG 检索策略来提升模型输出内容的质量和准确性。
• Agent 开发的深层关注点： 聚焦于复杂的任务拆解（Chain of Thought）、工具调用（Function Calling）的闭环处理、自我反思纠错机制以及长短期记忆的管理。
• 两者的本质区别： 总结了 LLM 开发侧重于“内容生成”，而 Agent 开发侧重于“任务闭环”与“工程编排”。

3. 一个直观的例子

假设你要开发一个“旅行助手”：

• 大模型服务版： 用户问：“去巴黎玩 3 天怎么安排？” 模型根据训练数据直接生成一份攻略。如果模型不知道明天的天气，它可能会编造（幻觉），或者告诉你它不知道。
• Agent 版： 用户说：“帮我订一套去巴黎的旅行方案，预算 1 万，要避开下雨天。” Agent 会这么做：

1. 1. 规划： 先查天气，再看机票，最后排行程。
   2. 行动（工具）： 调用“天气插件”发现后天有雨；调用“携程插件”查票价。
   3. 决策： 因为后天有雨，自主将室内博物馆行程调到后天。
   4. 反馈： 最终给用户一份基于实时信息的、可执行的预定链接。

4. 总结：两者的关系

大模型服务是 Agent 的“大脑”。

• 如果没有强大的 LLM，Agent 就会因为逻辑混乱而无法完成复杂的规划。
• 如果没有 Agent 框架（如 LangChain, AutoGPT, CrewAI），LLM 就只能永远待在对话框里“纸上谈兵”

目前的趋势： 开发者正在从单纯的“调教 Prompt”转向“构建 Agent 系统”。因为纯 LLM 只能解决“知不知道”的问题，而 Agent 才能解决“能不能做”的问题。