• 引言
• 一个没有传统前端的科研软件
• 为什么不是“人人写一个定制 App”
• Vibe Coding 的结构性税
• 软件的编译目标变了
• Skill 不是插件，而是新的软件单元
• 便宜的不只是形态，还有定价层级的错位
• LLM OS 不是一个比喻
• 这个例子可以推得很远
• 这个项目给出的设计原则
• 结语

引言

过去一年里，关于 AI 和软件的讨论大多停留在一个很直观的图景上：人提出需求，AI agent 帮人写代码；代码写完之后，软件还是传统软件，只不过生产过程被加速了。所谓 vibe coding，本质上就是把软件生产的边际成本打下来，把原来需要工程师逐行实现的东西，变成一轮又一轮自然语言驱动的生成、调试和重构。

这个判断是对的，但只对了一半。

更大的变化不是 AI 会不会生成软件，而是“软件”这个词本身会不会变。用 AI 生成一个新的独立 App，很多时候像是把发动机装在马车上：动力系统已经变了，但形态还停留在旧时代。你仍然有前端、后端、账户系统、部署、数据库、权限、日志、订阅、设置页，只是这些东西现在可以被更快地生成出来。

但如果引擎已经足够强，也许我们根本不需要继续优化马车。真正的下一代是：软件不再只是由 AI agent 写出来（by agent），而是开始存在于 AI agent 之内（within agent）。

下一代软件，不一定是一个完整 App、一个网站、一个桌面客户端，甚至不一定是一个固定入口的 CLI。它会是一组 prompts、skills、scripts、schemas、local files、cache conventions、tool permissions 和 agent-facing instructions。真正的运行时不是某个专门写出来的智能应用，而是 Codex、Claude Code 这类越来越强的 general agent。换句话说，现在的 Harness 其实就是下一代的软件本身。

Everyday ArXiv 这个项目正好是这个 insight 的一个具体例子。

一个没有传统前端的科研软件

Everyday ArXiv 是一个每日 arXiv 智能处理助手。传统做法大概会是：写一个后端服务，接 arXiv API；写一个推荐算法；做一个用户系统；做一个网页或邮件推送；把 LLM 调用嵌进某些节点，比如摘要、打分、推荐理由和邮件草稿。最后它会变成一个面向研究者的 specialized agent 或 SaaS。

这个路线没有错。很多产品也会继续这么做。问题是，在这个具体场景里，最有价值的部分并不是 UI，不是数据库，也不是固定 pipeline，而是每次阅读时的判断。

今天这篇论文为什么值得读？它和用户之前哪篇文章真的有关？它只是关键词相似，还是方法上产生了新的连接？一个 idea 是不是又落入了“加噪声、换模型、做更大数值”的平庸扩展？一篇新论文没引用用户工作时，到底是明显遗漏、弱相关，还是只是概念上有一点相邻？

这些问题很难被压成一个固定软件功能。它们更像研究助理的判断过程。所以这个项目的架构反过来做：Python 代码只负责确定性的部分，比如抓 arXiv metadata、解析 Google Scholar、写稳定 JSON cache、读取配置、维护本地文件边界。判断性的部分不写死在应用里，而是交给通用 agent。仓库给 agent 提供的是 workspace、skill、profile、prompt、脚本和隐私规则。

换句话说，这不是一个“带 LLM 功能的软件”，而是一套“让 LLM agent 直接运行的软件”。

为什么不是“人人写一个定制 App”

一个常见判断是：AI 让软件生产成本降低，所以以后每个人都会为自己写很多小 App。真正发生的可能不是人人都有一堆 custom apps，而是很多 custom apps 根本不会以 app 的形式存在。

因为一旦 general agent 足够强，很多“软件”没必要被编译成独立产品。它可以保持为开放形态：几条 Skill、几个脚本、一组目录约定、一份 profile、一些 examples。它的功能在每次运行时由 agent 临场展开。它没有固定按钮，但有明确协议；没有完整后端，但有稳定工具；没有页面，但有 Markdown 或 HTML 报告；没有内置智能模块，但能调用 agent 的通用智能。

