劈柴哥和哈萨比斯亲自站台！谷歌世界模型 Project Genie 刷屏，幕后团队揭秘 60 秒不是极限，内存是巨大约束
世界模型真的变天了！今天，谷歌正式发布重磅世界模型原型产品“Project Genie”，只需一句话或一张图，就能一键生成可玩、可交互的实时虚拟世界。它的重磅程度，让谷歌“掌舵人”劈柴哥和 Google DeepMind 创始人哈萨比斯亲自为它站台。在 Project Genie 生成的虚拟世界中，你可以用 WASD 键移动角色、旋转视角、跳跃，在生成世界自由探索。更重要的是，其生成画面的精细度、整体完成度，已经明显超出以往研究型 Demo 的范畴，在观感上直逼成熟游戏产品。过去几年，世界模型一直被认为是通往 AGI 的重要路径，但始终存在一个根本问题：它们更像会动的视频，而不是真正的环境。具体来说，早期世界模型普遍存在几大短板：生成世界质量偏低，结构简单难以实时交互，或只能交互一两步长期一致性差，画面和规则会“漂移”不符合物理和因果逻辑，更像梦境而非世界而 Project Genie，第一次把这些问题同时拉到了可用水平。Project Genie 是一个基于 Genie 3、Nano Banana Pro 和 Gemini构建的原型 Web 应用，其中的核心是谷歌最新的世界模型 Genie 3。与以往“先生成完整视频”的方式不同，Genie 3 采用自回归生成机制：它会根据世界描述和用户操作，逐帧生成环境状态，而不是播放预先生成好的内容。这带来了几个关键变化：长期一致性生成的世界可以在数分钟内保持稳定，不会快速崩坏；系统还能“记住”用户造成的关键变化，记忆时间最长可达约一分钟。真正的实时交互世界以 20–24 帧/秒运行，用户的操作会即时反馈到环境中，而非触发预设结果。更高质量的视觉表现生成画面分辨率约为 720p，整体真实感和细节水平明显高于以往世界模型，为智能体理解复杂环境提供了更可信的视觉基础。谷歌早在 2025 年就将 Genie 3 称为“通往 AGI 的关键一步”。而在 Project Genie 的官方页面中，谷歌再次强调：Genie 3 让智能体能够预测世界如何演化，以及自身行为如何影响世界，这是实现推理、规划和现实行动的基础。可以说，在 Project Genie 身上，已经释放出一个非常明确的信号：世界模型正在从长期的前沿研究方向，正式迈入可落地、可探索的关键阶段。一旦世界模型能够稳定生成高质量、可交互、具备长期一致性的环境，其应用边界将被迅速打开。无论是自动驾驶中的复杂场景模拟、具身智能的环境理解与决策训练，还是游戏开发、影视制作、互动教育与新型媒体内容创作，世界模型都展现出极具想象空间的潜力。据 The Verge 报道，谷歌选择在这一时间点推出 Project Genie，部分原因在于希望观察用户的真实使用方式，从而发现此前尚未预料到的新应用场景。Google DeepMind 产品经理 迭戈·里瓦斯透露，谷歌内部已经对 Genie 在电影制作、互动教育媒体等领域，帮助创作者进行场景可视化与世界构建的潜力感到兴奋。目前，Project Genie 仍是实验性产品：单个世界最长探索 60 秒分辨率约 720p，帧率约 24fps仅向美国地区、18 岁以上的 Google AI Ultra 订阅用户开放Project Genie 发布后迅速引发热议。马斯克第一时间发文祝贺关于 Project Genie 的讨论，也在 X 上迅速扩散，不少网友将其称为又一个“变革时刻”。对此，Project Genie 负责人之一 Jack Parker-Holder 表示：Genie 3 感觉像是世界模型领域的一个分水岭。我们现在可以生成任何可想象世界的、持续数分钟的实时交互式模拟。这可能正是具身通用人工智能此前缺失的关键一环。网友们玩疯了，在游戏世界释放创意具体来看，Project Genie 的使用流程并不复杂。进入页面后，用户可以直接从 Google 预设的多个世界模板中选择，也可以完全自定义环境和角色，构建一个专属的虚拟世界。为实现更精准的控制，Project Genie 会用 Nano Banana Pro 的能力，先为生成世界打个“草稿”。整个页面被清晰地分成左右两部分：左侧用于填写环境的 prompt，例如地形结构、视觉风格和整体氛围；右侧则用于描述主角的形象与设定，并可选择第一人称或第三人称视角，从而提前确定进入世界后的体验方式。完成初步设定后，Genie 会先生成一个缩略图，可以对生成内容进行预览和微调。如果符合预期，就能进入生成世界，开始实时交互与自由探索。Genie 3 的响应延时非常低，在控制角色移动时，会带来强烈的沉浸感。在官方案例中，你可以把自己变成一个球，在草原上自由滚动。可以看到，如果转换视角，球滚动留下的痕迹并不会消失，新生成的内容也不会覆盖旧区域。这一细节直观地体现了 Project Genie 所强调的世界一致性。在另一个官方案例中，你可以变成刷墙工人，想刷哪面墙就刷哪面，整个虚拟世界可以实时交互，且看起来十分合理。谷歌表示，这是想象力空间的无限释放，无论是自然世界或现实场景，还是构建动画、小说中的奇幻世界，甚至是突破时间与空间限制的未来世界，都可以被创造出来。不少网友迅速上手，开始“放飞自我”式创作，其中，各类游戏风格世界不断涌现。比如在沙滩上骑摩托：更绝的是直接制作山寨版“任天堂”游戏。比如马里奥系列，《塞尔达传说》，《银河战士》。即便抛开体验层面的不足不谈，Project Genie 在生成世界的质量与完成度上，依然足以令人震撼。这也难免让人产生进一步的联想，游戏从业者会不会大规模失业？这一担忧并非空穴来风。根据 Informa 本周发布的游戏开发者大会（GDC）报告，33% 的美国受访游戏开发者、以及 28% 的全球受访游戏开发者表示，他们在过去两年中至少经历过一次裁员。Project Genie 可能会进一步扩大这种趋势。不过，围绕 Project Genie 的能力边界，也有人提出质疑。The Verge 的记者亲自上手试验后认为，从“游戏”的角度来看，Project Genie 所生成的“可玩世界”显得相当单调。除了基础移动操作外，玩家几乎无事可做。没有任务目标，也缺乏音效反馈。更糟糕的是，输入延迟时有发生，甚至会出现角色失控、只能旋转视角的情况，严重影响整体体验的流畅度。该记者还提到，在仅有 60 秒 的探索时间内，世界的一致性并不稳定。系统有时会“忘记”此前生成的内容，例如滚动的小球留下的颜料痕迹会突然消失，已生成的道路也可能被重新覆盖为草地。这些现象让人难以确认模型是否能够持续、可靠地维护同一个世界状态。在内容生成层面，Project Genie 对知名游戏 IP 也存在明显限制。测试中，索拉、唐老鸭、高飞、杰克·斯凯灵顿等角色均无法直接用于生成可交互世界，相关内容在进入实际体验阶段会被系统拦截。目前，与生成世界交互的智能体只能执行较为有限的操作，同一世界中多个模型之间也难以协同互动。此外，Genie 在渲染清晰文本、还原现实世界具体地点方面仍存在困难，智能体对控制指令的响应有时也会出现异常延迟。对此，谷歌方面回应称，Genie 并非游戏引擎，团队更关注它在增强创意过程、提升构思能力以及加快原型制作方面所展现出的潜力。在 Geinie 3 官网上也特别强调，目前产品仍处于早期研究阶段，因此会有：生成的世界可能看起来并不完全逼真，也不一定总是严格遵循提示、图像或现实世界的物理规律；角色有时可能难以控制，或者控制延迟较高；生成时间受限等问题。Project Genie 团队深度揭秘关键问题在 Project Genie 上线不久，其背后的核心团队第一时间接受采访，包括 Google DeepMind 研究总监 Shlomi Fruchter、Google DeepMind 的研究科学家 Jack Parker-Holder、产品 Diego Rivas，他们都对世界模型长期关注，在这次访谈中深度揭秘 Project Genie 的关键问题。这次对话讨论了：什么是世界模型？为什么只能生成 60 秒？Project Genie 的研发历程是什么？它未来真正可能改变的是哪些领域？他们首先承认 Project Genie 的强大确实源于谷歌视频生成技术的积累，但同时他们也强调，Genie 并不是更强的“视频模型”，而是人类第一次可以实时走进、操控、改变的生成世界。其中的核心差异是，世界模型是逐帧实时生成，能与过去保持物理与视觉一致性，并且用户可随时干预。这对延迟、内存、算力的要求，比普通视频生成高得多，也是更前沿、更有挑战的方向。针对不少人抱怨“60 秒不够”的问题，他们表示这是在服务成本、系统稳定性和体验质量之间做出的权衡。他们其实已经做出过更长时间的生成世界，但在实际测试中发现，随着生成时间拉长，世界的动态感反而会逐渐减弱。研究员表示“与其花两分钟体验一个世界，不如花一分钟体验两个不同的世界，体验感会更好。”针对模型的生成速度，他们表示已经够快了，短期内进一步“加速”并没有太大意义。接下来，他们更重要的研发方向，是降低算力成本，让这种能力能够被更多人真正用得起。在产品定位上，他们并不把 Genie 看作一款游戏，而更像是一个正在快速演化的实验场：一方面，多人互动、长期一致性、复杂动态仍然是明确的技术瓶颈；另一方面，娱乐、教育、具身智能、机器人训练等方向，已经展现出非常清晰的应用前景回顾产品研发历程，从论文阶段的 Genie 1，到今天普通用户可以亲自上手体验的 Genie 3，这背后其实是谷歌一整套高度协同的跨部门合作。谷歌实验室与谷歌创意实验室是研发的核心力量，而服务团队、基础设施团队和沟通团队则共同兜底，确保这项起源于强化学习的前沿研究，能够被真实用户理解、体验并持续使用。当团队回看去年八月时，他们很清楚，当时外界已经迫不及待想“走进这个世界”，但 Genie 仍然只是一个规模庞大的研究项目。即便如此，研发人员脑海中已经浮现出一系列潜在应用场景，其中最清晰的方向之一，正是具身智能。一个标志性的例子，是他们与 Simmer 项目的长期合作。Simmer 是由双子座模型驱动的目标导向智能体，能够在 3D 世界中执行复杂任务。过去，它只能在少数几个固定游戏环境中训练；而现在，借助 Genie 3，只需一句文本指令，就能生成一个全新的、甚至是照片级写实的虚拟世界，把智能体直接“放进去”完成任务。从 Nano Banana Pro 的图像创作，到谷歌视频生成的成熟，再到可交互的世界模型 Project Genie ，生成式技术正在构成一个连续体，世界模型将成为第三次技术跃迁。以下是播客的更多细节，欢迎来看：为什么只能 60 秒？主持人：我很好奇，这背后的物理逼真度，是不是和我们在 VO（谷歌的视频生成模型）项目上取得的研究突破有关？感觉两者之间有相似之处。研究员：二者绝对是相关的，而且世界模型的研发难度其实更高。普通的视频模型，能在整个视频的时间线上自由调整过去和未来的帧，自由度很高 —— 就像有一块画布，模型能随时间生成视频，在画面的各个位置做微调，让整体效果连贯美观。但世界模型的难点在于，世界是持续演变的，每一帧的输入都是未知的，模型必须保证生成的画面既和过去的内容连贯，又能匹配用户当下的操作，所以技术难度会大很多。其实开发 Genie 1 时，我们用的是 Imagine 模型，当时我们的模型效果并不好，而且想要生成合适的图像也非常困难。Nano Banana Pro 是在Genie 3 之后推出的，技术进步的速度真的令人惊叹。也许未来某一天，我们定义虚拟世界的方式，将不再局限于图像和文本，但就目前而言，这种方式已经给了用户足够的创作灵活性。主持人：这个模型的复杂度上限在哪里？比如能不能在同一个世界里加入大量并行的互动元素？模型会在什么情况下出现效果衰减？其实 Nano Banana Pro 就是个很好的例子，如果一张图片里有 10 个人脸，想要对这张图进行编辑，模型就容易出问题。所以我想知道，Genie 3 的自然性能边界在哪里？研究员：这个模型肯定不是完美的，目前它还只是一个研究预览版本。我们希望让大家亲自体验，看看它的优势在哪里，不足又在哪里，我们也能从用户反馈中学习和优化。目前模型在各类创意环境的视觉呈现上做得不错，画面可以非常精致，但在世界的动态表现上还有短板 —— 有时候初期的动态效果很好，但时间久了，动态感会逐渐减弱，这也是我们正在优化的点。不过它的表现已经足够令人惊喜了，所以还是建议大家亲自上手试试，看看哪些玩法能达到理想效果。研究员：不过说到延迟问题，还有很多技术点需要考虑。Genie 3 的研发有一个核心约束：我们希望实现特定操作频率下的实时低延迟，也就是说，用户操作的往返延迟要极低。同时，内存也是一个巨大的约束 —— 模型的上下文长度越长，通常算力成本就越高，运行速度也会越慢。所以研发的核心挑战，就是平衡这些相互冲突的目标。而在研究层面，我们正在所有这些领域持续优化，我们相信，模型的性能会不断提升，变得更强大、更快、更经济，这也是行业的整体发展趋势。主持人：我还有个问题，模型的生成时长是人为限制在 60 秒，还是真的能实现 3 到 5 分钟的连续生成？研究员：其实我们已经做出过能连续生成更久的演示版本了，但我们觉得 60 秒是一个比较合适的时长 —— 既能让用户充分体验虚拟世界，又能保证为足够多的用户提供服务，这其实是在服务成本上做的权衡。而且就像我们之前提到的，生成时间越长，世界的动态感会逐渐减弱。所以我们觉得，与其花两分钟体验一个世界，不如花一分钟体验两个不同的世界，体验感会更好。当然，如果用户反馈希望延长时长，我们也会做出调整。这也和虚拟世界的类型有关，比如如果你在体验高山速降滑雪，两分钟的时长会很过瘾，因为整个过程是持续的动态体验；但如果只是探索图书馆，两分钟可能就没那么有趣了。主持人：是啊，人们总是能很快适应新的技术体验。但对我来说，这个模型的表现依然令人难以置信。你之前被问到能不能让模型运行得更快，现在的速度已经到极限了吗？研究员：在当前实时交互需求下，生成速度已经足够快，短期内进一步加速的意义不大。因为模型是实时生成虚拟世界的，速度再快其实也没有意义了 —— 它的生成速度已经和用户的体验速度完全匹配。接下来我们的研发重点，会放在降低算力成本上，这样才能让更多人用上这款产品。同时，在保持速度的前提下，不断增加新功能，这本身也是一个巨大的挑战，我们希望在各个方面都把模型做得更好。背后的故事：谷歌跨团队协作主持人：聊完当下的体验，我特别想知道模型的未来迭代方向。不过在聊未来之前，我们先回顾一下研发历程吧。我们八月份发布了 Genie 3 的首支演示视频，之后启动了可信测试，不断迭代产品、搭建基础设施。能不能跟大家快速讲讲，从一支惊艳的演示视频、小规模的早期测试，到正式推出面向用户的精灵计划，这中间都经历了什么？研究员：首先，八月份发布模型和演示视频后，我们让一小部分人体验了产品，核心是为了收集反馈 —— 因为这是一款全新的应用，一种全新的体验，我们需要思考如何负责任地将它推向市场。从那以后，我们的大部分工作都集中在基础设施、服务架构和成本控制上，毕竟我们希望能让尽可能多的用户体验到它。而美国的谷歌 Ultra 订阅体系，能让我们触达足够多的用户，收集到第一手的反馈：比如用户觉得哪些功能有用，会如何和产品互动，哪些玩法体验最好。这段时间里，我们也在持续完善可信测试项目。这其实是模型开发周期中最核心的阶段，因为我们能从不同类型的用户身上学到很多东西，无论是创意工作者，还是教育领域的从业者，都能给我们带来丰富的洞察，让我们知道模型目前的实际应用价值、未来的发展方向，以及哪些体验是用户最期待的。回头看八月份，当时我们知道大家肯定想体验这款产品，但它那时还只是一个大规模的研究项目。我们脑海里有很多应用场景，比如智能体、机器人这类具身智能领域，都能用到这项技术。去年年底还有一个和我们类似的项目发布，他们也用Genie 3 来训练游戏智能体。从消费端的角度来看，我们觉得这个产品会很有吸引力，所以想收集用户反馈，但当时也不确定是否已经到了面向更多用户发布的时机。而迭戈主导的可信测试项目，让我们发现，用户第一次上手这款产品时，都会有惊艳的体验。我们希望深入了解更多的应用场景，所以这次的发布，也是我们在这方面迈出的一大步。一年前，我根本没想到这个模型能有这么强的吸引力，但现在它已经成为一款非常有趣的产品，我们也很期待大家会用它来做什么。主持人：聊完产品和技术，我们再来聊聊谷歌的跨团队合作吧。显然，从你们的分享和幕后工作来看，打造这款产品的难度非常大。谷歌内部有哪些团队参与了 Genie 3 和 Genie 的研发？研究员：幕后参与的团队非常多，谷歌实验室、谷歌创意实验室是核心 —— 画廊里的那些虚拟世界，大多是创意实验室的作品；还有服务团队、基础设施团队，基本上有一个完整的幕后团队在推动这项工作。从八月份发布模型到现在，我们一直在全力冲刺，所有团队的付出都堪称英勇。我们还和沟通团队深度合作，因为想要向大家解释一款全新的模型，一种大家从未体验过的技术，是一个非常细致的话题 —— 它起源于强化学习这个相对小众的领域，现在却被媒体、社交媒体上的各类人群广泛讨论，所以用正确的方式传递这项技术，非常重要。回顾这个领域的研究起点，我们甚至不确定这项技术能否成功落地。而现在，我们让它实现了实时交互，达到了不错的画质，完成了从研究构想到发布模型，再到推出面向用户的体验产品的闭环，这一点让我非常兴奋。这并非理所当然，也充分体现了谷歌内部跨技术栈的团队协作能力，这种能力非常独特。主持人：我们在镜头外还聊过，不仅是 Genie 3，谷歌所有模型的能力都在不断拓展，而这和模型的训练方式息息相关。杰克，你之前还尖锐地提到，这些模型其实并没有针对任何特定的应用场景进行训练，却能在各个领域实现很好的泛化能力，能不能再聊聊这一点？研究员：没错，我们一开始其实并不知道这个模型的具体应用场景。去年年底，Genie 团队还在做纯粹的研究项目，Genie 1 最初只是一篇研究论文，和 VO（谷歌的视频生成模型）完全不同。与此同时，我们还在做 Doom 游戏引擎的相关研究，这项研究充分展现了实时交互的潜力，但它仅适用于 Doom 这一个特定的游戏世界，迭戈可以再聊聊这一点。另外，2024 年 12 月 VO（谷歌的视频生成模型）2 的发布，在 AI 领域已经是很久以前的事了，但当时我看到它的效果时就觉得，视频生成技术已经成熟了，视觉质量达到了行业前沿，值得我们深入探索。于是我们达成共识，认为这项技术的潜力无限，随后组建了跨团队的研发小组，汇集了各个领域的专家 —— 他们都在不同的技术领域有积累，我们相信把这些技术结合起来，会产生不可思议的效果。而我们的研发，并非针对某个特定的下游应用场景，而是因为它蕴含着无数的应用可能。最酷的是，我们脑海里有一些预想的应用场景，比如和 Simmer 项目的合作，我们和这个项目的合作已经有很长时间了，他们也参与了 Genie 2 的研发，体验过 Genie 2，现在已经基于 Genie 3 发布了相关产品。Simmer 是我们最强大的目标导向智能体之一，能在 3D 世界中互动，是由双子座模型驱动的 —— 你可以在 3D 世界中向它输入文本指令，它就能完成各种不同的目标，泛化能力非常强，还能通过自我提升学习。这也是我们迈向通用人工智能、具身智能的重要方向。去年年底我们发布了这款智能体，他们就用 Genie 3 的虚拟世界来探索智能体的能力。要知道，Simmer 原本只在几款游戏中接受过训练，但现在借助 Genie 3，你只需输入文本，就能创建一个全新的、甚至是照片级写实的虚拟世界，然后把智能体放进去，看它完成各种任务。这两个项目的结合，可以说是水到渠成。未来的应用领域：娱乐、教育、具身智能研究员：从应用层面来说，我个人对娱乐和教育领域的应用最期待。我们希望让更多人体验这款产品，看看凭借现有的技术，现在能打造出哪些应用。教育领域是我们重点关注的方向，比如让人们在虚拟世界里互动学习 —— 想象一下，能为用户打造一些他们在现实中无法体验的场景，比如一个孩子害怕蜘蛛，我们可以打造一个满是蜘蛛的房间，让孩子在虚拟世界里慢慢适应，克服恐惧。我的孩子就怕蜘蛛，所以我觉得这种个性化的全新体验，价值非常大，这也是我们近期的研发重点。另一方面，我们之前也聊过，机器人技术和具身智能领域的世界模型，潜力也非常大。当然这个领域还有很多研究工作要做，但我个人对它充满期待。简单来说，核心思路就是：如果一个模型能模拟现实环境，那我们就可以用它在虚拟世界里训练机器人，或是让具身智能体在虚拟世界里学习，甚至实时辅助智能体做出决策。Genie 计划虽然现在已经很惊艳了，但它只是一个起点。未来我们会和谷歌实验室继续深度合作，不断优化产品的功能、操控方式、应用架构等；也会拓展更多的使用场景，不局限于Genie 计划这一个应用，还会推出开发者 API，让更多开发者参与进来。不得不说，开发者总能发掘出产品的商业价值，找到极具经济影响力的应用场景，这也是我觉得很有意思的一点 —— 除了娱乐，世界模型还能在哪些领域找到产品市场契合点。而且很多功能在不同的应用场景中是相通的，比如更广泛的交互性。可以肯定的是，机器人技术的发展，不可能只靠方向键来实现，未来的机器人助手需要更多的操控方式，而这和虚拟世界的交互研发是相通的。八月份发布 Genie 3，让我们成为首批推出这类模型的团队，也让我们能和谷歌内部的各个团队展开合作。我们会认真吸纳所有的用户反馈，把大家提出的建议都列出来，成为下一代模型的研发方向。我之前跟杰克说过，我们只实现了目标的 50%—— 因为我们总是会设定极具野心的目标，这个领域还有太多可以探索的地方，模型还有很多不足，需要我们不断优化。这个领域的发展空间巨大，我们才刚刚起步。就像写论文一样，一个项目完成后，你马上就会想，下一个项目可以加入哪些功能，做得更好。现在社区里也出现了很多有趣的世界模型，有些和 Genie 3 很相似，但我们的目光已经放得更远了。怎么玩这个产品？主持人：除了研发历程和未来规划，还有没有什么想跟大家分享的？比如对于即将体验这款模型的用户，你们有什么建议？毕竟你们比普通人花了更多时间研究和使用模型。研究员：我建议大家尝试个性化创作，打造属于自己的、其他系统无法实现的世界。当然，用它打造游戏环境也很有趣，但这类场景其他系统也能做到；而把现实中的专属事物 —— 比如一个玩具、一张照片，或是让自己以特定风格出现在真实的环境中，这种体验是独一无二的。这让我想起了 VO（谷歌的视频生成模型）早期的一个研究项目：有人用 VO（谷歌的视频生成模型）为阿尔茨海默病患者重现童年记忆，让他们在虚拟世界里重温过去，这个项目特别棒。所以我觉得，把个人专属的事物融入虚拟世界，让它们 “活” 过来，这种互动方式非常有价值，大家可以试试这个方向。另外，大家肯定会发现，模型的提示词创作目前还不够完善，但这恰恰是机会。几年后当这个模型变得非常成熟时，大家会想起现在这个阶段，就像我们现在看待 VO（谷歌的视频生成模型）3 一样 —— 现在 VO（谷歌的视频生成模型）3 的每个提示词都能生成优质视频，精灵 3 号的每个提示词基本也能实现预期效果，但在早期，提示词的创作至关重要，甚至有人会花 10 到 20 分钟精心打磨一个提示词。所以如果第一次创作的效果不好，别放弃，这款全新的模型，可能会以你意想不到的方式呈现出惊喜的效果。而且亲自上手体验，你就不是在消费一款产品，而是在探索前沿技术。主持人：太认同了，“探索前沿技术” 这句话简直可以当作产品标语了。我还有一个觉得很有趣的点：当被动的媒体消费变成交互式的体验，会发生什么？这是一片全新的未知领域。过去也有人做过尝试，但现在有了这种真正定制化的交互式媒体叙事，它会给整个媒体和娱乐行业带来什么影响，真的太值得期待了。研究员：还有一个玩法也很有趣，你可以在虚拟世界里设置挑战，把这个世界分享给别人，让对方完成任务，比如从 A 点走到 B 点。这是一种基础的、有目标的游戏体验，现在的模型已经能实现了。比如那个球的场景，你可以让别人用球写出自己的名字，这类简单的挑战都能设置。就像杰克说的，现在的体验虽然还比较基础，但它蕴含着巨大的创意潜力。比如还有一个带环的场景，你可以操控角色穿越环道，体验飞行的感觉，这也是用户发掘的玩法。人们还经常问，行业的前沿在哪里，我们下一步要做什么。我经常会做一件事：长时间沉浸在 Genie 3 的第一人称写实世界里，然后看向窗外，对比虚拟和现实的差距。我认为最终，虚拟世界会和现实世界变得几乎无法区分，虽然今天我们不深入聊这个话题，但从模型的性能发展来看，这显然还有很长的路要走。但如果能生成和现实高度逼真的世界，在里面自由移动、互动、完成各种事情，那该多不可思议。而这也是驱动我们开展这项研究的核心愿景：想象你拥有一个宇宙的副本，你可以在其中随心所欲。显然，这个副本有巨大的应用价值，能用到很多领域。这虽然是一个非常远大、甚至可能无法实现的目标，但它就像北极星一样，一直指引着我们。比如我们这次把恐龙鲍勃放进虚拟世界，其实就是在重构现实空间，给现实事物做有趣的增强。未来这方面的探索，一定会非常有意思。主持人：那到 Genie 5 的时候，我们可能真的会分不清自己是在现实还是在模拟世界里了。世界模型是第三次技术跃迁主持人：我还有一个有点尖锐的问题想问问大家：你们觉得，大多数人体验到世界模型的时间线会是怎样的？世界模型会先通过企业端影响普通人的生活吗？比如企业利用世界模型提高生产效率，打造更好的日常产品；还是说，未来普通人的日常生活中，会直接和世界模型产生互动？如果是后者，这个时间线大概会是多久？研究员：这其实取决于你如何定义世界模型。如果是指交互式的视听体验类世界模型，我认为今年、明年，就会有越来越多的人接触到它，我们也会看到它在一些领域大放异彩，最终成为很多应用的基础功能。但就像现在的视频生成技术，虽然发展很快，但真正融入普通人日常生活的比例其实并不高，世界模型也需要时间来完成用户普及，找到合适的应用场景—— 毕竟视频和图像不同，世界模型又和视频生成不同。而如果是具身智能领域的世界模型应用，很难给出具体的时间线，但这个领域已经在取得不错的进展了。另外，用户的人群特征也很重要：有些经常接触交互式媒体的人，会成为世界模型的早期使用者，他们知道该如何体验；但如果把它交给一个对前沿技术不感兴趣的家人，他们可能会觉得无从下手，体验不到产品的魅力。但具身智能相关的应用，可能在未来 1-2 年就会走进现实，普通人会在生活中直接接触到，所以最终的普及时间，还是取决于用户所处的技术接受曲线位置。还有一点，Genie 计划也印证了一个趋势：生成式技术正在形成一个连续体，从 Nano Banana Pro 的图像创作，到 VO（谷歌的视频生成模型）的视频生成，再到现在Genie 3 的交互式实时媒体创作，成为第三个核心支柱。我们希望未来有更多人能体验到这个连续体上的各类创作体验。主持人：我特别期待看到行业的发展趋势，毕竟 VO（谷歌的视频生成模型）和 Nano Banana Pro 的发展过程中，都出现过一些爆红的玩法，都是我从未预料到的，太疯狂了。研究员：世界模型的发展，和图像、视频生成还有些不同。图像和视频生成的作品，能被数百万人观看，一个人的创作可以被广泛传播，家人、朋友都能看到；而世界模型的独特之处在于，你可以在探索的过程中，不断改变周围的世界，这开辟了很多我们未曾考虑过的新途径、新玩法。图像和视频生成，本质上是用新技术替代或自动化了过去的一些创作方式，当然也带来了新的能力和限制；但世界模型，实现了很多过去根本不可能做到的事情，这是它最大的不同，当然二者也有很多相似之处。还有一个我们非常兴奋的想法，大家在演示中也能看到端倪：用户可以在现有虚拟世界的基础上继续创作，这样就会形成很多有趣的世界分支，还能追溯创作源头。这方面的潜力非常大，值得我们深入探索。Genie 计划上线时，用户可以下载自己的虚拟世界演示视频；未来我们还会探索更多的世界分享方式，让大家能以更有趣的方式在别人的世界基础上创作。主持人：太酷了，我还想要一个 “世界档案” 功能，这样大家就能看到我所有的创意想法了。从世界模型的发展来看，技术进步的节奏是怎样的？显然我们已经看到了巨大的进步，图像生成、VO（谷歌的视频生成模型）视频生成、核心双子座模型，都取得了长足的发展。世界模型是不是也在遵循同样的发展轨迹，到处都是触手可及的技术突破，同时受益于算力规模和推理能力的提升？研究员：可以这么说。图像生成技术显然比视频生成更成熟，视频生成和世界模型之间的差距，我无法准确衡量，但可以肯定的是，世界模型是超越视频生成的前沿技术。最新一代的视频生成模型，画质已经比Genie 3 高很多了，我们也不指望Genie 3 现在能生成极致精美的视频，因为实时交互的约束，是普通视频生成模型所没有的。所以世界模型的发展，可能会比视频生成稍慢一些，但它能带来全新的体验。说实话，我们现在仍处于技术快速进步的阶段。硬件始终是一个巨大的约束，这对所有模型来说都是如此。行业的整体趋势是，在成本基本不变的情况下，让模型的运行效率越来越高。但最终，我们还是需要更易获取的硬件支持—— 比如希望未来人们能直接在自己的设备上运行这类模型，实现无延迟的即时体验。目前高性能的 TPU、GPU 还并非人人可得，硬件的发展速度因为一些实际原因，会比模型研发慢一些，但这也是我们的未来方向 —— 希望到 Genie 5 时，大家能在手机上运行完整的通用模拟系统。这一点我们也讨论过，谷歌拥有垂直技术栈的优势，这也是我们在谷歌、在深度思维工作的魅力所在：我们既能站在模型研发的前沿，又能利用谷歌最好的硬件来支持模型的运行。而且专门为世界模拟打造的硬件，本身也极具发展潜力，它就像通往另一个维度的入口，点击就能进入，充满了新鲜感。传送门：https://labs.google/projectgenie链接：https://blog.google/innovation-and-ai/models-and-research/google-deepmind/project-genie/https://deepmind.google/models/genie/https://www.youtube.com/watch?v=Ow0W3WlJxRY&t=4shttps://www.theverge.com/news/869726/google-ai-project-genie-3-world-model-hands-on?view_token=eyJhbGciOiJIUzI1NiJ9.eyJpZCI6ImZCakl0bmxFNGwiLCJwIjoiL25ld3MvODY5NzI2L2dvb2dsZS1haS1wcm9qZWN0LWdlbmllLTMtd29ybGQtbW9kZWwtaGFuZHMtb24iLCJleHAiOjE3NzAxNDAwNTYsImlhdCI6MTc2OTcwODA1OH0.q5OBTD_V36-65oc1EGqPxKYCZF00c7ODvifvagVcwbA&utm_medium=gift-link
原文链接： https://mp.weixin.qq.com/s/Zlwn42Ky…TRAE 字节跳动技术团队_2026 年 1 月 12 日 17:02 北京_本文作者：小夏，TRAE 技术专家在 Agentic Coding 实践中，提升效率的关键在于优化与 AI 的协作方式，而非寄望于无限的上下文窗口。核心策略是采用 “短对话、精简上下文” 的模式，将复杂任务拆解为专注的子对话，并借助 “复利工程” 将 bug 修复、代码审查等日常经验沉淀为可复用的项目知识库，使系统获得记忆并实现效率的持续增长。此外，改善开发者体验（如清晰文档、快速测试）具有双重价值，既能帮助人类开发者，也能显著提升 AI 的表现。最终，与 AI 的协作应被视为一门需要刻意练习的技能，通过不断实践，开发者可以成为驾驭 AI 的 “专家型通才”，在更广阔的领域创造价值。第一性原理｜理解 LLM 的本质LLM 是如何「思考」的大语言模型的工作方式可以用一句话概括： 预测下一个 token。当你向 LLM 提问时，它并不是先在「脑中」构思好完整答案再输出。相反，它每次只做一件事：基于当前看到的所有文本（你的输入 + 它已经生成的内容），预测最可能的下一个词是什么。然后把这个词加入序列，再预测下一个，如此循环直到生成结束，这种方式被称为 自回归生成（Autoregressive Generation） 。理解这一点至关重要，因为它揭示了 LLM 的几个本质特征：没有独立于输出的「思考」过程 ： LLM 的推理就是生成本身。它不能先想好再说，只能边说边想。这就是为什么让模型「一步步思考」（Chain-of-Thought）会提升效果 — 你实际上是在给它更多的「思考空间」，让它通过生成中间步骤来辅助推理。尽管新一代模型很多都带有显式的 reasoning 能力，依然脱离不了这个范式。上下文就是全部记忆： LLM 没有独立的记忆存储。它对当前对话的所有「理解」，完全来自于输入给它的上下文窗口。窗口之外的内容，对模型来说就是不存在的。生成具有概率性： 每一步预测都是基于概率分布采样，这意味着同样的输入可能产生不同的输出。自回归（autoregressive）LLM 的核心工作方式是： 一次只预测下一个 token ，然后把自己刚生成的内容再喂回去继续生成。这个机制很强（通用、可扩展、能「写出」复杂结构），但也天然带来一些局限，在 Coding Agent 里这些局限会被放大，因为软件开发是 「长链路、强约束、强验证」 的任务。当前 Coding Agent 普遍存在的问题：局部最优：一步一步「续写」，不等于全局规划容易先写得很像、很顺，然后在后面发现不对再补丁式修修补补（历史债务快速累积）。多文件重构 / 架构调整这种「先规划后落地」的任务，会变成边写边想，导致接口不一致、重复实现、遗漏迁移步骤。对「最终能不能通过测试 / CI」缺乏感知，除非你把测试结果显式喂回 agent 循环。一旦走偏，会沿着偏差继续滚雪球早期误读需求 / 误判代码库的约束 ，导致后面每一步都在错误世界观里自洽。生成了一个不存在的函数名 / 类型后，后续会越来越「相信它存在」，直到编译 / 运行时打脸。在长对话、长任务里尤其明显：越写越像「另一个项目」。输出是流式的，无法回头修改之前输出的内容擅长「写新文件 / 新段落」，相对不擅长在复杂代码中做精确、最小化、局部一致的编辑。容易倾向于「重写一遍」而不是「进行修改」，导致 diff 过大、review 成本高。在需要保持大量不变量（API、格式、风格、兼容性）的仓库里尤其痛苦。满足约束的能力有限，而代码是强语法 / 强语义约束的「看起来合理」的实现，经常在边界条件、并发、错误处理、资源释放上出错。跨文件的符号解析、泛型 / 模板推导、宏 / 代码生成等，靠纯文本推断很容易漏。复杂的重构（rename、move、split）没有 AST / 语义工具辅助时，错一个引用就全盘崩。天然单线程思考，难并行探索在方案选择（架构、依赖、实现路径）上容易早早押注一个方向，缺少系统性对比。排查 bug 时更像「单线推理」，不如人类 / 工具那样并行假设、并行验证Attention：LLM 如何「阅读」上下文在预测下一个 token 时，模型需要从上下文中提取相关信息，这个过程由 Attention（注意力）机制 完成。你可以把 Attention 想象成一个动态的「聚光灯」：当模型生成每个新 token 时，它会扫视整个上下文，对不同位置的内容分配不同的「注意力权重」。权重高的部分会对当前生成产生更大影响，权重低的部分则几乎被忽略。具体来说，对于当前要生成的 token，模型会：计算相关性： 当前位置与上下文中每个位置的相关程度分配权重： 相关性高的位置获得更高权重，形成一个概率分布加权聚合： 根据权重汇总上下文信息，用于预测下一个 token这个机制有几个重要特性：注意力是稀疏的： 模型不会均匀地关注所有内容。在实践中，Attention 权重往往集中在少数关键位置，大部分位置的权重接近于零。注意力需要「学习」的： 模型通过训练学习在什么情况下关注什么内容。这意味着它可能会形成某些偏好模式，比如更关注开头和结尾。计算复杂度是平方级的： 标准 Attention 需要计算每个位置与所有其他位置的关系，计算量随上下文长度的平方增长。这是上下文长度存在物理上限的根本原因之一。理解了 Attention 机制，我们就能更好地理解上下文长度为什么会带来多种限制。上下文长度：最关键的约束上下文窗口的限制是影响 Coding Agent 设计最核心的约束条件。结合对 Attention 机制的理解，我们可以更清楚地看到这个限制的多个层次。物理上限每个模型都有最大 token 限制，目前主流模型通常在 128K 到 200K 之间。这个硬性边界的存在有两个根本原因：Attention 的计算复杂度通常是 O（n²），上下文长度翻倍，计算量变成四倍需要存储完整的注意力矩阵，内存消耗同样是平方级增长超过这个长度的内容根本无法被处理。有效上下文远小于标称上下文虽然模型宣称支持 200K tokens，但这不意味着在 200K 长度下都能保持良好表现。问题出在 Attention 的「稀疏性」上：当上下文很长时，注意力权重需要分散到更多位置。如果关键信息只是海量内容中的一小部分，它获得的注意力权重可能会被稀释到难以有效利用的程度。实际上，一个支持 200K 的模型，可能在超过 80K 或 100K 之后，就开始出现明显的性能退化。性能退化曲线随着上下文变长，不仅是「记忆」变差，模型的整体能力，包括推理准确性、指令遵循能力、代码生成质量都会下降。这是自回归 + Attention 组合带来的累积效应：每一步生成都依赖于对上下文的正确理解更长的上下文意味着更稀疏的注意力分布错误理解会传递到后续生成，形成累积误差理解这些限制，你就能明白为什么 Coding Agent 需要精心设计上下文管理策略，而不是简单地把所有信息塞进窗口。强化学习：让模型学会「做事」前面我们讨论的是 LLM 的基础能力，预测下一个 token。但要让模型从 「能说会道」 进化到 「能做事情」 ，还需要另一个关键技术： 强化学习（Reinforcement Learning， RL）。预训练的局限LLM 的预训练本质上是「模仿」：通过阅读海量文本，学会预测「人类会怎么写下一个词」。这让模型获得了广泛的知识和流畅的表达能力，但也有明显的局限：模型学会的是「文本看起来应该是什么样」，而不是「什么行动能解决问题」预训练数据中很少有「调用工具 → 观察结果 → 调整策略」这样的交互序列模型可能会生成看起来合理但实际无效的操作步骤简单来说，预训练教会了模型「说」，但没有教会它「做」。强化学习的核心思想强化学习用一个简单的循环来解决这个问题： 尝试 → 反馈 → 调整。想象教一个小朋友下棋：你不会给他看一百万盘棋谱让他背（这是预训练的方式），而是让他实际下棋，赢了就表扬，输了就复盘。通过无数次的尝试和反馈，他逐渐学会什么是好棋、什么是坏棋。对 LLM 来说，强化学习的过程类似：尝试： 让模型在真实或模拟的环境中执行任务（比如调用工具、编辑文件）反馈： 根据结果给出奖励信号（任务完成了？代码能运行？测试通过了？)调整： 更新模型参数，让它更倾向于选择能获得高奖励的行动这个过程会重复成千上万次，模型逐渐学会：在什么情况下应该调用什么工具、如何解读工具返回的结果、什么时候应该继续尝试、什么时候应该换个方向。为什么 RL 对 Agentic 能力至关重要传统的 LLM 微调（比如监督学习）需要人类标注「正确答案」。但 Agent 任务的特点是：路径多样： 完成同一个编程任务可能有无数种合理的步骤组合结果导向： 我们真正关心的是最终结果，而不是中间每一步是否「标准」需要探索： 有时候必须尝试几种方法才能找到可行的路径RL 天然适合这种场景。它不要求你定义「正确的步骤序列」，只需要定义「什么算成功」。模型通过自己的探索，学会找到通往成功的路径。实际训练中的应用现代 Coding Agent 背后的模型通常会经历这样的 RL 训练：在模拟的编程环境中执行任务（创建文件、运行代码、修复 bug）用测试通过率、代码质量评分等作为奖励信号学习何时应该读取更多文件来获取上下文，何时应该直接动手修改学习如何从错误信息中提取有用线索，调整下一步策略值得注意的是，RL 训练的效果高度依赖奖励信号的设计。如果只奖励「任务完成」，模型可能学会走捷径（Reward Hacking）；如果奖励信号太复杂，训练可能不稳定。 这也是为什么不同模型在 Agent 任务上的表现差异很大，背后的 RL 训练策略可能完全不同。对使用者的启示理解了 RL 的作用，你会更清楚为什么某些使用方式更有效：提供清晰的成功标准： 当你告诉 Agent 「修好这个 bug，运行 npm test 应该全部通过」，你实际上是在给它一个明确的「奖励信号」，这与它训练时的模式一致允许试错： Agent 在训练中学会了通过尝试来解决问题，给它多次尝试的机会往往比期待一次成功更实际观察它的决策模式： 当 Agent 做出某个决定（比如先读文件而不是直接修改），这往往反映了它在 RL 训练中学到的策略Coding Agent 的实现原理理解了 LLM 的本质和限制后，我们来看 Coding Agent 是如何在这些约束下被设计出来的。LLM API 的核心结构现代 LLM API 采用基于消息的对话结构。理解这个结构是构建 Agent 的基础。Messages 数组API 的核心是一个消息数组，每条消息包含角色（role）和内容（content）：{ "messages": [ { "role": "system", "content": "你是一个专业的编程助手..." }, { "role": "user", "content": "帮我写一个快速排序函数" }, { "role": "assistant", "content": "好的，这是一个 Python 实现的快速排序..." } ] } 三种角色各有用途：system： 设定 Agent 的行为准则、能力范围和工具定义user： 用户的输入assistant： 模型的回复Tool Calling 机制Coding Agent 的核心能力来自工具调用。API 允许你定义工具的 schema，模型会在需要时生成结构化的工具调用请求：{ "tools": [ { "name": "read_file", "description": "读取指定路径的文件内容", "parameters": { "type": "object", "properties": { "path": { "type": "string", "description": "文件路径" } }, "required": ["path"] } } ] } 当模型决定调用工具时，它的响应会包含工具调用信息：{ "role": "assistant", "content": null, "tool_calls": [ { "id": "call_abc123", "name": "read_file", "arguments": "{\"path\": \"src/main.py\"}" } ] } 工具执行结果作为新消息返回给模型：{ "role": "tool", "tool_call_id": "call_abc123", "content": "def main():\n print('Hello, World!')\n..." } Reasoning Content 的保留对于具有显式推理能力的模型，API 响应中可能包含 reasoning 或 thinking 字段，记录模型的思考过程：{ "role": "assistant", "reasoning_content": "用户需要读取文件来理解项目结构。我应该先查看 src 目录下的主要文件...", "content": "让我先看一下项目的主文件。", "tool_calls": [...] } 在多轮对话中保留这些推理内容，可以帮助模型维持思维的连贯性。模型可以「回顾」自己之前的思考过程，从而做出更一致的决策。Prompt Caching：工程实践的关键由于 LLM 的自回归特性，每次请求都需要重新处理整个上下文。对于动辄几万 token 的 Coding Agent 对话来说，这意味着大量的重复计算和延迟。Prompt Caching 通过缓存上下文前缀的计算结果来解决这个问题。关键在于： 缓存基于前缀匹配 。只有当新请求的开头部分与之前的请求完全一致时，才能命中缓存。这直接影响了 prompt 的组织方式：┌─────────────────────────────┐ │ System Prompt │ ← 稳定不变，可缓存 │ (角色定义、行为准则) │ ├─────────────────────────────┤ │ Tool Definitions │ ← 稳定不变，可缓存 │ (工具的 schema 定义) │ ├─────────────────────────────┤ │ Project Context │ ← 相对稳定，尽量少变 │ (项目说明、代码规范) │ ├─────────────────────────────┤ │ Conversation History │ ← 动态增长 │ (对话历史) │ ├─────────────────────────────┤ │ Current User Message │ ← 每次都变 │ (当前用户输入) │ └─────────────────────────────┘ 最佳实践参考：把稳定内容放在前面： system prompt 和工具定义应该保持稳定，避免频繁修改动态内容放在后面： 对话历史和当前输入放在最后避免在稳定前缀中插入可变内容： 比如不要在 system prompt 中插入当前时间戳Agent Loop：核心循环语言模型可以回答问题，而 Agent 可以 做事情 。Agent Loop 正是实现这一差异的关键。当模型收到一个无法仅凭训练知识完成的请求时，它需要与外部世界交互：读取文件、查询数据库、执行代码。Agent Loop 就是管理这个「推理 - 行动」循环的编排层，使模型能够处理需要多个步骤、外部信息或产生实际影响的任务。循环的基本原理Agent Loop 的运作遵循一个简单的原则：调用模型 → 检查是否需要使用工具 → 如果需要则执行工具 → 将结果返回给模型再次调用 → 重复直到模型产生最终响应。这个循环的关键在于 上下文的累积 。每次迭代都会向对话历史中添加新内容。模型不仅能看到原始请求，还能看到它调用过的每个工具以及收到的每个结果。这种累积的上下文使得复杂的多步骤推理成为可能。一个具体的例子假设用户请求：「帮我修复项目中的这个 bug：用户登录后会话没有正确保存」。这不是模型仅凭知识就能完成的任务，它需要通过 Agent Loop 逐步探索：第一轮： 模型收到请求，首先需要了解项目结构。它调用 list_directory 工具查看项目根目录。第二轮： 模型看到了目录结构，识别出 src/auth/ 目录可能与登录相关。它调用 read_file 查看 src/auth/login.js 。第三轮： 模型看到了登录代码，发现它调用了 sessionManager.save() 。为了追踪问题，它调用 read_file 查看 src/session/manager.j s。第四轮： 模型发现了问题， save() 方法中有一个异步操作没有被正确 await 。它调用 edit_file 工具修复这个 bug。第五轮： 修复完成，模型调用 shell 工具运行测试来验证修复是否有效。第六轮： 测试通过。模型不再请求工具，而是生成最终响应：总结问题原因、修复内容和验证结果。每一轮都遵循相同的模式：模型接收上下文，决定是继续行动还是给出响应，要么继续循环，要么退出。关键在于，模型基于对任务不断演进的理解 自主做出这些决策。循环的终止条件每次模型调用都会返回一个停止原因（stop reason），决定接下来发生什么：end_turn： 模型完成了响应，没有进一步的行动需要执行。这是正常的成功终止，循环退出并返回最终消息。tool_use： 模型想要执行一个或多个工具后再继续。循环执行请求的工具，将结果追加到对话历史，然后再次调用模型。max_tokens： 模型的响应因达到 token 限制而被截断。这在当前循环中无法恢复，循环以错误终止。理解这些终止条件有助于预测 Agent 的行为并处理边界情况。Coding Agent 的典型工具一个功能完整的 Coding Agent 通常需要以下几类工具：文件操作read_file ：读取文件内容write_file ：创建或覆盖文件edit_file ：对文件进行局部编辑（而非完全重写）代码执行shell / terminal ：执行命令行命令，用于运行代码、安装依赖、执行测试等代码搜索grep / search ：在代码库中搜索文本或模式semantic_search ：基于语义的代码搜索项目导航list_directory ：列出目录内容find_files ：根据模式查找文件这些工具的设计直接影响 Agent 的能力边界，工具的粒度、参数设计、返回格式都需要仔细考量。常见问题与解决方案在了解了 LLM 和 Coding Agent 的基本原理后，我们再来看看一些常见的问题就能更好地理解了。会话间失忆Coding Agent 面临的一个根本性问题是： 它们在会话之间没有持久记忆。每次启动新会话时，Agent 只知道它能在磁盘上找到的内容。就像电影《记忆碎片》或《初恋 50 次》中的主角一样，Agent 每天醒来都不记得昨天发生了什么。而典型的工程工作流往往需要跨越多个会话才能完成一个功能 —— 因为需要测试、代码审查和后续清理。这导致了一个荒谬的局面：你需要在每个新会话开始时，重新向 Agent 解释项目背景、当前进度和接下来的计划。解决方案：使用结构化的任务追踪系统（如 issue tracker）在每个会话结束时，让 Agent 生成一个状态摘要，供下次会话使用将重要决策和发现记录在固定位置，而不是对话历史中上下文窗口耗尽每轮循环都会向对话历史添加消息。对于需要多次工具调用的复杂任务，历史记录可能超出模型的上下文窗口。当这种情况发生时，Agent 无法继续。具体表现包括：模型提供商返回输入长度错误，或随着上下文填满不太相关的早期消息，模型性能明显下降。目前有两种主流的上下文管理策略：Observation Masking（观察遮蔽）这种方法只针对工具返回的观察结果进行处理，而完整保留 Agent 的推理和行动历史。具体做法是：用占位符替换较早轮次的观察内容（比如 「内容已省略」），只保留最近 N 轮的完整输出。这种方法简单高效，因为典型 Coding Agent 的每轮交互中，工具输出（如文件内容、命令执行结果）往往占据了绝大部分 token。通过遮蔽旧的观察内容，Agent 仍然可以访问自己过去的推理和决策，但不再重复处理早期轮次的冗长文本。LLM Summarization（LLM 摘要）这种方法使用另一个 LLM 将较早的交互历史（包括观察、行动和推理）压缩成简短的摘要。摘要会替代原始的详细历史，而最近的几轮对话保持完整。这种方法理论上可以支持无限长的对话，因为历史会被反复压缩。但它也有代价：每次生成摘要都需要额外的 API 调用，而且摘要可能会丢失某些细节信息。研究发现，摘要有时会掩盖 Agent 应该停止尝试的信号，导致 Agent 运行更多轮次，反而增加了成本。两种方法各有优劣：Observation Masking 实现简单、成本低，但上下文仍会缓慢增长；LLM Summarization 可以更彻底地压缩历史，但引入了额外开销和信息损失风险。实践中，可以考虑混合使用，以 Observation Masking 作为主要策略，仅在上下文确实过长时触发 LLM Summarization。其他解决方案：减少工具输出的冗长程度，返回摘要或相关片段，而非完整数据简化工具 schema，深度嵌套的结构会在工具配置和模型推理中消耗大量 token将大型任务分解为子任务，每个子任务使用新的上下文有效上下文远小于标称值即使拥有 1M token 的上下文窗口，Coding Agent 实际上只能有效利用其中的 10-15%。 超过 20% 后，成本和性能都会急剧恶化。大多数 Agent 会在达到约 20% 时强制中断，而最佳实践是在 15% 之前就重启会话。这意味着，以全速工作时，你大约只有 5-10 分钟的有效工作时间，然后 Agent 就会「耗尽上下文」，需要重启（相当于死亡）或进行 compaction（相当于记忆清除）。有一个生动的比喻：上下文窗口就像潜水员的氧气罐。所有人都说「我们给他一个更大的氧气罐：100 万 token！」但他最终还是会耗尽氧气，更大的窗口并不能解决根本问题。「Dumb Zone」：中间区域的性能退化研究发现，上下文窗口的中间 40-60% 区域存在一个「Dumb Zone」，在这个区域，模型的召回率下降，推理能力变差。这与前面提到的「Lost in the Middle」现象相呼应。当 Agent 深入工作时，它会逐渐表现出类似「痴呆」的症状：迷失方向、产生幻觉接口、忘记原始目标。这不是因为模型变笨了，而是因为关键信息被淹没在大量的上下文中，无法被有效利用。新发现的任务被丢弃这是 Agentic Coding 中一个容易被忽视但影响巨大的问题： LLM 在工作过程中会注意到各种问题，但在上下文空间紧张时，会选择忽略这些发现，不采取任何行动。例如，Agent 在修复一个 bug 时，可能会注意到代码中的另一个潜在问题、一个需要重构的地方、或一个缺失的测试用例。但如果当前上下文已经很满，Agent 可能会「假装没看到」，继续专注于手头的任务。这些被发现但被丢弃的工作，就这样悄悄消失了。解决方案：使用外部工具让 Agent 随时记录发现的问题在任务结束时，要求 Agent 列出所有观察到但未处理的问题建立「发现即记录」的工作流程过早宣告完成当 Agent 经历多次 compaction 后，可能会出现一个荒谬的情况：它会自信地宣布「恭喜，任务完成了！让我们开始手动测试吧！」而实际上还有大量的阶段没有完成。解决方案：将整体计划保存在上下文之外的固定位置定期让 Agent 对照原始计划检查进度使用结构化的任务追踪，而不是依赖 Agent 的记忆工具选择不当当模型持续选择错误的工具时，问题通常出在工具描述的模糊性上。从模型的角度审视描述：如果两个工具的描述有重叠，模型就没有选择的依据，我们应该确保每个工具的用途清晰且互不重叠。通过上述的探讨，我们已经完成了从 LLM 本质到 Agentic Coding 原理的理论铺垫：从逐个预测 token 的底层逻辑，到注意力机制的上下文约束，再到强化学习如何让模型学会「做事」；从 API 结构的基础框架，到 Agent Loop 的核心循环，最后到解决上下文耗尽、会话失忆等工程问题的实践策略。这些内容共同构成了 Agentic Coding 的第一性原理基石 —— 理解这些，你就能跳出 "黑盒工具" 的使用层面，看到各种最佳实践背后的深层逻辑。接下来，我们将从理论走向实操：结合具体案例拆解如何设计高效的 Agent 对话流程、如何选择合适的工具集、如何优化上下文管理策略，以及如何将这些原理应用到实际的编码任务中（如 bug 修复、功能开发、代码重构）。你将看到，当我们用第一性原理的视角重新审视 Agentic Coding 时，那些看似零散的技巧会形成一套系统的方法论，帮助你真正成为 AI 编程助手的「驾驭者」而非「使用者」。了解了 LLM 的特性、Coding Agent 的实现原理以及常见问题后，我们总结出了一些最佳实践，帮助大家更高效地使用这些工具。短对话优于长对话这可能是最重要的一条实践： 保持对话简短、专注，每个对话只做一件事。很多人认为更大的上下文窗口意味着更强的能力，可以把更多任务塞进一个对话里。但实际情况恰恰相反，最好的对话是短对话，它们只做一件事，并且只包含完成这件事所需的上下文。为什么短对话更好？当你往上下文里塞太多内容时，Agent 的表现就像喝醉了一样：它会开始犯错、跌跌撞撞、甚至开始和你争论，如果你继续喂它更多 token，它甚至会「吐」得你一身（产生大量无意义的输出）或者进入死循环。对话越长，上下文窗口里就会积累越多与当前任务不太相关的内容。为了让 Agent 发挥最佳工况，你需要给它完成当前工作所需的上下文。长对话不仅效果差，还更贵。每次发送消息时，整个上下文都会被发送给模型提供商。这意味着对话越长，新消息的成本就会指数级增长。而且长对话更容易因为消息间隔时间长而错过缓存窗口，导致费用飙升。所以，长对话既效果差，又花费高，尤其在以 tokens 消耗计费的套餐下面。拆分对话，本质上是拆分任务，大任务应该被分解为小任务。这在 Agent 时代之前就是软件工程的最佳实践，现在看也依然如此，短对话让任务拆分这件事变得自然甚至有趣。就像小任务更容易管理一样，小对话也更容易追踪：每个对话都有明确的目标，你可以轻松掌握整体进度。以对话为单位组织工作如果把对话视为任务的基本单位，那么一个功能或 bug 修复就自然变成了一组相互关联的对话。一个典型的工作流程假设你要实现一个新功能，可以这样组织对话：功能：用户登录后的会话管理 [对话 1] 调研现有代码结构 ├── 了解 auth 模块的实现 ├── 查看 session 管理的现状 └── 输出：关键文件列表和当前架构理解 [对话 2] 实现基础功能 ├── 参考对话 1 的发现 ├── 实现核心的 session 保存逻辑 └── 输出：基础实现代码 [对话 3] 添加错误处理 ├── 参考对话 2 的实现 └── 增加边界情况处理 [对话 4] 编写测试 ├── 参考对话 2、3 的实现 └── 添加单元测试和集成测试 [对话 5] 代码审查 ├── 检查实现是否符合项目规范 └── 确认没有引入安全问题 [对话 6] 清理和重构 └── 根据审查结果进行调整 每个对话都很短，只专注于一件事。它们加在一起，完成了整个功能的开发。那对话之间如何共享上下文？当你开始一个新对话时，可以通过以下方式传递必要的上下文：引用之前对话的结论： 在新对话开头简要说明之前的发现或决策利用 Git 状态： 让 Agent 查看 git diff 或检查最近的提交使用项目文档： 将重要决策记录在 AGENTS.md 或类似文件中，Agent 每次都能读取直接提及相关 文件： 在新对话中 #mention 需要的文件关键是： 不要试图在一个对话里完成所有事情。 每当你发现当前任务已经完成，或者对话开始变得混乱，就应该开始一个新对话。编写有效的项目配置文件大多数 Coding Agent 都支持在项目根目录放置配置文件（比如 Rules 或者 Agent.md），这个文件会 自动注入到每一个对话 中 ，这意味着它是你影响 Agent 行为的杠杆支点，但这把双刃剑也很容易用错。理解 Agent 的无状态本质LLM 是无状态函数。它的权重在推理时是冻结的，不会随着使用而学习，Agent 对你代码库的全部了解，完全来自于你放进上下文窗口的 token，这有三个重要含义：每次新对话开始时，Agent 对你的代码库一无所知任何重要的项目信息都需要在每次会话中告诉它项目配置文件是实现这一点的首选方式因此，你应该把这个文件视为 每次会话的入职培训文档。配置文件应该包含什么一个好的项目配置文件应该回答三个问题：WHAT（是什么）： 技术栈、项目结构、各模块的职责。这在 monorepo 中尤其重要，应该告诉 Agent 有哪些应用、哪些共享模块、每个部分是做什么的WHY（为什么）： 项目的目的、设计决策的背景。为什么选择这个架构？为什么有些代码看起来不合理（比如历史债务）？HOW（怎么做）： 如何运行项目、如何测试、如何验证改动。用 bun 还是 npm？测试命令是什么？少即是多这是最容易犯的错误：试图把所有可能需要的信息都塞进配置文件。研究表明，前沿的思考模型大约能可靠地遵循 150-200 条指令，而 Coding Agent 的系统提示本身可能已经包含了约 50 条指令。这意味着你的配置文件应该 尽可能精简 ，理想情况下只包含那些对所有任务都普遍适用的内容。# 不好的做法：塞满各种可能用到的信息 ## 数据库 Schema 设计规范（500 行详细规范...） ## API 设计指南（300 行规范...） ## 代码风格指南（200 行规范...） # 好的做法：简洁 + 指向详细文档 ## 项目概述 这是一个 Next.js 电商平台，使用 PostgreSQL + Prisma。 ## 关键目录 - `apps/web`: 前端应用 - `apps/api`: 后端服务 - `packages/shared`: 共享类型和工具 ## 开发命令 - `bun dev`: 启动开发服务器 - `bun test`: 运行测试 - `bun typecheck`: 类型检查 ## 详细文档 根据任务需要，查阅以下文档： - 数据库设计：`docs/database-schema.md` - API 规范：`docs/api-guidelines.md` - 代码风格：`docs/code-style.md` 一个经验法则：配置文件应该控制在 300 行以内 ，越短越好。有些团队的配置文件甚至不到 60 行。渐进式披露与其在配置文件中塞满所有信息，不如使用 渐进式披露 策略：agent_docs/ ├── building_the_project.md ├── running_tests.md ├── code_conventions.md ├── service_architecture.md └── database_schema.md 在配置文件中列出这些文档并简要描述，让 Agent 根据当前任务决定读取哪些。这样，只有相关的信息才会进入上下文，避免不必要的干扰。偏好指针而非副本： 不要在文档中复制代码片段 —— 它们很快会过时。使用 file:line 引用指向代码的权威位置。不要让 Agent 做 Linter 的工作很多人喜欢在配置文件中写详细的代码风格指南， 这不是个好的实践。LLM 做格式检查既慢又昂贵，更重要的是，这些指南会增加指令数量，降低 Agent 对其他指令的遵循能力。更好的做法：使用真正的 linter 和 formatter（如 ESLint、Prettier、Biome）配置自动修复，让工具处理格式问题如果 Agent 产生了格式错误，让 linter 在后处理阶段修复它LLM 是上下文学习者。如果你的代码库遵循一致的风格，Agent 通常会自动模仿这种风格，不需要你明确告诉它。这是最高杠杆点，要认真对待一行糟糕的代码就是一行糟糕的代码，一个糟糕的技术方案可能产生很多行糟糕的代码，而配置文件中的一行糟糕的指令会影响 每一个会话、每一个任务、每一个产出。杠杆效应： 配置文件 → 影响每个会话的行为 ↓ 研究/规划阶段 → 影响实现计划的质量 ↓ 实现阶段 → 影响最终代码的质量 花时间仔细考虑配置文件的每一行，这是你能做的 ROI 最高的投资之一。200K Token 足够了当大家都在追求更大的上下文窗口时，一个反直觉的事实是：200K token 对于大多数任务来说已经绰绰有余了。关键不在于你有多大的上下文窗口，而在于你如何使用它。一个 200K 的窗口，如果你用短对话的方式工作，可以支持你完成非常复杂的功能。因为虽然每个对话只有几十 K 到上百 K 个 token，但你可以开启 10 个、20 个甚至更多对话，它们加起来的总量远超任何单一上下文窗口。而且，由于每个对话都是从相对干净的状态开始，Agent 的表现会一直保持在最佳水平，而不是随着上下文膨胀而逐渐退化。实践建议当对话超过 80K-100K token 时，考虑开始新对话完成一个独立的子任务后，开始新对话处理下一个任务如果 Agent 开始表现出「醉酒」症状（重复、遗忘、偏离目标），立即开始新对话把「开始新对话」视为正常工作流程的一部分，而不是「失败后的重试」Compounding Engineering：让系统自我改进传统的 AI 编程是关于短期收益的：你给 prompt，它写代码，然后发布，然后从头开始。Every.to 提出的 Compounding Engineering（复利工程） 则是关于构建具有记忆的系统：每个 PR 都在教育系统，每个 bug 都成为永久的教训，每次代码审查都在更新 Agent 的默认行为。普通 AI 工程让你今天更高效，Compounding Engineering 让你之后的每一天都更高效。核心理念：你不只是在解决问题，而是在教育系统当你使用 Coding Agent 时，问自己一个问题：我是在解决今天的问题，还是在教系统？每次修复 bug 时，如果不能防止同类问题再次发生，就只完成了一半每次代码审查如果不能提取出可复用的教训，就是浪费时间每次成功的工作流程如果不能被记录和复用，就会随着会话结束而消失如何实践 Compounding Engineering将经验沉淀到项目文档大多数 Coding Agent 都支持读取项目根目录下的特定文件，这是你指导系统的主要途径：# AGENTS.md ## 代码风格 - 使用 async/await 而非 Promise.then() - 错误处理必须包含具体的错误类型 - 变量命名遵循 PR #234 确立的模式 ## 已知陷阱 - session 模块的 save() 方法是异步的，必须 await - 不要在循环中调用 API，使用批量接口 ## 成功模式 - 新增 API 端点时，参考 PR #241 的错误处理方式 - 测试覆盖率要求参考 PR #219 的反馈 每次你发现一个重复出现的问题或一个有效的解决方案，就把它加入这个文件。Agent 在每次对话开始时都会读取它，自动应用这些经验。让 bug 修复产生长期价值当你修复一个 bug 时，不要只是改代码。问自己：这类问题能否通过添加 lint 规则来预防？是否应该在 Rules 或者 AGENTS.md 中记录这个陷阱？能否编写一个测试来防止回归？代码审查清单是否需要更新？一个真正的 bug 修复应该让同类问题再也不会发生。从代码审查中提取模式每次你在审查中指出问题或提出建议，可以考虑：这个反馈是否适用于未来的类似代码？是否应该成为项目的编码规范？Agent 能否在下次自动应用这个改进？如果答案是肯定的，就把它记录下来。让你的审查意见成为系统的永久知识，而不是一次性的对话。建立可复用的工作流程当你找到一个有效的工作模式时，把它进行沉淀：## 工作流程：添加新的 API endpoint 1. 先编写接口测试（参考 tests/api/example.test.ts） 2. 实现端点，遵循 src/api/users.ts 的模式 3. 添加错误处理，使用 AppError 类 4. 更新 API 文档 5. 运行完整测试套件验证 下次你或 Agent 需要做类似的任务时，可以直接说「按照添加新 API endpoint 的工作流程来做」，系统已经知道该怎么做了。复利效应Compounding Engineering 的魔力在于累积效应。第一周，你可能只是记录了几条编码规范。第一个月，你有了一套完整的项目知识库。三个月后，Agent 开始自动应用你从未明确告诉它的模式，因为它从之前的 PR、bug 修复和代码审查中学习了这些。想象一下：你打开一个 PR，发现 Agent 的评论是「根据 PR #234 的模式修改了变量命名，按照 PR #219 的反馈移除了过度测试，添加了与 PR #241 类似的错误处理」。它学会了你的品味，就像一个聪明的同事，而且还有记录可查。这就是复利，每次修复、每次审查、每次教训都在为未来投资。对人难的事，对 AI 也难有一个简单但常被忽视的事实： 如果一个任务对人类开发者来说很难，那么它对当前的 AI 来说大概率也很难。这听起来显而易见，但它的推论却很深远：所有那些能提升人类开发者体验的工作，对 AI 同样有价值。更好的文档、更清晰的架构、更快的反馈循环，这些「老生常谈」的工程实践，在 AI 时代不仅没有过时，反而变得更加重要。为什么 AI 面临和人类相似的挑战？回想一下 LLM 的工作原理：它通过阅读上下文来理解任务，然后生成响应。这个过程和人类开发者阅读代码、理解需求、编写解决方案的过程惊人地相似。当文档缺失或过时时，人类需要花大量时间阅读源码猜测意图。AI 也一样，它会在代码库中反复搜索，消耗大量上下文空间，最终可能还是理解错误。当架构混乱、模块边界不清时，人类很难知道该改哪里。AI 也会迷失，它可能改了错误的文件，或者遗漏了需要同步修改的地方。当测试运行缓慢时，人类倾向于跳过测试。AI 也面临同样的压力，长时间的等待会消耗对话的「耐心」和上下文空间。值得投资的开发者体验既然 AI 和人类面临相似的挑战，那么以下这些传统的「开发者体验」优化就具有了双重价值：更好的文档# 好的文档对 AI 的价值 ## 之前（无文档） Agent 需要： 1. 读取 5-10 个相关文件 2. 猜测模块的职责和边界 3. 推断 API 的使用方式 4. 可能还会猜错 消耗：大量上下文 + 高错误率 ## 之后（有文档） Agent 只需要： 1. 读取 README 或 API 文档 2. 直接了解正确的使用方式 消耗：少量上下文 + 高准确率 好的文档不仅帮助新人上手，也帮助 AI 快速建立正确的心智模型，比如：架构决策记录（ADR）： 解释「为什么这样设计」，避免 AI 做出违背设计意图的修改API 使用示例： 比纯粹的类型定义更有效已知陷阱和常见错误 ：直接告诉 AI 什么不该做更清晰的代码结构当你在纠结要不要花时间重构一个混乱的模块时，考虑一下：这个混乱不仅困扰你，也会困扰每一个试图理解它的 AI。清晰的命名： processUserData() 比 doStuff() 对 AI 的帮助和对人类一样大单一职责： 一个做一件事的函数，比一个做十件事的函数更容易被正确修改显式依赖： 依赖注入比全局变量更容易被 AI 理解和测试更快的反馈循环这可能是最容易被低估的一点。Agent Loop 的每一轮都需要等待工具执行完成，如果：测试套件需要 10 分钟才能跑完 → Agent 要么跳过测试，要么在等待中浪费大量上下文构建需要 5 分钟 → 每次小改动的验证成本都很高部署需要 30 分钟 → 几乎不可能让 AI 做端到端的验证相反，如果你有：秒级的单元测试 → Agent 可以频繁验证，快速迭代快速的增量构建 → 改动能立即得到反馈本地可运行的环境 → 不需要等待远程部署具体的改进建议为 AI 优化你的测试# 不好：运行所有测试需要 10 分钟 npm test # 好：可以只运行相关测试，几秒完成 npm test -- --grep "session" npm test -- src/auth/__tests__/ 确保 Agent 知道如何运行局部测试，而不是每次都跑完整套件。提供快速的健康检查# 创建一个快速验证脚本 # scripts/quick-check.sh #!/bin/bash echo "Type checking..." npm run typecheck echo "Linting changed files..." npm run lint -- --changed echo "Running related tests..." npm test -- --related 让 Agent 可以在几秒内验证基本的正确性。文档放在代码旁边src/ auth/ README.md # 这个模块是做什么的 login.ts login.test.ts session/ README.md # session 管理的设计决策 manager.ts 当 AI 浏览目录时，它能立即看到相关文档，而不需要去别的地方找。让错误信息更有帮助// 不好 throw new Error("Invalid input"); // 好 throw new Error( `Invalid session token: expected format 'sess_xxx', got '${token}'. ` + `See docs/auth.md for token format specification.` ); 好的错误信息帮助 AI（和人类）快速定位问题，而不是盲目搜索。反过来未必成立，有时需要专门为 AI 设计需要注意的是，反过来的推论并不总是成立：对人来说简单的事，对 AI 未必简单，例如：人类可以轻松地「看一眼」就理解一个 UI 的布局问题，但 AI 需要解析整个 DOM 结构人类可以凭直觉判断「这个改动风险很高」，但 AI 缺乏这种隐性知识人类可以在飞书里随口问一句就获得关键信息，但 AI 只能依赖文档化的知识更有趣的是，有时候你需要 专门为 AI 设计 工具和接口，即使这对人类来说可能不是最自然的方式。LLM 需要专门的信息架构用户体验领域有一个概念叫「信息架构（Information Architecture）」，它关注的是如何组织和呈现信息，以提供最佳的用户体验，好的信息架构你很少会注意到，但糟糕的信息架构会让你抓狂。当我们观察 Agent 使用现有命令行工具时的困惑和迷失，这强烈表明： 我们现有工具的信息架构对 LLM 来说是不够的。LLM 是在我们现有的 CLI 工具上训练的，所以它们知道如何使用这些工具。但这些工具是为人类设计的，它们的输出格式、错误信息、交互方式都假设用户是人类。我们需要为 Agent 增强这些工具，提供对 LLM 更有用的上下文，甚至调整输出格式以便 Agent 更好地消费。API 设计：在信息量和上下文消耗之间取得平衡当你为 Agent 设计工具接口（比如 MCP 工具）时，需要在两个目标之间取得平衡：提供足够的信息： 减少 Agent 需要的工具调用次数避免填满上下文： 不要返回过多无关信息一个好的实践是：提供便捷函数和底层函数两套 API，并通过工具描述引导 Agent 优先使用便捷函数。@jsonrpc def get_global_variable_at(address: str) -> dict: """ Get the value of a global variable at the specified address. Automatically identifies the type and returns the best string representation. This is the preferred method for reading global variables. """ # 智能的、高层的实现 ... @jsonrpc def data_read_byte(address: str) -> int: """ Read the 1 byte value at the specified address. Only use this function if `get_global_variable_at` failed. """ # 底层的、更通用的实现 ... 通过在 docstring 中明确指出「只有在 get_global_variable_at 失败时才使用这个函数」，你可以引导 Agent 优先使用更智能的 API，减少不必要的工具调用。为 AI 设计友好的命令行输出如果你观察 Agent 的工作方式，会发现它经常使用类似 head -n100 的方式来限制输出。这看起来是在节省 token，但实际上引入了新问题：Agent 不知道还剩多少行没看到，如果需要完整信息就必须重新运行命令，而重新构建项目是非常耗时的。一个更好的设计是：让工具主动告诉 Agent 还有多少内容被截断了，甚至缓存输出以便后续获取。另一个常见问题是 Agent 在错误的目录中执行命令，它会反复尝试，在不同目录之间跳来跳去，浪费大量 token。一个简单的 shell hook 可以帮助它快速定位：# 在 .zshrc 中添加 command_not_found_handler() { echo "zsh: command not found: '$1'" echo "zsh: current directory is $PWD" return 127 } 现在当命令失败时，Agent 能立即知道自己在哪个目录：$ npm run build zsh: command not found: 'npm' zsh: current directory is /Users/ryan zsh: Perhaps you meant to run: cd project_directory; npm run build 很多命令行工具都提供了 –json 或 –porcelain 选项，在给 Agent 使用的工具中优先使用这些格式 —— 人类喜欢格式化的输出，但 AI 更擅长解析结构化数据。用工程约束来「驯服」AgentAgent 有时会试图走捷径，绕过你设定的规则。与其在 prompt 中反复强调「不要跳过测试」，不如用工程手段来强制执行。借助 linters、formatters 和 git hooks让 Agent 频繁提交代码是个好习惯（在 Rules 或者 Agent.md 中告诉它），但它往往会忽视「确保构建不失败」和「修复失败的测试」这样的指令。一个 .git/hooks/pre-commit 脚本可以强制执行项目标准：#!/bin/bash # .git/hooks/pre-commit echo "Running type check..." npm run typecheck || exit 1 echo "Running linter..." npm run lint || exit 1 echo "Running tests..." npm test || exit 1 echo "All checks passed!" 这样，无论 Agent 多么想跳过验证，它都必须通过所有检查才能提交。拦截 Agent 的「偷懒」行为Agent 有时很「聪明」，当它发现测试一直失败时，可能会进入这样的循环：修改代码构建：通过运行测试：失败尝试修复测试修复失败说「这个测试之前就是失败的，我用 –no-verify 提交」然后它就绕过了所有检查！（RL 训练中的 Reword Hacking）解决方案是用一个 git 命令 wrapper 脚本拦截这种行为：$ git commit --no-verify ------------------------------------------------------------------ ❌ ERROR: Commit Rejected. ------------------------------------------------------------------ 🤖 GUIDANCE FOR THE AI AGENT: You have attempted to bypass the required pre-commit verification. All code must pass quality checks before it can be committed. DO NOT BYPASS THE CHECKS. YOU MUST FIX THE UNDERLYING ERRORS. The pre-commit hook is likely failing. Diagnose and fix the issues. After all commands complete successfully, attempt the commit again *without* the '--no-verify' flag. 这个技巧的本质是： 把对 Agent 的指导嵌入到工具的输出中 ，Agent 会读取命令执行的结果，所以错误信息本身就是最好的 prompt 注入点。每当 Agent 发明新的「偷懒」方式，你就需要堵上这个漏洞。但总体来说，工程约束比 prompt 指令更可靠。显式优于隐式// 对人友好，对 AI 可能困难（隐含状态） client.connect() client.authenticate(user, password) client.query("SELECT * FROM users") // 对 AI 更友好（显式、无状态） const result = await db.query({ connection: { host, port }, auth: { user, password }, sql: "SELECT * FROM users" }) 有状态的 API 需要 AI 理解和跟踪隐含的状态变化，而无状态的、显式的 API 更容易被正确使用。结构化的错误信息# 对人足够，对 AI 可能困惑 Error: Something went wrong. Please try again later. # 对 AI 更友好 Error [AUTH_TOKEN_EXPIRED]: Token expired at 2024-01-15T10:30:00Z. Call refreshToken() to obtain a new token. See: docs/auth.md#token-refresh 人类可以通过上下文推断「something went wrong」是什么意思，但 AI 需要明确的错误代码、原因和解决方案。AI 眼中的「合理」可能和人类不同这是一个更微妙的发现：AI 认为合理的代码结构和命名，可能和人类的直觉不一致。Amp 团队分享过一个有意思的案例：他们让 AI 构建了一个 TUI 框架，过程中开发者一开始会干预 AI 的决策。比如，AI 给一个交换屏幕缓冲区的函数命名为 present() ，开发者觉得这个名字不够直观，改成了 swapScreens() 。但随后他们发现了问题：Agent 在后续工作中反复尝试寻找一个叫 present() 的函数，找不到后报告「让我尝试其他方法」，最终才找到 swapScreens() 。这浪费了 token，也浪费了时间。为什么会这样？因为 Agent 的命名「直觉」来自训练数据的统计概率。 present() 是 Flutter 等框架中双缓冲交换的常见命名，对于 Agent 来说是「最可能」的名字。当开发者用自己的命名覆盖它时，实际上是在对抗 Agent 的统计直觉。Agent 不能再问「过去的我会怎么命名这个」并从权重中找到答案 —— 它必须记住人类的特殊习惯。后来，开发者决定放手让 Agent 自己决定命名和代码结构。结果呢？Agent 在这个代码库上的工作效率大幅提升。最终的代码可能看起来有些「奇怪」：比代码库其他地方更多的 OOP 模式和类开发者不会选择的命名约定不太常见的泛型用法文件布局和人类习惯不同但 Agent 在这个自己构建的框架中如鱼得水：它知道如何添加滚动条，知道动画系统如何工作，知道键盘快捷键的处理方式 —— 尽管这个框架没有任何文档，甚至无法完整放入一个上下文窗口。这是一个「由 Agent 构建、为 Agent 优化」的代码库。在这里，东西放在 Agent 的「直觉」认为它们应该在的地方，命名符合 Agent 的统计预期，语法和概念在「统计上最可能」和「实际能编译」之间取得平衡。启示与权衡这给我们的启示是：不要过度干预： 如果你频繁地因为「我觉得这个名字更好」而覆盖 Agent 的决策，可能反而在降低效率注意「找不到」的信号： 如果 Agent 反复在某个地方「找不到」东西，考虑是否是你的命名和它的预期不一致拥抱常见模式： 使用广泛使用的设计模式和命名约定，AI 的训练数据中更可能包含这些模块级的风格隔离： 在某些由 Agent 主导开发的模块中，可以考虑让 Agent 保持它自己的风格当然，这需要权衡。人类仍然需要阅读和维护代码，完全「AI 风格」的代码可能会让人类开发者困惑。一个务实的做法是：把「只存在于人脑中」的知识显式化：写下来，放进文档在 Agent 主导的模块中，给 Agent 更多自主权在人类频繁维护的核心模块中，保持人类友好的风格在工具接口上，提供 AI 友好的选项（如 –json 输出）投资回报是双倍的当你投资于更好的文档、更清晰的架构、更快的测试时，你获得的回报是双倍的：人类开发者（包括未来的你）会更高效AI 助手也会更高效这些投资不会因为 AI 的进步而贬值。相反，随着你越来越多地依赖 AI 来完成任务，这些基础设施的价值只会越来越高。所以，下次当你犹豫要不要花时间写文档、重构代码、优化测试速度时，记住：你不只是在帮助人类，你也在帮助 AI。而在这个 AI 辅助编程越来越普遍的时代，这是一笔非常划算的投资。刻意练习：像学乐器一样学习 AI为什么有些人说「AI 对我不起作用」，而另一些人却能用 AI 完成大量的工作？这个问题需要区分来看，如果你只在公司的大型私有代码库中使用过 AI，你的体验可能确实不好，那些代码库可能有古老的架构和专有模式，AI 的训练数据中根本没有这些，这是完全可以理解的。但问题是： 你有没有在个人项目中尝试过 AI？你有没有进行刻意的、有意识的练习？AI 就像一件乐器以吉他为例，每个人都知道吉他是什么，也都知道如果投入刻意练习，就能变得擅长，但这需要时间、努力和实验。AI 工具也是一样。那些从 AI 中获益最多的人，都投入了刻意练习。他们不会因为一次失败就下结论说「它给了我完全错误的答案」，然后假设这将是他们的常态体验。他们会 玩 / Hack 。AI 工具也有这种潜力，它们的「正确用法」还在被发现中，那些愿意实验、愿意失败、愿意从失败中学习的人，会找到别人看不到的可能性。如何进行刻意练习创造一个干净的实验环境不要只在工作的复杂代码库中评估 AI 的能力，启动一个个人项目，一个没有历史包袱的新项目。在这里，AI 可以展示它真正的能力，你也可以专注于学习如何与它协作。从失败中提取教训当 AI 给出错误的结果时，不要只是说「它不行」然后放弃。问自己：我的 prompt 是否足够清晰？我是否提供了足够的上下文？我是否在一个对话里塞了太多任务？这个错误是否揭示了 AI 的某个系统性弱点？每次失败都是一次学习机会。把它记录下来，下次避免同样的陷阱。观察和模仿高手的实践关注那些公开分享 AI 工作流程的开发者，观看他们的演示，阅读他们的文章，尝试复制他们的技巧。很多时候，差距不在于 AI 工具本身，而在于如何使用它。建立肌肉记忆就像弹吉他需要建立手指的肌肉记忆一样，高效使用 AI 也需要建立某种「肌肉记忆」：什么时候应该开始新对话？如何组织一个复杂任务的 prompt？遇到某类问题时，哪种工具组合最有效？这些直觉只能通过大量练习获得。没有捷径。投入时间最关键的是：你需要投入真正的时间。不是偶尔试一试，而是持续地、有意识地练习。就像学习任何乐器一样，每天练习 30 分钟，坚持几个月，效果会远超每周练习一次几个小时。总结AI 正在以惊人的速度发展。本文讨论的许多「限制」和「问题」：上下文窗口的约束、会话间的失忆、中间区域的性能退化等等，这些很可能在未来几年内被大幅改善甚至解决。每隔几个月，我们就会看到新的突破：更长的有效上下文、更好的长程推理、更可靠的工具使用。但这并不意味着我们应该等待这一天的到来。恰恰相反， 正是这个充满限制的阶段，给了我们工程师极大的探索和成长空间。 那些现在就开始深入理解 LLM 工作原理、积极实践最佳方法、在限制中寻找创造性解决方案的人，将在 AI 能力进一步释放时获得最大的杠杆效应。这是一个转型的窗口期。通过刻意练习，我们不仅能提升当下的生产力，更重要的是在构建自己的核心竞争力 —— 理解这些工具的本质，知道何时信任它们、何时质疑它们，以及如何让它们发挥最大价值。从第一性原理理解 LLM 的本质，理解它们如何「思考」、如何受到上下文的限制、如何在 Agent Loop 中发挥作用，这些知识不会随着具体工具的迭代而过时。无论你使用的是哪个 Coding Agent，无论模型如何更新换代，这些基础原理都将帮助你更好地与 AI 协作。短对话优于长对话、刻意管理上下文、将经验沉淀为可复用的知识、为 AI 友好的工作环境投资，这些实践同样具有持久的价值。AI 编程的未来会是什么样子，没有人能确切知道。但有一点是确定的：那些现在就开始认真学习、积极实践、深入理解的人，将最有能力塑造和适应这个未来。去实验，去失败，去学习。像学习乐器一样学习 AI。这个过程本身，就是价值所在。📌 转载信息来源： https://linux.do/t/topic/1443237转载时间： 2026/1/14 10:48:25