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