昨天 Sam Altman 与他的 OpenAI 团队参加了 Reddit 上的 AMA 直播，来回答网友们任何关于 GPT-5 的问题。 AMA 即 Ask Me Anything。一般都是回答网友的各种问题 原贴地址：GPT-5 AMA with OpenAI’s Sam Altman and some of the GPT-5 team 我随手整理了一版，方便大家阅读。 关于老模型 Sam Altman 表示已经收到了大量关于恢复 GPT-4o 的反馈，表示会重新为 Plus 用户启用它，并会观察使用情况，以确定支持多长时间 对于 GPT-4.1， Sam Altman 表示团队正在探索用户是否同时需要 4o 和 4.1 或者仅仅有4o 就足够 关于 GPT-4.5， 团队没有正面回应，但是也说了认为 GPT-5-Thinking 能带来更好，更有趣的写作能力。 发布会的错误与技术修复 对于发布会 PPT 的图表错误，Sam Altman 表示直播之前加班搞到太晚，太累了，出现了人为错误。但是博客文章以及系统卡里的介绍都是准确的。 GPT-5 在发布时出现了严重的技术问题，自动切换器也坏了。这导致对于很多用户的查询没有找到正确的模型，所以表现异常的迟钝。团队正在对决策边界进行干预，帮助用户更频繁地获得正确的模型，并且考虑增加模型回答的透明度，以便让用户更好地知道是哪个模型回答的问题。 GPT-5 的重大发布导致 API 流量在 24 小时内翻倍，导致了很多用户的服务出现了中断。OpenAI 预计会在一两天内让服务稳定，并将 Plus 用户的速率限制翻倍，以完成最后的推广。 OpenAI 承诺自动切换器会更好用。当然，也可以通过在 prompt 里加入指令，比如 “Think Hard” 来让模型强制触发思考推理模式。 关于编程以及工具调用 Codex CLI 现在通过付费的 ChatGPT 计划来支持 GPT-5. Pro 用户几乎不会遇到用量上的限制， Plus 和 Team 用户每周可以处理几个 1-2 小时的对话，并且速率限制会每 5 小时重置，按周的维度来统计。 Codex CLI 很快将迎来重大升级 已经在考虑将 GitHUb 直接集成到 ChatGPT 中，这样可以让 ChatGPT 直接读取代码仓库 GPT-5 工具调用能力明显增强，特别是 GPT-5-Thinking 版本。 未来考虑会把 GPT-5-Pro 集成到 API 中，但是会非常贵 。 关于产品 新推出的聊天气泡颜色的定制功能是开放给所有用户 未来会考虑在 IDE 中让ChatGPT 以第三方插件的方式兼容进来。 关于模型与未来计划 之前传的很火的 Zenith 和 Summit，团队经过大量的测试以及评估，最终 Summit 在排行榜和内部测试中大幅优于 Zenith。 团队认为 GPT-5 相比于之前的 GPT-4 在很多方面都有重大的提升：推理、写作、指令遵循等。 考虑增加 Plus 用户的上下文长度，目前仅有 32K，非常的有限。 对于 GPT-5， 有一个遗憾是没能做大支持更长的上下文。研究人员 Michelle Pokrass 表示，如果计算资源、成本都允许的情况下，更愿意支持 1M 的上下文长度 与 Opus 4.1 的比较，OpenAI 认为两个都是非常好的模型。对于别家的模型，不能评价很多，但是它们认为 GPT-5 是它们发布过写代码最好的模型。 它们正在努力将推理和非推理模型统一为一个单一模型，并且考虑采用 Token 定价的方式而不是消息限制。 ChatGPT 的 memory 功能即将迎来升级。 GPT-5 在长文对话方面已经取得了进步 昨天新发的语音模型在指令遵循、响应都有很大的提升。同时，OpenAI 表示目前没有相关计划做一个数字人在语音模式中。（像 Grok 那样）

