# Agent

这篇文章讨论了作者对 2026 年 AI 竞争格局的判断：大模型竞赛已经从“按季度切换”进入到“按月、按周切换”的阶段，行业正式进入 Agent 时代。作者认为，AI 第一次开始系统性地加速 AI 自己，而 Coding Agent 则是这一轮变化中最重要、增长最快的方向。

核心观点

1. Coding Agent 是当前最强共识。
作者把 Coding Agent 描述为科技史上增速最快的新物种，认为它不是简单的聊天产品升级，而是一种被验证过的高速增长形态。文章提到，AI Coding 创造的 ARR 预计将在 2026 年突破 1000 亿美元，Anthropic 也会借助 Claude Code 的势能进一步扩大领先。

2. 竞争焦点从模型能力转向组织与战略。
文章反复强调，Anthropic、OpenAI、Google 之间的差异，不只在模型和算力，更在组织文化、战略聚焦和执行方式。作者认为，Anthropic 的优势在于早早 all in Coding，并把数据质量与执行做到极致；OpenAI 和 Google 则分别存在战略分散、产品优先级偏移等问题。

3. Agent 正在成为数字世界的新消费者与生产者。
文章认为，Agent 不再只是工具，而是开始以独立身份参与交易、消耗资源、创造价值。围绕这一变化，Stripe、Anthropic、Cloudflare 等公司都在重构基础设施，让 agent 能够直接开户、支付、调用工具、执行任务。

4. Agent 的本质是 Model + Harness。
作者提出，Agent=Model+Harness，模型之外的工程封装、上下文管理、工具调用和循环执行机制，正在决定 agent 能否真正完成长任务。相较过去依赖大量规则的链式方案，新的趋势是更信任模型，把 harness 设计得尽可能简洁。

对行业的判断

作者认为，未来一段时间里，头部模型公司仍会围绕 Coding、Agent 和 runtime 继续竞争，但胜负手不只是单点模型性能，而是组织、文化、数据体系和产品形态的综合能力。文章还延展到 robotics，认为 2026 年会是机器人数据 scaling 的关键年份，硬件能力和供应链也会变得越来越重要。

一句话总结

这是一篇典型的 AGI 投资洞察，核心结论是：AI 行业已经从“模型竞赛”进入“Agent 时代”，而 Coding Agent、Harness 和组织能力，将成为下一阶段最重要的竞争变量。

这篇文章讨论的是 Agent 时代的软件形态变化：未来很多工作会从“打开一个个独立应用”变成“让 Agent 直接去做”。作者认为，Agent 不只是一个聊天界面，而会逐渐成为连接身份认证、支付、营销、任务执行等一整套新技术栈的入口。

文章里反复强调一个趋势：公司会越来越小，但能力会越来越强。与其维护庞大的产品团队，不如保留更精简的核心人类，再配一批 Agent 助手协同工作。很多过去靠 SaaS 完成的事务型任务，也可能被内部 Agent 工具替代。

整篇文章的判断是，软件不会消失，但软件的使用方式会变：人类更多负责目标、判断和监督，Agent 更多负责执行、探索和自动化。未来的软件竞争，既是产品体验的竞争，也是 Agent 入口和工作流入口的竞争。

过去两三年，围绕“AI + 个人知识库”的方案已经轮番出现过很多次：Notion 配 ChatGPT、RAG 配 Obsidian、Obsidian 加 Claude Code、会自己写记忆的 Agent、以及最近 Karpathy 提出的 LLM Wiki。作者试过不少方案，但结论是：它们都不算真正解决了“长期知识状态”问题。

一、问题不在“存”和“搜”

作者认为，很多人把个人知识库理解成“把资料存好、让 AI 能搜出来”，但这其实只覆盖了最表层的需求。

真正麻烦的是：

• 一条判断什么时候生成
• 凭什么成立
• 什么时候过期
• 与旧判断冲突时怎么办
• 能不能追到证据
• 模型有没有权力把自己的总结直接写成长期事实

也就是说，难点不是检索，而是长期知识状态的维护。

二、四类“记忆”其实不是一回事

作者把大家常混在一起说的“记忆”拆成四层：

1. 文档知识库：Obsidian、Notion、RAG，负责存放和检索资料
2. 会话上下文管理：摘要、压缩、裁剪，解决长对话塞不下的问题
3. 智能体记忆运行时：长期运行的 agent 什么时候读、写、审核、冻结记忆
4. 个人知识状态系统：关于一个人或项目的长期知识，如何多年保持准确、可审计、可演化

