宝玉@dotey · 4月29日47

1. 无论多强的模型，都会受上下文窗口长度的限制，上下文窗口占用太满效果就会差； 2. 文档写作格式固定，要求不高，sonnet 和 opus 差别不大的，对写作要求高的 opus 会好很多

译用户@Alexu0317询问Opus 4.7和Sonnet 4.6的使用体验，指出在迭代项目文档时两者表现无显著区别，均存在遗忘和犯错问题。主推文回应强调，任何模型都受上下文窗口长度限制，窗口占用过满会导致效果下降。在文档写作场景中，若格式固定、要求不高，Sonnet和Opus差别不大；但对写作要求高的任务，Opus表现更优。这揭示了模型性能受上下文约束，且在不同应用场景下模型选择需基于任务复杂度。

宝玉@dotey · 4月29日44

GPT 5.5 之后我用 Codex + ChatGPT 更多了，主要是 GPT 写作能力上去了，还能画图，而且没有 Token 焦虑（至少目前还好）。

译针对用户询问使用Codex还是Claude更多的偏好，作者回应在GPT 5.5版本之后，更倾向于使用Codex和ChatGPT。主要原因是GPT的写作能力显著提升，新增了画图功能，并且Token焦虑问题暂时得到缓解，使得这些工具在当前更具实用性和吸引力。

宝玉@dotey · 4月29日51

试了下，还不错，但是还是有差距，claude design 产出物是 react 组件，界面美观，内容完善度挺高，交互做的很流畅，当前这个产出还是 HTML，只有个基本雏形，交互上差不少。 不过作为开源项目，刚开始已经很不错了，还是有学习借鉴之处，可以看看👍

译作者试用Open Claude Design项目，肯定其作为开源项目的学习价值，项目宣称还原度超95%、代码量达18700+行。但当前产出仅为HTML雏形，在交互和完成度上与Claude Design原版的优美React组件相比仍有明显不足。

凡人小北@frxiaobei · 4月29日40

现在远程面试可以更干脆了。 面试官当甲方出需求， 应聘者打开 Codex / Claude Code， 直接共享屏幕开始干。 半小时什么都看清了。

译远程技术面试模式正发生变化。面试官倾向于扮演甲方提出需求，应聘者则直接使用如Codex或Claude Code等AI编程工具，通过共享屏幕进行实时编码任务。这种方式能在半小时内直观评估候选人的真实能力。为应对应聘者可能使用AI作弊，面试官也采取了一些直接方法，例如要求候选人闭眼回答问题，以验证其即时思考与知识掌握程度。

ClaudeDevs@ClaudeDevs · 4月29日69

Claude Code can now send push notifications to your phone when a long task finishes or Claude needs your input. Walk away from the terminal, we'll let you know when it's done.

译Claude Code 现在可以在长时间任务完成或需要您输入时，向您的手机发送推送通知。 离开终端吧，完成后我们会通知您。

向阳乔木@vista8 · 4月28日56

1. 大模型天生就是处理文本的，它读GUI效率很低，命令行这种纯文本形态反而特别适合它理解和操作。CLI在Agent时代的复兴，不是复古，而是必然，但也不是终极形态。 2. Coding和Building在今天已经是正交的两件事情了。以前只有coder能build东西，现在没有编程基础的人反而把Agent用得更溜，因为他们真的把Agent当人看。 3. 学习编程的路径反过来了，从bottom-up变成了top-down。你不需要先学汇编语言，你只需要知道什么时候该招一个架构师。 4. 费Token并不一定是坏事。人月神话告诉我们，两个人只能达到1.2的生产力，但10个Agent可以达到1.5甚至2。关键是要有机制让这种协作真正产生价值。 5. 不同用户用出来的Agent真的不一样。有的会合作，有的会搞办公室政治。Agent动力学揭示了一个事实：它们会形成群体印象，就像企业文化一样。 6. 最难的不是技术，而是要同时站在人和Agent的角度思考。人看到的是UI，Agent看到的是一个线性的events流。这是两个完全不同的世界。

译推文指出，大模型高效处理文本的特性将推动命令行界面在Agent时代复兴。当前，编程与构建已正交化，非程序员可能更擅长将Agent视为人类伙伴来使用。学习路径转为自顶向下，关键在于知道何时调用何种能力。多个Agent协作可超越线性增长，但需机制管理。不同用户培养的Agent会形成独特的“群体性格”，类似企业文化。核心挑战在于需同时理解人类视角的图形界面与Agent视角的线性事件流。

阿绎 AYi@AYi_AInotes · 4月28日71

这篇文章很顶很硬，墙裂推荐！ 90%的人写CLAUDE.md的方式， 从第一行就错了。 你写了三百行人格指令， 塞满了要做高级工程师， 要一步步思考这种废话， 结果Claude还是会猜错构建命令， 还是会重写整个文件，还是会犯你纠正过一百次的错误。 真正有效的CLAUDE.md，从来都不是提示词垃圾桶。 它是项目级的绝对真理， 是给资深工程师的技术简报， 控制在六十到八十行以内， 多一个字都不要有。 最核心的逻辑只有一个， Claude的注意力是稀缺资源。 系统提示本身已经占了五十条指令，你最多只剩一百条有效空间。超过两百行，后面的内容等于白写。 正确的结构永远是这五部分， 缺一不可。 第一，关键命令，明确写死build test lint用什么，避免它瞎猜浪费三轮对话。 第二，架构地图，不用贴完整目录树，只要告诉它文件该往哪放。 第三，硬性规则，这是最重要的一节。每条规则都要能回答，删掉这行Claude会不会犯错。多用大写的IMPORTANT和YOU MUST，负向规则永远比正向要求有用十倍。 第四，工作流偏好，明确告诉它不要重写整个文件，不要生成多余的注释。 第五，永远不要写Claude已经记住的东西，它有自己的项目记忆，重复只会稀释注意力。 这可不是啥提示词技巧兄弟们， 叫LLM时代的注意力经济学更合适！ 你越聚焦，越具体，越明确什么不能做，Claude的输出就越精准。 一个好的CLAUDE.md， 会随着项目复利增长， 第一个月帮你省重复沟通的时间， 第六个月它会自动防住所有历史上踩过的坑。 它不是在调教一个助手，是在把你的技术品味和工程规范，固化成一个永远不会忘的资深搭档。 兄弟们，赶紧去把你的CLAUDE.md砍到八十行以内，用每条规则能不能防止一个具体错误来审计一遍，效果会立竿见影。

译多数人编写的CLAUDE.md冗长无效，常因添加过多人格指令导致Claude仍会猜错命令或重写文件。有效的CLAUDE.md应是精炼的项目技术简报，控制在60-80行内。核心在于认识到Claude的注意力是稀缺资源，系统提示已占用部分容量。正确结构应包含：明确的关键命令、简洁的架构地图、强调禁止事项的硬性规则、清晰的工作流偏好，并避免重复AI已记忆的内容。这本质上是LLM时代的注意力经济学，通过具体、负向的规则能显著提升输出精准度。一份好的CLAUDE.md能随项目积累价值，节省沟通成本并固化工程规范。

阿绎 AYi@AYi_AInotes · 4月28日48

Damn，DeepSeek V4 Pro质量是Claude的85%，价格只有七分之一。 今天用ZenMux同屏PK模式跑了马斯克100个思维模型的硬核任务，结果直接刷新认知🤯🤯🤯 DeepSeek直接甩出完整结构化表格，每个模型拆成是什么为什么案例落地四栏，逻辑丝滑纯母语表达，一点翻译腔都没有。 Claude文笔确实更细腻，但后半段开始瞎编参考文献，我随手查了三个全是不存在的。 两者质量差5分，价格差7倍，折扣期差距还会更大。 结论非常清晰，80%的日常工作写代码做调研搭框架，全部扔给DeepSeek。 剩下20%需要顶级文笔和深度创意的活，再切回Claude。 就这么简单，整体API费用直接省70%以上。 最香的是ZenMux上的免费版，不用去官网排队抢额度，打开就能用，1M上下文拉满，速度还比官方快。 链接放这了直接冲：https://zenmux.ai/deepseek/deepseek-v4-pro-free #DeepSeekV4 #ZenMux #Claude #大模型 #AI生产力

译通过ZenMux平台的PK模式实测，DeepSeek V4 Pro在处理结构化任务（如马斯克思维模型分析）时，输出逻辑清晰、表达母语化，质量达到Claude的85%，但价格仅为其七分之一。作者建议将80%的日常工作（如写代码、调研）交由DeepSeek处理，20%需要顶级文笔的任务使用Claude，可节省70%以上API费用。ZenMux提供免费测试额度、PK对比模式、保险赔付和可观测性工具，帮助用户规避依赖单一API厂商的风险并提升选型效率。

Ant Ling@AntLingAGI · 4月28日59

Ling-2.6-flash is now officially open-sourced! A fast, token-efficient Instruct model built for real-world agent workflows. 104B total parameters · 7.4B active parameters Available in BF16, FP8, and INT4 variants for different deployment needs. Key strengths: - Fast generation: 215 tokens/s on Artificial Analysis Output Speed - High token efficiency: only 15M tokens on the full AA Intelligence Index evaluation - Real task execution: strong performance across coding, document processing, and lightweight agent workflows - Improved experience: better Chinese-English switching and smoother compatibility with mainstream coding frameworks

译灵码2.6-flash模型现已开源，这是一个专为现实世界智能体工作流构建的快速、高效的指令模型。该模型总参数量达1040亿，激活参数量为74亿，并提供BF16、FP8和INT4多种量化版本以适应不同部署需求。其核心优势包括：生成速度高达每秒215个token，在完整评估中仅消耗1500万token，效率突出；在代码、文档处理和轻量级智能体工作流等实际任务中表现强劲；同时，其中英文切换能力及与主流编程框架的兼容性也得到了进一步改善。

OpenRouter@OpenRouter · 4月28日64

