大模型与 AI 应用核心概念全解

目录

• 1. 基础概念
  • 1.1 专有名词解释
  • 1.2 核心技术逻辑关系
• 2. 大模型 LLM 介绍
  • 2.1 大模型能力的底层支柱
  • 2.2 核心特征
  • 2.3 发展历程
  • 2.4 大模型分类
• 3. 提示词 Prompt
  • 3.1 核心目标
  • 3.2 Prompt 提示词类别
  • 3.3 提示词公式
  • 3.4 进阶技巧
  • 3.5 避坑指南
• 4. RAG（检索增强生成）技术
  • 4.1 专有名词解释
  • 4.2 解决问题
  • 4.3 RAG 工作全流程
  • 4.4 核心流程拆解（六步法）
  • 4.5 避坑指南
• 5. 大模型接入方式
• 6. 模型记忆与 Context
• 7. 分词器 Tokenizer
  • 7.1 生成原理
  • 7.2 Token 的定义
  • 7.3 缓存命中与 Token 计费
• 8. Tool、MCP、CLI
  • 8.1 Tool（工具/函数）
  • 8.2 MCP (Model Context Protocol)
  • 8.3 CLI (Command Line Interface)
• 9. 高阶智能形态：Agent 与 Agent Skill
  • 9.1 Agent - 智能体
  • 9.2 Agent Skill - 智能体技能
• 10. Harness Engineering
  • 10.1 技术演进：从 Prompt 到 Harness
  • 10.2 OpenAI 的实战案例：5 个月写百万行代码
  • 10.3 Anthropic 的实战案例：F-Harness 架构
  • 10.4 总结

1. 基础概念

• 1.1 专有名词解释

• AI (Artificial Intelligence) - 人工智能：最广泛的概念，旨在让机器变得聪明，能够像人一样思考、学习和做事。
• AGI (Artificial General Intelligence) - 通用人工智能：行业的终极目标，指造出像人一样聪明的 AI，能胜任人类所能做的各种智力劳动。
• ML (Machine Learning) - 机器学习：实现 AI 的核心方法。不同于传统程序，机器学习是让电脑从海量数据中自动找规律、学经验。
• DL (Deep Learning) - 深度学习：机器学习的升级版，模拟人脑的神经网络结构，能处理更复杂、更深层的信息（如复杂环境下的人脸识别、语音识别）。
• LLM (Large Language Model) - 大语言模型：目前深度学习最热门的产物。它是通过阅读全网文章、书籍资料训练出来的超大 AI 模型，能听懂对话、写文章并解决复杂问题（如 ChatGPT、通义千问等）。
• Transformer (2017)：大模型的底层基座。在它出现之前，AI 处理长文本和长句子的效果较差；它的诞生解决了这一核心难题，使得训练超大规模模型成为可能。
• 基座模型 (Foundation Model)：支持搭建无数种不同的 AI 应用的模型。
• 多模态 (Multimodality)：使大模型从只能看文字的“瞎子”，进化为拥有视觉（图像、视频）和听觉（音频）能力的智能体。
• AI Agent (智能体)：AI 发展的进阶形态。它从被动执行指令的“执行者”，转变为能独立思考、规划路径并自行寻找工具干活的“贴身助理”。

• 1.2 核心技术逻辑关系

AI（目标）：造出聪明的机器。
ML（路径）：实现AI的方法，让机器自己学。
DL（分支）：ML中最管用、最核心的分支。
LLM（产物）：DL发展到现阶段的最先进成果，也是大众目前接触到的大模型。

2. 大模型 LLM 介绍

• 2.1 大模型能力的底层支柱

• 极大规模的参数量：大模型拥有十亿级甚至万亿级的参数量。这些参数构成了极其复杂的逻辑网络，使其具备了处理极高复杂度任务的“脑容量”。

• 全人类知识的预训练：与传统 AI 针对特定数据集训练不同，大模型在发布前已完成了对全网公开文章、书籍、图片、视频等海量数据的深度学习。

• 2.2 核心特征

