CrewAI 数字员工团队架构审计 + 引流组整治方案

背景:两天动刀后本人对团队产出仍不满意,点名"引流组效率低下,工具、流程、质检肯定有问题"。 本方案由军师调研产出(另一窗口 concurrently 在跑文章产出,未动其工作)。 审计基准:crewai 技能手册(2026-08-07 官方文档 15 页精读)+ D:/code/CrewAI 全量摸查。

一、先回答 MCP 的问题:crewai-docs 没有加,也不该加在运行时

• 全仓 grep mcp 零命中;src/crew_factory.py 装配 Agent 时只透传 role/goal/backstory/llm 等 6 个字段,根本没有 tools/mcps 通道;requirements.txt 无 mcp 相关包。
• 但判断:crewai-docs MCP 是"开发者查框架文档"用的,是军师侧(Kimi Code)的工具,本会话已挂上;运行时数字员工写稿不需要查 CrewAI 文档。引流组 agent 真正缺的工具是:①选题对标用的搜索/抓取工具;②数据复盘用的采集数据读取。动刀别动错地方——给运行时挂 crewai-docs 是错刀。

二、架构审计:对标成熟多智能体方案,什么到位、什么缺失

工程现状:CrewAI 1.15.8,YAML 驱动,入口 main.py --team <名> --topic <主题>,5 个团队(yinliu/xianyu/shengchan/shouhou/template),全员顺序流程,全员 kimi(OAuth 续期守护已修)。

已到位(高于"基本配置"线的部分)

• 声明式团队配置 + template 模板机制;lite/full 双模式装配层通用裁剪
• guardrails 硬+软混合校验链(官方手册钦定"最便宜的质检升级")——yinliu 4 硬 + 2 软,禁词表与 zhijian_check 同源,数字溯源硬闸(无来源标注直接打回)
• rules.md 单一事实来源 + 按节注入(防上下文臃肿)
• 结构化日志 + usage_metrics + 语义化退出码(0/2/3/4/5)
• context_tasks 上下文裁剪、archive_to 确定性归档(不依赖 agent 自觉)
• 装配校验 --no-run 不烧钱;3 个测试文件;OAuth token 续期(修掉了 401 必死)

缺失(对照官方成熟架构清单)

三、引流组效率诊断(证据来自 logs/ 10 次真跑 + 产出抽读)

先说反直觉的结论:引流组不是落后者,是全工程唯一重装的旗舰(唯一有 rules.md/guardrails/数据注入;其他三个团队裸配,shouhou 从未真跑)。它的问题是"重到臃肿再一路砍",外加两个流程结构病。

效率账(lite 链实测)

full 链:33 分钟 / 61 万 token。单篇成本仍然太高。

病因分解(按损耗排序)

1. 基建事故税占一半:10 次真跑 5 次死于基建(3 次 OAuth 401、1 次 LLMGuardrail 解析崩溃、1 次 CrewAI 事件总线 getsource bug)。已逐个修掉,但属"踩一个修一个",无测试覆盖 CrewAI 内部坑。
2. 结构病 A:打回 = 全文重生成。长文被打回 2 轮,每轮两篇长文整体重吐——token 成本第一大头。缺"局部改写/只重跑该任务"机制。
3. 结构病 B:品控只能代笔,不能退回写手。顺序流程里 pinkong 的任务书是"不过的直接修改到过"——写手永远收不到否定信号,同类毛病(台账味/AI 腔)每篇靠 guardrail 再拦一次,没有学习回路。这是"反复出现同类打回"的流程根因。
4. 数据闭环在默认链路是断的:fupan 任务被裁进 --full,lite 默认链看不到采集数据;xuanti 选题岗零数据注入,选题不靠数据——"生死组"的核心机制空转。
5. 发布粘合靠手工:run 目录 → gen_paiban_html/gen_covers → fabu 分发包,军师手工组装,无自动化。
6. 采集端半残:6 平台只通 3(juejin cookie 失效、toutiao 反爬未解、baijiahao 空响应);篇 3 已发布但 CSDN 未收录。

产出质量本身不差(抽读 21:44 定稿:口语化、真实细节、口径正确、数字全标来源,可直接进发布流程)——问题确实在工具、流程、基建,不在内容。

四、整治方案(动刀清单,按优先级)

P0 纯配置,零风险,另一窗口跑完即可做

