Agent 核心概念

一个可用的 Agent 必须包含哪几个部分？

必须有以下三大部分： LLM、Tool、Context。

其中，LLM 负责工作决策；Tool 由 LLM 决策调用，增强 LLM 功能；Context 构建 LLM 工作上下文。

前两者自不必说，很多人实际上忽略了 Context 的重要性，这一部分甚至可以排在三者中最重要的地位，在 LLM 高度依赖 AI 厂商提供的 API、Tool 直接化用传统编程成果的当下，Context 的高度依赖设计者自身经验，上下文质量直接决定一个 Agent 的智商，这可能将是未来竞争的主要战场。

Tool

Agent 调用工具，必不可少的两大要素：Structured Schema & MCP Protocol。前者使 LLM 能够规范调用工具，后者使 Agent 与工具直接能够实现通信。

Structured Schema

现在主流的数据格式基本都在向 OpenAI Function Calling Schema 靠拢，一个 Schema 被设计出来是供 LLM 查看的，里面定义了诸如工具名称、用途、何时调用、调用时必要的字段等信息，每个工具都对应一个唯一的 Schema。

为什么 Schema 都在使用 JSON？

前面提到，一个 Schema 应当定义一个工具，将其暴露到 LLM 后，LLM 唯一的执行该工具的方法就是依照这个 Schema 输出必要字段，也就是说，LLM 本身是不能知道这个工具底层是怎么调用的，它只知道需要提供哪些信息，将这些信息（必要字段）提交给服务器后，服务器就能自动翻译然后真正调用底层工具。

没错，LLM 网关也需要承担翻译工具意图的事。

然后是必要字段的事情，众所周知，目前最通用、最适合这种 k-v 格式的就是 JSON，所以大伙就都用 JSON 了。

Skill

Skill 我们都很熟悉，本质上是一段提示词，将需要的工作进行编排，能实现很多功能。

不过， Skill 也可以应对这个问题：当一个任务需要调用多次工具，可能还伴随着复杂的工具时序编排，有可能 LLM 的智商跟不上，没法准确现场编排工具，那不就完犊子了。

所以，如果在 Skill 中，将某个大的需求细细分解编排，再弱智的模型在开卷考试的情况下，基本上也能完整执行了。

当前 Skill 有两种形态：1. ToolKit，被封装的提示词，LLM 无法直接看到内部细节，只能看到对外暴露的 Schema；2. Agent Skill，开放明文存储的提示词，LLM 可以完全看到内部的细节和编排。

两种形态的基本需求都是，告诉 LLM 特定的工作流 Workflow。

另外，Skill 是渐进式披露的，LLM 根据当前任务可自动匹配对应的 Skill；亦可手动调用。、

MCP 协议

在 MCP 之前，所有的工具都需要手动编写接口、手动实现，然后手动注册发现，工具系统和 Agent 系统高度耦合，既不好维护也不好拓展或复用。而在 MCP 之后，Agent 系统和工具系统实现了解耦，双方从此允许部署在不同的服务上，二者之间维护一套 MCP 中间层进行通信。

市面上存在不少 MCP 服务器，你也可以自己创建专属的 MCP 服务器。基于 MCP 规范，MCP 服务器需要向 Agent 系统提供以下服务：

工具的调用 Schema 或者其他接口，供 LLM 如 Function Calling 一般调用；
MCP 服务器的本地资源，图片、文档、数据等；
Prompt/Skill。mcp服务器的工具是本地agent应用不知道的，在面对需要mcp服务器工具交叠使用的复杂场景时，本地的skill全体失效，所以需要构建一套专门用于编排mcp工具的skill，并且将其布置到mcp服务器，和工具一同发布，便于 Agent 或者用户调用。
工具注册/发现服务，统一告诉 Agent 自己所拥有的工具；
订阅机制，消息通知等。

普通的本地提供工具时的 Function Calling：

1	LLM -> Function Calling -> JSON Schema(本地提供) -> 本地服务器 -> 工具

而存在 MCP 工具时的 Function Calling：

1	LLM -> Function Calling -> JSON Schema(MCP服务器提供) -> MCP协议中间层 -> MCP服务器 -> 工具

⭐Context Engineering⭐

Prompt Engineering

提示词工程是上下文工程的前身，彼时大伙对待 LLM 的态度仅仅是一个聊天问答式机器人，倾向于短期使用，这样有可能是网页大模型普遍存在轮次限制，天然不支持长程任务，于是提示词工程应运而生，它研究提示词的写法，致力于在一次交互内解决一个单一问题，尽量不将问题拖延到后面的轮次。

Context Engineering

上下文工程是提示词工程的迭代，在 LLM 能够理解本地文件、和任务长程化的当下，为了保证 LLM 能够更精准地理解工作空间和任务，单纯研究严谨的提示词已然无法满足要求，而随着 Agent 开发范式逐渐成型，一段提示词被解构为多个部分的组合，例如系统提示词、任务描述、可用工具、标准输出等，每个部分来源于不同的信源，由 Agent 本地服务将之搜集并构建。

诚然，从直接形式上看，二者没有本质区别：都是构建标准的提示词并输入 LLM。

然而，构建提示词的过程二者却天差地别。提示词工程中，几乎完全依赖用户自身设计的提示词，后端服务并不会对其进行处理，或者只是进行简单的处理，例如按照一个模板填表；而上下文工程的设计理念是，用户不需要自己绞尽脑汁设计提示词，只需要尽可能地用一段自然语言表达清楚一个任务就行，主要改进点在于后端服务需要根据用户的自然语言，搜集与之相关的信息，搜集的信源则是 Agent 的记忆系统，将权威信息搜集之后，按照一定格式再组合成一套提示词。

也就是说，上下文工程，是由 记忆系统、后端专用服务和上下文规范共同构建的，这与提示词工程完全不一样。

Agentic Workflow

Agent & Workflow 是相对于一个任务而言的，一个任务是否能够按照特定流程稳步推进，直接决定这个任务适合什么样的工作方法。Agent 中，LLM 自己决策并承担一切编排工作；而 Workflow 中，LLM 只是已有的编排中的一环。

假如任务有着相对固定的流程，一般而言都是原本用代码可以完成的工作，适用 Workflow，我们熟知的 skill 就是一种 Workflow。例如 查询orderId=10029364248的订单金额，LLM 能做的其实很少，它只能够向后端或 MCP 服务器发送工具请求，然后服务器再处理，然后返回 LLM，LLM 再组织语言返回，这实际上和编写代码没有任何区别，区别只是：调用者从手动编写的接口变成了 LLM。

而任务没有固定流程，一般是探索性任务，适用 Agent。例如 服务器崩溃了，你找原因 这种纠错任务，在此之前高度依赖人工进行，流程也不固定，有可能是网络问题，也有可能是后端问题，从多个角度入手都没问题，这种任务交给 LLM，它会有很大的自由度，能够自由安排任务执行，只要最终完成任务，其内部的任务过程可以忽略。

而 Agentic Workflow 就是将两者混用，由 Agent 构成原子任务，将各个原子任务再组合成一个 Workflow。