ai-agent教程-02-核心原理与架构

方方洛2026-10-04 10:41

本章目标:深入 Agent 的心脏------「感知-思考-行动-观察」循环; 讲透 ReAct 为什么有效;介绍规划、反思、子任务分解; 以及几种经典的 Agent 架构模式与控制流设计。

1. 核心循环:感知-思考-行动-观察

所有 Agent,无论框架如何包装,底层都是同一个循环:

scss 复制代码 
         ┌──────────────────────────────────────────┐
         │                                          ▼
  感知(Perceive) ──► 思考(Think) ──► 行动(Act) ──► 观察(Observe)
   收集输入           推理决策         执行动作       接收反馈
         ▲                                          │
         └──────────────────────────────────────────┘
                 (直到目标达成或达到停止条件)

在代码层面,这个循环具体化为:

ts 复制代码 
messages = [system_prompt, user_input]           // 感知
while (true) {
  response = llm.complete(messages, { tools })   // 思考
  messages.push(response.assistant_message)
  if (response.tool_calls.empty()) break          // 模型决定结束
  results = tools.execute(response.tool_calls)   // 行动
  messages.push(results_as_tool_messages)        // 观察(反馈回喂)
}

几个关键设计点:

  1. 整个循环的历史都在 messages 里。模型的「记忆」就是它的输入上下文, 所以每次迭代都要把完整历史(含工具往返)传给模型。这是 token 成本的大头, 也是第 05 章「上下文工程」要解决的核心问题。
  2. 停止条件是「模型不再请求工具」 。循环的出口由模型决定, 但必须有一个硬性上限(如最多 8 轮),否则「模型一直要调用工具」会无限烧钱。
  3. 工具错误不中断循环。工具可能失败,但失败信息作为观察回喂给模型, 让它自我修正------这是 Agent 韧性(intelligence)的直接来源。

对照 mini-agent:完整实现见 src/agent.ts 的 run() 方法。 第 07 章会逐行讲解。

2. ReAct:为什么「边想边做」有效

ReAct(Reasoning + Acting)是 Yao et al. 在 2022 年提出的方法,核心思想极其朴素: 让模型在行动之间穿插自然语言推理(thought),而不是直接输出动作。

一个 ReAct 轨迹看起来像:

scss 复制代码 
Thought(思考): 用户想知道耳机物流,我需要订单号,先检查记忆里有没有。
Action(行动):  search_memory("order_id")
Observation(观察): 没有找到订单号
Thought(思考): 需要向用户询问订单号。
Action(行动):  reply("请提供您的订单号")
Observation(观察): 用户提供了订单号 8847-223
Thought(思考): 现在查询物流。
Action(行动):  query_order(order_id="8847-223")
Observation(观察): 已发货,预计明天到达
Thought(思考): 信息足够,组织最终回答。
Answer(回答): 您的耳机已发货,预计明天到达。

为什么穿插思考如此有效?

  1. 把不可见的决策过程显式化。模型被迫「说出」它在想什么, 使得下一步行动有据可依,减少跳步错误。
  2. 提升多步推理的准确率。类似思维链(CoT)的原理: 中间推理步骤为后续决策提供了「工作记忆」,缓解了长链任务中的遗忘问题。
  3. 让失败可诊断。当 Agent 做错时,我们能从轨迹里看到是哪个思考环节错了, 这对评测(第 10 章)和调试至关重要。
  4. 提高可控性。显式的思考让系统设计者可以在关键节点介入 (例如「思考里出现了危险操作,拦截」)。

ReAct 的两种实现形态:

  • 隐式 ReAct :循环结构固定,模型在一条 assistant 消息里同时输出 「思考文本 + 工具调用」(content + tool_calls)。大多数现代框架如此, 因为原生 function calling 已经天然支持。
  • 显式 ReAct:把「Thought/Action/Observation」作为显式的消息格式/提示模板, 让模型按格式输出。适合不支持原生 function calling 的模型(如早期模型、自托管小模型)。