1. xuanti 接数据:tasks.yaml 给选题任务加 inject_files: D:/code/thinking/tools/yinliu_data/reports/latest.md(一行配置,机制现成)——"数据定选题"闭环接到默认 lite 链。
2. 装配层开 tools 通道:crew_factory 增加 tools/mcps 透传;给 xuanti 挂搜索工具(SerperDevTool 或 BraveSearchTool,需 key——花钱项,报本人确认;不花钱的过渡方案:挂 FileReadTool 读本地对标稿库)。
3. 给运行时加 crewai-docs MCP ——否掉,错刀(见第一节)。

P1 结构动刀(等另一窗口跑完,本次主刀)

1. Flow 化产线骨架(治结构病 A+B 的总手术):
   • @router 质检三分支:合格→meta 归档 / 打回→退回写手任务重跑(不是品控代笔,不是整链重吐)/ 废弃→止损;
   • 打回重跑只烧写手一个任务的 token,预计单篇成本再降 30-50%;
   • 顺手开 checkpoint=True 防中断重跑;
   • 骨架用 Flow、创作用 Crew,符合官方决策矩阵;flow.plot() 出图给本人验收。
2. 过渡方案(Flow 不稳时降级):纯 Crew 不动,打回改用 crewai replay -t <task_id> 从写手任务重跑——成本优化拿到大半,结构病 B(无反馈回路)留待 Flow。

P2 沉淀层(本周内插空)

1. Knowledge 接选题库/历史定稿,rules.md 从 210 行瘦身回"纪律+红线",风格知识进 RAG。
2. 事件总线接打回率 + 单篇 token 成本,落 logs/metrics.jsonl,给 jihua 的 kimi_quota_check 供数据。
3. crewai train 沉淀本人口味(交互式,选人闲时;把篇 3 四次返工换来的审稿标准固化进 pkl)。

P3 待拍板

1. 便宜模型 key(模型分层真正生效,花钱);
2. 采集端补通 juejin/toutiao/baijiahao(反爬对抗,投入产出比先估再定)。

五、蛇尾预案(铁律四)

• 收尾验收线(什么叫整治完成):lite 链单篇 ≤10 分钟且 ≤20 万 token;打回退回写手而非品控代笔;选题卡带数据来源标注;同一选题重跑时 guardrail 打回次数环比下降(学习回路生效的证据)。
• 降级/止损线:Flow 改造若连跑 2 次仍死于 CrewAI 内部坑,立即降级到方案 5(replay 局部重跑),不硬扛;tools 通道若引入新的不稳定源,先回滚装配层改动(改动全部 git 留痕)。
• 验收方式:整治后同一主题连跑 2 篇,对照本文件第三节的效率账逐项核对,数据只认 logs/ 实测。

五.五、执行记录(2026-08-09 深夜,当晚上半场的刀已落)

• 口径全栈修复(CrewAI fdb0bf0 / thinking 7abc4ec):tasks.yaml 4 处+agents.yaml 1 处旧口径命令、guardrails.py 旧口径豁免——任务书下令写错、质检闸保护错误的自相矛盾已清除;zhijian_rules.json 两条打回文案指向作废口径的误导顺手修复。39 项测试全过,双模式 --no-run 装配通过。
• P0-1 落地:xuanti 注入 latest.md,数据闭环接上默认 lite 链。
• 篇 3 重制实测:lite 链 880s / 26.0 万 token / 30 请求 / 零打回零崩溃,品控一次签字;分发包 output/fabu_20260810_pian3/(六件齐,封面底图旧口径烘焙字已修)。
• 效率账对照:耗时与 token 对比上轮 lite(823-932s / 23.7-48.1 万)基本持平,未再降——今晚的收益全在质量侧(口径事故根除、一次成稿);速度侧下一刀就是 P1 Flow 化(打回局部重跑),不变。
• P0-2(tools 通道)未做:搜索 key 是花钱项,等本人拍板。

六、分歧与边界

• 本人判断"引流组工具、流程、质检肯定有问题"——核实结果:质检没问题(全工程最重),工具和流程判断正确。如实记录,供复盘检验。
• 扩编不在本方案内(2026-07-29 本人裁决"不扩编"仍有效)。
• 涉及花钱项(搜索 key、便宜模型 key)均已标注,未执行,等一句话确认。