寫東西只為了抒發,一切隨緣不為流量

有事找 @finalfantasty

👻 個人博客 Blog: https://blog.pdzeng.com

👻 個人微博客 Blog:
https://daily.pdzeng.com/
每當你看到一個很有聲量甚至於很有傳播度的文章或是專案,你得去問問,這對我有用嗎?他為什麼這麼出圈?
探索本質的過程中,你會學習到一些東西,例如

gstack skills 相當於透過 gary tan 的哲學來協助你做出決策跟判斷,單純的使用會得到 gary tan 十幾年的工作經驗,相當於找他當顧問
那要怎麼活用這些技能在你的工作上,每個東西你都需要嗎?

不,但是這些你得自己探索
OpenAI 宣布将收购 uv、Ruff 等工具的开发商 Astral,整合 Python 开发工具至 Codex 生态

OpenAI 宣布将收购开源 Python 工具开发商 Astral,后者开发的 uv、Ruff 和 ty 等工具支撑着数百万开发者的现代 Python 工作流。交易完成后,Astral 团队将加入 OpenAI 的 Codex 团队,其开源工具链将被整合进 Codex 生态系统,使 AI 代理能够直接调用开发者日常依赖的工具,覆盖从代码规划、修改到验证和维护的完整软件生命周期。

目前 Codex 自年初以来已实现用户量 3 倍增长和使用量 5 倍增长,每周活跃用户超过 200 万。此次收购尚需获得监管批准,完成前 OpenAI 与 Astral 将保持独立运营。

OpenAI

🚀 在花频道社区讨论投稿通道
最近,技术圈风向突变,鼓吹“MCP已死,CLI万岁”。但这场争论的本质,并非协议优劣或Token效率,而是一个更深层的问题:你是满足于自娱自乐的“感觉编程”,还是在构建严肃的“智能体工程”?本文揭示,对于任何想超越个人玩具规模的团队来说,这场争论的答案从一开始就是确定的。| blog

技术圈的风向变得比天气还快。几个月前,模型上下文协议(MCP)还是人人都想上的船,转眼间,风评急转直下,鼓吹“MCP已死,CLI万岁”成了新的政治正确。

很多人被表象迷惑了。他们说,MCP臃肿、消耗大量上下文,远不如简单直接的命令行(CLI)来得高效。经验丰富的老炮们甚至不屑一顾:“这玩意儿看起来就像垃圾,那它就是垃圾。”

这种论调听起来很酷,但可能完全搞错了重点。

是的,如果AI智能体要用的工具是`git`或`curl`这种早已刻在模型“肌肉记忆”里的命令,那用CLI当然省事。但如果你用的是一个自定义工具呢?智能体照样需要一份说明书(`--help`或者`SKILL.md`)来学习,所谓的Token优势瞬间荡然无存。整个OpenAPI schema塞进上下文的场景,并不少见。

这场争论的真正分野,不在于技术,而在于开发的组织形态。它区分了两种开发者:单打独斗的“感觉编程”(vibe-coding)信徒,和面向组织的“智能体工程”(agentic engineering)实践者。

对于前者,MCP确实显得多余。但对于一个10人以上的团队,问题就变了:如何保证不同技术栈的工程师用不同智能体得到一致的结果?如何管理密钥、做权限控制?如何追踪哪个工具有效、哪个在拖后腿?

这才是MCP真正发力的地方——不是本地`stdio`模式的小打小闹,而是作为中心化服务器通过HTTP提供的服务。它把认证(Auth)、安全(Security)、遥测(Telemetry)这些麻烦事一揽子解决了。工程师离职?吊销他的OAuth令牌即可,他从未接触过核心密钥。这对于任何依赖GitHub Actions这类临时运行环境的团队来说,更是刚需。

更有趣的是,连Anthropic和Cloudflare都发现,让LLM直接调用MCP,不如让LLM“写代码去调用MCP”来得更稳、更省。Anthropic的“程序化工具调用”甚至能节省高达98.7%的Token。这说明,MCP的价值在于提供了一个稳定的、可被机器理解的“契约”,而不是一个手感舒适的“玩具”。

所以,当人们在激烈争论MCP和CLI的优劣时,他们实际上在无意中暴露了自己的立场:他们究竟是在构建一个随时可丢弃的个人项目,还是在为一个需要长期维护、多人协作的系统打地基?这根本是两条路线的斗争。

这已经不是技术选型问题,而是工程成熟度问题。当你的智能体应用开始考虑“人”的因素——团队协作、权限、审计、迭代——你会发现,你需要的不是一个更“聪明”的工具,而是一个更“笨”、更稳固、有明确边界的协议。那些嘲笑MCP的人,可能还没遇到需要为AI代码擦屁股的烦心事。
Back to Top