应该是这一篇https://www.joyehuang.me/blog/20261011---alwaysonagents/post

回复 joye： 已更新记忆，你最新一篇是 10 月 11 日发的《Personal Agent 拆解：模型越强，产品越要做减法》。如果用这篇里“删掉产品（Delete the product）”以及“补偿层 vs 承载层”的框架来审视 OpenUI 1.0，其实能看出它做对了一半，但另一半正站在你说的“跟模型进化速度对赌”的危险边缘： 1. 它做对的减法：删掉了重平台，退回到了极简的 SendToUser 接口 你在博客第三节讲 gb 的“薄客户端、厚服务器”时提到，客户端和服务器之间只有一个工具叫 SendToUser，客户端收到消息后再按内容渲染成登录表单、付款或草稿确认；第五节也提到，对话框之所以能回归极简，是因为生成式 UI 让界面不再是事先写死的菜单，而是在模型需要时才出现。 Thesys 从早期的 C1 闭源黑盒 API 退回来，做成开源的 OpenUI 渲染协议和组件库，本质上就是做了一次“Delete the product”——把原来自己重度包裹的平台外壳删掉，退化成服务端 Agent 与前端界面之间那层薄薄的渲染通道，再把私有设计系统、评测基准、AST 校验这些属于“承载层”的东西加厚。这一步是完全顺着你文章里的逻辑走的。 2. 它最拧巴的地方：OpenUI Lang 本身就是一层典型的“补偿层” 你在文章第五节写了一个非常直接的判断：“Opus 4.6 之后的模型已经能稳定地输出复杂的 JSON，产品只要准备好一套组件，模型输出 JSON，就能直接渲染出表单、卡片和图表。” 对照这句话看，OpenUI 1.0 最核心的卖点——自创一套按行赋值的 OpenUI Lang 去替代 JSON——在你的框架里其实属于典型的“补偿层”： 它之所以要砍掉键名、改用位置传参、写流式闭合容错，背后的底层假设是“现在的模型输出深层嵌套 JSON 太慢、费 Token、容易漏括号”。但就像你在第六节说的，补偿层的价值会随着模型变强先升后降，每一个专用设计背后都写死了一个即将过期的假设。 3. 用你文中的四个标准看，这套自研 DSL 已经露出了补偿层的代价 你在博客第六、七节列了补偿层拖后腿的特征，以及 Peak Ji 检验架构好坏的指标，套在 OpenUI Lang 上几乎条条命中： 第一是固定上下文税与过度耦合：为了让没有预训练过这套语法的模型学会写 OpenUI Lang，每次请求都要先塞约 7000 Token 的语法说明和签名，这正好撞上了你说的“冗长规则占用上下文与缓存预算”。 第二是跨模型家族表现差距极大：按 Peak Ji 的指标，好架构换成不同模型表现差距要尽量小；但 OpenUI Lang 一旦从旗舰模型切到 26B 级别的开源模型，因为没有键名做语义锚点，位置传参立刻乱套，连续生成全过率直接腰斩到 50%。为了补这个窟窿，他们又不得不在网关里再叠一层专门微调的 Autofix 小模型——这就是典型的“为了维护脚手架，花掉比改进 Agent 本身更多的力气”。 所以按你这篇新博客的视角来看，OpenUI 把自己拆轻、接进 ca 工作流、帮企业绑定私有组件库，这些是在加厚“承载层”，生命力会很强；但他们引以为傲的 OpenUI Lang 语法和网关修复小模型，本质上是在替今天的模型打补丁。等再过一两代模型，原生结构化输出的速度、成本和稳定性进一步拉满，这套自研 DSL 很可能会成为第一块需要被他们自己删掉的脚手架。