mini-agent 的 run() 采用隐式 ReAct:content 字段承载思考文本, toolCalls 字段承载行动请求,工具结果作为 role: 'tool' 消息回喂。 这与 OpenAI / Anthropic / 各家 SDK 的实现方式完全一致。

2.3 推理模型(Reasoning Models)与扩展思考

2024--2026 年,「推理模型」(如 OpenAI o 系列、Claude 的 extended thinking) 把 ReAct 的「思考」推到了极致:在输出最终答案之前,模型先在内部生成 一段长的思考链(reasoning trace),再给出结论。

makefile 复制代码 
普通模型:  思考(短暂)→ 直接回答
推理模型:  思考(长链条,内部)→ 再思考(验证)→ 给出回答

对 Agent 的影响:

维度 普通模型 推理模型
复杂推理 可能跳步出错 长思考链提升多步推理正确率
工具调用决策 直接发 tool_calls 先在内部推演「该用什么工具」再发
延迟与成本 低 明显更高(思考 token 也计费)
适用任务 快速问答、简单工具调用 复杂规划、数学/逻辑、多步决策

三个工程原则:

  1. 按任务分级使用:推理模型是「重武器」。简单任务用普通模型(便宜快), 复杂任务才用推理模型------这就是第 12 章「模型分级」的落点。
  2. 思考可见性是可选项 :各家 API 的思考过程要么不可见、要么有独立的 reasoning 字段。不要依赖「读模型的思考过程」来做业务逻辑------它可能被 屏蔽、被压缩、随版本变化。
  3. 推理模型仍然需要循环:推理模型提升的是「单次思考质量」,不改变 「循环」本身。Agent 的规划/工具调用/记忆管理,在推理模型上同样成立------ 只是每一步的「想」更深了。

判断:如果你的 Agent 卡在「逻辑推理」而非「信息获取」,换推理模型 可能比加更多工具更有效;反之,如果瓶颈在工具/记忆/上下文,换模型没用。

3. 规划(Planning)

循环让 Agent「能做事」,但面对复杂目标(「帮我写一本书」),逐轮临场决策是不够的。 规划是指 Agent 在行动之前(或之中)把大目标拆成有序的小步骤。

3.1 为什么需要规划

  • 减少累积误差:长任务里,每步的小错误会累积成大偏差。先规划可以校准方向。
  • 提高可读性与可控性:计划让用户(和系统)知道 Agent 打算做什么。
  • 支持并行与分工:拆出的步骤可以分给不同工具/不同 Agent(第 08 章)。

3.2 规划的类型

类型 时机 特点
事前规划(plan-then-execute) 行动前一次性拆解 简单,但计划可能过时
动态重规划(re-plan) 每步执行后按需调整 更鲁棒,适合开放任务
分层规划(hiarchical) 大任务拆子任务,递归 支持子 Agent/子循环

3.3 规划的两种实现

  • 模型驱动规划 :提示模型「把目标拆成 JSON 步骤数组」,解析后执行。 mini-agent 的 Planner 正是如此(src/planner.ts): 模型输出 [{"step": "..."}],或退化为启发式按句子切分。
  • 规则驱动规划:用代码规则拆解(如「检测到多个任务 → 分批」)。 确定性高,但灵活性差。生产系统常两者结合。

并行规划(LLMCompiler):把「步骤列表」升级为「步骤图」

以上两种规划产出的都是有序列表 ------严格串行。但很多任务的子步骤是可并行 的 (「查北京天气」与「查上海天气」互不依赖)。LLMCompiler(Kim et al. 2023)把计划 建模为有向无环图(DAG):

css 复制代码 
[步骤1:查北京天气] ──┐
                     ├──► [步骤3:汇总两地天气]
[步骤2:查上海天气] ──┘

计划器输出:{"steps":[{"id":1,"desc":"查北京","depends_on":[]},
                     {"id":2,"desc":"查上海","depends_on":[]},
                     {"id":3,"desc":"汇总","depends_on":[1,2]}]}
  • 依赖无环 :depends_on 表达步骤间依赖,无依赖的步骤并行执行;
  • 执行器按图调度:每完成一个步骤,检查哪些下游步骤的依赖已全部就绪,立即启动;
  • 收益:总延迟从「串行之和」降到「关键路径长度」; 依赖越少、分支越多,收益越大。
  • 代价:计划阶段多一次模型往返,且 DAG 的调度逻辑比线性列表复杂。

