忒修斯之船:什么是流式软件

两千多年前，古希腊人问了一个问题：忒修斯之船上的木板被一块块更换，当最后一块旧木板也换成新的时候，这艘船还是原来那艘船吗？人们争论了两千年，没有答案。但今天，这个问题从哲学课堂走进了软件世界——当你正在使用的软件，每一个部件都可以被替换、被重写、被重新装配，甚至被你亲手改造成全新的模样，它还是原来那个软件吗？流式软件给出的回答是：这个问题也许不再重要了。重要的不是"它还是不是它"，而是"它正在成为什么"。

最近我在用DeepSeek Harness——DeepSeek 在 2026 年 8 月开源的 Agent 框架。最让我惊讶的，不是模型变聪明了，而是另一件事：

让软件多干一件事，不用等厂商发版，自己写个插件挂上去，能力就长出来了。

这画面有点反常识。我们习惯了软件是"买来就用、用旧就换"的东西——它是什么，厂商说了算。可这一次，软件的能力边界，是我这个使用者当场划定的。

其实过程中还有另一个观察：大模型会在这次对话里，通过你的纠正自己把说法校准得更准。但那是模型本身的能力，圈内人早都知道。真正少见、也真正让我兴奋的，是上面那件事——软件本身"活"了过来，把迭代的权力交还给了用户。

这篇文章想聊的，就是这第二种变化。

流式软件：一种以 AI 为内核、由可插拔的插件组合而成、没有固定"版本"边界、允许用户自行编写与装配插件从而持续演化能力的软件形态。它不再是一个"写好就交付"的成品，而是一个会流动、会生长、把迭代权力交还给使用者的活系统。

先厘清：两个常被混为一谈的概念

讲流式软件之前，必须先分清楚两层，否则整篇文章会被读成又一篇"大模型会自我校准"的科普。

概念 A：模型通过交互自我校准。这是大模型本身的现象——通过交互设定约束、逐渐精准化。它确实存在，也是"软件在流动"的一个证据。但它是已知事实，业内早已熟知。所以本文只把它当作支撑标题的其中一个证据，不展开为主角。

概念 B：可插拔、且用户可写插件的系统带来的用户驱动迭代。这是另一回事。它突破的是传统软件"固定发版、固定迭代、用户无从参与"的体制，让用户自己也能写插件、提升软件本身的能力，从而让同一套软件在不同用户、不同行业里呈现完全不同的功能。这是本文真正要讲的东西，是"流式软件"这个标题的主要支柱。

两层差异一句话：A 是模型层的自我修正，B 是系统层 / 架构层的权力转移。 A 很多人都知道；B 才是这篇想说清的。而 B 在 2026 年已经有了真实载体——DeepSeek Harness 提出的 "Everything is a Plugin"（一切皆插件）。

一、从"固态软件"到"流式软件"

过去我们买软件，像买一台家电：出厂什么样，回家就是什么样，想加个原本没有的功能，基本只能等厂家出下一代。你拥有它，却改不了它的本质。

流式软件不一样。它更像租来的一辆车——你不一定拥有每一个螺丝，但随时能加装模块、换套配置、甚至自己改一改，让它更合你的用途。而且它还在路上一直跑、一直变。说到底，它更像水：没有固定形状，装进什么容器就呈现什么形态；你往里加一块插件，它就改变流向。

下面这张表是全文的骨架，后面三节都围着它转：

维度	传统 / 固态软件	流式软件
组成方式	单体代码，焊死在二进制里	插件组合，可运行时增删
升级方式	厂商单向发版	用户驱动 + 系统自演化
用户角色	被动消费者	共建者 / 插件作者 / 升级者
逻辑来源	预先编码	模型推理 + 可写可插的插件
迭代参与	用户无法参与	用户当场参与、当场写插件
生命周期	上线 → 迭代 → 下线	无明确终点的持续流动

我只讲三件事：它怎么随情境自适应、它的能力怎么由使用者自己用插件演化、以及——最关键的——用户怎么变成了软件的插件作者与升级者。

二、特征一：情境自适应

这是流式软件"像水"的那一面，部分来自前文说的"模型自我校准"的能力，但表现为系统层的流动。

固态软件的行为是确定的：同样输入，同样输出。这曾经是它的优点——可预测、可审计、好追责。但代价是僵化：它不会因为你今天场景不同、上下文不同、面对的人不同，就调整做法。真实世界一变，它就要么报错，要么失灵。

流式软件相反。同一个问题，面对不同用户、不同上下文，它会给出不同的处理。它"懂此刻的情况"。这不是 bug，这是它的本性——它流动，所以它能嵌入真实世界的复杂与变化，而不是要求真实世界来迁就它那套固定逻辑。

