最近在使用Langgraph编写一个Agent，其中涉及了大量的标准化内容和规则条件。一开始想使用workflow来标准化操作流程，保证整个系统的稳定性，却发现单一workflow难以应对用户的各种需求。于是需要增加agent自由度，采用react架构将系统的自由度放权给语言模型，但是这也会导致各类规则全部写进prompt，模型的注意力不集中，处理准确率下降。于是产生一些思考，分析一下面对各种情况时，workflow和react的权衡和特点。
1.Workflow
简单一句话来说Workflow 是将人类的经验代码化，并利用 LLM 的认知能力作为"引擎"来驱动每一步的执行，从而在保证灵活性的同时，实现了工程上的稳定性和可控性。相当于你在手把手带着一个呆瓜实习生做项目，它的执行力很强，但是没有对项目的思考。
预定义路径：开发者通常会设计好类似于流程图的结构。Agent 不再是漫无目的地尝试，而是沿着既定的流程图行进。
降低幻觉：通过限制 LLM 在每一步的行动范围，强制其专注于当前的小任务，从而显著降低模型的幻觉概率。
结果可预测：相比于完全自主的 Agent，基于 Workflow 的系统输出结果更加稳定，更符合对稳定输出和可靠性的要求。
2.ReAct
react架构基本上是完全把问题的解决流程交给了模型，让模型去选择合适的工具，达成需要的目标。可以说这样架构的最大优势是灵活性，无论你给他一个怎样奇怪的问题，他都能接住，但是至于回答是不是你想要的，那就不一定了。可以类比成一个你把项目交给了一个低智商实习生，他有一些自己的思考，但不多。对于简单问题能处理的较好，但对于复杂问题基本没有解决能力。
ReAct 的灵魂在于它定义了一个标准的"三步走"循环，直到问题解决：
1.Thought (思考)：
模型开启"内心独白"（Internal Monologue）。它会分析当前的情况，决定下一步该做什么。
例如："用户想知道现在的天气，我需要先查找用户的所在地，然后查询天气 API。"
2.Action (行动)：
基于刚才的思考，模型生成具体的工具调用指令（JSON 或特定的函数格式）。
例如：调用工具 GetLocation() 或 Search(query="Beijing weather")。
3.Observation (观察)：
这是工具执行后返回的真实结果。模型把这个结果"看"在眼里，作为新的上下文。
例如：工具返回字符串 "Beijing, Sunny, 25°C"。
3.What we need?
"宏观稳定，微观灵活"
对一个面对用户的项目来说，最重要的是保持输出稳定，解决95%的case，最常处理的任务需要保持稳定。对于另外5%的case，可能会有一些需求在我们的预料之外，那么就要有react来保证灵活的处理模式。无论用户有怎样的query，我们都要能接住，保证用户的体验。
对于外部函数的功能细分往往会带来更加稳定的智能体执行效果，设想一个函数包含很多的参数和逻辑，大模型在选择函数和生成的参数时出错的概率自然会变大。
所以比较理想的架构是router架构，有一个router去管理整个任务的进程，向一个个子节点发送请求。子节点在处理时，使用workflow，保证处理的效果和质量。这样的设计，能让整个智能体有更高的自由度，同时保证在预设任务时有很好的稳定性。