最近在做 Agent 应用开发过程中团队遇到了 AI 相关名词理解不对齐沟通成本高的问题。这篇文章主要整理 AI Agent 开发过程中可能涉及的概念并对每个概念做解释说明帮助正在经历从其他方向转型 AI Agent 开发的开发者及团队统一概念理解与沟通语言减少误解降低沟通成本。主要包含 LLM、Chat bot、Agent 等概念的说明。LLMLLM英文为 Large Language Model即大语言模型。首先从“模型”说起通过训练模型具备接收特定输入给出特定输出的能力。“语言模型”即限制了输入输出的内容为自然语言。“大语言模型”即指模型的参数量很大例如 25 年爆火的 DeepSeek R1其参数量为 671B。输入给 LLM 的自然语言会经 Transformer 转换为 token模型内部根据输入的 token预测应该输出什么 token最终再将 token 转为自然语言就是我们看到的“模型输出”。这也是 GPT 名称的由来Generative Pre-trained Transformer。LLM 工作原理Chat bot早期的语言模型擅长模仿。当用户问它“北京天气怎么样”时它会遵循这种模式来预测接下来的字符。于是可能会输出“南京天气怎么样”、“成都天气怎么样”。后来模型经过训练可以回答用户的问题。当用户再问它“北京天气怎么样”时它会回复一段看上去像回答的文本给人感觉就像在聊天一样。这就是聊天机器人早期 ChatGPT、豆包、DeepSeek App 等 AI 助手都可以统称为 Chat bot。Chat bot 的演进AgentPromptPrompt提示词。指发送给 LLM 的自然语言。通常分为两种system prompt系统提示词和 user prompt用户提示词。System prompt 通常内置在 agent 中用户不可修改或只能通过配置的方式追加部分内容到系统提示词中。User prompt 通常由用户提供但有时为了优化 Agent 能力或优化使用体验开发者也会替用户追加 user prompt。Re-ActLLM 的能力远远不止聊天如何让 LLM 的智力和实际场景结合完成实际落地应用这是研究者们一直在思考的问题。2022 年姚顺雨的一篇论文 Re-Act 指明了方向一个 reasoning-action-observation 的循环奠定了目前主流 Agent 的基本架构例如 Manus、Claude Code、Cursor 等。还以天气问题举例当用户问“北京明天天气怎么样”首先作为 LLM它会想reasoning“哦用户想知道明天天气怎么样但我并不知道答案我可以让用户去搜索一下”。于是LLM 的做出了自己的动作action它告诉用户“去 Google 搜索一下 ‘北京 明天 天气’把结果发给我”。用户照做把结果发给 LLM它就可以观察到observation“搜索结果显示明天是晴天”。于是 LLM 回答用户“北京明天是晴天”。这就是一个最简单的 Re-Act 例子。Re-Act 循环RAGRAG英文为 Retrieval-Augmented Generation即获取增强生成。还是刚刚的例子当用户问 LLM “北京明天天气怎么样”时有没有什么办法可以不麻烦用户去搜索我们可以先获取北京未来 7 天的天气把这段文本和用户的问题一起发给大模型。这样LLM 就能直接输出“北京明天是晴天”的结果了。这就是获取增强生成先获取上下文让模型根据上下文和问题总结输出正确的答案。这里还有一个容易混淆的名词即 RAG 和向量数据库Vector Database。两者的关系是RAG 的 Retrieval获取部分可以通过向量数据库来获取相关上下文但不是必须。例如我们刚刚举的例子”把北京过去七天的天气情况告诉模型”可能是一段普通文本或 JSON 数据不一定是从向量数据库中查询得出的。RAGTool call接着上一个问天气的例子当用户问 LLM “明天北京天气怎么样如果是晴天帮我买一张天坛的门票”。天气信息可以 RAG但“天坛门票”没法“获取增强生成”。它会回答用户“明天天气不错你可以去 xxx 购买门票”。有没有什么办法可以让用户不用亲自去买门票呢我们可以提供给 LLM 一个“购买天坛门票”的工具让模型可以告诉我们的代码需要调用这个工具。我们在代码里执行购买门票的工具并将工具执行结果告诉模型比如购买成功了。这时模型会观察到工具调用的结果告诉用户”明天是晴天门票已经帮你买好了”。Tool callMCPMCP英文为 Model Context Protocol即模型上下文协议。通过 tool call我们解决了模型无法与外部系统交互的问题。但作为一个 Agent例如 Manus显然不应该内置一个“购买天坛门票”的 tool 给模型使用。这时就可以基于模型上下文协议MCP通过提供一个 MCP Server 的方式让 LLM 可以调用 MCP Server 声明的 tool实现和外部系统的交互。请注意MCP 本身指的就是一种协议而不是一个工具集。在沟通中经常能听到这样的一些误用“MCP 协议”或“我们应该提供什么 MCP 给他们用”。翻译成中文就是“模型上下文协议协议”和“我们应该提供什么模型上下文协议给他们用”。这听起来太奇怪了。如果只是普通的 AI 使用者当然没必要区分这么清楚。但作为 AI Agent 建造者无论是否为技术岗位都应该正确使用这个概念。在 MCP 中定义了三个参与者Participants即 MCP HostMCP Client和 MCP Server。MCP Host即支持 MCP 协议的整个应用例如 Manus、Claude Code、Cursor。MCP Client实现于 MCP Host 中用于从 MCP Server 获取可用的 tool 列表并告诉 LLM。MCP Server通过标准协议提供 tool也可以通过例如 MCP Apps 之类的 extensions实现可交互的 UI 渲染能力。MCPHuman-in-the-loop首先需要理解“loop”指的是什么。在 Agent 执行任务的过程中在 LLM 输出最终回复之前LLM 调用 tooltool 的结果传递给 LLM这个过程不断循环就是“loop”。那么什么是 HITLHuman-in-the-loop目前 Agent 业内对 HITL 没有统一的、明确的定义。通常情况下在 Agent loop 中有两种情况需要 human 参与。一是需要人工审批一个 tool 是否应该使用特定参数被调用。一是需要人的输入作为 tool result 存在于 LLM 上下文中。LangChain 定义的 HITL 特指执行 tool call 之前的用户审批确认要不要执行这个 tool。Claude 没有特别使用 HITL 这个词而是统称为 user input。分为tool approval request和clarifying request分别对应我们上述的两种需要 human 参与的情况。个人更倾向于 Claude 对 HITL 的定义。因为这两种本质都属于中断 Agent loop等待用户输入只是需要用户输入的目的以及用户输入的内容不太一样。即 HITL 分为两种类型一种是Human as gatekeeper守门员另一种是Human as tool作为提供信息的工具。两种 HITL 区别如下。Human as gatekeeperHuman as tool触发基于规则LLM 通过 tool call 触发Human 职责Approve / Reject / Edit通常不建议使用提供信息、澄清需求、做出选择等目的安全和控制防止意外的副作用人与 LLM 协作补齐 LLM 上下文在 Agent loop 中的位置LLM tool call 之后tool 实际执行之前与人交互是 tool 的执行过程与上下文的关系不一定存在于上下文中人的输入是 tool result一定存在于上下文中为什么需要 HITL首先是 Human as gatekeeper。以 Claude Code 之类的 Agent 举例这些 Agent 有 Bash tool某些 Bash 命令可能有操作风险比如rm命令。在 LLM call Bash tool 之前需要人工确认是否同意用 xxx 参数调用 Bash tool。这就是需要 Human as gatekeeper 的原因。其次是 Human as tool。以 Claude Code 中 AskUserQuestion tool 为例Agent loop 中LLM 需要用户提供额外信息可以通过这个 tool要求用户输入。用户的输入会作为 tool result 存在于 LLM 上下文中LLM 通过观察 tool result再规划下一步的 action。对用户来说两种 HITL 的输入输出分别是什么首先Human as gatekeeper。基于规则触发因此给用户的输入应该是预先确定的三类选项同意Approve、修改Edit和拒绝Reject。常用的是 Approve 和 Reject。Edit 由于会修改 tool call 的参数可能会造成 LLM context confuse通常不建议使用。而用户的输出就是决策 Approve 还是 Reject 这次 tool 的执行。如果用户 Approve则 tool 会完成执行并将获取到的结果作为 tool result 给到 LLM 的 context list 中。如果用户 Reject则 tool 不会实际执行。Agent 开发者会构造一条 tool result告诉 LLM 这次执行被拒绝了LLM 会基于这次 action 的结果做观察规划下一步的 action。其次Human as tool。基于 LLM 的 tool call 触发这种 HITL 的触发与否、触发时的数据内容都是不确定的。我们只能通过 JSON schema定义这个 tool 的入参数据结构。对用户而言接收的输入是模型生成的、符合特定数据结构的自然语言。而用户的输出通常同样是自然语言也可能会支持多模态。需要注意的是有另一种交互同样需要用户输入信息特别容易和 HITL 混淆但它不是 HITL。仍然以 Claude Code 举例即是 Claude Code 输出的最终结果中要求用户输入的问句。它本质只是 LLM 的最终输出结果。此时一轮 Agent loop 已经结束用户再次输入消息发送给 Agent会开启下一轮的 Agent loop同一个会话内携带历史上下文。因此这种交互不是 HITL。Human-in-the-loopContext EngineeringContext Engineering即上下文工程。在 Agent loop 中system prompt、user prompt、一轮一轮的 tool call 和 tool result会快速填充上下文。但 LLM 的 context window上下文窗口是有限的现在的大模型 context window 通常为 200K tokens部分模型支持 1M tokens。因此需要做上下文工程对 LLM 接收的 context list 进行控制。上下文工程可能有很多不同的手段但万变不离其宗。下面将介绍几种常见的概念。Agent Skills这是 2025 年 10 月发布至今AI 相关圈子内最火的名词之一。特别是“养虾”热潮之后更是将这个名词的热度炒到了巅峰。经常能听到这样的言论“给你的龙虾一个 xxx skill它就能 xxx 了”。听起来似乎 skill 能解决所有问题。但究其本质Skill 到底是什么为了解决什么问题我们可以接着刚刚“查天气”和“逛天坛”的例子。我们给了 LLM 查天气和买门票的 toolLLM 只知道这两个 tool 的参数数据结构不知道要怎么使用这两个 tool才能满足用户的要求。这时可能有几种解决方案。一是做一个“旅游 Agent”在 system prompt 里告诉 LLM 怎么使用这两个 tool。但这个 Agent 无法完成其他任务或者说要完成其他任务需要修改 system prompt。有可能修改后更多的上下文 confuse 了 LLM导致什么任务都无法完成。这个解决方案不可行。二是某些 Prompt 高手用户会手动告诉 Agent应该怎么使用这两个 tool。这是很长一段 user prompt每次都输入很麻烦而且用户很难管理这段 Prompt 模板。有没有什么更优雅的方式呢Claude Skills后来发展为 Agent Skills 标准应运而生。所以 Skill 本质就是一段 prompt 模板。为了解决动态注入上下文的效率问题。至于“上下文渐进式披露”“脚本执行能力”这都是基于 LLM 能调用 Bash tool自然而然的收益。即使不遵循 Skills 规范在一个 markdown 文件里提及另一个 markdown 文件LLM 也会在需要的情况下读取对应的 markdown 文件做到渐进披露上下文。MemoryMemory记忆通常分为短期记忆和长期记忆。短期记忆很好理解同一个会话中几条消息之前用户给 LLM 说了什么LLM 给我回复了什么希望在这次新发消息时LLM 还有上下文。通常在用户新发消息时把历史消息带给 LLM 即可实现。长期记忆通常是指跨会话的上下文传递。例如用户在会话 1 中告诉 LLM 他是一名程序员在会话 2 中他希望不用再次提及LLM 也可以知道他是程序员。要满足这个需求最简单的实现是在会话 2 中把会话 1 的历史消息也告诉 LLM。但这样做会引入其他问题因为会话 1 和 2 可能完全是不同的话题可能会 confuse LLM。通常在 Agent 中要实现长期记忆会在用户给 LLM 发送 prompt 时追加一个外挂的步骤提取值得作为长期记忆的信息存储起来同时提取之前存储的长期记忆中与本次任务相关的部分替用户追加到 user prompt 里。这样看起来 Agent 就具备了长期记忆能力。但实际上只是 RAG 的一种实现方式。MemorySub-agents不要把“人”生而为人的限制生搬硬套给 Agent。—— Peak Ji from Manus首先需要明确sub-agent 最大的作用是隔离上下文而不是“过家家”。在解决一些长难任务需要基于 wide 和 deep research获取充足上下文的基础上再开始完成任务。如果不考虑 sub-agent所有的上下文都在同一个 LLM 的 context list 中有可能上下文快速积累导致 research 还没做完就达到 LLM 的 context window 限制长难任务无法被完成。但重新观察填满 LLM context window 的上下文可能很多都是与完成任务本身无关的可能只需要这些上下文给出一个能或不能做某件事的结论。这些上下文不出现在 LLM context window 中也可以只要有最后的结论即可。这时就适合使用 sub-agentsub-agent 会维护一个单独的 context list把不必要的出现在主 agent 中的上下文隔离出来只告诉主 agent 最终的结论。这样主 agent 的上下文中就不会出现与完成任务本身无关的部分了。前段时间 OpenClaw 爆火有人设计了一个“三省六部制”的 Agent 体系这就是一个使用 sub-agent 来“过家家”的例子是 sub-agent 使用的反例。首先对于“过家家”中的每个角色可能仍然会遇到需要 wide / deep research上下文快速填满无法继续“过家家”的问题。其次不同 agent 之间上下文的传递、共享以及它们之间的交互方式是一个复杂工程。人和人之间的沟通尚存在这么多上下文的不对齐和误解没有合理的设计agent 之间的上下文也会有很多 gap导致整个系统的效果大打折扣。Sub-agentsContext Offload / Compaction即使通过合理拆分 sub-agent可以规避一部分 context window 限制的问题但对于长难任务而言这可能是不够的。并且对于 LLM 来说并不是 context window 完全填满才会影响输出当上下文达到一定长度时LLM 会感受到 context pressure输出 end of sequence token 的几率会显著上升。表现为输出质量断崖式下降开始疯狂输出 bullet list开始倾向于写总结性的句子并且写短。所以需要通过上下文卸载Offload、压缩Compaction来解决这个问题。在长难任务中Agent 上下文可能有一部分在使用过后就不再有必要了。例如 Coding Agent 读了文件 A但后续的操作不需要文件 A 的内容在 context list 中。此时可以通过修改历史消息把原本文件 A 的内容替换为告诉 LLM文件 A 的内容在硬盘 xxx 位置如果有需要可以重新读取。这就是上下文卸载把 context list 里的上下文通过一个 file system可能是本地也可能是沙盒卸载到外部有需要时再重新加载。随着上下文的累积卸载可能也无法满足要求这时可以对历史的上下文进行总结用总结后的文本代替所有的历史上下文。这就是上下文压缩。上下文卸载可以视为一种无损的 context window 释放方式因为历史上下文并没有丢失随时可以重新加入 context list 中而上下文压缩通常是有损的历史上下文中的一些细节可能在总结的过程中被丢弃掉。Context Offload / CompactionHarnessHarness中文原意为“马缰”“缰绳”。在 Agent 中LLM 就是一匹马除了 LLM 的一切都是 harness。给 LLM 设计的 tool、所做的上下文工程都是 harness 的一部分。Harness 相比于 Framework框架抽象层级更高。Framework 只提供了制造马缰的方法而 Harness 才是完整的马缰。例如 LangChain 相关的包中LangGraph 是底层的流程控制 FrameworkLangChain 是 Agent 相关的 Framework而 DeepAgents 是 Agent Harness。DeepAgents 在 LangChain 的基础上提供了内置 tool 以及上下文工程相关的封装因此它是 Harness 而不是 Framework。HarnessTrace EvaluationAgent 开发与传统软件开发最大的不同是传统软件开发中软件的极大部分逻辑是写在代码里的数据从哪来传递什么参数给哪个函数先执行什么函数再执行哪段逻辑……这些都是写在代码里的而 Agent 开发中由于函数执行是通过 LLM 返回的 tool call 以及对应参数触发所以直到 Agent 实际上线运行之前开发者都无法知道 Agent 会如何表现。因此trace追踪 evaluation评估在 Agent 开发中特别重要。一次线上的问题排查我们需要知道中间执行了哪些 tool call其中哪些是不符合预期的一次代码或 prompt 的变更我们需要在上线前评估出会对 Agent 在各个方面的表现产生什么影响。Trace Evaluation一些个人思考Workflow vs AgentWorkflow工作流是指执行逻辑和步骤由代码提前定义好的系统。Workflow 中可能也涉及 LLM 节点但大多的功能是做意图识别、信息提取、总结输出等工作工作职责确定功能单一不需要或很少需要给 LLM 提供 tool只需要提供 prompt 即可。可能有人会把包含 LLM 的 Workflow 称作“Agentic Workflow”我的观点是不管前面的形容词怎么加都还是 Workflow和 Agent 完全是两个东西。Agent 是指执行逻辑和顺序由 LLM 通过 tool call 动态控制的系统。与 Workflow 最大的区别是「逻辑通过代码预先定义」还是「逻辑通过 LLM 的 tool call 动态控制」。Workflow vs Agent因此Agent 的主体代码逻辑通常很简单以 OpenClaw 的底层依赖 pi-agent 代码为例只有两层循环。外层循环处理等待中的 message阻止 agent loop 结束内存循环处理一轮 agent loop 中的 tool call 和 messages。通用 Agent vs 垂直 Agent首先区分通用 Agent 和垂直 Agent主要应该从 Agent 的输入输出方面入手。对于通用 Agent例如 Manus、Claude Code、Cursor 之类它们把更多输入输出的责任交给了用户。作为用户在输入方面需要配置各类的 MCP server、skill甚至需要开发一些 MCP server 或 CLI 工具让这类通用 Agent 能够和现有的系统进行交互。在输出方面通常输出只会在通用 Agent 自己的平台上如果需要输出到其他系统例如飞书、Telegram 或其他内部系统需要做额外的配置或者有一定的适配开发工作量。对于垂直 Agent会替用户承担更多输入的责任并且在输出上也可能与通用 Agent 不同。以 Notion Agent 和 Figma Make 为例作为垂直 Agent它们替用户内置了操作 Notion 和 Figma 的 tool可以减少一部分需要用户输出的工作。在输出上Notion Agent 的输出会直接体现为文档的编辑结果Figma 的输出会直接体现为设计稿。而输入输出的不同通常在技术实现上体现在给 Agent 设计 tool 的不同。因此垂直 Agent 和通用 Agent在技术架构上是趋同的主要区别可能只在内置的 tool 不同。通用 Agent vs 垂直 Agent这就有另一个问题了作为 Notion、Figma 以及诸如此类的“工具类”平台应该给通用 Agent 做工具还是应该做自己的 Agent我的观点是应该做自己的 Agent但同时也应该给通用 Agent 做工具两者并不冲突。首先从用户视角看用户为 Notion / Figma 付费后需要再买个 Manus 或 Claude Code 的会员才能用 Agent 能力体验上会很奇怪。所以应该做自己的 Agent至少让只需要使用这一个工具的用户可以在同一个平台内拥有完整的使用体验。其次面向未来地看未来大部分软件其用户可能更多是 Agent 而非人类。通过 MCP server 或 CLI 这种能方便 Agent 使用的工具是一个软件未来还能有足够用户的基础。所以同时应该给通用 Agent 做工具。至于从商业视角看应不应该自己做 Agent这个存疑。因为截至 2025 年底即使是 Manus 这样成功的 Agent还是在花钱贴补用户体验 Agent 这种产品形态至少目前做 Agent 还不算 token 低买高卖的赚钱模式。普通人如何抓住AI大模型的风口领取方式在文末为什么要学习大模型目前AI大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 大模型作为其中的重要组成部分 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 为各行各业带来了革命性的改变和机遇 。目前开源人工智能大模型已应用于医疗、政务、法律、汽车、娱乐、金融、互联网、教育、制造业、企业服务等多个场景其中应用于金融、企业服务、制造业和法律领域的大模型在本次调研中占比超过30%。随着AI大模型技术的迅速发展相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业人工智能大潮已来不加入就可能被淘汰。如果你是技术人尤其是互联网从业者现在就开始学习AI大模型技术真的是给你的人生一个重要建议最后只要你真心想学习AI大模型技术这份精心整理的学习资料我愿意无偿分享给你但是想学技术去乱搞的人别来找我在当前这个人工智能高速发展的时代AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料能够帮助更多有志于AI领域的朋友入门并深入学习。真诚无偿分享vx扫描下方二维码即可加上后会一个个给大家发【附赠一节免费的直播讲座技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等欢迎大家~】大模型全套学习资料展示自我们与MoPaaS魔泊云合作以来我们不断打磨课程体系与技术内容在细节上精益求精同时在技术层面也新增了许多前沿且实用的内容力求为大家带来更系统、更实战、更落地的大模型学习体验。希望这份系统、实用的大模型学习路径能够帮助你从零入门进阶到实战真正掌握AI时代的核心技能01教学内容从零到精通完整闭环【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块内容比传统教材更贴近企业实战大量真实项目案例带你亲自上手搞数据清洗、模型调优这些硬核操作把课本知识变成真本事02适学人群应届毕业生无工作经验但想要系统学习AI大模型技术期待通过实战项目掌握核心技术。零基础转型非技术背景但关注AI应用场景计划通过低代码工具实现“AI行业”跨界。业务赋能突破瓶颈传统开发者Java/前端等学习Transformer架构与LangChain框架向AI全栈工程师转型。vx扫描下方二维码即可【附赠一节免费的直播讲座技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等欢迎大家~】本教程比较珍贵仅限大家自行学习不要传播更严禁商用03入门到进阶学习路线图大模型学习路线图整体分为5个大的阶段04视频和书籍PDF合集从0到掌握主流大模型技术视频教程涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向新手必备的大模型学习PDF书单来了全是硬核知识帮你少走弯路不吹牛真有用05行业报告白皮书合集收集70报告与白皮书了解行业最新动态0690份面试题/经验AI大模型岗位面试经验总结谁学技术不是为了赚$呢找个好的岗位很重要07 deepseek部署包技巧大全由于篇幅有限只展示部分资料并且还在持续更新中…真诚无偿分享vx扫描下方二维码即可加上后会一个个给大家发【附赠一节免费的直播讲座技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等欢迎大家~】
收藏 | AI Agent 开发核心概念解析：从 LLM 到 Sub-agents，小白也能轻松入门
最近在做 Agent 应用开发过程中团队遇到了 AI 相关名词理解不对齐沟通成本高的问题。这篇文章主要整理 AI Agent 开发过程中可能涉及的概念并对每个概念做解释说明帮助正在经历从其他方向转型 AI Agent 开发的开发者及团队统一概念理解与沟通语言减少误解降低沟通成本。主要包含 LLM、Chat bot、Agent 等概念的说明。LLMLLM英文为 Large Language Model即大语言模型。首先从“模型”说起通过训练模型具备接收特定输入给出特定输出的能力。“语言模型”即限制了输入输出的内容为自然语言。“大语言模型”即指模型的参数量很大例如 25 年爆火的 DeepSeek R1其参数量为 671B。输入给 LLM 的自然语言会经 Transformer 转换为 token模型内部根据输入的 token预测应该输出什么 token最终再将 token 转为自然语言就是我们看到的“模型输出”。这也是 GPT 名称的由来Generative Pre-trained Transformer。LLM 工作原理Chat bot早期的语言模型擅长模仿。当用户问它“北京天气怎么样”时它会遵循这种模式来预测接下来的字符。于是可能会输出“南京天气怎么样”、“成都天气怎么样”。后来模型经过训练可以回答用户的问题。当用户再问它“北京天气怎么样”时它会回复一段看上去像回答的文本给人感觉就像在聊天一样。这就是聊天机器人早期 ChatGPT、豆包、DeepSeek App 等 AI 助手都可以统称为 Chat bot。Chat bot 的演进AgentPromptPrompt提示词。指发送给 LLM 的自然语言。通常分为两种system prompt系统提示词和 user prompt用户提示词。System prompt 通常内置在 agent 中用户不可修改或只能通过配置的方式追加部分内容到系统提示词中。User prompt 通常由用户提供但有时为了优化 Agent 能力或优化使用体验开发者也会替用户追加 user prompt。Re-ActLLM 的能力远远不止聊天如何让 LLM 的智力和实际场景结合完成实际落地应用这是研究者们一直在思考的问题。2022 年姚顺雨的一篇论文 Re-Act 指明了方向一个 reasoning-action-observation 的循环奠定了目前主流 Agent 的基本架构例如 Manus、Claude Code、Cursor 等。还以天气问题举例当用户问“北京明天天气怎么样”首先作为 LLM它会想reasoning“哦用户想知道明天天气怎么样但我并不知道答案我可以让用户去搜索一下”。于是LLM 的做出了自己的动作action它告诉用户“去 Google 搜索一下 ‘北京 明天 天气’把结果发给我”。用户照做把结果发给 LLM它就可以观察到observation“搜索结果显示明天是晴天”。于是 LLM 回答用户“北京明天是晴天”。这就是一个最简单的 Re-Act 例子。Re-Act 循环RAGRAG英文为 Retrieval-Augmented Generation即获取增强生成。还是刚刚的例子当用户问 LLM “北京明天天气怎么样”时有没有什么办法可以不麻烦用户去搜索我们可以先获取北京未来 7 天的天气把这段文本和用户的问题一起发给大模型。这样LLM 就能直接输出“北京明天是晴天”的结果了。这就是获取增强生成先获取上下文让模型根据上下文和问题总结输出正确的答案。这里还有一个容易混淆的名词即 RAG 和向量数据库Vector Database。两者的关系是RAG 的 Retrieval获取部分可以通过向量数据库来获取相关上下文但不是必须。例如我们刚刚举的例子”把北京过去七天的天气情况告诉模型”可能是一段普通文本或 JSON 数据不一定是从向量数据库中查询得出的。RAGTool call接着上一个问天气的例子当用户问 LLM “明天北京天气怎么样如果是晴天帮我买一张天坛的门票”。天气信息可以 RAG但“天坛门票”没法“获取增强生成”。它会回答用户“明天天气不错你可以去 xxx 购买门票”。有没有什么办法可以让用户不用亲自去买门票呢我们可以提供给 LLM 一个“购买天坛门票”的工具让模型可以告诉我们的代码需要调用这个工具。我们在代码里执行购买门票的工具并将工具执行结果告诉模型比如购买成功了。这时模型会观察到工具调用的结果告诉用户”明天是晴天门票已经帮你买好了”。Tool callMCPMCP英文为 Model Context Protocol即模型上下文协议。通过 tool call我们解决了模型无法与外部系统交互的问题。但作为一个 Agent例如 Manus显然不应该内置一个“购买天坛门票”的 tool 给模型使用。这时就可以基于模型上下文协议MCP通过提供一个 MCP Server 的方式让 LLM 可以调用 MCP Server 声明的 tool实现和外部系统的交互。请注意MCP 本身指的就是一种协议而不是一个工具集。在沟通中经常能听到这样的一些误用“MCP 协议”或“我们应该提供什么 MCP 给他们用”。翻译成中文就是“模型上下文协议协议”和“我们应该提供什么模型上下文协议给他们用”。这听起来太奇怪了。如果只是普通的 AI 使用者当然没必要区分这么清楚。但作为 AI Agent 建造者无论是否为技术岗位都应该正确使用这个概念。在 MCP 中定义了三个参与者Participants即 MCP HostMCP Client和 MCP Server。MCP Host即支持 MCP 协议的整个应用例如 Manus、Claude Code、Cursor。MCP Client实现于 MCP Host 中用于从 MCP Server 获取可用的 tool 列表并告诉 LLM。MCP Server通过标准协议提供 tool也可以通过例如 MCP Apps 之类的 extensions实现可交互的 UI 渲染能力。MCPHuman-in-the-loop首先需要理解“loop”指的是什么。在 Agent 执行任务的过程中在 LLM 输出最终回复之前LLM 调用 tooltool 的结果传递给 LLM这个过程不断循环就是“loop”。那么什么是 HITLHuman-in-the-loop目前 Agent 业内对 HITL 没有统一的、明确的定义。通常情况下在 Agent loop 中有两种情况需要 human 参与。一是需要人工审批一个 tool 是否应该使用特定参数被调用。一是需要人的输入作为 tool result 存在于 LLM 上下文中。LangChain 定义的 HITL 特指执行 tool call 之前的用户审批确认要不要执行这个 tool。Claude 没有特别使用 HITL 这个词而是统称为 user input。分为tool approval request和clarifying request分别对应我们上述的两种需要 human 参与的情况。个人更倾向于 Claude 对 HITL 的定义。因为这两种本质都属于中断 Agent loop等待用户输入只是需要用户输入的目的以及用户输入的内容不太一样。即 HITL 分为两种类型一种是Human as gatekeeper守门员另一种是Human as tool作为提供信息的工具。两种 HITL 区别如下。Human as gatekeeperHuman as tool触发基于规则LLM 通过 tool call 触发Human 职责Approve / Reject / Edit通常不建议使用提供信息、澄清需求、做出选择等目的安全和控制防止意外的副作用人与 LLM 协作补齐 LLM 上下文在 Agent loop 中的位置LLM tool call 之后tool 实际执行之前与人交互是 tool 的执行过程与上下文的关系不一定存在于上下文中人的输入是 tool result一定存在于上下文中为什么需要 HITL首先是 Human as gatekeeper。以 Claude Code 之类的 Agent 举例这些 Agent 有 Bash tool某些 Bash 命令可能有操作风险比如rm命令。在 LLM call Bash tool 之前需要人工确认是否同意用 xxx 参数调用 Bash tool。这就是需要 Human as gatekeeper 的原因。其次是 Human as tool。以 Claude Code 中 AskUserQuestion tool 为例Agent loop 中LLM 需要用户提供额外信息可以通过这个 tool要求用户输入。用户的输入会作为 tool result 存在于 LLM 上下文中LLM 通过观察 tool result再规划下一步的 action。对用户来说两种 HITL 的输入输出分别是什么首先Human as gatekeeper。基于规则触发因此给用户的输入应该是预先确定的三类选项同意Approve、修改Edit和拒绝Reject。常用的是 Approve 和 Reject。Edit 由于会修改 tool call 的参数可能会造成 LLM context confuse通常不建议使用。而用户的输出就是决策 Approve 还是 Reject 这次 tool 的执行。如果用户 Approve则 tool 会完成执行并将获取到的结果作为 tool result 给到 LLM 的 context list 中。如果用户 Reject则 tool 不会实际执行。Agent 开发者会构造一条 tool result告诉 LLM 这次执行被拒绝了LLM 会基于这次 action 的结果做观察规划下一步的 action。其次Human as tool。基于 LLM 的 tool call 触发这种 HITL 的触发与否、触发时的数据内容都是不确定的。我们只能通过 JSON schema定义这个 tool 的入参数据结构。对用户而言接收的输入是模型生成的、符合特定数据结构的自然语言。而用户的输出通常同样是自然语言也可能会支持多模态。需要注意的是有另一种交互同样需要用户输入信息特别容易和 HITL 混淆但它不是 HITL。仍然以 Claude Code 举例即是 Claude Code 输出的最终结果中要求用户输入的问句。它本质只是 LLM 的最终输出结果。此时一轮 Agent loop 已经结束用户再次输入消息发送给 Agent会开启下一轮的 Agent loop同一个会话内携带历史上下文。因此这种交互不是 HITL。Human-in-the-loopContext EngineeringContext Engineering即上下文工程。在 Agent loop 中system prompt、user prompt、一轮一轮的 tool call 和 tool result会快速填充上下文。但 LLM 的 context window上下文窗口是有限的现在的大模型 context window 通常为 200K tokens部分模型支持 1M tokens。因此需要做上下文工程对 LLM 接收的 context list 进行控制。上下文工程可能有很多不同的手段但万变不离其宗。下面将介绍几种常见的概念。Agent Skills这是 2025 年 10 月发布至今AI 相关圈子内最火的名词之一。特别是“养虾”热潮之后更是将这个名词的热度炒到了巅峰。经常能听到这样的言论“给你的龙虾一个 xxx skill它就能 xxx 了”。听起来似乎 skill 能解决所有问题。但究其本质Skill 到底是什么为了解决什么问题我们可以接着刚刚“查天气”和“逛天坛”的例子。我们给了 LLM 查天气和买门票的 toolLLM 只知道这两个 tool 的参数数据结构不知道要怎么使用这两个 tool才能满足用户的要求。这时可能有几种解决方案。一是做一个“旅游 Agent”在 system prompt 里告诉 LLM 怎么使用这两个 tool。但这个 Agent 无法完成其他任务或者说要完成其他任务需要修改 system prompt。有可能修改后更多的上下文 confuse 了 LLM导致什么任务都无法完成。这个解决方案不可行。二是某些 Prompt 高手用户会手动告诉 Agent应该怎么使用这两个 tool。这是很长一段 user prompt每次都输入很麻烦而且用户很难管理这段 Prompt 模板。有没有什么更优雅的方式呢Claude Skills后来发展为 Agent Skills 标准应运而生。所以 Skill 本质就是一段 prompt 模板。为了解决动态注入上下文的效率问题。至于“上下文渐进式披露”“脚本执行能力”这都是基于 LLM 能调用 Bash tool自然而然的收益。即使不遵循 Skills 规范在一个 markdown 文件里提及另一个 markdown 文件LLM 也会在需要的情况下读取对应的 markdown 文件做到渐进披露上下文。MemoryMemory记忆通常分为短期记忆和长期记忆。短期记忆很好理解同一个会话中几条消息之前用户给 LLM 说了什么LLM 给我回复了什么希望在这次新发消息时LLM 还有上下文。通常在用户新发消息时把历史消息带给 LLM 即可实现。长期记忆通常是指跨会话的上下文传递。例如用户在会话 1 中告诉 LLM 他是一名程序员在会话 2 中他希望不用再次提及LLM 也可以知道他是程序员。要满足这个需求最简单的实现是在会话 2 中把会话 1 的历史消息也告诉 LLM。但这样做会引入其他问题因为会话 1 和 2 可能完全是不同的话题可能会 confuse LLM。通常在 Agent 中要实现长期记忆会在用户给 LLM 发送 prompt 时追加一个外挂的步骤提取值得作为长期记忆的信息存储起来同时提取之前存储的长期记忆中与本次任务相关的部分替用户追加到 user prompt 里。这样看起来 Agent 就具备了长期记忆能力。但实际上只是 RAG 的一种实现方式。MemorySub-agents不要把“人”生而为人的限制生搬硬套给 Agent。—— Peak Ji from Manus首先需要明确sub-agent 最大的作用是隔离上下文而不是“过家家”。在解决一些长难任务需要基于 wide 和 deep research获取充足上下文的基础上再开始完成任务。如果不考虑 sub-agent所有的上下文都在同一个 LLM 的 context list 中有可能上下文快速积累导致 research 还没做完就达到 LLM 的 context window 限制长难任务无法被完成。但重新观察填满 LLM context window 的上下文可能很多都是与完成任务本身无关的可能只需要这些上下文给出一个能或不能做某件事的结论。这些上下文不出现在 LLM context window 中也可以只要有最后的结论即可。这时就适合使用 sub-agentsub-agent 会维护一个单独的 context list把不必要的出现在主 agent 中的上下文隔离出来只告诉主 agent 最终的结论。这样主 agent 的上下文中就不会出现与完成任务本身无关的部分了。前段时间 OpenClaw 爆火有人设计了一个“三省六部制”的 Agent 体系这就是一个使用 sub-agent 来“过家家”的例子是 sub-agent 使用的反例。首先对于“过家家”中的每个角色可能仍然会遇到需要 wide / deep research上下文快速填满无法继续“过家家”的问题。其次不同 agent 之间上下文的传递、共享以及它们之间的交互方式是一个复杂工程。人和人之间的沟通尚存在这么多上下文的不对齐和误解没有合理的设计agent 之间的上下文也会有很多 gap导致整个系统的效果大打折扣。Sub-agentsContext Offload / Compaction即使通过合理拆分 sub-agent可以规避一部分 context window 限制的问题但对于长难任务而言这可能是不够的。并且对于 LLM 来说并不是 context window 完全填满才会影响输出当上下文达到一定长度时LLM 会感受到 context pressure输出 end of sequence token 的几率会显著上升。表现为输出质量断崖式下降开始疯狂输出 bullet list开始倾向于写总结性的句子并且写短。所以需要通过上下文卸载Offload、压缩Compaction来解决这个问题。在长难任务中Agent 上下文可能有一部分在使用过后就不再有必要了。例如 Coding Agent 读了文件 A但后续的操作不需要文件 A 的内容在 context list 中。此时可以通过修改历史消息把原本文件 A 的内容替换为告诉 LLM文件 A 的内容在硬盘 xxx 位置如果有需要可以重新读取。这就是上下文卸载把 context list 里的上下文通过一个 file system可能是本地也可能是沙盒卸载到外部有需要时再重新加载。随着上下文的累积卸载可能也无法满足要求这时可以对历史的上下文进行总结用总结后的文本代替所有的历史上下文。这就是上下文压缩。上下文卸载可以视为一种无损的 context window 释放方式因为历史上下文并没有丢失随时可以重新加入 context list 中而上下文压缩通常是有损的历史上下文中的一些细节可能在总结的过程中被丢弃掉。Context Offload / CompactionHarnessHarness中文原意为“马缰”“缰绳”。在 Agent 中LLM 就是一匹马除了 LLM 的一切都是 harness。给 LLM 设计的 tool、所做的上下文工程都是 harness 的一部分。Harness 相比于 Framework框架抽象层级更高。Framework 只提供了制造马缰的方法而 Harness 才是完整的马缰。例如 LangChain 相关的包中LangGraph 是底层的流程控制 FrameworkLangChain 是 Agent 相关的 Framework而 DeepAgents 是 Agent Harness。DeepAgents 在 LangChain 的基础上提供了内置 tool 以及上下文工程相关的封装因此它是 Harness 而不是 Framework。HarnessTrace EvaluationAgent 开发与传统软件开发最大的不同是传统软件开发中软件的极大部分逻辑是写在代码里的数据从哪来传递什么参数给哪个函数先执行什么函数再执行哪段逻辑……这些都是写在代码里的而 Agent 开发中由于函数执行是通过 LLM 返回的 tool call 以及对应参数触发所以直到 Agent 实际上线运行之前开发者都无法知道 Agent 会如何表现。因此trace追踪 evaluation评估在 Agent 开发中特别重要。一次线上的问题排查我们需要知道中间执行了哪些 tool call其中哪些是不符合预期的一次代码或 prompt 的变更我们需要在上线前评估出会对 Agent 在各个方面的表现产生什么影响。Trace Evaluation一些个人思考Workflow vs AgentWorkflow工作流是指执行逻辑和步骤由代码提前定义好的系统。Workflow 中可能也涉及 LLM 节点但大多的功能是做意图识别、信息提取、总结输出等工作工作职责确定功能单一不需要或很少需要给 LLM 提供 tool只需要提供 prompt 即可。可能有人会把包含 LLM 的 Workflow 称作“Agentic Workflow”我的观点是不管前面的形容词怎么加都还是 Workflow和 Agent 完全是两个东西。Agent 是指执行逻辑和顺序由 LLM 通过 tool call 动态控制的系统。与 Workflow 最大的区别是「逻辑通过代码预先定义」还是「逻辑通过 LLM 的 tool call 动态控制」。Workflow vs Agent因此Agent 的主体代码逻辑通常很简单以 OpenClaw 的底层依赖 pi-agent 代码为例只有两层循环。外层循环处理等待中的 message阻止 agent loop 结束内存循环处理一轮 agent loop 中的 tool call 和 messages。通用 Agent vs 垂直 Agent首先区分通用 Agent 和垂直 Agent主要应该从 Agent 的输入输出方面入手。对于通用 Agent例如 Manus、Claude Code、Cursor 之类它们把更多输入输出的责任交给了用户。作为用户在输入方面需要配置各类的 MCP server、skill甚至需要开发一些 MCP server 或 CLI 工具让这类通用 Agent 能够和现有的系统进行交互。在输出方面通常输出只会在通用 Agent 自己的平台上如果需要输出到其他系统例如飞书、Telegram 或其他内部系统需要做额外的配置或者有一定的适配开发工作量。对于垂直 Agent会替用户承担更多输入的责任并且在输出上也可能与通用 Agent 不同。以 Notion Agent 和 Figma Make 为例作为垂直 Agent它们替用户内置了操作 Notion 和 Figma 的 tool可以减少一部分需要用户输出的工作。在输出上Notion Agent 的输出会直接体现为文档的编辑结果Figma 的输出会直接体现为设计稿。而输入输出的不同通常在技术实现上体现在给 Agent 设计 tool 的不同。因此垂直 Agent 和通用 Agent在技术架构上是趋同的主要区别可能只在内置的 tool 不同。通用 Agent vs 垂直 Agent这就有另一个问题了作为 Notion、Figma 以及诸如此类的“工具类”平台应该给通用 Agent 做工具还是应该做自己的 Agent我的观点是应该做自己的 Agent但同时也应该给通用 Agent 做工具两者并不冲突。首先从用户视角看用户为 Notion / Figma 付费后需要再买个 Manus 或 Claude Code 的会员才能用 Agent 能力体验上会很奇怪。所以应该做自己的 Agent至少让只需要使用这一个工具的用户可以在同一个平台内拥有完整的使用体验。其次面向未来地看未来大部分软件其用户可能更多是 Agent 而非人类。通过 MCP server 或 CLI 这种能方便 Agent 使用的工具是一个软件未来还能有足够用户的基础。所以同时应该给通用 Agent 做工具。至于从商业视角看应不应该自己做 Agent这个存疑。因为截至 2025 年底即使是 Manus 这样成功的 Agent还是在花钱贴补用户体验 Agent 这种产品形态至少目前做 Agent 还不算 token 低买高卖的赚钱模式。普通人如何抓住AI大模型的风口领取方式在文末为什么要学习大模型目前AI大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 大模型作为其中的重要组成部分 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 为各行各业带来了革命性的改变和机遇 。目前开源人工智能大模型已应用于医疗、政务、法律、汽车、娱乐、金融、互联网、教育、制造业、企业服务等多个场景其中应用于金融、企业服务、制造业和法律领域的大模型在本次调研中占比超过30%。随着AI大模型技术的迅速发展相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业人工智能大潮已来不加入就可能被淘汰。如果你是技术人尤其是互联网从业者现在就开始学习AI大模型技术真的是给你的人生一个重要建议最后只要你真心想学习AI大模型技术这份精心整理的学习资料我愿意无偿分享给你但是想学技术去乱搞的人别来找我在当前这个人工智能高速发展的时代AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料能够帮助更多有志于AI领域的朋友入门并深入学习。真诚无偿分享vx扫描下方二维码即可加上后会一个个给大家发【附赠一节免费的直播讲座技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等欢迎大家~】大模型全套学习资料展示自我们与MoPaaS魔泊云合作以来我们不断打磨课程体系与技术内容在细节上精益求精同时在技术层面也新增了许多前沿且实用的内容力求为大家带来更系统、更实战、更落地的大模型学习体验。希望这份系统、实用的大模型学习路径能够帮助你从零入门进阶到实战真正掌握AI时代的核心技能01教学内容从零到精通完整闭环【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块内容比传统教材更贴近企业实战大量真实项目案例带你亲自上手搞数据清洗、模型调优这些硬核操作把课本知识变成真本事02适学人群应届毕业生无工作经验但想要系统学习AI大模型技术期待通过实战项目掌握核心技术。零基础转型非技术背景但关注AI应用场景计划通过低代码工具实现“AI行业”跨界。业务赋能突破瓶颈传统开发者Java/前端等学习Transformer架构与LangChain框架向AI全栈工程师转型。vx扫描下方二维码即可【附赠一节免费的直播讲座技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等欢迎大家~】本教程比较珍贵仅限大家自行学习不要传播更严禁商用03入门到进阶学习路线图大模型学习路线图整体分为5个大的阶段04视频和书籍PDF合集从0到掌握主流大模型技术视频教程涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向新手必备的大模型学习PDF书单来了全是硬核知识帮你少走弯路不吹牛真有用05行业报告白皮书合集收集70报告与白皮书了解行业最新动态0690份面试题/经验AI大模型岗位面试经验总结谁学技术不是为了赚$呢找个好的岗位很重要07 deepseek部署包技巧大全由于篇幅有限只展示部分资料并且还在持续更新中…真诚无偿分享vx扫描下方二维码即可加上后会一个个给大家发【附赠一节免费的直播讲座技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等欢迎大家~】
