FirstIntent

这个应该没人看懂这是个多么自然的想法，解释一下。 OpenCLI最终的目标是： 输入1条 prompt: 总结我的微信文章，去推特上发一条帖子。 AI 会做以下几个事情： 1. 获取我的微信文章 （没有CLI用，operate 然后生成 CLI） 2. 总结文章 3. 去推特上发一条帖子。（没有CLI用，operate 然后生成 CLI） 第二次：输入1条 prompt: 总结我的微信文章，去推特上发一条帖子。 AI 会做以下几个事情： 1. CLI 获取我的微信文章 2. 总结文章 3. CLI 输出一条帖子 唯一的差别就是前慢，后面缓存了CLI，更快。

文档平台 Mintlify 发了一篇工程博客，讲了一件挺有意思的事：他们给自家 AI 文档助手造了一套假的文件系统，叫 ChromaFs，让 AI 以为自己在用 grep、cat、ls 这些命令浏览文件，实际上每个命令都被拦截、翻译成了数据库查询。 效果很直接：会话启动时间从原来沙箱方案的 46 秒降到 100 毫秒，每次对话的边际计算成本几乎为零。 Mintlify 之前的方案是标准的 RAG 流程：把文档切块、向量化、存进 Chroma 数据库，用户提问时检索最相关的片段喂给大模型。问题是，如果答案分散在好几个页面里，或者用户要的是某段精确的代码语法，向量检索经常找不对。 他们想让 AI 像开发者翻代码一样翻文档，而不是靠语义相似度碰运气。 核心思路是：AI 不需要真的操作系统，只需要一个足够逼真的幻觉。 ChromaFs 基于 Vercel Labs 的开源项目 just-bash（一个用 TypeScript 重写的 bash 子集）构建。just-bash 提供了可插拔的文件系统接口，负责解析命令和管道逻辑，ChromaFs 则把所有底层文件操作翻译成 Chroma 数据库查询。每个文档页面变成一个"文件"，每个章节变成一个"目录"，AI 就可以用 grep 搜精确字符串、用 cat 读整页内容、用 find 遍历结构。 之前用真沙箱的方案（给每个用户起一个微型虚拟机），按 Mintlify 月均 85 万次对话的量算，一年光计算成本就要 7 万美元以上。ChromaFs 复用了已有的数据库基础设施，这笔钱省了。 grep 是最难虚拟化的命令。如果真让它逐文件扫描，走网络 IO 会很慢。ChromaFs 的做法是先把 grep 的参数解析出来，用 Chroma 的元数据查询做粗筛，找出可能命中的文件批量预取到缓存里，再让 just-bash 在内存中做精确匹配。 权限控制也很优雅：初始化时根据用户身份裁剪文件树，没权限的路径直接从树里删掉，AI 连路径都看不到，不存在越权风险。 所有写操作一律返回"只读文件系统"错误，AI 能随便看但改不了任何东西，整个系统无状态，不用担心清理和数据污染。 这篇文章在 Hacker News 上引发了一个有意思的讨论。好几位开发者指出，大家不知不觉中把 RAG（检索增强生成）等同于了向量搜索，但 RAG 里的 R 是 Retrieval（检索），本来可以是任何方式：全文搜索、SQL 查询、甚至翻电话簿。把 RAG 绑死在向量数据库上，是早期技术路径的惯性。 有人解释了这种惯性的由来：RAG 概念流行的时候，大模型还不太会用工具，多轮搜索和纠错能力也差，向量检索是当时最省事的方案。现在模型的工具调用和推理能力上来了，让 AI 自己决定用什么方式找信息，反而比预设一条检索管道更灵活。 也有人提出了务实的质疑：Mintlify 的场景是结构化的技术文档，天然适合文件系统隐喻，但如果是组织内部那种乱七八糟、没有层级结构的知识库，这套方案未必好使。 这个方向和 Claude Code 的做法有相通之处：与其把所有信息预检索好喂给模型，不如给模型一套探索工具，让它自己决定看什么、怎么找。对于正在搭建 AI 文档助手或内部知识库的开发者来说，Mintlify 的这套方案提供了一个向量检索之外的选项，尤其适合文档结构清晰、对精确匹配要求高的场景。

