企业官网建设流程全解析

第一部分 理论篇：大模型Agent核心原理

1.1 Agent的定义演化时间轴

Agent = 模型 + 记忆 + 工具 + 规划 + 循环

1.2 现代Agent四层架构：感知、规划、执行、记忆

现代工业落地的大模型 Agent，一般拆解为感知层、规划层、执行层、记忆层四大核心模块。四层相互循环协作，记忆层贯穿整个生命周期，共同实现智能体自主思考、工具调用、任务迭代执行的完整能力闭环。

1.2.1 感知层（Perception Layer）：多源输入与上下文组装

感知层是Agent的“感官入口”，负责接收来自外部世界的各类信息，将多路输入整合、组装成完整Prompt上下文，喂给后续推理模块。

1.2.1.1 输入来源类型

• 用户文本指令：用户自然语言描述的任务目标和约束条件。
• 工具返回结果：函数调用、API执行完成后返回的数据，作为本轮任务的反馈信息。
• 历史对话记录：从记忆层读取出来的短期、长期上下文信息。
• 外部环境状态：网页内容、本地文件、代码仓库等环境读取的数据。
• 多模态输入（可选）：图像、表格、PDF等非文本类信息。

1.2.1.2 Prompt上下文组装过程

感知层将多路信息拼接成大模型可识别的消息列表，依次放入系统提示词、检索得到的长期记忆内容、历史对话上下文、当前用户输入。

1.2.1.3 感知层核心设计问题

• 信息筛选：什么信息必须传入上下文？哪些冗余信息可以过滤？
• 上下文窗口控制：上下文超长时，如何截断、摘要压缩，避免超出模型Token上限。
• 多模态统一表征：图片、表格等异构信息，如何转换成模型可理解的格式。

1.2.2 规划层（Planning Layer）：LLM作为推理引擎

规划层是Agent的大脑，Agent自主决策、任务分解、动态反思的能力全部由该层提供。规划层质量直接决定Agent能力上限，大模型本身的推理能力，就是Agent的规划智慧。

1.2.2.1 四项核心职责

• 目标理解：解析用户意图，提取任务核心目标与约束条件，把自然语言转换成机器可处理的任务表征。
• 路径规划：将复杂大目标拆解为多个子任务，确定任务执行顺序、挑选合适工具序列，生成行动计划。
• 动态调整：根据工具返回的执行结果实时更新计划；当执行结果不符合预期时，重新规划后续执行步骤。
• 自我反思：审查中间执行结果和历史操作，判断任务是否回退、修正或者直接终止，避免错误不断累积放大。

1.2.2.2 典型推理模式：思维链CoT

规划层最常使用Chain‑of‑Thought提示词范式，拆分Thought思考、Action行动两个阶段：

System：分步骤思考，先列出计划再执行。

Thought：用户要分析销售数据，需要：

1. 读取 CSV 文件
2. 计算各月环比
3. 找出峰值月份
4. 生成摘要报告

Action: 读取销售文件

1.2.3 执行层（Execution Layer）：从指令到真实行动

执行层是Agent的手脚，负责落地规划层输出的行动指令，完成和外部世界交互，拿到任务执行结果再反馈回去，开启新一轮循环。

1.2.3.1 三大核心职责

• 工具调用：解析规划层输出的行动指令，分发到对应的工具、接口；同时处理调用超时、异常报错、权限不足等问题。
• 环境交互：操控浏览器、读写本地文件与数据库、运行脚本命令，完成真实环境操作。
• 结果回收：将工具返回的数据格式化为文本，注入下一轮Prompt上下文，触发规划层开启新一轮推理循环。

1.2.3.2 执行层完整工作流

规划层输出行动指令 → 工具路由器分发任务 → 工具执行 → 结果格式化与异常处理 → 将结果注入上下文，触发下一轮规划。

1.2.4 记忆层（Memory Layer）：Agent的知识基础

记忆层相当于Agent的“记忆系统”，用来存储对话、任务、知识信息，让智能体拥有跨轮次长期认知。Agent记忆体系一共分为四类：

• 短期记忆：当前对话消息历史，直接拼入Prompt上下文；受模型上下文窗口限制，一般保存最近N轮对话。
• 长期记忆：将重要信息做Embedding向量化，存入向量数据库；每次任务开始时通过语义检索，取出相关历史信息注入Prompt。
• 情景记忆：记录具体时序事件，例如“用户上次项目框架是React”；偏向保存事件发生过程，类似人类经历回忆。
• 语义记忆：存储通用规则、抽象知识，例如“用户偏好简洁风格报告”；偏向概念、事实、用户偏好类知识。

