从 AI 到 Agent：给模型装上手脚
摘要：大模型很会回答问题，但"会回答"不等于"能完成任务"。一个 Agent 的关键变化，是让模型进入一个可行动的闭环：理解目标、决定下一步、调用工具、观察结果，再继续判断。本文先把 LLM 和 Agent 的边界讲清楚，为后面动手实现一个最小 Agent 打地基。
标签：Agent、LLM、AI 应用、工具调用、AI 工程
聊天机器人为什么还不是 Agent
很多人第一次接触大模型，会自然地产生一种感觉：我已经有一个 AI 助手了。你问它一个概念，它能解释；你让它写一段文案，它能生成；你贴一段代码，它也能指出问题。这个体验确实很强，但它和 Agent 之间还有一道非常关键的工程分界线。
普通聊天模型大多数时候只是在"生成下一段文本"。它不知道你电脑里有哪些文件，不能自己打开项目目录，也不会真的运行测试。它可以说"我建议你创建一个 hello.py"，但文件并不会因此出现在磁盘里。它可以说"你应该检查依赖版本"，但它没有真正执行 pip list。
所以判断一个系统是不是 Agent，不要只看它回答得像不像人，而要看它有没有进入行动闭环。一个 Agent 至少应该能围绕目标持续做这几件事：
text
理解用户目标
判断下一步该做什么
选择合适工具并给出参数
读取工具执行后的真实结果
根据结果继续推进或收口这就是从"会说"到"会做"的变化。
LLM 是大脑，但不是完整系统
如果只看一次普通模型调用，它的结构非常简单：
text
User input → LLM → Reply用户输入一段文本，模型返回一段文本。这个结构适合问答、总结、改写、翻译、生成代码片段，但它没有外部反馈。模型不知道自己的建议有没有被执行，也不知道执行后发生了什么。
Agent 的结构则多了一层运行时：
这张图里，LLM 仍然是决策中心。它负责理解目标、推理下一步、生成工具调用参数。但是工具执行不发生在模型内部，而发生在宿主程序里。宿主程序拿到模型给出的结构化请求，去运行命令、读文件、查网页或调用 API，再把结果作为观察值放回上下文。
于是模型不再只是回答"你应该做什么"，而是可以在每一步之后看到真实反馈：
text
我想查看目录 → 调用 list 工具 → 看到文件列表
我想读取配置 → 调用 read_file → 看到配置内容
我想运行测试 → 调用 shell → 看到报错或通过结果这套"思考 - 行动 - 观察 - 再思考"的循环，才是 Agent 的底座。
Agent 的四个核心要素
为了避免把 Agent 讲成一个模糊概念，我们可以把它拆成四个要素：规划、记忆、工具、感知。
规划负责决定任务怎么拆。复杂目标通常不能一步完成，比如"帮我修复这个 bug"可能要先复现、再定位、再修改、再验证。没有规划，模型容易想到哪做到哪。
记忆负责保存上下文。大模型 API 本身是无状态的，下一次请求不会天然知道上一次发生了什么。所谓"记得"，其实是程序把历史消息、长期信息或任务状态重新交给模型。
工具负责让模型接触外部世界。工具可以是 shell 命令、文件读写、网页抓取、数据库查询，也可以是你自己封装的业务接口。模型通过参数请求工具，代码负责执行。
感知负责把执行结果带回来。工具输出、文件内容、错误日志、网页正文，都会成为下一轮推理的依据。如果没有观察结果，Agent 只是盲目行动。
把这四个要素合在一起，就能得到一个很实用的定义：
Agent 是一个由 LLM 驱动的任务执行系统。它接收目标，在上下文中推理，通过工具改变或查询外部环境，再根据观察结果继续决策，直到产出结果。
这个定义故意没有使用"自主意识""智能体人格"之类的词。因为从工程角度看，Agent 首先是一套围绕模型组织起来的运行机制。
工具调用为什么是转折点
Agent 最关键的转折点，是工具调用。
在没有工具之前，模型只能生成建议。你问它"帮我看看当前目录有什么文件"，它最多告诉你"你可以运行 ls"。有了工具之后，模型可以输出一个结构化请求：
json
{
"name": "run_command",
"input": {
"command": "ls"
}
}宿主程序看到这个请求后执行命令，再把输出交回模型。模型看到真实文件列表，才能继续判断下一步要读哪个文件、改哪个配置、运行哪个测试。
这也是为什么很多 Agent 框架看起来很复杂，但底层都绕不开同一个模式：
text
声明工具能力
模型选择工具
代码执行工具
结果回灌模型
模型继续判断框架可以帮你封装工具注册、参数校验、并发执行、日志记录，但不会改变这条基本链路。理解了这条链路，再看任何框架都不会只剩黑盒。
Agent 不等于无限自动化
Agent 能行动，不代表它应该无边界地行动。恰恰相反，越是能调用工具，越需要边界。
比如 shell 工具很强，但也很危险。模型请求运行 ls 没什么问题，请求删除文件就需要谨慎。文件写入工具能提高效率，但也应该限制工作区范围。网页抓取能扩展信息来源，但要处理失败、超时、内容过长等问题。
所以一个可靠的 Agent 系统，除了"能做事"，还要考虑：
- 工具权限：哪些工具能用，哪些工具不能用；
- 参数校验：模型给出的参数是否合法；
- 执行边界：能读写哪些目录，能访问哪些服务；
- 观察截断：工具输出太长时怎么处理；
- 停止条件：什么时候任务算完成；
- 审计记录：做过哪些动作，结果是什么。
这些问题听起来不像"智能"，但它们决定了 Agent 能不能从 demo 走向真正可用。
先建立一个最小心智模型
如果你现在要在脑子里留下一个最小模型，可以只记住这句话：
LLM 负责决定下一步，工具负责接触世界，运行时负责把结果带回来。
用更具体的结构表示，就是：
text
目标 → 模型推理 → 工具调用 → 执行结果 → 模型继续推理 → 最终回答很多看起来复杂的能力，最后都会回到这条循环上：模型先判断，程序去执行，结果再回到模型面前。循环稳定，系统才有继续加能力的地基；循环不稳定，外面包再多概念也只是演示效果。
但在真正写这些能力之前，第一步不是选框架，而是先把这个循环亲手写出来。只要能跑通一次"模型请求工具、程序执行工具、模型读取结果"的闭环，一个最小 Agent 的骨架就出现了。
常见误区：把"智能感"当成"Agent 能力"
很多产品会让 AI 表现得很像一个助手：有头像，有称呼，会用自然语言解释自己的思路，甚至会主动说"我来帮你处理"。这些设计能提升体验，但它们不等于 Agent 能力。
判断一个系统时，可以故意问几个很具体的问题：
text
它能不能读取真实文件？
它能不能运行一个命令并看到输出？
它能不能根据错误结果改变下一步？
它能不能知道自己刚才做过什么？
它能不能在任务完成前不急着给结论？如果答案都是否定的，那它更像一个包装精致的聊天机器人。它也许非常有用，但还没有进入"行动系统"的范畴。
另一个误区是把 Agent 等同于"全自动"。真正靠谱的 Agent 反而应该知道边界。有些动作可以自动执行，比如读文件、列目录、搜索文档；有些动作需要确认，比如删除文件、提交代码、调用付费接口。Agent 的目标不是把所有控制权交给模型，而是让模型在明确边界内更高效地推进任务。
一个好 Agent 应该让状态可见
当系统只是聊天时，状态大多藏在对话里。用户读完回答，大概知道发生了什么。但一旦 Agent 开始行动，状态就必须更清楚。
它正在做哪一步？刚才调用了什么工具？工具返回了什么？下一步为什么这么选？如果失败了，是工具失败、参数错了、权限不够，还是模型判断错了？
这些问题不应该只靠模型最后写一段总结来解释。运行时本身就应该留下可观察的信息：工具调用日志、输入参数、输出摘要、错误信息、上下文记录。这样你才能调试它，也才能相信它。
这也是为什么从第一步开始，我们就把 Agent 理解成一个工程系统。模型很重要，但它只是系统的一部分。真正让 Agent 可用的，是模型之外那层负责上下文、工具、状态、权限和日志的运行时。
读完这一篇可以自己做的练习
你可以不写任何框架代码，只在纸上画一个任务闭环。比如任务是"检查一个 Python 项目为什么测试失败"。
先写出模型可能需要的工具：
text
列目录
读取文件
运行测试
搜索报错
修改文件
再次运行测试再写出每一步的观察结果如何影响下一步：
text
看到测试失败 → 读取失败文件
看到缺少依赖 → 查看 requirements
看到断言错误 → 定位对应函数
修改后 → 再运行测试这个练习会帮助你把 Agent 从"一个会聊天的 AI"重新理解成"一个围绕工具结果不断决策的系统"。只要这个心智模型建立起来，后面写代码就不会迷路。
工具闭环为什么比"回答质量"更基础
做 Agent 时，很容易被模型回答质量吸引。模型解释得越流畅，越像真的理解了任务。但工程上更应该先看闭环是否可靠。
假设用户让系统"修复一个脚本"。如果模型只是根据报错猜答案，它可能写出看似合理的建议；但如果它能读取脚本、运行脚本、看到报错、修改文件、再次运行，它就有机会用事实纠正自己的猜测。工具闭环的意义就在这里：它让模型不再只依赖训练时学到的模式，而是能把当前环境里的真实反馈纳入判断。
所以，一个 Agent 的早期验收标准不应该是"它说得像不像专家"，而应该是：
text
它的每一步判断有没有观察依据？
它调用工具后有没有读取结果？
它遇到失败时有没有改变策略？
它最终回答能不能追溯到执行过程？只要这些问题成立，即便工具很少、界面很朴素，系统也已经具备了 Agent 的基本骨架。
边界感也是能力的一部分
Agent 能做事，并不代表它应该什么都能做。恰恰相反，越能行动的系统越需要边界。
比如读取目录通常风险很低，运行测试也比较安全；但删除文件、修改配置、安装依赖、调用外部付费服务，就需要更严格的控制。一个成熟的运行时会把工具分级：有些工具可以直接执行，有些工具需要用户确认，有些工具只能在指定目录内工作。
这不是在削弱 Agent，而是在让它可用。没有边界的自动化很难被信任；有清楚边界的自动化，才能被放进真实工作流里。
小结
一个最小 Agent 不是一开始就复杂。它从一次 API 调用开始，逐步加上循环、history、system prompt、tool use 和 skills。
这篇最重要的结论是：Agent 的基础不是框架对象，而是工具闭环。只要模型能请求工具，程序能执行工具，结果能回到上下文，模型能继续判断，一个 Agent 的骨架就已经出现。
但这也留下了新的问题：history 会随着对话和工具结果不断增长。一个能长期工作的 Agent，不能永远把所有原始消息都塞回模型。下一步，就要给它设计记忆系统。
视频与源码
如果你想看完整演示，可以在主页的《从零手搓 Agent》合集里按顺序观看视频版：
文章里的示例代码和完整项目也放在这里：
- 📦 教学仓库：github.com/TheSyart/cl...
- ⚔️ 实战项目：github.com/TheSyart/em...
我会持续更新 Agent 教学与实战内容。觉得有用的话，欢迎给项目点个 Star ⭐，也谢谢你一路看到这里。