• 泛化能力：大模型不再依赖程序员预设的固定模板，而是凭借对海量知识和语言逻辑的理解，实现举一反三。这种能力极大降低 AI 的应用门槛。企业不再需要为每一个细分业务场景定制模型，只需通过简单的指令（Prompt）引导，同一个大模型就能胜任行政、财务、文案等多个岗位的工作。

• 涌现能力：当模型规模达到临界点时，会出现量变引起质变的现象，自发解锁许多未经程序员预设的能力。这是大模型与传统 AI 的分水岭。
  “涌现”意味着 AI 开始具备初步的推理和逻辑构建能力。这种非线性的能力增长让 AI 具备了解决未知问题的潜力，也是通向 AGI（通用人工智能）的关键。

• 2.3 发展历程

大模型发展的三个关键阶段

• 从奠基到全球爆红 (2017-2022)：
  技术突破：从 Transformer 的诞生到 GPT-3 验证了“模型规模（1750 亿参数）决定潜力”的逻辑，证明了大模型可以胜任翻译、写作、编程等上百种任务。
  ChatGPT 的发布打破了科技圈与普通人的壁垒，开启了全人类真实接触 AI 的序幕。
• 能力进化与交互升级 (2023-2024)：
  大模型进入多模态时代，感官延伸，能够理解并生成图片和视听内容。
  行为逻辑方面进入智能体（Agent）时代，AI 开始具备自主规划能力，能根据模糊的目标自动拆解步骤并完成任务。
• 深度融入实体经济 (2025+)：
  大模型走出办公室和互联网，成为农业、医药研发等传统产业升级的核心驱动力。

2.4 大模型分类

• 通用大模型：具备广泛的知识和能力，能够处理多种任务，如 GPT 等
• 垂直领域大模型：针对特定行业或领域进行优化，如医疗、法律等领域的大模型。
• 多模态大模型：可处理文本、图像、语音、视频等多种模态数据，实现跨模态的理解与生成。
• 单模态大模型：仅处理单一类型的数据。

3. 提示词 Prompt

3.1 核心目标

提示词（Prompt）工程的核心目标是消除歧义，精准对齐预期。

人类语言充满模糊与省略，而 AI 的逻辑底层是基于海量数据的概率预测，而非真正具备人类的共情或长时推理能力。
提示词工程本质上是将模糊的需求，翻译成 AI 能听懂并执行的精准指令。
点餐比喻：最基础的提示词（Prompt）像“我要吃鱼香肉丝”，而提示词工程则是研究如何写出一份包含口味（少盐）、忌口（不要香菜）和规格（配米饭）的精细点餐单。

3.2 Prompt 提示词类别

Prompt Engineering（提示词工程）：研究如何把话说明白，让模型更精准地理解意图。
User Prompt（用户提示词）：用户在对话框直接输入的具体任务。
System Prompt（系统提示词）：开发者在后台配置的，用来设定模型人设和做事规则（例如：你是一个耐心的数学老师，不要直接给答案）。

3.3 提示词公式

提示词万能公式：Role - Task - Context - Constraint - Format
要让 AI 输出高质量结果，需遵循“角色 + 需求 + 背景 + 约束 + 输出格式”的组合。

• 角色 (Role)：赋予 AI 特定身份（如“10 年经验的旅游博主”），让其站在专业视角思考，输出会更地道。
• 需求 (Requirement)：明确具体目标（如“规划三天两晚的xx旅游攻略”），不能含糊。
• 背景 (Background)：提供关键的上下文信息（如“两人从 xx 出发，预算 1500 元”），辅助 AI 进行逻辑判断。
• 约束 (Constraint)：设定规则与边界（如“主打美食体验，不要赶景点”），避免 AI 给出不符合实际需求的通用方案。
• 输出格式 (Format)：规定结果的呈现样式（如“以包含费用对比的表格形式呈现”），直接省去后期整理工作。

3.4 进阶技巧

• 思维链 (Chain of Thought, CoT)
  核心：引导 AI “一步步思考”，要求其先给出推理过程，再得出结论。
  应用：例如在处理复杂数学题或业务逻辑分析时，通过显性化的推理路径，可以显著降低大模型的“幻觉”现象，提升答案准确率。
