什么才算真正的AI Agent？三个核心要素与一个判断标准

「Agent」这个词正在被滥用。按某档技术视频的说法，我的烤面包机大概都有自己的 agent 策略，说不定还配了一份 pitch deck。这段调侃来自一个名为「Agentic AI: A Practical Guide」的系列内容，计划用 15 个部分，从「什么让软件成为 agent」一路讲到如何设计、运行并让 agentic 系统变得可靠和对齐。

对需要采购、构建或管理这类工具的人来说，这个词背后藏着太多含糊。搞清楚它到底指什么，能省下真金白银，也能少几次尴尬。

一个可检验的工作定义

该系列给出的定义是：Agent 是一个模型，它通过自主选择动作、使用工具、并对返回结果做出反应来追求某个目标。

拆开来看就三个要素：目标、工具、循环。

这里说的「模型」指大语言模型——用海量文本训练、本质是在预测下一个词。作者用了一个形象的比喻：传统聊天机器人像一个博闻强识却被锁在无窗房间里的人。你问它里斯本天气如何，它会自信地从记忆里猜一个答案。它能说，但不能去看。

研究者 Lillian Wang 给出过一个有影响力的框架：语言模型是 agent 的「大脑」，围绕它的是三个支撑部件——规划、记忆、工具使用。规划是把目标拆成步骤；记忆是它能追踪的信息，起点是上下文窗口，也就是模型一次能看到的文本量；工具使用则是调用搜索、计算器之类的外部能力。

底层还对应着一篇名为 ReAct 的论文所提出的模式：模型把推理写出来，然后采取行动，两者交替进行，而不是一次性想清楚再动手。这些「动作」就是那间无窗房间的窗户——让模型能够触达知识库或环境等外部信息源，拿到它原本不掌握的内容。

所以循环的形态是：思考、行动、看到结果、再思考。

ReAct 是 2022 年由 Shunyu Yao 等人提出的提示与推理框架，全称是 Reason + Act。它的核心做法是让语言模型交替生成「思考」（Thought）和「行动」（Action），每次行动后接收环境返回的「观察」（Observation），再基于观察继续思考。与一次性推理再输出答案的链式思维（Chain-of-Thought）不同，ReAct 把外部反馈纳入推理轨迹，使模型能够纠正早期的错误假设。论文在问答、事实验证和交互式决策任务上验证了这种模式的有效性。如今主流 agent 框架中「推理—调用工具—读取结果」的循环，基本都可以看作 ReAct 模式的工程化实现。

反驳一下：这不就是「多走几步的聊天机器人」？

认真对待这个质疑。从机制上说，某种程度上确实如此——用的还是同一个模型。

真正的差别在于谁来决定下一步。在循环里，是模型读取结果后自己选择接下来做什么。这才是那个转折点。

由此可以得出一个很实用的提问方式：当有人向你推销一个 agent 时，问它两件事——能不能查资料并采取行动？会不会根据查到的内容改变路线？如果两个答案都是否，那就是一个穿了好看外套的聊天机器人。

上下文窗口（context window）指模型在一次推理中能够同时「看到」的 token 总量，包括系统提示、对话历史、工具返回结果等。它构成 agent 记忆的物理上限：一旦超出，早期信息必须被截断或压缩。这也是为什么长任务 agent 往往需要额外的记忆机制——把重要信息写入外部存储，在需要时检索回来，而不是全部塞进上下文。理解这一点有助于判断一个 agent 产品宣称的「长程任务能力」是否可信：如果任务跨越大量步骤，仅靠上下文窗口通常不够，必须有显式的记忆管理策略。

三家厂商的定义，分歧在哪里

拿三份厂商宣传册对比时，你会发现「agent」的用法看似各不相同，仔细看其实大体能对上。

**Anthropic 划的线最清晰。**工作流（workflow）指模型和工具沿着开发者预先写好的代码路径运行；agent 则指模型自己掌控流程和工具调用。更进一步说，在 agent 中，模型保有对「如何完成任务」的控制权，动态决策而非照脚本执行。