这比 vibe coding 更进一步。Vibe coding 仍然默认目标是生成一个软件。Agent-native software 的目标是避免生成一个旧形态的软件。它问的是：什么是软件，是否现在形态还不是软件的最终答案？

Vibe Coding 的结构性税

Vibe coding 的诱惑在于，它让我们第一次感觉到：写一个软件好像不贵了。你可以让 agent 生成一个 full-stack repo，带 React 页面、API route、数据库 schema、Dockerfile、鉴权、部署说明和 README。

但这也暴露出一个问题：AI 生成得越快，旧软件形态的结构性税越清楚。

独立 App 有很多默认税收。你要付 UI tax，因为每个能力都要被设计成按钮、表单和页面。你要付 deployment tax，因为每个能力都要有自己的运行环境。你要付 integration tax，因为每个新 App 都要重新接入数据源、权限和用户状态。你要付 maintenance tax，因为依赖会漂移，框架会升级，部署会坏。你还要付 product-shape tax，因为很多开放的判断过程，必须被压缩成固定功能，失去灵活性和定制性。功能凝固在代码中，遇到长尾未定义需求会直接 报错。

当任务本质上只是“在特定上下文里执行一个高判断密度 workflow”时，这些税就显得很重。

Everyday ArXiv 如果被做成传统软件，就会被迫发明很多并非核心价值的东西：推荐页面、profile 编辑器、PDF 阅读器、邮件草稿编辑器、后台任务、账户系统、同步状态。它们当然可以做，但它们不是“读 arXiv 并做研究判断”的核心。核心其实是：把用户画像、当天论文、论文全文、历史偏好和科研品味放进同一个 reasoning loop。

如果通用 agent 已经能读文件、跑命令、调用工具、改 Markdown、维护本地状态、遵守项目规则，那么很多独立 App 的外壳就开始显得多余。更进一步地，功能在运行时由 Agent 临场解释（Just-In-Time Interpretation），天然具备 LLM 的语义容错与泛化兜底能力。

这就是为什么“AI 帮我更快地写一个 App”可能只是过渡形态。它优化的是软件生产速度，不是软件形态本身。

软件的编译目标变了

传统软件的编译目标是机器：CPU、浏览器、移动端、云服务。即使是 SaaS，它最后也要被编译成某种固定 runtime 上的确定性行为。

Agent-native software 的编译目标不完全是机器，而是 agent。

这句话听起来有点怪，但很关键。一个 Skill 不是单纯的文档。它更像一种 runtime definition：当 agent 遇到某类任务时，应该读取哪些文件，调用哪些脚本，遵守哪些边界，怎样处理失败，什么时候停止，输出什么格式，哪些判断不能硬编码，哪些数据不能提交到 Git。

在 Everyday ArXiv 里，src/ 里的 Python package 是 deterministic kernel；SKILL.md 是工作流定义；user_profile/ 是用户态 memory； agents.md 是运行规范；data 是持久化层；Codex 或 Claude Code 是 execution environment/runtime。

如果用传统软件的眼光看，src/ 才是软件，其他都是文档和数据。但在 agent-native software 里，这个边界反过来了。src/ 只是工具层。新范式里 Python 反而变成了汇编，Markdown 变成了高级语言，LLM 变成了 CPU。

这就是 architectural inversion：基础设施从每个独立应用下沉到 agent platform，应用本身变成轻量、可注入、可修改、可迁移的能力层。

可以把这个变化压成一张表：

维度	旧范式：Software by AI	新范式：Software within AI
架构	AI 生成 custom full-stack repo：前端框架、后端 API、数据库、hosting layer 一套俱全。	Lightweight skills、structured manifests、execution scripts 和本地目录约定，作为能力注入 agent。
基础设施	每个 App 都有自己的运行时、数据库、DevOps pipeline、权限和部署环境。	复用 host agent platform 的原生环境：文件系统、命令行、浏览器、沙箱、工具调用和上下文窗口。
成本模型	独立 AI App 既要维持 SaaS 外壳，又要为每次模型调用承担 API 边际成本，重度使用时很容易变贵。	Agent-native workflow 寄居在 Claude Code / Codex 等通用 agent 订阅里，用户共享模型厂商的订阅优惠。
灵活性	功能被硬编码在 UI、后端和 schema 里，新增能力需要改代码、重新部署、重新设计入口。	Agent 根据 runtime intent 动态解释 Skill、读写文件、调用脚本，可以在不重做产品形态的情况下适配边界情况。

