第3章：Agent 认知架构全景

前两章回答了"Agent 是什么"和"什么时候该用 Agent"。这一章进入具体的架构设计：当你决定要构建一个 agentic system 时，有哪些架构模式可以选？它们各自适合什么场景？会在哪里失败？

一个关键前提：Agent 不一定是最合适的起点。Anthropic 在《Building Effective Agents》中明确建议，在考虑 Agent 之前，先看看五种 Workflow 模式能不能解决你的问题 [1]。所以这一章的组织方式是：先讲 Workflow 模式（3.1），再讲 Agent 认知架构（3.2），然后讲它们如何组合和演进（3.3），最后讲为什么 Agent 最终会变成一个系统工程问题（3.4）。

3.1 Anthropic 的五种 Workflow 模式：在上 Agent 之前先掌握这些

核心直觉

在让 LLM 自己做决策之前，先看看"你来安排流程、LLM 只负责填空"能走多远。大多数时候，走得比你想象的远。

为什么先讲 Workflow

因为 Anthropic 观察到的一个规律 [1]：

The most successful implementations weren't using complex frameworks or specialized libraries — instead, they were building with simple, composable patterns.

最成功的实现没有用复杂框架，而是用简单、可组合的模式。以下五种模式就是这些"简单模式"的系统化总结。

模式一：Prompt Chaining（顺序链）

机制：把任务拆成几个步骤，顺序执行。每一步的输出是下一步的输入。可以在步骤之间加程序化的检查（gate），不满足条件就提前终止或重试。

什么时候用 [1]：

This workflow is ideal for situations where the task can be easily and cleanly decomposed into fixed subtasks. The main goal is to trade off latency for higher accuracy, by making each LLM call an easier task.

任务能清晰地拆成固定子任务时就用它。每一步都更简单，所以准确率更高，代价是增加了一点延迟。

例子：先生成营销文案，再翻译成目标语言；先写大纲，检查大纲是否符合要求，再写全文。

工程权衡：这是最容易理解和调试的模式——出了问题你看中间步骤就知道哪一步错了。但灵活性最低：步骤是写死的，遇到新场景需要改代码。

模式二：Routing（路由分类）

机制：先对输入做分类，然后根据分类结果路由到不同的处理流程。每个流程可以有专门的 prompt 和工具。

什么时候用 [1]：

Routing works well for complex tasks where there are distinct categories that are better handled separately, and where classification can be handled accurately.

有明确的分类维度、不同类别需要不同处理时用它。

例子：客服系统把查询分为"通用咨询 / 退款请求 / 技术问题"，分别路由到不同处理逻辑；简单问题路由到小模型（便宜快），难问题路由到大模型（贵但准）。

工程权衡：核心风险在分类的准确率。如果分错了类，后续流程再完美也没用。好在分类是一个相对容易评估和优化的子问题——你可以用 LLM 做分类，也可以用传统的分类模型，甚至用正则和规则。

模式三：Parallelization（并行）

机制：多个 LLM 调用同时执行，结果由程序聚合。有两个变体：

• Sectioning（分段）：把任务拆成独立的子任务并行处理。比如写一篇报告时，三个 LLM 分别处理市场分析、技术评估、风险评估，最后合并。
• Voting（投票）：同一个任务跑多次，取多数意见或最佳结果。比如用三个 LLM 分别做代码审查，综合它们的发现。

什么时候用 [1]：

Parallelization is effective when the divided subtasks can be parallelized for speed, or when multiple perspectives or attempts are needed for higher confidence results.

子任务可以并行时用它加速，或者需要多视角提高置信度时用投票。

工程权衡：成本会线性增加（N 个并行 = N 倍 token 消耗），但延迟只取决于最慢的那个。适合对延迟敏感但对成本不那么敏感的场景。

模式四：Orchestrator-Workers（编排-工人）

机制：一个中央 LLM（编排者）分析任务，动态决定需要哪些子任务，把它们分配给 Worker LLM 执行，最后综合结果。

什么时候用 [1]：

This workflow is well-suited for complex tasks where you can't predict the subtasks needed. The key difference from parallelization is its flexibility — subtasks aren't pre-defined, but determined by the orchestrator based on the specific input.

关键区别在于：Parallelization 的子任务是预定义的，Orchestrator-Workers 的子任务是动态决定的。

例子：编程任务中，需要改哪些文件、每个文件怎么改，取决于具体的 bug；搜索任务中，需要查哪些数据源、查什么关键词，取决于用户的问题。

