为什么我们没做超级 Agent，而是搞了个多 Agent 应用中心？

做 AI 产品这段时间有个问题一直绕不过去到底是做一个啥都能干的超级 Agent还是做一堆专门干一件事的垂类 Agent我们选了后者。这篇文章就是想聊聊这个决策背后的想法给同样在纠结的朋友一点参考。先说说我们为啥质疑超级 Agent现在主流的 AI 工具默认思路都是做一个尽可能强的通用 Agent。但说实话这个假设有几个前提我们越想越觉得不对劲。第一个前提用户需要灵活跨域的能力其实不是。我们聊了很多用户后发现大家真正高频的需求特别具体每天发一篇小红书每周写一篇技术博客每月交一份周报每个节日做一组营销图这些都是重复做、有固定套路的事。用户要的不是灵活的 AI而是快、稳、别出错的专业工具。第二个前提AI 能力可以无限堆叠我们测过现实很骨感工具超过 30 个选工具的准确率就开始掉提示词超过 5000 字模型就开始装傻上下文塞太满推理质量明显下降Agent 不是越大越强是越大越糊。第三个前提Agent 越强体验越好恰恰相反。一个 Agent 既要会写小红书又要会写代码还要会做图、调 API…提示词必然变得又臭又长各种能力互相打架。用户用起来就是啥都能干但啥都干不好。我们的解法应用中心 垂类 Agent所以我们就反着来了。不搞一个超级大脑而是搞一群专家TipKay 应用中心里有通用 Agent实在搞不定的扔给它兜底小红书博主 Agent专门写小红书 直接发布知乎博主 Agent写长文专用博客发布助手适配 CSDN、知乎、掘金、头条四个平台文章配图 Agent专门搞图文搭配还有用户自己用编辑器搭的 Agent…每个 Agent 的设计原则很简单提示词只聚焦一件事控制在 1000 字以内工具不超过 10 个反复执行的任务要又快又稳别被无关的能力分心几个关键的工程决策1. 每个 Agent 独立提示词我们没搞主提示词 加载 Skills那种方案。每个垂类 Agent 都是独立的——独立提示词、独立工具、独立配置。好处很明显改一个不会影响其他调试也简单。用户也清楚自己在用啥“我在用小红书博主而不是我在用一个加载了小红书技能的通用 AI”。代价就是工程上要维护多套提示词一些通用逻辑比如品牌包注入得想办法共享。2. Context Assets 三层共享为了解决这个问题我们做了 Context Assets 系统用户资料你是谁、做啥的品牌包Logo、配色、Slogan素材包产品图、案例、文案库所有 Agent 自动读取这些上下文相当于有个全局共享的用户记忆。// 简化版伪代码classBaseAgent{asyncbuildPrompt(userInput:string){constcontextAssetsawaitthis.loadContextAssets()return${this.systemPrompt}# User Context${contextAssets.baseProfile}# Brand Context${contextAssets.brandKit}# Available Materials${contextAssets.assetManifest}# User Input${userInput}}}每个垂类 Agent 继承这个 BaseAgent自动获得 Context 注入能力。3. MCP 和 Skills 只是补充我们也支持 MCP但定位很清楚垂类 Agent 缺能力的时候用来补而不是先搞个超级 Agent 再用 MCP 去撑。优先级是垂类 Agent 主力 → 缺啥补啥。4. 用户可以自己造 Agent我们做了个 Agent App 编辑器用户可以自己搭垂类 Agent配提示词、选工具、选模型测试完发布到市场给别人用这样 Agent 的数量就从我们做的 6 个变成了无限个。实测数据垂类 Agent 真的更强吗我们做过对比实验任务是让 AI 生成 10 篇小红书笔记。指标通用 Agent垂类 Agent平均耗时4 分 12 秒1 分 38 秒文案合格率67%92%配图风格统一率23%96%工具调用错误率12%2%Token 消耗8.3k2.1k在重复任务上垂类 Agent 确实是降维打击。但多 Agent 也不是万能的说实话这个方案也有不适合的场景不适合的深度研究类任务比如 deep research需要在多个领域跳来跳去探索性任务你自己都不知道要啥需要 AI 给建议开发者工具像 Cursor 那种写代码、读文档、调 API 随时切换适合的重复执行的固定任务发小红书、写博客特定行业的深度任务普通用户不是程序员是花店老板、自媒体博主给同行的几点建议如果你也在做 AI 产品可以想想这几个问题你的用户是开发者还是普通人开发者习惯自己配 Skills普通人更喜欢开箱即用的垂类工具。核心场景是探索还是重复执行探索用通用 Agent重复执行用垂类 Agent。Agent 数量预期多少少于 5 个凑合用一个超级 Agent超过 10 个就必须上应用中心架构。你愿意把多少决策权交给用户交得多就做通用平台交得少就做多 Agent 矩阵。最后说两句架构决策说到底是对用户需求的判断。我们选多 Agent 矩阵是因为觉得中文创作者的核心需求是把重复的事做得又快又稳而不是有一个啥都懂的 AI 助手。这个判断对不对时间会给出答案。但至少希望这篇文章能让大家意识到——做 Agent 不是只有做一个超级大脑这一条路。