工程经验:别一上来就用 DAG。先线性计划,当评测(第 10 章)证明 「步骤确实互相独立、并行收益显著」时,再升级为 LLMCompiler 式调度。 这也是第 08 章「先单后多」思想在规划层面的映射。

3.4 执行计划时的关键问题

  1. 计划与执行的衔接:计划步骤如何传给循环?常见做法是 「把计划文本拼进 user 消息」或「作为额外的 system 上下文」。
  2. 步骤失败:某一步失败,是重试?跳过?还是重新规划? 好的 Agent 在失败 N 次后触发重规划,而不是无限重试。
  3. 计划的粒度:拆太细浪费 token 且僵化,拆太粗等于没拆。 经验法则:一个步骤应该是「模型单次循环能完成的最小动作」。

3.5 规划的失败模式

规划不是万能的,它有自己的失败模式。认识它们才能对症下药:

失败模式 症状 对策
计划幻觉 模型编造不存在的步骤/工具 计划必须基于「真实可用的工具清单」,并让模型在计划里引用工具名
计划过时 执行中环境变了,原计划不再适用 动态重规划:每 N 步或遇到失败时,让模型修订计划
过度规划 计划本身比任务还复杂,token 白烧 限制计划步数上限;简单任务跳过规划(能确定就不规划)
计划与执行脱节 模型不按计划执行 把计划注入 user 消息并明确「每完成一步标注到该步骤」(mini-agent 的做法)
计划不可验证 计划步骤没有明确的完成判据 每步带「完成标准」,执行后对照检查

核心认知 :规划的价值不是「预测未来」,而是「建立检查点」------ 让 Agent(和人类)能判断「走到哪了、下一步该干嘛」。计划的价值在于 可对照,不在于「正确」。

4. 反思(Reflection)

反思是比规划更高一层的元认知:Agent 对自己的输出或行为进行自我评估并改进。 经典的 Reflexion 框架(Shinn et al., 2023)把反思整合进循环:

复制代码 
尝试 → 结果 → 自我评估 → 生成「教训」→ 把教训写进记忆 → 下一次尝试更好

4.1 反思的三种粒度

粒度 内容 例子
输出级 对刚生成的内容自检 「这段代码有 bug 吗?」
轨迹级 对整个执行轨迹复盘 「我上次失败在哪一步?」
跨会话级 把教训存入长期记忆 「用户不喜欢长回复,以后要简洁」

4.2 反思的实现方式

  • 双轮模式:生成后让模型「批评自己一次」再输出最终答案 (generate → critique → revise)。
  • 自我校验工具 :调用 code_executor 跑一遍代码看是否通过测试------ 让模型用工具验证自己的输出,比让它「想象正确性」可靠得多。
  • 轨迹记忆:把每次尝试的经验压缩成一段文本存入记忆, 下次遇到同类问题直接调用。

关键认知 :反思是「用计算换正确性」。它让 token 成本翻倍甚至更多, 但往往能把成功率从 60% 提到 90%。在生产中,请对高价值、高失败成本的任务启用反思, 对低风险任务关闭。

5. Agent 工作流设计模式

工程学里有一个被反复验证的道理:大多数好系统不是从零设计的,而是由少数可命名的「模式」组合而成。 《设计模式》之于面向对象、《重构》之于代码,都建立在「命名 + 结构 + 权衡 + 适用场景」的模式语言之上。 Agent 工程同样需要这样一套模式语言------它把 2023 年以来被反复验证的结构固定下来, 让你能用一句话说清「我的系统是路由 + 评估-优化」,而不是含糊地说「用了很多 Agent」。

下面给出 7 种核心工作流模式 与 3 种基础形态 。每种模式都回答四个问题: 结构 (长什么样)、适用 (什么时候用)、优点/缺点 (代价是什么)、变体(怎么演化)。

