Agent 应用作为下一代应用底座：智能扩散，知识汇聚

一、综述：从技术底座到双向循环

不得不说，Agentic AI 绝对是现在最让人快乐的领域，甚至经常让我产生一种战后技术繁荣的错觉。每隔一段时间，各家的基础模型和 Agent 产品就会突然密集更新一批非常有意思的能力，基本上已经达成了“过几天就是一个 big day”的效果。

特别是在 2026 年，Agent 产品的迭代速度确实有点夸张。以前我们讨论 ChatGPT 的时候，主要还是在讨论它能不能回答问题；后来变成它能不能完成一个任务，比如做一份幻灯片、处理一个文档、分析一个数据集；而现在，产品设计正在从“完成一次任务”，继续走向“积累完成任务的经验”，甚至开始主动发现哪些工作值得变成 Skill、Memory 或 Automation。

从今年三月份开始，当我用 Agent 作为中心去想下一代数字应用的时候，我越来越觉得，Agent 应用不会只是另一种软件类别，它很可能会成为下一代应用的技术底座。

当然，先提一下写作这篇文章的八月份，我最喜欢的一条新闻。

Moderna 与 Merck 公布了个性化 mRNA 新抗原疗法 intismeran autogene 联合 pembrolizumab 用于术后高风险黑色素瘤的三期积极顶线结果。它仍然是研究性疗法，完整结果、总生存数据和监管结论都还需要继续等待，所以现在还不能把它写成一个已经完成验证的通用癌症治疗平台。Moderna 的官方说明

不过，这条路线最吸引我的地方依然非常明确：mRNA 提供了一种可编程的技术底座，而每一位患者肿瘤中的特征，又可以成为这个底座上的个性化配置。底层平台具有通用性，上层疗法根据具体对象定制；随着设计、制造、治疗和随访流程逐渐数字化，不同场景中的经验又可能反过来改进人们对疾病和技术平台的理解。

我特地提这个例子，不是为了说 Agent 与癌症治疗在技术上相同，而是因为它们背后有一种很相似的结构：

一个具有通用性的技术底座，进入大量个性化场景；不同场景产生新的经验，经过整理之后，再反过来推动底座进步。

过去，我会把这个结构写成：

基础模型 ↔ 数字化知识中心 ↔ 通用 Agent 应用 ↔ 定制化软件

现在我觉得，可以把它表达得更清楚一些。整个系统其实存在两个方向。

第一个方向是从数字化知识中心走向真实世界，把模型、Skill、Harness、工具和工作流带进不同软件与业务场景。我把它称为：

智能的扩散，Intelligence Diffusion。

第二个方向是从真实世界重新回到数字化知识中心，把场景中的任务、轨迹、结果、失败、纠正和边界，转化成可以被下一代 Agent 复用的知识。我把它称为：

知识的汇聚，Knowledge Aggregation。

如果把它画成一张图，大概会是这样：

┌────────────────────┐                 ┌────────────────────┐
│   数字化知识中心     │                 │   真实世界终端场景   │
│                    │                 │                    │
│ Models             │── 智能扩散 ───→│ Agentic Software   │
│ Skills / Harnesses │                 │ Persistent Agents  │
│ Evals / Contracts  │←─ 知识汇聚 ────│ Tasks / Outcomes   │
│ Policies           │                 │ Evidence / Failure │
└────────────────────┘                 └────────────────────┘

这里一侧是数字化知识中心，另一侧是真实的一线场景。Agent 应用、Agent Runtime 与 Agentic Software，是连接两侧的基础设施。

这个双向循环，也是整篇文章接下来要讨论的核心。

二、智能扩散：把 Agentic Software 带进每一个 Loop

Agent 产品竞速大赛

现在最热闹的事情之一，就是各家的 Agent 产品竞速大赛。

这里的竞争已经不只是模型分数，而是在探索 Agent 究竟怎样进入真实工作流，以及怎样降低人和 Agent 长期协作的成本。