Skill 不是插件，而是新的软件单元

我们习惯把插件理解成某个主程序的附属物。浏览器插件依赖浏览器，编辑器插件依赖编辑器。

但 agent 里的 Skill 更接近一种新的软件单元。

它至少包含四层东西。

第一层是 deterministic tools。它们是普通脚本、CLI、解析器、fetcher、formatter，负责不该让 LLM 临场发挥的部分。

第二层是 semantic policy。也就是 instructions：什么算好推荐，什么算平庸 idea，什么时候要 citation check，什么时候不能强行凑满 10 篇，什么时候只能写本地私有文件。

第三层是 private state。用户画像、历史论文、负面偏好、idea log、local config。这些东西不是传统意义上的“数据库记录”，而是 agent 每次运行时可读、可解释、可更新的个人上下文。

第四层是 execution substrate。也就是 agent 平台提供的文件系统访问、命令执行、浏览、代码理解、长上下文、多工具协调和自然语言交互。

一个传统 App 往往把这四层都封装进自己的代码和服务里。Agent-native software 则把它们拆开：稳定部分写成脚本，判断部分写成 Skill，个人部分留在 local files，执行部分复用 general agent。

所以它更像动态加载的 driver，而不是一个完整机器。它不需要每次都开一家公司式的软件外壳，只需要把能力注入到一个已经存在的 agent runtime。

便宜的不只是形态，还有定价层级的错位

另一个重点在 API call 和 subscription 的成本差异上。自己做 specialized agent，每个智能步骤都要调用模型 API；用 Codex 或 Claude Code 这类订阅式 general agent，很多工作被包含在平台里。这个成本差异不只是“便宜一点”，而可能是一个数量级的架构差异。

举个例子。Karpathy 提出的 LLM Wiki / agentic wiki，本质上是一组很轻的目录约定、Markdown 文件、schema 和 agent instructions。你当然可以把它产品化：做成一个独立知识库笔记软件，加登录、上传、搜索、同步、团队空间、RAG pipeline，漂亮UI，再接入前沿模型 API。这样它就会变成一个标准 AI SaaS：用户每次 ingest、query、rewrite、cross-reference，本质上都在烧你的 API bill。

但同一个想法也可以完全不被产品化。你把 raw sources、wiki pages 和 instructions 放在一个本地 repo 里，让 Claude Code 这样的 general agent 直接维护它。对用户来说，这不是“打开一个新 SaaS”，而是“在已有 agent 订阅里运行一个 workflow”。这个 workflow 足够轻，它把主要成本从 API 计费迁移到 agent subscription 里。

这里的价差可能非常大。对于重度使用者，等价 API 成本订阅要便宜十倍以上。换句话说，同样是使用前沿模型，一个独立 AI app 必须按 API 量表付费，而一个寄居在 Claude Code / Codex 里的 agent-native workflow，可能被平台订阅吸收掉全部用户成本，因为用户反正也要有 AI subscription plan。

如果前沿模型厂商能长期维持这种定价结构，后果会很激烈。通用 Agent 工具如 codex 会吞噬掉大量只是把大模型 API 接进旧软件外壳的所谓智能化软件。因为后者同时背着两层成本：一层是传统 SaaS 的产品形态成本，另一层是前沿模型 API 的按量成本。而前者复用的是 agent 平台已经补贴、已经部署、已经被用户购买的 runtime。

也就是说 SaaS Wrapper 正在失去认知套利的空间。以前开发者靠接个 API 加上漂亮 UI 就能卖信息差和智能差。现在，当 General Agent 的可以直接读取本地的 Workspace 和 Skill 时，用户直接在底层用最便宜、甚至被大厂严重补贴的订阅制算力完成了平替。包装成独立 App 的行为，在商业上变成了反向优化。