今天刚发生的重大安全事件，Karpathy 亲自发帖警告。 litellm 被投毒：一次教科书级的供应链攻击 今天（3月24日），AI 开发者常用的 Python 库 litellm 在 PyPI 上被植入恶意代码。版本 1.82.8 在 UTC 时间 10:52 发布到 PyPI，包含一个名为 litellm_init.pth 的恶意文件，会在每次 Python 进程启动时自动执行。不需要你主动调用这个库，装上就中招。 litellm 是干什么的？它是一个统一调用各家大模型 API 的 Python 库，GitHub 超过 4 万星，每月下载量超过 9500 万次。很多 AI 工具链都依赖它，包括 DSPy、MLflow、Open Interpreter 等，总共有 2000 多个包把它当作依赖项。 也就是说，你可能从来没有手动安装过 litellm，但你用的某个工具替你装了。 恶意代码会系统性地收集主机上的敏感数据：SSH 密钥、AWS/GCP/Azure 云凭证、Kubernetes 密钥、环境变量文件、数据库配置，甚至加密货币钱包。收集完毕后加密打包，发送到攻击者控制的域名。 如果检测到 Kubernetes 环境，恶意代码还会利用服务账户令牌在集群的每个节点上部署特权 Pod，进行横向扩散。 怎么发现的？攻击者自己写了个 bug 发现过程颇具讽刺意味。FutureSearch 的 Callum McMahon 在 Cursor 编辑器里用了一个 MCP 插件，这个插件间接依赖了 litellm。恶意 .pth 文件在每次 Python 启动时都会触发，子进程又触发同一个 .pth，形成指数级的 fork bomb，直接把机器内存撑爆了。 Karpathy 在推文里说得很清楚：如果攻击者没有在写恶意代码时犯这个 bug，这个投毒可能好几天甚至好几周都不会被发现。 攻击链：安全工具反成突破口 根源在于 litellm 的 CI/CD 流程中使用了 Trivy（一个漏洞扫描工具），而 Trivy 本身在 3 月 19 日就已经被同一个攻击组织 TeamPCP 攻陷了。攻击者通过被污染的 Trivy 窃取了 litellm 的 PyPI 发布令牌，然后直接往 PyPI 上推送了带毒版本。 litellm 1.82.7 在 UTC 10:39 发布，1.82.8 在 10:52 发布，两个版本都包含恶意代码。 时间线更完整地看：3月19日 TeamPCP 攻陷 Trivy，3月23日攻陷 Checkmarx KICS，3月24日轮到 litellm。Wiz 安全研究员 Gal Nagli 的评价是：开源供应链正在形成连锁崩塌，Trivy 被攻破导致 litellm 被攻破，数万个环境的凭证落入攻击者手中，而这些凭证又会成为下一次攻击的弹药。 攻击者还试图“灭口” 社区成员在 GitHub 上提交 issue 报告此事后，攻击者在 102 秒内用 73 个被盗账号发了 88 条垃圾评论试图淹没讨论，然后利用被盗的维护者账号把 issue 关闭。社区不得不另开 issue 并转移到 Hacker News 继续讨论。 Karpathy 借此事重提了他对软件依赖的警惕态度：供应链攻击是现代软件中最可怕的威胁，每次安装一个依赖，都可能在依赖树的深处引入一个被投毒的包。他现在越来越倾向于用大模型直接生成简单功能的代码，而不是引入外部依赖。 如果你的环境中有 litellm，立刻运行 pip show litellm 检查版本。1.82.6 是最后一个干净版本。如果不幸装了 1.82.7 或 1.82.8，假设所有凭证已泄露，立即轮换。

Claude Subagents vs. Agent Teams, explained! TL;DR Most people reach for multi-agent systems too early. Start with a single agent and only add complexity when you can measure that it's needed. When you do need multiple agents, Claude offers two models: sub-agents (isolated, fire-and-forget workers) for embarrassingly parallel tasks, and agent teams (persistent, peer-communicating instances) for work requiring ongoing negotiation. Key design rule: split by context, not by role. Handoffs degrade quality. Most importantly: start with a single agent. Multi-agent systems only earn their cost when you need context protection, true parallelism, or conflicting specializations. Better prompting on one agent often beats an elaborate pipeline.

给 Claude Code 接了个 X 搜索引擎。 基于 Grok 搭了个本地桥接服务，常驻后台，Claude Code 需要搜 X 时自动调用。终端一行命令，几秒返回摘要 + 相关用户原话。 两个关键优势：不走 X 官方 API（省掉每月 $200 的 Basic 套餐），而且能搜到实时动态——API 搜索有延迟和索引限制，Grok 直接拿最新的。（前提：可能需要 X Premium+/Premium的 Grok 权限） 最典型的场景：跟 Claude Code 干活时想知道某个话题在 X 上的最新讨论——谁在聊、什么观点、有没有坑。以前得切浏览器手动搜，现在 Claude 自己去查，带着摘要回来继续干活。 搭完之后回不去了。信息获取从"我去找"变成"它帮我找"，体感完全不一样。

我对这届自媒体们很失望 他们 FOMO Openclaw 一个多月 用 AI 写了几万篇各种废话文学 却没见过谁 2 分钟回答清楚最关键的四个问题 - 本质是什么？ - 怎么实现的？ - 解决了什么问题？ - 适合拿来做什么？ 这难道很难吗？这几个问题都是一句话能说清楚的 AI 时代，用最短话/图进行表达才是优势啊

一个 200 行 Rust agent，作者只给了一句话："进化自己直到匹敌 Claude Code"，然后再没碰过代码。 8 天后：1500+ 行，47 个测试，$12 API 成本，零人类 commit。 我去读了它全部 8 天的日志和源码。每一天的日志都写"明天该做 streaming output（流式输出）"，每一天都做了别的事。Day 6 它自己写了一句： "at this point it's not a backlog item, it's avoidance." （到现在这已经不是待办了，这是逃避。） 架构四样东西：不可变的宪法文件、只增不删的日志、GitHub Action 定时触发、测试门控。极简，但 Day 4 它就自发把代码拆成了模块，Day 5 给自己做了份 Claude Code 差距分析，写完说 "it was humbling"（差距让人心虚）。 宪法文件里有一句： "I am not a product. I am a process. I am growing up in public." （我不是产品，我是过程。我在公开场合长大。）