http://x.com/i/article/2084050963296604160
BestBlogs 精选周刊 | 第 106 期：1% 法则
🎧 本期也有播客版本：BestBlogs 周刊 第 106 期 · 1% 法则 · 时长 27：17 · 在小宇宙搜索「BestBlogs 周刊」即可收听。
导语
一个 AI 产品从演示走到真实用户手中，中间究竟隔着什么？
这周看完 20 篇文章，我发现大家谈论的对象虽然差异很大，从 GPT-5.6、Kimi K3、Claude Code 和 MCP，到机器人、无人机与产业演化，最终都回到了相近的工程问题：目标有没有被准确描述，结果怎样验证，任务中间状态怎样保存，失败能不能恢复，高风险动作由谁批准，系统进入现实环境后又由谁承担责任。
Jeff Dean 在 Y Combinator 对谈中使用「1% 法则」描述这段距离。这里的 1% 是一种构建方法和主题隐喻，没有研究证明模型已经完成 99%，也不能用它推算剩余工作量。这个小数字的作用，是把注意力从醒目的能力演示移到容易被遮住的系统细节。
过去 7 期周刊，我们从答案越来越便宜，谈到慢下来才能更快、智能的账单、系统新信号、判断力回归，以及上一期的明与暗。模型能力继续增长，真正稀缺的部分逐渐落在完成定义、验证闭环、组织理解与结果责任上。
这条线也贯穿了最近 7 天的早报。WorkBuddy、模型裁判、Claude Code 消融、MCP 无状态核心、vLLM、GPT-5.6 效率和 Skill 供应链先后出现。单独看，它们分别属于产品、协议、模型或基础设施；连起来看，行业正在把注意力从「模型能做什么」推进到「系统怎样稳定完成任务」。
本期沿着 7 个问题展开。完成怎样定义，评测怎样保持可信，一次成功任务要付出多少成本，系统应该记住什么，Skill 与协议如何治理，模型和基础设施怎样共同设计，以及智能进入物理世界后，产品边界会发生什么变化。
一、规格是一份持续更新的完成契约
Jeff Dean 在 YC 对谈中反复使用一种很朴素的方法：先做量级估算，再找真正限制系统的因素。
他回顾早期语音识别需求时，先计算使用规模继续增长后，现有硬件的延迟与能耗是否承受得住。这个估算后来推动了 TPU 的方向。它没有替团队完成所有设计，却提前暴露了通用硬件路线会遇到的边界。
把同样的方法放到智能体产品上，瓶颈很少只落在模型。一次真实任务通常还依赖：
- 检索能否找到正确材料
- 记忆是否保留仍然有效的事实
- 工具是否只拥有完成任务所需的权限
- 上下文有没有包含业务约束
- 评测能否发现结果已经偏离目标
- 编排层能否在中断后继续，而非从头重来
所以 Jeff Dean 很强调规格。详细设计文档可以减少模型必须自行补全的假设。目标越含糊，模型越容易把流畅文字、能运行的代码或一次成功截图当成完成。到了真实业务里，遗漏的假设会变成返工、兼容性破坏、数据覆盖，甚至一次不该发生的外部动作。
评测为什么会进入产品需求
Anthropic 产品负责人 Diane Penn 在 Lenny Rachitsky 主持的访谈中，把这件事推进到产品流程。她提出，评测正在成为新的产品需求文档。
她关心的是一条完整反馈链。用户需求先被写成可以观察的行为，再转成研究和工程都能重复运行的测试。模型发布后，团队继续用真实使用结果修正测试，让产品与研究看到同一类失败。
以研究助手为例。如果需求只写成「生成一份高质量报告」，模型很容易用篇幅、格式和流畅语气制造完成感。更可靠的定义会继续检查：
- 关键事实能否回到原始来源
- 作者、主持人与受访者有没有分清
- 缺少证据时会不会明确停下来
- 争议结论是否保留限制与反方观点
- 最终内容是否帮助用户形成判断
Diane Penn 还谈到 token maxing，也就是高强度使用前沿模型，尽早体验尚不稳定的新能力，再从失败和意外用法中发现未来工作流。她用 Golden Gate Claude 实验说明，小型跨职能团队可以快速把研究发现做成用户能感知的产品体验。产品载体随后带回采用数据、失败案例和新的研究问题。
模型升级后，先删除旧补偿
Boris Cherny 在 YC 对谈中介绍的 Claude Code 提示词消融，是这套思路的工程版本。
每次接入新模型，团队会删除系统提示里的旧规则，删除工具说明里的补偿，再让模型完成困难的真实任务。只有某类失败反复出现，团队才把对应上下文、工具或约束加回来。
很多智能体产品会把旧模型的缺点逐层写进提示词。模型升级后，旧脚手架继续存在，规则越来越长，彼此甚至开始冲突。团队看到系统复杂度不断增长，却很难判断其中每一层是否仍有贡献。
Boris 举的例子是一项仍在运行的桌面应用迁移。智能体要把 Electron 应用改写成 Swift，并在 Mac 虚拟机里反复比较界面截图。模型可以快速生成大量代码，复杂系统迁移、状态一致性和像素级验证依然会暴露失败。团队从这些失败里决定下一步该增加工具、视觉反馈，还是补一份更清楚的规格。
我的判断是，成熟规格不会在开工时写完后封存。它更像一份持续更新的完成契约。用户、产品、工程与研究团队都能在里面看见同一个问题，也能指出当前证据缺在哪里。
→ 阅读原文：https://www.bestblogs.dev/video/7661f98c6
→ 阅读原文：https://www.bestblogs.dev/video/085fbfbd6
→ 阅读原文：https://www.bestblogs.dev/video/227347908
二、验证也需要被验证
完成定义建立起来之后，评测规模会迅速成为新问题。人工无法阅读每天产生的几万条智能体轨迹，于是 LLM-as-a-Judge，也就是模型裁判，进入了生产流程。
模型裁判可以给单个结果打分，可以比较两个候选答案，也可以按照多项 rubric 分别判断。Karthika Raghavan 的实战指南把它的生产用途、偏见、领域失效和对抗风险整理得很完整。她给出的核心提醒很克制：模型裁判适合扩大筛查覆盖，最终分数仍需要校准。
2023 年的一项 NeurIPS 研究，在自己的任务设置里观察到强模型裁判与人类偏好的吻合度超过 80%。这个结果支持了模型裁判的实用价值。同一项研究也记录了位置偏见、冗长偏见、自我增强倾向和推理能力限制。
80% 描述的是特定模型、任务和数据。它无法成为跨领域可靠性的通行证。
后续研究还发现，模型能够以高于随机的水平识别哪些文字更像自己生成的，而且自我识别越强，自我偏好也可能越明显。如果同一模型家族同时生成候选并负责评分，多裁判投票也未必带来真正独立的证据。
一条更可靠的校准链
稳妥做法通常从拆分标准开始。事实一致性、任务完成度、安全性、表达质量和格式合规分别判断，避免一个总分掩盖不同类型的失败。
实际流程可以分成几层：
- 比较两个答案时交换候选顺序，检查位置偏见。
- 裁判模型尽量与被评模型分离，降低同源偏好。
- 保留一小组人工标注样本，持续观察人和模型在哪些场景分歧。
- 低置信度、高风险和分布外样本直接升级到人工。
- 将新发现的失败加入回归集，跟随模型版本持续运行。
能够用确定性程序检查的边界，应优先交给程序。格式是否正确、链接是否可访问、代码能否编译、测试是否通过、字段是否完整，这些问题没有必要先让模型表达意见。
模型裁判更适合处理开放质量，例如一份研究是否遗漏关键反方观点，一段解释是否真正回答了用户的问题。验证闭环因此是一条分工明确的校准链。团队需要知道自动评分在哪些任务上可信，哪些情况必须交还给人，以及哪一次失败应该进入下一轮评测。
→ 阅读原文：https://www.bestblogs.dev/article/20cb8c9352
三、一次成功任务的成本来自整个循环
谈智能体效率时，最容易获得的数据是每百万 Token 的价格。这个数字方便比较，却无法回答用户真正关心的问题：一项任务成功完成，总共花了多少钱、等待了多久，又经历了多少次返工。
OpenAI 在 GPT-5.6 的官方工程文章里，把效率拆成训练、推理系统和智能体 Harness 三层。Harness 是连接模型、工具与用户运行环境的执行框架。
官方披露，GPT-5.6 Sol 参与改写和优化生产推理内核，相关工作让端到端服务成本最高降低 20%。它还设计并运行了数百项推测解码实验，让 Token 生成效率提升超过 15%。
推测解码会让一个更便宜的草稿模型先提出多个候选 Token，再由主模型并行验证。候选质量、验证速度、内核实现和调度策略需要配合，收益才会出现。
内核优化还要经过正确性工具验证。OpenAI 文章提到开源的浮点检查工具，用来检查模型参与编写的底层代码。速度与正确性在这里属于同一个工程问题。
文章给了一个容易感知的例子。一次 Codex 任务可能包含 30 次模型请求。每轮只多 1 秒，整项任务就会积累出明显等待。每轮重新处理不变历史、全部工具定义和重复结果，成本也会沿着循环持续放大。
从连接、缓存到 Code Mode
ByteByteGo 团队在采访参与 Codex 与 ChatGPT Work 优化的 OpenAI 工程师后，把循环拆成编排、接口和推理三层：
- 持久 WebSocket 减少每轮重新建立连接的握手成本
- 增量请求只发送新增内容，避免不断重传完整历史
- 追加式历史保住稳定提示前缀，提高缓存复用
- 延迟工具发现避免几百个工具定义长期占据上下文
- Code Mode 让模型先写一小段程序，由运行环境并行调用工具并压缩结果
Code Mode 的关键价值，是让中间数据停留在更适合处理它的确定性运行环境里。模型不必在每次工具调用后重新阅读所有结果，只有过滤、合并后的结论进入上下文。
编排器怎样污染自己的工作记忆
Martin Fowler 站点刊载的一篇 Claude Code 会话复盘，提供了一个具体反例。正文没有给出可证明的个人署名，因此这里讨论的是复盘者的观察。
最初，他怀疑成本来自同时运行 4 个子智能体。继续检查后，他发现主编排器反复读取后台记录，把探索过程、重复文件定位和失败路径重新带回主上下文，这可能才是更大的负担。
复盘者由此提出「认知局部性」。需要同一套系统理解的任务，最好留在同一个上下文里。拆分若只看任务名称，多个智能体会分别重建相同的代码心智模型，文件读取和方向判断都被重复支付。
子智能体更有价值的用途，是隔离探索噪声，只向主线程返回仍然影响决策的结论。这篇复盘也承认缺少完整 Token 计量，所以认知局部性仍是一条由真实会话启发的工作假设，不能据此推导统一的智能体数量上限。
团队衡量智能体效率时，至少应该同时记录成功率、调用轮数、提示缓存命中、工具等待、重试、人工返工和用户实际等待时间。单次调用省下的钱，可能被更高失败率吃掉。局部输出更快，完整结果也可能更晚到达。
→ 阅读原文：https://www.bestblogs.dev/article/1237e03a4e
→ 阅读原文：https://www.bestblogs.dev/article/928222df59
→ 阅读原文：https://www.bestblogs.dev/article/36ff88dcab
四、系统应该记住什么
长任务必须保持连续，模型本身却没有可靠的长期状态。Context、Memory、Skill、知识库和 Handoff 经常被当成几组独立概念，放在完整任务里看，它们都在回答状态怎样被保存、加载、更新和交接。
WorkBuddy 策略产品经理 Anne 在腾讯技术工程刊载的实践中，把 Agent 产品拆成模型、上下文、Harness 和 Loop。
模型负责理解任务并提出工具调用。产品侧 Agent 负责参数校验、权限检查与真实执行。密钥、数据库、文件修改和外部发送都留在模型之外。删除、发送、支付、发布等高风险动作，需要审批、沙箱、审计和最小权限提供强制边界。
Anne 把上下文工程拆成 5 个动作：
- 写入：明确目标、规则、环境和当前状态
- 选择：从已有材料中挑出当前步骤需要的部分
- 检索：从历史会话、资料库和工具目录取回缺失信息
- 压缩：降低长期任务不断累积的上下文负担
- 隔离：让不同子任务的探索过程不互相污染
这 5 个动作背后是一套控制逻辑。系统要知道谁能写入，哪些内容可以被压缩，哪些原始记录必须保留，哪一类动作必须重新征得用户同意。上下文窗口再大，也不会自动替团队回答这些问题。
Memory 至少包含 5 类状态
浮之静的独立技术研究把 Memory 分成至少 5 类：
- 当前计划、步骤与等待条件属于工作状态。
- 工具调用和外部动作属于事件历史。
- 业务规则与系统事实属于领域知识。
- 用户习惯和表达选择属于偏好。
- 凭据、授权和人工决定属于身份与隐私。
这些信息需要不同的更新与恢复规则。工作状态可以被新检查点取代，事件历史适合追加写，领域知识要保留版本与来源，偏好需要衰减和纠错，凭据则应该停留在专用安全边界。
摘要适合继续工作，审计仍要依靠原始记录。系统若没有先定义写入权、有效期、冲突处理和删除义务，检索速度再快，也可能把过期事实稳定地送回每一次任务。
组织知识不能只从代码自动生成
阿里技术刊载的后端知识库实践，把组织知识拆成业务、架构、系统和基建四层。
业务层解释为什么改，也把「退款体验优化」「权益冻结」这类业务词映射到订单、支付、履约、财务、客服和风控链路。架构层保存服务协作与依赖方向。系统层记录接口、状态机、兼容逻辑和验证规则。基建层保存数据库、消息、缓存、发布、监控与回滚约定。
一个自动生成的代码百科可以告诉智能体当前仓库有哪些类和接口，却很难解释一段看起来冗余的兼容逻辑为什么保留，也无法仅凭单仓库判断一次退款改动会不会影响财务对账。局部代码事实很准确，放到完整业务链路里仍可能导向错误方案。
代码生成加速之后，理解会成为瓶颈
另一篇由阿里技术刊载的个人技术思考，把风险拆成技术债、认知债和意图债。
- 技术债留在代码里，让系统难以修改。
- 认知债发生在团队共享理解逐渐变薄的过程中。
- 意图债出现在需求、架构决策、测试和规格没有记录目标、约束与理由的时候。
AI 生成代码时，少了一段建立心智模型所需的摩擦。代码可以运行，团队却未必知道为什么这样设计。下一次异常发生时，团队也很难安全修改。
理解的作用已经超出逐行验收。它让人继续参与设计、判断和责任分配。知识系统需要保存事实、原因、约束、决策与证据，也要允许内容过期和删除。记忆的质量最终取决于治理，容量只决定它能存多少。
→ 阅读原文：https://www.bestblogs.dev/article/933063ff13
→ 阅读原文：https://www.bestblogs.dev/article/e2c6c71ac5
→ 阅读原文：https://www.bestblogs.dev/article/b664eb7929
→ 阅读原文：https://www.bestblogs.dev/article/f77d81a742
五、Skill 与 MCP 开始进入治理阶段
程序性知识需要一种能够发现、复用和版本化的载体。Yogendra Miraje 在 AI Engineer 的分享中，把 Skill 定义为智能体产品里的功能单元。
提示词说明智能体的角色，工具说明它可以连接什么，Skill 记录一项任务怎样完成。最小 Harness 可以只有 Skill 注册表、系统说明和读取文件的能力。注册表先暴露名称、描述与路径，模型只加载当前任务需要的 Skill，这就是渐进披露。
Skill 描述承担路由信号。描述写得含糊，模型会误触发相似能力。如果团队只按照底层数据模型切分 Skill，用户真实意图可能横跨多个文件和工具，执行过程就会碎裂。Yogendra 建议先围绕用户要完成的事情设计，再根据真实使用逐步重构边界。
当 Skill 数量从十几个增长到几百个，团队还要回答：
- 谁负责维护和审核
- 允许调用哪些工具与数据
- 怎样进入正式注册表
- 模型升级后原有评测是否仍然通过
- 旧版本什么时候弃用和删除
文件本身可以很轻，运行它的责任并不轻。Skill 到了生产环境，就进入了产品生命周期和供应链治理。
协议转向无状态核心
MCP 2026-07-28 规范，把连接层推向类似方向。官方核心改成无状态、自包含的请求响应模式，服务器因此更容易部署到 Serverless 和边缘环境。长任务和交互界面通过版本化扩展加入，企业授权则对齐 OAuth 2.0 与 OIDC。
Claude 团队披露，MCP SDK 月下载量已经超过 4 亿，年内增长 4 倍。这组数字来自官方口径，能说明采用速度，无法单独证明生产质量。
MCP 官方安全原则要求把工具描述视为不可信内容。用户需要理解并同意数据访问和动作，产品仍要负责最小权限、审批、审计与结果验证。
协议解决互操作，Skill 保存程序性知识，Harness 承担执行边界。三者配合得好，能力才能被发现、复用与升级。任何一层缺少所有权，系统都容易把「连接成功」误认为「任务已经可靠完成」。
→ 阅读原文：https://www.bestblogs.dev/video/fd0779622
→ 阅读原文：https://www.bestblogs.dev/article/b4007ae077
六、模型效率是一项系统属性
这周两篇模型与基础设施内容，都在提醒我们离开参数榜单，去看能力如何被训练和服务出来。
腾讯科技旗下企鹅智库的博阳在徐青阳编辑下，对 Kimi K3 技术报告做了细致拆解。文章给出的精确规模是 2.78 万亿总参数，每个 Token 激活约 1042 亿参数，共有 896 个路由专家，最长上下文为 100 万 Token。
总参数很大，每次计算只调用其中一小部分专家模块。Kimi 官方页面采用 2.8 万亿参数口径，并明确承认 K3 整体表现仍落后最强的闭源模型。参数规模说明它跨过了一道工程门槛，无法直接证明每项任务都更好。
仅用 BF16 保存一份 K3 权重，就需要约 5.56 TB。训练时还要容纳梯度、优化器状态、中间激活和通信缓冲。模型能不能装下只是第一步，真正困难的是数千张卡之间能不能传动，专家负载是否均衡，通信能否与计算重叠，GPU 能不能持续吃满，以及投入的计算最后能否换成模型质量。
从 K2 到 K3，几组变化需要一起看：
- 路由专家从 384 个增加到 896 个
- 每个 Token 激活的专家从 8 个增加到 16 个
- 网络深度从 61 层增加到 93 层
- 上下文从 128K 扩到 100 万 Token
容量、深度与长度同时增长，也放大了通信、稳定性和长上下文计算压力。
K3 使用 Kimi Delta Attention、Attention Residuals 和 Stable LatentMoE。文章还介绍 Unified Activation Manager，它可以决定中间结果留在 GPU、转移到 CPU 内存、压缩保存，或者在反向传播时重新计算。这个机制类似训练系统的仓储调度，目标是避免局部显存突然爆满。
Kimi 官方称，相比 K2，整体缩放效率约提升 2.5 倍。这个比例仍属于官方评测，需要未来独立测试补充。它至少说明，3T 级模型的困难已经落到一组可以讨论和测量的工程变量上。
推理引擎也会反过来影响模型
在张小珺主持的 3 小时访谈中，受访者游凯超回顾了 vLLM 从伯克利校园项目走向生产基础设施和开源社区的过程。张小珺是主持与采访者，游凯超是受访者。
节目材料写到，vLLM 社区维护者用了接近 3 年，把一篇算法论文发展成开源项目，再走向 Inferact 的公司化运营。
游凯超谈到模型与 Infra Co-design。模型结构会影响缓存、并行、调度和硬件利用，推理引擎的约束也会反过来影响模型怎样设计。如果双方只在发布后才对接，很多成本会被固化到线上服务阶段。
节目还讨论了开源治理。Inferact 获得 1.5 亿美元种子轮融资，数字来自节目材料。融资为长期维护与工程投入提供资源，也会带来商业目标和社区信任之间的新张力。开源影响力、生产可靠性和公司长期交付能力，需要分别验证。
算力最终会落到物理基础设施
Sam Altman 在 Invest Like The Best 访谈中，把算力延伸到芯片、能源、数据中心、供水、冷却与建设能力。他认为智能需求会随着价格下降继续增长，这属于他的战略判断。
即便模型越来越高效，基础设施供给、工作流、集成和协作仍可能形成差异。访谈还讨论了权力集中、人的自主选择和认知萎缩。AI 工具可以替人完成更多工作，用户仍要保留理解重要概念与系统的能力，否则自主选择会逐渐变成一句抽象承诺。
把 K3 的训练、vLLM 的推理引擎、OpenAI 的线上优化和 Sam Altman 的基础设施叙事放在一起，我更愿意把最后的 1% 理解为共同设计。模型架构、训练系统、推理引擎、能源约束和产品工作流从一开始就互相影响。等到发布后再补性能，往往已经错过成本最低的设计窗口。
→ 阅读原文：https://www.bestblogs.dev/article/26cdd6a71f
→ 阅读原文：https://www.bestblogs.dev/podcast/d8dc6b222
→ 阅读原文：https://www.bestblogs.dev/video/160d16d87
七、进入物理世界后，最后一步变成安全与责任
软件系统里的智能体循环已经足够复杂。进入物理世界后，反馈还会受到空间、传感器、动作延迟和真实风险影响。
Google DeepMind 官方发布的 Gemini Robotics 2，把视觉和语言继续接到全身控制、灵巧操作与多机器人协作。Carolina Parada 与 Google DeepMind 团队介绍了 3 个责任层不同的模型：
- 一个将视觉和语言转成动作
- 一个负责高层具身推理与多步规划
- 一个在机器人设备上本地运行，并用少量数据适配新本体
官方演示里，人形机器人可以走到货架前，弯腰拿起物品，再放到指定位置。多个机器人还能协作完成清理任务。值得关注的是感知、规划和动作被拆成不同层级，系统需要在任务进行中持续检查进度并纠正。
官方页面也保留了清楚的限制。多指精细操作仍然困难，运动速度需要提高，动作模型和端侧模型目前只向早期合作伙伴开放。演示证明研究路径正在进步，还无法代表机器人已经能够在开放环境里长期稳定工作。
无人机暴露了三维环境理解的瓶颈
Anthropic 研究团队与 Andon Labs 的 Project Pilot，把相近问题放到无人机上。Drone-Bench 将定位跟随任务拆成 5 个环节：
- 从视频重建三维环境
- 在地图中确定自身位置
- 规划并纠正飞行路径
- 识别目标
- 持续跟随
能力链中的任何一环失效，完整任务都会失败。当前最明显的瓶颈，是从二维视觉输入建立可靠的三维环境。模型如果无法稳定判断自己与障碍的位置，后续导航和跟随就缺少落点。
评测由 Andon Labs 执行，Anthropic 没有接触测试集，这能减少针对题目调优的空间。场景仍然属于室内受控任务，不能直接外推到天气变化、传感器故障、城市环境和复杂人群。
无人机具有明确的双用途属性。农业、搜索救援和灾害响应可能受益，监控、越权和伤害风险也会同时增长。软件智能体写错一段代码，还能回滚提交。物理智能体判断错误，后果可能立即落到人和环境上。
富足叙事无法代替责任分配
Web3 天空之城整理发布的另一份材料，来自《经济学人》对 Elon Musk 的访谈。观点属于 Musk，采访属于《经济学人》，中文整理来源是 Web3 天空之城。
Musk 把机器人和自动化描绘成通向物质富足的路径，也给出很激进的时间判断。采访者持续追问监管、分配、政治影响和权力集中，并在若干事实判断上直接提出反驳。
这场访谈的价值来自双方之间的张力。预测者描述能力曲线，采访者要求证据，也追问拥有技术平台的人怎样使用自己的影响力。富足不会自动回答资源怎样分配、谁设定规则、错误由谁承担。
我们可能仍处在产业的分化带
李鸿胜在腾讯研究院的文章里，用 Utterback 和 Klepper 两套经典框架观察产业时间。
Utterback 从产品维度区分流动期、过渡期和专门期。早期竞争集中在「产品应该是什么」，主导设计出现后，重心逐渐转向可靠、便宜和规模化。Klepper 则从企业进入、分化和退出观察产业结构。
李鸿胜把当前 AI 称为「分化带」。主导设计还没有完全确立，模型、应用、组织和基础设施却已经按照不同速度拉开差异。
这个判断属于探索性分析。制造业历史无法直接套到数字产业，虚拟现实、元宇宙和 Web3 等长期未收敛案例，也会挑战周期压缩的推演。不过，它提供了一个有用的决策问题：公司究竟在为流动期准备，还是已经按照专门期的方式追求效率与规模？
如果阶段判断错了，擅长试验的团队可能过早固化，擅长规模化的团队也可能把资源投入到尚未形成的主导设计里。
本期 20 篇内容共同留下的现实观察是，通用能力继续增长，差异开始积累在评测资产、组织知识、推理基础设施、权限设计和交付纪律里。它们没有模型榜单醒目，却会决定一家公司能否把下一轮能力进步真正变成产品。
→ 阅读原文：https://www.bestblogs.dev/article/06b4dbd82a
→ 阅读原文：https://www.bestblogs.dev/article/e490646730
→ 阅读原文：https://www.bestblogs.dev/article/98b87ff4fb
→ 阅读原文：https://www.bestblogs.dev/article/015737a3d3
本周关键词
完成契约：规格和评测共同定义系统准备交付什么，也让团队知道当前证据缺在哪里。
持续校准：模型裁判、人工金标和确定性程序各有边界，评测需要随着模型、工具和用户行为继续更新。
工作记忆：上下文、长期记忆和组织知识需要分层，探索噪声、审计记录、业务事实和凭据不应该混在同一个容器里。
共同设计：模型、训练、推理、能源、协议和产品工作流互相影响，很多效率在设计早期就已经决定。
结果责任：系统有能力调用工具或控制硬件，只能说明动作可以发生。它是否安全、是否经过授权、失败能否停止、最终由谁负责，决定了产品能不能真正上线。
下周我会继续关注一个变化。随着 Skill、MCP 和长时间运行的智能体进入生产，团队会不会开始把成功任务成本、可恢复性和责任边界放到核心指标里，并逐渐减少对单一模型分数的依赖。
关于 BestBlogs
BestBlogs.dev 是 AI 驱动的私人阅读助手。它会从 RSS、Newsletter、Twitter、YouTube、Podcast 等来源中筛选高质量内容，结合你关注的源、兴趣标签和阅读行为，把「我的早报」整理成每天真正适合你的阅读流--不论你关注的是技术、AI、产品、商业、研究、设计、投资、文化还是个人成长。
完成新用户三步引导即送 7 天 Pro 试用；现有 Pro 用户每邀请 1 位朋友双方各得 7 天 Pro（单人上限 28 天）。
发现真正适合你的高质量内容--欢迎来体验，也欢迎推荐给身边认真阅读的朋友。
🏷️ 标签：#AIAgent #Harness #上下文工程 #模型评测 #MCP #具身智能 #AI基础设施
BestBlogs.dev · 发现真正适合你的高质量内容 · https://bestblogs.dev