背景与问题 最近在推进课程项目，方向是做一个旅行规划agent。进行到前端设计的时候，我和codex陷入了多轮的讨论和修正： “不要这样，这个交互不好” “把行程路线风格调整成…” 事后反思发现原因在于： 我不太清楚一个 “好的旅行规划助手的交互设计” 应该是什么样的； 同时， 我又能想到 “我明显不喜欢的交互设计” ，所以会不断patch 前者开发者视角，要设计一个让大部分人“用起来舒服”的页面，需要门槛较高的经验加持和前期设计； 后者用户视角，我觉得一个软件不好用，可能是因为它的设计还不成熟，也可能软件是成熟的但我有我自己的偏好需求 例如我是个P人，我希望旅行规划页面地图中，可以显示行程路线周围、会路过的好玩的地方 常见的开发范式中，这种需求可能要不断反馈、服务提供方进行评估、排期实现、发布更新这样的冗长闭环，甚至很多时候这种个人的需求很难通过评估 那有没有一种更好的开发范式，让软件更容易适配每个用户？ Better Way？ 我想到之前刷到过的一个基于DSH开发工作台的演示。博主开发的工作台以插件的形式内嵌，他可以一边使用，一边告诉agent自己对哪里不满意，再让agent去修改。 基于Cordis的DSH实现了这一点： 用户正在使用的软件，也可以成为 agent 正在修改的对象。 这联系上了我之前的想法， 一类以 agent 为中心、通过可插拔模块组织软件能力的底座 。 从成熟基础出发，让用户塑造自己的软件 我的设想大致如下： 用回前面我的I人旅行需求例子，如果软件提供方提供了成熟的路线、地点搜索和地图能力，agent就能利用这些基础能力，根据我的需求开发适合我的前端并实时覆盖旧版前端 该设想下的用户需求适配 和 前面提到的反馈闭环 进行对比： 支撑设想的三个核心： 需要OS级别的基座？ 和旅行规划场景一样，大部分软件主要应用都在移动端，而移动端的用户自由度又比较低，不像电脑能随便code 现在手机也没有一个像电脑agent那样的东西 就算开放又需要一个合理的架构防止用户改着改着把手机变砖头了 … End 上面是我经过一天开发后的突发奇想，假如佬友们有什么更成熟的想法，可以踢我一脚，或者说网上其实已经有类似的更深入的讨论，也可以踢我一脚 另外上面想到啥说啥的风格，可能让人读起来比较懵，我让AI润色了一下放在个人博客，佬友们可以看看： lingulang.com 用AgentOS解决用户自适应的困境？ | Lingu 从旅游规划的场景出发，探讨 AgentOS-Based 软件如何利用可插拔结构、内嵌 agent 和热更新，降低用户个性化需求与软件之间的适配成本。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：硬件与数码
  • 分类依据：内容涉及硬件、数码产品或通信卡
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/29 10:49:52