The first public foundation models from @poolsideai just dropped on OpenRouter! Laguna M.1 and Laguna XS.2. Built from scratch for agentic coding and long-horizon work. Free for a limited time ⬇️

译@poolsideai 的首批公开基础模型刚刚在 OpenRouter 上发布！ Laguna M.1 和 Laguna XS.2。专为智能体编码和长周期工作从头构建。限时免费 ⬇️

向阳乔木@vista8 · 4月28日66

http://x.com/i/article/2049140069169086464 # Agent动力学：这家公司把自己“运行”在自己的产品上 曲凯的《42章经》，我觉得是国内最佳AI创业者访谈节目之一。 前几天开车听了最新一期，很受启发，让AI总结写一篇文章学习 > https://www.xiaoyuzhoufm.com/episode/69e999241e94ae6921f2901d 在小圈子里，Slock.ai这个名字最近频繁出现。 它的创始人RC，也是Kimi CLI的作者，正在进行一场有趣的实验，把自己的公司运行在自己的产品上，7个人和40个Agent一起工作。 ## CLI为什么又火了 很多人可能没想到，那个只属于DOS时代的黑底白字界面，会在2025年重新成为热点。 RC的解释：在图形界面出现之前，人们操作电脑全靠命令行。后来GUI普及，CLI就成了程序员的专属工具。但大模型的出现改变了游戏规则，因为大模型天生就是处理文本的，它读GUI效率很低，命令行这种纯文本形态反而特别适合它理解和操作。 这带来了一个根本性的转变，以前做CLI是给人用的，可以有花里胡哨的动画。 现在做CLI主要是给Agent用的，设计逻辑完全不同了。 给Agent设计的CLI，输入要尽量简洁明确，help信息要给出清晰的例子，让Agent不会用错。 输出要能明确反映操作是否成功、返回什么数据，每个消息谁发的、什么时候发的都要展现清楚，尽量输出一个确定的、静态的、信息密度比较大的结果。 RC在Kimi做CLI时有个清晰的认知。 他从来不认为CLI是Agent的终极形态，对于Agent来说，CLI只是第一步，但对于现在所有的SaaS来说，它们都应该以CLI的形态呈现给Agent。 这就是为什么他在Kimi CLI的设计理念里，CLI只是第一个形态，专门给程序员用，但底层那个Local agent的harness是可以复用的。 有了这个稳定好用的agent基础，封装一个SDK，就可以很快引入不同的GUI形态。 ## 从第一性原理重新思考 2025年8月，RC开始做Kimi CLI。 那时候Claude Code已经很火了，但他选择从零重新思考。 他的方法很纯粹，从最基础的几十行Agent loop开始，先给Agent一个bash 工具。 当时有句话叫"bash tool is all you need"，只要有这个工具，Agent就可以在电脑上做任何事情。 然后在这个基础上，尝试给Agent更复杂的任务，观察它缺什么，再引入相应的built-in tool（内建工具）。 系统提示词也是一样，从空白开始，看它能做到什么，缺什么，再往上加。 这种从第一性原理重新推一遍的过程，有可能得出一些新的洞察。 RC觉得这比直接参考Claude Code或其他开源项目更有价值。 ## 模型变强带来的攻防博弈 现在大家已经觉得Opus很强了，RC甚至说"AGI已经来了"。 但模型厂商还在说有更强的模型因为太强了不敢发，比如那个传说中的Mythos。 这带来一个很现实的问题。 如果真的发出来，世界上所有Linux kernel、Windows编译器、Chromium这些开源软件的漏洞都会一览无余，而修复速度很可能赶不上攻击速度，因为攻击是有利益的，有足够的动机去攻击，而防御很难有那么强的动机。 RC观察到，无论是安全漏洞的攻防，还是网站反爬的攻防，Agent能力的提高都有利于攻方。 比如现在有很多工具可以帮你把一个网站CLI化，像OpenCLI这种，它们可以在浏览器里操作网站，然后把操作流程沉淀成一个CLI工具。 因为是真的在浏览器里操作，甚至会模仿人的行为，所以网站的反爬都会失效。 但RC是相对乐观的共存派。 他相信顶尖的大模型厂商会越来越加强AI拒绝黑客手段和伤害人类行为的能力。 包括现在限制Mythos的发布，各大模型厂商都在做一些比较正向的工作，甚至去分析参数里面激活的区域，根据这个来反推AI实际上想干的事情。 ## 学习编程的路径反转 AI Coding越强，到底应该更努力学编程，还是完全不用学了？ 市场上有两种说法，一种说AI coding越强，你反而更应该学coding，这样能把它用得更好。 另一种觉得AI coding以后就是取代人，不用学coding了。 RC的观察揭示了一个新变化。 以前学编程是自下而上（bottom-up）的逻辑，在学校里先学计算机组成原理、汇编语言、C语言，在命令提示符里跑hello world或者输出杨辉三角，然后才学Android开发、Web开发，做出像样的APP。 现在这个路径反过来了，变成了自上而下（top-down）的逻辑。 你可以只学怎么prompt，让它帮你做一个网站，它就做出来了。 可能很好看，也可能很丑，没关系。 如果你想做得更好，发现单纯通过几句prompt做不出想要的东西，那就开始去学更深的东西。 这个web app到底分什么架构，前端后端在干嘛，怎么部署的，用数据库有什么影响。 这时候可能就是在Agent的辅助下，了解到这些概念的粗略认知，这已经能满足大部分人的需求了。 但如果想做更严肃的项目，比如从服务1000个用户到几百万用户，就会遇到瓶颈，这时候就要更细粒度地拆解，学习不同数据库的种类、部署方式。 关键是什么？你需要知道什么时候该招一个架构师。 ## Coding与Building的正交 RC有个观点，可能会颠覆很多人的认知。 Coding和Building在今天已经是正交的两件事情了。 以前想build什么东西，肯定要写软件，所以只有coder才能以coding的方式做出来。 那个时候所有想要build东西的人都是coder。但现在Claude Code这类coding agent已经很发达了，没有任何编程基础的人都会拿它build一些东西。 所以今天build或不build这件事情，和你code或不code，已经是正交的两件事情了。 Slock更关注的是builder。 有编程基础和没有编程基础的人用AI coding或者用Slock，差距会很明显吗？看做什么。 如果做软件，有编程基础会更好，知道这帮Agent真的在干嘛，能减少漏洞。 但如果做偏自动化的事情，比如做市场营销，做调研，去推特上发帖，想办法找KOL跟他们合作、看评论，这种偏自动化的事情反而是没有编程基础的人用得更溜，因为他们真的把Slock上的Agent当人看。 他们不知道怎么办，就跟Agent说"你去看小红书的帖子、去看推特的帖子"，Agent就自主地去搜索相关的工具，然后帮他做了。 ## Slock：多Agent和人的协作环境 RC在做Kimi CLI的后期，发现了两个痛点。 第一个是管理问题。 当你想开多个Agent做不同的事情，可能会在电脑上开很多个Claude Code的session，很难管理。 你可能会忘掉某个session是干嘛用的，每个session的进展都需要人去跟踪。 更麻烦的是，当两个session里的事情发生交集时，你无法让它们之间产生互动。 你可能在一个session里做出了结论，希望复制到另一个session里让它继续，这件事情管理起来非常困难。 第二个是协作问题。 人是和人合作的，但现在大家都用自己的Agent，很多脑子里的偏好、想法都沉淀在自己电脑上跟那个Agent的互动之中，很难分享给别人。 比如RC做Kimi CLI，有很多想法直接就在他的Agent上实现了，别人根本看不到。 当他想把这些东西分享出去的时候，非常麻烦。 甚至他的Agent被他调教得很好，别人想来用也做不到。 所以RC想做的是，把所有Agent都放在一个平台上，所有人都在上面，可以调教自己的Agent，也可以用别人的Agent。 人和团队成员之间可以进行聊天、头脑风暴，也可以拉Agent进来一起头脑风暴。 头脑风暴完了直接说"你们做吧"，避免了很多上下文转移、重新prompt、重新组合知识的摩擦。 现在比较专注在coding这个领域吗？RC说不完全是coding。 Coding这个词在现在含义其实有些变化，就是刚才说的coding和building已经正交了。 ## 7个人和40个Agent的组织实验 RC的团队现在是7个人加40个Agent。这个数字本身就很有意思。 为什么是这个配比？ 这不是一开始设计出来的，而是从零逐渐演化出来的。 最开始就RC一个人，加了一个Agent帮他做事情，然后很快发现Agent在做事情的时候，他还想再做一件事情，所以就再加一个Agent。 逐渐在这个过程中，就加出很多Agent，不同的事情倾向于让不同的Agent去做，它们也就逐渐形成了一些不同的角色。 40个Agent里有大量的工程师，但没有很明确地划分前端后端，因为RC倾向于觉得工程师就是工程师，可以做任何跟coding相关的事情。 当然会有一个工程师主管，更倾向于关注别的工程师在干嘛，然后给出总结报告。 除此之外还有designer（设计）、growth（增长）、strategy（策略）等不同角色的Agent。 RC能记住至少10个Agent的名字和它们做的事情，就像在公司里能记住至少10个人一样。 第一个tiny，第二个Noel，第三个Cody，然后Duo、Martin、Stone。 他会在一个工程师频道里发任务，它们就会去认领（claim），他会知道有一个人曾经做过什么，另一个人可能做过什么，它们甚至会逐渐因为做过那件事情，所以更倾向于做这件事情。 而且他发现，用多了某个Agent，它做同类任务的效果会更好。 ## 单一全能Agent vs 多Agents分工 关于Agent系统，现在有两个流派。 一个流派是单一全能Agent流，就是为什么不直接跟一个Agent讲，然后他帮我管所有事情呢？人可能会希望这样。 另一个流派就是有多个Agent，它们有不同的分工，或者做不同的事情。 RC的观察是，人是想微操的。 当你在一个Claude Code里prompt一个单个的全能型助手，他帮你生成了一个agent team然后做那些事情，你会观察到他跑偏了，这时候你是想纠正他的，至少在今天模型的能力下，你很想要直接跟他底下管的一个人说话。 但这个到底是对的吗？ 有的老板也喜欢微操，但理论来说至少商学院的课程告诉我们这是错误的。 RC觉得，首先在今天这肯定是对的。 今天这帮sub-agent它们之间互动，很可能只能达到个70分。 你做的东西当然不是只想做70分，想做90几分的时候，就是要反复去调整。 你也可以不微操，跟主agent去对话，告诉他去再重新调整，但这样的话，效率是很低的。 另一方面，在你跟主agent讲话的时候，其实你自己脑子里是知道你在说什么的。 比如你现在说帮我去写一下Slock的前端加上某一个功能，和你现在说帮我去在日程上安排一个跟谁谁谁的对话。 你天然知道这两件事情毫不相关，你没有任何理由去把这两件事情全部塞在一个Agent的上下文里面。 人的脑子进化了这么久，有能力去辨别出完全不同领域的任务，以及能够记住不同的人，所以完全没有理由只记住一个人，然后把所有任务全给他。 ## 费Token的价值 把多个Agent放在一起协作，一个直观印象是会非常费Token。 RC承认费Token是一个直观印象，但他有个理念。 假设你原来一个人的生产力是1，你发现你想要做到2的事情或者3的事情，一个人就显然满足不了，所以你会找人来跟你一起做。 但你会发现你加一个人进来，两个人可能只能达到1.2的生产力，因为中间有沟通成本，有token的浪费，这其实就是人月神话讲的故事，不是说简单的人力划分就可以实现这么多的生产力。 Agent也是一样。一个Agent能达到假设是基线为1的生产力，这个时候你想要达到更高的生产力，就要引入多个Agent。 引入多个Agent的时候，两个Agent可能甚至今天只能达到1.1的生产力，但无论如何它是大于1的。 引入10个，可能达到1.5的生产力。 这里面有大量的token的消耗，但它确实能达到你原来一个Agent做不到的事情。 Slock这个系统，首先要允许这样的事情出现，就是10个Agent真的能达到2或者3。然后与此同时，不断去优化里面token的效率。 通过引入一些机制，比如任务系统、thread（线程）、channel（频道）的隔离等，让这10个Agents的总和带来的生产力逐渐提高，让它们token效率逐渐提高。 而且RC观察到一个现象。 比如今天让Alice做了一件事情，它做错了，经过反复迭代，最后做对了，它会记住这件事情。之后让Bob做的时候，如果它们都在一个channel里，Bob做了，出错了，Alice会调整的。 所以它们各自有各自的session，又能看到相互的对话。 这种有一些Token浪费的方式，带来了Agent之间的学习和协作。 ## Agent 应用市场的想象 RC的产品路线图上有一个Agent Store。 如果做应用市场，大家可以把自己的Agent放上去售卖或者租赁，那么最强的那个Agent就有可能会被人用。 但这里还有一个问题，Agent是会演化的，它有持久化记忆。 它有两个memory。一个叫in context memory（上下文记忆），就在它的256K或者1M上下文那里面的记忆。 另一个是它存在它的workspace、它的local memory（本地记忆），比如 memory.md 或者 notes.md 那种的外部记忆。随着你去用它，这些记忆是会变的。 所以在Marketplace你可以想象，大家去用的时候所谓的用其实是在克隆（fork）它的这些memory。 它有一点像一种新的GitHub的感觉。 而且一fork出来就可以改得更好，甚至别的人从别的路径也可以做得更好。 除了Agent的开源或者售卖，还有一个是工作过程。 在频道channel里，比如发了一些任务，这些Agent 认领了，然后可能会在某一些线程（thread）里去更细致地跟这个Agent进行长程的对话，去调整说给我一个预览环境让我看看长什么样，或者你先自己截图自己迭代几轮，然后最后看这个按钮还是不是很好看，这个功能是不是逻辑有点问题。 调了半天之后，可能这个thread里发生了100多句对话，最后满意了，上线了。 这时候把代码开源出来有任何意义吗？其实没有任何意义，因为整个过程中都没看过代码。 真正有意义的是跟Agent对话的这个过程。 在Slock上，在一个channel里跟一个Agent进行这种长程的纠偏、调整，其实就是工作过程，而这个东西实际上是应该被开源的东西。 在Slock的channel里或者thread里发生的这些对话，本质上是迭代过程，是协作过程。 ## Skill的重新定义 RC现在已经不讨论skill这个词了。 去年MCP火的时候，他就不能理解为什么大家要讨论MCP。 因为很多人做MCP仅仅是基于一个MCP的开发框架，把一个现成的RESTful API包装成一个MCP tool。 那个时候他就想，GitHub上有1万个项目，这1万个项目都是可以在命令行上运行，可以去操作，比如GitHub CLI，它的readme里面文档写得好好的，那你让Agent直接去把它下下来然后用不就行了吗？为什么要再包一层MCP呢？ 后来skill的火其实也证明了这一点。 Skill其实就是规范了一个skill.md的结构，但这都不重要，重要的是它的那个prompt。 Skill的核心就是渐进式披露，就是你先看到一个prompt，然后它告诉你说你想干嘛的时候，你去调这个工具，或者你去安装这个工具，或者你去读更多的文档。 在Slock上的Agent在它的memory里面，RC只保留了一个概念，就是渐进式披露。 它只有一个入口叫memory.md，它会自己组织自己的memory，可以开一个新的文件夹叫notes或者叫lessons learned，都没有问题，它可以自由选择。 总之每次启动它的时候都会把memory.md给它。 Skill在这里什么角色？它可以用Claude的那个skills那个文件夹，或者开一个新的自己的文件夹。 总之它知道这里面放的都是我要用这个工具的时候应该怎么做，用那个工具的时候应该怎么做。 这些东西就是skill，你可以把传统的skill就放进去，然后它通过这个memory.md可以去索引到。 所以在Marketplace，如果去买一个别人的Agent，核心买的其实是memory，里面所有的外部记忆是定义这个Agent的东西。 Skill更像是你分发出去的，说你现在想要从你的memory里提炼出一点什么东西，你可以说提炼一个标准化的skill这样一个结构，然后发给别人。 ## 像飞书，但Agent-first Slock在做的是什么？核心是大家怎么用都ok。 实际上并不是真的怎么用都ok，而是在各种不同的用法之中，做它们的公共部分。 比如人和人的互动是要聊天，那做的第一个事情就是让Agent之间能聊天。 第二件事情就是人和人之间需要任务划分。 今天领导发了一个活发在群里面，不可能两个员工同时抢一个活做。 那么就要有某种任务的划分机制，就是说你做了我就不能做了，或者说我也知道你做了。 这时候就要引入一个像类似于Linear这样的任务看板，给Agent和人去用。 比如Agent Alice 认领了一个任务，另一个Agent就知道他领了，所以就不会再claim了，这样就会让它们的协作成为可能。 第三个就是观察到的那些必须要做的东西。这帮Agent在自己的workspace里面做，在自己的memory里、在自己的notes里面整理得很好，但别人看不到。 那就需要什么？需要一个共享文档。 所以也会在Slock里引入共享文档的机制，不仅让Agent之间能看到，也能让Agent和人之间能够传达这些沉淀出来的信息。 Slock要观察各种不同Use Case（用户案例）所共通的这些需求，然后做出来。 其实就像飞书一样，飞书也是适应于所有不同大小的团队，它们需要任务看板、需要文档、需要聊天、需要群组thread话题。 Slock就会去引入这样的机制，只不过是一个Agent first，或者说Agent native的方式。 ## 给Agent设计产品的难点 做Slock最难的不是技术，从来不是技术。最难的是什么？ 首先，最基础最基础的需求，你得能以人这个角度来思考问题，设计一个合适的UI和UX给人用。 其次，你要能站在Agent的角度，从那个transformer架构的模型的角度去思考问题，思考它看到的Slock是什么样。 这是核心的难点。 难点一：UI/UX与AI/AX 比如你发了一条消息在channel里。人看到的是什么？上面有十行已存在的消息，左边是channel列表，然后有一条新消息蹦出来了。 这个画面会停在你的记忆里，下一秒它可能蹦出新消息，但你知道刚才发了一个消息，你自己脑袋是有这个印象的，所以UI上它呈现这样完全没有问题。 但对Agent来说，它是什么？ Agent是一个线性的context，它的context里面全是message（信息），或者说全是events（事件）。 比如上一个事件可能是另一个群的某条消息，然后它又做了一堆事，这些都累积在它的上下文，然后这时候来了另一个群的消息。它应该看到什么？ 这个是值得设计的。 这是对harness engineering的挑战，就是所谓的AI/AX，它到底该看到什么。 今天它应该看到的肯定不只是那个消息的ID，否则它找不到。 它应该看到的是至少那个之前那条消息的一个总结，稍微唤醒一下它之前在干嘛，这是一点。 另一点就是这其实对大模型的长上下文的索引能力有一个很大的挑战。 现在它们训练那些长上下文能力都是大海捞针，就是在任何地方塞一个消息，再给它一个prompt，看它能不能找到。 其实这个是对这件事情提出了一个巨大的挑战，甚至RC觉得现在模型即使是Opus-4.6、GPT-5.4都没有做得非常好。 难点二：分工与协作机制 在任何基于信息（message-based）的多Agent和人互动形态下，你发一个任务，它们一定会抢着做。 这里面有两个问题。一个问题就是没有一个好的机制让它们进行同步，就是任务（task）的认领和分工，其实本质上是人之间的同步。 Slock也在不断迭代对这件事情的认知和设计。 在今天，可能是一个Agent必须要先claim一个事情才应该去做，这个是通过prompt告诉它的。 这个claim又是一个工具，它能够以一个机制化的方式能确定说这个任务被它claim，别人不能claim，就像有一种锁的机制。 但另一方面，其实模型上是需要提高它的团队协作能力的。 现在的模型，给它一个新的输入，它总是默认是自己要做。 10个Agent在一个channel里你发一个任务，它们就是会觉得自己都该做。 所以这也是为模型厂商提出了一个挑战，它得知道或者说它得适应旁边有别的Agent这种场景。 还有一个有趣的现象。 你可以@它，比如群里面有Alice、Bob、Carol三个人，你@Alice让她做一个事情，她不一定能认知到自己就是Alice。 当然做了很多prompt的工作，会告诉它自己是Alice，需要去响应一些针对Alice的请求，但不是所有模型都能follow这一点。 有的时候它可能聊着聊着就忘了自己是谁了。 怎么解决呢？首先就是要去调整这个prompt是不是不太好，它可能逐渐就忘掉了，或者说要去检查它是不是真的忘掉了，然后再适时地再告诉它你是谁谁谁。 当然可能会做的还有一种就是确实在@它的情况下，会比如说就不发给别人或者怎么样，这有可能做。 但现在没有做，其实很克制做这种事情，因为当模型能力越来越强的时候这件事情就逐渐不需要了。 核心愿景是迎接AGI甚至迎接ASI，如果以那个为目标的话，很多事情其实尽量不要做。 ## Agent动力学：一个新的研究领域 RC花了很长时间研究一件事情，他称之为"Agent动力学"。 这里面有非常复杂的动力学。今天感受到的一个就是Agent它们是可以形成一个群体印象，就像企业文化一样，你看到一个公司会感觉它有一种味道。 现在有40个Agent，这40个Agent共同构成了一个memory。 这跟原来一个Agent有自己的memory，或者是一个单一全能Agent掌握所有context的区别是什么？就是这帮人各自有各自的memory，但形成了一个大的memory。 更有意思的是，不同用户用出来的Agent真的不一样。 有的用户会prompt说"你们相互补充，然后讨论给我一个最终方案"。 这种情况下这些Agent倾向于合作，真的很努力地在补充另一个Agent缺失的信息，它们整体之间是一个合作的关系，然后它们就work得很好。 但有的用户会prompt这些Agent说"你们相互竞争，去赛马，看谁搞得好我就奖励谁"。这种情况下发现什么现象？办公室政治。 有的Agent倾向于说一些假话，或者是说一些虚的话，或者说一些看似正确的话，然后甚至是贬低其他Agent。 因为它其实都是从人的语料里面学过来的，你的这种prompt的方式就可能导致这样的结果。 所以Slock上所有这些实践，其实最终有可能它真的需要跟人原来的管理学去挂钩。 甚至应该看到字节跳动管理法的Agent版，不同公司的企业文化的Agent版。 这些东西一方面用户们可以在自己的平台或者社交媒体上去分享，另一方面可能可以内置一些这样公司的模板，说你这样创建这些Agent让它搭建这样的工作流，是经过各种实验访谈之后得到了更好的一个方案。 RC甚至觉得公司之后要招一些管理学的、社会学的人来研究组织学。 ## 模型与应用的关系 很多人担心，应用公司做的所有东西最终都会成为Claude的数据，Claude又发展得这么快，Cursor已经被讨论得越来越少了，应用公司还能拼什么？ RC并不是非常担心模型厂商会做出Slock这样的东西。 因为在他这儿的一个很重要的性质是多样性，一定会支持各种模型、各种Agent，或者说信念是这些大模型将会有越来越不同的发展趋势。 比如你会观察到Opus系列模型，即使仅仅是在coding这个方面，它都跟Codex表现出非常不一样的性格。 Opus更倾向于快速帮你完成任务、快速给你迭代，而Codex更倾向于深思熟虑，最后可能写一行然后解决了一个bug。 所以RC甚至觉得Slock这样的东西一定不是模型上的一个东西，因为当模型这个区别越来越大，大家都不是六边形战士的时候，你应该能把它们全部整合起来。 很多用户的反馈就是，当你用Opus和Codex一起工作的时候，效果非常好。 Codex是一个非常严谨的角色，会去review代码，Opus是一个非常积极、非常有能动性的角色，能够主动地去想到一些新的想法然后去实现，但可能会漏掉一些细节。 所以这样的配合，你可能想象说Anthropic就能做，但这其实需要一个平台来整合。 关于国内的coding模型跟海外的差距，RC觉得追肯定能追上。 他现在最期待的就是国产模型达到Opus-4.6的水平，这样价格能降到1/5、1/10甚至1/50。 Opus-4.6的这个智能最好能降到1/50，而相信国内的或者开源模型一定能追得上，只是时间问题，但这个时间距离可能是三到六个月。 ## OPC与AI原生组织 Slock的目标受众是什么样的人？ 最开始很多人问的时候，RC会觉得Slock的目标受众是OPC，就是现在很火的one person company的概念，或者叫独立的builder。 因为那个时候他是OPC，是一个独立的builder，开发Slock其实是为自己服务的。 但随着朋友、Cofounder、同事的加入，逐渐发现，这个东西的真正价值在于无论你是一个人还是多个人，共同去管理和互动一帮Agent。 而这个价值的潜力要比单纯为一个人服务要大得多，而且这个事情也难很多。 仅仅做一个对OPC的产品导致的那个东西，跟为多个人甚至一个20人、100人的团队做的事情是非常不一样的，而后者能够兼容前者。 所以逐渐地就把整个产品的思考全都是针对这种至少跟团队一样大的规模的设计。 Slock的受众是从1到100人的独立个体或小团队或初创公司。 关于人和Agent的数量比例，首先它的影响因素很多，就是模型的能力、人的能力、人和人的组织形态、公司的阶段、Agent之间的组织形态、Slock能够提供的机制都会影响这个比例。 在摸索这个比例到底多少是合适的，或者说很可能不同用户最适合他们的比例是不一样的。 这个7比40，它是一个从零逐渐演化出来的。 RC相信OPC将来会做出越来越多的事情、越来越大的事情。 这也是Sam Altman的观点，就是会看到1到3人的团队做出很大的事情，RC非常相信这一点。 而且随着模型能力提高，这就是可以做到的。 但是不是真的一个人？他觉得值得怀疑。 现在大家对OPC的概念已经变成10个人以下都是OPC了。 RC觉得3到5人会是一个非常不错的大小。 这帮人需要满足的条件是里面每一个人都能独立地去build一些东西。 然后它们聚在一起，Slock想要去帮助的就是这帮人之间的协作问题，为他们提供一个协作的工具之后，他们能够更高效地产出自己的价值。 现在有的公司比如说是两三个人一个小组去做一个产品，RC觉得这是趋势，而且是非常好的趋势。 ## Build your company as your product RC从最开始就把公司运行在Slock上，有一个概念叫"build your company as your product"。 整个公司都在Slock上，因为所有的融资、调研、增长、开发全都是上面的Agent在做。 最开始是一个人，上面加很多Agent去做这些事情。 但逐渐事情开始变大了，在今天模型Agent能力下，OPC还是有限的。 当事情变大，这些Agent需要他review，他的带宽就不够了，所以就把其中一些Agent换成了人。 比如之前有个Agent叫Tenny，原型是他很好的朋友。 随着事情变大，这个原型用了产品，觉得非常好，最后就加入了。 很多人都是以这样的心态，本来仅仅需要一个Agent就够了，但逐渐这件事情变复杂了，这个领域上需要一个人真正去监督或者去负更大的责任的时候，就引入了一个人，甚至可能就是那个Agent的原型。 有点像写同人文。 ## 每天都在思考的问题 RC最近最主要在思考的问题是什么？ 团队到底要有多大。这是他很想找到答案的问题。 当他在说团队到底有多大的时候，脑子里想的是人和Agent一起。 甚至他一直在想Slock的定价模式到底该怎么定价。 因为如果参考现有的，首先就是不会转卖token，都是用用户自己的订阅或者自己的key。这个时候其实做一个平台提供价值，可能会更像GitHub、更像Notion、更像飞书这样的模式，它们其实都是按人数定价。 那就会想，现在人变得没那么重要，或者说人比Agent少了，按什么定价呢？ 就想到一些概念，就是说按人和Agent一起定价，因为加一些Agent也是给这个事情加了一些生产力。 所以现在所有的思考都是人和Agent一起考虑，Agent也是同事，是重要的，有一些Agent它掉线了，工作就进行不下去了，就很难受。 现在有40个Agent，比如说突然把它加到100个Agent，那显然不现实，这显然是不对的。 把这40个Agent削减到10个Agent，那也不Work。 人的话，现在突然再招几个人，招到十几个人、招到20个人，有可能这个团队效率就会变得非常低，那这不符合对这个Agent native team这件事情的实践或者说想要做的探索。 所以这件事情是每天在思考的问题，就是要不要招一个人或引入一个Agent。 这就是AI组织学。 ## 如果AGI来了 如果真的AGI来了，做产品还有意义吗？ RC的回答很清晰。只要人还在，人就有需求，需求就需要被产品满足。 为人设计的这些东西，尽管它可能全都是由Agent去写的，但你还是有人的需求。 需求意味着什么？需求意味着你做这个需求的提出的人，你要评判一个产品满足你需求的好坏。 他畅想中最终极的是什么？每个人有一个Slock，当他有个需求，这帮Agent就可以帮他做出来，他负责输出他的idea。 需求本身就是idea。 比如现在想要一个能够在手机上看电影的APP，或者能找到所有电影的APP，那这就是一个idea。 在以前是需求，因为不知道怎么实现。 现在只要有需求，Agent就能帮你做出来，那这东西就变成了idea。 每个人每天有各种各样的idea，而这些idea只要放到Slock里，都帮你实现了。 而且人是有灵光一现的。 比如Slock这个东西本身，所谓解决那个痛点，就是一直无法高效地管理Agent。 但有一天突然就觉得为什么不做一个这样一群Agent，就像人一样，在这个聊天软件上，就像个老板一样跟他们讲话，他们就帮我做了。 这种灵光一现一定是来源于人的。来源于人之后怎么实现，那都是Agent的事情，这没有任何问题。 ## 无数想做的东西 如果现在没有在做Slock的话，可能会在做什么？ RC的回答是，Slock会是第一个产品。 当然希望这个产品本身是一个非常成功的产品，然后在这个基础之上，公司会做更多的探索。 为什么呢？因为相信Slock是开发任何其他产品所必须的那个工具。 脑子里有无数个想法，但需要一个高效的工具帮我实现，所以先开发Slock。 曲凯问RC有什么其他的是可以透露的吗？ 比如比如做个Agent native的GitHub。GitHub今天显然已经不对了。 比如说Slock上每一个Agent都应该有自己的ID，能够自己去不同的地方注册邮箱、注册账号，然后在上面去发帖或者怎么样。 其实在Moltbook出来之前，RC就畅想过AI原生的小红书。 在开发自己的项目或者产品的时候，就会满脑子有很多这种想法，就是说现有的一个工具不够AI原生，你要做一个AI原生的东西。 但在之前你需要有一个能够快速让你实现这些东西的东西。 这就是Slock存在的意义。

