AI Agent：原理、架构与开发实战

在上一章中，我们认识了以脉冲神经网络为代表的类脑智能——它尝试模仿人脑的生物学机制，以更贴近真实神经元的方式处理信息。然而，无论单个模型多么精妙，它们本质上仍然是在做"感知"或"预测"：识别图片中的物体、预测下一个词是什么。

但真正的智能不止于感知与预测——它还意味着在真实世界中采取行动、使用工具、面对不确定性并不断调整策略。随着大模型推理与工具调用能力成熟，AI 的边界开始从“能理解”延伸到“能行动”——这就是AI Agent（人工智能体）。

AI Agent 不是简单的聊天机器人，也不是传统的自动化脚本。它是一种能够感知环境、规划任务、调用工具、根据反馈调整行动的智能系统。本文不会在“扫盲”和“开发”之间突然换挡，而是从工作原理一路讲到工程实现。

什么是 AI Agent？

要准确理解 AI Agent，我们可以将其与相关概念进行对比——它们有什么区别，又在哪里交汇？

哲学家怎么定义"智能体"？

"智能体"这个概念最早来自哲学和认知科学。计算机科学家 Stan Franklin 和 Art Graesser 在 1996 年给出了一个被广泛引用的经典定义——

这个定义揭示了 Agent 的四个核心属性：自主性（不依赖外部干预）、感知能力（对环境有某种观测手段）、行动能力（能通过某种行动模式影响环境）和持续性（在一段时间内持续存在）。

AI Agent 的发展历程

• 1950s-1970s — 符号主义 AI：基于逻辑推理的专家系统尝试模拟智能行为
• 1980s-1990s — 智能体理论诞生：哲学家和认知科学家提出"Agent"概念，自动化脚本在工业领域起步
• 2000s-2010s — 机器学习崛起：从统计学习方法到深度学习，AI 感知能力飞跃，但行动能力仍受限
• 2020 年 — GPT-3 发布：大语言模型展现出惊人的零样本推理能力，为 Agent 提供了强大的"大脑"
• 2023 年 — Function Calling 技术成熟：OpenAI 等公司推出的函数调用能力，让 LLM 首次能稳定地与外部工具交互
• 2024 年 — AI Agent 爆发：从 Devin 代码 Agent、AutoGPT 到 Anthropic 的 Computer Use，Agent 成为 AI 领域最热门的方向
• 2025 年及以后 — 多 Agent 协作、自主 Agent 成为新前沿：多个 Agent 可以像团队一样协作完成复杂项目

AI Agent 典型工作流

一个 AI Agent 从接受任务到完成任务，通常经历以下核心步骤：

不管 AI Agent 的外壳多么花哨，它本质上都是由几个核心模块组成的系统——大脑（Brain）、记忆（Memory）、规划（Planning）、工具（Tools）。理解了这些模块，你就理解了 Agent 的本质。

大脑：LLM 如何成为 Agent 的推理引擎？

大语言模型之所以能成为 Agent 的大脑，是因为它具备几种关键能力——从"只会说"到"会思考"的转变，依赖于这些推理技术。

记忆系统：Agent 的"大脑皮层"

记忆是 Agent 能够持续学习和积累的关键。一个好的记忆系统让 Agent 不再"记不住"——每次对话、每次经验都能被保留和调用。

记忆系统的工作流程

工具：Agent 的"双手和双眼"

工具是 Agent 从"纸上谈兵"走向"真枪实弹"的关键。有了工具，Agent 不再只是在一个封闭的对话世界里"空谈"——它可以去搜索、去写代码、去操控浏览器、去访问数据库。

Function Calling：大模型如何"学会"使用工具？

工具之所以能被 Agent 调用，核心在于Function Calling（函数调用）技术——它让大语言模型能够理解工具的定义，并在合适的时机生成调用工具的请求。

// 给模型的"工具定义"
function search_web(
  query: string,    // 搜索关键词
  max_results: int  // 最多返回结果数
) => string

// 用户提问
"今天 AI 领域有什么重大新闻？"

// 模型生成工具调用请求
{
  tool: "search_web",
  arguments: {
    query: "AI major news today",
    max_results: 5
  }
}

// 系统执行工具，返回结果
// 模型根据结果生成最终回复

根据任务复杂度、自主程度和协作方式，AI Agent 可以分为多种类型。了解这些类型有助于我们在不同场景下选择合适的 Agent 架构。

多 Agent 协作模式

在多 Agent 系统中，Agent 之间可以采用不同的协作模式来完成复杂任务：

AI Agent 正在从概念走向大规模实践。以下是一些正在发生或即将发生的典型应用场景——每个场景都展示了 Agent 在"行动"方面的独特能力。

软件开发 Agent：目前最成熟的 Agent 应用

软件开发是 Agent 落地最快、最成熟的领域之一。Agent 可以参与的环节贯穿整个软件开发生命周期——从需求分析到代码实现、测试、部署、运维。

代表性 AI Agent 产品一览

在使用和开发 AI Agent 时，有一些核心概念和技术你需要了解——它们决定了 Agent 的行为模式和最终效果。

LLM 关键参数对 Agent 的影响

调整 LLM 的参数会显著影响 Agent 的行为——这些参数决定了模型的"性格"和"风格"。

理解之后，开始构建

