说实话，这个话题在我脑子里转了大半年了。从去年开始，我一直在做企业内部编码助手的落地，从最早期接 LangChain 搭 RAG 问答，到后来用 AutoGen 写多 Agent 剧本，再到最近彻底转向直接跑 Claude Code / OpenAI Codex 这一类 Coding Agent，整个过程中最大的感受就是：Coding Agent 正在自己变成一个 Agent Runtime，而传统 Framework 的定位正在被快速边缘化。
先说结论吧，免得大家越看越焦虑：Framework 不会“死”，但它的角色会被彻底重写。过去 Framework 是所有 Agent 的“运行底座”，未来它更多是编码 Agent 外围的“局部能力封装”。这个问题不是简单的二选一，而是架构演进中必然要面对的一次分工洗牌。接下来我会从自己的实测经验出发，把 Coding Agent 到底做了哪些 Runtime 该做的事、Framework 在哪些场景依然有效、以及你该怎么决策这几件事拆开讲清楚。
1. Coding Agent 的形态变化：从“插件”到“执行者”
要判断“传统 Framework 还有没有用”，得先搞清楚 Coding Agent 到底进化到了什么程度。最早大家接触的编程助手就是 Copilot 那种代码补全，后来是 ChatGPT 网页版的对话问答，再后来你会发现，现在这一批 Coding Agent 已经完全换了一种工作方式：它们不是给你“建议”，而是直接在终端里替你干活。
1.1 编码工具走过的三个阶段
我把编码工具的进化分成三个阶段，方便理解整个逻辑。
第一阶段是“补全式”。代表是 GitHub Copilot 和 TabNine 这些 AI 代码助手。它们的核心模式是“你写，它补”，本质是一个基于上下文的 Token 生成器。这个阶段不需要 Agent 这个概念，也不涉及工具调用、文件修改，就是最单纯的模型推理。
第二阶段是“对话式”。ChatGPT、Cursor、通义灵码这类产品把编程助手带入了对话模式。你可以问它“这段代码为什么报错”“帮我重构一下这个函数”，它会基于上下文给出代码答案。但这个阶段仍然有一个关键的边界：AI 不直接操作你手里的项目文件，修改的动作和结果还是要靠你手动完成。也就是说，外部世界和模型之间隔着一层玻璃，玻璃从来没有被打碎。
第三阶段就是我称之为“执行者”的阶段。代表产品有 OpenAI Codex CLI、Claude Code、Devin、以及国内厂商出的各种终端型编码智能体。OpenAI 那句很有名的欢迎语 “welcome to codex”，说的就是把命令行变成一个可以执行任务的 Agent 入口。这个阶段的本质变化是，AI 不再停留在生成文本，而是拥有了对真实环境的控制权：它可以读文件、改代码、跑测试、执行终端命令、查看输出结果再继续决策。它做的不只是“生成一个方案”，而是“执行一个完整闭环”。
这第三阶段的跃迁，才是让 Coding Agent 从“引入的插件”变成“自主执行者”的分水岭。也是从这里开始，传统 Agent Framework 的叙事开始出现了裂缝。
1.2 编码 Agent 的真实工作流
第二阶段到第三阶段，真正意义上的变化从哪里体现？我用一次真实的编码任务来说明。
假设我用最原始的 LangChain 思路做一个编码助手，工作流大概是：接收用户需求 → 调用 LLM 生成代码片段 → 把代码返回给用户 → 用户手动保存、手动运行、手动把报错贴回来。整个过程是“人机接力”，每一次信息交换都要经过用户这个中转站。这个设计的根本问题是：AI 没有失败后自愈的能力，它永远在等人类反馈，整个 Agent 的“主动性”其实很弱。
而现在的主流 Coding Agent 工作流，以 OpenAI Codex 或 Claude Code 为例，已经完全换了一套逻辑：
- Agent 接收到自然语言任务（比如“修一下这个模块的分页 bug”），先读取项目结构、定位相关文件。
- 它会直接编辑文件，而不是生成代码片段让你自己粘贴。
- 修改完之后，Agent 自己调用终端命令运行测试或构建脚本。
- 如果测试失败，它会读取报错日志，分析原因，再回到第 2 步继续修改。
- 循环直到测试通过，然后向用户汇报改动内容。
看到了吗？整个循环里，Agent 自己拥有读、写、执行、观察、修正的能力，它是一个自包含的闭环。这个闭环本身就是运行时的雏形。任何一个能自发执行多个步骤，并且能感知环境状态变化的系统，都已经具备了 Runtime 的核心特性。这也是我认为“Coding Agent 正在成为 Runtime”这一判断最直接的证据。
1.3 为什么原有框架会在这个场景里“失效”
那为什么同样的闭环，用 LangChain 也能搭出来，但在实际工程中却如此别扭？
我在早期项目里确实尝试过用 LangChain 的 Agent Executor 搭一个编码助手：配置好 Tool 集合（读文件、写文件、执行 shell），接入 OpenAI 的 function calling，然后跑 ReAct 循环。看起来结构差不多，但一落地就暴露出一堆问题。
首先是状态管理灾难。编码不是一次性的对话，它需要维护项目上下文、文件变更记录、历史决策原因。LangChain 里的 ConversationBufferMemory、AgentState 这些抽象，在设计时就没有考虑到“文件系统状态”这种外部共享状态。一个完整的编码会话如果拆成几百条消息塞进 context，Token 成本直接爆炸。
其次是工具调用链路的脆弱。编码 Agent 需要高频调用几十种工具，而每种工具都可能超时、失败、返回格式不齐。LangChain 当时提供的 Tool 抽象在单次小任务里没问题，但真实工程里的错误远比它设想的复杂：文件锁、权限、Shell 返回的非结构化日志、测试命令的长度超限……这些都不是用一个“Tool 类”就能抽象干净的东西。
第三点是生命周期问题。Framework 通常假设 Agent 的生命周期是“一次调用结束就结束”，但编码 Agent 要处理的是跨小时、跨会话的长期任务。它必须像守护进程一样管理状态、持久化进度、恢复上下文。传统 Framework 往往没有把“Agent 自身作为持久化服务”这一个维度做好，导致开发人员要自己堆基础设施，最后等于自己写了个 Runtime，Framework 反而变成了一层皮。
所以我的经验是，不是 Framework 本身失效了，而是在 Coding Agent 这个高复杂度、强交互的场景里，Framework 提供的抽象层级不够“厚”，无法承载真实工程的需要。
2. Agent Runtime 的本质：Coding Agent 自己变成了那层底座
如果你认同了上一节的推断，那接下来就必须回答一个问题：Agent Runtime 到底是什么？它和传统 Framework 有什么区别？只有把这个问题想透了，才能评估 Framework 的剩余价值。
2.1 什么是 Runtime？用生活化的方式理解
我理解 Runtime（运行时）的核心职能，一句话就能概括：为上层代码或 Agent 提供可运行的环境、生命周期管理和资源访问能力。
类比一下会更容易懂。在一个操作系统里，进程不需要自己处理 CPU 调度、内存分配、磁盘读写这些底层逻辑，它只需要向 OS 申请资源，由 OS 来提供了。Java 里你只管写业务代码，JVM 帮你搞定垃圾回收、线程调度、字节码解释。
在 AI Agent 的领域里，Runtime 就是“让 Agent 能够在这个环境中真正行动的基础设施”。它至少要提供三方面能力：一是执行能力（读写文件、跑命令、调 API），二是状态与上下文管理（记住当前任务阶段和历史决策），三是生命周期控制（何时开始、何时暂停、出错如何恢复）。
过去的 Framework 扮演的角色确实接近这个定义：它提供工具注册、记忆模块、多 Agent 协调。但是 Framework 本质上只是一套“代码库”，它自己跑在一个更大的宿主进程里，为上层提供编程接口。而今天的新局面是——Coding Agent 不再是运行在某个框架里的一个模块，它本身就是那个执行环境。
2.2 Coding Agent 作为 Runtime 的四个体现
如果还是觉得抽象，那直接看当前的 Coding Agent 产品是怎么设计的，四点很明确：
Execution（执行）层面：Agent 不止调用外部 API，它能直接在沙箱或容器里执行 Python、Bash、编译指令，本身就是一个命令行级别的执行环境。Codex CLI 甚至就是一个命令行工具，它不依赖你额外起的服务，直接在终端里完成全链路。
Memory（状态）层面：Agent 会把项目结构、仓库历史、用户的偏好、lint 规则、完成进度都纳入到自己的上下文管理体系中。有的产品开始引入专门的持久化存储，把重要信息导出成文件，避免每次都要把所有代码库都读一遍，这其实就是在做 Runtime 级的记忆服务。
Lifecycle（生命周期）层面：真实场景里一次编码任务可能要跑几十分钟甚至几个小时，Agent 需要长时间管理一个任务，中间可能因为 API 限流中断、因为测试失败回滚。成熟的 Coding Agent 会设计 checkpoint 和恢复机制，这完全就是 Runtime 干的事。
Interfaces（接口）层面：现在的 Coding Agent 正在标准化 Agent 与外部世界的通信协议，比如 Model Context Protocol（MCP）。这相当于 Runtime 提供了统一的 API 接口，让 Agent 与各种外部工具之间的连接有了标准的“插槽”，不再需要每个工具用一种自定义方式接入。
这四点叠加在一起，你就会发现 Coding Agent 的自我定位已经不再是“框架里的一个 Agent”，而是“所有 Agent 的运行底座”。它正在吃掉传统 Framework 喊了很多年的那一整套概念。
2.3 框架的价值被内化，而不是被消灭
这里想澄清一个容易走极端的判断：Framework 的价值并不是被“杀死”了，而是被“内化”了。
用.NET Framework 的类比可能不太准确，但方向上很像。当年做 Windows 原生应用必须依赖 .NET Framework 提供运行时，后来 .NET Core / 高性能运行时出现了，以前框架里很多功能（JIT、GC、类库）被吸收进新的运行时里，一部分组件则被淘汰了。Framework 没有被完全消灭，而是它的最佳实践和核心能力被下一代平台吸收，新平台变得更轻、更快、更贴合场景。
Coding Agent Runtime 也一样。LangChain 里关于 Prompt 模板、函数调用、工具封装的经验，很多都被下一步的 Coding Agent 产品团队吸收并重新实现了：工具描述和参数 schema 的写法、错误重试规则、上下文裁剪策略，这些成熟工程模式都被直接做进了 Agent 的运行时内核里。
所以我建议所有做 Agent 开发的团队，别再抱着“用哪个 Framework 能产生 Agent”的思路往前走了。你现在应该思考的是：在 Coding Agent 自己就是 Runtime 的前提下，你还需要在哪个层面补充它不擅长的能力？
3. 传统 Framework 的现役价值：不至于被淘汰，但定位变了
这不是一个非黑即白的问题。Coding Agent 成为 Runtime 之后，传统 Framework 依然有自己明确的生存空间。说它没用是错的，把它当万能药也是错的。关键是哪些场景它真的还能打。
3.1 框架现在还有用的三个场景
场景一：垂直领域的 RAG 流程控制。编程之外，大量的知识库问答 Agent、私有数据检索 Agent 并不需要执行代码的能力，它们的核心是检索增强生成和一些简单的工具调用。LangChain 的 PGVector、文档分块、Embedding 管理那一套封装，在这个场景里依然效率很高，没必要重新发明轮子。
场景二：多 Agent 协作与业务流程编排。跨部门的流程型任务，比如“操作系统处理完报销单再通知财务 Agent 做账”这类场景，需要明确的流程编排、状态机定义和人工审核节点。LangGraph、AutoGen、Semantic Kernel 的图编排能力比用 Coding Agent 自己硬写逻辑要稳很多。Coding Agent 擅长的是自主探索，不擅长的是严格流程约束，这一点一定要分清。
场景三：工具接入协议与统一鉴权。当 Agent 需要接入企业内部十几个既有系统时，统一工具注册、权限控制、审计日志这些还是需要一套基础设施。Framework 可以在这一层做存量能力集中管理，即使它不再负责 Agent 的推理流程。
这三类场景里，Framework 的角色已经从“Agent 运行底座”降级为“局部能力封装”，它输出的不是 Agent 本体，而是某一块横向能力。你该用的时候还是要用，但不要再因为迷信“框架产生 Agent”就去全套引进了。
3.2 与技术方案选型相关的两个案例观察
我根据自己的实际项目观察，举两个真实的选型案例。
案例 A 是一个企业内部的智能工单系统。业务 Agent 需要从一大堆历史工单和知识库里检索答案，再自动提交到不同部门系统。因为流程规则明确、工具接口统一，我最终选了 LangGraph 做流程编排，而不是用一个 Coding Agent 全盘接管。原因很简单：这里的需求是“按流程办事”，不是“自主探索”，流程里每一步都必须有人工审批，用编码式 Agent 反而要花大量精力去约束它不要越界。这个选型跑了大半年，稳定性非常高。
案例 B 是一个研发效能团队要做代码自动重构工具。他们一开始直接用 LangChain 的 AgentExecutor 搭建，结果很快遇到了上一节说的状态管理难题。后来他们选择了把重构逻辑下沉到 Claude Code / Codex CLI 这一类 Coding Agent 上，用 Agent 自己擅长的“文件修改-运行测试-修复回归”模式去工作，反而把集成周期从几周压缩到几天。Framework 在这儿几乎只用来做简单的 prompt 模板和输出格式化。
这两个案例说明一个道理：按“流程驱动”选框架，按“执行驱动”选 Coding Agent。Framework 的适用面没有归零，只是被严格划定在一个更窄、更清晰的边界里。
3.3 框架真正让人头痛的“重抽象”问题
当然，我也有对传统 Framework 很不满意的地方，最核心的问题就是抽象过重。
Framework 为了兼容各种场景，会引入大量抽象层：Model Wrapper、Tool Wrapper、Memory Store、Callbacks、Retry Policy……每一层看起来都是精心设计的解耦，但在真实项目中，你调试一个问题往往要穿过多层包装才能找到根因。尤其当 Coding Agent 自己已经把执行逻辑跑得很顺时，你再用框架去包一层，反而显得多余。
我印象很深的一次排查经历是，用某框架搭一个简单的“读取文件-总结-回复”任务，框架层的回调机制把 LLM 输出和工具返回结果混在一个事件流里，为了拿到最后的回复，我不得不去框架内部找出回调的下发顺序。这个“为了抽象而抽象”的复杂度，正是新一代 Runtime 型 Coding Agent 试图降低的东西——它直接给你一个终端，让你看到它每一步在干什么，出错了直接改就行，反而少了中间那几层不必要的管理器。
4. 选型和落地：到底是直接上手 Coding Agent，还是继续选 Framework？
聊到这儿，你大概率已经有了一个判断：能不能简单粗暴地给出一个选型结论？我觉得可以给，但要分场景给。这里我给出一套我实际用的思考框架。
4.1 决策的四个核心维度
我判断一个新的 AI 项目到底该用 Coding Agent 还是传统 Framework，主要看四个维度：
第一是任务特征。这个任务是流程型的、规则明确的，还是探索型的、结果引导的？流程型任务选框架，探索型任务选 Agent。所谓探索型，就是没有一条标准步骤，Agent 需要反复试错才能到达目标，典型代表就是“读懂一个老项目的代码并重构”。
第二是环境控制权。你允许 Agent 在多大范围内操作系统、文件、网络？如果必须在严格容器里运行，并且每一步都要有第三方审批，那就适合用框架把人控制的流程显式建模出来。如果环境安全边界你已经能管控好，Agent 直接落在开发沙箱里跑也是最省事的。
第三是调试复杂度。如果团队对现有框架已经非常熟悉，并且项目逻辑复杂到需要图状态机才能描述清楚，那继续用框架没问题。如果你更在意“AI 能自己把活干完”，那应该优先考虑 Coding Agent，因为它的调试方式就是给它一个任务，看它跑完的结果，你恢复工作只需要改提示词。
第四是长期维护成本。Coding Agent 依赖的模型和工具变化非常快，今天用 Codex、明天可能出现更强的竞品。如果对一个刚性业务系统来说，你受不了这种快速变化给上层业务带来的风险，那用框架把你和模型解耦就很有必要。如果只是做研发效能工具，允许快速迭代试错，那直接拥抱 Coding Agent 更合适。
4.2 选型对照表
为了让大家一眼看明白，我整理了下面这张对照表，是我自己在项目评审时用的简化版本。
| 判断维度 | 优先用传统 Framework | 优选用 Coding Agent |
|---|---|---|
| 任务类型 | 多步骤流程、状态机强约束 | 自主探索、试错修复 |
| 环境要求 | 每次执行需要人工审批、细粒度鉴权 | 开发沙箱内自主可控 |
| 调试方式 | 通过日志链路查看每步状态 | 直接看 Agent 在终端做了什么 |
| 上下文规模 | 场景简单，几千 Token 足够 | 长期项目，需要超大上下文和记忆管理 |
| 维护重点 | 业务规则变更频繁但需要确定性 | 模型/工具快速迭代，接受结果不稳定 |
| 典型示例 | 工单流转、审批机器人、业务助手 | 自动修 bug、代码重构、原型开发 |
这张表的核心不是“哪个好”，而是“哪个更适合”。我见过太多团队非常迷信“Agent 是未来”，把流程化管理任务硬塞给自主 Agent，结果在安全审计上耗费了巨量时间。反过来，也有团队明明要做的是 AI 自动修复代码这种天然自主任务，却还在框架的状态机里拼命建模，把简单问题复杂化。
4.3 如果自己动手做个“最小 Agent Runtime”该怎么入手？
如果你的需求是自建一个轻量编码 Agent，而不是完全依赖商用产品，那最好也是先搞清楚 Runtime 需要哪些基础部分，再决定要不要用框架。
我的经验是一个最简 Runtime 需要四个模块：
- 执行循环：一个 while 循环，调用模型接口，判断模型返回值里有没有工具调用。有就执行工具，把结果作为新的消息喂回去，直到没有工具调用为止。
- 工具集合：至少要有读文件、写文件、执行 shell 三个基础工具。每个工具要按照 function calling 的 schema 写好描述和参数定义，模型是靠描述来决定要不要调用它的，描述写不懂模型就会瞎搞。
- 上下文管理：把长对话做压缩，把中间工具运行结果适当省略，只保留必要的上下文。上下文管理是最容易先崩的环节，代码跑起来之后大量输出会让 Token 额度瞬间爆掉。
- 安全策略：规定哪些路径可以写、哪些命令禁止执行、是否需要人工确认。安全策略最好直接编进系统提示词里，而不是靠事后过滤做最后一道防线。
这四个模块加起来，功能上其实就是一个极简的 Agent Runtime。你会发现它并不复杂，真正复杂的不是组装这些模块，而是让模型在真实项目里做出正确决策。而很多事情，商用 Coding Agent 已经做得很好了，自研未必更划算。
当时的实践感受是：LangChain 这类框架反而成为外围最简单的一层“适配器”，真正的核心工作变成我需不需要自己维护上下文管理、权限控制、沙箱隔离。很多团队注意到这一点之后，反而开始从框架切回原生 SDK + 手写循环。
5. 实操笔记：我踩过的坑和现在的做法
说了这么多方法论，最后分享一些非常具体的实操经验和踩坑记录，这些大部分是官方文档里看不到的。
5.1 三个容易让人反复折腾的坑
坑一：把所有工具全丢给 Agent 调用，项目会失控。一开始我图方便，把 Git、Docker、npm、Shell 全部注册成可用工具，结果 Agent 经常在没有询问的情况下直接执行 git push 或者 docker compose down。后来我强制加入一层“危险操作确认门卫”，任何命令只要匹配危险词列表，必须先进入人工审批流程。以后做任何 Agent 时，默认就不该给工具开放全部权限。
坑二：上下文爆炸远比你想象来的快。编码 Agent 跑半小时，日志和中间结果能轻松填满整个模型上下文窗口。如果你的上下文管理做得不好，Agent 会发现它忘记最开始的用户需求，然后开始问你要需求。我这里最有效的经验：每轮工具调用后只保留结构化摘要，原始完整输出落到本地文件，用时间戳做索引。
坑三：不要试图用“更长的 prompt”去约束 Agent 的行为。很多团队发现问题就拼命往系统提示词里加规则，最后提示词几千行，Agent 变的迟钝且不稳定。正确的方式是用“工具本身的定义”来约束行为，比如你不希望 Agent 删除文件，就不要注册 delete 工具，比在 prompt 里写“禁止删除”要有效得多。
这几个坑从 LangChain 时代到 Coding Agent 时代都有体现，只是换了呈现方式：以前是框架层回调和记忆模块出错，现在则是 Agent 自身的能力边界和安全问题。
5.2 目前我认为比较舒服的落地组合
最后说下我现在的真实落地组合，供大家参考，不是什么标准答案，但实测比较舒服。
- 编码开发与自动化修复场景：直接用现成的 Coding Agent（Codex / Claude Code / 以及一些国产的终端型 Agent），通过标准命令行接入，不额外套框架，尽量让 Agent 自己闭环。
- 业务编排与流程审批场景：继续用框架，但我选用到的部分很少——主要是多轮条件分支、人工审批节点、状态持久化。真正用到的代码量很小，不需要全套框架。
- 大数据与知识库检索场景：用轻量 RAG 组件 + 传统工具库，不用 Agent 框架，因为核心瓶颈在检索质量和排序，不在 Agent 编排。
- 底层协议和数据连接层：逐步用 MCP 标准统一起来，把工具接入当作一个公共服务去维护，不管是 Coding Agent 还是框架都能直接复用。
对大多数团队，我的建议是：不要再从“我该学哪个 Agent 框架”这个问题出发做选型，而是从“我的任务到底需要哪些 Runtime 能力，哪种实现方式更稳、更省、更好维护”出发。Coding Agent 正在吃掉 Runtime 层这件事，不是理论推演，是每天都在发生的现实。你越早把思路从“框架思维”切换到“运行环境思维”，在下一波工具迭代里就越不容易被牵着鼻子走。
最后分享一个很小但很实用的经验：无论你最终选了框架还是 Coding Agent，一定要把“工具调用日志”做成一个可回放的审计流。每次 Agent 干了什么、调了什么工具、改了哪些文件，都应该能事后复盘。这一点比选哪个技术栈都重要，因为自主智能体一旦失控，你手里唯一的救命稻草就是一份完整的行为日志。