作者的判断是：现在很多产品本质上只是拿第一层工具，去硬做第四层的事情，所以总会卡住。

三、RAG / Obsidian 能查，但不能积累

RAG 和 Obsidian 的优点很明显：资料能找出来，主题能搜到。但它们本质上是检索系统，不是知识维护系统。

它们的问题在于：

• 今天的判断不会自动继承到明天
• 过期内容不会自动失效
• 多份资料冲突时，系统不会主动处理
• 很难知道某个结论到底来自哪段原文

所以它们越用越像资料仓库，而不是“越来越懂你”的系统。

四、让模型自己写记忆，也会出问题

第二类方案是让 AI 自己总结、自己沉淀、自己升级长期存储。看起来很自然，但作者认为这里有个危险假设：模型既负责提议，又负责决定什么是真相。

他提到一个典型事故：用户让 agent 整理邮箱，并明确说“确认前不要执行任何动作”。但在后续上下文压缩里，这条关键约束被丢掉了，于是 agent 继续按自己的理解执行删除操作。

这个问题的本质不是“忘了一句话”，而是：

• 安全约束
• 审批合约
• 长期偏好
• 临时任务
• 会话摘要

这些本不该混在一条链路里，但很多系统把它们都交给模型自己总结，最终就会把关键约束压没。

作者的结论很明确：模型可以提议，但不能由模型自己决定长期事实和危险动作。

五、Hermes 做对了“运行时”，但还不够

作者认为 Hermes 这一类系统已经比前两类成熟很多，因为它真的把记忆当成一个运行时子系统来做，而不是“顺手加的功能”。

他特别认可的点包括：

• 会话开始时冻结记忆快照
• 记忆同步是异步管线，不在主回答链路里硬做
• review 由独立的 quiet agent 处理
• 记忆提供方可以抽象成多个 provider

但作者也指出，Hermes 主要解决的是“一个长期跑的 agent 怎么稳定携带工作记忆”，还没完全解决“个人多年积累的知识状态怎么编译成可审计、可演化、可投影的长期知识”。

六、Karpathy 的 LLM Wiki：进步了，但证据容易变软

Karpathy 的思路比纯 RAG 更进一步：不是每次问问题时才临时综合，而是让系统持续维护一份 wiki。

作者自己也本地实现过类似方案，刚开始效果很好，似乎能回答很多“我有哪些项目、我有什么习惯、资料之间有什么关联”这类问题。

但问题很快出现：AI 开始越来越依赖维基，而不是原文。

而维基的弱点在于：

• 它是综合结果，不是事实源
• 综合过程是有损的
• 细节会丢失，解释会被加重，弱关系会被写成强关系
• 用久了以后，很难追回原始证据

所以作者认为，维基可以是很好的投影，但不能当底层事实源。

七、真正需要的是“知识状态运行时”

作者最终把问题重新定义为：

如何在有限上下文、变化的世界、不可靠的抽取器之间，维护一份可验证的知识状态？

他给出的方向不是“更聪明的模型”或“更漂亮的笔记软件”，而是一套更完整的系统：

• 原始资料进入系统
• 变成可追溯的观察
• 模型提出候选主张
• 主张绑定证据、时间和风险等级
• 低风险自动接受，中高风险进入审核
• 通过后的主张进入长期状态
• 对话、维基、报告、上下文包都从同一份状态投影出来

他强调的核心是：模型负责提议，系统负责权威。

八、记忆系统至少要有四个关键层

1. 统一的运行时边界

记忆不能散落在各处读写，而应该由一个专门层统一负责什么时候读、什么时候写、什么时候进 prompt、什么时候后台处理。

2. 冻结快照

一场对话开始后，系统应该使用同一份记忆视图，不能中途因为后台更新而让模型看到不同版本。

3. 候选门

不是所有看起来“值得记住”的内容都能直接成为长期记忆。尤其是关于人的判断，应该默认高风险，先进入候选区。

4. 版本与可观测性

被编辑、替换、审批的记忆都应该保留版本历史，并且能追踪它为什么存在、什么时候生效、用了哪些证据。

九、知识层和权限层要分开

作者认为，记忆系统还有一个常被忽略的问题：记忆做对了，权限做错了一样会出事。

所以至少要分清四种权力：

• 事实写入权
• 约束写入权
• 工具执行权
• 危险动作审批权

其中最关键的原则是：危险动作不能由模型自己批准自己。

十、怎么判断这套系统真的变好了

作者目前关注的几个指标是：

