Agent 是什么

延伸阅读：

OpenAI：Building agents —— 从“会回答”到“会采取行动”的官方入门。(OpenAI 开发者)

Anthropic：Building Effective AI Agents —— 很适合建立“什么时候该用 Agent、什么时候不该”的工程直觉。(Anthropic)

Model Context Protocol（MCP）简介 —— 理解 Agent 如何连接外部工具、数据和工作流。(模型上下文协议)

flowchart LR
  A[用户目标] --> B[感知当前状态]
  B --> C[决策下一步]
  C --> D[调用工具 / 执行动作]
  D --> E[观察结果]
  E --> F{任务完成?}
  F -->|否| B
  F -->|是| G[交付结果]

很多人第一次接触 Agent，往往会把它理解成“更强的 Chatbot”：更会说话、更会写、更懂上下文。这个理解不算错，但还不够。

Agent 和普通聊天机器人的真正差别，不在于它“更聪明”，而在于它开始从“生成回答”走向“推进任务”。它不只是对一句输入做一次响应，而是会围绕一个目标持续感知、判断、调用工具、修正路径，直到任务完成、失败，或者被人类中止。OpenAI 在其面向开发者的 Agent 指南里就把边界说得很直接：如果一个系统不仅能理解输入，还会连接外部系统并基于输入采取行动，这就进入了 Agent 的范畴。(OpenAI 开发者)

所以，本文要讲清楚的不是“Agent 的营销定义”，而是一个更工程化的问题：

什么样的系统，才配叫 Agent？它和 Chatbot、Copilot 的边界在哪？它为什么重要，又为什么不能神化？

Agent 的定义

先给一个适合工程语境的定义：

Agent 是一种面向目标的 AI 系统：它能够感知当前状态，基于上下文做出决策，必要时将目标拆成多步，并通过调用工具或与外部环境交互来推进任务。

这个定义里，关键不在“AI”，而在“面向目标”和“推进任务”。

因为如果一个系统只是：

接收输入；
生成一段文本；
然后等待下一轮提问；

那它更接近一个会话系统，哪怕这段文本写得再像人在思考。而如果一个系统会：

读取环境信息；
决定下一步该查什么、做什么；
调用搜索、数据库、代码执行、文件系统、浏览器或业务 API；
根据返回结果调整后续动作；
最终产出一个结果、修改一个状态或完成一个流程；

那它才更接近 Agent。

Anthropic 在“Building Effective AI Agents”里其实也强调了类似的判断标准：很多成功的 Agent 系统，并不神秘，核心在于是否围绕任务形成了一个可持续运行的闭环，而不是单次文本生成。(Anthropic)

学术语境里的 Agent，与今天常说的 Agent，不完全是一回事

“Agent”这个词并不是从大模型时代才出现的。

在更传统的 AI 研究中，Agent 通常指的是： 在环境中观察、行动，并试图最大化某种目标或奖励的主体。

这个定义来自强化学习、多智能体系统、自动规划等更早的研究传统。而 2024–2026 年行业里高频提到的 Agent，更常见的是另一层意思：

基于 LLM 的任务执行系统。

它未必有严格定义的奖励函数，也未必像强化学习环境那样形式化；它更像一个以大模型为“决策核心”，通过工具调用和状态循环完成任务的应用系统。

所以这两种 Agent 有连续性，但不应简单混同。本文聚焦的是后者，也就是当下产品和工程实践里最常说的 LLM-based Agent / Agentic System。

Agent 的最小闭环：感知、决策、行动、反馈

如果只保留最核心的骨架，Agent 至少包含四个环节：

环节	说明
感知（Perceive）	获取用户输入、工具返回、环境状态、历史上下文
决策（Reason / Decide）	判断当前处境，选择下一步行动
行动（Act）	调用工具、操作系统、发请求、写文件、执行流程
反馈（Observe / Update）	读取动作结果，更新状态，决定是否继续

