– by Javier Allegue Barros in Unsplash
不知不觉，我的电脑上已经装了 8 个具备不同技能的 Agent。它们有的负责播客，有的负责日常任务，有的负责写作，有的负责 Jira，有的负责从网页里提取干净内容。它们不是一个统一产品里的几个按钮，而是分散在我本地不同目录里的工作伙伴。
我调用这些智能体最常用的方式，其实也不是 Codex 或 VS Code，而是通过终端进入到对应的文件目录来唤醒 Codex CLI，所以也带来了一个很小但很真实的困扰：技能越来越多以后，我开始浪费时间在“先去哪一个文件夹”这件事上。
一开始这不是问题。只有一两个 SKILL.md 或 AGENTS.md 的时候，我当然记得它们在哪里。要做播客，就去 podcast/；要做日常工作规划，就去日常工作助理目录；要写文章，就打开写作助理的目录。每个智能体都有自己的上下文、规则和文件结构，这种组织方式本身是合理的。
但当 Skill 数量超过五个以后，我明显感觉到这个流程开始变重了。真正的任务还没有开始，我已经要先花一点注意力判断：这个请求应该去哪个目录？这个智能体的规则放在哪里？我要不要再开一个终端窗口？如果每天都用智能体，这种小成本会不断重复。它不一定很大，但很打断思路。
我一开始想到的一个办法，是不是应该把所有 Skills 都移动到 /workspace 目录？这样 Codex 一进来就能看到所有能力，似乎调用起来会更方便。但很快我意识到，这其实是一个坏方向。
因为我的 Skills 不是一次性设计出来的。它们是随着工作一点点长出来的。播客生成有自己的流程，Notion TODO 有自己的数据库规则，写作助手有采访和草稿规则，Jira 工作又是另一套上下文。它们的位置不同，不只是历史原因，也代表了它们所属的工作域。
这种目录结构背后，其实还有一段更早的整理过程。之前我差不多和 ChatGPT 聊了一整天，主题就是理清楚我电脑目录的组织结构，以及我到底希望自己的个人知识库变成什么样。那次讨论里，我借鉴了 Andrej Karpathy 的 llm-wiki 思想，最后整理出一个比较接近自己理想状态的目录结构。它不只是文件归档系统，更是一个让知识从文档、输入逐渐变成个人认知，并且能持续升级的第二大脑。
更重要的是，有些 Skills 看起来相似，但责任并不相同。如果把它们全部放到全局，短期看是省了路径，长期看会增加歧义。智能体可能更容易加载无关规则，浪费 token，甚至调用到错误的 Skill。把所有能力都堆在一起，并不等于系统更聪明，很多时候只是让边界变模糊。
这让我想到一个很经典的软件设计问题：当模块越来越多时，我们到底应该把它们合并成一个大模块，还是给它们一个清晰的入口和分发机制？
我的答案是后者。我在 /workspace 下做了一个入口 Skill，它的职责只有一个：routing 路由。
这个 workspace Skill 不是一个真正干活的智能体。它不生成播客，不管理 TODO，不写文章，也不处理 Jira。它只做一件事：根据用户请求判断应该去哪里，然后加载对应的本地 SKILL.md 或 AGENTS.md。真正的工作仍然交给功能智能体完成。
换句话说，/workspace 是门口，不是工厂。播客生成器 AI 还是负责播客，写作小助手 AI 还是负责写作采访和草稿，任务管理助理 AI 还是负责 TODO 数据库。Router 只负责把请求送到正确的人手里。
这个设计立刻解决了我的日常痛点。以前我要生成播客，先进入 podcast/。要做 daily work assistant，又开一个 terminal 去另一个目录。要写文章，再打开 writing assistant。现在我只需要站在 /workspace 这个入口，对它说我要做什么，Router 会把请求送到正确的智能体。
这背后其实不是一个多复杂的技术实现，而是一个很朴素的工程原则：单一职责。
Router 的职责是分发，不是执行。功能 Skill 的职责是执行，不是到处抢入口。每个智能体都应该清楚自己负责什么，也应该清楚自己不负责什么。这和传统软件工程里的模块设计没有本质区别。
另一个对应的原则是开闭原则。整个系统应该对扩展开放，但对已有模块的职责修改保持关闭。以后如果我需要一个新智能体，我不需要把它复制到 root，也不需要把它揉进某个已有智能体里。我只要创建一个新的 job-specific Skill，然后在 workspace router 里注册一条路由规则。
这样系统就可以继续增长，但不会变成一个 all-in-one 智能体。
这也是我最近对 agentic engineering 的一个感受。现在大家常说从传统 coding 进入 vibe coding，甚至进入 agentic engineering，好像以前那些软件工程原则都不重要了。但我的体验恰好相反：当智能体越来越多，Skill 越来越多，这些原则反而更重要。
一个 Skill 本质上也是一个模块。一个智能体也需要边界、责任和接口。如果我们把所有能力复制来复制去，最后得到的不是一个强大的系统，而是一个职责混乱、难以维护、难以预测的系统。它可能一开始很方便，但很快就会变成“什么都能做，所以不知道该由谁做”。
Routing pattern 的价值就在这里。它让系统有一个统一入口，同时保留局部专业化。用户不需要记住每个智能体住在哪里，但每个智能体仍然可以待在最合适的位置，维护自己的规则和上下文。
这对我来说，是一次很小的个人工程演化：不是把所有东西搬到一个地方，而是给它们设计一条清晰的路。
我越来越觉得，未来使用智能体的能力，不只是会不会写 prompt，也不是会不会让模型生成代码。更重要的是，我们能不能像设计软件系统一样设计自己的智能体系统：哪里是入口，哪里是边界，哪里是责任，哪里应该开放扩展，哪里应该保持封装。
换句话说，Vibe coding 仍然需要工程原则。Agentic engineering 也仍然是 engineering。
#ai #agent #agenticengineering #softwareengineering #workflow