5.1 提示链(Prompt Chaining)

结构:把任务拆成多个顺序步骤,每步的输出作为下步的输入,模型只负责其中一步。

css 复制代码 
[步骤1:提炼] ──► [步骤2:翻译] ──► [步骤3:润色] ──► 最终输出
  用户输入         上一步输出         上一步输出

适用 :任务可明确拆成若干「前馈」步骤------如「提取要点 → 扩写 → 压缩成标题」、 「先生成大纲 → 再按大纲写作」。 优点 :每步的提示词与上下文高度定制,质量稳定;每步可单独评测与替换;token 按需分配。 缺点:串行(慢);中间步骤的错误向下游传播;总延迟 = 各步之和。

与 Workflow(第 01 章 §3.2)的关系:提示链就是「多步 LLM 工作流」最常见的形态。 当每步的转换规则明确、不需要模型自主决策时,提示链是首选------能确定就绝不交给 Agent。

5.2 路由(Routing)

结构:先用一个分类器(轻量模型调用 / 规则 / 关键词)判断任务类型, 再把请求分派给对应的「专用处理单元」。

scss 复制代码 
                    ┌─► 编码 Agent(工具:读写文件 / 执行代码)
[输入] ──► [路由] ──┼─► 调研 Agent(工具:搜索 / 抓取)
                    └─► 客服 Agent(工具:查订单 / 退换货)

适用 :任务类型明确可分,每类有专门的提示词 / 工具 / 上下文 (第 16 章客服系统的「路由 + 专用 Agent」就是它)。 优点 :每个分支高度定制,质量与成本都可控;路由通常用一次轻量调用,开销小。 缺点:路由判断错误 = 任务失败;新类型任务需要新增分支;跨域任务可能被错误分派。

这是生产中最常见的模式之一(类似微服务)。关键设计是路由的判定要稳------ 低风险用规则路由(确定性高、零成本),高风险用「基础分支兜底 + 扩展分支按需」。

5.3 并行化(Parallelization)

结构:把大任务拆成独立的小任务同时处理,再合并。两种变体:

ini 复制代码 
分段并行:  [输入] → 拆成 N 段 → [段1] [段2] ... [段N] 同时处理 → 合并
投票并行:  [输入] → 同一任务 N 次独立尝试 → [结果1] [结果2] ... [结果N] → 投票/取优

适用:

  • 分段并行:子任务相互独立(「把 10 份文档各总结一段」「分章节调研 5 个话题」);
  • 投票并行 :需要多视角降低方差(「3 次独立解答取多数」「生成 + 审查」)。 优点 :延迟大幅下降;投票并行显著提升可靠性(类似 self-consistency)。 缺点:合并阶段要处理不一致结果;并发使 token 成本叠加;不是所有任务都可拆分。

5.4 编排者-工作者(Orchestrator-Workers,即 CEO 模式)

结构:一个「领导者」拆解任务、分派给「工作者」、再汇总结果。 这是并行化的升级版------把「拆解」和「汇总」也交给模型。

scss 复制代码 
                    ┌─► worker(research)
[leader] ──拆解──►  ├─► worker(write)
  │                 └─► worker(review)
  └───────汇总────────┘

适用 :任务可分解、子任务相对独立、需要并行或专业化(第 08 章详细展开; mini-agent 的 Orchestrator 正是它)。 优点 :并行、专业化、可扩展;职责清晰。 缺点:leader 是单点(失败全挂,需重试);拆解与汇总多两次模型往返;协调与失败处理复杂。

5.5 评估-优化(Evaluator-Optimizer)

结构:一个「生成器」产出结果,一个「评估器」对照标准打回并给出改进意见,循环直至达标。

css 复制代码 
[生成器] ──► 输出 ──► [评估器] ── 不合格 + 改进意见 ──► 回到生成器
                          │
                          └── 合格 ──► 最终输出

适用 :结果有明确可判断的「质量标准」,且生成可以迭代改进------ 代码生成(评估器跑测试)、翻译润色、文案创作。 优点 :质量上限显著高于单次生成;可用「最大迭代次数」精确控制成本。 缺点:延迟与成本随迭代翻倍;评估器必须可靠(否则乱打回,越改越差)。