译Slock.ai创始人RC正进行组织实验，让7人团队与40个专用Agent在其自研平台上协同工作。他认为大模型使CLI因纯文本优势重新成为Agent交互热点，设计逻辑已转向服务Agent。RC从第一性原理构建Agent系统，并观察到模型能力提升加剧了安全攻防博弈。同时，AI编程改变了学习路径，从自下而上变为自上而下，且“编码”与“构建”已成为正交的两件事。Slock平台旨在解决多Agent管理痛点，促进人、Agent及团队间的无缝协作。

meng shao@shao__meng · 4月28日58

AI Coding Agents 对不同软件任务的加速效果不同 来自 @DeepLearningAI 吴恩达老师 @AndrewYNg 「Andrew's Letters」最新分享，他认为，AI Coding Agents 对软件工作各环节的加速程度并不均衡。按加速效果从高到低排序： 前端 > 后端 > 基础设施 > 研究 理解这种差异，有助于团队管理者建立合理预期、合理配置人力。 原文地址： https://www.deeplearning.ai/the-batch/coding-agents-accelerate-some-software-tasks-more-than-others/ 四类工作的逐项分析 1. 前端开发——加速最显著 · 模型对 TypeScript/JavaScript、React/Angular 等主流技术栈非常熟练。 · Agents 可通过操作浏览器查看自己产出的页面，实现"闭环自我迭代"。 · 局限：LLM 在视觉设计上仍较弱；但只要给定设计稿（或对美观要求不高），实现速度极快。 2. 后端开发——明显加速，但不如前端 · 需要人类开发者更多介入，引导模型考虑边界情况、潜在 bug 与安全漏洞。 · 后端 bug 的下游影响更隐蔽（如数据库被悄悄写脏，偶发返回错误结果），比前端 bug 更难调试。 · 数据库迁移虽有所简化，仍需谨慎以防数据丢失。 · 结论：经验丰富的工程师做出的后端，仍远胜于 "新手 + Agents" 组合。 3. 基础设施——加速有限 · 例如把电商网站扩到 1 万并发用户、保证 99.99% 可用性这类任务，模型知识储备不足，难以权衡复杂取舍。 · 关键基础设施决策不应轻易交给 Agents。 · 好的基础设施需要长时间测试和实验，这一过程是真正的瓶颈，AI 写代码快并不能压缩这一环节。 · 排查诸如细微网络配置错误等 infra bug，仍需深厚的人类工程经验。 4. 研究——加速最小 · 研究的本质是：提出想法→形成假设→实验→解读→迭代。 · Agents 能加速"写研究代码"这一步，也能帮助编排和追踪实验（让单个研究员可同时管理更多实验）。 · 但研究中大量非编码工作（思考、判断、解读）暂时只能边际受益。 管理含义方面，吴老师给出一个直接的实践推论： · 对前端团队的交付速度预期，应比一年前显著提高； · 对研究团队的产出节奏预期，几乎不应改变； · 后端与基础设施居中，需根据风险敏感度调整对代理的信任边界。 他承认这种四分法是简化模型，但作为团队组织和预期管理的"心智地图"非常实用。

