想入门 AI Agent 开发，先把这套大脑、眼睛与手脚的骨架弄懂

刚开始接触 AI Agent 时，最容易陷入概念迷宫：各种文章天天造新词，读完依然是一头雾水。这篇教程换一种讲法，尝试把 Agent 的骨架彻底拆开，让你弄清楚它到底由哪几部分组成、它们如何协同，以及哪些情况根本不需要请出 Agent。适合正准备学习 Agent 开发、或者想在业务里落地 AI 应用却不知从何下手的读者。

一、先把 Agent 拆成大脑、眼睛和手脚

理解 Agent，不妨记住一个最基础的公式：Agent 由 LLM（大语言模型）、上下文和工具共同组成。为了方便记忆，可以把它们分别想象成「大脑」「眼睛」和「手脚」——这并非文学修辞，而是严格的职责划分。

大脑（LLM）：只负责「想」，从不亲自动手。它在整套体系里的职责非常明确：理解用户的真实意图、拆解任务、规划步骤，决定下一步做什么、要不要调用工具、调用哪个工具，以及根据结果决定后续动作。注意，这里没有一项是「执行」——它不查数据库、不发邮件、不跑代码，只产出决策。

大脑的决策力也不是凭空来的，主要依赖两个过程：一是在海量语料上完成的预训练，帮模型积累语言规律和世界知识，形成「问题怎么拆」的直觉；二是通过监督微调、强化学习完成的后训练，把「何时该动手」固化成能力。

眼睛（上下文）：决定 Agent 能看到什么。很多人以为上下文只是用户刚说的那句话，其实它是每个决策点上所有输入的总和，至少包含六块内容：

• 环境观察：读到的文件、网页、数据库记录和终端输出
• 用户记忆：偏好和历史习惯
• 领域知识：借助 RAG 检索来的外部资料
• 自身状态：当前进行到哪个阶段、已经做过什么
• 任务进展：还剩哪些步骤
• 历史消息与工具结果：之前的每一轮对话及每次工具返回值

手脚（工具）：负责与外部世界交互。工具的建设分三个方向：读取信息（查数据库、读文件、搜索）、改变状态（写文件、执行代码、调用外部 API）、与他人协作（委托给子 Agent 或请人工确认）。

这里特别提醒初学者：不要以为工具就是孤立写一个 get_weather() 函数。完整的工具系统还包括工具定义、调用协议、适配器、代码执行沙箱、子 Agent 委托机制与人机沟通通道。能力差距，往往就体现在这种系统性建设上。

二、更贴近生产的视角：Model + Harness

如果你打算开发生产级 Agent，光有三件套还不够，推荐再记一个更精确的公式：Agent = Model + Harness。Model 依然只负责理解上下文、制定策略、决定下一步；Harness 则是环绕在模型外围的「运行治理层」，负责上下文管理、工具接口、约束、验证与纠正。

Harness 很容易被误解成「给模型上的枷锁」。恰恰相反，它存在的意义是把模型的能力引导到正确方向。可以把它想象成一辆马车：Model 是一匹马，Harness 是缰绳、挽具、马车和车夫——缰绳防止马往悬崖跑，挽具让力气用在正处，马车装载工具，车夫负责验证结果、纠错并决定何时停下。马越快，越需要好车夫。

此外，还要分清 Harness 与 Environment 的边界：Harness 管理「如何访问环境」，Environment 决定「环境本身是什么样」。比如，沙箱的权限设置与重置机制归 Harness 管理，而沙箱里运行的文件、进程则属于 Environment；数据库的行级安全既可能侧置于 Environment，也可能由 Harness 调用校验机制实现。

把内外结构连起来，就得到一个闭环：外层是 Agent 与 Environment 的交互——环境提供观察，Agent 通过行动改变环境，新观察又反过来驱动下一轮决策；内层则是 Model 与 Harness 的配合，由 Harness 完成双向翻译：把环境状态翻译成模型能读懂的上下文，再把模型的选择翻译成环境可执行的操作。这两支箭是整套系统真正区别于「聊天机器人」的命脉。

三、拉开产品差距的，其实是观察空间和动作空间

如果用「眼睛 / 手脚 / 策略」三个维度横向比较几类常见 Agent，会发现一个非常规整的规律：

看出规律了吗？这些产品的「策略」环节几乎一模一样，全是观察、判断、行动、修正的循环。真正的差异全在「眼睛」和「手脚」上。以 Manus 为例，它没有发明新算法，厉害之处在于把 Deep Research 的信息获取、Coding 的代码执行、Computer Use 的界面操作合并到了一起：挂上虚拟浏览器，就能看见网页内部结构而不只是截图；挂上文件系统、代码执行与命令行，才真正具备了资源和系统操作能力。后来的演进依然遵循这条路线——连接 Google Drive、开放桌面端，不断扩大观察空间和动作空间的并集。因此有一条很务实的工程结论值得记住：在底层模型固定时，提升 Agent 能力最有效的手段，往往不是换更强的模型，而是扩充上下文和工具，把「观察通道」和「动作接口」修得更宽。

四、什么时候不该套 Agent

这套公式虽好用，但边界很清晰，弄清楚比盲目上概念更重要：

• 纯问答场景不适用。如果任务只是「解释这段代码」或「翻译这段话」，不需要工具与环境反馈，眼睛和手脚都是空的，直接调 LLM 更快、更便宜、更准确，套 Agent 循环纯属浪费。
• 步骤完全确定的流程不适用。如果业务是「校验身份→搜索航班→付款→出票」这种每步都写死的链路，Agent 的自主决策毫无价值，只会徒增不确定性。这类场景该用确定性工作流，让模型只做节点内部的自然语言理解。
• Harness 不是免费的。上下文压缩、权限管理、验证纠错、沙箱隔离是一整套工程投入，任务太简单时收益根本覆盖不了成本。这也是「能跑 demo」和「能在生产里可靠交付」之间隔着十万八千里的原因。
• 公式描述的是结构，而不是质量。三件套凑齐不代表产品有用——上下文塞满噪声、工具命名混乱、约束与业务规则对不上，照样会做出一个废物 Agent。组件只是必要条件，绝非充分条件。

小结

Agent 的骨架可以压缩成三句话：Agent = 大脑（LLM）+ 眼睛（上下文）+ 手脚（工具）；进阶版则是 Model + Harness，其中 Harness 承担上下文管理、工具接口、约束、验证与纠正；整个系统以 Agent ↔ Environment 的闭环方式持续运转。三条必须记住的边界是：没进上下文的信息等于不存在；没被动作接口允许的操作等于做不到；模型固定时，扩上下文和工具往往比换更贵的模型更有效。把这些原理内化后，你就可以开始动手设计自己的第一个 Agent 了。

本文基于 rss-juejin《Agent = 大脑 + 眼睛 + 手脚：一篇看懂现代 AI Agent 的骨架》深度重写，事实与观点归原作者所有。建议阅读原文。原作者：米小虾。发布于 2026-10-15。