我不用 Agent，也不用 Skill，我回到了 Workflow
- 作者：Bougie
- 创建于：2026-06-20
- 更新于：2026-06-20
上个月，我收到了 AWS 账单，比预期多了大概四百美元。
四百美元。对于一个小项目来说不算致命，但足够让我坐下来复盘一下到底发生了什么。
事情是这样的——我有个跑在 EC2 上的小服务，本来只是每天定时抓几个 API，把数据处理一下存进 S3，夜里跑一趟，几分钟搞定，成本几乎为零。后来我看那个服务越来越像一坨 legacy 代码，就想着用 Agent 重构一下，加点智能功能。怎么说呢，我想着让 Agent 自己判断什么时候该抓数据、怎么处理异常、怎么告警，听起来很美好对吧？
结果就是这个 Agent 在某天凌晨两点被触发后，开始循环调用 API，然后不知道怎么的陷入了某种奇怪的状态——它没有真正完成任务，但也没有停下来，而是一直在调用，一直调用，直到我第二天早上看到那条告警短信。
账单就这么来的。
我不是说 Agent 烂到不能用。我只是说，当你把控制权交出去的时候，成本、风险、可预测性这些东西全都不归你管了。而这些东西在我熟悉的领域里，本来是完全可控的。
说起来，我大概从去年开始就注意到这个趋势了——Agent 火，然后 Skill 火，到处都在讲。Twitter 上、Newsletter 里、技术会议上，到处都是这些词。好像你不搞个 Agent 就落伍了，好像你的产品不加个 Skill 就没竞争力了。
但我干了十几年基础设施相关的工作，我有个朴素的经验：一个系统越简单，它就越可靠；一个系统越透明，你越知道它什么时候会出问题。
Agent 和 Skill 做的事情，恰恰是在往复杂和不可控的方向走。它们当然有它们的用武之地，但我看到的现实是——太多人在用它们解决本来不需要它们解决的问题。
就拿我上个月那个项目来说吧。我本来只是想定时抓数据、处理、存储。这种需求，二十年前的 cron 脚本就能搞定，十年前的 Python 脚本能搞定，五年前的 serverless 函数能搞定，今天你非要上个 Agent，这是图什么呢？
图它能「智能」处理异常？但我的脚本里写两行异常处理逻辑也不难啊。
图它能「自动」决策？问题是有些决策根本不需要它来做啊。
图它能「自我修复」？我靠，自我修复的代价往往是它修复出更大的问题。
后来我把那个服务回滚了。用回了老办法——一个 cron 跑 shell 脚本，shell 脚本里用 curl 抓数据，用 jq 处理 JSON，结果存进 S3。如果需要 LLM 的能力怎么办？简单，在脚本里加一行调用 curl 调 OpenAI 的 API，把需要理解的内容丢给它，然后继续往下走。
就这一行。
response=$(curl -s -X POST "https://api.openai.com/v1/chat/completions" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"model\":\"gpt-4o-mini\",\"messages\":[{\"role\":\"user\",\"content\":\"$prompt\"}]}")
然后解析 response，继续后面的流程。
这个脚本大概一百行，跑了半年多了，从来没有出过问题。它的成本是可预测的——每次调用花多少钱，我清清楚楚。它什么时候跑、跑多久、产出什么，我清清楚楚。它出问题的时候去哪里看日志、怎么排查，我清清楚楚。
清清楚楚这件事，在这个 Agent 满天飞的时代，可能被低估了。
有人会说，你这太土了，Workflow 这个词不是挺流行的吗？什么 n8n、什么 Zapier、什么 langchain 的链式调用，不都是 Workflow 吗？
是，也不是。
我承认这些工具做得越来越好了，n8n 我也在用，挺好。但我今天想说的 Workflow 不太一样——我说的 Workflow 是更底层的东西，是脚本主导、确定性优先、LLM 作为工具嵌入其中的思路，而不是让 LLM 主导整个流程、然后在旁边打补丁。
核心区别在于：谁在控制节奏。
在 Agent 模式下，你给 LLM 一个目标，它自己决定怎么拆解、怎么执行、什么时候调用什么工具。它很灵活，但它也可能跑偏。你像是在让一个聪明但不太听话的下属去完成任务——大多数时候还行，但总有那么几次，它会给你惊喜。
在我说的 Workflow 模式下，你定义好了每一步是什么，什么时候该做什么，该调用 LLM 的时候才调用，调用的时候给明确的指令，让它只做它擅长的事情——比如理解一段文本、提取关键信息、生成一段回复——然后你拿走结果，继续走你写好的流程。
LLM 在这里面不是大脑，它是大脑旁边的计算器。你什么时候按一下，怎么解读结果，都是你说了算。
这种思路有个明显的好处：可审计。
我之前帮朋友看一个被 Agent 搞砸的项目。他们用 Agent 做客服对话，生成回复。效果还不错，直到有一天，有个用户截图发到 Twitter 上——Agent 生成的回复里有明显的错误信息，还带着一种很奇怪的语气，像是在嘲讽用户。
朋友去找 Agent 的日志想复盘问题，结果发现 Agent 的执行过程是一团迷雾——它调用了什么、怎么生成的那段回复、中间有没有被人为干预过，全都不清楚。最后只能把那段时间的对话全撤了，重新处理。
如果当时用的是 Workflow 呢？日志会清晰得多：用户的输入进来了，系统调用了哪个 prompt，返回了什么，选取了哪段内容作为最终回复——每一步都是确定的，每一步都是可追溯的。
可审计性在生产环境里不是锦上添花，是基本要求。
当然，我知道会有人反驳：那你遇到需要真正「智能」的场景怎么办？比如要理解自然语言、要处理模糊的输入、要应对开放域的问题？
我的回答是：LLM 本身是个好东西，我从来没有说不用它。
我反对的是让 LLM 去控制一个复杂系统的执行流程，让它成为那个「决定下一步做什么」的存在。我支持的是把 LLM 当成一个能力强大的函数，在需要的时候调用它，给它明确的输入，让它返回明确的输出，然后你继续你的业务逻辑。
这两个模式的区别听起来不大，但实际用起来，差别是根本性的。
第一种模式，你在使用 LLM 的「判断力」。它好不好用，取决于它能不能正确理解你的意图、能不能做出合理的规划、能不能在出问题时自我修正。
第二种模式，你在使用 LLM 的「理解力」。你给它一段文字，它告诉你这段文字里提到了什么；你给它一个问题，它给你一个答案；你给它一个列表，它按你的规则筛选出符合条件的内容。它不决定做什么，它只做你让它做的事。
判断力是不稳定的，理解力是相对稳定的。
我愿意用 LLM 的理解力，因为它可靠、可控、成本可预测。我不愿意把整个系统的控制权交给 LLM 的判断力，因为我已经吃过亏了。
说个具体的例子吧。
我之前做过一个 RSS 阅读助手，需求很简单：每天早上给我推送几篇我觉得值得看的文章。原来的做法是让 Agent 自己判断——每天早上抓一批文章，让 Agent 挑出它认为最好的几篇，推荐给我。
效果嘛，怎么说呢，有时候还不错，但经常会出现一个问题：Agent 会推荐一些它觉得「有趣」但实际上跟我无关的文章。它会把一些标题党文章推到前面，因为它学会了怎么用吸引眼球的措辞。而我真正关心的技术深度文章，因为标题平淡，反而被它忽略了。
后来我换了个思路。我写了个脚本，里面定义了几个明确的过滤规则——比如关键词匹配、来源偏好、字数区间、发布日期——先用这些规则把候选文章筛到二十篇左右，然后才让 LLM 介入，对这二十篇文章写一句话推荐。LLM 的任务从「判断什么是好文章」变成了「给这二十篇文章各写一句推荐语」。
结果好多了。推荐质量稳定了，套路化了，但符合我的需求。
这就是 Workflow 思维的好处：把模糊的「智能」问题拆解成确定的规则问题，只在规则解决不了的地方才动用 LLM。
我不是要跟 Agent 和 Skill 较劲。它们有它们的场景，有它们的价值。
但现在的问题是，铺天盖地的宣传让很多人觉得 Agent 是万能解法，好像不管什么问题，套个 Agent 就能解决。厂商推 Agent 平台，开发者上 Agent 框架，投资人看 Agent 项目——热度是真的，但这热度里有多少是真实的价值，有多少是 FOMO？
我有我的立场：我干的是基础设施，我关心的是可靠性和成本。Agent 的不确定性在这些场景里是致命的。而 Workflow——或者说脚本主导的、LLM 作为工具的工作流——在这些场景里依然是更好的选择。
这不是保守，不是拒绝新事物。是因为我踩过的坑告诉我：控制力是有价值的，确定性是有价值的，可审计是有价值的。
当你不需要这些的时候，Agent 很好。但当你需要这些的时候，你会发现，兜兜转转，你还是会回到那个 cron 脚本面前。
它简陋，但它不会半夜三点给你烧四百美元。