它是本章 §4「反思」的工程化:生成 → 批评 → 修订。区别在于评估器与生成器 可以是同一个模型(自我反思),也可以是不同模型(双模型更稳,避免「自说自话」)。

5.6 计划-执行(Plan-and-Execute)

结构:先让模型把目标拆成有序计划,再执行计划;执行中按需重规划。

css 复制代码 
[目标] ──► [计划器:拆成步骤列表] ──► [执行器:逐/并行执行] ──失败──► [重规划]
                                          │
                                          └── 完成 ──► 汇总输出

适用 :复杂多步目标(调研报告、跨多工具任务),需要「先想清楚再做」。 优点 :减少累积误差;计划让用户与系统可见「打算做什么」;支持并行与分工。 缺点:计划可能过时(需要重规划);拆解与执行双份 token;计划本身可能拆错。 详细机制见本章 §3(规划)。

5.7 反思与自我修正(Reflection & Self-Correction)

结构:Agent 对自己的输出 / 轨迹进行自评并改进(本章 §4 已完整讨论)。

复制代码 
尝试 → 结果 → 自我评估 → 教训 → 改进后的再次尝试

适用 :高价值、高失败成本的任务;有客观验证手段(测试、检索、对比)的任务。 优点 :成功率显著提升(常见 60% → 90%);失败可诊断。 缺点:token 成本翻倍甚至更多;反思可能「越改越差」(需要约束,如只允许改一次)。

5.8 基础形态:单循环 / 黑板 / 层级

三种更基础的系统形态,可与上述模式任意组合:

形态 结构 适用 关键权衡
单循环(Standard Loop) 一个循环 + 一套工具 + 一个记忆 单一明确任务 最简单、最便宜、易调试;复杂目标顾此失彼
黑板模式(Blackboard) 多个 Agent 共享记忆区,隐式通信 松散模块协作 高度解耦、天然并行;执行顺序难控、信息冲突需协调(mini-agent 的 MessageBus.history() 即黑板)
层级模式(Hierarchical) 父 Agent 递归拆解给子 Agent 超大规模任务 无限扩展、责任清晰;深度增加导致延迟与成本指数增长、深层错误难回溯

5.9 模式选择速查

场景 推荐模式
多步转换、每步规则明确 提示链
多类任务、每类有专用工具 路由
子任务独立、需要提速 并行化(分段)/ 编排者-工作者
需要多视角降低方差 并行化(投票)/ 辩论
结果可判质量、可迭代改进 评估-优化
复杂多步、需要先规划 计划-执行
高失败成本、需要自愈 反思 / 评估-优化
单一明确任务 单循环
多个松散模块协作 黑板
超大规模、可递归拆分 层级
不确定走哪条路 先用单循环,失败再升级

三条工程经验:

  1. 模式是组合的,不是互斥的。真实系统 = 路由 + 编排者-工作者 + 评估-优化, 是常有的事。先画结构图,再命名,再选型。
  2. 能确定就不要交给模型。提示链、路由这种「结构确定」的部分用代码 / 规则实现; 不确定的部分才用 Agent 模式。这控制成本、提高可靠性与可审计性。
  3. 不要为了「多 Agent」而多 Agent。多 Agent 引入的协调开销与失败点, 往往比单个精心设计的 Agent 更多。先用最简单能工作的模式, 用评测(第 10 章)证明瓶颈确实在「单 Agent 能力不足」时,再升级。

6. 控制流:循环的五个工程问题

无论哪种架构,循环本身都有一组必须回答的工程问题。这些问题正是 mini-agent 的 Agent.run() 逐个解决的:

问题 解决方案(mini-agent 对应代码)
何时停止? 模型不再调用工具即停;maxIterations 硬上限兜底
超长上下文怎么办? ContextWindow.trim() 按 token 预算裁剪(第 04 章);预算/排序/缓存/压缩见第 05 章
工具失败怎么办? 错误作为观察回喂(ToolRegistry.call 返回 isError)
单次可以并行调多个工具吗? 可以,Promise.all 并行执行,减少往返延迟
如何观测循环? 事件流 + span 追踪(agent.on('tool_call', ...) / Tracer)

