背景与问题

最近在推进课程项目，方向是做一个旅行规划 agent。进行到前端页面设计时，我和 Codex 陷入了多轮讨论和修正。

原因在于：

  • 我不太清楚一个 “好的旅行规划助手的交互设计” 应该是什么样的；
  • 同时，我又能想到 “我明显不喜欢的交互设计” ，所以会不断 patch。

开发者的视角

要设计一个让大部分人用起来舒服的页面，需要经验，也需要前期设计。我作为开发者，得不断判断用户会怎么用、哪里会不顺手。

用户的视角

我觉得一个软件不好用，可能是因为它的设计还不成熟，也可能软件已经很成熟，只是我有自己的习惯和需求，它满足不了。

例如，我希望旅行规划页面的地图里，能显示行程路线会路过的、可能好玩的地方。软件原有的功能可以很好地完成规划，但我仍然想在这个基础上增加一种自己的用法。

在常见的开发流程里，这类需求往往要经过：

用户反馈 → 开发者理解和评估 → 排期实现 → 发布更新 → 用户再次体验

而一个人的偏好，也未必值得被做进所有人的公共版本。

这让我想到一个问题：

那有没有一种更好的开发范式，让软件更容易适配每个用户？

Better Way？

一次“边用边改”的启发

之前刷到过一个基于 DeepSeek Harness 开发工作台的演示。用户可以用这个工作台创造自己的应用，并快速查看效果。

我尤其注意到了博主自己开发工作台的过程。

这个工作台内嵌在 DSH 中，以插件（plugin）的形式存在。他可以一边使用，一边告诉 agent 自己对哪里不满意，再让 agent 去修改。

这让我想到：

用户正在使用的软件，也可以成为 agent 正在修改的对象。

如果这种能力直接存在于软件内部，用户发现某个地方不合适时，就可以当场提出需求、体验修改，再继续使用。

以 DSH + Cordis 为参照

DSH 采用 Cordis 的插件架构，模型、工具、界面等能力都可以通过插件替换和重组。官方介绍

Cordis 还支持热模块替换（HMR）：启用对应机制后，可以在运行中卸载旧插件、加载新版插件。官方说明

我想借这个参照，讨论一类以 agent 为中心、通过可插拔模块组织软件能力的底座。本文暂且把它称为 AgentOS。

从成熟基础出发，让用户塑造自己的软件

我设想的起点，是开发者提供一个已经成熟、可以正常使用的软件。

它有完整的基础能力，也有一套经过设计的默认页面。用户用着用着，发现了自己的偏好，就让内嵌的 agent 去做调整。

**基础页面本身也可以由几个扩展组合而成。**用户因此可以重新组织页面、替换交互方式，或者增加新的扩展。

先把这个设想画得抽象一点：

图 1：从成熟的默认组合出发，由 agent 根据用户需求塑造个人版本。

还是拿旅行规划举例：

一个具体的愿望

“我希望地图里能显示这条路线附近，可能会好玩的地方。”

如果软件已经提供路线、地点搜索和地图能力，agent 就可以利用这些基础能力，设计并实现一个适合这个用户的“沿途发现”功能。

用户还可能希望地图占据更大的空间，或者希望直接在地图上修改行程。Agent 可以围绕这些愿望，重新组织页面和操作流程。

用户负责表达自己的体验和需求，agent 承担主要的设计与实现工作。用户不需要先想出一套完整的交互方案，也不需要自己编写插件。

旅行规划只是把我带到这个问题的引子。这种关系也可以出现在其他软件里：开发者提供成熟起点，用户在实际使用中，逐渐塑造适合自己的版本。

可插拔 + Agent + 热更新

这三个条件，在我的设想里各自承担一部分工作：

条件提供什么能力对用户意味着什么
可插拔结构功能和页面可以重组、替换与扩展，成熟模块可以复用能在原有软件基础上，调整自己的用法
内嵌 agent理解需求，承担设计与实现工作表达愿望和体验，就能推动修改
热更新支持热替换的改动可以在运行中生效无需重启整个软件，接着体验修改结果

把前面的反馈链路和这个设想放在一起看：

图 2：两个过程都可能反复调整；这个设想把需求、修改和体验放进同一次使用过程。

发现不合适 → 表达需求 → 软件改变 → 继续体验。

个性化改造由此有机会形成一个更短的循环。

这里的“边用边改”很重要。

很多时候，我只有真正用起来，才知道自己喜欢什么、不喜欢什么。能快速体验修改结果，就有机会从一个成熟设计出发，逐步找到适合自己的形态。

这也回应了最初那个矛盾：

我未必知道好的设计是什么，但我能对实际体验作出判断。

它能缓解什么？

我觉得，这个设想首先能缓解的是个人需求进入软件的成本。

用户的个性化需求，可以通过 agent 直接转化为自己的软件版本，减少反馈、排期和等待统一更新的过程。

设计上的试错仍然存在。Agent 给出的方案可能也要调整几轮。但可插拔结构、成熟模块和热更新，有机会让每一次尝试更轻、更快。

当然，能够修改软件，和能够改出好用的软件之间，还有一段距离。Agent 是否能做好设计，生成的扩展是否可靠，用户改过的版本以后是否容易维护，都需要实际验证。

所以，我现在更愿意把它理解为一种降低软件与用户之间适配成本的可能路径。

这个 idea 目前最吸引我的地方是：

软件交付之后，用户仍然能通过 agent，在使用过程中持续塑造它。

开发者提供一个成熟的起点，而软件最终长成什么样，还可以由每个人自己的使用过程继续决定。