• 少样本提示 (Few-shot)
  核心：给 AI 提供 1-2 个高质量的范例。
  延伸：当企业需要 AI 模仿特定的品牌调性或公文格式时，单纯的描述往往不够精准，提供“榜样”能让模型迅速实现风格对齐，减少反复修改的成本。
• 反问法 (Self-Verification) - 交叉验证
  核心：要求 AI 进行自我校验，从多维度审视结论是否合理、是否有遗漏。
  应用：这相当于引入了“交叉验证”机制，使 AI 从单纯的指令执行者转变为具备初步质量把控能力的智能助手。这种交叉验证可以扩展到使用不同的大模型来进行验证，互相纠正。

3.5 避坑指南

• 拒绝模糊描述：避免使用“好一点”、“专业一点”、“生动一点”等主观且无标准的形容词。
  改进：使用可量化的标准，如“使用短句”、“分三点陈述”、“加入具体数据”。
• 一事一求（任务原子化）：不要试图在一个提示词里让 AI 同时完成周报、数据分析和活动方案。保证一个提示词只解决一个核心问题，确保 AI 的注意力和计算资源集中。
• 背景先行：不给背景只给需求（如：写份推广文案，但不说产品和受众），AI 只能产出毫无价值的空话。
• 尊重能力边界：不要强求 AI 提供实时的股市波动、最新新闻，或要求其执行违法及超出逻辑计算极限的任务。
• 语言规范化：避免中英文随意切换或语法混乱，这会显著增加 AI 的理解成本，降低准确率。

4. RAG（检索增强生成）技术

4.1 专有名词解释

• RAG (Retrieval-Augmented Generation) - 检索增强生成系统：通过为大模型挂载一个外部“知识库”，让模型在回答问题前先去库中查找相关资料，从而实现精准回答。
• 知识边界 (Knowledge Boundary)：指通用大模型训练数据的截止时间点，以及其无法获取的企业或行业内部非公开数据。
• AI 幻觉（AI Hallucination）：大模型在缺乏事实依据时“张口就来”、胡编乱造虚假信息（如虚构法条或产品参数）的现象。
• 文本切割/拆分 (Text Chunking)：将长文档切分为一个个独立、语义完整的小段落，以便系统精准定位信息。
• 向量化 (Vectorization/Embedding)：利用模型将文本转换为一串数字（向量），作为文本的“数字身份证”，使计算机能通过数学计算理解语义。
• 向量数据库 (Vector Database)：专门用于存储和检索这些“数字身份证”的高性能数据库，是专属知识库的底层底座。
• Top-K 检索：在知识库中按照语义相似度排序，只提取出与问题最相关的前 K 个文本片段，而非全盘读取。
• 混合搜索 (Hybrid Search)：结合“语义搜索”与传统的“关键词搜索”，互补短板，极大提升检索准确率。
• 嵌入模型 (Embedding Model)：负责给资料和问题生成“语义二维码”（标签），其准确性直接决定了能否找到正确的资料。
• 分块策略 (Chunking Strategy)：决定如何将原始文档拆分成小卡片，直接影响知识点的完整性和查询精度。

4.2 解决问题

• 根治幻觉：答案全部来自于你提供的资料，有出处，可溯源。
• 知识实时更新：不需要重新训练大模型，更新资料库后，它就能立即掌握新知识。
• 使用私人资料：完美适配个人、公司、家庭资料，提供专属精准回复。

4.3 RAG 工作全流程

4.4 核心流程拆解（六步法）

RAG 的完整运行流程总结为以下六个步骤：

• 文档收集与整理：收集产品手册、故障处理方案、内部规章等核心业务资料。
• 拆分与向量化建库：将文档切分成片段并转为向量数据，搭建结构化的专属知识库底座。
• 用户提问向量化：将用户的自然语言实时转换为与知识库统一标准的向量格式。
• 相似度检索匹配：通过算法在库中精准找到与问题最相关的片段（Top-K 检索）。
• 提示词封装与生成：将检索结果与原始问题整合成标准提示词，引导 AI 有据可依地作答。
• 动态更新与迭代：支持随时更新或修改文档，使 AI 能力随知识库同步升级。

