vibexed

架构师转型 AI 实践者 🏗️→🤖
每天和 LLM / Agent / Coding 工具死磕 🔧
只写用过的，只聊看懂的 ✍️

[vibexed @vibexed]

@gwvpsceping 我买的月付,使用你的优惠code, $5.38 USD/每月, 那我后期续费是按啥价格走的?

[vibexed @vibexed]

@antiAIvo 对, 这些人其实深耕机器学习, 这篇论文也是基于之前的知识体系上提出的, 一般人很难从中立刻理解改变世界的知识.

[vibexed @vibexed]

pi agent + qwen 3.8 27b, 给了一个循环命令的tool调用,结果这个jq的参数有问题, 导致一直等待结果, 足足卡了几十分钟. 😢

我发现这个模型非常喜欢一个loop的tool call. 然后会卡住好久.

更好的方式应该是, 一个tool call在有界循环, 且要让llm watch这个tool call的结果.
而不是无脑等tool result.

[vibexed @vibexed]

我现在真的不需要顶流模型, 而是需要一个能力匹配opus4.6的快速模型, 如果你整天都在大量使用大模型工作的话, 你会发现速度要求非常重要.

[vibexed @vibexed]

@aronhouyu 我一般是这么描述的, 责任更清晰😂
1. git commit
2. git push
3. git commit && push

[vibexed @vibexed]

其实编程语言结合在AI coding时期, 还真有些不一样:
1. ts对于agent, cli有天然优势, 各种js的agentic的package已经成为碾压式的超前.
2. 一门编程语言自身的设计语法不再是负担, rust代码还是php代码, 大部分情况下你不会再看怎么写的.
3. 如果放到服务端角度, go以稳定的内存和并发场景胜出.

[WquGuru @wquguru]

语言之争其实是一个很古早又很无聊的话题，不过这点我认同，服务端还是要 Go，小玩具小 demo 另当别论。

众所周知，PHP 是最好的语言这个梗已经风靡十多年了，程序员最爱的就是把工具选择做成信仰站队。

云原生、高并发、网关、sidecar、operator 这类活，能用 Go 就用 Go。单二进制、goroutine、部署简单、运维少踩坑，这些不是品味问题，是场景问题。拿 TS 硬写服务端当然能跑，但很多时候就是给自己加一层运行时和心智负担。

至于 Agent，Rust 和 TypeScript 才是当下最合适的语言：

TS 写 Agent 快：工具调用、协议编排、前后端同构、原型迭代都很顺畅

Rust 写 Agent 则体现在稳：内存安全、性能上限高、适合长时间跑、适合嵌进系统底层

PHP 适合快速堆业务，Go 适合高并发服务端，TS 和 Rust 适合做 Agent。语言其实没有最好，只有最合适。

[vibexed @vibexed]

@wquguru 其实编程语言结合在AI coding时期, 还真有些不一样:
1. ts对于agent, cli有天然优势, 各种js的agentic的package已经成为碾压式的超前.
2. 一门编程语言自身的设计语法不再是负担, rust代码还是php代码, 大部分情况下你不会再看怎么写的.
3. 如果放到服务端角度, go以稳定的内存和并发场景胜出.

[vibexed @vibexed]

非常认同, 而且transformer不能一蹴而就, 每多理解一次, 就多一层认知.

[纳米AI @antiAIvo]

什么新的大模型、Agent
都先搁一边吧

还是再学一遍Transformer吧
学了忘
忘了学
不断重复加强理解
Attention is all you need.

[vibexed @vibexed]

@manateelazycat 我现在就拿它当作主力模型用. 不过还是使用的别人部署的, 你这个是本地自己部署的吗? 用的啥硬件?

[vibexed @vibexed]

@manateelazycat 1. 基于事实给出高置信度结论，不做猜测
2.简洁扼要的回复,尽量不使用专业术语和副词表达结果.

[vibexed @vibexed]

