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

pingu 2026-09-29 10:49 1

背景与问题


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


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

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


事后反思发现原因在于:



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

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



前者开发者视角,要设计一个让大部分人“用起来舒服”的页面,需要门槛较高的经验加持和前期设计;

后者用户视角,我觉得一个软件不好用,可能是因为它的设计还不成熟,也可能软件是成熟的但我有我自己的偏好需求



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


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


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




Better Way?


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


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

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


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




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


我的设想大致如下:



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


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


支撑设想的三个核心:



需要OS级别的基座?


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


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

…


End


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


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

最新回复 (3)
  • Crain 09-29 11:48
    1楼

    DSH,PI,不都是这个思想吗?但是业务是复杂的,你的想法每个人的想法都不一样,你指望AI做你心里的蛔虫,怕是只能让AI把你自己蒸馏一下了哈哈

  • harriman 09-29 11:53
    2楼

    确实想法是这个想法,我也想过。但是想要做成用户不懂技术都能用的产品,估计就是浏览器级别的创造了

  • pingu 楼主 09-29 11:54
    3楼

    所以是在官方提供成熟的基础能力、接口和默认组合的基础上的用户自定义


    然后就是想移动端什么时候能支持agent这种形式

* 帖子来源Linux.do
返回