Andrew Ng 转向 AI Engineering
自上一篇《AI Engineer 的崛起》发布以来，AI 领域已经跨过了多少个应用里程碑，我们都数不清了。不过，Google Brain 和 Coursera 等机构的联合创始人 Andrew Ng 重新定位 DeepLearning.ai，将重点放在AI Engineering 上，无疑是其中一个重要节点：
这项分析基于“对超过 10,000 条招聘信息进行分析；与 AI 专家、招聘经理和招聘人员开展数十次结构化访谈；通过问卷收集数据；并综合其他在线数据”。
Andrew 认为，以下是最重要的四项 AI Engineering 技能：
想听听当事人的完整观点，可以阅读他的全文。我们也认同，“AI Engineering 技能”并不只适用于职位名称中带有“AI Engineer”的人，而是具有广泛的适用性。把重点放在这些技能上，确实很有洞察力。
下面逐一点评这四项技能：
构建和部署 AI 应用：“擅长构建和部署 AI 应用的人，了解 AI 的基本构件（例如 LLM、上下文工程、RAG、智能体工作流、机器学习和深度学习），更重要的是，他们知道如何运用统计技术来测量、引导和治理 AI 系统，让系统的行为更可预测。其中一项核心能力，就是持续进行严谨的评估和错误分析。”
软件工程基础。“理解软件基础，才能意识到有哪些权衡取舍。这有助于更好地选择软件技术栈、设计系统架构和数据存储方案，以及制定测试策略等。相比之下，缺乏经验、不了解 coding agent 所做取舍，却凭感觉写代码的开发者，往往很难取得同样好的结果——他们通常不知道应该向 coding agent 提供哪些上下文，因此 coding agent 做出的取舍往往并不理想。”
没错。这部分最接近传统的 SWE 工作流。LLM 会放大专业能力——它们提升高水平开发者上限的幅度，远高于提升低水平“凭感觉编程者”下限的幅度，不过两者都能从中受益。
使用 coding agents。“如今，对每位开发者来说，高效使用 agentic coding 已成为一项关键技能。掌握这项技能，你就能建立起对 agents 工作方式的正确心智模型，了解它们的局限以及应对方法，并能快速引导它们——知道什么时候该介入、什么时候该放手——在不浪费过多时间或 tokens 的前提下，构建稳健的软件。你还需要知道如何依据清晰的 spec 开展工作（以及什么时候没必要费这个功夫）、如何编排多个协同工作的 agents，并避开诸如 agent 搞砸生产数据库之类的风险。由于 agentic coding 发展迅速，熟练使用 coding agents 不仅意味着掌握前沿实践，还要养成持续尝试新工具的习惯，并随着最佳实践的变化不断优化工作流。”
2023 年我们第一次聊到“1000 倍 AI 工程师”时，Copilot 还是唯一的主流选择。当时这一点最不明显，但显然已经初现端倪。2024—2026 年间，coding agents 爆发式发展，Cursor 上演了从 0 到 600 亿美元的史诗级增长，Claude Code、Codex、Cognition、Cline，以及其他名字不以 C 开头的 coding 强者也纷纷崛起。在这一领域保持敏捷是一大优势，但也要提防那些陷入 LLM 迷思、疯狂追求 token 用量的人。
把握构建方向。“高效的 AI 工程要求具备产品意识，理解业务背景和客户目标，这样才能参与并推动产品构建……要抓住这一机遇，就必须知道如何推动项目向前发展。比如，什么时候应该快速做出 MVP 交给用户测试，以及什么时候应该放慢脚步，投入更多时间把产品打磨得更扎实。”
这或许是 AI Engineering 中唯一一个最初那篇文章没有预见到的部分。我们在 World’s Fair 2024 中加入了 AI PM 方向，后来又增加了 Design Engineering 等相关方向，因为产品开发两端的边界都开始迅速变得模糊。
总的来说，这是对 DeepLearning.AI 重点方向的一次出色更新。欢迎 Andrew 和团队加入！
AI News 2026 年 8 月 22 日至 24 日。我们浏览了 12 个 subreddit、544 个 Twitter 账号，没有再查看其他 Discord。你可以在 AINews 官网搜索往期所有内容。提醒一下，AINews 现已成为 Latent Space 的一个栏目。你还可以选择接收或取消接收不同频率的邮件！
AI Twitter 速览
Agent Harness、持久化 Agent 与企业级 MCP
Harness 设计正成为主要的优化方向：多篇帖子都提到，Agent 的质量越来越取决于 Harness，而不只是底层模型。NVIDIA 最新的评测工作指出，对 Agent“技能”进行结构化检查，几乎无法预测其实际效用——扫描得分与人工评定质量之间的 Spearman ρ 相关系数仅为 0.14——并提出改用 “Skill Lift” 进行衡量：在完全相同的条件下，分别使用和不使用某项技能完成同一任务，再比较最终完成工作量的差值（@omarsar0 提供的论文摘要）。与此同时，一篇讨论 Anthropic 风格 Harness 的立场论文认为，企业应统一采用一套可复用的编码 Agent Harness，而不是为每个场景单独搭建编排流程；在企业任务中，Harness 的选择甚至可能比模型选择更重要（@dair_ai 提供的摘要）。
持久化、自我修改型智能体正从概念走向开源实现：@andykonwinski 发布了 Headlong，这是一个面向持久化智能体的开源“微型 harness”。这类智能体无需等到收到请求才行动，而是能够持续思考。该系统将运行轨迹存储为由 jsonl 文件组成的 DAG，并持续运行自我引导的内部循环。据称，它曾在无人值守的情况下用 48 分钟完成自我调试和修复；代价是后台持续思考每小时约需 $1–$2，偶尔还会因自我修改而导致故障。与此同时，@omarsar0 介绍了 exo，一种用于递归式自我改进的 harness 架构，具备只追加事件日志、可替换执行器，以及支持快照和回滚的沙箱。这套设计明确确保智能体可以重写 prompt、工具和记忆，却无法破坏持久化状态。综合来看，这些项目表明，下一波智能体基础设施关注的将不只是更好的 prompting，还包括持久性、分叉、回滚和持续运行。
MCP 正逐步成熟为企业级基础设施：Anthropic 推出了 MCP connector 的企业托管身份验证，通过组织的身份提供商统一管理授权。这样一来，终端用户无需再为 Asana、Atlassian、Canva、Datadog、Figma、Notion、Slack 和 Supabase 等 connector 分别进行 OAuth 操作（@ClaudeDevs 发布的公告）。此外，MCP 路线图还公布了即将支持的功能，包括通过 streaming/server push 处理长时间运行的工作负载、为本地服务器提供 HTTP 支持、面向大型目录的渐进式发现，以及标准化身份和委托权限（@_philschmid 的路线图总结）。这些进展填补了玩具级 Demo 与可审计的企业部署之间的一大空白。
模型发布、泄露与竞争定位
Qwen3.8-27B 继续展现出超越自身规模的实力：在 Code Arena: WebDev 榜单中，Qwen3.8-27B 以 1595 分位列总榜第 9，是该参数规模中唯一进入前十的模型，仅比 Qwen3.8-Max 低六名（@arena 发布的榜单更新）。它在消费类产品、品牌与营销、游戏等类别中同样排名靠前。与此同时，@kaiostephens 发布了一个相关的开源衍生模型 Carnice-V3-27B：这是一个基于 27B Qwen、经过 Hermes-agent SFT 的模型，目标是在消费级 GPU（3090 及以上）上运行，并提供合并后的 BF16 和 GGUF 版本。
围绕尚未发布的前沿模型，传闻持续升温：多条推文提到了疑似提前访问权限，或捕捉到了尚未发布系统的相关踪迹。据称，名为 “claude-melon-eap” 和 “claude-marshmallow-eap” 的 EAP 模型，主要面向 3D 和 RL 类任务，并会使用大量思考 token（@Lentils80 的演示）；@kimmonismus 汇总了有关新 Claude 模型、Ox Alpha、Qwen 4 以及已确认存在的 GPT Astra 的各种迹象；@eliebakouch 则声称接触到了一个仍在训练中的模型，并指出其对应的 W&B 运行记录已公开。大多数信息目前更应被视为生态动向，而非经过证实的模型规格。不过，值得注意的是，当前讨论的重点越来越从公开发布，转向预发布模型访问权的不对称——这也呼应了@michael_nielsen 的警告：控制尚未发布模型的访问权限，正逐渐成为权力集中的新来源。
OpenAI 与 Anthropic 的定位仍在变化：OpenAI 开发者宣布，GPT-5.6 已在 Kiro 中上线；在 Kiro 面向 Terra 变体的规范驱动环境里，每个成功完成的 Terminal-Bench 2.1 任务据称可降低约 82% 的成本（公告）。OpenAI 还将 GPT-5.6 Sol API 的价格下调至输入每百万 token 4 美元、输出每百万 token 20 美元（@kimmonismus 提供的价格说明）。Arena 的最新数据则显示，Sol 和 Luna 正在重新定义成本与性能之间的 Pareto 前沿（@arena）。Anthropic 方面，@tenobrus 指出，过去六个多月里，Opus 系列一直没有明确的升级；不过，外部测试者称，新版 Claude 在中等难度推理任务上的表现更强（@kimmonismus）。
推理、基准测试与成本效率
工具延迟重叠正成为提升 Harness 整体速度的关键手段：@a1zhang 介绍了 Speculative Programmatic Tool Calling（sPTC）。它会在生成代码时预测安全的工具调用，并提前在环境副本中启动，让工具执行与 token 生成并行进行。目前提升幅度还比较有限，约为1.0–1.2 倍，但这一机制的意义在于：优化重点正从 token 级解码技巧转向Agent 工作流流水线化。@lateinteraction 将其类比为 CPU 的推测执行，并强调只要大多数预测正确，少量被丢弃的计算就是可以接受的。
Token 统计和 benchmark 规范依然混乱：多篇帖子指出，当前的报告方式容易误导。@bnjmn_marie 分享了一次 DeepSWE 运行记录：输入 Token 达到 918.9M，并澄清其中很多是缓存命中；而 @cHHillee 则直言，把缓存的输入 Token 计入“Token 用量”是“蠢得离谱”。在评测方面，@jmbollenbacher 警告，如果量化模型在某个 benchmark 上超过参考模型，可能意味着它只是过拟合了量化配置，并不代表真正有所提升；@xeophon 总结了更广泛的启示：修正评测方法，可能比不断优化评测分数更重要。
按成本归一化的 agent benchmark 持续影响模型选择：Together AI 报告称，在$100 的预算内，GLM-5.3 在 DeepSWE 上完成的工作量是 Fable 5 的 5 倍，大约解决了 17 个任务，而后者为 3 个；但两者首次尝试的表现相近（推文）。@reach_vb 也报告称，GPT-5.6 Sol Max 在 DeepSWE v1.1 上的成绩为 72.7%，每项任务成本 $6.47；相比之下，Fable 5 Max 的成绩为 69.7%，每项任务成本 $21.63。Cline 还用一个真实 bug 修复任务比较了 Ox Alpha 和 Fable：两者都成功解决了问题，但 Ox 使用的输出 Token 约少了3 倍。这说明两者在后训练理念上存在明显差异：前者更重视重新验证，后者则更倾向于直接执行首次结论（@cline 的对比）。
端侧 AI 与推理系统
Liquid AI 与 Artificial Analysis 联手推出了一套严肃的端侧基准测试体系：@liquidai 发布了开源评测套件 Pipette，用于评估端侧推理在不同模型、量化方案、运行时和设备组合下的质量、速度、延迟与内存占用。目前已收录1 万多条经过验证的结果，覆盖35 类模型、7 种量化方案、llama.cpp 运行时和四款设备。Artificial Analysis 则在此基础上，针对iPhone 17 Pro 和 Galaxy S26 Ultra 开展了独立的手机端智能评测（完整讨论串）。
手机端测试呈现出与云端评测不同的性能前沿：在8 GB 内存、16K 上下文的限制下，Nanbeige4.2-3B 和 LFM2.5-2.6B 以63 分并列平均得分第一。不过在 iPhone 上，LFM2.5-2.6B 的效率明显高于 Nanbeige：前者耗时8.0 秒、占用2.3 GB内存，后者则分别为21.4 秒和4.0 GB。LFM2.5-8B-A1B、Ling 3.0 Tiny 等 MoE 架构同样值得关注，它们每个 token 只激活约10 亿参数，因此能在手机硬件上实现低于 6 秒的响应。评测还明确显示，许多看似“聪明”的推理模型并不适合移动设备的内存和延迟限制。
推理服务商的竞争焦点已从单纯的 TPS，转向面向智能体的吞吐能力：据介绍，NVIDIA 的 Groq 3 LPX 将为 Vera Rubin 配备专用 token 生成加速器。Artificial Analysis 的基准测试显示，在 100K context 下运行 Gemma 4 31B 时，其输出速度可达 3,400 output tokens/s（@kimmonismus 总结）；Groq 表示将成为首批把该产品部署到生产环境的厂商之一（公告）。另一方面，vLLM 发布了基于真实多轮编码轨迹的大量 AgentX 1.0 测试结果，强调要实现高智能体吞吐，关键在于 KV offload、prefix reuse 以及 prefill/decode disaggregation，而不是传统的单轮服务指标（@vllm_project）。
研究、论文与技术教育
LLM 的 RL 与 harness-native training 依然是热点：@cwolferesearch 发布了一份全面的 reinforcement learning 指南，涵盖 token-level 与 completion-level formulation、PPO/GRPO 变体、actor-critic 方法、基于 rubric 的 RL，以及 agentic RL/world modeling。与此同时，业界对“harness-native”RL 和 agent environment 的关注持续升温，相关讨论见于 @TheTuringPost 等论文汇总，以及对 Agent Lightning、LEGO-RL、EnvHarness 和 SkillGate 等论文的介绍。
其他值得关注的研究方向：Meta/USC 的 Periodic Row-wise Muon 通过摊销开销高昂的 Newton–Schulz 更新，将 Muon 优化扩展到更大规模的 diffusion transformer，同时仍保持相较 AdamW 的性能优势（@iScienceLuvr 总结）；Adobe 的 Latent Dynamics Reasoning 通过建模潜在状态的演化，而不是直接预测未来画面，从像素中学习具备外推能力的视频世界模型（论文，来自 @_akhaliq，作者说明）；Cartwheel 则公布了人类运动生成的计算最优 scaling laws，认为运动可能成为继文本、图像等之后的第五种模态，并呈现类似 Chinchilla 的 scaling 特性（发布信息）。
值得收藏的学习资料：@fchollet 推荐 Deep Learning with Python 第 15、16 章，称其是通俗解释点积 attention 为何有效的最佳材料之一；@ProfTomYeh 发布了手算 self-attention 的详细教程；@mervenoyann 则宣布了 llama.cpp docs 的新主页，后续还将加入有关推测解码、量化和 coding agent 的内容。
热门推文（按互动量排序）
产品/UI 实测性能：Anthropic 表示，Claude 网页版和桌面版现在可以更流畅地输出长答案：在较慢的笔记本上，卡顿减少约 9 倍，最严重的冻结时间缩短约 4.5 倍，整体流式输出流畅度提升约 4 倍（公告）。
更快的图像生成体验：@samdape 展示了一种让 GPT 更快生成图像的技术。
OpenAI 的研究文化：@gdb 转发了 @kundan2510 的帖子，称赞 OpenAI 愿意长期投入全双工模型等方向。
学习资源：@fchollet 推荐《Deep Learning with Python》中的 attention 章节，是这批内容中信息价值最高的教育类帖子之一。
企业级 MCP：Anthropic 为 MCP connectors 推出的企业统一管理身份验证，是生产环境部署智能体最具影响力的平台更新之一（公告）。
AI Reddit 速览
/r/LocalLlama + /r/localLLM 速览
1. Qwen 3.8 27B 的编程与量化基准测试
“Qwen 3.8 达不到 Opus 水平”：我重新跑了一遍测试。（热度：911）：图片（链接）显示，作者使用 Deepseek/pi.dev 风格的编程测试框架，让
qwen3.8-27b以“Plan”模式完成 C#/OpenGL 海洋渲染任务。这支持了原帖的观点：测试框架的质量会显著影响人们对模型能力的判断。在作者重新测试时，同一个 Qwen3.8 模型和提示词在 VS Code Copilot 中运行失败，只得到黑屏；换用另一个框架后则成功了。据称，该框架会利用截图反馈，并且在未启用视觉能力时甚至自行生成 PNG 解码器。模型在 RTX 5090 上运行ninfer-nvfp4构建版本，使用约190k上下文，以约150–180 tok/s的速度，在大约1 hour内生成了海浪、天空、太阳和水下视图。评论者普遍认为，这一结果说明，“偷懒”或受沙箱限制的编程框架，与具备执行和截图反馈能力的智能体框架之间存在巨大差距。最初批评 Qwen3.8 的作者也承认先前的结论有误，并开始使用 pi.dev 重新测试，称与 VS Code/BYOM 搭配 llama.cpp 相比，前者崩溃更少、内存占用更低。一个重要的技术主题是：工具链的质量可能比模型本身更能决定用户对其能力的感知。有评论指出，Qwen 3.8 似乎实现了一个“即时 PNG 解码器”，即使最初的执行环境配置不当或受到限制，仍然成功生成了可运行的海洋着色器。大家据此认为，像 Copilot 这类带沙箱的工具环境，可能无法充分展现编程代理在拥有完善运行时和测试闭环时的实际能力。
最初的测试者承认之前的工具链不够完善，随后从通过 BYOM 连接 llama.cpp 的 VS Code 切换到了pi.dev。他们在 VS Code 环境中发现了两个具体问题：启动测试可执行文件后出现驱动错误；同时，来自 Lemonade SDK 的 llama.cpp RocM 1200 构建版本仍在运行且没有输出错误，但 VS Code 会随机崩溃。相比之下，pi.dev 没有崩溃，而且内存占用明显更低。
几位评论者比较了pi.dev/OhMyPi、opencode 以及本地llama.cpp方案，关注这些代理工具链相比标准 Claude 式聊天流程究竟能提供多少自主性。硬件限制也是讨论焦点：有人推测，配备RTX 5090或类似高端本地 GPU，并结合Ninfer等工具，或许能让本地代理式编程工作流变得更实用，无需订阅云服务。
Qwen3.8:27B：将 3.9 万行 C 代码移植为单文件 HTML / Three.js（活跃度：655）：一项单次运行的 Agent 基准测试，尝试将一个
2.1 MB、包含39k行代码、约600ktoken 的单文件 C 过程式射击游戏（skill-issue）移植为单文件 HTML/Three.js。原始代码长度超过可用262,144token 上下文的两倍。在配备 RTX 6000 Pro 96GB、使用 vLLM、FP8 权重和 FP8 KV cache 的环境中，Claude Code + Opus 5 用时21 min、生成1759行代码，产出了唯一一个“还算可以”的移植版本；通过 hermes 调用 qwen3.8:27b 则耗时4h18m、生成949行代码，通过 codehamr（repo）则耗时1h40m、生成1056行代码，但两者都被评为“很差”。评论者指出，直接提示模型“转换这段代码”，往往会让模型重新臆造程序行为；更可靠的流程是先生成一个 transpiler，得到可以运行的目标语言代码，再逐个函数迭代重写，并通过高层像素对比或底层寄存器/状态信息进行校验。 技术讨论主要围绕本地运行效果不佳的原因展开：究竟是 prompt/harness 设计问题、缺少任务拆解和测试，还是推理配置导致的。多位评论者提醒，FP8 KV-cache 量化可能会明显损害长上下文性能，建议关闭该选项后重新测试。也有人认为，墙钟时间上的差距本来就可以预期，因为 Anthropic 能够使用更多硬件进行并行处理；他们建议先测量 vLLM 的 tokens/sec，先做规划，将单体 C 文件拆分成多个模块，并在移植前加入行为测试。一些评论者认为，即使使用 frontier model，直接提示“转换这个代码库”也会让模型重新臆造源代码，而不是保留原有行为。有人建议先让模型协助编写一个面向目标语言的 transpiler，然后逐个函数迭代重写，同时通过高层像素对比或底层寄存器/数值追踪进行验证，最终实现像素级一致。
多条评论质疑了推理配置，尤其是FP8 KV-cache 量化、Q8，以及没有在 RTX 6000 级别的 GPU 上运行完整的bf16 Qwen 27B模型。评论者担心，在长上下文代码移植任务中，KV-cache 的压缩或量化可能严重影响输出质量；如果取消 FP8 KV-cache，或改用完整的 bf16 配置重新测试，就能更好地区分模型本身的能力与量化引入的误差。
有技术分析认为，运行时间过长的一个原因是vLLM反复处理 KV-cache：如果引擎释放了会话缓存，那么在生成新 token 之前，可能要花几分钟重新计算此前的上下文。一位评论者建议使用LMCache将 KV-cache 持久化到 RAM 中，并指出云服务商通常会跨轮次缓存已处理的上下文，从而避免这类延迟。