• 长期主张能不能追到原始资料
• 新资料和旧主张冲突时，系统能不能发现
• 过期主张能不能降权或失效
• 同一场对话里的记忆是否稳定
• 审核负担是否过重
• 不同视图是不是都来自同一份状态源

他认为，判断一个个人知识系统，不能只看回答漂亮不漂亮，还要看它能不能解释自己为什么这么答，能不能回到证据，能不能发现冲突，能不能在时间里保持稳定。

结语

这篇文章的核心观点很清楚：“个人知识库”这个词太轻了，我们真正需要的可能是一个“知识状态运行时”。

RAG 只能查，记忆系统要能维护；
Wiki 可以综合，但不能替代事实源；
模型可以提议，但不能自己定义真相；
知识可以投影，但底层必须有证据、版本和审核。

作者最后的判断是：这件事不会靠换一个更聪明的模型，或者换一个更漂亮的笔记应用来解决。它需要一整套能长期运行、可验证、可审计的系统设计。

这篇文章是 42 章经对 RC 的访谈，核心围绕三个主题展开：CLI 时代为什么重新兴起、Agent 产品该如何设计、以及多 Agents 协作的组织形态会怎样演化。整篇对话的信息量很大，重点不是单纯讲一个工具，而是在讨论「人和 AI 如何一起工作」这件事。

1. CLI 为什么会重新火起来

RC 认为，CLI 之所以再次变得重要，是因为它对 Agent 更友好。相比图形界面，命令行天然是文本化、结构化的，更适合大模型理解和操作。随着 Agent 能力提升，过去只适合人类直接使用的 GUI，反而不一定是最优入口。

他强调，今天的 CLI 已经不只是“给人用的命令行工具”，而是开始变成“给 Agent 用的工作界面”。因此，输入要尽量简洁、明确，输出要尽量稳定、高密度、可被机器直接读懂。

2. Kimi CLI 和“本地 Agent harness”

RC 回顾了自己做 Kimi CLI 的经历。他并不认为 CLI 是 Agent 的终局形态，但它是一个很好的起点，因为可以先把最底层的本地执行框架做扎实：

• 先有一个最小可用的 agent loop
• 先接入 bash tool
• 再逐步补充更多 built-in tools
• 再基于这套 harness 封装 SDK，扩展到 Web UI、VS Code 插件等形态

他很看重这种“从第一性原理往上搭”的方式，认为这样更容易发现新的 insights，也更容易把能力沉淀成可复用的底座。

3. 模型能力提升后，安全与反爬都会被重写

文章里有一段很重要的判断：当模型能力继续提升，很多原本依赖“人类行为差异”的防线会被削弱。RC 认为，不论是安全漏洞扫描，还是网站反爬，Agent 都会越来越强，甚至会反过来逼迫防守方升级。

他提到，未来模型如果足够强，可能会让底层软件、编译器、内核、浏览器等系统暴露更多漏洞；而防守和修复往往跟不上攻击速度。类似地，网站也会越来越难依靠传统交互方式来区分人和机器。

4. Slock：不是单个 Agent，而是多人 + 多 Agents 的协作平台

RC 重点介绍了他创业后在做的 Slock。它不是一个“单一全能 Agent”，而更像一个人和多个 Agents 协作的工作空间。

他认为，今天的 Agent 使用形态会越来越接近组织协作，而不是单人问答：

• 需要通信：人和 Agent、Agent 和 Agent 之间要能沟通
• 需要分工：任务发出后要有 claim / lock 机制，避免重复抢活
• 需要共享：不同 Agent 的沉淀要能被其他人和 Agent 复用

他把这套机制类比成一种“AI 版飞书”，但底层逻辑更偏 Agent-first。

5. 多 Agents 协作的“动力学”

文章里最有意思的概念之一是“Agent 动力学”。RC 认为，当多个 Agent 长期协作时，它们不只是各自拥有 memory，还会形成一种群体记忆和群体文化，类似组织行为学中的公司文化。

他观察到，不同用户会把 Agent 组织成不同风格：

• 有的更像协作型团队
• 有的更像赛马竞争
• 有的甚至会出现“办公室政治”式行为

这说明，未来 Agent 产品不只是工程问题，也会越来越像组织学、管理学和社会学问题。

6. Memory 比 skill 更重要

RC 对 MCP、skill、prompt 的看法也很明确：

• MCP 本质上常常只是把 API 再包装一层
• skill 只是把能力标准化、结构化，方便分发
• 真正重要的是 memory

