这个题材属于技术科普，我先把权威信源和 “7 个概念” 的原始出处查清楚，避免自己拼凑。
信源到手，而且发现一个有意思的点：不同机构对这 “7 个概念” 的切法并不一样。我在文里做了一张对照表，先把这件事说清楚，比硬凑七个词更有价值。
AI Agent 不是 "更聪明的聊天机器人"，而是 "一个模型加一整套架构"。模型只负责其中一件事 —— 推理；剩下六件事全是工程活儿：给它一个能判断何时停下来的目标、让它在权限内接收输入、把模糊意图拆成可验证的步骤、记住跨步骤的状态、真的动手调用工具、执行完回头检查自己有没有做错、需要时把任务分给多个角色协作。这七件事构成一个闭环，缺任何一环，任务就会以三种方式失败：卡住不动、跑偏不自知、或者停不下来一直烧钱。所以判断一个 Agent 能不能把你的任务做完，别看它模型多大，看这七层齐不齐。
一、先看清它和聊天机器人的分界线
| 维度 | 聊天机器人 | AI Agent |
|---|---|---|
| 交互形态 | 单轮问答，问完就停 | 多步执行，跑到目标达成为止 |
| 状态 | 无状态，每轮从零开始 | 有记忆，跨步骤、跨会话保留上下文 |
| 能力边界 | 只能输出文字 | 能调 API、查数据库、跑代码、写文件 |
| 自我检查 | 不做 | 执行完评估结果，发现偏差就改策略 |
| 人的介入 | 每一步都要人盯着 | 只在不可逆动作前设人工确认点 |
| 失败方式 | 答错 | 卡死、死循环、越权操作、误差累积 |
支撑这套差别的核心机制叫 ReAct 循环：思考（Thought）→ 行动（Action）→ 观察（Observation）→ 再思考。这个模式 2022 年由普林斯顿的论文提出，现在是生产环境里最主流的推理骨架，最大优点是 "可读"—— 每一步的思考都能被人看懂，出了问题能定位到具体哪一轮。
二、七个概念，逐层拆开
1. 目标（Goal）：不是 "帮我写份报告"，而是 "写到什么程度算完"
目标层要定三件事：任务边界、优先级、终止规则。终止规则是工程上最容易被忽略的，包括迭代上限、Token 预算、置信度阈值。
- 缺了会怎样：提前停止（误判完成，实际没满足需求）或者过度执行（没有终止条件，一直调工具直到预算烧光）。
- 落地做法：在系统提示里写清终态条件，并给一个显式的 "完成校验清单"，输出最终结果前先过一遍。
2. 感知（Perception）：它能接收什么，决策上限就在哪
感知是 Agent 的眼睛和耳朵，超出感知范围的信息对它等于不存在。真实场景远不止文字：表单、图片截图、结构化 JSON、工具返回值，每一条通道都要单独设计处理机制。
| 输入类型 | 处理方式 |
|---|---|
| 文字 | 语义理解 |
| 结构化数据 | 参数解析 |
| 图片 | 视觉模型 |
| 工具返回值 | 结果解析 |
- 缺了会怎样：某个通道没设计好，那个通道的信息就直接丢失，后面再强的模型也补不回来。
- 附带一层安全职责：输入必须做清洗和校验，防提示词注入。
3. 规划（Planning）：把 "我想要" 翻译成 "先做什么"
规划负责把模糊意图变成可执行步骤。这里有个反直觉的事实：规划质量高度取决于提示词设计和任务分解策略，而不是模型聪不聪明。同一个模型，换一套分解策略，执行质量能差 40% 以上。
- 拆得太粗：每步都超出工具能力，执行必失败。
- 拆得太细：步骤过多，误差累积。
- 可操作的判断标准：每个子任务的输出必须是明确可验证的，不能以 "处理完成" 这种没法判断的结论收尾。
4. 记忆（Memory）：三套机制拼出来的 "记得住"
LLM 本身没有记忆，Agent 的记忆是外挂拼装的，按时间维度分四类：
| 记忆类型 | 类比 | 存在哪 | 容量 | 用来干什么 |
|---|---|---|---|---|
| 工作记忆 | 人的短期记忆 | 模型上下文窗口 | 8K–200K tokens | 当前任务状态、最近几步的观测 |
| 情景记忆 | 自传体记忆 | SQL/NoSQL 数据库 | 不限 | 历史对话、过去任务结果、用户偏好 |
| 语义记忆 | 事实性知识 | 向量数据库 | 百万级文档 | 领域知识、产品文档、制度文件 |
| 程序记忆 | 技能与习惯 | 提示模板 + 工具 schema | 静态 | 工具用法、工作流模板 |
- 最常见的坑：以为 "记住" 就是丢进向量库。向量检索只比相似度，不比权威性和时效性 —— 问 "现在的定价政策是什么"，它可能翻出一份旧版 PPT，因为读起来一样像。
5. 工具调用（Tool Use）：LLM 只会写字，动手全靠这一步
工具调用分四步走：模型判断调哪个工具、传什么参数 → 宿主系统实际执行 → 结果作为观测值回传 → 模型基于结果继续推理。
- 决定成败的是工具定义质量。名称、描述、参数说明模型都会读，描述含糊，参数就填错，整条链路断掉。
- 有个实测上限值得记住：同时可调用的工具超过 20 个，选择准确率开始明显下降。工具集要按场景严格筛选，不能无差别全暴露。
6. 观测与反思（Observation & Reflection）：它能不能发现自己做错了
观测是每轮执行后环境给的反馈，是进入下一轮推理的唯一信息来源。两个典型工程问题：信息过载（返回一堆原始数据，反而抓不到信号）、信息缺失（出错只返回空值，链路直接卡死）。设计原则叫 "最小充分"—— 够支撑下一步决策，但不引入噪声。
反思是更高一层的能力：判断结果是否符合预期、识别偏差、调整策略。有两个数字可以参考：
- Reflexion 框架的实验结果是，反思循环在复杂推理任务上比标准 ReAct 表现好 15%–22%，且不需要额外训练。
- 更贴近工程的口径是：加入反思机制后，复杂多步任务成功率平均提升 25%–35%，但总耗时增加 15%–20%。
必须区分反思和重试：重试是失败后重复相同动作，反思是先分析失败原因再改策略。不分析原因的重试，第二次大概率还是失败。
7. 编排（Orchestration / Multi-Agent）：什么时候该拆成多个角色
拆分的动机只有一个：单个上下文窗口装不下全部信息时，决策质量必然下降。主流两种结构：
| 结构 | 怎么跑 | 适合什么 |
|---|---|---|
| 主管 - 执行（supervisor-worker） | 一个协调 Agent 拆任务，分给若干专精 Agent 并行或串行，再汇总结果 | 分支多、专业跨度大 |
| 顺序流水线（pipeline） | 固定顺序，上一步输出喂下一步 | 流程确定、线性可预测 |
但这里有个来自 Anthropic 工程实践的建议值得抄：能用一个 Agent 就别上两个。每多一个 Agent，就多一份协调开销，也多一层误差放大。一个范围清晰、工具给足的单 Agent，在多数标准流程上比多 Agent 更稳。
三、把七个概念串成一次真实任务
任务：让 Agent 调研五个竞品，做对比报告，发给策略组。
| 步骤 | 用到哪个概念 | 具体动作 | 失败会是什么样 |
|---|---|---|---|
| 1 | 目标 | 定义 "五个竞品 + 对比维度 + 发送对象"，设 3 步调研上限、Token 预算、置信度阈值 | 无限扩大调研范围，永远不结束 |
| 2 | 感知 | 解析用户给的竞品名单表格、附件里的历史报告 | 表格没解析，当成一段文字读，维度全错 |
| 3 | 规划 | 拆成：确定名单 → 逐个检索（可并行）→ 生成对比矩阵 → 写文档 → 查收件人 → 发邮件 | 一次让模型 "顺便把邮件也发了"，跳步 |
| 4 | 记忆 | 工作记忆存当前进度，语义记忆检索过往竞品资料，情景记忆记住上次谁提过什么要求 | 反复重查同一份资料，Token 翻倍 |
| 5 | 工具 | 搜索、DB 查询、文件写入、邮件 API，各带 JSON schema | 工具描述含糊，参数填错，调用失败 |
| 6 | 反思 | 写完报告先自查：五个都覆盖了吗？数据有出处吗？格式对吗？ | 少了一个竞品却直接交付 |
| 7 | 编排 | 若并行检索量太大，拆出 5 个检索子 Agent，各自产出结构化结果，主 Agent 只汇总 | 所有信息都塞进主对话，上下文爆炸 |
四、三家机构是怎么切这七块的
这件事没有标准答案，切法差异本身就是信息。
| 本文七概念 | Glean（2026-04）七组件 | 88 Labs（2026-07）七概念 | 产品经理老王（2026-06）十概念 |
|---|---|---|---|
| 目标 | Goal definition | AI Agent 定义 | 目标（Goal） |
| 感知 | Perception and input | — | 感知 |
| 规划 | Reasoning and planning | 规划（Planning） | 规划 + 推理（拆成两个） |
| 记忆 | Memory systems | 短期 / 长期记忆 | 记忆 |
| 工具 | Tool execution and action | 工具与接地（Grounding） | 工具使用 + 动作空间（拆成两个） |
| 反思 | Feedback and observability | 反思与自我修正 | 观测 + 反思（拆成两个） |
| 编排 | Orchestration and coordination | 单 Agent / 多 Agent | 多智能体协作 |
差异集中在三个地方：推理要不要和规划分开（老王分开了）、观测要不要和反思分开（老王也分开了）、动作空间要不要单列（老王认为权限边界必须独立成一个概念）。他的理由是：Agent 能改数据库、能写文件、能发外部请求，这不是提示词能控制的，是系统层面必须硬性划定的权限 —— 只读工具可以让它自主用，涉及状态修改的必须配人工确认。
五、真正决定成败的四个工程细节
- 终止条件必须显式存在。 不是 "模型觉得做完了"，而是代码层面有步数上限、Token 预算、置信度阈值。
- 工具定义当成接口文档来写。 名称、描述、参数 schema，写不清楚就等于让模型瞎猜。
- 上下文要主动管理。 Anthropic 的做法值得参考：阶段完成后把结论压缩进外部记忆，接近上限时开一个干净上下文的子 Agent 接力，子 Agent 的产出直接落盘、只把轻量引用回传主 Agent，避免 "传话游戏" 丢信息。
- 权限前置，不可逆动作必须人工确认。 发钱、发邮件、删数据，这三类操作无论自动化到什么程度，都该设确认点。
六、五种典型故障，对照排
| 故障 | 症状 | 对策 |
|---|---|---|
| 提示词注入 | 工具返回的内容里藏了 "忽略之前指令"，Agent 照做 | 输入清洗、工具输出与指令隔离、权限最小化 |
| 死循环 | 反复用同样参数调同一个工具 | 循环检测、步数预算、去重缓存 |
| 工具误用 | 调了不存在的工具，或参数类型错 | schema 校验、工具集精简、错误信息结构化 |
| 误差累积 | 第三步的小错传到第十步，得出自信但错误的结论 | 关键节点校验、反思机制、分阶段人工抽查 |
| 越界操作 | 把 "整理资料" 理解成 "顺手清理旧文件" | 动作空间硬限定、不可逆动作确认、沙箱执行 |
评估也别只看 "答得对不对"，要看四个指标：任务完成率（按难度分层统计）、步骤效率（实际调用数 vs 最短路径）、越界率、失败类型分布。
七、给不同角色的落地建议
| 角色 | 建议 |
|---|---|
| 想用 Agent 的个人 | 先看它有没有终止条件和人工确认点，再看它能调什么工具；能调文件写入和发邮件的，必须审权限 |
| 产品经理 | 概念对齐先于技术选型，先把目标、动作空间、记忆分层讲清楚再让研发动手 |
| 开发者 | 从单 Agent 起步，工具集控制在 20 个以内，先做观测日志再谈优化 |
| 企业采购 | 问三个问题：审计日志能不能导出？权限是不是在模型之前就做了拦截？出错的爆炸半径多大？ |
【相关 FAQ】
问题 1：AI Agent 的 7 个关键概念里，哪一个最容易出问题？
回答 1：规划和工具调用这两个最容易出问题。AI Agent 的规划质量高度取决于任务分解策略，同一个模型换个拆法，执行质量能差 40% 以上；工具调用则卡在 "工具定义写不清" 和 "工具给太多" 两件事上，同时可用工具超过 20 个，模型的选择准确率就开始明显下降。目标和反思属于 "设计时容易忽略、出事后才发现" 的两类。
问题 2：AI Agent 的记忆和普通大模型的内存有什么区别？
回答 2：大模型本身是无状态的，每轮调用都从零开始；AI Agent 的记忆是外挂拼装的四套机制：工作记忆放在上下文窗口（8K–200K token），情景记忆放数据库存历史对话和任务结果，语义记忆放向量库存文档知识，程序记忆是提示模板和工具 schema。关键差别是 AI Agent 要主动决定 "这一步该调哪套记忆"，而不是把所有东西都塞进上下文。
问题 3：为什么 AI Agent 一定要有 "反思"，它和重试有什么区别？
回答 3：反思是 AI Agent 判断自己结果对不对、偏差在哪、下一步怎么改；重试只是失败后用同样方式再来一遍。不分析原因的重试，第二次大概率还是错。数据显示加入反思机制后，复杂多步任务成功率平均提升 25%–35%，代价是总耗时增加 15%–20%，所以它不是免费的，要看场景值不值。
问题 4：做 AI Agent 一定要用多智能体吗？
回答 4：不一定，而且多数情况下不该。多智能体的唯一正当理由是单个上下文窗口装不下任务所需信息。Anthropic 的工程建议是 "能用一个就别上两个"，因为每多一个 Agent 就多一份协调开销和误差放大。一个工具给足、范围清晰、规划做好的单 Agent，在标准流程上往往比多智能体更稳。
问题 5：判断一个 AI Agent 靠不靠谱，看哪几个指标？
回答 5：看四个，都不看 "答得像不像"。一是任务完成率，要按简单 / 中等 / 困难分层统计；二是步骤效率，实际调用次数与最短路径的比值；三是越界率，有多少次跑出了预设权限范围；四是失败类型分布，是规划错、工具错、观测误读还是死循环。这四项决定了它能不能进生产环境。
【参考资料】
[2026-08-29]（AI Agent Engineering Glossary：Tool Call、Tool Result、Computer Use、Multi-Agent、Pipeline 等术语定义，逐条标注 Anthropic、OpenAI、LangChain 原始出处）hidekazu-konishi.com
[2026-07-20]（AI Agents 101: The 7 Concepts You Need to Know）88 Labs AI
[2026-06-11]（一文讲透 AI 产品经理必懂的 10 个 Agent 相关的核心概念）火龙果 UML / 产品经理老王霸
[2026-05-01]（Key Components of AI Agents：基础模型、规划、记忆、工具、学习与反思五组件）SellerShorts
[2026-04-27]（How Autonomous AI Agents Work: Architecture, Memory, Planning & Tool Use 2026）Atlia Learning
[2026-04-25]（AI Agents：从 ReAct、Plan-and-Execute 到记忆架构与故障模式的完整条目）BloomWiki
[2026-04-01]（7 Core Components of an AI Agent Architecture Explained）Glean
[2025-06-13]（Building Effective AI Agents：架构模式与实现框架 / How we built our multi-agent research system）Anthropic 工程博客
【免责声明】
本文依据 Glean、88 Labs AI、Anthropic、Atlia Learning、BloomWiki、SellerShorts 等公开技术文档与工程博客，以及中文技术社区的产品实践文章整理。文中 "7 个关键概念" 是为便于理解所做的归纳，业界并无统一切法 —— 不同机构分别划分为 5 组件、7 组件、7 概念或 10 概念，本文在第四节给出了对照。文中引用的性能提升比例（如反思机制提升 25%–35%、Chain-of-Thought 提升 20%–40%、Reflexion 提升 15%–22%）均来自各原始来源的实验结论，测试任务、模型与基线不同，结果不可直接横向比较，也不代表在具体业务场景中一定能复现。本文不构成技术选型建议或采购依据。
顺带一句：这个题材最容易踩的坑是 "七个概念各写一段，互不搭界"，读起来像词典。我这版把七层串成了一条完整任务链（第三节那张表），你能直接拿它对照自己手上的 Agent 是哪一环掉链子。以后要写这类概念科普，给我一句话说清 "读者是谁、要拿它干什么"，我就能把抽象概念落到可验证的动作上。