学Agent，本质上是在学什么

前几天公司里有个程序员问我一个问题。

他最近在看 LLM 怎么和知识库结合，也就是用户问一个问题，系统先去知识库里查资料，再把资料交给大模型回答。

他问我：这算不算在学 Agent？

这个问题挺典型的。我刚开始接触 Agent 的时候，也差不多是这么理解的：能查知识库，能调工具，能自己干点事，好像就算 Agent 了。

但后来做业务场景看多了，我慢慢觉得，这个理解有点偏。

Agent 不应该只看它用了哪些功能，而要看它到底解决了什么问题。

我现在更愿意把 Agent 理解成一套工程方法。它真正要解决的，不是“怎么让大模型更聪明”，而是：

怎么让一个不太稳定的大模型，在真实业务里尽量稳定、可控地工作。

这个角度一变，很多东西就顺了。

当前大模型最大的问题不是不会，而是不确定

程序员过去写业务系统，习惯的是确定性。

比如一个安防值守流程：收到警情，核实警情，联系客户，通知警卫，记录处理结果。

如果流程规则很清楚，用 Java 写就行。什么条件进入下一步，什么情况重试，什么情况转人工，几个判断分支就能表达清楚。

这种场景里，硬把所有事情都交给大模型，反而会让人不放心。

因为大模型不是传统函数。

传统函数一般是输入确定、逻辑确定、输出也相对确定。大模型不是这样。同一个问题，它可能这次这么答，下次换一种答法。有时候它说得很像那么回事，但依据并不充分。

在普通问答里，这可能只是体验问题。但在企业业务里，这就是风险问题。

比如模型判断错了怎么办？它的判断依据是什么？就像豆包如果它很自信的胡说八道怎么办？

这些问题，才是 Agent 开发真正绕不开的地方。

所以我现在理解的 Agent，不是让模型更自由，而是给模型设计一个可以工作的范围。让它在这个范围里发挥判断、推理和调度能力，但关键地方要有规则、流程、日志和人工兜底。

LLM + 知识库，不一定就是 Agent

回到前面那个问题：LLM + 知识库算不算 Agent？

我觉得不一定。

如果只是用户问一句话，系统去知识库里查几段内容，然后拼到 Prompt 里让模型回答，这更像 RAG。

RAG 很重要，而且很多业务场景第一步确实应该先做 RAG。但它不一定就是 Agent。

因为在这个过程中，模型主要是在“基于资料回答问题”。它没有明显地判断下一步要做什么，也没有围绕一个目标持续推进任务。

但如果系统变成这样，就开始接近 Agent 了：

模型知道当前目标是什么；
它能判断还缺哪些信息；
它能决定要不要查知识库、调接口、看历史记录；
它能根据中间结果调整下一步；
最后还能输出一份程序可以继续处理的结构化结果。

这时候我们讨论的就不是单个问答能力了，而是一个任务流程。

所以我觉得，Agent 不是某个固定功能，也不是“有没有知识库”或者“有没有工具调用”。它更像是一种系统设计方式：把大模型放进一个受控的任务流程里，让它做适合它做的部分。

Agent 框架真正帮我们处理什么

如果只是调用大模型，其实一个 API 就够了。

Agent 框架有价值的地方，是它把大模型应用里那些不稳定、不可控、难追溯的问题，拆成了一些可以组合的模块。

比如 Prompt，不只是写几句提示词。它是在告诉模型：你是谁，要完成什么目标，哪些事情不能做，最后应该怎么输出。

Retriever 也不只是查知识库。它其实是在控制模型的信息来源。我们希望模型基于企业自己的资料回答，而不是凭感觉发挥。

Tool 的意义也不只是“让模型会调用外部能力”。更重要的是，模型不能直接操作业务系统，它只能通过我们开放出来的工具去查数据、调接口、创建任务。这个边界很重要。

Structured Output 看起来只是把结果变成 JSON，但在业务系统里，这一步很关键。因为程序没法稳定消费一段自由发挥的自然语言。你得让模型输出字段明确、含义明确、后续可以继续处理的数据。

Chain、Agent、Graph 这些东西，本质上是在管任务怎么往下走。什么时候继续，什么时候重试，什么时候停下来，什么时候交给人。

Tracing 在 demo 阶段很容易被忽略，但真上线以后非常重要。因为你迟早会遇到这样的问题：模型为什么这么答？它查了哪些资料？调用了哪个工具？是哪一步开始跑偏的？

没有这些记录，出了问题只能猜。

所以学 Agent 框架时，我觉得可以少问一点“这个 API 怎么用”，多问一点：

这个组件到底是在控制大模型的哪一部分不确定性？

这样学起来会更有主线。

用安防值守举个例子

拿安防值守来说。

假设系统收到一条警情，需要判断这次是不是误报。

最简单的 demo 很好做：把警情信息丢给大模型，然后问它“这是不是误报”。

但这种东西，企业一般不敢直接用。

因为误报判断不是普通聊天。模型如果把真实警情判断成误报，后果可能很严重。哪怕它大多数时候判断对，只要关键时刻错一次，客户也很难接受。

真正能落地的做法，通常不是让模型直接拍脑袋给结论，而是先设计一个受控流程。

比如系统先收集这条警情相关的信息：告警类型、设备位置、发生时间、历史告警记录、这个点位过去的误报率、摄像头当前状态、客户有没有特殊要求。

模型可以参与判断，但它要基于这些证据判断。

输出也不能只是一句话“我认为是误报”。更合理的是结构化结果，比如：

是否疑似误报；
置信度是多少；
判断依据有哪些；
有哪些风险点；
建议下一步怎么处理。

最后还要有兜底规则。

比如置信度低的时候必须转人工；重点区域必须人工确认；证据不足时不能直接判定为误报；某些客户的规则优先级高于模型判断。

这样业务上才稍微让人放心。

因为系统并不是完全相信模型，而是在利用模型的理解和判断能力，同时用流程、规则、证据和人工确认来约束它。

这可能才是 Agent 在企业场景里的价值。

它不是替代原来的业务系统，而是进入业务系统，在设计好的边界里承担一部分过去不好自动化的判断和调度工作。

程序员应该怎么学 Agent

所以程序员学 Agent，我觉得不要一上来就陷进名词里。

比如：
这个到底算不算 Agent？
LangChain 要不要学？
LangGraph 是不是必须学？
哪个框架现在更流行？

这些问题当然可以问，但不应该是最先问的。

更重要的问题应该是：

为什么 Agent 能让大模型在业务里更可控？

带着这个问题再去看各个组件，会清楚很多。

Prompt 控制模型的行为预期。
Retriever 控制模型能看到什么资料。
Tool 控制模型能做什么动作。
Structured Output 控制模型怎么把结果交还给程序。
Graph 控制任务怎么一步一步推进。
Tracing 控制过程能不能回看和追溯。
人工确认控制关键风险。

这些东西背后，其实都在回答同一个问题：

怎么让大模型在真实业务里稳定一点、可靠一点、可追溯一点。

如果从这个角度学 Agent，就不会只是背 API，也不会纠结某个功能到底算不算 Agent。

你会更清楚地知道：自己学的不是一个新名词，而是一套把大模型接进真实业务系统里的工程方法。