1. 项目概述从模型到智能体的认知跃迁最近和不少同行交流发现一个挺有意思的现象大家聊起大语言模型LLM时都能头头是道地讲几个模型名字、参数规模甚至微调技巧。但一旦话题转向“AI Agent”智能体讨论就变得有些模糊和发散。有人说Agent就是给LLM加个工具调用有人说它是个能自主完成任务的系统还有人说它就是个高级版的ChatGPT插件。这种认知上的割裂恰恰说明了我们正处在一个关键的技术拐点——从单纯研究“模型能力”到构建“智能系统”的工程化转型。这个项目标题“从LLM到Agent拆解AI大语言模型的基础工程概念全景图”精准地捕捉到了当前AI应用开发的核心脉络。它不是一个简单的技术教程而是一张旨在帮助开发者、产品经理乃至技术决策者系统化理解如何将原始的LLM能力通过一系列工程化手段组装成能够感知、规划、执行并完成复杂目标的“智能体”的认知地图。简单说LLM是“大脑”而Agent是拥有这个大脑并配备了感官、手脚和行动策略的“完整智能体”。理解从前者到后者的跨越意味着理解现代AI应用落地的整套工具箱和设计哲学。为什么这张“全景图”如此重要因为在实践中我见过太多团队直接拿着GPT的API就开始硬编码业务逻辑结果很快陷入提示词工程的黑洞或者构建出脆弱、低效且难以维护的“伪智能”流程。真正的Agent工程涉及规划、记忆、工具使用、多步推理、安全防护等一系列基础概念的组合与权衡。本篇文章我将结合自己在一线构建和部署Agent系统的经验为你逐一拆解这些核心工程概念梳理它们之间的关联并分享在具体落地时那些容易踩坑的细节。无论你是想入门Agent开发还是希望优化现有的AI应用架构这张“全景图”都能帮你建立起坚实、系统的认知框架避免在技术浪潮中迷失方向。2. 核心基石深入理解大语言模型LLM的工程本质在谈论Agent之前我们必须先回归本源重新审视作为核心引擎的LLM。很多开发者容易陷入一个误区将LLM视为一个“魔法黑盒”只需输入问题就能得到完美答案。但在工程实践中我们必须将其解构为一个具有特定能力、局限性和成本特征的“预测性文本服务”。这种视角的转变是构建稳健Agent系统的第一步。2.1 LLM的核心能力与固有局限LLM的核心能力源于其在海量文本数据上训练出的“下一个词预测”机制。这赋予了它几项对Agent构建至关重要的工程特性强大的上下文理解与生成能力LLM能够在一个会话窗口Context Window内维持对话历史、理解指令、并根据给定的信息生成连贯的文本。这是所有交互的基础。隐式的知识存储与推理模型参数中压缩了训练数据中的知识使其能够进行常识推理、逻辑推导和简单的计算尽管不精确。指令跟随与格式控制通过精心设计的提示Prompt可以引导LLM以特定的格式如JSON、代码、列表输出这对于与下游系统对接至关重要。然而其固有的局限性也同样明显并且直接影响了Agent的设计非实时性与静态知识模型的训练数据有截止日期无法知晓最新事件。这意味着Agent若需处理实时信息如股价、新闻必须为其配备信息检索工具。“幻觉”与事实性错误LLM会生成看似合理但完全错误的内容。在严肃的Agent应用中必须通过检索增强生成RAG、事实核查链或限制其自由发挥来 mitigating缓解此风险。有限的精确计算与逻辑能力虽然能进行简单算术但对于复杂、多步骤的精确计算或严谨的逻辑验证LLM并不可靠。必须将计算任务“卸载”给专用工具如计算器、代码解释器。上下文长度限制与成本虽然上下文窗口不断增大从4K到128K甚至更多但更长的上下文意味着更高的计算成本和延迟。如何精炼、摘要和管理对话历史是Agent内存设计的核心课题。输出的非确定性即使输入相同LLM的输出也可能有细微变化可通过设置temperature0来降低但无法完全消除。这要求Agent对模型的输出进行解析和验证时要有一定的容错性。实操心得不要试图用提示词工程去“硬刚”LLM的固有缺陷。比如试图通过长篇大论的提示词要求模型“绝对不要胡编乱造”效果往往有限。正确的工程思路是“扬长避短”用LLM做它擅长的理解、规划和生成而把它不擅长的精确操作、事实查询、长时记忆交给外部模块。这就是Agent架构设计的起点。2.2 LLM即服务供应商、接口与成本考量在工程层面我们很少直接部署和训练千亿参数的原生模型更多的是通过API调用云服务。这就引出了对LLM提供商Provider的选择问题它直接关系到Agent的性能、成本和稳定性。目前主流的LLM服务可分为几类通用巨头模型如OpenAI的GPT系列、Anthropic的Claude、Google的Gemini。它们通常能力最强、生态最完善但API成本较高且可能面临政策与访问稳定性风险。开源模型如Meta的Llama系列、Mistral AI的模型、国内的Qwen、Baichuan等。它们可以本地或私有化部署数据隐私性好长期成本可能更低但需要自备算力且工程化如部署、优化、服务化门槛较高。垂直领域或优化模型针对代码、数学、特定语言等进行优化的模型。选择时需要建立一个多维度的评估矩阵评估维度关键问题对Agent的影响能力在指令跟随、复杂推理、长上下文、工具调用等方面的表现如何决定了Agent核心“大脑”的智力上限和任务处理范围。成本按Token计费的价格输入/输出是否同价是否有批量折扣直接影响Agent的运营成本。一个频繁调用、上下文长的Agent成本可能非常惊人。速率限制每分钟/每秒的请求数RPM/RPS和Token数TPM/TPS限制是多少限制了Agent的并发处理能力和响应速度高负载场景下需要设计队列或降级策略。延迟API调用的平均响应时间P95/P99是多少影响用户体验对于需要实时交互的Agent如客服机器人至关重要。稳定性API的可用性SLA如何错误率如429限流、5xx错误高吗要求Agent必须具备错误重试、服务降级和优雅失败的能力。可控性是否支持调整temperature、top_p等参数是否提供logprobs用于输出置信度评估影响Agent输出的确定性和可调试性。踩坑记录我曾在一个项目初期仅使用单一GPT-4 API当用户量激增时频繁触发速率限制429错误导致整个Agent服务瘫痪。后来我们引入了负载均衡与降级策略设置一个模型优先级列表如首选GPT-4超时或限流时自动降级到Claude或本地部署的Llama并实现了请求队列和重试机制。这提醒我们将LLM视为一个可能失败的外部服务而非永不宕机的“神”是Agent鲁棒性设计的第一课。3. Agent架构全景核心组件与工作流解析当我们理解了LLM这个“引擎”的特性后就可以开始组装智能体了。一个典型的Agent远不止是“LLM 函数调用”。它是一个由多个协同工作的组件构成的系统。下图展示了其核心架构与工作流我们可以将其类比为一个高效的“个人助理”。这个助理的工作流程是循环的它先“思考”Planning当前要做什么然后根据需要“回忆”或“查找”信息Memory/Knowledge接着“使用工具”执行具体动作Tools最后“观察”结果并决定下一步Observation。整个循环由“决策中枢”Orchestrator来驱动和管理。3.1 规划与决策中枢Agent的“大脑皮层”这是Agent的指挥中心通常由一个或多个LLM调用驱动。它的核心职责是分解任务、制定计划、选择工具、并评估结果。根据复杂度不同规划可以分为几个层次简单任务规划对于“查一下北京明天天气然后推荐是否要带伞”这类简单任务一个设计良好的提示词如ReAct格式Thought, Action, Observation就足以让LLM规划出“调用天气API - 分析结果 - 生成建议”的步骤。复杂工作流规划对于“为我策划一个三天的上海旅游行程包括酒店、景点和餐厅预订”这类复杂任务需要更结构化的规划。这通常通过**任务分解Task Decomposition**来实现。LLM首先将大任务拆解成子任务如1. 确定景点清单 2. 查询酒店 3. 查询餐厅 4. 排路线 5. 模拟预订然后可能为每个子任务生成更详细的步骤或直接执行。关键工程概念思维链CoT与ReAct范式思维链通过让LLM在输出最终答案前先输出一系列的中间推理步骤“Let‘s think step by step”能显著提升其在复杂推理问题上的表现。在Agent中CoT被内化为其“内部思考”过程。ReAct将Reasoning和Acting结合是Agent最经典的规划范式。其输出格式通常为思考我需要先理解用户的问题。用户想找关于Agent的论文。 行动搜索工具关键词“Agent survey paper 2024” 观察[工具返回的论文列表] 思考根据观察这篇《A Survey on Large Language Model based Agents》看起来最相关。我需要获取其摘要。 行动获取论文详情工具论文IDxxx 观察[论文摘要内容] 思考现在我已经获得了相关信息可以总结给用户。 最终答案根据您的要求我找到一篇2024年关于LLM Agent的综述论文标题是...其摘要主要内容是...这种结构化的输出使得程序可以可靠地解析出“下一步该执行什么动作”从而驱动Agent运行。注意事项规划模块的提示词设计是成败关键。你需要明确告诉LLM可用的工具列表、每个工具的用途和输入格式、以及输出的格式规范。一个常见的技巧是提供少量示例Few-shot Examples让LLM通过示例学习如何正确地规划和调用工具。同时要为规划步骤设置最大迭代次数防止Agent陷入死循环。3.2 记忆模块Agent的“海马体与笔记本”记忆是Agent实现持续对话和长期学习的基础。根据信息的生命周期和用途Agent的记忆通常分为几种类型短期记忆/对话历史保存当前会话中用户与Agent的交互记录。这是最基本的记忆形式直接作为上下文提供给LLM使其能理解对话的来龙去脉。工程挑战在于如何高效管理有限的上下文窗口。常见策略包括滑动窗口只保留最近N轮对话。摘要压缩当对话历史过长时调用LLM对之前的对话进行摘要然后将摘要而非原始历史放入上下文。例如在对话进行10轮后可以将前8轮总结成一段话只保留最近2轮原始记录和摘要。关键信息提取从历史中提取出实体如人名、地点、任务参数并结构化存储在需要时注入上下文。长期记忆存储跨越多个会话的、关于用户或世界的持久化信息。这通常需要外部存储如数据库、向量数据库。用户画像存储用户的偏好、习惯、历史交互信息。知识库存储领域特定的知识通过检索增强生成RAG技术在需要时查询。经验缓存存储Agent成功解决过的问题及其方案未来遇到类似问题时可以直接参考或复用提升效率。工具记忆记录工具调用的历史、参数和结果。这对于调试、审计以及让Agent在后续步骤中引用之前的结果至关重要。向量数据库在记忆中的核心作用对于需要语义搜索的记忆如知识库、历史对话摘要向量数据库是核心组件。它将文本转换为高维向量嵌入并存储起来。当需要查询时将查询语句也转换为向量然后通过计算余弦相似度等方式快速找到最相关的记忆片段。例如用户问“我们上次聊到的那个AI绘画工具叫什么”Agent可以将此问题转换为向量并从长期记忆中检索出最相关的关于“AI绘画工具”的对话片段。3.3 工具使用Agent的“手与感官”工具是Agent与外部世界交互、弥补LLM自身不足的桥梁。一个工具本质上是一个函数Agent可以调用它来执行特定操作。工具的定义与注册一个工具通常包含以下元信息名称唯一标识符如get_weather。描述用自然语言清晰描述工具的功能和用途。这部分至关重要因为LLM主要依据描述来决定是否以及如何调用该工具。例如“获取指定城市的当前天气情况及未来几天的预报。”参数模式定义输入参数的JSON Schema包括参数名、类型、是否必需、描述等。例如{city: {type: string, description: 城市名称如‘北京’}}。执行函数实际的代码逻辑调用外部API或执行本地计算。在工程中我们需要一个工具注册表来管理所有可用工具并将其描述和模式注入到给LLM的提示词中。工具的类型信息获取工具搜索引擎、数据库查询、API调用天气、股票、航班。操作执行工具发送邮件、创建日历事件、控制智能家居、执行数据库写操作。计算与处理工具计算器、代码解释器如Python沙箱、数据格式转换器。感知工具图像识别、语音转文本、文档解析OCR。实操心得工具的设计要遵循“单一职责”和“原子性”原则。一个工具只做一件事并且做好。避免设计“瑞士军刀”式的复杂工具这会让LLM难以理解和正确调用。例如与其设计一个“处理用户请求”的巨型工具不如拆分成“查询用户信息”、“计算订单金额”、“更新库存状态”等多个小工具。同时务必为工具调用添加严格的权限验证和输入清洗防止Agent被恶意提示诱导执行危险操作如“删除数据库所有数据”。4. 主流Agent框架与开发实践理解了核心概念后如何快速搭建一个Agent幸运的是目前已有许多优秀的开源框架它们封装了上述的通用模式让开发者能更专注于业务逻辑。这里对比几个主流的框架。4.1 框架选型对比LangChain, LangGraph, LlamaIndex, Dify框架核心定位优势适用场景LangChain最早的LLM应用开发框架之一模块化设计生态丰富。组件丰富Models, Prompts, Chains, Agents, Memory社区活跃教程多。像一个“乐高工具箱”灵活度高。适合研究、原型验证和需要高度定制化Agent逻辑的场景。LangGraph基于LangChain用于构建有状态、多参与者的复杂工作流。引入了图Graph的概念可以清晰定义Agent、工具、条件分支之间的流转关系。支持循环、并行、持久化状态非常适合构建复杂的多步Agent。适合构建涉及多个决策点、循环审批、长流程自动化如客服工单处理、复杂数据分析流水线的Agent系统。LlamaIndex专注于数据连接与检索增强生成RAG。在文档加载、索引、检索方面非常强大提供了多种向量索引和检索器。与Agent结合时能极佳地处理需要深厚知识背景的任务。适合构建知识库问答、文档分析、基于私有数据的智能助手等场景。Dify, CrewAI等更高层次的AI应用平台或多Agent协作框架。Dify提供了可视化的工作流编排界面降低开发门槛。CrewAI专注于多Agent团队协作内置角色分工、任务分配等机制。Dify适合快速构建和部署端到端的AI应用包括Agent。CrewAI适合模拟销售团队、研究小组等需要多个Agent分工合作的场景。选择建议新手入门或快速原型可以从LangChain开始它的文档和例子最全。构建复杂、有状态的工作流LangGraph是目前最自然的选择它用图来管理控制流比单纯的链Chain更清晰。核心需求是知识库问答LlamaIndex是首选专注于RAG做得更深入。追求开发效率不想写太多代码可以评估Dify这类可视化平台。构建多Agent系统研究CrewAI或基于LangGraph自行编排多Agent交互。4.2 基于LangGraph构建一个旅行规划Agent让我们通过一个简化但完整的例子看看如何用LangGraph构建一个旅行规划Agent。这个Agent能理解用户需求自动调用工具搜索航班、酒店和景点并生成一份整合报告。第一步定义工具我们先定义三个简单的工具实际应用中会调用真实APIfrom langchain.tools import tool import json tool def search_flights(departure_city: str, arrival_city: str, date: str) - str: 根据出发城市、到达城市和日期搜索航班信息。 # 模拟API调用 results [ {airline: Airline A, flight_no: AA100, departure: 08:00, price: 1200}, {airline: Airline B, flight_no: BB200, departure: 14:00, price: 950}, ] return json.dumps(results) tool def search_hotels(city: str, check_in: str, check_out: str) - str: 根据城市和入住/退房日期搜索酒店信息。 results [ {name: Grand Hotel, price_per_night: 500, rating: 4.5}, {name: Cozy Inn, price_per_night: 300, rating: 4.0}, ] return json.dumps(results) tool def search_attractions(city: str) - str: 搜索城市的景点信息。 results [ {name: City Museum, type: Museum}, {name: Central Park, type: Park}, ] return json.dumps(results)第二步定义Agent状态在LangGraph中状态是一个字典在节点间传递。from typing import TypedDict, Annotated, List from langgraph.graph.message import add_messages import operator class AgentState(TypedDict): # 消息历史 messages: Annotated[List, add_messages] # 从用户输入中提取的旅行信息 trip_info: dict # 收集到的航班、酒店、景点数据 flight_results: list hotel_results: list attraction_results: list # 最终报告 final_report: str第三步创建图和节点我们将创建一个有四个节点的图1. 解析用户需求2. 并行搜索信息3. 生成报告4. 结束。from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI # 初始化LLM llm ChatOpenAI(modelgpt-4-turbo-preview) # 创建图构建器 workflow StateGraph(AgentState) # 节点1解析用户需求 def parse_request(state: AgentState): 从用户消息中提取结构化旅行信息。 user_message state[messages][-1].content # 获取最新用户消息 # 使用LLM提取信息这里简化实际可用Pydantic输出解析器 prompt f 请从以下用户请求中提取旅行信息 用户请求{user_message} 请以JSON格式返回包含字段departure_city, arrival_city, trip_date, check_in_date, check_out_date。 如果某些信息不明确请设为null。 response llm.invoke(prompt) # 解析response.content中的JSON此处省略解析代码 trip_info {departure_city: Beijing, arrival_city: Shanghai, ...} # 模拟解析结果 return {trip_info: trip_info} # 节点2并行搜索实际LangGraph中需用特殊节点处理并行此处简化示意 def search_data(state: AgentState): 调用三个工具搜索数据。 info state[trip_info] flights search_flights.invoke({departure_city: info[departure_city], arrival_city: info[arrival_city], date: info[trip_date]}) hotels search_hotels.invoke({city: info[arrival_city], check_in: info[check_in_date], check_out: info[check_out_date]}) attractions search_attractions.invoke({city: info[arrival_city]}) return { flight_results: json.loads(flights), hotel_results: json.loads(hotels), attraction_results: json.loads(attractions) } # 节点3生成报告 def generate_report(state: AgentState): 根据收集的数据生成旅行规划报告。 data { flights: state[flight_results], hotels: state[hotel_results], attractions: state[attraction_results] } prompt f 你是一个旅行规划助手。请根据以下收集到的信息为用户生成一份简洁友好的旅行规划摘要 {json.dumps(data, indent2)} report llm.invoke(prompt).content return {final_report: report, messages: [{role: assistant, content: report}]} # 添加节点到图 workflow.add_node(parse, parse_request) workflow.add_node(search, search_data) workflow.add_node(report, generate_report) # 设置边定义执行顺序 workflow.set_entry_point(parse) workflow.add_edge(parse, search) workflow.add_edge(search, report) workflow.add_edge(report, END) # 编译图 app workflow.compile()第四步运行Agent# 初始化输入状态 initial_state AgentState( messages[{role: user, content: 我想下周五从北京去上海住两晚帮我规划一下。}], trip_info{}, flight_results[], hotel_results[], attraction_results[], final_report ) # 执行图 final_state app.invoke(initial_state) print(final_state[final_report])这个例子展示了LangGraph如何通过定义状态和节点清晰地组织一个多步骤的Agent工作流。在实际项目中你还需要增加错误处理、条件分支例如如果没找到酒店该怎么办、以及更复杂的工具调用逻辑。5. Agent工程中的核心挑战与应对策略构建一个能演示的Agent原型相对容易但要打造一个能在生产环境中稳定、可靠、安全运行的Agent系统则会面临一系列严峻挑战。以下是几个最常见的“坑”及其应对策略。5.1 可靠性挑战处理LLM输出的不确定性LLM的输出是非确定性的即使temperature0也可能因为API的负载均衡等原因产生微小差异。这对于需要精确解析工具调用参数的Agent来说是致命的。问题场景你期望LLM输出{action: search, action_input: {query: LLM Agent survey}}但它可能输出{action: search, action_input: LLM Agent survey}缺少嵌套结构或者{action: search, query: LLM Agent survey}键名错误。解决方案强制结构化输出使用LLM提供的**函数调用Function Calling或JSON模式JSON Mode**功能。这是最推荐的方式。以OpenAI为例你可以明确定义工具的参数模式LLM会返回一个符合该模式的结构化JSON对象极大提高了可靠性。输出解析与重试如果无法使用结构化输出则必须编写健壮的输出解析器。使用Pydantic等库定义期望的数据模型然后结合重试机制当解析失败时将错误信息反馈给LLM要求它修正输出。通常设置2-3次重试。后置验证与清洗在将LLM的输出传递给工具之前进行数据验证和类型转换。例如确保日期字符串是合法格式数字在合理范围内。5.2 效率与成本挑战管理上下文与Token消耗Agent的每次思考、每次工具调用结果的整合都需要消耗Token。一个复杂的多轮对话Agent成本可能迅速攀升。优化策略上下文压缩与摘要如前所述对长篇的对话历史或工具返回结果进行摘要。例如一个网页搜索工具可能返回10KB的文本在放入上下文前先调用一个“摘要LLM”通常用小而快的模型将其压缩成200字的核心要点。分层记忆系统不要将所有记忆都塞进上下文。使用向量数据库存储长期记忆和知识只在需要时检索最相关的片段注入上下文。短期对话历史采用滑动窗口。模型分级调用并非所有步骤都需要最强大、最贵的模型。可以用小模型如GPT-3.5-Turbo处理简单的意图分类、信息提取只用大模型如GPT-4处理复杂的规划、推理和总结。这被称为LLM路由或级联。缓存对相同的用户查询或中间结果进行缓存。例如如果两个用户都问“北京天气”第一个查询的结果可以缓存一段时间直接用于回答第二个用户无需再次调用天气API和LLM。5.3 安全与合规挑战构建“安全护栏”一个不受控的Agent是危险的。它可能被用户诱导执行恶意操作“删除所有文件”也可能在输出中产生有害内容。安全防护措施工具权限控制为工具划分安全等级。例如“读取文件”是低风险工具“执行Shell命令”是高风险工具。在Agent调用高风险工具前引入人工审批环节或二次确认机制例如让LLM生成一个执行摘要由另一个验证模块或用户确认。输入/输出过滤在用户输入传递给LLM前进行敏感词过滤和恶意指令检测。在LLM输出返回给用户或传递给工具前同样进行内容安全审核。沙箱环境对于执行代码、访问文件系统的工具必须在严格的沙箱环境中运行限制其网络访问、文件系统权限和运行时间。监控与审计记录Agent所有的思考过程、工具调用和结果。这不仅是调试的需要也是事后审计和安全分析的关键。当出现问题时你可以完整回溯Agent的“决策链”。5.4 评估与测试挑战如何知道Agent“好不好”与传统软件不同Agent的行为是非确定性的其输出质量难以用简单的单元测试断言来判断。评估方法端到端评估设计一系列覆盖核心场景的测试用例输入-期望输出对。通过自动化脚本运行这些用例但评估标准不是精确匹配而是使用LLM作为评判员LLM-as-a-Judge。让一个强大的LLM如GPT-4根据任务目标对比Agent输出和期望输出给出评分和理由。组件隔离测试规划能力测试给定一个任务检查Agent生成的计划步骤是否合理、完整。工具选择测试给定一个用户请求和工具列表检查Agent是否选择了正确的工具。工具参数测试检查Agent为工具生成的输入参数是否正确。人工评估与红队测试定期进行人工测试让测试人员尝试“攻破”Agent诱导其产生错误或有害行为。收集这些案例用于迭代改进提示词和安全规则。6. 未来展望Agent工程的演进方向技术发展日新月异Agent领域更是如此。从当前的工程实践出发我们可以看到几个清晰的演进方向这些方向将决定下一代Agent系统的形态。1. 从单一Agent到多Agent协作系统当前的焦点多在单个Agent的能力上。未来复杂任务将由多个各司其职的Agent组成的“团队”协同完成。例如一个产品设计任务可能涉及产品经理Agent负责需求分析设计师Agent生成草图工程师Agent评估可行性文案Agent撰写描述。这些Agent之间需要通过高效的通信协议和协作机制如竞争、协商、投票来共同决策。框架如CrewAI正在探索这一范式。2. 更强的自主性与长期目标目前的Agent大多由用户查询触发完成即结束。未来的Agent将更具“主动性”和“长期性”。它们可以设定长期目标如“优化我的个人财务”并持续在后台运行自主监测信息如账单、市场动态在适当时机采取行动如提醒还款、建议投资调整。这需要更强大的记忆、事件驱动架构和长期规划能力。3. 多模态感知与行动当前的Agent主要以文本为交互媒介。随着多模态大模型如GPT-4V, Gemini的成熟Agent将能直接“看”和“听”。例如一个客服Agent可以接收用户发送的屏幕截图识别上面的错误信息一个家庭机器人Agent可以理解语音指令并分析摄像头画面来执行任务。这将极大扩展Agent的应用场景。4. 模型与工具的深度集成工具调用目前还是一个相对“外挂”的过程。未来LLM本身可能会更深度地与工具集成或者出现工具学习能力让Agent能快速理解新工具的使用方法甚至根据任务需求自行组合或创建简单工具。5. 专用化与小模型化虽然通用大模型能力强大但成本高、延迟大。对于特定垂直领域法律、医疗、金融将会出现更多使用高质量领域数据微调过的小模型。这些模型在特定任务上可以达到甚至超越通用大模型的效果同时成本更低、响应更快、数据更安全。Agent系统将学会根据任务动态选择最合适的模型形成“模型联邦”。在我个人看来Agent工程的核心正在从“如何让LLM调用工具”的技法层面上升到“如何设计一个可靠、高效、安全的智能系统”的架构层面。这意味着对开发者的要求也变了除了要懂提示词工程和API调用更要具备系统工程思维理解并发、容错、安全、成本优化等传统软件工程领域的知识。这场从LLM到Agent的旅程不仅是技术的升级更是我们构建AI应用范式的根本性转变。