从第一个我体感“有点不一样”的 Code Agent —— Claude Opus 4.5 发布（2025年11月24日）以来，竟然才过去半年。但在这半年里，基本所有能被程序化、自动化的工作，都受到了前所未有的冲击。我们这个以代码为生的群体更是被当头棒喝，周围即使最保守的程序员，也在“卧槽”声中做了调整和转向。
现在深处漩涡中，去预测 AI 带来的社会层面变化，是我万万力所不及的。本篇只想稍稍记录下最近将 Agent 嵌入工作流的一些体验，以待将来回忆起有所凭借，零零碎碎，林林总总。主要从工作模式变迁，如何管理 Agent 和上下文，如何创建和管理 Skill 等方向聊一些一个大模型人的一线体感和经验。
同步到异步
作者：木鸟杂记 https://www.qtmuniao.com/2026/06/16/vibe-coding/ 转载请注明出处
古法编程时代，将代码从脑中有节律的赶到 IDE 中是一件很容易“心流”的事情，有一种“纯手打”现榨果汁的美感。而这种设计——输入——测试——迭代的小碎步循环，基本都是同步执行的。
但在 Code Agent 强大之后，我们基本只需要粗略（此处通常有坑）的描述设计，开启 yolo 模式，Agent 就能吭哧吭哧实现个七七八八。如果 Agent TPS （token per second）足够高、我们任务足够简单，这个过程倒也可以是同步的。但目前（2026 上半年）来说，一个稍大任务布置给 Agent，通常要花几分钟到几十分钟不等，这就意味着我们很难同步地等着模型的输出，再去迭代。
由此，一般都会同时会开几个 Agent，并行做几个小任务。然后像“打地鼠”一般，循环响应执行就绪的 Agent。但，这种频繁地、零碎地切换人脑上下文，体验并不美妙。
解法有很多。
最直接地，我们可以将时间片强行拉到小时级，不再过于频繁（分钟级）地切换。在单个小时内，我们只专注于一两件事情。当然这是降低效率的，但我们的注意力资源也是要保护的。为了避免落下任务，我甚至每天用纸质小本本记下几个大的 TODO，每到时间片切换“触发边沿”，就眼动轮询下。
再比如，将其中一个 Agent 提升为 Manager（包工头），帮我们来管理其他 Worker Agent。我们平时只需要盯着包工头就行。然后不断积累实践“判例”，将一些常见、无歧义决策方法，写到其 AGENT.md 中，进一步降低我们的决策成本。类似于大脑习得一些惯常后，就下放给基底神经节去执行一样**。**
决策层级上移
如果说公司是创始人的组织杠杆，那 Agent 就是我们干活的杠杆。杠杆的存在，都是为了保护我们有限的决策带宽；但杠杆大了，也意味着决策层级的提高。这可能会让我们一线程序员被动进入某种类 Manager 的角色。
当然不同之处在于，相比人的千面性，Agent 呈现出一种古典的“淳朴”——它多半不会骗你。但在你交代任务的（有意或者无意的）留白之处，总会进行奇怪地非线性“插值”，即在代码库现状和你给他的目标之间，沿着很多奇怪的路径“搜”过去，在耗了惊人的 Token 之后，给出了某些似是而非的实现。
而通常，在你决策层级过高只进行黑盒观测的时候，这种“雷”会延迟很久才起爆。
这似乎是脱离一线，决策层级提高后的必然后果，千百年来中国王朝周期律，大体有这种现象的影子。对于创业之君来说，起于微末，知道如何有效衡量不同层级的人的产出。而对于守成之君来说，养于深宫之中，乏于一线体感，做出的决策多少难以验证或者进行有效迭代。于是满朝文武会倾向不断自我繁殖，直到“石人一只眼”。
Vibe Coding 大类如此。如果我们对一个领域不同层级的细节有足够多的理解，就可以有效地，通过更多的先验引导 Agent 的搜索方向、通过更精确的语言限制 Agent 的实现路径。但如果，我们对某个领域底层实现缺乏了解，但又想要足够复杂的功能，不断鞭策 Agent 进行“撒丫”式的复杂度的堆叠，那代码仓库爆掉的速度，也会和隋元覆灭一样倏忽。
但也需要考虑代码本身的生命周期。我在**影响我写代码的三个 “Code”**中也聊过，如果你的代码本来生命周期也很短，比如跑一两次的脚本、比如一次性展示的网页，那正是可以 yolo 使用 Agent 大放异彩的场景。
上下文管理
用 Agent 越多，越发现我们不断提效（scale 自己）的过程，就是不断精细化管理上下文的过程。
对于编程这个场景来说，最朴素想法是——将所有的上下文维护在仓库（repo）之内。简单说，仓库即上下文。具体点，让 Agent 实现以下几个文档：
所以，对于大项目来说，只要编程语言这个中间媒介还在，那么传统以降低复杂度为核心目的软件工程的一些原则，就仍然有效。这仍然是你和其他人、你和将来的你、你和 Agent 进行有效合作的唯一手段—— Agent 的上下文窗口有限，你的心智带宽也有限。
因此，“移步换景”式的维持一个实时的、精简的上下文，就永远是一个行之有效的基本目标。古法编程时代，一些通用的抽象隐喻、一些合理的层级组织也可以沿用。
Vibe 工具的选用
我观察身边人驱动 Agent 进行编程、干活，有两种常见的形式：
💡 可以看出这两种都是基于文本的（text-based），这也是这一波 AI 浪潮的“本尊”——LLM，大语言模型的所决定的。其本质上是一个语言模型，因此对文本的理解和推理都是原生的（native），但对图像的理解却是通过 ViT 等方式嫁接的。因此，LLM 对图片的理解很像“盲人骑瞎马”，且不论基于图像进行原生推理的能力很有限，像素级点击按钮进行定位、精确数画面中细小对象的数量，这种图原生操作的基本能力，就一直难以稳定解决。
所谓 terminal-like，即 Code Agent 最原始的形式，比如 Claude Code 。刚开始是服务于程序员写代码的，可以使用 TUI 进行稍微复杂的结果呈现：比如中间的思考过程、比如命令行工具的调用、比如工具结果的合理展示，都让习惯了命令行干活的我们，感到相当丝滑。但短板在于：很难临时想用手机下个指令、也难以让不同 Agent 进行交互（比如让 Manager Agent 收集 Worker Agent 的反馈，指挥 Coder Agent 迭代工具）。
所谓 chat-like，则是之前火过一阵的 OpenClaw 的方式，通过各式样的聊天工具，打通我们和云端 Agent 的交互通道。让我们可以随时通过聊天软件以消息的形式跟 Agent 交代任务。但缺点也是切实的，在聊天软件中很难像在 vscode 那样进行代码审查，在需要时也很难像在终端中那样盯着 Agent 到底怎么干的活。即，由于聊天这种形式表达能力的限制，我们很难对 Agent 干活轨迹进行更精确的管控。
于是，有人利用 tmux 自带的通信协议，造了 web tmux 类似物来进行端侧（比如手机）的人- Agent 交互、进行 Agent-Agent 间的命令交互，以同时获得终端的表达能力和随时在线的通信能力。但终究不太 AI 原生。于是，又有创业团队，使用 html-based 或者 UI-based，围绕 chat ，在多端通信的情况下，增加更丰富的呈现能力，比如 paseo 。
至于未来会如何发展，我们且行且看。
skill 创建和迭代
从刚开始的 mcp 到现在的 skill，如何给 Agent 提供合适的弹药，让它解决我们各自领域内的问题，也是一个有相当多实践的议题。
我们先从 skill 的生命周期来聊聊：
在创建的 Skill 的时候，一开始时，我们会倾向纯用自然语言来描述。但用着就会发现其在多次执行时的执行过程的漂移。这时，我们很自然的想将确定的过程通过附加脚本来固定、将模糊的过程通过给例子来引导。用脚本时，我们又可以在 setup 阶段写明如何固定环境、如何使用相对路径来保证不同环境执行的稳定性。
迭代 Skill 也很有意思。因为创建 Skill 的成本足够低，我们重用 Skill 的时候，如果改动很多，完全可以不维护进行重做；我们在将 Skill 分享给别人的时候，对方也完全可以不做兼容，完全复用框架但重做执行路径（Copy-then-Write）。所以维护还是新造，也没有个定则，需要根据不同场景进行不同取舍。
另外，我将和 Agent 的协作，以 Skill 为界，大体分为两个“结界”——写代码和干活。和 Agent 协同进行写代码造工具（命令行和 Skill），然后驱动 Agent 利用前述工具进行干活。在不同模型 “token 纯度”不同的眼下，正好可以利用这个分野，造工具可以利用强一些、贵一些的模型；用工具可以用弱一些但便宜些的模型。
在用 Skill 干活时一个很重要的功能就是定时任务，在线各家 Agent 也都越来越原生支持了。
以上，是最近和 Agent 协同干活的一些想法。由于基础模型能力还在快速提升，很多实践注定是——学的慢就可以不用学了。但在大变革、大浪潮时代下记录下的一些一线的体感，待到尘埃落定时回头来看，或许可以建立一点自己从状态到决策的预测链路样本库，也是一个很有意思的事情。
关于 Agent，大家都有什么有意思的想法，欢迎分享。
题图故事
将之前拍的北京的一些地标性建筑，让 AI 用插画风格统一生成了下，做了个集锦
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
