# BestBlogs 早报 09-06：蚂蚁数科 Harness 验收、Uber 智能体成本治理与 UrbanGround 长程评测 - 来源：ginobefun (@hongming731) - 发布时间：2026-09-06 08:04 - AIHOT 分数：54 - AIHOT 链接：https://aihot.virxact.com/items/cmtp21idf043aroblzbx682de - 原文链接：https://x.com/hongming731/status/2096389047900082595 ## AI 摘要 BestBlogs 早报 09-06 精讲三篇工程实践：蚂蚁数科魏长征在 AICon 分享 Harness 验收闭环，覆盖 40 万行 Rust 新项目与 60 万行 C++ 存量项目。 ## 正文 https://x.com/i/article/2096388518268588032 BestBlogs早报·09-06｜蚂蚁数科 Harness 验收，Uber 成本治理，UrbanGround 测长程 在线阅读本期早报 BestBlogs.dev 是 AI 驱动的私人阅读助手。这是面向所有人的每日早报内容，如果你希望它基于你的兴趣和阅读习惯整理，可以体验「我的早报」。 导语 当 Agent 一天能交付过去几周的代码，团队面对的问题会从「能不能生成」转向「怎样证明结果可以接受」。同样的变化也发生在基础设施和现实行动中：调用量扩大以后，成本需要被解释；任务拉长以后，模型需要持续记住目标。今天没有一条必须统摄全部内容的大新闻，更适合沿着一条实践路径，看清工程系统如何从局部能力走向稳定结果。 第一步是建立验收闭环。蚂蚁数科用新项目与存量项目说明，约束、状态、评审和证据怎样进入 Harness。 第二步是把成本拆成可以测量的乘数，Uber 展示智能体请求增长九点四倍时，如何通过基准、路由和上下文治理保持总支出相对稳定。 第三步把评测放进真实三维香港，UrbanGround 让模型连续走路，观察单帧识别与长程完成之间的差距。 这三条分别服务不同判断，不需要被夸大成一种统一趋势。它们提供的是一组可复用问题：目标是否写清，结果怎样验收，资源花在什么地方，任务是否真正走到终点。七条速览继续补上自有算力、训练数据通路、上下文清理、边缘推理、开源代码治理、电话代理与可改写软件，让这套检查覆盖从底层资源到用户体验。 ★ 精讲一：AI Coding 的下一步不是写得更快，而是可验收：蚂蚁数科 Harness 工程实践 来源：InfoQ 中文 · BestBlogs 评分：90 蚂蚁数字科技技术专家魏长征在 AICon 分享了两个项目。一个是超过四十万行的 Rust 新项目，从第一天就让 Agent 参与；另一个是超过六十万行、持续开发多年的 C++ 存量项目。两者面对的共同变化是代码产出突然变快，而需求、架构、评审和验收仍按原来的速度运行。只要验证能力没有同步提高，更多代码就可能变成更长的返工队列。 文章的关键判断很克制：AI Coding 没有凭空制造全新的软件工程问题，它放大了需求模糊、目标漂移、事实冲突和质量欠账。过去这些问题分散在几周或几个月里，现在可能在一个长任务中集中出现。开发者也从主要负责写代码，逐渐转向定义目标、提供上下文、检查路径和判断交付结果。于是，团队真正稀缺的能力不再只是实现速度，而是把意图转化为可验证标准。 这里的 Harness 不是某个工具或固定框架，而是一套围绕约束、验证和验收建立的闭环。约束层先写清任务目标、非目标、架构、接口和唯一事实源，避免 Agent 在冲突信息之间自行猜测。状态写入把阶段进展、已通过检查和未解决问题持久化，使跨越多个上下文窗口的任务仍能接续。目标对齐要求每个阶段回看最初任务，检查局部实现是否偏离整体结果。 对抗验证与证据层决定了人怎样参与。确定性的格式、编译、单测和覆盖率可以交给脚本做硬门；架构一致性、已有能力复用、根因判断和边界风险由不同视角的 Agent 做软评审。最终交付不只是一句「已经完成」，而是一份包含测试路径、结果、可视化和遗留问题的证据。人不必逐行阅读几千行变更，但需要确认目标、实现路径和验收证据能否互相对应。 新旧项目采用了不同顺序。Rust 新项目从第一天把事实源、文档和验证放进流程，使约束随代码一起生长。C++ 存量项目没有直接扩大 Agent 权限，而是先清理冲突事实、补齐质量门禁，再进行仓库升级。原文披露，存量项目的代码缺陷率从百分之二十以上降到个位数。这个数字来自团队自身项目，不能自动复制到别的代码库；更值得迁移的是先修底座、再扩大自动化的顺序。 这篇延续了近期关于 AI 原生软件生命周期的讨论。此前的重点是 Agent 怎样进入规划、构建、测试和部署，今天进一步回答结果怎样被接受。团队不必一次性照搬五层架构，可以先找到最常失控的环节：需求经常被误解，就先补目标与非目标；长任务经常漂移，就先写状态；测试经常只覆盖 happy path，就先让证据对应真实用户路径。Harness 的价值，在于把高速生成重新接回可追踪的工程责任。 ★ 精讲二：智能体请求暴增 9.4 倍，token 账单却没涨：Uber 公开 AI 软件工厂省钱方法 来源：AI前线 · BestBlogs 评分：90 Uber 披露，超过百分之七十的代码合并请求由本地或云端智能体生成，内部已经构建三千六百多个智能体技能，每天执行超过三万次调用。从二月到八月，所有员工中的周活用户增长七倍，周请求量增长九点四倍；与此同时，AI 总支出从四月起保持相对稳定。这组信息的意义不在于证明 Agent 变得便宜，而在于展示大规模采用后，团队怎样把成本问题变成可测量的运营系统。 只看 token 单价会漏掉最重要的乘数。Uber 把成本拆成采用率、参与度、每个会话的请求数、每次请求的 token 数、模型价格和工具开销。采用率与参与度是团队希望提高的指标，优化空间主要落在模型路由、上下文长度、缓存、请求轮次与工具设计。这样一来，讨论从「哪个模型最便宜」变成「哪一类任务应该使用什么能力，以及完整任务花了多少钱」。 团队用真实 PR 和已知错误建立基准，比较不同模型的精确率、召回率、F1 分数、成本、延迟、超时和噪音。只有在质量与可靠性不下降时，降低成本才算有效。固定模型进行对照后，Uber 观察到每一千次请求的成本较峰值下降近百分之三十四，单会话成本较六月峰值下降百分之五十二。原文明确这些结果依赖 Uber 的代码库、模型组合和工作负载，因此可复用的是实验设计，不是某个固定降幅。 上下文是最容易产生复利效应的一层。每一轮交互都会重新发送历史、项目资料和工具结果，单次多一点，长会话就会重复很多次。Uber 把自动压缩阈值设在四十万 token，即使模型支持更长上下文，也不等于每轮都应该携带全部历史。不同任务还使用不同缓存时长：短生命周期子智能体强调快速复用，长交互则需要覆盖工程师离开再返回的间隔。 模型路由同样围绕任务，而不是围绕品牌。主 Agent 负责分解问题和判断结果，边界清楚的子任务可以交给更经济的模型。工具 Schema 变短、无效轮询减少、相关文件更快被检索到，也会同时降低 token 和等待时间。团队通过会话分析追踪哪一步产生大量无效请求，再把改进反馈给 Harness。成本可观测性因此与质量证据相连，而不是成为单独的财务报表。 近期早报介绍过 GitHub 通过上下文压缩和线上实验优化 Copilot 成本。Uber 的新增信息是把单项实验扩展到软件工厂的完整运营体系。读者可以先画出自己的成本公式，找到占比最大、重复最多的乘数，再判断应该换模型、缩上下文、改工具，还是减少不必要的回合。成本治理的目标不是让每次调用尽可能便宜，而是让规模扩大后仍能解释资源换来了什么任务质量。 ★ 精讲三：走两步，就忘了路｜UrbanGround：上交、NUS 等团队把大模型放进「真实三维香港」 来源：机器之心 · BestBlogs 评分：89 UrbanGround 由上海交通大学、新加坡国立大学、美团、香港中文大学、上海大学和牛津大学团队推出。研究者使用香港真实三维地理数据搭建城市沙盒，模型从第一人称看街景、查地图、过天桥，也会遇到封路和移动行人。与单张街景问答不同，这里要求模型连续采取动作，把已经做出的判断带到后续路口，并在环境变化时调整路线。 团队整理了八百一十个人工检查任务，用同一套动作接口测试十个多模态模型。视觉识别准确率为百分之七十五到九十三点八，说明它们大多能认出眼前地标。方向理解只有百分之二十三点三到五十八点三。短程导航中，表现最好的模型成功率达到百分之七十五；路线拉长以后，十个模型的成功率都落在百分之零到三点八。局部识别与完整任务之间出现了清楚的能力断层。 文章把失败拆成三个层次。空间定位要求模型在视角转动后，仍知道地标相对自己的方向。持续记忆要求地标离开视野以后，把此前线索、当前位置和目标重新对上。动态调整则要求它在封路或行人出现时，识别旧计划已经失效并重新规划。模型可能连续几步都正确，但一个路口的小偏差如果没有被发现，就会在长路线里不断累积。 一些案例让差距更具体。模型可以认出正确银行，却在寻找线索时离开人行网络；也可能打开地图后判断出大致方向，却无法在多次转弯后维持同一坐标。对现实系统来说，答对名称不等于走法安全，局部动作合理也不等于最终到达。评估 Agent 时，除了看回答准确率，还需要记录任务完成率、轨迹偏离、错误恢复和环境变化后的重新规划。 UrbanGround 是一个可重复运行的沙盒，并不等同于真实机器人部署。它的价值在于控制变量：同一条路线可以只改变天气、封路或人流，研究者便能定位模型从哪一步开始失去目标。真实城市实验成本高，也很难让多个模型遇到相同情况；沙盒先提供了一套可比较的压力测试，再为后续实体验证筛出最值得关注的失败模式。 这与近期关于物理 AI 可靠性、记忆和长期自主运行的讨论形成进展关系。此前更多是产品与研究者对长期能力的判断，今天出现了连续城市轨迹和任务完成数据。更好的评测不是为了证明模型不行，而是帮助团队区分会识别、会回答和能持续行动，并找到能力从哪里开始断开。 这也给软件 Agent 一个启发：长任务的质量同样需要用完整结果和恢复能力衡量。 速览 如何自建数据中心：为什么每家创业公司都该认真对待算力 来源：20VC with Harry Stebbings · BestBlogs 评分：90 Speechify 创始人比较了购买 GPU、长期云合约和峰值租用，认为稳定负载可以由自有集群承担，而波动需求继续使用云端。讨论还包括电力、液冷、网络、融资、运维和旧硬件转做推理，说明决策远不止服务器报价。 自有算力只有在利用率足够高时才有意义。团队需要把资本占用、设备折旧、网络拓扑、供电散热、人员与故障恢复计入总成本，同时估算硬件在模型更新后还能承担什么任务。云端的价值则是弹性、特殊硬件与降低早期不确定性。 标题提出普遍主张，内容更适合作为一张工作负载决策表。先识别稳定基线和峰值，再决定哪些容量值得拥有。它与 Uber 的软件成本治理构成上下两层：无论是 token 还是 GPU，关键都不是单价最低，而是让利用率、控制权和产品反馈匹配。 从 S3 到 GPU 一步到位：重新思考 ML 训练的数据加载 来源：InfoQ · BestBlogs 评分：86 Vortex 重新设计训练数据从 S3 到 GPU 的路径。传统流程常经过对象存储、CPU 解码、本地 NVMe、主机内存和设备复制，任何一步变慢，昂贵的加速器都可能等待输入。 它使用可组合数组编码和区域图布局支持选择性读取，再把解压工作移动到 GPU。紧凑数据可以先通过网络传输，由并行内核在设备端重建，减少 CPU 中转与重复复制。收益取决于数据形状、压缩方式、网络和硬件配置。 这篇最适合用来改变排查顺序：增加 GPU 之前，先测量对象读取、CPU 解码、主机复制和设备空闲时间。它与自建算力一篇共同提醒，拥有更多计算资源和让资源真正工作，是两个不同的工程问题。 The Batch: 979 | LLM 清理智能体的“垃圾” 来源：DeeplearningAI · BestBlogs 评分：86 Self-GC 让模型在长任务中主动管理上下文，对信息执行保留、折叠或剪枝。目标是在降低冗余 token 的同时，留下任务目标、关键证据和下一步需要的状态。 这种做法比固定窗口截断更细，因为模型可以判断一段历史的功能。过程性讨论可以压缩成结论，重复工具输出可以删除，决定后续行动的约束则必须保留。真正需要验证的是压缩后任务能否继续，而不只是上下文变短了多少。 它与 Uber 的成本公式直接相连，也与 Harness 的状态写入互补。会话历史可以清理，经过验证的阶段结果应当持久化。好的上下文治理不是记得更少，而是让下一步仍能基于正确事实行动。 前沿推理抵达边缘：如何在 NVIDIA Jetson 上部署和优化模型 来源：NVIDIA Technical Blog · BestBlogs 评分：90 NVIDIA 指南介绍在 Jetson 上部署推理模型的组合方案，使用 NVFP4 量化降低计算与内存搬运，再用投机解码提升生成吞吐。小型草稿模型先提出 token，主模型批量验证，从而减少逐 token 推理的等待。 文章报告最高六点二八倍解码吞吐提升，但这个数字对应特定模型、硬件和配置。量化精度、草稿接受率、响应长度、功耗和内存共同决定实际效果；工具调用频繁的 Agent 与长文本生成也会有不同瓶颈。 边缘部署的价值是把延迟、隐私、离线能力和成本放进同一系统设计。读者可以用自己的决策任务做基准，在速度与答案质量之间选择配置，而不是期待一套优化覆盖所有场景。 科技爱好者周刊（第 411 期）：OpenClaw 2.0 是一个缩影 来源：阮一峰的网络日志 · BestBlogs 评分：91 阮一峰从 OpenClaw 2.0 的高吞吐贡献讨论 AI 时代的代码治理。版本功能近期已经出现过，本次新增角度是一月内约一万六千个 PR 被合并后，维护者怎样处理审查、运行隔离和技术栈选择。 人工很难逐行阅读所有变更，因此确定性测试、权限边界、沙盒环境和可回退路径变得更重要。AI Review 可以扩展视角，却不能替代项目对合并标准和发布责任的定义。 开源项目与企业代码库面对的风险不同，但都需要把不可接受行为变成可执行规则。它与蚂蚁数科 Harness 的关联很具体：生成速度提高以后，稳定交付取决于什么证据足以支持一次合并。 AI 电话代理的工作原理：背后的架构分析 来源：freeCodeCamp · BestBlogs 评分：90 一通 AI 电话要经过电话网络、流式语音识别、语言模型与工具、语音合成，再写回日历、订单或客户系统。每一层的延迟会累积，任何一次状态丢失也会让用户觉得模型没有理解任务。 实时系统还要处理轮次检测与打断。等待太久会形成尴尬停顿，判断过早会切断用户；工具调用必须有清楚 Schema、授权和幂等规则，外部服务失败时还要安全重试或转人工。 排查体验问题时，先定位运营商、转写、推理、工具、合成还是业务集成，再决定是否更换模型。真正应该衡量的是预约、查询或订单有没有完成，而不仅是声音是否自然。 Lex Fridman 对话 DHH：Omarchy，才是真正属于 Agent 时代的操作系统 来源：Founder Park · BestBlogs 评分：90 DHH 用 Omarchy 讨论一种可由用户意图持续改写的软件形态。Agent 参与生成大量代码，界面与流程不再完全固定，用户可以更直接地把个人工作方式变成系统行为。 这是受访者基于自身产品的判断，重要之处不在于宣布传统软件终结，而在于提出新的维护问题：个人改写怎样兼容升级，权限怎样约束，自动生成的变化怎样被理解和回退。 它把今天的内容从工程效率带回产品控制权。软件越容易改写，越需要明确验收与恢复。值得继续思考的是，未来的个人软件会把多少自由交给用户，又用什么证据保证这份自由不会破坏日常任务。 今日小结 回顾今天的内容，蚂蚁数科用 Harness 回答结果怎样验收，Uber 用成本公式回答资源怎样归因，UrbanGround 用连续轨迹回答任务怎样完成。算力、数据、上下文和产品架构的七条速览，则把这三个问题延伸到系统的不同层级。 如果你在改研发流程，先读蚂蚁数科与 OpenClaw；如果负责基础设施，接着看 Uber、Speechify、Vortex 与 Jetson；如果在做 Agent 产品，UrbanGround、Self-GC 与电话代理提供了更完整的验证视角。时间有限时，先从自己最难测量的那一层开始。 欢迎把这期早报分享给正在建设 AI 系统的同事，也欢迎讨论：你的团队现在最缺的是更强模型，还是更清楚的目标、环境与证据？当生成、调用或行动规模继续扩大，哪一种验收信号最值得先建立？ 👉 近期早报 • BestBlogs 早报 · 2026-09-05 • BestBlogs 早报 · 2026-09-04 • BestBlogs 早报 · 2026-09-03 • BestBlogs.dev 第 111 期：经验复利 • BestBlogs.dev 第 110 期：新的稀缺 • BestBlogs.dev 第 109 期：程序员的职业未来 BestBlogs 是 AI 驱动的私人阅读助手，帮助你发现真正适合你的高质量内容，关注你感兴趣的来源和主题，每天生成一份更适合自己的「我的早报」，欢迎体验和关注我们。