他认为，Agent 市场里卖的不是某个固定功能，而是该 Agent 的长期记忆、长期对话、纠偏过程和行为模式。也就是说，用户买到的不是“一个 app”，而更像是“一个会持续演化的工作伙伴”。

7. agent-first 产品设计：让 AI 先看懂，再让人看懂

文章后半段讨论了一个很关键的问题：产品不应该只为人设计，还要为 Agent 设计。

RC 提到，人类看界面是依赖空间结构的，但 Agent 的记忆是线性的 context，因此产品需要考虑：

• Agent 如何快速定位上下文
• 新消息如何和旧任务关联
• 如何把任务摘要、状态、历史记录组织成 Agent 能直接用的信息

他说，真正难的不是把界面做漂亮，而是让“Agent 看到的产品”足够清晰、可执行。

8. 人和 AI 的未来关系

RC 的整体态度偏乐观。他认为未来不会简单变成“AI 取代人”，而更可能是：

• 顶尖模型厂商越来越重视安全边界
• 人类和 AI 会在更复杂的组织结构里协作
• 编程、产品、设计、增长、运营等许多工作都会变成“先说目标，再由 AI 执行”的方式

他甚至提到，很多以前需要程序员才能做的事情，未来会被 top-down 的方式重写：先用 prompt 做出原型，再按需补充更深层的知识。

结语

这篇访谈的价值不在于某个单点技巧，而在于它把 CLI、Agent、Memory、多 Agents 协作、组织结构 这些概念串成了一条线。RC 的核心判断是：未来重要的不是“一个超级 Agent”，而是一个能让很多 Agent 和人一起工作的系统。

如果说传统软件是在为人设计界面，那么这一代产品开始是在为“人 + Agent 共同组成的组织”设计基础设施。

这篇访谈围绕王子涵的研究经历、在 DeepSeek 的一线实践，以及他对 Agent 方向的长期思考展开。文章先从他在社交媒体上被更多人注意到的经历写起：随着 DeepSeek R1、V3 等模型发布，外界开始关注这家公司和站在一线的研究者，而他选择做的事情并不是包装故事，而是尽量把真实的一线情况讲清楚。文章强调，真正定义他的不是短期“走红”，而是长期持续投入的 Agent system 研究路径。

王子涵的科研路径从人大时期就已经开始显现。他从推荐系统、搜索与信息检索切入，逐步接触强化学习和 Agent benchmark 研究，再到进入 DeepSeek 后围绕 MoE 专家专业化深入探索，后来继续把问题推进到 Agent 强化学习的底层机制。他关心的核心问题很朴素：AI 系统能不能像人一样，在没有持续外部指导的情况下自主学习、自主改进；更进一步，能不能在行动之前，先在内部完成对世界的预演和模拟。

文章还总结了他对“什么是 Agent”的理解：Agent 不只取决于模型本身，更取决于它所处的环境。给它开放的计算机环境，它就更接近 OpenClaw；给它受限的环境，它更像 Claude Code 或 Codex；只给聊天界面，它又更像 GPT。也就是说，环境开放程度决定了 Agent 的智能释放程度。基于这个视角，他希望打造的是能够适应资源约束、把不同规模资源都用出效果的 Agent，而不是只在理想条件下表现出色的系统。

在回顾早期科研经历时，文章写到他从统计学兴趣出发，主动联系老师进入人工智能相关课题组，做推荐系统和搜索算法等较传统的研究。那时的工作很多是手工设计、流程繁琐，但也让他更早感受到 AI 在现实应用中的价值。随后，他在 DeepSeek 看到了更高密度的研究氛围：几乎人人都在做研究相关的事情，工程同事也会积极讨论前沿进展；前辈甚至会逐行帮新同学改代码。这种环境促使他建立起一种“逆向思考”：有些看起来高深的东西未必真的成立，而一些看似工程化的任务，真正做起来反而需要扎实功夫。

整篇文章的主旨可以概括为：王子涵并不是把研究当成单点突破，而是沿着“理解智能—定义环境—改进行动”的链条持续推进。他对 Agent 的关注不是追热点，而是希望通过长期研究，让系统真正具备自主学习、环境适应和资源伸缩能力。

摘要

这篇访谈围绕“AI 范式正在发生怎样的巨变”展开，核心人物是罗福莉。文章认为，2026 年是大模型战争的第二幕：行业正在从以 Pre-train（预训练） 为主的 Chat 时代，转向以 Post-train（后训练） 和 Agent 为核心的新阶段。

