看AI教程时，最容易遇到的问题不是操作难，而是名词太多。

本文用一个“电商团队处理订单问题”的例子解释常见概念，重点是它有什么用、什么时候会遇到，不展开底层实现。

比喻只是帮助理解；文中的订单工具和业务流程是假设案例，不代表安装Codex后就自带这些能力。

一、先记住这几句话

名词	一句话比喻
大模型（LLM）	团队里负责理解和分析的“大脑”
提示词（Prompt）	你交代的任务和要求
上下文（Context）	这次工作摆在桌面上的资料
Agent	能围绕目标、借助工具推进工作的“办事员”
工具（Tool）	办事时可用的查询、搜索和执行功能
MCP	办事员连接不同系统时遵守的统一接口约定
Skill	某类任务可以反复使用的操作手册
AGENTS.md	项目里的长期工作规则
插件（Plugin）	把一些能力打包好的安装包
工作流（Workflow）	预先安排好的办事流程
RAG	先查资料，再根据资料回答

这些东西不是一套必须全部安装的组件，而是在解决不同问题。

二、AI怎么理解你的需求？

1、大模型：负责理解和分析

LLM全称Large Language Model，通常译作“大语言模型”，能根据输入理解文字、生成内容、分析代码等。

可以把它比作熟悉很多知识的同事：你给它一段支付日志，它能帮忙分析可能的问题。

但它不会因为知识多，就自动知道你公司的订单数据。要分析具体问题，需要你提供资料，或者让应用通过工具去查询。

2、提示词：这次具体要做什么

Prompt就是交给模型的输入，其中可以包含任务、要求和示例；日常使用时，最直观的就是你发出的那段话。

例如，只说“帮我看看订单”，很难知道你想查什么；换成下面这样就清楚得多：

排查订单<ORDER_ID>已支付但未发货的原因。
只查询订单、支付和发货记录，不修改数据。
输出已确认的事实、可能原因和还缺少的证据。

提示词像任务单，重点是目标、范围和完成标准，不是写得越长越好。

3、上下文、上下文窗口和Token：桌面上的资料与容量

名词	通俗理解	订单案例
上下文（Context）	模型这次实际能参考的资料	你的要求、相关对话、订单状态、日志和工具返回结果
上下文窗口（Context Window）	这张“工作桌”能容纳的信息总量上限	不能无限塞入历史聊天和整库日志，还要为生成内容等留空间
Token	模型处理内容时使用的小单位	一段文字会被切成多个Token，不固定等于一个汉字或一个英文单词

文件在电脑上、消息在聊天记录里，不等于它们已经完整进入当前上下文。 应用需要读取、选择或整理相关内容；对话过长时，也可能压缩或省略部分历史。

实际使用时，优先给订单号、时间范围、相关日志和接口入口，通常比把所有文件一起塞进去更有效。

这里的Token不是登录接口使用的访问令牌，只是英文单词恰好相同。

三、从“回答问题”到“动手办事”

1、Agent：会推进任务的办事员

Agent常译作“智能体”。在本文的应用场景里，可以理解为：用模型判断下一步，并借助工具、任务记录等，把事情持续推进的程序。

例如处理“已支付但未发货”：先查订单，发现缺少发货记录，再查发货任务，最后给出证据和结论。

它与单纯问答的区别不在于名字，而在于是否能围绕目标执行步骤、接收结果，再决定下一步。

只写一句“你是一名资深客服”，不会自动获得查询订单、发送消息或退款的能力；这些仍要由应用接入，并配置相应权限。

2、工具与工具调用：真正执行动作的部分

Tool是应用提供的具体功能，例如搜索日志、读取文件、查询订单或运行测试。

Tool Calling或Function Calling可以理解为：模型提出“调用哪个功能、传什么参数”，由应用执行，再把结果交回来。

模型提出请求：查询订单<ORDER_ID>
    ↓
应用检查调用是否允许，并执行查询工具
    ↓
工具返回订单状态
    ↓
模型根据结果继续分析

模型说“应该查一下订单”，不等于真的查过。 要看有没有实际工具调用、返回值和可核对的证据。

3、MCP：对接不同系统的统一约定

MCP全称Model Context Protocol。可以把它比作不同业务窗口共用的一套办事表单：能办什么、需要填什么、办完返回什么，都有约定。

例如，GitHub MCP提供读取Issue、PR等能力，Notion MCP提供读取页面等能力；AI应用按相同协议接入，不必为每个系统重新设计一整套交互方式。

• MCP Server：提供能力的程序，相当于业务窗口，可以在本机或远程运行。
• MCP Client：AI应用里负责连接窗口的部分，不是另一名AI员工。

MCP不是专门让两个AI互相聊天，也不只是封装HTTP。 它约定工具和资料如何被发现、调用或读取；消息可以通过HTTP，也可以通过本机进程的标准输入输出传递。

Agent也可以直接调用API、命令行或内置工具，不一定需要MCP。接入MCP仍需要相应授权，不会绕过业务系统的权限。

四、规则和经验怎么反复使用？

1、AGENTS.md：长期规则

把AGENTS.md当成项目的工作须知，记录每次都需要遵守的稳定约定。

例如：订单金额按“分”处理；修改支付逻辑后补充回归测试；未经确认不执行生产数据修改。

它回答的是“在这个项目里做事，要遵守什么”，不是只给某一次任务写的需求单。

注意，AGENTS.md是规则文件，Agent是执行任务的程序，名字相近但不是同一个东西。规则文件也不是权限开关，真正的访问限制仍要靠账号权限、工具配置等落实。

2、Skill：某类工作的操作手册

Skill把重复任务的步骤、参考资料、模板或辅助脚本放在一起，供Agent在需要时使用。

例如，把“订单异常排查”整理成一份手册：