注意：确定性不是被消灭了，是被转移了——从"代码写死"转移到了"模型在情境中判断"。这正是它强的地方，也是它麻烦的地方（后面会讲）。

三、特征二（主线）：由插件组成，且允许用户写插件

这是流式软件真正区别于以往软件的地方，也是概念 B 的落脚点。要讲清楚它，最好的标本就是 DeepSeek Harness——它把"一切皆插件"做成了工程现实。

3.1 "Everything is a Plugin"：整个软件就是插件组成的

DeepSeek Harness 的核心设计哲学就是官方那句"Everything is a Plugin"（一切皆插件）。它基于一个名为Cordis的插件内核（其思路来自论文《A Programming Paradigm for Spatiotemporal Composability / 时空可组合性的编程范式》）。落到具体：

模型、工具、技能、会话、沙箱、存储、循环（Agent Loop 本身就是一个可整体替换的插件）、调度、UI——全都是插件。开发者不用改一行 Harness 源码，就能在配置层把任意能力替换、扩展或重组。一个大模型，只是这整套技术栈里一个可随时换掉的零件。

这意味着软件不再是一块焊死的铁板，而是一盒可随意拼装的零件。换模型，是改一行配置；换工具、换沙箱、换调度逻辑，同样是挂上不同的插件。正如社区评价所说，这种"极端模块化"在闭源的 Codex、Claude Code 面前确实少见——后者交付的是一个"拿来即用的 Agent"，而 Harness 更像一套"组装 Agent 的运行时"，把结构暴露出来，让使用者决定 Agent 是谁、用什么工具、怎么工作。

3.2 更进一步：用户能自己写插件

"可插拔"还不算最狠的。最狠的是——用户能写自己的插件。

Harness 在设计上就支持"树外插件"（out-of-tree plugins），通过 Profile / Bundle 在配置层叠加、通过事件流拦截 Agent 循环的关键节点、通过 Capability Seam 替换底层能力，开发者理论上甚至可以完整换掉整个调度逻辑。也就是说，可插拔不等于"只能插官方给的零件"；使用者自己就是零件的制造者。

这个判断不是推测，而是已经在发生的事实：DeepSeek Harness 开源仅3 天，围绕它的第三方开源插件就达到了约 4300 个，GitHub Star 三天破 10 万，Hacker News 讨论冲上 TOP 1。社区的开发者已经在写自适应上下文压缩、跨会话长期记忆、因果图检索等自己的插件。

3.3 结果：同一套软件，在不同手里是截然不同的东西

这才是概念 B 真正的分量，也是"流式"二字的全部含义：

你接的插件、写的插件，决定了软件为你长成什么样子；

在另一个用户那里，因为插件组合不同，它可以是完全不同的功能；

给政务、给金融、给制造，各自就是一组不同的插件组合（Bundle / Profile）——行业方案完全可以自定义，而不是等厂商出一个"行业版"。

软件第一次不再是"一个被定义好的东西"，而是一个由使用者自己定义的东西。这正是传统软件"固定发版、用户无法参与"体制被突破的那一刻。

四、特征三：用户即插件作者与升级者

第三特征，是第二特征的必然结果，也最让我兴奋：用户自己就能升级、乃至重新定义软件。

在过去，软件的"升级"是厂商的特权——你用旧版，它发新版，你被动接受。流式软件把升级权拆给了使用者：你挂一个插件，就是在升级；你写一个插件，就是在给软件增加一种它本来没有的能力；你沉淀下来的插件组合，本身就是软件的一部分。用户从消费者，变成了共建者、插件作者、升级者。

这带来一个范式级的变化：软件的演化不再由厂商单向决定，而由"使用者 + 系统"共同驱动。版本号这种东西失去了意义——因为没有"一版"，只有"每个人手里那一版正在流动的状态"。

五、为什么是现在，而不是二十年前

这个概念不是凭空来的。它成立，是因为几块技术刚好同时成熟：

大语言模型：让"用自然语言指挥软件"从想象变成现实（概念 A 的底座）；

强化学习与自蒸馏：让模型能自我提升、自我校准，而不必全靠人工标注（概念 A 本身）；

Cordis 式的插件内核 / 时空可组合性架构：让"一切皆插件"从口号变成可运行的系统——这是概念 B 成立的关键前提，也是本文要害所在；

智能体（Agent）架构：让软件能自己规划、调用工具、完成多步任务；

自然语言编程 / 无代码：把写插件、拼装的门槛降到"会说话、会一点配置就行"。

