Agent核心架构（四层架构、ReAct、OTAC、自主决策、Multi-Agent）

一、Agent是什么？

1.1、最初的定义：大模型+提示词工程

大模型LLM能力快速成熟后，业界率先将其部署与垂直领域。只需一个基础模型加上精心编写的系统提示词（System Prompt），就能构造出行为固定的专用助手。

这个阶段的产品已被冠以Agent称谓，但其能力边界极为有限--它只是一个"被提示词塑造的模型"，谈不上自主性。

核心特征：

• 目标单一：聚焦特定领域，行为由提示词固化
• 无状态性：每轮对话独立，不记住上一轮
• 依赖提示工程：质量高度取决于提示词设计水平
• 快速上线：无复杂工程，API调用即可部署
• 成本极低：无需构建工具链或记忆模块

在2025年之前，我所在的企业，使用到的AI技术是：

• 企业内部的运维监控系统的人员人脸识别能力 --底层调用华为封装的科大讯飞的人脸识别功能、
• 运营商的客户反馈高频词云功能 --使用NLP的hanlp的分词及高频词提取为词云的功能、
• 运营商的客户评价正负向识别功能 --使用BERT进行运营商客服评价的正负向训练配套小模型、
• NoSQL实现动态报表能力 --将表模型都喂给大模型，根据用户诉求自动识别意图，生成sql语句，自动查询数据、
• 糖胖系统根据用户上传的餐饮照片，分析餐饮的合理性 --使用到了人工智能的CV能力
• 运营商的省级系统的客服助手 --对接文心一言的开源大模型。

在2025年开年的时候，deepseek爆火出圈，然后BA的情绪异常高涨，要求一个月之内，必须完成切换到DeepSeek，并且上线使用，否则不给项目付费：

• 这个里面应该存在竞争压力、国内政策对AI的重视、客户作为国企承担的AI化的指标压力
• 最后项目组，在一个月内，完成了DeepSeek大模型部署所需的资源评估、大模型部署、功能代码改造切换
• 真正的功能上线后，项目组大量的时间用于处理用户反馈的回答不符合预期的问题。开发一个月，调测3个月，还在持续调测
  • 在当时，真正可调测的内容，也就仅仅是提示词
  • 记忆也有，但是记忆是很短暂的，受context window约束，用户体验并不好
  • 该项目相当于是我们公司的一个真正意义上的LLM的试水项目

1.2、能力扩展一：赋予Agent记忆

• 问题：多轮对话中Agent失忆，每轮重新开始，无法积累上下文
• 短期记忆（In-Context Memory）
  • 将历史对话消息拼入Prompt上下文，模型在单词推理中看到过去的对话内容。受Context Window限制，对话过长需截断或压缩。
• 长期记忆（外部存储 + 检索）
  • 将重要信息向量化后存入数据库（Pinecone/Faiss/Chroma）。每轮对话时检索相关记忆片段注入上下文，突破Context长度限制
  • 用户偏好 -> 向量库 -> 检索注入
• 记忆引入后Agent的新能力
  • 持续理解意图
    • 跨轮保持对用户目标的理解，不再每次重新介绍背景
  • 个性化响应
    • 积累用户偏好和习惯，提供定制化的回复和建议
  • 多轮任务连贯
    • 在多轮任务流程中保持目标一致性和状态连续
  • 跨会话记忆
    • 下次对话仍记住重要决策、偏好和历史结论

此阶段中，Agent = 模型 + 记忆

1.3、能力扩展二：赋予Agent工具调用

• 问题：Agent只能输出文字，无法真正"做事"
• 工具调用四步机制：
  • 描述工具：以JSON Schema 告知模型可用工具与参数格式
  • 模型决策：LLM判断是否需要工具，输出结构化调用指令
  • 外部执行：宿主程序捕获指令，执行真实操作返回结果
  • 结果注入：将返回值拼回上下文，继续推理或生成答案
• 可调用工具的常见类型：所有IT技术能够触达的
  • 搜索引擎
  • 代码执行
  • 数据库查询
  • API调用
  • 文件读写
  • 浏览器操控
• 从我个人角度看，这个工具使用，原本就是个软件行业很普通的技术的应用，但是在LLM爆火的时代，这种基础软件工程能力，都被吹嘘的好像是很新颖的东西一样。
  • 在LLM之前，软件行业没有哪个项目的实现，是依赖单一技术的，其实都是根据项目常见，访问各种资源的集大成者
  • 至于Agent使用工具，这个只说明LLM被软件工程纳入进来，用于辅助决策使用哪项工具。差异就是从传统的规则选择工具 --》 LLM选择工具。
  • 然后又因为LLM要使用工具，程序员们为LLM量身定做了工具的对接能力，比如：Function Call、CLI、MCP
  • 所有本质，并不是因为有了Agent，然后才有了工具。而是软件行业本身就有工具，只是在Agent（LLM对接）出现后，进行了工具与LLM的适配实现，仅此而已
  • Agent使用工具，真正值得学习的是：怎么在软件工程中，发挥出LLM的能力。创新很重要，发现新的业务形态，创造出更高级的软件能力。

