AI Agent 架构深度解析：原理、模式与生产落地

发表于 分类于
AI Agent LLM OS

这篇是我最近准备搭 Agent 时整理的学习笔记。它和上一篇 《Agentic 入门：让 AI 不再一把梭，而是像人一样反复干活》 是一个系列：上一篇偏“怎么上手”，这一篇偏“底层怎么运转、上线怎么落地”。

最近我想给自己的工作流做一套 Agent，结果第一周就被现实教育了：这事远不只是“写个提示词模板”那么简单。

真动手之后你会发现，问题全在工程细节里。记忆怎么分层存储？任务队列怎么调度？循环什么时候该停？状态怎么恢复？这些都决定了系统是“能跑 Demo”，还是“能稳定跑在生产上”。

最不适应的一点是，传统软件那套确定性思维在这里会失灵一大截。以前写业务代码，if-else 写完，流程基本可预期；现在很多控制流是 LLM 在运行时动态决定的，排错方式也完全变了。

所以这篇我会把最近研究的几条主线串起来：Andrej Karpathy 的 LLM OS 视角、BabyAGI 的循环架构、以及 LangGraph 的状态机模式。目标很简单：把我自己踩坑后想明白的东西讲清楚，也给正在做 Agent 的你一个可复用的分析框架。

一、核心概念深度辨析：Agent 与 Agentic

先说我自己这次最大的认知纠偏：Agent 是”系统实体（名词）”，而 Agentic 是”设计模式与工作流（形容词）”。

1. Agent（智能体）：基于大语言模型操作系统（LLM OS）的计算实体

Agent 不仅仅是一个高级聊天机器人，而应该被视为一种具备拟人化特征的数字实体（People Spirits），或者说是基于大语言模型操作系统（LLM OS）运行的一台新型计算机4-6。在 LLM OS 的宏观架构中：

  • CPU（中央处理器）： 大语言模型（LLM）本身负责指令处理、推理与决策5, 7。
  • RAM（内存/工作记忆）： 模型的上下文窗口（Context Window）。这是一种短期的工作记忆，LLM 在此编排内存与计算以解决问题7, 8。
  • 外设与接口（Tools）： Agent 可以通过工具调用与数字世界的外部基础设施交互，例如访问文件系统、运行代码沙箱或调用网络浏览器5, 9, 10。

2. Agentic Workflow（智能体化工作流）：告别 Zero-shot 的迭代范式

吴恩达（Andrew Ng）指出，传统上我们主要以”零样本（Zero-shot）”模式使用 LLM，即提示模型逐字生成最终输出而不进行任何修改。这很像要求一个人从头到尾敲击键盘写文章，全程不允许按退格键11。

Agentic 工作流是一种引入迭代循环（Loop）的系统方法论。 它允许系统像人类工程师一样：规划大纲 -> 决定是否需要网络搜索 -> 撰写初稿 -> 审查初稿中的逻辑漏洞 -> 结合审查结果继续修改12。

惊人的工程收益：这种工作流带来了巨大的性能提升。在 HumanEval 代码编写基准测试中，GPT-3.5 的零样本正确率仅为 48.1%，GPT-4 为 67.0%；但是，如果将较弱的 GPT-3.5 放入 Agentic 迭代循环中，其正确率飙升至 95.1%13。

二、Agent 的底层架构与运行机制

要理解 Agent 的底层架构，我们得先抛弃”它只是个聊天机器人”这个视角，把它当成一台基于自然语言指令运行的新型计算机。

2.1 宏观架构：大语言模型操作系统（LLM OS）

前特斯拉 AI 总监 Andrej Karpathy 提出了理解 Agent 架构的最佳抽象模型：LLM OS（大语言模型操作系统）。在这个架构中：

组件 对应关系 功能描述
CPU（处理器） 大语言模型（LLM） 负责处理输入、执行逻辑推理、以及发出指令
RAM（内存 / 工作记忆） 模型的上下文窗口（Context Window） 和 KV Cache 短期工作记忆，任何在当前执行步骤中需要被 LLM 直接读取的信息，都必须被塞进这个窗口里
外存（硬盘 / 长期记忆） 外部的向量数据库（Vector Database，如 Pinecone） 甚至传统关系型数据库 由于 LLM 每次调用完成后会”失忆”（无状态），历史数据必须持久化在这里
外设与执行器（Tools） 代码沙箱（Code Sandbox）、文件系统读写权限、浏览器 API 相当于计算机的网卡、显卡或机械臂

