AI Agent 之所以失败，是因为架构混乱
AI Agent 往往看起来很强大，但实际上非常脆弱。
十二小时前，我的技能系统是这样的：
- 34 个技能分散在 3 个不同的目录中。
- 28 个技能声称可以移动，但实际上只有 2 个能动。
- 两个管理系统无法通信。
- 一个工具在无人察觉的情况下删除了某个技能中的 100 行代码。
大多数人都在赞美大语言模型。他们认为模型就是力量。但模型仅仅是大脑。一个能够运行的 Agent 需要四样东西：
- 记忆 (Memory)
- 技能 (Skills)
- 钩子 (Hooks)
- 扩展 (Extensions)
如果其中一个环节出错，Agent 就会失效。我的错误不是一个 Bug，而是碎片化。我拥有断裂的路径和缺失的链接。
AI 开发中的危险在于不加计划地立即使用工具。为了节省时间，你会添加 Firecrawl、Crawl4ai 和各种 MCP 服务器。但当你拥有 115 个第三方技能时，会发生三件事：
- 命名冲突：两个同名的技能会导致系统崩溃。
- 环境污染：一个技能破坏了另一个技能运行的环境。
- 更新导致损坏：API 更新会悄无声息地破坏你的调用链。
这就是架构熵。随着系统的增长，它们会变得越来越难以追踪。
不要等到项目稳定后再去整理。那是一个陷阱。我花了 12 小时来修复我的系统：
- 我将分散的目录合并为两条清晰的路径。
- 我增加了一个门控机制来检测意外删除。
- 我创建了一条规则，在任何系统变更后通知创建者。
- 我删除了旧的、无用的文件。
这不是在开发新功能，而是在进行架构卫生管理。卫生管理是一种复利投资，而不仅仅是维护成本。
如果你正在构建 AI Agent，请遵循这条规则： 从第一天起就为记忆和技能设定规则。
及早询问这些问题：
- 记忆存储在哪里？
- 你如何管理版本？
- 技能存储在哪里以避免命名冲突？
- 谁来记录扩展之间的依赖关系？
- 谁来执行定期审计？
这些问题的答案决定了你的 Agent 能成长到多大。AI 的瓶颈不在于参数量，而在于一个混乱的“家”。
Optional learning community: https://t.me/GyaanSetuAi