Claude Code 支持了 Artifacts，可以把一个 Session 中正在进行的工作变成持续更新、可以分享和协作的可视化页面。它不是简单把回答做得更漂亮，而是在尝试把 Agent 的中间状态和工作过程变成团队可以共同理解的对象。Claude Code Artifacts

Anthropic 还推出了 Claude Tag。在 Slack 频道中，用户可以像 @ 一位同事那样 @Claude，让它读取经过授权的频道、工具和代码库，异步完成任务，甚至主动跟进没有解决的问题。不同 Claude 身份的记忆和权限还可以被限制在不同频道中。Claude Tag

Codex 推出了 Record & Replay。用户可以先演示一次工作流，Codex 再把目标、输入、步骤和验证方法整理成可以重复使用的 Skill。这件事最有意思的地方，是它让“教 Agent 做事”从写一份抽象说明，变成了先做一遍给它看。Record & Replay

后来的 Computer History 又继续向前走了一步。它可以在用户主动开启并选择数据来源之后，把跨应用活动整理成时间线和本地记忆，帮助用户恢复之前的工作，还会在发现重复模式时建议创建 Skill 或 Automation。它并不是一个持续录屏版本的 Record & Replay，而是一套以交互事件、摘要、权限和用户控制为基础的长期工作背景系统。Computer History

Cursor 的 /automate 允许用户直接用自然语言描述自动化目标，由 Agent 帮助配置触发条件、指令和工具。它还支持由 GitHub、Slack 等事件触发 always-on agent。Cursor Automations

Kimi Work 则把本地文件、浏览器、定时任务、专业数据库和长任务执行放进一个桌面 Agent 环境。它还可以按照任务复杂度组织 Agent Swarm。官方目前给出的上限是一次组织最多 300 个 Sub-agent，并支持持续数十小时、执行数千次工具调用的长任务。Kimi Work

我之前最喜欢 Kimi Work 的部分有点搞笑：它里面可以连接专业金融数据，所以我推荐给了炒股的同学，让 Agent 帮忙写量化回测。反馈是效果挺好，就是确实有点吃 Token，哈哈哈。

把这些产品放在一起，会发现它们的演进路线其实非常清楚：

回答问题
→ 完成任务
→ 生成可分享的 Artifact
→ 把流程外化成 Skill
→ 形成跨任务的 Memory
→ 成为长期运行的 Agent
→ 主动发现和改进工作流

所以，我把它叫作“竞速大赛”，不是因为大家都在做同样的聊天产品，而是因为 Coding Agent 大幅降低了从产品想法到功能实现的时间。一个好功能出现以后，其他产品很快就能跟上，于是竞争被迫继续向更远的地方推进：谁能更好地理解用户，谁能持续工作，谁能积累经验，谁又能把 Agent 安全地放进更多真实系统中。

Agent 应用为什么可能成为应用底座

于是，一个很自然的问题出现了：这些能力只是 Agent 产品的功能，还是具有平台性质的通用技术？

我的判断是后者。

今天开发 Web 应用时，我们通常不会重新实现一遍窗口系统、字体渲染、网络协议、本地存储、安全沙箱和跨平台适配，而是直接以浏览器为底座。浏览器当然不能替开发者理解业务，但它提供了一个足够通用的 Runtime，让开发者可以把主要精力放在自己的产品上。

成熟的 Agent 应用也在逐渐形成类似结构。基础模型提供概率性的理解与推理能力，而 Agent Harness 负责上下文、工具、状态、权限、审批、执行、验证、错误恢复和长期记忆。

我有时把基础模型类比为一种 NLPU，把 Agent Harness 看作它的 Runtime 和 Control Plane。这个类比当然不是说自然语言等价于 CPU 指令，而是说模型正在成为一种需要调度、约束和验证的概率性计算资源。自然语言适合表达目标，但是当一个动作可以被转换成代码、查询、测试或结构化 Tool Call 时，系统就应该尽快回到更确定、更容易验证的执行路径。

