团队 Vibe Coding 月报 - 2026年2月（兼谈 agent 应用设计的两个小套路）

继上月尝试 Clone NotebookLM 之后，本月尝试着将 TUI 和 Deep Agents结合做了一个自用的 cli agent，形式上类似一个玩具版的 claude code。其中值得一提的几个特点：

• 全面拥抱 Gemini，包括基础设施。
• terminal 下的图片（含 mermaid 图）预览。
• local sandbox（基于 HF smolagents python_interpreter 魔改）和 remote sandbox（基于 Gemini 的 code execution tool ）。
• 内置 rlm 实现，由内置的 python 解释器动态生成 sub llm 的调用，绕过 llm 的 context window 限制。
• 仿 opencode 的 token 和 cost 估算。

其他的，则稀疏平常：subagent 和 skill，使用 langchain 的 deepagents 构建完成。

从工程实践方面来讲，并无太多新的收获，无非是进一步的夯实上月形成的实践。

但从应用本身的架构方面，到有若干体会。

Agentic vs Workflow

对于这两个概念，说太多技术性的解释反而不容易让人理解。但换个角度从管理方面来讲，则要容易得多：

• agentic，让 agent 来决定，类似管理上的授权。
• workflow，则是工作的流程。

在编写 agent native 的应用时，需尽量避免过多的 workflow，尽可能的让 agent 来决定。因此，从开发上来讲，应尽可能给围绕业务设计不同的小工具，让 agent 自行组合完成任务。

worlflow 则应针对高层原则性问题设计，卡住关键节点即可。过多的微观 workflow 反而会让整个应用限于僵硬无法适应未来变化环境的境地。

“高层流程 + 微观工具”本质上是新时代的“高内聚 + 松耦合”，这种设计可以让你的应用从模型的升级中获得好处。相反，过于微观的 workflow 反而可能在模型升级之后对其造成伤害。

如果你将 ai 当作人来看待，想必能理解我的意思。

Skill 是新的插件系统

我一直认为 subagent 纯属画蛇添足，它不仅没有简化概念，反而增加了一层复杂性。因为凡是你需要 subagent 协作的地方，都可以通过多个 agent 协作完成。而且只用 agent 进行组合完全符合 unix 的最佳设计实践。

对于 skill，则完全符合“最小惊讶法则”，不仅自然而且跟我去年 8 月份写一篇文章里提的想法不谋而合（当然，没有 CC 自己那么标准化）：

建立 llms-skills 目录用于存放 ai 可参考的技能

并且在这次实验的过程中，最终的演变结果也是通过 skills 来扩充 agent 的能力。这样，你的 agent 的核心就成了：code executor + skill loader + CodeAgent。一旦形成这样的内核，通过不同的 skill 即可实现能力的扩充，因为它会自行编写代码解决问题。

在以上的自用项目中：

1. agent 本身就会写 python
2. rlm 就是一个 skill，内部包含了指令和相关的 python 函数

高层流程时，当需要分析的文件超过某个大小时，直接使用 rlm 完成任务。

印象最深的两个观点

虽然本月在 vibe coding 开发实践上没有形成新的玩法和收获，但是从两篇文章里看到了两个观点，印象深刻（注，链接忘了）：

• vibe coding 的难点不在于功能代码的生成，而在于“正确性的逼近”，而后者则是区分手艺高下的要点。
• 解决 coding agent 并行开发的方法就是给每个 agent 分配一个完全干净独立的 vm，这是不是有点给每个新员工配电脑的感觉了，😄。