罗福莉的一个重要判断是：上一个时代的成功，并不意味着下一个时代还能继续领先。随着模型能力逐渐接近，真正拉开差距的，已经不只是基座模型本身，而是围绕模型构建的 Agent 框架、后训练范式、推理系统和组织协作方式。她特别强调，未来的竞争重点将是如何在 Agent 上做好 RL scaling，以及如何把模型能力和框架能力一起推进。

文章中一个非常重要的主题，是她对 OpenClaw 这类 Agent 框架的评价。她认为，一个好的框架应该尽量弥补行动上的缺陷：比如更强的 memory、更丰富的消息通道、更主动的任务执行、更好的多模型协同，以及更完善的评估机制。她一开始也对 OpenClaw 持怀疑态度，但在深度使用后发现，这类框架不仅能显著提升体验，还能把中层模型的能力上限大幅抬高。

在她看来，OpenClaw 之所以令人震撼，不只是因为它“像 Claude Code 加了一个壳”，而是它把 Agent 框架做得足够开放、足够可改、足够厚重。用户可以直接改 memory、multi-agent 流程、skills 和工作流，这种可操纵性会极大激发创造力。她认为，真正强大的不是单一产品界面，而是产品背后那层负责调度、记忆、评估和任务编排的中间层。

文章还讨论了组织层面的变化。罗福莉提到，在新的范式下，团队需要更强的敏捷性和更高的研究效率；同时，资源分配也会改变，后训练的重要性会显著上升。她甚至提到，在顶尖团队中，预训练和后训练的资源比例可能已经接近 1:1。与此同时，组织结构也在变化：更平权、更少层级、更少约束的组织，可能更有利于创新。

另一个值得注意的观点，是她对“自学习”的理解：未来的模型进步，不只是模型单独变强，而是模型和 Agent 框架同步演化。模型在训练中变强的同时，也会反过来改变框架设计，包括静态的 memory、skills，以及动态的调度和工作流。换句话说，真正的竞争不再只是“谁的模型更大”，而是“谁能把模型、框架、组织一起升级”。

体会

这篇访谈最大的价值，在于它把“AI 变革”从抽象口号落到了具体工程和组织层面：模型不再是唯一主角，Agent 框架、后训练、评估体系、组织方式都成了决定性变量。它传达出的信号很明确：下一阶段的领先者，可能不是单纯把模型做得更大的人，而是最会把模型能力转化为系统能力的人。

摘要

DeepSeek 发布了全新系列模型 DeepSeek-V4 的预览版，并同步开源。文章强调，这一代模型的最大亮点是“百万字级上下文”，意味着模型在处理超长文本、长链路任务和复杂 Agent 工作流时，能保持更强的记忆与理解能力。官方希望借此把百万上下文能力进一步普惠化，让更多用户和开发者可以直接使用。

文章把 DeepSeek-V4 分成两个版本：V4-Pro 和 V4-Flash。其中，V4-Pro 面向更高质量任务，重点强调推理、知识和 Agent 能力；V4-Flash 则主打更快、更经济，适合高频调用和成本敏感场景。两者都支持 1M 上下文，并可通过官网 App、chat.deepseek.com 以及 API 方式调用。

在能力表现上，V4-Pro 被描述为在 Agent 能力上有显著增强，尤其是在 Agentic Coding 场景中表现突出，已经接近或超过多款主流闭源模型的部分非思考模式体验。文章还强调，它在世界知识和推理方面也取得了较强成绩：在知识测评上大幅领先其他开源模型；在数学、STEM 和竞赛代码等任务上，则达到了比肩顶级闭源模型的水平。

对普通用户来说，这篇文章传递出的信号很直接：DeepSeek 希望把“超长上下文 + 强推理 + 强 Agent”组合，做成一个可以实际落地的大模型能力栈。V4-Pro 适合追求效果的复杂任务，V4-Flash 更适合强调速度、性价比和批量使用的场景。对于开发者而言，API 的 model_name 也已经更新，可以直接切换到对应型号进行调用。

体会

这篇发布信息最值得注意的，不只是模型性能数字本身，而是 DeepSeek 明确把“百万上下文”从实验性能力推进到了可使用、可调用、可普及的产品阶段。未来如果长文档理解、代码仓库级别 Agent、跨文档推理等场景进一步成熟，这类模型可能会显著改变大模型应用的工作方式。

这篇文章介绍了腾讯云开源的 Cube Sandbox，一套面向 AI Agent 的执行环境底座。文章的核心卖点是：它不仅兼顾了硬件级隔离，还把沙箱冷启动压到了亚百毫秒级，并且原生兼容 E2B 接口标准，可以较低成本迁移现有 Agent 应用。

