当我刚开始接触LLMs时，我以为关键在于写出完美的提示词。给它足够的上下文——然后，砰的一下——它就应该能正常工作了，对吧？
并非如此。
很早我就意识到，我基本上是在对着一个高级 autocomplete 堆砌文字。输出内容看起来很聪明，但它什么都不懂。它不会规划、调整或推理。措辞上稍有改动，整个结果就会出错。
我们所欠缺的是结构。智能不仅仅在于给出答案，更在于这些答案是如何形成的，过程很重要。
这促使我们研究agentic AI模式，这些设计技巧能让LLMs多一些目的性。它们能让模型进行规划、反思、使用工具，甚至与其他Agent协作。这些模式帮助我们从脆弱、时灵时不灵的提示词，转变为真正能解决问题的方案。
以下是影响最大的五种模式，我会以实用的方式进行解释。
-
反思（Reflection）：教你的Agent自查工作
你有没有过这样的经历：问ChatGPT一个问题，读完答案后觉得，“这听起来不错……但总有点不对劲”？
这就是反思（Reflection）的用武之地。这是一个简单的技巧：让模型在最终确定输出之前，再检查一遍自己的成果。
基本流程：
-
提出问题。
-
让模型给出答案。
-
然后再次提示它：“这个答案完整吗？有没有遗漏什么？怎样才能更好？”
-
让它自行修改。
你不需要叠加模型或增加复杂度。你只是让它仔细检查自己的工作。说实话，仅此一点就能减少大量粗心的错误，尤其是在代码、摘要或任何细节密集型内容上。
可以把这想象成给你的模型一个暂停键和一面镜子。
-
工具使用（Tool Use）：不要期望模型无所不知
你的LLM并不知道你的数据库里有什么，也不知道你的文件内容，更不知道今天的新闻头条。这没关系——因为你可以让它自己去获取这些信息。
工具使用模式将模型与现实世界的工具连接起来。它不必再编造信息，而是可以查询向量数据库（vector DB）、在REPL中运行代码，或者调用外部API，比如Stripe、WolframAlpha，或是你的内部接口。
这种设置确实需要一些基础架构：函数调用（function-calling）、路由，可能还需要用到LangChain或Semantic Kernel之类的工具，但这些投入是值得的，你的Agent不再靠猜测，而是开始获取真实数据。
人们总以为LLMs天生就应该很聪明。但事实并非如此。不过，当它们能够使用合适的工具时，就会变得聪明得多。
-
ReAct：让模型在行动中思考
反思（Reflection）很好，工具（Tools）也很好。但当你让你的Agent在循环中思考和行动时，效果会更好。
这就是ReAct模式的核心：推理（Reasoning）+ 行动（Acting）。
模型不再一次性给出所有答案，而是逐步推理，并在了解更多信息后调整自己的行动。
示例：
-
目标：“找到用户最近的发票。”
-
步骤1：“查询支付数据库。”
-
步骤2：“嗯，结果已经过时了。最好让用户确认一下。”
-
步骤3：调整查询，重复操作。
这不仅仅是回应——这是在自主导航。要让ReAct模式生效，你需要三样东西：
-
工具（用于采取行动）
-
记忆（用于保留上下文）
-
推理循环（用于跟踪进度）
ReAct让你的Agent更具灵活性。它们不再拘泥于僵化的脚本，而是会仔细思考每一步，实时调整，并在出现新信息时及时调整方向。如果你想构建的东西不只是一个快速的一次性答案，那么这种模式正是你所需要的。
-
规划（Planning）：教你的Agent提前思考
LLMs在快速回答方面表现不错。但对于任何涉及多个步骤的任务呢？它们就力不从心了。
规划（Planning）正好能解决这个问题。
模型不会一次性回答所有问题，而是将目标分解为更小、更易处理的任务。
假设有人问：“帮我推出一款产品。”Agent可能会这样回应：
-
确定目标受众
-
设计着陆页
-
设置电子邮件营销活动
-
起草公告文案
然后它会一步一步地处理每个部分。
你可以将这一点融入你的提示词中，或者让模型自己制定计划。如果你将计划存储在某个地方，以便Agent之后能从上次中断的地方继续，那就更好了。
规划（Planning）能让你的Agent从一个被动的助手转变为主动的行动者。对于工作流程以及任何需要多个步骤的任务，都适合使用这种模式。
-
多Agent（Multi-Agent）：让一个团队协同工作
既然可以让一整个团队协同工作，何必只依赖一个Agent呢？
多Agent（Multi-Agent）设置会给不同的Agent分配不同的角色，每个Agent负责解决问题的一部分。它们会协作——有时甚至会争论——以得出更好的解决方案。
典型设置：
-
研究员（Researcher）收集信息
-
规划师（Planner）列出步骤
-
程序员（Coder）编写代码
-
审核员（Reviewer）仔细检查所有内容
-
项目经理（PM）：确保一切顺利推进
这不一定要很复杂。即使是基础的协作方式也能奏效：
-
给每个Agent起个名字并分配工作。
-
让它们通过一个控制器相互发送信息。
-
观察它们如何迭代、评判和完善。
当它们产生分歧时，奇妙的事情就会发生，这时你会获得更深刻的见解和更深入的思考。
想试试吗？这里有个简单的起点
假设你正在构建一个研究助手。以下是一个实用的设置，能将这些模式付诸实践：
- 从规划（Planning）开始
提示词：“在回答前，将这项研究任务分解为清晰的步骤。”
示例：“1. 定义关键词，2. 搜索最新论文，3. 总结研究结果。”
- 使用工具（Tool Use）
将其连接到搜索API或向量数据库（vector DB），这样它就能获取真实事实——而不是编造内容。
- 添加反思（Reflection）
每次回答后，提示：“有什么遗漏？什么可以更清晰？”然后重新生成。
- 用ReAct模式包装
让Agent在步骤之间思考。“结果看起来不够深入——用新术语再试一次。”然后再次行动。
- 扩展到多Agent（Multi-Agent）（可选）
一个Agent负责撰写，另一个负责评判。
它们交流、争论，输出结果会越来越好。
就是这样，你已经有了一个能运行的最小可行产品（MVP）。不需要复杂的框架，只需要巧妙的提示词、基础的粘合代码和清晰的角色划分。你会惊讶地发现，自己对LLM的信心会提升很多。
总结
智能化设计并非要让模型变得更智能，而是关于设计更好的系统——能够处理复杂性、在过程中适应变化，且不会在遇到第一个意外输入时就崩溃的系统。
这些模式帮助我不再将LLMs视为魔法盒子，而是开始将它们看作更大流程中不够完善的组件。它们并不完美，但只要你赋予它们结构，它们就会拥有强大的能力。因为真正的智能，在于你在模型周围构建的框架结构，而不仅仅存在于模型本身。
智能存在于设计中，而不仅仅是模型里。这既令人沮丧，又让人释然。