OpenAI 最近已经直接把 Codex 描述为一个可以嵌入其他产品的开放 Agent Harness：它负责 Agent Loop、状态、工具、沙箱和审批，而宿主软件继续拥有自己的 UI、业务规则、数据、权限和最终控制。Codex as a platform

学术上，AIOS 也在尝试把调度、上下文、内存、存储和访问控制抽象成 Agent Operating System 的服务。AIOS

这正是我所说的“Agent 应用作为下一代应用底座”。

它并不是说所有软件最终都会变成一个聊天框。恰恰相反，优秀的固定 UI 仍然非常重要。对于高频、确定性的操作，直接点击、拖拽、筛选和比较，通常比每次重新描述目标更快、更便宜，也更可预测。

真正的变化是，未来的软件不必重新实现一整套通用 Agent 能力。它可以保留最适合自己业务的界面和数据模型，同时把理解意图、组织上下文、调用工具、处理异常和长期学习的能力交给底层 Agent Runtime。

发布只是开始：用户成为软件共建者

当 Agent Runtime 进入普通软件之后，软件的形态也会发生变化。

传统软件主要由开发团队定义。用户可以修改设置，但是很少能够安全、低成本地改变产品本身。然而，用户才是离真实场景最近的人。

一个面对全公司的报销系统，对某个销售团队来说，可能有一半字段永远固定；同一份系统运行数据，安全、产品和工程团队关心的内容也完全不同。过去，中心开发团队不可能低成本地为每一种局部需求单独开发。

Agent 让这件事第一次有可能在经济上成立。

这个方向已经有非常直接的先例。Geoffrey Litt 在 2023 年提出 Malleable Software，认为普通用户可以在 LLM 的帮助下修改自己正在使用的软件，让 LLM 成为用户身边的“本地开发者”。他还特别强调，未来不会只有聊天框，而可能同时存在直接操作软件的内循环，以及让 LLM 帮助修改软件的外循环。Malleable Software in the Age of LLMs

我认为，Agentic Software 可以继续沿着这个方向向前走，形成：

公共产品内核 + 私人 Agent Overlay。

公共内核负责数据模型、核心能力、安全不变量、兼容性和公共 Verifier；私人 Overlay 负责用户自己的工作流、自动化、界面组织和表达方式。

用户不需要复制一份源码，也不需要先成为传统程序员。他可以通过表达意图、演示流程、纠正错误和验收结果，在受控边界内继续开发自己正在使用的软件。

比如，一家公司的报销系统要求用户下载发票、填写十几个字段、选择审批链并归档凭证。Agent 可以学习一个销售团队的实际流程，生成一个私人 Overlay：从发票和日历中提取项目、地区和金额，预填固定成本中心，只把异常项交给用户确认。

公共报销系统没有消失。Agent 只是把这个团队不需要反复处理的复杂度折叠起来。

当然，这不能变成“让 AI 随便改软件”。一次可靠的本地改造需要明确：

• 哪些界面、逻辑和资源允许修改；
• 哪些安全与业务不变量必须保持；
• 哪些操作需要用户批准；
• 修改后怎样预览和验证；
• 软件升级之后 Overlay 是否仍然有效；
• 出现问题时怎样回滚到公共默认状态。

如果每个人都在本地修改，还会出现另一个问题：软件会不会碎成无数无法测试、无法升级、也无法维护的私人分叉？

因此，本地有效的改造还需要一条回到公共产品的路径。

我提出的 Knowledge-based Pull Request，主要贡献的不是一份要求项目直接合并的陌生代码，而是足以让项目重新实现的产品知识：用户想改变什么，这个需求在哪些场景中成立，什么结果才算完成，哪些例子和反例定义了边界，什么不能被破坏，以及这个方案怎样在真实使用中被修正和验证。Knowledge-Based Pull Requests