2.2 核心模块拆解（以经典 Agent 为例）

如果剥开代码看，一个标准的自主运行 Agent（例如早期 BabyAGI 或现代框架的核心模块）通常由以下几个核心组件（Components）构成：

1. 大语言模型控制器（LLM Controller）

这是整个系统的大脑。它接收系统提示词（System Prompt），明确当前的角色设定、可用工具列表以及输出格式（通常为 JSON），以此将自然语言转化为结构化的机器动作。

2. 记忆管理系统（Memory System）

  • 短期记忆： 通常由开发框架（如 LangChain/LangGraph）维护当前的对话历史或近期几步的操作日志。
  • 长期记忆： 当任务周期极长时，框架会将之前的操作结果转化为”向量嵌入（Embeddings）”，存入向量数据库。当 Agent 执行新任务时，系统会通过”语义搜索（Semantic Search）”提取最相关的历史经验，拼接进当前的上下文中供 LLM 读取。

3. 工具与环境接口（Tool Integrations / Harness）

LangChain 创始人 Harrison Chase 强调，现代 Agent 的强大来源于强大的“脚手架（Harness）”。这包括预置的工具函数。最核心的工具是文件系统（File System）访问权限，因为它可以让 Agent 把长篇的中间结果写入文件，而不是全部塞进上下文里导致内存溢出。

2.3 运行机制：死循环与状态机（The Loop & State Machine）

Agent 并不是”一口气”运行完的，它的底层是一个事件驱动的循环结构（Loop）。在工程实现里，主流运行机制大致有两种：

机制 A：经典的”三节点”死循环（如 BabyAGI）

BabyAGI 证明了只要三个 Python 脚本节点相互配合，就能让 Agent 无限期自主运转：

  1. 任务执行节点（Task Execution）： 读取当前任务队列的第一个任务，结合向量数据库中的历史上下文，调用 LLM 执行任务，并保存结果。
  2. 任务创建节点（Task Creation）： 观察上一步的执行结果，调用 LLM 判断”为了实现总目标，接下来还需要新增什么任务？”，并将新任务丢进队列。
  3. 任务优先级排序节点（Task Prioritization）： 调用 LLM 对现有的任务队列重新排序，清理冗余，决定下一步最该做什么。 这个循环（While Loop）会不断运转，直到任务列表清空或达到预设的终止条件。

机制 B：现代的图与状态机架构（如 LangGraph）

面对更复杂的企业级业务，简单的死循环难以控制。现代框架（如 LangGraph）将运行机制升级为有向图（Graph）和状态机（State Machine）：

  • 节点（Nodes）： 代表具体的处理单元（可以是一个调用 LLM 的函数，也可以是执行 Python 代码的工具）。
  • 边（Edges）： 包含条件判断逻辑（如 IF-ELSE）。基于当前节点返回的结果，决定数据流向下一个哪个节点。
  • 状态管理（State Management）： 整个图共享一个全局状态（State）。每次循环都在更新这个全局状态，并自带持久化（Persistence）功能。这意味着当 Agent 运行到一半崩溃，或者遇到高风险操作需要”人类审批”时，程序可以暂停保存状态，之后再无缝恢复。

2.4 底层工程的终极挑战：上下文工程（Context Engineering）与执行轨迹（Traces）

当我们把上面这些模块拼起来后，运行逻辑会发生根本变化，这也是研发人员最需要适应的地方：

  • 逻辑不再只存在于代码中： 传统软件的控制流（If-Else）写在代码里；但 Agent 的控制流很大一部分由 LLM 在运行时动态决定（具有不确定性）。
  • 上下文工程（Context Engineering）决定成败： 决定 Agent 表现的，是每次循环调用 LLM 时，你在这个循环点（通过检索或状态机）给它组装了什么上下文。如果塞入的信息太多，LLM 会忘记关键指令；如果太少，它会产生幻觉。
  • 排错（Debug）依赖执行轨迹（Traces）： 在传统开发中，出 Bug 了我们看代码；但在 Agent 开发中，当系统在第 14 步失败时，看代码毫无用处，因为你需要知道前 13 步它往上下文（Context）里塞了什么。因此，记录每一步提示词、输入和输出的执行轨迹（Traces） 取代了源代码，成为了 Agent 开发中测试和调试的“唯一真相来源”。