1.4、能力扩展三：规划层与自主执行循环

• 问题：单步工具调用不够，复杂任务需多步推理、动态调整和自我修正
• 规划层带来的新能力：
  • 目标分解：
    • 将复杂任务拆解为可执行的子任务序列
  • 动态调整：
    • 根据工具返回结果实时修改后续计划
  • 自我反思：
    • 检验中间结果，发现错误后主动回退重试
  • 多轮循环：
    • 循环执行直到目标达成或超出重试上限
• Agent = 模型 + 记忆 + 工具 + 规划 + 循环

1.5、定义为何一直在变？

• Agent定义持续扩张的三个根源：
  • 底层能力跃升
    • 上下文窗口扩大、工具调用成熟、推理能力增强 --每次跃升都解锁新的Agent形态，旧定义随之过时
  • 社区定义分裂
    • 研究者、工程师、产品经理对Agent的理解不同，同一词在不同语境中含义差异极大，需根据上下文判断
  • 商业竞争驱动
    • 企业倾向于将产品冠以Agent以突出智能性，导致定义被宽泛化使用，反而模糊了技术边界
• Agent = 模型 + 记忆 + 工具 + 规划 + 循环

二、Agent核心架构

2.1、四层架构总览

• 感知层 Perception
  • 接收多源输入，将原始数据组装成LLM可处理的Prompt上下文
• 规划层 Planning/LLM
  • 核心推理引擎：理解目标·制定计划·选择工具·生成行动指令·评估结果·自我反思修正
• 执行层 Execution
  • 调用工具/API/代码执行：将结果回收，反馈给规划层继续推理
• 记忆层 Memory
  • 短期记忆
  • 长期记忆
  • 情景记忆
  • 语义记忆

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

• 输入来源类型：
  • 用户文本指令、工具返回结果、历史对话记录、外部环境状态、多模态输入（图像、表格、PDF等非文本信息）
• 上下文组装 --Prompt构建过程
  • 组装时尽量将不会变化的放在前面，会变化的放在后面，这样大模型的KV-Cache的缓存命中率才会高，LLM响应才会更快
• 感知层的关键设计问题：
  • 什么信息必须传入？什么信息可以过滤？
  • 上下文过长时，如何截断或压缩？
  • 多模态输入如何统一表示？

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

• 目标理解、路径规划、动态调整、自我反思
• 规划层是Agent的大脑
  • 规划层的质量决定Agent的上限。
  • LLM的推理能力 = Agent的规划智慧

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

• 工具调用 Tool dispatch
  • 解析规划层输出的工具调用指令（JSON）
  • 路由到正确的工具实现（函数/API/SDK）
  • 处理调用失败、超时、权限错误等异常
• 环境交互 Environment Interaction
  • 操控浏览器（点击/输入/截图）
  • 读写文件系统、数据库、代码仓库
  • 执行Shell命令、运行Python代码
• 结果回收 Result Feedback
  • 将工具执行结果格式化为文本
  • 注入下一轮Prompt上下文
  • 触发规划层进行下一步推理

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

• 短期记忆 In-Context Memory
  • 当前对话的消息历史，拼入Prompt上下文。受Context Window限制，通常存最近N轮对话
  • 强调的是写入Prompt的内容
• 长期记忆 External Vector Store
  • 将重要信息向量化后存入数据库，每次对话时检索相关片段注入上下文
• 情景记忆 Episodic Memory
  • 记录具体事件序列，如【用户上次说他的项目是React】。类似人类的情节记忆，偏向具体时序事件。
  • 强调的某一次具体事件、会话片断、当时的上下文（比如这一轮用户和AI的对话历史，就是情景记忆）
• 语义记忆 Semantic Memory
  • 存储通用知识和规则，如【该用户偏好简介回答】。类似人类的常识记忆，偏向抽象事实与概念。

三、ReAct循环

3.1、ReAct：打破推理与行动的割裂

• 传统方式：
  • 先推理后行动：模型一次性生成完整计划，执行时不能根据中间结果动态调整
• 纯行动方式：
  • 直接调用工具：没有推理过程，无法解释决策逻辑，也无法推理复杂依赖任务
• ReAct方案：Reasoning + Acting
  • 交织推理与行动：每次行动前思考，行动后根据观察结果继续推理，形成自适应循环
  • Thought --》 Action --》Observation --》Thought。。。
  • 其实说白了，就是利用LLM的规划能力，在程序中写了个循环，仅此而已。搞个新的ReAct名词，显得好像很高大上，说穿了也就这样。

