读《从零开始构建智能体》：我对 Agent 开发的认知升级与工程思考

yllj_05

531人浏览 · 2026-04-01 05:00:00

yllj_05 · 2026-04-01 05:00:00 发布

引言：我为什么重新理解“智能体开发”关键词

过去很长一段时间，我对“智能体”的理解是偏工具化的：在大模型外面接一层提示词、再注册几个工具函数、加一点流程控制，好像就可以称之为 Agent 了。

但当我开始系统阅读 Datawhale 的《从零开始构建智能体（Hello-Agents）》后，我逐渐发现，这种理解其实还停留在“模型使用者”的阶段，而不是“系统构建者”的阶段。这个项目本身就把目标说得非常明确：它希望帮助学习者从大语言模型的使用者，转向智能体系统的构建者，并重点讨论 AI Native Agent，而不只是传统的软件流程编排。

也就是说，智能体开发并不是“把模型接入业务”这么简单，而是围绕模型构建一套能够理解目标、调用资源、管理状态、接受反馈并逐步完成任务的运行机制。

如果把我这次阅读后的最大感受概括成一句话，那就是：

智能体开发的核心难点，不在于模型会不会说话，而在于系统能不能稳定做事。

智能体不是一个模型，而是一套工作机制

我现在越来越倾向于把智能体理解为一种“系统能力”，而不是一种“模型能力”。

因为只要进入真实场景，你很快就会发现：
单一模型再强，也很难独立完成完整任务。它需要工具来访问外部世界，需要记忆保存状态，需要检索系统补充知识，需要上下文工程来压缩和组织输入，还需要追踪机制来帮助开发者调试错误。

Hello-Agents 的整体结构也恰好说明了这一点。它并不是单纯围绕“提示词技巧”展开，而是从经典范式、记忆与检索、上下文工程，再延伸到更系统性的构建问题。

而从工程角度看，OpenAI 的 Agents SDK 也给出了非常相似的定义方向：一个 agentic application 不只是“生成回答”，还涉及额外上下文、工具调用、handoff、流式输出以及完整 trace。换句话说，现代智能体系统强调的是可执行、可协作、可追踪。

这也意味着：
我们今天讨论 Agent，已经不能只讨论“模型回答对不对”，而必须讨论：

它怎么决策
它什么时候用工具
它如何记住历史
它怎样获取外部知识
它如何在预算内构造上下文
它出错后能否被定位和修复

从这个意义上说，智能体不是一个孤立模型，而是一整套围绕模型组织起来的工作机制。

经典范式的价值，不在名词，而在工程取舍

阅读《Hello-Agents》第四章《智能体经典范式构建》时，我最大的收获，并不是“记住了几个流行名词”，而是第一次把这些范式放回工程现实里去理解。

以前我会把 ReAct、Plan-and-Solve、Reflection 理解成三种不同风格的“智能体玩法”；现在我更愿意把它们看作三种不同的系统取舍方案。
它们分别在解决的问题并不相同：有的强调可解释性，有的强调整体规划能力，有的强调质量与鲁棒性，但都要面对成本、延迟和复杂度的限制。

ReAct：推理与行动耦合的最小可用范式

第四章中，ReAct 被总结为具有较强的可解释性、动态规划与纠错能力，以及工具协同能力。它的关键思想是把系统过程拆成一条可见链路：模型先思考，再决定行动，然后根据外部返回结果继续思考。

这一点对开发者非常重要。
因为一旦系统过程可见，我们就不再只看到一个“最终答案”，而能看到：

它是如何理解任务的
为什么选择这个工具
拿到结果后如何修正自己的判断
最终在哪个步骤开始偏离目标

这意味着 ReAct 不只是“会调用工具”，更重要的是，它让系统第一次变得可观察、可审计、可调试。

当然，教程也明确指出了 ReAct 的局限：它对底层模型能力依赖较强，串行执行容易带来效率损失，提示模板容易脆弱，而且在复杂任务中可能陷入局部最优。

