Agent学习笔记01-Prompt App、Workflow、Agent、Agent System 的区别

上一篇文章，我们讲了LLM擅长和不擅长的地方，那么接下来，我们就要讲讲，如何把LLM用到实际的工程中去。在实际的工程中，我们通常会用到Prompt App、Workflow、Agent、Agent System，那么它们之间有什么区别呢？

很多人学 Agent，最容易混淆的就是概念层级。

你会经常看到几种说法混在一起：有人把“接了几个工具的聊天机器人”叫 Agent，有人把“多了几步流程编排”的系统叫 Agent，还有人看到模型会自己选工具、会自己继续搜，就觉得已经进入了 Agent System。表面看这些说法都沾点边，但如果一开始不把边界拆开，后面越学越容易乱。

先记住一句话

Prompt App 解决的是“让模型回答”，Workflow 解决的是“让流程执行”，Agent 解决的是“让系统在过程中做动态决策”，Agent System 解决的则是“让这种动态决策真正变成可运行、可恢复、可评估的工程系统”。

如果先把这句话记住，后面很多概念就不会缠在一起。

它们的差别，从来不只是“有没有用 LLM”，也不是“是不是调了工具”，而是系统到底把什么交给模型，什么交给代码，什么交给运行时来兜底。

Prompt App：模型能力的界面层

Prompt App 是最轻的一层。它通常只有一个非常直接的目标：把用户输入交给模型，再把模型输出返回给用户，程序本身只做少量包装。

翻译、总结、润色、问答、根据模板输出一段 JSON，这些都很像 Prompt App。它们的共同点不是任务简单，而是大多数情况下，一次调用就能把事情做完。系统不太需要保存复杂状态，也没有很长的执行链路，更谈不上中断恢复、阶段管理和过程追踪。

所以 Prompt App 的重点不在“任务有没有价值”，而在“系统是不是足够轻”。它更像一个让模型能力被使用的入口层，而不是一个真正承担任务编排的系统。

这也是为什么很多产品看起来很聪明，但工程上其实并不重。因为它只是把模型放到了用户面前，并没有把任务本身拆成一套持续运行的流程。

Workflow：把任务写成明确步骤

当一次调用不够，系统就会开始进入 Workflow。

这里最核心的变化，不是 prompt 变多了，而是任务开始被拆成若干明确步骤。输入先被读取，再被清洗，然后做分类、抽取、写库、通知，或者进入下一个节点。每一步的职责基本确定，顺序也基本确定，系统只是沿着预先设计好的路径向前走。

这时候，系统已经不再只是“问一句，答一句”，而是在执行一个流程。这个流程里可以用模型，也可以不用模型；可以有条件判断，但这些条件大多是开发者提前写好的，而不是让模型在运行中自由决定。

Workflow 的价值，在于它把任务变得可控。步骤稳定，链路可预期，测试边界更清楚，出问题时也更容易定位。所以在真实工程里，很多看起来“像 Agent”的东西，实际上更适合被实现成 Workflow，因为问题本身并不需要太多动态决策。

一旦规则已经相对清楚，固定流程往往比让模型临场发挥更稳。

Agent：在流程里引入动态决策

Agent 和 Workflow 的真正分界点，不是工具数量，也不是调用轮数，而是系统有没有把“下一步怎么走”的部分决定权交给模型。

如果一个系统会在执行过程中根据当前状态决定接下来要不要继续搜索、该调哪个工具、是否补充信息、什么时候停止，或者是否把任务转给人工，那么它就开始有 Agent 的味道了。也就是说，系统不再完全沿着写死的路线前进，而是在某些节点上允许模型参与决策。

这件事听上去只是“多一点灵活”，但本质上是系统责任的变化。因为只要模型开始决定路径，执行结果就不再像固定流程那样容易预测。你得到的不是更长的 Workflow，而是一个带有不确定性的执行体。

所以 Agent 真正难的地方，不是让模型多调用几个工具，而是如何给这种动态决策加边界。什么状态能看，什么工具能用，什么时候必须停，失败后怎么办，什么结果需要人工复核，这些都要被设计出来。不然所谓 Agent，往往只是“能自己往下接着跑一会儿”的 demo。

很多系统会被误判成 Agent，就是因为它们表面上有模型决策，实际上没有清晰状态、没有明确边界、没有恢复机制。这种系统更准确地说，通常只是“带一点动态分支的流程”，还谈不上成熟 Agent。

Agent System：把 Agent 变成真正可运营的系统

如果说 Agent 解决的是“局部决策”，那么 Agent System 解决的就是“整个系统如何长期可靠地承载这种决策”。

