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

我花了两个月 vibe coding 搞了个 OpenHive——自己版的 OpenClaw——就想看看"agent as feature"这套东西放到一个人的工作流里，到底能跑多远。

一路迭代到 v4，大概 90% 的功能都通了。直到有天下午，我的 Loggly 监控 agent 打出一行日志："I am now going to query loggly API to check errors."我从来没让它输出这句话。改 prompt 也没用，怎么都压不掉。

那一刻我把 repo 归档了。

为什么一开始觉得能成

三月份我写了 Agent as Feature 那篇，算是用文字理思路——讨论用 reasoning agent 替代 deterministic controller。我当时觉得这个 pattern 是成立的，现在还是这么觉得。但"觉得成立"和"把唯一工程师的两个月 all in 进去"是两码事，我想亲手踩一遍坑。

我给自己画的饼是这样的：一人公司嘛，没精力写维护传统自动化。我需要的是一群能接住目标、自己想辙、自己干活的同事——包括那些我压根没想到要交代的部分。要的是 agent，不是 script；是推理，不是 if-else 分支。

于是动手了。两个月，四个版本。repo 公开且已归档。不是周末随手糊的玩具，是一次认真尝试。

到底哪里崩了

崩的方式跟我预想的完全不一样。

代码大部分时候是对的。Loggly 监控会查 API、检测错误、发告警，活儿确实干了。但它还会时不时给自己加戏——不管 prompt 怎么写，它都会往结构化输出里塞一段"自我解说"，好像每次 poll 之前还得发个新闻通稿。

这不是 bug。bug 是能 patch 的。问题出在模型跑到一个我没封死的角落，做了件它觉得挺合理的事。常规手段我都试了：system prompt 写得更狠、加 explicit negative rules、给 few-shot examples 演示我想要的"安静干活"行为。每次微调能压下去一点症状，同时把其他部分拖慢。写到最后变成了规则套规则。

脑子里反复冒出一句话：这哪是工程，这是在求菩萨。

这就是信号。如果你的系统和凌晨两点的 oncall 之间只靠"感觉应该没问题"撑着，那你根本没有系统。

确定性的取舍

这件事我进去之前没想明白。

任何系统都有 non-deterministic 的地方——用户输入、网络状况、真实世界本身。工程问题从来不是"怎么消灭不确定性"，而是：不确定性放在哪？有多少 control flow 要从它身上过？

OpenHive 把 LLM 放在了编排层。每一个路由决策、每一次"现在该不该告警"、每一个状态检查、每一次 agent 之间的交接，全部过模型。non-determinism 没有被关进笼子——它就是控制平面本身。

N8N 的做法刚好反过来。控制平面是确定性的：节点、连线、重试、定时器、分支逻辑。LLM 只是这个平面里的可选单元，每个只管一件有边界的事——分类这条消息、抽取这些字段、总结这段对话、判断这一件事。LLM 的输出先经过校验，再喂给下一步确定性逻辑。

同样的材料，排列方式反过来，failure surface 完全不同。

取舍很清楚：你在主干道上放弃 LLM 的一部分灵活性，换来的是 debuggability、重试机制、明确的错误路径、可审计的状态——这些全部白送。对一人公司来说，这笔账根本不用算。

Prompt 不能 deterministically compose，这不是写更好的 prompt 能解决的。问题出在 LLM 放错了位置。

15 分钟重建

同一个 Loggly 监控，搬到 N8N 里：cron trigger、一个 HTTP request 节点指向 Loggly API、filter 节点、notification 节点。完事。

我不用自己写的东西：重试逻辑、错误处理、追踪"告警是不是已经发过"的 state machine、半夜出问题的时候我真愿意盯着看的 dashboard——全部开箱即用。

公平的对比不是"N8N 吊打 OpenClaw"。而是面对这类问题，15 分钟的纯确定性节点，赢了两个月的"求 LLM behaving like deterministic system"。而"这类问题"恰好覆盖了一人公司绝大多数真正想自动化的场景。

"等模型变强了不就行了"

最常见的反驳：模型指令遵循能力会越来越强，到时候多余日志行的问题自然就没了。

不会的。

那行多余日志不是"不听话"。模型没有拒绝任何指令。它只是在一个我没封死的空白地带，用它觉得合理的方式填了个空。更强的 instruction following 意味着模型会更严格地遵守我写出来的 spec——但不代表它会在我忘记锁死的地方停止自由发挥。问题不在能力，在于 spec 永远是不完整的，而一个跑在控制流里的模型，会按自己的理解去填每一个你没说清楚的缝隙。

还有一个更现实的理由。把两个月赌在"模型会变好"上，本身就是我在避免的那种 failure mode。这里的核心论点是机会成本，不是技术悲观。如果你有 ML engineering 团队、有预算投 guardrails、structured output 和 evals，那就去做。大规模 agent orchestration 是真的，我也真心希望它跑通。但那不是我的处境。如果你在读一篇一人博客，大概率也不是你的。

我还是想让 agent 干什么

这不是"从此不用 AI 了"。AI 我留着，只是把它挪进了确定性骨架里面。

我还在追的 pattern 是这样的：Discord 聊天触发器把自然语言消息丢给 LLM，LLM 做 intent classification、抽取参数，然后用 structured parameters 路由到对应的 N8N workflow。LLM 的角色是 parser、classifier、fuzzy matcher——负责把人类说的话翻译成 workflow 能吃的东西。N8N 负责执行。LLM 永远不碰控制流。

这个 pattern 我还没完全跑通。如果你在确定性 workflow engine 上做过干净的自然语言触发方案，真心希望能交流一下。

我现在用的判断标准

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

先搭确定性骨架。LLM 只处理模糊的部分。千万别反过来。

路由、状态管理、调度、重试、错误路径——这些天生就是确定性的。硬塞 LLM 进去，你会花好几个月试图让一个概率系统表现得像确定性系统。分类、生成、语义匹配、自然语言解析——这些才是真正模糊的领域。LLM 在这里是正确选择，但要放在有 typed input 和 validated output 的单元格里。

我现在拿来检验自己的标准：如果发现自己在每个 LLM 步骤外面都包了一层 validation logic，那本质上就是在绕大弯子手写一个 workflow engine。那就直接用 workflow engine。

那两个月不是浪费，是学费。现在我清楚 agent-as-orchestrator 这个 pattern 在一人运营下会在哪里断掉，也知道了如果再试一次需要什么条件：一支 ML engineering 团队、guardrails 预算、以及一套至少和 agent 本身一样认真设计的 evals 体系。

归档了，又重建了。比再花两个月撞墙便宜得多。