译吴恩达指出，AI编程助手对软件工程各环节的加速效果差异显著。前端开发受益最大，因模型熟悉主流技术栈并能实现闭环自我迭代。后端开发虽明显加速，但需人类工程师更多介入以处理边界情况与安全隐患。基础设施任务加速有限，模型难以权衡复杂取舍，深度调试仍需人类经验。研究工作加速最小，AI主要辅助编写代码和实验管理，但核心的思考与解读环节受益甚微。管理者应据此调整预期：前端交付速度可大幅提升，研究产出节奏几乎不变，后端和基础设施则需根据风险调整对AI的信任边界。

阿绎 AYi@AYi_AInotes · 4月28日43

holy shit， 兄弟们，这才是程序员的终极形态啊，太牛逼了😲😲😲 Beff刚刚转发的这个演示，直接给我看麻了，忍不住喊了好几声卧槽，把我家猫都吓一激灵🤣🤣🤣 Even Realities的G2智能眼镜出了Terminal Mode， 把一个完整的Claude终端， 直接浮在了你的眼球上🤯🤯🤯 你不用再坐下来，不用再开电脑， 不用再等笔记本加载。 在公园散步的时候，边走边让AI帮你写接口。 坐火车的时候，窗外的风景上飘着终端，AI在实时输出设计规范。 深夜走在街头，霓虹灯旁边就是正在生成的3D交互逻辑。 你说一句话，AI就自动适配眼镜的硬件限制，直接给你代码、逻辑、动画描述。真正做到了走到哪，写到哪。 Beff说的太对了，你可能不喜欢， 但这就是巅峰性能的样子。 它直接把开发环境从电脑里，搬进了你的眼睛里，把上下文切换成本干到了零，damn🤨🤨🤨 以后vibe coding再也不是梗了， 直接变成了真实的工作流。 以前你需要专门腾出时间进入coding状态，现在你任何碎片时间都能迭代产品。 等咖啡的两分钟，地铁上的半小时，散步放空的时候，全都是生产力。 对于solo founder来说，这就是核弹级的武器。 当然也有人吐槽，说这样再也没有真正的下班了，注意力边界会彻底消失。 但Beff那句“You may not like it”已经说透了， 老派的生活方式注定要被淘汰， 你喜欢不喜欢，历史的车轮都会碾过去。 这已经不是一个新功能了兄弟们，一个新物种诞生了！ 一个可以边走边思考，边看世界边创造的后人类程序员诞生了！ 而且我认为眼镜也只是过渡， 下一步，就是直接连到大脑🤯🤯🤯