缺任意一块，"流式软件"都只是修辞手法。五块齐了，它才从比喻变成一种正在发生的软件形态——而其中真正新、真正值得写清楚的，是插件化架构把迭代与定义权交还给用户这一块。DeepSeek Harness 在 2026 年的出现，恰好把这块从论文和设想，变成了可以 npx @deepseek-ai/dsh web 一键拉起的现实。

六、一个思想实验：今天你想给软件加个功能

假设你要给正在用的工具加一个"自动把会议录音转成带待办清单的纪要"。

固态软件路径：你提需求 → 产品经理评估 → 排进下个季度版本 → 工程师开发两周 → 测试 → 发版 → 你更新 → 你才用上。中间可能隔着三个月，而且前提是厂商觉得这事值得排期。

流式软件（插件化 harness）路径：你写一个"纪要插件"（或用自然语言让系统生成一个），挂上去、用 Profile 编排一下"会议录音 → 转写插件 → 纪要插件 → 待办"，当下就能用。你想到，它就到；你想换一种纪要格式、想接你们单位的内部系统，自己改插件或加一个就行。

差别不在快慢，在于软件的演化权与定义权在谁手里。固态软件把这两权锁在厂商的工程团队；流式软件把它们交还给了正在使用的人——这，就是用户驱动迭代的全部分量。

（插一句边界：不是所有场景都能这么自由。强合规场景——比如政务内网、企业微信的安全边界——恰恰划出了流式软件不能越的线。这既是限制，也是它必须被认真治理的理由，后面会展开。）

七、当软件"液态化"之后：谁该负责？

说到这儿，必须泼一盆冷水。流式软件带来的不只是便利，还有一连串老软件没有的麻烦：

确定性丧失：同样输入可能不同输出，出错了很难"复现"，排障从看代码变成看概率。

审计困难：软件由用户自己写插件、自己迭代，事后要查"当时它为什么这么做"，痕迹是流动的、难回溯的。

责任归属：用户自己接的插件、自己写的逻辑带来的行为，出了事算谁的？厂商、用户，还是系统本身？

厂商锁定：你的业务流程沉淀在它的"流动态"里，换一家可能带不走、挪不动。

我一直认为，商业的本质不是提供价值，而是兜底结果、承担责任。流式软件如果只谈"它会自己变强""用户能自己写插件"，不谈"谁来为它的变化负责"，那就是漂亮的口号，落不了地。这一节不是附录，是整本书的承重墙。

不过也该公允地说：以 DeepSeek Harness 为代表的新一代设计，已经在内核里预埋了治理的接口——它的另一条原则是"Every run is traceable"（每一次运行都可追溯）：模型看到的一切（系统提示、推理、工具调用与结果、子 Agent 调度、每一次上下文注入）都被记录进一条只追加（append-only）的会话日志，可在 Trajectory 视图里按来源检视、恢复、分叉、重放。这说明"流动"和"可追溯"并非天然对立——好的流式软件，应该流动得可被追责。这反而证明了：治理不是流式软件的敌人，而是它能不能真正落地的试金石。

八、结语：下一个时代的软件，是流动的

我们正站在软件史的拐点上。过去七十年，软件从机器指令走到高级语言，再走到互联网和 App，本质都是"人写、机执行"，而且用户被挡在迭代门外。流式软件第一次让"机也在长、用户也在改、人人都能写自己的零件"成为常态。

它不是某个产品的功能，而是一种新的软件存在方式：无版本、随情境自适应、由可写可插的插件组成、用户即插件作者与升级者。它像水一样，没有固定形状，却能够填满真实世界的每一个缝隙——而填成什么形状，由用它的那个人决定。

顺带分清轻重：模型通过交互自我校准业内早已熟知，只是"软件在变活"的一个证据；真正值得立为一说的，是让用户自己写插件、自己驱动软件的迭代与升级，让同一套软件在不同用户和行业里呈现完全不同的能力。

接下来我想顺着这个想法，慢慢写成一本书——一章一章地，把流式软件是什么、为什么是现在、边界在哪、产业怎么变、责任谁来担，讲清楚。但今天，先从这一篇开始：

什么是流式软件？一句话——它是一个由插件组成、会自己流动、并且把迭代与定义权力交还给使用者的活软件。

回到忒修斯之船。传统软件害怕那个问题——所以它需要版本号，需要固定边界，需要向所有人证明"我还是我"。流式软件不害怕：它坦然承认自己每一刻都在被更换、被装配、被重新定义，它的身份不在过去，而在持续的流动之中。它不在乎自己是不是"原来那艘船"，它在乎的是——能不能陪你把海走完。