朋友们，大家好。 今天给大家带来 Anthropic 的 CEO，Dario Amodei 最近参加的一次采访内容的整理，他不仅分享了 Anthropic 飞速发展的秘密，更是对当前 AI 领域的诸多争议给出了自己的见解。 Dario Amodei 以及它背后的 Anthropic 公司一直以来颇具争议。一方面在编码领域，Claude 天下第一，不得不服；另一方面，Dario 本人以及 Anthropic 对中国以及中国用户持有显而易见的偏见，哪怕是海外用户，也对它们的模型限量策略怨声载道。 以及非常神奇的是Dario 本人早年还在百度呆过一年。 言归正传，不管 Anthropic 对用户到底是一个什么样的态度，这个公司的一些研究论文、访谈都是值得观看学习的。 访谈链接： https://www.youtube.com/watch?v=mYDSSRS-B5U 不愿被称为“悲观主义”的AI领导者 首先，Dario 对那些称他为“AI 悲观主义”的人感到非常愤怒。他表示自己绝非想减缓 AI 的发展。恰恰相反，他深知这项技术带来的益处，甚至能够拯救生命。如果技术早日加速实现，他的父亲也不会当年因病离世。 Dario 强调外界对他的很多批评是错误的，比如批评他想掌控、垄断整个 AI 行业 Dario 认为他自己以及 Anthropic 在阐述 AI 带来的好处方面甚至比一些盲目的“乐观主义者”做的更好。正是因为他们甚至 AI 能创造一个多么美好的世界，他才感到有义务去警示 AI 可能带来的风险，以此来督促人们把事情做对。 他强烈批评了那些不理解 AI 带来的好处、只知道“加速发展”的加速主义者，认为它们缺乏道德公信力。 AI 的指数级发展与 Dario 的“短时间线” Dario 认为整个AI领域最真实且核心的现象是指数级增长。也就是大家经常会看到的每隔几个月，新的 AI 模型会比前一个效果好很多，而这得益于对计算资源、数据投入和新型训练犯法的持续投资。 他观察到，AI 系统正在从几年前的“勉强能用”发展到“聪明的高中生”，现在正接近“聪明的大学生”甚至是“博士生”的水平，并开始在整个经济领域发挥作用。 尽管 Dario 认为预测未来是非常困难的一件事，特别是关于社会层面，但是对于底层技术的进步、发展，他非常的自信。他提到，虽然有 20-25% 的可能性模型在未来两年内停止提升，但鉴于他所看到的增长趋势，他愿意承担这种风险。 Dario 解释说，人们不太能理解指数级增长：一个每六个月翻一番的事物，在它真正爆发的两年前，看起来只完成了$\frac{1}{16}$。因此，我们现在可能正处于 AI 能力和收入的“爆炸式增长”的边缘。他将这比作 90 年代互联网的崛起，当时很少有人预见到它会以多快的速度带来全球数字通信网络。 ...

