leeight retweeted
与 agent 交流的越多，越觉得与人交流的宝贵，虽然人和人的交流是低效的，人和人之间存在信息差，还可能因为各种情绪影响交流，但相比 agent 完美的回答，我还是更喜欢人与人之间“低质量”的交流。
以前 oncall 时候经常吐槽各种词不达意的低级问题，但这都成为了茶余饭后的谈资，成为工作中的调味品，现在和 agent 交流只能感觉自己的能量被 agent 给吸收走，却很难从 agent 里补给能量，下班后只会感觉精疲力尽，需要寻求新的能量补给。
AI 越强大，human as tool 的感觉越强烈，人与人的链接感觉越宝贵。
习惯了每个帖子都用 AI 润色后，尝试发一些粗糙的未经加工的帖子，能够明显的感觉到表达能力的下降 🤡
Think you'll appreciate this one borretti.me/article/no-man-i…
leeight retweeted
很多时候读AI生成的回答，哪怕内容完全正确，读上几段就会觉得异常疲惫、喘不过气。
来自纽约大学和德克萨斯大学奥斯汀分校的语言学研究人员，通过对 14 个主流大模型与人类真实文本的横向对比，揭示了这种“心累感”背后的真正元凶：
前沿AI模型正在系统性地过度使用 6 类极其消耗人类工作记忆的语言结构...
为什么 AI 写出来的东西读着这么累？
人类日常交流遵循一条内在铁律：在“表达省力”和“理解省力”之间寻找平衡。但当下的前沿模型却彻底倒向了极限压缩与高密度，制造了六大阅读路障：
生造生僻短语（冷门搭配）模型喜欢把两个罕见的词硬拼在一起，比如造出“读者耐心预算（reader-patience budget）”这类人类几乎不用的怪异词组，迫使大脑在理解时卡顿半秒。
长距离语法割裂（主谓严重脱节）模型习惯在主语和核心谓语之间塞入冗长修饰语，例如“一只总是能站起来并跑掉的猫，是一只更冷静的猫”。主语和结论被拉得极远，读到后半句时，人脑前面积攒的工作记忆已经被耗空。
强行删掉连接词（省略连接代词）为了追求字数上的精简，模型常把“the book that the professor wrote”中的 that 直接抹掉，变成“the book the professor wrote”。表面上省了一个词，实际却模糊了从句边界，增加了快速扫读时的误读率。
名词像糖葫芦一样死板堆叠诸如“恐怖电影原声带生成器（horror movie soundtrack generator）”这类名词串，完全省去了逻辑介词，迫使读者自己去逆向拆解“到底谁在修饰谁”。
不合习惯的名词动用把不该作动词的名词硬搬成动词，比如把“记在日历里”直接缩写成“calendar it”。机器觉得紧凑，人读起来却极度别扭。
对没有生命的物体强行拟人化比如写出“整场对话正在咬自己的尾巴（eating its own tail）”。虽然隐喻意图可以被猜出来，但抽象事物搭配强动作性动词，会给读者的具象思维带来额外的认知摩擦。
leeight retweeted
来x半个多月啦，认识了很多朋友，这2天意外涨了2000粉，感恩～ 也想正式介绍下自己。
我在腾讯和字节工作过15年，前期在QQ群团队，后来从0-1做过腾讯文档、capcut web、即梦/dreamina等项目，在两家公司也都负责过一些研发效能提升的事情，写过一本可能很多前端朋友看过的书《JavaScript设计模式与开发实践》
今年3月从字节离职，和一些朋友一起开始第一次大厂外的创业，这时候我已经过了40岁。之间也有不少朋友问起为什么会在这个时间出来创业 - 肯定不是为了改变世界，这个世界已经挺好，我也没有能力改变。
原因大概有：
1. 在大厂做了一些0-1的产品，待了很长的时间，在腾讯和字节也待到了前端通道最高的职级，这些产品有些有结果，有些没有结果，但都很难判断它们跟我的关系到底有多大。
2. 我们做了近15年的协同产品，做了可能是在线文档的第一个千人协同引擎。在疫情和水灾的那几年，支撑过多次真实的千人协同场景。也许在Agent时代，能用我们的经验，做一个有一点不一样的协同产品出来。
3. 暂时没有太大经济压力。
而创业以来的半年多，我们做的是一个跨多人、跨物理设备、跨厂商的Agent实时协作平台，特点是让它们共享同一个运行时环境和同一套文件系统，使用体验有点类似Agents的飞书/腾讯文档。了解Agent、沙箱、协同技术的同学可能知道，在技术平权的ai时代，它依然算工程技术门槛挺高的一个产品。昨天也看到manus这篇文章里mp.weixin.qq.com/s/I_hNNAf7L…谈到很近的未来，正好也在我们这大半年在做的事情当中。
但我有很多不擅长的地方，大部分技能都在从0开始学习。比如因为之前一直在技术线，我们都不擅长将技术更好的进行产品化。比如我以前也没有社媒账号，在注意力稀缺的时候，不知道如何让更多人知道我们这小小的初创产品。
所以我们也想从坚持分享产品进展和一些技术实现方式开始，希望能在x更结识更多的朋友，以及让更多人了解我们的产品和技术。感谢您能看到这里。方便的话也可以再点一下关注 @tutti_global
PS: 听说现在流行薄肌，因为健身比较早，失去薄肌很久了，试试能不能发厚点的（不是被@Kkkatia1逼迫的），能发的话她让我多发。
leeight retweeted
Despite MoonBit is optimized for agents, the master of mind behind @moonbitlang is human being! We take the language semantics seriously instead of vibing
leeight retweeted
🔥刚刚离职的 Anthropic 员工、Claude Code 桌面版主创 Anthony Morris近日发文直言：
他不想去管理一堆带有不同人设的 AI agent。在他看来，如果智能水平足够强大，根本不需要人为去划分角色；“聪明的通才”才是未来主流。
为此，他抛出一个犀利的问题：大家真的从这些繁复的人设中获得过实际价值吗？
他解释道：给 AI 划分角色，更多是人类固有习惯或现阶段技术限制（如上下文窗口、记忆可靠性）的产物。事实上，“全新的上下文 + 对应的技能”就已经足够，完全没必要专门去炮制什么“审查代理”或“执行者”。
大多数用户其实并不会去配置复杂的人设，因此，开箱即用的默认体验就应该是一个强大的通才。技术终将重塑工作方式，我们没必要永远去照搬过去人类的那套精细分工。
leeight retweeted
capcut web是我到字节做的第一个项目（招我来字节也是为了这个项目。）在架构和性能上花了特别多的精力（熬了几个月），😅 希望跟chatGPT一起起飞。
We’re excited to announce our new CapCut plugin is coming soon to @ChatGPT at CapCutWorldLA.
The plugin brings CapCut's video editing and generation tools alongside ChatGPT. You can start with an idea in ChatGPT, bring it to life with the CapCut plugin right inside ChatGPT, then take your draft video to CapCut's web editor to refine, share and publish.
By bringing the CapCut product you already love and use in ChatGPT, we're making content creation more seamless and efficient.
leeight retweeted
We’re excited to announce our new CapCut plugin is coming soon to @ChatGPT at CapCutWorldLA.
The plugin brings CapCut's video editing and generation tools alongside ChatGPT. You can start with an idea in ChatGPT, bring it to life with the CapCut plugin right inside ChatGPT, then take your draft video to CapCut's web editor to refine, share and publish.
By bringing the CapCut product you already love and use in ChatGPT, we're making content creation more seamless and efficient.
leeight retweeted
Magpie 现在有 Web 版了，可以部署在服务器上用了 🎉
· magpie web：在浏览器里打开完整界面，WSL、SSH 远程的机器都能用
· Docker 镜像：ghcr.io/yetone/magpie（amd64 / arm64）
· MAGPIE_WEB_KEY 固定访问密钥，适合长期作为服务运行
部署说明：github.com/yetone/magpie#doc…
leeight retweeted
Anthropic 这篇新文章在劝搭 agent 的人少拆 subagent，里面有句话太真实了，很多企业的 agent 架构就是照着组织架构图抄的。每个团队交一个 subagent，平台组在最上面套个 orchestrator，康威定律又赢了
思路是把 router、planner、按领域拆的 subagent，能折回主 agent 循环的都折回去，换成按需加载的 skill 和 tool
他们经常看到的方案是一层层叠上去的，意图分类器、固定的多步推理流水线、用户分群、单独的推荐分支，最上面再套一层多 agent 编排。给的反馈往往是，这套结构大部分在替模型干它早就不需要别人替的活，一个写清楚的 system prompt、四五个很薄的数据 tool、加上严格的输出护栏，就够覆盖大部分场景
Applied AI 团队在几家企业的部署里对比过，单 agent 加 skill 的质量经常同时赢过一个 prompt 包办一切和多 subagent 两种做法，很多时候成本和延迟也更低。有家客户拿单循环跟自己的多 agent harness 比，快了差不多一倍
新的循环是一个模型、一个上下文窗口，harness 只管设上限，轮数、成本预算、写操作要过闸。模型每轮发一批 tool call，harness 并行跑完，把原始结果还给同一个模型，由它决定继续调工具、问用户还是回答。计划也是模型第一轮自己写进上下文，结果回来再改。写计划的就是执行的那个，中途随时能改，这是跟 orchestrator 那套最大的区别，以前用代码按规则表改计划的那一步可以直接删了
原来各个 subagent prompt 里装的东西分到几个地方。团队做事的步骤、顺序和判断写成 skill。校验、审批这种硬限制，还有查记忆这种对话中途才要的，放进 tool。政策、指标定义、产品规格放知识库，让模型自己去查，别用代码查好了往 prompt 里粘。代码只留给便宜又几乎每次都要跑的步骤，和 tool 内部那些机械活
上下文不会爆，靠的是渐进式披露。skill 和 tool 平时只露一句简介，用到才完整加载，tool 那边靠 tool search 延迟加载。以前拆 subagent 最主要的理由就是上下文塞不下，这下基本没了，Claude Code 给新模型的 system prompt 砍了 80% 以上，其中就有这块。而且所有步骤的结果都在同一个上下文里，模型能前后连起来看，比 subagent 各交回一份摘要强，也不会交接一次丢一次细节
模型也撑得住了。从 Opus 4.5 开始，一个循环里能管的事就比大多数团队以为的多得多，Opus 5.5 和 Fable 5.1 的 thinking 都关不掉，还会边做边报进度边自查。帮客户迁新模型的时候，拦着新模型多干活的常常就是那套死板的多 agent 结构
团队分工也跟着变。各团队不再各交一个 agent，改成交 skill 和 tool，一个很小的中央团队管 system prompt 和端到端质量，新的 skill、tool、eval 上线前都要过他们。不然就是每个团队往 system prompt 里塞一句，最后规则打架、口吻也不统一，文章管这叫 Frankenprompt
各团队交上来的 tool 要按用户意图分组，别一个 API 一个 tool，定义超过 30 到 50 个，选工具就开始变差。前置条件和权限也写进 tool 里，缺了前一步的结果就返回一句模型能照做的提示，用户没权限就返回一句普通的拒绝。这样一个循环就能服务权限不同的用户，不用每个权限级别配一个 agent
subagent 当然还有用，三种情况还是该拆。单循环因为上下文膨胀效果有了能测出来的下降，几件事要并行、各开一个用完就丢的干净上下文，或者单个 agent 老选错工具、system prompt 里指令打架。要拆也按上下文拆，给它一块不太依赖别处的活，让它交回精简的结果。按问题类型拆就成了传话游戏，交接一次失真一次。留下的 subagent 最好当 tool 调，主 agent 一直握着跟用户的对话
迁移别想一步到位。先做 eval，10 条标准样例就够起步。从调用最多的开始折，生产流量里经常前后脚被调的两个专家 subagent，就适合先合成一个。之后一次只折一个，prompt 改成 skill，API 调用改成 MCP tool，再跟原来比
比的时候别只看总分，要看哪些题翻了。他们拿一个示例客服 agent 试，折完延迟降了，但一个本来能过的流程坏了，主 agent 手里有查订单的 tool，就自己答了，没去问管物流的那个 subagent 要送达日期。这个问题跑两次只出现一次，这种最阴。所以生产上一起跑的每条 agent 链、每条不能破的规则都要有对应的题，每题多跑几遍。折回去的版本分数更低，才继续留着 subagent
配套还有个迁移工具包，能先在模拟系统上跑 demo。几个 /claude-api skill 里我觉得 prompt-audit 最有意思，专门找当年为旧模型写的、现在反而让 agent 变慢变死板的规则
对写 harness 的人来说最扎心的是这句，每出一代新模型，就能把更多决策从 harness 挪进模型里。我感觉 harness 以后只会越写越薄
leeight retweeted
[1/n] 作为这场训练“投毒”事件最直接的受害者，2024年那几个月漫长的训练排查、对峙与质疑，对我而言是一段炼狱般的经历，也是一场对意志和技术的锤炼。
感谢好友们最艰难的时候支持陪伴。也感谢当时所有并肩作战的同事们。
leeight retweeted
We believe voice is the most natural way to interact with intelligence, so we created Dessa, the most authentic full-duplex speech model ever built. Talking with it feels like talking with a person…full of emotion, nuance, pauses, and a natural cadence.
block.xyz/dessa
leeight retweeted
Been working on the @RomeAILab Mac app for a while now. My agent and I have been working together really well through it, and the results have been pretty amazing. Can’t wait for you to try it.
Stay tuned 👀
leeight retweeted
Anthropic 最近开始建议企业「少用点 Subagent」，甚至把一些专家 Agent 重新合并回主 Agent Loop。
他们在多个企业项目中发现，单 Agent + Skills 的效果经常比复杂的多 Agent 架构更好。有个客户改成单 Loop 后，运行速度甚至快了约 2 倍。
原因很容易理解。
多个 Agent 之间反复交接任务，每次都要传递和总结 Context，信息容易丢失，延迟和成本也跟着增加。
Anthropic 现在更推荐让一个主 Agent 负责规划和执行，需要时再动态加载 Skills 和 Tools，把业务流程和领域知识留在可复用的组件里。
不过文章里有个细节值得关注。
他们曾把客服系统里的 Subagent 合并，延迟确实降低了，却让一个原本能完成的任务失败了，因为主 Agent 漏掉了向物流专家确认送达时间这一步。
所以作者强调，每合并一个 Subagent，都要用端到端 Eval 验证，尤其要检查哪些原本通过的任务突然失败了。
当然，并行研究、独立验证、Context 隔离这些场景，Subagent 依然有价值。
这样看来以后设计 Multi-Agent，可能得先问问自己，每个 Subagent 真的需要独立的 Context 和执行循环吗？
Anthropic 还开源了一套迁移工具，可以帮你分析现有架构，逐步合并 Subagent，并比较改动前后的质量、成本和延迟。很推荐做 Agent 工程的朋友试试。
原文：claude.com/resources/article…
leeight retweeted
I’m looking for my next role.
I created SWC (swc.rs), the Rust-based open-source transpiler used by Next.js, Rspack, Node.js’s amaro, Parcel 2, and other projects.
I maintained Next.js and Turbopack at Vercel and previously worked with Deno.
My expertise is in developer tooling and performance optimization. I enjoy digging deep into difficult technical problems, and I’m open to new challenges across fields.
I prefer roles that let me work remotely from Korea. If you’d like to work together or know a team that could be a good fit, please DM me.