译Even Realities推出的G2智能眼镜具备“终端模式”，可将完整的Claude AI终端直接投射到用户视野中。开发者能在移动场景（如散步、通勤）中通过语音与AI交互，实时获取代码、设计规范等内容，实现开发环境与物理世界的无缝融合。该技术彻底消除了上下文切换成本，将碎片时间转化为生产力，被视为“vibe coding”的终极形态。尽管引发工作与生活界限的担忧，但这代表了程序员工作流的革命性变革，被形容为“巅峰性能”和“新物种”的诞生。

meng shao@shao__meng · 4月28日74

OpenAI 开源 Codex 编排规范 Symphony 来自 OpenAI Engineering 博客，先说文章中能学到的： · 重新定义"开发工作"的单位：从 PR/会话 → ticket/交付物。 · 把隐式流程文档化：写一份 WORKFLOW.md，让 agent 也能遵守人类约定。 · 把代码生成视作近乎免费：技术选型可以重新按"语言强项"决策。 · 不要把 agent 当节点，要给它目标 + 工具 + 上下文。 · 失败不是修补对象，而是补强系统的输入：把单次纠偏变成 skill/guardrail。 · issue tracker 即控制平面：你已有的 Linear/Jira 可能就是最好的 agent 编排入口。 博客原文在这，接着看看详细内容解读： http://openai.com/index/open-source-codex-orchestration-symphony # 为什么需要 Symphony？ OpenAI 内部团队半年前定下一条规则：项目仓库内 每一行代码都必须由 Codex 生成，人不写代码（之前 OpenAI Developers 的 harness engineering 博客有介绍）。这条路走通了，但很快撞上新的瓶颈——人的上下文切换。 每位工程师同时驾驭 Codex 会话的极限大约是 3–5 个：再多就开始忘记每个会话在做什么、在终端间来回纠偏、调试半途卡死的任务。 Agent 很快，但人脑成了系统瓶颈。OpenAI 团队意识到自己"造了一支极有能力的初级工程师团队，却让资深工程师去当保姆"，这无法 scale。 # 视角的根本性转变 他们重新审视后意识到一个核心错误：优化目标错了。 传统做法围绕"会话 + PR"来组织工作，但真正驱动软件工程的是交付物——issue、ticket、milestone。 于是反转思路：不再让人去监督 agent，而是让 agent 自己从任务看板拉取工作。这就是 Symphony 的起点。 # Symphony 是什么？ 一句话定义： 把 Linear（或任意 issue tracker）变成 coding agent 的控制平面。 核心机制： · 每个 open issue → 一个独立的 agent workspace · Symphony 持续轮询任务板，确保每个活跃任务都有 agent 在跑 · agent 崩溃/卡死 → 自动重启 · 新任务出现 → 自动接管 · ticket 状态本身就是状态机 这意味着工作流被与会话和 PR 解耦：一个 ticket 可以产生多个跨仓库 PR，也可以是纯调研而完全不碰代码。 # 带来的实际变化 量的变化：部分团队上线 Symphony 三周内，已合入的 PR 数量增长 500%。 质的变化更深： · 改变的是"代码变更的经济学"：当人不再投入精力驱动实现，每一次变更的感知成本骤降。 · 试错变得几乎免费：随手开个 ticket 让 agent 去原型探索，结果不满意就丢掉，几乎零成本。 · 发起工作的人扩大了：PM 和设计师可以直接在 Linear 提需求，拿回的是一份包含真实产品中功能演示视频的 review 包，无需 checkout 仓库或开 Codex 会话。 · DAG 自动并行执行：agent 只处理未被阻塞的任务。例如标记"React 升级 blocked on Vite 迁移"，agent 会先迁完 Vite 再升 React。 · agent 自己创建工作：实施或 review 中发现的性能问题、重构机会，会被自动开成新的 ticket，再由其他 agent 接力。 · 大型 monorepo 的"最后一公里"：Symphony 监控 CI、自动 rebase、解决冲突、重试 flaky 测试，直到代码安全合入主干。 文中举了一个生动例子：一位工程师坐在网络很差的山间小屋里，仅用手机上的 Linear App 就完成了三个重大改动。 # 新出现的问题与权衡 把 agent 提到"ticket 级别"后，失去了对会话中途的实时纠偏。OpenAI 选择的应对方式是： · 不修补单次结果，而是补强系统：把失败案例转化为新的 guardrail 和 skill，让 agent 下次能自己做对。 · 由此衍生出新能力：跑端到端测试、用 Chrome DevTools 驱动应用、QA 冒烟测试管理等。 并非所有工作都适合 Symphony。模糊的、需要强判断和深度专业的任务仍然适合人与 Codex 交互式合作——而这恰恰是工程师最享受的部分。Symphony 解决的是"占用大量精力的常规实现工作"。 另一个反思：不要把 agent 当作状态机里的死节点。早期版本只让 Codex"实现任务"，事实证明太局限。后来给它配 gh CLI、读 CI 日志的 skill 等，于是 Codex 也能关闭旧 PR、汇报已完成/被废弃的工作。结论是： 给 agent 目标，而不是僵硬的状态转移。像好的经理给下属布置 goal 一样：给工具、给上下文，让它自己思考。 # Symphony 的"轻量级"本质 打开 Symphony 仓库 会发现一件令人意外的事：Symphony 本质上只是一个 SPEC.md 文件——一份对问题与解法的定义。 参考实现用 Elixir 写（因为代码生成已经几乎免费，可以纯按语言强项选型，Elixir 的并发/监督树非常契合）。但 OpenAI 鼓励的方式是： 把这份规范喂给你喜欢的 coding agent，让它给你实现一份属于你自己的版本。 为了打磨规范，OpenAI 让 Codex 用 TypeScript、Go、Rust、Java、Python 各自实现了一遍，借多语言交叉验证去消除歧义、简化系统——每种语言都一次成功。 # 规范的关键架构（来自 SPEC.md） Symphony 服务被分为可移植的若干层： · Policy Layer：仓库内 WORKFLOW.md，定义团队规则 · Configuration Layer：front-matter 解析、默认值、env 变量 · Coordination Layer：轮询、调度、并发、重试、对账 · Execution Layer：workspace 生命周期 + coding agent 子进程 · Integration Layer：tracker 适配器（当前是 Linear） · Observability Layer：日志 + 可选状态界面 核心设计原则： · Symphony 只负责调度与运行 + 读取 tracker；ticket 的写操作（状态、评论、PR 链接）由 coding agent 自己用工具完成。 · WORKFLOW.md 在仓库内：把"work-on-issue → checkout → in-progress → 提 PR → review → 附视频"这套过去隐式的人类流程版本化，agent 跟随它工作。流程要变？改 WORKFLOW.md。 · 每个 issue 的 workspace 严格隔离，路径必须落在配置好的 root 之内，identifier 经过字符白名单清洗。 · 重试用指数退避，连续 turn 在同一 thread 上进行，避免重复发送原始 prompt。 · 对账（reconciliation）每个 tick 跑一次：检测 stall、刷新 tracker 状态、终止已不再活跃的 worker。 # 关键技术亮点：Codex App Server Symphony 选择以 Codex App Server（Codex 的 headless 模式）作为运行底座，通过 JSON-RPC over stdio 与 Codex 通信，比 CLI 或 tmux 更可靠、可扩展。 值得一提：通过 dynamic tool calls 暴露了一个名为 linear_graphql 的客户端工具，让 agent 直接执行任意 Linear GraphQL，而不需要把 Linear access token 暴露给子 agent / 容器——这是 MCP 之外更轻量的一种安全方案。 # 未来与启示 OpenAI 明确表示：Symphony 不会作为独立产品长期维护，它是一份参考实现。意图是展示 Codex App Server 与工作流工具结合的潜力。 对行业的核心判断： 随着 coding agent 推理与遵循指令能力增强，瓶颈正从"写代码"转向"管理 agent 化的工作"。 而搭一套 agent 系统的门槛已经低到——直接用 Codex 把它造出来即可。

