早报精讲三篇方法论：循环工程、Agent工具设计、Token成本控制 · AI HOT
ginobefun @hongming731 41
2026-06-16 07:57 ·17天前
AI 摘要 循环工程将人机协作从单次对话转为连续回路，需回答何时启动、工具集、错误检测、记忆、刹车五个问题。Agent工具设计强调单一职责、强约束schema、结构化错误返回、幂等键等有效模式，并列出静默部分成功、功能重叠等反模式。Token成本控制揭示用户提问仅占成本1%以下，真正大头顶在系统提示词、项目文档、Skill定义、历史会话等固定前缀。速览还涉及Anthropic Fable 5模型被美政府出口管制叫停、Scaling Law参数冗余研究。
ginobefun @hongming731 · X 2026-06-16 07:57 · 17天前
在 X 看原推 · x.com AI 摘要 循环工程将人机协作从单次对话转为连续回路，需回答何时启动、工具集、错误检测、记忆、刹车五个问题。Agent工具设计强调单一职责、强约束schema、结构化错误返回、幂等键等有效模式，并列出静默部分成功、功能重叠等反模式。Token成本控制揭示用户提问仅占成本1%以下，真正大头顶在系统提示词、项目文档、Skill定义、历史会话等固定前缀。速览还涉及Anthropic Fable 5模型被美政府出口管制叫停、Scaling Law参数冗余研究。
对于正在评估是否要给自己的工作流搭一套循环的读者，这篇文章值得通读--尤其是关于"一个完整 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 表格，并基于此提出两个实用方法，适合关注模型后训练范式的读者。
今日阅读路径 精讲一：Codex 和 Claude Code 负责人都不写提示词了，AI 圈爆火的 Loop 到底是什么 -- 先搞清楚 Loop Engineering 到底是不是一个新东西，以及它真正值得讨论的判断标准是什么。 精讲三：一篇搞懂 AI Coding Agent 的 Token 成本控制 -- 如果你已经在用 AI Coding Agent，这篇能直接帮你省钱，而且能解释清楚"循环跑起来之后账单去哪了"。 精讲二：AI 智能体工具设计：有效与无效的模式 -- 如果你在给自己的 Agent 写工具或者评估别人写的工具，这篇的对照表可以当 checklist 用。 时间更充裕的话，再看 Fable 5 禁令始末和 AI 应用层泡沫这两篇，了解一下当下 AI 行业里政策和商业层面正在发生的事。
BestBlogs 是 AI 驱动的私人阅读助手，帮助你建立稳定、可信、个性化的高质量信息输入。它帮你判断什么值得读、协助你读懂，并逐渐理解你关注什么，欢迎体验。
这篇文章给出的回答相当克制。如果只看技术实现，循环工程并没有发明什么全新的东西。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 表格，并基于此提出两个实用方法，适合关注模型后训练范式的读者。
今日阅读路径 精讲一：Codex 和 Claude Code 负责人都不写提示词了，AI 圈爆火的 Loop 到底是什么 -- 先搞清楚 Loop Engineering 到底是不是一个新东西，以及它真正值得讨论的判断标准是什么。 精讲三：一篇搞懂 AI Coding Agent 的 Token 成本控制 -- 如果你已经在用 AI Coding Agent，这篇能直接帮你省钱，而且能解释清楚"循环跑起来之后账单去哪了"。 精讲二：AI 智能体工具设计：有效与无效的模式 -- 如果你在给自己的 Agent 写工具或者评估别人写的工具，这篇的对照表可以当 checklist 用。 时间更充裕的话，再看 Fable 5 禁令始末和 AI 应用层泡沫这两篇，了解一下当下 AI 行业里政策和商业层面正在发生的事。
BestBlogs 是 AI 驱动的私人阅读助手，帮助你建立稳定、可信、个性化的高质量信息输入。它帮你判断什么值得读、协助你读懂，并逐渐理解你关注什么，欢迎体验。
ginobefun@hongming731 · X