工程权衡：这个模式已经接近 Agent 了——编排者在做动态决策。但它仍然是 Workflow，因为整体流程（分析→分配→执行→综合）是预定义的。编排者只决定子任务的内容，不决定整个系统的控制流。

一个真实的教训：LangChain 团队在总结多 Agent 系统经验时提到 [2]，如果编排者给 Worker 的指令太简短（比如"研究半导体短缺"），Worker 很容易误解任务或重复劳动。这个例子本身未必能代表所有系统，但它清楚说明了一点：在 Orchestrator-Workers 模式里，子任务描述的具体程度会直接影响效果。

模式五：Evaluator-Optimizer（评估-优化循环）

机制：一个 LLM 生成输出，另一个 LLM 评估并给出反馈，循环迭代直到达标。

什么时候用 [1]：

This workflow is particularly effective when there are clear evaluation criteria, and when iterative refinement provides measurable value.

两个前提条件：有明确的评估标准，迭代改进能带来可衡量的提升。

一个架构细节值得注意：生成器和评估器可以是不同的模型实例、不同的 system prompt、甚至不同的模型。评估器可以拥有生成器没有的工具——比如代码生成场景中，生成器写代码，评估器可以运行代码并检查测试结果。

工程权衡：每一轮迭代都增加延迟和成本。你需要设置最大轮次来防止无限循环，还需要确保评估标准真的能区分好坏——如果评估器本身不靠谱，迭代只会在低质量之间来回摇摆。

五种模式的选择

这五种模式不是互斥的，生产系统常常组合使用。比如：一个 Router 把输入分到不同类别，简单类别用 Prompt Chaining，复杂类别用 Orchestrator-Workers，最后套一层 Evaluator-Optimizer 做质量检查。

只有当这五种模式都满足不了需求——任务的步骤数无法预测、工具选择需要动态判断、执行路径取决于中间结果——才考虑升级到真正的 Agent。

3.2 Agent 认知架构

核心直觉

当你决定把控制权交给 LLM 时，它怎么"思考"和"行动"就成了核心设计问题。不同的认知架构决定了 Agent 如何处理信息、做出决策和从错误中恢复。

ReAct：交替推理与行动

论文：Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023 [3]

机制：ReAct 的核心想法直截了当——让 LLM 交替进行推理（Thought）和行动（Action），每次行动后观察结果（Observation），再进入下一轮推理。

Thought: 用户问的是 2024 年奥运会在哪举办。我先搜索一下。
Action: search("2024 Olympics host city")
Observation: The 2024 Summer Olympics were held in Paris, France.
Thought: 找到了，巴黎。我可以直接回答了。
Action: finish("2024 年夏季奥运会在法国巴黎举办。")

为什么交替有效？论文的核心发现是：推理帮助模型"归纳、追踪和更新行动计划，并处理异常情况"；行动让模型"与外部信息源交互以获取额外信息" [3]。纯推理（CoT）的问题是模型只能依赖训练时的知识，容易产生幻觉；纯行动（Act-only）的问题是模型不会解释为什么采取某个行动，更容易走偏。ReAct 结合了两者的优势。

关键结果（PaLM-540B）[3]：

基准测试	ReAct	说明
HotpotQA	29.4 EM	多跳问答
FEVER	62.2 EM	事实验证
ALFWorld	70.9% 成功率	文本游戏（比纯行动高 34 个百分点）
WebShop	40.0% 成功率	网页购物（比纯行动高 10 个百分点）

论文还发现，最好的结果来自 ReAct + CoT 的组合——同时利用内部知识和外部检索。

生产中的失败模式：

ReAct 是最广泛使用的 Agent 架构，但在生产环境中有几个已知的痛点：

1. 幻觉工具调用。Agent 编造不存在的工具名，或者用真实工具但传入虚构的参数。一些工程分析和基准讨论都指出，很多重试其实没有带来新信息，而是在错误工具名、错误参数或错误策略上原地打转 [4]。

2. Token 爆炸。一旦进入长链条工具循环，prompt 会迅速膨胀。失败重试、冗长 observation 和重复思考都会把上下文越拖越长，最后开始影响模型对早期指令的记忆 [4]。

3. 循环卡死。Agent 在同一个错误上反复重试，不会换策略。LangGraph 的一个 GitHub issue（#6617）就讨论过这类问题，但要注意，这属于某个框架社区里暴露出来的工程痛点，不应直接泛化为"所有 ReAct 实现都不适合生产" [5]。

