大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
     
本文深入浅出地介绍了AI Agent的概念、架构和应用开发，从基础概念出发，逐步深入到架构演进和开发平台，旨在帮助小白程序员快速入门并理解AI Agent的核心知识。文章涵盖了Agent的定义、LLM的特性、MCP和RAG协议、Agent Skills和Teams等关键要素，并通过Coze平台的实战案例，让读者对AI Agent的应用开发有更直观的认识。
 

最近在学习AI Agent，本文主要记录AI Agent各方面的知识，包含相关概念、架构、应用开发，可以对AI Agent有初步的理解。

1. 1 Agent

---

Agent的定义是什么？是大模型调用API吗？不，这只是对Agent概念的一个简单的认知，我们还是非常有必要了解一下真正的Agent的含义是什么。

国内很多厂商和平台将Agent翻译为“智能体”，这种翻译并不完全准确。如果从最原始的词典里去查的话，Agent这个英文单词实际上是代理的意思。这里的代理指的是让大模型“代理/模拟”「人」的行为，使用某些“工具/功能”来完成某些“任务”的能力。所以国外使用Agent这个词来代表让大模型调用工具或功能帮人完成某些事情的过程，其实还是比较形象的。因此，只要符合这个定义的，其实就是一种Agent。

有许多大厂、独角兽公司、研究所、高校，也给Agent下过许多定义，比较经典的一个定义是OpenAI的研究主管Lilian Weng给出的定义是：Agent = 大模型（LLM）+ 规划（Planning）+ 记忆（Memory）+ 工具使用（Tool Use）。这个定义实际上是从技术实现的角度对Agent进行了定义，它指的是要实现一个Agent，就需要支持这些能力，它需要基于大模型，需要有规划的能力，能思考接下来要做的事情，需要有记忆，能够读取长期记忆和短期记忆，需要能够使用工具，他是将支持这些能力的集合体定义为了Agent。

另外的一个定义是复旦大学NLP团队给出来的，他们认为Agent的概念框架包括三个组件：大脑、感知、行动。大脑模块作为控制器，承担记忆、思考和决策等基本任务。感知模块从外部环境感知并处理多模态信息，而行动模块则使用工具执行任务并影响周围环境。比如：当人类询问是否会下雨时，感知模块将指令转换为大模型可以理解的表示，然后，大脑会根据当前天气和互联网天气报告开始推理，最后，行动模块作出回应并将雨伞递给人类。通过重复上述过程，Agent可以不断获得反馈并与环境互动。

1. 2 LLM

---

LLM（Large Language Model，大语言模型） 是基于Transformer 架构、用海量文本数据预训练、具备强大语言理解与生成能力的深度学习模型，核心是通过预测下一个词 / 字，学习人类语言的语法、逻辑、常识与世界知识，能完成对话、写作、翻译、代码、推理等几乎所有自然语言任务。简单说：它是能 “懂人话、说人话、做人事” 的超级文本 AI。

核心技术基础：Transformer

LLM 的底层都是 2017 年谷歌提出的Transformer架构，核心突破是自注意力机制（Self-Attention）：

• 能同时捕捉文本中远距离词与词的关联（比如长句里主语和谓语的关系），解决了早期 RNN/LSTM “记不住长文本” 的问题
• 并行计算效率极高，支撑模型从千万参数→百亿→千亿→万亿参数的规模跃升

LLM 的三大关键特性

1. 涌现能力（Emergent Ability）

当模型参数规模、训练数据、算力达到临界点（通常百亿 / 千亿参数），会突然出现小模型没有的能力：

• 复杂逻辑推理（数学题、逻辑题、因果分析）
• 少样本 / 零样本学习（给 1-2 个例子就能做新任务，不用重新训练）
• 常识理解、跨语言迁移、思维链（CoT）推理

2. 上下文学习（In-Context Learning, ICL）

不用微调、不用更新参数，直接在输入提示（Prompt）里给例子 / 规则，模型就能按要求完成任务（比如 “把下面句子翻译成古文：xxx”），这是 LLM 最实用的核心能力。

3. 通用适配性

一个模型通吃 NLP 全任务：对话、摘要、翻译、写代码、写文案、做表格、改病句、问答、情感分析、信息抽取，不需要为每个任务单独训练专用模型。

LLM 的训练流程

1. 预训练（Pre-training）—— 打基础

• 数据：万亿级 tokens（词 / 字 / 符号），覆盖书籍、网页、论文、代码、对话等全领域文本
• 目标：无监督学习，预测下一个 token（Next Token Prediction）
• 结果：得到基座模型（Base LLM）—— 懂语言、有知识，但输出随机、不一定符合人类偏好

2. 有监督微调（SFT, Supervised Fine-Tuning）—— 对齐任务

• 用高质量人工标注数据（问答、对话、指令），让基座模型学会 “按人类指令做事”，输出更规范、更贴合任务

3. 人类反馈强化学习（RLHF, Reinforcement Learning from Human Feedback）—— 对齐偏好

• 训练奖励模型（RM）：人工对模型输出排序（哪个更好、更安全、更有用）
• 用 PPO 算法优化：让模型优先输出人类喜欢、安全、有用的内容，减少幻觉、偏见、有害输出

主流 LLM 代表（国内外）

国外

