Agent 的实质：LLM + Tools + Prompt 三元素拆解
做了大半年 AI Agent 开发，写了不少 demo，也踩了不少坑，回头看的时候发现——核心就三样东西：LLM、Tools、Prompt。
这个认知不是一开始就有的。最初我也是照着教程一步步来，调 API、接工具、写提示词，但总觉得缺个全局视角。后来有一天整理笔记，把做过的 Agent 项目拆开来看，才有了一个发现。不管是简单的问答机器人，还是复杂的多步骤任务系统，本质上都是在组合这三个元素。
这感觉有点像当年学 Web 开发——理解了 MVC 模式之后，再看任何框架都能快速拆解。Agent 也一样，理解了三元素框架，你就能用一个清晰的视角去拆解市面上任何 Agent 产品，也能自己从零设计一个。
图 1：Agent 三元素框架 — LLM（推理）+ Tools（操作）+ Prompt（目标），三者汇聚生成 Agent
如果你刚接触 Agent，建议先看看之前写的什么是 Agent，有个基本概念再来读这篇，会顺畅很多。
LLM 选型——Agent 的大脑
Agent 的推理能力完全依赖底层的大语言模型（LLM），所以选型是最底层的决策。我的经验是，选型的核心考量不是"哪个模型最强"，而是性价比——根据你的使用频次和能力需求来选。
当前格局大致是这样：Claude、Gemini、ChatGPT 三强领跑，各家各有特长。国内厂商追赶得很快，但在复杂推理和长上下文场景下，差距还是能感受到的。我的原则很简单：能用国外模型就优先用国外模型，尤其在 AI Agent 场景下，推理能力的差异会直接影响任务完成率。
但这里有个很多人忽略的坑：反向代理（Reverse Proxy）的风险。
国内开发者因为网络原因，经常通过第三方 API 代理来调用模型。这些代理表面上看起来一切正常——请求能发出去，响应也能收回来。但问题是，你很难确认中间层有没有对请求做改动。有些代理会在你的 Prompt 前面插入系统指令。有些会对上下文（Context）做截断或压缩。更有甚者，会把你的对话数据拿去做训练。
我在早期用第三方代理的时候，经常遇到一个诡异的现象：同样的提示词，过一阵子效果就不一样了。后来才意识到，是代理方在中间层调了策略。这对 Agent 开发是致命的——Agent 的行为依赖提示词的稳定性，如果底层上下文不纯净，你根本无法构建可复现的行为模式。
所以我的建议是：要么直接用官方 API，要么自己搭建代理通道。只有稳定的提示词系统，才有积累的可能。
选好了大脑，接下来要给它什么工具？这涉及到 Agent 设计中最有讲究的部分。
Tools 设计——上下文管理的三大工具类型
如果说 LLM 是大脑，那 Tools 就是 Agent 的手和脚。但我觉得更准确的说法是——工具的本质是辅助模型处理上下文。所有工具设计的目标，都可以归结为一句话：构造「短、高目标性、主题单一」的上下文。
为什么这个目标如此重要？因为模型的推理能力会随上下文膨胀而下降。上下文越长、主题越杂，模型就越容易"走神"——忘掉最初的任务、被无关信息带偏、或者产生自相矛盾的输出。这不是某个模型的问题，而是目前所有 LLM 的共同局限。
我根据自己的实践，把 Agent 常用的工具分成三类：
图 2：Agent 工具三大分类 — Plan 工具保证一致性，文件操作卸载上下文，Sub-Agent 隔离上下文
Plan 类工具：让 Agent 保持方向感
Plan 类工具包括 todo list、思考工具（Chain of Thought 的外部化版本）等。它们的核心作用是让 Agent 始终朝目标前进，不跑偏。
举个具体例子：你让 Agent 去完成一个多步骤的编程任务，如果没有 Plan 工具，它可能写到第三步就忘了第一步的需求是什么。但如果它能把计划写下来，每完成一步就更新状态，行为就会一致得多。这跟人做事情是一个道理——好记性不如烂笔头。
文件操作类工具：卸载上下文，构建记忆
这类工具涵盖的范围很广：读写文件、执行命令行、记忆模块，还有检索增强生成（RAG）。它们的共同目的是把大量信息从上下文中卸载到外部存储，需要的时候再按需检索。
Agent 不需要把所有信息都塞在对话历史里。它可以像人一样，把笔记写在文件里、把关键信息存到数据库中，需要的时候再去查。这样上下文就能保持精简和聚焦。记忆模块更是如此——把上次任务的经验存下来，下次直接复用，这就是一种数字资产。
如果你好奇为什么不能靠纯工作流编排来解决这些问题的，可以看看我之前写的AI 工作流的局限。简单说，工作流是静态的路径规划，但 Agent 需要的是动态推理和自主决策能力。
Sub-Agent：隔离上下文的利器
第三类工具比较特殊——把子 Agent 当作工具来调用。这听起来有点套娃，但背后的逻辑很清晰：上下文主题冗杂会直接降低模型能力。
想象一下：让一个 Agent 同时处理多个不同目的的任务，比如一边写代码一边做调研一边管理文件。这时候它的上下文会变得非常嘈杂。解决方案是给每个目的分配一个独立的子 Agent，每个子 Agent 只关心自己的任务，上下文保持主题单一。主 Agent 负责调度，把各个子 Agent 的结果汇总。
这不仅是工程上的最佳实践，也是当前 Agent 设计的一个核心趋势。关于这方面的深入讨论，可以参考多 Agent 系统。
值得一提的是，Anthropic 在他们的 Building effective agents 一文中也提到了类似的思路——工具设计的关键不在于工具本身有多强大，而在于它如何帮助模型更好地管理上下文。
工具讲完了，但光有工具还不够。工具解决的是「怎么做」的问题，而 Agent 还需要知道「做什么」和「做成什么样」——这就轮到提示词登场了。
Prompt 与 Skill——经验的沉淀
有了 LLM 和 Tools，最后一个元素是 Prompt。说到提示词，很多人的印象还停留在"写一段话让模型做什么"。但在 Agent 场景下，提示词需要高度目标化和语义化——你必须非常明确地告诉 Agent 目标是什么、约束条件是什么、判断标准是什么。模糊的提示词在 Agent 系统中会被放大成灾难性的行为偏差。
但我想重点聊的不是怎么写提示词，而是一个更有长期价值的概念：Skill。
什么是 Skill？简单说，Skill 就是验证过的提示词。你写了一段提示词，跑了十次，效果稳定、结果可靠，于是把它封装起来，加上清晰的输入输出定义，下次直接复用——这就是一个 Skill。
这个过程跟人的学习很像。一个智商很高的人做事情，也不可能第一次就完美——他需要多次尝试、拿反馈、积累经验，最后形成方法论。AI 系统也一样。快反馈 + 经验积累 = 强大的系统。
这也是为什么我特别强调 Skill 的积累。每个人的需求不同，你在自己场景下调好的提示词，就是你的专属数字资产。行业里已经有不少这样的实践——Claude Code 的 Skills 系统、OpenAI 的 Custom GPTs，本质上都是在做同一件事：让用户把验证过的提示词沉淀下来。
我的方法论很简单：执行效果好 → 分析为什么好 → 封装为 Skill → 下次直接复用。这个循环转得越快，你的 Agent 系统就越强。
三个元素分别聊完了。但真正有趣的事情发生在你把它们组合起来的时候。
用三元素框架设计 Agent
到目前为止，我们分别聊了 LLM、Tools 和 Prompt 三个元素。但真正有趣的事情发生在你把它们组合起来的时候。
这里我想分享一个我自己的元范式：不要直接让 Agent 去执行任务，而是先让它构建一个「专门解决该任务的 Agent」。
什么意思？假设你要做一个自动化代码审查的 Agent。按照传统思路，你可能直接开始写提示词、配工具。但按照元范式的思路，你应该先分析这个任务需要什么：
- LLM 选型：代码审查需要强推理能力，所以选高能力模型；但如果只是做风格检查，用小模型就够了
- Tools 设计：需要读代码文件（文件操作）、需要了解项目规范（RAG）、可能需要并行审查多个文件（Sub-Agent）
- Prompt 设计：审查标准是什么、输出格式是什么、发现问题时怎么处理
确定了三元素之后，再生成 Agent 去执行，然后验证效果。效果好？封装成 Skill，下次直接用。效果不好？调整三元素的配置，再来一轮。
图 3：从任务到 Agent 的设计流程 — 分析需求 → 确定三元素 → 生成 → 执行 → 验证 → 封装 Skill
这其实就是 构建 Tiny Agent 里那个最简示例的放大版——即使是那个最简单的 Agent，你也能清晰地看到三元素的各自角色。
再往上一层看，这个流程本身就揭示了 Agent 编排的底层逻辑：知识库（外部信息）+ Agent（编排构造）+ 工作流（存档复用）。知识库提供信息输入，Agent 负责动态编排，工作流把验证过的方式沉淀下来。三元素框架不是理论，它就是你设计 Agent 时的操作清单。
回头看，Agent 开发这两件事最关键：快反馈循环和经验积累。快反馈让你能快速验证想法、发现问题；经验积累让你不用每次都从零开始。三元素框架就是帮你系统化地做这两件事的工具。
说到底，LLM 提供推理能力，Tools 管理上下文边界，Prompt 沉淀验证过的经验——三者缺一不可。没有好的模型，工具再精巧也是空转；没有合理的工具设计，模型再强也会被上下文拖垮；没有经过验证的提示词，每次都是重新发明轮子。把这三个变量调对了，Agent 自然就跑起来了。
这个框架不算什么高深理论，但确实帮我在做 Agent 项目时少走了不少弯路。希望对你也有用。
下一篇，我打算聊聊移动端 Agent 的从零开发——怎么在手机上跑起来一个真正有用的 Agent。这是一个我正在探索的方向，踩了不少新坑，到时候分享给你。
延伸阅读：
- 什么是 Agent — 如果你刚入门，从这里开始
- 构建 Tiny Agent — 最小化的 Agent 实现，感受三元素
- 多 Agent 系统 — Sub-Agent 设计模式的深入探讨