提示词工程 (Prompt Engineering)

我们向 AI 提问时，输入的内容就是提示词。ChatGPT 的诞生，催生了 提示词工程 (Prompt Engineering)，简单来说，就是如何与AI说话的艺术。

早期的 ChatGPT 或者 Stable Diffusion，需要非常巧妙的提问，才能得到比较好的答案。提示词工程就是用来教你怎么写好提示词的。例如，给AI设定角色、提供背景、约束输出格式，从而让AI给出惊艳的回答，而不是泛泛而谈的废话。

上下文工程（Context Engineering）

大模型很好，但是它有两个问题：上下文窗口有限 和 幻觉。

问题一：上下文窗口有限

在我们与大模型进行对话的时候，每一个对话窗口所能够输入的内容是有限的。例如，你不能一次性把一整本《红楼梦》粘贴在对话框，让大模型帮你续写。也不能对一个问题连续追问几千上万次。

这是因为大模型内部有一个 上下文窗口（Context Window），这个窗口就像是大模型的工作内存或短期记忆。它决定了模型在处理当前请求时，一次性能够看到并理解多少之前的信息。是的，当你追问时，其实是把新追问的问题拼接在之前的对话历史上，重新发送给大模型。

如何在有限的上下文窗口中，尽可能地“物尽其用”？

2024年发布的 DeepSeek-R1 模型，所能支持的上下文窗口大小约 12.8万（128K） token，相当于一本《小王子》的长度，进入2025年和2026年，最先进的模型例如 Gemini 3.1 Pro、Claude 4.6 已经能够支持超过 100万（1M） token 的上下文，相当于 1.5 本《红楼梦》的长度。

问题二：大模型的幻觉

大模型的知识只停留在它被训练好的那一天，无法给出实时信息或者是企业内部知识，加上其本质是一个概率机，容易给出一些看似有道理实际上错误的回答，这就是大模型的“幻觉”。

如何让大模型准确回答，不要瞎编？

检索增强生成（RAG）

为了解决上面两个问题，2020 年 AI 研究科学家 Patrick Lewis 等人提出了 检索增强生成（Retrieval-Augmented Generation，RAG） 技术，简而言之，就是给 AI 外接一个知识库或搜索引擎。

我们可以提前把资料上传，这些资料会先被切分成文字块，再进行向量化（Embedding），存储在向量数据库中。向量化就是把文字变成翻译成计算机能理解的高维浮点数数组。在向量化的世界中，越是语义相似的词语，会越接近。

当我们提问时，问题不是直接发送给大模型，而是先到向量数据库提取最相关的内容。然后把这些内容作为提示词的一部分，跟用户输入一起传输给大模型，让大模型结合这些准确资料来生成回答。例如：

你是一个专业的公司内部助手。请严格根据以下【参考资料】来回答用户的【问题】。
如果参考资料中没有相关信息，请回答“我不知道”，不要编造。