所以在我看来，ReAct 最大的价值不是“最强”，而是它构成了智能体工程里一个非常重要的起点：

它是最容易落地、最容易解释、也最容易调试的最小可用范式。

很多系统从 ReAct 起步，不是因为它已经完美，而是因为它在“足够智能”和“足够可控”之间达成了一个很现实的平衡。

Plan-and-Solve：先规划，再执行

ReAct 更像“边走边想”，而 Plan-and-Solve 则提醒我们：
并不是所有任务都适合一边推理一边执行。

对于链条长、依赖多、阶段明确的任务，先形成总体计划，再逐步执行，往往比“走一步看一步”更稳。第四章中对这类范式的介绍，也让我第一次非常明确地意识到：很多 Agent 失败，不是因为模型不够聪明，而是因为任务根本没有被建模成适合当前范式处理的形式。

这类方法的价值，在于把任务拆成两个层次：

第一层是“全局目标与路径设计”；
第二层是“局部动作执行”。

一旦缺少第一层，系统就很容易在局部动作中不断消耗预算，却迟迟无法抵达最终目标。

因此，对长任务来说，我现在更认同这样一种判断：

先规划不是额外负担，而是避免局部最优和无效试错的重要手段。

Reflection：用成本换质量

第四章关于 Reflection 的部分给我留下了非常深的印象。教程明确指出，Reflection 能显著提高系统输出质量和鲁棒性，但它的代价同样非常明显：更多模型调用、更长响应延迟、更高提示工程复杂度。最后的结论也很务实——这是典型的“用成本换质量”的策略，更适用于那些对正确性和可靠性要求高、而对实时性要求相对没那么严苛的场景。

这个结论非常重要，因为它打破了一种常见误解：
很多人会默认“让模型多反思几轮，总会更好”。
但工程现实是，任何一次额外反思都意味着真实的延迟和费用增加。

所以我现在会更倾向于这样看待 Reflection：

不是默认开启的“高级模式”
而是一种需要根据任务目标谨慎启用的质量增强机制

比如在复杂代码生成、长报告写作、关键结论验证等任务中，Reflection 很可能是值得的；但在普通问答、实时交互、低成本辅助类任务中，它未必划算。

这让我第一次真正从质量—成本—实时性三角关系里去理解智能体范式，而不再只是停留在“哪个更聪明”的表层比较。

记忆系统：没有分层记忆，就没有真正可持续的智能体

如果说第四章解决的是“智能体怎么行动”，那第八章《记忆与检索》解决的，就是“智能体如何不在每一轮都从零开始”。

在这之前，我对“记忆”的理解其实很粗糙，更多把它等同于“多带一点历史消息”。
但阅读这一章之后，我基本不再愿意这样表述了。

教程借鉴认知科学中的记忆模型，把记忆过程抽象为编码、存储、检索、整合与遗忘，并据此把智能体记忆划分为不同模块。
这件事让我第一次真正意识到：

记忆不是一个缓存区，而是一套有生命周期、有层次、有策略的信息管理机制。

为什么记忆必须分层

第八章把记忆分为工作记忆、情景记忆、语义记忆和感知记忆。
其中：

工作记忆更偏当前对话与短期上下文
情景记忆更偏具体交互事件与历史经历
语义记忆更偏长期有效的知识、规则和偏好
感知记忆则面向图像、语音等多模态输入

这个划分对我的启发非常大。
因为它说明“让 Agent 有记忆”并不是简单地拉长上下文窗口，而是要回答下面这些问题：

哪些信息只对当前会话有用
哪些信息应该被长期保留
哪些历史事件值得回溯
哪些知识应该被抽象为长期规则
哪些旧信息应该遗忘或压缩

没有分层记忆，系统很快就会滑向两个极端：
要么什么都记不住，每次都像第一次见面；
要么什么都往一个桶里塞，最终导致检索污染、信息淹没和行为失控。