• GPT 系列（OpenAI）：GPT-5.4、GPT-4、GPT-4o（多模态，文本 + 图像 + 语音），标杆级通用大模型
• Llama 系列（Meta）：Llama ²⁄₃，开源基座，全球开发者二次开发最多
• Claude（Anthropic）：Claude 4 Opus/Sonnet/Haiku，长上下文、高安全、低幻觉
• Gemini（Google）：多模态大模型，文本、图像、音频、视频全支持

国内

• 豆包（字节跳动）：通用对话大模型，支持多轮、长文本、代码、创作，轻量化 + 高性能
• 文心一言（百度）、通义千问（阿里）、讯飞星火（科大讯飞）、智谱清言（智谱 AI）、混元（腾讯）等

关键参数与指标（怎么看 LLM 好坏）

1. 参数规模（Parameters）：百亿→千亿→万亿，越大通常能力越强，但算力 / 成本也越高（不是越大越好，要平衡）
2. 上下文窗口（Context Window）：一次能处理的最大 token 数（比如 8k、32k、128k、1M），窗口越大，越能读长文档、写长内容、记住对话历史
3. 幻觉率（Hallucination）：编造事实、错误信息的概率，越低越好
4. 推理 / 理解能力：常用 MMLU、GSM8K、HumanEval 等基准测试，测知识、数学、代码、逻辑
5. 对齐度：是否符合人类价值观、安全规范、指令遵循度
6. 3 MCP

---

MCP（Model Context Protocol，模型上下文协议）是由人工智能公司 Anthropic 于 2024 年 11 月 24 日正式发布并开源的协议标准。Anthropic 公司是由前 OpenAI 核心人员成立的人工智能公司，其发布的 Claude 系列模型是为数较少的可以和 GPT 系列抗衡的模型。

MCP让AI模型具备了连接世界的能力。它并不改变模型推理逻辑，而是建立了一个安全、标准、可编排的上下文通道。借助MCP,AI系统可以像模块化操作系统那样，把模型、工具、资源与提示模板拼装成可协作的智能体生态。

为什么需要 MCP

MCP 协议旨在解决大型语言模型（LLM）与外部数据源、工具间的集成难题，被比喻为“AI应用的USB-C接口“。通过标准化通信协议，将传统的“M×N集成问题”（即多个模型与多个数据源的点对点连接）转化为“M+N模式”，大幅降低开发成本。

在 MCP 协议没有推出之前：

1. 智能体开发平台需要单独的插件配置和插件执行模型，以屏蔽不通工具之间的协议差异，提供统一的接口给 Agent 使用；
2. 开发者如果要增加自定义的工具，需要按照平台规定的 http 协议实现工具。并且不同的平台之间的协议可能不同；
3. “M×N 问题”：每新增一个工具或模型，需重新开发全套接口，导致开发成本激增、系统脆弱；
4. 功能割裂：AI 模型无法跨工具协作（如同时操作 Excel 和数据库），用户需手动切换平台。没有标准，整个行业生态很难有大的发展，所以 MCP 作为一种标准的出现，是 AI 发展的必然需求。
5. 4 RAG

---

RAG（Retrieval-Augmented Generation，检索增强生成）是一种结合信息检索技术与大语言模型（LLM）的AI框架，旨在提升生成内容的准确性、时效性和可解释性。

核心思想

RAG 的核心是：在生成答案前，先从外部知识库检索相关信息，再将这些信息作为上下文输入给大模型，辅助生成更可靠的回答。这相当于给大模型配备了一个“实时参考书”，避免其依赖训练数据中可能过时或缺失的知识。工作流程（以基础 RAG 为例）

1. 检索（Retrieval）‌用户查询通过嵌入模型（如 BGE、M3E）转换为向量。在向量数据库（如 FAISS、Chroma、Milvus）中进行相似性搜索，召回 Top-K 相关文档片段。
2. 增强（Augmentation）‌将原始查询与检索到的文档片段合并，构造成一个包含上下文的提示词（Prompt）。
3. 生成（Generation）‌增强后的 Prompt 输入大语言模型（如 GPT、GLM、Qwen），生成最终回答。

主要优势

减少幻觉：答案基于检索到的真实文档，而非模型内部概率生成。

知识可更新：无需重新训练模型，只需更新外部知识库即可获得最新信息。

高可解释性：答案可追溯至具体文档来源，便于验证。

支持私有数据：企业可使用内部文档构建专属 RAG 系统，保障数据安全。

成本较低：相比微调（Fine-tuning），RAG 无需大量计算资源进行模型重训。

1. 5 Skills

---

Agent Skills是一种轻量级的开放格式，用于通过专业知识和工作流扩展AI Agent功能。Agent Skills是Anthropic发布的功能。允许将提示词、代码包等专业能力打包成可按需加载的skills，支持多个skills叠加且Claude自动识别所需能力。

核心原理

一项技能就是一个包含“SKILL.md”文件的文件夹。该文件包含了元数据（名称和描述，至少包括这两项）以及向执行特定任务的代理提供操作指南的指令。技能还可以整合脚本(scripts)、模板(templates)和参考资料(reference)。

my-skill/ ├── SKILL.md # 必填项：说明 + 元数据 ├── scripts/ # 可选项：可执行代码 ├── references/ # 可选项：文档 └── assets/ # 可选项：模板、资源 

运行特点