很多文章会把“规划”单独列出来，这当然有帮助；但从系统视角看，规划本身也是决策的一种形式：它只是比“下一步做什么”更进一步，变成“接下来几步可能怎么做”。

真正让 Agent 和普通对话系统分开的，是这个循环会持续运行：

目标 -> 感知当前状态 -> 决定下一步 -> 执行动作 -> 读取结果 -> 再决策

只要这个循环存在，系统就不再只是“答一句”，而是在“推进一件事”。

Agent 和 Chatbot，区别不只是“会不会调工具”

一个常见说法是： “Chatbot 不会用工具，Agent 会用工具。”

这句话有一定道理，但还不够准确。因为现实里很多 Chatbot 也可以接搜索、知识库、计算器、数据库查询。 真正的区别不在于是否接工具，而在于工具在系统里扮演什么角色。

Chatbot 的中心是“回复”

Chatbot 的默认工作方式是：

用户问一句；
系统回复一句；
如果用了工具，工具只是为了让这句回复更像样、更完整、更实时。

它的主语仍然是“回复”。

Agent 的中心是“完成”

Agent 的默认工作方式是：

用户给出一个目标；
系统判断需要哪些步骤；
它自己决定什么时候查资料、什么时候调用接口、什么时候修改状态、什么时候停下来；
输出的不只是话，而是一个完成度更高的结果。

它的主语是“任务完成”。

所以，两者可以做一个更准确的对比：

维度	Chatbot	Agent
核心单位	一次回答	一个任务
默认交互	你问我答	你交代目标，我推进过程
工具角色	辅助回答	构成执行能力
状态管理	对话上下文为主	任务状态、步骤状态、工具状态都重要
失败方式	回答不够好	步骤走偏、工具误用、任务中断
产出形态	文本回复	文本、代码、操作结果、工作流状态更新

先看定义：Chatbot 的中心是“说”，Agent 的中心是“做”。

这里的“做”，不一定总是现实世界中的高风险动作，也可以是数字空间中的执行：查资料、读代码、整理表格、生成报告、更新工单、调用 API、修改配置、提交草稿等。

从 Chatbot 到 Agent，是连续谱系，不是二元分类

现实产品很少严格落在某一个纯粹类别里。更准确的理解方式，是把它们放在一个连续谱系上：

层级	典型形态	核心特征
Chatbot	通用问答助手	以回复为主，工具少或工具不构成执行主线
Copilot	写作助手、编程助手、办公助手	AI 辅助明显，但通常由人类主导步骤
Agent	研究 Agent、客服 Agent、编程 Agent	系统可自主推进多步任务，人类做监督或兜底
Autonomous Agent	更长期运行的自治系统	更强持续运行能力、更少人工介入、更高治理要求

这条谱系里，Copilot 是很容易被忽视但非常重要的一层。

因为大量真实产品并不追求“完全自主”，而是在追求：

让 AI 提高任务推进效率；
但仍然把关键决策权放在人类手里。

这类系统从产品体验上可能已经很“Agentic”，但从治理上更接近“带执行能力的 Copilot”。这其实往往是一个更稳妥的落点。

不要把 Agent 神化：它不是“数字员工”，首先是“有执行闭环的系统”

“数字员工”“自主智能体”“会自己工作的 AI”这些说法很吸引人，但容易制造误解：好像 Agent 已经天然具备稳定执行复杂任务的能力，只要给它一个目标，它就会像成熟员工一样自己完成。

现实不是这样。

Agent 的核心能力，很大一部分不是模型天生带来的，而是系统设计出来的：

给它哪些工具；
工具描述是否清楚；
允许它做什么、不允许它做什么；
任务状态怎么表示；
失败了如何回滚；
什么时候必须向人类确认；
结果如何校验；
长上下文怎么管理；
记忆如何读写；
成本如何约束。

从这个意义上说，Agent 更接近一种系统形态，而不是单一模型能力。

LLM 很重要，但它更像这个系统里的“推理与生成核心”，而不是整个系统本身。

Agent 的四项核心能力