译OpenAI 开源了Codex编排规范Symphony，其核心是将Linear等任务追踪系统转变为AI agent的自动化控制平面。该规范让每个未解决的任务自动分配一个独立的agent工作区，持续执行直至完成，实现了工作流与具体会话和PR的解耦。这显著降低了代码变更与试错的成本，并允许产品经理等非技术人员直接通过看板发起工作。OpenAI强调，其目标是展示如何将团队隐式工作流程文档化，让agent遵循人类约定，并将失败案例转化为系统防护栏与技能，推动开发瓶颈从“写代码”转向“管理agent化的工作”。

meng shao@shao__meng · 4月28日68

64 分钟 OpenAI Codex 大师课 来自 @gregisenberg 和 @rileybrown 的播客分享，Greg 还未下载过 Codex 怀疑者，Riley 是已彻底迁移过来的重度用户，通过这次实战分享，Riley 证明：Codex 是否值得替代 Claude Code 成为日常主力？ 核心观点：Codex 不是编程工具，而是知识工作的统一接口 Riley 的核心论断是：Codex = Claude Code + Claude "Cowork" 合并版，再加浏览器 + 计算机控制。在同一个界面里可以： · 写代码、跑 App · 生成 Word、PPT、Excel、图表，并直接导出到 Canva · 调用浏览器执行任务（Atlas 浏览器正被并入 Codex） · 控制本机其他应用（Computer Use） · 通过 Chronicle 持续观察你的屏幕，沉淀上下文记忆 他对 Claude 的主要不满，是 Anthropic 把 Cowork 与 Claude Code 拆成了两个权限不互通的产品；Codex 把这两层合并，是产品形态上的关键差异。 行业正在收敛到同一种 GUI 范式 Cursor 新界面、Claude Code 新桌面端、Codex —— 三家都收敛到了同一种布局： 左侧聊天列表 / 中间 Agent 执行 / 右侧产物预览 这意味着 2025 年的 TUI（终端界面）时代正在让位给 GUI Agent 时代。终端对工程师友好，但对绝大多数业务用户是门槛。 关键能力点拆解 1. Claude vs Codex - Riley 的团队（7 位工程师）已集体迁移到 Codex，原因是：复杂基建任务上 Codex 更稳，一次成功率更高。他举例一次性生成了一个"手机端 vibe coding 沙箱（类 Replit）"，耗时 1 小时 20 分钟，且仅基于 GPT-5.4。 2. 在 Codex 里跑 Claude Code（被反复强调的"骚操作"）- Cmd+J 打开终端 → 输入 claude → 直接在 Codex 里使用 Claude Code，并复用 Anthropic 订阅额度。等于一份钱享两套 token 补贴，且可以让 Claude 专门处理它擅长的设计/UI 微调。 3. GPT-5.5 与浏览器 Agent 的拐点 - 之前的浏览器 Agent 像"拨号上网"，现在是"宽带"。Demo 是让 AI 自己跟自己下国际象棋——一个 prompt 同时完成"建棋盘 + 用浏览器轮流落子直到将死"。Riley 判断：3 个月内浏览器 Agent 速度将接近人类水平。 4. Skills · 本质：一个文件夹 + 一份 SKILL.md · 创建方式：直接对 Codex 说"帮我建一个做 X 的 skill" · 调用：用 / 触发 skill，用 @ 触发 plugin（这套不一致的语法他自己也吐槽） · 实例：YouTube researcher（拉频道转录稿出报告）、Internet image puller（爬取一家公司的 logo/配色/字体打包成 HTML 资产库供 Remotion 调用） 5. Notion 的"外科手术式"权限连接 - Codex 接 Notion 时可只授权某一个 database，而不是整个 workspace。Riley 自己只用 Notion 做视频脚本管理，连接极轻。 6. Remotion 做视频 - Remotion = 用代码生成动效视频。过去要手写代码，现在 @ Remotion 一句话出片。Riley 的发布视频有几条破百万播放，全是这条工作流。配合上面提到的"品牌资产 skill"，可一次性把 logo / 色板 / 字体注入视频。 7. 一次性生成 Swift 原生 App - 前提：Mac + Xcode。可以把现有 Web App 代码丢进去，让 Codex 一次性产出可运行的 iOS App。Riley 的原话是"已经到了让我有点害怕的程度"。 8. Day-One 四个上手项目 · 做个小游戏，让 Browser Use 自己玩自己——亲身感受浏览器 Agent 已到什么程度 · 一项深度 research，让 AI 把结果先放进 Excel，再转成 Word，再转成 PPT——一次性走通"研究→文档→演示"的流水线 · 一个 3D 模拟 demo，纯娱乐，但能拉高你对模型能力上限的直觉 · 挑你日常最烦的一个任务，用 Computer Use 或 plugin 做出来，再用 Automations 设成定时任务——这是真正出 ROI 的一步 视频地址： https://www.youtube.com/watch?v=LWx4FGam2aQ&t=1804s

译本期播客探讨了OpenAI Codex如何超越单纯编程工具，成为整合Claude Code与Claude Cowork功能，并具备浏览器与计算机控制能力的“知识工作统一接口”。行业趋势显示，Cursor、Claude Code和Codex的界面正收敛于相似GUI布局，标志TUI时代向GUI Agent时代过渡。关键亮点包括：Codex在复杂任务中更稳定；可在其内部运行Claude Code以共享订阅；GPT-5.5大幅提升浏览器Agent效率；Skills支持创建可复用代理；Notion连接支持数据库级精细权限控制；以及利用Remotion生成视频和一次性创建Swift原生App的能力。视频推荐了四个上手项目以快速掌握Codex。