4. 静默推理错误。思维链推理出了错，但最终答案看起来很合理，没有触发任何报错。用户拿到一个自信但错误的回答。

工程权衡：ReAct 的优势是简单直接——一个循环就能处理很多任务。劣势是每一步都要调用大模型做推理，成本高、延迟高、且缺乏全局规划。它适合步骤较少（5 步以内）、需要与环境频繁交互的任务。对于需要长链条规划的复杂任务，Plan-and-Execute 通常更合适。

Plan-and-Execute：先规划后执行

这更像一种工程模式，而不是由某一篇论文单独定义的标准架构。 在今天的 Agent 实践里，Plan-and-Execute 通常指：先由 Planner 生成计划，再由 Executor 按计划执行；如果环境发生变化，再由 Replanner 调整后续步骤。LangChain 的 planning agents 文章把这类模式系统化整理了出来 [6]。

机制：把"想"和"做"分成两个阶段。第一阶段，一个 Planner LLM 生成完整的执行计划；第二阶段，Executor 逐步执行计划中的每一步。执行过程中可以有一个 Replanner，根据已完成步骤的结果调整剩余计划。

和 ReAct 的本质区别：ReAct 是"边想边做"——每一步都重新推理。Plan-and-Execute 是"先想好再做"——有一个全局视角。

如果一定要追学术脉络，它和 Wang 等人的 Plan-and-Solve Prompting 有相通之处：先显式规划，再进入执行阶段。但你这里看到的 planner / executor / replanner 三段式，更接近工程上常见的 agent pattern，而不是 Plan-and-Solve 论文本身的完整实现。

维度	ReAct	Plan-and-Execute
规划方式	每步即时推理	先生成全局计划
适合场景	步骤少、需要频繁与环境交互	步骤多、目标明确、可以提前规划
执行速度	慢（每步都调大模型）	快（执行阶段可以用小模型）
成本	高（每步都是完整推理）	更可控（规划一次，执行用便宜模型）
适应性	高（实时响应新信息）	中（需要通过 Replanner 调整）
可解释性	低（推理过程是即兴的）	高（计划可以在执行前审查）

有开发者总结 [7]：

The honest truth: nearly every production AI system uses a hybrid approach. "Pure" ReAct and "pure" agentic planning are mostly theoretical endpoints.

老实说，几乎每个生产级 AI 系统都在用混合方案。纯 ReAct 和纯 Plan-and-Execute 更多是理论上的两端。

Plan-and-Execute 的失败模式：

1. 计划过时。环境在执行过程中发生了变化，但计划是基于旧信息生成的。Replanner 能缓解这个问题，但增加延迟。
2. 过度规划。花太多 token 生成一个精致的计划，结果一开始执行就发现前提不成立。
3. 计划-执行鸿沟。Planner 生成的步骤描述对 Executor 来说太抽象或太模糊，导致执行偏差。

进阶变体：LLMCompiler。把计划表示为 DAG（有向无环图），每个节点标注工具、参数和依赖关系。没有依赖的步骤可以并行执行。这超越了顺序执行的限制，但实现复杂度也更高。

Reflexion：通过自我反思优化决策

论文：Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning", NeurIPS 2023 [8]

机制：Reflexion 的核心思路是：Agent 失败后不只是重试，而是先反思为什么失败，把反思结论存入记忆，下一次尝试时带上这些教训。

这不是更新模型权重——没有任何梯度回传。它是用自然语言做强化学习：反思文本就是"语言反馈信号"。

关键结果 [8]：

基准测试	基线	Reflexion	提升
HumanEval（Python）	80%（GPT-4）	91% pass@1	+11 个百分点
ALFWorld	基线	+22 个百分点	12 轮迭代学习
HotPotQA	基线	+20 个百分点

在 HumanEval 上，91% 的 pass@1 在当时是一个不小的突破。

和 Evaluator-Optimizer 模式的关系：两者都是"生成→评估→改进"的循环。区别在于 Reflexion 把反思结论存入跨轮次的记忆——它在多次尝试中"学习"；而 Evaluator-Optimizer 通常在单次生成周期内迭代。

一个已知局限：Reflexion 常常用同一个模型既做生成又做反思。工程上一个常见担忧是：同一个模型既当选手又当裁判，容易把早期的错误认知反复强化。用不同模型做生成和反思，或者让外部 verifier 参与评估，通常能缓解这个问题，但也会增加系统复杂度。