如果要把 Agent 的能力拆开来看，通常可以分成四类：

能力	英文	作用
推理	Reasoning	理解任务、分析约束、判断下一步
规划	Planning	把目标拆解成步骤，安排执行顺序
工具使用	Tool Use	调用外部能力，真正产生行动
记忆	Memory	维持任务连续性，跨步骤或跨会话保留关键信息

这四项里，最容易被高估的是“推理”，最容易被低估的是“工具”和“记忆”。

1. 推理：决定“当前该怎么想”

推理不是玄学，它在工程里通常体现为这些问题：

这是不是一个需要多步完成的任务？
当前信息够不够？
下一步该检索、计算、提问、还是直接执行？
结果是否可信？
现在应该继续，还是停下来请求确认？

LLM 的确为 Agent 带来了前所未有的推理灵活性。但要注意，Agent 场景里的推理不是考试式推理，而是任务式推理。它更关心“下一步怎么做”，而不只是“逻辑上怎么解释”。

2. 规划：决定“先做什么，后做什么”

规划能力让 Agent 不必每一步都完全临时决定，而是可以先形成一个粗方案。

例如用户说：

“帮我对比三家云服务商的向量数据库方案，并给出适合中型团队的推荐。”

一个更像 Agent 的系统通常不会立刻写结论，而会先形成隐式或显式计划：

确认比较维度；
检索三家方案资料；
对比成本、扩展性、运维复杂度；
汇总；
给出推荐和适用边界。

但也要克制一点看待规划： 不是所有 Agent 都需要重规划器。

很多任务并不需要复杂任务分解，过度规划反而增加成本和路径漂移。Anthropic 也明确强调，很多成功的 Agent 系统依靠的是简单、可组合的模式，而不是过度复杂的编排。(Anthropic)

3. 工具使用：决定“它到底能不能做成事”

这是 Agent 最接近“执行者”的地方。

一个没有工具的系统，再会思考，也只能停留在文本层面。它可以建议你做什么，但不能真正去做。

而一旦有了工具，Agent 的能力边界就被极大扩展：

搜索网页和知识库；
读取文件；
运行代码；
查询数据库；
操作浏览器；
调用企业 API；
修改工单、订单、配置、日历、草稿；
连接更多外部系统。

MCP 的定位就很能说明这一点：它试图把“模型如何连接数据源、工具和工作流”标准化，让 Agent 接入外部能力不必每次都从头定制。(模型上下文协议)

但这里也有一个很重要的现实： 工具不是越多越好。 Anthropic 关于工具设计的工程文章也反复强调，Agent 的效果高度依赖工具定义是否清晰、边界是否稳定、返回值是否结构化。工具越多、越模糊，系统越容易走偏。(Anthropic)

4. 记忆：决定“任务能不能连贯地做下去”

记忆可以分成几种不同层次：

类型	作用
短期上下文	当前对话和当前任务窗口内的信息
工作记忆	中间结果、计划、已完成步骤、待处理事项
长期记忆	用户偏好、历史决策、长期项目背景
外部记忆	存储在数据库、向量库、文件或状态机中的可持久状态

没有记忆，Agent 很难做长任务。它会不断丢失中间状态，重复做事，或者在多步流程中忘记自己做到哪一步。

但“记忆”也不是简单把所有历史都塞进上下文。 2025–2026 年一个越来越被强调的方向，是 context engineering：不是无限扩大上下文，而是更有选择地组织当前步骤真正需要的状态和信息。Anthropic 甚至明确把它看作 prompt engineering 之后更关键的能力。(Anthropic)

为什么 Agent 在 2026 年重要

Agent 之所以在 2026 年继续成为核心话题，并不是因为“大家喜欢这个词”，而是因为几个条件正在同时成熟：

