“把大模型接上工具”就算 Agent 了吗？这个说法有一定道理，但还不够完整。

如果只是用户点击按钮，程序固定调用一个函数，那更像普通自动化；如果模型能够根据目标和当前结果，决定下一步做什么，并在受限范围内循环执行，才更接近 Agent 的核心形态。

Agent 的最小定义

我会把 Agent 暂时理解成：以目标为导向，能够感知环境、进行决策、调用动作，并根据反馈继续推进的系统。

这里有四个关键词：

• 目标：系统要完成什么，而不是只回答什么；
• 感知：读取用户输入、文件、数据库或工具结果；
• 决策：判断下一步是否需要继续行动；
• 反馈：根据行动结果修正后续计划。

少了目标，系统可能只是聊天；少了反馈，系统可能只是一次性生成计划；少了动作，系统没有真正改变外部世界。

一条典型的 Agent 循环

用户目标
  -> 读取上下文
  -> 模型判断下一步
  -> 选择工具并填充参数
  -> 工具返回观察结果
  -> 更新状态
  -> 继续执行或输出最终答案

比如“帮我整理本周的会议安排”：Agent 可能先读取日历，再识别冲突，接着询问缺失信息，最后生成安排。模型不一定一次就知道所有步骤，而是通过工具结果逐步推进。

Agent 与传统程序有什么不同

传统程序通常由开发者预先写出控制流：输入满足条件 A 就执行函数 B。Agent 则把部分控制流交给模型，让模型在多个工具和步骤之间做选择。

这带来灵活性，也带来不确定性。普通程序的错误往往可以通过单元测试覆盖；Agent 可能选择了“合法但不合适”的工具，或者在错误结果上继续推理。因此 Agent 旁边必须有确定性约束：参数校验、权限判断、最大轮数、超时和人工确认。

我不会把“模型参与决策”理解成“程序不再需要规则”。恰恰相反，决策权交给模型以后，规则要更明确。

从符号主义到大模型 Agent

早期智能体更多依赖规则、知识库和规划算法，优点是可解释，缺点是适应开放语言的能力有限。大模型出现后，系统可以直接理解自然语言目标、总结工具结果并生成计划，Agent 的交互方式变得自然很多。

但大模型并没有消除旧问题，只是把边界推得更远：规划可能出错，知识可能过时，工具可能失败，循环可能停不下来。今天的 Agent 工程，本质上是把模型的语言与推理能力，放进一个可控制的程序系统中。

什么时候不该使用 Agent

有些任务看起来很适合 AI，实际上使用固定流程更稳：

• 根据文件后缀选择解析器；
• 按用户权限过滤数据；
• 计算订单金额；
• 判断字段是否为空；
• 按固定步骤生成审批单。

这些逻辑的特点是答案可以明确写成规则。把它们交给模型，只会增加延迟和不确定性。

这章给我的启发

Agent 的重点不是“会聊天”，也不是“有很多工具”，而是形成了一个目标驱动的感知、决策、行动和反馈闭环。

理解这个闭环以后，记忆是为了保存什么，RAG 是为了补充什么，规划是为了拆解什么，Harness 又是为了约束什么，就都有了位置。接下来需要先补上闭环里的“大脑”：大语言模型到底能做什么，不能做什么。

文章摘自：https://www.cnblogs.com/hazy-star/p/22615734