我把小某薯运营做成了一个Agent系统

先说结论TokenFactory的小某薯运营专家不是一个能写小红书笔记的ChatGPT。它是一个由6个专业Agent组成的协作系统运行在TokenFactory的Harness编排层之上通过A2A协议实现Agent间通信由TokenRouter做智能路由决策。整个系统架构如下为什么是6个Agent而不是1个这是很多工程师的第一反应——一个大Prompt不就完了吗不行。原因如下单Agent的三个致命问题问题具体表现多Agent如何解决上下文爆炸单Agent需要同时理解品牌调性、竞品动态、平台规则、达人数据……上下文窗口很快爆掉每个Agent只处理自己领域的任务上下文精简聚焦职责混乱单Agent容易写着写着开始分析数据流程不可控L3执行编排强制每个Agent只做自己的事不允许跨职责操作错误传播单Agent如果竞品分析出错后续所有内容都会基于错误信息生产竞品监控Agent的输出经过L5独立评估错误不会传播到内容生成AgentA2A协同一篇种草笔记的诞生过程来看一个完整的协作流程——品牌要推一款熬夜修复精华Step 1竞品监控Agent检测到竞品本周各有3篇新品笔记关键词集中在熬夜肌、急救——通过A2A发给选题挖掘AgentStep 2选题挖掘Agent结合热点竞品数据品牌素材库输出选题《熬夜到凌晨3点第二天还被夸皮肤好》《打工人熬夜自救指南这瓶精华我回购了5次》《测评了10款熬夜精华只有这瓶让我真香》Step 3内容生成Agent根据选题品牌素材库平台调性模板生成3篇笔记的完整文案标题正文标签封面建议Step 4合规审核AgentL5L6逐篇扫描第1篇标题含好非极限词→通过功效宣称修复在备案中→通过第2篇文案含回购5次→触发L6真实性校验→需品牌确认销量数据第3篇测评10款需确认是否真的做过竞品对比→标记风险Step 5平台发布Agent将审核通过的笔记适配各平台格式小某薯种草口吻emoji话题标签Step 6数据复盘Agent在发布后72小时内追踪各笔记的曝光/互动/收藏数据自动生成周报并反馈到选题挖掘Agent优化下一周的内容策略TokenRouter路由策略Benchmark这是工程师最关心的——路由策略到底能省多少Token、质量有没有降跑了一周的实测数据路由策略周Token消耗内容质量人工抽检评分/10分高性能模型调用占比全部走高性能模型112万Token8.3分100%智能路由TokenRouter41万Token8.1分28%变化↓63.4%≈持平路由精准度验证部署踩坑实录坑1品牌调性漂移现象连续生成3篇笔记后风格开始偏离品牌预设调性原因L1上下文窗口被竞品数据污染品牌素材的权重被稀释解法L1增加品牌调性锚定机制——每生成3篇笔记后强制刷新品牌素材库的上下文优先级坑2小红书平台规则变更现象某天全部笔记被平台限流原因小某薯更新了引流规则数字员工的标签策略品牌账号话题标签组合触发了新规则解法L2工具系统增加平台规则更新订阅规则变更后48小时内自动调整策略模板坑3达人数据时效性现象推荐的部分达人已停止更新或粉丝量严重注水原因达人数据源更新频率不够原为周更解法接入实时达人数据API推荐前增加账号活跃度校验前置检查这个案例的工程亮点不在于用AI写小某薯笔记——这本身并不复杂。亮点在于多Agent协作的编排设计——6个Agent各有职责边界通过A2A协议协同L3确保流程不乱TokenRouter的精细化路由——不是简单的简单/复杂二分法而是按任务类型复杂度品牌等级的三维决策六层防护网的场景化落地——每一层都对应一个真实的小红书运营痛点如果你在做一个企业级AI产品这个案例值得仔细研究——它展示了从Prompt工程到Harness工程的范式转移。