三、驱动系统运转的核心：四大 Agentic 设计模式

在底层循环与状态机之上，真正让 Agent 表现出”智能感”的，是吴恩达总结的四种核心 Agentic 设计模式（Design Patterns）24：

1. 工具使用（Tool Use）

赋予 LLM 网络搜索、代码执行等外部函数调用能力，以收集信息或处理数据24。

2. 规划（Planning）

面对复杂目标时，LLM 能够自主提出并执行一个多步计划24。

3. 反思（Reflection / Self-Correction）

强迫 LLM 检查自身的输出，发现缺陷并提出改进方案24。例如，在缓解模型幻觉的研究中，Chain-of-Verification (CoVe) 强制模型生成验证问题并自我审查，而 Self-Refine 则采用”生成 -> 反馈 -> 改进”的迭代框架扮演自我批评者的角色25, 26。

4. 多智能体协作（Multi-agent Collaboration）

实例化多个不同的 AI 角色，通过分担任务和相互辩论，得出比单一 Agent 更优的解决方案24。

四、研发视角的范式转换：开发 Agent 与传统软件的区别

LangChain 创始人 Harrison Chase 指出，构建 Agent 会显著改变传统软件工程的一些基本常识27。

1. 逻辑存在于模型中（非确定性系统）

传统软件的逻辑被硬编码（Hard-coded）在代码中，开发者可以确切知道程序的流向；而在 Agent 中，程序的控制流是由大模型在运行时基于上下文动态涌现的，具有高度的黑盒性和不确定性27, 28。

2. “执行轨迹（Traces）”取代代码，成为 Debug 的唯一事实依据

由于 Agent 在循环中反复运行，当系统在第 14 步报错时，单看代码无法推断前 13 步 LLM 的上下文窗口里到底装载了什么29。因此，详细记录每一步输入、输出、工具调用和状态变化的执行轨迹（Traces），取代了源代码，成为了开发者测试、排错（Debug）和团队协作的核心工具27, 30, 31。

3. “脚手架（Harness）”与”上下文工程（Context Engineering）”决定成败

长周期 Agent（Long-Horizon Agents）的成败往往不仅仅取决于底层模型有多强大，更取决于开发者构建的 Harness（深度定制的脚手架体系）32, 33。这包括内置的规划工具、处理超长文本的压缩（Compaction）策略，以及至关重要的文件系统访问权限（File System Access）9, 33, 34。这一切本质上都是 “上下文工程（Context Engineering）”——即在 Agent 循环的每一个特定步骤，精准地为其上下文窗口注入最需要的记忆、工具结果和指引32, 35, 36。

五、生产环境落地的终极指南

对于准备把 Agent 投入生产环境的研发团队，行业里有一个高度一致的共识：不要一上来就追求 100% 全自动（Fully Autonomous）。

1. 做好迎接”Agent的十年”的准备，它是一个”九的游行”

Andrej Karpathy 强调，目前行业处于”Agent的十年（Decade of Agents）”，而非所谓的一年37。构建可靠的 Agent 与研发自动驾驶汽车极度相似：展示一个能解决 90% 问题的 Demo 非常容易，但要达到生产级别，需要经历漫长的”九的游行（March of nines，即追求 99.9% 到 99.99% 的极端可靠性）”38, 39。

2. 定位为”初稿生成器（First Drafts）”

现阶段长周期 Agent 最杀手级的应用场景，不是直接交付最终结果，而是生成一份极具价值的”初稿”40。无论是代码的 Pull Request、SRE 的日志诊断分析报告，还是客户支持的复杂调研，Agent 的作用是承担粗重的初期工作，然后交由人类审核与编辑40, 41。

3. 保留”自主性滑块（Autonomy Slider）”

在产品设计（如 Cursor 或 Perplexity）中，必须赋予用户控制权42-44。开发者可以选择只补全一行代码（Tap completion）、修改单个文件，或是让 Agent 放开手脚重构整个代码仓库，用户可以根据任务复杂度动态调整这种”自主性滑块”44, 45。

