当前位置：首页 > news >正文

20个核心概念+1张图！彻底搞懂AI Agent的底层架构，告别学习混乱！

news 2026/7/8 8:45:20

过去一年，几乎所有 AI 产品都开始做 Agent。

Claude Code、Codex、Cursor、OpenHands、Hermes、OpenClaw……

名字越来越多，概念也越来越多。

Memory、MCP、Skills、Harness、Context Engineering、Prompt Cache、KV Cache、Guardrail、Human in the Loop……

很多人学了一圈，最后会有一种很微妙的感觉：

“
每个词单独看，好像都认识。
但它们放在一起，就不知道彼此之间到底是什么关系。

我一开始学 Agent 的时候，也卡在这里。

后来发现，问题不是这些概念有多难，而是我们总是一个一个去学。

今天看 MCP，明天看 Memory，后天看 Context，最后脑子里全是碎片。

但Agent 不是一堆概念的拼盘。

它更像一套完整的工程系统。

如果把 Agent 看成一家正在工作的 AI 公司，那么：

Prompt 像老板；
Planning 像项目经理；
Tools 像外包工具；
Memory 像公司经验库；
Harness 像质检体系；
Guardrail 像法务和安全部门。

这样一看，关系就顺了。

今天我们就从一次完整的 Agent 工作流程出发，把20 个核心概念串起来。

先别急着背概念。

先看这张图。

一张图，看懂整个 Agent

flowchart TD A["用户提出任务"] --> B["Prompt<br/>任务说明与行为约束"] B --> C["Context<br/>当前可见信息"] C --> D["Agent Loop<br/>感知、决策、执行、反馈"] D --> E["Planning<br/>拆解任务和制定步骤"] E --> F{"需要外部能力吗？"} F -- "需要" --> G["Tool / MCP / JSON Schema<br/>调用工具和外部系统"] G --> H["Observation<br/>工具返回结果"] H --> D F -- "不需要" --> I["Reflection<br/>自我检查与修正"] I --> J["Harness / Evaluation<br/>验证是否完成"] J --> K{"结果可靠吗？"} K -- "不可靠" --> D K -- "可靠" --> L["Trace / Observability<br/>记录过程，方便复盘"] L --> M["Guardrail / Human in the Loop<br/>安全边界与人工审批"] M --> N["回复用户或提交结果"] O["Memory<br/>长期经验"] --> C P["Skills<br/>可复用能力包"] --> D Q["Prompt Cache / KV Cache<br/>降低重复计算成本"] --> C R["Hooks<br/>在关键节点插入自动动作"] --> D S["Benchmark<br/>衡量系统能力"] --> J

不要急着记每个名词。

先记住这条流程：

“
用户提出任务。 Agent 读 Prompt 和 Context，开始思考。它会先做规划，判断要不要调用工具。如果需要，它会通过 Tool、MCP、JSON Schema 这些机制连接外部系统。拿到结果后，它会继续判断、修正、验证。最后通过 Harness、Evaluation、Trace、Guardrail 这些工程机制，确保结果不是“瞎跑出来的”。

这中间的所有能力，就是我们今天要讲的 20 个概念。

第一站：Agent 为什么会“思考”？

我们先从最像“智能”的部分开始。

假设你对 Claude Code 说：

“
帮我完成一个网站。

它第一件事通常不是马上写代码。

一个稍微成熟点的 Agent，会先弄清楚几件事：

这个网站要做什么？
用什么框架？
当前项目里已经有什么文件？
哪些页面要改？
改完以后怎么验证？

这就是 Agent 和普通 Chatbot 的差别。

Chatbot 更像“你问一句，它答一句”。

Agent 则会围绕目标，自己拆任务、调用工具、检查结果。

Agent Loop：Agent 的主循环

Agent Loop 是整个系统的心跳。

它通常会反复做四件事：

感知：读取用户任务、上下文、工具返回结果；
决策：判断下一步该回复，还是该调用工具；
执行：调用工具、写文件、查资料、跑命令；
反馈：把执行结果放回上下文，继续下一轮判断。

Claude Code、Codex、OpenHands 这类产品底层都离不开这个循环。

区别只是：

有的 Agent 工具更多，有的上下文管理更好，有的安全边界更强。

Planning：先想清楚，再动手

Planning 就是任务规划。

比如用户说“帮我做一个网站”，Agent 不应该直接开始写 HTML。