1.2.4.1 记忆读写时机

• 读取时机：每轮对话启动、感知层组装Prompt、规划层参考历史决策时读取记忆；
• 写入时机：对话结束提取摘要、检测重要偏好信息、任务完成保存执行过程与结论。

1.2.5 四层协作：一次完整Agent执行全流程

四层模块并不是一次性单向运行，而是循环迭代，记忆层全程贯穿任务生命周期，每一步都可以读写记忆。

完整执行链路：

感知层（接收输入） → 规划层（推理规划） → 执行层（调用工具） → 执行层（回收结果） → 规划层（再次规划迭代） → 记忆层（写入任务成果）

1.2.5.1 实战案例：任务「帮我写一份竞品分析报告」

1. 感知层：接收用户「竞品分析」指令，从记忆层读取用户所在行业背景信息，组装完整Prompt；
2. 规划层：任务拆解生成计划：搜索竞品A →搜索竞品B →对比分析 →生成报告摘要；
3. 执行层：依次调用搜索工具，获取竞品A、竞品B结构化数据；
4. 规划层：汇总搜索结果，再次推理分析，产出竞品对比文本；
5. 记忆层：将本次竞品分析结论写入长期记忆，后续对话可以直接复用本次成果。

1.3 ReAct循环：Thought‑Action‑Observation推理行动交织

ReAct 是目前工业Agent最主流的执行范式，核心思想就是推理思考（Thought）和行动执行（Action）交替循环。大模型不再一次性给出最终答案，而是先思考、再动手调用工具、观察返回结果，基于新信息再次思考，往复迭代直到任务完成。

1.3.1 ReAct完整执行流程

1. 用户输入目标任务
2. Thought（思考）：分析当前任务，拆解步骤，制定下一步行动计划，判断是否需要调用外部工具。
3. Action（行动）：执行计划，调用对应的工具接口；如果信息已经充足，也可以直接输出最终答案结束任务。
4. Observation（观察）：接收工具返回的数据、结果反馈，把外部信息带回给大模型。
5. Thought（再次思考）：评估刚刚拿到的结果，判断任务是否完成、数据是否充足，规划后续步骤。
6. 重复「Thought‑Action‑Observation」循环，直到模型产出Final Answer（最终答案），任务终止。

1.3.2 三个阶段详解

1.3.2.1 Thought 思考阶段

属于模型内部推理过程，不需要接触外部环境。
负责解析现状、反思上一轮结果、判断缺口、生成下一步策略。是Agent“动脑”的环节。

1.3.2.2 Action 行动阶段

Agent对外交互的环节。
按照思考得出的方案，发起工具调用，例如联网搜索、读取文件、查询数据库。

1.3.2.3 Observation 观察阶段

接收外部世界给到Agent的反馈。
将工具返回的原始结果整理成可读文本，送入上下文，供给下一轮思考使用。

1.3.3 ReAct 的优势与局限

1.3.3.1 ReAct 的优势

• 可解释性强
  Thought 步骤暴露推理过程，方便调试、审计和用户理解。

• 动态适应
  每一步 Observation 都能够修正计划，不再依赖一次性生成完美规划。

• 支持多步工具链
  天然支持任务先后依赖关系（先查A才能查B），相比单次工具调用能力更强。

• 框架简洁
  仅依靠提示词约束 + 工具路由即可实现，开发门槛低，LangChain、AutoGPT 等大量开源Agent框架均基于该范式。

1.3.3.2 ReAct 的局限

• 无显式验证步骤
  行动完成之后缺少专门的校验环节。一旦工具返回结果出错，错误会在循环迭代中不断累积放大。

• 单路径推进
  同一时刻只探索一条执行路线，无法并行尝试多种备选方案，也不具备任务分支回溯能力。

• 上下文随循环增长
  每一轮 Thought‑Action‑Observation 的内容都会追加进Prompt上下文；长任务很容易逼近模型上下文窗口上限，同时带来更高的 Token 消耗成本。

• 依赖 Prompt 格式稳定性
  强依赖大模型输出严格遵守指定格式。一旦模型发生输出漂移，返回格式错乱，工具解析失败就会直接造成Agent运行崩溃。

1.4 OTAC循环：Observe‑Think‑Act‑Check带校验的自主循环

OTAC 是在 ReAct（Thought‑Action‑Observation）范式之上迭代升级出来的Agent循环框架。最核心的改动就是在行动之后新增了Check自我检查环节，解决ReAct缺少结果校验、错误不断累积放大的痛点。