整合与遗忘，才是成熟记忆系统真正的难点

我特别喜欢第八章没有把记忆讲成“存进去就结束”这件事。
教程把“整合（Consolidation）”和“遗忘（Forgetting）”专门提出来，说明短期信息并不会自动变成长期能力，重要的是哪些内容值得升级、哪些内容应该淘汰。

这一点非常像真实世界中的认知过程：
人也不是把所有经历原封不动长期保存，而是不断筛选、压缩、抽象和遗忘。

放到智能体开发里，我越来越认同这样一句话：

遗忘不是缺陷，而是能力。

如果一个 Agent 只会累积信息，不会整理信息，它最终一定会被自己的历史拖垮。
因此，真正成熟的记忆系统，核心并不在“能存多少”，而在于“能不能让真正重要的信息留下来”。

RAG 不是外挂，而是知识能力的一部分

第八章对 RAG 的梳理也非常清晰。教程指出，RAG 的本质是在生成前先从外部知识库检索信息，再把检索结果作为上下文输入模型，以提升回答的准确性与可靠性；同时还介绍了从朴素 RAG 到高级 RAG 的演进，包括稠密嵌入、查询重写、文本分块、重排序等优化方向。

这一部分让我最有感触的一点是：

RAG 不该被理解成“外挂模块”，而应该被看作智能体知识获取能力的一部分。

如果说语义记忆解决的是“系统长期知道什么”，
那么 RAG 解决的就是“系统当前可以去查什么”。

前者偏内部长期能力，后者偏外部即时增强。
真正稳定的智能体系统，往往不是二选一，而是把两者整合成一个统一的信息流体系。

上下文工程：很多问题不是模型不行，而是上下文组织太差

如果让我从这次阅读中选出一个最容易被低估、但实际上最关键的主题，我会选第九章《上下文工程》。

因为很多时候，一个系统表现差，不是模型能力真的不够，而是它收到的信息本身就已经混乱、冗余、过时甚至互相冲突了。

以前我对上下文的理解也比较朴素：
把系统提示词、历史消息、RAG 片段、工具说明一起塞给模型。
但这章让我真正明白，上下文工程的关键从来不是“塞得多”，而是“选得准、排得清、压得稳”。

上下文工程首先是一道“选择题”

教程在上下文构建中强调了相关性和新近性打分、贪心选取以及阈值过滤等策略。它背后的核心逻辑非常明确：模型输入预算是有限资源，因此最重要的问题不是“我有哪些信息”，而是“哪些信息值得进入这一次推理”。

这件事对开发者来说非常重要。
因为一旦错误、不相关或过时的信息进入模型上下文，它带来的不是“多一点背景”，而是直接干扰模型的注意力分配。

所以我现在越来越认同一句话：

给错的上下文，往往比不给更危险。

结构化上下文，比自然堆叠更适合工程化

第九章提出了把上下文按角色区、任务区、证据区、背景区等模块化组织的方式。这样的好处不只是“看起来更整齐”，更关键的是让系统输入具备了可维护性和可调试性。

过去很多所谓 Prompt 工程，本质上更像“文本堆叠工程”：
所有要求都写进一大段文字里，模型读不读得清靠运气，开发者调试也非常痛苦。

而结构化上下文意味着：

角色与规则是独立区块
当前任务目标是独立区块
可引用证据是独立区块
历史状态与补充背景也是独立区块

这样一来，系统跑偏时，你至少知道该先检查哪一层出了问题。
这已经不是简单的提示词技巧，而更像一种输入架构设计能力。

压缩不是补丁，而是运行时能力

第九章还强调，当上下文接近或超过预算时，不能简单粗暴地整段截断，而应优先保持结构完整，再按模块进行摘要、裁剪或压缩。

这一点看起来像细节，实际却非常关键。
因为在真实系统里，上下文是动态膨胀的：

用户不断追问
工具返回结果越来越长
检索内容越来越多
历史状态不断累积

