即刻App年轻人的同好社区
下载
不妨说的更明白一些。
对绝大多数消费者而言，阿里就是淘宝、字节就是抖音，巨大的互联网企业只是一个个App。
这一个个 App 在消费者与商品/服务提供者之间， 轻资产的撮合分发，并以此获得利润。
但是很多人都看到了，未来的软件界面将由用户的个人 Agent 实时而又个性化的生成。用户将通过这个界面直接触达自己需要的商品/信息/服务。
App 不再重要，或者说如果我们在商业世界画一根轴线，一头是数字世界一头是物理世界，数字的这头在产生增量——模型与Agent，物理这头相对稳固——本轮AI 革命引发物理世界产能爆发还有待时日，但轴线中间部分的摧毁几乎是确定的。
所有的科技公司都想去抢数字世界的皇冠，但公司和公司是不同的，现有业务形态决定了字节天然就更数字世界一些，而阿里美团则没那么纯粹，只能别扭的「我全都要」
或者，至少至少，我在物理世界的优势不能丢。那要如何不丢呢？当商品/信息/服务被用户的个人 Agent 直接触达，传统渠道不再有议价权也不再有利润，答案似乎就只剩：走向更重的供应链，强化控货和控价的能力。难听点说：追求物理世界的____
坦白讲，直觉上我也不是那么反对物理世界的____，毕竟一个____数字世界的霸主加原子化没有议价权的物理世界的组合似乎更可怕一些。技术引发的巨大变革是挡不住的，只希望有合理分配让每个个体可以得到应得的体面生活
对绝大多数消费者而言，阿里就是淘宝、字节就是抖音，巨大的互联网企业只是一个个App。
这一个个 App 在消费者与商品/服务提供者之间， 轻资产的撮合分发，并以此获得利润。
但是很多人都看到了，未来的软件界面将由用户的个人 Agent 实时而又个性化的生成。用户将通过这个界面直接触达自己需要的商品/信息/服务。
App 不再重要，或者说如果我们在商业世界画一根轴线，一头是数字世界一头是物理世界，数字的这头在产生增量——模型与Agent，物理这头相对稳固——本轮AI 革命引发物理世界产能爆发还有待时日，但轴线中间部分的摧毁几乎是确定的。
所有的科技公司都想去抢数字世界的皇冠，但公司和公司是不同的，现有业务形态决定了字节天然就更数字世界一些，而阿里美团则没那么纯粹，只能别扭的「我全都要」
或者，至少至少，我在物理世界的优势不能丢。那要如何不丢呢？当商品/信息/服务被用户的个人 Agent 直接触达，传统渠道不再有议价权也不再有利润，答案似乎就只剩：走向更重的供应链，强化控货和控价的能力。难听点说：追求物理世界的____
坦白讲，直觉上我也不是那么反对物理世界的____，毕竟一个____数字世界的霸主加原子化没有议价权的物理世界的组合似乎更可怕一些。技术引发的巨大变革是挡不住的，只希望有合理分配让每个个体可以得到应得的体面生活
26 14
不是，这两天为 Pretext 欢欣鼓舞的人有多少在前两周还无比赞同 「GUI 已死 / 还在做GUI 的公司都完蛋了」
注：Pretext 是个GUI 库，本条没说 Pretext 不好的意思（但这个上涨趋势，谁说Coding不能做内容平台了？🐶
注：Pretext 是个GUI 库，本条没说 Pretext 不好的意思（但这个上涨趋势，谁说Coding不能做内容平台了？🐶
8 01
在一些特殊场景，想要控制 Agent 的工具调用，既没有合适的规则去做约束解码，System Prompt 也写无可写，还能怎么办，我们实践出一种比较 tricky 的“诱骗”方法
具体的例子（做了简化）：
主 Agent 为了不污染自身上下文，发起异步让子 Agent 完成某任务
为了让主 Agent 有完善的异步能力，除了异步发起工具，还需要有查询、插入指令、结束等配套工具
由于异步任务可能会执行很长时间，所以用户中途询问进度是很常见的，我们期望中的模型行为是查询并反馈用户进度即可，但是在非常多的时候，模型会进入：无限轮询、杀掉子 agent 重启任务、自己上手再干一遍等浪费低效的路径。
并且如前面说，这种情景即没有很好的规则可以通过约束解码控制工具调用，只在 System Prompt 里做约束也效果更是十分有限
我们尝试的方向是给模型提供一个新工具：加速工具。入参 Agent ID，并在工具描述里向主 Agent 承诺该工具可以将任务处理速度提升xxx
我们不用也无法真的实现这个工具的加速能力（否则也不叫诱骗了），而是再模型调用该工具时返回你已经写在System Prompt 里的约束进行再次强调，就能很大程度缓解问题
总结一下：如果能在 log 中识别到模型高频陷入的无效路径，可以通过设计一个“诱饵”工具，用一个看似更符合情景的选项把它矫正回来
具体的例子（做了简化）：
主 Agent 为了不污染自身上下文，发起异步让子 Agent 完成某任务
为了让主 Agent 有完善的异步能力，除了异步发起工具，还需要有查询、插入指令、结束等配套工具
由于异步任务可能会执行很长时间，所以用户中途询问进度是很常见的，我们期望中的模型行为是查询并反馈用户进度即可，但是在非常多的时候，模型会进入：无限轮询、杀掉子 agent 重启任务、自己上手再干一遍等浪费低效的路径。
并且如前面说，这种情景即没有很好的规则可以通过约束解码控制工具调用，只在 System Prompt 里做约束也效果更是十分有限
我们尝试的方向是给模型提供一个新工具：加速工具。入参 Agent ID，并在工具描述里向主 Agent 承诺该工具可以将任务处理速度提升xxx
我们不用也无法真的实现这个工具的加速能力（否则也不叫诱骗了），而是再模型调用该工具时返回你已经写在System Prompt 里的约束进行再次强调，就能很大程度缓解问题
总结一下：如果能在 log 中识别到模型高频陷入的无效路径，可以通过设计一个“诱饵”工具，用一个看似更符合情景的选项把它矫正回来
15 04
让普通用户为 Agent 准备一台独立且网络长期稳定的设备是奢侈的，只有跑在云上的 Agent 才能保障持续运行永久在线
但另一方面，一个 Agent 如果只有云环境而没有本地行动能力，不能在离用户最近的地方拿到个性化上下文，不能利用/接管本地的一些现成工具，那么普通用户使用它的输入成本就很难降到合理水平
一个合理的结构是，harness 在云上作为智力与记忆的中枢，用户的各类端设备/应用（本地应用+云应用）作为眼睛与手脚通过网络协议接入
但另一方面，一个 Agent 如果只有云环境而没有本地行动能力，不能在离用户最近的地方拿到个性化上下文，不能利用/接管本地的一些现成工具，那么普通用户使用它的输入成本就很难降到合理水平
一个合理的结构是，harness 在云上作为智力与记忆的中枢，用户的各类端设备/应用（本地应用+云应用）作为眼睛与手脚通过网络协议接入
18 33
去年下半年，我正在筹备这次创业，想做自己最有热情的方向，除了已有的合伙人，还缺少一位某领域的技术专家加入。人很难找，所以在找人的同时也在看是否能从不同的角度去做
关于我最有热情的方向，如果抽象一些来描述，它更偏消费端，要寻找不同角度，自然的，便导向了供给，通过 AI Coding 来创造更多供给
当时最热的、给非程序员用的 AI Coding 产品是 Lovable，数据猪突猛进，它的故事是：每个人都能搭建自己的网站来服务自己的用户
这建立在高价值流量来自人类客户的基础假设之上，我们认为这不能很好的描述未来
所以我们要做一个 Lovable Copy ，别的都大差不差，核心区别是 Lovable 给用户交付的是一个人类友好网站，而我们给用户交付的是一个人类友好的网站+一个基于MCP、A2A 或者其他随便什么对 Agent 友好协议的接口服务 —— 让你的业务为 Agent 流量做好准备，所有服务都值得为 Agent 重做一遍
并且对于我们自己，在积累足够多服务之后，还能从工具转平台，做服务分发和服务抽成
在龙虾大火的当下，这几乎就是最风口的故事，在那个时点，我们却收到了不少来自投资人的挑战，相对给 Agent 搭友好的服务，大家甚至更相信 Coding 是新内容形态，可以长出新的内容社区
我们不得不往这个故事里塞东西：谁要建网站？当时的 Lovable 有什么问题？
谁要建网站？
北美欧洲没有大众点评，只有 Google map。大众点评既有列表页又有详情页， Google map 只有列表页，详情需要这些小商家自己搭官网，产生大量建站需求，所以我们要为北美欧洲小商家建站而服务
当时的 Lovable 有什么问题？
当时的 Lovable，几乎就是个原型工具，无法稳定维护生产级的带后端业务的站点。小商家所需要的官网会涉及会员、预定、电商这类带后端且零 Bug 容忍度的业务组件，没必要每次都让 AI 从 0 写，费 token 不说，主要是质量不够生产级，容易有bug，所有这些都应该预制好，让 AI 直接复用
这俩问题我们的回答，也是当时不少团队的共同思路。经过几个月，大家开发的差不多了，便扎堆上线了一批“生产级”Coding Agent（包括Lovable自己）。还有那个 AI Coding 社区，也开始讲起了小商家建站的故事
然而无人关心了，因为龙虾的大火，投资人和自媒体说他们要第一版，要那个为 Agent 做基建、为 Agent 做服务、为 Agent 搭平台的版本
（以上无论是第一版还是挑战应答版，我们都没去做，最终还是选择了那个自己更有热情东西去投入
关于我最有热情的方向，如果抽象一些来描述，它更偏消费端，要寻找不同角度，自然的，便导向了供给，通过 AI Coding 来创造更多供给
当时最热的、给非程序员用的 AI Coding 产品是 Lovable，数据猪突猛进，它的故事是：每个人都能搭建自己的网站来服务自己的用户
这建立在高价值流量来自人类客户的基础假设之上，我们认为这不能很好的描述未来
所以我们要做一个 Lovable Copy ，别的都大差不差，核心区别是 Lovable 给用户交付的是一个人类友好网站，而我们给用户交付的是一个人类友好的网站+一个基于MCP、A2A 或者其他随便什么对 Agent 友好协议的接口服务 —— 让你的业务为 Agent 流量做好准备，所有服务都值得为 Agent 重做一遍
并且对于我们自己，在积累足够多服务之后，还能从工具转平台，做服务分发和服务抽成
在龙虾大火的当下，这几乎就是最风口的故事，在那个时点，我们却收到了不少来自投资人的挑战，相对给 Agent 搭友好的服务，大家甚至更相信 Coding 是新内容形态，可以长出新的内容社区
我们不得不往这个故事里塞东西：谁要建网站？当时的 Lovable 有什么问题？
谁要建网站？
北美欧洲没有大众点评，只有 Google map。大众点评既有列表页又有详情页， Google map 只有列表页，详情需要这些小商家自己搭官网，产生大量建站需求，所以我们要为北美欧洲小商家建站而服务
当时的 Lovable 有什么问题？
当时的 Lovable，几乎就是个原型工具，无法稳定维护生产级的带后端业务的站点。小商家所需要的官网会涉及会员、预定、电商这类带后端且零 Bug 容忍度的业务组件，没必要每次都让 AI 从 0 写，费 token 不说，主要是质量不够生产级，容易有bug，所有这些都应该预制好，让 AI 直接复用
这俩问题我们的回答，也是当时不少团队的共同思路。经过几个月，大家开发的差不多了，便扎堆上线了一批“生产级”Coding Agent（包括Lovable自己）。还有那个 AI Coding 社区，也开始讲起了小商家建站的故事
然而无人关心了，因为龙虾的大火，投资人和自媒体说他们要第一版，要那个为 Agent 做基建、为 Agent 做服务、为 Agent 搭平台的版本
（以上无论是第一版还是挑战应答版，我们都没去做，最终还是选择了那个自己更有热情东西去投入
23 46