从 Prompt 到 Agent 蜂群：AI 使用技巧与核心概念全景指南
从 Prompt 到 Agent 蜂群：AI 使用技巧与核心概念全景指南
本文面向初中级 AI Agent 用户，以技术演进为主线，一次性讲透 Prompt、Context、Harness、Loop、Agent、蜂群，以及 Rule、Memory、Skill、MCP、Hooks、定时任务、插件等所有常见概念。读完本文，你将拥有一张完整的 AI 使用认知地图。
一、为什么需要一篇"全景式"的文章？
如果你刚接触 AI 编程助手或 Agent 工具，大概率会被一堆名词淹没：Prompt Engineering、Context Window、System Prompt、Tool Use、ReAct Loop、MCP、Memory、Skill、Hooks……它们看起来像是不同公司发明的不同概念，彼此之间似乎毫无关系。
但事实上，它们是一条清晰的演化链上的不同环节。
这条链的逻辑是：
人如何跟 AI 说话（Prompt）
→ AI 能看到什么信息（Context）
→ 如何约束 AI 的行为边界（Harness）
→ AI 如何自主循环执行（Loop）
→ 一个完整的自主执行体（Agent）
→ 多个 Agent 如何协作（蜂群）
每一个新概念的出现，都是为了解决上一个阶段解决不了的问题。理解了这条链，所有名词都会各归其位。
二、第一纪元：Prompt——人与 AI 对话的起点
2.1 什么是 Prompt？
Prompt（提示词）就是你输入给 AI 的那段文字。它是一切交互的起点。
最早期的 AI 对话极其简单——你说一句，它回一句，就像聊天。但人们很快发现：同样一个问题，换一种问法，AI 的回答质量天差地别。
这就是 Prompt Engineering（提示词工程）诞生的原因。
2.2 Good Prompt 的核心原则
一个好的 Prompt 不是"写得长"，而是信息密度高、歧义少、约束明确。以下是经过大量实践验证的核心原则：
原则一：明确角色（Role Assignment）
你是一位有 10 年经验的 Java 架构师，请审查以下代码的设计问题。
为什么要给角色？因为 AI 的训练数据覆盖了所有领域，给它一个角色等于告诉它："请从这堆知识里，调用这个子集来回答。"角色越具体，回答越聚焦。
原则二：提供上下文（Context Providing）
我正在开发一个电商系统，使用 Spring Boot 3 + MyBatis-Plus，
数据库是 MySQL 8.0，部署在阿里云 ECS 上。
现在需要设计一个订单超时自动取消的方案。
AI 不知道你的项目背景。你提供的上下文越精确，它越不需要"猜"，回答就越贴合你的实际情况。
原则三：明确输出格式（Format Specification）
请以 JSON 格式输出，包含以下字段：
- solution: 方案名称
- pros: 优点数组
- cons: 缺点数组
- recommendation: 是否推荐（布尔值）
不指定格式，AI 会用它"觉得自然"的方式输出。指定格式后，输出变得可预测、可解析、可程序化处理。
原则四：给出示例（Few-shot Examples）
将以下需求转化为 SQL：
示例：
需求：查询最近 7 天注册的用户数
SQL：SELECT COUNT(*) FROM users WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY);
现在请转化：
需求：查询每个城市最近 30 天的订单总金额
示例是最强的"教学"手段。一个好的示例胜过三段描述。这在学术上叫 In-Context Learning（上下文学习）——AI 通过你给的示例"学会"了你要的模式。
原则五：分步思考（Chain-of-Thought）
请一步一步分析这个问题，先列出已知条件，再推导每一步，最后给出结论。
让 AI "展示思考过程"可以显著降低复杂推理任务的错误率。原理是：AI 生成文本是自回归的（每个 token 依赖前面的 token），让它先输出中间步骤，等于给后续推理提供了"草稿纸"。
2.3 Prompt 的局限性
Prompt Engineering 非常强大，但它有一个根本性的天花板：
Prompt 是"一次性"的。每次对话你都要重新写一遍所有约束。
如果你希望 AI "永远记住"你的代码风格偏好、"永远"在回答前先检查某个规则，单靠 Prompt 是做不到的（或者说，做起来极其笨拙）。
这就引出了下一个概念——Context。
三、第二纪元：Context——AI 的"视野"
3.1 什么是 Context？
Context（上下文）是 AI 在生成回答时能看到的所有信息的总和。
很多人把 Context 等同于"聊天记录"，这是一个常见误解。实际上，一次 AI 调用的 Context 包括：
| 组成部分 | 说明 | 示例 |
|---|---|---|
| System Prompt | 系统级指令，用户通常不可见 | "你是一个代码助手，禁止输出暴力内容" |
| 对话历史 | 之前的问答轮次 | 用户问了什么、AI 答了什么 |
| 用户当前输入 | 本轮用户说的话 | "帮我重构这个函数" |
| 注入的文件/代码 | 工具自动塞入的项目信息 | 当前打开的文件、选中的代码片段 |
| 工具返回结果 | AI 调用工具后获得的信息 | 搜索结果、文件内容、API 响应 |
| 规则/记忆 | 持久化的约束和偏好 | "用户偏好 TypeScript" |
3.2 Context Window：AI 的"工作记忆"
AI 模型有一个硬限制叫 Context Window（上下文窗口），表示一次调用最多能处理多少 token。
- 早期模型（GPT-3）：约 4K token（约 3000 字）
- 中期模型（GPT-4）：8K ~ 32K token
- 当前主流模型：128K ~ 200K token（约 10~15 万字）
- 前沿模型：1M+ token
窗口越大，AI 一次能"看到"的信息越多。但有两个关键认知：
-
窗口大 ≠ 用得好。 研究表明，当上下文过长时，AI 对中间部分信息的注意力会下降（"Lost in the Middle" 效应）。关键信息应放在开头或结尾。
-
窗口是"消耗品"。 每一轮对话都在消耗窗口空间。对话越长，留给新信息的空间越少。这就是为什么长对话中 AI 会"忘记"早期内容。
3.3 Context Engineering：比 Prompt Engineering 更重要的事
2024-2025 年，业界逐渐形成一个共识：
真正决定 AI 输出质量的，不是你的 Prompt 写得多花哨，而是你往 Context 里塞了什么。
这就是 Context Engineering（上下文工程） 的核心思想。它关注的不是"怎么措辞"，而是：
- 该给 AI 看哪些文件？
- 该注入哪些规则？
- 该在什么时机提供什么信息？
- 哪些信息该持久存储，哪些该临时注入？
一个好的 AI 工具（如 IDE 中的编程助手），其核心竞争力往往不是底层模型，而是上下文组装策略——它决定在每次调用时，从你的项目中挑选哪些信息塞入 Context。
3.4 实践技巧：管理你的 Context
- 精简注入：不要把整个项目丢给 AI。只给它当前任务相关的 3~5 个文件。
- 分层管理：系统指令（不变）→ 项目规则（少变）→ 当前任务信息（每次不同）。
- 及时清理：长对话中，不相关的早期对话可以总结压缩，释放窗口空间。
- 结构化优先：给 AI 看结构化的信息（表格、JSON、代码）比自然语言描述更高效。
四、第三纪元：Harness——给 AI 套上"缰绳"
4.1 为什么需要 Harness？
随着 AI 能力增强，人们不再满足于"问一句答一句"。我们希望 AI 能： - 遵守固定的行为规范 - 使用外部工具 - 按照特定流程工作
但如果只靠 Prompt，这些约束是"软性"的——AI 可能遵守，也可能不遵守。我们需要一种结构化的控制框架，这就是 Harness（约束框架/治具）。
4.2 Harness 的核心组成
Harness 不是一个具体的产品，而是一个设计模式。它通常包含以下组件：
┌─────────────────────────────────────────────┐
│ Harness │
│ │
│ ┌───────────┐ ┌───────────┐ ┌────────┐ │
│ │ System │ │ Rules │ │ Tools │ │
│ │ Prompt │ │ (规则) │ │ (工具) │ │
│ └───────────┘ └───────────┘ └────────┘ │
│ │
│ ┌───────────┐ ┌───────────┐ ┌────────┐ │
│ │ Memory │ │ Output │ │ Safety │ │
│ │ (记忆) │ │ Parser │ │ Guards │ │
│ └───────────┘ └───────────┘ └────────┘ │
│ │
└─────────────────────────────────────────────┘
- System Prompt：定义 AI 的身份、能力边界、行为基调
- Rules（规则）：强制性的行为约束（后文详述）
- Tools（工具）：AI 可以调用的外部能力（搜索、执行代码、读写文件等）
- Memory（记忆）：跨对话持久化的信息（后文详述）
- Output Parser（输出解析器）：将 AI 的自由文本输出解析为结构化数据
- Safety Guards（安全护栏）：防止 AI 执行危险操作的检查机制
4.3 从"对话"到"系统"的思维转变
理解 Harness 的关键在于一个认知升级：
AI 不再是一个"聊天对象"，而是一个"系统组件"。
当你把 AI 视为系统组件时，你会自然地思考： - 它的输入是什么？（Context 组装） - 它的输出是什么？（结构化输出） - 它的边界在哪？（规则约束） - 它能调用什么？（工具注册） - 它出错怎么办？（错误处理、重试）
这种思维方式是后续理解 Agent、Loop 等概念的基础。
4.4 Structured Output：让 AI 的输出可编程
Harness 的一个重要能力是结构化输出。早期 AI 只能输出自由文本，但实际系统中我们需要：
{
"action": "create_file",
"path": "/src/utils/helper.ts",
"content": "export function formatDate(d: Date) { ... }"
}
实现方式包括： - JSON Mode：强制 AI 输出合法 JSON - Function Calling / Tool Use：AI 不直接输出文本，而是"调用"一个预定义的函数，参数由 AI 填充 - Schema 约束：通过 JSON Schema 严格定义输出结构
结构化输出是 AI 从"聊天玩具"走向"生产力工具"的关键一步。
五、第四纪元：Loop——AI 学会"自主循环"
5.1 单次调用的瓶颈
到目前为止，AI 的工作模式都是：
人提问 → AI 回答 → 结束
但真实的任务往往不是一步能完成的。比如"帮我修复这个 bug"，AI 需要： 1. 先读代码，理解上下文 2. 定位问题所在 3. 思考修复方案 4. 修改代码 5. 运行测试验证 6. 如果测试失败，回到第 3 步重新来
这显然不是"一问一答"能搞定的。我们需要 AI 能自己决定下一步做什么，做完之后自己判断是否完成，没完成就继续。
这就是 Loop（循环） 的核心思想。
5.2 ReAct：思考-行动-观察循环
2022 年，Google 提出了 ReAct（Reasoning + Acting） 框架，奠定了几乎所有现代 Agent 的基础模式：
┌─────────────────────────────────────────┐
│ │
│ ┌─────────┐ │
│ │ Thought │ ← AI 思考当前该做什么 │
│ └────┬────┘ │
│ ↓ │
│ ┌─────────┐ │
│ │ Action │ ← AI 调用一个工具 │
│ └────┬────┘ │
│ ↓ │
│ ┌─────────────┐ │
│ │ Observation │ ← 获取工具返回的结果 │
│ └────┬────────┘ │
│ ↓ │
│ ┌─────────┐ │
│ │ 完成？ │──否──→ 回到 Thought │
│ └────┬────┘ │
│ │是 │
│ ↓ │
│ ┌──────────┐ │
│ │ 最终回答 │ │
│ └──────────┘ │
│ │
└─────────────────────────────────────────┘
这个循环看似简单，但它带来了一个质变：
AI 从"被动回答者"变成了"主动执行者"。
它不再需要你一步步指挥，而是自己规划、自己执行、自己验证。
5.3 Planning：任务分解与规划
简单的 ReAct 循环适合 3~5 步的任务。但面对复杂任务（如"重构整个认证模块"），AI 需要先制定计划，再逐步执行。
常见的规划策略：
- Plan-then-Execute：先生成完整计划，再逐步执行
- Iterative Planning：边执行边调整计划（更灵活，适合不确定性高的任务）
- Tree of Thought：对关键决策点展开多个分支思考，选择最优路径
5.4 Loop 中的关键机制
一个健壮的 Loop 还需要：
| 机制 | 作用 | 类比 |
|---|---|---|
| 最大轮次限制 | 防止 AI 陷入无限循环 | 程序的 max_iterations |
| 错误重试 | 工具调用失败时自动重试 | try-catch-retry |
| 中间检查点 | 每 N 步向用户汇报进度 | 游戏存档点 |
| 回滚机制 | 发现方向错误时撤销操作 | Git revert |
| 超时控制 | 单步执行超时时中断 | HTTP timeout |
5.5 实践理解：你每天都在用 Loop
如果你用过 Cursor、Windsurf、Qoder 等 AI 编程工具的"Agent 模式"，你其实已经在用 Loop 了：
- 你说"帮我实现用户注册功能"
- AI 自动搜索现有代码 → 创建文件 → 写代码 → 检查错误 → 修复 → 再检查……
- 这个"自动做很多步"的过程，就是 Loop 在运转。
六、第五纪元：Agent——完整的自主执行体
6.1 Agent 的定义
当我们把前面所有纪元的概念组合在一起：
Agent = LLM（大脑）
+ Context（感知）
+ Harness（约束）
+ Loop（自主循环）
+ Tools（手脚）
+ Memory（记忆）
就得到了一个 Agent（智能体）。
一个更正式的定义：
Agent 是一个能够感知环境、自主决策、采取行动、并从反馈中学习的闭环系统，其核心决策引擎是大语言模型。
6.2 Agent 与"聊天机器人"的本质区别
| 维度 | 聊天机器人 | Agent |
|---|---|---|
| 交互模式 | 一问一答 | 接受目标，自主执行 |
| 步骤数 | 1 步 | 多步（可能几十步） |
| 工具使用 | 无或极少 | 大量使用外部工具 |
| 错误处理 | 报错就停 | 自动诊断、重试、换方案 |
| 状态管理 | 无状态 | 有记忆、有上下文 |
| 人的角色 | 指挥每一步 | 设定目标，审查结果 |
6.3 Tool Use：Agent 的"手脚"
Agent 之所以能"做事"，是因为它可以调用 Tools（工具）。工具是 Agent 与外部世界的接口：
- 文件操作：读文件、写文件、搜索文件
- 代码执行：运行 Shell 命令、执行脚本
- 网络访问：搜索互联网、调用 API
- 浏览器操作：打开网页、点击按钮、填写表单
- 代码智能：跳转定义、查找引用、语法分析
每个工具都有一个描述（Description）和参数定义（Schema），AI 根据任务需要自行决定调用哪个工具、传什么参数。
6.4 Agent 的可靠性挑战
Agent 很强大，但也带来了新挑战：
- 幻觉传播：如果 AI 在第 2 步产生了错误判断，后续所有步骤都会基于错误前提执行
- 成本失控：一个复杂任务可能触发几十次 LLM 调用，token 消耗巨大
- 安全风险：AI 自主执行命令，如果缺乏约束，可能执行危险操作
- 不可预测性：同样的任务，两次执行的路径可能完全不同
这些挑战催生了后续的 Rule、Hooks、Safety Guards 等机制。
七、第六纪元：蜂群——多 Agent 协作
7.1 为什么一个 Agent 不够？
单个 Agent 面对超复杂任务时会遇到瓶颈：
- Context 窗口有限：一个 Agent 无法同时"记住"所有信息
- 角色冲突：让同一个 AI 既当架构师又当测试员，效果不如各司其职
- 串行瓶颈：一个 Agent 只能一步步做，多个独立子任务无法并行
解决方案很自然：用多个 Agent，每个负责一个子任务，彼此协作。
这就是 Multi-Agent System（多智能体系统），形象地称为"Agent 蜂群"。
7.2 蜂群的常见架构模式
模式一：Orchestrator（编排者模式）
┌──────────────┐
│ Orchestrator │ ← 总指挥，分解任务、分配、汇总
└──────┬───────┘
┌───────┼───────┐
↓ ↓ ↓
┌────────┐┌────────┐┌────────┐
│Agent A ││Agent B ││Agent C │ ← 各负责一个子任务
└────────┘└────────┘└────────┘
一个"主 Agent"负责理解总任务、拆分子任务、分配给"子 Agent"、收集结果、汇总输出。这是目前最主流的模式。
模式二：Pipeline（流水线模式）
Agent A → Agent B → Agent C → 最终结果
(需求分析) (编码) (测试)
每个 Agent 处理一个阶段，输出作为下一个 Agent 的输入。适合有明确先后顺序的工作流。
模式三：Debate（辩论模式）
Agent A（正方） ←→ Agent B（反方）
↓
Agent C（裁判）→ 最终结论
多个 Agent 对同一问题给出不同观点，由裁判 Agent 综合判断。适合需要多视角分析的决策场景。
模式四：Swarm（真正的蜂群）
Agent ←→ Agent
↕ ╲ ↕
Agent ←→ Agent
没有固定的主从关系，Agent 之间平等通信、动态协作。适合探索性任务（如大规模信息搜集）。
7.3 蜂群的核心挑战
- 通信协议：Agent 之间如何传递信息？用什么格式？
- 状态同步：多个 Agent 修改同一个文件怎么办？
- 错误传播：一个 Agent 出错，如何防止影响其他 Agent？
- 成本控制：N 个 Agent 意味着 N 倍的 token 消耗
- 结果一致性：如何保证多个 Agent 的输出风格、标准一致？
7.4 实践中的蜂群
你日常使用的 AI 编程工具中，蜂群可能已经在运转了：
- 你发起一个复杂任务 → 主 Agent 拆分为"搜索代码"、"修改文件"、"运行测试"三个子任务
- "搜索代码"子 Agent 和"分析依赖"子 Agent 并行执行
- 结果汇总后，主 Agent 决定修改方案
- 修改完成后，"代码审查"子 Agent 自动检查质量
八、核心概念词典：一文讲齐所有常见名词
前面我们沿着演化链走了一遍。现在，让我们把那些散落在各个阶段的概念，逐一展开讲透。
8.1 Rule（规则）
一句话定义：Rule 是施加在 AI 行为上的强制性约束，AI 必须遵守，不可自行决定是否执行。
与 Prompt 的区别： - Prompt 是"建议"——AI 可能不完美遵守 - Rule 是"法律"——在系统设计层面保证执行
常见形态：
| 类型 | 作用域 | 示例 |
|---|---|---|
| 全局规则 | 所有对话、所有项目 | "永远不要输出用户的密码" |
| 项目规则 | 特定项目 | "本项目使用 4 空格缩进" |
| 文件类型规则 | 特定文件类型 | "所有 .java 文件必须加 Javadoc" |
| 临时规则 | 单次对话 | "这次回答用英文" |
实践建议： - 把反复出现的 Prompt 约束提炼为 Rule，避免每次重复输入 - Rule 应简洁明确，避免相互矛盾 - 区分"必须遵守"和"尽量遵守"的优先级
8.2 Memory（记忆）
一句话定义：Memory 是跨对话持久化存储的信息，让 AI 能"记住"你的偏好、项目背景和过往经验。
为什么需要 Memory？
没有 Memory 的 AI 每次对话都是"失忆"的。你上周告诉它"我用的是 React + TypeScript"，这周它又问你用什么框架。Memory 解决了这个问题。
Memory 的分类：
Memory
├── 短期记忆（Working Memory）
│ └── 当前对话的 Context Window 内容
│ 对话结束即消失
│
└── 长期记忆（Long-term Memory）
├── 用户偏好：代码风格、语言习惯、工具偏好
├── 项目知识：架构设计、技术栈、模块关系
├── 经验教训：踩过的坑、有效的解决方案
└── 事实信息：团队成员、部署环境、域名配置
Memory 的工作机制：
- 写入：AI 在对话中识别到值得记住的信息，主动存储（或用户明确要求"记住这个"）
- 检索：新对话开始时，根据当前任务语义搜索相关记忆
- 注入：将检索到的记忆注入 Context，影响 AI 的行为
- 更新/删除：信息过时时修正，错误时删除
实践建议： - 主动告诉 AI 你的长期偏好（"记住：我偏好函数式编程风格"） - 定期清理过时记忆 - 不要存储敏感信息（密码、token 等）
8.3 Skill（技能）
一句话定义：Skill 是预定义的可复用能力包，教会 AI 如何完成一类特定任务。
Skill 与 Tool 的区别：
| 维度 | Tool（工具） | Skill（技能） |
|---|---|---|
| 粒度 | 原子操作（读文件、执行命令） | 完整流程（部署项目、生成报告） |
| 定义方式 | API Schema | Markdown 文档 + 脚本 |
| 触发方式 | AI 自主决定调用 | 用户通过斜杠命令或关键词触发 |
| 可定制性 | 通常由平台提供 | 用户可以自己编写 |
Skill 的典型结构：
my-skill/
├── SKILL.md ← 技能说明书（何时触发、如何执行、注意事项）
├── scripts/
│ └── deploy.sh ← 实际执行的脚本
└── templates/
└── config.yaml ← 模板文件
一个具体例子：
假设你经常需要"把 Markdown 文章发布到博客"。你可以创建一个 Skill：
- 触发词：/publish
- 执行流程：检查 Markdown 格式 → 生成 HTML → 上传到服务器 → 返回访问链接
- AI 读取 SKILL.md 后，就知道何时、如何执行这个流程
实践建议： - 把重复性高的多步操作封装为 Skill - Skill 的说明文档要写清楚触发条件和执行步骤 - 一个 Skill 只做一件事，保持原子性
8.4 MCP（Model Context Protocol）
一句话定义：MCP 是一个开放标准协议，用于标准化 AI 模型与外部工具/数据源之间的连接方式。
为什么需要 MCP？
在 MCP 出现之前，每个 AI 工具接入外部能力的方式都不一样： - A 平台用自定义 JSON 格式定义工具 - B 平台用 Python 函数签名 - C 平台用 OpenAPI Spec
这导致：工具开发者要为每个平台适配一遍，用户在不同平台间无法复用工具。
MCP 的出现就是为了解决这个问题——它是 AI 工具生态的"USB 接口"。
MCP 的核心架构：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ AI 应用 │◄───────►│ MCP Client │◄───────►│ MCP Server │
│ (IDE/Chat) │ │ (协议层) │ │ (工具提供方) │
└─────────────┘ └─────────────┘ └──────┬──────┘
│
┌────────┼────────┐
↓ ↓ ↓
数据库 文件系统 第三方API
MCP 的三类核心能力：
| 能力 | 说明 | 示例 |
|---|---|---|
| Tools | AI 可调用的操作 | 查询数据库、发送消息 |
| Resources | AI 可读取的数据 | 文件内容、配置信息 |
| Prompts | 预定义的交互模板 | 代码审查模板、翻译模板 |
一个实际场景：
你有一个 MCP Server 连接了公司的 Jira 系统。任何支持 MCP 的 AI 工具（无论是 Cursor、Qoder 还是其他）都可以： - 搜索 Jira Issue - 查看任务详情 - 添加评论 - 变更状态
你不需要为每个 AI 工具单独写集成代码。
实践建议： - 优先使用现成的 MCP Server（如 GitHub、Slack、数据库等） - 如果有内部系统需要接入 AI，考虑开发 MCP Server - MCP Server 的 Tool 描述要写清楚，这直接影响 AI 能否正确调用
8.5 Hooks（钩子）
一句话定义：Hooks 是在 AI 工作流的特定节点自动触发的自定义逻辑。
类比理解： - Git 有 Hooks（pre-commit、post-merge） - React 有 Hooks（useEffect、useMemo） - AI Agent 也有 Hooks——在 Agent 执行的关键时刻插入你的自定义代码
常见的 Hook 时机：
| Hook 时机 | 触发时刻 | 典型用途 |
|---|---|---|
| before_request | AI 调用 LLM 之前 | 注入额外上下文、记录日志 |
| after_response | AI 生成回答之后 | 格式校验、敏感词过滤 |
| before_tool_call | AI 调用工具之前 | 权限检查、参数校验 |
| after_tool_call | 工具返回结果之后 | 结果过滤、缓存 |
| on_error | 发生错误时 | 告警、自动恢复 |
| on_complete | 任务完成时 | 通知、清理资源 |
实践场景：
# 示例：在每次 AI 写文件之前，自动检查是否在正确的分支
hooks:
before_tool_call:
- condition: tool_name == "write_file"
action: run_script("check_git_branch.sh")
on_fail: abort # 如果不在正确分支，阻止写入
Hooks 与 Rules 的区别： - Rules 是"告诉 AI 应该怎么做"（软约束，AI 层面） - Hooks 是"在 AI 做之前/之后强制执行某段逻辑"（硬约束，系统层面）
8.6 定时任务（Scheduled Tasks）
一句话定义：定时任务是让 AI Agent 在指定时间自动执行预设工作，无需人工触发。
为什么 Agent 需要定时任务？
传统定时任务（Cron）执行的是固定脚本。但很多工作需要"判断力"： - 每天早上检查代码仓库，如果有新的 PR，自动生成审查意见 - 每周五汇总本周的 Jira 变更，生成周报并发送邮件 - 每小时检查服务日志，如果发现异常模式，自动分析原因
这些任务需要 AI 的理解和判断能力，不是简单脚本能搞定的。
定时任务的组成：
定时任务 = 触发条件（When） + 执行内容（What） + 约束条件（How）
- When：Cron 表达式、一次性时间点、事件触发
- What：一段自然语言描述的任务（AI 理解并执行）
- How：可用的工具范围、输出格式、通知方式
实践建议： - 从简单任务开始（如定时生成报告） - 设置失败通知，避免静默失败 - 给定时任务明确的输出目标（发邮件、写文件、发消息）
8.7 插件（Plugin）
一句话定义：插件是扩展 AI 工具平台能力的可安装模块，通常打包了 Tools + Rules + UI 的组合。
插件与其他概念的关系：
插件（Plugin）是一个"打包分发"的概念：
├── 可以包含 MCP Server（提供工具能力）
├── 可以包含 Rules（注入行为约束）
├── 可以包含 Skills（提供可复用流程）
├── 可以包含 UI 组件（提供可视化界面）
└── 可以包含 Hooks（注入工作流逻辑）
类比理解： - VS Code 的 Extension = 给编辑器加功能 - Chrome 的 Extension = 给浏览器加功能 - AI 工具的 Plugin = 给 AI 加功能
插件生态的意义：
没有插件系统时，AI 工具的能力是"出厂固定"的。有了插件系统： - 社区可以贡献能力（如"Kubernetes 管理插件"、"Figma 设计稿解析插件"） - 企业可以开发内部插件（如"公司部署流程插件"） - 用户按需安装，不用的能力不占资源
8.8 其他常见概念速查
| 概念 | 一句话解释 |
|---|---|
| System Prompt | AI 的"出厂设置"，定义身份和行为基调，用户通常不可修改 |
| Function Calling | AI 输出结构化的"函数调用请求"，由外部系统执行 |
| RAG | 检索增强生成——先从知识库搜索相关内容，再让 AI 基于搜索结果回答 |
| Embedding | 将文本转为向量，用于语义搜索（RAG 的基础） |
| Token | AI 处理文本的最小单位（约 0.75 个英文单词 / 0.5 个中文字） |
| Temperature | 控制 AI 输出随机性的参数（0=确定性高，1=创造性高） |
| Hallucination | AI 一本正经地输出不存在的事实（幻觉） |
| Grounding | 让 AI 基于真实数据回答，减少幻觉 |
| Agentic Coding | AI 自主完成编码任务（搜索→编码→测试→修复的完整循环） |
| Human-in-the-Loop | 在 AI 自主执行中设置人工审批节点 |
| Sandbox | 隔离环境，让 AI 执行代码时不影响真实系统 |
| Guardrails | 安全护栏，防止 AI 输出有害内容或执行危险操作 |
九、全景图：所有概念如何协同
让我们用一张完整的图，展示所有概念在一次 AI Agent 任务中的协作关系：
用户发出指令："帮我修复登录页面的 bug 并部署"
│
▼
┌─────────────────────────────────────────────────────────┐
│ AI Agent 系统 │
│ │
│ ① Rule 检查：确认操作权限、代码规范约束 │
│ │ │
│ ▼ │
│ ② Memory 检索：调取项目架构、技术栈、历史 bug 修复经验 │
│ │ │
│ ▼ │
│ ③ Context 组装：System Prompt + Rules + Memory │
│ + 当前文件 + 对话历史 → 构成完整 Context │
│ │ │
│ ▼ │
│ ④ Planning：分解为 [定位bug → 修复 → 测试 → 部署] │
│ │ │
│ ▼ │
│ ⑤ Loop 执行： │
│ ┌─────────────────────────────────────────┐ │
│ │ Thought: 先搜索登录相关代码 │ │
│ │ Action: 调用搜索工具（Tool/MCP） │ │
│ │ Observe: 找到 login.tsx 第 42 行有问题 │ │
│ │ Thought: 修改验证逻辑 │ │
│ │ Action: 调用文件编辑工具 │ │
│ │ Hook: before_tool_call → 检查分支 │ │
│ │ Observe: 修改成功 │ │
│ │ Thought: 运行测试验证 │ │
│ │ Action: 调用终端执行 npm test │ │
│ │ Observe: 全部通过 │ │
│ │ Thought: 执行部署（触发 Skill） │ │
│ │ Action: /deploy skill │ │
│ │ Observe: 部署成功，返回 URL │ │
│ └─────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ⑥ 输出结果 + 更新 Memory（记住这次 bug 的修复方式） │
│ │
└─────────────────────────────────────────────────────────┘
│
▼
用户收到："已修复并部署，访问 https://xxx.com 验证"
十、学习路径建议
阶段一：Prompt 熟练工（1~2 周）
- 掌握角色设定、上下文提供、格式指定、Few-shot、CoT 五大技巧
- 在日常工作中刻意练习"把需求说清楚"
- 推荐练习：同一个任务用 5 种不同的 Prompt 方式提问，对比输出质量
阶段二：Context 管理者（2~4 周）
- 理解 Context Window 的限制和"Lost in the Middle"效应
- 学会精选信息注入，而非"全部丢给 AI"
- 开始使用 Rules 和 Memory 功能，减少重复劳动
- 推荐练习：为一个真实项目配置完整的 Rules 和 Memory
阶段三：Agent 驾驶员（1~2 月）
- 熟练使用 Agent 模式完成多步任务
- 理解 Loop 的运转机制，能判断 AI "卡住"时该如何干预
- 学会使用 Tools/MCP 扩展 Agent 能力
- 推荐练习：用 Agent 模式完成一个完整的 feature 开发（从需求到部署）
阶段四：系统设计者（持续精进）
- 能设计 Skill、配置 Hooks、编排定时任务
- 理解多 Agent 协作模式，能判断何时需要蜂群
- 能评估 AI 方案的可靠性和成本
- 推荐练习：为团队设计一套 AI 辅助开发工作流
十一、写在最后
回顾整条演化链：
Prompt（会说话）
→ Context（看得见）
→ Harness（有规矩）
→ Loop（能循环）
→ Agent（会做事）
→ 蜂群（能协作）
每一步的进化，都是在解决前一步的核心瓶颈： - Prompt 解决了"如何跟 AI 说话" - Context 解决了"AI 能看到什么" - Harness 解决了"AI 的行为如何可控" - Loop 解决了"AI 如何自主完成多步任务" - Agent 解决了"AI 如何成为完整的执行体" - 蜂群解决了"多个 AI 如何分工协作"
而那些看似繁杂的名词——Rule、Memory、Skill、MCP、Hooks、定时任务、插件——它们不是独立的概念，而是分布在演化链不同位置的零件，共同组装出了今天你手中的 AI Agent 工具。
理解了这张全景图，你就不再是一个"按按钮的用户"，而是一个知道机器内部如何运转的驾驶员。这将帮助你在 AI 工具快速迭代的时代，以不变应万变——因为底层逻辑，从未改变。