4. 终极形态：环境智能体（Ambient Agents）与 智能体收件箱（Agent Inbox）

传统的基于聊天（Chat-based）的 Agent 受限于极高的延迟要求和一对一的交互瓶颈46-48。未来的生产级落地形态将走向环境智能体（Ambient Agents）46, 49。

  • 事件驱动与异步执行： Ambient Agents 在后台静默运行，监听并响应事件流（如新收到的客户邮件、代码库提交、系统报警等）46。由于没有即时聊天的延迟压力，它们可以执行包含数十次工具调用和复杂规划的深层任务48, 50。
  • 人类在环（Human-in-the-loop）与 Agent Inbox： 这种异步、高并发的运行模式绝不意味着失控。相反，系统必须设计一个类似”智能体收件箱（Agent Inbox）”的交互界面51。Agent 将执行到一半的高风险操作或半成品报告推送到收件箱中，人类在此进行审批（Approve）、编辑修改（Edit）、解答 Agent 的疑问（Answer），甚至进行”时间旅行（Time Travel，即回滚到之前某一步重新运行）”52, 53。这不仅保证了业务的安全性，人类的纠错反馈也将作为记忆（Memory），驱动 Agent 系统的自我迭代与进化51, 54。

六、当前实践：病历质量评估 Agent 的版本演进（从简单到复杂）

为了和前面的学习框架对齐，我把当前病历质量评估 Agent 的实现拆成四个版本。每一版都解决上一版暴露的问题，而不是一上来就做“大而全”。

V1：纯规则引擎（无 Agent）

最早版本只有确定性规则：字段完整性、格式约束、必填项检查。

  1. 优点是稳定、可解释、上线快。
  2. 缺点是只能发现“结构性问题”，看不懂跨段语义矛盾。

这一版对应本文里的“传统确定性系统”，适合作为基线能力。

V2：单 Agent 循环（引入 Agentic Workflow）

第二版把 LLM 接入到循环里，流程是：读取病历 -> 发现问题 -> 生成建议 -> 自检修正。

  1. 能力明显增强，可以识别时间线冲突、表达不一致、潜在漏项。
  2. 也暴露出典型问题：偶发幻觉、建议过于抽象、同类问题重复输出。

这一版验证了本文第二部分的结论：有循环就会有收益，但没有工程约束就会不稳定。

V3：图与状态机编排（从“能跑”到“可控”）

第三版把单循环改成状态机，拆成多个节点：

  1. 输入结构化节点。
  2. 规则校验节点。
  3. 语义评估节点。
  4. 证据绑定节点。
  5. 报告生成节点。

每一步都有明确输入输出和状态落盘，支持暂停/恢复/重跑。
这一版对应本文的 LangGraph 思路，本质收益是“可观测、可回放、可定位”。

V4：生产化闭环（Human-in-the-loop + Traces）

当前线上思路是第四版：不是追求全自动判定，而是做“高质量建议系统”。

  1. 高风险结论必须进人工审核收件箱。
  2. 每条问题必须附原文证据和触发依据。
  3. 全链路记录 Traces（上下文、模型输出、工具调用、状态迁移）。
  4. 人工反馈回写，驱动下一轮提示词和规则优化。

这正好对应本文“上下文工程 + 执行轨迹 + 自主性滑块”的三条主线。

这条演进线给我的最大启发：医疗质控这种高风险场景里，Agent 的价值不在“替人做最终判断”，而在“把问题找全、证据对齐、把人工复核效率做上去”。
总结：我们正在经历软件工程范式的一次关键转折。从"软件 1.0"的确定性代码，到"软件 2.0"的神经网络权重，再到"软件 3.0"的 LLM 驱动 Agent，每一次跃迁都在重新定义"编程"这件事。对研发人员来说，理解 Agent 的底层架构——LLM OS 的计算模型、四大设计模式、以及上下文工程的核心地位——会是未来十年非常关键的技术投入。

核心参考文章

1. 吴恩达 (Andrew Ng) —— Agentic 核心概念与设计模式

3. Andrej Karpathy —— LLM OS 系统愿景

4. BabyAGI —— 自主智能体先驱