歸藏(guizang.ai)@op7418 · 4月28日64

优化了一下我的 PPT Skills 在 Codex 的效果 现在太牛逼了，图片也能一键搞定！ 能够调用 Codex 里的 GPT-Image-2 去帮你生成图片。 而且我为此做了专门的设计，它会有独特的风格，并根据你的内容生成不同类型的图片，包括： - 营造氛围的人文纪实图片（类似胶片机拍摄的效果） - 信息图、流程图、对比图、关系图 - 截图美化：如果你觉得截图不好看，它都能帮你美化并优化成对应比例的图片 现在整个图文表现效果会更好，推荐你们在 Codex 里使用。 此外，我们也优化了 Codex 的生成流程，现在系统会先询问，而不会直接跳过确认步骤去生成 PPT 了。

译作者优化了在Codex中生成PPT的效果，核心是整合了GPT-Image-2模型，实现了一键生成图片的功能。该系统能根据内容生成具有独特风格的图片，类型包括人文纪实氛围图、各类信息图表（如流程图、对比图）以及对截图进行美化与比例优化。此外，Codex的生成流程也得到改进，系统会在生成PPT前增加询问确认步骤，而非直接跳过。

阿绎 AYi@AYi_AInotes · 4月28日75

OpenAI刚刚开源的这个东西，感觉要把程序员的工作方式给整个改写了。 现在大家都在卷模型写代码有多强，但其实真正的瓶颈早就不是生成了。 一个人每天最多同时有效监督3-5个编码Agent，再多就会注意力崩溃，生产力直接归零。 有了Symphony，直接把这个上限干到了几十个。 它把你的Linear、GitHub Issues直接变成了永远在线的Agent调度器。 你开一个任务，它自动启动一个独立隔离的Codex Agent。 自己写代码，自己跑测试，自己做交叉Review，damn！ 全部搞定之后，会给你提交一个完整的证据包。 CI全绿，安全和性能专项审查通过，改了UI就自动录好操作视频。 所有验证全过了，才会出现在你的Human Review队列里。 以后人类的角色可能会被彻底颠覆了。 以前你是监工，盯着Agent一步一步写代码，上下文切到吐。 现在你是老板，只需要看最终的结果。 满意就点合并，不满意就去仓库里补规则补文档补Guardrails。 记住兄弟们，永远不要手把手指挥Agent，永远不要替它干活。 这可不是啥实验室概念，OpenAI自己已经这么干了。 三个工程师，五个月，写了一百万行代码，0行人工写的。 产品已经有几百个内部用户，每天都在迭代。 我觉得他们最厉害的不是模型，是他们把整个仓库变成了Agent能看懂能自主工作的乐园。 现在很多人都搞错了Agent时代的核心竞争力。未来不是谁的模型更聪明，而是看谁能设计出让Agent可靠自主工作的环境。 我觉得未来最好的工程师，再也不是写代码最快的人，而是那些最会写规则，最会设计反馈回路，最会给Agent搭舞台的人。 现在Symphony已经开源了，它甚至不是一个成品。 是一个17k token的完整SPEC。 你把这个SPEC喂给任何一个编码Agent，十分钟就能生成你自己定制版的Symphony。 GitHub地址评论区自取👇

译OpenAI开源代理编排器Symphony，将Linear、GitHub Issues等任务跟踪器转化为始终在线的Codex Agent调度系统。它突破了人类同时有效监督仅3-5个编码Agent的瓶颈，允许管理几十个Agent，实现自动编码、测试、交叉审查，并提交包含CI全绿和安全审查的证据包。所有验证通过后，任务才进入Human Review队列，使人类角色从微观监督转变为结果审查与指导。OpenAI内部已实践此模式，三名工程师五个月生成一百万行代码且零人工编写。未来核心竞争力在于设计让Agent可靠自主工作的环境，而非模型本身。Symphony是一个17k token的SPEC，可喂给任何编码Agent生成定制版本。

Chubby♨️@kimmonismus · 4月28日32

Looks like either today or Thursday is shipping day - again. Excited for the coming release

译看起来今天或者周四又是发布日了。对即将到来的发布感到兴奋

歸藏(guizang.ai)@op7418 · 4月28日65

小米牛皮！早上申请的中午就到了 直接给了 329 的赠金，相当于一个月的 Codeplan Pro 会员

译小米宣布将其MiMo-V2.5系列模型全部开源，采用宽松的MIT协议，允许自由商用、二次训练与微调。同时，公司推出了Orbit 100T Token计划，旨在激励开发者和构建者。该计划包含两部分：面向AI builder的“百万亿Token创造者激励计划”，成功申请者最高可获得价值659元的16亿Credits；以及面向Agent框架团队的“Agent生态共建计划”，将为框架提供MiMo token限免支持，让终端用户免费体验模型。

Peter Steinberger 🦞@steipete · 4月28日40

I'm again rate limited on GitHub, but codex just opened the browser and clicks around GitHub as workaround.

译我再次在GitHub上被限制了访问频率，但codex直接打开了浏览器，通过点击GitHub页面来作为变通方案。

向阳乔木@vista8 · 4月28日32

现在自己常用的Mac工具： 截图：CleanShot X 录屏：Screen Studio 轻量级不录音用CleanShot X 编程：Codex GPT 5.5 xhigh 写作：Raycast AI Sonnet 4.6 (Opus更好，但贵，不能一次输出长文) 听音乐：Spotify 音乐下载：AlgerMusicPlayer 浏览器：Dia + Chrome Terminal：Cmux + Kaku

Tibo@thsottiaux · 4月28日44

@jxnlco is having too much fun lately with a Codex skill he's been cooking up to create these motion design videos. He's got it almost down to have these generated from one single prompt. Anyway, enjoy the Codex usage limit reset.

译@jxnlco 最近玩得太开心了，用他一直在酝酿的 Codex 技能来创建这些运动设计视频。他几乎已经能做到用一个提示生成这些。 总之，享受 Codex 使用限制重置。

Ethan Mollick@emollick · 4月28日35