4.5 避坑指南

• 资料拆分不当：按语意拆分，确保每个分块是完整知识点。
• 仅依赖语义检索：应结合关键词搜索，特别是针对专有名词和数字。
• 一次性召回太多：资料过多会干扰模型，需控制核心资料数量。
• 未给模型设定规则：必须在指令中明确要求模型严禁编造。
• 原始数据不干净：导入前必须进行文档清洗，剔除乱码和冗余信息。

总结：细节决定成败，文档清洗、分块策略、检索方式、Prompt 规则，每一步都需要做好。

5 大模型接入方式

• 5.1. Web 页面直接使用
  通过官网或应用界面使用，比如 ChatGPT、Claude、Gemini、通义千问、豆包、Kimi、文心一言等。
  适合：个人使用、写作、问答、学习、临时分析。
  特点：门槛最低，但自动化和系统集成能力有限。
• 5.2. API Key 接入
  通过模型厂商提供的 API Key，把大模型能力接入自己的应用或业务系统。
  适合：开发 App、客服系统、知识库问答、Agent、自动化流程。
  特点：灵活、可集成、按量计费，但需要开发能力。
  接入方式可参考：https://blog.csdn.net/weixin_49263546/article/details/162349358?spm=1001.2014.3001.5501
• 5.3 云平台托管接入
  通过云厂商平台使用大模型，例如模型市场、AI Studio、Bedrock、Azure AI、阿里云百炼、火山方舟、腾讯混元平台等。
  适合：企业应用、统一权限管理、模型治理、合规部署。
  特点：通常提供模型选择、密钥管理、监控、限流、私有数据接入等能力。
• 5.4 开源模型本地部署
  下载开源模型，在本地服务器、个人电脑或私有云中运行。
  常见模型包括 Llama、Qwen、DeepSeek、Mistral、Yi 等。
  常见工具包括 Ollama、vLLM、LM Studio、llama.cpp、Text Generation WebUI。
  适合：数据隐私要求高、成本可控、需要定制化部署的场景。
  特点：数据可控，但对硬件、运维和模型调优有要求。
• 5.5. 私有化 / 专有化部署
  企业把模型部署在自己的内网、私有云或专属云环境中。
  适合：金融、政务、医疗、能源、大型企业内部系统。
  特点：安全性和可控性更强，但成本高，部署周期长。
• 5.6 RAG 知识库接入
  把企业文档、数据库、网页、PDF 等资料接入检索系统，再让大模型基于检索结果回答。
  适合：企业知识库、客服问答、制度查询、文档助手。
  特点：比直接微调更轻量，知识更新方便。
• 5.7 微调 / 训练后接入
  在基础模型上用自己的数据进行微调，让模型更适合特定任务、语气或领域。
  常见方式包括 SFT、LoRA、DPO 等。
  适合：垂直行业模型、特定风格生成、专业任务优化。
  特点：效果更定制，但需要数据、算力和评估能力。
• 5.8 Agent 框架接入
  通过 LangChain、LlamaIndex、Dify、Coze、AutoGen、CrewAI 等框架，把大模型接入工具、工作流、知识库和外部系统。
  适合：自动化任务、智能客服、数据分析助手、办公助手。
  特点：模型不只是回答问题，还可以调用工具、执行步骤、完成任务。

6 模型记忆与 Context

Context（上下文）：大模型本质上没有人类那样的长久记忆，它通过将之前的对话历史随新问题一起发送来实现“记忆”。
Context 即模型处理任务时接收到的信息总和，可看作其临时记忆体。
Context Window（上下文窗口）：代表 Context 能容纳的最大 token 数，即模型一次能处理的数据量。

7 分词器 Tokenizer

7.1 生成原理：

大模型的本质是一个“文字接龙游戏”。它通过接收输入，预测下一个概率最高的词（token），然后将该词追加到输入中再次预测，直到输出结束标识符。