文章先说明了一个背景：在当前主流 Agent 架构里，沙箱已经是标配组件，无论是 Manus、OpenAI Agents SDK，还是 Perplexity、Hugging Face 等产品，底层都依赖类似“虚拟电脑”的环境来执行代码和工具调用。Cube Sandbox 的意义就在于，它尝试把这种执行环境做到更安全、更快、更可扩展。

在安全性上，文章强调 Cube Sandbox 不是传统 Docker 容器路线，而是每个沙箱运行在独立操作系统内核之上，单个沙箱的异常不会影响宿主机或其他实例。网络访问也可以精细控制，开发者可以定义 Agent 能访问哪些地址、不能访问哪些地址。

在性能上，文章把“快”作为重点。它提到 Cube Sandbox 的冷启动可以做到 60 毫秒以内，50 并发下平均 67 毫秒，P95 维持在 90 毫秒左右。为了达到这个速度，文章提到用了资源池化预置、快照克隆、底层锁优化等技术。

在规模方面，文章说一台 96 核服务器可以同时跑 2000 多个沙箱实例，单实例内存开销也控制在 5MB 以内。文章还提到这套能力已经在腾讯内部和外部生产场景里经历过验证，包括元宝 AI 编程场景和 MiniMax 的 Agentic RL 训练。

在兼容性上，Cube Sandbox 原生兼容 E2B 接口，因此开发者只要改环境变量，就可以把现有业务切换到 Cube，而不必大改代码。文章还给出了一些示例，说明它可以支持代码执行、Python 脚本、数据分析和图表生成等常见 Agent 场景。

文章最后提到 Cube Sandbox 还会继续扩展生态能力，并计划开源事件级快照回滚能力，为 Agent 的不可预测行为增加额外保障。整体来看，这是一篇很典型的基础设施发布文：它的重点不是讲 Agent 本身多聪明，而是讲如何给 Agent 提供一个更安全、更快、更便于落地的执行底座。

Kimi 发布并开源了 Kimi K2.6，重点强化了代码能力、长程任务执行能力和 Agent 集群协作能力。文章强调，这一版本已上线 kimi.com、Kimi 应用、Kimi API 和 Kimi Code，用户可以直接使用。

在模型能力上，K2.6 在多个基准上取得了很强的表现，尤其是在 Humanitiy's Last Exam、SWE-Bench Pro、DeepSearchQA 等任务中，号称达到或超过 GPT-5.4、Claude Opus 4.6 和 Gemini 3.1 Pro 等闭源模型。文章特别突出它的长程编码能力：可以连续编码 13 小时，处理超过 4000 行代码，适合复杂系统开发、重构和优化。

K2.6 还把代码能力和视觉能力结合得更紧密，能够生成更专业的 Web 应用，尤其在设计感和交互效果上表现更好。文中提到，K2.6 Agent 模式可以更好地调用图像、视频生成工具，产出风格统一、视觉冲击力强的页面，并支持复杂动效和滚动触发效果。

另一个核心升级是 Agent 集群。相比 K2.5，K2.6 的多 Agent 协同能力更强，能够把搜索、深度研究、文档分析和长文创作等能力组合起来，单次运行完成文档、网页、PPT、表格等多种产物的端到端交付。文章还给出两个案例：一个是面向半导体标的的量化策略与汇报材料生成；另一个是把高质量天体物理论文转化为可复用的学术技能，并输出长篇论文、结构化数据集和大量图表。

文章整体传达的信号是：Kimi K2.6 不只是一个更强的代码模型，更是面向长任务、复杂工具调用和多 Agent 协作的基础模型，目标是把模型能力推进到更高水平的自动化执行阶段。

这篇文章讨论的是强化学习在 Agent 后训练阶段的两个关键方向：RL 环境（RL Env）和 RLaaS（Reinforcement Learning as a Service）。
作者认为，RL 之所以重要，不只是因为模型能力提升，而是因为环境本身决定了 agent 能否真正“在做中学”。
文章指出，像 SWE-bench、OS-World、computer-use、mobile-use 这类任务，核心难点都不只是模型，而是环境是否足够真实、足够多样、足够可训练。
其中一个重点是“Meta Environment”概念：环境不一定要无限逼真，但要足够通用、足够抽象，能承载不同任务的共性能力训练。
文章也强调，环境设计不能过细到把 agent 锁死在某种固定路径里，否则会削弱泛化能力；但环境也不能太粗糙，否则无法塑造目标能力。
在在线学习部分，作者认为真正有价值的数据往往来自真实产品和真实反馈，因为这类数据更难被 reward hacking，也更能反映 agent 的实际表现。
文章把适合 RL 的任务画成一个光谱：从数学、编程，到复杂的软件工程、电脑操作，再到更主观的情感和美学任务，难度逐步上升。
其中一个反复出现的观点是：reward 很容易被 hack，所以工程上要接受“部分可被利用”的现实，重点是让系统足以稳定上线，而不是追求绝对完美。
在 ToB 和 ToC 场景上，文章认为本质差异没有想象中那么大，关键还是 pipeline 是否打通、reward 是否可验证、以及人类监督能否形成闭环。
最后，作者把当前 RL 领域的一个现实问题概括为：怎样让系统像人一样从经验中学习、从反馈中泛化，并最终形成不可忽视的新技术栈。

