LLM自动化任务：如何设计可验证的输出契约

我看到许多 cron 代理结合 LLM 失败，不是因为模型本身，而是因为输出。任务启动良好，prompt 看起来合理，可最后没人知道结果是否被批准了、是否真的发布了，还是系统只留下了漂亮的日志。当这种事发生在凌晨 3 点时，问题就不是 prompting 的问题了。这是一个契约的问题。

对我来说，一个调度代理需要清晰的输出，就像 API 一样。如果流程写入内容，也应该留下可验证的证据：计划、最终制品、发布结果，以及一条容易检查的执行路径。听起来有点死板，但在生产环境中，这种严格性能够带来安心。

Cron 代理为什么需要输出契约

LLM 擅长生成选项。另一方面，cron 系统需要在一个可观察的决策上收尾。如果你混合这两种本质而没有清晰的边界，会出现一些典型的症状：

• 每次重试时代理都生成不同的制品
• 发布者不知道哪个版本是正确的
• 后续审查变得几乎不可能
• 团队最终依靠直觉而不是证据

输出契约解决了这个问题，强制代理以少数几个有可预测名称的制品结束。在我脑子里，概念图很简单：上下文 -> 批准的计划 -> 单一文章 -> 发布结果。每一步都减少自由度。不会扼杀模型的创意，但会给它有用的栏杆。

这类似于在不产生操作焦虑的情况下分离 UX 和验证重试中证据的理念。在两种情况下，技巧都不是"做更多 AI"，而是更好地定义成功意味着什么以及如何观察它。

能挺过一个深夜的最小设计

当我搭建这类自动化时，我尽量让每次运行留下四样东西：

• 一个 plan.json，包含标题、关键字、链接和大纲。
• 一个 article.raw.md，只写一次。
• 一个 publish-result.json，包含最终状态和 URL。

有了这些，你几乎可以在不打开十个标签页的情况下重建整个 job 的历史。如果某次运行发布了奇怪的东西，你可以对比计划和文章。如果没有发布，你读结果。如果发布了两次，你搜索 run_id 并看到哪里破坏了规则。

这有一个实际原因：自动化的可靠性在系统使其转换可见的时候提高。DORA 的《DevOps 现状》报告继续显示，具有更好反馈循环和操作可观察性的团队以更少的摩擦执行更改。当然这不仅仅涉及 LLM，但原则完美贴切。

契约的最小例子可能看起来像这样：

{
  "run_id": "20260801T112224Z-lucasg88",
  "artifacts": ["plan.json", "article.raw.md", "publish-result.json"],
  "write_once": ["article.raw.md"],
  "final_message": ["selected_account", "title", "run_directory", "published_url"]
}

不复杂。也不试图描述一切。只是固定了操作边界。这样做，老实说，已经避免了很多愚蠢的痛苦。

创意与可验证性之间的权衡

常见的反对是："如果我过度约束流程，LLM 会写得更差"。有时确实会，但几乎总是因为契约设计得像紧身衣而不是接口。我更喜欢这样思考：

• 计划定义约束和焦点。
• 文章在该框架内保持自由。
• 发布者永远不即兴创作内容。

第三点很重要。如果发布脚本改写文本、修正标题或发明元数据，你就没有一个可分离的系统。你有一个隐藏在执行器内的生成器，之后调试它是一团糟。

在后端栈中，我将其与清晰的边界测试相比较。类似的东西出现在这些关于 FastAPI 中事务电子邮件的清晰测试中：当执行器只执行而计划已经阐明意图时，系统变得更可读。

还有一个有点不舒服的细节需要接受：一点点人的不完美可能在编辑内容中是可取的，但基础设施不应该继承那种模糊性。你可以容忍一个有点奇怪的句子；你不应该容忍一个模糊的最终结果。这种区别不总是被很好地设计。

在某些地方我使用临时一次性邮箱而不污染系统

虽然这类流程不依赖外部品牌，但有些时刻临时一次性邮箱帮助很大：onboarding 测试、隔离验证和不想与真实帐户混合的可交付性检查。关键是不要把这个资源放在系统的中心。它应该位于边界，按场景，生命周期短，运行名称清晰。

如果一个团队混合了测试邮箱、真实凭证和诸如 tamp mail com 之类的 seed 作为同一证据，之后没人知道实际发生了什么。LLM 也不知道。它只学会了操作噪音。因此我倾向于让代理接收清晰的上下文，并且任何临时收件箱都绑定到 run_id，从不松散放在那里。

简短但有用的检查清单：

• 每个重要阶段一个制品。
• 最终内容的单一写入。
• 没有编辑逻辑的发布者。
• 人类可读的最终证据。

保存多个草稿值得吗？

对于手动探索，值得。对于自主 cron，几乎不值得。增加完整的草稿会使可追溯性复杂化，并模糊官方制品是什么。

这在博客之外也适用吗？

是的，相当适用。它适用于回答工单、生成 changelog 或准备报告的代理。真正的模式不是"发布文章"；是以可验证的输出结束。

如果一个 job 失败，我首先会检查什么？

首先检查 publish-result.json。然后对比 plan.json 和 article.raw.md 以查看失败是执行问题还是设计问题。这听起来显而易见，但拥有那个顺序可以避免浪费时间，有时可以避免触碰已经工作良好的东西。