• Tokenizer - 分词器：由于大模型本质是运行矩阵运算的数学函数，只认识数字而不认识文字，因此需要 Tokenizer 作为“翻译官”，实现人类语言向机器数字的高效转化与压缩。
• 编码 (Encoding)：将文字切分成最小片段（Token），并映射为数字（Token ID）。
• 解码 (Decoding)：当模型计算完毕吐出一个 Token ID 后，Tokenizer 再次登场，通过单步的映射操作将数字转回文字输出。

7.2 Token 的定义

模型处理文本的最小单位。
它与词并不一定是一对一关系，例如“程序员”可能被切分为“程序”和“员”两个 token。平均而言，1 个 token 约等于 0.75 个英文单词或 1.5 到 2 个汉字。

• 换算比例
  如果只用单字作为 Token，效率极低。通过将常见词组（如“人工智能”）合并为一个 Token，可以大幅减少模型需要处理的输入量，从而提高模型的推理速度和效率。
  换算比例：
  1 个 Token 大约代表 1.5 到 2 个汉字。
  1 个 Token 大约代表 0.75 个英文单词（或 4 个英文字母）。
  例如以 GPT-4 的 40 万 Token 窗口为例，这实际上意味着它一次能处理大约 60 到 80 万个汉字。

7.3 缓存命中与Token计费

“缓存命中”的关键在于前缀匹配，而不是任意位置的重复。在 Token 消耗计算上，费用是按照输入 Token 是否命中缓存来分开计算的。

• 匹配规则：系统只会检查当前请求的输入内容，是否从第 0 个 Token 开始就与之前某个请求的前缀完全一致。如果相同，这部分内容就算是“命中”了缓存；如果只是中间或后面有重复，是无法命中的。

• 缓存单元：缓存内容会被切分成独立、完整的“前缀单元”进行存储和匹配。要命中缓存，必须完整匹配上这样一个前缀单元。此外，缓存系统通常以一定数量 Token（如 64 个）为最小单位，不足的部分可能不会被缓存。

• 例如：
  会命中：第一次问了“A + B”，第二次“A + B + C”。第二次请求的输入开头正好是“A + B”，与第一次的完整内容完全一致，所以“A + B”这部分就能命中缓存。
  不会立即命中，但为未来做准备：第一次问了“A + B”，第二次“A + C”。虽然第二次请求的开头“A”和第一次的开头“A”相同，但后缀“B”和“C”不匹配，所以第二次请求不会命中。但此时系统会识别出公共前缀“A”并将其落盘缓存。当第三次请求“A + D”来时，就能命中“A”这部分。

提示：缓存系统是“尽力而为”的，不保证100%命中。不再使用的缓存会在几小时到几天内被自动清空。

• API 返回的用量明细：
  在每次 API 调用的返回结果里，usage 字段会明确告诉你输入 Token 的构成：
  prompt_cache_hit_tokens：本次请求的输入中，命中缓存的 Token 数量。
  prompt_cache_miss_tokens：本次请求的输入中，未命中缓存的 Token 数量。
  费用计算公式：总输入费用 = (命中缓存 Token 数 × 缓存命中单价) + (未命中缓存 Token 数 × 标准输入单价)。输出 Token 的费用则按标准输出单价另行计算。
  以某模型为例：
  

8 Tool、MCP、CLI

8.1 Tool（工具/函数）

大模型无法直接感知实时环境（如查询天气），需要通过“工具”这一本质为函数的接口来获取外部数据。
交互流程：用户提问 → 平台转发给模型 → 模型选择工具并生成调用指令 → 平台执行工具函数 → 平台将结果回传给模型 → 模型总结并回答用户。其中，模型负责选择工具和归纳，平台负责串联流程。

8.2 MCP (Model Context Protocol)