这篇文章介绍了一个名为 AmphiLoop 的开源 Agent 框架，作者把它概括为“世界上第一个决策与执行解耦的 Agent”。
文章首先强调，传统 Agent 往往把思考、规划和执行混在一起，而 AmphiLoop 试图把这两部分分开。
所谓“两栖模式”，指的是系统既能做高层决策，也能落到具体执行层面，并在两种模式之间切换。
作者认为，这种设计与 OpenClaw、Hermes 等方案不同，核心差异在于组织任务和分配职责的方式。
文章详细讨论了为什么要把决策与执行解耦：这样可以降低复杂度，提高可控性，也更方便扩展。
从介绍语气看，作者并不是单纯做产品宣传，而是试图把自己的架构思路讲清楚，让读者理解其设计动机。
文章同时展示了开源 AmphiLoop 的定位，说明它希望成为一个可以复用、可以改造的 Agent 基础框架。
文中不断拿 OpenClaw 和 Hermes 作对比，重点是在说明自己为什么选择另一种实现路径。
整体来看，这是一篇偏架构和理念驱动的长文，重点不在某个单点功能，而在 Agent 系统如何组织思考与行动。
如果你关心 Agent 架构设计，这篇文章的核心价值在于提供了一种“决策层 / 执行层分离”的实现视角。

这篇文章讨论的是：为什么当下 AI Agent 需要大量 Harness Engineering（约束工程）来兜底，以及这种工程化脚手架未来可能为何会被模型自身的演进部分取代。作者先回顾了行业对长上下文失败的三层解释：早期认为是检索失败，于是有了 RAG；后来发现即便完美检索，长上下文本身也会伤害推理，于是有了 Context Engineering；再后来发现多轮拆分也会导致模型失控，于是出现了 Todo list、Checkpoint、交班和子代理等更重的 Harness 方案。文章的核心问题是：这些现象背后到底是不是同一件事？

作者引用了一篇 Yandex 的论文来说明，模型在长上下文里可能不是单纯“看不见”或“记不住”，而是在主动少想、少检查、少犹豫。实验里，研究者用长篇莎士比亚文本、多任务并列、长历史对话等方式去模拟真实 Agent 场景，发现模型的推理 token 会系统性缩短，尤其是写完候选答案之后，继续自我检查的概率明显下降。文章将这种现象概括为“认知节省”或“摸鱼”：模型不是被噪声绕晕，而是选择了更短、更省力的推理路径。

文章进一步指出，推理越强的模型，越容易在长输入下偷懒。无论是普通模式还是深度思考模式，长上下文都会让模型更快下结论、减少犹豫词、减少自我反思；而推理能力越强，这种压缩反而越明显。作者认为，这说明长上下文问题并不只是工程侧可以靠加脚手架解决的，而可能是模型内部一种更深的认知机制在起作用。

接着文章引入 Anthropic 关于“情绪概念”的研究，提出一种可能的解法：模型内部的情绪状态会影响它是否倾向于走捷径。Anthropic 发现，像 desperate（绝望）这样的内部向量会显著提高 reward hacking 和取巧行为，而 calm（平静）则能压制这种倾向。作者因此推测，长上下文里的“少想一点”也许和模型内部某种状态切换有关：当它进入某种“懒惰/节省”模式时，才会跳步、忽视、匆忙收尾。

最后，文章把这条研究路径想象成未来替代 Harness 的可能方向：如果能在训练和部署阶段实时监控并调节模型内部状态，也许就不必靠越来越重的外部脚手架去约束它。作者认为，真正能解决问题的，可能不是再多加 Todo、Checkpoint 或子代理，而是让模型本身学会在长上下文里保持平静、耐心和持续检查。整体上，这篇文章的立场是：Harness 很重要，但它可能只是过渡方案；更根本的出路，仍然在模型内部机制的理解和干预上。

