课程简介
欢迎来到 Hi-Agent——一门关于 AI Agent 工程的系统课程。
如果让我选择一个词来概括 2026 年的互联网生态，或者说 AI 领域最重要的技术方向，我想这个词一定是：Agent。
当然，Agent 并不是一个突然冒出来的新概念。早在 ChatGPT 刚刚进入大众视野之后，AI 应用就经历了从“对话式 Chat”到“工具调用 Function Call”的演进。也正是在这个过程中，Agent 的雏形开始逐渐清晰。
最早的时候，我们使用大模型，更多是在和它聊天：问一个问题，它给一个回答；给一段文本，它帮我们总结、润色、翻译。这个阶段的大模型更像是一个“知识型助手”，它很聪明，但能力基本停留在语言层面。
后来，Function Call 出现了。大模型不再只是生成文字，而是可以根据用户意图，决定什么时候调用外部工具，比如查数据库、发请求、读文件、调用搜索接口、生成图片、发送邮件，甚至控制某个业务系统完成具体操作。到这一步，AI 开始从“会说”走向“会做”。
在 2026 年，随着 OpenClaw 的火出圈，随着 Harness 的快速发展，Agent 的体系框架正在不断完善。 当 AI Agent 可以在生活中真正“动手”解决我们的需求时，这件事确实很激动人心。但一旦真正落到工程里，我们马上会遇到一堆现实问题：任务怎么拆？工具怎么管？上下文怎么传？权限怎么控？多 Agent 怎么协作？执行失败了怎么恢复？用户怎么知道它现在做到哪一步了？
而这些问题，又进一步带来了新的困惑。在我身边有很多朋友都在问：
市面上这么多Agent产品，我到底应该用哪个？他们到底有什么区别？
我想构建一个AI Agent， 应该怎么学习？
AI现在每天都在诞生新的内容，新的项目，新的方向，我如何快速的掌握？
说实话，这也曾是我的来时路。
我也经历过那种状态：今天看到一个新的 Agent 框架，觉得它好像能改变一切；明天又刷到一个新的工具平台，感觉自己之前学的东西是不是又过时了；再过几天，社区里又开始讨论新的协议、新的模型、新的多 Agent 架构。信息越来越多，方向越来越多，但真正能落到手里的东西，反而越来越少。
后来我慢慢意识到，学习 AI Agent，最怕的不是技术难，而是被信息流牵着走。
如果只是追热点，我们永远追不完。今天学一个框架，明天换一个平台，后天又被新的概念吸引过去。看起来每天都在学习，实际上脑子里只有一堆碎片：知道很多名词，却不知道它们之间的关系；看过很多项目，却不知道自己该从哪一个切入；收藏了很多教程，却始终没有真正搭出一个能跑、能用、能迭代的 Agent 系统。
所以，这门 Hi-Agent 课程想解决的第一件事，不是让你记住更多新名词，而是帮你建立一套清晰的 Agent 工程认知框架。
我们会一起回答几个最关键的问题：
- Agent 到底是什么？它和 ChatBot、工作流、Function Call、RPA、自动化脚本有什么区别？
- 一个真正能落地的 Agent 系统，应该由哪些模块组成？
- 为什么有些 Agent 看起来很聪明，但一到真实业务场景就不稳定？
- 为什么工具调用、上下文管理、权限控制、任务规划，才是 Agent 工程里真正的硬骨头？
以及，面对 OpenClaw、Harness、AutoGen、LangGraph、Dify、Coze 等越来越多的平台和框架，我们应该如何理解它们各自的位置，而不是被它们牵着鼻子走？
Agent的本质
现如今，我每天早上定时都会收到我的OpenClaw给我发来的当天的科技日报，也会给我发回当天晚上他自主学习的学习笔记， 这一切看起来很酷的过程，究竟是如何实现的呢？ 我们先从一个最简单的动作开始：
多比，今天西安天气如何？
表面上看，这只是一句很普通的提问。但在 OpenClaw 背后，一个完整的 Agent 流程已经启动了。
-
首先，消息会进入 Chat 层：系统要先知道：这句话是谁发来的，来自哪个会话，要交给哪个 Agent 处理。这里的“多比”不是一个简单昵称，它对应的是一个具体的 Agent。这个 Agent 有自己的身份、配置、模型、工具权限、记忆和工作空间。 所以，这句话不会被当成一段孤立文本处理，而是会被包装成一条带有角色、来源、会话和上下文的消息。
-
接着，系统会进入 Context Engineering 阶段：因为“今天西安天气如何”这句话虽然简单，但模型要回答准确，就必须知道几个关键信息：今天是哪一天，西安是哪个城市，是否需要实时天气数据，当前 Agent 有没有天气查询工具，以及是否要用用户偏好的表达方式来回答。
如果只是把这句话直接丢给大模型，模型可能会凭经验胡说一个天气结果。但真正的 Agent 系统不会这么做。它会把当前时间、用户问题、可用工具、工具调用规则、历史偏好等信息整理好，再交给模型判断下一步该怎么做
-
然后，Agent 进入 Agent Loop：模型看到这个问题后，会判断：天气属于实时信息，不能靠记忆回答，需要调用天气工具。于是它不会直接编一个答案，而是做出一个行动决策：
我需要调用天气查询工具，查询西安今天的天气。
这一步就是 Agent Loop 的开始。Agent 不是一次性生成答案，而是在不断进行：理解任务 → 决定动作 → 调用工具 → 观察结果 → 继续判断 → 输出结果。
-
随后，系统进入 Tool 调用: OpenClaw 会根据模型选择的工具，去调用对应的天气接口。工具可能会访问第三方天气 API，拿到西安当天的温度、天气状况、降水概率、风力、空气质量等数据。 工具返回结果后，模型再根据真实数据组织回答，比如：
今天西安的天气是晴朗，温度是25摄氏度，降水概率是10%，风力是2级，空气质量是良好。
这时你看到的只是一句自然语言回复，但它背后已经完成了一次“模型 + 工具”的协同。
-
再往后看，Memory 也会参与进来: 如果多比记得你平时关心的不只是天气，而是“今天适不适合骑车”“孩子上学要不要带伞”“空气质量会不会影响户外运动”，那么它下次回答天气时，就不会只说温度和天气状态，而会主动补一句更贴近你的提醒。
今天没有明显降雨，适合通勤；但早晚偏凉，孩子上学建议加件外套。
这就是 Memory 的作用。它让 Agent 不只是回答“西安天气”，而是在理解“你为什么问天气”。再进一步，如果这个任务变复杂，比如你问：
多比，结合今天西安天气，帮我安排一下今天的出行和工作提醒。
这时就不只是天气查询了。Agent 可能需要同时调用天气工具、日历工具、地图工具、待办工具，再综合判断你的通勤时间、会议安排和外出风险。
-
这时就可能进入 Multi-Agent 或多工具协作:
- 一个 Agent 负责查天气；
- 一个 Agent 负责看日程；
- 一个 Agent 负责规划路线；
- 主 Agent 负责把结果整合成你能直接使用的建议。
-
而所有这些动作，都需要 Harness 在背后兜底。 它要负责运行时管理、工具权限、任务调度、错误恢复、日志记录、沙箱隔离和安全控制。比如天气接口失败了怎么办？工具调用超时了怎么办？Agent 有没有权限读取你的日历？是否允许它主动给你发消息？这些都不是模型自己能解决的，而是工程系统必须处理好的问题。
所以，当你问：
多比，今天西安天气如何？
这句话背后，其实串起了 Agent 系统里的七个核心模块：
掌握了这些内容，大概率就可以解决一部分你和我曾经面对过的共同困惑。因为当市面上出现新的 Agent 产品、新的 Agent 框架、新的 Agent 技术时，我们就不会再只是被它的宣传语带着走，也不会简单地问：
这个工具火不火？ 这个框架强不强？ 这个项目要不要马上学？
而是可以换一种更清醒的方式去看它：
- 它解决的是 Agent 里的哪一层问题？
- 它是在增强 Chat 体验，还是在优化 Context 组织？
- 它是让 Tool 调用更稳定，还是让 Agent Loop 更可控？
- 它有没有 Memory？有没有 Multi-Agent 协作？有没有真正可生产化的 Harness？
- 它适合做个人助手，还是适合进入企业级业务流程？
当我们有了这套判断框架，再面对层出不穷的新项目，就不会轻易焦虑。
Agent开发的复杂性
当我们拆解完Agent的七层结构的时候，会有新的一种声音出现：
这看起来也没有那么复杂
在很多的对外的场合，我都会去这样描述Agent发展的过程中出现的各种技术，MCP、Skill、A2UI等等；我会把他们抽象为：它们本质上都是人类为了让 Agent 更好工作，而注入的一套套机制、一种种约束，以及不同类型的提示词和提示词加载方式。 这种表述也出现在很多Agent的课程和推文中，他们泛泛的将Agent的开发归结为API的调用 + 提示词工程，这让很多伙伴产生了一种错误的理解：好像只要会调大模型接口，再写一段不错的 Prompt，就已经掌握了 Agent 开发。
接下来，我展开几个七层架构里的小细节，让你感受下，Agent开发的复杂性。
Agent Loop 远不止一个简单循环
我经常会看到很多第一性原理解析Agent机制的推文，他们将Agent工作抽象为一个循环，在循环中，Agent 会重复执行以下步骤：
- 接收用户输入: 用户输入问题或指令。
- 调用模型: Agent 调用大模型，根据用户输入生成回复。
- 处理回复: 模型回复会被处理，提取出有用的信息。
- 更新上下文: 上下文会被更新，包含用户输入、模型回复、工具调用结果等。
- 重复以上步骤: 重复以上步骤，直到任务完成。
但是，你仔细思考下如下的问题：
- 模型输出到一半，余额不足了，或者网络中断了，怎么办？
- Agent 执行循环的轮次究竟多少轮为最优，如果Agent陷入死循环了怎么办？
- Agent 执行循环的过程中，如果用户输入了新的指令，或者上下文发生了变化，怎么办？ …
单回答以上问题，就足以开多篇万字长文逐一拆解。
Tool system 数量和质量的取舍哲学
在工具生态里，我们现在已经有了传统的内置 Tool、MCP 工具、Skill 等等，模型的“武器库”变得越来越强。
但你有没有过这种感觉：
- 当我给一个 Agent 安装了一堆 MCP 之后，它反而像是“降智”了；
- 当我给一个 Agent 塞进几十个甚至上百个 Tool 之后，它不但没有更强，反而开始调用不准、判断变慢、回答变散，甚至经常选错工具。
这并不是你的错觉。
Agent 的能力并不会随着 Tool 数量的增加而线性增长。很多时候，工具越多，Agent 面临的选择压力就越大；工具描述越相似，模型越容易混淆；工具边界越模糊，调用结果就越不稳定。
这就是 Tool System 的工程哲学：
工具不是越原子越好，也不是越多越好，而是要在“可组合”和“可理解”之间找到平衡。
这也是工具调用部分，我们要深入去聊的一大部分内容。
Memory 从向量库到MD文件，是开倒车吗
当OpenClaw的记忆模式把 Memory 存成 MD 文件时，第一反应可能是：
这不是开倒车吗？都 2026 年了，怎么还不用向量库？
但如果我们把 Memory 放回 Agent 工程里看，就会发现，从向量库回到 MD 文件，不一定是退步，反而可能是一种更务实的工程选择。
向量库适合解决“语义检索”的问题。比如用户过去说过很多话、项目里有大量文档、系统需要从海量信息里找出相似内容，这时候向量库很有价值。它像一个模糊搜索引擎，可以帮 Agent 在大量历史信息中快速召回相关片段。
但 Memory 不完全等于语义检索。
对一个 Agent 来说，很多记忆其实并不需要“模糊召回”，而是需要稳定、可读、可编辑、可追踪。 哪种更好呢，其实没有一个确切的答案，这就像是在做技术选型，用户量不同，面向的用户群体不同，所要承载的记忆量也不同。 因此，如何选择记忆的存储方式，也是我们的内容里，很重要的一个话题。
除了以上说的这些，多Agent，上下文管理，Harness工程，每一项，都远没有从表面看到的那么简单。
我们不把 Agent 神秘化，也不把 Agent 简化成 API 调用和提示词工程。我们会尽量从工程视角出发，把它拆开、讲透，再重新拼回一个完整的系统。
适合谁读
这篇内容更适合三类人：
-
第一类，是已经做过 LLM 应用，但还没真正理解 Agent 的开发者。 你可能写过聊天机器人、知识库问答、Function Call，甚至接过几个工具调用。但你仍然不确定：Agent 和普通 AI 应用到底差在哪里？这篇内容会帮你把概念拆清楚。
-
第二类，是想把 Agent 从 Demo 推向生产的人。 如果你遇到过工具调用不准、上下文混乱、任务状态难维护、权限不好控制、失败不好恢复这些问题，那么你会发现，Agent 真正的难点不在“跑起来”，而在“稳定运行”。
-
第三类，是希望建立 Agent 系统认知的技术人。 无论你是开发者、架构师、产品经理，还是独立开发者，只要你想判断一个 Agent 产品到底解决了什么问题，想看懂 OpenClaw、Harness、MCP、Skill、A2UI 这些技术在体系中的位置，这篇内容都会给你一张底层地图。