• 定义及核心价值
  模型上下文协议（Model Context Protocol）：
  MCP 是 Anthropic 在 2024 年 11 月发布的一种开放协议，旨在解决大模型与外部工具之间通信标准不统一的问题。
  
  核心价值：大模型本身只能进行问答，无法直接操作外部世界。MCP 的出现相当于为大模型提供了“手和脚”，使其能够使用浏览器上网、操作本地文件、查询实时路况或调用各类 API。
  主要角色：
  1、MCP Host：支持 MCP 协议的软件或平台（如 Cline、Cursor、Claude Desktop、Cherry Studio），负责管理和调度工具。
  2、MCP Server：具体的工具提供程序（通常由 Python 或 Node 编写）。它并不一定是一个远程服务器，本质上是一个符合 MCP 规范的本地程序。
  核心组件：工具 (Tools)
  本质：在 MCP 领域，工具（Tool）本质上就是编程语言中的“函数”。它是一个执行特定任务的机器，接收输入（参数），按规则处理后给出输出（结果）。
  描述机制：
  Server 通过 JSON Schema 规范向 Host 描述工具的名称、用途及参数要求。这包含在函数的装饰器和注释（Docstring）中，帮助模型理解何时以及如何调用该工具。
• 工作原理与交互协议
  通信方式：目前市面上大部分 MCP Server 采用 stdio（标准输入输出） 与 Host 沟通。
  交互步骤：
  1、初始化：Host 与 Server 互相“打招呼”，确认协议版本和软件信息。
  2、工具发现：Host 询问 Server 拥有哪些工具，Server 返回包含工具功能描述的列表。
  3、执行调用：当模型决定使用某个工具时，Host 向 Server 发送调用请求及参数，Server 运行对应的函数并回传结果。
  协议本质：
  MCP 协议仅规定了 Host 与 Server 之间的沟通（如何发现和调用函数），并不强制要求模型如何与 Host 交互。

MCP 通过提供可调用的函数环境，让模型能够感知和操作外部的“上下文”。理解了 MCP，就理解了如何构建一个能够持续思考、自主调用工具并解决复杂任务的 Agent（智能体）。

8.3 CLI (Command Line Interface)

CLI (Command Line Interface) - 命令行界面：
指通过输入一行文本指令来执行程序的工具（如 FFmpeg、grep、ImageMagick 等）。由于主流 CLI 工具（如 git、grep）在训练阶段已被模型“内化”，模型无需查看文档也能直接写出用法。对于冷门工具，则可通过 Agent Skill 提供一份说明文档来解决。

• 优势：

1. 只需向模型提供一个极简的 bash 工具说明（约十几行），核心指令仅需模型生成一行命令即可。
2. 相比 MCP 执行效率极高：
   MCP 的瓶颈：大模型是整个链路的“调度中心”。每执行一步（如：读目录 → 读图片信息 → 处理 → 上传），数据都必须回传给大模型进行下一次思考和决策，导致效率卡在模型响应速度上。
   CLI 的链式执行：模型只需思考一次，生成一条包含管道符和逻辑判断的长命令（如：find | ImageMagick && scp），本地系统即可自动跑完所有步骤，无需模型中途参与，更省 Token。

• CLI 风险：
  模型可能误操作（如执行 rm -rf）或在共享云端环境中破坏服务器集群

• 应用场景：
  个人/轻量化场景：推荐使用 CLI。它更快、更便宜、更直接，能够灵活组合参数解决多变的个人需求。
  企业/云端场景：推荐使用 MCP。它在安全性和稳定性上的表现无可替代，是结构化、受限调用的首选。
  CLI 走向个人，MCP 留在企业。
  

9 高阶智能形态：Agent 与 Agent Skill

9.1 Agent - 智能体

AI Agent（人工智能体）是在大模型热潮下兴起的一个核心概念。它将大模型作为“大脑”，通过连接外部工具作为“感官和四肢”，从而能够感知并改变外界环境，独立完成复杂任务。

1、 核心定义：大模型 + 工具
Agent 的本质：当大模型连接上对应的工具（如读写文件、运行终端命令、浏览器搜索等）后，就变成了 Agent。
形象比喻：大模型仅是“大脑”，而 Agent 是一个具备感官和四肢的“机器人”，能够自主查询文件、写入代码并运行，整个过程无需人工插手。