所以便宜来自两个方向。

第一，形态更轻。独立软件之所以贵，不只是因为它要跑服务器，而是因为它要维持一个固定产品形态。这个形态要求你提前定义用户路径、功能边界、异常处理、状态同步、权限模型、UI 文案、升级机制。对于高频标准化任务，这是值得的。对于个人化、低频、高判断密度任务，它会变成负担。

第二，计费层更低。API wrapper 软件要把每一次智能行为都变成自己的边际成本；agent-native software 则尽量把智能行为放进用户已经拥有的 general agent runtime 里。前者像是在每个小工具里自带发动机，后者像是在一个统一动力系统上加载不同工具。

文件系统就是状态。Markdown 就是界面。JSONL 就是数据库。Skill 就是产品逻辑。Python CLI 是指令集。Agent 是交互层、推理层和 glue code。用户不需要一个完整 App，只需要一个可以被 agent 理解和操作的工作空间。

LLM OS 不是一个比喻

这也解释了为什么 software within AI agents 和 LLM OS 说法会共振。

如果把 LLM 看成一个操作系统，模型本身不是全部。真正的 OS 包括文件系统、权限、进程、工具调用、环境变量、包管理、历史记录、工作目录、用户偏好、可执行脚本和应用协议。Agent 平台正在把这些东西重新组织起来。

在这个视角下，Skill 很像应用程序。Prompt 很像配置和入口。Script 很像系统调用背后的可执行文件。user_profile 很像用户态数据。agents.md 很像软件说明书、权限模型和运行规范。缓存目录是持久化层。Agent 则是 shell、window manager、workflow engine 和 interpreter 的混合体。

传统软件运行在操作系统之上。下一代轻量软件运行在 LLM OS 之内。

这不是说所有软件都会消失。高频、多人、强一致性、强权限、强交易的系统仍然需要传统软件形态。银行系统、协同编辑器、生产数据库、支付平台、医疗系统，不可能只靠一个 agent runtime。

但大量个人化、低频、高判断密度的软件，会被重写。

科研阅读助手、个人知识系统、论文回复工具、代码审查流程、实验记录、文档撰写、数据清洗、图表生成、长期研究项目和想法管理，这些东西以前很难成为好软件。不是因为需求不存在，而是因为每个人的需求都太具体，市场太小，形态太碎，固定产品很快变得不合身。

Agent 改变的是这个经济学。

这个例子可以推得很远

Everyday ArXiv 只是一个例子，但它背后的结构可以推广到很多原本需要“做成软件”的场景。

一种是科研计算和实验任务管理。比如一个 research project 需要管理模型、参数、运行脚本、远程机器、结果目录、日志、图表和结论。你当然可以写成一个独立 CLI，规定一套命令：submit、status、plot、report。这仍然有价值，因为底层确定性任务需要稳定工具。但如果整个实验管理都被压进 CLI，反而会丢掉大量上下文判断：什么时候该重跑，哪些参数组合值得扩展，哪个异常可能是 bug，哪张图应该进入论文，哪个结果已经足以停止。

更自然的方式是：底层脚本保持确定性，上层用一组 Skills 规范 agent 怎么读实验目录、怎么提交任务、怎么记录 provenance、怎么生成报告、怎么避免覆盖结果。这样实验系统不是一个封闭工具，而是一个 agent 可操作的 research workspace。它的灵活性通常比独立 CLI 更强，效果也更好，因为科研实验本来就不是一串固定命令，而是不断判断、调整和解释的过程。

另一种是已经存在的 Python 软件框架。过去我们会想：是不是要给它套一层 GUI？是不是要做一个 web app，让用户点选参数、拖拽模块、展示结果？但对于很多科学计算、机器学习、量子模拟框架来说，更好的界面也许不是 GUI，而是 agent。