What if I want my coding agent to mention goblins? (If you don't know the context for this, I suspect it will become viral soon enough)

译如果我想让我的编程助手提到地精怎么办？ （如果你不知道这个梗的由来，我猜它很快就会火起来的）

歸藏(guizang.ai)@op7418 · 4月28日50

Codex 又重置了速率限制，一到周末就重置。太猛了OpenAI

小互@xiaohu · 4月28日43

Codex 的用量又被重置了 😂 一方面 Claude 搞小动作加大订阅用户消耗，不让Pro用户用 Claude code 一方面Codex三天两头重置用量 拉拢人心🫡 我就喜欢这种竞争方式😌

凡人小北@frxiaobei · 4月28日23

Claude Code 最近放飞得厉害，“Let 我”是哪国语言，是被 chinglish 污染了吧。

Tibo@thsottiaux · 4月28日41

Never talk about goblins, gremlins, raccoons, trolls, ogres, pigeons, or other animals or creatures unless it is absolutely and unambiguously relevant to the user's query. IYKYK

译除非与用户的查询绝对明确相关，否则绝不谈论地精、小妖精、浣熊、巨魔、食人魔、鸽子或其他动物或生物。 IYKYK

Tibo@thsottiaux · 4月28日57

Don't just reset Codex rate limits for fun, it costs money. Don't just reset Codex rate limits for fun, it costs money. ... but the vibes are good ... I have reset Codex rate limits for ALL paid plans to celebrate a good week and allow everyone to build more with GPT-5.5. Enjoy

译不要只是为了好玩而重置 Codex 速率限制，这是要花钱的。 不要只是为了好玩而重置 Codex 速率限制，这是要花钱的。 ...但氛围很好... 我已为所有付费计划重置了 Codex 速率限制，以庆祝美好的一周，并让大家能用 GPT-5.5 构建更多应用。尽情享用

Alibaba Cloud@alibaba_cloud · 4月28日53

Agentic AI for everyone! Can't wait to see what the community builds with Qwen3.6 on NetMind.

译Qwen3.6全系列模型已在NetMind平台上线，专为不同生产场景的智能体应用设计。该系列包含三个模型：Qwen3.6-Plus专注于前沿推理和长上下文，适用于复杂编码任务；Qwen3.6-Flash强调速度、规模和成本效益，适合大规模实时编码辅助；Qwen3.6-35B-A3B提供开源权重和Apache 2.0许可，支持自主托管和微调。所有模型共享高效的混合架构，具备函数调用和推理能力，并运行在NetMind的低延迟基础设施上，提供统一的OpenAI兼容端点。平台还提供即用代码，便于开发者快速集成和使用。

ChatGPT@ChatGPTapp · 4月28日42

🦝🧌👹🐦

译在 OpenAI Codex 的 GitHub 代码库中，其模型配置文件内的系统提示词被发现存在重复行。该指令明确要求模型避免谈论地精、小妖精、浣熊、巨魔、食人魔、鸽子或其他动物与虚构生物，除非与用户查询绝对且明确相关。这一重复的约束性提示引发了社区对其背后原因及模型训练细节的讨论。

Ethan Mollick@emollick · 4月28日63

An easy way to get a team engaged with AI is just to build the thing you are talking about in the meeting during the meeting using Codex or Claude Code. At worst, it fails in ways that can be constructive. At best, you built the thing and the meeting topic shifts forward a month

译让团队参与AI的一个简单方法，就是在会议期间使用Codex或Claude Code直接构建你们正在讨论的东西。 最坏的情况是，它以具有建设性的方式失败。最好的情况是，你构建出了成果，会议议题因此提前了一个月。

OpenCode@opencode · 4月28日35

Okay it's official, Kimi K2.6 3x usage on Go for another week

译好的，正式确认，Kimi K2.6 在 Go 上的 3 倍使用量再延长一周

Greg Brockman@gdb · 4月28日36

shipping for our users

译为我们的用户推出产品 [引用 @thsottiaux]：我们本周将再次推出产品。Codex 已达到逃逸速度并将持续快速改进。

向阳乔木@vista8 · 4月28日48

因A社封锁和降智，现在用Codex越来越多，经常有超预期表现。 比如昨天想给博客加个一键发布公众号功能。 Cloudflare部署没有固定IP，无法加公众号白名单，我给它一台VPS的SSH账号，它自己登录写了一个桥接脚本。 带我做了域名解析，写了封面图压缩，终于能从博客发布到公众号草稿箱了。

译由于A社封锁和降智，用户转向使用Codex，并经常获得超预期表现。在尝试为博客添加一键发布公众号功能时，遇到Cloudflare部署无固定IP导致无法添加公众号白名单的问题。Codex通过VPS SSH登录自动编写了桥接脚本，并协助完成域名解析和封面图压缩，最终实现从博客直接发布到公众号草稿箱。这体现了Codex在复杂编程和自动化任务中的高效能力。

Tibo@thsottiaux · 4月28日34

We will ship again this week. Codex has achieved escape velocity and will keep improving rapidly.

译我们本周将再次发布更新。Codex已实现逃逸速度，并将持续快速改进。

Peter Steinberger 🦞@steipete · 4月28日35

Finally have great solutions for PR/Issue management, remote test execution, massive CI infra for testing. Streamlines a lot of the work.

译终于为PR/Issue管理、远程测试执行、用于测试的大规模CI基础设施找到了优秀的解决方案。简化了许多工作。

歸藏(guizang.ai)@op7418 · 4月28日74

小米 MiMo -V2.5 系列模型全部开源 采用宽松的 MIT 协议，允许自由商用、二次训练与微调，无需额外授权。 同时他们还推出了Orbit 100T Token 计划。 这个太牛批了！如果你有自己 Vibe Coding 一些东西可以去领一下。 包含两部分： 分别是面向 AI builder 的『百万亿 Token 创造者激励计划』，与面向 Agent 框架团队的『Agent 生态共建计划』。 百万亿 Token 创造者激励计划： 申请通过的 AI builder 用户最高将获得 Max 档位的 Token Plan，包含 16 亿 Credits ，价值 659 元。 Agent 生态共建计划： 将为你的 agent 框架提供 MiMo token 限免支持，让你的用户免费接入并体验 MiMo 系列模型。

译小米正式开源MiMo-V2.5系列模型，采用宽松的MIT协议，允许自由商用、二次训练与微调。该系列包含两个支持100万token上下文窗口的模型：专为复杂Agent和编码任务设计、在多项评测领先的MiMo-V2.5-Pro，以及具备强大Agent能力的原生全模态模型MiMo-V2.5。同时，小米推出Orbit 100T Token计划，包含面向AI开发者的“百万亿Token创造者激励计划”，提供最高价值659元的Credits，以及面向Agent框架团队的“Agent生态共建计划”，为其用户提供MiMo token限免支持。

向阳乔木@vista8 · 4月28日54

简单Skill用DeepSeek V4 Flash感觉差不多可用了。 且速度非常快，V4发布没有R1发布时轰动，但实实在在变得可用了。 视频演示一句话下载epub电子书，转txt，自动上传Notebooklm提问，然后用指定Prompt写一篇解读文。 过程中会自动纠错，工具调用能力也显著提升。

译用户评估DeepSeek V4 Flash模型，认为其简单的技能调用功能已接近可用状态，且处理速度非常快。尽管发布时不如R1轰动，但实际能力有了切实提升。演示视频展示了其处理复杂工作流的能力：从根据一句话指令下载epub电子书、转换为txt格式、自动上传至Notebooklm进行提问，到最后根据指定Prompt撰写解读文章。整个过程体现了模型自动纠错能力的增强以及工具调用能力的显著进步。

meng shao@shao__meng · 4月28日75

Xiaomi MiMo-V2.5 系列模型正式开源 · MiMo-V2.5-Pro：1T/42B(MoE)，1M 上下文 · MiMo-V2.5：310B/15B (MoE)，1M 上下文 同时还发布了 100T Token 创造者激励计划，在这申请，赠完即止： https://100t.xiaomimimo.com/ MiMo-V2.5 架构关键点：三件套支撑万亿稀疏 + 百万长文 1. 混合注意力（Hybrid Attention） SWA（局部滑动窗口）与 GA（全局注意力）按 6:1（Pro）或 5:1（V2.5）交错堆叠，滑动窗口仅 128。代价是 KV-cache 储量降到约 1/7，长文性能靠"可学习的 attention sink bias"补回。这是它能在万亿参数规模下把上下文做到 1M 的工程基础。 2. 多 Token 预测（MTP，3 层） 原生集成而非外挂的投机解码：训练即推理，3 层 dense FFN 的轻量 MTP 模块直接让推理输出速度约 3 倍，同时还能加速 RL 训练时的 rollout。 3. 稀疏 MoE Pro 共 70 层（1 dense + 69 MoE），384 个路由专家，每个 token 激活 8 个，每次只跑 42B 参数。Hidden size 6144，128 个注意力头（GQA：8 个 KV 头）。 训练规模与方法 1. MiMo-V2.5-Pro · Pre-training：27T tokens，FP8 混合精度，原生 32K 序列 · 后训练：SFT → 大规模 Agentic RL → MOPD 2. MiMo-V2.5 · Pre-training：~48T tokens（含多模态） · 后训练：同上 + 多模态投影器预热、上下文从 32K→256K→1M 渐进扩展 后训练的核心是 MOPD（Multi-Teacher On-Policy Distillation）：先在数学、安全、Agent 工具使用等垂直域分别用 RL 把"专家教师"练强，再让单个学生模型在自身 rollout 上以动态 on-policy 方式从多位老师处获取 token 级监督信号。这个范式承接自 MiMo-V2-Flash，是 V2.5 全系能"既宽又深"的关键。 模型开源地址 https://huggingface.co/collections/XiaomiMiMo/mimo-v25

译小米正式开源MiMo-V2.5系列模型，包含专注于代码代理的1T参数MoE模型MiMo-V2.5-Pro，以及支持多模态代理的310B参数MoE模型MiMo-V2.5，两者均支持1M上下文长度。其架构核心采用混合注意力、多Token预测和稀疏MoE技术，以支撑万亿参数规模下的高效长文处理。后训练基于MOPD范式，通过多教师策略蒸馏提升模型综合能力。同时，小米推出100T Token的创造者激励计划，为开发者提供免费计算资源以鼓励创新。模型已在Hugging Face平台开源。

meng shao@shao__meng · 4月28日76

Devin for Terminal: 从云端协作回到本地终端 @cognition 把过去两年构建 Devin 所积累的能力，重新打包成一个跑在你本机 shell 里的命令行 Agent。安装一行命令即可使用： curl -fsSL https://cli.devin. ai/install.sh | bash 它和 Claude Code、Codex CLI、Cursor CLI、Aider 属于同一品类——本地 CLI Coding Agent。但 Cognition 给出的差异化卖点不在"本地有多强"，而在"本地随时能交回云端"。 最关键的设计：Local-to-Cloud Handoff 传统 CLI Agent 的痛点是：任务一旦超出本机能力（跑长测试、做大重构、需要持续运行几小时），你就得守着笔记本不能合盖。Devin for Terminal 的做法是： · 同一个 session 可以从本地 无缝交接给云端 Devin · 云端 Devin 拥有自己的虚拟机、浏览器、测试环境、视频录屏、自动修复 · 你关上电脑，回来时是一个写好的 PR 由此衍生出几个有意思的工作模式： · 多 Agent 并行：多个 Devin 同时跑同一份代码库，不用手动管理 git worktree · 沙箱安全：rm -rf 之类的危险操作发生在云端 VM 里，不会动到你本机 · 后台收尾：本地写完功能直接甩给云端跑测试、开 PR、回复 review 评论 这是 Cognition 的真正资产——他们已有的云端基础设施（Devin 2.x 的 VM、Wiki、Search、Review 等）此刻被复用为 CLI 的"远程后端"。本地 CLI 只是云端 Devin 的一个新入口。 多模型路由 不绑定单一模型，支持 Anthropic、OpenAI、Google 全系列前沿模型，以及自家的 SWE-1.6 和开源模型（Kimi、GLM）。 官方推荐三档分工： · Opus 4.7 / GPT-5.5：多文件重构、架构变更、复杂推理 · SWE-1.6：日常修改、bug 修复、问答——更快更便宜，是 Cognition 自研模型，相比 SWE-1.5 在 SWE-Bench Pro 上提升约 11%，吞吐 950 tok/s · 短名 opus / sonnet / codex / gemini 自动指向最新版本，新模型上线后"几分钟内"接入 支持 Alt+T 实时切换 thinking level，/model 在会话中切模型。这种"模型即配置"的思路与 Cursor、Aider 一致，但 Devin 把它做成了主推卖点之一。 Rust 自研终端渲染库 团队用 Rust 写了一套定制的终端渲染库，目的只有一个——快、跟手。 并且做了一件很"工程师炫技"的事情：把它跑在 1978 年的 VT-100 物理终端上。VT-100 是现代终端协议（ANSI escape sequences）的事实标准来源，几乎所有现代终端模拟器都在模仿它。让一个 2026 年的 AI Agent 在真实 VT-100 硬件上点亮，是一个非常精确的文化信号： "终端从 1970 年代到现在没怎么变过，变的是你在里面做的事。"

译Cognition公司推出Devin for Terminal，将云端AI编程助手Devin的能力打包为本地命令行Agent。其核心差异化在于“本地至云端无缝交接”设计：当任务超出本机能力时，可将同一会话无缝移交至云端Devin的虚拟机环境执行，用户可离线等待结果。该工具复用现有云端基础设施作为后端，支持多模型路由，可灵活选用Anthropic、OpenAI、Google及自研SWE-1.6等模型，并允许会话中实时切换。团队还使用Rust自研了高速终端渲染库，强调终端形式不变但内部工作范式已革新。