聊起大模型写代码不少人的第一反应还停留在“让它生成一个排序函数”之类的片段级任务。但最近开发者圈子里密集讨论的GLM-5已经把这件事往前推了一大步它试图让模型不是“帮你想代码”而是“替你把整个工程跑起来”。这篇文章就以GLM-5为观察样本聊聊从Vibe Coding到Agentic Engineering这次范式转移到底意味着什么以及我们这群靠代码吃饭的人要怎么调整自己的干活方式。文章里的方案、参数和流程一部分来自我自己的实测一部分来自和同行交流后整理出的相对稳健的做法。我没有照搬某个产品文档而是把它们整理成一套可以直接复用的操作框架。适合正在评估AI辅助开发、想让Agent真正上手跑项目、或者对“模型自主写代码”边界感兴趣的开发者。无论你是独立开发者还是团队里的技术负责人下面这些内容应该都能派上用场。1. 从Vibe Coding到Agentic Engineering编程范式正在换挡1.1 Vibe Coding解决了什么又留下了什么“Vibe Coding”这个词最初描述的是一种跟着感觉走的编程方式开发者用自然语言描述需求模型生成代码人觉得差不多就复制进项目跑不通就继续改提示词。它确实让编程门槛降低了不少也让很多非科班朋友第一次体验到了“能动手做东西”的快感。但从工程视角看它本质上是人在回路中的生成式补全——模型只负责产出代码片段上下文、系统设计、依赖关系、验证策略全都压在开发者肩上。这种方式有非常明显的天花板。模型生成的代码没有全局状态概念它对项目的理解只局限于对话窗口里的那几段内容它不会主动去读取其他文件、不会自己跑测试、也不会在报错之后尝试修复。换言之Vibe Coding解决的是“写代码”这个环节但工程里真正耗时的“让代码在系统里跑起来”这件事它几乎没碰。1.2 Agentic Engineering的核心特征是什么Agentic Engineering描述的是一种更完整的形态模型不再是一个被动的生成器而是一个能够感知环境、做出决策、执行动作、并根据反馈自我修正的工程实体。它会把一个模糊的目标拆解成一系列具体的子任务主动调用工具去读取文件、修改代码、执行命令、运行测试然后根据结果调整策略继续推进。这里的关键差异在于“闭环”。Vibe Coding是单轮对话Agentic Engineering是多轮自主执行Vibe Coding靠人把上下文喂给模型Agentic Engineering靠模型自己从环境里抓取上下文Vibe Coding失败后靠人来改提示词Agentic Engineering失败后靠模型自己读日志、改代码、重试。对比维度Vibe CodingAgentic Engineering上下文来源对话窗口内的人工粘贴模型主动从文件系统、命令输出中获取任务粒度函数级、片段级模块级、系统级迭代方式人改提示词后重新生成模型根据测试反馈自主修改验证手段人肉运行并检查模型自动编写并运行测试失败处理人介入排查模型读错误信息并自我修复人的角色翻译官和质检员目标设定者和最终验收者这不是一个简单的版本升级而是工作范式的换挡。之前我们是在“使用”一个生成工具现在是在“管理”一个执行体。“管理”意味着你要学会拆目标、定约束、设检查点这些能力跟传统编程不太一样但同样可以系统性地训练。2. 拆解GLM-5的“自我写代码”能力2.1 从代码补全到自主工程能力分层要理解GLM-5这类前沿模型的“自我写代码”先得把能力分出层次。我习惯用下面这个分层模型来思考L0 片段补全自动补全变量名、函数体类似常见的补全插件。L1 函数生成根据自然语言描述生成可运行的函数处理输入输出和异常。L2 模块搭建能一次性生成包含多个函数、多个文件的模块基本遵守项目现有风格。L3 工程执行能自己读项目结构、修改多个文件、运行测试、修复报错直到任务完成。L4 自我进化能根据历史经验调整自身的行为模式沉淀项目级的最佳实践。GLM-5对外展示的“自己写代码”并不是指L1或L2层面的内容生成而是L3层面的工程执行能力。L3和L2之间隔着一条很大的鸿沟生成模块只需要局部注意力但工程执行要求模型具备全局状态跟踪能力——它得记得自己改过哪个文件、哪里的依赖还被谁引用着、哪个测试失败是因为哪个变更引起的。2.2 四个关键能力长程规划、工具调用、自我验证、多语言协同我拆解了这类模型在工程执行上真正起作用的四件事第一长程规划。给模型一个需求比如“给这个项目加上用户登录功能”它不能直接闷头写代码而是要先把需求拆成一个可执行的计划需要新建哪些文件、修改哪个路由、数据库要加什么表、前端要加哪些页面、哪些地方需要鉴权。模型需要把计划以中间产物比如一个PLAN.md文件的形式固化成上下文供后续步骤参照。这个环节的难点在于计划的顺序和依赖关系比如“先建表再写API还是先写API再建表”不同的顺序会影响调试的效率。第二工具调用。模型不能只输出代码还要能“动手”。它需要用一套工具接口去读文件、写文件、执行Shell命令、查询文档。工具调用的质量决定了Agent的上限——如果工具的粒度太粗模型就无法精细修改如果粒度太细模型又会陷入海量调用中迷失方向。GLM-5在这块的思路是提供一个结构化的工具集比如read_file、edit_file、run_command、search_symbol等等并允许开发者自定义工具扩展。第三自我验证。这是“会写代码”和“能建系统”最本质的分界线。一个可靠的Agent必须在完成改动后主动验证而不是直接把代码交给人类。验证分为静态验证语法检查、类型检查、Lint和动态验证运行测试、手动构造边界用例。GLM-5的做法是先自动生成测试用例或复用项目已有的测试运行后读取失败信息再回到代码修改形成一个内部循环。第四多语言协同。一个真实项目很少是单一语言的。一个后台接口可能要写Python、前端要用TypeScript、配置要写YAML、查询要用SQL。模型需要在多个语言和文件之间来回切换保持数据流的一致性。比如改了后端返回结构那么前端的类型定义也要同步更新。这种跨文件、跨语言的协同能力恰恰是早期代码生成模型最薄弱的地方。2.3 为什么“会写”不等于“能建”很多人对“大模型写代码”有一个误解既然它能写出正确的函数那给它一个复杂点的需求它应该也能写出来。但真实情况是会写句子不等于会写小说。一个函数只要关注自己内部的输入输出而一个系统要处理的是多个函数之间的交互、共享状态、异常传播、性能瓶颈和演进路径。举个例子让模型写一个merge_sort很容易但让它在一个没有测试框架的项目里加入“对账模块”并保证不破坏原有的批处理流程难度就完全不同了。它需要先理解现有项目的架构风格、找到合适的插入点、设计边界情况、为改动写测试还要跑通旧用例。这个过程中的每一步都可能出错而真正的系统构建能力体现在从错误中恢复——模型读报错、定位问题、修正逻辑、再次运行直到进入收敛状态。3. 实操指南用GLM-5跑一个Agentic工作流3.1 环境准备与最小配置先说环境。要跑这样的工作流你需要一个能够提供GLM-5模型能力的接口可以是一个本地推理服务也可以是一个兼容OpenAI协议的远程接口。我习惯在Python环境里通过openai客户端库来对接只需要配置好base_url和api_key两个参数。pip install openai export GLM_API_KEYyour-key-here export GLM_BASE_URLhttp://your-endpoint/v1然后写一个最小客户端脚本确认模型能跑通from openai import OpenAI client OpenAI( api_keyyour-key-here, base_urlhttp://your-endpoint/v1 ) resp client.chat.completions.create( modelglm-5, messages[{role: user, content: 返回一句话说明你能做什么}] ) print(resp.choices[0].message.content)这步看起来简单但有个细节值得强调务必保持请求环境的纯净和可复现。Agent跑出来的结果跟模型版本、温度参数、工具定义都强相关最好把运行环境固化成一个Docker镜像或一份requirements.txt否则下次复现时容易扑空。3.2 任务设定让模型自己拆解需求很多人让Agent干活失败不是因为模型不够强而是任务描述写得太模糊。你需要给Agent一个可执行的目标文件我通常用task.md来承载。里面包含五个部分项目背景、目标描述、约束条件、验收标准、允许使用的工具清单。下面是我常用的模板# 任务实现一个命令行待办事项工具 ## 背景 当前仓库是一个空目录需要从零搭建一个Python CLI工具。 ## 目标 用户可以通过命令行添加、查看、完成和删除待办事项数据持久化到本地文件。 ## 约束 - 只使用Python标准库不引入第三方依赖 - CLI接口通过 argparse 实现 - 数据文件默认保存在 ~/.todo.json - 所有函数必须有类型注解和docstring ## 验收标准 - 运行 python main.py add 写周报 后python main.py list 能列出该事项 - 运行 python main.py done 1 后该事项状态变为已完成 - 对空参数和非法索引有明确的错误提示 - 重复运行命令不会导致数据丢失把问题定义清楚之后Agent的“长程规划”能力才有施展空间。它会把上面这个任务拆成“初始化项目结构、定义数据模型、实现文件存储、实现CLI逻辑、编写自测脚本”几个子步骤并创建一个PLAN.md来记录自己的执行计划。检查PLAN.md是很有价值的动作你能在它动手前就看出理解是否偏了。3.3 工具生态让Agent真正动手改文件要让Agent动手光靠对话接口是不够的。我写了一个轻量的Agent运行时核心是一个tool_loop——把模型每次返回的“工具调用请求”翻译成真实的文件操作和命令执行再把结果反馈给模型。import json import subprocess from pathlib import Path TOOLS { read_file: lambda path: Path(path).read_text(), write_file: lambda path, content: Path(path).write_text(content), list_files: lambda path.: \n.join(str(p) for p in Path(path).rglob(*)), run_command: lambda cmd: subprocess.run( cmd, shellTrue, capture_outputTrue, textTrue, timeout30 ).stdout, } def call_model(messages): # 调用GLM-5接口解析返回的tool_calls字段 pass def tool_loop(task_md: str): messages [{role: user, content: task_md}] for _ in range(50): resp call_model(messages) if resp.get(tool_calls): for call in resp[tool_calls]: name, args call[function][name], json.loads(call[function][arguments]) result TOOLS[name](**args) messages.append({ role: tool, tool_call_id: call[id], content: str(result), }) else: # 模型认为任务完成输出最终总结 print(resp[content]) break这个顺手写的运行时虽然简陋但已经足够说明Agent的执行逻辑模型通过结构化指令请求动作运行时负责执行并把结果变成新的上下文。关键点是max_iterations参数我设成50轮防止模型陷入无限循环。实际跑下来合理的任务一般在10到20轮内能收敛超过这个阈值就该人工介入了。这里有一个非常重要的细节工具返回的内容别太大。如果run_command返回的日志有几百行会迅速塞爆上下文窗口导致模型丢失早期信息。我通常会加一个tail或head截断只保留最近几十行。记住一句话Agent的上下文不是拿来存日志的是拿来存决策依据的。3.4 验证闭环让Agent自己审代码工具循环里如果没有验证环节Agent很容易陷入“自我感觉良好”的状态——代码写完了但一跑就崩。真正的Agentic工作流必须包含一个验证者和执行者分离的机制。执行者负责写代码验证者负责跑测试、挑毛病、把失败理由写清楚再回到执行者手里去修改。我在上面那个运行时里加了一个规则每当模型完成一个阶段性的文件改动它必须调用run_command去执行自己创建的测试脚本并把输出结果读回来。如果失败就根据具体的错误信息去修改代码再试。经过这样几轮循环最后得到的不只是一段看起来合理的代码而是一个被测试证明能跑起来的交付物。下面是我在项目中实际跑出来的简化交互轨迹模型创建 main.py完成TODO项的数据模型和存储逻辑 模型创建 test_todo.py包含添加、列出、标记完成、删除四个测试用例 模型运行 python test_todo.py - 发现json读写路径的目录不存在 模型修改存储逻辑在写文件前增加mkdir(parentsTrue) 模型再次运行 python test_todo.py - 全部通过 模型运行 python main.py add 测试项 python main.py list - 确认CLI输出正常 模型输出完成总结这种“写代码→写测试→跑测试→修复→回归”的循环是Agentic Engineering最重要的核心。模型在循环中展现出的能力上限取决于两个因素一是测试用例设计得是否足够刁钻二是错误信息是否足够还原现场。所以如果你发现Agent反复改不对先别急着怪模型检查一下你的测试是不是覆盖了真正的边界条件。4. 从“代码生成”到“代码交付”质量与安全控制4.1 让Agent学会写测试TDD的反向实践传统开发中测试先行但在Agent场景下我更喜欢“反向TDD”先让Agent把功能写出来再强制它写测试去验证自己的代码。这种方式对Agent的约束力更强——功能代码好不好最终由测试说了算。GLM-5支持的“自我验证”如果配合完善的测试框架效果会非常明显。我一般会在任务描述里明确要求## 验证要求 - 使用pytest编写测试覆盖正常路径、边界路径、异常路径至少各一个 - 质量门槛测试必须能运行通过且语句覆盖率不低于80% - 若任何测试失败必须阅读错误堆栈、修正代码后重新运行直到全绿这里要留意“覆盖率不低于80%”这类硬性数字。模型对百分比的理解可能很机械会为了凑覆盖率写出一些“假测试”比如只调用函数但不断言结果。所以验收时我会抽看几个测试用例的断言质量。测试的价值在于断言不在于调用。你可以用pytest --cov看覆盖率但要留意那些只有调用没有断言的“空转测试”。4.2 人机协作的最佳节奏什么环节人必须介入虽然Agent能自主执行不少任务但有一些环节我建议人工介入绝不让步。我总结了四个必须人盯的节点需求澄清阶段模型对“用户想要的”理解再快也不能替代人和真实业务方确认意图。不要让模型替你做一个你不理解的产品决定。架构选型阶段在多种技术方案之间取舍时例如“该不该引入消息队列”“要不要拆微服务”模型容易给出“看起来合理但不适配团队现状”的建议。安全审查阶段涉及鉴权、支付、敏感数据处理的代码绝不能只靠模型自测。人必须逐行审查并额外进行安全测试。上线前验收阶段Agent说“完成了”不等于可以发布。必须由人走一遍真实场景的冒烟流程确认产品层面没问题。除此之外的过程可以大胆放手。把一个任务完整地交给Agent跑自己在旁边看着它报错、修复、再报错其实很像在带一个很聪明但没有工程经验的新人。你的角色不是每一步都插手而是设置好边界然后在关键路口值班。4.3 常见翻车现场与排查技巧实录这一节是我最想写的。Agent听起来很美真正跑起来的时候坑比想象中多。我把我踩过的、以及从同行那里收集到的典型问题整理成了下面这个表常见问题现象排查思路预防措施无限循环Agent反复执行同一段修复报错不变检查是否缺少错误信息截断、上下文膨胀设置最大迭代次数建议20~30设置“发散检测”改A坏B某个功能修好了其他用例回归失败Agent没有跑完整测试集合只验证了局部在任务验收标准中要求“必须全量回归测试”幻觉API模型调用了不存在的库或函数框架初始化时把可用API列表注入上下文在任务描述中明确“只允许使用以下依赖”上下文爆炸执行到一半模型开始答非所问工具返回内容过长把早期关键决策挤出窗口对工具输出做截断中间产物写入文件而不是塞进对话权限失控Agent执行了破坏性命令工具集没有限制危险Shell操作沙箱容器运行工具白名单机制验收假阳Agent宣称“完成”但产品路径走不通自测脚本没有覆盖真实用户操作链路人工冒烟测试必须保留不能被自动化替代以“上下文爆炸”为例这是最容易踩的坑。模型执行到十几轮之后前面拆解的计划、已经读过的文件内容、跑过的日志全都堆在上下文里。到后来模型往往“忘记”了自己最初的目标开始凭感觉乱改。我的对策是持续把关键状态固化到文件里——比如每个阶段完成之后更新PLAN.md、把阶段性产物写进progress.md。这样即使上下文被截断模型也能通过读文件重新找回上下文。“幻觉API”也很典型。模型有时候会自信地写出一个不存在的库比如在标准库环境里引入requests。解决办法不是靠模型自觉而是在系统提示词里明确给出“可用依赖清单”并在运行时用tool封装一个依赖检查工具让模型调用之前先验证包的可用性。Agent和人一样边界越清晰发挥越稳定。5. 对开发者工作方式的冲击与应对思路5.1 独立开发者从“一人写代码”到“一人管一支Agent团队”Agentic Engineering最直接的机会体现在独立开发者身上。以前一个人要包揽前端、后端、运维、测试的活儿现在你可以用多个不同职责的Agent来分担。一个Agent负责探索技术方案一个Agent负责写后端接口一个Agent负责写前端页面你只需要在最顶层把需求拆清楚然后验收它们的交付物。我实际尝试过用这种方式做一个内部工具。我的角色从“写每行代码”变成了“定义任务书、审查产出、处理Agent之间的接口问题”。最明显的变化是时间消耗从“编码”转移到了“定义和验收”而这两件事恰好是可以复用的经验积累。你定义任务的质量越高Agent的产出就越稳定。当然也要泼一盆冷水独立开发者仍然需要懂架构、懂业务、懂质量。Agent只是把你的手放大并没有替代你的大脑。如果一个需求在拆解的时候就是错的那么再强的Agent也只能把错误实现得很完美。5.2 团队协作模式从“结对编程”到“人机结对”在团队场景里Agentic Engineering改变的不只是个人效率还有协作关系。传统的“结对编程”是两个人盯一段代码现在变成一种更不对称的模式人和Agent结对。人负责提供上下文、确定验收标准、审查关键路径Agent负责快速产出初稿和重复性工作。这种模式下代码评审的形式也在变化。逐行看Agent生成的代码变得不现实更高效的方式是“计划评审结果评审”先评审Agent的执行计划和测试方案再评审最终的测试报告和变更差异。评审的粒度上移到“需求理解得对不对”“验证做得够不够”而不是“某个变量命名是否优雅”。团队里还需要一个新的角色定位——Agent工作流设计师。这个人负责设计任务模板、维护工具集、制定验证标准、持续改进Agent的提示词和流程。这有点像以前的自动化测试工程师但面向的对象从测试框架变成了整个AI开发生命周期。5.3 技能树的重绘编码能力还重要吗很多人问模型都会自己写代码了我们还需要学编程吗我的回答是基础编码能力仍然是地基但登堂入室的本事变成了“拆解、验证与决策”。未来的开发者核心技能会变成这样几项任务拆解能力把模糊的业务需求拆成Agent可以执行的原子任务。这比写代码更难因为它需要你理解系统结构、依赖关系和验收路径。验证设计能力设计高质量的测试用例和验收标准保证Agent的产出真的可用而不是看起来可用。安全边界意识在Agent具备执行能力之后权限控制变得性命攸关。你需要懂得如何在沙箱里运行Agent、限制文件访问范围、在危险操作前设置审批节点。经济性判断API调用是有成本的Agent每跑一轮都在烧钱。你需要判断哪些任务适合交给Agent自主执行哪些任务一句话让人工做反而更划算。说到底编程的本体不是“敲键盘”而是“把想法转化成一个可运行的系统的能力”。键盘可以交给Agent但转化系统的那套思维短期来看还很难被替代。只不过它换了一种表现形式——从“这个函数怎么写”变成“这个任务怎么拆、这个验证怎么收”。写在最后几个月实操下来我最大的感受是GLM-5这类模型有多聪明反而不如我的工程习惯重要。我把任务拆得足够细、把验证标准写得足够硬它就跑得又快又稳我一旦偷懒想靠一句模糊的需求让它“自己看着办”它立刻就能给我整出五花八门的返工现场。Agentic Engineering真正考验的不是一个会写代码的模型而是一个会管理Agent的工程师。如果你正准备把手头项目交给Agent去跑我的建议是别一上来就挑战复杂系统。先拿一个一周可以手动搞定的内部小工具练手在它身上把任务文件模板、工具集、验证闭环跑通积累属于你自己的“Agent工作流手感”。这套手感才是模型怎么换你都不慌的真正底气。