完整题目
请列举并简述AI Agent常见的几种行为模式或架构（如ReAct、CoT等）。
答案要点
- 能清晰区分推理模式（CoT/ToT）与行动模式（ReAct/Reflexion）的差异
- 准确描述ReAct的"Thought-Action-Observation"循环机制
- 说明不同架构的适用场景和 trade-off
- 提及Function Calling作为工程化落地的简化方案
核心分类：推理模式 vs 行动模式
一、纯推理模式（无外部交互）
- CoT（Chain-of-Thought）：通过"Let's think step by step"激发逐步推理，解决复杂数学/逻辑题，但无法获取外部信息
- ToT（Tree of Thoughts）：维护多条推理路径，用投票或评估函数选择最优分支，适合探索性问题（如创意写作、谜题）
二、推理+行动模式（Agent核心）
-
ReAct（Reasoning + Acting）：Thought → Action → Observation 循环
- Thought：分析当前状态、制定计划
- Action：调用工具（搜索、计算、API）
- Observation：接收结果，进入下一轮
- 优势：推理与行动交织，错误可及时修正
-
Reflexion：在ReAct基础上增加自我反思层，Agent评估行动结果并写入记忆，避免重复犯错
三、工程简化方案
- Function Calling：模型直接输出结构化工具调用参数，由外部系统执行，无需模型自循环，延迟更低、可控性更强，是目前主流落地方式
选型建议：复杂多步任务用ReAct/Reflexion， latency敏感场景用Function Calling + 预定义工作流。
换一种问法，检查是否真正理解
场景切入
假设你在做一个智能客服Agent，用户问“我的订单怎么还没到”，Agent需要先查订单状态，再决定要不要联系物流。你一般会用什么思路来编排这种“先想再动”的流程？
层层追问
我们让大模型解决复杂任务时，你怎么组织它的推理步骤？……如果不仅要推理，还要调用工具查数据呢？……那常见的把这些组合起来的模式有哪些，你能简单说说吗？
直球架构
请列举并简要说明AI Agent的几种常见行为模式或架构，比如ReAct、CoT这些，重点说清楚它们各自的核心机制和适用场景。
练习口述回答 · 约4分钟
- 一句话定位：Agent行为模式本质是模型与外部世界的互动策略
- 推理模式：CoT和ToT，适合纯思考场景，无外部交互
- 行动模式：ReAct和Reflexion，思考与行动交织，适合复杂任务
- 工程简化：Function Calling，低延迟可控的落地方式
- 取舍与总结：场景决定选型，组合使用是常态
这道题问的是[[Agent]]的行为模式，其实本质是在问：模型怎么跟外部世界互动，是纯靠推理，还是边想边动。我一般会把它分成两类，一类是纯推理模式，一类是推理加行动模式。
先说纯推理。最典型的就是 [[Chain-of-Thought]] 和 [[Tree-of-Thoughts]]。CoT 说白了就是让模型一步步推理，比如做数学题，你加一句“Let's think step by step”，效果就上来了。但它有个硬伤，它拿不到外部信息，完全靠模型内部知识，所以碰到需要查实时数据或者调用工具的场景，它就歇菜了。ToT 更进了一步，它维护多条推理路径，像一棵树，然后通过投票或者评估选最优分支，适合创意写作、解谜这类探索性问题。但本质上还是闭门造车，没有外部反馈。
接下来是真正的Agent核心，推理加行动模式。最经典的是 [[ReAct]]，它的循环是Thought、Action、Observation。模型先想，当前状态是什么，该干什么；然后去调用工具，比如搜索、计算、调API；拿到结果后观察，再进入下一轮思考。好处是推理和行动交织，错了能立刻纠正。举个例子，客服退款场景，用户问“我订单还没收到，但显示已签收”，ReAct 可以这样走：先想可能物流异常，然后调物流API查轨迹，观察到签收地址不对，再想可能是配送错误，接着调客服系统发起退款。整个过程是动态的。
在此基础上还有 [[Reflexion]]，它加了一层自我反思。Agent做完一轮后，会评估行动结果，把经验写进记忆，下次类似情况就不会犯同样的错。比如同样客服场景，Reflexion 会发现“上次查物流时忘了核对收货人姓名”，于是把“先核对收货人”作为经验存下来。不过代价是更慢、更复杂。
但现实落地中，我其实更倾向用 [[Function Calling]]，这是工程上的简化方案。模型不自己循环，而是直接输出结构化的工具调用参数，比如“search_order(order_id: 12345)”，由外部系统执行。这样延迟更低，可控性更强，出问题也好排查。很多主流框架都在走这条路。
所以选型上，我有个判断：复杂多步任务，比如需要反复推理和纠错的，用ReAct或Reflexion；对延迟敏感的场景，比如在线客服实时回复，用Function Calling加预定义工作流。真正上线时，往往是两者结合，比如用Function Calling做单步动作，用ReAct做高层规划。
这里有个延伸点值得注意：ReAct 的 Thought 部分其实高度依赖模型本身的推理能力，如果模型基础能力不行，Thought 就会变成瞎想，导致 Action 跑偏。所以我会把 [[System Prompt]] 的设计看得很重，怎么约束 Thought 的输出格式，怎么避免[[幻觉]]，这些都是上线前要反复调的东西。