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

**Summary:** 我花两个月构建 OpenHive，也就是自己的 OpenClaw，想为一人公司探索 Agent as Feature。它做到 v4，90% 可用，却仍会输出我没要求的日志。我用 N8N 花 15 分钟重建了同一个监控器。这里是我对 LLM 适合位置的复盘。

- Canonical: https://markhuang.ai/zh/blog/the-determinism-trade
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-04-21
- Section: AI 与 LLM
- Tags: AI 智能体, Agentic AI, n8n, 智能体编排, 氛围编程, 经验
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一位架构师面对从概率性闪烁过渡到确定性晶格的全息网络](https://cdn.markhuang.ai/blog/the-determinism-trade/hero.webp)

*确定性的取舍*

我花了两个月 vibe coding 搞了个 [OpenHive](https://github.com/Z-M-Huang/openhive)——自己版的 [OpenClaw](https://github.com/openclaw/openclaw)——就想看看"agent as feature"这套东西放到一个人的工作流里，到底能跑多远。

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

那一刻我把 repo 归档了。

## 为什么一开始觉得能成

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

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

于是动手了。两个月，四个版本。repo [公开且已归档](https://github.com/Z-M-Huang/openhive)。不是周末随手糊的玩具，是一次认真尝试。

## 到底哪里崩了

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

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

![一排机器人安静工作，其中一个向空中吐出一条琥珀色文字带](https://cdn.markhuang.ai/blog/the-determinism-trade/stray-log-line.webp)

*那一行多出来的日志*

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

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

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

## 确定性的取舍

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

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

![分屏图：一边是概率云包着确定性方块，另一边是确定性晶格包着有界概率气泡](https://cdn.markhuang.ai/blog/the-determinism-trade/orchestration-inversion.webp)

*编排反转*

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 节点。完事。

![工作台上四个小型玻璃与黄铜机器由一条干净琥珀色光线连接，背景里复杂旧机器被关掉推开](https://cdn.markhuang.ai/blog/the-determinism-trade/n8n-rebuild.webp)

*15 分钟重建*

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

> **Info:**
>
> 说实话，Loggly 的付费计划本身就自带告警功能，这个 case 我直接升级套餐也行。但我还是重建了一遍，因为我真正想要的不是一个 Loggly 监控，而是下一个自动化、再下一个自动化的模板。

公平的对比不是"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 上做过干净的自然语言触发方案，真心希望能交流一下。

## 我现在用的判断标准

![琥珀色脚手架在靛蓝天空下升起，小型发光概率雾团被放在脚手架特定格子里](https://cdn.markhuang.ai/blog/the-determinism-trade/heuristic-gate.webp)

*先搭确定性脚手架*

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

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

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

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

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

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