6.1 停止条件:三个必答问题

  1. 正常停止 :模型 finish_reason == 'stop' 且无工具调用。
  2. 硬上限:最大迭代数(默认 8)。防止死循环。
  3. 预算上限:最大 token / 最大工具调用数 / 最大耗时。防止烧钱。

6.2 并行工具调用

现代模型可以在一条消息里输出多个 tool_calls。并行执行能显著降低延迟:

css 复制代码 
用户:「帮我查北京的天气和上海的天气」
模型输出两个 tool_calls: weather_get(北京), weather_get(上海)
程序并行执行 → 两个结果一起回喂 → 模型一次汇总

注意:并行调用的工具必须互相独立。如果工具 B 依赖工具 A 的结果, 必须串行(等 A 完成后,把结果回喂模型,模型再发起 B)。

6.3 重试与退避

对模型接口的调用(网络、限流)要有重试策略:

scss 复制代码 
重试 N 次,每次等待时间指数增长(如 0.5s → 1s → 2s → 4s)
只在「瞬时错误」上重试(429 限流、5xx、网络超时)
对「确定性错误」(400 参数错误、401 鉴权失败)直接失败

mini-agent 的 provider 层是天然的重试挂载点(真实生产在 OpenAIProvider 外包装一个 RetryProvider)。

6.4 把循环当作状态机:显式状态,消灭隐式漂移

「循环」这个词容易让人以为它只是个 while(true)。但从工程视角, 一个 Agent 循环其实是一台状态机------把状态显式化,是让循环可预测、 可调试、可恢复的关键:

scss 复制代码 
状态 S = (messages, current_tool_results, iteration, budget_remaining)

转移 T = 状态机:
  idle ──用户输入──► planning(可选)──► thinking
  thinking ──模型请求工具──► acting(并行)──工具结果──► observing
  thinking ──模型不再请求工具──► done(正常结束)
  observing ──► thinking(下一轮)
  any ──超时/取消──► interrupted
  any ──迭代数耗尽──► max_iterations
  any ──不可恢复错误──► error

为什么显式状态重要:

  1. 可恢复(断点续跑):如果状态 S 可序列化(消息 + 计数 + 预算), 进程崩溃后可以从 S 恢复,而不是从头再来。LangGraph 的 checkpoint、 第 12 章的「任务状态表」都是这个思想的生产形态;
  2. 可测试:状态机可以单元测试------「给定状态 S,喂入输入 X,断言转移到 S'」; mini-agent 的测试正是这样写的(给定 MockProvider 脚本,断言 stopReason);
  3. 可观测 :每个状态转移都对应一个事件/span(第 07 章 Tracer), 「卡在哪个状态」一目了然;
  4. 可约束 :预算、超时、取消都是「任何状态下都要检查的守卫条件」, 而不是散落在代码各处的 if。

工程提示 :把循环的状态转移图画出来再写代码。大多数「Agent 行为怪异」 的问题,本质是「状态转移没定义清楚」------例如「模型输出了工具调用但参数 不合法」应该转移到 observing(回喂错误)而不是 error。

7. 认知架构的进化:从单轮到多模块

把第 02 章的内容组装起来,一个「完整认知架构」的 Agent 长这样:

scss 复制代码 
                    ┌───────────────────────┐
                    │    元认知(反思/自评)     │
                    └──────────┬────────────┘
                               │ 教训写入
                    ┌──────────▼────────────┐
用户输入 ──► 感知 ──►│  工作记忆(上下文窗口)    │
                    │  + 长期记忆(向量库)      │
                    └──────────┬────────────┘
                               │
                    ┌──────────▼────────────┐
                    │    规划器(拆解/重规划)   │
                    └──────────┬────────────┘
                               │ 步骤
                    ┌──────────▼────────────┐
                    │    执行循环(ReAct)      │──► 工具 ──► 观察
                    └───────────────────────┘

