Agent

这是理解 Agent 最重要的一件事。

一个最纯粹的大语言模型，本质上只做一件事情：

根据当前输入，预测接下来最可能出现的 token。

你问它：

帮我查一下明天从伦敦到巴黎最便宜的机票。

模型本身其实没有能力打开浏览器，也不知道实时机票价格，更没有能力替你购买。

它最多只能生成一句：

我建议你去 Google Flights 或 Skyscanner 查询。

因为它唯一真正能做的事情，是生成文字。

所以如果我们想让 AI 从“告诉你怎么做”，变成“真的去做”，就必须给模型增加一些东西。

比如：

• 浏览器
• 搜索引擎
• Python
• 数据库
• Shell
• 文件系统
• API
• 邮件
• 日历

这些东西在 Agent 系统里通常被统称为：

Tools。

模型负责决定：

我现在应该使用什么工具？

工具负责真的执行：

搜索、点击、计算、修改、发送、运行。

于是，一个非常粗略的 Agent 结构就出现了：

LLM + Tools = Agent 的雏形。

假设我给一个模型接入了天气 API。

用户问：

今天海南天气怎么样？

模型调用一次天气 API，然后告诉你结果。

这当然已经比纯 LLM 更强，但严格来说，它依然更像是一次简单的 Tool Calling。

真正让 Agent 出现的，是另一件事情：

循环（loop）

Agent 不只是：

用户 → 模型 → 工具 → 答案

而是：

用户 → 模型思考 → 调用工具 → 获得结果 → 再思考 → 再调用工具 → 再观察结果……

直到任务完成。

这就是 Agent 最核心的运行方式。

可以把它理解成一个不断循环的过程：

Think → Act → Observe → Think

思考。

行动。

观察。

再思考。

例如你告诉一个 Coding Agent：

帮我修复登录页面的 Bug。

它可能会先：

读取项目目录。

然后判断登录页面在哪个文件。

接着打开代码。

发现调用接口的参数可能有问题。

于是修改代码。

运行测试。

测试失败。

读取错误日志。

重新判断原因。

再次修改。

重新运行。

直到测试通过。

这里最重要的并不是“模型写出了代码”。

而是模型能够根据上一步产生的新信息，重新决定下一步做什么。

这时候，它才真正开始表现得像一个 Agent。

Agent 是一个由模型驱动、能够观察环境、选择行动，并根据行动结果持续调整下一步决策的系统。

里面有三个关键词。

第一个是 观察。

Agent 必须能够获得环境信息。

代码文件、网页内容、数据库结果、API 返回值，都属于环境。

第二个是 行动。

它必须能够对环境执行某些操作。

修改文件、发送请求、运行程序、搜索网页。

第三个是 反馈。

行动执行之后，Agent 必须知道发生了什么。

成功还是失败？

返回了什么？

有没有报错？

结果是否满足目标？

然后它再基于这些反馈继续决策。

所以 Agent 从计算机逻辑上看，并没有想象中那么神秘。

它很像这样：

while 任务还没有完成：

    观察当前环境

    判断下一步应该做什么

    执行动作

    获取执行结果

    根据结果重新判断

Agent 真正复杂的地方，在于：

“下一步应该做什么”不再完全由程序员提前写死，而开始交给模型决定。

传统软件同样可以自动执行一堆任务。

比如：

用户提交订单之后：

检查库存。

扣库存。

生成订单。

调用支付接口。

发送短信。

这些流程几十年前就能实现。

但这种东西一般叫 Workflow，也就是工作流。

它最大的特点是：

路径是提前设计好的。

程序员事先规定：

A 完成以后执行 B。

B 成功以后执行 C。

C 失败以后执行 D。

本质上仍然是一棵写好的流程树。

Agent 不一样。

Agent 的流程可以在运行过程中动态生成。

你只告诉它：

帮我完成这个任务。

至于到底需要三步、五步还是二十步，它可以自己决定。

所以两者之间一个非常重要的区别就是：

Workflow 是人提前决定流程，Agent 是模型运行时决定流程。

当然，现实中的 Agent 通常不会完全自由。

因为完全自由意味着不可控。

因此很多成熟 Agent 实际上都是：

Workflow + Agent。

大的流程由人设计。

局部决策交给模型。

这可能也是目前最现实的工程形态。

因为以前的软件根本没有一个足够强的“通用决策器”。

传统程序最擅长的是：

如果 A，则执行 B。

但现实世界里的大量任务并不是标准化的。

例如：

帮我调研五家 Model Router 产品，然后比较它们的技术路线。

这里根本不存在固定流程。

不同产品的网站不同。

资料位置不同。

信息完整度不同。

有些要读文档。

有些要看 GitHub。

有些可能还需要看论文。

传统程序员如果想把整个过程自动化，需要提前写大量规则。

但 LLM 出现以后，事情发生了变化。

因为模型可以理解非结构化的信息。

它可以阅读网页。

理解文档。

分析代码。

判断当前缺什么信息。

然后决定下一步去哪里找。

于是以前那些很难通过固定代码描述的流程，第一次有可能被自动化。

这可能才是 Agent 真正重要的地方。

它把自动化从“标准流程自动化”，推进到了“非标准任务自动化”。

如果拆开一个现代 Agent，通常至少可以看到几个核心部分。