它更应该先拆成几个步骤：

读取项目结构；
确认技术栈；
设计页面和组件；
修改代码；
启动项目；
检查页面效果；
修复错误。

这也是为什么很多 Agent 会先输出一个 plan。

不是为了显得聪明，而是为了减少乱做。

没有 Planning 的 Agent，很容易像一个刚入职但特别积极的实习生：

“
很努力，也很容易改错地方。

Reflection：为什么 Agent 会自己检查？

Reflection 可以理解成“做完以后回头看一眼”。

比如代码写完了，Agent 会问自己：

测试跑了吗？
页面真的能打开吗？
有没有报错？
用户要的是登录页，我是不是只做了首页？

Reflection 不是玄学。

它本质上是一种反馈机制：让模型根据结果重新判断自己有没有完成任务。

在写代码、做数据分析、生成报告这类任务里，Reflection 很重要。

没有 Reflection，Agent 很容易出现一种情况：

“
嘴上说“已经完成”，实际项目根本跑不起来。

第二站：为什么 AI 越来越像人？

很多人说，现在的 AI 越来越像“有记忆的人”。

其实它并不是真的像人一样记住了所有事。

它只是越来越会管理上下文。

Prompt：老板给的任务说明

Prompt 是 Agent 的任务说明和行为约束。

它告诉 Agent：

你是谁；
你要做什么；
你不能做什么；
遇到不确定情况要怎么处理。

一个 Agent 的 Prompt，不只是用户输入的那一句话。

它还包括 system prompt、开发者指令、工具说明、项目约束、用户偏好等一整套内容。

所以 Prompt 更像老板给员工的任务书。

任务书写得清楚，员工就不容易跑偏。

Context：Agent 当前“看得见”的东西

Context 是模型当前能看到的全部信息。

用户刚刚说的话、之前的对话、项目文件摘要、工具返回结果、系统规则，都可能在 Context 里。

很多人以为模型窗口越长越好。

但真实情况没这么简单。

Claude Code 明明支持很长上下文，为什么有时任务越做越笨？

问题往往不是窗口不够大，而是Context 太乱。

无关内容太多，关键内容就被淹没了。

这就是 Context Engineering 要解决的问题。

它不是简单地“塞更多内容”，而是决定：

什么该放进来；
什么该按需读取；
什么应该写到文件里；
什么根本不该让模型看。

Memory：长期经验，不是聊天记录仓库

Memory 是 Agent 的长期经验。

比如你经常要求：

代码风格要简洁；
文章口吻要像公众号；
生成视频脚本时要带分镜。

这些偏好如果每次都重新说，会很烦。

Memory 就是用来保存这类长期信息的。

但 Memory 不是把所有聊天记录都存进去。

更合理的 Memory 应该保存稳定、可复用的信息：

用户偏好；
项目背景；
常用流程；
反复出现的问题；
已经验证过的经验。

临时任务细节不应该随便写进长期 Memory。

否则用久了以后，Agent 会被自己的旧记忆带偏。

Prompt Cache：为什么稳定 Prompt 更省钱？

Prompt Cache 是为了减少重复计算。

如果多轮请求的前半部分完全一样，模型就可以复用之前计算过的内容，不用每次从头算。

这对 Agent 很重要。

因为 Agent 的 system prompt、工具定义、项目规则，往往很多轮都不变。

如果这些稳定内容放在前面，动态内容放在后面，就更容易命中缓存。

这也是为什么好的 Agent 不会每一轮都随便重排 Prompt。

“
结构稳定，本身就是一种工程优化。

KV Cache：模型推理时的“临时笔记”

KV Cache 更底层一点。

Transformer 在生成文本时，会为前面的 token 计算 Key 和 Value。

后面继续生成时，如果能复用这些计算结果，速度就会快很多。

你可以粗略理解成：

“
模型在读长文本时，会把前面读过的内容整理成一份临时笔记。

Prompt Cache 更偏产品和计费层面的复用。

KV Cache 更偏模型推理层面的复用。

它们都在说明一件事：

“
Agent 不只是“会想”，还要“想得起、算得快、别重复浪费”。

第三站：Agent 为什么会“干活”？

如果一个 AI 只能聊天，它还不算真正的 Agent。

Agent 之所以能干活，是因为它能调用外部能力。