大模型更擅长处理多步任务了 不只是生成答案，而是能在一定程度上维持中间状态、理解工具返回结果并继续行动。(OpenAI 开发者)
工具调用越来越标准化 OpenAI、Anthropic 等厂商都在围绕工具使用、Agent 开发、评测与追踪提供更系统化的能力；MCP 也在推进跨系统工具连接的标准化。(OpenAI)
很多真实工作本来就是“多步任务” 写代码、查资料、处理工单、生成分析、整理流程、执行办公操作，这些都不是一句话能完成的。
用户期望发生了变化 以前用户对 AI 的期待是“给我答案”；现在越来越多场景里，用户期待的是“帮我把事情往前推进”。

也正因为这样，Agent 的价值不只是“更酷”，而是它切中了一个真实的产品变化：

AI 的价值单位，正在从单次回答，转向任务完成率。

真实世界里，Agent 常见在哪些场景

Agent 不是只存在于“未来感演示”里。真正合适它的，通常是那些同时满足下面条件的场景：

任务需要多步；
中间过程要调用外部系统；
输出不只是文本，而是结果或状态变化；
允许一定程度的自动推进；
有办法为高风险步骤加护栏。

1. 编程 Agent

这是当前最典型、也最容易让人直观理解的一类。

你给它的不是“写一段排序代码”，而是：

给这个接口加缓存层；
修掉这个测试；
把旧 SDK 升级到新版本；
在这个仓库里定位问题并提交修复建议。

它可能会：

搜索代码库；
读取相关文件；
修改多个位置；
运行测试；
根据报错继续修正；
最后给出变更说明。

这里它做的已经不是“答一题”，而是在一个有限软件环境里循环推进任务。

2. 研究 / 信息整合 Agent

这类 Agent 的关键不是“查到一篇资料”，而是：

明确问题范围；
多轮检索；
对比来源；
汇总差异；
按目标格式输出。

例如：

对比三家数据库产品；
总结某个主题最近的研究方向；
把多份政策文档整理成决策备忘录；
为一个项目做初步调研框架。

它本质上是在把“搜索 + 阅读 + 组织 + 写作”串成一个任务链。

3. 客服 / 业务流程 Agent

这类 Agent 的价值，通常不在“回答更亲切”，而在“真的把业务流程接起来”。

比如用户说：

“我想把默认收货地址改成上海。”

“我需要查询上个月那张发票。”

“帮我取消自动续费，并确认什么时候生效。”

一个普通 Chatbot 也许会告诉你“请去官网操作”；而 Agent 可以在权限允许的前提下：

查询账户状态；
修改地址；
拉取发票；
创建工单；
取消订阅；
返回最终结果。

这里的本质变化是： AI 不再只是业务流程的说明书，而开始成为业务流程的执行入口。

4. 数据分析 / 办公 Agent

这一类 Agent 最容易和“会写 Python 的 Chatbot”混淆，但两者差别仍然存在。

Agent 更像是在帮你完成一个完整分析流程：

理解问题；
连接数据源；
清洗或筛选数据；
生成查询或代码；
产出图表和结论；
必要时继续追问数据异常；
调整结果输出形式。

同样，重点不在于它“能写分析代码”，而在于它能不能围绕任务形成闭环。

一个判断标准：它是在“生成建议”，还是在“消耗世界状态”？

判断一个系统是否更接近 Agent，有一个很实用的视角：

它是否真的在改变某种外部状态？

这里的“状态”可以很广义：

文件被改了；
工单被创建了；
数据被查询并汇总了；
订单被更新了；
日历被写入了；
浏览器操作被执行了；
报告被产出了；
代码被提交了。

如果一个系统只是在告诉你“接下来你应该怎么做”，那它更像顾问。如果一个系统开始自己去做，哪怕范围有限，它就更接近 Agent。

当然，这也意味着风险随之上升。因为一旦系统可以“消耗世界状态”，就不再只是内容正确性问题，而变成了执行正确性、权限边界和责任归因问题。

Agent 的局限与风险：越像执行者，越不能按聊天产品的心态去设计

Agent 让人兴奋的地方，正是它能做事；但它最危险的地方，也正是它能做事。

1. 可靠性问题：多步任务会累积误差