1. Model

也就是 Agent 的“大脑”。

负责理解任务、推理、规划以及决定下一步行动。

可以是 GPT、Claude、Gemini、DeepSeek 等模型。

2. Tools

Agent 的“手”。

模型自己不会搜索网页，也不会执行代码。

真正的动作由 Tools 完成。

比如：

search_web()
read_file()
write_file()
run_python()
execute_shell()
send_email()
query_database()

模型负责决定什么时候调用它们。

3. Memory

如果没有 Memory，每一次 Agent 工作都像失忆。

所以很多 Agent 会加入记忆机制。

最简单的是 Context：

把之前发生过的事情继续放在上下文里面。

更复杂一些的系统会加入：

短期记忆。

长期记忆。

数据库。

向量数据库。

RAG。

甚至用户画像。

这样 Agent 才可能真正“认识你”。

4. Planning

复杂任务通常不能一步完成。

因此 Agent 会尝试拆解任务。

例如：

帮我调研一家公司。

可能先形成：

1. 查公司背景
2. 查产品
3. 查融资
4. 查竞争对手
5. 查用户评价
6. 汇总结论

然后逐步执行。

这就是 Planning。

5. Execution Environment

Agent 还需要一个真正执行动作的环境。

例如 Coding Agent 可能需要：

代码仓库。

Terminal。

Python 环境。

Docker。

浏览器。

文件系统。

否则模型即使知道下一步应该怎么做，也没有地方执行。

Agent 越强，一个问题就越明显：

模型可能做错事。

普通聊天机器人说错一句话，最多就是答案错了。

Agent 如果判断错了，可能真的会执行错误操作。

比如：

删错文件。

运行危险命令。

修改生产数据库。

调用错误 API。

泄露密钥。

所以 Agent 越强，外围控制系统反而越重要。

这就是为什么 Harness、Sandbox、Permission、Approval 这些东西正在变得越来越重要。

模型可以提出：

我要删除这个文件。

但 Harness 可以说：

不允许。

或者：

需要用户确认。

所以如果继续往下拆：

LLM 是大脑。

Tools 是手。

Agent Loop 是行动逻辑。

Harness 是护栏。

一个真正成熟的 Agent，绝对不会只是把一个强模型接上 Shell 然后让它随便运行。

真正困难的其实是：

怎么让它足够自主，同时又足够可控。

这是 Agent 工程里非常核心的问题。

如果一个 Agent 可以完成任务，那自然会出现另外一个想法：

能不能让多个 Agent 分工？

比如开发一个产品：

一个 Agent 当产品经理。

一个 Agent 写前端。

一个 Agent 写后端。

一个 Agent 测试。

一个 Agent Code Review。

于是就出现了所谓 Multi-Agent。

它模拟的其实就是人类组织。

不同 Agent 拥有不同角色、Prompt、工具和权限。

然后互相传递任务。

但 Multi-Agent 并不是 Agent 越多越好。

Agent 越多，协作成本也越高。

信息需要同步。

任务可能重复。

Agent 之间可能产生冲突。

Token 消耗也会迅速增加。

所以很多看起来非常复杂的 Multi-Agent 架构，最后可能还不如一个强 Agent + 好工具。

Agent 的数量并不是关键。

决策质量和执行效率才是。

以前的软件是这样的：

程序员提前预测用户会做什么，然后把对应功能全部写出来。

所以一个软件本质上是一堆提前设计好的按钮和流程。

用户只能在开发者规定的能力范围里面操作。

Agent 带来了另一种可能。

以后软件可能只需要告诉 AI：

这是数据库。

这是 API。

这是你可以操作的工具。

用户直接说：

帮我把过去三个月销售下降最大的客户找出来，然后给销售经理生成一份跟进名单。

Agent 自己完成：

查数据库。

写 SQL。

分析数据。

排序。

生成报告。

甚至发送邮件。

这个时候，软件的交互方式发生了变化。

以前是：

人学习软件怎么用。

以后可能是：

软件理解人想干什么。

这其实是一个非常巨大的变化。

LLM 是会思考的模型，而 Agent 是一个能够利用模型不断“观察—决策—行动”，直到完成目标的系统。

它并不是某一种具体的软件。

也不是某一个模型。

更不是一个插件。

它是一种系统架构。

可以把整个结构压缩成：

Agent = LLM + Tools + Memory + Planning + Execution Loop + Harness

其中真正的核心并不是 Tools，也不是 Memory。

而是那个 Loop。

因为正是这个循环，让模型第一次从：

“我告诉你应该怎么做。”

变成了：

“我来做，做完以后我再看看下一步。”

我觉得 Agent 最值得关注的地方，并不是“AI 会不会像人”。

这个问题其实没有那么重要。

更现实的问题是：

过去必须由人坐在电脑前一步一步完成的工作，有多少可以被 Agent 接管？

搜索资料。

整理数据。

写代码。

测试程序。

操作后台。

管理文件。

调用 API。

分析业务。

这些事情一旦开始被 Agent 连起来，AI 的角色就会发生根本变化。

Chatbot 更像一个知识接口。

Agent 更像一个执行接口。

前者解决的是：

“我不知道。”

后者试图解决的是：

“我不想亲自做。”

而这两句话之间，可能就是这一轮 AI 真正的分水岭。