Agent 是什么？从让 AI 帮你修一个 Bug 说起

2026-10-11 / 6 min read / #agent #ai

从修 Bug 说起，解释 Agent 如何调用工具、根据反馈推进任务，以及它的能力边界。

假设你写了一个程序，启动时报错。你把错误信息发给 AI，它解释了原因，又给出一段修改后的代码。

接下来，你把代码复制回去，运行，发现还有问题，再把新的报错发给它。

这个过程很常见。AI 在帮忙分析，你负责操作电脑，也负责把每一步的结果告诉它。

现在换一种做法。你允许 AI 读取项目文件、修改代码、运行测试，然后告诉它：“帮我查清这个错误，把它修好。”

它先查看报错涉及的文件，发现问题可能出在配置读取，于是继续找相关代码。改完之后运行测试，测试没通过，它根据新的错误调整修改。直到检查通过，或者遇到需要你决定的问题，才停下来。

这就是理解 AI Agent 的一个入口：你交给它一个目标，它能够采取行动，再根据行动的结果决定下一步。

这里讨论的是以大语言模型为核心的 Agent。中文常译作“智能体”，但这个名字有点抽象。先记住它干活的过程，比记住名词有用。

下一步由谁决定

“Agent”没有一个所有人都严格遵守的定义。有些产品把能调用工具的聊天助手叫 Agent，有些则要求它能连续完成一段工作。

一个实用的区分方法，是看任务推进到一半时，谁来决定下一步。

比如，你写了一段固定程序：收到文章，生成摘要，把摘要翻译成英文，再保存到文件。里面调用了几次模型，但路线早已写好。这通常属于工作流。

如果系统读完文章，发现一个结论缺少依据，自己决定搜索资料；查到的信息互相矛盾，又决定核对原始出处，那么它已经在根据现场情况选择路线。Anthropic 在工程文章中，也用“预先定义的路径”和“模型动态决定过程”来区分工作流与 Agent。来源

实际产品往往把两者结合起来。报销审批可以保留固定流程，单据异常的调查则交给 Agent。没必要为了叫 Agent，就把每一步都交给模型临场发挥。

模型说“我帮你改好了”，文件不会因此发生变化。真正修改文件的是外面的程序。

开发者会给模型提供一组工具，比如读取文件、搜索内容、执行命令。模型根据任务选择工具，并给出参数。程序检查请求、执行操作，再把结果交回模型。

回到修 Bug 的例子，一轮操作大致是：

读到报错，决定查看文件；拿到文件内容，决定修改某一处；收到修改成功的结果，决定运行测试。

这几步不断接下去，就形成了 Agent 的工作循环。

工具也不一定是复杂的新东西。一个已有的搜索接口、数据库查询函数，或者文件操作程序，都可以成为工具。关键是让模型知道它能做什么、需要什么参数、返回结果该怎样理解。工具说明含糊，模型就可能选错工具或传错参数。来源

所以，同一个模型，放进不同的系统里，能做的事可能差很多。只接聊天界面，它主要给你回答；接上文件和测试环境，它才有条件实际修改项目。至于能不能改对，还要另外验证。

假设它已经改了三个文件，却忘了你说过“不要改变现有接口”，后面的工作就可能越做越偏。

Agent 每次决定下一步，都需要看到相关信息：原来的目标、你的限制、已经做过的操作、最新的执行结果。这些放在一起，就是它当时的上下文。

但上下文不是一个无限大的仓库。工作时间越长，文件内容、报错和历史记录就越多。把所有东西一直塞进去，既增加成本，也可能让重要信息淹没在无关细节里。

因此，系统通常需要保留关键进展，整理过长的记录，并在需要时重新读取文件。有些还会把任务状态或笔记存到外部，后续再取回来。来源

这也解释了为什么“它刚才明明知道，怎么现在又忘了”。你看见的是一段连续对话，模型每次实际拿到的信息，却未必完全相同。保存过的信息，也只有被正确取回并提供给模型，才有机会影响下一步。

Agent 的麻烦在于，错误可能被后续行动放大。

聊天时，它误判了原因，你还可以在复制代码之前发现问题。允许它连续操作后，它可能围绕这个错误判断修改多个文件，甚至把原本正常的部分也改掉。

因此，可靠的 Agent 需要明确的完成标准和停止条件。修 Bug 时，要知道原来的错误是否消失、相关测试是否通过；多次尝试仍无进展时，要停下来说明卡在哪里。测试通过也只是证据的一部分，不能自动证明所有需求都满足。来源

对前面的修复任务，你可以给出更具体的要求：“修复这个启动错误，保持现有接口不变，运行相关测试，并说明修改了什么。”

这样一来，它要完成什么、不能改变什么、最后拿什么证明完成，都更清楚了。

权限同样需要具体。查看代码、修改本地文件、发布到线上，是不同的操作。允许它研究和修改，不必连发布权限一起交出去。

如果任务只有一步，比如翻译一段话，直接调用模型往往就够了。步骤长期固定，用普通程序或工作流可能更省事。

Agent 更适合这种情况：目标能说清楚，但开始之前，你也不知道中途会遇到什么，需要做几步。

查一个陌生项目的错误就是这样。可能看两行配置就解决，也可能要追到几个模块之外。让系统根据反馈选择下一步，在这里有实际用途；代价是执行时间、调用成本和出错机会也会增加。

理解 Agent，不妨一直带着开头那个例子：它看到了什么，能做哪些操作，如何利用结果继续推进，又凭什么判断可以停了。

把这几件事看清楚，你就能判断一个产品到底能替你完成哪一段工作，以及哪一段还需要你接手。