1. 收集订单号和发生时间。
2. 核对订单、支付、发货记录。
3. 找出状态不一致的位置。
4. 输出证据、可能原因和待确认事项。

以后遇到类似问题，就不必每次重新复制整套要求。

在支持Agent Skills的工具中，通常用SKILL.md描述适用场景和执行步骤，旁边可以放脚本、参考资料等。

Skill不是重新训练模型，也不是新增一名员工。 它主要告诉现有Agent怎么做；手册里写了“查询订单”，仍然需要有可用的查询工具和权限。

3、插件：把能力打包交付

Plugin可以理解成工具包。以Codex中的插件为例，一个插件可以包含Skill、MCP连接等，让使用者统一安装和使用。

假设团队把“订单排查Skill”和“订单查询MCP连接配置”打包成插件，其他同事安装后，就不必逐个整理这些文件和连接。

但安装工具包不等于完成业务授权，登录、密钥和访问范围仍要按服务要求配置。不同产品对“插件”的定义也可能不同。

简单记：AGENTS.md写规矩，Skill写做法，插件负责打包；实际办事的是Agent和它调用的工具。

五、资料从哪里来，能不能记住？

1、RAG：开卷查资料，再作答

RAG通常译作“检索增强生成”，直白地说就是：先找相关资料，把找到的内容交给模型，再生成回答。

例如，用户问“优惠券退款后会不会退回”，先查团队的售后规则，再结合规则回答，而不是只凭模型原有知识猜测。

问题 → 检索相关文档 → 将相关段落交给模型 → 回答并注明来源

它不是把整套知识库永久背进模型，也不等于重新训练。资料过期、没检索到关键规则或理解有误，仍可能答错。

2、Embedding和向量检索：按意思找资料

Embedding可以理解成给文字生成一组“含义坐标”，方便比较内容是否相近；向量检索就是利用这些坐标寻找相关资料。

例如，用户搜“钱没退回来”，可能找到标题为“退款到账时间”的文档，即使两句话没有完全相同的关键词。

它是检索的一种方法，不是判断事实真假的工具。RAG也不一定必须使用向量数据库，还可以结合关键词搜索等方式找资料。

3、Memory：下次可能用到的笔记

Memory通常指应用保存、并在后续任务中按需取用的信息，例如项目偏好、历史摘要或处理记录。

可以把上下文理解成“桌上正在看的材料”，把记忆理解成“柜子里保存的笔记”：笔记要被取出来，才能参与这次分析。

是否保存、保存哪些、什么时候取用，取决于具体产品或实现，不能假定所有Agent都永久记得以前的对话，也不应把密码等敏感内容当成普通记忆保存。

六、工作流和多Agent：事情怎么分工？

名词	比喻	例子
工作流（Workflow）	提前安排的办事路线	收集订单号 → 查询状态 → 判断异常类型 → 生成报告
子Agent（Subagent）	被分派一项明确工作的协作者	主Agent把“分析支付日志”交给子Agent，再接收结果
多Agent（Multi-agent）	多个执行者协作	一个查支付，一个查发货，由负责人汇总结论

工作流可以有分支、循环、人工确认，也可以在某个环节使用Agent；它们不是二选一。

实际选择时，可以先用这两条判断：

• 步骤明确、重复执行：优先考虑普通脚本或工作流，不必每一步都交给模型决定。
• 需要根据结果决定下一步：考虑让Agent参与；只有任务能相对独立拆分时，再考虑多个Agent协作。

多个Agent不一定更快、更可靠，还会增加沟通成本和结果冲突。两个Agent得出同样结论，也不等于结论已经被事实验证。

七、用一次订单排查把它们串起来

假设团队已经接入必要的只读工具，你提出：

排查订单<ORDER_ID>已支付但未发货的原因，只查询，输出证据和待确认事项。

这句话是Prompt，订单号和后续查到的记录构成Context。整个过程可以是：

你提出排查任务
    ↓
Agent参考项目规则和订单排查Skill
    ↓
模型判断需要查询哪些记录
    ↓
应用在权限范围内调用工具
    ↓
工具读取订单、支付和发货系统
    ↓
查询结果回到Agent，作为后续分析的上下文
    ↓
证据不足：继续查询或向你确认
证据足够：给出结论、依据和待办项

其中，工具既可以直接连接业务API，也可以通过MCP提供；需要查售后规则时，可以加入RAG；有独立子任务时，可以交给子Agent。

这些都只是按需加入的能力，不用为了做一个Agent，把所有名词对应的东西都装一遍。

另外常见的幻觉（Hallucination），就是生成了看起来可信、实际错误或缺少依据的内容。例如只查到“未发货”，就断言“一定是库存不足”。因此，报告应把已确认事实和推测分开，不能用流畅的表述代替证据。

相关阅读

• MCP入门与Codex使用教程：连接GitHub、Notion等服务的实际用法。
• Codex AGENTS使用教程：长期规则应该写什么、放在哪里。
• Codex Skills使用教程：把重复流程整理成可复用的Skill。

参考资料

以下资料用于核对概念；文中的电商团队比喻和订单案例为帮助理解而作的简化说明。

• OpenAI基础概念：模型、提示词、Token和Embedding。
• OpenAI对话状态与上下文：历史信息如何进入后续请求，以及上下文容量。
• OpenAI构建Agent指南：模型、工具、记忆与流程组织。
• OpenAI工具调用指南：模型提出调用、应用执行、返回结果的过程。
• MCP官方架构说明：客户端、服务端和连接方式。
• Agent Skills官方介绍：Skill的组成与按需加载方式。
• Codex定制指南与Skills和插件说明：项目规则、可复用流程和插件的定位。
• OpenAI检索指南：语义检索和利用资料生成回答。