项目自己的 Agent 再根据项目代码、架构、Policy 和测试重新实现。维护者首先审查问题、证据和边界，再审查最终实现，而不是一开始就试图理解外部 Agent 在陌生上下文中生成的大量代码。

GitHub 已经把 Agent PR 的增长与 Review Bandwidth 压力当作现实问题。Agent pull requests are everywhere

不过，KPR 目前依然只是一个需要验证的产品与研究提案。如果它并不能减少维护者的首次判断时间、澄清轮次、返工次数和合并后缺陷，那么它就只是一个更加复杂的 Issue Template。这个边界必须说清楚。

但如果它成立，本地改造就不再只是私人便利。真实场景中经过验证的需求，有机会反过来推动公共软件演化。

开发者作为智能分销商

这里还有一个很俗、但没有办法回避的问题：这个循环中的钱从哪里来？

今天的软件开发者在接入基础模型之后，首先是 Token 的消费者。用户使用得越多，软件公司支付的推理成本越高。如果开发者只能承担成本，却无法分享 Agent 带来的新增价值，那么很多软件不会有足够动力把 Agent 部署到所有细小场景中。

所以，我愿意保留一个稍微有点挑衅性的说法：

软件开发者可能成为基础模型公司与 Agent 平台的 Token 分销商。

这并不是完全没有现实先例。Poe 已经允许 Bot 创建者根据输入长度、输出长度和计算复杂度动态定价，并从用户使用中获得收入。Poe Bot Monetization API

但严格地说，Token 只是成本计量单位，不应该成为最终的价值单位。如果开发者的收入与 Token 消耗直接绑定，就可能奖励冗长、低效甚至故意增加调用次数的产品。

因此，更准确的长期概念应该是：

软件开发者成为 Agent 能力与价值的分销节点。

它可以按照 Token 或消息收费，也可以按照订阅、工具调用、交易、专业数据、成功结果或者节省的工作时间收费。

基础模型公司提供通用智能，Agent 平台提供 Harness 和 Runtime，软件开发者提供领域数据、业务流程、界面、客户关系和最后一公里的交付能力。三者共同完成智能扩散，也共同分享智能进入真实场景之后产生的价值。

当这条经济链成立以后，软件开发者才会真正有动力把 Agent 部署到更多此前不值得自动化的场景中。

而场景越多，另一条反向路径就越重要。

三、知识汇聚：真实场景如何反哺 Agent

当 Agentic Software 被部署到越来越多的真实场景中，会自然产生大量交互轨迹。

这里的轨迹不只是模型说了什么，还包括：

• 用户真正想完成的任务；
• Agent 观察到了什么环境状态；
• 调用了哪些工具；
• 哪一步失败了；
• 用户在哪里进行了纠正；
• 最终结果是否被接受；
• 哪些安全或业务约束阻止了某个动作；
• 任务完成以后是否产生了真实效果。

这些数据当然可能帮助我们训练更好的 Agent。但是，“场景更多、轨迹更多，所以模型自动变得更强”是一个非常危险的简化。

轨迹不等于知识，数量也不等于训练价值。

例如，一个 Agent 选择了错误工具，和产品根本没有给它提供正确工具，是两类完全不同的问题；模型没有理解用户意图，和用户自己也没有表达清楚目标，也不能被标记成同一种失败。如果所有错误都含混地归结为“模型还不够聪明”，那么再多轨迹也只会制造更大的噪声。

同一次任务还会产生两种所有权完全不同的知识。

一类是关于系统的知识：哪个工具不稳定，什么上下文容易缺失，什么时候应该升级给人，什么停止条件容易导致任务半途结束。这些信息在经过授权和脱敏之后，可以用于改进 Harness、Eval、Model Driver 和模型本身。