LATS：搜索式推理

论文：Zhou et al., "Language Agent Tree Search Unifies Reasoning, Acting, and Planning in Language Models", ICML 2024 [9]

机制：LATS 把 Agent 的决策过程建模为一棵搜索树，结合了蒙特卡洛树搜索（MCTS）的策略。每个节点是一个状态，每条边是一个行动，LLM 充当三个角色：

1. 策略（决定在每个节点扩展哪些行动）
2. 价值函数（评估每个状态的好坏）
3. 反思器（失败后生成经验教训）

搜索过程是标准的 MCTS 循环：选择→扩展→评估→模拟→回传→反思。

关键结果 [9]：

HumanEval Pass@1（GPT-3.5）:

方法	Pass@1
CoT	46.9
ReAct	56.9
Reflexion	68.1
LATS	83.8

GPT-4 上 LATS 达到 94.4%——在发表时是 HumanEval 的最优结果。

为什么这么强？ 因为它不走单条路——遇到死路可以回退到之前的节点尝试另一条路径。ReAct 和 Plan-and-Execute 都是线性的（或至多重规划），一旦走错几步，回头很难。LATS 天然支持探索多条路径。

代价：LATS 在每个节点扩展时采样 5 个候选行动，跑 8 轮迭代。Token 消耗比线性方法高一个数量级。只有当正确性远比成本重要、且环境提供了明确的反馈信号时，LATS 才值得。典型场景：代码生成（有测试套件验证）、数学证明（有自动验证器）。

四种架构的选择

架构	适合场景	不适合场景	核心优势	核心代价
ReAct	步骤少、需要频繁交互	长链条规划	简单直接	每步都要大模型推理
Plan-and-Execute	步骤多、目标明确	环境高度动态	有全局视角、执行可用小模型	计划可能过时
Reflexion	允许多次尝试的任务	一次机会的任务	从失败中学习	依赖有效的自我批评
LATS	高价值、有验证机制的任务	对成本敏感的场景	探索多路径	Token 消耗极高

实践中，这些架构经常混合使用。一个常见的组合是：Plan-and-Execute 做大框架，每个子步骤内部用 ReAct 循环，失败时加 Reflexion 反思。你需要根据任务特点找到最小够用的组合。

3.3 从简单到复杂的演进路径

核心直觉

不要直接跳到最复杂的架构。你的系统应该从单次调用开始，遇到瓶颈时才升级到下一层。

三级演进

第一级：单次调用 + 优化

大多数任务应该先尝试这一级。一个精心设计的 prompt，加上 RAG 检索提供上下文，加上几个 few-shot 示例，能解决的问题比你想象的多。

什么时候该升级？当你发现单次调用无法完成任务——要么需要多步推理，要么需要中间步骤调用工具获取信息，要么输出质量需要迭代改进。

第二级：单 Agent 循环

一个 LLM + 工具 + 循环。这是 Anthropic 和 OpenAI 都推荐的"第一个 Agent 形态"。OpenAI 在《A Practical Guide to Building Agents》中明确建议 [10]：

Begin with single-agent deployments; scale to multi-agent only as complexity demands.

单 Agent 能做到的事：

• 读取文件、搜索信息、调用 API
• 根据结果决定下一步
• 在工具调用失败时重试或换策略
• 完成后自动停止

什么时候该升级？当单 Agent 的上下文窗口装不下所有必要信息，或者任务需要多个明显不同的专业能力（比如同时需要写代码和做设计审查），或者你需要并行处理多个子任务。

第三级：Multi-Agent

多个 Agent 协作完成任务。这是最灵活也最复杂的形态。第 12-13 章会详细展开，这里只提一个关键判断：

从单 Agent 升级到 Multi-Agent 的信号不是"这个任务很复杂"——复杂任务单 Agent 可能也能处理。真正的信号是：

1. 上下文隔离需求：不同子任务需要不同的上下文，塞在一个 Agent 里会互相干扰
2. 专业化需求：不同子任务需要不同的工具集和 system prompt
3. 并行需求：多个子任务可以同时执行，串行太慢

一个数字帮你感受可靠性

这里有一个简单但很有用的算术事实：如果 Agent 每一步的成功率是 85%（这已经不低了），并且粗略假设每一步相互独立，那么 10 步链路的整体成功率只有 0.85^10 ≈ 20%。

这个简单的乘法解释了为什么：

