一口一个三明治🥪 ＆ 不间歇式发癫 Eason Billie Eilish APEX Johann Sebastian Bach NF JVKE Softlips 喜欢一切的美 处处书简湖
SHUT THE FXXK UP
- Tweets 6,928
- Following 823
- Followers 146
- Likes 25,814
我作为一个后台工程出身的人
对于学习从0-1实现agent
我的建议是：
学习的过程中，别去抠那些工程细节
不是它们不重要，恰恰相反
是我知道它们太重要、太复杂了
所以更不该拿它们当学习目标
举个简单例子：
让一个 Agent 跑起来，半天的事
但让它稳定、崩了能恢复、工具调错了能兜住
这是一个Agent工程师
要花几个月甚至几年去磨的东西
因为仅靠自己学习
没有大用户量的请求
你根本练不出真正的工程能力
那些高并发、容错、恢复的坑
是在真实压力下才暴露的
不是你在本地跑个 demo 能模拟出来的
所以学习的目标应该是理解核心：
骨架亲手搭一遍，踩几个坑，理解了就行
剩下的脏活累活，交给 AI 去填
毕竟你也不指望自己搭的Agent干活吧
当然如果你的目标是成为一个Agent工程师
那上面说的这些细节
就是你的必修课，一个都跑不掉
36
13
206
15,483
一口一个三明治🥪 retweeted
这条推文的评论区非常精彩，我做一下简单总结：
代码正在从一种高门槛的手艺，变成一种充裕的基础原料，而真正稀缺的资产在向几个维度极端分化：
1. 底层的算力与工具成了硬通货。
无论怎样，卖铲子的人总能赚到钱，人们写代码越来越多，对 Token 的需求也会越来越大，提供算力的玩家，已经率先锁定了确定性的收益。
2. 审美和克制成了第一道分水岭。
AI 写代码可以写得很快，但它很难让人赏心悦目的排版、克制的间距以及恰到好处的交互手感。
当人人都能靠模型快速堆出一个功能页面，充斥市场的往往是塞满无用按钮的毛坯房。
懂得给界面留白，懂得砍掉多余的功能，用最轻巧克制的方式解决问题，这种美学把控力是自动化工具很难代劳的。
3. 真实需求与端到端交付才是底牌。
写代码只是商业闭环的一小部分，如果需求本身是伪需求，那模型就会变成高速拉屎机，没有任何的价值。
用户从来不会为了后台写了多少行代码掏钱，大家只认自己的痛点有没有被切切实实解决。
4. 判断力与注意力成了昂贵资产。
在海量自动生成的代码面前，能保持注意力专注，不被廉价的造物快感带偏，耐下心来把核心逻辑做透，非常考验一个人的心力。
5. 复杂系统的治理能力依然是硬壁垒。
能在复杂的系统里抽丝剥茧，守住稳定性边界，让复杂的系统维持高内聚、低耦合的稳定状态，这依然是资深工程师很强的护城河。
2
1
9
1,395
《深入理解 AI Infra》开源发布了！
写完《深入理解 AI Agent》后，在与读者交流的过程中，我越来越感到，要开发好基于模型的应用，还需要理解它赖以运行的基础设施。
最近几十年系统领域最重要的变化是编程抽象的上移：从操作系统到模型上下文。传统的操作系统、编译器和硬件要为事先未知的各种程序提供通用能力，系统优化总要在可编程性与性能之间取舍。
如今 LLM 成了最重要的应用，可以针对特定的模型和加速器架构优化；模型设计也开始反过来适应硬件，DeepSeek V4/V4.1 重新设计长上下文的表示方式，就是一例。
从某种意义上说，模型成了 LLM 时代的操作系统，AI Infra 成了 LLM 时代的计算机体系结构。《计算机体系结构：量化研究方法》是我在体系结构领域的入门书，而 AI Infra 领域还缺少一本从硬件约束和模型架构出发、量化推导系统设计的书，这是我写作本书的动机。
全书约 500 页，包括 12 章：
1. 初识 AI Infra
2. 模型架构
3. 推理与训练负载
4. 加速器架构
5. 算子与运行时
6. 超节点
7. 数据中心网络
8. 推理优化
9. 分布式推理
10. 训练系统
11. 资源调度与运行环境
12. 端边云协同
欢迎 star & 提 issue/PR！
github.com/bojieli/ai-infra-…
79
595
2,930
425,717
一口一个三明治🥪 retweeted
今天有个薄肌男发信息给我说，这是他成年以来最好的夏天。
这一年他遇到了人类最强大的AI模型GPT‑6 Astra，用上MacBook 32G运行内存的电脑开始vibe coding。
每天带着iPhone 17和AirPods，点一杯美团自取的4块钱冰美式，练完后再去沙县小吃吃一个13块的鸡腿饭。
他说很开心，有一种人类黄金时代的错觉。
151
18
374
84,139
README 里面 star 曲线崩了，因为 star 数超过 40k 之后触发了 github API 的一个限制，刚刚修好……
我最近发现《深入理解 AI Agent》可以当作 coding agent 的指导书。Claude Code / Codex 每次给我乱写一通的时候，我就会给它讲 “请读这本书的第x章”，agent 看了以后往往会恍然大悟，省得我一遍一遍解释浪费口舌了。
现在 AI coding 这么强了，我有种感觉，知识的整理过程是零散的文字 -> code -> 系统的文字（例如这本书），code 和真实世界反馈是验证和迭代的必要步骤，但最终沉淀下来的往往不是代码，而是 principle level 的，像书和论文一样的文字。有了书和论文很容易复现一个系统，而开源代码本身却包含很多偶然复杂度，不一定那么有价值。
github.com/bojieli/ai-agent-…
送给大家的七夕礼物：《深入理解 AI Agent》开源书发布 2.0 版了！最近一周修订了大量内容：
1. 把第四章中的异步和第九章的多模态重组为第六章，交互：观察和动作空间的扩展。原有第六至八章顺延，实验也重新编号了。
2. 加入了包括 DeepSeek Harness、Anthropic 最新研究在内的新实战案例。
3. 评估、后训练、agent 持续进化章节用根据线上 bad case 自动调优 agent 的例子来贯穿。
4. 后训练补充 mid-train、数据构造和模型蒸馏的内容。
5. 修正了大量不准确的表述，改进了中文表达。
感谢社区增加了希伯来语翻译。
github.com/bojieli/ai-agent-…
9
5
109
49,288
一口一个三明治🥪 retweeted
分享下我用 matt 这套技能让 codex 长时间稳定跑项目的经验
同一套流程我已经完整跑完 2 个项目，亲测靠谱
1、先把 matt skills setup 好，选定 issue tracker。我一直用 github：自动建 issues、配 labels、拉好依赖关系，后面推进会顺很多
2、再用 wayfinder / grill-with-docs 把需求对齐：做什么、怎么做、验收标准、结束条件都讲清楚。提醒一下，这一步 ai 会追问到你把细节说透
3、然后 prototype 做界面原型。它会直接写代码把界面骨架搭出来，不满意就迭代改。很多“效果不对”的问题，往往是这一步没做或做得不够
4、接着 to-spec + to-tickets：生成开发方案，把大任务拆成可执行的小票据，并建立依赖。做完一张自动解锁下一张，进度清晰、节奏好控
5、最后让 codex 新建 goal，按计划依次调用 implement 落地实现。implement 会带上 tdd + code review，把质量守住，不靠运气
⭐️ 技巧：每处理一个新 issue，都让 codex 新建一个 implement issue xx 的任务，让侧边栏生成独立会话。好处是每个 issue 单独上下文，不串线；而且子任务愿意的话还能并行推进。
☝️ 注意：需要注意的是我都是基于 TanStarter 模板上进行开发，有经验的朋友应该都知道，ai 擅长学习项目已有代码编程，如果之前代码是屎山，那么写出来就是屎上雕花，如果之前代码架构设计优秀，那么写出来的代码又快又好，测试方便，任务执行效率高，推荐基于高质量的目标进行开发，例如 TanStarter (tanstarter.dev) 或者 MkSaaS (mksaas.com)
最近研究了下 Matt 的技能集合，也体验了用这套技能进行开发的流程。主流程如下：
1、grill-me / grill-with-docs：开工前先拷问你，有些细节需要在写代码前想清楚并确认下来。问题会比较多，一般采纳建议就行。
2、to-spec 和 to-tickets：对于大任务，建议执行这两个 skills，产出 spec 文档，并生成要执行的具体任务。小任务就没必要用了。
3、implement：开始执行。它会先检查当前有哪些任务未被阻塞，然后立即执行；执行完成后会解锁其他被阻塞的任务，再继续推进。
4、code-review：顾名思义，做代码检查。这一步也挺有意思：Matt 给出了 12 种代码 bad smell，让 AI 尽量避免生成低质量代码。
youtu.be/M6mYodf0dJM
上面是视频教程，不如听听作者 matt 是怎么介绍的。
为什么现在 superpowers 技能失效了？因为模型能力变强了。之前那套强规范废话太多，反而把模型束缚住了，看起来更“笨”。
为什么推荐 matt 这套技能？它更轻量，skill 内容都很短，相当于把 matt 这个专家几十年的软件开发经验浓缩在一起。你可以按需选用，偶尔会很有帮助。
比如，我感觉前面 grill 之后，to-tickets 会在 github 仓库里生成一堆 issues，再让 ai 去 implement，就像变相做了一个 loop，让 ai 自己持续推进，比我一个 task 一个 task 地搞要高效很多。
65
60
392
71,228
送给大家的七夕礼物：《深入理解 AI Agent》开源书发布 2.0 版了！最近一周修订了大量内容：
1. 把第四章中的异步和第九章的多模态重组为第六章，交互：观察和动作空间的扩展。原有第六至八章顺延，实验也重新编号了。
2. 加入了包括 DeepSeek Harness、Anthropic 最新研究在内的新实战案例。
3. 评估、后训练、agent 持续进化章节用根据线上 bad case 自动调优 agent 的例子来贯穿。
4. 后训练补充 mid-train、数据构造和模型蒸馏的内容。
5. 修正了大量不准确的表述，改进了中文表达。
感谢社区增加了希伯来语翻译。
github.com/bojieli/ai-agent-…
35
211
1,060
106,125
一口一个三明治🥪 retweeted
亲密关系其实跟搞大模型差不多。
刚认识的时候就是Zero-shot。
双方手里只有一点有限的Context：头像、朋友圈、共同好友、几次聊天记录。
朋友圈更像一个公开的RAG知识库。
你从里面检索对方喜欢什么、去过哪里、平时跟什么人玩，再基于这些有限信息开始推理。
第一次约会就是第一次跑Benchmark。
双方都拿着极少的样本开始推理，能不能聊下去，很大程度上看底座模型的泛化能力。
进入恋爱以后，更像两个Agent在交互中持续Online Learning。
刚开始谁也不知道对方真正的preference，只能不断聊天、约会、跑rollout。
今天发现她不喜欢别人迟到，记进Memory。
明天发现她说「随便」的时候其实不能随便，再更新一次policy。
交互样本越积越多，Memory越来越长，时间久了，两边才慢慢收敛出一种所谓「懂你」的状态。
所以恋爱这件事训练数据最好还是自己跑。
看小红书恋爱攻略、研究别人的聊天记录，属于Offline Learning。
数据全是别人的trajectory。
看了一万条「高情商回复」，真轮到自己上场，对方的state distribution一变，直接OOD。
自己的relationship data，还是得亲自跑rollout才能拿到。
问题是恋爱的反馈机制极其黑盒。
你永远拿不到对方的logits。
她不会告诉你：
回复「好的」，reward=-0.8。
回复「怎么啦」，reward=0.3。
回复「我现在过去找你」，reward=0.9。
她最后只给你一个black-box response：
「随便。」
然后让你自己做inference。
这种互动很像Contextual Bandit。
她发来一句：「我没事。」
你面对当前context，从几个action里选一个：
A：「好的。」
B：「怎么了？」
C：「那你早点睡。」
然后观察环境给你的reward。
但从长期来看，一段恋爱更像一个Multi-agent、Partially Observable的Long-horizon RL系统。
因为你今天的action，会改变明天的state。
今天说错的一句话，reward可能三个月以后才回来。
对方真实的hidden state，你从头到尾都只能估计。
更麻烦的是，两边的policy还在同时更新。
你在学她，她也在学你，这大概就是长期关系真正有意思的地方。
于是人类经常在这种极其恶劣的RL环境里训练两年，前面几百万个token都没有明确反馈。
最后突然收到一个terminal reward：
「我们分手吧。」
然后开始做这辈子最困难的一次credit assignment：
到底是哪一步错了？
亲密关系中还会经常出现Hallucination。
比如：
「我记得你以前说过你喜欢这个。」
「我什么时候说过？」
典型的事实性错误。
翻旧账其实也是一种RAG。
数据库里存着三年前的一句话，平时retrieval score很低，一吵架query进去，突然精准召回。
时间、地点、原话、前后文，一个不少。
所以一句「这件事过去了」，技术上的意思通常只是：
它暂时离开了Context Window。
Vector Database还在。
谈久了以后，还很容易发生Reward Hacking。
一个人可能没有真正学会你的value function，只是逐渐摸清楚了哪些回答reward高。
比如你问：
「我是不是胖了？」
这个时候模型面对的任务已经从Truthful QA切到了Preference Optimization。
目标只有一个：
把reward做高。
如果同时谈几个，那套系统就更复杂了。
你开始承担Router的工作，不同对象变成MoE里的不同Expert：
有的负责陪聊，有的负责哄人，有的负责提供情绪价值。
理论上Expert越多，系统能力越全面。
工程上的灾难也从这里开始。
本来应该发给A的Prompt，Router分给了B。
跟A聊出来的Context，塞进了B的Session。
A昨天说的话，被你拿去预测B今天的reward。
一次Context Leak，就是一次Production Incident。
尤其是叫错名字。
基本相当于数据库串租户。
所以Expert多不一定出事，Router不靠谱才是真的要命。
结婚以后才是真正上Production。
工作、房贷、父母、生病、凌晨两点孩子哭，全部变成线上真实流量。
而且没有精心筛选过的测试集，每天都是长尾case。
这时候才会发现底座模型有多重要。
Prompt Engineering可以解决沟通方式。
Post-training可以慢慢磨合行为习惯。
但真正决定长期上限的，还是双方原本的性格、价值观、责任感和处理问题的能力。
Production跑几年以后，还会遇到Distribution Shift。
训练阶段的你：
天天秒回、周末约会、认真听她说话。
上线三年后的你：
加班、已读不回、回家躺尸。
模型本身可能没坏。
只是线上分布已经和训练分布完全不一样了。
你们还有可能共同启动一个更大的训练项目：养孩子。
养孩子更像两个人合资，从头训练一个新模型。
它带着一点遗传Prior出生，但具体会训练成什么模型，谁也不知道。
训练数据来自家庭、学校、朋友和整个互联网。
刚上线的时候Instruction Following接近于零。
前几年连Tokenizer都还在训练。
你跟他说：「别碰那个。」
它解析出来的是：「过去研究一下那个。」
而且这个模型训练成本极高，7×24小时占用算力，每隔几年还来一次巨大的Distribution Shift。
你们两个长期充当Teacher，一路陪它跑rollout、给feedback、做alignment。
最后它还会逐渐形成自己的preference、自己的policy，开始拒绝Teacher的部分监督信号。
最麻烦的是这个模型没有官方文档，没有标准Benchmark，没有稳定版本号，也没有Checkpoint Rollback。
以及基本不支持恢复出厂设置。
58
27
190
13,804
RT @tison1096: 我在想这里有一篇文章可以写，叫做《你可以 review 代码》或者说《你应该 review 代码》。
因为我最近发现说英文圈里面越来越多的这个一般人啊，以前可能只是这个早期采用者或创新者，现在逐渐偏向早期大众，大家都发现说 Agentic Cod…
4
Pi 两位作者的见解：
1. 代码即真相，代码不需要记忆系统，不需要 RAG，模型很擅长理解代码结构
2. Bash 工具足够用，Bash 类似于编程语言，可以任意组合；大部分时候没必要 MCP，skill + 脚本足够。
Good morning from Vienna People of Pi 🌞
Sunday meditations from @badlogicgames and @mitsuhiko
- On memory: code is the truth
- Bash is all you need
- Build context efficient tools
117
155
1,228
227,681
一口一个三明治🥪 retweeted
卧槽，Codex急得直接开口说话了？😲
为了完成任务，Codex是真的什么招都想出来了😂
先发系统通知叫人，发现没人理，接着让屏幕疯狂闪烁，还是没反应，最后干脆直接调用电脑扬声器开始喊：
请摸 YubiKey！
如果再没人理，下一步是不是要打电话了？
44
29
443
109,082
一口一个三明治🥪 retweeted
这篇帖子很值得所有做 AI Coding 的人认真读一下。
Agent 越强，工程自动化的价值反而越高。
过去我们写 lint、测试、CI，是为了减少人的重复劳动；现在这些基础设施还会同时放大一整支 Agent 队伍的效率。
更值得关注的是，团队里的隐性知识也该开始被系统化沉淀：写进 CLAUDE.md、Skills、代码注释、Review 规则和测试里。
如果一个新人或 Agent 提交代码后，才被告知「这里不能这么写」「必须用另一个框架」，很多时候说明这条知识还停留在人脑里。
以后真正成熟的代码库，应该让陌生人和 Agent 在几乎不需要额外讲解的情况下，也能正确工作。
AI Coding 的竞争，最后会逐渐变成工程环境和知识基础设施的竞争。
Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things.
I think many of these automations have become even more important now. This is true for a number of reasons.
First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time.
Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time!
Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation.
Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.
42
18
115
23,180