3.2、关键设计要点：

• Prompt格式约束
  • 通过System Prompt 强制LLM按Thought/Action/Observation格式输出，便于解析。
  • 当前LLM已经足够强大，其实不需要System Prompt说明，也能自行完成要求
• 工具路由表
  • 维护{tool_name:function}字典，Action解析后直接路由，新增工具无需修改核心逻辑
• 历史拼接策略
  • 每轮将完整TAO三元组追加进上下文，LLM可看到完整推理历史在决策
• 终止保护
  • 设置max_steps防止无限循环。生产环境还需要超时、Token预算等多重保护。

3.3、ReAct的优势与局限

• 优势：
  • 可解释性强
    • Thought步骤暴露推理过程，方便调试、审计和用户理解。
  • 动态适应
    • 每步Observation都能修正计划，不再依赖一次性完美规划
  • 支持多步工具链
    • 天然支持先后依赖关系（先查A才能查B），比单次工具调用更强大
  • 框架简洁
    • 仅需Prompt约束 + 工具路由，实现极简，LangChain/AutoGPT均基于此
• 局限：
  • 无显式验证步骤
    • 行动后没有check环节。若工具结果有误，错误可能在循环中悄悄累积
  • 单路径推进
    • 一次只探索一条路径，无法并行常识多种方案或回溯分支。
  • 上下文随循环增长
    • 每轮TAO追加进Prompt，长任务会逼近Context Window上限，Token成本高
  • 依赖Prompt格式稳定性
    • 若LLM输出不遵循格式（模型漂移），解析失败导致整个Agent崩溃

3.4、ReAct的适用场景与实战经验

• 最适合ReAct的场景
  • 多步信息检索
    • 需要先查A才能查B
    • 答案隐藏在多轮工具调用中
    • 典型：复杂问答、竞品调研
  • 工具链任务
    • 顺序依赖的工具调用
    • 结果需要二次处理再使用
    • 典型：数据分析、代码生成+执行
  • 对话式Agent
    • 每轮用户反馈可调整计划
    • 不需要严格验证中间结果
    • 典型：客服Bot、助手对话
• 实战经验与最佳实践
  • 工具描述要精准
    • 工具的名词和参数描述直接影响LLM的Action准确率，模糊描述是失败原因之一
  • 设置合理的max_steps
    • 生产环境建议5~15步，过大浪费成本，过小任务未完成
  • 记录完整TAO日志
    • 调试ReAct Agent时，打印每轮Thought/Action/Observation是定位问题的最快方式
  • 格式失败要有Fallback
    • LLM输出格式不对时，触发重试（1~2次）或降级为直接回答，避免崩溃

四、OTAC循环

4.1、从ReAct到OTAC：增加自我检查环节

• Observe --> Think --》 Act --》Check
• 设计哲学：先做，再查。每次行动后主动验证，将错误消灭在当步，而不是等到任务失败时再回头排查。
• Check后的三种决策路径
  • 继续Pass
    • 条件：结果符合预期，无异常
    • 将结果写入记忆，进入下一个Observe步骤，推进任务
  • 重试 Retry
    • 条件：结果不达预期，但方向正确
    • 调整参数或换工具，在当前步骤内重新执行Act，最多N次
  • 回退 Rollback
    • 条件：执行产生错误或进入错误路径
    • 回退到前一个安全状态，重新Think，制定新的行动方案

五、自主决策与任务分解

5.1、自主决策：从规则驱动到LLM动态推理

• 传统方式：硬编码决策树
  • 无法处理未预见的场景
  • 规则增加-->维护成本爆炸
  • 不能动态适应任务上下文
• LLM动态推理：用语言来做决策
  • 零样本泛化：见过未知情景也能推理
  • 上下文感知：结合历史动态调整策略
  • 自然语言指令：无需重新编写规则
• Agent自主决策的三个关键时刻
  • 选什么工具？LLM根据工具描述和上下文动态匹配，无需硬编码路由逻辑。
  • 继续还是停止？LLM判断当前进展是否满足目标，决定是否终止循环
  • 自己做还是求助？遇到高风险操作（删除文件、发生邮件）或信息不足时，主动停下来向用户确认，而不是盲目执行

5.2、信心判断：Agent何时行动、停止与求助

