原野: 你有没有发现,最近AI圈子里头,什么AI工具啊、自动化啊,那可真是热得发烫,尤其是那个叫MCP的,模型上下文协议,简直被吹上了天,都快成“神物”了。结果呢,最近一位开源界的大佬,直接就给这股热潮“兜头一盆冷水”泼下来了,这是演的哪一出啊?
晓曼: 没错,你说的就是Armin Ronacher,咱们都特熟的那个Flask框架的作者。他最近在社交媒体上发了篇文章,结果自己还“凡尔赛”了一下,说这是篇“烂文章”。你猜怎么着?底下评论区直接就“炸”了,工程师们那叫一个“心有戚戚焉”,都说“大佬你说得太对了!”
原野: 一篇自己都说是“烂文”的东西,结果反而把整个技术圈子都给“炸”了,这事儿本身就透着一股子戏剧性。那这篇“神文”到底讲了些啥呢?
晓曼: 它的标题就特别“硬核”,叫Tools: Code is all your need,直白点说就是“工具嘛,代码就够了!”。他文章一上来就摊牌了,说自己对MCP这套玩意儿根本不感冒,觉得现在大家对它的吹捧,有点过了,简直就是“捧杀”。
原野: 这可太有意思了,一位这么受尊敬的开发者,居然敢公开“叫板”一个当下最热门的技术趋势。他到底看到了什么,让他对MCP如此“不屑”?他最担心的核心问题到底是什么呢?
晓曼: 他觉得吧,MCP那套让大语言模型,也就是咱们说的LLM,通过“推理”去调用工具的路子,根本就是个“歪路”。这套机制不仅效率低得吓人,而且在扩展性上,用他的话说,就是存在“致命缺陷”。说白了,他认为我们可能把AI的“脑子”想得太聪明了,高估了它的推理能力,反而把人家在“写代码”这方面的真正潜力给低估了。
原野: 听起来Ronacher这番话,可真不是“无的放矢”啊。那咱们就好好掰扯掰扯,他到底给MCP挑了哪些毛病,甚至说是“致命伤”呢?
晓曼: 成,第一个就是,他直接指出MCP所谓的“可组合性”,根本就是个“伪命题”,压根儿就不成立。
原野: 可组合性?这词儿在咱们程序员耳朵里,那可是个好东西啊,不就是能像搭乐高积木一样,把一个个小模块拼起来,完成大任务嘛。MCP的“可组合性”难道有什么“黑科技”不一样吗?
晓曼: 那区别可就大了去了!传统编程的组合,那是板上钉钉的,效率高得飞起。可MCP这套组合,说白了,就是让模型一次又一次地“瞎琢磨”来完成任务。它每调用一个工具,都得重新“捋一遍”上下文,然后再“寻思”下一步该干啥。这不光是效率低的问题,它还特别“烧钱”,极度消耗资源!
原野: “烧钱”?具体是指哪些资源啊?是算力不够烧,还是…别的是啥?
晓曼: 主要就是这个“上下文窗口”啊。Ronacher举了个特别形象的例子,简直让人哭笑不得。他想让AI工具去GitHub上捞点儿仓库信息。结果他发现,用GitHub官方那个MCP工具,AI为了理解、为了调用这个工具,它自己消耗的上下文,居然比他自己动手写一段直接调GitHub API的代码,还要!多!
原野: 我得说,这简直是“反向自动化”啊!为了让AI“替我干活”,结果我发现它比我自己干还费劲?这逻辑有点儿颠覆啊。
晓曼: 可不是嘛!他还特意做了个对比,就用MCP工具和咱们程序员每天都离不开的那个`gh`命令行工具,去搞定同一个任务。结果呢,`gh`命令行工具不仅操作起来“丝滑”又直接,效率更是甩了MCP好几条街!这摆明了告诉我们,至少在目前这个阶段,你非得让模型去“琢磨”、“推理”怎么用工具,那简直就是一条“烧钱”又“磨洋工”的路。Ronacher直接就给它下了个定义,说这就是个“死胡同”!
原野: 既然他把MCP这条路都给“堵死”了,那在他看来,真正能“跑起来”、能“靠得住”的自动化,到底长啥样啊?他有没有给出个“活路”呢?
晓曼: 他给出了一个非常清晰的“解药”,咱们可以概括成一个“闭环”:就是“代码生成 + 评审 + 批量运行”。核心思路就是,别老想着让LLM去“推理”怎么干活儿了,直接让它“吐”出能完成任务的代码来!
原野: 哦?这个听起来就有点儿意思了!他是不是还分享了自己是怎么“玩转”这个方案的例子啊?
晓曼: 对,他分享了一个自己的“血泪史”——哦不,是亲身实践!就是把他之前所有的博客文章,从那种老掉牙的reStructuredText格式,统统转换成现在大家都在用的Markdown格式。这可真是个典型的,得“批量搬砖”的自动化任务。
原野: 那他是怎么搞定的?难道他没有直接跟AI说:“嘿,哥们儿,帮我把这些文章都转成Markdown格式?”那样吗?
晓曼: 他当然没有啊!那样做的话,AI就得一篇一篇地“在那儿琢磨”怎么转换,结果可能每篇都不一样,而且慢得像蜗牛。他的“神操作”是,直接让LLM给他写了个Python脚本,这个脚本就是专门干格式转换这活儿的。然后呢,他自己可以像个老司机一样,去审查LLM生成的代码,确保逻辑没毛病,甚至还能自己动手“装修”一下,优化优化。最后,他就用这个经过自己“法眼”验证过的脚本,去批量处理他所有的博客文章。那效率,简直了!
原野: 我算是彻底明白了。这个流程的精髓就在于,最终去“干活”的,是一段板上钉钉、能被咱们“审阅”的代码,而不是模型每一次都“即兴发挥”的“瞎搞”。那这种模式跟MCP比起来,优势到底在哪儿呢?
晓曼: 优势那可真是“明晃晃”地摆在那儿。首先是可靠性,代码是死的,只要逻辑没毛病,你跑一百遍,结果都一模一样,稳得一匹!其次就是成本了,LLM每次“推理”那可都是真金白银地在烧,但代码一旦生成了,你运行它的成本几乎就是零啊,可以无限次地“白嫖”复用。这,才是真正能“跑量”、能“靠谱”的自动化!
原野: 咱们嘴上老说“自动化”,但说到底,自动化的真谛确实是在可重复、可预测的任务上。那Ronacher为啥就死咬着说,只有“代码”才能实现这点,LLM的“推理”就不行呢?
晓曼: 因为“推理”这事儿本身就带着“不确定性”啊!Ronacher就说了,你让LLM通过推理去完成一个小任务,它可能成功,也可能给你“搞砸”。最要命的是,它要是搞砸了,你想去查它为啥失败,那个排查成本,简直高到离谱!但LLM生成出来的代码呢,那可是白纸黑字的,明明白白写在那儿,确定的!你能读懂它,能调试它,一切都在你的“掌控”之中。这感觉,多踏实!
原野: 他好像还提到了一个叫Playwright的工具来举例,那可是搞浏览器自动化的,听起来就特别需要AI的“聪明劲儿”啊。
晓曼: 没错,这恰恰就是“代码生成”的牛X之处啊!你想想,就算是远程控制浏览器这种听起来特别“高大上”的复杂场景,与其让AI模型一步一步地“瞎琢磨”:“嗯,先点这个按钮,再敲点儿字”,还不如让它直接给你“吐”出一个完整的Playwright自动化脚本呢!这个脚本一旦跑起来,那速度可就快多了,而且出错的概率也低得多。从咱们工程师的角度来看,手里有这么一个能跑、能改的脚本,那可比指望一个“黑箱”模型在那儿“玄学操作”要靠谱太多了!
原野: 听Ronacher这么一说,这不仅仅是对MCP的“炮轰”啊,这还引出了一个更深层次的问题:咱们现在这些大语言模型,在编程这个领域,到底还面临着哪些“硬骨头”挑战呢?
晓曼: 这不,又牵扯出另一位技术圈的“大神”了,叫Mario Zechner。他可是对Ronacher的观点“举双手赞成”,而且还进一步给LLM在编程领域指出了两大“深坑”!
原野: 哦?“深坑”?是哪两大“深坑”啊?快给我说说!
晓曼: 第一个,就是“上下文不够用”。咱们现在看到的LLM啊,虽然那个上下文窗口是越搞越大,但对付一个动不动就几十上百万行代码的真实项目,那简直就是“杯水车薪”啊!它根本就没法儿“一览众山小”,看清整个项目的全貌。
原野: 那这会带来什么具体的“幺蛾子”呢?
晓曼: 这意味着LLM很难去“驾驭”真正复杂的系统。比如说吧,它生成的代码可能在一个单独的文件里看起来“贼棒”,一点毛病没有,结果放到整个项目里一看,哎呀妈呀,它可能把整个项目跨进程通信的“规矩”都给破坏了,或者根本没法儿正确处理并发和锁这些“老大难”问题。因为它呀,压根儿就“盲人摸象”,看不到全局的“大局观”设计。
原野: 我明白了,这就像一个乐手,手里只有一页乐谱,你让他去演奏一整部交响乐,那不是为难人嘛。那第二个“深坑”又是什么呢?
晓曼: 第二个困境嘛,Zechner用了一个特别有意思的词儿,他说LLM缺乏“品味”(Taste)。
原野: “品味”?嘿,这词儿用到代码上,还真有点儿意思!按理说,LLM都把互联网上那些代码“吃”了个遍,难道它不应该是个“老饕”,很有“品味”才对吗?
晓曼: 这可真是“一语道破天机”啊!它确实学了所有代码,所以它“吐”出来的,就是一种“统计学上的平均值”代码。它知道什么代码语法上没毛病,什么代码是大家常用的,但它压根儿不知道什么是“好”的代码!咱们那些资深工程师啊,追求的是代码的优雅、简洁,还有那份让人看了就“舒服”的可维护性,这可就是一种“品味”!而LLM生成的代码呢,往往就显得特别平庸、冗余,简直是“索然无味”,缺乏那种“灵魂”啊。
原野: 我好像有点儿茅塞顿开了。这就像一个AI,能把成千上万幅画作都给分析透了,然后给你生成一幅“平均水平”的画,技术上可能没毛病,但它就是没有那些艺术大师那种独一无二的风格和审美判断,少了点儿“灵气”。
晓曼: 你这个类比简直是“神来之笔”啊!所以说,面对这些个“深坑”,咱们才能更清楚地看到未来到底该往哪儿走。
原野: 没错,这场关于MCP和代码生成的“世纪大辩论”,说到底,最终还是指向了咱们人类到底该怎么跟AI“搭档”协作。
晓曼: 可不是嘛!它狠狠地提醒了我们,别老是盲目地追求让AI去“瞎琢磨”、“做决策”了,那可能真是把AI用到了“歪门邪道”上。LLM真正能“颠覆世界”的潜力,可能就在于它能成为一个超级无敌的代码生成器!它就像咱们身边那个“神助攻”的程序员助手,能把咱们的奇思妙想,嗖嗖地翻译成能跑、能查的代码。
原野: 这么看来,未来咱们搞智能体编程,可能就得为这种“人机协作”的新模式,打造一个更“丝滑”的环境了。
晓曼: 完全正确!比如说,咱们就需要一个更“安全可靠”的沙盒环境,让AI生成的那些代码能放心地去“撒欢儿”测试、运行。到头来,咱们可能会发现,这场旷日持久的争论,其实就给咱们指明了一条“光明大道”:MCP这种老是让AI“猜来猜去”的模式,可能真就是个“死胡同”,而真正能搞定大规模、能让人放心的自动化,还得是“代码生成”这条康庄大道!