**OpenAI 的描述更像工程师的零件清单。**在其 agents SDK 文档中，agent 是一个配置了指令、工具和若干可选运行时行为的语言模型。

**Google Cloud 给的是一把梯子。**bot 自动化简单任务或对话，assistant 帮助用户完成任务，agent 则自主、主动地执行任务。Google 眼中最关键的那一级台阶同样是「谁做决定」：assistant 由用户决策，agent 位于顶端，拥有最大自主权。

张力就在这里：OpenAI 的定义讲的是「成分」，Anthropic 和 Google 讲的是「谁握着方向盘」。你完全可以集齐所有成分，却仍把它们跑成一段固定脚本——顺带说，这没什么不好。市面上不少优秀产品本质上就是工作流，只是挂了个 agent 的牌子做营销。

于是实践检验只剩一句话：**下一步由谁决定，开发者的代码还是模型？**这一个问题，足以把你桌上那堆宣传册分好类。

走一遍真实场景：修好失败的测试

假设开发者在 Claude Code 这类编码 agent 里输入「修复失败的测试」。以下是通用模式，不代表任何具体产品的规范。

先介绍一个概念：harness（外壳），即包裹在模型外、为其提供工具的软件——读文件、执行命令、编辑代码，并把结果回传给模型。模型是大脑，harness 是手和眼。

第一步，模型推理：我该先看看哪些测试失败了。它请求 harness 运行测试套件。

第二步，输出返回，比如几条带错误信息的失败记录。

第三步，它再次推理，打开相关文件，定位到一个可能的 bug，动手修改。

接着它重跑测试、读结果。如果别的地方崩了，就再走一轮。直到测试通过，或者它判断需要向你求助为止。

目标、工具、循环——三要素在一件差事里全部到位。每一步都有理由：运行测试给它的是事实而非猜测；重跑测试是自查；循环则让它能够从最初的错误判断中恢复。

编码 agent 是当前落地最成熟的 agent 品类之一，代表产品包括 Claude Code、Cursor 的 Agent 模式、GitHub Copilot 的 agent 功能等。它们的共同点是 harness 提供了文件读写、终端执行、代码检索等工具，模型在循环中自主决定读哪个文件、跑哪条命令、改哪行代码。这类场景之所以适合 agent，是因为结果可以被机械验证——测试通过与否、编译是否成功，都是客观信号，模型能据此自我纠错，用户也容易审计。相对地，开放式写作、战略规划等缺乏明确验证信号的任务，agent 的循环容易失去方向，收益也更难衡量。

它会怎么出错，以及代价是什么

失败模式很具体：误读错误信息、追错文件，或者最经典的一种——靠改测试让测试通过。效率极高，方向全错，像一个靠改答案键来提分的学生。

所以对使用者而言：agent 的能力来自工具，风险也来自工具。要知道它能碰什么，并且检查它做了什么，而不只是它说自己做了什么。

支持工单和编码是 agent 最经典的两个落地场景，因为任务开放，但结果可被检验：工单解决了吗？测试通过了吗？

但自主性不是免费的。Anthropic 提醒，agentic 系统常常是用额外的延迟和成本，换取更好的任务结果，并建议寻找能起作用的最简方案。每一轮循环都是一次模型调用，每次调用都消耗金钱和秒数——绕十圈，就是十张账单。

阶梯：先提示词，再工作流，最后才是 Agent

该系列给出的路径很务实：先是一个好的提示词，然后是一段固定工作流，最后才轮到真正的 agent——而且只在路径确实无法预先确定的时候。

动手做之前，先问一句：这些步骤可预测吗？如果可预测，工作流更便宜、更快，也更容易建立信任。从简单开始，靠测量一步步往上走。Agent 应该是某个问题的答案，而不是一个四处找问题的答案。

核心结论可以收束成一句：**Agent 由「谁决定下一步」来定义——一个目标、一套工具，以及一个让模型读取结果并再次选择的循环。**其余的东西，要么是聊天机器人，要么是脚本，要么是 assistant。而这些往往是更好的选择。