最近压力很大，工作上出现了一些问题，以及忙着搬家。 这趟搬家大概持续了两个月，直到这两天才逐渐搬完，搞定。我们找了一套开发商新装修好的房子，但是里面的柜子什么的都是没有的，需要我们自己弄。房东委托中介给我们安排了全屋定制。 但是这个做定制的设计师反正弄的也是一团糟，尺寸量的很多地方有问题，然后有的设计的地方也不符合我们的要求。反正来来回回装柜子、修、补，这些都做了一个月了，然后还有布置新家，以及我们自己搬家。整体是一个非常疲惫的过程，真的搬一次家感觉半条命都没了。我女朋友在这其中做了大量的工作，真的很不容易，特别是跟装柜子的人扯皮扯来扯去，都是她弄的。以我这种，“嫌烦，懒得管”、“不是自己的家，搞那么好”的这种心态，肯定是没法把这件事做的很好的。 如果说搬家、装修这些事早晚都会结束，还有些盼头，工作上出的这个问题，真的是在我的意料之外了。 4 月份，我女朋友因为我的引荐，入职了我现在在的公司，和我一个部门。但是直到前两周 Q2 季度结束，谈话的时候，我曾经最信任的领导给我的口径都是虽然不是很满意，但是都愿意再给机会试试。结果过了不到一周，就被通知解雇了，连试用期都没满，甚至 3 个月的时间都不到。而且是非常临时的通知，甚至一点心理准备都没有。下午通知的，当天就是 last day。 事情反正大致就是这样，但是其中细节，发生的种种令人恶心的事远不止这么简单。 我也并不能改变什么，但是这也给我上了非常深刻的一课。职场上哪怕和你关系再好的人，都不值得你信任。以及无论在哪里上班，都是给别人打工，在我熟悉的工作环境中，都碰上了这样的事情，更不要说陌生的工作环境了。这也由此激发了我自己创业的想法。 自己创业做的想法来源于两个方面： 对现状的不满意。我觉得我包括我所在的部门现在的工作是有问题的。从来没有好好的打磨过一款产品，每次都是只做成一个 demo，然后就不接着往下做了。一共就 10 个人左右的团队，却做了好多的 demo，但是一款像样的产品都没有。而在我看来，如果只是做 demo 的话，我一个人就可以做现在这个团队里的人做的东西，我认为它们做的都很烂。 发生在我女朋友身上的事，同样也给我上了一课。当初，想把她引荐进来，主要就是觉得这边相对稳定，然后部门领导也是认识的，相对比较熟悉点，不像在别的公司，逼事很多。结果没想到，才三个月不到，也发生了这样的事。如果连我这里都这样，更不要说其他公司了。所以企业、团队本质都是一样的，不是自己的团队，跟你关系再好，也都是假的。那与其这样，我不如自己干，反正我觉得我现在团队做的东西都很烂，我自己也能做。 反正事情虽然很糟心，但是也都发生了，改变不了什么。日子还要继续，希望会好起来。 碎碎念结束～

朋友们，大家好。 这两天读到开源的代码 Agent，Cline 团队的一篇博客，《Why Cline Doesn’t Index Your Codebase (And Why That’s a Good Thing) 》，做了一些整理和探索，来分享一下这篇博客内容。 先放原文链接：Why Cline Doesn’t Index Your Codebase (And Why That’s a Good Thing) 为什么RAG不行？ 早期，在模型上下文窗口还不大的时候，RAG 一直是作为让模型获取到额外相关上下文信息的办法而存在。哪怕到现在，这个市面上大部分的 AI 知识库解决方案也依然是 RAG，因为这种方法非常简单—它将知识库进行分块、创建嵌入、存储到向量数据库中，并在需要时会根据问题进行相关片段的检索。 但是，代码数据与其他数据不同。它是互相关联且不断演变的。当你将传统的 RAG 方法应用于代码库时，会出现三个关键问题： 1. 代码不是以块的形式思考 RAG 大致上来说可以分为两个部分：索引知识库（代码库）和检索。但是当你将代码块用于嵌入时，实际上是破坏了原有的代码库逻辑。举个例子来说，假设一个函数被调用是在片段 47，但是它的定义是在片段 892，而解释它存在的关键上下文又可能是散落在其他十几个片段中，先不说模型最后是否能够真正解决问题，就连把这些相关片段一次性全部检索出来，都是十分困难的。因为对于自然语言来说，一般的段落和句子，为创建具有语义意义的片段提供了明显的边界点，但是代码库的构造那就是完全另一回事了，所以简单的分块方法在准确界定代码有意义方面存在许多困难。 2. 索引随代码演变而衰减 实际上生产环境中，代码库不是静态的，而是一直在不断变化的。所以，索引不是一次性或周期性的工作。每一次你的代码合并都可能导致 AI的理解 与你的代码库之间存在分歧。所以，这也会导致你的代码助手会自信地建议调用不再存在的函数。 3. 安全 使用 RAG 还有一个最大的问题是安全。当你将你的代码库文件转换为向量嵌入时，你需要将其存储在某个地方。不管是云服务商，还是自己部署托管，都要花费额外的资源去做保证安全。 Cline 的方法 Cline 采用的方法更像一个真实的开发者在处理代码库时一样。它不提供索引或者嵌入。它只是通过遵循代码的自然结构来构建上下文，进行智能探索。 举例来说，你如果开发一个 React 组件。Cline 读取它，看到导入语句，然后跟随它。那个文件又导入另一个文件，所以 Cline 也跟随了那个文件。每个文件都建立在之前的基础上，从而形成一个相互关联的理解，展示你的代码是如何运作的。 这种方法其实非常依赖模型的上下文窗口。 无论是 Claude 4 也好，还是Gemini 2.5 Pro，都提供了非常大的上下文窗口。Cline 的这种像人类工程师一样阅读代码库的方法自然能生成高质量的上下文，因为它遵循的是代码库里的逻辑结构，而不是像 RAG 一样，把代码库文件切块，依赖语义进行匹配。 ...