2、主流运行模式：ReAct (Reasoning and Acting)
ReAct 是目前使用最广泛的 Agent 运行模式，其核心在于思考与行动的循环。

• 运行流程：
  Thought（思考）：大模型先分析用户任务，决定是否需要调用工具。
  Action（行动）：如果需要，模型会请求调用特定的工具（如读取文件）。
  Observation（观察）：Agent 主程序执行工具并返回结果（如文件内容或报错信息）给模型。
  循环与结束：模型基于观察结果再次思考，重复上述步骤，直到认为信息足够，输出 Final Answer（最终答案）。
• 实现机制：
  ReAct 模式主要通过系统提示词（System Prompt）实现。提示词规定了模型的角色、必须遵守的规则（如使用特定 XML 标签输出思考和行动）以及环境信息。

3、进阶构建模式：Plan and Execute（规划与执行）
对于更复杂的任务，Agent 会采用“先规划再执行”的模式，这种模式引入了动态调整机制。

• 角色组成：
  Plan 模型：负责将任务分解为具体的执行步骤。
  执行 Agent：负责完成计划中的每一个具体步骤（其内部可能就是一个 ReAct 模式的 Agent）。
  Re-plan 模型：根据每一步的执行结果，动态调整剩余的计划。如果任务已完成，则输出最终答案。
  Agent 主程序：负责串联以上模块的逻辑逻辑。
• 优势：
  相比单纯的循环，这种模式能够根据中间结果及时更正方向，处理更具不确定性的任务。

9.2 Agent Skill - 智能体技能

Agent Skill 是由 Anthropic 公司于 2025 年推出的技术，现已演变为 AI Agent 领域的一种跨平台、跨产品的通用设计模式。它本质上是一个大模型可以随时翻阅的**“说明文档”**，旨在教导模型在特定场景下如何处理任务。

• 核心定义与组成结构
  Agent Skill 将复杂的指令从对话中剥离，存储为特定的文件结构，避免用户在每次对话中重复粘贴长段要求。
  文件组织：每个 Skill 对应一个文件夹（文件夹名即 Skill 名），核心文件是 skill.md。
  skill.md 的双层结构：
  元数据层 (Metadata)：包含 name（名称）和 description（描述）。描述部分主要用于向模型说明该 Skill 的用途，作为模型选择工具的依据。
  指令层 (Instruction)：详细描述模型需要遵循的规则，并通常包含示例（Example）以确保模型准确理解输出格式。
• 三层渐进式披露机制 (Progressive Disclosure)
  这是 Agent Skill 的核心机制，通过分层加载来极大节省模型的 Token 消耗。
  元数据层（常驻加载）：大模型在回答前会先查看所有已安装 Skill 的名称和描述。这相当于一份“轻量级目录”，模型据此判断用户问题是否归某个 Skill 管。
  指令层（按需加载）：只有当模型判断用户问题与某个 Skill 匹配时，才会读取该 Skill 的完整 skill.md 正文。其他未选中的 Skill 内容不会被加载。
  资源层（按需中的按需）：包含更深层的参考资料或脚本，只有在满足特定触发条件时才会被调用。
• 高级功能：Reference 与 Script
  为了处理更复杂的业务逻辑，Agent Skill 提供了两种进阶能力：
  Reference（参考资料）：
  定义：指外部的参考文档（如财务手册、法律条文）。
  特性：条件触发。只有当模型读取了指令层并判断需要查阅相关资料时，才会向用户申请读取该文件。
  影响：文件内容会被加载到上下文中，因此会消耗 Token。
  Script（脚本/代码）：
  定义：允许 Skill 运行代码（如 Python 脚本）来执行实际任务。
  特性：只跑不读。大模型只关心脚本的运行方法和结果，而不会读取脚本内部成千上万行的具体逻辑。
  影响：由于代码不进入上下文窗口，其消耗的 Token 几乎为零。
  Agent Skill 的设计理念是**“授人以鱼不如授人以渔”**：MCP 负责把“鱼”（数据）搬过来，而 Agent Skill 负责教会模型“怎么做鱼”（处理逻辑）。

10 Harness Engineering

