Agent
为什么需要 Agent
LLM 很强，但强在"说"，弱在"做"。
你可以让它回答"今天天气怎么样"，但如果让它帮你"查天气、发邮件、记住客户偏好、明天再跟进"，它就卡住了——因为普通 LLM 只能做一次问答，说出一段话就结束，不会持续行动。
这时候就需要一个能把大任务拆成小步骤、并且自己判断下一步该做什么的执行者。Agent 解决的就是这个问题：让 AI 从"回答问题"变成"推进任务"。
但光有这个想法还不够——Agent 需要实际"做"的能力。这就是 Tool Calling 的作用：让模型能发起调用指令，驱动外部系统执行搜索、写数据库、发消息等动作。
有了 Tool Calling，Agent 能调用一次工具了。但现实任务往往不是调用一次就结束，而是需要根据返回结果判断下一步。这引出了 ReAct 的概念：思考 → 行动 → 观察 → 再思考的循环闭环。
什么是 Agent
一句话定义：Agent 的本质是循环执行——感知 → 规划 → 行动 → 观察 → 再规划，直到任务完成或达到终止条件。
你可以把它理解成一个数字员工：
- 普通员工接到"写一份市场报告"的任务，会拆解成"搜数据 → 整理 → 写稿 → 检查"等多个步骤
- Agent 同样如此，它不会一次性把所有内容都说出来，而是走一步看一步
Agent 不是聊天机器人的升级版，而是完全不同的工作模式：
- 聊天机器人：输入 → 输出 → 结束
- Agent：输入 → 执行动作 → 看结果 → 再执行 → ... → 完成
这也解释了为什么很多 Agent 框架都强调 Thought → Action → Observation 的闭环——Agent 的核心不是"想说什么"，而是"做了什么并看到了什么"。
Chain of Thought 让模型学会"先想后答"，ReAct 在这个基础上加上"做"和"看结果"，让 Agent 能真正推进任务。
怎么做：什么时候用 Agent
适合用 Agent 的场景：
- 多步骤任务：任��需要拆解、执行、检查、继续推进，而不是一句话能解决的
- 需要调用外部工具：仅靠语言生成不够，必须访问搜索、数据库、文件系统、API
- 环境会变化：执行中要根据新信息动态调整
- 需要持续上下文：用户偏好、历史记录、任务阶段都很重要
典型例子：
- 帮用户搜集资料并输出总结报告（涉及 RAG 检索外部知识）
- 根据业务规则处理工单、审批和消息通知
- 自动读取文档、更新表格、同步知识库
- 在代码仓库中检索、修改、测试并反馈结果
不适合用 Agent 的场景：
- 一次性生成文案
- 单轮问答
- 固定模板填空
这些场景用普通 LLM 或传统自动化就够了，上 Agent 反而增加复杂度。
常见误区
误区一：模型够强，就自然是 Agent
模型能力强不等于具备执行闭环。一个强模型如果缺少工具调用和循环执行的设计，它仍然只是一个会说话的模型，不是 Agent。
误区二：Agent 一定要完全自主
现实中很多高质量 Agent 是"人机协同"——Agent 负责执行循环，人类负责审核关键节点。不要把"完全自主"当成 Agent 的必要条件。
误区三：Agent 越自由越智能
缺少边界会导致幻觉、乱调用、成本失控。好的 Agent 不是"最像人"，而是在可控性、成本、准确率和自动化程度之间做平衡。
误区四：所有自动化都该 Agent 化
规则稳定的流程，传统自动化更便宜可靠。Agent 的价值在于处理需要判断和调整的复杂场景，而不是替代所有自动化。
构建 Agent 时最重要的三件事
- 明确目标与终止条件：任务什么时候算完成，必须定义清楚。不能含糊地说"帮我做得好一点"。
- 限制可用工具和权限：避免错误操作、越权调用和无效循环。给 Agent 太多自由度反而容易出问题。这里就需要为每个 Skill（工具能力）设计清晰的边界。
- 建立可观察性：记录步骤、工具调用、失败原因，便于调试与优化。没有日志的 Agent 很难优化。
很多 Agent 项目失败，不是模型不够强，而是因为目标含糊、工具设计粗糙、没有日志回放能力。
记住这一句：Agent 的本质是循环执行，不是一次问答。它不只"会说"，还会"做"并且"根据结果继续做"。
相关词条：ReAct · Tool Calling
标签