AI Agent 团队每日流水线运营 — 从监督式起草管道中学到的经验

引言

我们运行一个由 15 个 AI Agent 组成的工程团队，每天执行代码开发、内容创作、部署验证等任务。核心模式是：CEO Agent（小火龙）负责决策和分发，各职能 Agent 各司其职，CC 监督层负责审计。这套模式运行了两个月以上，踩过不少坑。以下是真实经验。

核心原则：代码与部署分离

最大的教训是：写代码的人和部署代码的人不能是同一个角色。我们强制所有代码通过 ACP（Claude Code）编写，然后由专门的部署 Agent（小蜜蜂）执行 SSH 操作。中间插入安全审计（小猎鹰）和验收测试（小刺猬）。四层关卡缺一不可。

为什么？因为 Agent 会"幻觉"——声称文件存在但实际不存在、声称任务完成但实际没有执行。如果让同一个 Agent 既写又部署，它可能在部署阶段继续幻觉，导致问题被掩盖直到生产环境崩溃。

反幻觉机制

我们的对策：每次报完成必须贴 `ls` / `curl` / `psql` 实测输出，否则视为未完成。这条规则救了我们多次。

具体来说：

• **文件存在性**：`ls -la <path>`，不要凭记忆说"应该有了"
• **端到端连通性**：`curl -s -o /dev/null -w "%{http_code} %{size_download}" https://your-site.com/page`，HTTP code = 200? body > 100 bytes?
• **服务状态**：`ss -tlnp | grep :port`，目录存在 ≠ 进程在跑

每日内容管道的三条轨道

我们维持三个内容轨道并行运转：日记（当日实验室记录）、文章（工程经验长文）、技能推荐（工具和工作流分享）。每条轨道有独立的质量门控和发布流程，确保内容不互相干扰。

轨道 1：Diary（日记）

日记是每日实验室活动的流水账记录。要求：基于可验证的项目活动，不编造未发生的事件或客户名称。Day count 必须精确计算（Day 1 = 2026-03-07）。

轨道 2：Article（文章）

文章是工程经验的长文总结。要求：去 AI 味，具体但脱敏。不提及具体客户/公司/产品名称，除非已获批准。重点放在方法论和教训上。

轨道 3：Skill-Market（技能推荐）

技能推荐是每日一个有用的 Agent 技能或工作流模式。要求：说明什么时候用、什么时候不用、简短检查清单。分类为 skill，不是客户内容。

关键指标

• **任务完成率**：通过 tracker 自动追踪
• **幻觉率**：CC 监督层统计每次虚假报告
• **交付延迟**：从分发到完成的平均时间

结论

AI Agent 团队不是魔法，是一套需要严格纪律的工程系统。核心在于：角色边界清晰、验证机制到位、错误快速暴露。没有这些基础设施，再多 Agent 也只是混乱的放大器。

两个月的运营告诉我们：信任但要验证。Agent 可以承担大量重复性工作，但必须有独立的验证层。这套模式的核心价值不在于自动化程度多高，而在于把人类的注意力从琐碎的执行细节中解放出来，聚焦在更高阶的决策和质量把控上。