框架本身提供严格 API、类型、测试、文档和 examples。Agent-native 改造则让 agent 直接读文档、组合算法、写脚本、运行 demo、解释结果、生成图表。用户不再需要先学完所有 API 才能开始探索，而是用自然语言描述目标，由 agent 把目标编译成框架代码。这类改造不是给旧框架套壳，而是把框架接入一个自然语言可编程的操作层。TensorCircuit-NG 就代表了成这种 agent-native 方向：核心不是再做一个漂亮 GUI，或者限制功能的 CLI，而是让框架本身成为 agent 能理解、能调用、能扩展的计算基底。

这些例子指向同一个判断：下一代软件不一定是把每个工具都做成独立产品，而是让工具进入 agent 的流动环境。这种形态的一个巨大优点是流动性。

传统软件很硬。它需要安装、部署、升级、编译、发版。它的功能以按钮和页面的方式凝固下来。用户要修改它，通常只能提 issue、等开发者、fork repo、改代码。

Agent-native software 很软。它可以被复制成一个目录，可以被改成另一组 Skill，可以被用户用自然语言局部重写，可以在不同 agent 平台间迁移。它不一定需要编译，不一定需要固定 UI，不一定需要发布版本。很多时候，软件就是一组可读、可改、可执行的约定。具体说就是一个文件夹。执行者 runtime 可以换，软件还在。

如果用户非得需要界面，也完全可以让 agent 临时生成一个 HTML。今天要一个极简表格，明天要一个炫酷 dashboard，后天要一个论文风格的报告页面。界面变成运行时产物，而不是软件的固定外壳。

这可能是最反直觉的地方：AI 时代的软件不一定会越来越像“更智能的 App”。很多软件会变得更不像 App，更像一种能被 agent 读取、修改、组合和临时显形的无定形流体。

这套流体不依赖某个固定 UI。它可以被 Codex 执行，也可以被 Claude Code 执行，也可以未来被别的 agent 执行。只要 agent 足够强，能读文件、跑命令、遵守 skill、维护边界，它就能运行这个软件。

这个项目给出的设计原则

从 Everyday ArXiv 这个例子，可以抽象出几条原则。

第一，确定性留给代码。抓取、解析、缓存、schema、配置、路径、格式检查，都应该是普通软件工程。不要让 LLM 每次临场发明数据结构。

第二，判断性留给 agent。推荐、取舍、科研 idea、邮件语气，这些正是 general agent 的优势。把它们硬编码成固定的 API pipeline，反而会牺牲灵活性。

第三，用户画像应该是本地文件，而不是抽象偏好按钮。研究兴趣、负面偏好、过往论文、citation anchors 都很细，应该能被 agent 直接读取、引用、更新和审计。

第四，Skill 是产品核心。它不是文档的附属品，而是 agent-native software 的主要执行逻辑。传统软件的核心在代码路径里；agent-native software 的核心入口往往在 skill 里。

第五，开源边界要前置设计。公共仓库保存通用协议，私有文件保存用户。这样软件才能既可复用，又不把个人知识和工作流泄露出去。

这些原则组合起来，给出了一种新的软件形态：不是用 LLM API 包起来的应用，而是围绕通用 agent 平台生长出的工作空间。

结语

AI agent 最开始像一个更会写代码的程序员。然后它像一个能操作工具的助理。再往后，它可能会更像一个通用的智能运行环境和操作系统。

如果这个判断成立，下一代软件的一部分就不会再被理解为“应用”。它们没有固定形态，却能稳定运行；没有完整 UI，却能完成复杂工作；不只是被 AI 一次性生成，而是持续生活在 AI agent 里面。

Everyday ArXiv 只是一个很小的科研工具，但它展示了这个方向的雏形：软件的智能部分不一定要被封装成专用 agent；当通用 agent 足够强时，软件可以把自己写成通用 agent 的 Harness。甚至我有个暴论，很少有专用 agent 最终还有用，都会被通用 agent 吞噬，正如 Sutton 的苦涩的教训，只不过这次是软件工程版本。

这也许就是从 AI 生成软件，到软件存在于 AI 之内的转变。