返回博客列表

Agent到底是什么：一篇大白话讲透全部组件

2026-08-15T04:30:00+08:00
AgentLLMMCPSkillsReActEvalTrace大白话

Agent 到底是什么：一篇大白话讲透全部组件

跟着做一遍，5 分钟搞懂。搞不定评论区问我。

网上讲 Agent 的文章不是堆术语就是画一堆看不懂的架构图。这篇不搞那些，用大白话把 Agent 的每个零件讲清楚。

Agent 是什么

一句话：Agent 是一个能自己想办法完成任务的 AI。

普通 LLM 是「你问一句它答一句」。Agent 是「你给一个目标，它自己拆步骤、调工具、遇错重试、直到干完」。

区别就像计算器和员工。计算器你按一下算一下，员工你说「把这个报表做完」，他自己打开 Excel、找数据、写公式、检查错误、交给你审。

Agent 就是那个员工。但这个员工有个前提：它的所有行为能力，都来自你给它设定的「岗位说明书」。

本文提纲

用一张图先看全貌，然后逐个拆解每个零件。

graph TB
    SP["System Prompt
job description + tools + skills"] --> AG["Agent"]
    UP["User Prompt
task for this run"] --> AG
    AG --> PL["Plan
break down complex tasks"]
    PL --> RL["ReAct Loop
core execution cycle"]
    RL --> TL["Tool / MCP / Skill
call when needed"]
    TL --> RL
    RL --> UP2["Update Plan
end of each loop"]
    UP2 --> RL
    RL --> SUB["Sub-Agent
split complex steps"]
    SUB --> RL
    RL --> MEM["Memory
short + long term"]
    RL --> GR["Guardrails
safety checks"]
    RL --> EVAL["Eval
quality gate"]
    RL --> TR["Trace + Observability
see what happened"]
    RL --> TOK["Token Optimization
cost control"]
    style SP fill:#FF6B6B,color:#000000
    style UP fill:#FF6B6B,color:#000000
    style RL fill:#4ECDC4,color:#000000
    style TL fill:#45B7D1,color:#000000
    style EVAL fill:#FFEAA7,color:#000000
    style TR fill:#96CEB4,color:#000000

System Prompt：岗位说明书

Agent 开工前，系统先给它灌一段话。这段话叫 System Prompt，本质是岗位说明书。

它告诉 Agent 三件事：

你是干什么的。 「你是一个客服 Agent」「你是一个代码审查 Agent」「你是一个 SRE 值班 Agent」。角色定义了 Agent 的行为边界——客服不该帮你改代码，代码审查 Agent 不该帮你下单退款。

你可以用什么工具。 工具列表就是 Agent 的「工具箱」。查数据库是一个工具，调 API 是一个工具，发邮件是一个工具。没有列在工具箱里的东西，Agent 不能用。

你有什么 Skills。 Skill 是领域知识包——比如「退款政策」「安全规范」「部署流程」。Agent 在匹配到相关场景时自动加载对应 Skill，不需要每次都翻文档。

MCP（Model Context Protocol）是工具的标准化接口。Agent 不用关心每个工具怎么连，MCP 统一了协议——就像 USB-C 统一了充电线。NOOA 的做法是 MCPManager.create_from_server("wiki") 一行接入，Claude Code 用 .mcp.json 配置文件，格式通用。

System Prompt 在整个执行过程中始终在场，不是用完就扔。每一步 LLM 调用时，System Prompt 都会被带上——它是 Agent 的「常驻记忆」。

User Prompt：这次的任务单

System Prompt 是岗位说明书（长期有效），User Prompt 是这次的任务单（用完即弃）。

「帮我查一下订单 #12345 的物流状态」——这是 User Prompt。它告诉 Agent 这次执行的目的是什么。

User Prompt 不需要重复 System Prompt 里已经说过的规则。你不用每次都告诉客服 Agent「你是客服」——岗位说明书已经写了。你只需要说这次要干什么。

好的 User Prompt 有三个特征：目标明确、约束清晰、不包含实现细节。「实现一个 REST API」是糟糕的 User Prompt（太泛）。「实现 GET /orders/:id 返回订单详情，错误时返回 404」是好 User Prompt。

Plan：复杂任务先做计划

Agent 拿到任务后，如果任务简单（比如「查一下天气」），直接进 ReAct Loop 执行。

如果任务复杂（比如「帮我把这个项目从 JavaScript 迁移到 TypeScript」），Agent 先做一个 Plan——把大任务拆成步骤：

  1. 扫描项目，列出所有 .js 文件
  2. 为每个文件创建 .ts 版本
  3. 修改 tsconfig.json
  4. 修复类型错误
  5. 跑测试
  6. 提交 PR

Plan 不是一成不变的。每执行完一步，Agent 可以更新 Plan——发现步骤 3 比预想的复杂，可以拆成 3a 和 3b；发现步骤 4 已经被步骤 2 顺带解决了，可以删掉。

这就是 NOOA 的 ... 方法体背后的逻辑——方法签名是 Plan 的一个步骤，方法体 ... 告诉运行时「这个步骤交给 LLM 执行」。

ReAct Loop：核心执行循环

这是 Agent 的心脏。ReAct = Reason + Act，推理 + 行动。

每个循环做四件事：

Reason（推理）： LLM 看 System Prompt + User Prompt + 之前的执行历史 + 当前 Plan 步骤，决定下一步干什么。

Act（行动）： 如果 LLM 判断需要调用工具，就调。查数据库、读文件、调 API、执行代码——都是 Act。

Observe（观察）： 把工具返回的结果加到上下文里。「数据库返回了 3 条记录」「文件读取成功，内容是...」

Update（更新）： 更新 Plan，进入下一个循环。

循环直到任务完成或者 Agent 判断无法继续（需要人类介入）。

一个具体的循环长这样：

Loop 1:
  Reason: "用户要查订单 #12345 的物流。我需要先查数据库。"
  Act:    调用 query_database("SELECT * FROM orders WHERE id = 12345")
  Observe: 返回 {id: 12345, carrier: "SF", tracking_no: "SF123", status: "shipped"}
  Update:  Plan 更新 — "已获取订单信息，下一步查物流"

Loop 2:
  Reason: "订单已发货，承运商是顺丰。我需要查顺丰物流。"
  Act:    调用 mcp_tool("sf_tracking", {tracking_no: "SF123"})
  Observe: 返回 {status: "在途", location: "深圳转运中心", eta: "8月16日"}
  Update:  Plan 更新 — "已获取物流信息，任务完成，生成回复"

Loop 3:
  Reason: "信息齐全，可以回复用户了。"
  Act:    生成最终回复
  Observe: "您的订单 #12345 已发货，顺丰快递 SF123，
            目前在深圳转运中心，预计 8月16日送达。"
  Update:  任务完成，退出循环

三次循环，三个推理-行动-观察-更新。这就是 Agent 执行任务的基本节拍。

工具调用：MCP 和 Skills

工具调用发生在 Act 阶段。Agent 有三类「工具」可用：

普通工具： 就是普通的函数调用。查数据库、读文件、发 HTTP 请求。NOOA 里就是一个普通的 Python 方法，有真实函数体的方法直接执行，不经过 LLM。

MCP 工具： 通过 MCP 协议连接的外部服务。MCP server 可以是本地的（stdio 传输）也可以是远程的（HTTP + OAuth）。MCP 的价值是标准化——同一个 MCP server 可以被 Claude Code、Codex、NOOA、Pi 任何 Agent 框架使用，不用为每个框架写适配。

Skills： 不是工具，是知识。Skill 告诉 Agent「在某个场景下应该怎么做」，而不是「调用什么 API」。比如一个「退款政策」Skill 告诉 Agent「30 天内已签收的订单可以全额退款，超过 30 天需要主管审批」。Agent 读了 Skill 后自己判断当前订单是否符合退款条件——这个判断是 LLM 推理，不是函数调用。

区分工具和 Skill：工具是手（做什么），Skill 是脑子里的知识（怎么做）。

子 Agent：拆分和并行

复杂任务的某一步可以创建子 Agent 来执行。子 Agent 有自己独立的 System Prompt、工具集和上下文，不共享父 Agent 的执行历史。

为什么要子 Agent？两个原因：

上下文隔离： 父 Agent 的上下文窗口有限。如果某一步需要大量信息（比如「分析整个代码库的依赖关系」），把这一步交给子 Agent，避免污染父 Agent 的上下文。

并行执行： 如果 Plan 里有多个互不依赖的步骤，可以创建多个子 Agent 并行跑。父 Agent 等所有子 Agent 返回后汇总结果。

Anthropic 的「Scaling Managed Agents」博文讲的就是这个模式——「decoupling the brain from the hands」（把大脑和手分开）。大脑（父 Agent）做规划和决策，手（子 Agent）做执行。

Memory：记忆系统（补充）

Memory 是 Agent 的记忆。分两层：

短期记忆（上下文窗口）： 就是当前对话/执行的历史。System Prompt + User Prompt + 之前所有 Loop 的推理和工具返回。上下文窗口有限（200K token 听起来多，但一个复杂任务很快就满），满了需要摘要压缩——把前面的对话浓缩成关键信息，腾出空间给新内容。

长期记忆（跨会话）： 跨多次执行的持久记忆。「上次用户问了什么」「这个客户的历史偏好」「上次类似问题的解决方案」。NOOA 的 nooa-memory 包提供 MemoryManager，Diagram Design 的 profile 系统也是一种长期记忆（品牌偏好跨会话保持）。

没有 Memory 的 Agent 像金鱼——每次对话从零开始。有 Memory 的 Agent 像老员工——记得你的偏好和历史。

Guardrails：安全护栏（补充）

Agent 能调工具能执行代码，意味着它有能力搞破坏。Guardrails 是安全护栏，定义了 Agent 不能做什么。

三个层次：

输出验证： LLM 生成的回复在发出前检查——不能包含敏感信息、不能有有害内容、格式必须符合要求。这是最外层的护栏。

行为约束： Agent 执行代码前的 AST 检查、模块黑名单、文件系统访问限制。NOOA 做了这层——但明确说这只是 defense-in-depth，不是真正的隔离边界。

OS 级隔离： 真正的护栏。容器、VM、NVIDIA OpenShell 沙箱。Agent 能 open() 任意文件？没关系，在容器里 open() 只能碰到容器内的文件。Docker Sandboxes 做的就是这件事——给每个 Agent 独立的 Linux 内核和文件系统。

NVIDIA 说得很直接：The containment boundary is OS-level isolation. 进程内的检查器防不住恶意代码，只有操作系统级隔离才是真正的边界。

Error Handling：出错怎么办（补充）

Agent 执行中会出错——工具调用超时、LLM 返回格式不对、数据库连接断开。没有 Error Handling 的 Agent 遇到错误就卡死。

好的 Error Handling 做三件事：

重试： 瞬时错误（网络超时、API 限流）自动重试，指数退避（1s → 2s → 4s → 8s），最多 3 次。

降级： 工具不可用时走 fallback。查物流 API 超时？返回「物流信息暂时不可用，您的订单已发货，运单号 SF123」——不报错，给用户能用的信息。

上报： 连续失败 N 次后，不要死循环，要上报给人类。「连续 3 次调用失败，需要人工介入」——这是 Claude Tag 值班 Agent 的设计：Agent 自己判断什么时候该 page 人类。

Error Handling 是 Agent 从 demo 到生产的最小差距之一。demo 里一切顺利，生产里什么都可能出错。

Eval：生产环境的真正难点

Agent 跑得通不等于跑得好。Eval（效果评估）是判断 Agent 质量的体系。

传统软件的测试是确定性的：输入 A，期望输出 B，不是 B 就是 bug。Agent 的输出是 LLM 生成的自然语言或工具调用序列，判断「对不对」本身需要推理。

这就是 HarnessEval-W 做的事——把评测本身变成一个 Agent 任务。不是跑个 assert 就完事，是让一个评测 Agent 推理「这个输出是否满足规格」，输出带完整推理链的判定（evidence tree）。

Eval 三个层次：

单元评测： 单个工具调用是否正确。调对了 API？参数格式对？返回值合理？

端到端评测： 完整任务是否完成。用户要查物流，最终回复里有没有物流信息？信息对不对？

回归评测： Agent 升级后（换模型、改 prompt、加工具），之前能完成的任务还能完成吗？不能因为加了新功能搞坏了旧功能。

Eval 是 Agent 上生产环境最难的一步。Anthropic 在 Claude Code 的 auto mode 设计里明确做了「分级权限 + 可审计的操作日志」——先做小范围 Eval 再放开权限。

Trace + Observability：可观测性

Agent 执行一次任务可能有几十次 LLM 调用、十几次工具调用、多个子 Agent。出了问题怎么排查？

Trace： 记录每一步——什么时间调了什么 LLM、传了什么 prompt、工具返回了什么、推理过程是什么。NOOA 的设计是「每个 LLM 调用、代码执行和方法调用都默认 traced，保留父子 span 关系」。

Observability： 不只是记录，还要能看懂。NOOA 有内置 trace viewer（nooa start-dev 启动），Anthropic 的 Claude Code auto mode 有完整的操作日志。trace 的价值是事后分析：为什么 Agent 在这一步选了这个工具？为什么这个循环花了 30 秒？哪一步的 token 消耗最大？

没有 Trace 的 Agent 像黑盒——出了问题只能猜。有 Trace 的 Agent 像有行车记录仪——每一步都有据可查。

Token 优化：成本控制

Agent 每次循环都要调 LLM，每次调 LLM 都花钱。一个复杂任务跑 20 个循环，每个循环带 100K token 的上下文，就是 2M token 的消耗。

Token 优化的五个手段：

上下文压缩： 不把所有历史原样传给 LLM，压缩成摘要。对话越长，压缩越重要。

模型路由： 简单步骤用便宜模型（Haiku），复杂步骤用强模型（Opus）。Cursor Router 就是做这个的——自动选模型。

Prompt Caching： Anthropic 的缓存机制让重复的 System Prompt 打一折。固定不变的部分缓存，只传变化的部分。

渐进式加载： Skill 和工具定义不全部加载，只在需要时加载。NOOA 和 Diagram Design 都是这个设计。

Plan 优化： 好的 Plan 减少无效循环。如果 Plan 设计得好，10 个循环就能完成的任务不需要跑 30 个循环。

还缺什么？补四个

上面的组件覆盖了 Agent 的主干。还有四个经常被忽略但上生产就不能没有的：

Human-in-the-loop： 敏感操作需要人类批准。Agent 要删数据库？先停下来等人类确认。Claude Code 的 auto mode 不是无脑自动，是分级权限——低风险自动执行，高风险必须人工确认。

成本预算： 不只优化单次 token，还要设总量上限。「这个任务最多花 1 美元」，超了就停。防止 Agent 死循环烧钱。

幂等性： Agent 被中断后重启，不应该重复执行已经完成的步骤。Plan 的每一步有状态标记（pending / in_progress / done），重启时从第一个 pending 步骤继续。

多模态： Agent 不只能处理文字。能看图（截图分析 UI）、能听音频（语音输入）、能生成图（架构图）。Claude Code 可以截图分析代码界面，Diagram Design 生成可视化输出。多模态是 Agent 从文本助手到全栈助手的跳板。

完整的 Agent 组件清单

组件 大白话 关键设计
System Prompt 岗位说明书 角色 + 工具 + Skills，始终在场
User Prompt 任务单 目标明确，不包含实现细节
Plan 工作计划 复杂任务先拆步骤，可动态更新
ReAct Loop 干活循环 Reason → Act → Observe → Update
Tool / MCP / Skill 工具箱 + 知识库 手（工具）和脑子（Skill）分开
Sub-Agent 分身术 上下文隔离 + 并行执行
Memory 记忆 短期（上下文窗口）+ 长期（跨会话）
Guardrails 安全护栏 输出验证 → 行为约束 → OS 级隔离
Error Handling 出错处理 重试 → 降级 → 上报人类
Eval 质量门禁 单元 + 端到端 + 回归，Agent 化评测
Trace 行车记录仪 每步可审计，父子 span 保留
Token 优化 省钱 压缩 + 路由 + 缓存 + 渐进加载
Human-in-the-loop 人工审批 敏感操作必须人类确认
成本预算 预算上限 超额停止，防止死循环烧钱
幂等性 中断恢复 步骤状态标记，重启不重复执行
多模态 能看能听 图片 + 音频 + 生成可视化

16 个组件，构成了一个生产级 Agent 的完整检查清单。少任何一个，上生产时都会踩坑。

参考文档与链接

你的 Agent 上了几个组件？哪个最让你头疼？评论区聊聊。觉得有用点个赞让更多人看到。

作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。

分享给朋友

相关阅读

NVIDIA NOOA开源：Agent不是图不是链，是一个Python类

2026-08-15 NVIDIANOOAAgent

AI 技术日报 - 2026-08-02

2026-08-02 AI技术日报LLM

AI 技术日报 - 2026-08-01

2026-08-01 AI技术日报LLM

AI 技术日报 - 2026-07-31

2026-07-31 AI技术日报LLM