另一类是关于用户的知识：他的命名习惯、表达方式、风险边界、工作流程和验收标准。这些信息可以生成私人 Skill 或 Preference，但默认不应该因为“提高产品体验”就自动进入通用训练集。

前者让 Agent 系统变得更可靠，后者让当前 Agent 更理解当前用户。这两条学习路径可以来自同一次任务，却不应该共享相同的所有权。

从原始轨迹到可信知识

所以，数字化知识中心不能只是一个巨大的轨迹数据库。

一个真正有用的数字化知识中心，至少需要记录：

1. Task：究竟要完成什么；
2. Context：当时的环境与约束是什么；
3. Trajectory：Agent 与人的行动过程；
4. Outcome：最后发生了什么；
5. Evidence：为什么认为结果成功或失败；
6. Provenance：信息来自谁、经过了哪些修改；
7. Permission：这些信息可以用于什么；
8. Verifier：如何在未来重新检查这个结论；
9. Scope：这个知识适用于哪里，又不适用于哪里。

这也是为什么在技术层面，我更愿意把它称为：

Trusted Knowledge Aggregation，可信知识汇聚。

“Trusted”并不意味着相信某个中心平台，而是每一份进入公共知识中心的内容都可以被追溯、检查、撤销和重新验证。

原始私人数据甚至不一定需要离开本地。真正汇聚的可以是经过用户签认的 Claim、脱敏后的失败类型、可复现任务、Verifier、Skill、参数更新或者经过边界化的产品知识。

这也是 KPR 在整个架构中的另一个作用：它不只是软件协作协议，也是从私人场景向公共知识中心转移知识的一种可信边界。

三层不同的知识回流

“知识反哺 Agent”也需要进一步拆开。至少存在三个不同层级：

第一层是 Memory 与 Skill 回流。

它不改变模型权重，而是让当前 Agent 记住用户偏好、环境知识和经过验证的工作流。这是成本最低、反馈最快，也最容易保留用户所有权的一层。

第二层是 Harness 与 Eval 回流。

团队可以从失败轨迹中发现上下文缺失、工具设计错误、权限不合理、停止条件过早或者 Verifier 不足，然后修改 Runtime、Tool Schema、Prompt、Workflow 和测试集。

第三层才是 模型后训练回流。

当任务已经被重构为可复现环境，结果可以验证，失败可以归因，数据也获得了相应授权之后，它才可能进入 SFT、Verifier Training、Preference Learning 或 Agentic RL，真正改变模型权重。

现在已经有一些研究支持“高质量、多样化、可验证的场景数据能够提高 Agent 能力”这个判断。

Agent-FLAN 发现，Agent 训练数据需要把格式遵循、推理、工具使用和负样本进行更细致的设计；在其评测设置中，这种设计让 Llama2-7B 比此前方法提高了 3.5%，并通过负样本缓解了一部分幻觉问题。Agent-FLAN

SWE-Gym 收集了 2,438 个带有真实代码库、可执行环境和单元测试的软件工程任务，并报告了最高 19 个百分点的绝对提升。这里真正有价值的不只是“真实任务”，而是这些任务可以执行和验证。SWE-Gym

ATLAS 则给出了一个很重要的反例：完整模仿专家轨迹不一定最好。在它的实验中，只选择大约 30% 的关键规划和决策步骤进行训练，反而超过了使用完整轨迹的方案。ATLAS

APIGen-MT 也把重点放在多轮、不同场景和可验证数据上，而不只是扩大数据量。APIGen-MT

这些工作共同说明：

真正有价值的不是更多原始轨迹，而是更多经过授权、可以验证、能够归因，并覆盖不同场景的经验。

我觉得可以把训练价值粗略地写成：

知识价值
≈ 场景覆盖度
× 可验证性
× 可归因性
× 使用授权

任何一项接近零，这段轨迹的公共训练价值都可能非常低。

模型与 Harness 的共同演化

更进一步，Harness 本身不仅影响 Agent 今天怎样行动，也影响系统能够收集到什么样的训练数据。

