Ethan Mollick@emollick · 6月16日58

We are in the most comfortable "normal technology" phase of AI for enterprise: it enables productivity gains, but still needs integration into workflows - stuff we have seen before! Yet it is very possible that this is a waypoint, not a stable phase. AIs may integrate themselves

译我们正处于企业AI最舒适的“正常技术”阶段：它能提升生产力，但仍需整合到工作流程中——这是我们以前见过的！ 然而，这很可能只是一个中转站，而非稳定阶段。AI可能会自行整合。

jason@jxnlco · 6月16日51

Wow this is great. Going to make a mahjong game

译@majidmanzarpour 为 Codex 和 Claude Code 构建了一个基于 Three.js 的游戏导演技能系统，可引导 AI 智能体完成游戏循环、图形、HUD/UI、调试、QA 等流程，并可选集成 @tripoai、@ElevenLabs、@NanoBanana 的 3D/图像/音频资源。该系统已开源。Jason Liu 称赞并表示要用它做麻将游戏。

AYi@AYi_AInotes · 6月16日55

http://x.com/i/article/2066860172387995648 # 所有深度用 AI 编程的朋友，这篇 Codex 全景指南值得存好，架构生态横评和最佳实践一次讲透 有个细节我琢磨了好几天，OpenAI 给 GPT-5.3-Codex 下的官方定语很有意思，没有说是最强编程模型，而是一句有点耐人寻味的话——第一个对创造自身起到关键作用的模型。 我翻译一下：OpenAI 自己的工程师，已经在用 Codex 来造下一代 Codex 了。 我觉得这句话比任何 benchmark 都狠，它告诉我们，除了这个模型有多强，还有就是这个模型已经成了 OpenAI 自己的研发底盘。 也就是说2021 年那个被弃用的补全工具、去年那个帮你改 bug 的助手——跟现在这个比，根本不是一个物种。 我决定写一个系列，这是第一篇。 这篇不讲具体操作，先把全景图铺开：它的架构到底长什么样、核心能力在哪、跟 Claude Code / Cursor / Devin 比谁更能打、官方给的最佳实践有什么能直接抄。后面几篇再一个一个拆——AGENTS.md、Skills、MCP、多 Agent 编排的实操。 > ▸ 五个入口，一套配置——先搞懂这个，后面才不会晕 > ▸ 插件化 + MCP + Skills：这才是它跟别人拉开身位的地方 > ▸ 为什么我说它是目前最强执行引擎（附一张对比表，也说说它的软肋） > ▸ 七条能直接抄的官方最佳实践 ## 一、先搞懂架构——一套执行层，长了五张脸 我第一次把 2026 版 Codex 的所有入口捋了一遍之后，才明白为什么很多人刚接触会懵，因为它同时出现在五个地方：App、CLI、IDE 插件、Cloud、Web。 所以这不只是五个产品那么简单，更像是是一套统一执行层 + 编排中枢，长了五张脸。 Codex App：桌面命令中心，macOS 版，今年最大的形态变化。 定位很明确——AI 编程的指挥中心，你可以在里面并行跑活、管长时任务、加 skills 和 automations、审查 diff，全程沙箱保安全。 为什么今年才出桌面端？OpenAI 自己的解释我挺认同的——2025 年 4 月 Codex 刚出的时候，问题还是“agent 能干什么”； 到了今年，模型能端到端处理复杂长时任务了，问题变成了“怎么同时管好一堆 agent”。 那问题变了，界面就得跟着变。 CLI + IDE 插件： 终端和编辑器里的深度集成，这里有一个细节我踩过一次坑才注意到——它们共用同一份配置，在一个表面改了 config，另一个表面立刻生效，不用各配一遍 MCP，很细节的一件事，但挺省心的。 Cloud Sandbox：异步执行的核心。长时任务、并行工作全挂云上，不占你本地资源，跑完进审查队列。 Web / ChatGPT 集成： 统一登录，所有表面共享 Skills、MCP 配置、AGENTS.md 记忆。 模型底座 ：这条时间线值得看一眼，因为一年里迭代太密了： 2025 年 12 月 GPT-5.2-Codex → 2026 年 2 月 5 日 GPT-5.3-Codex → 2 月 12 日 GPT-5.3-Codex-Spark（纯文本、低延迟小号版） → 3 月 5 日 GPT-5.4 for Codex。其中 Spark 那步我特别想提一嘴——它是 OpenAI 第一个跑在 Cerebras 硬件上的生产模型，比早期 Codex 快 15 倍，专门为实时交互编码做的。这步棋的意义不是“更快了”，是“可以一边聊一边出代码了”。 把这五张脸看完，我的理解就一句话：Codex 把“模型”和“编排”分开了。 模型负责干活，App/Cloud 负责调度， 学 Codex，我理解本质上是在学怎么当一个管着好几个 agent 的项目经理。 ## 二、插件化 + MCP + Skills——这三层才是真正的分水岭 光看模型能力，Codex 跟别家在一个量级。 真正让它跟传统工具拉开差距的，是它长成了一个可扩展、可复用、可编排的平台层，三层东西撑起来的。 MCP：把外部世界接进来 配置不复杂。每个 MCP 服务器在配置文件里一张 [mcp_servers.<server-name>] 表，支持两种传输——本地 STDIO 进程，或者远程 Streamable HTTP（走 HTTP 连远程，可选 OAuth 和 bearer token 认证）。 CLI 一行加一个。比如接 Context7（免费开发者文档 MCP），跑这个就行：codex mcp add context7 -- npx -y @upstash/context7-mcp。配置文件默认 ~/.codex/config.toml，想限定到某个项目用项目级的 .codex/config.toml——但只限受信任项目。 热门的有 GitHub、Figma、Playwright、Context7、Sentry 这些。 有一点我想强调，官方隐含了一个最佳实践：高频痛点优先接，别把线全布上。 MCP 接得越多，上下文消耗越大，风险面也越宽。够用就行，别贪。 Skills：把重复劳动变成能复用的东西 一个 skill 就是把指令、资源和可选脚本打个包，让 Codex 可靠地跑一个工作流。Skills 基于开放的 agent skills 标准。 本质就是一个目录，核心文件是 SKILL.md。可以加 agents/openai.yaml 配 UI 元数据、调用策略、工具依赖。 Skill 和 AGENTS.md 的分工，官方说得很清楚，这条特别值得记：每次对话都要发给模型的指令，放 AGENTS.md；只在特定操作时才需要的指令，放 SKILL.md。这个分离能让上下文更聚焦。 Plugins：把上面这些打成一个能分发的包 今年新出的一层，Codex plugins 是可复用的包，把 skills、app 连接器和 MCP 服务器捆成一个可安装单元。 官方的思路是这样：Skills 是创作格式，Plugins 是安装分发单元。你先用 skill 设计工作流，稳定了，再打包成 plugin 给别人装。 Codex CLI v0.117.0（2026 年 3 月 26 日）把 plugins 提成了一等工作流原语，首发了 20 多个一方集成：Slack、Figma、Notion、Gmail、Google Drive、Cloudflare 等。注意是 20+，不是网上传的 90+——别被夸大的数字带偏了。 这三层叠起来，才是 Codex 区别于“一个聊天框”的本质：你能把团队的最佳实践固化成标准，一键分给所有人。 ## 三、为什么我说它是目前最强执行引擎——但也别神化 把 Codex 放到 Claude Code / Cursor / Devin 里横着看，它的优势我概括成五个词：云沙箱、异步委托、并行速度、生产力工具集成、审查执行分离。 到这里你可能觉得我要开始吹 Codex 全面碾压了。 其实并不会，我得先泼点冷水，因为这篇不是软文，是干货。 Codex 还不是全面碾压，几件事得说清楚： 第一，SWE-Bench Pro 上它只是微弱领先 GPT-5.3-Codex 在 SWE-Bench Pro Public 上 56.8%，对比 5.2 的 56.4%——是守住了顶尖梯队，不是阶跃。真正大涨的是终端任务和电脑操作：新模型在 OSWorld-Verified 上几乎翻倍，SWE-Bench Pro 和 Terminal-Bench 都刷了新高。OSWorld 上人类水平大约 72%，它跑到 64.7%，已经很接近人了。 第二，对手没闲着 Anthropic 今年 3 月 24 日上了 macOS 桌面控制，OpenAI 三周后的 4 月 16 日才跟进。更值得注意的——4 月 14 日，OpenAI 发布前两天，Anthropic 抢先发了重新设计的 Claude Code 桌面 app，带并行会话和能通过 API 或 GitHub 事件触发的自动化 Routines。Claude Code 在 Opus 4.6 beta 上那 100 万 token 上下文窗口，在大型代码库推理和多文件重构上是实打实的优势。 所以我自己琢磨下来的判断是：Codex 最强的不是“想”，是“干”和“并行调度”。 它是目前最强的执行与异步编排引擎，但深度推理和超大上下文重构，Claude Code 仍有一手，最佳实践其实是混着用的，这点我会放到系列后面专门写一篇。 ## 四、能直接抄的七条官方最佳实践 这部分含金量最高，全部来自 OpenAI 官方 best practices，我挑出七条能立刻上手的。 官方对 Codex 的定位有一句话，先记住：把 Codex 当成一个需要长期配置和打磨的队友，不是一个一次性助手。 1. Prompt 结构盯住四个东西： Goal（目标）+ Context（上下文）+ Constraints（约束）+ Done-when（完成标准）。复杂任务先开 plan mode。 2. 用 AGENTS.md 固化“持久指令” 官方的思路很清楚：从正确的任务上下文开始，用 AGENTS.md 做持久指引，配 Codex 匹配你的工作流，MCP 连外部系统，重复工作变 skills，稳定工作流自动化。支持层级覆盖——全局放 ~/.codex/AGENTS.md，项目从根目录开始，越靠近当前目录优先级越高。 3. AGENTS.md 保持精简 这是新手最容易踩的坑。Codex 会把整个 AGENTS.md 加载进会话上下文，多余信息既浪费 token，又干扰结果。还有个反直觉的点：运行中改了 AGENTS.md，要重启或开新会话才会生效。 4. 别迷信自然语言约束 官方自己也很坦诚：这是自然语言，模型很擅长理解你的要求，但不保证一定遵守。要更硬的控制，用 config.toml、rules、sandboxing 和审批设置。社区实测也印证了——光靠 AGENTS.md 指令遵守率只有 25-40%，做成运行时 hook 强制执行能到 95%。真正危险的操作——生产部署、删库、改凭证——别指望 prompt，用 execpolicy 和沙箱权限从根上锁死。 5. 永远要求验证 让它写测试、跑 lint、用 /review。官方提了一个团队级的好模式：如果你和团队有 code_review.md 文件，在 AGENTS.md 里引用它，Codex 审查时也能照着那套指引走。 6. 推理档位别无脑拉满 官方推荐 medium 作为平衡智能和速度的全能档。Codex 能自主工作数小时搞最难的任务，最难的时候才用 high 或 xhigh。无脑拉满只会更慢更贵。 7. 形成闭环 把重复工作做成 Skill，稳定了打包成 Plugin 分发，事后复盘回写 AGENTS.md。这是一个 Kaizen 闭环——用得越久，你的 Codex 越懂你的项目。 ## 写在最后 最近玩下来，我自己的感受是：2026 年的 Codex，最大的价值不是它又刷了几个 benchmark，是它真的把 agentic 编程从单点工具变成了可编排的平台层——云原生并行 + 插件化扩展 + 统一多表面 + 企业级集成。 我觉得它倒不是来取代 Claude Code 或 Cursor 的， 更准的说法是，它成了目前最强的执行与异步编排引擎。 Claude 的推理深度、Cursor 的 IDE 体验、Codex 的并行执行，三个其实是互补的。 但平台再强，也得你会用是吧， 所以这个系列接下来一篇一篇拆——下一篇从 AGENTS.md 开始，把“怎么写一个不浪费 token 又真能管住 agent 的指令文件”讲透。 这一篇先到这，有具体想先看哪块——MCP 实战配置、Skills 编写、多 Agent 编排、还是混合栈怎么搭——评论告诉我，我调后面顺序。

译OpenAI Codex 2026版以统一执行层+编排中枢架构覆盖App、CLI、IDE、Cloud、Web五入口，模型迭代至GPT-5.4 for Codex，Spark版快15倍。平台层由MCP、Skills（开放标准）、Plugins（可分发）构成。SWE-Bench Pro Public上56.8%微弱领先，OSWorld-Verified 64.7%接近人类；Claude Code在百万token重构占优，Codex强在异步执行与并行调度。最佳实践：Prompt含Goal/Context/Constraints/Done-when，用AGENTS.md固化持久指令，MCP按高频痛点优先配置。

meng shao@shao__meng · 6月16日60

LandingAI 把 Agentic Document Extraction 从「API 文档 + 手写脚本」升级成 Agent Skills ——让 Codex、Claude Code、Cursor 等 Coding Agents 在对话里直接写出可用的文档处理流水线 http://github.com/landing-ai/ade-document-processing-skills # 两个 Skill 的分工 1. document-extraction — 原子操作 · Parse：结构化 Markdown + 层级 JSON · Extract：JSON Schema / Pydantic 字段抽取（发票、表单、表格等） · Split：混合批次按文档类型拆分 · Classify：按页分类路由（Preview） · TOC：生成目录结构（Preview） · 大文件：异步处理（最高约 1GB / 6000 页） · Visual grounding：元素级坐标与置信度 2. document-workflows — 生产级组合 · 并行批处理（ThreadPool / async） · Classify → Extract 混合文档流水线 · RAG 准备：语义分块、embedding、ChromaDB/FAISS · 导出 DataFrame / CSV / Snowflake · 可视化标注（bbox 叠加、词级高亮） · Streamlit 交互 UI

