★ FEATURED ARTICLE 我最初看到这个标题的时候就在想一个问题为什么聪明人总是讲不清楚那个很关键的概念这半年我一直在折腾 Agent 相关的东西从 LangChain 到 Dify从 LangGraph 到各种自研框架身边的同事也天天把 Agent 挂在嘴边。但你要是真问我Agent 到底是什么我可能憋半天只能憋出一句就是让大模型自己调用工具完成任务。这话没错但说了等于没说。直到我后来把 Agent 拆成了两个角色来看整个问题的思路一下子就通了一个是有嘴没手的学霸也就是大模型另一个是会干活的项目经理也就是 Agent 框架和编排层。这篇文章我想把这条思路完整地讲一遍包括 Agent 的基础原理、主流框架选型、落地时踩过的坑以及我自己总结的安全边界和学习路线。适合所有刚接触 Agent、或者已经会调用 API 但想知道下一步该往哪走的人。1. 一句话本质为什么大模型是有嘴没手而 Agent 是会动手的项目经理Agent 这个词这两年被玩坏了什么都是 Agent什么都不是 Agent。为了把概念落地我从一个特别生活化的角度来理解它。1.1 大模型本身只是个会说话的脑不是一个会干活的体我们平时用 ChatGPT、Claude 或者任意一个开源模型本质上是在做一个事情把一个输入丢进去然后它输出一段文本。哪怕它在后端调用了搜索、调用了代码解释器你感知到的还是它说了什么而不是它做了什么。但注意这里有个特别反直觉的点。当你问 GPT帮我查一下今天北京的天气的时候它如果网上的训练数据里有实时天气接口它可以直接把结果背出来如果训练数据里没有它就只能编。这就是大模型的本质——它是一个在给定上下文条件下预测下一个 Token 的机器。它没有能力打开浏览器没有能力执行 SQL没有能力调用支付接口。它只能输出文字哪怕输出了代码代码也不会自己运行。这就是我标题里说的有嘴没手。模型可以口若悬河地告诉你应该怎么查天气、应该怎么写一个 Python 脚本但它自己不能按回车。那怎么让它真正干活呢答案是给这个嘴配一个身体配一个能理解它的语言、并替它执行具体动作的执行层。这个执行层就是 Agent 框架的核心。1.2 项目经理的角色拆解、调度、验收项目经理这个岗位核心职责不是自己写代码而是把一个大的目标拆成可执行的任务分配给不同的人然后看结果是否达标不达标就打回重做。Agent 框架干的事情本质上就是这个。你给 Agent 一个目标帮我统计这个月电商订单的数据并且生成一份周报。Agent 框架会做下面几件事把目标拆解成几个子任务连接数据库、查询订单表、汇总数据、生成周报文本。依次调度模型来决定每一步调用哪个工具查订单表需要先连数据库这就要用到 SQL 工具汇总数据可能需要调用脚本工具生成周报又要用到大模型本身。每一步执行完检查结果是否符合下一步的输入要求如果工具报错了还要把错误信息交给模型让它修正策略重试。全部执行完成后把最终的结果组装、输出。注意这里有一个关键的分界线模型负责决定调用哪个工具、生成什么参数框架负责实际执行这些工具。模型是决策层框架是执行层。我之前给同事打过一个比方你给学霸出了一道题学霸说这题我会需要用到微积分和拉普拉斯变换但学霸的手是断的他写不了演算步骤。这时候项目经理站在旁边学霸说用微积分经理就拿计算器帮你算了学霸说需要拉普拉斯变换经理就去查变换表帮你把结果拿回来。学霸负责说经理负责做两个人拼起来才是完整的一个 Agent。1.3 从对话机器人到Agent的进化到底变在哪里这道进化线其实是 Agent 技术近几年最核心的主线。如果你去看 2023 年之前的所谓AI 应用大多数是问答机器人你给我一个问题我返回一段答案。这种交互模式叫 IO 模式Input 和 Output中间只有一个模型在转。后来大家发现如果我让模型多走几步——先搜索、再思考、再调用代码、再根据结果生成答案——效果会好得多。每一步模型都在产生中间结果而这些中间结果会成为下一步的输入。于是就有了Chain的概念也就是把一次大模型调用变成了多次大模型调用。再往后大家发现不能让模型一口气把所有步骤都规划完因为环境是动态的第一次调用的结果可能跟预期不一样也许需要临时改变计划。于是就有了Agent 循环感知环境 - 模型思考 - 选择动作 - 执行动作 - 观察结果 - 再次思考。这是一个闭环模型在每一步都在动态决策而不是一次性把路径定死。所以Agent 和普通对话的本质区别可以总结成一句话普通对话是一次性回答Agent 是目标驱动、多轮决策、工具辅助、自主执行的闭环系统。2. 记住这三个词你就懂 Agent 架构了记忆、工具、编排把概念搞清楚了我们来看一个能真正落地的 Agent 需要哪几个核心模块。我总结下来就三样记忆、工具、编排。2.1 记忆Session、上下文窗口、向量数据库分别解决什么问题记忆是 Agent 落地时第一个要面对的问题。我们想一下学霸虽然聪明但有个致命短板——他的记忆只停留在当前对话的上下文里。你跟他聊十轮前九轮的结论在他脑子里但如果你新建一个对话他之前记住的全没了。这就是大模型的短期记忆本质上是模型输入里的上下文窗口。短期记忆的问题非常明显上下文窗口是有限的。GPT-4o 或 Claude 的窗口可能有 128K、200K Token听着很大但如果你让 Agent 读一个 50 页的 PDF、翻一遍 20 万字的文档再让它延续之前的对话窗口很快就满了。这就像项目经理手下的一个临时工只能记住最近交代的几件事干完一件忘一件。所以我们需要长期记忆。长期记忆通常有两种实现方式把重要信息提炼成摘要每次对话开始前把摘要放回上下文里。相当于临时工每干完一件事写一份工作小结给项目经理看。把知识存到向量数据库里相似度检索出相关的片段再放回上下文。这相当于给临时工配一个外接硬盘硬盘里存着所有的历史资料需要的时候按需查。这两种方式都会在主流框架里用到解决的核心问题是一样的怎么在有限的上下文窗口里只把最相关的信息喂给模型。如果你看过 Agent 的代码实现你会发现大多数框架在每次循环的时候都会做几件事从 memory 里取出历史信息、从 vector store 里检索出相关片段、加上系统提示词、再加上当前用户请求一起作为这次调用的输入。这一步是 Agent 系统最繁琐、也最能体现工程量差异的地方。2.2 工具Function Calling 是如何让大模型动手的如果说记忆是 Agent 的仓库那工具就是 Agent 的手。大模型要动手就必须依赖工具的调用能力。目前主流的实现方式是 Function Calling。具体流程如下开发者在系统提示词里把可用的工具清单发给模型。每个工具的描述是一个 JSON 格式的结构包含工具名、参数列表、参数类型、参数说明、工具用途说明。模型根据用户的请求决定要不要调用某个工具。如果决定调用它会输出一个结构化的 JSON指定工具名和参数值。框架层拿到这个 JSON解析出来要调用哪个工具、传什么参数然后在你写的代码里去执行这个工具函数。工具执行完返回一段结果文本。框架把这个结果作为工具返回消息重新发给模型。模型阅读工具返回结果决定下一步是继续调用下一个工具还是对结果进行总结之后输出给用户。所以工具本身是你写的普通函数比如 query_database(connection_str, sql_stmt)或者 send_email(recipient, subject, body)。Agent 框架的价值在于它替你完成了模型输出 → 函数调用 → 返回结果 → 再次传给模型这一个循环。如果这层循环没有你就得自己写代码去解析模型的输出然后自己拼接下一步的上下文。刚开始亲手实现一遍这个循环很有帮助能让你对 Agent 框架的底层逻辑彻底透底。我第一次纯手写这个循环的时候踩了一个很蠢的坑工具函数的返回结果里包含了大量格式化字符达到了上万 Token结果下一次调用模型时上下文中塞进了这么一大堆无关紧要的内容当时就发现 Token 消耗暴增。后来才意识到工具返回的结果其实应该做裁剪和摘要只把关键字段暴露给模型。这在后面章节我会专门展开讲。2.3 编排ReAct、Plan-and-Execute 与主流的 Agent 循环有了手还要有脑子来指挥手。这个指挥的过程就是编排。目前最经典的编排模式叫 ReAct这个词来自一篇著名的论文核心逻辑就是让模型在 Reasoning推理和 Acting行动之间反复切换。看一个最简单的循环就知道了模型输入用户目标 历史对话 可用工具清单 已执行过的步骤模型输出第一段话Thought分析当前情况 Action选择调用哪个工具 Action Input传给工具的参数框架执行工具返回 Observation工具的观察结果模型把这次观察结果当作新的信息再次输出 Thought Action或者输出 Final Answer结束循环这个循环看起来简单但实际落地你会发现如果不加限制模型可能会陷入死循环调一次工具不行再调一次还是不行再换一个工具试……试了十几次还在原地打转。所以我后来都会给 Agent 配置两个硬性参数最大迭代轮次max_iterations和单轮超时时间max_execution_time。这两个参数基本是 Agent 系统的标配。另一个常见的模式是 Plan-and-Execute。它不是让模型边做边想而是先让模型输出一个完整的执行方案包括步骤列表和每步需要的工具然后按方案逐步执行。如果中间某一步执行失败了再回到规划阶段重新调整方案。这两种模式没有绝对优劣ReAct 更灵活适合任务不太确定、需要边走边看的场景Plan-and-Execute 更可控适合流程相对固定、执行步骤明确的场景比如电商订单处理、日报生成这种。3. 框架选型LangChain、Dify、CrewAI到底哪个适合你现在用 Agent 做项目几乎不可能完全从零造轮子选框架是绕不开的一关。市面上的主流选择大概就是 LangChain、LangGraph、Dify、CrewAI 这几类。我分别说说我用下来的体感和适用边界。3.1 LangChain/LangGraph内核级选手程序员的最爱LangChain 是老牌 Agent 框架了也是最容易被初学者骂太抽象的框架。我自己刚接触它的时候用了一个星期每天都被抽象类搞到怀疑人生。但后来我才慢慢意识到它的核心价值是提供了一套高度可扩展的抽象各类模型连接器、提示词模板、链式调用、工具注册表、记忆模块应有尽有。你如果想做一个比较复杂的 Agent 系统LangChain 是最接近搭积木逻辑的选择。LangGraph 可以理解为 LangChain 的升级版它把 Agent 流程建模成图结构节点是各种操作边是流程路径。你可以在图上定义什么时候重试什么时候中断什么时候去调用另一个子 Agent。这种图编排方式控制力极强适合生产级系统。但有一个教训我必须说LangChain 的文档和 API 变动相当快版本升级时经常会遇到接口改名的情况。我维护的两个项目中一个停在 0.2.x另一个升级到 0.3.x 时花了一天时间修兼容性。所以如果你要用 LangChain 做长期项目建议锁版本别追新。3.2 Dify让你一周搭出 Agent 应用的低代码平台Dify 是低代码派的代表它把 Agent 工作流变成了可视化拖拽。你在界面上放一个开始节点连一个大型语言模型节点再接一个工具节点再连到结束节点一个简单的 Agent 就出来了。Dify 自带记忆、知识库、RAG、工具插件市场甚至支持多租户、API 发布像一个专门为 Agent 场景定制的中台系统。Dify 最适合什么人我认为最适合业务人员、产品经理以及想快速验证 Agent 想法的个人开发者。让我自己做内部的小工具比如给客服团队生成回复建议“自动整理工单摘要”我首选就是 Dify因为它前后端都给你弄好了我只需要写几个工具函数、配置模型 API Key 就行。但 Dify 也有明显短板一是它的编排灵活性是有限的如果你要处理特别复杂的条件分支、循环嵌套、人工审批流程你会发现被平台的边界卡住二是自托管部署相对吃资源Docker 全家桶跑起来内存轻轻松松占掉 2-3 GB。3.3 CrewAI把一群 Agent 组织成团队CrewAI 走的是多 Agent 协作路线它的核心概念是角色扮演你可以定义角色、任务、团队流程然后让多个 Agent 像在一个公司里一样协作。比如定义一个产品经理 Agent负责收集需求和拆解任务定义一个工程师 Agent负责写代码定义一个测试工程师 Agent负责审查代码。几个 Agent 之间通过任务传递关系来协作你可以设置顺序执行或者并行执行。这种设计的体验非常直观因为它是贴合组织分工来建模的。但它也有天花板多 Agent 之间的上下文传递会产生大量的 Token 开销而且系统一旦出错定位问题的复杂度会直线上升——到底是哪个 Agent 的决策错了、哪一步的工具调用失败了排查链路比单 Agent 系统长得多。所以我的建议是如果你的任务可以由一个 Agent 若干工具完成绝对不要为了炫技而上多个 Agent。多 Agent 不是银弹它只适合任务天然需要多个角色分工的场景。3.4 新兴工具与 Harness 概念Agent 的应用外壳除了上面三个大框架这两年还冒出不少新东西比如以 Hermes Agent、Claude Agent Skills 为代表的一批轻量级 Agent 外壳。先说 Agent Harness 这个概念。Harness 原意是马的挽具在 Agent 领域它指的是给大模型套上一层工程化约束的脚手架。Singularity 那篇文章里把 Harness 定义为 Agent 外面那层包含控制逻辑、工具调用循环、约束规则、日志审计的壳。说白了大模型本身是大脑Agent Harness 就是大脑外面那一整套让大脑真正安全落地干活的装置。这个概念最大的价值是提醒我们把注意力从模型多聪明转移到工程系统多可靠上后者才是 Agent 能进入生产环境的决定性因素。再比如 Hermes Agent 这类项目主打的是本地化、可插拔、轻量。我在 Windows 环境里折腾过它的本地安装包它跟 Dify 这种全家桶不一样更像是一个可嵌入的 Agent 运行环境。你可以把它理解成给有经验的开发者提供的 Agent 框架适合在已有代码工程里嵌入智能体能力。Claude Agent Skills 则是从模型厂商的视角来做能力封装你把某项专业技能比如处理 PDF、操作 Excel、执行特定领域的数据分析封装成一个 Skill模型在需要的时候自动加载对应的 Skill 提示词和工具集。这个思路和 Function Calling 的差别在于Function Calling 是框架显式调用工具Skill 是模型根据任务需求自动发现并加载专业能力更像给 Agent 配了一背包的专业工具包。如果让我给一个选型结论我大概会这么说想快速试错、搭个演示Dify想做一个复杂的生产级系统追求控制力LangGraph想让多个 Agent 协作、模拟团队分工CrewAI想嵌入现有工程灵活控制、本地化Hermes Agent 这类轻量框架想在某个专业领域内提高 Agent 的能力上限研究一下 Skill 机制4. 别让 Agent 失控安全边界、失败现场与调参实战所有概念聊完还是要回到落地。我见过太多 Agent 项目跑起来容易但真正上生产就崩的场景。这一章把我踩过的坑、常见的异常、以及安全管理经验全部整理出来。4.1 Agent 的失败现场为什么它总是莫名其妙地中止我先说一个和标题相关的实操教训。热搜词里有一条很典型的报错agent execution terminated due to error.。很多新手第一次遇到这个错误第一反应是模型能力不行换个更贵的模型结果依然报错。其实这个错误根本不是在模型层面而是在 Agent 执行循环里。我遇到过一次比较典型的场景当时给一个用户搭了自动化数据报表 Agent让它在每天凌晨跑一次结果它连跑了三天第三天凌晨突然执行中止而且不是模型返回错误是执行框架直接抛异常终止。我去翻日志发现问题出现在工具返回结果的上一步工具返回的 JSON 格式不符合模型输入的预期 schema框架在把工具输出转换成标准消息时直接抛了异常。这个排错过程我记得很清楚我拆成三步定位的确认异常发生在哪个环节。报错信息里带有环节名先区分是模型调用异常还是工具执行异常还是流程编排异常。如果是工具执行的异常去看工具的输入参数和返回结构。我在工具外面包了一层 try-except 和日志每次调用都会打印入参和返回摘要。如果是模型调用环节去看是不是 max_tokens 设得太小导致模型回复被截断。有些模型在 Response 被截断时不会输出 complete 标记。另一个排查经验是Agent 这类系统最怕的是循环空转。我见过一个 Agent 在调用某个工具时模型生成的参数总是缺一个字段工具一直报缺参模型就一直重试同一个工具重试了 20 次最终触发 max_iterations 限制中止。这类问题的根源往往不在模型而在工具描述写得不够清楚。后来我把工具的 JSON Schema 里每个字段都补上了类型说明、必填标记、默认值、示例值问题立刻缓解了大半。4.2 Token 失控与Agent 烧钱问题和 Agent 打交道有一个词绕不开Token。很多第一次接触 Agent 成本的人都吃过一个大亏跑一个看似简单的任务账单却高得离谱。原因很简单。Agent 不是一次模型调用就结束了它是一轮一轮的循环。每一轮循环都要把系统提示词、历史对话、工具描述、工具返回结果全部重新发送给模型。也就是说即使工具返回结果本身只有 100 个 Token但每循环一轮模型都要重新读取一遍前面所有内容。当你的 Agent 循环了 20 轮时它的 Token 消耗不是每轮相加而是每一轮都在重复读取全部上下文这叫做线性累积极其烧钱。我自己的经验是给 Agent 设置明确的 Token 控制机制通常有这几招控制工具返回的文本长度在工具函数内部对返回做摘要只把关键数据返回给模型。控制历史对话的循环次数最多保留最近 N 轮对话再早的压缩成摘要。设置最大迭代次数避免无限循环。在 Prompt 里明确要求模型只有在必要的时候才调用工具减少无效调用。如果你在做商业项目我强烈建议在模型调用层做一个 Token 监控中间件每次请求前记录预估 Token请求后记录实际消耗按月汇总。有了数字才不会让成本失控。4.3 Agent 的安全边界权限最小化是底线最后说一个最不该被忽略、却最容易被新手忽略的问题Agent 的安全。我经常看到新手拿一个 API Key 往环境变量里一存就开始让 Agent 调用文件系统、调用命令行、调用数据库。这在开发环境没问题但一旦上了生产环境如果 Agent 的权限没有收敛一个小小的问题就可能变成严重的事故。我的建议是几件事必须做到权限最小化。给 Agent 分配一个专用账号这个账号只拥有完成业务所需的权限绝不能直接给 root 或管理员权限。Agent 调用数据库也同理只给读写特定表的账号不能给整个库的管理员权限。工具白名单。能被 Agent 调用的工具必须在代码里显式注册不要让 Agent 有能力去执行任意 shell 命令或任意 Python 代码。数据脱敏。不要直接把含敏感信息的原始数据传给外部模型如果有条件在工具返回之前做字段脱敏处理。操作审计。所有工具调用的入参和返回都要留日志。对安全敏感的操作比如删除、修改配置等建议加人工确认环节。外部依赖的风险评估。很多 Agent 框架会从插件市场拉第三方工具这些工具如果不可信代码审查不严非常危险。第三方工作台和插件市场提供的工具必须先审代码跑在隔离环境里再接入到生产。我心里始终有一个底线原则Agent 可以替我干活但不能替我做决定。凡是涉及高风险、高成本、合规敏感的操作AGENT 再聪明我也只让它建议和草拟最终执行动作必须由人来审核确认。这不是保守这是在 Agent 能力逐渐变强的阶段唯一稳妥的工程态度。5. Agent 学习的几条路线建议与面试经验分享从零开始学 Agent 到能独立负责一个 Agent 项目到底该怎么走我根据自己的经验和对周围同事的观察梳理了一条相对高效的路。5.1 从手写一个最小的循环开始而不是直接上框架我的第一个建议可能会让很多人意外先别急着用 LangChain 或 Dify先亲手写一个最原始的 Agent 循环。你只需要一个支持 Function Calling 的模型 API然后自己实现拼接工具描述列表、把用户请求和工具描述发给模型、解析模型输出、执行工具、把结果拼回上下文、再发给模型。这个循环总共加起来不到一百行代码但写完这一百行你对 Agent 架构里的轮换上下文工具闭环会有非常直观的理解。我是在把 LangChain 源码里 AgentExecutor 的实现手抄一遍之后才真正弄懂 ReAct 是怎么回事。在那之前LangChain 对我来说就是一个黑盒。所以对新手我的建议是先用底层 API 把概念落地再用框架做工程提效。顺序反过来的话你即使会用框架也会在各种疑难问题面前丧失排查方向。5.2 面试题的背后考察的是什么现在很多公司在招聘 AI 相关岗位时都会问 Agent 的题目热搜词里也有一条叫agent 面试题“agent 八股文”。我聊一下我理解里这类面试题到底在考什么。一些基础题比如ReAct 是什么Function Calling 原理考察的是候选人有没有真的理解机制。这些光背答案没用几个追问就露馅了。比如面试官追问工具返回结果太长了怎么办你会明显感觉到背题的人和真正写过 Agent 的人回答完全两种模样。高级题往往会落到实践细节上比如你的 Agent 有一次无限循环了你怎么排查如果候选人能说出先看日志里最后一条工具调用是什么再结合实际案例说明说明他真实做过。你怎么控制 Agent 的成本这考察的就是 Token 控制和上下文管理经验线上项目做过的人至少能说出三四种方法。Agent 怎么保证安全这题能答好的人说明他认真考虑过 Agent 从 demo 变成生产系统的关键障碍。所以我的看法是面试题其实就是社会实践的浓缩。你与其去背一百个名词解释不如多花时间在真实项目里把 Agent 走通一遍解决了几个实际问题面试时自然有故事可讲。5.3 后续可以深入研究的方向Agent 的技术迭代非常快学习路径上也有一些进阶方向可以考虑深入底层协议与架构比如研究主流框架的源码理解 Agent 循环里的每一个细节如何被抽象管理。基于底层语言做极致优化最近 Rust 语言在 AI Agent 领域很受关注核心原因是 Rust 适合实现高性能、低延迟、内存安全的 Agent 运行时很多新兴框架都在向 Rust 方向靠拢。但 Rust 的学习门槛比较高不要盲目追热点根据自己的方向和项目需求来决定。Agent 记忆系统长期记忆是 Agent 能力的天花板之一研究记忆模型、摘要压缩、检索增强有很大的空间。评测与可观测性Agent 的效果评测、日志追踪、链路追踪是一个被大多数团队忽略却极有价值的领域。不管往哪个方向走都建议保持一个习惯亲手做一个端到端的项目。Agent 的理论看起来都很简单但只有当你亲手处理过一遍工具返回异常、上下文爆掉、Token 失控、安全问题之后你才会真正理解那些框架为什么那么设计、那些最佳实践为什么存在。这篇文章的核心思路很简单Agent 等于一个大模型大脑加一个工程化的执行身体。大脑负责思考、决策、生成身体负责记忆、工具调用、流程编排。理解了这个模型你再去看任何 Agent 框架它们的设计逻辑都逃不出这个框架。希望这篇整理能让你少走一些弯路也欢迎有实操经验的朋友一起来交流。
阅读完成 · 觉得有帮助？
