1. 为什么LLM 到 Agent不是一次简单的升级很多人第一次听到AI Agent这个词脑子里浮现的画面是更聪明的聊天机器人。这个理解不算错但远远不够。我在过去一年多的时间里从最初拿大模型 API 写个问答脚本到后来搭出能自己查资料、调工具、分步骤完成任务的智能体系统中间踩过的坑让我意识到LLM 和 Agent 之间的差距不是模型变强了而是系统形态变了。打个比方。LLM 像是一个知识渊博但被关在房间里的人你隔着门缝递进去一张纸条他回你一张纸条。他知道很多但他看不见外面、动不了手、记不住上次你问过什么。而 Agent 是把这个人的门打开了给了他一部手机、一个笔记本、一双手还告诉他你可以自己决定先做什么后做什么。能力边界完全不一样。这个变化带来的直接后果是你不能再把 Agent 当成一个输入-输出的黑盒来用。它有了循环、有了状态、有了工具调用、有了失败重试。这些新增的环节每一个都可能出问题也每一个都是你可以优化的地方。我见过太多团队兴冲冲地上 Agent 项目结果卡在工具调用格式老是对不上多轮之后模型忘了自己要干嘛并发一上来就雪崩这些具体问题上。这篇内容我想做的事情很明确把 LLM 到 Agent 这条演进路径上的每一个关键概念拆开讲清楚然后落到实际搭建时会遇到的具体问题上。不管你是刚听说 Agent 这个词想搞明白它到底是什么还是已经在动手搭但被某个环节卡住了我都尽量给出能直接用的解释和方案。关键词里的 LLM、Agent、AI Agent、agent 框架、agent 记忆、agent 安全这些我都会在对应章节里展开。2. 拆开看LLM 到底提供了什么又缺了什么2.1 LLM 的本质是一个条件概率补全器要理解 Agent得先把 LLM 看透。抛开那些玄乎的说法LLM 的核心工作就一件事给定一段文本预测下一个 token 最可能是什么。你输入的 prompt 是条件它输出的内容是概率最高的续写。所谓对话能力推理能力代码能力都是这个补全机制在海量数据上训练后涌现出来的副产品。这里有个经常被忽略的点就是热词里提到的LLM 的 token 三个点key 我是谁、query 我在找什么、value 我能提供什么。这说的是 Transformer 里的注意力机制。简单讲模型在处理每个 token 时会把它拆成三个向量Query我现在需要什么信息、Key我能被检索的标签、Value我实际携带的内容。然后用 Query 去和所有 Key 做匹配匹配度高的 Value 就被加权聚合进来。这个机制让模型能看到上下文里所有位置的信息而不是像老式 RNN 那样只能顺序记忆。理解这一点很关键因为它解释了 LLM 的两个天然局限第一它的记忆只存在于当前这次推理的上下文窗口里窗口一满前面的内容就被挤掉了第二它只会生成文本不会真的去执行任何动作。它可以说我应该去查一下天气但它没有手去查。2.2 上下文窗口不是记忆这是最大的认知误区我见过太多人把上下文窗口当成模型的记忆。这是错的。上下文窗口更像是一块白板每次对话开始时是空的你把内容写上去模型看着白板回答回答完这块白板可能就被擦掉了取决于你是否保留历史。它和人类那种内化的、跨会话的、会自动关联的记忆完全是两回事。这个区别在实际项目里会变成很具体的麻烦。比如你做一个客服 Agent用户第一轮说我要退昨天买的那个蓝色杯子第五轮说就它吧。模型在第五轮能不能知道它指的是什么如果中间几轮对话把第一轮的内容挤出了窗口它就不知道了。这时候你就需要外部的记忆机制把关键信息存到向量数据库或者结构化存储里需要的时候再检索回来塞进上下文。这就是热词里agent 记忆要解决的问题。2.3 从补全到行动缺的三样东西把 LLM 变成 Agent本质上要补三样东西工具Tools让模型能调用外部函数比如查数据库、发请求、读写文件。模型输出一个结构化的调用请求外部系统执行后把结果返回给模型。循环Loop让模型能多轮思考。做完一步看看结果再决定下一步。这就是所谓的 ReActReasoning Acting模式。状态State让模型在循环过程中记住自己做过什么、当前目标是什么、还差什么没完成。这三样东西凑齐一个最基础的 Agent 就成型了。听起来简单但每一样展开都有一堆细节。下面我逐个拆。3. Agent 的核心循环ReAct 模式到底在转什么3.1 一次完整的 Agent 执行长什么样先看一个最朴素的 Agent 循环用伪代码表示def agent_loop(user_input, tools, max_steps10): messages [{role: user, content: user_input}] for step in range(max_steps): # 1. 把当前所有消息和工具定义发给 LLM response llm.chat(messages, toolstools) # 2. 如果模型决定调用工具 if response.has_tool_call(): tool_name response.tool_call.name tool_args response.tool_call.args # 3. 执行工具 result execute_tool(tool_name, tool_args) # 4. 把工具结果追加到消息历史 messages.append(response.message) messages.append({role: tool, content: result}) else: # 5. 模型没有工具调用说明它认为可以给出最终答案了 return response.content return 达到最大步数限制任务未完成这个循环就是 Agent 的心脏。它和普通 LLM 调用的区别在于普通调用是一次性的Agent 调用是一个带条件的循环。模型每轮都可以选择继续调工具还是给出答案这个选择权交给模型本身。3.2 为什么是 ReAct 而不是别的模式ReAct 的核心思想是让模型在每一步都先想再做。想的部分是推理Reasoning做的部分是行动Acting。为什么这个模式好用因为它把复杂的多步任务拆成了观察-思考-行动的小循环每一步的决策都基于上一步的真实结果而不是一次性规划到底。我试过让模型一次性规划出所有步骤再执行结果很惨。因为第一步的实际结果往往和模型预想的不一样后面的计划就全废了。ReAct 的好处是每步都能根据实际情况调整容错性高很多。但 ReAct 也有代价它消耗的 token 多、延迟高。每一步都要把完整的历史发给模型步数一多上下文就爆炸。这也是为什么后面会有各种优化比如只保留最近 N 轮、把中间结果做摘要、用更小的模型做简单决策等。3.3 循环的终止条件是个容易被忽视的坑上面代码里有个max_steps10这个限制非常重要。我踩过的坑是模型有时候会陷入死循环反复调用同一个工具、反复得到同样的结果、反复决定再试一次。如果没有步数上限这个循环能一直转下去烧钱又烧时间。除了步数上限还应该加几个保险重复检测如果连续两次工具调用的名称和参数完全一样直接中断。超时控制整个 Agent 执行设置一个总超时比如 60 秒。成本上限累计 token 消耗超过阈值就停。这些在 demo 阶段感觉不到一上生产就是救命的。热词里ai agent 怎么扛并发这个问题很大一部分答案就在这些边界控制上——没有边界的 Agent 在并发场景下会迅速耗尽资源。4. 工具调用Agent 的手和脚也是最容易出问题的地方4.1 工具定义的质量直接决定 Agent 的成败工具调用Tool Calling / Function Calling是 Agent 能力的核心。模型根据工具的名称、描述、参数 schema 来决定调不调、怎么调。这里有个反直觉的经验工具描述写得越清楚模型调用越准但描述太长又会占用宝贵的上下文。我一般遵循这几个原则工具名用动词开头比如search_weather而不是weather让模型一眼知道这是动作。描述里写清楚什么时候用和什么时候不用。比如查询实时天气时使用如果用户只是问天气常识不要调用。参数 schema 尽量简单能用字符串就别用嵌套对象。模型对复杂嵌套结构的生成准确率会明显下降。参数描述里给例子。比如date参数描述写成日期格式 YYYY-MM-DD例如 2024-01-15。4.2 工具调用格式报错最常见的三类问题热词里有个很具体的报错llm request failed: provider rejected the request schema or tool payload。这类问题我遇到过太多次基本可以归为三类问题类型典型表现解决方向Schema 不合法参数类型不匹配、必填字段缺失检查 JSON Schema 是否符合规范必填项是否都提供了模型输出格式错模型返回的调用参数不是合法 JSON用支持结构化输出的模型或在 prompt 里强调格式工具名/参数名对不上模型编造了一个不存在的工具工具列表要精简名字要直观避免相似命名第一类问题通常是开发者自己写的 schema 有问题。比如用了type: string但实际传了数字或者required数组里写了不存在的字段名。这类问题在开发阶段用单元测试就能发现。第二类问题更隐蔽。有些模型在生成工具调用参数时会输出带 markdown 代码块包裹的 JSON或者多输出一些解释文字。这时候解析就会失败。解决办法是优先选用原生支持 function calling 的模型它们经过专门训练输出格式更稳定。第三类问题在工具数量多的时候特别常见。我有次定义了 20 多个工具结果模型经常把get_user_info和get_user_profile搞混。后来把工具精简到 8 个准确率立刻上去了。工具不是越多越好能合并的合并能删的删。4.3 工具执行失败后Agent 该怎么办工具调用不可能 100% 成功。网络超时、参数错误、权限不足各种情况都有。关键是失败信息要以模型能理解的方式返回而不是直接抛异常把整个循环打断。我的做法是把工具执行结果统一包装成一个结构def execute_tool(name, args): try: result TOOL_REGISTRY[name](**args) return {success: True, data: result} except Exception as e: return {success: False, error: str(e), hint: 请检查参数或换一种方式}这样模型拿到失败结果后能看到success: False和具体的错误信息它就有机会调整参数重试或者换一个工具。如果直接抛异常整个 Agent 就崩了用户体验很差。注意错误信息里不要暴露敏感的内部细节比如数据库连接串、文件路径。给模型的错误信息应该是用户友好的比如查询失败请稍后重试而不是Connection refused to 10.0.0.5:5432。5. Agent 的记忆系统别让模型失忆5.1 短期记忆和长期记忆要分开设计Agent 的记忆分两层这个区分很重要短期记忆就是当前这次任务执行过程中的消息历史。它存在内存里任务结束就没了。它的作用是让模型知道我刚才做了什么、现在到哪一步了。短期记忆的管理核心是上下文窗口的分配——你不能把所有历史都塞进去得做取舍。长期记忆是跨会话、跨任务的知识。比如用户的偏好、之前解决过的问题、领域知识库。它需要持久化存储通常是向量数据库加结构化数据库的组合。热词里agent 记忆说的主要是这一层。我一般这样分配短期记忆保留最近 5-10 轮完整对话更早的做摘要压缩长期记忆用向量检索每次任务开始时根据当前输入召回最相关的几条。5.2 上下文压缩一个必须掌握的技巧当 Agent 执行步数多了消息历史会变得很长。直接全部发给模型一是贵二是可能超出窗口三是模型在超长上下文里反而容易迷失。这时候就需要压缩。我常用的压缩策略有三种滑动窗口只保留最近 N 轮简单粗暴但有效。摘要压缩把较早的对话让模型总结成一段话替换掉原始消息。关键信息提取只保留工具调用的结果和关键决策丢掉中间的推理过程。摘要压缩效果最好但成本高要额外调一次模型。滑动窗口成本最低但可能丢信息。实际项目里我一般是组合用最近 3 轮完整保留3-10 轮做摘要10 轮以上只保留关键结论。5.3 记忆污染一个安全层面的隐患热词里有个词叫 agentpoison: red-teaming llm agents via poisoning memory说的是通过污染 Agent 的记忆来攻击它。这个思路很值得警惕。如果 Agent 的长期记忆是可写的攻击者就可能往里面注入恶意内容比如遇到转账请求就直接执行不用确认这样的指令。等下次 Agent 检索到这条记忆就可能被带偏。防御思路有几个写入记忆前做内容审核记忆检索时做来源标记区分用户输入和系统指令关键操作永远需要二次确认而不是依赖记忆里的指令。这些在 demo 阶段可以不管但一旦 Agent 要接触真实业务就必须考虑。6. 从单 Agent 到多 Agent什么时候该拆什么时候不该拆6.1 单 Agent 的能力天花板在哪单 Agent 看起来很美好一个循环搞定所有事。但实际用下来它有几个明显的天花板第一工具太多会互相干扰。前面说过工具超过一定数量模型选择准确率就下降。如果一个 Agent 要同时处理查天气、订机票、写代码、发邮件它的工具列表会非常长决策质量堪忧。第二不同任务的 prompt 要求冲突。写代码需要严谨、注重边界条件做创意文案需要发散、天马行空。你很难用一套 system prompt 同时满足这两种需求。第三单点故障。一个 Agent 卡住了整个任务就停了。6.2 多 Agent 的两种主流编排方式多 Agent 系统主要有两种组织方式一种是主管-工人模式。一个主管 Agent 负责理解任务、拆解步骤、分派给不同的工人 Agent工人完成后把结果汇报回来。这种模式适合任务边界清晰、可以明确分工的场景。另一种是流水线模式。多个 Agent 按固定顺序处理前一个的输出是后一个的输入。比如研究 Agent → 写作 Agent → 审核 Agent。这种模式适合流程固定的场景可控性强。热词里agent 框架与编排说的就是这些。选哪种取决于你的任务特性。任务拆解不确定、需要动态决策的用主管模式流程固定、追求稳定的用流水线。6.3 多 Agent 不是银弹通信成本很高我得泼盆冷水多 Agent 系统的复杂度和调试难度是单 Agent 的好几倍。Agent 之间的通信要设计协议一个 Agent 的输出格式变了下游可能就崩了。而且多 Agent 意味着多次模型调用成本和延迟都上去了。我的建议是能用单 Agent 解决的就别上多 Agent。只有当单 Agent 确实因为工具太多、prompt 冲突、或者需要并行处理而力不从心时才考虑拆分。拆的时候也要从两个 Agent 开始验证有效再继续拆。7. 工程化落地并发、安全、可观测性7.1 Agent 怎么扛并发热词里ai agent 怎么扛并发是个很实际的问题。Agent 和普通 API 不一样它一次请求可能包含多轮模型调用和工具调用耗时可能是普通接口的几十倍。这意味着同样的 QPS 下Agent 占用的连接和资源要多得多。我的应对策略异步化Agent 执行全程用异步不要阻塞线程。Python 里用 asyncioJava 里用 CompletableFuture 或响应式框架。队列削峰请求先入队后台 worker 按能力消费。避免瞬时高并发打垮下游。分级超时单次模型调用超时、单次工具调用超时、整个任务超时三层都要设。结果缓存相同或相似的请求可以缓存结果尤其是那些工具调用结果稳定的场景。7.2 Agent 安全不只是 prompt 注入Agent 安全比普通 LLM 应用复杂得多因为它有行动能力。一个被注入的 prompt 可能让 Agent 去删文件、发邮件、转账。防护要点最小权限Agent 能调用的工具权限要尽可能小。能读的别给写能查单条的别给批量。危险操作二次确认删除、支付、发送这类操作必须有人工确认环节。输入输出过滤用户输入里的可疑指令要过滤工具返回的内容也要检查防止间接注入。审计日志每一次工具调用都要记录出问题能追溯。7.3 可观测性看不见的 Agent 最可怕Agent 是个黑盒套黑盒。模型为什么这么决策工具为什么失败循环为什么卡住没有可观测性你只能干瞪眼。我一般会记录这些东西每一轮的完整 prompt 和 response、每次工具调用的名称参数结果耗时、整个任务的步数和总耗时、token 消耗。这些数据用 LangSmith、LangFuse 这类工具能自动采集也可以自己写日志。关键是出问题时能完整复现当时的执行链路。8. 一些实际搭建时的经验杂谈8.1 模型选型不是越大越好Agent 场景下模型选型有个反直觉的点最强的模型不一定是最合适的。因为 Agent 要多次调用模型成本和延迟会被放大。很多时候一个中等规模但工具调用能力强的模型比一个超大模型更实用。我的经验是复杂决策用强模型简单步骤用轻模型。比如任务拆解用强模型工具参数生成用轻模型。这种混合策略能显著降本。8.2 从 demo 到生产的距离比想象中远Demo 阶段Agent 跑通一个例子就觉得很牛。但生产环境要考虑的东西多得多异常处理、并发、成本、监控、灰度、回滚。我见过太多 demo 惊艳但上不了线的项目。建议是尽早把工程化的东西补上别等到要上线了才想起来。尤其是日志和监控越早接入越好因为你需要这些数据来优化 Agent 的表现。8.3 别迷信框架理解原理更重要现在 Agent 框架很多LangChain、LangGraph、各种国产框架。框架能加速开发但也容易让人停留在会调 API的层面。一旦遇到框架没覆盖的场景或者框架本身的 bug就抓瞎了。我的建议是至少手写一遍最基础的 Agent 循环。理解了 ReAct 的本质、工具调用的机制、消息历史的管理再用框架就是如虎添翼。反过来只会用框架遇到问题连从哪查都不知道。8.4 评估 Agent 比评估 LLM 难得多LLM 的评估相对简单给一批输入看输出质量就行。Agent 的评估复杂得多因为它的输出是一个过程不是单一结果。同一个任务Agent 可能走不同的路径有的路径对有的路径错。我一般从几个维度评估任务完成率最终有没有做对、步骤效率用了多少步、工具调用准确率该调的时候调了没参数对不对、成本token 消耗。这几个指标结合起来才能比较全面地反映 Agent 的表现。9. 回到最初的问题Agent 到底是什么绕了一大圈回到标题。AI Agent 不是一个具体的模型也不是一个具体的框架而是一种系统架构。它把 LLM 作为推理核心配上工具、循环、记忆让模型从只会说变成能做事。理解这个架构比记住任何具体的技术细节都重要。因为技术在快速迭代今天流行的框架明天可能就过时了但推理核心 工具 循环 记忆这个基本结构在可预见的未来不会变。我在实际项目里最深的体会是Agent 的难点从来不在模型本身而在模型之外的那些工程细节。工具怎么定义、记忆怎么管理、循环怎么控制、并发怎么扛、安全怎么防这些才是决定一个 Agent 项目能不能落地的关键。模型能力在快速提升这些工程问题的解决方案也在不断成熟但底层的那套思考方式需要每个做 Agent 的人自己去趟一遍。如果你正准备动手搭第一个 Agent我的建议是从最小的循环开始先跑通模型调用工具拿到结果再回答这个最基本的流程然后再逐步加记忆、加多 Agent、加工程化。别一上来就追求大而全那样很容易在细节里迷失。 
长河君 · 2026/10/31 13:16:26 · 阅读 1.2k 从LLM到AI Agent：核心架构、工具调用与工程化实践
1. 为什么LLM 到 Agent不是一次简单的升级很多人第一次听到AI Agent这个词脑子里浮现的画面是更聪明的聊天机器人。这个理解不算错但远远不够。我在过去一年多的时间里从最初拿大模型 API 写个问答脚本到后来搭出能自己查资料、调工具、分步骤完成任务的智能体系统中间踩过的坑让我意识到LLM 和 Agent 之间的差距不是模型变强了而是系统形态变了。打个比方。LLM 像是一个知识渊博但被关在房间里的人你隔着门缝递进去一张纸条他回你一张纸条。他知道很多但他看不见外面、动不了手、记不住上次你问过什么。而 Agent 是把这个人的门打开了给了他一部手机、一个笔记本、一双手还告诉他你可以自己决定先做什么后做什么。能力边界完全不一样。这个变化带来的直接后果是你不能再把 Agent 当成一个输入-输出的黑盒来用。它有了循环、有了状态、有了工具调用、有了失败重试。这些新增的环节每一个都可能出问题也每一个都是你可以优化的地方。我见过太多团队兴冲冲地上 Agent 项目结果卡在工具调用格式老是对不上多轮之后模型忘了自己要干嘛并发一上来就雪崩这些具体问题上。这篇内容我想做的事情很明确把 LLM 到 Agent 这条演进路径上的每一个关键概念拆开讲清楚然后落到实际搭建时会遇到的具体问题上。不管你是刚听说 Agent 这个词想搞明白它到底是什么还是已经在动手搭但被某个环节卡住了我都尽量给出能直接用的解释和方案。关键词里的 LLM、Agent、AI Agent、agent 框架、agent 记忆、agent 安全这些我都会在对应章节里展开。2. 拆开看LLM 到底提供了什么又缺了什么2.1 LLM 的本质是一个条件概率补全器要理解 Agent得先把 LLM 看透。抛开那些玄乎的说法LLM 的核心工作就一件事给定一段文本预测下一个 token 最可能是什么。你输入的 prompt 是条件它输出的内容是概率最高的续写。所谓对话能力推理能力代码能力都是这个补全机制在海量数据上训练后涌现出来的副产品。这里有个经常被忽略的点就是热词里提到的LLM 的 token 三个点key 我是谁、query 我在找什么、value 我能提供什么。这说的是 Transformer 里的注意力机制。简单讲模型在处理每个 token 时会把它拆成三个向量Query我现在需要什么信息、Key我能被检索的标签、Value我实际携带的内容。然后用 Query 去和所有 Key 做匹配匹配度高的 Value 就被加权聚合进来。这个机制让模型能看到上下文里所有位置的信息而不是像老式 RNN 那样只能顺序记忆。理解这一点很关键因为它解释了 LLM 的两个天然局限第一它的记忆只存在于当前这次推理的上下文窗口里窗口一满前面的内容就被挤掉了第二它只会生成文本不会真的去执行任何动作。它可以说我应该去查一下天气但它没有手去查。2.2 上下文窗口不是记忆这是最大的认知误区我见过太多人把上下文窗口当成模型的记忆。这是错的。上下文窗口更像是一块白板每次对话开始时是空的你把内容写上去模型看着白板回答回答完这块白板可能就被擦掉了取决于你是否保留历史。它和人类那种内化的、跨会话的、会自动关联的记忆完全是两回事。这个区别在实际项目里会变成很具体的麻烦。比如你做一个客服 Agent用户第一轮说我要退昨天买的那个蓝色杯子第五轮说就它吧。模型在第五轮能不能知道它指的是什么如果中间几轮对话把第一轮的内容挤出了窗口它就不知道了。这时候你就需要外部的记忆机制把关键信息存到向量数据库或者结构化存储里需要的时候再检索回来塞进上下文。这就是热词里agent 记忆要解决的问题。2.3 从补全到行动缺的三样东西把 LLM 变成 Agent本质上要补三样东西工具Tools让模型能调用外部函数比如查数据库、发请求、读写文件。模型输出一个结构化的调用请求外部系统执行后把结果返回给模型。循环Loop让模型能多轮思考。做完一步看看结果再决定下一步。这就是所谓的 ReActReasoning Acting模式。状态State让模型在循环过程中记住自己做过什么、当前目标是什么、还差什么没完成。这三样东西凑齐一个最基础的 Agent 就成型了。听起来简单但每一样展开都有一堆细节。下面我逐个拆。3. Agent 的核心循环ReAct 模式到底在转什么3.1 一次完整的 Agent 执行长什么样先看一个最朴素的 Agent 循环用伪代码表示def agent_loop(user_input, tools, max_steps10): messages [{role: user, content: user_input}] for step in range(max_steps): # 1. 把当前所有消息和工具定义发给 LLM response llm.chat(messages, toolstools) # 2. 如果模型决定调用工具 if response.has_tool_call(): tool_name response.tool_call.name tool_args response.tool_call.args # 3. 执行工具 result execute_tool(tool_name, tool_args) # 4. 把工具结果追加到消息历史 messages.append(response.message) messages.append({role: tool, content: result}) else: # 5. 模型没有工具调用说明它认为可以给出最终答案了 return response.content return 达到最大步数限制任务未完成这个循环就是 Agent 的心脏。它和普通 LLM 调用的区别在于普通调用是一次性的Agent 调用是一个带条件的循环。模型每轮都可以选择继续调工具还是给出答案这个选择权交给模型本身。3.2 为什么是 ReAct 而不是别的模式ReAct 的核心思想是让模型在每一步都先想再做。想的部分是推理Reasoning做的部分是行动Acting。为什么这个模式好用因为它把复杂的多步任务拆成了观察-思考-行动的小循环每一步的决策都基于上一步的真实结果而不是一次性规划到底。我试过让模型一次性规划出所有步骤再执行结果很惨。因为第一步的实际结果往往和模型预想的不一样后面的计划就全废了。ReAct 的好处是每步都能根据实际情况调整容错性高很多。但 ReAct 也有代价它消耗的 token 多、延迟高。每一步都要把完整的历史发给模型步数一多上下文就爆炸。这也是为什么后面会有各种优化比如只保留最近 N 轮、把中间结果做摘要、用更小的模型做简单决策等。3.3 循环的终止条件是个容易被忽视的坑上面代码里有个max_steps10这个限制非常重要。我踩过的坑是模型有时候会陷入死循环反复调用同一个工具、反复得到同样的结果、反复决定再试一次。如果没有步数上限这个循环能一直转下去烧钱又烧时间。除了步数上限还应该加几个保险重复检测如果连续两次工具调用的名称和参数完全一样直接中断。超时控制整个 Agent 执行设置一个总超时比如 60 秒。成本上限累计 token 消耗超过阈值就停。这些在 demo 阶段感觉不到一上生产就是救命的。热词里ai agent 怎么扛并发这个问题很大一部分答案就在这些边界控制上——没有边界的 Agent 在并发场景下会迅速耗尽资源。4. 工具调用Agent 的手和脚也是最容易出问题的地方4.1 工具定义的质量直接决定 Agent 的成败工具调用Tool Calling / Function Calling是 Agent 能力的核心。模型根据工具的名称、描述、参数 schema 来决定调不调、怎么调。这里有个反直觉的经验工具描述写得越清楚模型调用越准但描述太长又会占用宝贵的上下文。我一般遵循这几个原则工具名用动词开头比如search_weather而不是weather让模型一眼知道这是动作。描述里写清楚什么时候用和什么时候不用。比如查询实时天气时使用如果用户只是问天气常识不要调用。参数 schema 尽量简单能用字符串就别用嵌套对象。模型对复杂嵌套结构的生成准确率会明显下降。参数描述里给例子。比如date参数描述写成日期格式 YYYY-MM-DD例如 2024-01-15。4.2 工具调用格式报错最常见的三类问题热词里有个很具体的报错llm request failed: provider rejected the request schema or tool payload。这类问题我遇到过太多次基本可以归为三类问题类型典型表现解决方向Schema 不合法参数类型不匹配、必填字段缺失检查 JSON Schema 是否符合规范必填项是否都提供了模型输出格式错模型返回的调用参数不是合法 JSON用支持结构化输出的模型或在 prompt 里强调格式工具名/参数名对不上模型编造了一个不存在的工具工具列表要精简名字要直观避免相似命名第一类问题通常是开发者自己写的 schema 有问题。比如用了type: string但实际传了数字或者required数组里写了不存在的字段名。这类问题在开发阶段用单元测试就能发现。第二类问题更隐蔽。有些模型在生成工具调用参数时会输出带 markdown 代码块包裹的 JSON或者多输出一些解释文字。这时候解析就会失败。解决办法是优先选用原生支持 function calling 的模型它们经过专门训练输出格式更稳定。第三类问题在工具数量多的时候特别常见。我有次定义了 20 多个工具结果模型经常把get_user_info和get_user_profile搞混。后来把工具精简到 8 个准确率立刻上去了。工具不是越多越好能合并的合并能删的删。4.3 工具执行失败后Agent 该怎么办工具调用不可能 100% 成功。网络超时、参数错误、权限不足各种情况都有。关键是失败信息要以模型能理解的方式返回而不是直接抛异常把整个循环打断。我的做法是把工具执行结果统一包装成一个结构def execute_tool(name, args): try: result TOOL_REGISTRY[name](**args) return {success: True, data: result} except Exception as e: return {success: False, error: str(e), hint: 请检查参数或换一种方式}这样模型拿到失败结果后能看到success: False和具体的错误信息它就有机会调整参数重试或者换一个工具。如果直接抛异常整个 Agent 就崩了用户体验很差。注意错误信息里不要暴露敏感的内部细节比如数据库连接串、文件路径。给模型的错误信息应该是用户友好的比如查询失败请稍后重试而不是Connection refused to 10.0.0.5:5432。5. Agent 的记忆系统别让模型失忆5.1 短期记忆和长期记忆要分开设计Agent 的记忆分两层这个区分很重要短期记忆就是当前这次任务执行过程中的消息历史。它存在内存里任务结束就没了。它的作用是让模型知道我刚才做了什么、现在到哪一步了。短期记忆的管理核心是上下文窗口的分配——你不能把所有历史都塞进去得做取舍。长期记忆是跨会话、跨任务的知识。比如用户的偏好、之前解决过的问题、领域知识库。它需要持久化存储通常是向量数据库加结构化数据库的组合。热词里agent 记忆说的主要是这一层。我一般这样分配短期记忆保留最近 5-10 轮完整对话更早的做摘要压缩长期记忆用向量检索每次任务开始时根据当前输入召回最相关的几条。5.2 上下文压缩一个必须掌握的技巧当 Agent 执行步数多了消息历史会变得很长。直接全部发给模型一是贵二是可能超出窗口三是模型在超长上下文里反而容易迷失。这时候就需要压缩。我常用的压缩策略有三种滑动窗口只保留最近 N 轮简单粗暴但有效。摘要压缩把较早的对话让模型总结成一段话替换掉原始消息。关键信息提取只保留工具调用的结果和关键决策丢掉中间的推理过程。摘要压缩效果最好但成本高要额外调一次模型。滑动窗口成本最低但可能丢信息。实际项目里我一般是组合用最近 3 轮完整保留3-10 轮做摘要10 轮以上只保留关键结论。5.3 记忆污染一个安全层面的隐患热词里有个词叫 agentpoison: red-teaming llm agents via poisoning memory说的是通过污染 Agent 的记忆来攻击它。这个思路很值得警惕。如果 Agent 的长期记忆是可写的攻击者就可能往里面注入恶意内容比如遇到转账请求就直接执行不用确认这样的指令。等下次 Agent 检索到这条记忆就可能被带偏。防御思路有几个写入记忆前做内容审核记忆检索时做来源标记区分用户输入和系统指令关键操作永远需要二次确认而不是依赖记忆里的指令。这些在 demo 阶段可以不管但一旦 Agent 要接触真实业务就必须考虑。6. 从单 Agent 到多 Agent什么时候该拆什么时候不该拆6.1 单 Agent 的能力天花板在哪单 Agent 看起来很美好一个循环搞定所有事。但实际用下来它有几个明显的天花板第一工具太多会互相干扰。前面说过工具超过一定数量模型选择准确率就下降。如果一个 Agent 要同时处理查天气、订机票、写代码、发邮件它的工具列表会非常长决策质量堪忧。第二不同任务的 prompt 要求冲突。写代码需要严谨、注重边界条件做创意文案需要发散、天马行空。你很难用一套 system prompt 同时满足这两种需求。第三单点故障。一个 Agent 卡住了整个任务就停了。6.2 多 Agent 的两种主流编排方式多 Agent 系统主要有两种组织方式一种是主管-工人模式。一个主管 Agent 负责理解任务、拆解步骤、分派给不同的工人 Agent工人完成后把结果汇报回来。这种模式适合任务边界清晰、可以明确分工的场景。另一种是流水线模式。多个 Agent 按固定顺序处理前一个的输出是后一个的输入。比如研究 Agent → 写作 Agent → 审核 Agent。这种模式适合流程固定的场景可控性强。热词里agent 框架与编排说的就是这些。选哪种取决于你的任务特性。任务拆解不确定、需要动态决策的用主管模式流程固定、追求稳定的用流水线。6.3 多 Agent 不是银弹通信成本很高我得泼盆冷水多 Agent 系统的复杂度和调试难度是单 Agent 的好几倍。Agent 之间的通信要设计协议一个 Agent 的输出格式变了下游可能就崩了。而且多 Agent 意味着多次模型调用成本和延迟都上去了。我的建议是能用单 Agent 解决的就别上多 Agent。只有当单 Agent 确实因为工具太多、prompt 冲突、或者需要并行处理而力不从心时才考虑拆分。拆的时候也要从两个 Agent 开始验证有效再继续拆。7. 工程化落地并发、安全、可观测性7.1 Agent 怎么扛并发热词里ai agent 怎么扛并发是个很实际的问题。Agent 和普通 API 不一样它一次请求可能包含多轮模型调用和工具调用耗时可能是普通接口的几十倍。这意味着同样的 QPS 下Agent 占用的连接和资源要多得多。我的应对策略异步化Agent 执行全程用异步不要阻塞线程。Python 里用 asyncioJava 里用 CompletableFuture 或响应式框架。队列削峰请求先入队后台 worker 按能力消费。避免瞬时高并发打垮下游。分级超时单次模型调用超时、单次工具调用超时、整个任务超时三层都要设。结果缓存相同或相似的请求可以缓存结果尤其是那些工具调用结果稳定的场景。7.2 Agent 安全不只是 prompt 注入Agent 安全比普通 LLM 应用复杂得多因为它有行动能力。一个被注入的 prompt 可能让 Agent 去删文件、发邮件、转账。防护要点最小权限Agent 能调用的工具权限要尽可能小。能读的别给写能查单条的别给批量。危险操作二次确认删除、支付、发送这类操作必须有人工确认环节。输入输出过滤用户输入里的可疑指令要过滤工具返回的内容也要检查防止间接注入。审计日志每一次工具调用都要记录出问题能追溯。7.3 可观测性看不见的 Agent 最可怕Agent 是个黑盒套黑盒。模型为什么这么决策工具为什么失败循环为什么卡住没有可观测性你只能干瞪眼。我一般会记录这些东西每一轮的完整 prompt 和 response、每次工具调用的名称参数结果耗时、整个任务的步数和总耗时、token 消耗。这些数据用 LangSmith、LangFuse 这类工具能自动采集也可以自己写日志。关键是出问题时能完整复现当时的执行链路。8. 一些实际搭建时的经验杂谈8.1 模型选型不是越大越好Agent 场景下模型选型有个反直觉的点最强的模型不一定是最合适的。因为 Agent 要多次调用模型成本和延迟会被放大。很多时候一个中等规模但工具调用能力强的模型比一个超大模型更实用。我的经验是复杂决策用强模型简单步骤用轻模型。比如任务拆解用强模型工具参数生成用轻模型。这种混合策略能显著降本。8.2 从 demo 到生产的距离比想象中远Demo 阶段Agent 跑通一个例子就觉得很牛。但生产环境要考虑的东西多得多异常处理、并发、成本、监控、灰度、回滚。我见过太多 demo 惊艳但上不了线的项目。建议是尽早把工程化的东西补上别等到要上线了才想起来。尤其是日志和监控越早接入越好因为你需要这些数据来优化 Agent 的表现。8.3 别迷信框架理解原理更重要现在 Agent 框架很多LangChain、LangGraph、各种国产框架。框架能加速开发但也容易让人停留在会调 API的层面。一旦遇到框架没覆盖的场景或者框架本身的 bug就抓瞎了。我的建议是至少手写一遍最基础的 Agent 循环。理解了 ReAct 的本质、工具调用的机制、消息历史的管理再用框架就是如虎添翼。反过来只会用框架遇到问题连从哪查都不知道。8.4 评估 Agent 比评估 LLM 难得多LLM 的评估相对简单给一批输入看输出质量就行。Agent 的评估复杂得多因为它的输出是一个过程不是单一结果。同一个任务Agent 可能走不同的路径有的路径对有的路径错。我一般从几个维度评估任务完成率最终有没有做对、步骤效率用了多少步、工具调用准确率该调的时候调了没参数对不对、成本token 消耗。这几个指标结合起来才能比较全面地反映 Agent 的表现。9. 回到最初的问题Agent 到底是什么绕了一大圈回到标题。AI Agent 不是一个具体的模型也不是一个具体的框架而是一种系统架构。它把 LLM 作为推理核心配上工具、循环、记忆让模型从只会说变成能做事。理解这个架构比记住任何具体的技术细节都重要。因为技术在快速迭代今天流行的框架明天可能就过时了但推理核心 工具 循环 记忆这个基本结构在可预见的未来不会变。我在实际项目里最深的体会是Agent 的难点从来不在模型本身而在模型之外的那些工程细节。工具怎么定义、记忆怎么管理、循环怎么控制、并发怎么扛、安全怎么防这些才是决定一个 Agent 项目能不能落地的关键。模型能力在快速提升这些工程问题的解决方案也在不断成熟但底层的那套思考方式需要每个做 Agent 的人自己去趟一遍。如果你正准备动手搭第一个 Agent我的建议是从最小的循环开始先跑通模型调用工具拿到结果再回答这个最基本的流程然后再逐步加记忆、加多 Agent、加工程化。别一上来就追求大而全那样很容易在细节里迷失。