1. 为什么Agent开发需要框架？聊聊Agent开发的痛点
1.1 Agent到底在解决什么问题？
很多朋友第一次接触Agent时，会觉得“这不就是给大模型写个循环，让它自己调工具吗？”。没错，最原始的Agent确实可以这么玩，但真把它放到业务里，问题立刻不一样了。Agent不是单次问答，而是一个能够感知环境、自主决策、采取行动、持续迭代的闭环系统。它要解决的核心问题有三个：任务拆解、工具调用、状态维持。
任务拆解对应的是“用户说帮我查一下明天去上海的航班，再订一个离机场近的酒店”，这绝不是一次模型调用能完成的，而是需要把目标分解成若干子任务，每个子任务可能要调用不同的API，还要判断依赖顺序。工具调用对应的是“模型本身不会发请求，它得知道有哪些工具、参数怎么填、返回结果怎么解析”，这就是Function Calling和工具Schema要做的事。状态维持则更难，Agent多轮执行时，要记得自己已经做了什么、还剩什么没做、上下文里哪段信息是可信的。
框架的价值，就是把这三件事沉淀成可复用的组件和模式。你不用每次从零造轮子，也不需要重复踩那些“模型输出不稳定”“上下文爆炸”“日志丢失”的坑。但框架也不是越多越好，选型不对，框架反而会成为你最大的约束。所以这篇文章我想把常见框架梳理一遍，再把“怎么选”这件事讲透。
1.2 没有框架时你会遇到的若干困境
我自己最早就是徒手撸Agent的。当时接了一个内部问答助手的需求，用最朴素的ReAct循环：先定义工具列表，然后拼System Prompt，再把历史对话、工具返回一股脑塞给模型，让模型输出“下一步动作”。试运行两天后就崩了。
第一，模型输出格式不稳定。今天是标准JSON，明天就给你冒出一段Markdown，你得专门写一个“清洗器”来处理这些意外。第二，请求上下文越积越长，免费窗口很快就不够用，我必须自己实现截断和摘要，感觉不是在写业务，而是在给模型搬运上下文。第三，工具调用的日志全靠print，线上出了问题，根本没法回溯是哪一步选错了工具、传错了参数。
这些痛点我在用了框架之后才真正意识到：框架不是在旁边加一层漂亮外壳，而是在帮你处理那些“看似无聊但极其重要”的工程问题。好在市面上已经沉淀了多种成熟思路，下面我把这些框架按层次拆开来看。
2. 常见Agent框架全景：从“链式调用”到“多智能体协作”
2.1 框架的四个层次
现在市面上的Agent框架，我习惯把它们分成四层。
第一层是链式/工作流框架，代表是LangChain、LlamaIndex这类。核心思路是把“调用大模型”和“调用工具”编排成有向无环的链或图，每一步都是确定的，开发者手动写流程，什么时候调模型、什么时候查数据库，全部写死。适合那些流程固定、规则明确的场景，比如“先抽取关键词，再搜索，再生成摘要”。优点是可控、易调试、省token；缺点是灵活度有限，模型不是自主决策的。
第二层是自主Agent框架，代表是AutoGPT、BabyAGI，以及各家的Agent SDK。这类框架给模型一个“总目标”，让模型自己拆解子目标、自己选工具、自己判断是否完成。这相当于把指挥权交给模型，它需要循环很多轮。好处是能处理开放任务，坏处是结果不稳定、token消耗大、容易陷入死循环。现在做生产用，很少直接裸用AutoGPT模式，更多是借鉴它的任务规划思路。
第三层是角色化/多智能体框架，代表是CrewAI、MetaGPT、AutoGen。这类框架允许你定义多个不同角色，比如“产品经理”“程序员”“测试员”，每个角色本身是一个Agent，它们之间可以对话、协作、辩论，共同完成一个复杂任务。价值在于把大问题切分给多个上下文窗口，避免单个Agent上下文爆炸，适合模拟团队协作和复杂任务流。
第四层是企业级框架或低代码平台，它们更关注运维、权限、可观测性和与现有系统的集成。往往不需要写代码，而是通过配置文件或界面拖拽完成Agent搭建。这类选型很多是业务部门在做，但技术团队也必须理解底层架构，否则出了问题无从下手。
分层的好处是，你不会在一个工作流框架里苦苦寻找“自主决策”能力，也不会要求一个全自动Agent同时具备严格稳定。先判断自己需要哪个层次，再在具体框架里挑，思路会清晰很多。
2.2 典型框架逐个说
我按“实际落地使用”的频次来介绍。
LangChain，无论是原版还是面向Agent的LCEL语法，它的核心资产其实是那一大堆现成的Tool、Memory、Retriever适配器。你接向量库、接搜索API、接各种内部系统，都能找到集成方案。生态肥是它最大的优点，但正因如此，版本迭代也相当剧烈，老项目升个级往往要改一大片代码。我的体会是：如果你需要大量外部集成，LangChain值得用，但别追捧它的高级Agent特性，优先用其稳定成熟的功能就够了。
LlamaIndex则更聚焦于RAG场景，它对文档解析、索引结构、检索重排序的处理非常细腻。如果你做的是知识库问答Agent，LlamaIndex比LangChain更省心。它也有Agent和Workflow能力，但核心思维依然是“索引—检索—生成”。
AutoGPT是最早把“AI自主完成任务”这个概念打爆的项目。它的问题很明显：跑起来像一个黑盒，过程不可控，token消耗惊人。今天很少有人直接部署AutoGPT做产品，但它的“目标拆解—子任务执行—结果校验”的循环思想已经被吸收进很多框架。
Semantic Kernel（简称SK）诞生于微软体系，更多是面向.NET和企业环境的编排框架。它保留了链式步骤的确定性，又支持规划器。对已经重度使用微软技术栈的团队来说，SK可能是最平滑的选择。缺点在于社区规模相对小一些，中文资料也少。
CrewAI用角色协作理念，让你快速定义几个角色，每个角色有自己的工具集和目标，然后用任务串起来。上手非常快，写Python几乎像写口语。但多智能体并发时会有稳定性问题，需要自己做重试和超时控制。
MetaGPT走的是“软件公司”路线，它把大模型Agent编排成产品经理、架构师、开发者等角色，以标准化文档作为中间产物，比如需求文档、设计文档、代码等。对于生成复杂程序、模拟完整交付流程的探索很有启发，但真正用于生产代码仓库，还是需要大量人工review。
AutoGen是微软研究院的开源框架，主打对话式多Agent，一个Agent可以发起对话，另一个Agent作为执行者或评估者。它非常灵活，也因此学习成本高。另一个问题是这套机制建立在递归对话上，可观测性和调试是老大难，后面避坑部分我会详细说。
我没有提“哪个最好”，因为框架没有最好，只有“在当前团队、当前需求下最适合”。选型是一门权衡的艺术。
3. 选型决策：关键维度和判断清单
3.1 五个硬性维度
第一维度是可控性。你能不能允许Agent严格按业务流程执行？如果不能，那误操作发生时谁来兜底？面向用户的Agent，可控性优先级最高。链式框架可控性最高；自主Agent最低；多智能体居中，但可以通过角色限制提升一定可控性。
第二维度是调试与可观测性。用Agent最容易出现“你不知道它为什么这么想”的困境。框架是否输出完整Trace、是否支持中间步骤暂停、是否方便记录每次Prompt和工具返回，就变成生产级需求。很多自主Agent框架在这点上偏弱，日志稀碎，你根本定位不到问题。
第三维度是生态成熟度。包括文档质量、社区规模、第三方集成数量、已知坑的沉淀量。生态大不一定好，但至少你遇到问题时能搜到答案。我用一个简单标准：去搜框架的报错信息，头部框架可能上千条结果，小众框架可能只有个位数。搜索热度背后就是踩坑前辈的数量。
第四维度是成本与性能。Agent是多轮调用模型，每一轮都有token成本。自主Agent动辄几十次循环，费用可以很快烧穿预算。选型时要估算一次完整任务的token消耗上限，再来看框架的规划策略。比如某些框架支持“先规划再执行”，就可以显著减少循环次数。
第五维度是团队技术栈。框架本身的语言偏好，是否匹配团队主力语言？团队全是.NET，却硬推一个Python框架，光是部署、维护依赖就够喝一壶。反过来也一样。框架再优秀，团队成员不熟悉，最终还是会被束之高阁。
3.2 不同场景下的推荐组合
我按常见场景给出大致组合，不是唯一解，是我实测中比较省心的方向。
先说“企业知识库问答”。推荐LlamaIndex为主，配合少量链式工作流做权限控制和后处理。重点是RAG质量，而不是Agent自主性。知识库问答的流程相对固定：用户问题—检索—重排—生成。用LlamaIndex原生支持的索引和查询接口，比用LangChain更趁手。
再说“具备多个业务API的自动化助手”。比如内部工单系统、请假系统、库存系统，用户用自然语言操作这些系统。推荐用链式框架（LangChain或SK）来定义明确流程，配合Function Calling实现安全可控的调用。先做意图识别，再进入对应流程，每一步都是确定的，不要直接把所有工具丢给模型自主选。
接着是“开放式探索项目”，比如帮用户写小说或做竞品分析，过程很发散。这种情况可以用自主Agent或多智能体框架，CrewAI或AutoGen比较合适。但一定要加人工审批环节，比如Agent生成的最终结果需要用户确认，并且对中间步骤设定最大轮数，防止AIGC式跑飞。
最后说“高并发、低延迟、强稳定的线上服务”。这时候其实不太适合用完整的Agent框架，而是直接在轻量应用后端用Function Calling写一个有限状态机。框架提供的抽象反而会带来不必要的性能开销。选型时不要被“框架”两个字绑架，能够不用Agent框架解决问题，本身就是一种成熟的选择。
3.3 一个选型打分表
我在内部做选型时会用一个简单的打分表。维度权重不是固定不变的，但可以给你一个参考：可控性30%，调试能力20%，生态20%，成本15%，团队匹配15%。每一项按1到5打分，乘以权重加总。
比如要做基于.NET的自动化报表Agent。框架A是SK：可控性4，调试3，生态3，成本3，团队匹配5，总分=1.2+0.6+0.6+0.45+0.75=3.6。框架B是LangChain：可控性3，调试3，生态5，成本3，团队匹配2，总分=0.9+0.6+1.0+0.45+0.3=3.25。算下来SK胜出。
这个表的核心价值不是算出一个绝对分数，而是逼你把决策因素摊开，让团队在同一个标准下讨论，而不是拍脑袋说“我觉得这个好”。分数本身可以调整，但“不可控性”这种风险一旦爆出来，代价远比你省下的开发时间要高。
4. 实操对比：用三种思路实现同一个工具调用Agent
4.1 需求描述与统一测试目标
光谈概念太虚，我拿一个具体小需求来走一遍：用户输入“上海今天穿什么？”，Agent需要先识别城市，再查询该城市的实时天气，最后基于天气数据给出穿衣建议。这个需求很小，但已经包含意图识别、工具调用、多步依赖和最终生成四个典型环节。
我们分别用链式框架、自主Agent、多智能体框架三种思路来实现，对比它们在代码量、可控性、调试难度和扩展性上的差别。注意，以下代码是伪代码级别的示例，重点展示结构，不是某个框架当前版本的官方API。
4.2 基于链式框架的实现
链式思路的代码就是三步走：先抽取城市，再查天气，最后生成建议。每一步都是确定的，开发者完全掌控流程。
# 伪代码，展示链式编排思路 from langchain_core.prompts import ChatPromptTemplate extract_prompt = ChatPromptTemplate.from_template( "从用户的描述中提取城市，只输出城市名。用户输入：{input}" ) extract_chain = extract_prompt | llm def get_weather(city): city_code = weather_api.city_to_code(city) return weather_api.get_current(city_code) advice_prompt = ChatPromptTemplate.from_template( "根据城市{city}的天气{weather}，给出穿衣建议，50字以内。" ) advice_chain = advice_prompt | llm def full_pipeline(user_input): city = extract_chain.invoke({"input": user_input}).content.strip() weather = get_weather(city) advice = advice_chain.invoke({"city": city, "weather": weather}).content return advice这段代码的好处是“一眼能看到全貌”，哪里出错直接看是哪一步。坏处是，如果用户输入的是“上海明天和后天穿什么”，抽取链就不够用了，需要额外处理多城市、多日期的逻辑。链式适合确定路径，一旦需求变成开放式，代码会迅速膨胀。
4.3 基于自主Agent框架的实现
自主Agent的思路是为模型准备一个工具集，让它自己决定调哪个工具、按什么顺序调。下面是简化版的ReAct循环，也是很多自主Agent框架的内部原型。
# 伪代码，展示自主Agent循环思路 tools = { "get_weather": get_weather, "city_to_code": weather_api.city_to_code, } max_steps = 5 observed = [] def agent_loop(user_input): for step in range(max_steps): response = llm.invoke(build_react_prompt( user_input, tools, observed )) action = parse_action(response) # 解析JSON动作 if action["type"] == "finish": return extract_final(response) if action["name"] in tools: result = safe_call(tools[action["name"]], **action["args"]) observed.append({"action": action, "result": result}) else: observed.append({"action": action, "result": "错误：工具不存在"}) return "已达最大步数"这种实现把控制权交给了模型，理论上它能处理更多开放问题，比如“上海今天穿什么？明天呢？顺便告诉我适合跑步吗”。但代价是：需要处理输出格式解析、循环终止、非法工具调用、上下文长度管理。框架往往会帮你把这些细节封装好，比如LangChain的AgentExecutor或各家Agent SDK。可封装得越深，调试就越难。
4.4 基于多智能体框架的实现
多智能体思路则把任务拆给两个角色：一个负责查天气，一个负责给建议。每个Agent只关注自己的小目标，通过任务对象互相衔接。
# 伪代码，基于角色协作思路 from crewai import Agent, Task, Crew weather_agent = Agent( role="天气查询专员", goal="准确查询指定城市的天气数据", tools=[weather_tool, city_code_tool] ) advice_agent = Agent( role="穿衣顾问", goal="基于天气情况给出合理的穿衣建议" ) task = Task( description="查询{user_input}中提到的城市天气，并给出穿衣建议", expected_output="一句穿衣建议", agent=advice_agent ) crew = Crew( agents=[weather_agent, advice_agent], tasks=[task] ) result = crew.kickoff(inputs={"user_input": "上海今天穿什么？"})多智能体的优势是角色清晰，后续如果还想加入“运动建议Agent”“通勤建议Agent”，只需要加一个角色并挂到Task上就好。缺点是框架本身会引入较多抽象概念，团队需要理解任务分配机制和智能体间的通信方式。而且多个Agent都在调用大模型，成本和控制点都会增加。
4.5 三种实现方式的对比结论
从我的实践感受来说，这个“查天气穿衣服”的小需求，如果做内部工具，链式框架最稳，成本最低。如果做面向C端的高自由度助手，自主Agent体验更自然，但要加防跑飞机制。如果做的是需要持续扩展多个职能的办公助手，多智能体框架的模块化优势才会真正体现。
关键不是谁先进，而是你的需求边界在哪里。需求越封闭，越应该用链式；需求越开放，才越需要考虑自主Agent或多智能体。很多项目的失败，是把一个封闭需求硬写得特别开放，结果花了一半精力在“防止模型自作聪明”上。
5. 实战避坑：框架选型中最容易踩的五个坑
5.1 坑一：被“全自动”骗了，过度相信自主决策
我见过一个项目，直接上AutoGPT让Agent处理“自动整理销售数据并发送周报”。头一天运行得好好的，第二天Agent自己创建了十几个无用文件，还调用API给客户发了邮件。原因就是模型在循环中产生了误判，而系统里没有人工审批环节。
避坑的建议：凡是涉及对外发送、写入数据库、删除数据等高风险操作，一定要加入审批节点。就算你用的是自主Agent框架，也要把“高风险动作”踢出去走人工确认流。再智能的Agent，也只是把概率做到很高，永远不是100%。
5.2 坑二：版本升级犹如开盲盒
Agent框架的版本迭代速度非常快，尤其是头部框架，接口说改就改，老代码经常一夜之间不能跑。前一阵某开发者升级框架后，原来能正常工作的Agent突然报错，排查了半天才发现是工具定义语法变了，而不是业务逻辑出了问题。
避坑方法很简单：锁版本。在项目里使用固定版本，通过锁文件管理依赖，不要随手升级小版本。即便要升级，也要先在测试环境跑一遍全量回归，尤其是“Prompt模板+工具调用+输出解析”这条链路，最容易受版本影响。
5.3 坑三：调试黑盒化，出了问题无据可查
自主Agent和多智能体框架普遍存在可观测性不足的问题。你只知道最终输出错了，但不知道是模型决策错了，还是工具返回错了，还是上下文被污染了。没有中间日志的Agent等于一个黑盒，线上出现问题时只能靠猜。
我现在的一个习惯是：所有Agent项目，不管用什么框架，都会在关键节点记录结构化日志，包括完整Prompt、模型原始输出、解析后的动作、工具返回结果、每轮token消耗。这一步看起来笨重，但能救你无数次。很多框架也提供追踪能力，比如LangSmith、Langfuse这类工具，就算不用它们，也要自己用logging把关键信息存下来。
5.4 坑四：忽略token消耗和API限流
Agent的token消耗远比普通问答要高，因为它要做多轮推理、反复调用工具。实际项目里，一个看似很简单的任务，可能烧掉几千甚至上万token。如果用的是按量计费的模型，一个月下来账单会非常可观。
建议在框架层面就做预算控制：设定单次任务的最大模型调用次数、最大token数、超时时间。能用规则完成的步骤就不要让模型参与。比如校验用户输入格式、查询城市编码这类操作，直接写代码处理，既快又便宜，不要事事都去调大模型。
5.5 坑五：为了框架而框架，简单需求复杂化
有些团队选框架是为了“跟上技术潮流”，而不是因为业务需要。一个只需要从两个固定接口取数据并汇总的需求，硬塞进一套多智能体框架，弄出三四个Agent互相聊天，最后速度慢、成本高、还难维护。
我自己的判断标准是：如果业务逻辑能用不超过20行的普通代码实现，就不要引入框架。框架是用来处理复杂度的，不是用来制造复杂度的。你完全可以在项目里只用Function Calling或Prompt模板，后续复杂度真的上来了，再平滑迁移到框架。这种轻起步的方式，往往比一开始就重框架更靠谱。
5.6 我的个人选型心法
绕了一大圈，总结一下我个人实际团队里用的选型流程。第一步，把需求写成五种不同类型，标出哪些是确定性流程、哪些是开放探索、哪些涉及高风险动作。第二步，挑两到三个候选框架，分别写一个最小原型跑通端到端流程。第三步，用前面那个打分表做一次全员讨论，重点听开发和运维对“调试体验”和“部署复杂度”的感受。第四步，小范围灰度一段时间，记录真实任务的成功率、平均token消耗、平均耗时，再决定是否全面铺开。
这些年Agent框架迭代很快，但选型背后的逻辑其实很稳定：先可控，再智能；先能观测，再谈优化；先跑通业务，再追新概念。选型不是选一个“最好”的框架，而是选一个“你的团队能维护得住、你的业务能承受得起”的框架。真正做得好的Agent项目，框架往往藏在背后，业务价值站到了台前。这个思路，我觉得比任何框架本身都更值钱。