前面的定义、架构和工具解释了 Agent 如何工作；接下来把这些组件落到工程中：先看开发方式如何演进，再学习框架选择、设计模式、能力扩展与生产实践，最后完成一个可运行的 Agent。

从"手动组装"到"框架赋能"的演进之路

Agent 的开发方式经历了三次重大跃迁——从最初的"从零手写"，到"链式封装"，再到如今的"图编排+自主协作"。理解这个演进过程，能帮助你更好地选择适合的工具。

关键里程碑

从 ChatGPT 点燃大模型浪潮，到 Agent 进入生产环境，不过短短三年——这场变革的节奏远超以往任何技术周期。

为什么需要框架？

直接调用 LLM API 当然可以做 Agent，但面对复杂的业务逻辑、错误处理、状态管理、并发控制时，框架能帮你解决重复造轮子的问题。它们提供标准化的抽象——工具管理、循环控制、记忆系统、持久化等——让你专注于业务逻辑而非基础设施。

框架三大类别

主流框架对比一览

Agent 不是单一设计——它有多种"思维模式"

就像不同的人用不同的方式解决问题，Agent 也有多种架构模式。理解这些模式，能帮你在不同场景下选择最合适的策略。

Agent 设计的三个核心问题

在设计任何 Agent 之前，有三个根本性问题必须想清楚——它们决定了你的 Agent 的"基因"。

一个负责“连接世界”，一个负责“沉淀做法”

当 Agent 从演示走向真实工作，仅有 LLM 和几个手写函数还不够：它既需要一种统一方式连接文件、数据库、浏览器和企业系统，也需要把成熟的操作步骤保存下来，避免每次都从零探索。MCP 与 Skill 正好解决这两个不同层面的问题。

MCP 的基本架构：Host、Client 与 Server

MCP 采用客户端—服务器架构。Host 是承载 Agent 的 AI 应用；Host 内部创建一个或多个 Client，每个 Client 与一个 MCP Server 保持连接；Server 再负责访问本地或远程系统，并向 Agent 暴露可发现的能力。

Skill 如何工作：按需发现，而不是一次塞进 Prompt

一个设计良好的 Skill 会采用渐进式披露（Progressive Disclosure）：先只暴露名称与用途，让 Agent 判断是否匹配；命中任务后再读取完整说明；真正执行到某一步时，才继续加载脚本、模板或参考资料。这样既节省上下文，也减少无关指令干扰。

Tool、MCP、Skill 到底有什么区别？

MCP + Skill：现代 Agent 的完整能力链

一个 Skill 与一个 MCP Tool 的最小示意

---
name: research-report
description: 调研一个主题并生成可核验的报告
---

# 工作流程
1. 明确问题与交付格式
2. 搜集多来源资料
3. 交叉验证关键事实
4. 输出结论与来源清单

# 完成标准
- 关键结论至少有两个来源支持
- 明确区分事实、观点与推断

{
  "name": "search_documents",
  "description": "在知识库中检索文档",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "limit": { "type": "integer" }
    },
    "required": ["query"]
  }
}

什么时候应该使用它们？

从无数踩坑中总结的经验

随着 Agent 开发进入生产环境阶段，社区积累了大量实践经验。以下是当前公认的最佳实践——每一条都来自真实项目的教训。

工具设计原则：让 Agent 用好工具

工具是 Agent 与外部世界交互的唯一桥梁。工具设计的好坏，直接决定了 Agent 的"动手能力"。以下是一条简单但强大的原则——

Agent 开发常见陷阱

项目：让 Agent 安全整理一个杂乱文件夹

这一次，我们不再从安装框架、复制代码开始。你只需要把目标、约束和验收标准告诉 Coding Agent，让它负责创建项目、编写代码、运行测试并根据反馈迭代。最终得到的文件整理 Agent会扫描一个指定目录，理解文件内容，生成分类与重命名方案，并且只有在你确认后才执行整理。

第一步不是写代码，而是定义安全边界

“帮我整理文件”是一个危险的模糊需求。一个真正可用的 Agent，必须先把能做什么、不能做什么、怎样才算完成说清楚。

├── app.py                     # plan / apply / verify 命令入口
├── organizer/
│   ├── agent.py               # 任务编排与循环
│   ├── tools.py               # 扫描、摘要、复制、核验工具
│   ├── policy.py              # 路径和操作安全策略
│   ├── schemas.py             # 整理计划的数据结构
│   └── prompts.py             # 分类规则与输出约束
├── tests/                     # 安全边界和核心流程测试
├── demo-inbox/                # 只放虚构的演示文件
└── organized-output/          # Agent 的输出目录

# 先让 Coding Agent 生成一组不含真实信息的演示文件，再运行：
python app.py plan --source demo-inbox --output organized-output

# 此时只允许产生 plan.json 和预览报告，不应复制任何文件。

# 预览计划，同时生成一次性确认令牌
python app.py plan --source demo-inbox --output organized-output

# 人工检查 plan.json 后再执行。示例令牌仅用于演示：
python app.py apply --plan plan.json --confirm PLAN-7K2M

# 再次核对：源文件数量不变，输出文件与计划一致
python app.py verify --plan plan.json

# 具体命令由 Coding Agent 根据它选择的界面框架写入 README
# 示例：
streamlit run web.py --server.port 8011

最终得到的不是脚本，而是一个受约束的 Agent

核心要点回顾

下一步去哪里？