• 步骤越少越好——每减少一步，整体可靠性就提升
• 每一步的可靠性极其重要——从 85% 提升到 95%，10 步链路的成功率会从约 20% 提升到约 60%
• Agent 架构的价值之一在于错误恢复——纯 Workflow 一步错了就全错，Agent 可以检测到错误并重试

3.4 从 Prompt 驱动到状态驱动：为什么 Agent 最终会回到系统工程问题

核心直觉

当 Agent 从"跑几秒完成一个任务"变成"跑几小时完成一个大任务"，你面对的就不再是 prompt 优化问题，而是分布式系统问题。

为什么会发生这个转变

LangChain 团队在描述 LangGraph 的设计动机时写过 [11]：

Agents can be written as a single function with one big while loop, but when you do that, you lose the ability to implement features like checkpointing or human-in-the-loop.

Agent 当然可以写成一个大循环。但一旦你需要检查点（进程崩溃后恢复）、人工审批（在关键步骤暂停等待确认）、时间旅行调试（回到某个中间状态重新执行）、多用户并发（同时处理多个任务），你就需要把这个大循环拆成离散的步骤，每一步之间有明确的状态。

这时候，Agent 系统看起来就越来越像传统的分布式系统了。

StreamNative 的一篇技术博客说得很直白 [12]：

Running dozens of always-on agents is more akin to running a microservice cluster than executing isolated lambdas.

运行几十个常驻 Agent 更像是运行微服务集群，而不是执行孤立的 Lambda 函数。

状态驱动架构的核心要素

当 Agent 从 prompt 驱动转向状态驱动，你需要关心这些事：

1. 检查点（Checkpoint）

每一步执行完后，把当前状态持久化存储。如果进程崩溃，从最后一个检查点恢复，而不是从头开始。

AWS 在一篇关于用 DynamoDB 构建持久化 Agent 的博客中写道 [13]：

With in-memory storage, you cannot resume a session that started elsewhere or recover if a workflow crashes halfway — which is not acceptable for production.

纯内存存储在生产环境中不可接受——你没法恢复中途崩溃的 Workflow，也没法在不同进程间共享会话状态。

2. 状态序列化与恢复

Agent 的状态不只是对话历史。它包括：

• 当前的执行计划（如果用了 Plan-and-Execute）
• 已完成的步骤和结果
• 工具调用的中间结果
• Agent 的"工作记忆"（scratchpad）
• 外部系统的状态引用

这些都需要能序列化、存储、在新环境中恢复。

3. Human-in-the-Loop 暂停点

Agent 在执行过程中可能需要暂停等待人工确认——比如执行一个高风险操作前。这意味着系统需要能"冻结"当前状态、通知人类、等待响应、然后从冻结点继续。这是一个异步状态管理问题。

4. 可观测性

Agent 不是一个黑盒。每一步的决策、推理过程、工具调用参数和返回值都需要被记录和追踪（Trace）。这和微服务的分布式追踪是同一类问题。第 17 章会专门讨论。

这对你意味着什么

如果你在构建一个只需要跑几秒的 Agent，上面这些问题可能都不紧迫。一个内存中的 while 循环就够了。

但如果你在构建一个需要运行几分钟甚至几小时的 Agent——比如代码库重构、多文档研究报告、复杂的数据分析流水线——那你实际上是在构建一个有状态的分布式系统，只是它的"业务逻辑"恰好是由 LLM 驱动的。

状态管理、故障恢复、权限控制、可观测性、评估体系——这些不是"高级功能"，而是 Agent 从 demo 走向生产的必经之路。本书的第五篇（第 16-21 章）会逐一展开这些工程挑战。

常见误区

误区："Agent 是 AI 问题，不是系统工程问题。" 恰恰相反。模型选得好只是起点。真正决定 Agent 能否在生产环境中可靠运行的，是围绕它的工程系统——状态管理、错误恢复、权限隔离、可观测性、评估体系。Stack Overflow 2025 开发者调查显示，开发者对 AI 的使用率升到了 84%，但信任度却降到了 29%（比 2024 年低了 11 个百分点）[14]。信任缺口不是模型能力的问题，而是工程可靠性的问题。

面试高频题

题目一：ReAct 和 Plan-and-Execute 分别适用于什么场景？它们的失败模式有何不同？

好的回答思路：

先说核心区别：ReAct 是"边想边做"，Plan-and-Execute 是"先想好再做"。

然后按场景分：