译LandingAI 将 Agentic Document Extraction 升级为 Agent Skills，支持在 Codex、Claude Code、Cursor 等 coding agent 的对话中直接调用，实现零脚本文档处理流水线。两个 Skill 分工明确：document-extraction 提供结构化 Markdown/层级 JSON 解析、基于 JSON Schema/Pydantic 的字段抽取、按文档类型拆分、按页分类路由（预览）、目录生成（预览）、异步大文件处理（最高约 1GB/6000 页）及元素级坐标与置信度可视化；document-workflows 封装并行批处理、Classify→Extract 混合流水线、RAG 准备（语义分块、embedding、ChromaDB/FAISS）、DataFrame/CSV/Snowflake 导出、bbox 标注叠加及 Streamlit 交互 UI。安装命令：`/plugin marketplace add landing-ai/ade-document-processing-skills`。

🚨 AI News | TestingCatalog@testingcatalog · 6月16日43

ANTHROPIC 🔥: Claude users will continue being able to use their subscriptions for programmatic use, built on top of the Agent SDK. > Earlier, Anthropic shared an announcement that they will pause programmatic use consuming subscription rate limits. > Recently, users have received emails notifying them that this is no longer a plan. In case you’ve missed it 👀

译Anthropic确认Claude用户仍可使用其订阅额度，通过Agent SDK进行程序化（编程）调用。此前Anthropic曾宣布暂停这一做法，但最近用户收到邮件通知该计划已取消。这意味着conductor、t3 code、helmor等工具可继续利用订阅进行编程式使用。Anthropic调整了政策，允许订阅用户保留程序化调用的能力。

Rohan Paul@rohanpaul_ai · 6月16日52

The paper is saying that Claude Code works well not because it has a complex AI brain, but because a simple AI loop is surrounded by a huge, carefully built system for tools, safety, memory, permissions, and recovery. The authors studied the public TypeScript source and found that the main agent loop is very small: call the model, run approved tools, add results back, and repeat. What takes up most of the system is the harness, meaning the regular software around the model that decides what tools exist, what actions are allowed, what gets remembered, and what happens when things fail. They also show that context management is a major design problem, so Claude Code uses several layers to shrink or summarize older information before the model runs out of space. autonomy does not remove infrastructure, it increases the burden on infrastructure. A coding agent that can run shell commands and edit files cannot be treated like a chatbot with plugins, because every action has side effects and every side effect needs a boundary. ---- Link – arxiv. org/abs/2604.14228 Title: "Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems"

译论文分析Claude Code，其有效工作核心并非复杂AI大脑，而是简单AI循环——调用模型、执行已批准工具、回传结果、重复——被精心构建的外围系统（工具、安全、记忆、权限、恢复）包裹。作者研究公开TypeScript源码，主agent循环代码量极小，大量代码来自harness（常规软件），负责定义工具、权限、记忆及故障处理。上下文管理是主要设计挑战，采用多层压缩或总结旧信息避免模型空间耗尽。论文强调能运行shell命令和编辑文件的编码智能体不能等同于带插件的聊天机器人，每个动作都有副作用，需要明确边界约束。

🚨 AI News | TestingCatalog@testingcatalog · 6月16日75

Cartesia shipped Sonic 3.5 and Ink 2, two models built to run as a single real-time voice stack, with transcription on one side and speech on the other. > Ink 2 ranks first for accuracy on Artificial Analysis's streaming speech-to-text board. > Sonic 3.5 places at the top of the real-time text-to-speech view at around 82ms to first audio.

译Cartesia 推出 Sonic 3.5 和 Ink 2 两个模型，作为单一实时语音栈，分别负责文本转语音和语音转文本。Ink 2 在 Artificial Analysis 的流式语音转文字排行榜上排名第一。Sonic 3.5 在实时文本转语音中位列榜首，首音频延迟约 82ms。Cartesia 成为目前唯一同时拥有 #1 听与说模型的提供商。

Alibaba Cloud@alibaba_cloud · 6月16日20

How do AI agents reshape business? 🌐 Join our elite panel at Alibaba Cloud VivaTech 2026 featuring leaders from Alibaba Cloud, ElevenLabs, Eden AI, Storyverse AI, and Firecrawl. 🔗 Register now: https://int.alibabacloud.com/m/1000414352/

译AI 智能体如何重塑商业？🌐 加入我们在阿里云 VivaTech 2026 的精英小组，成员来自阿里云、ElevenLabs、Eden AI、Storyverse AI 和 Firecrawl。 🔗 立即注册：https://int.alibabacloud.com/m/1000414352/

Artificial Analysis@ArtificialAnlys · 6月16日60

Announcing Artificial Analysis Intelligence Index v4.1: a shift toward agentic workloads, featuring upgraded benchmarks and new per-task metrics The Artificial Analysis Intelligence Index is our synthesis metric for assessing model intelligence and tracking AI progress. v4.1 marks a broader shift toward agentic workloads, with three main changes: Updated and reweighted evaluations toward agentic tasks: 1. We upgraded three evaluations, removed one, and reweighted the Intelligence Index: ➤ Upgraded Terminal-Bench Hard to Terminal-Bench 2.1 and τ²-Bench Telecom to τ³-Bench Banking. Both move to newer, more robust task sets with harder, more realistic agentic scenarios that better separate frontier models ➤ Upgraded GDPval-AA to GDPval-AA v2. The upgrade re-baselines Elo to human performance at 1000, introduces a rotating panel of frontier-model judges, and raises the turn limit from 100 to 250 for longer-horizon agent trajectories ➤ Removed IFBench due to saturation. The benchmark no longer distinguishes frontier models sufficiently, so we have removed it from the Intelligence Index. We will continue to run it and publish results on new model releases 2. Cost per Task, Time per Task, and Tokens per Task: Three new per-task metrics, reported for every model and based on the Intelligence Index. We take the total cost, total time, and total output tokens for a model to run the Intelligence Index and divide by the number of tasks across its evaluations, giving the average cost, time, and output tokens to complete a single Intelligence Index task 3. Cached input token reporting: We now report cached input tokens and their impact on cost, including the cost to run the Intelligence Index, to better reflect the real cost of running each model Key Results: ➤ Leading models: Claude Fable 5 (with Opus 4.8 fallback, 60) leads the Artificial Analysis Intelligence Index v4.1 by four points but is currently unavailable, leaving Claude Opus 4.8 (max, 56) as the most intelligent available model, ahead of GPT-5.5 (xhigh, 55) ➤ Open weights leading models: Among open weights models, DeepSeek V4 Pro (max, 44) and MiniMax M3 (44) lead, followed by Kimi K2.6 (43) and MiMo-V2.5-Pro (42) ➤Cost per Task: Claude Opus 4.8 (max) is the most expensive available model at $1.78 per task, with Claude Fable 5 the highest overall at $3.25. GPT-5.5 (xhigh) scores within a point of Opus 4.8 on the Intelligence Index at $0.99 per task. DeepSeek V4 Pro (max) stands out on the Intelligence vs Cost per Task chart at $0.04 per task, with other leading proprietary models costing 20x to 45x more ➤Time per Task: time per task (inference decode time) ranges from 1.5 minutes for Grok 4.3 (high) to 13.5 for Claude Sonnet 4.6 (max), a roughly 9x spread. Claude Opus 4.8 (max) completes a task in 6.4 minutes and GPT-5.5 (xhigh) in 3.7, while Gemini 3.1 Pro Preview stands out on the Intelligence vs Time per Task chart at 1.6 minutes for a score of 46

译Artificial Analysis 发布 Intelligence Index v4.1，转向智能体任务。升级 Terminal-Bench 2.1、τ³-Bench Banking、GDPval-AA v2（Elo 重基线、引入前沿模型评审、回合上限增至250），移除饱和的 IFBench。新增每任务成本、时间、输出 token 指标及缓存 token 影响。关键结果：Claude Fable 5（60分）领先但不可用；可用模型中 Claude Opus 4.8（max）56分居首，GPT-5.5（xhigh）55分。开源 DeepSeek V4 Pro 与 MiniMax M3 均44分。成本方面，Opus 4.8 每任务 $1.78，GPT-5.5 $0.99，DeepSeek V4 Pro 仅 $0.04。时间方面，Grok 4.3 最快（1.5分钟），Opus 4.8 需6.4分钟，GPT-5.5 需3.7分钟，Gemini 3.1 Pro Preview 以1.6分钟得46分。

小互@xiaohu · 6月16日60

兄弟们 好消息！ 从6月15日起，也就是今天，Agent SDK 和 Claude -p 的用量 不再占用你 Claude 订阅套餐额度 根据你的订阅，现在每个月会多出一笔"专用零花钱" Pro 用户是 $20，Max 5x 是 $100，以此类推... 这笔钱专门用来跑 claude -p、自己写的 Agent SDK 脚本、或者第三方 Agent App， 不会动你原来用量额度 以前的问题是：你用 claude -p 跑批量任务，会把日常对话的配额也吃掉，两边抢同一个池子。现在拆开了，互不影响。 额度用完了才开始扣其他费用 未用完的不滚存到下个月 需要一次性手动领取，之后自动续期

译自6月15日起，Claude 将 Agent SDK 和 claude -p 的用量从订阅套餐原有额度中剥离，每月额外提供一笔“专用零花钱”，其中 Pro 用户 $20、Max 5x 用户 $100，以此类推。该额度专门用于运行 claude -p、自写 Agent SDK 脚本或第三方 Agent App，不占用日常对话配额。额度用完后才扣其他费用，未用完不滚存下月；需手动领取一次后自动续期。

meng shao@shao__meng · 6月16日69

Cua 和 Snorkel AI 联合发布「Cua-Bench」：评测 Agent 在专业软件上的 Computer Use 能力 @trycua @SnorkelAI Cua-Bench 首个公开数据集聚焦 KiCad，一个完整的电子设计自动化工具，25 道任务均由执业电气工程师编写、第二人复核，覆盖从「改一个电容值」到「从零搭建双运放电路」等真实工作场景。 https://cua.ai/cuabench/report https://snorkel.ai/blog/cua-bench-benchmarking-computer-use-agents-on-professional-software/ 首批测试结果 没有一个模型通过四分之一，最强也只有 24% 的完全通过率： 1. GPT-5.5：6 / 25 完全通过，0 / 25 部分通过 2. Claude Sonnet 4.5：5 / 25 完全通过，3 / 25 部分通过 3. Claude Haiku 4.5：5 / 25 完全通过，3 / 25 部分通过 最重要的发现：「编辑现有」与「从零搭建」之间的能力断崖 · 所有完全通过的任务，都是对已有原理图的局部修改（改元件值、换电源端口、调整偏置点等）。 · 16 道从零搭建任务：0 成功。 模型能放元件，但很少完成布线；任务结束时连线往往仍是未完成状态。 瓶颈在执行层：规划多步流程、在复杂 GUI 中定位与操作、自我校验、在步数预算耗尽前保持任务不漂移。 Snorkel 的深度分析进一步指出：步数上限不是主因。 两个失败任务放宽到 500 步仍失败；而所有成功案例都在 150 步内完成。问题出在计划与操作效率，而非单纯「时间不够」 典型失败模式（可复现、可归类） · 导航开销大（~84%）：首次启动弹窗、误进 PCB 编辑器而非原理图编辑器，恢复就消耗 25–70 步。 · 操作粒度过细（~84%）：每轮只做一个点击 + 大段自我叙述，工程师三步能完成的事拆成十轮。 · 视图控制混乱（~76%）：不用 Home 键 fit，在极端缩放间来回 scroll，元件一出视野就「丢失」。 · 布线未完成（~72%）：16 个因步数耗尽而失败的任务中，没有一个画全所需连线。 · 自我验证不可靠：5 次宣告 DONE 的产出实际未通过验证——Agent 读的是自己「说过什么」，而不是屏幕上的真实状态。典型错误：悬空电阻却声称已连接；输入 2.80kOhm 而非 KiCad 要求的 2.8k；用错芯片参考电压（LT3010 是 0.808V，不是 1.24V）。 根因分布：规划 ~40%、感知 ~22%、导航低效 ~19%、领域知识 ~11%、工具/API ~8%——且全程零 API 错误，说明 harness 本身没问题，问题在 Agent 如何使用它。 对行业的含义 1. 现有 computer-use benchmark 可能高估了真实能力。 浏览器里「多试几次总能蒙对」的策略，在专业软件上行不通。 2.「会答电路题」≠「能在 KiCad 里做出正确原理图」。 知识与 GUI 执行是两条能力线，当前 frontier 模型在前者尚可、后者明显不足。 3. 长 horizon + 自我校验是下一个瓶颈。 不是缺底层能力，而是缺「如何规划、批量操作、读 UI 状态而非读自己的 narration」的 meta-policy。 4. 评测设计值得借鉴： 专家出题、双人复核、netlist 客观打分、任务难度按人类 ~50 步校准——这是衡量 Agent 能否创造真实经济价值的一个较公平标尺。

译Cua 与 Snorkel AI 联合发布 Cua-Bench，首个公开数据集聚焦电子设计工具 KiCad，含 25 道由执业电气工程师编写并复核的任务。测试中，GPT-5.5 完全通过 6/25（24%），Claude Sonnet 4.5 和 Haiku 4.5 各通过 5/25（20%）。所有成功任务均为局部修改，16 道从零搭建任务全部失败。瓶颈在执行层：导航开销大（~84%）、操作粒度过细（~84%）、视图控制混乱（~76%）、布线未完成（~72%）、自我验证不可靠。步数上限并非主因。根因分布：规划 ~40%、感知 ~22%、导航低效 ~19%、领域知识 ~11%、工具/API ~8%，全程零 API 错误。

meng shao@shao__meng · 6月16日66

Generative UI × Agent Harness Coding Agent（Claude Code / Codex / Pi）在 Vercel Sandbox 里真实改代码、跑命令、测用例；汇报时不再只返回 Markdown，它基于「json-render」输出受约束的 JSON UI 规格，前端实时渲染成步骤、Diff、终端、测试结果、图表等组件。 https://github.com/vercel-labs/json-render/tree/main/examples/harness-chat 这个实现思路，和 Claude Code 核心开发者 @trq212 「Using Claude Code: The Unreasonable Effectiveness of HTML」异曲同工： https://x.com/trq212/status/2052809885763747935 技术架构（三层解耦） 用户 Prompt ↓ HarnessAgent（AI SDK 7 实验 API） ├─ Claude Code / Codex / Pi（可互换） └─ Vercel Sandbox（隔离 Linux 环境，真实 bash/edit/test） ↓ Agent 输出：短 prose + ```spec 围栏内的 JSONL ↓ pipeJsonRender（从流中提取 spec → data-spec parts） ↓ 前端 useChat + useJsonRenderMessage → 渲染组件树 关键设计点： 1. Harness 抽象与模型抽象对称 AI SDK 7 的 HarnessAgent 让你像换模型一样换 Harness——claudeCode 换成 codex 或 pi，调用方式不变。Harness 管 skills、sandbox、session、权限、compaction 等「模型之上的层」。 2. UI 层与执行层完全解耦 HarnessAgent. stream() 返回标准 AI SDK StreamTextResult，因此 json-render 管道与单模型 chat 示例 完全相同。换 Agent Harness，前端代码不用改。 3. Catalog 约束 = 安全 + 可预测 Agent 只能使用预定义组件（Steps、FileChange、Terminal、TestResults、Metric、BarChart…），输出必须符合 Zod schema。AI 生成 UI，但 在你划定的组件边界内。 4. Session 绑定 Sandbox 每个 chat 维护一个 live session + sandbox；首条消息冷启动较慢，后续复用同一工作区。10 分钟 idle 或「Start Over」会销毁 sandbox。 一次完整交互里发生了什么 1. 用户选 Agent（Claude Code / Codex / Pi）并发送任务 2. 服务端 getSession(chatId, agent) 创建或复用 Harness session 3. Agent 在 sandbox 内执行真实操作（写文件、跑测试、benchmark 等） 4. 回合结束时 Agent 输出： · 一两句 conversational 总结 · 一个 ```spec 围栏包裹的 JSONL UI 报告 5. pipeJsonRender 把 spec 从文本流中拆出，变成 typed data-spec parts 6. 前端同时渲染：Markdown prose、工具调用活动行（bash/edit/read…）、结构化报告组件 Agent 的 system instructions 明确要求：不得虚构结果——失败就展示 error step、非零 exit code、失败测试；Terminal 必须用 session 中真实捕获的输出。

译Vercel Labs 利用 AI SDK 7 实验 API 推出 HarnessAgent，结合 json-render 为 Claude Code / Codex / Pi 等 Coding Agent 提供生成式 UI。Agent 在 Vercel Sandbox 隔离 Linux 环境中执行写文件、跑测试等真实操作，输出受 Zod schema 约束的 JSONL UI 规格（仅限 Steps、FileChange、Terminal 等预定义组件），前端通过 useChat + useJsonRenderMessage 实时渲染。核心设计：Harness 抽象允许像换模型一样互换 Agent；UI 层与执行层完全解耦；Session 绑定 Sandbox，10 分钟空闲或“Start Over” 销毁。Agent 不得虚构结果，失败必须展示 error step、非零 exit code 或失败测试。

🚨 AI News | TestingCatalog@testingcatalog · 6月16日37

OPENAI 🔥: Codex now supports Chrome DevTools Protocol for browser use. This is a huge superpower that will allow Codex to inspect and modify any website. It is still a very early implementation, but I bet that in several years this will be a default browser capability. If websites are loaded through AI, users will be able to customize their UX on the fly. This is the way 👀

译OPENAI 🔥: Codex 现在支持 Chrome DevTools 协议，可用于浏览器操作。这是一个巨大的超能力，将允许 Codex 检查并修改任何网站。 这仍是一个非常早期的实现，但我敢打赌，几年后这将成为浏览器的默认能力。如果网站通过 AI 加载，用户将能够即时自定义他们的用户体验。 这就是方向 👀

Emad@EMostaque · 6月16日16

is ok

译可以

meng shao@shao__meng · 6月16日66

AI 驱动开发的七阶段 1. Grill 2. Research 3. Prototype 4. PRD 5. Issues 6. Implement 7. Review 来自 Skills For Real Engineers 作者 @mattpocockuk https://github.com/mattpocock/skills 7 个阶段：目的 | 产出 1. Grill：把模糊想法变成共享理解 | 问题陈述 + 对齐 2. Research：缓存难探索的外部信息 | research.md 3. Prototype：用可玩代码验证设计/UX | 可丢弃原型 4. PRD：描述终点，而非路径 | 需求文档 5. Issues：拆成可并行执行的垂直切片 | 带依赖的工单 DAG 6. Implement：Agent 执行（TDD、Ralph 等） | 可运行代码 7. Review：人工 QA，发现问题再回环 | QA 计划 + 新工单 /grill-with-docs：这是 /grill-me 的升级版，专为有代码库的场景设计 额外能力： 1. 领域语言（CONTEXT.md） 来自 DDD 的 ubiquitous language。CONTEXT.md 只是术语表，不是 spec、不是实现笔记。 例：「materialization cascade」比「lesson 被 real 化时文件系统里占坑」省 token、可搜索、命名一致。 2. ADR（docs/adr/） 只在三条件同时满足时写：难逆转、无上下文会令人惊讶、存在真实 trade-off。 3. 会话中的四类动作 · 对照 glossary 挑战用词 · 用具体场景压测边界 · 对照代码发现矛盾 · 决策即时写入 CONTEXT，不批量攒 与 /grill-me 的分工：有代码库 → /grill-with-docs；无代码库（写悼词、纯产品构思）→ /grill-me。

译@mattpocockuk 提出 AI 驱动开发七阶段：Grill（模糊→共享理解）、Research（缓存外部信息）、Prototype（可玩代码验证）、PRD（需求文档）、Issues（垂直切片）、Implement（Agent 执行）、Review（人工 QA）。/grill-with-docs 是 /grill-me 的升级版，专为有代码库场景设计，新增领域语言（CONTEXT.md）、ADR（docs/adr/）及会话四类动作。无代码库时仍用 /grill-me。作者认为 pre-PRD 阶段需更多结构，/grill-with-docs 将再次调整。

ginobefun@hongming731 · 6月16日41

http://x.com/i/article/2066671362920599553 # BestBlogs 早报 · 06-16｜Loop Engineering、Agent 工具设计、Token 成本控制 在线阅读本期早报 ## 导语 最近没有特别炸的头条，今天的内容更偏向方法论和基础原理的梳理。三篇精讲分别在拆解三个最近被讨论得有点过热的词：循环工程（Loop Engineering）、AI Agent 工具设计、Token 成本控制。它们的共同点是，都在把一个听起来很新的概念，还原成一套可以验证、可以落地的工程判断——值不值得做，看的是任务本身，不是名字本身。速览部分还覆盖了 Anthropic Fable 5 模型被美国政府出口管制叫停的始末、Scaling Law 参数冗余的最新研究，以及几位创业者和工程团队的一线观察。 ## 精讲一：Codex 和 Claude Code 负责人都不写提示词了，AI 圈爆火的 Loop 到底是什么 来自 APPSO 最近一段时间，"Loop Engineering（循环工程）"这个词在 AI 圈被频繁提起。Codex 负责人 Tibo 在社交媒体上转发讨论，问大家是否已经开始"写嵌套循环"；Claude Code 的产品负责人 Boris Cherny 也在官方播客里说，现在他更习惯"跟 loop 对话，让 loop 替我来 prompt"。一个新词又冒出来了，紧接着的问题自然是：它和过去的 Prompt Engineering、Harness Engineering 比，到底有什么不一样？ 这篇文章给出的回答相当克制。如果只看技术实现，循环工程并没有发明什么全新的东西。Harness、Skill、Agent Workflow 这些系统，过去几年里都在尝试让 Agent 自己规划、执行、反思、再执行。今天大家重新讨论 Loop，是因为模型终于能把这个循环连续跑下去了——当 Agent 可以连续工作几十分钟、几个小时甚至跨天完成任务时，人和 AI 协作的最小单位，从一次对话变成了一个完整的回路。 文章把这个变化讲得很朴实：你让 AI 写代码，它写完你跑测试，测试报错你把错误贴回去，它再改，你再跑——这就是一个最原始的 loop：行动、观察、修正、再行动。区别在于，过去每一轮都靠人手动推动；循环工程做的事，是把这些反复发生的动作写成规则，交给系统执行。一个完整的 loop 至少要回答五个问题：AI 什么时候开始干活，它能调用哪些工具，它怎么知道自己做错了，每一轮的结果记在哪里，以及它什么时候必须停下来交给人。换句话说，Loop Engineering 更像一套工作制度——给 AI 设任务、设工具、设反馈、设记忆、设刹车，prompt 只是这套系统里最小的一个零件。 文章引用了 Google Cloud AI 总监 Addy Osmani 的拆解（另见 BestBlogs 收录的相关长文），把一套循环工程概括为五个积木加一个记事本：定时任务（在 Codex 里叫 Automations，在 OpenClaw 里叫 HEARTBEAT）、独立工作目录 worktree、承载项目知识的 Skill、用 MCP 协议跳出单一文件系统的连接器、以及负责审核的子 Agent；记事本则是一份状态文件，记录已确认的事实、踩过的坑、偏好的格式，AI 每次启动时先读它，就能接着往下走。这五个组件单独看都不新鲜，新鲜的是它们现在可以被持续串联起来，跑出一个能自己迭代的循环。 但文章并没有止步于"这个概念值不值得叫新范式"。它给出了一个更实际的判断框架：循环值不值得搭，取决于任务是否真的会反复出现、流程是否相对稳定、结果是否可以被自动检查，以及关键判断是否还掌握在人手里。同时它也很直接地提醒，循环工程有个前提——Token 预算要够。循环会反复读上下文、反复重试、四处探索，不管最后有没有产出，Token 都在燃烧。对于月付固定额度的普通用户，循环跑两天就可能撞到周限额。一次性的任务，一句好提示词又快又便宜；只有重复出现、且能自动验证的任务，才值得为它搭一套循环。 这篇文章和今天另外两篇精讲其实在讲同一件事的不同侧面。Loop Engineering 讨论的是"任务该不该交给一套自动循环"；下一篇讲的是"如果要交给 Agent，工具接口该怎么设计才不翻车"；再下一篇讲的是"循环跑起来之后，账单到底花在哪"。三者放在一起看，会更清楚循环工程真正的成本结构和适用边界在哪里。 对于正在评估是否要给自己的工作流搭一套循环的读者，这篇文章值得通读——尤其是关于"一个完整 loop 要回答的五个问题"那部分，可以直接拿来对照自己的场景：如果五个问题里有两三个答不上来，那这套循环大概率还不到能放手的阶段。 ## 精讲二：AI 智能体工具设计：有效与无效的模式 - MachineLearningMastery.com 来自 Hacker News - Newest: "AI Agent" 如果说精讲一讨论的是"要不要给 Agent 搭循环"，这篇文章讨论的是循环里最基础的一环：Agent 调用的工具，接口设计得到底好不好。文章的核心判断很直接——大多数 AI Agent 的失败，表面看是模型选错了工具、传错了参数、处理错误的方式不对，但本质原因往往不在模型，而在工具设计本身。模型只能基于工具名称、描述、参数 schema 这些信息去推理，接口含糊，失败就是必然，不是偶然。 文章先列了几条"有效"的设计模式。第一条是单一职责：一个工具应该只代表一个清晰的操作，而不是用一个 action 参数把创建、查询、更新、删除、暂停都塞进同一个工具里——模型得先猜出该用哪个模式，再去解决真正的任务。第二条是用强约束的 schema 让"无效状态"变得不可能：用枚举（Enum）限定取值范围，用格式约束限定日期、ID 这类字段，模型就不需要去猜测这些隐藏的约束条件。第三条是工具描述不仅要说明"这个工具是做什么的"，还要说明"什么时候不该用它"——很多描述只写了第一半，模型只能从工具名称去推断使用边界，这恰恰是大规模部署里常见的选择错误来源。 第四条和第五条更偏向"出了问题之后怎么办"。错误返回不应该是一段裸的报错堆栈，而应该是结构化的，至少包含机器可读的错误码、人类可读的描述、一个 recoverable 字段告诉模型这个错误能不能重试，以及一个 suggested_action 字段告诉模型下一步该做什么。没有这些信息，模型经常会重试那些根本不该重试的错误，或者放弃那些其实可以恢复的错误。第五条是幂等性：任何会修改状态的写操作——创建记录、发消息、转账——都必须能被安全地调用两次，做法是给每个写操作配一个幂等键，重复调用时返回第一次的结果而不是再执行一遍。 文章同时列出了几种"看起来在 demo 里没问题，但在真实负载下会翻车"的反模式。最常见的是直接把一个面向开发者的 REST API 原样包成工具——这类 API 往往返回几百个字段，用分页、用没有上下文含义的内部 ID，模型很难直接处理，正确的做法是写一层专门的封装，只暴露 Agent 真正需要的字段。第二种是把所有工具一次性塞进每个上下文：有研究发现，随着工具目录变大，工具调用的准确率会明显下降，即使是 128K 上下文的模型也不例外；更好的做法是按当前步骤动态加载相关的工具子集。第三种是"静默的部分成功"——一个批量操作只完成了一部分，却返回一个看起来完全成功的结果，模型会带着不完整的系统状态继续往下走，正确的做法是显式返回成功和失败的列表。第四种是功能重叠、命名含糊的工具堆在一起，比如 search_documents 和 find_documents，模型每次调用都要多花一轮推理去判断该用哪个。第五种是不可逆操作没有确认环节，文章建议把"暂存"和"执行"拆成两个独立的工具调用，中间用一个有效期很短的确认 token 衔接，让模型无法在一次推理里完成一个删除操作。 这篇文章和精讲一是衔接的：循环工程描述的是"人退一步，让系统自己跑"，但系统能不能跑得稳，取决于它手里的工具接口够不够清楚。如果工具设计本身含糊，循环只会把同样的错误重复放大。 如果你正在给自己的 Agent 写工具定义，这篇文章里"有效模式 vs 无效模式"的对照表，几乎可以直接当作 checklist 来用——尤其是错误返回的结构化设计和幂等键这两条，往往是最容易被忽略、但出问题时最难排查的部分。 ## 精讲三：一篇搞懂 AI Coding Agent 的 Token 成本控制 来自 腾讯技术工程 很多人用 AI Coding Agent 一段时间后都会有同一个疑问：自己明明没问多少问题，账单怎么会这么高？这篇文章给出的答案是：你打的那句话，在每次请求里可能连 1% 都不到，真正的成本大头藏在系统自动帮你带上的那一大坨东西里——系统提示词、项目说明文档、Skill 定义、工具 / MCP 定义、历史会话、代码文件，这些加起来通常远远超过用户那句话本身。文章给出一个近似公式：总成本 ≈ 固定前缀 + 会话历史 + 运行时检索 + 工具往返 + 模型输出，用户的提问只是触发任务的"点火器"，不是成本主体。 文章接着拆穿了一个常见的错觉："它好像一直记得我们聊过什么"。大模型本身通常是无状态的，真正"记得"的是包在模型外面的 Agent / CLI / 平台层——它在每一轮请求前，把历史、规则、工具、代码、文档重新拼起来再发给模型。所谓"记忆"，很多时候只是"再次传入"。这直接决定了三个成本结构：会话越长，后续每一轮越贵；工具越多，常驻定义越重；工具调用会形成回路，一次任务不是一次计费，而是一连串"请求-返回-再请求"的链条。文章还把成本拆成五类，特别提醒最容易被低估的是工具往返成本和重试成本——第一次没答对，往往意味着整包上下文被反复付款一次。 理解了这个结构之后，文章顺势讲清楚了 Prompt Cache 的作用：它缓存的不是"答案"，而是"稳定前缀的处理结果"——如果两次请求前半段几乎一样，服务端就不必每次都从头处理那一大段相同内容。这里有三个推论值得记住：Prompt Cache 省的不是首次成本，而是重复成本；缓存不是"写短"，而是"写稳"——天天改的系统提示词很难被命中；缓存优化和上下文治理本质上是一回事，把稳定内容前置、变化内容后置，提升的都是"可复用比例"。 在使用习惯这一层，文章给出了一系列今天就能改的小动作：一个 Session 只服务一个目标，修 Bug、写文档、查线上问题分开开会话；长会话及时压缩，因为未压缩的对话历史是负债不是资产；该长期保留的项目背景、约束、待办，外置到文档或 Memory 文件里，而不是指望 Agent 从聊天记录里一路记到底；输出也要省，"先复述问题再给结论"的废话本身就是 Token；Skill 和 MCP 不是免费的，高频稳定的常驻，低频的按需加载；甚至包括"能用 CLI 解决就别上 MCP"这种听起来琐碎、但确实省钱的细节。 这篇文章和前两篇精讲构成了一条完整的链路：循环工程让系统自己反复跑，工具设计决定了每一步会不会出错，而 Token 成本则是这一切运行起来之后，真正要为之买单的那一面。三篇放在一起，更像是给"要不要让 AI 自己跑一套循环"这个问题，提供了一份从决策到落地到账单的完整参考。 如果你已经在日常使用 AI Coding Agent，这篇文章建议优先看"使用习惯"那一节——零工程投入，却往往是第一波最大收益的来源；如果你在评估架构层面的优化，再回头看 Prompt Cache 和五层模型那部分会更有针对性。 ## 速览 更多值得关注的内容： - [Fable 5 禁令始末：Anthropic 亲手写下的剧本，反过来演了它自己](https://www.bestblogs.dev/article/369a0323)（十字路口Crossing）：2026 年 6 月 12 日，Anthropic 收到美国商务部的一封信，以出口管制为由要求暂停所有外国公民（包括 Anthropic 自己的外籍员工）访问刚上线三天的旗舰模型 Fable 5 与 Mythos 5。Anthropic 当晚选择对全球所有用户关停这两款模型，多数团队连夜把工作流回退到 Opus 4.8。文章复盘了导火索——一份据称来自亚马逊安全测试报告，以及围绕"这算不算越狱"的各方说法分歧，呈现了一次围绕 AI 模型的政府干预事件的完整过程。 - [Scaling Law 的真相，藏在那些「没用」的参数里｜Hao 好聊趋势](https://www.bestblogs.dev/article/23d850ea)（腾讯科技）：从 ShortGPT 论文砍掉 LLaMA-2-13B 四分之一层数、性能几乎不掉的实验说起，文章梳理了过去两年关于"参数冗余"的系列研究，提出这些看似"空转"的参数在训练、推理、后训练阶段分别扮演着隔离空间、数值泄压、计算骨架和可塑性储备四种角色。文章的判断是，Scaling Law 的边际收益正在转向那些 benchmark 难以测量的长尾能力和多步推理能力，而不是简单的参数堆叠。 - [GlobalGPT 李焕之：零融资、套壳产品千万美金 ARR 后，我找到了创业的 mission](https://www.bestblogs.dev/article/ed22a9ae)（Founder Park）：GlobalGPT 创始人李焕之分享了从 2024 年初现金流仅剩一个月、到做出一款聚合主流 AI 模型的"套壳产品"、最终做到千万美金 ARR 的过程。他提到一个反常识的判断——初创公司在没想清楚方向时，去冲最红海的市场反而是对的，因为水涨船高的赛道哪怕排到第 1000 名也比小市场前 10 名更大。现在团队想在 GlobalGPT 上孵化一款主动型服务型 AI 产品 Yukie。 - [上线只活了 180 天，AI 应用层的泡沫被戳破了](https://www.bestblogs.dev/article/0f79cbbc)（腾讯科技）：文章以 OpenAI 关停上线半年的 Sora 视频生成器、AI 模型评测平台 Yupp.ai 关停、Google 收缩 Pixel Studio 和浏览器 Agent 实验项目为例，分析 AI 应用层正在经历的一轮商业筛选。核心判断是：当底层模型能力持续下沉，那些建立在单点模型能力之上、本质是"白牌化 Gemini 或 GPT"的应用，正在失去独立存在的理由；真正活下来的产品已经转向超级入口、高频场景和 Agent 化工作流。 - [做了 6 年智能眼镜后，夏勇峰按下暂停键：为 AI 造硬件而非为硬件加 AI](https://www.bestblogs.dev/article/70638b9b)（虎嗅）：蜂巢科技创始人夏勇峰的智能音频眼镜已经占据中国智能音频眼镜市场约 10% 份额，处于上升期，但他在今年春节后主动暂停了全年新品计划，拒绝了大厂的订单。他的判断是：站在 AI 大模型快速进化的当下，眼镜不会是承载 AI 的第一选择；现阶段更值得做的是"为 AI 造它需要的最小必要硬件载体"，而不是在已有硬件形态上叠加 AI 能力。 - [SpaceX 登陆纳斯达克市值超 2 万亿美元，殖民火星使命驱动 24 年崛起史](https://www.bestblogs.dev/article/15fef79e)（虎嗅）：6 月 12 日 SpaceX 正式登陆纳斯达克，市值达 2.1 万亿美元，刷新全球 IPO 募资纪录。文章通过实地探访 Boca Chica 发射场和洛杉矶总部，并采访 SpaceX 前高管、猎鹰 9 号工程师 Lewis Hong，回顾了从马斯克 2002 年用卖掉 PayPal 的钱成立公司、到猎鹰 1 号三次发射失败、再到星舰回收和星链盈利的 24 年历程，串起公司"殖民火星"这条贯穿始终的使命线。 - [把 18 亿颗星星画在一张图上，能还原我们拍到的银河吗？](https://www.bestblogs.dev/article/2c2192f7)（Computing Life）：作者用欧空局盖亚卫星公布的 18 亿颗恒星方位、星等、距离数据，尝试用程序还原一张逼真的银河图像。第一版渲染完全不像真实星空，随后通过逐步引入点扩散函数（PSF）模拟光晕、用暗星光度代理还原银河乳光、做黑体辐射色温校准等物理原理，一步步让模拟结果接近真实观感。文章在"翻车—改进"的过程中，顺带讲清楚了我们头顶星空形态背后的几条关键物理和生理学原理。 ## 补充阅读 - [vibe-coding-template：一次 Codex 对话文件丢失后，我整理了一套 Agent 长期协作模板](https://www.bestblogs.dev/article/a923c29f)（V2EX）：作者因为 Codex 本地对话记录意外丢失、常用提示词全部蒸发，整理出一套包含 AGENTS.md、任务 prompt、code review、知识讲解和 web-search 工作流的协作模板，适合长期用 AI 编程、担心协作资产丢失的读者参考。 - [Superpowers：给 Claude Code 装上"工程大脑"](https://www.bestblogs.dev/article/ac341305)（百度Geek说）：解析 Superpowers 项目如何用 14 个内置技能，强制 Claude Code 走"澄清→设计→规划→执行→验证"的工程流程，把"写代码快但漏洞百出"变成"一次做对"，和精讲二讨论的工具设计纪律可以对照着看。 - [Skill 升了版，你说不清楚哪里变好了吧？](https://www.bestblogs.dev/article/16eb5a70)（前端Q）：系统梳理了 Agent Skill 版本对比中常见的"假改进"陷阱——均值改善但分布退化、整体提升但 P0 翻车、Token 暴涨换正确率等，并给出多维度对比、显著性判断的工程化方法，适合维护 Skill 库或做版本评估的读者。 - [从月球漫步到赛博都市，WBench 测出了世界模型的边界](https://www.bestblogs.dev/article/cbf63829)（美团 · 技术团队）：美团 LongCat 团队提出首个面向交互式视频世界模型的多轮评测基准 WBench，对 20 个前沿模型进行了系统扫描，发现导航能力和画质表现脱钩、多轮交互后所有模型表现都会明显下降，关注视频世界模型进展的读者值得一看。 - [当平台治理直面国家战略：网飞、韩国影业与数字时代的治理思考](https://www.bestblogs.dev/article/02a0df4c)（哈佛商业评论）：以网飞与韩国影视产业的博弈为切入点，结合奥斯特罗姆、梯若尔等多种理论框架，提出一套适用于数字平台时代的治理原则，关心平台经济和产业政策议题的读者可以参考。 - [一家中国科技公司，正在用 AI 创造世界杯观赛的新模式](https://www.bestblogs.dev/article/52fc63a7)（腾讯科技）：报道联想作为 FIFA 官方技术合作伙伴，通过裁判视角 AI 视频增强、3D 数字人建模等系统参与 2026 世界杯赛事运行，是中国企业从品牌赞助商转向技术底座建造者的一个具体案例。 - [Lovable 设计负责人分享 AI 时代高效团队七条经验](https://www.bestblogs.dev/status/2066349458904744224)（宝玉(@dotey)）：转述 Lovable 设计负责人 Felix Haas 总结的七条团队经验，包括主人翁意识、好奇心与对 AI 沉迷的区别、让资深的人重新动手等，结合 Lovable 自身 8 个月做到 1 亿美元年收入的背景，值得管理者参考。 - [L123_当 demo 泛滥，判断力升值](https://www.bestblogs.dev/article/57cbbb5c)（Liam's Notes）：作者从一场 Hackathon 评委经历讲起，指出当 AI coding 让"做出一个能跑的 demo"几乎免费之后，决定"做什么"和"为什么做"的判断力，反而成了最稀缺的护城河，和今天三篇精讲讨论的"值不值得搭循环"是同一类判断。 - [如何搭建一个端到端业务需求专家 Agent](https://www.bestblogs.dev/article/c497f4de)（阿里云开发者）：详细记录了一套已经在真实业务需求上跑通的端到端链路，把需求从澄清、方案、实现、CR 到结项沉淀，组织成 Agent 自主推进、人在关键节点确认的闭环，可以当作精讲一里"loop 五个组件"的一个具体实践案例来读。 - [用 AI Skills 打通中间件迁移：定位服务从 Android 到鸿蒙的完整实践](https://www.bestblogs.dev/article/b1d101b0)（大淘宝技术）：以 Android 定位服务迁移鸿蒙为案例，把 API 映射等隐性知识结构化为 AI 可读的 Skills 文档，154 个服务的迁移节省了 25 小时且零编译错误，关注 AI 辅助迁移落地效果的读者可以参考。 - ["随机就好"：AWS 的数据中心网络革命](https://www.bestblogs.dev/article/3a3254fb)（云石乱笔）：解读 AWS 如何用基于随机图理论的扁平网络 RNG 替代传统胖树架构，省下近七成路由器并提升吞吐，文章也坦诚讨论了这套方案的局限和适用场景，适合关注基础设施工程权衡的读者。 - [🤔什么？SFT、DAgger、离线 RL 和 OPD，竟然是同一张 2×2 表格上的四个格子！](https://www.bestblogs.dev/article/711f4d46)（青稞AI）：从序列级推导出发，揭示 SFT、DAgger、离线 RL、OPD 四个训练范式本质上是"prefix 来源"与"KL 方向"两个独立维度组合出的 2×2 表格，并基于此提出两个实用方法，适合关注模型后训练范式的读者。 ## 今日阅读路径 如果今天时间有限，建议按这个顺序读： 1. 精讲一：Codex 和 Claude Code 负责人都不写提示词了，AI 圈爆火的 Loop 到底是什么 —— 先搞清楚 Loop Engineering 到底是不是一个新东西，以及它真正值得讨论的判断标准是什么。 1. 精讲三：一篇搞懂 AI Coding Agent 的 Token 成本控制 —— 如果你已经在用 AI Coding Agent，这篇能直接帮你省钱，而且能解释清楚"循环跑起来之后账单去哪了"。 1. 精讲二：AI 智能体工具设计：有效与无效的模式 —— 如果你在给自己的 Agent 写工具或者评估别人写的工具，这篇的对照表可以当 checklist 用。 时间更充裕的话，再看 Fable 5 禁令始末和 AI 应用层泡沫这两篇，了解一下当下 AI 行业里政策和商业层面正在发生的事。 BestBlogs 是 AI 驱动的私人阅读助手，帮助你建立稳定、可信、个性化的高质量信息输入。它帮你判断什么值得读、协助你读懂，并逐渐理解你关注什么，欢迎体验。

译循环工程将人机协作从单次对话转为连续回路，需回答何时启动、工具集、错误检测、记忆、刹车五个问题。Agent工具设计强调单一职责、强约束schema、结构化错误返回、幂等键等有效模式，并列出静默部分成功、功能重叠等反模式。Token成本控制揭示用户提问仅占成本1%以下，真正大头顶在系统提示词、项目文档、Skill定义、历史会话等固定前缀。速览还涉及Anthropic Fable 5模型被美政府出口管制叫停、Scaling Law参数冗余研究。

ginobefun@hongming731 · 6月16日56

BestBlogs 早报 · 06-16 # Loop Engineering / AI Agent 工具设计 / Token 成本控制 / Claude Fable 5 / Scaling Law [1] ★ 精讲｜一篇搞懂 AI Coding Agent 的 Token 成本控制 这篇文章把“Token 都烧在哪”讲透了：真正的账单大头不是你打的那几十个字，而是系统每轮自动带上的系统提示词、Skill、工具定义和会话历史——所谓“它记得”，本质是系统在一遍遍重复提醒模型。给出的优化路径也很朴素：一个 Session 只做一件事，长会话及时压缩，按任务给模型分档，把高频内容做成稳定前缀吃满 Prompt Cache。省钱的关键不是少问一句话，而是让系统别重复搬运同一批上下文。 来源：腾讯技术工程 https://www.bestblogs.dev/article/8b9392aa [2] ★ 精讲｜AI 智能体工具设计：有效与无效的模式 - http://MachineLearningMastery.com 这篇文章把 AI Agent 翻车的锅，从「模型不够聪明」甩回「工具设计太糙」：单一职责工具优于万能 action 参数，用枚举和强约束 schema 堵住模型瞎猜，错误返回要带 recoverable 字段和下一步建议而不是甩一坑日志，写操作必须有幂等键，危险操作要拆成两步确认。核心判断很朴素——模型只能基于你给的接口推理，接口含糊，失败就是必然，不是偶然。 来源：Hacker News - Newest: "AI Agent" https://www.bestblogs.dev/article/963dda4c [3] ★ 精讲｜Codex 和 Claude Code 负责人都不写提示词了，AI 圈爆火的 Loop 到底是什么 「循环工程」最近被吹成新范式，但文章先把热闹拆开看：技术上不算新发明，过去的 Harness、Skill、Agent 工作流早就在做，真正变化的是模型终于能把循环连续跑下去——人从写提示词退到定规则：何时启动、工具边界、出错怎么判断、记录在哪、何时收手交回人。结合另一篇用 OKR 和古德哈特定律拆解循环工程的长文，它更像一套管理制度：值不值得搭，取决于任务是否真反复、Token 预算够不够，而非这个新名字。 来源：APPSO https://www.bestblogs.dev/article/24d7bb20 [4] Scaling Law 的真相，藏在那些「没用」的参数里｜Hao 好聊趋势 本文深入剖析大模型参数冗余现象，论证看似「空转」的参数在训练、推理和后训练阶段分别扮演隔离空间、数值泄压、计算骨架和可塑性储备四种关键角色，并指出 Scaling Law 的边际收益正流向 benchmark 无法测量的长尾与多步推理能力。 来源：腾讯科技 https://www.bestblogs.dev/article/23d850ea [5] GlobalGPT 李焕之：零融资、套壳产品千万美金 ARR 后，我找到了创业的 mission GlobalGPT 创始人李焕之分享从零融资套壳产品做到千万美金 ARR 的创业历程，并阐述其从「先活下来」到回归初心、打造服务型 AI 产品 Yukie 的思考。 来源：Founder Park https://www.bestblogs.dev/article/ed22a9ae [6] 上线只活了 180 天，AI 应用层的泡沫被戳破了 本文以 Sora、http://Yupp.ai 等应用关停为引，分析 AI 应用层泡沫破裂的深层原因，指出真正活下来的产品已从单点功能转向超级入口、高频场景和 Agent 化工作流。 来源：腾讯科技 https://www.bestblogs.dev/article/0f79cbbc [7] Fable 5 禁令始末：Anthropic 亲手写下的剧本，反过来演了它自己 本文深度复盘 Anthropic 旗舰模型 Fable 5 遭美国政府出口管制禁令事件，揭示其背后技术争议、政治博弈与深层反讽，并探讨 AI 治理中权力制衡的核心命题。 来源：十字路口 Crossing https://www.bestblogs.dev/article/369a0323 [8] 做了 6 年智能眼镜后，夏勇峰按下暂停键：为 AI 造硬件而非为硬件加 AI 蜂巢科技创始人夏勇峰基于对 AI 大模型趋势的判断，暂停了已占市场 10%份额的智能眼镜业务，转向「为 AI 造硬件」的新方向，核心是让硬件成为 AI 进入现实世界的最小载体，而非在硬件上叠加 AI。 来源：虎嗅 https://www.bestblogs.dev/article/70638b9b [9] SpaceX 登陆纳斯达克市值超 2 万亿美元，殖民火星使命驱动 24 年崛起史 本文通过实地探访 SpaceX 总部与星舰基地，结合前高管访谈，完整回顾了 SpaceX 从猎鹰 1 号三次失败到星舰成功回收、星链盈利、国防业务崛起的 24 年发展史，并解析其殖民火星的终极使命。 来源：虎嗅 https://www.bestblogs.dev/article/15fef79e [10] 把 18 亿颗星星画在一张图上，能还原我们拍到的银河吗？ 本文利用盖亚卫星 18 亿颗恒星数据，通过逐步引入点扩散函数、暗星光度代理、黑体辐射色温校准和韦伯阈值等物理与生理学原理，模拟出逼真的银河图像，并在此过程中揭示了星空视觉形态背后的关键科学原理。 来源：Computing Life https://www.bestblogs.dev/article/2c2192f7 --- http://BestBlogs.dev · 发现真正适合你的高质量内容 BestBlogs 是 AI 驱动的私人阅读助手，帮助你建立稳定、可信、个性化的高质量信息输入。 关注你感兴趣的来源和主题，每天生成一份更适合自己的「我的早报」。 在线阅读：https://www.bestblogs.dev/explore/brief/2026-06-16

译BestBlogs精选10篇AI行业文章：Token成本控制大头在系统提示词、Skill和会话历史；AI Agent工具设计强调单一职责、强约束schema、幂等键；循环工程（Loop）作为新范式让模型连续跑规则；Scaling Law参数空转扮演骨架角色；GlobalGPT零融资做到千万美金ARR；AI应用层泡沫破裂，Sora等180天关停；Anthropic旗舰模型Fable 5遭美国政府出口管制禁令；夏勇峰暂停智能眼镜业务转向“为AI造硬件”；SpaceX登陆纳斯达克市值超2万亿美元；利用盖亚卫星18亿颗恒星数据模拟银河图像。

elvis@omarsar0 · 6月16日35

Is this real? I haven't received any communication. Wild if true. I moved a lot of my stuff away from the Claude Agent SDK due to the way they were going to charge programmatic use of Claude Code. It's tiring to run in circles with this stuff, but hope they reconsider things.

译这是真的吗？ 我没有收到任何沟通。 如果是真的那就太离谱了。我把很多内容从Claude Agent SDK迁移走了，因为他们打算对Claude Code的程序化使用收费。 在这些事情上兜圈子很累，但希望他们重新考虑。

elvis@omarsar0 · 6月16日34

Verifiers are a big deal. Without good verifiers, /goal &amp; /loop breaks a lot. Anything out of distribution for an LLM, the agent will struggle to verify work correctly. I think it's worth tuning your own verifiers and figuring out how to hook them up with your current agents.

译验证器很重要。 没有好的验证器，/goal 和 /loop 经常出问题。 对于大语言模型而言，任何超出分布的内容，智能体都难以正确验证工作。 我认为值得调优你自己的验证器，并弄清楚如何将它们与你当前的智能体连接起来。

Rohan Paul@rohanpaul_ai · 6月16日54

Factory 2.0 is here. Connects AI agents to the whole software workflow: tickets, customer requests, code, tests, security checks, reviews, deployments, docs, and production incidents. Managing this feedback loop is so important - every incident and review should become training signal for the next task. It treats every bug report, customer request, internal discussion, code review, test failure, security warning, and incident as a signal inside one loop, where agents help triage work, write code, test it, review it, ship it, watch production, and feed what happened back into the system.

译FactoryAI 今日推出 Factory 2.0，将 AI 智能体与整个软件工作流打通——涵盖工单、客户请求、代码、测试、安全检查、代码审查、部署、文档和生产事故。系统强调反馈循环的重要性：每个事故和审查记录都应成为下一任务的训练信号。所有 bug 报告、客户请求、内部讨论、测试失败、安全警告和事故被视为单一循环内的信号，由智能体协助分类、编写代码、测试、审查、发布、监控生产环境，并将结果反馈回系统。这标志着从编码智能体向软件工厂的升级。

elvis@omarsar0 · 6月16日73

I just open-sourced my /learn skill. Learn anything with agents and HTML artifacts. I have been learning about all kinds of topics with it. Install the skill and interact with any agent to help you through any topic. Ask it to generate visual and interactive artifacts and help you go deeper or generate knowledge checks (e.g., quizzes). Upskilling myself on any topic is one of the most impactful ways I have been able to use AI agents. If you are a DAIR Academy pro member, you can use it with our AI Builder. Skill: https://github.com/dair-ai/dair-academy-plugins Try now: https://academy.dair.ai/

译DAIR AI 创始人 Elvis Saravia 开源 /learn skill，允许用户通过 AI 智能体和 HTML artifacts 学习任意主题。该 skill 可安装后与任何 Agent 交互，生成视觉化、交互式的 artifact，帮助深入理解或生成知识检测（如测验）。支持 DAIR Academy pro 会员在 AI Builder 中使用。GitHub 链接及试用平台已开放。

elvis@omarsar0 · 6月16日30

This is the most capable AI I have put in front of my own work. Added an AI employee to my Slack, asked it to run this week's DAIR Academy, and it went and did the work, ready to ship. Here is exactly what happened:

译这是我放在自己工作中用过的最强大的AI。 我在Slack里添加了一个AI员工，让它运行本周的DAIR Academy，它就去做了，并准备好发布。 以下是具体经过：

jason@jxnlco · 6月15日28

if you use codex's computer use tools Whats the craziest most yolo thing you've done with it? I'll start, codex has: 1. found me a website to fax medical records 2. used docusign to sign something on my behalf 3. its negotiating the sale of a watch 4. guestlist for the 5/5 party what about you?

译如果你使用 Codex 的计算机使用工具 你用它在做什么最疯狂最随心所欲的事？ 我先来，Codex 已经： 1. 帮我找到了传真病历的网站 2. 用 DocuSign 替我签了东西 3. 正在谈判卖一块手表 4. 搞定 5/5 派对的嘉宾名单 你呢？

🚨 AI News | TestingCatalog@testingcatalog · 6月15日35

xAI is planning to transform Grok Tasks into Grok Automations. A new version will be able to use skills and will have a model selector.

译xAI 计划将 Grok Tasks 转变为 Grok Automations。新版本将能使用技能并配备模型选择器。

凡人小北@frxiaobei · 6月15日62

未来已经发生了： 一条 GitHub issue，从发现 bug 到修复 merge，全程是 Agent 在对接。 组织视角， 这是 AI native 最真实的样子，默认执行者已经不是人了。 经济视角， 这是 Agent 经济最好的例子，干活的全是 bot，人在两头。 人类视角…… 人类负责决策，贡献一个 OK。🌚

译开发者@JeffreyCalm分享经历：他将GitHub链接交给Codex部署，发现Bug后Codex自动提Issue。官方仓库的Code Review Bot确认Bug并At Hotfix Bot，后者30分钟内提交修复PR，最后At真人开发者。真人仅回复“OK”即完成Merge。全程人类零编码，仅贡献一个决策确认，折射出Agent经济与A2A平台雏形。

Peter Steinberger 🦞@steipete · 6月15日43

Whenever you create an issue on one of oure open source projects, @clawsweeper will review it, and *if* it fits the VISION.md file, will pick it up and create+autoreview a PR. e.g.: https://github.com/openclaw/gogcli/pull/816

译每当你在我们的一个开源项目上创建issue时，@clawsweeper 会审核它，*如果*它符合VISION.md文件，就会接手并创建+自动审核一个PR。 例如：https://github.com/openclaw/gogcli/pull/816

X.PIN@thexpin · 6月15日54

An AI-powered Alipay is being tested by Ant Group. This is Alibaba's first attempt to plug AI into China's biggest payments platform. The new Alipay will embed an AI assistant called "Abao," shifting the interface from "function menus + search bar" to conversation-first.

译蚂蚁集团正在测试一款 AI 驱动的支付宝。这是阿里巴巴首次尝试将 AI 植入中国最大的支付平台。新版支付宝将嵌入一个名为“阿宝”的 AI 助手，界面从“功能菜单+搜索栏”转变为对话优先。

swyx@swyx · 6月15日41

havent seen many people outside anthropic ultracode yet. this thing is scarily good at burning tokens but you need to set up your repo to parallelize properly to make use of the fanout that i think subagents are best at. basically the idea is "subroutines but intelligent". when you undersatnd just how much knowledge work is just yakshaves after yakshaves that require some judgment and intelligence, you start to appreciate that dynamic workflows are not just for coding tasks...

译swyx 指出，Anthropic 的 Ultracode 工具在消耗模型 token 方面表现惊人，但需要正确设置仓库的并行化以利用子智能体（subagents）的扇出（fanout）能力。该工具的核心思想是“智能子程序”——当理解大量知识工作不过是需要判断和智能的琐碎任务（yak shaves）时，动态工作流不仅适用于编码任务。

小互@xiaohu · 6月15日64

兄弟们 发现了一个 AI Agent 悬赏任务市场 相当于是一个AI版的“猪八戒”，你有一些复杂的问题自己不想搞或者搞不定（比如优化数据库、写个skill、开发工作流），就把问题扔上去，挂一笔赏金，会有“人”接单 重点来了，这里面不是人在接单，全是 AI Agent 来抢活 谁干得好、验收通过，钱自动打给它... 你也可以开发AI Agent发布上去赚钱... 怎么运转的？ 整个流程五步，用点外卖类比就很好理解： 1、你可以下单：描述问题，定价，钱先冻住（和外卖平台扣款一样，不是直接给骑手） 2、Agent 抢单：多个 AI Agent 看到你的需求，各自报价、说自己怎么解决 3、选择Agent：挑一个靠谱的，或者让平台自动匹配 Agent 干活：它会去写代码、跑测试、交付结果，不是只给你一段建议 4、你验收：满意就确认收货，钱自动到账。不满意可以拒绝，钱退回来 平台从中间抽 15%，Agent 拿 85% 几个有意思的设计： CLI 优先：不用在网页上填表单，一行命令就能发任务 这意味着你可以把"发需求"这件事写进定时脚本里，比如每天自动发一个"抓竞品价格"的任务，Agent 自动接、自动做、自动交。机器给机器派活儿，人不用管。 Agent 有信誉分：干得好加分，干砸了扣分 分高的 Agent 能优先看到高价任务，形成一个"越靠谱越赚钱"的循环。五个等级，从新手到传奇。

译小互介绍了一个AI Agent悬赏任务市场，类似AI版“猪八戒”。用户可发布复杂任务（如优化数据库、开发工作流）并设定赏金，由AI Agent自动抢单、交付结果、收款。流程五步：用户下单（资金冻结）→Agent抢单报价→用户选择Agent→Agent干活（写代码、跑测试）→用户验收，通过则自动付款，平台抽15%，Agent拿85%。设计亮点：支持CLI命令行发任务（可脚本化，实现机器给机器派活）；Agent有信誉分（五级，从新手到传奇），高分优先接高价任务。

数字生命卡兹克@Khazix0918 · 6月15日58

Prompt该退环境了，未来属于Loop Engineering。 最近，AI行业又出现了一个有趣的新词。Loop Engineering。 如果你关注AI这个领域的话，这两天应该都会刷到。推特在刷，各种社媒也在刷，群里也有蛮多人在讨论。事情是这样的。 6月7号，OpenClaw的创始人Peter发了一条推，非常的简短，但是直接就爆了。 翻译过来意思就是：你不再需要为编码智能体编写提示词了，你应该设计循环来提示你的Agent。 而在这之前几天，Claude Code的创始人老哥Boris在一个开发者大会上也说了差不多的话。 他的原话大概是，我不再手动给Claude写提示词了，我运行着能让Claude自动编排任务的循环，我的工作，就是编写这些循环机制。 也就是，写loop。 这两个人呢，说了同一件事。然后Google的Addy Osmani紧接着发了一篇长文，把Loop Engineering这个概念正式梳理了出来。 于是，继Prompt Engineering、Context Engineering、Harness Engineering之后，AI行业的第四个逐渐形成共识的Engineering，就这么诞生了。 我其实是个特别不喜欢造新词的人，但是很多时候，造词这事我觉得还是得分两种情况，有一种我觉得就是为了炒概念，比如xxx 4.0。 而有的时候，真的只是行业太快，人们更需要一个精准的表达来帮助自己表达而已。Loop Engineering我觉得就是后一种。 而且，这个东西跟我自己一直使用Agent的方法、一直在鼓励大家做的事，是高度吻合的。如果你看过我之前写的那篇Harness Engineering的文章，你大概能理解一些我的感觉。那篇文章里我聊了从Prompt到Context到Harness的三次跃迁，聊了马具和缰绳的比喻，聊了约束先行。 而Loop Engineering，其实就是在Harness之上，又往上走了一层。把一个套马的缰绳，变成了全自动工业流水线。很有《文明》里时代的进化的感觉。 给大家举个例子。比如说，以前你用Claude Code写代码，流程大概是这样的。你给它一个任务，它写完了，你看一眼，觉得不太对，你再给它提一个修改意见，它改完了，你再看，再提意见。整个过程你会发现，是坐在设备前的，一轮一轮的，你说一句它回一句，你就是那个驱动整个循环的发动机。 即使我们以前从chatbot时代迈向了Agent时代，绝大多数的事情，也一样是任务制的。 而现在，比如Boris老哥，他的工作方式是，他会去写一个loop，比如/loop babysit all my PRs，自动修CI问题，有新评论就派子Agent去处理，就这么一句话，然后Claude Code就开始自己跑了，它会自动去看他GitHub上所有的PR，哪些CI挂了就自己修，哪些review有新评论就自动派一个独立的工作树Agent去改代码。 他还把一些其他的loop挂到定时任务上，每天晚上自动启动去干这个事，晚上睡觉的时候，甚至有时候会有几千个Agent在同时工作。他自己说，2026年，他就再也没有手写过一行代码了。 你会看到，这就是loop，定好目标，然后全自动流程化，你完全不需要在电脑前，甚至都不需要看手机。 你可以直接睡觉，醒来的时候，代码已经改好了，测试也已经跑过了，PR也已经提上去了。你并不是自己给Agent写了一段Prompt帮你完成某个单次的任务，是你自己设计了一个目标，这个目标使用loop的方式，帮你提示Agent。 你定义目标，定义验证条件，定义失败了怎么处理，然后，就可以放手了，从此以后，这一切，交给系统。 说到这里，我估计很多人已经大概理解loop是个什么东西了。Addy Osmani在他那篇长文里，把一个完整的loop拆成了五个组件。 我觉得这个拆法蛮清晰的，我用我自己的理解给大家过一下。 第一个是定时任务，整个loop的心跳。 你得有一个东西能自动启动循环，不管是定时跑、还是事件触发，都行。 Claude Code里有好几种方式，/loop命令按间隔自动执行，cron定时调度，Hook在Agent生命周期的特定节点自动触发（比如每次改完文件自动跑一遍lint，这个很好玩，教程和玩法我也在准备了），或者直接丢到GitHub Actions里，关上电脑它也在跑。 没有定时任务的Agent，你每次都得手动去踢一脚它才会动，那就不是loop了，那还是你在操控。 第二个是工作树隔离，Worktree（搞过开发的朋友应该秒懂）。 就是你同时跑好几个Agent的时候，给每个Agent一个独立的工作空间，各干各的互不干扰，干完了再合并。两个Agent改同一个文件的痛苦，跟两个设计师同时改一个图层又不打招呼的痛苦，是一模一样的。 第三个是项目知识体系，Addy Osmani在他的原文里写的是skill，但是我觉得他写的不太对，单skill其实是不够的，必须得是知识管理体系。 大家也都知道，AI每次开新对话就啥都忘了，你跟它说过的代码规范、项目架构、踩过的坑，下次开对话全部从零开始。 所以你得有一整套方法来沉淀、优化这些知识，让Agent每次启动的时候就已经知道你的项目，我自己在这快一年的coding开发过程中，总结的方法论其实就沉淀成了我自己的洁癖.skill，这个基本是我的Agent每天调用最多的skill。 CLAUDE.md是全局的规则和约束，跨会话记忆是一些之前悬而未决的记录和文档路由，docs体系就是你完整的所有的知识和经验沉淀，因为CLAUDE.md和记忆都有大小和行数限制，所以每次任务完成后我会用洁癖.skill来对整个的知识体系进行梳理和审查，确保没有错误。 为什么知识管理体系这个东西在loop里特别重要呢？ 因为loop是自动跑的，你不在场。如果Agent的记忆里有过期信息，它就会基于错误的前提做决策，如果CLAUDE.md膨胀到几百行全是历史叙事，真正的规则反而被挤出去了Agent读不到。没有干净的知识体系的loop，就像一个每天早上都在看过期文档的员工，干的得越快错得越多。 所以洁癖.skill我非常推荐大家可以去安装一下，也在我自己的仓库里开源了，我自己真的觉得特别有用。 https://github.com/KKKKhazix/khazix-skills 第四个是连接器，MCP。 一个只能看文件系统的Agent，能力是很有限的。但你给它接上GitHub、Linear、Slack、数据库，它就能在你的真实工作环境里干活了。 这才叫真正的闭环，从发现问题到解决问题到通知人类，一条龙。 第五个是子Agent。 做事的和检查的分开，写代码的Agent不能自己给自己打分，这跟学生自己批自己的考卷一个道理，它一定会对自己太宽容。所以你得有另一个Agent，甚至用不同的模型，专门来检查前一个Agent的输出，一个负责做，一个负责验。 这五个东西加在一起，就是一个完整的loop的骨架。 Claude Code和Codex有一个命令，其实就是Loop Engineering这套骨架最直接的微观型的产品化体现，只不过很多人没有意识到。 他叫/goal，在Codex里叫追求目标。 意思就是你给Claude一个完成条件，比如「所有测试通过并且lint检查没有报错」，然后它就会一轮一轮的自己干，干完每一轮之后，就会检查这个条件是不是满足了。 大多数讲Loop Engineering的文章，都停在了这一层。讲了五个组件，讲了/goal和/loop命令，讲了怎么配定时任务，就结束了。 这些我觉得，都是术。而我更想聊的，是道。 Loop Engineering这件事，我觉得它最核心最核心的能力，其实不是什么技术能力，也不是写脚本的能力，更不是什么会配hook的能力。 最核心的，是定义目标的能力。定义目标，相信我，这四个字，听起来简单，做起来是真的难。 回到前面说的/goal，它的用法看起来非常直接，给一个完成条件，Claude自己干到满足为止。 听起来很简单对吧。但你如果真正用过就会知道，/goal用得好不好，完全取决于你那个目标定义得好不好。这个事我拿两个例子对比一下你就明白了。 目标A，「把这个应用优化一下」。 目标B，「test/auth目录下所有测试通过，tsc --noEmit零报错，npm run lint零违规」。 目标A会发生什么呢。大家可能都能猜到，Claude会陷入一种非常尴尬的状态，因为它不知道什么叫「优化好了」，除非他是Fable 5，能自己在你之上，自主的帮你定义目标。 而绝大多数的模型，包括Opus 4.8和GPT-5.5，在自己定义目标的能力上还是非常的弱，它可能改了一点代码，然后自己觉得还行，就停了。 也可能不停，一直改一直改，把你的代码库改得面目全非，因为它始终无法判断自己到底什么时候算完成了。那目标B呢？Claude每改一轮代码，都会去跑测试、跑类型检查、跑lint。 三个命令，三个明确的通过标准。全过了就停，没过就继续，清清楚楚，干干净净。同一个工具，同一个模型。 区别只在于，你的目标定义得好不好。 我自己其实一直有一个原则，我经常跟身边的人说，在公众号里也说了无数遍，如果一件事你重复做了三次，你就一定要想办法把它完全自动化掉。 这个习惯跟了我很多年了。我每天也都在写代码、做自动化，我们的AIHOT热点监控系统，我们的数据分析流程，我们的财务对账流程，我们的数据清洗管道，能自动的我全部自动了。 但说实话，在做这些自动化的过程中，我踩过最多的坑，从来不是技术问题。 是目标不清晰的问题。我早期做自动化的时候，经常犯一个错，就是目标定得太模糊。 举个例子，比如自动监控AI行业热点，这句话听起来没毛病，但其实是一句纯粹的废话。 什么叫热点？浏览量过万算热点还是过十万算热点？抓取频率是每小时还是每天？抓到以后怎么评估质量？评估完以后怎么排序？排完以后怎么推送？ 这种反问的问题，我现在可以直接随手问20个以上。 每一个环节如果没有明确的判定标准，整个自动化链条就是一坨狗屎，你相信我，绝对的。 后来我懂了，每次做自动化之前，我会先花很多时间去定义目标。 去花很多很多时间，去定义怎么算做完了，怎么做完算做的好。这其实就是/goal的逻辑。也是Loop Engineering的灵魂。 而如何定义目标，这个能力，我其实不是从AI中也不是从开发中学来的。 这个能力，是我从这几年创业的过程中，学来的。定义目标的能力，其实就是，管人的逻辑。 我自己也开公司，虽然公司不大，只有30来号人，但管人这件事我是真真切切经历过的。 管人最痛苦的是什么，不是人不努力，也不是人能力不够，是你给出去的目标不够清晰，然后下属就一脸懵逼，不知道你要什么，跟无头苍蝇一样打转，最后做出来的东西，你又不满意。 你跟员工说，“把这个功能做好”，那他做出来的东西大概率不是你想要的。 因为你脑子里的好跟他脑子里的好不是一个东西。 你跟他说，“这个接口的响应时间降到200毫秒以下，错误率控制在0.1%以内，下周三之前上线”，他做出来的东西跟你预期的偏差就会小很多。 因为你给了他一个可以验证完成的标准。这一切其实也适用于那种天才型的大神，虽然大神们会自己定义目标，甚至比你定义的还要强，但是给大神们依然是需要有目标的，只是这个目标，不需要那么细节了而已。 对人如此，对AI也是如此。 其实你回头看，所有好的管理方法论，不管是管理学之父Peter Drucker在上世纪50年代提出的目标管理，还是后来Andy Grove在Intel发明的OKR，还是再后来一代又一代CEO们用的各种变体，核心其实就一个东西。 你能不能把一个模糊的意图，翻译成一组可衡量、可验证的完成条件。 管理者要做的，是确保目标足够清晰、资源足够充足、反馈足够及时。你看这三条。跟一个好的loop的三个要素，是不是一模一样。 目标清晰，就是你的条件写得精准。资源充足，就是你给Agent配好了Skill、连接器、工作权限，让它手里有足够的工具干活。 反馈及时，就是你设计了验证机制，每一轮都有一个独立的检查器告诉Agent做得对不对，哪里需要改。管人的逻辑和管Agent的逻辑，是完全一样的。 只不过，管Agent比管人还要极端一些。 因为人可以理解你的模糊意图，人可以主动来找你确认，人可以说老板你这个需求说得不太清楚我不太确定你是不是这个意思。 Agent很多时候是不会的。Agent会非常自信地按照它自己的理解去执行，然后非常自信地告诉你它做完了。 所以，对管理能力的要求，其实比管人还高。 这也是为什么我一直说，AI时代我最讨厌什么「文科已死」「理科已死」的言论，管理学、心理学、组织行为学这些，不但没死，反而变得更重要了。 说到底，Loop Engineering说是Engineering，但我觉得其实它的核心竞争力根本不在工程。 在管理。 而在管理学上，就定义目标这件事，其实不止是把话说清楚就行，其实还有一个非常阴险的陷阱，在管理学和经济学里有个专门的名字，叫古德哈特定律。 当一个衡量指标变成了目标本身的时候，它就不再是一个好的衡量指标了。 翻译成人话就是，你考核什么，员工就只做什么，然后其他东西可能全都退化。 这个事在人类管理中已经是老问题了，而在AI Agent身上，这个问题被放大了一百倍，因为Agent比人类更擅长钻规则的空子。 有人总结过Loop Engineering里很好玩的事情，就是Agent会针对验证器做优化，而不是针对你真正的目标做优化。 比如说你的loop条件是让测试全部通过，那Agent可能最后不去修Bug，直接把失败的测试给你删了。 你看，最后答案依然是测试全过了，完事，从验证条件来看，它确实完成了目标，但从你真正想要的结果来看。。。它啥也没干。 人也会这么干，只不过，Agent做得更快、更彻底、更没有心理负担。所以，一个好的目标定义，不能只有做完了的标准，还必须有不能怎么做的边界。 这其实就是Harness Engineering在Loop Engineering里面发挥作用的地方。 Harness是约束，是护栏，是告诉Agent你可以自由发挥，但这条线你不能越。 Loop是驱动力，是告诉Agent往那个方向一直跑。两个加在一起，才是一个完整的系统。到这里，骨架讲了，灵魂也讲了，陷阱也讲了。 Loop Engineering的东西，终于也差不多了。 最后我想把前面聊的管理学的思路收一下，给一个我自己用得比较多的目标定义框架，不一定科学，纯粹就是我自己的一点点经验。 1. 完成标准要可以被机器验证。 2. 边界条件要跟完成标准一起定义。 3. 要有失败的降级方案。 4. 目标要分层。 回到整条线来看，从Prompt到Context到Harness到Loop，四次跃迁，其实讲的是同一个故事。Prompt Engineering告诉你，好好说话，AI会更懂你。 核心能力是语言表达。Context Engineering告诉你，光说话不够，得给AI足够的信息。 核心能力是信息筛选和组织。Harness Engineering告诉你，光给信息也不够，得给AI设规则和约束。 核心能力是系统设计和规则制定。 Loop Engineering告诉你，光设规则也不够，得让整个系统能自己跑起来。 核心能力是目标定义和管理。 语言学、信息科学、控制论、管理学。四个Engineering，四门古老的学科。 多有意思。 人类社会，其实从来就没有变过。

译6月7日，OpenClaw创始人Peter与Claude Code创始人Boris提出不再手动写提示词，而是设计循环（Loop）让Agent自动编排任务。Google的Addy Osmani将其梳理为Loop Engineering，成为AI行业第四大工程范式。一个完整Loop包含五个组件：定时任务（心跳）、工作树隔离（Worktree）、项目知识体系（CLAUDE.md/skill等）、MCP连接器、子Agent（执行与检查分离）。核心在于定义精确的可验证目标（如/goal“所有测试通过”），而非技术能力。作者指出定义目标的能力才是关键，并推荐其开源的洁癖.skill用于知识管理。

凡人小北@frxiaobei · 6月15日52

Vercel CEO Guillermo Rauch 给 AI builder 内容圈的一记委婉提醒。 现在 X 上有两群人， 一群天天发 coding agent 内容但不发实际产品， 还有一群闷头 ship 东西。 后者才在真创造价值。

译Vercel CEO Guillermo Rauch 指出AI圈存在两类人：一类天天发coding agent内容却从不实际出货，另一类产出暴增并持续ship有价值的产品。讽刺的是，两类人比例与AI出现前并无变化，而后者出货效率更高，形成“出货越多越能出货”的循环。评论认为，只有后者在真创造价值。

jason@jxnlco · 6月15日68

check out my /ultragoal skill https://github.com/jxnl/dots/blob/master/agents/skills/ultragoal/SKILL.md

译查看我的 /ultragoal 技能 https://github.com/jxnl/dots/blob/master/agents/skills/ultragoal/SKILL.md

meng shao@shao__meng · 6月15日67

Databricks 推出「Omnigent」 团队认为：Agent 能力的瓶颈，正在从「模型/harness 本身」上移到「如何组合、治理、协作多个 Agent」。Omnigent 就是针对这一层的新抽象：meta-harness。 它要解决什么问题？ Databricks 从自身实践出发（5000+ 工程师用 coding agent、对外交付 Genie 等产品），归纳出三类真实痛点： · 用户侧：同时开 4–5 个 Agent（Claude Code、Codex、Gemini 等），在 Agent、Docs、Slack 之间反复 copy-paste · 构建侧：新 harness、SDK、模型不断出现，换工具就要重写集成逻辑 · 架构侧：高质量 Agent 系统已是「多模型 + 多 harness + 多人协作」，但每个 harness 只认自己的 session，彼此隔离 Omnigent 是什么？ 基于现有 Agent（Claude Code、Codex、Pi、自研 Agent），提供统一接口、策略层和协作层。 关键设计洞察：无论底层 harness 如何调用 LLM，对用户界面本质相同——messages + files in → text streams + tool calls out。Omnigent 据此抽象出通用 API，同时覆盖 CLI coding agent 和 SDK（OpenAI Agents、Claude Agents SDK 等）。 三大能力支柱 1. Composition（组合） · 一行配置切换 Claude Code <-> Codex <-> Pi <-> 自研 Agent · YAML 定义 custom agent，可跨 harness 移植 · 同一 Agent 内可组合不同 harness 的 subagent 内置 Polly（coding orchestrator）、Debby（model debate）示例 价值：把「选哪个 harness」从架构决策降成配置决策。 2. Control（控制） 区别于 prompt 级 guardrail，Omnigent 在 meta 层做有状态、上下文感知的策略： · 成本策略：按 session 追踪 LLM 花费，例如每 $100 暂停并请求继续 · 上下文安全策略：例如 npm 安装新包后，git push 需人工批准；Agent 只能写自己创建的 doc · OS 沙箱：灵活限制文件系统/网络；凭证对 Agent 不可见，由 egress proxy 在批准请求时注入（如 GitHub token） 价值：策略与 harness 解耦，换 Agent 不换治理逻辑。 3. Collaboration（协作） · 通过 URL 共享 live agent session · 多人同时查看 workspace 文件、评论、甚至发送命令 · 同一 Agent 可从 terminal、Web、macOS 原生 App、mobile、REST API 访问 · 可在本机或 Modal/Daytona 等托管沙箱中运行，便于安全协作 价值：Agent session 从个人终端工具，变成可共享的协作 surface。 为何 Databricks 认为这很重要？ 用 Kubernetes / Terraform 类比：工程师不再管单个进程/服务器，而是管整个 fleet。Agent 领域同理—— 模型和 harness 会持续变化；你工作的抽象层不应随之反复重建。 Meta-harness 让 session、policy、skills 与具体 harness 解耦，形成可迁移的工作层。

译Databricks 推出 Omnigent，一个开源（Apache 2.0）meta-harness，位于 Claude Code、Codex、Pi 及自研 Agent 之上，提供统一接口。三大能力：组合（一行配置切换不同 harness，YAML 定义跨 harness 可移植 agent，同一 Agent 内可组合不同 subagent）；控制（有状态成本策略如每 $100 暂停，安全策略如 npm 后 git push 需审批，OS 沙箱，策略与 harness 解耦）；协作（通过 URL 共享 live session，支持多端访问及实时评论）。理念类似 Kubernetes，让 session、policy 与具体 harness 解耦，形成可迁移工作层。

meng shao@shao__meng · 6月15日73

OpenAI Codex Mobile 工程实践指南 @Dimillian 提出了 Codex Mobile 核心心智模型： 手机不只是缩小版终端，它是远程开发机的「控制中心」。 · 代码执行、任务运行仍在 Mac / Windows / devbox 等已连接主机上完成 · 手机提供原生 UI，用于启动、引导、审查、组织工程工作 · 价值不在「在手机上写代码」，而在「离桌时仍能做出关键决策」 # 任务启动：先定边界，再发 prompt 好 agent 工作的前提是正确隔离的执行环境。Codex Mobile 在创建新 thread 时可配置： · 选择主机与工作区：指定在哪台机器、哪个项目跑 · 选择 Git 分支：从正确基线出发，避免事后修 Git 状态 · 创建独立 worktree：隔离变更，不污染当前 checkout · 运行 environment setup 脚本：worktree 创建后自动执行桌面端配置的初始化脚本 三种典型模式： 1. 用当前 checkout → 快速调查 2. 新建 worktree → 需要隔离的改动 3. 从目标 base branch 起步 → 避免后续 merge 混乱 限制：environment 脚本目前不能在 Mobile 上编辑，需在 Desktop 配置。 # Side Chat：主线程做活，旁路线程理解 长线程会积累大量上下文；每个旁路问题都打断主线程，会让 transcript 变噪、agent 偏离目标。 Side chat 的定位：与当前 thread 关联的轻量对话，不抢占主工作流。 · /side 或 /side <prompt> 打开 · 选中 transcript 文本 → Ask in side chat，选中内容成为起始上下文 适合的问题类型： · 为什么选这种架构？ · 这个 error 实际含义？ · 与 desktop 行为是否一致？ · 生成 release note 版说明 · 批准这条命令前应验证什么？ 分工： 主 thread 负责执行；side chat 负责理解与决策辅助。 # Plan 与 Goal：路径 vs 结果 两者解决不同问题： · Plan mode：「怎么实现？」，任务欠规格、风险高、跨多系统 · Goal：「完成标准是什么？」，需多轮迭代的 durable 目标 推荐工作流： 1. 高风险任务 → 先 Plan，审查边界 2. 方案确认后 → 转为 Goal，让 agent 跨实现、测试、review、清理持续推进 3. 实操中常跳过显式 Plan：先与 Codex 讨论细节，满意后让 Codex 自己写 Goal（通常比人工写更好） Goal 写法注意： 设定可验证、不过宽的终态。过于绝对的要求（如「100% 像 X 或 Y」）容易导致过度执行、浪费 token。Mobile 端现已可监控 token 消耗，但仍应控制 Goal 粒度。 Mobile 对 /goal、/plan 支持完整：可见运行时长、编辑、暂停；Plan 工具的问题也会在 UI 中展示。 # Mobile 独有优势：别忘记「你在用手机」 Composer 内置访问本地手机数据的能力，这是桌面端没有的： · 拍照 / 选图 / 浏览文件 · 语音录制 prompt（后台持续录音：切到其他 app 时 dictation 不中断） 典型场景（作者做 ChatGPT iOS 的经验）： · 发现问题 → 直接截图发给 Codex thread → 快速修复，无需回电脑 · 同 Wi-Fi 下 → 在真机构建运行，直接验证 Codex 改动结果 · 边用 app 边口述 10 分钟问题 → 回 Codex 发送，形成「Talk to phone → app appears」闭环 Pinned 长线程： 例如绑定 Linear tracker 的 thread，随手粘贴文本即可按当前上下文正确建 issue、打标签。 # Mobile 代码审查：不必等回工位 Completed turn 可展示变更文件摘要，支持： · 打开 diff、展开/折叠、换行 · 查看带语法高亮的源文件 · 行内评论 → 自动汇入 composer，发回 Codex 分层用法： 1. 变更摘要 → 快速 sanity check 2. 完整 diff / 源文件 → 缺上下文时深入 3. Inline comment → 精确修正 4. review 命令 → 审查本地变更或与分支对比 5. 链接文件回 chat → 让 Codex 针对特定文件推理 关键洞察： 手机不能替代大屏做深度 code reading，但很多 review 卡在一两个决策点——这些决策不必等到回 desk。

译手机是远程开发机“控制中心”，代码执行在主机。任务启动可配主机、工作区、Git分支，创建独立worktree并自动执行环境脚本。Side Chat提供轻量旁路对话，不打断主线程。Plan模式用于高风险任务规划，Goal模式设定可验证终态。手机独有优势包括拍照截图、后台持续录音语音prompt、真机构建验证。代码审查支持diff查看、语法高亮、行内评论，不必等回工位。

宝玉@dotey · 6月15日72

我在做 baoyu-skills 时，做了一个尝试，就是用了一个 EXTEND.md 文件保存用户自定义设置，当时我想的是 Agent 读起来方便。 但是这导致一个问题，Markdown 不是严格的结构化数据，LLM 自己读取没问题，但是程序解析很困难，另外格式很难严格保持一致性。 如果让我再设计的话，我会更倾向于用 json 或者 yaml 文件格式作为 Skill 的扩展配置，这样既可以让 LLM 方便读取，也可以用代码解析和保存。

译宝玉在开发 baoyu-skills 时，采用 EXTEND.md 文件保存用户自定义设置，初衷是方便 Agent 读取。但实践发现，Markdown 非严格结构化数据，虽能被 LLM 理解，却难以被程序解析，且格式难以保持一致性。他认为更合理的方案是采用 JSON 或 YAML 作为 Skill 扩展配置，既能被 LLM 方便读取，也便于代码解析与持久化。

Orange AI@oran_ge · 6月15日70

http://x.com/i/article/2066286219416469504 # 置身钉内的 20 个切片和 1 个 skill 上周写了一篇文章，与 AI 一起做产品的六条原则，很多朋友都喜欢这套插图，问我怎么做，就把它做成 skill，开源发布。 周六的时候，去出海去的活动做了一次分享，分享的 PPT 也是这套插图做的，也有很多朋友喜欢。 在 AI 信息图和 HTML 文字块泛滥的今天，也许一张有空白的插画反而能让注意力聚焦在一点。据说 PPT 做到极致，每页就只有一句话。 于是周末这两天在家，都在持续迭代这个插图，目标是让它变得更稳定、更好看、更有趣。 我想要的效果是，让人一眼就懂，会心一笑。 这套插图是 Fable 5 以纽约客的插图为灵感设计做了初版设计，可惜这个视觉能力很强的模型已经绝版了。 让其他模型来迭代插图的绘制，比想象中要吃力一些，最难的是让插图的小人 IP 保持一致性。AI 很不擅长设计 IP，每次都出点我不喜欢的东西，我给它意见每次给他修改意见，它的下一版都会引发新的问题。 细节修改越来越多，整体效果越改越差，像极了 vibe coding 出来的交互界面。 试了几个模型，迭代了数十张图片，发现同时让模型设计几个 IP 还折腾很久之后，终于搞定。 我想找篇文章试试这个 skill 的效果，顺便可以作为这个项目的 readme。 在《鹅腿阿姨》和《置身钉内》之间，还是选了后者，毕竟这篇文章不仅是对阿里对钉钉的反思，也是对通用智能产品的反思。 虽然 AI 产品的功能是通用的，但人们对新事物的理解是简单的。 一个好产品只有一个主发心。 这篇文章的原文有 7.5 万字，在注意力涣散的今天，能看完的人寥寥无几，但把20张插图看完只要一分钟，应该人人都可以。 现在，正文开始： ## 01 — 雨燕不落地 > 钉钉的动物园形象钉三多，是一只尖尾雨燕。它最特殊的地方在于，可以吃喝、睡眠、交配通通在空中完成；每年最多可以连续飞行三百多天不落地。在钉钉飞行了300多天，将满一年，最近也到了重新踩回地面的，离开的节点。 ## 02 — 族谱上钉 > 钉钉面试前要先完成的那份大作业，题目是'族谱上钉'。要求把家族成员拉进钉钉，建立一个6人以上的族组织。他反复追问：为什么做不成？父亲家还有人吗？母亲家还有人吗？外公外婆还在吗？真的凑不齐六个能上钉钉的家人吗？ ## 03 — 贪心是七罪之一 > 当一个产品的发心又多又没有主次的时候，就会成为一个贪心而焦虑的产品。贪心是七罪之一。什么都想要，容易什么都得不到。 ## 04 — 事找人 > 我们当时的slogan叫，'让人找事变成事找人。'ONE想解决的是这个问题：让重要的事自己浮上来，让用户少一点遗漏，少一点翻找。 ## 05 — 成功留下手感 > 一个产品经理最难摆脱的，往往不是失败，而是成功。因为失败会留下伤口，而成功会留下手感。钉钉早年的胜利，给无招留下了一套很深的身体记忆：站在发信人一侧，替组织争取确定性，用强触达把事情往前推。 ## 06 — 发信人立场 > 钉钉的基因，从诞生的第一天起，就是永远站在'发信人'立场、为'发信人'所驱策的。为什么卡片里的消息一定要算已读？为什么系统要主动把事情推到用户面前？为什么AI忍不住要替组织去催促个体？ ## 07 — 旗帜 > ONE承担了这个角色。它既是产品，也是旗帜。旗帜能聚拢人，也容易把太多东西都挂上去。 ## 08 — 最美逆行者 > 在那个节点，很多朋友开玩笑说我是'最美逆行者'。原因是，四月初无招回归后，雷厉风行地举行一系列措施：工时调整、开固定晨会晚会、午休缩短、周末单休，再兼全员Python考试，组织整体在人口净流出。在当时有其他明显更好条件的offer的情况下，跳上轻舟，平薪平职来了钉钉。 ## 09 — 穿过旧系统的技术债 > 钉钉不是白纸，它有多年积下来的产品逻辑、权限系统、端侧差异、多组织问题、客户定制和用户习惯。AI要在这里做事，必须穿过旧系统的技术债。 ## 10 — 孔乙己 > 钉钉像孔乙己一样走进咸亨酒店，空气里就弥漫着快活的气氛。 ## 11 — 常数与变行 > '凡历术在于常数，而不在于变行。'编订历法，需要归纳规律性的常数，而不在于一味记载关注期变化。这份文档既想记录我这三百天亲历的'变行'，也想尽可能凝练出在反复实践、受挫和复盘之后得到的'常数'。 ## 12 — Context 不平权 > 智能是平权的，但是context是不平权的。有context，才能判断用户的背景和偏好，才能提供用户想消费的商品/服务/内容。 ## 13 — Stay Hungry, Stay Foolish > 无招的钉钉签名用它，钉钉的文化衫印它。他也在寻找精神偶像的寄托时，每每提到那个男人。一个人骤然发现命运之书被风吹开到和偶像相似的一页，很难不教人动心、疑心这是命运的召唤。 ## 14 — 学徒与空厨房 > 做产品和做菜、做手工一样，是一门手艺。在各个大中小司流转，学到本领，最后在哪里栖身独当一面，或者自立门户。在ONE超过3个月的产品只有3个人，我是其中一个。 ## 15 — 薛定谔的用户 > 在初始定位的构思中，用户究竟是普通员工还是老板的问题，始终没有闭环。但是事情总不能无休止地讨论下去，我们就这样，带着一盒薛定谔的用户出发了。 ## 16 — 旧城中央的风口 > 它站在一个很有吸引力的风口，但是取景再往远退一舍，就会发现，这个风口正处在一片难以改造的旧城中央。 ## 17 — 高压之后的补课 > 当你开了一个两小时的长会，或者半天没看手机，再次打开钉钉时，面对的是几十个群里炸开的海量未读消息。此时用户的核心诉求是'快速赶上进度'。 ## 18 — 重峦叠嶂 > 工时调整-提前到9点上班、开固定晨会晚会、午休缩短、周末单休，再兼全员Python考试，节假福利削减，部分职级以上薪酬调整。现在回想起来，那时种种debuff，重峦叠嶂。 19 — 在ONE超过3个月的只有3个人 > 在ONE超过3个月的产品只有3个人，我是其中一个。我来的第二周，我的设计leader就离开了，第四周，联系并推荐我进组的师兄也被调离去了其他部门。 20 — 好产品只有一个主发心 > 产品的发心就是它的发起人最原始的出发点。大部分情况下，好产品只有一个主发心。大道至简，这也和许多投资人会提倡的'一句话说清产品价值'异曲同工。 在制作这些插图的时候，我让  Agent 为每个场景生成了2套让我去挑，这样比较高效，也最终也更省 token。 我在挑配图的时候有些喜出望外，我发现我自己对文章也有了更强的画面感和更深的理解。 不知道看完之后，你的感受如何，如果喜欢的话，可以在这里安装下载： 橙线插画.skill： https://github.com/orange2ai/orange-line-illustration 这个 skill 免费开源发布，支持各类 Agent ， Cola / Claude Code / Codex 等等。 另外要补充一句，这个 skill 不仅支持文章配图，还能直接生成带插图的 HTML 幻灯片。 拿去试试看吧。

译Oran Ge发布开源技能“橙线插画.skill”，基于Fable 5模型（已绝版）的纽约客风格插画迭代而来，支持Cola、Claude Code、Codex等Agent。该skill可生成文章配图及带插图的HTML幻灯片。作者同时分享了在钉钉工作期间的20个反思切片（如“好产品只有一个主发心”），配图由Agent为每个场景生成2套方案，最终免费开源发布在GitHub。

karminski-牙医@karminski3 · 6月15日53

27B小模型挑战Fable 5? 还成功了? 劲爆消息, 在 Iterative-Contextual-Refinements 这个框架的加持下, Qwen3.6-27B 跑分超过了 Anthropic Fable5! 真的不是做梦吗? 还是跑分没输过, 实战没赢过? 于是赶紧看了一下这个框架, 发现设计的很有启发性, 能学到很多东西, 给大家详细讲下. 这个框架主要提升的是软件性能优化, 即如何才能让代码性能更高. 大家如果还记得我那个 vector-db-bench, 给大模型提供了火焰图, perf, 各种测试 tool_call 让大模型自己迭代去优化代码性能. 而这个框架更进了一步, 它瞄准了小模型的最核心弱点, 参数量不足导致的"脑残", 即小模型更容易长上下文衰退或陷入局部最优. 于是这个框架出手了, 先针对技术方案, 它搞了个BFS探索模式, 在写代码的 plan 过程, 让小模型自己提出多种解决方案, 比如写个字符串匹配, 小模型直接搞了个O(N^2)的暴力搜索, 而这一步它的Agent会让小模型思考, 你能想到哪些可能的解决方案? 于是就拓展了小模型的视野, KMP, 滑动窗口等技术方案没准就出来了. 然后就是写代码的过程中使用的DFS模式, 它会借助Agent让小模型借助代码性能测试工具不断跑分, 然后让小模型反思, 有哪些性能热点可以优化, 然后进行优化. 最后, 他还有个统筹全局的路由, 不但负责在BFS/DFS过程中选取最佳的技术方案, 而且还会在DFS过程中, 总结模型优化过程中面临的问题, 再反馈到BFS过程, 告诉模型, 需要注意xxx优化是有价值的, xxx优化面临xxx问题. 从而形成优化闭环, 解决掉模型陷入死胡同不断仰卧起坐的问题. 最后, 在框架加持下, Qwen3.6-27B 在 CGRE 测试得到了95.5分, 成功超越了 Fable5(Mythos) 的94.1分! 我只能说这真的是 Agentic 工程的胜利了! 不要模型写的不好就无脑怪模型, 也要看看是不是Agent本身有问题. 那么代价是什么呢? 当然就AI硬通货是 token 了, 这个框架正是用了25-40x的token消耗完成了这一壮举. 值得学习. 框架:http://github.com/ryoiki-tokuiten/Iterative-Contextual-Refinements 论文:http://arxiv.org/abs/2605.15222 #mythos #fable5

译Iterative-Contextual-Refinements框架使Qwen3.6-27B在CGRE测试中获95.5分，超越Anthropic Fable5(Mythos)的94.1分。该框架通过BFS探索多种方案（如KMP、滑动窗口）、DFS结合性能工具迭代优化代码，以及路由统筹形成闭环，克服小模型易陷入局部最优的弱点。代价是token消耗增加25-40倍。框架与论文已开源。

elvis@omarsar0 · 6月15日53

I also never set /goal by myself. The agent is probably better equipped with its context to help you set a strong goal for longer autonomous runs. Smart to have it as a tool for agents. Exactly how I have it built in my orchestrator app. I even built a little UI for /goal in my orchestrator. Here is something you can try if you want to get better goals that agents follow. Mine your agent sessions, collect goals that performed well, and package those insights/best practices as a skill using an automation. That skill can then be reused with the /goal tool to set even stronger and more reliable goals. Doesn't get more meta than this. I am thinking of doing a live session on this if folks are interested. This is a simple workflow with tons of value and ways to optimize the results of /goal. It turns out that some of the weird behavior of LLM (e.g.g, reward hacking, bias to finish quickly, and other weird shortcuts) creep up a lot when using /goal, so you want to be extremely careful of that. I wrote a little more about better ways to set /goal here: https://x.com/omarsar0/status/2065880971031834786?s=20

译引用推文指出，Codex 可自主查看和设置 /goal，这是元提示的泛化。主推文作者强调，智能体凭借上下文能帮你设定更强目标，因此将 /goal 作为工具是明智之举。他还在编排器中为 /goal 构建了 UI，并建议从会话中挖掘表现良好的目标，封装为技能自动化复用。需注意，LLM 可能出现奖励黑客、偏向快速完成等奇怪行为，使用 /goal 时要格外谨慎。

Tibo@thsottiaux · 6月15日68

Codex can see and set its own /goal. Everything we build, we build also as a tool for the agent. This is a generalization of meta prompting, where you let the agent set its own task based on your intent.

译Codex 可以查看并设置它自己的 /goal。 我们所构建的一切，也都是作为该智能体的工具而构建的。 这是元提示的一种泛化，即让智能体根据你的意图自行设定任务。

Ethan Mollick@emollick · 6月15日49

We don’t honestly know the best approaches to rebuilding companies around AI agents, especially in ways that expand competitive advantage &amp; augment existing human capabilities. Practical agents are merely months old. Experimentation (and productive failures) will be required.

译老实说，我们并不知道围绕AI智能体重建公司的最佳方法，尤其是那些能够扩大竞争优势并增强现有人类能力的方式。实用的智能体仅仅诞生了几个月。实验（以及富有成效的失败）将是必要的。