AI News｜2026-10-13

今日目录

• Codex 把 GPT-6.1 Sol 默认上下文提到 500k，取消长上下文费
• 同一改动下，Codex 订阅用户用长上下文不再额外收费
• Karpathy 更新 LLM 扩散漏斗：多数人连模型都还没真正用过
• Aaron Levie：agent swarm 可能是终极形态，但几乎没人真的在用
• Rasmic：还没到信任 agent 的程度，靠证据链降低人审摩擦
• Garry Tan：能用确定性代码就别用 LLM 调用
• Matt Turck：从 Flash 开发者到 harness 工程师，角色一直在换

今日判断

今天最值得记的一笔是 Codex 把 GPT-6.1 Sol 在 Codex 和 Work 里的默认上下文从 272k 提到 500k，超过 500k 也按订阅走、不再收长上下文费。这比参数数字更能说明问题：真正的瓶颈不是模型能不能吃 1M，而是工作流里频繁 compaction 会打断 agent 的连贯推理。默认值调到 500k，等于官方承认大多数真实任务需要跨文件、跨时段的上下文，之前那个 sweet spot 定低了。对做 coding tool 的人来说，接下来该测的是同一个任务在 500k 下能不能少一次手动重述、少一次上下文裁剪，而不是把窗口盲开 1M。

另一条线是 Karpathy 和 Aaron Levie 从两个方向说同一件事：LLM 的能力分布是个漏斗，绝大多数人只把 AI 当增强版搜索，agent swarm 那一端几乎没人。Levie 的说法我更认，但它对 builder 的启发不在于做更炫的 swarm，而在于先把单个 agent 的证据链做扎实。Micky 那段 workflow 讲得直白：手动 review 还是最后一步，他用 evidence-driven testing 和 greploop 让 agent 先自证做了什么、为什么是对的，本质是在降低人审的摩擦，而不是取消人审。这和 Garry Tan 说的把部分 LLM 调用换回确定性代码是一个方向，能确定性解决的别交给模型。

我看下来，今天没有大模型发布级别的新闻，真正的信号都在工程决策层面：长上下文默认值被重新标定，agent 的信任靠证据而不是靠宣传，确定性代码和 LLM 的边界在被重新划分。对一线 builder 来说，这比追新模型更值得花半天时间验证。

快讯

1. Codex 把 GPT-6.1 Sol 默认上下文提到 500k，取消长上下文费

查看原文 · 来源：Thibault Sottiaux (@thsottiaux)

OpenAI 的 Thibault Sottiaux 说，GPT-6.1 Sol 在 Codex 和 Work 里的默认上下文从 272k 提到 500k，涨幅约 80%，未来还会更高，模型上限仍是 1M。他明确说这次调整是为了减少 compaction、让需要长时间保留上下文和细节的任务更连贯，而不是单纯堆窗口。配合另一条推文，这一档长上下文在订阅制下不再收额外费用。对用 coding agent 的人来说，这意味着默认配置下跨文件、跨时段的推理会少被打断，之前围绕 272k 设计的切分和摘要策略可能要重测。我的判断是，500k 作为默认值比 1M 作为上限更有意义，因为默认值才是绝大多数任务实际跑的那条线。

2. 同一改动下，Codex 订阅用户用长上下文不再额外收费

查看原文 · 来源：Thibault Sottiaux (@thsottiaux)

Thibault 补充说，从订阅里调用 GPT-6.1 Sol 时，长上下文不再单独计费。这条看似小，但改变了团队的成本模型：以前长上下文是显式成本项，团队会刻意压缩、截断或做摘要，现在在订阅额度内可以更放心地用满 500k。对做 agent 产品的团队，这意味着上下文长度从成本约束变成工程约束，选择变多，但也更容易写出靠堆上下文掩盖设计问题的实现。我的判断是，收费口径变了以后，真正该优化的是检索和状态管理，而不是无脑塞满窗口。