写文件、查网页、跑命令、连数据库、操作浏览器、发消息，这些都不是模型本体完成的。

模型负责判断该做什么。

工具负责真的去做。

Tool：Agent 的工具箱

Tool 是 Agent 可以调用的具体能力。

比如：

read_file；
write_file；
run_command；
search_web；
open_browser；
query_database。

一个普通模型只能输出文字。

有了 Tool，它就能开始操作外部世界。

但 Tool 不是越多越好。

工具太多，Agent 反而容易选错。

好的 Tool 应该面向任务目标，而不是照搬底层 API。

比如让 Agent 调用：

{ "action": "update_article", "title": "文章标题", "content": "文章正文"}

通常比让它分别调用 get_article、update_title、update_body 更稳定。

MCP：不是 Agent，而是连接协议

很多人会把 MCP 和 Agent 混在一起。

其实MCP 不是 Agent。

MCP 更像一个标准接口，让 Agent 能连接外部工具和数据源。

比如一个 Agent 想访问 GitHub、Notion、数据库、浏览器、文件系统，就可以通过 MCP Server 暴露这些能力。

Agent 负责思考。

MCP 负责连接。

这两个不是一回事。

你可以把 MCP 理解成：

“
AI 世界里的 USB-C。

它不替你工作，但它让更多设备能接进来。

JSON Schema：工具调用的说明书

Agent 调用工具时，不能只说“帮我查一下”。

它必须给出结构化参数。

JSON Schema 就是用来描述工具参数格式的。

比如一个搜索工具可能要求：

{ "query": "AI Agent architecture", "limit": 5}

Schema 会告诉模型：

这个工具叫什么；
需要哪些字段；
字段是什么类型；
哪些是必填。

如果 Schema 写得含糊，Agent 就容易传错参数。

很多 Tool Calling 的问题，不是模型不会调用，而是工具说明写得太差。

Skill：可复用的能力包

Skill 和 Tool 不一样。

Tool 是具体动作。

Skill 更像一套做事方法。

比如：

写代码 Review；
部署项目；
改写公众号文章；
制作 Remotion 视频。

这些都可以做成 Skill。

Skill 通常会告诉 Agent：

什么时候用；
不要什么时候用；
具体步骤是什么；
输出格式是什么。

相比 Tool，Skill 更偏知识和流程。

一个好的 Skill，不是把说明写得很长，而是边界清楚。

比如：

“
Use when：用户要改写中文文章，去掉 AI 味。 Don’t use when：用户只是要翻译或总结。

这种描述比“本技能可以提高文本自然度和表现力”有用得多。

第四站：Agent 为什么没有翻车？

Agent 能干活之后，新的问题来了。

它会不会乱删文件？

会不会误发消息？

会不会改数据库？

会不会一本正经地完成一个错误任务？

所以企业里真正难的，不是让 Agent 动起来，而是让它别乱动。

Harness：把 Agent 圈在可控范围里

Harness 可以理解成围绕 Agent 的工程支架。

它包括：

测试；
约束；
验证；
兜底；
执行边界。

Anthropic 和 OpenAI 都很强调 Harness，因为真实系统里，模型能力只是其中一部分。

一个 Agent 能不能稳定完成任务，往往取决于 Harness。

比如写代码时，Agent 不能只说“我改好了”。

它要能跑测试、看日志、检查页面、确认结果。

没有 Harness，Agent 就像一个没人验收的外包团队。

“
干没干完，全靠它自己说。

Evaluation：怎么知道 Agent 真的做对了？

Evaluation 是评估系统。

普通聊天机器人评估起来还算简单，看回答好不好就行。

Agent 不一样。

它可能调用了十几个工具，改了文件，跑了命令，最后还修改了环境状态。

所以评估 Agent，不能只看它最后说了什么。

还要看：

过程有没有走错；
工具有没有选对；
文件有没有真的改；
测试有没有通过；
结果是否符合目标。

这就是为什么 Agent Evaluation 比普通 LLM Evaluation 难很多。

Trace：失败以后能不能复盘

Trace 是 Agent 的执行记录。

一个完整 Trace 应该记录：

每轮 Prompt；
每次模型输出；
每次 Tool Call；
工具参数；
工具返回；
错误信息；
最终结果。

为什么重要？

因为 Agent 失败时，问题可能不是最后一步。

它可能在三轮之前就选错了工具。