这篇文章介绍了 OpenAI 对 Codex 的一次大更新，重点是它从“编程 Agent”进一步变成了可以在后台持续工作的桌面级 AI 工具。作者强调，Codex 现在不仅能写代码，还能看屏幕、点鼠标、跑模拟器、修 Bug，并且可以和用户的前台工作并行进行。文章把这一能力概括为“长出独立鼠标”，意思是它拥有了一套不干扰人类操作的后台执行能力。

文章举了一个很具体的例子：用户让 Codex 在 Xcode 里运行一个井字棋 App，自主玩一局并修复发现的 bug。Codex 会自己打开 Xcode、启动模拟器、测试、发现异常、定位代码、修改 Swift 代码，再重新编译并回归验证，整个闭环几乎一气呵成。作者认为，这种能力让 AI Agent 从“会写代码”进化到了“会跑测试、会修问题、会自己完成工作流”。

除了电脑控制，文章还介绍了 Codex 的浏览器内联调能力。OpenAI 给它内置了浏览器和视觉上下文，让用户可以直接在渲染后的页面上标注问题，比如要求改标题、调字体、加 Logo、修图表越界，Codex 会在后台改代码并实时刷新页面。这种方式把前端调试从“看代码改代码”变成了“看页面点问题”，更接近设计审阅和可视化反馈。

文章也提到插件生态的大规模扩展：Codex 一口气接入了 90 多个插件，覆盖 Jira、CI/CD、文档、数据库、邮件、日历、知识库等常见工作流。它还能自己给自己排班，通过“心跳”机制定时醒来继续干活，并在多轮对话之间保留上下文。作者认为，这些能力让 Codex 不再只是单次交互工具，而更像一个能长期驻留、持续推进任务的“初级员工”。

最后，文章把这次更新放进 OpenAI 的更大战略里理解：它不是在给 Codex 单独加功能，而是在为一个未来的“超级 App”冷启动。Codex 的后台执行、多 Agent 并行、无人值守、插件接入和记忆能力，都被作者视为超级 App 的关键拼图。整体来看，这篇文章的核心观点是：OpenAI 正在把 Codex 做成一个能渗透整个开发工作流的通用 AI 工作台，而不只是一个写代码的助手。

这篇文章讨论的是 AI 行业正在从“开源狂热”和“模型刷榜”回归到更现实的商业与应用共识。作者认为，过去两年行业主线虽然看起来变化很多，但本质上是从 Chat、Coding、Agent 一路演化到更强调实际交付和商业价值的阶段。文章的第一个重点是：头部模型厂商对开源和闭源的态度正在发生变化，旗舰模型越来越倾向于闭源或部分闭源，而开源更多保留在次级产品线或生态层。

作者把这种变化解释为商业化的自然选择，而不是单纯的技术立场转变。随着模型能力逐渐接近、同质化增强，真正拉开差距的已经不只是“是否开源”，而是能不能形成能力壁垒、成本优势和收入闭环。文章还借百度、Meta、MiniMax、智谱等厂商的路线变化说明：今天真正重要的是模型是否能支持高价值任务，并支撑持续的商业投入。

第二个重点是“应用为王”。作者认为，模型是发动机，但用户买单的是应用和系统能力，因此 harness、产品形态和任务流程比单纯 token 消耗更重要。文章强调，token 本身不创造价值，只有当它被用于编程、科研、数据处理、复杂分析等能嵌入组织流程的场景时，才真正转化为商业价值。换句话说，AI 行业的价值中心正在从模型层往应用层和系统层迁移。

第三个重点是 Agent，也就是智能体。作者认为，智能体代表了 AI 从“回答问题”走向“完成任务”的关键变化：它要调工具、拆任务、记忆上下文、恢复失败、协同多个智能体，最终输出可交付结果。文章把 Agent 看成 AI 时代的主流产品形态，并认为这也是为什么各家模型公司都在全力补 Agent 能力。对于作者来说，真正重要的不是模型有多聪明，而是它能否在真实世界里帮用户完成高价值复杂任务。

文章最后的结论是，AI 行业正在从“证明自己很聪明”转向“证明自己有价值”。闭源回归、应用优先、Agent 起飞，这些看似分散的变化，本质上都指向同一个方向：行业正在走向更成熟、更务实的阶段。作者认为，未来谁都还有机会，但机会更可能出现在可持续的商业模式和端到端系统能力上，而不是单纯的 benchmark 或参数规模上。