如果没有压缩能力，系统一开始也许能跑，但越跑越久就越容易失控。
因此我现在非常认同一个判断：

上下文工程不是调用前的准备动作，而是智能体系统的重要运行时能力。

这次阅读带给我的三点工程观变化

阅读到这里，我最大的变化已经不只是“学到了一些知识点”，而是我开始改变自己对 Agent 开发的判断方式。

1. 我不再把 Agent 开发理解成“接几个工具函数”

过去很容易把 Agent 开发做成一个 Demo 式流程：

接一个大模型
注册几个工具
写一段系统提示词
让系统自动跑起来

这当然可以构成最小可用原型，但它并不等于一个成熟的智能体系统。
现在我会更优先考虑：

它采用什么范式
它的记忆是否分层
它的知识来源如何组织
它的上下文如何构造
它的执行过程是否可追踪、可调试

从这个角度看，OpenAI 对 agentic application 的定义之所以强调工具、上下文、handoff 与 trace，并不是为了增加概念复杂度，而是在提醒开发者：Agent 的本质已经不再只是模型调用，而是系统设计。

2. 我开始接受：没有单一万能范式，只有更适合当前目标的权衡

ReAct 有可解释性和灵活性，但串行且容易局部最优；
Reflection 能提升质量，但必然增加成本和延迟；
记忆系统带来连续性，但也引入检索污染与管理复杂度；
上下文工程提升稳定性，但本身也需要不断迭代。

这让我越来越认同一种工程态度：

先看任务目标，再选机制组合。

也就是说，未来做系统时，我不会轻易追求“全功能 Agent”，而是会优先追求：
这个任务到底需要什么，不需要什么。

3. 我越来越重视“可调试性”，而不是“看起来很智能”

很多 Agent Demo 的第一印象是“像人在思考”，但真正进入开发与维护阶段后，我发现最宝贵的品质反而不是“拟人感”，而是好定位问题。

ReAct 的显式链路、分层记忆、结构化上下文、执行轨迹保留，归根到底都在服务同一件事：
当系统出错时，开发者能不能知道它为什么出错。

所以现在的我，会更愿意用一句很朴素的话来概括自己的态度变化：

智能体系统越复杂，就越不能只追求“更聪明”，而要优先追求“更可控”。

结语：智能体开发真正开始变难的地方

经历这次系统阅读之后，我对“智能体开发”最大的重新认识，不是某个框架怎么调用，也不是哪个范式更流行，而是开始真正理解：

智能体不是一个神奇的新物种，而是一套围绕大模型构建起来的复杂系统。

它需要推理，需要行动，需要记忆，需要检索，需要上下文组织，需要预算控制，也需要完整的调试能力。
很多时候，智能体之所以做不稳，不是因为模型不够强，而是因为这套系统机制根本还没有被认真设计。

所以，未来真正有竞争力的 Agent 开发者，大概不会只是“最会写 Prompt 的人”，也不会只是“最会接 API 的人”，而会是那些能把模型能力、工具能力、信息能力和系统能力组织到一起的人。

而这，也许才是智能体开发真正开始变得有技术含量的地方。

从 Prompt 到 System，从回答问题到完成任务，这才是智能体开发最重要的跃迁。

参考阅读

Datawhale，《从零开始构建智能体（Hello-Agents）》项目主页：介绍了项目定位、面向对象与章节结构。
《Hello-Agents》第四章《智能体经典范式构建》：涉及 ReAct、Plan-and-Solve、Reflection 等经典范式及其优缺点分析。
《Hello-Agents》第八章《记忆与检索》：涉及工作记忆、情景记忆、语义记忆、感知记忆，以及 RAG 相关基础与演进。
《Hello-Agents》第九章《上下文工程》：涉及上下文选择、组织、压缩等工程问题。
OpenAI Agents SDK Guide：从工程角度说明 agentic application 的上下文、工具、handoff、trace 等关键能力。