3. Karpathy 更新 LLM 扩散漏斗：多数人连模型都还没真正用过

查看原文 · 来源：Andrej Karpathy (@karpathy)

Karpathy 把 4 月那条推重新翻出来，认为理解 LLM 能力的人群差距不是在缩小，而是变成了一个更陡的漏斗：约 75% 的人几乎没接触过 LLM，约 20% 是免费产品的轻度用户，把模型当更好的搜索或写作工具，剩下的一小部分才真正在跑复杂 agent 工作流。他举了非技术朋友和很多非数学、非编程专业人士的例子——他们理智地觉得没什么用。这条对做产品的人重要，因为它提醒你，默认用户不是你自己，聊天框形态可能已经把大量潜在价值挡在外面。我的判断是，机会不在于教育这 75%，而在于给那 20% 设计不用改变习惯就能进入更深工作流的入口。

4. Aaron Levie：agent swarm 可能是终极形态，但几乎没人真的在用

查看原文 · 来源：Aaron Levie (@levie)

Levie 说现在 AI 扩散还极早期，大部分人只是把 AI 当聊天机器人做接近下一代搜索的事，这严重低估了模型能力；另一端，agent swarm 可能是 agent 进入工作流的最终形态，凡是任务可并行、算力能加速的领域——数学、网络、生物、材料、软件工程、金融——都符合这个特征。但今天用这种方式的人少之又少，受模型能力、成本和可用 harness 限制。对做 agent 基础设施的人，这段话的价值在于它把 swarm 从概念拉回到具体领域和约束条件。我的判断是，短期内别急着做通用 swarm，先在一个任务可并行的垂直领域把 harness 和成本曲线跑通。

5. Rasmic：还没到信任 agent 的程度，靠证据链降低人审摩擦

查看原文 · 来源：Peter Yang (@petergyang)

Peter Yang 引述 Rasmic 的话：他现在还没到完全信任 agent 的程度，尤其是面向用户的部分，所以手动 review 仍是最后一步，但他用 evidence-driven testing、before/after 对比和 greploop 让 agent 先证明自己做了什么、为什么是对的，把 review 从重新检查变成看证据。Rasmic 说对开发者来说手动 review 本来就是最烦的部分，这套做法是在降低摩擦而不是取消人审。对正在把 agent 放进真实交付流程的团队，这比讨论 agent 能不能自主更有用。我的判断是，信任问题短期内会靠证据链解决，而不是靠模型变强自动消失。

6. Garry Tan：能用确定性代码就别用 LLM 调用

查看原文 · 来源：Garry Tan (@garrytan)

Garry Tan 说把 LLM 调用换成确定性代码是不用想的事，而且结果代码更好、更贴合用户需求。这条没有展开，但方向清楚：模型负责理解和模糊判断，能写成确定逻辑的部分就写死。对做 agent 的人，这对应一类常见错误，把本该用代码保证的步骤交给模型，既增加延迟和成本，又引入不确定性。我的判断是，随着 agent 进入生产流程，确定性代码和模型调用的边界会变成一项核心设计能力，今天这条可以当作一次提醒。

7. Matt Turck：从 Flash 开发者到 harness 工程师，角色一直在换

查看原文 · 来源：Matt Turck (@mattturck)

Matt Turck 把技术角色变迁串成一条线：打孔卡操作员、Lotus Notes 管理员、Flash 开发者、Dreamweaver 建站者、DevOps 和 Tableau 分析师，现在是 agent manager 和 harness engineer，结论是会没事。这条不是新闻，但它给今天 agent 工具链的从业者一个参照系。harness engineer 这个词值得注意，它指的不是写模型，而是设计 agent 运行环境、工具接口、上下文和反馈回路的人。我的判断是，这类角色在接下来一两年会明显增多，但要求是把模糊任务拆成可验证步骤，这跟传统前端或运维的技能并不完全重合。