故事的开始是发生在 1 年多前，硅谷发生了令人震惊的杀妻案件。凶手用拳头一拳拳打死了自己的妻子，再加上 华人、高学历、清华、大厂这样的无敌光环，这件案子当时格外引人关注。 但是随着时间的推移，关注度来的快去的也快，而且再加上天高皇帝远的，毕竟是在美国开的庭，接触到的后续相关信息也很少，大家对这件事的关注度就慢慢散了。 但是最近，这个案子又终于开审了，很多案件的细节都被曝光了出来。 作为一个经常需要依靠 AI 才能不在各类繁杂的信息源中不迷失的用户，觉得DeepResearch 真的太适合这类多个资料的搜寻、整合、最后输出了。 这不，正好 Kimi 的 Researcher来了么～ 我用 Kimi 的 Researcher 对硅谷杀妻案做了一个深度的报告，梳理了整个事件的始末发展。 首先，Kimi 的深度研究会先根据我的指令进行反问确认，确保自己能进一步理解清楚我的需求。 与我进一步确认之后，它开始进行搜索工作。 有意思的是，为了扩大搜索范围，它不仅用不同的中文关键词进行搜索，还同样使用英文关键词进行了搜索。 和大部分 Agent 不一样的是，Kimi 的 DeepResearch 是调用 Python 来写入一个 Markdown 文件。 当然，整个执行的过程中，并不是一帆风顺的，Kimi 还是会遇到困难，但是得益于端到端的强化学习训练，它能自己学会找到合适的办法解决问题。 最终，Kimi 给了我一份 12460 字的报告，详细梳理了案件的始末，以及目前的进度，并且做到了几乎每句话都有迹可循。 甚至，它还搜到了一些案件的惊人细节，比如第三者： 以及凶手可能的辩护策略： 详细报告因为长度关系，就不放在这里了。感兴趣内容的小伙伴可以直接私信我领取查看哦。 最让我觉得惊艳的是 Kimi 最后给我生成的那份可视化的报告，信息量和美感都非常在线。 您的浏览器不支持视频标签。 这份可视化报告同样保留了引用源的标注，提高了可信度的同时也方便查询。同时，它还针对一些关键信息（案件凶手和被害人之间的关系节点、整个案件发生的前后时间线等）画了流程图，便于理解。最后它也结合一些搜索到的法律人士的专业意见，给出了案件可能的最终走向，以及给出了一些建议来避免这类悲剧的事情再次发生。 整个报告的预览链接在这里➡️： https://www.kimi.com/preview/197b74a5-b521-8674-ba47-02a74b00051e 看完整个报告，从案发到现在，还是难以想象受害者临终前的绝望，一拳一拳被自己曾经最心爱的人打死，被迫离开了这个美好的世界。 那个曾经应该是用来监控小猫进食的摄像头，却意外拍下了这最残忍、惊悚的一幕。 ...