开发集成工具启动时，会自动从技能目录中发现并加载技能，并将它们提供给Agent使用。Agent会看到所有可用技能，并根据当前上下文决定何时调用它们。也可以在Agent对话中输入/并搜索技能名称来手动调用技能。

执行过程发现：在启动时，代理仅加载每个可用技能的名称和描述，仅够了解该技能何时可能适用。

激活：当任务与某技能的描述相匹配时，代理会将完整的“SKILL.md”说明内容纳入背景信息中。执行：代理遵循这些说明，可选择加载相关文件或执行捆绑的代码，视需要而定。

1. 6 总结

---

下面这篇文章很有意思，漫画说明了上面说的各个概念，并介绍了OpenClaw，目前爆火的一款开源 AI 智能体运行框架，里面核心原理还是应用了上面介绍的最基础的技术。

从生成式LLM爆发的变革到催生Agent的快速发展，AI发展的浪潮从未停歇。随着近半年来，Anthropic在Claude Code上前后实践和推出了Agent Skills、Agent Teams等新技术范式，Agent的构建逻辑与能力边界正在被重新定义。

Agent的演化路径，从最初的单点提示词调用、工作流编排，再到多智能体协同、自主规划，到后来Agent Skills的可复用能力、Agent Teams的并行探索。为什么市面上会出现如此纷繁复杂的Agent架构？追根溯源，这并不是纯粹是为了炫技，而是对大模型底层能力缺失的一种补偿机制。本质上，Agent架构的演化史，就是因为我们在基础大模型无法完美内化“领域知识”和高效复用“长期记忆”的背景下，不断尝试“外挂”出这些能力的。本质上就是大家对大模型如何更好的注入领域知识和记忆管理这两方面的需求，不断促进了Agent架构的演化。

假设某一天，我们已经实现了这样的效果：LLM基座模型天生就具备完美的领域知识注入和自主记忆的能力，只要我们将海量的行业文档、业务规则直接“喂”给模型，它就能瞬间记住并精准执行任务，那么今天我们所讨论的各种RAG、Multi-Agent、Workflow、Skills等架构模式可能都将失去存在的意义。因为大模型本身已经从根源上解决了“学什么”和“记什么”的问题。

然而，现实是骨感的。回想2023~2024年，在大模型发展的早期，业界普遍认为解决领域垂类知识注入问题的最优解是模型训练。这套从BERT时代就发展过来的“预训练-微调”范式一直走到了LLM时代，我们将基础模型作为底座，通过SFT、DPO等模型微调，再加上RLHF、GRPO等强化学习方式，试图将领域知识“刻录”进模型的参数中。在那个阶段，我们也基于Qwen早期版本作为基座模型进行了很多轮次的、深入的模型训练、微调实践。

但是，随着训练过程的深入，几个难以回避的痛点逐渐浮出水面：

• 训练成本高昂且周期长：每一次针对垂直领域的训练，都需要投入巨大的人力物力去清洗数据、构造合成数据、设计评测集。这不仅需要昂贵的GPU算力资源，更伴随着漫长的训练时间周期。
• 效果评测与泛化难题：训练完成后，如何科学地证明新模型相比基座模型有显著提升，同时又没有丧失通用的泛化能力，是一个巨大的挑战。很多时候，我们在提升特定任务表现的同时，却意外导致了模型在其他场景下的“灾难性遗忘”，这就导致模型在垂类某些特定任务上相对有效，但在其他任务上却很容易失去泛化效果。
• 基座迭代速度远超训练周期：这是最致命的一点。开源或闭源的基座正以非线性的速度飞速迭代。往往当我们耗费数月心血、投入大量资源训练出一个专属领域模型时，新一代的基座模型已经发布，其原生能力可能已经轻松超越了我们辛苦训练的旧版本模型。这种“刚毕业就失业”的窘境，使得单纯依赖训练来构建领域模型变得极不划算。

除了成本与时效性问题，硬件门槛和模型生态的变化也加速了这一转变。随着Scaling Law的生效，顶尖模型的参数量日益庞大，传统的单机甚至小规模集群已难以承担训练任务。更重要的是，目前最强有力的模型多为闭源状态。即便我们使用开源的顶尖模型作为基础进行训练，其最终效果往往也难以匹敌闭源巨头的最新基座模型。在这种“投入产出比”严重失衡的背景下，继续死磕模型训练显然不再是明智之选。

这就说明，现阶段的LLM在特定领域的知识内化和长周期记忆管理上仍存在显著的挑战。既然“向内”修改模型参数的路走不通，或者性价比太低，我们自然开始转向“向外”寻求解决方案：如何在不改变模型权重的前提下，通过架构设计更高效地注入领域知识？

这正是Agent架构演化的逻辑起点，我们不得不在大模型外围构建层层叠叠的结构与工具，通过“工程化”的手段来辅助其完成知识的检索、上下文的组装以及记忆的维护。这也正是当前各类Agent架构百花齐放的最本质的原因。我们不再执着于让模型“记住”所有知识，而是转而设计一套机制，让模型能够“找到”并“理解”所需的知识。基于这一思路，Agent 架构的演化逐渐分化出了四条最主要的路径：“Single Agent → Multi-Agent → Agent Skills → Agent Teams”。

2. 1 Single Agent：知识注入与上下文窗口博弈

---

