复核日期：2026-09-30
学习资料：Datawhale Hello-Agents《从零开始构建智能体》
说明：本文从后端研发视角总结课程内容，其中架构映射、工程建议和公式属于个人学习后的抽象，不代表课程或行业的统一定义。
一、学习背景
作为一名后端研发，我最初对 Agent 的理解比较简单：给大模型配置一段系统提示词，再接入几个 API，就可以让模型帮助用户完成任务。
学习 Hello-Agents 之后，我逐渐认识到，真正的 Agent 开发不是简单调用一次大模型，而是在构建一个由模型参与决策、能够感知环境、使用工具、管理状态并根据反馈持续行动的软件系统。
Hello-Agents 的课程内容从智能体与大语言模型基础开始，覆盖经典 Agent 范式、低代码平台、主流开发框架、自研 Agent 框架、记忆与 RAG、上下文工程、通信协议、Agentic RL、性能评估以及多个综合项目。这条学习路线的核心价值，是帮助开发者从大模型的“使用者”逐步转变为智能体系统的“构建者”。
二、重新理解 Agent：模型只是系统的一部分
普通的大模型应用通常是一次请求—响应：
用户输入 → 构造上下文 → 调用模型 → 返回结果这里所说的“普通大模型”特指没有接入工具、状态和外部环境的单次模型推理。模型本身可以理解和生成文本，但不会独立完成外部操作。
Agent 则更强调持续的“感知—决策—行动—反馈”闭环：
获取任务
↓
理解目标和当前状态
↓
决定下一步行动
↓
调用工具或操作环境
↓
观察执行结果
↓
继续决策，直到完成、失败或触发终止条件从个人的工程视角，我将 Agent 抽象为：
Agent
= LLM
+ Context
+ Planning
+ Tools
+ Memory
+ Control Loop
+ Environment Feedback
+ Guardrails这不是行业标准公式，而是一种帮助理解系统组成的工程模型：
- LLM 提供语言理解、推理和决策能力；
- Context 决定模型在当前步骤能够看到什么；
- Planning 负责目标分解和执行规划；
- Tools 负责访问真实世界；
- Memory 保存跨步骤、跨会话或长期信息；
- Control Loop 负责驱动执行过程；
- Environment Feedback 为下一轮决策提供观察结果；
- Guardrails 约束权限、成本、步骤和安全边界。
从后端开发角度看，Agent 可以被理解为一个由非确定性决策组件驱动的、有状态的任务执行系统。
三、Workflow 与 Agent：不是二选一
1. Workflow：路径主要由开发者定义
传统 Workflow 通常具有明确、固定的执行路径：
参数校验
→ 查询数据库
→ 调用第三方接口
→ 执行业务规则
→ 返回结果它的优势是稳定、可控、可测试、可审计，适合规则明确且风险较高的业务。
2. Agent：模型可以动态选择下一步行动
Agent 通常由开发者定义目标、工具和约束，具体步骤由模型结合当前上下文动态决定：
目标
→ 判断缺少哪些信息
→ 选择工具
→ 分析工具结果
→ 调整计划
→ 完成任务这种方式更加灵活，但会引入执行路径不稳定、结果难以完全复现、调用次数难以预测以及成本波动等问题。
3. 更合理的工程方式是混合编排
Workflow 和 Agent 并不是互斥关系。实际项目中更合适的方式通常是：
- 用 Workflow 固化确定性的主流程；
- 在需要理解、规划和动态选择的节点中调用 Agent；
- 对转账、退款、删除数据等高风险操作保留人工确认；
- 使用代码规则校验 Agent 的输入和输出。
可以概括为：
确定性逻辑交给代码，不确定性决策交给模型；模型负责提出行动，系统负责校验并执行行动。
四、经典 Agent 范式：行动、规划与改进
Hello-Agents 重点实践了 ReAct、Plan-and-Solve 和 Reflection 三种经典范式。
1. ReAct：在行动和观察之间循环
ReAct 可以从概念上表示为：
Reasoning / Decision → Action → Observation → Next Decision例如，旅行助手收到“制定上海两日游计划”的任务后，可以先查询天气，再搜索景点、路线和交通信息，最后根据工具返回的数据生成行程。
需要注意的是，这里的 Reasoning 或 Thought 是对决策过程的概念描述。生产系统应重点保存结构化的决策结果、工具调用和环境观察，而不是要求模型暴露完整内部思维链。
ReAct 的主要风险包括：
- 重复调用同一个工具；
- 选择错误的工具；
- 参数生成错误；
- 工具异常后无法恢复；
- 缺少终止条件导致循环失控。
因此，实现 ReAct 时应设置最大步骤数、超时时间、调用预算和明确的终止状态。
2. Plan-and-Solve：先拆解，再执行
Plan-and-Solve 先将复杂目标拆分成多个子任务，再根据计划逐步执行：
复杂目标
→ 生成计划
→ 执行子任务
→ 更新状态
→ 汇总结果它更适合深度研究、报告生成、代码迁移和复杂数据分析等长链路任务。
从后端角度看，Planner 类似工作流编排器，子任务类似 Job，Executor 负责调度执行，状态存储负责记录任务进度和中间结果。
3. Reflection：对结果进行检查和修正
Reflection 让 Agent 对已有结果进行评估，识别错误、遗漏和可改进点，再决定是否生成修订结果。
它能够提高复杂任务质量，但也会增加模型调用、响应时间和成本，而且反思结果本身仍可能出错。因此，它适合高价值、允许多轮处理的任务，不应默认应用于所有在线请求。
实际系统可以组合多种范式：
Plan：拆解任务
↓
ReAct：执行子任务
↓
Reflection：检查和修订结果五、从后端架构理解 Agent 框架
HelloAgents 框架通过 Message、Config、Agent 抽象基类、多种 Agent 实现和工具注册系统，展示了一个轻量 Agent 框架的核心组成。
使用后端研发熟悉的概念进行映射，可以得到：
| Agent 组件 | 后端系统中的近似概念 |
|---|---|
| LLM | 非确定性决策引擎 |
| Agent | 应用服务或任务执行器 |
| Tool | 外部服务适配器 |
| Tool Registry | 依赖注册与能力目录 |
| Memory | 数据库、缓存和历史状态 |
| RAG | 面向知识的检索服务 |
| ContextBuilder | 运行时上下文聚合层 |
| Planning | 工作流编排与任务分解 |
| Agent Loop | 状态机或任务调度循环 |
| Guardrail | 参数、权限和安全校验 |
| Evaluation | 测试、质量基线和回归体系 |
这里的映射只是为了辅助理解，并不表示两者完全等价。
一个可维护的 Agent 系统可以按下面的方式分层：
Application
├── API / Web / CLI
├── Agent Orchestrator
├── Agent
│ ├── Planner
│ ├── Executor
│ └── Reflector
├── Context
│ ├── Prompt
│ ├── Conversation
│ ├── Memory
│ └── Retrieved Knowledge
├── Tool Registry
│ ├── Search Tool
│ ├── Database Tool
│ ├── File Tool
│ └── Business API Tool
├── Model Gateway
└── Observability & Evaluation成熟框架的重点不是把模型调用包装成一个类，而是建立清晰的扩展边界：
- 更换模型时，尽量不影响 Agent 层；
- 新增工具时，不修改核心执行循环；
- 更换记忆存储时，不侵入业务逻辑；
- 切换 Agent 范式时，复用消息、模型和工具体系；
- 评估、监控和审计作为横切能力统一接入。
六、Memory、RAG 和 Context Engineering 的区别
1. Memory：保存 Agent 经历过什么
记忆主要服务于连续交互、经验积累和个性化，例如用户偏好、历史任务、中间结论和失败经验。
HelloAgents 借鉴认知科学，将记忆设计为工作记忆、情景记忆、语义记忆和感知记忆：
- 工作记忆：当前任务所需的短期信息；
- 情景记忆：具体事件和交互经历；
- 语义记忆：抽象知识、概念、规则和长期偏好；
- 感知记忆：图像、音频等多模态信息。
这四种类型是 HelloAgents 的框架设计，不是所有 Agent 系统都必须采用的统一行业标准。实际项目应根据业务需要选择数据模型和存储方式。
2. RAG：检索 Agent 当前需要的外部知识
RAG 主要解决外部知识访问问题：
文档加载
→ 内容解析与分块
→ 向量化和索引
→ 查询检索
→ 必要时重排
→ 注入上下文
→ 生成答案其工程重点包括数据质量、分块策略、召回率、相关性、时效性、权限和来源追踪。
3. Context Engineering：决定本次调用让模型看到什么
上下文工程需要在每次模型调用前动态组织：
- 系统指令；
- 当前目标；
- 对话历史；
- 可用工具描述；
- 工具执行结果；
- 相关记忆；
- RAG 检索内容；
- 当前计划和任务状态；
- 输出格式与安全约束。
HelloAgents 的 ContextBuilder 使用 GSSC 流水线：
Gather → Select → Structure → Compress
收集 筛选 结构化 压缩它将上下文视为一种有限资源，而不是简单地把所有历史信息都塞入模型。对于长时程任务，结构化笔记、上下文压缩和按需检索通常比无限扩展对话历史更加有效。
七、工具系统：核心不是能调用，而是可靠调用
Agent 要参与真实业务，就需要访问搜索服务、数据库、文件系统和内部 API。工具一旦具有副作用，工程风险也会同步增加。
1. 输入输出契约
工具参数应该结构化并经过严格校验：
class CreateOrderRequest(BaseModel):
product_id: str
quantity: int
address_id: str模型生成的参数应被视为不可信输入，不能绕过后端原有的业务校验。
2. 超时、重试和熔断
外部调用应具备：
- 超时控制；
- 有限重试；
- 指数退避；
- 熔断降级；
- 并发限制；
- 错误分类。
3. 幂等性
下单、转账、发邮件等有副作用的工具必须支持幂等键和重复请求检测，避免 Agent 重试或误判造成重复操作。
4. 权限控制
不应该将所有工具无差别暴露给 Agent。工具集合应根据用户身份、Agent 角色和任务动态生成：
查询订单：允许自动执行
取消订单：要求二次确认
退款操作：要求业务审批
删除数据：默认禁止或进入隔离环境5. 可观测与审计
每次模型和工具调用应尽可能记录：
- 任务 ID 与 Trace ID；
- Agent 和模型版本；
- 工具名称及参数摘要；
- 执行结果与错误类型；
- 调用耗时；
- Token 和费用；
- 是否经过人工确认；
- 最终终止原因。
记录时还要对密钥、个人信息和业务敏感数据进行脱敏。
八、通信协议：从点对点集成走向标准化
Hello-Agents 介绍了 MCP、A2A 和 ANP 三类协议：
- MCP：面向 Agent 与工具、资源的标准化通信；
- A2A：面向 Agent 之间的点对点通信与协作；
- ANP：面向大规模智能体网络的身份、发现和连接。
从后端视角可以近似理解为：
MCP ≈ 工具和资源访问协议
A2A ≈ 智能体之间的任务通信协议
ANP ≈ 智能体网络中的身份与服务发现基础设施需要注意两点：
第一，MCP 定义了统一协议，但模型不会因此天然获得所有工具。宿主应用仍需实现或集成 MCP Client/Host，连接对应服务器，并将能力暴露给 Agent。
第二，Hello-Agents 课程中的 ANP 为轻量、概念性实现，主要用于帮助学习服务注册、发现和网络管理，不应直接等同于成熟的生产级基础设施。
九、多智能体不是默认答案
多智能体会引入新的复杂度：
- 模型调用次数和成本增加；
- Agent 之间可能传播错误信息；
- 上下文在传递过程中可能损失；
- 决策责任边界变得模糊；
- 调试链路更长；
- 并发和状态一致性更难处理。
只有当任务具备以下特点时，才值得考虑多智能体：
- 可以拆成职责明显不同的子任务；
- 子任务可以并行或相对独立执行；
- 不同角色需要不同工具、权限或上下文；
- 中间结果能够结构化传递；
- 协作收益明显高于通信成本。
例如，深度研究任务可以拆为：
Planner Agent
↓
Research Agent × N
↓
Reviewer Agent
↓
Writer Agent简单查询、固定流程和低延迟请求则更适合普通代码、Workflow 或单 Agent。
十、评估是 Agent 工程化的分水岭
Hello-Agents 的评估章节覆盖了：
- BFCL：工具选择和函数调用能力；
- GAIA：真实世界综合任务能力；
- LLM Judge：开放式内容质量评估；
- Win Rate：方案或输出之间的相对比较；
- 人工验证：对自动评估结果进行补充和校准。
结合后端实践，可以从以下维度建立评估体系。
1. 任务效果
- 任务成功率；
- 答案正确率；
- 约束遵守率；
- 引用可靠性；
- 人工接管率。
2. 工具能力
- 工具选择准确率；
- 参数生成正确率；
- 工具调用成功率；
- 无效调用和重复调用次数；
- 有副作用操作的误执行率。
3. 系统性能
- 首次响应时间；
- 任务总耗时；
- 模型调用次数；
- Token 消耗；
- 单任务成本。
4. 稳定性和安全性
- 超时率；
- 最大步骤数触发率；
- 敏感操作拦截率；
- 提示注入防护效果；
- 模型或 Prompt 版本变更后的结果波动。
LLM Judge 适合评价开放式输出，但它可能受到模型偏好、答案长度、展示顺序和自我偏好的影响。因此，不能仅依靠单个 LLM Judge 下结论。更稳妥的方案是组合使用规则检查、公开基准、自定义数据集、多评委模型和人工抽检。
十一、我的 Agent 实践路线
第一阶段：实现最小闭环
实现一个基础 ReAct Agent：
用户任务
→ 模型决策
→ 工具调用
→ 结果回传
→ 最终回答重点解决结构化输出、工具注册、参数校验、最大步骤数和异常处理。
第二阶段：加入状态和记忆
增加会话历史、任务状态、执行记录、用户偏好以及记忆检索和淘汰策略。
第三阶段：加入上下文工程
控制上下文来源、相关性、优先级、长度和压缩方式，避免无差别堆叠历史内容。
第四阶段：完善工程治理
补充 Trace、日志、指标、超时重试、权限控制、人工确认、成本统计和敏感信息脱敏。
第五阶段：建立评估集
为工具调用、最终答案、任务耗时、调用成本和安全边界建立固定回归样本，并在修改模型、Prompt、工具描述或检索策略后自动运行。
第六阶段：按需引入多智能体
只有当单 Agent 出现职责过载、上下文膨胀、权限混杂或任务可并行化问题时，再引入多个角色协作。
十二、总结
通过 Hello-Agents 的学习，我形成了以下认识：
- LLM 是 Agent 的重要决策组件，但不是完整系统；
- Agent 的核心是模型、上下文、工具、状态与环境反馈形成的行动闭环；
- Workflow 与 Agent 可以组合，而不是必须二选一；
- Prompt 只是上下文的一部分，上下文工程决定模型在当前步骤真正看到什么；
- Memory、RAG 和 Context 分别解决经验保存、知识检索和运行时信息组织问题；
- 工具调用必须遵循后端系统既有的可靠性、安全性和审计规范；
- 多智能体是一种需要成本收益分析的架构选择，而不是复杂项目的默认答案；
- 没有评估、监控、权限和人工兜底的 Agent，更接近演示系统，而不是生产系统。
对于后端研发而言，学习 Agent 并不意味着抛弃已有的软件工程经验。接口设计、领域建模、状态机、任务调度、分布式治理、可观测性、安全控制和自动化测试，在 Agent 系统中依然重要。
Agent 带来的主要变化，是系统中出现了一个能够理解自然语言、动态规划并选择工具的非确定性组件。开发者的工作不是将所有业务逻辑都交给模型，而是为模型建立清晰的能力边界、可靠的执行环境、可验证的反馈闭环和必要的安全约束。
模型决定 Agent 能有多聪明，工程决定 Agent 能否稳定、安全地落地。
参考资料
- Datawhale Hello-Agents 在线教程：https://datawhalechina.github.io/hello-agents/
- Datawhale Hello-Agents 官方仓库：https://github.com/datawhalechina/hello-agents
- 第一章：
docs/chapter1/第一章 初识智能体.md - 第四章：
docs/chapter4/第四章 智能体经典范式构建.md - 第七章：
docs/chapter7/第七章 构建你的Agent框架.md - 第八章：
docs/chapter8/第八章 记忆与检索.md - 第九章：
docs/chapter9/第九章 上下文工程.md - 第十章：
docs/chapter10/第十章 智能体通信协议.md - 第十二章：
docs/chapter12/第十二章 智能体性能评估.md