本文为 Langchain 官方博客“The rise of context engineering”的双语对照版本。 推荐阅读理由：随着 Agent 的快速发展，”context“ 的概念越来越被重视。无论是 Vibe Coding，还是 Deep Research，提供的 ”context“越具体完整，最后出来的效果都会很棒！LangGraph 作为最著名的智能体框架之一，了解它们是如何看待上下文的重要性的，无论是对我们个人平时 AI 的使用还是企业业务上 AI 的落地，都有很大帮助。 Header image from Dex Horthy on Twitter 来自 Dex Horthy 的 Twitter 头图 Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task. 上下文工程是构建动态系统，以在正确的格式中提供正确的信息和工具，使得 LLM 能够合理地完成任务。 Most of the time when an agent is not performing reliably the underlying cause is that the appropriate context, instructions and tools have not been communicated to the model. ...

Anthropic 前两天发了一篇文章，重点讨论了他们是如何通过多智能体系统来构建 claude 的“深度研究功能”。 文章链接： https://www.anthropic.com/engineering/built-multi-agent-research-system 我仔细研究了一下，觉得写的非常不错，所以写了这篇文章来细致解读一下到底该如何构建一个多智能体系统。 开始前，我觉得首先要理解两个概念，智能体（Agent）和工作流（Workflow）。 现阶段我们谈论的智能体绝大多数都是以大模型为核心，利用各种工具自主规划并完成任务执行 工作流指的是按照既定的顺序执行的一系列相互关联的任务。 当我们把智能体放入工作流中，也就有了智能体工作流，也就是大家一直以来听到的 Agentic Workflow。 传统的工作流，其实比较的死板。就好像写程序一样，运转到哪个节点，做什么操作，都是提前设置好的。而相比于传统的工作流，这种智能体工作流更加灵活，自主。 在这个工作流中，智能体通常能够结合环境，自主的判断下一步执行什么动作，并且能够将复杂的任务拆解为多个可执行的小任务。 有了这些基本的概念，我们就可以来了解一下 Anthropic 是如何构建自己的多智能体研究系统。 架构设计 Anthropic 设计的整个研究系统采用了典型的多智能体架构，一个主智能体 + 多个子智能体。这种架构借鉴了调度者-执行者模型（orchestrator-worker pattern）：就好像团队领导和他手底下的员工一样，领导负责总体规划和协调，按需要将一个活派给多个手底下的员工并行执行具体操作。 具体的架构图如下所示： 用户在 claude 聊天界面提出需要查询的问题，系统接收到用户请求后，会通过一个主智能体（Lead Agent）来处理任务。Lead Agent 相当于总负责人，具备使用各种工具的能力（如网络搜索工具、内部 MCP 接口工具、内存Memory等等）。Lead Agent 首先对问题进行分析和规划，然后派出多个子智能体（Subagent）并行进行工作，每个 Subagent 负责一个分支的搜索任务。Lead Agent 同时还需要与右侧的记忆模块（Memory）进行交互，这个模块用于在上下文超长时保存重要信息。 此外，还有一个专门负责处理引用的智能体（Citation Agent），它主要负责在最终报告中添加引用标注。 整个过程中，Lead Agent 通过任务描述与Subagent 通信，当 Subagent 完成任务后将结果返回给 Lead Agent，最终由 Lead Agent 整合所有 Subagent 的结果撰写出研究报告，然后交给 Citation Agent 插入文献来源标注，形成含引用的最终报告返回给用户。 ...

In this note, I’ll document some critical implementation details about the LightRAG framework that I discovered while deploying it in production. These insights, which weren’t immediately apparent from just reading the paper, emerged during my hands-on experience with the codebase and are worth recording for future reference. Paper Link: LightRAG: Simple and Fast Retrieval-Augmented Generation GitHub Link: LightRAG: Simple and Fast Retrieval-Augmented Generation Let me begin with an overview of LightRAG. ...