• 三态决策模型：
  • 继续执行
    • 触发条件：信心充足、信息完整
    • Agent行动：按计划执行下一步action，无需等待确认
    • 典型场景：搜索公开信息、读取文件、生成草稿---低风险、可撤销的操作
  • 主动停止
    • 触发条件：不确定性高，需更多信息
    • Agent动作：向用户提问，补充缺失信息后再继续
    • 典型场景：【你希望报告的读者是内部员工还是客户？】--歧义影响后续所有步骤
  • 拒绝执行
    • 触发条件：高风险或越权操作
    • Agent动作：明确告知用户风险，请求显式授权后才执行
    • 典型场景：删除数据库表、发送群发邮件、修改生产配置 --不可撤销的高风险操作

5.3、任务分解：让Agent处理复杂长任务

• 为什么需要分解？
  • 上下文窗口有限
  • 子任务可并行提速
  • 分治降低每步出错概率
  • 子任务可独立验证
• 顺序分解 Sequential
  • 将任务拆成有先后依赖关系的子步骤，逐一执行。前一步的输出是后一步的输入。
  • 适用：子任务存在前后依赖
• 并行分解 Parallel
  • 子任务之间无依赖，可同时分配给多个Agent或多线程执行，汇总结果
  • 适用：子任务相互独立
• 层级分解 Hierachical
  • 大人物分解为中任务，中任务在分解为小任务。Planner --》Sub-Planner --》Executor多层嵌套
  • 适用：任务复杂度高，需多层规划

5.4、企业级Agent：自主决策的边界与挑战

• 最小权限原则：只申请完成当前任务所需的最小权限，不主动扩权
• 可撤销优先：优先选择可撤销的操作
• 透明行动：每步重要操作要向用户展示，不做无声操作
• 人在回路：高风险节点始终保留人类确认入口，自主不等于无监督

六、总结与前瞻

6.1、Agent的边界与挑战（一）：幻觉传播

循环中的错误放大

环节幻觉的三层策略：

• 工具层：
  • 工具返回值做格式验证，拦截异常输出
  • 高风险工具结果做二次API查证
  • 工具调用失败时返回明确错误而非空值
• 循环层：
  • OTAC的Check步骤提前发现矛盾
  • 设置关键事实的校验点Prompt
  • 跨轮次检测信息前后一致性
• 系统层
  • 使用Retrieval-Augmented减少凭空生成
  • 关键输出步骤引入人工审核节点
  • 日志记录每轮TAO/OTAC，便于事后回溯

6.2、Agent的边界与挑战（二）：工具滥用与安全对齐

• 三大安全风险
  • 工具过度调用
    • 问题：Agent为确保结果频繁调用工具，导致API成本失控，或因重复写操作产生副作用
    • 对策：设置工具调用预算（max_tool_calls），并在check阶段判断是否已足够，避免冗余调用。比如ClaudCode，设置low、medium、high等不同推理等級的实现
  • 权限蔓延攻击
    • 问题：恶意用户通过Prompt诱导Agent代用超出授权范围的工具（Prompt Injection/越权指令）
    • 对策：工具调用白名单 + 上下文沙箱隔离，每次工具调用前验证是否在当前任务的权限范围内
  • 不可逆操作风险
    • 问题：Agent执行了删除数据、发生邮件、转账等不可撤销操作，且没有提前向用户确认
    • 对策：操作前分类；可逆操作自动执行，不可逆操作强制暂停等待显式授权
• Agent安全对齐的四个维度
  • 意图对齐
    • Agent真正执行的是用户的目标，而不是字面指令
  • 行为约束
    • 操作便捷由权限系统而非Prompt决定，不依赖LLM的自觉
  • 透明可审计
    • 所有工具调用和决策过程可追溯、可解释
  • 可撤销设计
    • 优先选择可撤销方案，为人类干预保留空间

6.3、下一步：从单Agent到Multi-Agent协作

• 单Agent的天花板
  • 上下文窗口限制：超长任务中间信息丢失
  • 单一能力瓶颈：一个LLM无法精通所有领域
  • 串行执行慢：复杂任务各步骤无法并行
  • 单点故障：一个Agent出错，整个任务失败。这个理由有点牵强。
• Multi-Agent如何突破限制
  • Orchestrator
    • 总调度Agent，负责任务分解、分配给子Agent、汇总结果。相当于项目经理
  • Specialist Agent
    • 专家Agent，只负责单一领域，模型和工具针对领域优化
  • Critic Agent
    • 评审Agent，专门验证其他Agent的输出，类似OTAC的Check，但由独立Agent执行
  • Memory Agent
    • 记忆管理Agent，负责信息检索、存储和压缩，为其他Agent提供统一的知识服务
• 从一句Prompt到自主Agent
  • 四层架构：感知+规划+执行+记忆
  • ReAct：推理行动，交织循环
  • OTAC：验证驱动，自主纠错
  • 任务分解：复杂任务，分治处理
  • Multi-Agent：协作协同，突破边界
• 每一次能力边界的扩展，都带来对Agent定义的重写