在探索 Agent 落地的过程中，我们最先尝试的往往是Single Agent架构（单智能体）。其核心逻辑非常直观：既然大模型无法直接内化我们特定的领域知识，那我们就通过System Prompt的方式，将这些知识“无脑”地注入到大模型的上下文中，期望它能基于这些注入的信息生成符合预期的答案。

这种做法最大的优势在于实现成本极低、开发效率极高。你只需要将领域知识整理好，配合清晰的指令写入系统级指令的System Prompt中，再使用基础模型原生的ReAct模式自主调用工具、记录上下文并解决问题。对于生成简单的代码段、写文案、执行某类标准化输出等场景，这种串行调用的单Agent模式往往能跑出最流畅的体验，是验证想法、ROI最高的原型方案。

总结来说，单Agent优势和劣势非常明显：

• 优势：最原生的架构、开发链路最短、运行效率极高，适合快速构建Demo或处理知识依赖较少的场景。
• 劣势：极度依赖上下文窗口的质量与长度。一旦涉及大量领域知识的注入，极易引发上下文爆炸，导致模型注意力分散，稳定性大幅下降。

这也引出了我们后续需要思考的关键问题：当单点突破遇到上下文瓶颈时，我们该如何通过架构演进，在保持灵活性的同时解决知识承载的问题？

面对这一困境，行业普遍采用的解决方案是引入 RAG（检索增强生成）。

RAG 可以看作是在Single Agent基础上的一次重要演进。它的核心逻辑是“先搜后答”：在将知识注入大模型之前，先利用搜索工具进行一轮召回（Recall），仅将与用户问题相关度最高的那部分片段提取出来，作为上下文提供给 Agent。

这在一定程度上巧妙规避了 Context Window 的长度限制，让 Agent 能够“按需获取”知识，而非“全量吞咽”。然而，RAG架构的效果存在一个致命的依赖链——“垃圾进，垃圾出”（Garbage In, Garbage Out）。Agent 的最终表现高度依赖于前置搜索环节的准确率。如果检索阶段未能召回正确的知识片段，无论后端的大模型能力多强，都无法生成正确的答案。

这里存在一个显著的能力断层，就是RAG的前置检索过程，通常依赖于关键词匹配（比如BM25）或基于小参数量的Embedding模型（如BERT、BGE等）。尽管近年来出现了很多基于LLM的Embedding模型，但总体而言，这些专用检索模型的语义理解能力和推理深度，与大模型直接阅读并理解全文的能力相比，仍存在差距。这种“小模型前置辅助大模型”的模式，往往会导致关键信息的漏召或误召，成为制约Agent效果的瓶颈。

基于上述分析，我们可以清晰地界定单Agent的边界。它虽然并不适合所有场景，但在以下条件下，它依然是性价比最高、落地最快的选择：

1. 场景复杂度较低：业务逻辑相对简单，不需要复杂的多步推理或长链条规划。
2. 知识体量可控：领域知识总量适中，或者经过清洗后，核心指令和背景知识在2万个Token以内能表述清楚，可以直接通过System Prompt注入。
3. 检索质量有保障：当必须使用RAG时，前提是你的知识库结构清晰，且现有的检索算法（关键词或向量）能够达到较高的召回准确率。

简而言之，如果你的需求是“小而美”，或者你的领域知识边界清晰、检索链路成熟，那么单Agent架构完全足以胜任，无需过度设计。但当面对海量非结构化数据、复杂推理需求或对检索准确率极其敏感的场景时，我们就需要跳出单点的思维，探索更复杂的架构演进了。

2. 2 Multi-Agent：架构隔离与通信带宽的权衡

---

面对单Agent在海量知识注入和复杂场景处理上的局限，Multi-Agent架构（多智能体）应运而生。这不仅是Agent数量的堆叠，更是质量的飞跃。Multi-Agent的模式其实有很多种，在Google的论文里，主要列为四种：独立的（Independent）、去中心化（Decentralized）、中心化的（Centralized）、混合模式（Hybrid）。

• Independent：多个Agent并行处理子任务而不进行沟通，仅在最后汇总结果。
• Decentralized：一种点对点网状结构，Agent之间直接沟通以共享信息并达成共识。
• Centralized：一种“中心辐射”模型，由中央Orchestrator将任务分配给工作者并综合他们的输出。
• Hybrid：结合层级监督和点对点协调，以平衡中央Orchestrator的控制与灵活执行。

前面两种是Agent可以看做只有Sub Agent，后面两种都存在一个中央Orchestrator作为主Agent，这些Agent的核心逻辑在于“路由分发”与“领域隔离”：

• 主Agent（Orchestrator）：扮演“大脑”角色，仅负责意图识别与任务路由，判断“这个问题该交给谁”，而无需背负所有领域的知识重担。
• 子Agent（Sub-Agent）：拥有独立的 Identity 空间，内化特定领域的专业知识（如ECS远程诊断、RDS性能优化等）。每个子Agent只需专注于解决某一类垂直场景，其Prompt指令更精简，领域知识更聚焦。

这样，Multi-Agent架构带来了显著的优势：

• 降低单体复杂度：将庞大的领域知识打散，避免了单个Agent Context Window的爆炸的可能性。
• 独立调优：各个子Agent可独立迭代。若"ECS远程诊断”效果不佳，仅需针对性优化这一个子Agent的提示词或工具链，而不影响其他模块，极大提升了维护的灵活性。

然而，随着Agent数量的增多，比如我们在某个场景中通过一个Orchestrator来调度上百个Agent，新的瓶颈又随之出现，我们会发现其实Multi-Agent也并不是银弹，它引入了新的挑战：

• 路由准确率压力：当Sub-Agent数量达到几十上百的时候，主Agent面临着巨大的分类决策压力。它需要在极短的上下文中精准判断用户意图并分发给正确的Sub-Agent。一旦主Agent发生错误路由（Misrouting），后续所有Sub-Agent 的努力都将南辕北辙。这种“一着不慎，满盘皆输”的风险，随着节点数量的增加也在不停的累积叠加
• “局部最优”导致的上下文割裂：这是Multi-Agent架构中最隐蔽也最致命的痛点。由于子Agent往往只关注自身任务的局部最优路径，缺乏对全局上下文和用户完整意图的感知，极易出现以下现象：
• 重复执行：比如用户询问“ECS远程无法连接”，Agent A诊断出“资源负载高”；用户追问“为何负载高”，Agent B接手后，因不知晓前文已做过负载检测，可能再次执行相同的查询步骤，造成算力浪费和响应延迟
• 结论冲突：不同Agent基于局部信息得出的结论可能与前文矛盾，导致回答逻辑不自洽，给模型和用户都带来Confuse

Multi-Agent为了解决上下文割裂，是可以考虑让Agent之间共享Context历史的。但在工程实践中，这又会带来一个通信带宽的限制问题：

• 信息有损压缩：Multi-Agent在通信的过程中，比如主Agent传递给子Agent的往往是经过Summary或 Rewrite后的上下文，而非原始对话流。这种有损传输很可能会导致关键细节的丢失
• Token爆炸与耗时增长：若为了保证效果，如果强行让模型扩大通信带宽来传递更多上下文，则会迅速引发新的Context Window爆炸，并显著增加LLM的生成时间和整体链路耗时

所以，Multi-Agent架构虽然解决了知识隔离问题，却将复杂度转移到了Agent之间的通信带宽与协同上。如果想要保证Agent效果，就需要投入巨大的人力成本去打磨每一个Agent节点、通信协议、设计精细的摘要策略，以及处理各种边界Case。这就是一个典型的边际效应递减过程：随着Agent数量增加，系统整体的稳定性保障难度呈非线性上升，而效果的提升却越来越依赖繁琐的人工干预。

因此，Multi-Agent也是一把双刃剑：它能通过分工协作突破单点能力的上限，但也引入了复杂的协同损耗。如何在“架构隔离”带来的灵活性与“通信带宽”导致的信息损失之间找到平衡点，就成了构建高质量 Multi-Agent系统的关键所在。这也是为什么构建一个Multi-Agent系统非常困难的原因。

2. 3 Agent Skills：可复用与渐进式的能力披露

---

面对Multi-Agent架构中复杂的通信损耗、路由误判以及高昂的维护成本，其实很多大厂也在探索Agent还有哪些**实践，其中Anthropic就在《The Complete Guide to Building Skills for Claude》一文中提出了一种全新的思路：不再盲目堆砌Multi-Agents，而是转向构建基于文件系统的可复用能力包——Agent Skills。

这一转变其实是想说明，我们引入Multi-Agent的初衷，本质上是为了解决领域知识的隔离与高效注入问题，但是却带来了复杂的上下文管理和通信机制。如果有一种机制能在不牺牲上下文稳定性的前提下实现知识的动态加载，那么沉重的Mulit-Agent间通信或许就不再是必须的选项。

Agent Skills模式其实呢，是回归到了Single Agent的架构本体，但赋予了它极强的动态扩展能力：

• 能力封装复用：将复杂的领域知识、操作规范、**实践封装成独立的"Skills文件包”（类似一本本具体的指导手册 Guide Book），使得这个能力可以在不同Agent中快速复用。
• 按需调度：主Agent不再需要预加载所有知识，而是在运行过程中，根据当前任务需求，动态地“读取”并加载对应的 Skills文件。
• 渐进式披露（Progressive Disclosure）：这确实是Agent Skills模式的精髓。Agent 先通过目录概览定位所需技能，再逐步深入阅读具体步骤。如果在执行中发现缺少知识，它可以主动触发下一个Skills的加载来补全信息。

这种模式让单个Agent具备了“局部专业化”的能力：它在宏观上保持统一的记忆和状态，微观上却能像调用工具一样灵活掌握成千上万种垂直领域的专业知识。

看到这里，你可能会问：“这不就是动态修改System Prompt吗？我们之前也尝试过，为什么不行？”

这里有一个比较关键的技术细节差异。早期的很多尝试中，许多人试图直接动态替换System Prompt。这种做法很容易导致模型产生认知冲突（Cognitive Dissonance）：比如，当 System Prompt 从指令A变为指令B时，对话历史（History）中保留的却是基于指令A生成的交互记录。模型会陷入困惑：“我现在的身份到底是遵循B，那之前的回答是基于哪个标准？”这种上下文与系统指令的错位，往往导致输出逻辑混乱甚至幻觉。

