前阵子我把一个自动化脚本项目改成用 CLI 形态的 Coding Agent 来跑越用越觉得不对劲我好像不是在用一个 AI 编程插件而是在启动一个常驻的“执行环境”。它会自己建分支、跑构建、读报错日志、改测试、再提交我全程只是在旁边偶尔批准一下命令。这让我重新想起一个被问了很多次的问题当 Coding Agent 正在变成 Agent Runtime传统 Framework 还有用吗这个问题不是赶时髦它直接影响你下一个项目的架构选型。标题里三个词——Coding Agent、Agent Runtime、Framework——把它们放到一起看中间层的分工就变得很清楚了。过去我们习惯在 LangChain、Semantic Kernel 这类框架上搭 Agent因为模型调用之后的编排、记忆、工具分发都得自己写但现在像 Codex CLI、Claude Code、Gemini CLI 这类产品已经把“跑一个 Agent”这件事做成了标准运行时。那传统框架的位置在哪还需要用吗这篇文章就是我在真实项目里的观察、实验和选型判断。1. Coding Agent 怎么就从“写代码工具”变成了“运行时”要先捋清楚“Coding Agent 变成 Agent Runtime”到底是什么意思。它不是概念包装而是这类工具的实际架构发生了变化。1.1 我观察到的三个阶段第一阶段是代码补全。模型在 IDE 里根据光标上下文给建议比如早期的 Copilot。这时候模型本质上是一个“超级自动补全”它不执行代码不操作文件也不做多步判断所有 Agent 行为都不存在。第二阶段是 IDE 内嵌 Agent。模型开始能读多个文件、改多处代码、执行终端命令但它仍然寄生在 IDE 进程里面。它依赖 IDE 提供的文件树、终端面板、diff 视图离了 IDE 基本跑不起来。这个阶段已经具备 Agent 的雏形但还不是真正独立的运行时。第三阶段是命令行 Coding Agent。它自己就是一个长期运行的进程通过标准输入输出和人交互。它直接负责文件读写、命令执行、Git 操作、环境变量管理还能在多个任务之间保持会话状态。OpenAI 的 Codex CLI 就是典型代表登录 ChatGPT 账号后在终端里输入一句话它就能自己拆解任务并执行。到了这个阶段Coding Agent 就不再是 IDE 里的一个功能按钮而是一个能独立承载 Agent 逻辑的宿主环境。这个“宿主环境”就是我理解的 Agent Runtime。你写程序时需要 Node.js 或 Python 解释器来运行代码现在跑一个 Coding Agent 也需要这样一种运行时它负责让模型在主循环里运转并把模型决策翻译成真实的文件写入和 shell 命令执行。1.2 Coding Agent Runtime 到底在运行什么要判断传统 Framework 还有没有用先得看 Runtime 接管了哪些原本由 Framework 负责的活。我拆了一下一个成熟的 Coding Agent Runtime 至少包含六个部分。首先是主循环。传统框架管这个叫 AgentExecutor 或 AgentRunner现在 Runtime 内置了。它会自动完成“感知 → 决策 → 行动 → 观察结果”的闭环你不需要自己写 while 循环去反复调用模型。其次是上下文工程。这是最容易忽略但最核心的部分。Runtime 会在每轮决策前自动准备上下文读当前仓库文件、收集最近改动、保留关键的对话历史、压缩太长的旧消息。它甚至会根据任务目标自动裁剪无关文件让模型在有限的窗口里看到最值得看的信息。第三是工具调度。文件编辑、代码搜索、执行测试、Git 提交这些操作不是模型直接完成的而是 Runtime 调用内置工具完成的。工具返回结果后再喂回给模型形成下一轮决策依据。这跟 Framework 里的 Tool Calling 机制几乎一模一样但 Coding Agent Runtime 把它做成了默认内置能力而不是需要你注册的扩展点。第四是权限与沙箱。Runtime 会在一条命令真正执行前判断它是否被允许哪些命令可以自动跑哪些需要人确认哪些在沙箱里跑。这是运行时安全边界属于基础设施不是业务逻辑。第五是会话与状态管理。它可以保存整个 Agent 会话、支持断点恢复、创建 Git Checkpoint 以便回滚。相当于你的 Agent 有了“持久化内存”和“事务回滚”。第六是可观测性。它会把决策过程、工具调用、中间结果完整记录下来方便你复盘 Agent 为什么这么做。我画过一个很简化的运行时循环长这样while session_active: context build_context(history, repo_snapshot) action model.decide(context) if action.is_tool_call: if policy.is_allowed(action.tool): result runtime.execute(action.tool) history.append(result) else: history.append(blocked_notice) else: reply_to_user(action.answer)这段伪代码在传统 Framework 里经常要你亲手实现或者至少要配置一堆回调。但现在 Coding Agent Runtime 已经把它变成了像呼吸喝水一样的默认行为。所以我说Runtime 接管的正是框架曾经最核心的执行层。2. 传统 Framework 的价值盘点和快过时的位置Framework 被冲击是事实但它不是一点用都没有。它到底还有没有价值取决于你要用 Agent 做什么。2.1 传统 Agent Framework 原本解决什么问题传统框架解决的核心问题是让开发者不用从零搭建 Agent 基础设施。以 LangChain 为例它提供了模型抽象层、Prompt 模板、Chain、Tool 注册、Memory、输出解析Semantic Kernel 类似提出了 Plugin 和 Skill 的概念AutoGen 则把重心放在多 Agent 对话编排上。在没有 Coding Agent Runtime 的年代你想让模型调用工具就得自己定义工具 Schema、写工具分发逻辑、解析模型输出里的函数调用参数、再把结果塞回对话历史。这套流程很重复框架把这些统一抽象成“注册一个 Tool它就能被模型调到”。这是实打实的价值帮我省了很多时间。另外框架还提供了状态机和确定性流程。比如一个客服 Agent得先判断用户意图再决定调哪个业务接口最后生成话术。这种流程可以被定义成 Chain 或 StateMachine每一步都可控、可测。传统 Framework 在这个层面很强。还包括多 Agent 协作。A 模型负责拆解任务B 模型负责审查C 模型负责汇总。框架可以管理它们之间的消息传递。这种能力是 Coding Agent Runtime 默认不具备的至少现在还不怎么强调。所以传统 Framework 真正的位置在“应用层”它帮你把 Agent 变成产品逻辑而不是帮你跑最底层的模型执行循环。2.2 当 Coding Agent 自带 Runtime 后Framework 被替代的部分我整理了一个简表回头去看老项目时感受特别明显能力项传统 Framework 的做法Coding Agent Runtime 的做法Agent 主循环自己写代码或配置回调内置开箱即用上下文管理自己拼历史、管理窗口自动准备仓库级上下文工具调用注册 Tool 类写 Schema内置文件、Shell、Git 工具天然可用扩展工具继承 Tool 接口MCP 协议即插即用权限控制通常不负责内置批准/拒绝/沙箱状态恢复靠数据库和 Memory 模块会话持久化 Git Checkpoint可观测性接入第三方 Tracing自带完整会话记录可以看到执行层这一块确实快被 Runtime 覆盖了。过去你得用 LangChain 的 AgentExecutor 才能让模型循环跑起来现在你打开 Codex CLI它天然会循环。过去工具调用要写一堆 JSON Schema现在使用 MCP工具挂上去就能用。Framework 在这块的价值被显著稀释。2.3 传统 Framework 仍然稀缺的能力但Framework 也不是完全被干掉它在几个方向上依然有不可替代性。第一个是领域 Agent 的业务编排。如果你要做一个“读取进件材料 → 提取关键字段 → 调用审核接口 → 生成批复意见”的流程这里面的每个环节都需要和现有系统联动。它不只是让模型在代码库里改文件而是要和数据库、消息队列、审批系统打交道。这种流程需要明确的步骤、异常分支、人工介入点用 Framework 定义会很顺。第二个是多 Agent 的分工和角色关系。Coding Agent Runtime 擅长的是“一个全能 Agent 从头干到尾”但业务场景经常需要“规划者、执行者、审阅者”的三角色配合。Framework 对这种角色通信和任务分配提供了一整套抽象而 Coding Agent Runtime 目前没有直接等价物。第三个是模型和环境的可移植性。Framework 通常能让你轻松更换底层模型。你可以在同一套业务逻辑下从 GPT 换到 Claude 或开源模型。Coding Agent Runtime 则更像一个完整产品模型调用、工具、权限都是它的内部实现你很难只替换其中一个组件。当然如果你完全接受某个 Runtime 的产品形态可移植性就不重要了但如果你还想保留选择权Framework 更灵活。第四个是非 CLI 场景的集成。想象一个面向运营人员的 Web 界面运营人员点按钮触发 Agent 干活Agent 再把结果推送到企业微信。这种场景里CLI Runtime 只适合做后台执行器前面的状态流转、用户确认、权限管理还得靠你自己的服务实现。传统 Framework 与后端代码结合更紧密适合这种场景。所以我的判断是传统 Framework 不会立刻消失但它的重心正在从“执行层”全面转向“应用层”。3. 真实项目里到底该选哪套方案说了这么多理论落到项目上还是要做选型。我把过去几个月接触过的项目场景分成三类分别给出倾向性判断。3.1 适合直接用 Coding Agent Runtime 的场景如果你做的东西本质上就是“让 AI 去碰代码仓库”那直接上 Coding Agent Runtime 是最高效的。比如自动修复测试失败、批量重命名接口、升级依赖库、生成 API 文档、写迁移脚本。这些任务的特点是目标对象是代码本身输出结果也是代码变更任务过程中需要读文件、跑命令、反复试验。这正是 Runtime 最擅长的事情。我在一个老项目里验证过这种场景。那个项目有个永不过期的 TODO把所有模块的日志打印改成统一规范。人工改很枯燥我用 Codex CLI 把任务扔进去给它列出涉及的文件清单和规范说明它自己 grep、自己改、自己跑 lint。我唯一做的就是中途批准了几次格式化命令。这个过程用了不到半小时比框架方案少写了一堆胶水代码。另外如果你有 CI 自动化需求也可以把 Runtime 当作一个可编程的“修理工”。比如 nightly 构建崩了可以让 CI 自动拉取失败日志让 Coding Agent 提交一个修复 PR。这个模式就是把 Runtime 嵌入到现有工程流程里不需要另外起一个 Agent Framework 服务。3.2 适合保留传统 Framework 的场景反过来如果你的 Agent 要处理的是业务数据而不是代码文件那传统 Framework 依然很舒服。典型例子是客服 Agent用户发来一句投诉Agent 做情感分析、翻订单、查物流、判断是否触发退款策略再生成回复。这个流程和“代码文件系统”没有关系它要打的是企业内部 API要落的是业务数据库还往往要遵守固定的审批流程。用 Framework 来定义流程状态机比让一个通用 Coding Agent 自由发挥要可靠得多。多 Agent 应用的场景也一样。我见过一个项目用多个角色 Agent 模拟项目评审过程一个负责提方案、一个负责找漏洞、一个负责给结论。这种角色之间的消息流转和任务分配是有明确规则的。用传统框架你可以精确控制谁在什么时候发言、结果如何汇聚如果用 Coding Agent Runtime你很难做出这种多 Agent 的协作机制。还有一类容易被忽略如果你要把 Agent 能力嵌入到自己产品的后端比如提供一个 Web API 给前端调用传统框架会更好集成。因为你的系统本来就有用户体系、权限体系、任务队列Agent 只是其中一个模块。Framework 可以很好地和现有代码融合而单独拉起一个 Coding Agent Runtime 进程来提供 API 反而有点重。3.3 一份可以抄的选型清单我做选型一般先回答下面五个问题答案基本能确定方向任务的核心对象是“代码仓库”还是“业务数据”前者偏向 Coding Agent Runtime后者偏向传统 Framework。执行场景是不是本地 CLI 或 CI 环境能接受Runtime 优势明显非要在 Web 后端跑Framework 更顺手。是否需要频繁介入控制 Agent 的每一步需要强流程控制选 Framework只要最终结果正确选 Runtime。是否需要多个 Agent 扮演不同角色互相协作要就选 Framework不要就选 Runtime。你更在意长远的“模型可替换性”还是短期内“跑出效果”前者选 Framework后者选 Runtime。这五个问题不是绝对的但能帮你在第一次接触新项目时快速定方向不用在框架和 Runtime 之间反复横跳。判断维度倾向 Coding Agent Runtime倾向传统 Framework任务对象代码、文件、命令业务数据、业务流程使用环境CLI、IDE、CIWeb 服务、企业应用控制粒度粗粒度管结果细粒度管步骤多角色协作弱强模型可移植弱强上手速度快慢需配置4. 实操把 Coding Agent 当 Runtime 用起来如果不能亲手试一遍前面那些分析始终是纸上谈兵。我建议你花一晚上时间把 Coding Agent 真正当成一个 Runtime 来使用而不是把它当聊天框。这里分享一套我实际跑过的操作路径。4.1 最小配置让 CLI Coding Agent 跑起来以 Codex CLI 为例最小启动路径大概是安装命令行工具登录 ChatGPT 账号完成认证进入交互会话给它分配第一个任务。npm install -g openai/codex codex login登录完成后你可以直接运行codex它会启动一个交互式会话。你输入“看看当前目录里哪个测试最容易挂先跑一遍然后把问题最多的文件告诉我”它会自己开始跑测试、分析结果、汇总。第一次用的时候建议在独立的 Git 分支上操作因为它的行为比你预想的更主动。我踩过的坑是权限模式。Codex CLI 有几个权限模式比如每次操作都问我、自动批准安全命令、或者把高风险命令丢进沙箱。我一开始图省事选了全自动结果它执行了一个清理命令差点把我本地的编译缓存删掉。后来我改成了“只自动批准读取类命令写入类命令必须确认”体验稳定很多。我的建议是第一阶段先用“逐条确认”跑几个小任务摸清它的习惯再逐步放宽权限。另外如果你有本地模型偏好也可以指定模型。Runtime 的价值本来就在于不改变模型接口的情况下让模型在一个受控环境里自由操作。你用旗舰模型跑重活用轻量模型跑简单任务这都是运行时层面的调度自由。4.2 用 MCP 接入自己的工具而不是再套一层 Framework很多人问我需要让 Agent 调公司内部的构建状态查询接口到底要不要用 LangChain 写一个 Tool我的答案是不需要直接用 MCP 接进去。MCP 的概念可以理解成“Agent 世界的 USB 接口”。运行时负责插口工具负责实现协议。你不再需要把工具封装成某个框架的 Tool 类只需要实现一个 MCP Server然后在 Coding Agent 的配置里注册一下。我写过一个很简单的 MCP Server 片段用来让 Agent 查询内部构建状态大概长这样from mcp.server import Server from mcp.types import Tool, TextContent server Server(build-info) def get_build_status(module: str) - str: # 实际代码里这里会去请求内部 CI 的 API return f{module}: current build is green server.list_tools() async def list_tools(): return [Tool(nameget_build_status, description查询某个模块的构建状态, inputSchema{type: object, properties: {module: {type: string}}})] server.call_tool() async def call_tool(name: str, arguments: dict): if name get_build_status: return [TextContent(typetext, textget_build_status(arguments[module]))]然后在 Coding Agent 的配置文件里加上{ mcpServers: { build-info: { command: python, args: [mcp_server.py] } } }配置好之后Agent 在对话里自然就能调用get_build_status这个工具而且它知道这个工具是干嘛的会在合适的时机自己调用。整个过程不需要写任何 Framework 编排代码。这就是 Runtime 带来的体验变化工具接入从“写代码”变成了“配协议”。4.3 权限、钩子和可观测性才是 Runtime 的灵魂我越来越觉得Coding Agent Runtime 真正值钱的不是“模型聪明”而是它把 Agent 执行过程变得可控、可审计、可回滚。权限配置上我现在的做法是默认一切操作都要经过批准只把高频、低风险的命令加到自动允许列表。比如git status、grep、cat、pytest这类我直接放行但rm -rf、git push --force、npm publish这类必须人工确认。Runtime 底层做了命令分类比自己在 Framework 里写一套权限中间件省事太多。Hooks 也是一个被低估的能力。你可以定义 Agent 在某个阶段自动触发外部脚本。比如任务开始之前自动创建新的 Git 分支任务结束之后自动整理 changelog。这相当于给 Runtime 加了可编程的“生命周期回调”很多框架功能反而要额外封装才能实现。可观测性方面Runtime 自带完整会话记录每一步决策、一次工具调用、一个错误输出都在日志里。出问题时能精确复盘是哪一步把仓库弄坏了。传统 Framework 通常需要接第三方的 trace 系统而 CLI Runtime 开箱即有。5. 常见问题和避坑把 Coding Agent 当 Runtime 用看起来顺理成章但实际操作中你会遇到一堆边界模糊的问题。这里分享几个我亲测过的判断和避坑方法。5.1 开始套框架前先问自己三个问题第一个问题你想要的到底是“一个能自主改代码的机器人”还是“一个以 Agent 为核心的产品”如果要的是前者直接上 Runtime框架只会增加你的心智负担如果要的是后者框架能帮你把业务状态、鉴权、流程控制做得更严谨。第二个问题这个 Agent 是被一个人临时调用还是被整个团队/外部用户长期调用临时调用不需要框架抽象你只要保证效果和可回滚长期调用则要考虑配置管理、工具版本、多环境部署这时候 Framework 的统一抽象能帮上忙。第三个问题你是想快速验证业务价值还是构建一个可维护的技术资产为了验证价值用 Runtime 最快因为它的默认行为就是最优实践为了构建技术资产你可以选择在 Runtime 外围封装一层薄薄的适配层而不是把一个重量级框架作为地基。我见过最尴尬的案例是有人为了“跟风上框架”给 Coding Agent 外面包了一层 LangChain但 LangChain 什么都没做只是多绕了一道模型抽象。最后结果就是代码复杂了、调试难了、效果也没变好。所以不到必要时别主动加中间层。5.2 传统 Framework 会消失吗我的看法是传统 Framework 不会消失但会逐渐明确自己的边界。Coding Agent Runtime 吃掉了执行层以后Framework 的生存空间主要剩两块。第一块是业务 Agent 的开发框架它依然处理大量和业务系统打交道的场景比如状态机、人工审批、多角色对话。第二块是“元编排层”未来你手上可能同时有多个 Coding Agent Runtime每个负责不同的代码库或任务你需要一个上层调度的东西来决定把任务分给哪个 Runtime、如何汇总结果。传统 Framework 在这里有机会因为它擅长把复杂交互抽象成可管理的流程。不过这需要 Framework 主动改变定位。如果它继续把“执行循环”“工具分发”作为核心卖点那确实会慢慢被 Runtime 边缘化。反过来如果它把自己定位成“连接多个 Runtime 的服务编排层”它的价值反而会因为 Agent Runtime 的普及而变大。5.3 我实际用的三种组合模式第一种是纯 Runtime 模式。所有任务直接交给一个 Coding Agent Runtime人只做最终 review。适合单仓库、非关键路径、个人效率提升。第二种是 Runtime 加轻量调度。我不引入重量级框架而是用一个 Makefile 或者 CI 脚本来管理多个任务。比如“修这几个 issue”就是一个 Makefile target它触发 Codex CLI 跑完所有任务再自动校验测试结果。这种模式轻巧、易维护团队里其他人也能看懂。第三种是 Framework 编排多个 Runtime。当你有多个不同职责的 Agent 时用一个上层框架来管理它们。比如一个 Agent 负责分析日志一个 Agent 负责改代码一个 Agent 负责写测试最终由一个协调者把三期结果合并。这时候 Framework 更多是“编排器”而不是“执行器”。我目前推荐第二阶段也就是“Runtime 轻量调度”。它既保留 Coding Agent Runtime 的高效又不需要为一个简单流程引入过于复杂的抽象。等任务规模大到你自己都记不住哪些流程该怎么走时再考虑第三阶段的 Framework 编排。我自己跑了几周 Coding Agent Runtime 之后体会比较深的一点是先别急着问“Framework 还有没有用”应该先问“我要解决的问题到底是在执行层还是在应用层”。如果你需要的只是一个能在代码仓库里自主干活的 Agent那 Runtime 已经是答案你再往上套一层框架反而像是给已经会呼吸的人装呼吸机。但如果你在构建一个需要多人使用、和业务强耦合的 Agent 系统那传统 Framework 的流程抽象和状态管理能力依然是你值得保留的底牌。最后再分享一个小技巧拿一个你最不想干、但又规则明确的重复性任务先不写任何框架代码直接用 CLI Coding Agent 跑一遍。跑通之后再回头看框架的文档你会比任何时候都清楚哪些抽象是必要的哪些只是在给架构图增加复杂度。动手跑一次胜过读十篇选型文章。