大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



这条视频最扎人的地方，在于它说出了很多做 Agent 的人心里都知道、但不太愿意正面承认的一件事：

你明明看了很多教程，学了很多新概念，甚至把最近一年的流行词都背熟了，最后做出来的 Agent 还是慢、笨、不稳定。跑 demo 时看着还行，一进真实任务就开始变形，越做越别扭。

这类挫败感，过去常常会被归因成“是不是我还没学会某个新框架”“是不是我还缺一个更先进的架构”。可这条视频真正有价值的地方，是它把视线从“继续找新工具”拉回到了“系统到底哪里出问题”。

很多人做不对 Agent，不是因为教程看得不够多，反而常常是因为看得太多了。信息越多，越容易把注意力放在那些最像答案的名词上：Context Engineering、Skill、Harness、Planner、Subagent、Orchestration Layer……结果系统越搭越复杂，真实瓶颈却没被对准。

这条视频里，作者先复盘了自己最早采用的一套经典架构：Plan-and-Execute。

听起来很合理：主 Agent 负责 orchestration，把任务拆分，再交给设计型 subagent、编码型 subagent 去执行。结构分明，职责清楚，很像我们熟悉的软件工程分层思路。第一次接触 Agent 系统的人，几乎天然会觉得这就是正路。

问题出在，一套在图纸上很好看的架构，未必在真实工作流里也好用。

作者后来发现，这套结构在 demo 层面很整洁，但一进入真实开发环境，问题立刻变得具体起来：

• 一个本来很小的改动，经过 planner、executor、上下文传递之后，成本被放大了
• 主 Agent 名义上只是编排者，实际上却很难忍住不下场干活
• 子代理之间的信息传递变成了额外负担
• 每多一层结构，就多一层同步成本和误差来源

这其实特别典型。很多人做 Agent 容易踩的第一个坑，就是把“架构上看起来专业”误认为“系统上真的更有效”。

Agent 系统跟传统后端系统有一点不太一样。它更像一个持续与模型注意力、上下文权重、生成惯性打交道的动态系统。你如果只按模块图去设计，很容易得到一套逻辑上无懈可击、实际用起来却很拧巴的东西。

视频里第一个很有启发的调整，是作者把原先 design / coding subagent 的系统提示，直接改造成了可动态注入的 Skill，不再每次都额外起子代理。

这步看上去像是在“引入新概念”，实际上它解决的是一个很朴素的问题：信息传递太绕了。

之前的结构里，主 Agent 先理解任务，再把部分上下文整理给子代理；子代理处理完，再把结果回传给主 Agent。每一轮都要重新压缩、转述、解释。看似规范，实际上每多一次转述，就多一次损耗。

改成 Skill 之后，很多中短任务反而更顺了。原因不神秘：

• 主 Agent 不用再把上下文转述给另一个执行体
• 之前已经建立好的任务背景能直接继承
• 少了一层“告诉别人该知道什么”的过程
• token 开销更低，来回沟通损耗更小

这件事给我的提醒很直接：很多看起来高级的多代理结构，真正承担的可能只是“转述工作”。如果一个能力完全可以通过 skill 注入，让主 Agent 在同一上下文里直接完成，那就没必要为了形式上的分工，把系统做得更重。

所以 Skill 的价值，并不在于它听起来多先进，而在于它帮你砍掉了一层原本没必要存在的传输链路。

视频没有停在“把 subagent 去掉以后更轻了”这个层面，这是它比很多教程更成熟的地方。

因为只要任务一拉长，你就会发现系统遇到的麻烦完全变了。

作者后面面对的是那种真正的长链路任务：要连续生成上百段代码、上百帧内容，或者持续执行很长的创作过程。这种场景下，问题早就不只是“消息转来转去很烦”，更直接的麻烦包括：

• 后面的步骤开始被合并、跳过
• 一开始定好的规则慢慢失效
• 输出越来越像前面已经生成过的东西
• 系统越跑越疲，越跑越同质化

很多人一到这里，就会立刻往系统里再塞一个记忆层、再挂一个待办列表、再补一个更复杂的 planner。结果只是让系统看上去更完整，实际却没有真正命中问题。

视频最重要的一层解释，是它把问题推回到了大语言模型的注意力机制上。

这条视频里我最认同的一点，就是作者对 To-Do List 的理解。

很多人会把待办列表理解成“给 Agent 一个记事本”，好像只要事情被写下来，系统就自然不会忘。实际不是这么回事。信息写进上下文，不代表它会持续被模型优先关注。

大语言模型不会平均看待所有上下文。最靠前的 system prompt 很重要，离当前输出最近的内容也很重要，中间那一大段历史信息，随着上下文变长，会越来越容易被淹没。

这意味着一个很现实的结论：

很多规则并非没有写进去，只是随着上下文拉长，它们慢慢掉出了模型最关注的位置。

所以 To-Do List 真正的意义，不只是记录任务，而是做持续的 restatement，也就是不断重申：

• 现在做到哪一步了
• 还有哪些没做
• 下一步到底是什么
• 当前阶段最该优先守住的规则是什么