如果 Harness 没有记录工具结果、失败原因和用户纠正，那么模型团队只能看到一段模糊的对话；如果 Harness 能够保存结构化状态、Verifier 结果、权限阻断和不同候选方案，下一轮训练就可以得到更清晰的成功、失败、恢复和偏好样本。

两篇 2026 年的预印本已经开始直接研究这种关系。

Recursive Harness Self-Improvement 把 Harness 同时视为任务执行机制和未来训练轨迹的生产机制，并尝试让 Harness 根据自己的历史表现继续改进。不过，它目前主要在合成的机器学习研究任务中进行实验，距离真实世界的通用自我改进还有明显距离。RHI

HELIX 则提出“构建 Harness—用验证轨迹更新模型—再为更新后的模型重建 Harness”的 Build–Update–Rebuild 循环。它展示了模型与 Harness 如何共同决定当前行为，又共同产生下一代训练数据。不过，目前的证据仍然只是代码修复任务中的一轮演化。HELIX

这与本文的双向循环几乎完全对应：

数字化知识中心
→ 模型、Harness、Skill
→ Agentic Software
→ 真实终端场景
→ 任务、轨迹、结果与证据
→ 数字化知识中心

智能通过 Agentic Software 扩散到更多场景；不同场景中的经验经过可信汇聚，转化成新的 Memory、Skill、Eval、Harness 和训练数据；更强的系统再进入更多场景。

至此，智能扩散与知识汇聚形成了一个完整的大 Loop。

四、XYZ to RSI：从人的 Loop 到 Agent 改进 Agent 的 Loop

如果把现代社会的工作拆开，会发现我们其实生活在无数个 Loop 之中：

观察环境
→ 理解问题
→ 作出判断
→ 采取行动
→ 检查结果
→ 根据反馈调整下一次行动

过去，这些 Loop 中真正提供智能的节点几乎总是人。软件负责记录、传递和执行预先定义的规则；一旦遇到模糊问题、目标变化和例外情况，人就必须重新进入 Loop。

Agent 改变的正是人在 Loop 中的比例。

而且，这种变化并不只是让 Agent 替代现有工作中的某几个步骤。

人的智能昂贵、稀缺，并且难以并行复制。因此，过去只有足够重要的问题，才值得让一个人持续观察、判断和反馈。大量细小、低频但长期存在的问题，根本没有条件建立完整的智能 Loop。

Agent 可以同时维持大量这样的 Loop：持续观察一个软件项目，追踪一组科研实验，维护一个人的知识空间，检查业务异常，或者在某个外部事件发生时重新启动任务。

所以 Agent 带来的不仅是：

现有 Loop 中，Agent 承担的比例越来越高。

它还意味着：

我们能够同时建立的智能 Loop 数量会大幅增加。

这就是我理解的 AgenticXYZ。

X：Crossing

X 是 Crossing，People with Agents，对应 Human in the Loop。

在这个阶段，Agent 进入人的工作流程，人与 Agent 共同完成任务。人通常负责目标、背景、重要判断和最终验收，Agent 负责搜索、整理、生成、执行和验证其中的一部分。

X 的重点不是“AI 犯错以后人来兜底”，而是人和 Agent 开始共同建立以前无法自动化的 Loop。

这也是今天大多数 Agent 产品所在的阶段。Agent 已经能够完成很复杂的工作，但任务通常仍然由人触发，长期目标仍然依赖人维护，跨时间的身份、职责和资源也不够稳定。

Y：Yours

Y 是 Yours，Agents for People，对应 Agents in Every Loop。

在 Y 阶段，Agent 不再只是一次 Session 中临时出现的工具，而会成为具有持续身份、状态、职责和资源预算的 Persistent Agent。

这里的“长期运行”不意味着它必须 24 小时持续占用 GPU。一个 Agent 可以在大部分时间休眠，但在时间、消息、数据变化或外部事件触发时重新工作。关键是：它跨越 Session 保留身份和状态，并对某项持续任务负责。