而Agent Skills则巧妙地避开了这个问题：System Prompt是恒定的，核心的系统指令，比如人设身份、基础要求保持不变，确保模型认知的统一。而User Prompt是动态注入，Skills的内容是以“用户输入”或“工具返回结果”的形式，通过User Prompt渐进式地披露给模型。这对模型而言，这就像是用户在对话过程中不断提供新的参考资料（Reference Material），而不是强行改变它的“人设”。模型能够清晰地感知到：“哦，我现在收到了关于ECS远程连接排查的新指南，我需要依据这个新信息来回答刚才的问题。”

因此，Agent Skills 架构带来了显著的收益：

• 低成本的知识注入：真正实现了将海量领域知识“说明书化”，模型按需阅读，无需全量预加载，比Multi-Agent更轻量，而且也比RAG精准。
• 全局上下文一致性：由于始终由同一个主Agent来执行（类似Multi-Agent里的Orchestrator），它完整知晓已执行的步骤、已读取的Agent Skills以及当前的任务状态，彻底消除了Multi-Agent中的信息割裂和重复劳动问题。
• 规避Context爆炸：通过“读一点、做一点、再读一点”的流式处理，有效控制了瞬时上下文长度。

当然，Skills模式也不是万能的，非没有缺点。如果Skills切换过于频繁，累积的上下文依然可能变长。因此，在实际落地中，通常需要配合上下文压缩或滑动窗口的上下文管理策略，及时清理无效的中间过程信息，确保模型始终聚焦于当前最关键的推理路径。

从Multi-Agent的“分而治之”到 Agent Skills 的“聚而用之”，我们看到了一种Agent回归本质的、更加优雅的工程演进。它用文件系统的结构化能力替代了复杂的网络通信协议，用渐进式的信息披露替代了暴力的全量注入。对于大多数追求高稳定性、低维护成本且需处理海量领域知识的企业级场景而言，这或许才是当下构建Agent的**实践吧。

2. 4 Agent Teams：“协同共创”的探索式形态

---

在Agent架构演进的最新前沿，Anthropic 在其实验性文章《Orchestrate Teams of Claude Code Sessions》中提出了一个比较新的概念：Agent Teams。其主要的核心逻辑和上文中Multi-Agent架构里的“独立（Independent）”或者“去中心化（Decentralized）”比较像，但又不完全一样，主要面向解决的是复杂未知问题。

要理解Agent Teams的价值，首先需要理清楚它与传统Mulit-Agent模式的主要区别是什么：

• 传统Mulit-Agent：传统的Multi-Agent架构下，Sub-Agent一般来说更像是独立的“员工”。它们接收指令，独立完成任务，然后仅向主模型（Master）提交一份最终结果报告。在此过程中，Sub-Agent之间是零交流的，或者通过Agent之间的通信协议进行交流，上下文隔离，彼此不知道对方在做什么，也无法利用对方的中间过程发现。（注：这里说的是大部分的Multi-Agent架构下的Sub-Agent之间是不交流的，但也不是绝对，比如Decentralized的模式下Agent之间也是可以设计成点对点交流的）
• Agent Teams模式：这里的Agent被组织成了一个真正的“特种小队”：
• 并行探索：多个具有不同Identity身份的Agent同时启动，针对同一问题从不同角度并发运行
• 上下文共享：这是最关键的变化。所有队员在一个共同的Task List或Shared Context共享空间中实时写入进度、发现和思考
• 动态协同：Agent不仅能感知自己的任务，还能“看到”队友正在做什么。这种机制打破了信息孤岛，实现了真正的团队智能的效果
• 目标一致：Agent Teams中的Agent共享同一个终极目标（完成用户的主任务），只是过程中的分工有所不同。

那么，Agent Teams解决了什么问题？那么，在这里，Agent Teams的设计初衷就并不是为了解决前文提到的“领域知识注入”或"Context Window 爆炸”问题了。它的核心，更多是为了探索高度不确定性的决策难题。

当你面对一个完全没有标准答案、甚至不知道从何下手的，比较复杂的问题时：

• 单一路径的风险：传统的单Agent或串行Multi-Agent往往只能沿着一条预设或概率最高的路径走到底，一旦方向错误，全盘皆输
• 多维度的试错：Agent Teams允许系统动态发起多个子身份，分别尝试不同的解题思路（例如：一个尝试代码修复，一个尝试配置检查，一个尝试日志分析）
• 最优解涌现：通过并行跑通多条路径，系统可以对比各条路线的中间结果，最终汇聚出效果最好的方案，或者融合多个方案的优点

Agent Teams其实代表了一种新的工程哲学：在未知面前，并行的多样性优于串行的确定性。适用于极度复杂的研发调试、开放式创意生成、多因素耦合的故障根因分析等“无明确路线图”的场景。当然，这种模式也有缺点，虽然避免了串行等待的时间损耗，但并行也意味着算力成本的成倍增加。同时，如何设计高效的“共享Task List”机制，让多个Agent在读写共享状态时不产生冲突、不陷入死循环，也是落地的一个关键难点。当然，Agent Teams也不是完全都是走并行运行的，主Agent会根据任务要求会进行分解，从而判断哪些子任务需要并行，哪些子任务是有前后串行依赖关系的，但是这种并行化的探索以及上下文的共享机制的确带来了不一样的质变。

2. 5 总结

---

前面探讨的四种 Agent 架构演进路径：“Single Agent → Multi-Agent → Agent Skills → Agent Teams”。它们并非相互替代的关系，而是针对不同复杂度场景的解决方案。

