最近技术圈里有一个讨论挺能反映现状有人在 Hacker News 上直接发问“Agentic Programming 是不是已经失败了”。这个标题放在一年前可能没什么人理会因为那时候大家还在为 AI 能自动修复一个 bug、能连续修改多个文件而兴奋。但几个月过去风向变了越来越多的开发者开始分享 Agent 在真实项目里翻车的经历改错了文件、删掉了不该删的逻辑、跑出一个无法理解的中间状态……于是“失败论”开始流行。我自己也把 Agentic 编程放进真实项目里用了大半年结论和“彻底失败”不太一样。我的体感是Agentic 编程没有失败它只是从一个让人兴奋的演示阶段进入了一个更无聊、更麻烦、也更考验工程能力的落地阶段。很多人觉得它失败了是因为我们一直在用错误的尺子量它——我们用“AI 能不能替代程序员”的标准去评估但它真正改变的是“任务如何被拆解和执行”。 这篇文章不是给 Agent 编程唱赞歌也不是劝退。 我想做的是把它放到真实工程环境里看它真正解决了什么、误伤了什么、 需要在什么条件下才能变成可用的生产工具。1. 先回答“是不是失败”之前得先分清人们失望的到底是什么1.1 大家期待的 Agent 编程是一幅想象图我注意到一个规律越是没在真实项目里长时间用过 Agent 的人越容易对它抱有过高期待。很多人想象的 Agentic 编程是这样一幅场景你告诉 AI“给我做一个电商后台”然后它就自动建项目、建数据库、写后端接口、做前端页面、处理登录权限、部署上线。整个过程像是有个隐形程序员坐在电脑前替你加班。这个想象图不能说是错的但它把 Agent 编程的定义偷偷换掉了——它变成了“无人编程”而不仅仅是“代理式编程”。如果按这个标准衡量今天市面上几乎所有 Agent 工具都是失败的因为它们远远做不到端到端替代一个经验丰富的工程师。问题出在我们把“能自动拆解并执行一些子任务”放大成了“AI 全自动做软件”。而在 Hacker News 这类技术社区里失望情绪又被放大了一轮。因为这里的用户普遍具备工程背景他们不是拿一句 AI 生成的代码随便跑跑而是直接把 Agent 丢进一个存在多年的仓库里让它修复一个跨模块的 bug。结果当然不理想依赖关系、接口文档、历史约定、隐式规则任何一个环节不完整Agent 就会开始“自信地犯错”。1.2 技术圈对“失败”的判定往往太快另一个问题是技术圈对新事物的评价周期总是太短。一个工具从出现在 GitHub Trending 到被判定“凉了”中间可能只需要三个月。但很多真正产生价值的技术从来不是在三个月里见效的它需要一段缓慢渗透期先从能驾驭场景的人手里扩散到大众视野。Agentic 编程现在就处在这个尴尬阶段第一波宣传效应已经消退早期尝鲜者发现它不能解决所有问题而后面的质疑声会比赞美声传播得更快。如果看绝对能力Agent 写出的代码质量、执行多步骤任务的稳定性其实一直在缓慢上升但大众对它的感知会被一两次灾难级翻车彻底盖过。我在自己的实践里也有过类似的情绪波动。最开始用 Agent 时它成功完成了一个数据迁移脚本的编写我一度觉得以后是不是可以少写一半代码。后来让它处理一个带有历史包袱的老服务它连续改了三个文件结果把原本可以正常启动的服务改崩了。那种挫败感确实会让人想发一个“Agent 编程是不是失败了”的帖子。1.3 用一句代码生成能力来评价 Agent 是维度不对更深一层的问题是很多人拿普通 AI 编程助手的评价维度来审视 Agent比如“它生成的函数是不是正确”“它能不能记住我上一句话”。但 Agent 编程的关键变量根本不在这里。普通编程助手是“增强单点能力”的它帮你补全函数、生成测试、解释报错你仍然是流程的掌控者。Agent 编程则试图把一段“包含多个步骤的任务”整体交出去它自己决定先做什么、后做什么、中间遇到错误怎么处理。两者的差距类似于一个是计算器帮你算得更快另一个是实习生你能把活儿包给它但要为最终结果负责。所以如果只测试“让它写一个排序算法”Agent 编程的体验可能比普通 AI 助手好不了多少但如果是“让它在项目里找到一个配置文件修改日志级别重启服务并确认新日志是否生效”Agent 的价值就出来了。评价维度的错位是很多失败论的来源。2. Agentic 编程真正改写的不是“写代码”这个动作而是任务组织方式2.1 从“编辑器里补全”到“按目标拆解任务”传统 AI 编程助手解决的是“怎么写某段代码”的问题Agentic 编程解决的是“怎么完成一个任务”的问题。这两者差别非常大。举个例子。过去我让 AI 助手写一个反爬虫拦截规则它可能会直接给你一段正则表达式或一个中间件函数。它聚焦在“产物”上。而 Agentic 编程的逻辑是先拆出任务清单——抓取日志分析当下被拦截的请求特征、找到现有拦截中间件的位置、设计新规则、写测试、跑回归、确认对其他接口没有影响。每一步它都需要自己规划甚至需要调用工具去查看代码结构。这件事的本质变化是它把“人怎么驱动代码生成”变成了“人怎么驱动任务执行”。人从定义“每一行代码长什么样”的细节里退出来去定义“这个任务到底要覆盖哪些范围、边界在哪、验收条件是什么”。2.2 Agent 的核心能力是循环执行、观察、纠错、再执行很多人把 Agent 理解成“话更多的 AI”。实际上Agent 真正区别于单次对话的地方是它拥有一个循环结构执行一个动作 → 观察结果 → 判断是否符合预期 → 不符合就调整 → 再执行。这个过程有点像驱动程序里的控制循环也像人的工作方式先试一步看反馈修正方向。这个循环听起来不复杂但它给编程带来的影响很深远。过去 AI 生成完代码链条就结束了你只能手动复制到项目里测试。而 Agent 可以在生成代码之后继续执行测试命令、读取报错、修改实现、再跑一次测试直到通过或宣告失败。这意味着 AI 第一次从一个“生成器”变成了一个“执行器”。它不再只输出文本而是能在沙箱或真实环境里产生副作用。可不要小看这个变化——副作用是工程世界里的万恶之源也是 Agent 翻车概率飙升的根源。2.3 这意味着人从“每行代码的执行者”变成“目标和边界的定义者”在工作流层面Agentic 编程对人的能力要求发生了迁移。过去写代码核心能力是语法、算法、框架、调试现在驱动 Agent 写代码核心能力变成了目标拆解、验收标准设计、风险边界划定。我有一个很直接的感受能写好提示词的人不一定能驾驭 Agent但能把需求文档拆得足够细、把接口边界定义得足够清楚的人往往能让 Agent 跑得比较顺。因为 Agent 不会像人一样主动问“这个需求里的 exception 情况怎么处理”它只会按你给出的信息和上下文自行推断。如果边界定义不够它就会随机选择一个听起来合理的方案。这也可以解释为什么很多程序员会对 Agentic 编程感到不满。因为他们原本最擅长的是判断“这一行代码该怎么写”而现在他们被迫花时间思考“这个任务怎么能被拆得足够安全”。前者是工程师传统的技能树后者更接近技术管理者或架构师的日常。3. 我实践 Agentic 编程时踩过的几个真实分水岭3.1 单轮对话能解决的问题不需要 Agent我刚开始实践时犯过一个大错误把任何不想手写的任务都交给 Agent。后来发现很多任务用普通 AI 编程助手就够了引入 Agent 不会提升效果反而会因为多步骤判断引入更多不确定性。需要先分清楚如果任务没有多步逼近的过程没有“根据上一步结果调整下一步”的必要那它就只是一个代码生成问题而不是代理问题。比如“把这段 Python 改成 Rust 的语法”单轮对话就够但“分析这个仓库里哪些模块依赖了被废弃的 API逐一替换并保证测试通过”就是一个非常典型的 Agent 任务。分水岭就在这里你有没有给它足够的操作空间和反馈回路如果没有你只是在给一个 AI 套了一层更长的提示词本质上没变化。3.2 Agent 的上下文管理远比参数调优重要很多人拿到 Agent 工具后第一件事是调参数temperature 到底设多少、model 用哪个版本、最大 token 开多大。这些参数当然有影响但我在实际使用中觉得真正决定成败的是上下文管理。这里的上下文包括两大部分一是任务本身的描述二是 Agent 在执行过程中观察到的反馈信息。任务描述如果过于模糊Agent 就会依赖自己的“幻觉先验”反馈信息如果被截断或混杂Agent 就会做出错误判断。我自己吃过一次亏。让 Agent 在一个仓库里重构一个函数结果它把另一个同名函数的调用也一起改了。原因就是它的上下文窗口优先装了它自己觉得重要的几个文件而没有真正理解跨模块的调用关系。从那以后我在给 Agent 布置任务时都会额外附上一份“禁止修改文件清单”把明确不要动的文件写进去。3.3 工具授权是便利和风险的分界线Agent 编程和普通 AI 助手的另一个关键区别是它能调用工具。它能执行 shell 命令、读写文件、运行测试、甚至调接口。这带来极大便利但也带来一个非常现实的问题你知道它将要执行什么命令吗你允许它执行那些有副作用的命令吗我见过有人给 Agent 配置了一个拥有服务器最高权限的终端然后让它“把日志里的敏感信息脱敏”。Agent 确实去改代码了但它执行的第一步是扫描了整个项目目录接着访问了一些本该有权限控制的环境变量文件。整个过程工具都忠实地执行了但因为权限给得太大它把本该藏在后面的主机名、内部 IP 都暴露到了对话记录里。这是一个很典型的边界问题Agent 的工具调用能力越强它的破坏半径就越大。如果权限控制、命令白名单、运行沙箱没有跟上Agent 编程越成功事故越严重。3.4 输入输出边界比提示词技巧更能决定结果和很多人想象的不同Agentic 编程里最大的坑往往不在提示词本身而在输入输出边界。输入边界指Agent 能访问哪些文件、哪些命令、哪些网络资源。输出边界指它最终能碰触哪些仓库分支、能触发哪些部署流程、能留下哪些痕迹。如果一个 Agent 只能在一个隔离的开发分支上工作测试通过后再由人来合并那即使它中间出了错影响也是可控的。反之如果直接把它接到主干分支上还给了自动部署权限那一次失败就可能演变成生产事故。所以我现在面对一个新 Agent 工具或工作流时先不看它的代码生成能力有多强而是看它的权限和隔离机制做得怎么样。没有边界保护的 Agent在真实项目里不是帮手是风险源。4. 一套我自己常用的最小可用 Agent 编程流程4.1 前置条件把任务限制在一个可验证的范围内如果要在真实项目里用 Agent我的建议是先不要追求“全自动无人值守”。更稳妥的策略是先跑通一个最小可用流程把不确定性暴露在可控范围内。具体做法是从项目里挑一个边界清晰、自测容易、影响面小的任务。例如“给某个工具函数增加一个可选参数并为它补充测试”或者“把一份 JSON 配置从旧格式迁移到新格式”。不要一上来就选那种涉及多个服务、多个团队、多个遗留模块的任务。另外很重要的一点是在任务开始前必须明确验收标准。标准不能是“代码跑起来就行”而要是“某条测试用例通过、某个日志不再出现、某个接口响应值符合预期”。没有验收标准的 Agent 任务是没法收口的。4.2 第一步让 Agent 先输出计划而不是直接改代码我现在非常强调一个习惯拿到任务后先让 Agent 输出一份执行计划而不是马上动手。这个计划要包含它打算读取哪些文件、修改哪些文件、执行哪些命令、如何验证最终结果。这一步有两个好处。第一能提前看出 Agent 对任务的理解是否准确。如果它的计划里连目标文件都找错了那就应该当场纠正而不是等它改完代码后才发现方向错了。第二计划本身也会成为代码评审的骨架人工审查时只需要对照计划与实际改动。我通常会在提示词里加一句结构“请先列举你的执行步骤包括涉及的文件、命令和验证方式不要直接开始修改。等待我的确认后再执行。”这句话看起来很简单但能避免大量无效操作。4.3 第二步一次只放一个可验证的小任务进来如果是第一次在某个项目里使用 Agent不要一股脑把所有需求都交给它。我建议一次只让它处理一个小任务并且确保每个任务都能通过一条明确命令来验证。比如修改一个函数 → 运行对应的单元测试调整一个配置项 → 启动服务并确认日志输出重构一个模块 → 执行项目的 lint 和类型检查任务越小问题定位越容易。如果 Agent 在一个小任务上表现稳定再慢慢扩展范围如果它连小任务都会频繁翻车那问题多半出在工具配置或上下文质量上而不是任务复杂度上。这个节奏看着慢实际上比“让它一口气改五个文件然后面对一个无法运行的项目”要快得多。因为后者一旦出错你很难判断是哪一步导致的。4.4 第三步人工检查的关键点不是代码风格而是资源、权限和副作用Agent 生成的代码代码风格通常不会太差因为在训练数据里它已经见过大量规范的写法。真正需要人工检查的是那些 Agent 不擅长判断的事情这个改动会不会影响其他服务它有没有访问不该访问的敏感文件它执行了哪些有副作用的命令它在失败后有没有清理临时文件或回滚变更重复执行这个任务会不会产生不同结果我自己在代码评审时会把注意力重点放在“AI 以为它做了什么”和“它实际上做了什么”的差异上。比如 Agent 说自己只改了一个配置文件但实际执行时还动了一个旧格式的备份文件你说过“不要动 algorithm 目录”它却因为想跑测试而往里面写了一个临时文件。这些都不是代码风格问题而是工程管理问题。一个没有人工 review 的 Agent 流程会把这些细节全部掩盖掉。4.5 从单次到批量的保守推进方式单次任务跑通后你可能会想批量处理更多任务。我的建议是不要一次性把所有任务丢给同一个 Agent 去跑而是设计成一个可重复执行的流水线每个任务独立记录日志、独立验证、独立产出差异展示。批量处理时我会重点关注失败率。如果 10 个任务里有 3 个需要人工介入说明 Agent 对这个项目类型的理解还不够需要补充上下文或调整任务拆解方式。如果 10 个任务里有 9 个能顺利通过我才考虑让它处理更高风险的任务。这个“从单到批”的过程本质是一个压力测试。它不是在测试 Agent 能写多少代码而是在测试你对 Agent 行为的安全控制能力。 注意不要一上来就把批量数和并发数拉满 先用一条样例确认输入、输出和日志都正常再逐步扩大范围。5. 适合与不适合 Agent 编程的场景边界5.1 适合重现步骤明确、自测容易、上下文封闭的任务适合 Agent 的任务通常有三个特征重现步骤明确、有自动化验证手段、上下文相对封闭。比如“给某个函数补充参数校验逻辑”就非常合适因为它只需要看一个文件而且测试用例可以保证不破坏原有行为。再比如“把项目里所有 deprecated 的 API 调用换成新 API”这需要扫描仓库里的多处调用但替换规则相对固定也容易通过编译器和测试来验证。这类任务的共同点是Agent 不需要太多隐性知识它的所有决策依据都可以在代码、文档和测试输出里找到。只要给足文件和命令权限它就能在一个比较确定的空间里工作。5.2 适合重构、脚本化、脚手架、接口迁移这类重复动作还有一类任务非常值得交给 Agent那些步骤重复、模式固定、但工作量巨大的迁移工作。我曾经让 Agent 处理过一个内部的接口迁移任务某个旧 API 要从 V1 变成 V2参数名改名响应字段也随之变化。Agent 可以遍历代码里的所有调用点逐一修改并运行测试检查遗漏。这种活让我自己手动改可能得很认真地盯住每一处替换而 Agent 干这个相对更擅长。脚手架生成也是一类很适合 Agent 的场景。比如创建一组新的微服务目录、生成 CRUD 接口模板、补齐一组数据库迁移脚本。这类任务不需要高深判断只要遵循模板约定Agent 会做得比人更一致。5.3 不适合依赖大量隐性业务知识、架构决策、跨团队协调Agent 不适合的场景也很清晰当任务依赖大量隐性业务知识时它很容易“一本正经地胡说八道”。比如“优化这个支付流程”Agent 可能知道支付流程的一般架构但它不知道你们公司内部对金额精度、退款时限、对账逻辑的具体约定。它会按通用经验去改而通用经验在金融场景里往往是最危险的东西。类似地涉及架构选型、跨团队接口约定、长期演进规划的任务也不适合交给 Agent。这些任务需要的不只是代码能力还包含大量无法完全写进提示词里的组织知识和历史背景。用 Agent 来做这类决定本质上是在做无法验证的猜测。5.4 判断工具是否适合的四个检查项我现在拿到一个任务时会先过四个检查项任务有没有明确可验证的完成条件错误造成的后果是否可逆任务上下文是否能在仓库和文档内完全获得是否需要人的经验来判断“该不该这么做”如果四个答案都是“是”那这个任务很适合交给 Agent。如果前三个是“是”最后一个也是“是”那就得让人在关键决策点介入。如果前两个都说不准那再强大的 Agent 工具也建议别用。6. 为什么很多 Agent 项目会在生产环境“翻车”6.1 翻车往往不在写代码环节而在外部依赖很多 Agent 在本地演示时跑得很顺利一放到生产环境就出问题。原因是生产环境里有大量的外部依赖和约束条件而 Agent 的推理模型并不天然知道这些细节。比如Agent 可能在本地测试时生成了一个可以成功连接数据库的脚本但生产数据库有更严格的权限控制、更慢的网络延迟、更长的超时设置。这些差异在本地很难复现Agent 也不会主动考虑到。它只看到了配置模版里的某个 host却不知道真实生产环境的 host 是对外不可见的。这类问题不是 Agent 编程独有的所有代码都可能踩过环境差异的坑。但 Agent 会把问题放大因为它会自动生成多个文件的改动一旦环境不匹配你很难快速定位是哪个环节坏了。6.2 缺少可观测性你不知道它做了哪些修改Agent 编程在生产环境翻车的第二个原因是可观测性不足。传统开发流程里每次改动都对应一个明确的 commit你可以查看 diff可以追溯谁在什么时候改了什么。但 Agent 的任务往往涉及多个步骤、多个文件的修改如果不强制记录操作日志你根本不知道它到底做过什么。我的建议是任何 Agent 工作流都必须保留完整操作日志至少包括“读取了哪些文件”、“写入了哪些文件”、“执行了哪些命令”、“产生了哪些输出”。这些日志应该被视为和代码 diff 一样重要的生产资产。没有日志的 Agent就等于没有黑匣子的飞机。6.3 缺少幂等和回滚重复执行一次可能产生不同结果另一个隐蔽的坑是幂等性。有些 Agent 任务第一次执行正常你再跑一次却得到不同结果因为它可能已经改动过项目状态第二次执行时面对的是一个新的初始条件。如果它没有设计成幂等操作反复执行就会造成状态漂移。更麻烦的是回滚。传统代码改动可以通过版本控制轻松回滚但 Agent 的执行不仅有代码改动还可能包含文件重命名、临时文件生成、环境变量修改甚至数据库迁移。这些副作用不会自动随代码回滚而消失。所以在使用 Agent 前你必须先想清楚如果它的操作不对我能不能回到执行前的状态6.4 缺少安全边界Agent 能碰的东西太多最后一个翻车原因是安全边界。很多 Agent 工具默认拥有读取文件、执行命令的权限但并没有精细到“哪些命令可以执行、哪些文件只能读不能写”。一些团队把 Agent 当普通助手来配置结果它在执行任务时顺带访问了不该访问的秘密信息或者修改了不该修改的配置文件。想要避免这类事故需要在配置层面就做隔离Agent 只能访问它需要访问的目录只能执行白名单里的命令不能读取环境变量中的敏感字段不能触碰生产分支。7. 如果重新讨论“Agentic 编程是失败吗”我会这样回答7.1 按“替代程序员”的标准它确实还有距离先说结论里最不容易被误解的部分如果 Agentic 编程的定义是“让 AI 自动完成软件开发人不再需要写代码”那它确实尚未成功甚至还有很长一段路要走。今天的 Agent 可以在一个标准化的、上下文完整的小型项目里跑得不错但在带有历史包袱、隐性规则、复杂依赖的真实系统里它仍然经常犯错。这种犯错不是偶发性的而是结构性的它不理解组织里那些没有被写进代码里的“潜规则”。凡是声称 Agent 已经能完全替代工程师的说法基本都只存在于演示环境和营销文案里。对这一点保持清醒能避免后续很多不必要的失望。7.2 按“让重复工作自动化”的标准它已经过了玩票阶段但从另一个标准看Agentic 编程并没有失败。它已经能够稳定地完成相当一部分重复性、模板化、探索性编程任务尤其是在那些“上下文完整、验证方式清晰、影响面可控”的场景里。我自己最依赖 Agent 的地方一个是接口迁移一个是配置修改一个是测试补全还有一个是仓库结构分析。这些工作不需要很强的架构判断力但需要大量小心翼翼的细节操作。Agent 帮我节省的不是“思考时间”而是“机械执行时间”。它让我能腾出更多精力去处理真正的设计问题。所以我认为作为“重复任务的自动化执行器”Agent 编程已经在真实项目里产生了价值。它不需要替代资深程序员只需要把那些消耗时间又没有成长性的工作接过去就已经是很大的效率提升。7.3 未来三到五年更可能出现的形态是人机协处理器而不是无人编程我判断未来 Agentic 编程更可能朝“人机协处理器”的方向演进而不是走向“无人编程”。也就是说Agent 会变成工程师身边一个能够执行多步任务的协作者它可以独立尝试、提前踩坑、快速跑通实验但最终的关键决策仍然由人来完成。人会负责定义边界、解释隐性需求、判断取舍而 Agent 负责把明确的部分快速执行完。这个形态更像“有人驾驶的无人机”航线自动规划障碍检测自动响应但要不要进入某个敏感区域仍然由人来决定。对开发者来说这个形态意味着新的技能要求——不是提示词写得多华丽而是任务拆解、验收标准设计、风险边界的控制能力。7.4 最后一句话不要问它是不是失败要问你的场景是否准备好了如果非要给一个回答我会说Agentic 编程没有失败它只是从“让人兴奋”的阶段进入了“让人无聊但必须认真面对”的阶段。真正值得关注的问题不是“它是不是一个 flop”而是“你的工作流、你的仓库结构、你的验证机制、你的权限边界是否已经准备好让一个能自我循环执行的 AI 参与进来”。这就好比给一个团队里突然加了几个动作很快但经验不足的新人。问题不在于新人有没有价值而在于你愿不愿意给他们划定边界、搭好辅助流程、确定验收标准。如果你一开始就给 Agent 太大权限、太模糊的目标、太少的反馈那它大概率会搞砸。这半年来我学到的就一个经验Agent 编程的上限取决于模型下限取决于工程控制。大多数人体验到的失败都是工程控制没跟上而不是这条技术路线本身没戏。所以你可以在下个项目里做个实验挑一个边界清楚、验证容易、影响面小的任务给它一个最小但完整的运行环境。先不急着追问“Agentic 编程是不是失败”亲眼看看它在你的场景里能完成什么、又在哪个环节需要人的判断。那个答案会比任何社区里的争论都更接近真实情况。