Y 的目标不只是每个人都拥有一个 Agent。

我希望给它一个更加明确、也更加有传播力的目标：

Y 的临界点，是世界上承担持续责任的 Agent 数量超过生物人类的数量。

为了避免这个指标被轻易刷出来，这里的 Agent 至少应该满足几个条件：它具有持久身份和状态，承担持续而非一次性的职责，可以被时间或真实事件触发，拥有明确权限和资源预算，并持续产生可以检查的结果。

批量创建几十亿个没有职责、没有状态、也不产生结果的空闲实例，当然不能算到这个目标里。

我们离 Y 还很远。今天绝大多数 Agent 仍然是由人临时发起、短时间运行、结束后失去责任关系的任务执行器。真正能够长时间存在、可靠管理权限、在多个场景中持续负责的 Agent 数量，还远远没有达到人口级别。

但 Y 之所以重要，是因为当 Persistent Agent 广泛进入真实世界以后，智能扩散的规模会发生根本变化。更多 Agent 可以进入更多 Loop，更多以前不值得自动化的问题开始拥有自己的智能反馈过程，真实场景也会产生更丰富的任务、失败和验证信号。

Z：Zero

Z 是 Zero，Agents by Agents，对应 Human beyond the Execution Loop。

但是，Agent 数量超过人类还不是 RSI。

它只是一个数量与覆盖率的拐点。

Recursive Self-Improvement 的经典含义，是一个系统能够利用当前能力，改进产生未来能力的机制。I. J. Good 在 1965 年讨论超智能机器时，核心设想就是机器参与设计更好的机器；Gödel Machine 后来进一步讨论系统在能够证明修改有益时重写自身代码。I. J. Good、Gödel Machines

所以，可以把三个层次区分开：

Agent 自动完成一个 Loop
= Agentic Automation

Agent 自动改进完成这个 Loop 的方法
= Self-Improvement

Agent 改进产生下一次改进的机制
= Recursive Self-Improvement

Z 的真正含义，是 Agent 不再只完成外部任务，而开始改进：

• 自己的 Memory 和 Skill；
• 上下文管理与工具选择；
• Agent Harness 与工作流；
• Verifier 与评测任务；
• 训练数据生成和筛选方法；
• 下一代 Agent 或基础模型的研发流程。

改进后的系统重新进入同一个过程，并且提高下一轮改进的能力，递归循环才真正开始闭合。

Anthropic 最近也用一条非常相似的路线描述 RSI：过去由人完成 AI 研发，后来聊天模型帮助其中一部分工作，再后来 Coding Agent 可以自己运行代码、委托任务和完成实验；如果未来 Agent 能够自主设计、训练和验证自己的继任者，才算真正闭合 RSI。Anthropic 同时明确表示，现在还没有达到这一状态，而且 RSI 也并非必然发生。When AI builds itself

Lilian Weng 的 Harness Engineering 文章则提出，近期更加现实的自我改进可能首先发生在 Harness，而不是模型直接重写自己的权重。Agent 可以先改进上下文、工具、Memory、工作流、权限和评测，再把这些改进产生的验证轨迹用于下一代模型。Harness Engineering for Self-Improvement

这样再回头看 AgenticXYZ，它就同时包含两种增长。

第一种是外延增长：Agent 数量增加，进入更多场景，承担更多 Loop。

第二种是内涵增长：知识汇聚让每个 Agent 的 Skill、Harness、Eval 和模型能力继续提高。

X 是 Agent 进入人的 Loop；Y 是 Agent 在越来越多 Loop 中承担持续职责；Z 是 Agent 开始改进产生更好 Agent 的 Loop。

因此：

Agent 比人多，是 Y 的人口拐点。

Agent 能够改进产生下一代 Agent 的机制，才是 Z 的递归拐点。