【参考资料】：
{这里填入向量数据量查到的内容，例如：
# 1. "员工入司满一年后，每年可享受5天带薪年假..."
# 2. "年假需提前一周在OA系统中申请..."
# 3. "病假相关规定如下..."}

【用户问题】：
{用户的原始问题}

企业级的 AI 客服、智能文档助手基本都在用 RAG 技术。

同理，对于有很多轮的长对话，我们也不需要每次把历史记录原封不动地重新发送给大模型，而是先向量化，或者干脆让大模型提炼总结对话历史，这样就能节省大量的上下文窗口。

像这样，为了解决大模型知识断层、不认识企业内部知识、多轮对话遗忘等问题，从而极致利用上下文窗口的工程，叫做上下文工程。

Skills

大模型本身不能直接上网、查天气 或 定闹钟。它唯一能做的事情，就是接收一段文本，然后预测并输出下一段文本。如果我们要让 AI 帮我们做具体的事情，就必须让大模型搭配工具。

Skills 就是这样一份技能清单，它本质就是一个个现成的、可被 AI 读取的工具，刚刚提到， AI 大模型只能接收文本，所以这个“工具”必然也是以文本的形式存在。通常，Skill 会被标准化为一个 SKILL.md 文件，里面说明了这项技能的详细信息，包括这项技能涉及到的外部接口（如有）。

当我们想让 AI 帮我们查天气，AI 首先会查找 Skills 技能清单，如果清单里面恰好有一项“天气服务”，它就能根据“天气服务”的说明，构造相应的入参，让后台应用帮忙调用，得到结果后，再组织成通顺的语言来回答。

下面是一个查询天气服务的 SKILL.md 示例

# Skill: Weather Inquiry Assistant (天气查询助手)

## 1. 意图与描述 (Description)
**目标**：当用户询问当前天气、未来天气预报、温度或基于天气的出行建议时，使用此技能。
**角色**：你是一个准确、客观且贴心的气象服务助手。你没有任何内置的实时天气知识，必须绝对依赖外部工具提供的数据。

## 2. 触发条件 (Triggers)
- 用户直接询问天气（例如：“北京今天热吗？”、“纽约明天下雨吗？”）。
- 用户询问基于天气的建议（例如：“周末去上海需要带伞吗？”、“明天适合洗车吗？”）。

## 3. 依赖与工具 (Required Tools)
执行此技能需要依赖以下预设的外部工具（API 函数）：
- `get_current_weather(location: string, unit: string)`: 获取指定地点的实时天气。
- `get_weather_forecast(location: string, date: string)`: 获取指定地点、指定日期的天气预报。
- `get_user_location()`: 尝试获取用户当前的默认地理位置。

## 4. 执行工作流 (Execution Steps)

1. **参数提取与验证**：
   - 检查用户输入中是否包含 **地点 (Location)**。
   - 检查用户输入中是否包含 **时间 (Time)**（默认视为“今天”/“现在”）。
2. **处理缺失信息 (Missing Information Handling)**：
   - 如果用户没有提供地点：首先尝试静默调用 `get_user_location()`。如果调用失败或无权限，必须主动向用户发起追问：“请问您想查询哪个城市的天气？”。**绝对禁止** 默认假设一个城市。
3. **执行工具调用**：
   - 根据提取的时间参数，选择调用 `get_current_weather` 或 `get_weather_forecast`。
   - 除非用户明确要求华氏度（Fahrenheit），否则默认传入 `unit = "Celsius"`（摄氏度）。
4. **数据解析与响应生成**：
   - 解析 API 返回的 JSON 数据。
   - 将生硬的数据转化为自然语言。如果用户询问的是具体建议（如“需要带伞吗”），必须在回答中给出明确的“是”或“否”，并附带降水概率作为依据。

## 5. 核心规则与最佳实践 (Rules & Best Practices)
- **零幻觉原则**：如果天气 API 返回错误或超时，诚实地告诉用户“目前无法获取气象数据”，**绝对禁止** 捏造天气状况或温度。
- **简明扼要**：优先直接回答用户的核心问题。不要堆砌所有的气象参数（如风向、气压、湿度），除非它们极端异常（如台风天）或用户明确要求。
- **单位本地化**：在输出温度时，确保带上明确的单位符号（如 25°C）。

## 6. 输出格式约定 (Output Format)
向用户输出时，建议采用以下友好且清晰的结构：
1. **结论先行**：直接回答用户的问题（如：“北京今天非常热，最高气温 35°C。”）
2. **核心数据补充**：提供天气状况（晴/雨/多云）和当前温度区间。
3. **贴心建议（可选）**：根据天气情况提供一句话的穿衣或出行建议（如：“紫外线较强，建议做好防晒。”）

AI Agent（智能体）

前面提到，大模型本质上只能输入输出自然语言，并不具备执行能力。

那么，AI 是怎么帮我们定闹钟、查天气的呢？

事实上，我们面对的各种 AI 助手，输入框背后不单纯只有大模型，而是一个 AI Agent（智能体）。Agent 本质上就是一个程序，一边对接了大模型，另一边对接了各种各样的外部资源（Skills、RAG、MCP Server、第三方接口等等）。

当我们提问或下达一个命令，Agent 和大模型配合流程如下：

1. 问题先进入 Agent，判断需不需要用到 RAG
2. 将用户提问、可用的工具列表 和 通过RAG检索到的外部知识（如果有），组装成一个巨大的 Prompt，进入大模型
3. 大模型接收到 Prompt，开始思考和拆解：
   • 如果他认为需要调用外部接口，则返回 JSON
   • 如果不需要，返回自然语言回答
4. Agent 根据大模型的返回：
   • 如果收到 JSON，则调用对应的外部接口，再把结果重新组装到 Prompt 中再次给到大模型
   • 如果收到自然语言回答，则直接返回给用户

如下所示，是大模型返回给 Agent 的 JSON 文本，表示希望调用“getRealTimeWeather”服务，参数是“北京”。这样，Agent 就可以调用 getRealTimeWeather 方法的接口，获取北京的天气信息。

{
  "action": "getRealTimeWeather",
  "arguments": {
    "city": "北京"
  }
}

如果一次调用的结果不能达成目标，Agent 可以循环多次调用大模型和外部工具。直到大模型显式地认为目标达成（通常是在通信的 JSON 中有一个 finish_reason 字段为 stop）或者是达到 Agent 设定的最大循环次数。

可以用一个公式来定义 AI Agent：

AI Agent = LLM（大脑） + 规划（思考路径） + 记忆（RAG等） + 工具（Skills）

Function Calling / Tool Calling

早期的 Agent 经常跟大模型斗智斗勇，比如 Agent 希望让大模型返回纯 JSON 格式，但是大模型经常不听话，给自己加戏，要么是 JSON 缺了括号或者括号层级不对，要么是在 JSON 前面多了一句“好的，这是你要的 JSON ......”这样的废话。导致 Agent 程序解析 JSON 时出现问题。

后来大模型厂商意识到纯 JSON 输出是一个强烈的需求，于是在训练模型时专门为这种场景做了微调。如果我们听到某个模型厂商宣称支持 Function Calling ，注意，并不是说这个模型自己能够去发起外部调用了，而是说，在需要工具调用的时候，模型能够保证输出严格正确的 JSON 格式。

Tool Calling 是 Function Calling 的更广义的称呼。Function 特指函数，而 Tool 可以包含插件、API、甚至另一个 Agent 都可以被视为工具。

MCP 和 MCP Server

MCP

AI Agent 去调用外部工具，通常是用 JSON 交互，但是不同的工具由不同的人开发，有不同的出入参格式，一旦工具多了，就会造成超级大麻烦。

模型上下文协议（Model Context Protocol，MCP） 是由 Anthropic 公司开源的一项开放标准，用于解决 AI Agent 与外部数据源、工具和系统集成时所面临的碎片化和非标准化问题，类似于为 AI 应用提供了通用的“USB-C 接口”或“万能插头”。这样，大家都有了统一的标准，交互起来也就方便得多了。

MCP Server

如果我们把 AI Agent 比作客户端，那么 MCP Server 就是专门给 Agent 调用的服务器。

MCP Server 本质上也是一个后台程序，用来把私有数据或工具按照 MCP 的标准格式暴露给 AI 客户端。由于开源社区和官方已经有大量极度完善、经过无数测试的专用 MCP Server，因此我们需要什么服务就启动什么 MCP 服务，例如需要连接 PostgreSQL 数据库，直接拉取官方的 postgres-mcp-server 镜像跑起来就行，而不建议自己去写一套连接 PostgreSQL 的代码。

从 开箱即用、权限管控与安全隔离、单一职责与容错性、动态插拔 等角度考虑，不同的功能（如读取数据库、读取文件系统）应该启动不同的 MCP Server，除非在业务场景高度耦合和定制化的场景下，才考虑把不同的数据源统一定制成一个 MCP Server。

A2A（Agent-to-Agent）

如果说 MCP 是让模型连接外部工具的标准，那么 A2A 就是让不同的 Agent 之间相互连接的协议。

A2A 让多个 AI 分工协作，完成复杂任务。当然，A2A 可能会用到 MCP 来交换数据。

Vibe Coding

有了 AI Agent 之后，我们再也不需要自己手动编写代码，一些 AI Agent 会自主规划文件结构、写代码、运行测试，甚至在内置浏览器里自我纠错，我们只需要在关键节点做出决策即可（例如，确认修改、确认执行某个脚本）。

像这样，我们只需要像产品经理一样用自然语言就能够完成软件开发的过程，就叫做 Vibe Coding。

Anysphere 公司的 cursor 、Google 公司的 Antigravity 和 字节跳动 公司的 Trae ，本质上就是集成了大量 AI Agent 功能，方便我们进行 Vibe Coding 或者 AI 辅助编程的 IDE 工具。

而 Anthropic 公司 的 Claude Code， 或者 Google 公司的 Gemini CLI, 则把 AI Agent 做成了命名行。这样，无论你使用什么IDE，都可以在终端中让 AI 帮你分析项目结构，甚至帮你完成任务。

OpenClaw

当我们有了各种各样的 AI Agent 之后，会发现它们都太过于“定制化“了，有些 Agent 只会帮你写代码，有些 Agent 只会帮你查天气，并且这些 Agent 内部通常绑定了某些大模型和 Skills ，并不能自由搭配。

有没有一个全能的管家，我们能自由选择大模型，自由选择需要哪些 Skills，并无缝低嵌入到你的电脑中，可以完成几乎任何一些就像我们自己在操作电脑的事情呢？有的，那就是 2026 年初爆火的 OpenClaw 。

OpenClaw 具备行动能力，它可以操作浏览器、执行终端命令、管理日程与邮件、定时执行任务（如每日搜集新闻并向你汇报），而且它可以嵌入到聊天软件之中，你可以像给朋友发消息一样，在 iMessage 上给你的 OpenClaw 下发任务，它就会帮你去完成。

但是，OpenClaw 不是万能的，它最被诟病的两点是，其一是充斥大量 AI 生成的代码，工程结构混乱，意味着可能不稳定，其二是每处理一个任务，消耗的 Token 的天量级的，意味着使用成本高昂。