这篇文章主要梳理了AI Agent开发过程中可能会用到的一些概念，还会给每个概念做详细解释，帮那些从其他方向转型做AI Agent开发的开发者和团队，把对这些概念的理解统一起来，沟通的时候也能有一致的语言，减少不必要的误解，降低沟通成本。
里面主要包含LLM、Chat bot、Agent等15个核心概念的说明。
LLM
LLM，英文全称是Large Language Model，也就是咱们常说的大语言模型。先从“模型”本身说起，经过训练之后，模型就具备了接收特定输入、给出特定输出的能力。
而“语言模型”，就是把输入和输出的内容，都限定在了自然语言范围内。至于“大语言模型”，重点就在“大”上，指的是模型的参数量特别大，比如25年爆火的DeepSeek R1，参数量就达到了671B。
咱们输入给LLM的自然语言，会先通过Transformer转换成token，模型内部会根据输入的token，预测接下来该输出什么token，最后再把这些token转换成自然语言，这就是咱们看到的“模型输出”。这也是GPT名字的由来——Generative Pre-trained Transformer。
Chat bot
早期的语言模型，其实就只会模仿。比如你问它“北京天气怎么样”，它可能就会跟着这个句式，输出“南京天气怎么样”“成都天气怎么样”这种没用的答案。
后来模型经过不断训练，慢慢能回答用户的问题了，再问它“北京天气怎么样”，它就会给出一段看起来像模像样的回答，感觉就跟人聊天似的，这就是聊天机器人。像早期的ChatGPT、豆包、DeepSeek App这些AI助手，都能叫做Chat bot。
Agent
Prompt
Prompt，也就是提示词，说白了就是咱们发给LLM的自然语言。它一般分两种，一种是system prompt（系统提示词），另一种是user prompt（用户提示词）。
System prompt通常是内置在agent里面的，用户改不了，顶多只能通过配置的方式，往系统提示词里加一点内容。
User prompt一般是用户自己输入的，但有时候为了让Agent的能力更好，或者让用户用着更顺手，开发者也会帮用户补充一些user prompt。
Re-Act
LLM的能力可远不止聊天那么简单，怎么把LLM的智能和实际场景结合起来，真正落地用起来，这是研究者们一直都在琢磨的问题。
2022年的时候，姚顺雨的一篇论文Re-Act给出了方向，里面提出的reasoning-action-observation（推理-行动-观察）循环，奠定了现在主流Agent的基本架构，比如Manus、Claude Code、Cursor这些，都是基于这个架构来的。
还是拿天气问题举例子，用户问“北京明天天气怎么样”，首先LLM会在心里琢磨（也就是推理）：“用户想知道明天的天气，但我也不知道答案啊，不如让用户去搜一下”。
然后LLM就会做出动作——告诉用户“你去Google搜一下‘北京 明天 天气’，把结果发给我”。
用户照做之后，把搜索结果发过去，LLM就能观察到：“哦，搜索结果说明天是晴天”。接着LLM就会回答用户“北京明天是晴天”，这就是一个最简单的Re-Act循环例子。
RAG
RAG，英文是Retrieval-Augmented Generation，翻译过来就是获取增强生成。还是刚才查天气的例子，用户问LLM“北京明天天气怎么样”，有没有不用麻烦用户自己去搜索的办法？当然有。
我们可以先把北京未来7天的天气信息找出来，然后把这段文本和用户的问题一起发给大模型，这样LLM就能直接给出“北京明天是晴天”的答案了。
这就是获取增强生成的原理——先找到相关的上下文信息，再让模型结合上下文和用户的问题，总结出正确的回答。
这里有个容易弄混的点，就是RAG和向量数据库（Vector Database）的关系。其实RAG里的Retrieval（获取）环节，确实可以通过向量数据库来获取相关上下文，但并不是必须要用向量数据库。
比如咱们刚才举的例子，把北京过去七天的天气情况告诉模型，这段信息可能就是一段普通文本或者JSON数据，不一定是从向量数据库里查出来的。
Tool call
接着刚才查天气的例子往下说，如果用户问LLM“明天北京天气怎么样，如果是晴天，帮我买一张天坛的门票”。
天气信息可以用RAG来解决，但“买天坛门票”这件事，没法用“获取增强生成”来完成，LLM可能只会回答“明天天气不错，你可以去xxx购买门票”。那有没有办法让用户不用自己动手买门票呢？
我们可以给LLM提供一个“购买天坛门票”的工具，让模型能告诉我们的代码，需要调用这个工具。
然后我们在代码里执行这个购票工具，再把执行结果（比如“购票成功”）告诉模型，这时候模型就能根据这个结果，告诉用户“明天是晴天，门票已经帮你买好了”，这就是Tool call。
MCP
MCP，英文是Model Context Protocol，也就是模型上下文协议。通过Tool call，我们解决了模型没法和外部系统交互的问题，但作为一个Agent，比如Manus，显然不应该把“购买天坛门票”这种工具内置给模型用。
这时候，就可以基于模型上下文协议（MCP），搭建一个MCP Server，让LLM能调用MCP Server上声明的工具，从而实现和外部系统的交互。这里要特别注意一点：MCP本身就是一种协议，不是一个工具集。
在日常沟通里，经常会听到有人用错，比如“MCP协议”或者“我们应该提供什么MCP给他们用”，翻译成中文就是“模型上下文协议协议”和“我们应该提供什么模型上下文协议给他们用”，听着就很奇怪。
如果只是普通的AI使用者，分不清也没关系，但作为AI Agent的建造者，不管是不是技术岗位，都得正确使用这个概念。在MCP里，定义了三个参与者，分别是MCP Host、MCP Client和MCP Server。
MCP Host就是支持MCP协议的整个应用，比如Manus、Claude Code、Cursor；MCP Client是放在MCP Host里面的，作用是从MCP Server获取可用的工具列表，然后告诉LLM；MCP Server通过标准协议提供工具，也可以通过MCP Apps这类扩展，实现可交互的UI渲染功能。
Human-in-the-loop
首先得弄明白，这里的“loop”指的是什么。在Agent执行任务的过程中，在LLM给出最终回复之前，LLM调用工具，工具的结果再反馈给LLM，这个反复循环的过程，就是“loop”。
那Human-in-the-loop（简称HITL）又是什么呢？
目前Agent行业里，对HITL还没有统一、明确的定义。一般来说，在Agent的循环过程中，有两种情况需要人参与：一种是需要人工审批，判断某个工具是否应该用特定的参数去调用；另一种是需要人的输入，把这个输入作为工具结果，放到LLM的上下文中。
LangChain对HITL的定义比较具体，特指执行Tool call之前的用户审批，也就是确认要不要执行这个工具。
Claude那边没有专门用HITL这个词，统一叫做user input，还分成了tool approval request（工具审批请求）和clarifying request（澄清请求），正好对应咱们刚才说的两种需要人参与的情况。
我个人更倾向于Claude对HITL的定义，因为这两种情况本质上都是打断Agent的循环，等待用户输入，只是需要用户输入的目的和内容不一样而已。
简单说，HITL主要分两种类型，一种是Human as gatekeeper（人作为守门员，负责审批），另一种是Human as tool（人作为工具，提供信息）。
为什么需要 HITL？
首先是 Human as gatekeeper。以 Claude Code 这类 Agent 为例，它们自带 Bash tool，而部分 Bash 命令存在操作风险，比如 rm 命令。
在 LLM 调用 Bash tool 之前，需要人工确认，是否同意用指定参数执行该工具。这就是 Human as gatekeeper 的作用。
其次是 Human as tool。以 Claude Code 里的 AskUserQuestion tool 为例，在 Agent loop 中，LLM 如果需要补充信息，可以通过这个工具向用户提问。
用户的输入会作为 tool result 存入 LLM 上下文，LLM 再根据结果规划下一步动作。
对用户来说，两种 HITL 的输入输出分别是什么？
首先是 Human as gatekeeper。它由规则触发，给用户的输入是固定三类选项：同意（Approve）、修改（Edit）、拒绝（Reject）。
常用的是 Approve 和 Reject。Edit 会改动 tool call 参数，容易造成 LLM context confuse，一般不推荐使用。用户的输出就是决策：同意或拒绝本次工具执行。
如果用户 Approve，工具会正常执行，并把结果作为 tool result 加入 LLM 的 context list。
如果用户 Reject，工具不会实际执行，Agent 开发者会构造一条 tool result 告诉 LLM 本次被拒绝，LLM 再据此观察并规划下一步。
其次是 Human as tool。由 LLM 的 tool call 触发，是否触发、内容是什么都不固定。
我们只能用 JSON schema 定义这个工具的入参结构。对用户而言，收到的是模型生成、符合结构的自然语言问题。用户的输出一般也是自然语言，部分也支持多模态。
需要注意，有一种很容易和 HITL 混淆但不属于 HITL 的交互。同样以 Claude Code 为例：它在最终结果里让用户输入的问题，本质只是 LLM 的最终输出。
这时候一轮 Agent loop 已经结束，用户再次发消息会开启下一轮 loop（同会话保留历史上下文）。所以这种交互不算 HITL。
Context Engineering
Context Engineering 也就是上下文工程。在 Agent loop 里，system prompt、user prompt、一轮轮 tool call 和 tool result 会快速占满上下文。
但 LLM 的 context window 是有限的，目前大模型一般是 200K tokens，部分支持 1M tokens。因此需要做上下文工程，控制 LLM 接收的 context list。
上下文工程手段很多，但核心思路一致，下面介绍几个常见概念。
Agent Skills
这是 2025 年 10 月以来 AI 圈最火的词之一，尤其是“养虾”热潮之后，热度直接拉满。
经常能听到：给你的龙虾加个 xxx skill，它就能 xxx 了。听起来 skill 好像能解决一切问题。但本质上，Skill 到底是什么、解决什么问题？
拿查天气、逛天坛举例。我们给 LLM 开放了查天气和买门票的工具，LLM 只知道这两个工具的参数结构，不知道怎么组合使用才能满足用户需求。
常见方案有两种：
一是做“旅游 Agent”，在 system prompt 里教 LLM 怎么用这两个工具。但这个 Agent 就只能干这件事，想做别的就要改 prompt，改多了又容易让 LLM 混淆，最后什么都做不好。方案不可行。
二是靠 prompt 高手手动教 Agent 怎么用工具，但这段 prompt 很长，每次输入麻烦，用户也不好管理模板。
有没有更优雅的方式？Claude Skills（后来发展成 Agent Skills 标准）就这么来了。
Skill 本质就是一段 prompt 模板，用来解决动态注入上下文的效率问题。
至于“上下文渐进式披露”“脚本执行能力”，都是 LLM 能调用 Bash tool 自然带来的效果。
就算不按 Skills 规范，在一个 markdown 里引用另一个 markdown，LLM 需要时也会去读取，实现渐进式披露上下文。
Memory
Memory 也就是记忆，通常分短期记忆和长期记忆。
短期记忆很好理解：同一个会话里，希望 LLM 记得之前几条对话内容。一般在用户发新消息时，把历史消息一起带给 LLM 就行。
长期记忆指跨会话的上下文传递。比如用户在会话 1 说自己是程序员，会话 2 希望不用重复，LLM 也知道。
最简单的实现是把会话 1 的历史带到会话 2，但两个话题可能完全无关，反而会 confuse LLM。
Agent 里实现长期记忆，通常会加一个外挂步骤：
提取值得长期记住的信息存起来；同时在用户发 prompt 时，把之前存储的、和本次任务相关的记忆追加到 user prompt 里。
这样看起来 Agent 就有长期记忆了，本质其实是 RAG 的一种实现方式。
Sub-agents
不要把人类的思维限制，硬套在 Agent 身上。—— Peak Ji from Manus
首先明确：sub-agent 最大作用是隔离上下文，而不是模拟“过家家”。
处理复杂长任务时，需要大量 wide & deep research，先攒够上下文再执行。
如果不用 sub-agent，所有内容都塞在同一个 LLM 的 context list 里，很可能 research 还没做完，上下文就爆了，任务无法完成。
但仔细看塞满的上下文，很多内容和最终任务无关，只需要一个结论。这些内容不必留在主 Agent 上下文，只要结果就行。
这时候就适合用 sub-agent：它维护独立的 context list，把无关上下文隔离，只把最终结论传给主 Agent。这样主 Agent 就不会被无关信息干扰。
之前 OpenClaw 火的时候，有人设计“三省六部制”Agent 体系，这就是典型的反例——用 sub-agent 过家家。
第一，每个角色依然可能遇到上下文爆炸问题；
第二，Agent 之间的上下文传递、共享、交互逻辑非常复杂。
人与人沟通都有信息差，没有合理设计，Agent 之间也会出现大量 gap，整体效果大打折扣。
Context Offload / Compaction
就算合理拆分 sub-agent，对长难任务来说可能依然不够。
而且对 LLM 而言，不是上下文塞满才影响效果，达到一定长度就会出现 context pressure，输出 EOS token 概率大幅上升。表现就是质量骤降，疯狂列点、只写总结、句子变短。
所以需要上下文卸载（Offload）和压缩（Compaction）。
上下文卸载：某些内容用过就没用了，比如 Coding Agent 读过文件 A，后续不再需要。
可以把文件内容替换成提示：文件存在硬盘 xxx 位置，需要再读取。相当于把上下文存到外部文件系统，需要再加载，属于无损释放。
上下文压缩：历史内容太多，卸载也不够时，对历史做总结，用总结代替原始上下文。这个过程通常是有损的，部分细节会丢失。
Harness
Harness 原意是马缰、缰绳。在 Agent 里，LLM 就是马，除 LLM 以外的一切都属于 harness。
给 LLM 设计的 tool、做的上下文工程，都属于 harness。
Harness 比 Framework 抽象层级更高。Framework 只是提供做马缰的方法，Harness 才是完整的马缰。
比如 LangChain 体系里：
LangGraph 是底层流程控制 Framework
LangChain 是 Agent 相关 Framework
DeepAgents 则是 Agent Harness
因为 DeepAgents 在 LangChain 基础上，封装了内置 tool 和上下文工程，所以它是 Harness 而非 Framework。
Trace & Evaluation
Agent 开发和传统软件开发最大区别：
传统软件逻辑基本写死在代码里，数据来源、参数传递、执行顺序都确定；
Agent 开发中，函数执行由 LLM 返回的 tool call 和参数触发，上线前很难预知行为。
所以 trace（追踪）和 evaluation（评估）格外重要。
线上问题排查，需要看执行了哪些 tool call、哪些不符合预期；
代码或 prompt 变更后，要提前评估对 Agent 表现的影响。
Workflow vs Agent
Workflow 是执行逻辑和步骤由代码提前定义的系统。里面可能有 LLM 节点，但多用于意图识别、信息提取、总结等，职责固定、功能单一，很少需要 tool，靠 prompt 即可。
有人叫它 Agentic Workflow，但本质还是 Workflow，和 Agent 是两回事。
Agent 是执行逻辑和顺序由 LLM 通过 tool call 动态控制的系统。
最大区别：逻辑是代码预定义，还是 LLM 动态决定。
所以 Agent 主体代码通常很简单，以 OpenClaw 底层依赖 pi-agent 为例，只有两层循环：外层处理等待消息，防止 loop 结束；内层处理一轮 loop 里的 tool call 和 messages。
通用 Agent vs 垂直 Agent
区分通用和垂直 Agent，主要看输入输出设计。
通用 Agent 比如 Manus、Claude Code、Cursor，把更多输入输出交给用户。
输入方面：用户要配置各类 MCP server、skill，甚至自己开发 MCP 或 CLI 工具，让 Agent 对接现有系统。
输出方面：一般只在自身平台展示，想输出到飞书、Telegram 等需要额外配置或开发。
垂直 Agent 会帮用户承担更多输入工作，输出形态也不同。
比如 Notion Agent、Figma Make，内置了对应工具，减少用户配置。
Notion Agent 输出直接是文档修改结果；Figma 输出直接是设计稿。
两者技术架构趋同，主要区别只是内置 tool 不同。
由此引出一个问题：Notion、Figma 这类工具平台，应该给通用 Agent 做工具，还是自己做 Agent？
我的观点是：两者可以同时做，不冲突。
从用户角度：用户付费后，还要再买 Manus 或 Claude Code 会员才能用 Agent，体验很奇怪。所以要做自己的 Agent，让只用单一工具的用户在平台内获得完整体验。
从未来角度：未来大部分软件的用户会是 Agent 而非人类。通过 MCP server 或 CLI 提供易用工具，是软件保持竞争力的基础。所以也要给通用 Agent 做工具。
从商业角度：是否自己做 Agent 目前还存疑。截至 2025 年底，就算 Manus 这样成功的 Agent，仍在补贴用户体验，现阶段还不算靠 token 低买高卖的盈利模式。