也可能一开始就理解错了任务。

没有 Trace，你只能看最后的失败结果。

有 Trace，才能知道它到底在哪一步跑偏。

Guardrail：安全护栏

Guardrail 是安全边界。

比如：

不能删除指定目录外的文件；
不能直接执行危险命令；
不能自动发外部消息；
不能在没有确认时写数据库；
不能泄露敏感信息。

这些规则不能只写在 Prompt 里。

真正可靠的 Guardrail，应该落到权限系统、工具限制、路径检查、审批流程里。

你不能只对 Agent 说“不要删库”。

你要让它根本没有权限删库。

Human in the Loop：什么时候必须让人确认？

Human in the Loop 指的是人工介入。

不是所有事情都应该全自动。

比如：

删除数据；
发送邮件；
发生产环境命令；
修改账单；
合并 PR；
对外发布内容。

这些操作最好有人确认。

企业 Agent 一定绕不开 Human in the Loop。

不是因为 AI 不够强，而是因为责任需要落在人类流程里。

第五站：为什么大家都在做 Agent？

现在看 Agent，不要只看 Demo。

真正的竞争，已经开始转向工程体系。

谁能稳定完成任务，谁能接入更多工具，谁能评估质量，谁能复盘失败，谁就更接近可用。

Benchmark：大家为什么都在刷 SWE-bench？

Benchmark 是基准测试。

比如 SWE-bench，就是用真实 GitHub issue 测试 Agent 修代码的能力。

为什么 OpenAI、Anthropic、各种 Coding Agent 都喜欢看这类榜单？

因为它比普通问答更接近真实任务。

修 bug 不是回答一道题。

它需要读代码、理解项目、定位问题、修改文件、跑测试。

这就是 Agent 的典型场景。

但 Benchmark 也不能迷信。

榜单成绩好，不等于在你的项目里一定好用。

它更像体测成绩。

“
能说明一部分能力，但不能代替真实工作表现。

Observability：企业为什么要监控 Agent？

Observability 是可观测性。

普通软件要监控接口耗时、错误率、CPU、内存。

Agent 也一样，只不过监控对象更多。

你要知道：

它调用了哪些工具；
哪些任务最容易失败；
哪些步骤 token 消耗最高；
哪些用户反馈最差；
哪些工具经常被误用；
哪些 Prompt 改动导致退化。

没有 Observability，Agent 就是黑盒。

它好像在工作，但你不知道它为什么成功，也不知道它为什么失败。

Hooks：在关键节点自动插入动作

Hooks 是钩子。

它可以在 Agent 执行流程的关键节点插入自动动作。

比如：

调用工具前做权限检查；
写文件后自动格式化；
跑命令前检查路径；
任务结束后自动生成摘要；
出错时自动记录 Trace；
提交前自动跑测试。

Hooks 很像 Agent 系统里的自动化规则。

它不负责思考，但它能让系统更稳。

Codex、Claude Code 这类工具里，Hooks 的价值会越来越明显。

因为很多确定性的事情，根本不该交给模型判断。

“
能用规则做，就用规则做。

最后，把 20 个概念串起来

如果把整个 Agent 比作一家 AI 公司，大概可以这样理解：

概念	在 AI 公司里的角色	作用
Prompt	老板的任务说明	决定 Agent 要做什么、不能做什么
Context	当前办公桌	放 Agent 此刻能看到的信息
Agent Loop	员工的工作节奏	感知、决策、执行、反馈
Planning	项目经理	拆任务、排步骤
Reflection	自检环节	做完后回头检查
Memory	公司经验库	保存长期偏好和经验
Prompt Cache	复用任务说明	减少重复计算和成本
KV Cache	临时阅读笔记	加速模型推理
Tool	具体工具	读文件、跑命令、查数据库
MCP	外部接口标准	把更多工具接进 Agent
JSON Schema	工具说明书	告诉模型怎么传参数
Skill	标准作业流程	保存可复用方法
Harness	质检体系	约束、测试、验证 Agent
Evaluation	考核标准	判断任务是否真的完成
Trace	工作记录	出错后能复盘
Guardrail	安全部门	限制危险操作
Human in the Loop	人工审批	高风险动作交给人确认
Benchmark	统一考试	衡量 Agent 能力
Observability	监控系统	看见 Agent 怎么运行
Hooks	自动化规则	在关键节点插入检查和动作