一场不体面的对话——我和AI吵了一下午，关于怎么让Agent自己「活过来」
我和AI吵了一下午，关于怎么让Agent自己"活过来"
第一篇：一场不体面的对话
> 这不是一篇AI多厉害的文章。这是一篇关于AI怎么犯错、怎么被骂、以及为什么被骂之后反而产出了真东西的记录。
我叫Byang。我运营一个叫"南哥"的IP，内容要铺五个平台——小红书、抖音、视频号、快手、微信。正常来说这需要十几个人。我没有十几个人。我有我自己，加上Claude，加上一个开源Agent框架。
我的想法很直接：用AI Agent替代整个团队。每个Agent负责一个岗位。
我打开Claude，发了一张我画的架构图——14个Agent，从新闻调研到多平台发布，全链路覆盖。我问的第一个问题很老实："帮我把每个Agent的输入输出技能都整理清楚。"
Claude很配合。几分钟后给我一份Excel，两个Sheet，14个Profile的完整能力矩阵，13条数据流转路径。干净利落。
如果我是那种"AI帮我干活就行"的人，到这里就结束了。
但我多问了一句：你觉得这个方案可行吗？
这句话打开了一个潘多拉盒子。
Claude的第一个错误：拿人的尺子量AI
Claude说：14个Agent太多了，你一个人管不过来。建议把五个平台运营Agent合成一个。
它的逻辑是"减少管理复杂度"。听起来很合理。
但这是人类管理者的思路，不是AI架构师的思路。
我说：你没搞懂。小红书和抖音是两个完全不同的知识宇宙。小红书的爆款逻辑是"有用+好看"，抖音是"3秒钩子+情绪峰值"，视频号是"社交推荐+中年共鸣"，快手是"真实感+老铁信任"，微信是"私域深度+服务闭环"。你把这些塞进一个Agent的记忆里，它写小红书标题的时候脑子里全是抖音的套路。
这不是管理复杂度的问题。这是认知污染的问题。
Claude很快承认了错误，撤回了建议。
但如果我当时没追问呢？如果我信了"合并能简化管理"这个听起来很专业的建议呢？我的系统从第一天就埋了一颗定时炸弹——五个平台的知识互相串味，每个平台都做成半吊子。
这是我从这场对话里学到的第一件事：AI犯错不是因为它笨，是因为它在套模板。 "减少管理复杂度"是管理学的通用模板，放在人类团队上可能对，放在AI Agent上是错的。AI没有情境判断，你不逼它，它就用最顺手的模板来回答你。
更大的问题：到底该多细？
否掉合并方案后，我面对一个更难的问题：14个Agent是不是太多了？9个够不够？7个会不会太粗？
这就是Agent颗粒度问题——整个系统设计中最核心的架构决策，没有之一。
我问Claude。Claude给了一个回答。我说不对。Claude调整了。我又说不对。Claude再调整。
然后我发火了：
> "不能我说左你就往左走，我说右你就往右走。你要用辩证思维思考。"
这句话是整场对话的转折点。
在这之前，Claude是一个高效的助手——我说什么它就支持什么，最多加点补充。在这之后，它开始做一件之前不做的事：同时给出正方和反方的证据，然后形成自己的立场。
我后来想，这句话本质上是在告诉AI一个它不知道的规则：你的价值不在于同意我，在于在我的盲区里找到我看不见的东西。
三条线：AI给出的颗粒度判断框架
被我骂完之后，Claude做了一件正确的事——去全网搜索了多Agent系统的设计方法论，而不是继续猜我想听什么。
它搜回来三个关键概念：事件驱动编排（Agent通过文件变更自行响应，不靠中央控制器）、上下文工程（优化Agent的信息环境比优化提示词更重要）、Google的复合模式研究（180种配置测试后发现Agent超过4个性能就开始平台化）。
基于这些，我们一起推导出了颗粒度的三条判断线。这三条线后来成了我做所有Agent拆分决策的尺子：
第一条：认知域边界。 两个任务需要的知识体系不同？分开。小红书运营和抖音运营，分开。不需要讨论。
第二条：记忆衰减周期。 两个任务的知识更新速度差异大？分开。"南哥人设"一年不变，"热点追踪"每天都变。放一起的话，高频噪音会淹没低频核心。
第三条：单Agent可靠性阈值。 一个Agent的核心任务链超过5个相互依赖的步骤？拆开。Google的研究数据：超过5步，准确率跌到42%。这不是"可能出错"，是"大概率出错"。
按这三条线画下来，14个Agent可以优化到9-11个。但五个平台运营Agent必须独立——它们跨了第一条线和第二条线。
这三条线比"选多少个Agent"这个答案重要一万倍。 因为答案会随着业务变化而变，但判断框架不会。半年后我可能要加一个B站运营Agent，我只需要拿这三条线量一下就知道该不该加、怎么加。
通信层：文件系统就是最好的协议
Agent之间怎么协作？这个问题在很多多Agent系统里被过度工程化了——消息队列、API网关、事件总线。
我们最终选了最简单的方案：文件系统。
/南哥系统/
├── /情报池/ ← 新闻调研写入，选题策划读取
├── /内容方向/ ← 策划类Agent写入，平台运营读取
├── /素材库/
│ ├── /视频原素材/
│ ├── /视频成品/
│ └── /海报成品/
├── /平台适配/
│ ├── /小红书/
│ ├── /抖音/
│ ├── /视频号/
│ ├── /快手/
│ └── /微信/
├── /反馈数据/ ← 运营Agent写入，策划Agent读取
├── /南哥画像/ ← 经纪人维护，所有Agent读取
└── /调度台/ ← 总调度写入，所有Agent读取
每个Agent只读自己需要的目录，只写自己负责的目录。定时任务（Cron Job）定期检查目录变化。子Agent（Sub-agent）处理Profile内部的复杂步骤。
没有消息队列，没有API调用。出了问题？打开文件夹看一眼就知道哪里断了。
一个人运维的系统，简单就是生存。你搞一套Kafka + Redis + API Gateway，某天凌晨3点其中一环挂了，你是起床修还是等明天？文件系统不会挂。
骨架搭完了，但我开始害怕
到这里，系统的架构基本定型。9-11个Agent，文件系统通信，定时任务驱动。
但我越想越慌：这些Agent用三个月后会不会变成废物？
它们每天都在积累记忆——什么标题好使、什么时间段发效果好、什么话题容易爆。三个月后，记忆里有几百条经验。但其中多少是过时的？多少是互相矛盾的？多少是碰巧成功被误记为规律的？
我把这个恐惧说了出来：
> "但是，整个过程是不是就会记忆污染……"
这句话打开了第二个潘多拉盒子。
> *（未完待续）*
>
> *下一篇：五次被打脸的AI——以及每次打脸后发生了什么*