1. 去年n8n之类的工作流工具很红，把任务拆

1. 去年n8n之类的工作流工具很红，把任务拆成节点、连好线，让AI按流程跑。这种方式省钱、稳定、可预期，但它只能做你预先定义好的事，条件一变流程就得重来。

2. 光谱的另一端，则是完全放手让Agent自由探索，什么都让LLM自己想办法。它可能最终摸索出跟你手动定义一样的方案，但可能花了好几倍的Token，而且下次做同样的事还是得重新摸索。

两种方式各有优缺点，固定流程无法适应变化，自由探索虽然弹性高，但如果没后续整理与固化，经验就很难真正沉淀成可重用资产。

所以实际上比较合理的做法是分层。

1. Agent：全部让LLM自己来你给它目标，它自己思考、规划、执行、反思，每一步都是LLM在跑。弹性最大，适合你还不确定流程的时候让它先跑一遍。但因为每一步都靠LLM探索和决策，Token用量自然比较高。

2. Skill：把做过的流程整理起来在我的工作流里，Skill比较像是从Agent探索过程中萃取出来的可重用模块。只是你把探索的结果固定下来了，让Agent不用每次重新摸索，所以Skill相比纯Agent，通常会更省token、也更稳定，但本质上仍然是agentic的做法。

3. Workflow：脚本为主，LLM为辅Workflow的重点是把流程的控制权从LLM拿回来。简单的情况可以直接用Script线性跑，Step 1Step 2Step 3按顺序执行完就结束；复杂一点的会用Dispatcher做调度，根据条件分流或平行处理。不管哪种，核心都是脚本在主导，只有真正需要语言理解的地方才call LLM。Token通常最省、速度通常最快、稳定性也通常最高；代价是它对预设边界外的变化适应力较弱，如果没做好容错设计，某一步失败就可能连带影响后续流程，不像Agent可以自己绕路。

三种类型就是一个光谱，左边是最大灵活性，右边是最大稳定性和效率。

我自己的做法是先手把手带Agent跑一遍看流程可不可行，确认可行就写成Skill固定下来，如果这个Skill每天都在用，而且有些过程不需要LLM判断，就再推成Workflow，把不需要判断的部分用脚本跑，节省token。