Architecture Guide

最好的 Agent 模式: 判断交给 Agent
执行交给程式/n8n

Agent 做决策与分流;固定工作流做稳定执行。 只有在需要判断或 Debug 时才介入——这才是可靠、可预期、成本可控的自动化。

Agent 判断“该走哪条路”→ 你的 Program/固定 n8n 把路跑完
例外、模糊、出错时,才让 Agent(或人)介入

运作方式

角色分工清楚,系统才稳、才省、才好维护。

1

Agent 判断

读懂输入、分类意图、决定下一步该呼叫哪条流程。

  • 理解讯息/文件/例外状况
  • 在规则之间做分流决策
  • 不确定时标记为“需人工”
2

Program/n8n 执行

固定、可重现、可监控的流程把事情做完。

  • 写入表单、发通知、同步系统
  • 失败可重试、步骤可追踪
  • 行为稳定,不靠“模型心情”
3

例外才介入

判断不足或出错时,Agent/人再出手。

  • 模糊输入需要二次判断
  • 结果异常需要 Debug
  • 你只处理真正的例外

为什么不是“全交给 Agent”?

AI 很强,但不该什么都自己做。分工才是生产级架构。

不推荐

Agent 从头做到尾

每一步都让模型自由发挥——看起来很“智能”,实际上很危险。

  • 同一任务结果忽好忽坏,难重现
  • Token 成本高,每一步都在“思考”
  • 出错难定位:不知卡在判断还是执行
  • 合规与审计困难,行为黑箱
Smato 推荐

判断/执行分离

Agent 管“想”;Program/n8n 管“做”——只在关键点动用 AI。

  • 固定步骤稳定、可测试、可重试
  • Token 用在刀口上,日常成本可控
  • 异常有边界:判断层 vs 执行层分开 Debug
  • 你只处理例外,其余全自动

什么时候才需要介入?

日常 80–95% 的流量应由固定流程吃掉;Agent 是“决策层与救火队”,不是流水线工人。

需要判断时

意图不明、规则冲突、多方案择一、客户语气敏感——交给 Agent 决策或标记人工。

需要 Debug 时

输出异常、字段对不上、下游失败——Agent 协助定位原因,或触发告警给你处理。

需要分流时

同一入口、不同后续:客服 FAQ、订单查询、投诉升级——Agent 选对 n8n 分支即可。

需要你出场时

高风险决策、合约谈判、罕见客诉——系统自动升级,你专心处理真正重要的事。

对你的实际好处

不是炫技架构,而是可落地的营运结果。

结果可预期

固定流程跑同一条路,品质稳定。

成本更可控

AI 只在判断点出动,Token 不乱烧。

好 Debug

哪一层出错一目了然,修得快。

你只处理例外

日常自动跑;关键时刻才找你。

举个例子

以 WhatsApp/Discord 客服为例

1

客户发来讯息

“我想改地址”/“营业到几点”/“投诉物流”——同一入口。

2

Agent 判断意图

FAQ → 标准回复流程;改地址 → 验证 + 更新单;投诉 → 升级人工。Agent 只做这一步决策。

3

n8n/固定程式执行

查库、写单、推通知、记 log——每一步可重试、可监控,不靠模型“记得去做”。

4

例外才介入

地址格式乱到无法解析、客户情绪升级、系统回传错误——Agent 协助 Debug 或通知你接手。

常见疑问

这样会不会比较慢?
多数情况更快:固定流程零“思考延迟”,只有判断节点才呼叫模型。整体延迟往往低于“每一步都问 LLM”。
一定要用 n8n 吗?
不一定。原则是“固定、可观测的执行层”——可以是 n8n、你的后端 API,或脚本。Smato 偏好 n8n,因为可视化、易改、好交付。
这跟“纯 Chatbot”差在哪?
Chatbot 多半停在对话;这套模式会真正改系统、跑流程、写资料。Agent 是大脑,n8n/程式是双手。

想用这套模式打造你的自动化?

告诉我们你最痛的 1–2 个流程,我们帮你拆:哪里该判断、哪里该固定执行、哪里才需要人。