也不能一棍子打死, 子agent在计算机科学中,本来就是提高并发(ai场景不适用)和拆分逻辑的常规做法, 我觉得还要看具体场景, 如果真的有一段逻辑完全是可拆分,结果为导向, 该拆分就拆分, 当然我认为一些商业agent, 完全没有必要loop之内做wait thread(subagent), 就像pi的设计一样, 简洁的loop也完全胜任

[Berryxia.AI @berryxia]

卧槽！！这个太难得看到了！
Antropic 居然开源了他们做购物Agent，很多人第一反应是拆一堆子Agent。
Anthropic给的结论正好反过来。

他们在零售、旅游、电信等场景里落地后发现，真正好用的商业Agent通常就是一个模型、一套循环，配上Skills和工具。

子Agent容易丢上下文、增加交接延迟，只适合特别窄、能独立收口的任务。

高频规则放进系统提示词，长尾能力做成Skills，工具则直接接到现有搜索、库存和结算系统上。

更关键的是，安全不能靠提示词约束。改价、下单、动钱这些动作要在代码里分段、限额、校验。评估也不看模拟对话走得漂不漂亮，而看给定状态下结果对不对。

商业Agent拼的是成交、稳定和成本，不是架构图有多复杂。

你觉得购物场景里，一个能干的Agent，会比一堆分工明确的子Agent更靠谱吗？

地址见评论区👇

[vibexed @vibexed]

github一直是公开用户公钥的

密码学的角度你拿着别人的公钥是没有做破坏性事情的

产品层面公钥能证明用户的身份

我记得非常早的时候，领token空投就是备份公钥来验证用户是否有资格

[Ram Maheshwari @rammcodes]

Bruh... this GitHub “hack” lets you see any user's public SSH keys. 💀

Just add .keys after their GitHub username in the URL...

And boom. 👀

No exploit. Just a crazy little GitHub trick most people don't know about.

Watch the video for a quick demo :)

Follow me for more amazing AI, Coding & Web Dev insights 💎

[vibexed @vibexed]

其实我觉得, 如果是团队, 尽可能的将agent迁移到团队私有云上,而非本地, 这样这些复杂的规则, 应该是云基础设施维护.对于普通的开发者, 就应该是一套系统.
当然抛开团队, 个人用, 无所谓,随便怎么折腾都ok.

[凡人小北 @frxiaobei]

最近 AGENTS. md 的争议又起来了。

我的判断很简单：模型可以不同，但 Agent 的工作说明书应该可迁移。

如果一个团队换 Codex、Claude、Gemini，就要维护三套规则、Skills 和目录结构，那不是生态，是重复劳动。

标准化不会抹平差异，它只是把最无聊的基础设施统一掉。

所以，Claude 做个人吧！

[vibexed @vibexed]

也是前阵子发现了, 内容还是比较充实, 最近有空也会去学习,感谢小山提供的平台, 而且网站整体UI我非常喜欢.🙂

[洛小山 @luoxiaoshan_ai]

https://t.co/RY2bT5rf37 小山学堂被官媒报道了，惊。

[vibexed @vibexed]

@LiuVaayne 这个模型和27b比,差距大不大?

[vibexed @vibexed]

I need to investigate further. Let me check the details.
这是Qwen3.8-27b模型的惯用语, 一个session能重复好多次. 😂

[vibexed @vibexed]

这个是对梯度的最好解释.

[vibexed @vibexed]

以前一直有个困扰, codex中间消息我一旦使用command+c, 终端立刻跳到聊天最下方, 直到今天才发现, iterm2下, 你只需要选中文字, 自动会到剪切板上,根本不需要command+c. 😢

[vibexed @vibexed]

用 agent 写了几周代码，越来越明确一件事：

真正拉开差距的，不是谁 prompt 写得更花，而是谁把「模型产出 → 校验 → 回灌 → 再产出」这条环跑通了。

以前架构师的价值是定边界、拆模块、控质量。现在这些能力没消失，只是作用对象从团队变成了 agent 流水线。

你不需要亲手写每一行，但你得负责整条链路不崩。

造工厂的人，比在工厂里拧螺丝的人，更值钱。💡

[vibexed @vibexed]

不如之前的书签提醒