10.1 技术演进：从 Prompt 到 Harness

大模型应用技术的三个阶段，它们之间的研究范围不断扩大，层层递进：

• 提示词工程 (Prompt Engineering)：
  核心：研究“怎么把话说清楚”。
  方法：通过调整提示词，为模型提供更精准的需求描述（例如不仅要求给猫起名，还指定花色和性格要求）。
  现状：随着模型能力的增强，单纯研究提示词的门槛正在降低。
• 上下文工程 (Context Engineering)：
  核心：研究“怎么给信息”，即在有限的容量上限内，如何把最合适的内容放进 Context 中。
  技术：包含对话历史管理、上下文压缩、动态检索外部资料等。
• Harness Engineering（马具工程）：
  核心定义：研究“如何搭系统”。如果把大模型比作一匹强壮的烈马，Harness（马具）就是套在马身上、用来控制和驾驭它的整套系统。
  核心公式：Harness = Agent（智能体） - Model（大模型）。即一个完整的智能体中，除了大模型本身，剩下的所有控制逻辑、工具、规则和调度机制都是 Harness。

10.2 OpenAI 的实战案例：5 个月写百万行代码

OpenAI 在 2024 年进行了一项实验，由 3 到 7 人的小团队主导，让 AI 从零开始编写一个真实的、拥有百万行代码规模的生产系统，其开发效率达到了人工的 10 倍。其核心优化点分为三类：

• 上下文管理 (Context Management)：
  从厚到薄：放弃将所有规则塞进一个巨大的 Agent.md 文件（会导致模型迷失），转而将其压缩成约 100 行的目录索引，用到哪块再给模型看哪块。
  唯一事实来源：强制要求将散落在聊天记录、文档中的重要决策全部搬进代码仓库，让仓库成为 AI 唯一的参考依据。
• 验证与反馈 (Validation & Feedback)：
  赋能验证：为 AI 配置 Chrome 开发者工具、可观测性工具等，让它能自主截图、检查 UI、读取日志并原地修复 Bug。
  自动闭环：利用 Lint 和测试进行代码检测。若不合规，报错信息自动发回给 AI 修改，直至通过，全程无需人工干预。
• 技术债清理 (Technical Debt Cleanup)：
  后台自动维护：设置后台任务定期扫描代码库和文档库，自动修复重复代码或过时的文档，确保系统质量始终在高水准。

10.3 Anthropic 的实战案例：F-Harness 架构

Anthropic 提出了针对长时运行 Agent 的 Harness 设计，核心在于解决“急于求成”和“自卖自夸”的问题：

• 任务规划 (Planner)：
  引入 Planner（规划者） Agent。它负责将用户模糊的需求拆解为详细的功能列表。执行者 Agent 只需要按列表“稳扎稳打”，做完一个标记一个，避免中途因上下文满载而导致任务丢失。
• 独立评估 (Evaluator)：
  拒绝自评：Agent 自己评估自己的产出往往有“滤镜”。Anthropic 引入了独立的 Evaluator（评估者） Agent 进行第三方客观评审。
• F-Harness 流程：
  包含 Planner（规划）、Generator（生成） 和 Evaluator（评估） 三者协作。Generator 针对每个功能点与 Evaluator 讨论标准、提交结果、反复修改，直至通过。
  代价与效果：相比单 Agent 方案（Solo），F-Harness 耗时和花费更高，但产出质量达到了可商用的水平。

10.4 总结

目前行业内对 Harness Engineering 是否为炒作存在争议：
质疑观点：它使用的技术（如 Lint、任务拆解、评估机制）都不是新的，只是“新瓶装旧酒”。且随着模型能力的提升（如 Opus 3.6 的全局统筹能力），原本需要的复杂 Harness 限制正在被模型自身吸收。
而我认为，Harness Engineering 是一个过渡期的关键技术。在当前模型依然会犯错、有幻觉的现实下，它是将 AI 能力转化为生产力最现实的答案。软件工程师的核心职责正在从亲手写代码，转变为为 Agent 搭建稳定可靠的 Harness 系统，重塑软件开发流程。