确定性的交易：为什么我用 15 分钟的 N8N 归档了自己的智能体框架

我花了两个月用 AI 边试边写 OpenHive，也就是我自己的 OpenClaw 版本，想看看“智能体即功能”对一个人的工作流到底能做什么。

它到了 v4，功能大约 90% 可用。然后有一天下午，我的 Loggly 监控器打出了一行日志：“我现在要查询 Loggly API 来检查错误。”我从来没让它输出这句话。怎么改提示词都停不下来。

那一刻，我把代码仓库归档了。

为什么我原本以为它会成功

我三月写过 智能体即功能，那是一篇边想边写的文章，讨论用推理智能体替换确定性控制器。我相信这个模式是真的。现在也信。但相信一个模式成立，和把自己这个唯一工程师的两个月押上去，是两回事。我想亲自撞一次。

我说服自己的理由是：作为一家一人公司，我没有精力去写和维护传统自动化。我需要的是一队能接住目标、自己想办法、自己执行的同事，包括那些我没想到要明确写出来的部分。我要的是智能体，不是脚本；推理，不是分支。

所以我做了。两个月，四个版本。代码仓库公开且已经归档。这不是周末随便做做，而是一次认真的尝试。

它实际坏在哪里

它失败的方式和我预想的不一样。

代码大多数时候是对的。Loggly 监控器会查询 API、检测错误、发送告警。它确实能完成工作。但它还会时不时地自我解说。不管我怎么写指令，它都会在结构化输出里宣布自己的意图，好像轮询 API 之前还要发新闻稿。

这不是缺陷。缺陷是可以修补的。我遇到的是模型在一个我没想到要钉死的角落里，做了一件它觉得合理的事。我试了常规手段：更严格的系统提示词、明确负向规则、几个我想要静默状态的少样本示例。每次修补都削掉一点症状，同时拖慢其他部分。我开始写关于规则的规则。

我反复想到一句话：这不是工程，这是在碰运气。

这就是信号。如果你系统和凌晨两点告警之间只隔着一点感觉，那你没有系统。

确定性的取舍

我一开始没理解的是这件事。

每个系统某处都有非确定性。用户输入、网络条件、现实世界本身。工程问题从来不是“如何消灭不确定性”，而是：我把它放在哪里？有多少控制流程要经过它？

OpenHive 把 LLM 放在编排层。每个路由决策，每个“现在是否发告警”，每个状态检查，每个智能体交接都经过模型。非确定性没有被包住。它就是控制平面。

N8N 则反过来。控制平面是确定性的：节点、连线、重试、定时器、分支逻辑。LLM 是这个平面里的可选单元，每个都只负责一个有边界的工作：给这条消息分类、抽取这些字段、总结这个线程、决定这一件事。LLM 输出先被验证，再进入下一步确定性步骤。

材料一样，排列反过来，失败的表现形式就完全不同了。

取舍是：你放弃 LLM 在脊梁骨位置的一部分灵活性，换来可调试性、重试、明确错误路径和可审计状态。对一人公司来说，这笔账没有悬念。

提示词不会确定性地组合。这不是更好的提示词能解决的事，而是 LLM 应该被放在哪里的问题。

15 分钟重建

同一个 Loggly 监控器，在 N8N 里是：cron 触发器、指向 Loggly API 的 HTTP 请求节点、过滤节点、通知节点。结束。

我不用写的东西：重试逻辑、错误处理器、追踪告警是否已经发过的状态机器、午夜出问题时我真正愿意看的仪表盘。这些都已经内置了。

诚实的比较不是“N8N 赢了 OpenClaw”。而是对这类问题来说，15 分钟普通确定性节点胜过两个月诱导 LLM 像确定性节点一样行动。而“这类问题”恰好覆盖了一人公司绝大多数真正想自动化的东西。

“等模型变好就行”

最明显的反驳是：模型会更严格地遵循指令，到时多余日志行问题会消失。

不会。

那行多余日志不是不服从。模型没有拒绝指令。它只是填补了我没想到要封住的空白，而且用的是它认为合理的方式。更强的指令遵循意味着模型更会遵循我写出来的规格。它不意味着模型在我忘记锁死的地方停止生成内容。问题不是能力，而是规格永远不完整，而一个跑控制流程的模型会继续按自己的感觉填空。

还有第二个更实际的理由。把两个月押在“模型会变好”上，本身就是我要避免的失败模式。这里的论点是机会成本，不是技术悲观。如果你有机器学习工程的人力，有意愿投资护栏、结构化输出、评估，那可以去做。大规模智能体编排是真的，我也希望它成功。但那不是我的处境。如果你在读一篇一人博客，很可能也不是你的处境。

我仍然想在哪里使用智能体

这不是反对 AI。我保留了 AI，只是把它移进确定性图谱里。

我还在追的模式是：Discord 聊天触发器把自然语言消息交给 LLM，LLM 判断意图、抽取参数，然后带着结构化参数路由到正确的 N8N 工作流。LLM 作为解析器、分类器、模糊匹配器，连接人类输入和工作流需要的东西。N8N 作为执行器。绝不让 LLM 作为控制器。

这个模式我还没完全做顺。如果你有一个在确定性工作流引擎上做自然语言触发器的干净做法，我真想听。

我现在用的判断标准

这篇文章如果只能带走一句话，就是：

先搭确定性脚手架。LLM 只处理模糊部分。不要反过来。

路由、状态、调度、重试、错误路径，本质上是确定性的。把 LLM 推进去，你会花几个月让一个概率性东西表现得像确定性系统。分类、生成、语义匹配、自然语言解析，才是真正模糊的部分。LLM 适合在这里使用，但要在类型化输入和已验证输出的单元里。

我现在给自己的测试是：如果我发现自己在每一个 LLM 步骤周围都加验证逻辑，我其实是在绕远路做工作流引擎。那就直接用工作流引擎。

那两个月不是浪费，是学费。我现在知道“智能体作为编排器”模式对一人运营会在哪里断，也知道如果再试一次需要什么：机器学习工程团队、护栏预算、以及至少和智能体一样认真设计的评估框架。

我把它归档了，又重建了它。比再花两个月继续撞墙便宜。