在普通问答里，一次回答错了，就是一次回答错了。在 Agent 里，一步错可能会传染到后面所有步骤。

例如：

第一步检索错资料；
第二步基于错误资料做计划；
第三步调用了不该调用的接口；
第四步又把错误结果写回系统。

这类错误比单次幻觉更麻烦，因为它带有流程放大效应。

所以，Agent 系统必须比 Chatbot 更重视：

中间结果校验；
步骤级回滚；
高风险动作确认；
失败后停止而不是硬着头皮继续。

2. 成本问题：Agent 天生更贵

Agent 通常会消耗更多资源，因为它往往包含：

多轮模型调用；
多次工具调用；
任务状态维护；
可能的检索、记忆读写、rerank、执行反馈；
失败重试或反思步骤。

所以，Agent 的问题不是“能不能做”，而是“值不值得这样做”。

一个只需一次检索和一次回答就能完成的任务，硬上 Agent，通常是在用更高成本换更复杂路径。这也是为什么 Anthropic 和 OpenAI 的工程资料都强调：先从简单工作流开始，不要默认“越 agentic 越好”。(Anthropic)

3. 安全问题：工具能力越强，风险越高

只会回答的模型，主要风险是说错话。能调工具的 Agent，风险会扩展为：

越权访问；
错误操作；
意外删除或修改；
高风险业务误触发；
被 Prompt 注入操控调用不当工具；
通过连接器接触到不该看的系统。

因此，Agent 的安全重点不只是内容审查，而是：

最小权限原则；
工具白名单；
高风险操作二次确认；
操作审计；
结果可追溯；
执行动作前后的状态校验。

4. 可预测性问题：路径不透明

Agent 的一个典型挑战是：你知道它最终做了什么，但不一定知道它为什么这么做。

而一旦它能自主规划、多步调用工具，这种不透明性会迅速增加。所以工程上需要的不是“让它显得更像人在思考”，而是让系统具备可检查性：

这次任务走了几步？
调了哪些工具？
每一步为什么被触发？
失败发生在哪一层？
最终结果依据是什么？

这也是为什么 2025–2026 年主流 Agent 平台越来越强调 tracing、eval 和 workflow observability。(OpenAI)

何时该用 Agent，何时不该

“是不是所有 AI 产品最终都要变成 Agent？” 这个问题的答案大概率是否定的。

一个简单判断是：先看任务本身是否天然需要多步执行。

更适合 Agent 的情况

场景	原因
需要多步才能完成	单次回答不够，需要连续推进
需要调用外部系统	任务价值来自实际执行，不只是解释
有明确交付物	代码、报告、工单、配置、状态更新
人希望少管过程	用户希望“交代目标后等结果”
任务可被约束	有边界、有权限、有校验机制

不太适合 Agent 的情况

场景	原因
一次性知识问答	Chatbot 足够，Agent 只会增加复杂度
高风险且不可回滚动作	需要更强审批流，不宜直接交给 Agent
目标高度模糊	Agent 会在模糊目标上放大路径漂移
缺少工具和状态接口	没有执行闭环，Agent 只能空转
用户希望全程掌控	更适合 Copilot，而不是强自主系统

先看定义：如果问题的核心是“给我一个答案”，Chatbot 往往够用。如果问题的核心是“把这件事推进到完成”，才值得考虑 Agent。

实践中的常见误区

误区一：Agent 就是“ChatGPT 加几个工具”

工具当然重要，但“接上工具”只是最低门槛，不是完整答案。

真正决定 Agent 好不好用的，通常还包括：

任务状态怎么表示；
是否会在失败时停下来；
会不会重复调用无效工具；
会不会无依据地继续编下去；
怎么控制上下文；
怎么做权限和审计；
怎么判断完成与未完成。

没有这些，系统充其量只是“会调工具的聊天框”。

误区二：越自主越先进

自主度不是越高越好，而是要与场景风险匹配。