ReAct 适合步骤较少、需要频繁与环境交互的任务——比如信息检索、简单的工具调用。它的优势是适应性强，每一步都根据最新信息做决策。失败模式主要是：幻觉工具调用（调用不存在的工具）、循环卡死（反复重试同一个失败操作）、token 爆炸（多轮调用后上下文膨胀）。

Plan-and-Execute 适合步骤多、目标明确、可以提前规划的任务——比如多文件代码修改、研究报告生成。优势是有全局视角，且执行阶段可以用更便宜的模型。失败模式主要是：计划过时（环境变了但计划没更新）、过度规划（在规划上花太多 token 但计划不实用）、计划-执行鸿沟（Executor 理解不了 Planner 的抽象描述）。

加分点：

• 指出生产中几乎都是混合使用——用 Plan-and-Execute 做大框架，子步骤用 ReAct
• 提到可靠性数学：85% 单步准确率，10 步只有 20% 成功率——所以步骤数是关键
• 提到 LATS 作为第三种选择：用树搜索探索多路径，准确率更高但成本也更高
• 能举出具体的产品案例说明选择依据

题目二：什么是"有状态编排"，为什么它会让 Runtime 和状态管理变得关键？

好的回答思路：

"有状态编排"是指 Agent 系统在执行过程中维护和管理状态——不只是对话历史，还包括执行计划、中间结果、工具调用记录、外部系统的状态引用。

这和"无状态"的单次 LLM 调用有本质区别。单次调用是无状态的——请求进来，响应出去，不需要记住任何东西。但 Agent 是有状态的——它需要记住自己执行到了哪一步、之前做了什么决策、中间结果是什么。

一旦有了状态，就需要 Runtime 来管理它：状态的持久化存储（崩溃后能恢复）、状态的序列化（能跨进程传递）、Human-in-the-Loop 的暂停和恢复、多任务并发时的状态隔离。这些本质上是分布式系统的经典问题，只是发生在 Agent 的上下文中。

加分点：

• 提到具体的 Runtime 能力：Checkpoint、Durable Execution、Time Travel Debugging
• 引用 LangChain 的观点：Agent 可以写成一个大循环，但这样会失去检查点和人工介入的能力
• 指出这是 Agent 从 demo 到生产的分水岭——demo 可以纯内存，生产必须有持久化状态管理

---

参考资料

[1] Erik Schluntz, Barry Zhang. Building Effective Agents. Anthropic, 2024-12. https://www.anthropic.com/engineering/building-effective-agents

[2] LangChain. How and When to Build Multi-Agent Systems. 2025-06. https://blog.langchain.com/how-and-when-to-build-multi-agent-systems/

[3] Shunyu Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629

[4] Towards Data Science. Your ReAct Agent Is Wasting 90% of Its Retries. https://towardsdatascience.com/your-react-agent-is-wasting-90-of-its-retries-heres-how-to-stop-it/

[5] LangGraph GitHub Issue #6617. Production Reliability RFC. https://github.com/langchain-ai/langgraph/issues/6617

[6] LangChain. Plan-and-Execute Agents. https://blog.langchain.com/plan-and-execute-agents/

[7] dev.to. ReAct vs Plan-and-Execute: A Practical Comparison of LLM Agent Patterns. https://dev.to/jamesli/react-vs-plan-and-execute-a-practical-comparison-of-llm-agent-patterns-4gh9

[8] Noah Shinn et al. Reflexion: Language Agents with Verbal Reinforcement Learning. NeurIPS 2023. arXiv:2303.11366

[9] Andy Zhou et al. Language Agent Tree Search Unifies Reasoning, Acting, and Planning in Language Models. ICML 2024. arXiv:2310.04406

[10] OpenAI. A Practical Guide to Building Agents. 2025-04-17. https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

[11] LangChain. Building LangGraph: Designing an Agent Runtime from First Principles. 2025-09. https://blog.langchain.com/building-langgraph/

[12] StreamNative. From Functions to Agents: What Changes in the Runtime. 2025-09. https://streamnative.io/blog/from-functions-to-agents-what-changes-in-the-runtime

[13] AWS. Build Durable AI Agents with LangGraph and Amazon DynamoDB. 2026-01. https://aws.amazon.com/blogs/database/build-durable-ai-agents-with-langgraph-and-amazon-dynamodb/

[14] Stack Overflow. Developers Remain Willing but Reluctant to Use AI. 2025-12. https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai