我见过太多团队在自研 vs 框架这个问题上走弯路。有人花三个月学习框架最后发现业务场景根本用不上也有人坚持裸写等 Agent 数量增长到 5 个以上时编排层代码已经比业务逻辑还多。这篇文章不做框架推荐清单而提供一套工程决策指南什么时候该裸写什么时候该引入框架框架真正解决什么问题以及它会带来哪些长期成本。一、先搞清楚一个事实框架并非必需品一个能在生产环境跑的单 Agent核心代码通常不超过 50 行messages [{role: system, content: system_prompt}] ​ while step max_steps: response llm.chat(messages, toolstools) if response.stop_reason tool_use: results execute_tools(response.tool_calls) messages.extend(results) else: break这就是 Agent 的基本形态围绕 LLM、工具和上下文展开的工具调用循环。Claude Code、Cursor、echo-agent 这类产品的内核都可以看作这个模式的工程化变体LLM 读取上下文判断是否需要调用工具工具返回结果后再把结果写回上下文继续下一轮推理与行动。框架做的事情是在这个循环之上增加抽象层例如状态管理、流程编排、持久化、可观测性、人工介入、错误恢复等。真正需要判断的问题只有一个你的业务复杂度是否已经值得为这层抽象付出学习、调试、迁移和运行成本二、框架给你什么好处1. 编排复杂度的封装当你的流程变成分析 → 判断 → 分支 A / 分支 B → 人工审批 → 执行 → 验证 → 失败则回退这种结构时继续用 if/else 手写状态机很快会失控。第一版代码通常还能保持清晰真正的问题会出现在第三次、第五次需求变更之后新增一个分支、插入一个审批节点、修改失败回退策略、增加异常补偿逻辑原本直观的流程会逐渐散落到多个函数、多个文件和多个隐式状态里。LangGraph 的图模型让你用声明式方式表达复杂流程。节点代表动作边代表状态转移条件边表达分支checkpoint 负责恢复。相比手写状态机这种表达方式更容易阅读、测试和维护。2. 开箱即用的生产能力框架通常会提供一批生产环境常用能力持久化和断点恢复进程挂了可以从上次状态继续Tracing 和可观测性记录每一步输入输出、token 消耗、延迟人工介入节点高风险操作暂停等待人确认后继续错误重试和降级策略失败后重试、切换工具、进入备用路径这些能力自己写都能实现但每一项都意味着额外工程投入。真正麻烦的地方不只在写代码还在于处理边界情况流程跑到一半断电怎么办工具超时后状态如何回滚人工审批跨天后上下文如何恢复这些问题进入生产环境后都会变成真实成本。3. 团队协作的统一语言三个人同时开发 Agent 系统如果没有统一抽象很容易写出三种风格的编排逻辑。有人喜欢函数嵌套有人喜欢事件驱动有人喜欢状态字典加条件判断。短期看都能跑长期看会增加协作成本。框架强制了一套约定节点、边、状态、工具、checkpoint、trace。团队成员讨论问题时有了共同语言代码评审和问题定位都会更高效。坏处1. 抽象泄漏成本高框架的抽象在 80% 的场景下很优雅但生产环境的边界情况往往落在剩下的 20%。当你需要绕过框架做特殊处理时一个原本简单的问题可能已经被框架封装了三层。你需要理解框架的生命周期、状态序列化方式、回调机制、执行器调度逻辑和异常传播路径调试难度会明显上升。Agent 系统最怕黑盒。一旦 LLM 行为、工具返回、框架调度三者混在一起排查问题会非常痛苦。2. Token 开销不可忽视实测数据CrewAI 在简单单工具调用场景下token 消耗是等价裸写代码的 3 倍。框架需要注入角色描述、协调指令、格式约束、任务交接说明这些都会进入上下文最终转化成 token 成本。对 demo 来说这点开销通常可以接受对高频调用、低毛利、强成本敏感的生产系统来说这个开销会直接影响利润率。按 LLM 成本占 Agent 运营总支出 40-60% 计算框架带来的额外 token 消耗需要进入架构决策模型不能只看开发体验。3. 版本升级的被动性框架 breaking change 的节奏通常由框架方决定。LangGraph 从 0.x 到 1.0 的迁移、AutoGen 到 Microsoft Agent Framework 的合并都让依赖它们的团队付出了可观的迁移成本。你的业务逻辑没有变化但框架 API、执行模型、配置方式变了你就必须跟着调整。对于长期维护的生产系统框架依赖意味着你把一部分架构演进权交给了外部项目。选框架时必须考虑社区稳定性、版本策略、迁移成本和生态成熟度。4. 学习曲线侵蚀交付时间LangGraph 官方都承认需要 1-2 周才能上手。对于一个需要两周交付 MVP 的项目把一半时间花在学习框架上投入产出比显然不高。尤其在早期验证阶段最重要的事情通常是证明AI 能不能完成这个业务任务提前搭一个完备的编排系统反而会拖慢验证节奏。框架学习成本不仅体现在文档阅读上还体现在团队共同理解、代码风格统一、调试方式切换和上线流程适配上。三、主流框架怎么选2026 年的框架格局已经稳定逐渐从百花齐放进入各归其位的阶段框架核心隐喻生产验证适合场景LangGraph有向图状态机400 企业47M 月下载复杂流程、合规审计、长时间任务CrewAI团队角色分工44K starsFortune 500 探索快速原型、demo 演示、线性多角色任务OpenAI Agents SDK五原语极简模型19K stars1030 万月下载GPT 生态、语音 Agent、沙箱执行Google ADK层级 Agent 多模态17K stars50 A2A 伙伴GCP 团队、视频/音频/图像统一推理Microsoft Agent Framework图工作流 Azure 原生2026.4 GA.NET 团队、Azure 全家桶我的选型态度LangGraph 是不会错的选择原因不在于它覆盖所有场景而在于犯错成本最低。社区最大生态最完整天花板最高从简单流程到复杂工作流都能逐步演进。如果你不确定未来流程会不会变复杂LangGraph 至少给你保留了向上扩展的空间。它适合那些一开始看起来简单、但未来很可能引入条件分支、人工节点、失败恢复、审计追踪的项目。CrewAI 更适合作为演示和原型工具。它的角色分工模型很直观做 demo 很快适合把多个角色协作的概念迅速跑起来。但我见过太多团队从 CrewAI 起步半年后被迫迁移到 LangGraph。原因通常很相似流程一旦出现回退、循环、状态恢复、复杂条件判断CrewAI 的抽象就会变得吃力。如果你预期项目会长期维护从一开始就要谨慎选择 CrewAI。厂商 SDK 只在深度绑定时选。OpenAI Agents SDK、Google ADK、Microsoft Agent Framework 都有各自的生态优势。如果你的模型、云服务、权限体系、部署体系已经深度绑定某个厂商厂商 SDK 会带来明显便利。脱离母体生态后它们的优势会迅速变弱同时可能带来迁移成本和平台锁定问题。四、自研必须考虑什么如果你决定不用框架以下是按优先级排列的必备能力如果你想看一个不依赖框架、从零实现上述能力的完整项目可以参考 echo-agent。它展示了工具系统、上下文管理、护栏机制如何在没有框架的情况下落地适合作为自研路径的参考起点。P0没有这些就不叫 Agent工具系统Agent 和普通聊天机器人的核心区别就是能否稳定、可控地调用外部工具。你至少需要工具注册机制schema 定义 函数绑定执行引擎解析 LLM 返回的工具调用执行并回传结果错误隔离单个工具失败不能让整个 Agent 崩溃tools_registry { read_file: {fn: read_file, schema: {...}}, web_search: {fn: web_search, schema: {...}}, execute_code: {fn: execute_code, schema: {...}}, } ​ def execute_tools(tool_calls): results [] for call in tool_calls: try: result tools_registry[call.name][fn](**call.args) results.append({status: success, output: result}) except Exception as e: results.append({status: error, output: str(e)}) return results工具系统要尽量简单、透明、可测试。每个工具都应该有清晰的输入 schema、输出结构、错误类型和权限边界。不要把业务逻辑、权限校验、异常处理全部塞进一个工具函数里否则后续会很难排查。护栏和终止条件没有护栏的 Agent 会死循环或者烧穿你的账单。至少需要最大步数限制防止无限循环Token 预算上限防止成本失控连续错误熔断同一个工具连续失败 3 次就该停高风险操作确认点删除、发送、部署前暂停Agent 的不可控性很多时候来自没有明确停止条件。一个生产级 Agent 必须知道什么时候继续、什么时候暂停、什么时候请求人工确认、什么时候彻底终止。P1生产环境必须有上下文管理LLM 有窗口限制。长任务跑到一半 context 撞墙前面所有推理和工具结果都可能白费。你需要Token 计数知道还剩多少上下文空间消息压缩 / 摘要早期对话做摘要保留近期完整内容System prompt 动态组装根据当前阶段注入不同指令上下文管理的关键是保留决策所需信息丢弃过程噪声。早期工具日志、重复解释、无效尝试都可以压缩用户目标、关键约束、外部系统返回的重要事实必须保留。错误处理与重试现实世界里工具调用必然出错网络超时、API 限流、格式异常、权限失败、外部服务不可用。需要指数退避重试降级策略主工具不可用时切备选错误信息回传给 LLM让它调整策略错误处理不能只停留在 try/except。你需要区分哪些错误可以重试哪些错误需要换路径哪些错误必须交给人处理。把所有异常都变成字符串塞回 LLM看起来简单实际会让 Agent 行为变得不可预测。P2规模化后才需要记忆系统短期记忆就是 messages 列表天然存在长期记忆跨会话持久化通常用向量数据库 语义检索先试最简方案把关键信息塞回 system prompt。不够用时再上向量检索别过早引入复杂度。记忆系统最容易被过度设计。很多项目以为自己需要长期记忆实际只需要在当前任务中保存几个关键状态。真正需要长期记忆的场景通常具备跨会话连续性比如长期客户偏好、项目上下文、历史操作记录。日志与可观测性记录每一步的输入输出、token 消耗、执行时间。这属于生产排障的基础设施。当 Agent 在生产环境出现诡异行为没有 trace 你根本无法定位问题。你需要知道它当时看到了什么上下文为什么选择某个工具工具返回了什么LLM 如何解释结果最终如何生成动作。规划能力让 Agent 在执行前先输出步骤计划再逐步执行。这对复杂任务的成功率有显著提升但简单任务不需要。规划能力适合多步骤、高不确定性、高风险任务。对于简单查询、单次工具调用、固定流程任务额外规划反而会增加 token 开销和延迟。五、决策模型一棵可以直接用的决策树你的 Agent 项目 → │ ├─ 只有 1 个 Agent 几个工具 │ └─ YES → 裸写。50 行代码解决框架是负担。 │ ├─ 多个 Agent 需要协作 │ ├─ 协作模式是线性分工A做完给B │ │ └─ YES → CrewAI 做原型验证确认价值后评估是否迁移 LangGraph │ └─ 协作模式有条件分支/循环/人工节点 │ └─ YES → LangGraph别犹豫 │ ├─ 需要持久化、断点恢复 │ └─ YES → 框架LangGraph / Microsoft Agent Framework自研这个太贵 │ ├─ 被绑在某朵云上 │ ├─ Azure/.NET → Microsoft Agent Framework │ ├─ GCP/Gemini → Google ADK │ └─ OpenAI 生态 → OpenAI Agents SDK │ ├─ 项目周期 1 个月验证想法 │ └─ YES → 裸写或最轻量框架Pydantic AI / Agno │ └─ 自己维护的编排代码 500 行且跟业务逻辑无关 └─ YES → 该引入框架了你在重复造轮子这棵树背后的核心判断标准只有一个你的复杂度主要来自业务能力还是来自编排本身。如果复杂度来自 prompt、工具质量、检索效果、模型能力框架帮不上太多忙。如果复杂度来自状态转移、流程恢复、人工节点、多 Agent 协调、审计追踪框架会显著降低长期维护成本。六、场景实战场景一客服 Agent需求接入企业知识库回答用户问题必要时转人工。选择裸写理由本质上就是一个 RAG 工具调用循环。工具只有检索知识库和转人工两个。用 LangGraph 画一张图来表达检索 → 回答 → 用户不满意 → 转人工这个流程是用牛刀杀鸡。核心代码 100 行以内可以搞定重点精力应该放在 RAG 的检索质量上比如文档切分、召回策略、rerank、权限过滤、答案引用、拒答策略。客服 Agent 的瓶颈通常在知识库质量和答案可信度编排层不应成为早期投入重点。场景二自动化代码审查 Agent需求读 PR diff → 多维度审查安全、性能、风格→ 汇总报告 → 有严重问题时阻断合并。选择裸写但加规划层理由看起来是多 Agent比如安全审查员、性能审查员、风格审查员但它们之间没有真正交互只是并行执行然后汇总。用asyncio.gather()并行调用三次 LLM比引入 CrewAI 的角色系统简单得多token 消耗也低得多。reviews await asyncio.gather( review_security(diff), review_performance(diff), review_style(diff), ) summary await synthesize(reviews)这个场景真正需要关注的是审查维度设计、diff 压缩、规则库注入、误报控制和报告结构化。把它包装成多角色协作反而会增加额外上下文和协调成本。场景三金融合规审批流需求文档提交 → AI 初审 → 规则引擎校验 → 人工复核 → 通过 / 驳回 / 补件 → 归档。流程中任何一步失败都可能需要回退到前序步骤全程需要审计日志。选择LangGraph理由这里有明确的状态机多个状态、条件转移、人工节点、失败回退、跨天审批、审计追踪。它还需要持久化因为审批流程可能持续数小时甚至数天也需要可追溯性因为每一步的决策和依据都要记录。这正是 LangGraph 的甜区。裸写这个状态机可以做到但维护成本会随业务规则增加快速上升。每新增一种审批分支、补件规则、风控策略都可能影响已有状态转移。用图工作流表达会让复杂度更可控。七、踩坑经验坑一从 CrewAI 迁移到 LangGraph一个做内容生产的团队最初用 CrewAI 搭了选题 → 研究 → 撰写 → 编辑流水线demo 效果很好。但上生产后发现编辑 Agent 否决文章后没有优雅的方式让它回到撰写环节重做偶尔网络超时导致中间状态丢失整个流程要从头跑Token 消耗比预期高 3 倍CrewAI 的角色描述和协调指令吃掉大量 context迁移到 LangGraph 花了 3 周基本是重写。教训如果你的流程有回退需求一开始就别选 CrewAI。线性流水线可以用 CrewAI 快速验证带状态回退的复杂流程应该直接选图工作流。坑二裸写失控的信号另一个团队坚持裸写最初很顺畅。但 Agent 从 2 个增长到 6 个后编排逻辑散落在 8 个文件里没人能一眼看出完整流程状态通过全局字典传递调试时根本不知道某个值是谁在什么时候改的每次加新 Agent 都要改三个地方的代码经常漏改当你发现加一个 Agent 的边际成本在上升时就该引入框架了。裸写失控通常有几个信号状态传递越来越隐式流程图只能靠人脑记忆新增节点会影响多个旧节点排查问题必须全链路打日志。出现这些迹象说明你已经在重复造编排层的轮子。坑三过早优化架构最常见的坑项目还在验证AI 到底能不能做这件事的阶段就花两周搭框架、设计插件系统、写抽象层。结果 AI 能力本身不达标整个项目被砍掉框架白搭。先证明价值再优化架构。50 行裸写代码能验证的事情不需要 2000 行的框架集成。早期最重要的指标是任务成功率、人工替代率、成本、延迟和用户接受度。等这些指标跑通后再考虑工程化、框架化和平台化。八、结论我的明确立场经历过足够多的项目后我的判断是大部分 Agent 项目不需要框架。我做过的项目里60% 最终的生产版本是LLM API 工具循环 自己写的状态管理。框架的抽象在演示时优雅但生产环境的各种边界情况往往需要绕过框架处理。真正需要框架的信号只有三个多 Agent 间有复杂的协调逻辑超出简单并行进入有状态交互流程需要持久化和断点恢复审计和合规要求每一步决策可追溯如果这三个都不沾裸写就是最优解。代码量少、调试简单、迭代快、token 省。最后一句话框架解决编排复杂度无法替代 Agent 能力本身。如果你的 Agent 不够智能换框架不会让它变聪明。先把核心的 prompt engineering 和工具设计做对再考虑编排层的事情。推荐资源echo-agent — 无框架依赖的 Agent 实现工具循环 状态管理 护栏机制适合作为自研路径的参考起点LangGraph 官方文档 — 如果你决定用框架从这里开始Pydantic AI — 追求类型安全和代码质量的轻量方案