这听起来像“必要的废话”，但对长任务来说，这种重复根本不是浪费，它本身就是一种控制手段。你是在不断把最重要的信息重新推回模型注意力最强的位置。

这也是为什么很多 Agent 看起来“好像全都记住了”，最后还是会跑偏。记忆系统不是把信息囤起来就结束了，关键是它有没有以正确的方式重新进入当前生成过程。

视频里另一个很实用的判断，是它把静态规则和动态信息区分开了。

静态规则，比如代码风格、输出格式、长期边界，这些可以放在 system prompt 里。因为它们稳定、长期、需要高优先级。

动态信息，比如当前 plan、to-do、阶段性 skill、这一步到底做到哪儿，这些东西不应该频繁改 system prompt，更适合持续追加在上下文尾部。

这个判断背后既有模型层面的理由，也有很强的工程理由。

一方面，尾部追加更容易重新进入注意力中心；另一方面，频繁改 system prompt 会让缓存利用变差，长任务成本上升，整个系统变得更笨重。很多 Agent 做到后面越来越慢，往往问题出在上下文管理被你自己做得过于折腾。

换句话说，系统设计的关键不只是“有没有这层结构”，还包括“这层信息以什么方式进入模型”。这类问题如果不想清楚，后面你换多少框架、套多少名词，效果都很有限。

这条视频特别好的地方，是它没有把某个结构神化成终局答案。

前面 Skill 看起来很好，后面作者却又把 subagent 加回来了。乍看像是在打自己脸，实际上恰恰说明他开始从“具体问题”出发，而不是从“概念立场”出发。

这一次重新引入 subagent，目的已经不再是为了维持 planner / executor 的教科书式分层，而是为了做上下文隔离。

这是个很关键的变化。

当任务进入创意性代码生成、长篇连续生成这类场景时，问题已经不只是“重要信息没被看到”，还有另一种麻烦：不该被继承的历史内容，被继承得太多了。

模型会天然模仿前面自己已经写过的内容。前文越长、模式越稳定，后面越容易被前面的表达惯性拖住。于是本来应该有变化、有新意的输出，会越来越像机械延长线。

这时候 subagent 的价值就出来了。它不再是“执行外包者”，更像一个干净窗口：

• 只拿到局部任务必需的上下文
• 主动屏蔽不该继承的历史产物
• 给局部生成保留独立思考空间

这个思路比“多代理听起来更先进”要扎实得多。它回答的是一个真实问题：当上下文本身开始污染生成质量时，你该怎么切断污染源。

看完这条视频，我觉得它实际上给出了一个很值得反复记住的排障框架。

很多人做不好 Agent，最后卡住的原因，常常不在“没学到最新概念”这件事，真正麻烦的是下面几件事一直没有想明白：

只要看到 planner、executor、orchestrator 这类词，就会下意识觉得系统更成熟。但很多时候，这只是把问题转移成更多层的信息传递。结构更复杂，不代表结果更稳。

Skill 适合解决通信冗余，To-Do List 适合解决注意力衰减，Subagent 适合解决上下文隔离。它们处理的是不同层的问题。你如果把一个工具拿去治所有病，系统当然会越来越乱。

很多 Agent 系统越做越重，就是因为每出现一个问题，就再补一层结构。久而久之，整个系统像叠满补丁的旧房子。真正有效的设计，很多时候靠的是删掉不必要的中间层，而不是继续堆。

今天流行 Context Engineering，明天流行 Skill，后天流行 Harness，再下一波可能又会冒出新的抽象。问题在于，你一旦先爱上概念，就很容易忘记最该问的问题：

• 它到底解决什么具体问题？
• 这个问题在我的系统里真的存在吗？
• 它带来的复杂度，值不值得？

没有这层追问，学再多教程也只是不断更新词汇表。

这条视频给我最大的共鸣，是它没有把做 Agent 描述成一条“不断学新组件就会越来越对”的路线。真实情况更像另一回事：你得反复观察系统怎么失稳、哪里变慢、哪里开始跑偏、哪里开始同质化，然后针对那个具体症状做小步实验。

这跟很多人刚入门时的期待差别很大。我们一开始总希望有一套标准答案：哪个架构最好、哪个框架最先进、哪个模式最对。可真正做下去以后会发现，所谓成熟，往往是你开始有能力辨认“这次的问题到底发生在什么层”，而不再执着于一套完美模板。

这比继续搜教程重要得多。

所以回到标题：为什么很多人学了很多 Agent 教程，最后还是做不对？

我觉得最接近真相的回答是：

他们学到的往往是概念层答案，却没有建立起系统层判断。看到的是别人包装好的方法名，却没真正理解这些东西为什么会存在、各自解决什么问题、该在什么条件下使用。

教程当然有用，框架当然也重要，但它们都不该替代你对系统行为的阅读能力。做 Agent 这件事，最终拼的是谁能更快看出真实瓶颈，并愿意围着那个瓶颈做一轮又一轮克制的小实验，而不是谁知道更多新词。

这条视频的价值，也恰好在这里。它没有继续往外兜售一个新答案，而是提醒你别再把概念本身当答案。

原视频：https://youtu.be/eWFKPPgHMCw?si=4tKndYaeQV8c0Fse