这里还有一条非常重要的边界。

Human beyond the Execution Loop，不是 Human beyond the Governance Loop。

人在 Z 阶段可以退出大量具体执行过程，但目标、价值、权利、不可修改的规则、资源上限、停止条件和最终责任，不能因为 Agent 数量增加而自动消失。

一个可靠的 Z 系统，不应该让 Agent 直接修改一切。它需要沙箱、版本、独立 Verifier、未见任务评测、权限边界、审计日志和回滚机制。一些不可修改的治理规则还必须位于递归循环之外。

Z 不是让 Agent 无边界地自我改写，而是在可以验证和回滚的条件下，让 Agent 逐渐改进自己的工作方式，以及产生下一代 Agent 的方式。

五、总结：应用底座只是开始

回到这篇文章最开始的问题：Agent 应用会不会成为下一代应用底座？

我的答案依然是肯定的。

不是因为聊天框会取代所有软件，而是因为成熟的 Agent 产品正在把上下文、工具、状态、权限、审批、长期记忆、任务执行、失败恢复和验证封装成一种新的 Runtime。

应用开发者可以继续拥有自己的界面、数据、业务逻辑和用户关系，同时复用一个成熟 Agent 平台的通用智能能力。就像浏览器曾经把大量跨平台复杂度收进一个共同底座，Agent Runtime 也有机会把概率性智能进入真实软件时的大量复杂度收进一个共同底座。

建立在这个底座上的 Agentic Software，不再只是开发者发布以后由用户被动使用的成品。用户可以在 Agent 帮助下形成私人 Overlay，按照自己最直接的一线场景继续改造软件；其中真正具有公共价值的知识，再通过 KPR、Verifier 和人的签认回到公共内核。

软件开发者也可能从 Token 消费者变成智能与价值的分销节点，让基础模型公司、Agent 平台、软件开发者和最终用户形成新的经济循环。

当 Agentic Software 被部署到越来越多场景之后，真实世界中的任务、失败和纠正会逐渐数字化。但只有经过授权、溯源、归因、验证和边界化之后，它们才会成为能够进入数字化知识中心的可信知识。

所以，这个循环不能被简化成：

部署更多 Agent，收集更多数据，训练更强模型。

更准确的说法是：

智能通过 Agentic Software 扩散到更多真实场景；经过验证的场景经验汇聚成新的 Memory、Skill、Eval、Harness 和训练数据；改进后的 Agent 再进入更多场景。

一侧是数字化知识中心，另一侧是真实世界的一线终端场景。智能从中心扩散出去，知识从场景汇聚回来。

而 AgenticXYZ 描述的，是 Agent 在这个大循环中逐渐提高比例的过程：

X：Agent 进入人的 Loop
Y：持续工作的 Agent 广泛进入所有 Loop
Z：Agent 开始改进产生更好 Agent 的 Loop

我们现在离 Y 还很远，更不用说 Z。但这并不妨碍我们今天就开始建设其中需要的 Agent Harness、Persistent Memory、Skill、Agentic Software、Knowledge-based Pull Request、Verifier 和数字化知识中心。

因为真正的 RSI 不会突然从某个模型里凭空出现。

它更可能来自无数个真实 Loop：智能先进入场景，知识再从场景回来；Agent 建立更多 Loop，更好的 Loop 又产生更好的 Agent；然后这个过程逐渐加速，直到 Agent 不只是参与工作，也开始改进产生下一代智能的机制。

如果要把整篇文章压缩成最后几句话，我会这样写：

X puts Agents into human Loops.

Y begins when persistent Agents with real responsibilities outnumber humans.

Z begins when Agents improve the Loops that produce better Agents.

Intelligence diffuses into the real world. Knowledge aggregates back. That is the path from Agentic Software to RSI.

智能将扩散到每一个真实场景，知识将汇聚回数字化知识中心。

发布只是开始。应用底座也只是开始。