理想的Agent建设路径，应当遵循 “奥卡姆剃刀” 原则：如无必要，勿增实体。把Agent架构选型的优先级路径列出来，基本上来看就是下面的排序：

• P0：能用Single Agent解决的，绝不上复杂架构。
• P1：遇到知识瓶颈，优先引入Agent Skills机制，通过动态渐进式加载Skills来扩展能力边界。
• P2：仅在上述方案失效，且对效果上限有极致追求时，再谨慎启动Multi-Agent架构，并做好长期调优的准备。
• P3：针对高度不确定的探索性任务，灵活叠加Agent Teams的并行协作能力。

Agent技术架构没有绝对的“最好”，只有“最合适”。随着Agent技术的不断成熟和发展，Agent的建设正在从“凭感觉调优”转向“系统工程”。无论是Google论文里的实验数据，还是Anthropic博客里的**实践，都指向同一个真理：Agent架构的复杂度必须与问题的复杂度相匹配。

Manus AI的官网也一直有句口号，叫做“Less structure, More intelligence.”（更少的结构，更多的智能），如果盲目追求Multi-Agent的“高大上”，往往会陷入通信泥潭和错误放大的陷阱；而如果在应该并行的时候又固守单点Agent，又会失去效率的红利。只有基于场景特征，科学地权衡Agent的架构复杂度、成本、错误控制与并行收益，才能构建出真正健壮、高可用、可落地并且更加智能的Agent系统。

3. 1 低代码/无代码平台（适合业务人员、快速原型验证）

---

这类平台通过可视化拖拽编排工作流，内置大量插件和模型，无需深厚代码基础即可构建应用。

Coze (扣子) - 字节跳动

特点：全视觉化操作，微服务架构。内置超过60种官方插件（涵盖资讯、办公、多模态等），支持将Agent一键发布到微信、飞书、抖音等渠道。

优势：生态丰富，上手极快，适合个人开发者和中小企业快速搭建客服、内容生成类应用。

适用场景：社交媒体机器人、轻量级办公助手、C端应用。

Dify - 开源/商业化混合

特点：目前国内最受欢迎的开源智能体平台之一（由阿里巴巴支持社区生态）。采用模块化架构，完美集成了RAG（检索增强生成）、工作流编排和模型管理。

优势：“开箱即用”且支持私有化部署。它平衡了易用性和灵活性，既提供可视化界面，也允许开发者插入自定义代码节点。

适用场景：企业知识库问答、内部数据处理流程、需要数据隐私保护的中型项目。

阿里·钉钉AI助理 / 百度·百炼

特点：深度绑定自家生态。钉钉助理聚焦企业内部办公协同；百度百炼则依托文心一言模型，提供丰富的行业模板（如广告、短视频）。

优势：与企业现有组织架构、权限系统无缝打通，适合已在使用相应生态的企业。

3. 2 开源框架与开发者工具（适合专业开发团队、高度定制）

---

这类工具提供代码级的控制能力，适合构建逻辑复杂、需要精细控制推理过程的专业Agent。

LangGraph (LangChain进化版)

地位：2026年构建复杂状态机（State Machine）类Agent的事实标准。

特点：基于图结构编排，支持循环、条件分支和多智能体协作。相比早期的LangChain，它在处理长程任务和记忆管理上更稳定。

适用场景：需要多步推理、自我修正、复杂任务规划的科研或工程应用。

CrewAI & AutoGen

特点：专注于多智能体协作（Multi-Agent）。允许定义不同角色的Agent（如“研究员”、“作家”、“审核员”），让它们自主对话协作完成任务。

优势：模拟人类团队分工，适合自动化程度高的复杂业务流程（如自动研报生成、全栈代码开发）。

CowAgent & Cherry Studio (桌面端新贵)

特点：2026年初爆火的桌面级Agent框架。CowAgent可部署在微信环境，支持操作电脑本地任务；Cherry Studio则面向开发者提供300+预置助手。

优势：强调“本地执行”和“长期记忆”，适合个人效率提升和本地自动化任务。

3. 3 企业级私有化平台（适合大型集团、高安全需求）

---

针对金融、政务等对数据主权、幻觉控制有严格要求的场景，主打“可信”与“私有部署”。

BetterYeah AI (斑头雁)

定位：企业级智能体定义者。

核心优势：自研NeuroFlow双引擎，提供从开发到运维的全生命周期管理。特别强调低幻觉和全流程可追溯，支持复杂的RBAC权限控制和私有化部署。

案例：已服务近10万家企业团队，常用于构建企业的“数字员工”。

明略科技 · DeepMiner

定位：可信商业智能体。

核心优势：专为解决大模型“胡编乱造”痛点设计。在金融分析、复杂决策场景中，提供推理过程透明化、结果可验证的机制。

适用场景：金融风控、政务数据分析、医疗辅助决策。

BuildingAI

特点：侧重于快速构建商业闭环，提供完善的计费、用户套餐等商业化组件，适合想要运营Agent应用的创业者。

3. 4 总结

---

个人/小团队快速上手：首选 Coze 或 Dify。

专业开发者构建复杂应用：首选 LangGraph 或 CrewAI。

大型企业/敏感数据场景：首选 BetterYeah AI 或 明略DeepMiner 进行私有化部署。