在写代码草稿、做资料整理、生成报告提纲这类场景里，自主度高一点通常问题不大；但在删除数据、变更财务状态、修改生产配置、发送正式外部邮件这类场景里，自主度越高，治理压力越大。

成熟系统更在意的是： 什么动作可以自动做，什么动作必须请求确认。

误区三：Agent 会很快替代大多数人类工作

这个判断往往忽视了三个现实：

很多工作不是“步骤问题”，而是“责任问题”；
很多任务难点不在执行，而在目标定义、价值判断和边界取舍；
即使执行能力提升，组织也未必愿意把高风险决策直接交给系统。

所以更现实的演进路线不是“AI 完全替代人工”，而是：

从“人做、AI 辅助”逐步走向“AI 执行更多标准化步骤，人类负责目标、边界、审批和例外处理”。

误区四：所有复杂任务都该用多 Agent

多 Agent 很吸引人，因为它看起来更像组织协作：规划者、执行者、审查者、研究员各司其职。但在真实系统里，多 Agent 也意味着：

更多调用；
更高成本；
更多状态同步问题；
更难调试；
更复杂的失败路径。

很多时候，一个设计良好的单 Agent + 明确工具体系 + 简单检查点，就已经足够。多 Agent 更适合在后续文章里单独讨论，而不是一开始就默认上。

一个更克制也更准确的结论：Agent 不是一个“更会聊天的模型”，而是一种“更会推进任务的系统”

这是本文最想建立的核心判断。

Agent 的本质，不是让模型说得更像人；而是让 AI 系统开始具备以下特征：

有目标；
有状态；
有步骤；
有动作；
有反馈；
有边界；
有治理。

一旦你用这个视角看问题，就会发现很多讨论会自然变清晰：

为什么工具这么关键？因为没有动作就没有执行闭环。
为什么记忆重要？因为任务不是一句话做完的。
为什么安全和审计比聊天产品更重要？因为它真的可能改变外部状态。
为什么 Agent 不该被神化？因为它首先是工程系统，不是魔法人格。

本系列接下来会讲什么

本文解决的是概念问题： Agent 到底是什么，不是什么，值不值得用在某类任务里。

下一篇会继续往下拆：如果要把 Agent 真正实现成一个系统，它通常由哪些部件组成？Planner、Executor、Memory、Tools 之间是怎样协作的？什么是最小可用 Agent 架构，什么又是典型的过度设计？

后续几篇会继续展开：

ReAct：为什么“思考—行动—观察”会成为经典模式
Plan & Execute：为什么有些任务需要先规划，再执行
Reflection：为什么 Agent 需要自检，但又不能无止境反思
Multi-Agent：什么时候多 Agent 真的有价值，什么时候只是复杂度膨胀

核心概念速查

概念	一句话
Agent	以目标为中心，能感知、决策、行动并通过反馈持续推进任务的 AI 系统
Chatbot	以单次回复为中心的对话系统，即使接工具也未必具备任务闭环
Copilot	人类主导步骤、AI 提供辅助和局部执行的系统形态
Tool Use	Agent 接入外部世界的能力来源，决定它能不能真正“做事”
Memory	让任务跨步骤连续运行的状态能力，不等于把所有历史都塞进上下文
Agentic System	强调系统具备任务推进和执行闭环，而不只是生成更长的回答

小结

Agent 不是 Chatbot 的“高级皮肤”，也不是“会自己思考的数字员工”这种模糊想象。更准确地说，它是一种围绕任务目标运行的 AI 系统：能够读取状态、做出判断、调用工具、接收反馈，并在多步循环中推进任务。

它和 Chatbot 的核心区别，不是会不会多说几句，也不只是会不会查资料，而是是否从“生成回答”走向“完成任务”。这使它在编程、研究、客服、办公自动化等场景里很有价值，也使它天然面对更高的可靠性、安全、成本和治理要求。

理解 Agent，第一步不是追逐“自主性”的想象力，而是先看清它的工程本质： 它之所以重要，不是因为它更像人，而是因为它开始真正连接世界并对世界产生作用。