1.4.1 ReAct存在的核心缺陷

1. 没有验证环节
   行动完成后直接进入下一轮思考，Agent不会主动校验执行结果是否达到预期，错误会悄无声息流入后续步骤。
2. 错误累积放大
   在长任务流程里，早期步骤产生的错误结果被写入上下文，后续全部推理都会建立在错误信息的基础之上。
3. 无回退机制
   一旦执行路径出错，ReAct只会一直向前推进，缺少“退回上一步、更换备选方案”的纠错能力。

1.4.2 OTAC改进思路

• ReAct循环流程：Thought → Action → Observation，循环过程中无校验步骤。
• OTAC循环流程：Observe → Think → Act → Check，每一次行动结束之后都会执行Check验证，校验失败时可触发重试或者任务回退。

1.4.2.1 设计哲学

遵循「先做，再查」的执行理念。每次行动结束后主动校验执行成果，把错误消灭在当前步骤，而不是等到整个任务失败后再回头排查问题。

目前 Claude Code、Manus、Devin、OpenAI Operator 这类工程型Agent工具，都内置了该验证思想，在执行代码、操控网页之后添加结果校验步骤。

1.4.3 Check步骤：OTAC的核心创新

Check阶段负责检验Act行动产出的结果，校验完成后一共有三种决策分支：

1. 继续（Pass）

   • 条件：执行结果符合预期，无异常问题
   • 处理方式：将结果写入记忆，进入下一轮Observe步骤，继续推进任务。

2. 重试（Retry）

   • 条件：执行结果没有达到预期，但是任务的前进方向正确
   • 处理方式：调整参数或者更换工具，在当前步骤之内重新执行Act，一般设置最大重试次数防止无限循环。

3. 回退（Rollback）

   • 条件：执行出现严重错误、Agent走入错误路径
   • 处理方式：回退到前一个安全状态，重新开启Think环节，制定全新的行动方案。

1.4.3.1 Check校验时需要思考的核心问题

• 结果是否包含任务预期产出的内容？
• 是否出现报错、异常、空返回等负面现象？
• 当前距离最终任务目标，还缺少哪些信息？

1.4.3.2 案例对比

┌──────────────────────────────────────────┐ ┌──────────────────────────────────────────────────────┐ │ ReAct（无校验，错误跑偏） │ │ OTAC（带Check自检，重试成功） │ └──────────────────────────────────────────┘ └──────────────────────────────────────────────────────┘ 开始任务：读取网页价格 开始任务：读取网页价格 │ │ ▼ ▼ Thought：打开网页获取价格 Observe：目标读取网页价格，暂无结果 │ │ ▼ ▼ Action：访问目标网址 Think：计划调用浏览器访问网页 │ │ ▼ ▼ Observation：页面空白、加载失败 Act：第一次执行访问网页 │ │ ▼ ▼ Thought：网页无价格，改用搜索引擎查询 Check：页面空白加载失败 → Status:RETRY，刷新重试 │ │ ▼ │ Action：搜索商品价格 ┌───────────┘ ▼ ▼ Observation：拿到第三方报价 Act：第二次重新访问网页 │ │ ▼ ▼ 输出最终答案 Check：页面加载成功，读到价格¥199 → Status:PASS │ ▼ 任务完成，输出价格结果

1.4.4 Check 对比 ReAct 里 Thought 的核心区别

Thought 的首要目标是「往前规划下一步干什么」；Check 的唯一目标是「回头核验上一步有没有干成」。

1.5 自主决策与复杂任务分解策略

1.5.1 agent 自主策略

依靠大模型理解目标，实时做出判断，摆脱固定路由（严格规定的if else）代码。
Agent 在执行任务的全过程，需要自主回答三个核心问题：

1. 选什么工具？
   当前目标需要调用哪一个工具、参数如何配置。大模型依据工具描述、上下文动态匹配，不需要硬编码路由逻辑。
2. 继续还是停止？
   判断任务是否完成，剩余多少步骤。评估当前进展是否达成目标，决定是否终止循环。
3. 自己做还是求助？
   遇到高风险操作（删除文件、发送邮件）或者信息不足时，主动暂停任务、向用户确认，拒绝盲目执行。

Agent 根据自身信心程度，输出三种决策结果：

1.5.2 复杂长任务：任务分解

为什么需要任务分解？