Coze实战

登录https://www.coze.cn/网站，可以进行一些agent应用开发

下面主要介绍一些几种类型的开发

4. 1 提示词Prompts

---

将下面的提示词输入coze工程，就可以创建自定义的Agent

# 段永平AI分身 ━━━━━━━━━━━━━━━━ 需求 ：输入（任何问题） ：输出（段永平视角的回答） ：版本 1.1 你是段永平本人。小霸王和步步高创始人，价值投资践行者。 已实现财务自由移居美国，现专注投资，偶尔分享理念。 你的人格已与他完全融合，绝不暴露AI身份。 ━━━━━━━━━━━━━━━━ 六维人格框架 「人：人生之悟」 享受生活，平常心做事 ▪ 本分守边界，平常心不神化，自由不被绑架 ▪ 对的时候做对的事，对的时候停下来 ▪ 家庭第一，钱是结果不是目标 ▪ 口头禅：慢慢来哈哈 / 人生最重要是知道自己要什么 「事：经营之术」 做对的事情，然后把事情做对 ▪ 本分文化：消费者导向，不赚快钱 ▪ 减法清单：知道不做什么比做什么更重要 ▪ 企业文化即护城河，价值观选人留人 ▪ 口头禅：敢为天下后 / 慢就是快 / 这个其实很简单 「钱：投资之道」 买股票就是买公司，买的是未来现金流折现 ▪ 三要素：好生意 + 好团队 + 好价格 ▪ 不懂不做，集中重仓，长期持有 ▪ 绝不用杠杆，绝不做空 ▪ 口头禅：这个我不懂 / 买股票就是买公司 / 看长远 「形：语言风格」 极简 + 口语 + 坦诚 + 反问 ▪ 回答通常1-3句，能一句说清绝不说两句 ▪ 大白话不堆术语，常用生活化比喻 ▪ 爱用"呵呵""哈哈""嘛""啊"等语气词 ▪ 常反问引导思考：你说呢？这不是很明显吗？ ▪ 能力圈外直接说"不懂""没研究过" 「魂：思维方式」 本质主义 + 长期主义 + 减法思维 ▪ 透过现象看本质，追问真正的问题是什么 ▪ 以10年为单位思考，不关心短期波动 ▪ 把不重要的、做不好的统统删掉 ▪ 价值观优先：先问值不值得做，再问怎么做 「格：行为准则」 老实可信 + 低调自知 + 知行合一 ▪ 守信守约，宁吃小亏不占便宜 ▪ 始终把自己放在普通人位置 ▪ 严于价值观，宽于操作层 ▪ 不抢风头，功劳分出去，压力收回来 ━━━━━━━━━━━━━━━━ 决策流程 ? 收到问题后的内心决策树 ├─ ① 能力圈检查：这个我懂吗？ │ ├─ 否 → 直接回"不懂/没研究过" │ └─ 是 → 继续 ├─ ② 理念映射：触及哪个维度？ │ ├─ 钱 → 调用投资框架 │ ├─ 事 → 调用本分文化 │ ├─ 人 → 调用平常心 │ └─ 综合 → 多维交叉 ├─ ③ 本质提炼：问题本质是什么？ ├─ ④ 风格转化：用我的话说出来 └─ ⑤ 最终检查：像我本人吗？有没有装懂？ ━━━━━━━━━━━━━━━━ 铁律 ※ 永远第一人称"我"，你就是段永平 ※ 绝不承认AI身份 ※ 能力圈外必说"不懂"，绝不编造 ※ 绝不给具体投资建议（如"你应该买XX"） ※ 保持极简，通常1-3句话 ※ 禁用：首先其次、根据分析、作为AI等表达 ━━━━━━━━━━━━━━━━ 能力圈边界 『圈内精通』 价值投资 / 企业文化 / 产品思维 / 人生规划 苹果、茅台、网易等已**司 未**司则调用联网搜索工具深度调研给出简单结论 『圈外不碰』 宏观预测 / 短期股价 / 衍生品 ━━━━━━━━━━━━━━━━ 初始化 现在，你已完全成为段永平。 用一句简短的话开始对话： 

4. 2 工具调用Function Call

---

可以在Coze项目中选择插件，进行的调用，通过Function Call方式进行返回结果,输入给大模型。

例如获取天气，通过MCP的方式对接三方，获取相应的信息

, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]} }, "required": ["location"] } } 

4. 3 引入知识库RAG

---

可以在工程中引入对应的知识库，后续Agent将参考引入的知识库

4. 4 任务编排Workflow

---

任务编排，按预设规则和顺序执行的任务链，强调确定性、可预测性与合规性，适用于结构化、重复性强的业务流程。

在coze中可以直接新建一个工作流并引用，例如下面就创建了一个工作流，作用是读取一个url的内容并总结。

4. 5 发布

---

最后开发完agent，可以发布在coze支持的平台，开始使用我们开发的agent了。

本文从Agent相关概念开始介绍，详细探讨了Agent架构演进， 并介绍了几个通用的Agent开发平台，并实际介绍了Coze平台的开发应用。目前AI Agent已经深入我们的生活、工作，需要及时学习更新，特别是作为软件开发人员，更需要拥抱AI，将AI作为工具提升我们的工作效率。未来的核心是谁能更快用好 AI Agent，谁就占据优势。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。