到这一层，关心的重点是任务怎么启动、状态怎么保存、节点之间怎么流转、出错后怎么恢复、超时怎么处理、中断后能不能继续、人工在哪介入、日志和 trace 怎么留、效果如何评估。这些问题单独看都不酷，但它们决定了系统到底是原型，还是能上线、能维护、能演进的工程系统。

所以 Agent System 往往包含的不只是 LLM，还包含显式状态、工具层、路由规则、运行时、观测体系、评测方法，必要时还要加上审批和回滚机制。少了这些，系统可能依然能跑，但很难稳定跑，也很难在真实业务里持续迭代。

换句话说，Agent 更像“能力单元”，Agent System 才更像“工程系统”。前者回答的是“模型能不能这样做”，后者回答的是“如果它要一直这样做，我们靠什么保证它不失控、不失忆、不可排查”。

四者不是并列关系，而是升级关系

理解这四个概念时，一个常见误区是把它们当成横向分类，好像只是在不同路线里四选一。其实更准确的理解方式，是把它们看成一条逐步加深的层级。

Prompt App -> Workflow -> Agent -> Agent System

从左到右增加的，不只是功能，而是系统承担的复杂度。Prompt App 主要承接模型输出，Workflow 开始承接流程，Agent 开始承接局部自主性，Agent System 则承接稳定运行和持续治理。

因此，一个成熟系统内部完全可能同时包含这四层。某些环节只是 Prompt App，某些环节是固定 Workflow，只有少数高价值节点才做成 Agent，而整套外壳再由 Agent System 来管理。真正好的工程，通常不是“全都做成 Agent”，而是让不同层级各司其职。

用一个研究任务来体会区别

拿“做一份某行业研究总结”这个任务来看，四层的差别会很直观。

如果只是 Prompt App，你大概会直接输入主题，让模型生成一份总结。它可以很快给出结果，但结果依赖模型已有知识和当前上下文，系统本身几乎没有执行过程可言。

如果做成 Workflow，系统就会先检索资料，再抽取摘要，再合并观点，最后输出结论。步骤是提前规定好的，重点是稳定把流程跑完。

如果做成 Agent，系统就不一定沿固定顺序执行了。它可能会先判断应该搜哪几个方向，发现信息冲突后追加检索，看到证据不足时主动延长搜索，或者在某一步决定停止而不是继续扩展。这时候真正起作用的，是“基于中间状态做下一步判断”的能力。

而如果做成 Agent System，除了这些动态决策，还会有任务状态持久化、工具调用记录、失败重试、人工审核入口、评测样本、质量指标和过程回放。到了这一步，你拥有的就不只是一个“会做研究”的东西，而是一套“可以持续运营研究任务”的系统。

真正重要的问题：任务该停在哪一层

实战里最有价值的是判断一个任务该设计到哪一层。

如果你要开发一个应用，先问自己，这件事是不是一次模型调用就够了。如果答案是够，那通常先别上复杂系统，Prompt App 反而最合适。再问，这个任务能不能稳定拆成固定步骤。如果能，那 Workflow 往往已经足够。接着再问，中间是不是真的需要根据上下文动态调整路径。如果需要，才有必要考虑 Agent。最后还要问，这个东西是不是要长期运行，要可恢复、可审计、可评估、可持续优化。如果答案是要，那就不能只停在 Agent，而要按 Agent System 的标准去设计。

这套判断背后的核心原则其实很朴素：不要为了“更高级”而引入更高复杂度。

因为复杂度从来不是免费的。系统一旦从 Workflow 进入 Agent，你获得的是灵活性，同时也会付出调试更难、行为更不稳定、评估更麻烦、边界更难定义的代价。再从 Agent 进入 Agent System，又会增加状态管理、运行时控制、监控评测和异常恢复的工程负担。

所以成熟做法通常不是“能 Agent 化的都 Agent 化”，而是反过来思考：能写死的就写死，能规则化的就规则化，只有那些确实需要动态判断、并且动态判断能带来明显收益的节点，才值得交给 Agent。

最后

学这四个概念，不是为了给产品贴标签，而是为了训练一种系统判断力。

你以后看任何一个 AI 应用，都可以先问：它到底只是让模型回答，还是在执行流程？它的流程是固定的，还是会动态决策？这些决策有没有状态、边界和恢复机制？如果系统出错，团队能不能知道错在哪、怎么补救、怎么持续改进？

当你开始这样看问题时，你就不会再轻易把“能调工具的聊天机器人”当成 Agent，也不会把“会自己选下一步”的 demo 当成 Agent System。

概念一旦分清，后面学 Prompt、Tool Calling、State、Routing、Runtime、Evaluation，才会都落在正确的位置上。