用AgentOS解决用户自适应的困境？

背景与问题

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

“不要这样，这个交互不好”

“把行程路线风格调整成…”

事后反思发现原因在于：

- 我不太清楚一个 “好的旅行规划助手的交互设计” 应该是什么样的；

- 同时， 我又能想到 “我明显不喜欢的交互设计” ，所以会不断patch

前者开发者视角，要设计一个让大部分人“用起来舒服”的页面，需要门槛较高的经验加持和前期设计；
后者用户视角，我觉得一个软件不好用，可能是因为它的设计还不成熟，也可能软件是成熟的但我有我自己的偏好需求

例如我是个P人，我希望旅行规划页面地图中，可以显示行程路线周围、会路过的好玩的地方

常见的开发范式中，这种需求可能要不断反馈、服务提供方进行评估、排期实现、发布更新这样的冗长闭环，甚至很多时候这种个人的需求很难通过评估

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

Better Way？

我想到之前刷到过的一个基于DSH开发工作台的演示。博主开发的工作台以插件的形式内嵌，他可以一边使用，一边告诉agent自己对哪里不满意，再让agent去修改。

基于Cordis的DSH实现了这一点：

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

这联系上了我之前的想法，一类以 agent 为中心、通过可插拔模块组织软件能力的底座。

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

我的设想大致如下：

用回前面我的P人旅行需求例子，如果软件提供方提供了成熟的路线、地点搜索和地图能力，agent就能利用这些基础能力，根据我的需求开发适合我的前端并实时覆盖旧版前端

该设想下的用户需求适配 和 前面提到的反馈闭环 进行对比：

支撑设想的三个核心：

需要OS级别的基座？

和旅行规划场景一样，大部分软件主要应用都在移动端，而移动端的用户自由度又比较低，不像电脑能随便code ^-^ 现在手机也没有一个像电脑agent那样的东西

就算开放又需要一个合理的架构防止用户改着改着把手机变砖头了

…

End

上面是我经过一天开发后的突发奇想，假如佬友们有什么更成熟的想法，可以踢我一脚，或者说网上其实已经有类似的更深入的讨论，也可以踢我一脚 ^-^ ^-^

另外上面想到啥说啥的风格，可能让人读起来比较懵，我让AI润色了一下放在个人博客，佬友们可以看看：

lingulang.com

用AgentOS解决用户自适应的困境？ | Lingu

从旅游规划的场景出发，探讨 AgentOS-Based 软件如何利用可插拔结构、内嵌 agent 和热更新，降低用户个性化需求与软件之间的适配成本。