认知架构设计原则:

  1. 分层而不是叠加:把「决定做什么(规划)」与「怎么执行(循环)」分层, 而不是让所有决策混在一起。
  2. 记忆是认知的缓存:把「已经算过的结论」(反思教训、常用工具结果) 缓存到记忆,避免重复计算。
  3. 给每个模块明确的失败处理:规划失败→重规划;执行失败→重试/换策略; 反思失败→接受当前结果。
  4. 可观测优先:每个模块都有 span 和事件,否则无法调试。

8. 对照 mini-agent

本章的核心概念在 mini-agent 中的落点:

概念 代码 说明
感知-思考-行动-观察循环 src/agent.ts run() 主循环,事件驱动
ReAct(隐式) Message.content + Message.toolCalls 思考文本与工具调用同一条消息
停止条件 maxIterations + finish_reason 硬上限兜底
并行工具调用 Promise.all 执行 toolCalls 独立工具并行
错误回喂 ToolRegistry.call 返回 isError 模型看到错误自愈
规划 src/planner.ts 模型驱动 + 启发式兜底
上下文裁剪 src/context/window.ts token 预算管理
编排者-工作者 src/multiagent/team.ts 第 08 章展开

9. 本节要点

  1. 所有 Agent 底层都是感知-思考-行动-观察 循环,历史全在 messages 里。
  2. ReAct 通过在行动间穿插显式思考,提升多步推理的准确率与可诊断性。
  3. 规划 把大目标拆成小步骤,反思把经验沉淀为教训,二者都大幅提升鲁棒性。
  4. Agent 工作流设计模式 (提示链 / 路由 / 并行化 / 编排者 / 评估-优化 / 计划-执行 / 反思) 是对可控性与灵活性 的权衡;模式是可组合的,能确定就不用 Agent,能简单就不用多 Agent。
  5. 推理模型提升单次思考质量但不改变循环本身------按任务分级使用, 别依赖「读思考过程」做业务逻辑;
  6. 规划有五种失败模式(幻觉/过时/过度/脱节/不可验证)------计划的价值在「可对照」;
  7. 循环的五个工程问题:停止条件、上下文、工具失败、并行、可观测;
  8. 模型接口调用要有重试与退避策略,只在瞬时错误上重试;
  9. 并行规划(LLMCompiler) 把计划从列表升级为 DAG,让独立步骤并行执行, 先线性后 DAG,用评测驱动升级;
  10. 循环就是状态机:显式状态(消息+计数+预算)带来可恢复、可测试、可观测、可约束。

下一章进入 Agent 的「手脚」------大模型接口与工具调用。

相关推荐
方方洛1 小时前
ai-agent教程-01-认识AI-Agent
人工智能·llm·agent
空堂与归1 小时前
GPT-6 Astra填充Token 10%→50%监控盲区
人工智能·gpt·ai
空堂与归1 小时前
GPT-6.1 Sol 来了：1/5 价逼近 Astra 级
开发语言·人工智能·gpt·ai
小盆女神节奶粉1 小时前
对LangGraph的invoke的一些理解
agent
愤怒火龙果1 小时前
AI攻防 外部资源加载利用
人工智能·网络安全
一隅论数智1 小时前
给AI Agent一颗“私域大脑“：本体增强的工程化之路
大数据·运维·数据仓库·人工智能·笔记·学习·政务
深蓝AI1 小时前
78%的人写代码更快，交付却没加速：GitLab拆解AI结构性失衡
人工智能·程序员
_风不会停息1 小时前
剥开 Agent 开发：参照 pi-agent 实现一个小 Agent
人工智能·后端
方方洛1 小时前
ai-agent教程-04-记忆管理
人工智能·llm·agent
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03历年考研数学一、数学二、数学三真题试卷及答案PDF04Telegram APK 下载安装完整指南 — 2026年最新05GitHub 镜像站点06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接072026 爱知・名古屋亚运会怎么看？直播平台+赛程安排分享08微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新09Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）10给AI一张“业务概念地图“：本体如何从哲学走向企业智能