同一个任务、同样的输入，跑两次，你的AI智能体走的是同一条路吗？如果答案是不确定，那这篇讲的取舍就跟你有关。
现在每个带AI功能的产品都说自己在"做智能体"。AWFlow也有智能体：你可以创建它们、给它们技能、和它们对话、让它们替你跑事情。但在底层，它们跑在工作流上。为什么做这个选择，以及它在代码里长什么样，值得说清楚。
纯智能体的问题在哪
纯智能体是一个循环：模型看当前状态，挑下一个动作，观察结果，再重复。每一步都在运行时决定。它觉得自己做完了就停。下一次运行，路径可能完全不同。
这种灵活性正是它的意义，也正是它的麻烦：
- 每次路径都不一样。同样的任务、同样的输入，每次都是一份新计划。
- 难调试。出问题时，你只能读一份对话记录，没法指着某一步说"就是这里"。
- 不敢无人值守。你敢把它排在凌晨三点、没人盯着跑吗？
- 每一步都要调一次模型，包括那些根本不需要思考的步骤，比如"打开页面""追加一行"。
工作流给的是什么
工作流是一张能读懂的图：一个触发器、若干步骤、一个输出。
- 同样的输入，同样的路径。它在构造上就是确定性的。
- 每次运行都记录每一步的输入和输出，失败时能直接指向某一个框。
- 可以放心排期，因为它只做图上画出来的事。
把两者摆在一起，工作流在可预测性、可调试性、成本和无人值守上占优。智能体只赢一件事：处理没人画过框的那种情况。
这不太像在两种东西之间做选择，更像拧一个旋钮。一端是图决定一切，另一端是模型决定一切。全交给智能体能应对意外，但每一步都是新计划、都要调模型。
所以有用的问题不是"工作流还是智能体"，而是各自该放在哪。
确定性的骨架，AI放在槽位里
答案可以压成一句话：图决定下一步发生什么，模型从不选路径。
在AWFlow里，工作流是骨架。举个小例子：每天早上检查一个页面，只在有紧急情况时通知你。
它按计划启动。触发器是画出来的，所以你清楚它什么时候跑，不会因为某个模型"想跑了"而醒来。
它读取页面。打开页面、读出文本不需要判断，一个普通节点就能做，每次都一样，不消耗模型调用。
AI步骤只决定一个值。这是需要判断的槽位：模型读一段杂乱文本，返回一个值——"紧急"或"不紧急"。
图决定接下来走哪条路。一个If节点看这个值，然后选分支。模型从不选择下一个框是哪个。
你只在事情重要时收到消息。运行在一个地方结束，逐步记录。出错了，你指向某个框就行。
你得到的是：需要判断的地方有模型的判断，其余地方有流程图的确定性，而且只为需要判断的步骤付模型调用的钱。同样的思路贯穿整个引擎。当助手用小尺寸本地模型生成工作流、而模型把图结构弄错时（比如缺了触发器、连了悬空的边），我们在代码里修，而不是让模型再试一次。
连智能体本身也是工作流
当你给一个智能体设定例行动作，比如"每天早上检查这个页面，告诉我改了什么"，AWFlow不会偷偷起一个带自己调度器的智能体循环。它构建一个普通工作流：一个已有的触发器，后面接一个"运行智能体"节点。
"运行智能体"节点把任务交给你的某个智能体（或内置助手Aria）。智能体用它自己的模型、指令、记忆、技能和规则。回复出来，交给下一步。答案保存为一段可以打开、可以继续的对话。
因为例行动作就是一个工作流，它自动获得引擎已有的一切：排期，包括补跑；运行历史，和其他工作流一样；在画布上编辑，没有隐藏的智能体循环，没有你打不开、改不了的东西。
我们没有为智能体另建一套运行时，而是复用了那套确定性的。
没人看着的时候，智能体不即兴发挥
智能体有规则：每类动作分为允许、先问、禁止。在对话里，"先问"会弹出审批卡片，你点一下。但在后台例行动作里，没有人可以点。
所以在后台运行中，标记为"先问"的动作会被拒绝，而不是被猜着执行，并列入该智能体的活动记录，等你之后处理。即使它很聪明，也依然可预测。
一条经验法则
先问自己：结果必须每次都一样吗？
需要判断、输入是杂乱文本或网页、猜错代价低或有人复核——这些情况用AI步骤。按我们的经验，大多数真实的自动化大部分属于第一类，中间夹着一两次判断调用。把第一类建模成图，把AI恰好放进那一两个槽位里。
没人在场的时候，不猜。
这个想法最小的版本，就是一个只有一个AI槽位的工作流：读页面，让本地模型总结，展示结果。AI步骤周围的一切都是画出来的。
热门跟贴