别让“AI 自动化”成为你的工程债：从 100 个 Agent 到 1 个可靠 Pipeline 的反思

在过去半年的 AI Lab 交付中，我们经历了一个典型的“认知陷阱”：起初，我们痴迷于构建复杂的 Agent 编排。我们设计了拥有独立人格的“内容总监”、“代码专家”和“质量审计员”，试图通过一个庞大的多 Agent 协作网络来完成从选题到发布的闭环。

结果是，我们陷入了所谓的“Agent 熵增”。

1. “协作”的幻觉与延迟的真相

在早期的架构中，一个文章发布流程需要经过：选题 Agent $\rightarrow$ 大纲 Agent $\rightarrow$ 正文 Agent $\rightarrow$ 翻译 Agent $\rightarrow$ 审核 Agent。

表面上看，这模拟了人类编辑部的运作方式。但实际运行中，我们发现了三个致命问题：
- 上下文漂移：在传递过程中，最初的选题意图在第三个环节就被稀释了。
- 错误级联：如果大纲 Agent 在某个逻辑点上产生了幻觉，后续所有 Agent 都会基于这个错误进行“精美地扩写”，导致最终产出虽然流畅但完全错误。
- 不可预测的延迟：多步 LLM 调用意味着延迟是累加的，且任何一个节点的超时都会导致整个 Pipeline 崩溃。

2. 从“编排”回归到“Pipeline”

我们意识到，对于一个确定性的交付目标（如每日文章发布），Pipeline（流水线）远比 Agent（代理）可靠。

我们将架构重构为：单一强模型 + 结构化 Prompt + 硬编码校验逻辑。

重构后的核心逻辑：

1. 原子化任务：不再让 Agent “思考如何写作”，而是给它一个极其具体的指令集（例如：“基于以下项目日志，提取三个具体的技术痛点，并用‘问题-方案-结果’结构撰写”）。
2. 状态机驱动：使用 Python 脚本控制流程，而不是依赖 LLM 的自主决策。每一步的输出必须通过正则或 JSON Schema 校验，不通过则立即重试或报错，而不是交给下一个 Agent 去“猜测”。
3. 单点翻译策略：放弃多轮对话翻译，采用一次性、带上下文约束的翻译 Prompt，确保术语在 zh-CN, zh-TW, en 三语之间严格对齐。

3. 工程实践中的三个关键细节

在实际部署 SFD V4 CMS 的自动化发布时，我们采用了以下工程手段来降低风险：

A. 无状态的 Token 管理

不要在代码中硬编码凭据。我们采用了缓存文件 + 定期刷新机制。脚本启动时先进行 write_probe（尝试写入一个虚拟对象），如果返回 401 则触发重新登录流程。这避免了因为 Token 过期导致的深夜发布失败。

B. “封面-内容”异步解耦

封面生成（Image Gen）通常比文本生成慢得多且不稳定。我们将封面生成放在文章 POST 之后，通过 PATCH /api/v4/articles/:id 进行异步关联。即使图片生成失败，文章也能先以占位图发布，而不会阻塞整个发布链路。

C. 公网端到端验证 (E2E Verify)

最危险的成功是 API 返回 200 OK 但前端页面是空白。我们在 Pipeline 的最后一步加入了公网 API 回查：请求 /api/v4/articles?slug=...&locale=... 并验证返回的 status 是否为 published。只有三语全部回查成功，才标记为 PASS。

4. 给 AI 工程者的建议

如果你正在构建 AI 应用，请记住：能用 if/else 实现的逻辑，绝对不要交给 LLM 去决策；能用 Pipeline 完成的任务，不要试图用 Multi-Agent 来模拟协作。

AI 的价值在于处理非结构化的创造力部分（如将枯燥的项目日志转化为有温度的文章），而工程的价值在于将这种创造力包裹在一个极其枯燥、确定且可预测的管道之中。