1. LLM 上下文窗口有限，单次无法容纳全部中间结果；
2. 子任务可以并行执行，提升执行速度；
3. 分治策略降低单步出错概率；
4. 每个子任务结果能够独立校验。

1.5.2.1 三种任务分解策略

1. 顺序分解（Sequential）

任务拆分成存在先后依赖的子步骤，一步一步执行；前一步输出作为后一步输入。

示例：分析论文 →读取 PDF →提取摘要 →查找关键词 →生成报告

适用场景：子任务之间强前后依赖。

2. 并行分解（Parallel）

子任务之间互不依赖，可同时分配给多个 Agent 或多线程执行，最后汇总全部结果。

示例：竞品调研，同时搜索 A、B、C 三家公司资料，之后汇总对比。

适用场景：多个独立任务，没有数据依赖关系。

3. 层级分解（Hierarchical）

大任务拆成中型任务，中型任务继续拆分更小任务，形成多层嵌套：Planner → Sub‑Planner → Executor。

示例：开发功能 →设计模块 →(设计接口 + 编写单元测试 + 实现代码) →集成测试

适用场景：任务复杂度很高，需要多层规划。

1.5.2.2 企业 Agent 四大共性决策原则

1. 最小权限原则：只申请完成当前任务最小权限，不主动扩大权限范围；
2. 可撤销优先：优先执行可逆操作（草稿 > 发送、移动 > 删除）；
3. 透明行动：重要操作向用户展示过程，禁止后台无声执行；
4. 人在回路：高风险节点永远保留人类确认入口；Agent 自主决策不等于无监督运行。

1.6 Agent面临的边界挑战与Multi‑Agent展望

1.6.1 挑战一：幻觉传播（循环错误放大）

1.6.1.1 幻觉传播发生流程

1. 步骤1：LLM产生幻觉输出（错误事实 / 虚假数据）
2. 步骤2：错误 Observation 被写入上下文
3. 步骤3：后续所有 Thought 基于错误上下文推理
4. 步骤N：最终答案建立在完全错误的基础上

风险说明：幻觉比单次调用更危险，幻觉在循环中被不断「确认」和放大。

1.6.1.2 缓解幻觉的三层策略

1.6.2 挑战二：工具滥用与安全对齐

1.6.2.1 三大安全风险

1.6.2.2 Agent安全对齐的四个维度

1.6.3 从单Agent到Multi‑Agent协作

1.6.3.1 单 Agent 的天花板

• 上下文窗口限制：超长任务中间信息丢失
• 单一能力瓶颈：一个 LLM 无法精通所有领域
• 串行执行慢：复杂任务各步骤无法并行
• 单点故障：一个 Agent 出错，整个任务失败

1.6.3.2 Multi‑Agent角色分工（突破限制）

第二部分 实战篇：解析LLM如何调用Tool（ReAct教学项目）

2.1 方式一：手写Prompt实现工具调用

不依赖 API 的 Function Calling 能力，而是在 System Prompt 里和模型约定一种固定的输出格式，程序再用正则把这个格式"翻译"回结构化数据，从而知道模型想调用哪个工具、传什么参数。

流程如下：

① 调 LLM（带 stop=["Observation:"]，让模型停在调用工具前） ↓ ② 正则解析输出 ├─ 有 "Final Answer:" → 结束，返回答案 ├─ 有 "Action:" → 继续 └─ 都没有 → 格式解析失败（unparseable） ↓ ③ 程序执行工具 TOOLS_MAP[action](**action_input) ↓ ④ 把 assistant 输出 + "Observation: 结果" 追加回 messages ↓ ⑤ 回到 ①，循环直到 Final Answer 或达到 max_steps

2.2 方式二：原生Function‑Calling实现工具调用

把"工具说明书"用 JSON Schema 传给 API 的 tools 参数，让模型原生返回结构化的 tool_calls，程序只需消费这些结构，不再自己解析文本。

① 调 LLM（带 tools=TOOLS_SCHEMA, tool_choice="auto"） ↓ ② 看 finish_reason ├─ == "stop" → 模型直接给答案，循环结束 └─ == "tool_calls" → 继续 ↓ ↓ ③ 遍历 msg.tool_calls，逐个执行： - tool_call.function.name → 工具名 - tool_call.function.arguments → 参数（json.loads 转 dict） - 执行 TOOLS_MAP[name](**args) → 得到结果 ↓ ④ 把结果以 role:"tool" + tool_call_id 回填进 messages ↓ ⑤ 回到 ①，循环直到 finish_reason == "stop" 或达到 max_steps