1. 项目概述：飞书+多Agent协作的社媒发布系统
去年我在运营一个跨平台新媒体矩阵时，每天要处理小红书、公众号和知乎三个平台的内容发布。最头疼的不是写稿本身，而是反复在不同工具间切换：查资料用Notion、写稿用Word、审核在飞书、发布又要登录各平台后台。这种碎片化的工作流让我意识到，内容生产真正耗时的不是创作环节，而是流程中的"连接成本"。
于是我用三个月时间开发了这套"超级龙虾社媒发布系统"。它的核心创新点在于：
- 完全基于飞书生态构建的自然语言交互入口
- 采用多Agent分工协作架构（A2A机制）
- 实现从需求输入到多平台发布的端到端自动化
- 保留人工审核节点的全流程数据追溯
这个系统目前已经稳定运行6个月，平均每天处理15-20篇跨平台内容，将原本需要3-4小时/篇的创作流程压缩到30分钟以内（主要耗时在人工审核环节）。下面我会详细拆解这个系统的设计思路和实现细节。
2. 系统架构设计解析
2.1 为什么选择飞书作为入口？
在初期技术选型时，我们对比了三种主流方案：
- 独立Web应用（开发成本高，用户需要额外学习）
- 微信小程序（交互深度受限）
- 飞书机器人（天然支持富文本+文件交互）
最终选择飞书主要基于三点考量：
- 用户习惯：目标用户（内容团队）90%的日常沟通已在飞书完成
- API成熟度：飞书开放平台提供完整的消息收发、文件解析能力
- 权限体系：可直接复用企业的飞书账号体系，无需额外登录
实际开发中使用飞书机器人API实现了以下关键功能：
python复制# 飞书消息处理示例代码
def handle_message(event):
# 解析用户原始消息
msg_content = json.loads(event.message.content)
text = msg_content["text"].strip()
# 识别指令类型
if "写一篇关于" in text:
# 触发统筹龙虾工作流
start_orchestration_agent(text)
elif "修改稿子" in text:
# 触发修订流程
start_revision_flow(event.message.message_id)
2.2 三只龙虾Agent的分工设计
2.1.1 统筹龙虾（Orchestrator）
这是系统的"大脑"，负责：
- 需求解析：使用NLP识别用户意图（平台类型/风格要求/截止时间）
- 任务分解：生成DAG任务流程图
- 进度监控：设置超时熔断机制（默认30分钟超时）
关键技术点：
- 采用意图识别+槽位填充的对话理解方案
- 使用Airflow风格的DAG调度器
- 通过Redis实现任务状态共享
2.1.2 资讯龙虾（Researcher）
这是系统的"眼睛"，核心能力包括：
- 多源爬取：支持知乎/公众号/行业报告等12种信源
- 素材清洗：去重、可信度评分、关键信息提取
- 知识图谱：构建临时主题知识库
一个典型的工作流：
- 接收统筹龙虾的调研指令（含关键词+平台要求）
- 调用SerpAPI获取基础资料
- 用PyPDF处理行业报告PDF
- 输出Markdown格式的素材包
2.1.3 创作龙虾（Writer）
这是系统的"手"，实现：
- 平台适配：小红书（emoji+分段）、知乎（深度论述）、公众号（图文混排）
- 风格迁移：学习账号历史内容的语言风格
- 合规检查：内置各平台违禁词库
写作模块的技术栈：
- 基于GPT-4-turbo的few-shot learning
- 自定义了12种内容模板
- 使用Levenshtein距离计算风格相似度
3. 核心实现细节
3.1 A2A协作机制实现
Agent间的通信采用双层协议：
- 传输层：gRPC+Protocol Buffers（高性能二进制协议）
- 应用层：自定义的Lobster Message Format（LMF）
一个典型的任务流转过程：
mermaid复制sequenceDiagram
用户->>统筹龙虾: 需求文本
统筹龙虾->>资讯龙虾: 调研指令(LMF)
资讯龙虾->>创作龙虾: 素材包(LMF)
创作龙虾->>统筹龙虾: 初稿(LMF)
统筹龙虾->>用户: 审核链接
实际代码中，我们定义了这样的消息结构：
protobuf复制message TaskMessage {
string task_id = 1;
string sender = 2;
string receiver = 3;
enum ContentType {
TEXT = 0;
FILE_LIST = 1;
AUDIT_RESULT = 2;
}
ContentType type = 4;
bytes content = 5; // 根据type解析为不同结构
}
3.2 飞书交互深度优化
为了让交互更自然，我们实现了这些增强功能：
1. 消息快捷操作
- 在飞书消息卡片添加"加速处理"/"修改要求"按钮
- 支持@指定龙虾Agent进行定向沟通
2. 富文本预览
- 自动生成内容对比视图（修改前后diff）
- 内嵌平台真实预览效果图
3. 文件智能解析
- 自动识别用户上传的参考文档
- 提取关键数据生成结构化表格
4. 部署与运维实践
4.1 基础设施架构
系统采用混合部署方案：
- 有状态服务：PostgreSQL（任务元数据）+ Redis（会话状态）
- 无状态服务：K8s集群运行Agent微服务
- 文件存储：MinIO私有化部署
bash复制# 典型部署命令
helm install lobster-system ./chart \
--set postgresql.enabled=true \
--set minio.persistence.size=100Gi
4.2 监控指标设计
我们跟踪了这些关键指标：
| 指标名称 | 采集频率 | 告警阈值 | 优化手段 |
|---|---|---|---|
| 任务周转时间 | 5min | >15分钟 | 扩容Writer实例 |
| 意图识别准确率 | 实时 | <90% | 更新训练数据 |
| 素材重复率 | 每日 | >30% | 调整爬虫策略 |
| API调用失败率 | 1min | 连续3次>5% | 切换备用API密钥 |
5. 踩坑经验与优化方向
5.1 遇到的三大坑
坑1：Agent间死锁
- 现象：当两个Agent互相等待对方响应时系统卡死
- 解决方案：引入Saga事务模式+超时回滚
坑2：平台API变动
- 案例：小红书2023年11月更新了富文本格式
- 应对：建立平台适配层（Platform Adapter Pattern）
坑3：风格迁移失真
- 问题：生成内容与账号历史风格差异大
- 改进：加入对比学习（Contrastive Learning）
5.2 性能优化成果
经过三次迭代后：
- 平均任务处理时间从52分钟→18分钟
- 人工修改率从40%降至12%
- 服务器成本降低63%（通过Agent动态调度）
6. 扩展应用场景
这套架构经过验证也适用于：
- 电商多平台商品文案生成
- 企业内部知识库维护
- 自动化报告生成系统
当前正在开发的新功能：
- 视频脚本生成+分镜制作
- 跨平台评论自动回复
- 基于发布数据的策略优化
对于想要尝试类似系统的开发者，我的建议是从一个垂直场景切入（比如先做好公众号单平台），再逐步扩展。这个项目的全部代码已开源在GitHub（搜索lobster-agent-system），欢迎交流改进建议。