最近各种花里胡哨的技术，看得我眼花缭乱的。 抽空思考了LLM应用技术的本质内核，这里简单记录一下，以便后续展开实践。
LLM 发展线索以及技术地图
关于LLM技术的发展，经常看DL的论文都知道是起源与transformer相关的。LLM技术进入高速发展的阶段，我认为还是从GPT开始的，于是顺着研究的轨迹，我找到如下图的发展线索。
| 阶段 | 核心变化 |
|---|---|
| 2018--2020 | 通过预训练和 Scaling 获得通用语言能力，出现 In-context Learning |
| 2022 | Instruction Tuning + RLHF，使模型从"生成文本"变成"理解并执行指令" |
| 2023 | RAG、Function Calling、Code Interpreter 等让 LLM 开始连接外部知识和工具 |
| 2024 | 原生多模态成熟；Reasoning / Test-time Compute 成为新的能力增长方向 |
| 2025 | Reasoning 普及，并与 Tools 结合形成 Agent、Coding Agent |
| 2025--2026 | 重点从单一模型转向 Context、Skills、State、Harness、Runtime、Eval 等完整系统工程 |
LLM技术地图如下：
- 现代 LLM 技术栈可以概括为：Context + Model + Tools + Agent Runtime + Eval。
- 核心问题分别是：模型看到什么、模型如何推理、模型能调用什么、任务如何持续执行，以及系统如何被评估和控制。
- 技术地图关注的是 What：一个现代 LLM 系统由哪些技术模块组成；后面的 LLM 工程图则关注 How：这些模块在实际运行中如何协作。
核心概念
Context
- LLM 每次调用能够看到的全部信息，包括：System Prompt，用户输入，历史对话，RAG 检索结果，Memory，Skill 指令，Tool Result。
- 因此现代 LLM 工程很大一部分实际上是 Context Engineering：决定这一轮模型应该看到什么。
Reasoning
- 让模型在输出最终答案前使用更多推理计算。可以简单理解成： 普通模式： 输入 → 回答
Reasoning： 输入 → 推理 / 检查 / 修正 → 回答
RAG
- 从外部知识库中寻找相关内容，再加入 Context。 用户问题--->检索--->找到相关资料--->加入 Context--->LLM 回答
- RAG 解决的不是"模型能记多少"，而是：当前问题应该给模型看什么资料。
Tool Calling
- 模型负责决定调用哪个工具以及参数，程序负责真正执行。 LLM ---> call get_order(id=123) ---> 程序执行 API / DB---> Tool Result ---> LLM
- 核心原则：LLM 负责决策，程序负责执行。
MCP
-
MCP是一种标准化的 AI 与外部工具、数据源连接协议。可以粗略理解成：
LLM / Agent ---> MCP ---> Files / DB / GitHub / APIs / Tools
-
MCP 本身不会让模型变聪明，只解决连接和标准化问题。
Eval
- 用固定测试集衡量系统效果。
- 主要关注：任务成功率、Tool 调用正确率、输出正确率、延迟、Token / 成本
LLM工程图
现在大部分LLM产品，本质上都可以归结到这张图上：
其中：
- Context Builder：负责把 System Prompt、历史对话、RAG、Memory、Skills 等信息组合成当前输入。
- LLM：负责理解任务、推理，并决定直接回答还是调用工具。（基座模型，比如GPT, Deepseek）
- Tools：负责执行模型本身做不了的事情，比如搜索、数据库查询、Python、文件、浏览器、MCP 等。
- Agent / Workflow：控制整个执行过程，包括状态、路由、重试、人工审批、Sandbox 等。
- Eval / Tracing / Safety：属于外围保障，负责评估质量、记录运行过程、权限控制和成本管理。
LLM 工程的核心，就是构造合适的 Context，让模型进行决策，再通过 Tools 与外部世界交互，并由 Agent Runtime 控制整个过程。
Agent 基本原理
Agent很早其实就有研究，尤其是以前的符号主义盛行的时代。ABM建模技术也在管理学、复杂系统领域有着广泛的应用。如今的LLM时代，Agent得到了进一步的升华。跟以往技术不同，现代的Agent 可以理解成：能自己决定"下一步做什么"，并调用工具持续完成任务的 LLM 系统 。下面是Agent的示意图：
最近流行Loop Engineering ，Graph Looping ，Harness Engineering等等，各种花里胡哨的技术，看得让人头大。我这里简单整理了一下，如下表：
| 工程方向 | 主要解决什么问题 | 一句话理解 |
|---|---|---|
| Prompt Engineering | 指令怎么写 | 怎么跟模型说 |
| Context Engineering | 模型这次应该看到什么 | 给模型看什么 |
| Tool Engineering | 怎么连接 API、搜索、数据库、MCP 等 | 模型能做什么 |
| Loop / Graph Engineering | 怎么循环、分支、重试、并行、停止 | 任务流程怎么跑 |
| Harness / Runtime Engineering | 怎么组织 Agent 的工作方式，并让它稳定、安全地运行 | Agent 怎么工作、在哪里运行 |
| Eval / Observability | 怎么评估效果、记录 Trace、发现问题 | 怎么知道它好不好、哪里出错 |
Claude Code、WorkBuddy，以及 DeepSeek 最近开源的 Agent Harness，本质上都属于 Agent / Agentic System：它们以 LLM 为核心，通过 Context、Tools、Loop、State 和 Harness，让模型能够持续执行任务，而不只是进行一次问答。
提示词与Skills
我们现在直接使用主流 LLM 时，通常需要通过合适的 Prompt（提示词） 来描述任务、补充背景、规定输出格式和约束条件。Prompt 本质上是在回答一个问题：怎么把任务清楚地告诉模型。
但随着 LLM 能力提升，单纯依赖"写一个好 Prompt"已经不够。实际应用中更重要的是：
Prompt→ Context→ Skills→ Tools→ Agent
其中：
（1）Prompt：描述当前任务和要求
（2）Context：给模型提供完成任务所需要的信息
（3）Skills：把一类任务的经验、步骤、规则沉淀成可复用的说明
（4）Tools：让模型能够调用搜索、数据库、代码、文件等外部能力
（5）Agent：让模型持续执行、观察结果并决定下一步
很多 Skills 的核心实际上就是一个 SKILL.md 文件，其中包含：
（1）什么时候使用
（2）需要什么输入
（3）执行哪些步骤
（4）可以调用什么工具
（5）输出格式是什么
（6）遇到异常如何处理
因此可以简单理解为：
Skill ≈ 可复用、结构化、按需加载的 Prompt / Workflow
它不会改变模型本身的参数，而是通过向 Context 中加入更完整的任务说明，让模型在特定任务上表现得更加稳定。
从这个角度看，未来人与 LLM 的能力差距，未必只是"谁更会写一句提示词"，而更可能体现在：
谁更善于把问题描述清楚、提供正确的上下文、沉淀可复用的 Skills，并让模型合理使用工具完成任务。
也就是说，重点正在从单纯的 Prompt Engineering，逐渐转向更完整的 Context / Skill / Agent Engineering。
最后的提问
Q：有些人会觉得Agent的应用没啥东西，原理很简单，没必要去刻意学。怎么看待这种观点？
A：我觉得这个观点有一半是对的。
- Agent 的原理没多少东西，不需要"重学"；但 Agent 的工程能力值得学，因为难点已经从"让模型会做"转向"让模型稳定地做完"。
- Agent 易于 Demo，难于 Production。真正值得学习的不是 Agent 框架 API，而是 Context、Tools、Loop、State、Harness 和 Eval 等系统设计能力。