Agent 架构的演化逐渐分化出了四条最主要的路径：“Single Agent → Multi-Agent  → Agent Skills → Agent Teams”

Agent架构为什么需要演化，就是因为我们在 基础大模型无法完美内化“领域知识”和高效复用“长期记忆” 的背景下，不断尝试“外挂”出这些能力的。

本质上就是大家对大模型如何更好的注入领域知识和记忆管理这两方面的需求，不断促进了Agent架构的演化。

Single Agent架构

Single Agent指的是“狭义的”基于ReAct的自主Agent概念，使用System Prompt驱动、串行调用工具的原生Agent运行模式

核心逻辑

既然大模型无法直接内化我们特定的领域知识，那我们就通过System Prompt的方式，将这些知识“无脑”地注入到大模型的上下文中，期望它能基于这些注入的信息生成符合预期的答案。

你只需要将领域知识整理好，配合清晰的指令写入系统级指令的System Prompt中，再使用基础模型原生的ReAct模式自主调用工具、记录上下文并解决问题。

对于生成简单的代码段、写文案、执行某类标准化输出等场景，这种串行调用的单Agent模式往往能跑出最流畅的体验，是验证想法、ROI最高的原型方案

优势

实现简单、开发快、运行效率高，适合快速验证和简单场景。

劣势

上下文窗口易爆炸：注入海量知识会导致“关键信息遗忘”（Lost in the Middle）问题

长上下文并不等于长记忆。当输入数据量达到一定阈值时，模型极易出现“Lost in the Middle”问题，也就是“注意力缺失”或者“关键信息遗忘”的现象，导致其无法精准定位到所需的领域知识，最终输出的结果偏离预期

解决方案

行业普遍采用的解决方案是引入 RAG（检索增强生成）

[[RAG是什么]]

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

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

flowchart TD
    A["用户问题
（例如：ECS远程连接失败？）"] --> B["嵌入模型
（小模型）"]
    
    B --> C["将问题转化为
向量"]
    C --> D["向量数据库
（存储着海量领域知识）"]
    
    D --> E{"相似性检索"}
    E --> F["召回 Top-K 个
最相关的知识片段"]
    
    F --> G["提示词组装"]
    G --> H["将问题 + 召回片段
组合成最终提示词"]
    
    H --> I["大语言模型
（LLM）"]
    I --> J["生成最终答案"]
    
    style A stroke-width:2px
    style B fill:#e1f5fe,stroke:#01579b
    style I fill:#fff9c4,stroke:#fbc02d
    style J stroke-width:2px

Reference

《Agent/Skills/Teams 架构演进过程及技术选型之道》

“虚中法” 和 “子平法”学习框架

这份文档是一位命理老师在讲解八字命理学的核心框架与学习方法，内容详实，情绪激昂，旨在为学生厘清思路、夯实基础。以下是详细的内容总结：

一、核心思想与总论

3. 强调基础的重要性：反复告诫学生不要追求“秘诀”，命理学博大精深但没有秘密，真正的核心都在经典之中。学习的关键在于“打基础”，必须反复研读经典和上课视频。

4. 命理学的两大体系：明确指出八字命理主要分为 “虚中法” 和 “子平法”，二者视角不同，但需要结合使用。

   • 虚中法（禄命法）：以 年柱 为太极点（核心），论 先天之命。核心是“禄、命、身”加上神煞。看的是一个人与生俱来、命中注定的福禄、根基、体质等。

   • 子平法：以 日柱（日元） 为太极点，论 后天之运。核心是 月令格局 加上神煞。看的是一个人出生后，在具体的人伦社会中如何获取财富、地位、婚姻、子女等。

5. “主本同参”原则：这是核心方法论。必须将 年柱代表的先天命 和 日柱代表的后天运 结合起来看，不可偏废。先天命是根基，后天运是发挥。后天所得若与先天年柱的禄马贵气等呼应，则福大贵大；若脱节，则福贵减小。

二、具体方法论详解

1. 论六亲：

   • 年柱定六亲：决定命里“有没有”、先天缘分厚薄（“命里有时终须有”）。

   • 日柱定六亲：决定后天在社会中“如何得到”、关系相处的具体状态。

   • 二者需协调参看。

2. 论婚姻：

   • 主要看 日支（夫妻宫） 和 月支。

   • 同时必须结合 命宫 来起“十二宫”，其中 命宫的对宫就是夫妻宫。论婚姻时，要确保日支/月支的夫妻宫与十二宫的夫妻宫 不可交战，并综合查看两宫的神煞。

3. 其他重要概念与用法：

   • 胎元、胎息、胎变：三者与胎元所在之年，构成 “先天八字”。此盘不看十神，主要看地支的刑、冲、破、害，以及字形（如平头、悬针）和纳音交战，用于判断先天体质、有无夭折风险等。

   • 命宫：主要用于起“十二宫”（即“花園十二宫”），如命宫、夫妻宫、财帛宫等，用于多维度分析人生事项。

   • 神煞体系：是两大体系共用的重要部分。包括：

     • 马前神煞、太岁十二神。

     • 常用吉凶神煞：如红鸾、天喜、文昌、游奕、暗金煞、白衣、破碎、呻吟等。神煞需结合具体宫位和五行生克使用。

   • 虚中法看流年：核心是 “逐限而行”。将人生划分为不同年限（如年柱管1-16岁），重点看所行大运或流年 那一柱的天干地支，与年柱的禄命身产生何种生克合化及刑冲破害，并结合神煞，来判断该时段的吉凶。

   • 子平法论格局：核心是 月令分金定格局（如正官格、七杀格等）。需辨别格局的真假、成败。无格或破格时，则看喜用神。老师指出，真成格者（真富贵）极少。

   • 身强身弱：明确指出，身强身弱首先看年柱（年干、年支、纳音），这是先天体质根基。日元强弱是后天表现。日元强，承载财官的能力才强。

三、学习路径与经典推荐

1. 核心经典（打基础必读）：

   • 《渊海子平》：子平法的核心框架。

   • 《五行精纪》：虚中法（禄命法）的核心框架。

   • 《三命通会》：集大成的综合性经典。

2. 其他经典作为视角补充：如《神峰通考》（讲病药）、《穷通宝鉴》（讲调候）、《子平真诠》（讲格局）等，它们提供了特定视角，但非全面基础。

3. 学习方法：

   • 先建立清晰框架：在脑中牢固建立“虚中-年柱-先天”和“子平-日柱-后天”两大框架，以及神煞、刑冲等公共方法。

   • 带着框架去学习：有了扎实基础和框架后，再去广泛听取各家之言，才能有判断力，将他人观点纳入自己的体系，而非被误导。

   • 重视赋文：如《千里马》、《络绎赋》、《金玉赋》等，这些是古人将理论应用于实战的总结，基础扎实后才能看懂并运用。

4. 对市面上乱象的批判：

   • 强烈反对自称“独创”、“秘传”而不引经据典的理论，认为“凡是离开经典的，皆是无源之水”。

   • 指出很多民间传承或盲派技法，其根源也公开承认来自上述经典。

   • 提醒学生睁大眼睛，谨慎对待那些标新立异、脱离经典的教学。

四、总结与劝诫

• 最后归纳：八字的核心框架就是 “虚中的禄命身+神煞” 与 “子平的月令格局+神煞” 的结合。刑冲破害、十二长生、旺相休囚等是服务于这两个核心的分析工具。

• 终极劝告：“命理学没有秘密。命理学的基础逻辑在经典，实务传承在民间。” 要求学生沉下心来，回归经典，打好基础，以此立身，不贬低他人，但要有独立判断。

Harrison Chase（LangChain 联合创始人兼 CEO）那篇《How Coding Agents Are Reshaping Engineering, Product and Design》中文翻译：

编程Agent如何重塑工程、产品与设计

软件公司的 EPD（工程、产品与设计） 的核心是创建优秀的软件。虽然这些角色是分开的，但最终目标是产出能够解决商业问题、用户可用的功能性软件。归根结底，这一切都是代码。认识到 EPD 的产出本质上就是代码非常重要，因为……编程Agent突然让写代码变得非常容易。那么，这将如何改变 EPD 的角色呢？

流程的改变

1. PRD（产品需求文档）已死
在 Claude 时代之前，PRD 是软件开发的核心。EPD 的流程通常是这样的：

1. 有人（通常是产品经理）有了一个想法
2. 产品经理写一份 PRD
3. 设计师根据 PRD 制作原型图
4. 工程师将原型图转化为代码

想法 → PRD → 原型图 → 代码

这并非硬性规定（在初创公司这些步骤是融合的，最好的构建者能同时做多项工作），但这是教科书式的开发方式。

之所以这样，是因为构建软件（和原型图）需要大量的时间和精力。因此，人们创造了专门的学科来处理这些工作。随着专业化程度提高，跨学科沟通的需求也随之产生。PRD 就是这一切的基础，它启动了整个流程。然后它像瀑布一样流向设计，设计师将漂亮的文字转化为漂亮的 UI 和流畅的 UX。最后工程师将其变为现实。

编程Agent改变了这一切。 编程Agent可以直接将一个想法转化为功能软件。当我说（以及其他人说）“PRD 已死”时，我们真正的意思是：这种从撰写 PRD 开始的传统软件构建方式已经终结了。

2. 瓶颈从“实施”转移到了“评审”
现在任何人都能写代码，这意味着任何人都能构建东西。但这并不意味着构建出来的东西架构良好、解决了正确的问题或者易于使用。工程、产品和设计应该成为这些领域的评审者和仲裁者。

问题是，生成的代码并不总是“优秀”的。EPD 的角色变成了评审并确保它是“优秀的”。“优秀”可以指代几层含义：

• 工程系统视角： 架构是否可扩展、高性能且稳健？
• 产品视角： 这是否解决了用户的痛点？
• 设计视角： 界面是否易于使用且直观？

由于创建初始版本代码的成本极低，我们看到产生了更多的原型。这些原型成为焦点，由产品、工程和设计进行评审。

想法 → 代码 → [产品反馈 / 工程反馈 / 设计反馈]

问题是——生成代码太容易了。以前，创建代码需要很长时间，所以作为评审者，你桌面上待审的项目数量有限。但现在——任何人都能写代码。这意味着正在进行的项目数量在增加。我们发现瓶颈（在所有三个职能中）在于评审——即拿走这些原型并确保它们是“好”的。

3. PRD 万岁
Claude 时代之前的软件构建方式（从 PRD 开始）已经过去。但描述产品需求的文档仍然是必不可少的。

假设有人有一个想法并快速构建了一个原型。如何将其投入生产？它需要经过 EPD 的其他成员评审。在这个过程中，书面文档总是有帮助的，而且往往是必要的。当其他人进行评审时，他们怎么知道代码的某一部分是偶然存在的还是有意为之的？这取决于意图。需要某种形式的意图沟通。

我认为传统的 PRD 流程（PRD → 原型图 → 代码）已经死了。但描述产品需求的文本还活着。这份相关文档应该是原型的必备伴侣，在移交评审之前必须存在。最标准的格式是文档，但也有一些关于共享创建此功能所用提示词（Prompts）的有趣想法。如果未来的 PRD 只是结构化的、版本化的提示词呢？

想法 → 文档 → 代码 → [产品反馈 / 工程反馈 / 设计反馈]

对角色的影响

1. 通才比以往任何时候都更有价值
我说的通才，是指对产品、工程和设计都有良好感知的人。这些人一直都很有价值且有影响力——但在编程Agent时代，他们更是如此。为什么？
沟通是一切中最难的部分。它会拖慢进度。 一个能同时做产品、设计和工程的人，会比一个三人的团队跑得更快，因为没有沟通开销。

以前，当实施是阻碍时，这个通才仍然需要与他人沟通才能完成工作。现在他们只需要与Agent沟通。这意味着他们仅凭自己就能产生比以往任何时候都大得多的影响力。

2. 编程Agent是刚需
随着编程Agent让实施变得廉价，使用它们成为了一种要求。能够采用编程Agent的人将能凭一己之力做更多的事：

• 产品经理： 采用编程Agent可以直接通过构建原型来验证想法，而无需撰写规格说明书和等待。
• 设计师： 采用编程Agent可以在代码中迭代，而不仅仅是在 Figma 中。
• 工程师： 采用编程Agent可以将时间从实施转移到系统思考。

采用编程Agent是刚需，因为这并不难，如果你不这样做，你就会被使用它的人取代。

3. 好的产品经理很棒，糟糕的产品经理很可怕
好的产品思维比以往任何时候都更有价值——你可以构建有用的东西。糟糕的产品思维比以往任何时候都更浪费。如果有人有一个糟糕的产品想法，他们可以带着一个原型出现——但这个原型将是一个无用或构思拙劣的功能。这些原型现在需要更多的评审——来自工程、产品和设计。这消耗了时间和资源。而且，将这些原型投入生产的惯性更大（“它已经存在了！我们就合并它吧！”）。这有制造出更差或臃肿产品的风险。

（此处原文有图表：糟糕的 PM 使用 AI 产生负价值，优秀的 PM 使用 AI 产生高价值）

4. 系统思考是需要磨练的技能
在一个执行廉价的世界里，系统思考成为了差异化因素。你应该专注于擅长系统思考，并对你特定的领域有清晰的心智模型：

• 工程： 对如何架构服务、API 和数据库有极佳的心智模型。
• 产品： 对用户真正需要什么（而不是他们说想要什么）有极佳的心智模型。
• 设计： 对为什么某些东西看起来和用起来感觉对劲有极佳的心智模型。

系统思考一直很重要——那么什么变了？实施成本大幅下降。 这意味着实施某件事比以往任何时候都容易——但这并不意味着它很棒。成为一个好的系统思考者可以让你确保你一开始就构建了正确的东西。它也让你在事后评审他人的工作。这两点都意味着成为好的系统思考者的重要性增加了。

5. 每个人都需要产品感
编程Agent仍然需要有人向它们发出提示。有人告诉它们做什么。如果你告诉它们构建错误的东西——你就是在为其他人制造更多需要评审的垃圾。知道告诉Agent构建什么（“产品感”）是必须的，否则你会成为组织的拖累。这在工程、设计和（显然的）产品中都是如此。

EPD 的很大一部分现在是评审原型。如果你有产品感，评审设计/工程会更容易。如果你没有产品感，你需要一份与原型并行的超级详细的产品文档。如果你有产品感，你只需要最小的规格说明书就能理解功能的意图，从而加速沟通、评审和交付。

6. 专业化的门槛变高了
你需要知道如何使用编程Agent。你需要产品感。所有角色都在融合。

角色之间一直存在重叠。设计和产品长期以来联系紧密——在苹果和 Airbnb 等公司，设计师充当产品经理。“设计工程师”作为一种角色在 Vercel 等公司越来越流行。

这并不意味着没有专业化的空间。一个只思考系统架构的资深工程师仍然很有价值。就像一个没有掌握“氛围编码”（vibe coding）但对客户问题和构建内容有超级清晰心智模型的 PM 一样。设计师也是如此，他们可以理解和模拟用户旅程和交互，即使仍在使用 Figma。

但专业化的门槛更高了。你不仅要精通你的领域，还要在评审上极快，并且是令人难以置信的沟通者。而且在任何给定的公司里，可能都没有那么多这些角色。

7. 你不是构建者，就是评审者
我们在 EPD 中看到了两种不同类型的角色正在出现。

第一：构建者（Builders）。 这种原型具有良好的产品思维，能够使用编程Agent，并具备基础的设计直觉。在一定的限制范围内（测试套件、组件库），他们可以将小型功能从想法推向生产，并为大型功能制作功能原型。

第二：评审者（Reviewers）。 对于大型和复杂的功能，需要详细的 EPD 评审。这对评审者的要求很高——你必须是你领域的杰出系统思考者。你还必须以快节奏工作——有太多东西需要评审。

如果你现在是一名工程师——你应该要么努力在系统设计上变得出色并习惯评审架构，立志成为一名评审者……要么尝试增长你的产品/设计技能并成为一名构建者。

如果你在产品或设计领域——你必须要么对产品/设计有极佳的心智模型并主要进行评审……要么跳进编程Agent并提高你的编码能力。

（此处原文有图表：横轴为工程能力，纵轴为产品/设计思维）

• 独角兽（Unicorns）： 高工程能力 + 高产品/设计思维（构建者）
• 开始有麻烦的人： 低工程能力 + 高产品/设计思维（产品/设计评审者）
• 开始有麻烦的人： 高工程能力 + 低产品/设计思维（工程评审者）
• 总是有麻烦的人： 低工程能力 + 低产品/设计思维

有趣的是，角色正在某种程度上瓦解，如上图所示。角色开始融合——工程师有更多时间，可以更多地思考产品和设计。产品和设计可以创建代码。

8. 每个人都认为他们的角色从编程Agent中获益最大——而且他们是对的
Twitter 上有一篇关于从编程Agent中获益最大的人类型的精彩帖子：

“一个对现有产品有直观把握的人，知道它的软肋在哪里，哪里表现出色，以及如何将其迭代得更加锐利。
这种人的罕见版本存在于文化和深度技术的交界处。一个真正双语的人。他们知道技术上什么是可能的，也知道哪些文化潮流是真实的，哪些是短暂的。这种组合区分了那些感觉不可避免的产品和那些感觉是拼凑起来的产品。”

这篇文章很好地概括了这个新世界，它一度半病毒式传播。它之所以走红，是因为每个读到它的人都认为这是在说他们或他们的角色。我看到产品经理在引用它，设计师、设计工程师、创始人……每个人都认为它适用于他们和他们的角色。

而且他们可能都对！我认为这个新世界最令人兴奋的事情是，背景变得不那么重要了。我真心相信这种原型人物可能来自产品、设计或工程。这并不意味着每个人都会成为这种人——这说起来容易做起来难。真正的独角兽非常少。

这是一个令人兴奋的构建时代 :)

Skills一开始是由Claude发布的一种**为跨平台可移植性的开放标准。**它是指一个包含指令、脚本和资源的有序文件夹，代理可以动态发现并加载这些 文件夹，从而更好地完成特定任务。

一般来说，一个完整的Skill，包含以下文件：

为什么它能解决 Context 膨胀？

因为它采用了渐进式披露 (Progressive Disclosure) 的机制：

1. Discovery (扫描)：Agent 启动时，只读取 SKILL.md 里的 name 和 description。内存占用极小，只为了“知道有什么”。
2. Activation (激活)：只有当你的任务匹配到某个简介时（比如“处理 PDF”），Agent 才会动态加载完整的 SKILL.md 正文到 Context 中。
3. Execution (执行)：根据指令，按需调用 scripts 里的代码或读取 references 里的文档。

Skills有三个核心特点，也是它火起来的原因。

可组合。多个Skills可以协同工作，AI自动判断需要哪些，形成可复用的能力链。

可移植。同一个skill，Claude Code、Codex、Cursor、OpenCode都能用，不用改一行代码。

高效。只加载需要的，不浪费token和上下文长度。把上下文留给当下任务，而不是反复解释规则。

Agent Skills最大的改变就在于渐进式披露，其本质依然是行业中大家都在不断优化的提示词工程和上下文工程，其对提示词做了标准化拆分，通过在本地创建相关文件并控制文件的读取，只在Agent需要时自主且自动加载内容。

就单拿提示词来说，我们在调用MCP时总要描述很多的工具提示词，在没有执行前，工具描述先把 Context 占满了。

反观Skills，Agent 最初只加载多个 Skills 的元数据（每个 Skill 占用几百 token），当 Agent 认为需要使用某个具体的 Skill，就会读取这个 Skill.md 说明（几千 token）

Skill 里还可以无限嵌套下去，告诉 Agent，想要深入了解某个具体问题，还可以继续读取哪份文件。

官方文档：
https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

一、学习路径与方法

1. 打好根基，循序渐进：

   • 首要任务：必须首先熟练掌握“四季歌”。这是八字分析的第一步，用于判断日主在不同季节的先天旺衰和基本喜忌，从而定出命局的富贵贫贱基调。

   • 不要贪多求快：老师反复强调，在根基不牢时，不要看太多杂乱的知识，否则思路会混乱，变成“浆糊”。应该专注于核心基础，精专才能学好。

   • 先背诵，后简化：对于“四季歌”这类核心口诀，必须下功夫背诵熟记，理解其原理。只有在完全熟练之后，才能尝试使用简化方法去应用。在不熟的情况下追求捷径，心里会没底，判断不灵。

2. 学习步骤：

   • 第一步：拿到一个八字，首先用“四季歌”判断其季节喜忌，这已经能看出命局一半的高低好坏。

   • 第二步：在根基扎实后，再结合“财官”等十神知识，进一步分析格局和细节。

   • 第三步：结合大运走势。命局喜火，大运走东南木火之地则吉；命局喜水，大运走西北金水之地则吉。好运能提升层次，坏运则压抑发展。

二、核心学习态度与心法

1. 目的与心态：

   • 深层目的：学习命理浅层是看五行生克，深层是窥见“因果”。学习的最终目的不应是陷入对命运的焦虑或执着，而是调整心态、认识自我。

   • 改变自己：老师强调，命理学习者首先应该做到的是改变自己。改变自己很简单，就是“放好心态”——不要情绪化，不要名利化。当你心思清净（清气上升），运气自然会改善。如果自己都改变不了，就无法影响他人。

   • 避免学“郁闷”：如果学完后反而让自己郁闷了，那就学“坏”了。正确的学习应该让人“开悟”，看淡得失，无论有钱没钱都能心态平和。

2. 对“命”与“运”的认知：

   • 命里有时终须有：命局中固有的东西（如财官印）才是根本的、可能终身拥有的。

   • 运里有时一时有：大运带来的东西是阶段性的，运过则无，是“虚妄”。

   • 修为的作用：命里没有的东西，可以通过后天的修行和修为来改进。这指向了个人心态和行为的调整。

三、实用总结与简化技巧

• 四季月核心：无论什么五行，生于辰月、丑月（三月、十二月），首要需火来调候；生于未月、戌月（六月、九月），首要需水来滋润。

• 季节总原则：夏天生的八字普遍需要水调候；冬天生的八字普遍需要火温暖。这是快速判断的大方向。

总而言之，老师倡导的学习方法是：从背诵“四季歌”等核心口诀打下坚实基础开始，专注精研，避免杂学混乱。在学习过程中，要摆正心态，以认识自我、调整心性为目的，最终达到“清气上升”、豁达开悟的境界，而非被命运所困。

🔍 WHAT（是什么）

Skills 是一种应用层的架构模式，它将完成特定任务的专业知识、业务流程和最佳实践封装成可供 LLM 按需加载的”操作说明书”。

本质特征：

• 是一个结构化的 Markdown 文件（SKILL.md）+ 可选的脚本代码
• 是写给 LLM 看的 SOP（标准作业程序）
• 是可复用、可版本化、可共享的知识资产
• 不是 LLM 的原生能力，而是建立在 Function Calling 和 MCP 之上的上层建筑

文件结构示例：

1
2
3
4
5

skill-name/
├── SKILL.md         # 核心指令（LLM加载）
├── scripts/         # 脚本代码（LLM不加载）
├── references/      # 参考文档（按需加载）
└── skill.json       # 元数据（应用层使用）

🎯 WHY（为什么需要）

七大核心价值：

一句话总结：Function Calling + MCP 解决了”怎么调用工具”的技术问题，而 Skill 解决了”如何让 AI 专业地工作”的系统问题。

👤 WHO（谁负责）

Skill 涉及三个角色，职责清晰分离：

决策分工：

• 应用层负责：“有什么技能可用”（提供菜单）
• LLM 负责：“该用哪个技能”（根据菜单点菜）
• 开发者负责：“技能该怎么做”（写菜谱）

⏰ WHEN（何时使用）

适用场景：

触发时机：当用户请求匹配到某个技能的 description 时，LLM 会调用 activate_skill 激活该技能。

📍 WHERE（在哪里运行）

Skill 的运行环境是分层的：

flowchart TB
    subgraph Cloud[云端/本地]
        A[应用层 - Skill Registry]
        B[技能存储 - SKILL.md + scripts]
    end
    
    subgraph LLM[LLM 服务商]
        C[LLM 推理引擎]
        D[上下文 - 元数据 + 激活的指令]
    end
    
    subgraph Tools[工具层]
        E[MCP 服务器]
        F[外部 API/数据库]
    end
    
    A -- "注入元数据" --> C
    C -- "activate_skill" --> A
    A -- "提供工具描述" --> C
    C -- "调用工具" --> E
    E --> F

• 元数据：在 LLM 上下文中
• 完整指令：激活后加载到 LLM 上下文
• 脚本代码：在应用层执行（LLM 不加载）
• 工具调用：通过 MCP 标准化接入

🔧 HOW（如何工作）

5.1 核心机制：渐进式加载

5.2 完整调用流程

sequenceDiagram
    participant U as 用户
    participant L as LLM
    participant A as 应用层
    participant T as 工具(MCP)

    Note over L: 上下文有技能元数据列表
    
    U->>L: "审查这段代码"
    
    L->>L: 语义匹配，选择 code-reviewer
    
    L->>A: 返回 tool_calls
{name:"activate_skill", args:{name:"code-reviewer"}}
    
    A->>A: 验证权限，加载 SKILL.md
    
    A-->>L: 注入完整技能指令
    
    loop 按步骤执行
        L->>A: 调用工具（Function Calling）
        A->>T: 通过 MCP 执行
        T-->>A: 返回结果
        A-->>L: 注入结果
        L->>L: 决定下一步
    end
    
    L-->>U: 返回最终结果

5.3 关键技术点

📊 6.1 效果总结

🎯 终极总结

1
2
3
4
5
6
7

# Skill 的 5W1H 一句话版
WHAT  = 给 LLM 看的 SOP（标准作业程序）
WHY   = 让 AI 从"会调用工具"变成"懂业务地工作"
WHO   = 应用层管注册 + LLM做决策 + 开发者写内容
WHEN  = 需要多步流程、业务规则、稳定输出时
WHERE = 元数据在 LLM 上下文，脚本在应用层执行
HOW   = 元数据注入 → 语义匹配 → 激活 → 按指令执行

Skill 的本质：它是 Function Calling 和 MCP 之上的智能封装层，把 LLM 的灵活性（理解与决策）和应用层的确定性（流程与管控）完美结合，让 AI 真正成为能稳定处理复杂任务的”领域专家”。

搭建完openclaw 他的名字叫Assistant
想改一个名字，叫虾总9527

问了下deepseek，但不知道怎么描述这个需求，表述的都不对，不知道是个哪儿。

只能问问他自己

原来这是webchat界面上的默认设置。再去deepseek

让这么改

1
2
3
4
5
6
7
8

{
  "agents": {
    "defaults": {
      "model": "test-model",  // 临时测试
      "personality": "你的名字是虾总9527"
    }
  }
}

结果配置报错了，试了好几个方式都不行，去官网上查了查

看到一段示例：

https://docs.openclaw.ai/gateway/configuration-examples#recommended-starter

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  identity: {
    name: "Clawd",
    theme: "helpful assistant",
    emoji: "🦞",
  },
  agent: {
    workspace: "~/.openclaw/workspace",
    model: { primary: "anthropic/claude-sonnet-4-5" },
  },
  channels: {
    whatsapp: {
      allowFrom: ["+15555550123"],
      groups: { "*": { requireMention: true } },
    },
  },
}

因此我加了一段

1
2
3
4
5

identity: {
    name: "虾总9527",
    theme: "helpful assistant",
    emoji: "🦞",
  }

结果发现也报错了

怎么办呢？ 发现了一个有用的命令：
openclaw doctor –fix

openclaw doctor --fix 是 OpenClaw 的诊断修复命令，相当于一个”自动医生”工具。让我详细解释它的作用：

🏥 主要功能

1. 检查配置文件

• 扫描配置文件中的语法错误
• 检查配置项是否过时（比如你遇到的 identity 问题）
• 验证模型配置是否正确

2. 自动修复问题

• 自动迁移过时的配置项（如 identity → agents.list[].identity）
• 修复格式错误
• 补充缺失的必要配置项

3. 生成修复报告

会告诉你：

• 发现了什么问题
• 自动修复了什么
• 哪些问题需要手动处理

📋 实际效果

就像你之前看到的：

1
2
3
4

Config invalid
File: ~/.openclaw/openclaw.json
Problem:
  - identity: identity was moved; use agents.list[].identity instead

运行 openclaw doctor --fix 后，它会：

1. 自动帮你把旧的 identity 配置移到正确位置
2. 修改配置文件
3. 使配置生效

🔄 类似场景

相当于其他软件的：

• npm audit fix - 修复 npm 包问题
• git fsck - 检查 git 仓库完整性
• chkdsk - Windows 磁盘检查

✅ 使用建议

当你遇到配置相关错误时，第一步就应该运行：

1

openclaw doctor --fix

它会自动处理大部分常见问题。如果还有问题，会给出明确的提示告诉你需要手动修改什么。

最后，在界面上看到了效果

一号助手虾总9527诞生了。

MCP（Model Context Protocol，模型上下文协议）

2024年11月底，由 Anthropic 推出的一种开放标准，旨在统一大模型与外部数据源和工具之间的通信协议。

MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。

对于 LLM 开发者，MCP 是一个变革性的协议。

它消除了为每个数据源或工具进行定制集成的需要，减少了开发时间和维护成本。

从本质上来说，MCP是一种技术协议，一种智能体Agent开发过程中共同约定的一种规范。

在统一的规范下，协作效率就能大幅提高，最终提升智能体Agent的开发效率。

MCP协议本质就是Function calling技术的更高层封装和实现。

传统的Function calling技术要求围绕不同的外部工具API单独创建一个外部函数，类似一把锁单独配一把钥匙，而一个智能体又往往涉及到多个外部工具设计，因此开发工作量很大。

MCP 的灵感部分来源于 USB-C 的类比：如同 USB-C 通过统一接口连接多种设备，MCP 旨在为 AI 应用提供一个“即插即用”的上下文管理框架。

MCP 的核心思想是将模型与外部系统之间的通信抽象为一个客户端-服务器架构，通过标准化的接口（如基于 JSON-RPC 的通信）实现上下文的动态传递和工具的灵活调用。Anthropic 在发布时提供了初步的规范和 SDK（如 Python 和 TypeScript），并开源了多个预构建的 MCP 服务器（如 Google Drive、GitHub 集成），以加速该协议的推广。

MCP服务器与客户端

MCP技术体系中对大模型和外部工具的一种划分方式，也就是说在MCP技术体系中，会将外部工具称作服务器，而接入这些外部工具的大模型运行环境称作客户端。

MCP 客户端调用服务器工具的流程如下：

1、建立连接 ：与 MCP 服务器搭建通信链路。

2、查询工具 ：获取服务器上所有外部工具的数量信息。

3、生成列表 ：将查询到的外部工具整理成列表，并融入当前对话场景。

4、调用工具 ：通过 Function calling 技术调用所需的外部工具。

一个客户端可以接入多个不同类型的服务器的，但要求是都要遵循MCP通信协议。MCP服务器的输出内容是一种标准格式的内容，只能被MCP客户端所识别。在客户端和服务器都遵循MCP协议的时候，客户端就能够像Function calling中大模型调用外部工具一样，调用MCP服务器里面的工具。

VS Function calling

Function Calling是AI大模型模型调用函数的机制，

MCP是一个标准协议，使大模型与API无缝交互，

而AI Agent是一个自主运行的智能系统，利用Function Calling和MCP来分析和执行任务，实现特定目标。

ReAct（Reasoning + Acting）是一种将推理和行动相结合的 Agent 范式。在这个范式中，Agent 会：

1. 思考（Reasoning）：分析当前情况，决定下一步该做什么
2. 行动（Acting）：执行工具调用或生成最终答案
3. 观察（Observation）：接收工具执行的结果
4. 迭代：基于观察结果继续思考和行动，直到完成任务

这个循环使 Agent 能够：

• 将复杂问题分解为多个步骤
• 动态调整策略基于中间结果
• 处理需要多次工具调用的任务
• 在不确定的环境中做出决策

Spring AI Alibaba 中的ReactAgent 基于 Graph 运行时构建。Graph 由节点（steps）和边（connections）组成，定义了 Agent 如何处理信息。Agent 在这个 Graph 中移动，执行如下节点：

• Model Node (模型节点)：调用 LLM 进行推理和决策
• Tool Node (工具节点)：执行工具调用
• Hook Nodes (钩子节点)：在关键位置插入自定义逻辑

ReAct Agent 的工作方式其实挺像人类解决问题的过程。它不是一次性把整个流程都规划好，而是在有一个整体目标的前提下，走一步看一步。

具体来说，它会先观察当前的情况，然后思考下一步该做什么，接着执行这个动作，再观察结果，根据结果决定下一步。

这个过程会一直循环，直到任务完成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

函数 执行一个轮次(用户目标, 历史上下文):
    // 1. 获取当前环境信息
    当前环境信息 = 获取当前环境信息()
    
    // 2. 构建提示词（替换占位符）
    提示词模板 = "已知：\n当前历史上下文：${历史上下文}\n当前环境信息：${当前环境信息}\n用户目标：\"${用户目标}\"\n\n做出下一步的决策\n\n你必须最少使用一个工具来实现该决策"
    完整提示词 = 替换占位符(提示词模板, {
        历史上下文: 历史上下文,
        当前环境信息: 当前环境信息,
        用户目标: 用户目标
    })
    
    // 3. 调用 LLM 进行推理（思考过程隐藏，直接输出 toolcall）
    工具调用结果 = 调用语言模型(完整提示词, 历史上下文)
    
    // 4. 解析工具调用
    工具名称 = 解析工具名称(工具调用结果)
    工具参数 = 解析工具参数(工具调用结果)
    
    // 5. 执行工具调用
    观察结果 = 执行工具(工具名称, 工具参数)
    
    // 6. 更新历史上下文
    新历史上下文 = 追加到历史上下文(历史上下文, {
        行动: 工具调用结果,
        观察结果: 观察结果
    })
    
    // 7. 返回结果
    返回 {
        观察结果: 观察结果,
        新历史上下文: 新历史上下文
    }
结束函数

// 主循环
函数 执行ReAct流程(用户目标):
    历史上下文 = 空
    当前轮次 = 1
    最大轮次 = 10
    
    当 当前轮次 <= 最大轮次 且 未完成任务:
        结果 = 执行一个轮次(用户目标, 历史上下文)
        历史上下文 = 结果.新历史上下文
        
        如果 判断任务已完成(结果.观察结果):
            中断循环
        
        当前轮次 = 当前轮次 + 1
    结束循环
    
    返回 历史上下文
结束函数

最近股友推荐了一种复盘选择思路，想着正好让AI来干干呗

选股三步骤：

1、找到个股资金流向排行，点10日排行

2、排除法，超大盘子的，落后产能过剩产能的如房地产，行业太传统如钢铁，亏损的这些先剔除，然后按顺序翻看300只左右的股票，在其中选。连续十日增仓的都是强势股，在里面选择涨幅小，趋势好，行业独特的股票

3、连续10只增仓，连续十日资金流入的都是强势股，太强的，涨幅比较大的，也排除掉

把整个流程折成四步：

第一步：
1 浏览器打开数据中心 https://data.eastmoney.com/zjlx/detail.html
2 找到 个股资金流，使用 10日排行
3 抓取排名前2只股票，获取股票列表数据

最终以表格方式写入文件保存，一行一支股票, 表头是：股票号码|股票名称|10日涨幅,输出的文件包含表头内容，写到文件 stock_basic_data.md

第二步：
根据第一步输出的文件 stock_basic_data.md，先复制到stock_final_list.md

格式根stock_basic_data.md一样，在表头上增加两列所属行业 和 总市值

补充每行股票的所属行业和总市值信息

每只股票提取行业信息和总市值从下面的两个网址中提取，不需要点击其链接以查看详细信息

股票行业信息来源于网址：
https://emweb.securities.eastmoney.com/pc_hsf10/pages/index.html?type=web&code=SH600111&color=b#/gsgk

总市值信息来源于：https://emweb.securities.eastmoney.com/pc_hsf10/pages/index.html?type=web&code=SH600111&color=b#/cpbd，从概况页面提取总市值数值

信息提取完成后就关闭这个标签页

把提取到的所属行业和总市值信息写到文件 stock_final_list.md

一行一支股票, 表头是：股票号码|股票名称|所属行业|10日涨幅|总市值，输出的文件包含表头内容

第三步：
根据第二步输出的文文件 stock_final_list.md

你是资深财经专业人士，根据stock_final_list.md，各大财经网站和淘股吧精华贴等数据，总结，A股市场，1.热度总览2.第一梯队极度火热3.第二梯队局部高热4.第三梯队事件驱动5.第四梯队相对冷静，并对以上分析分别给出关键词和数据表现情况，最后给出整体总结及策略建议。然后，继续列表总结2月27日的连板梯队和跌停情况，以及对应的板块和题材。最后根据前述总结的内容用费曼学习法 1.先说结论 2.相应论点核心内容(前有序号） 3.总结 4.启示及未来行动指南及风险提示 5.奥卡姆剃刀总结

总结解读内容，除了以markdown格式输出一份文件 market_heat_analysis_{yyyyMMdd}.md，

再分析一下 linked_external/market_heat_analysis_20260227.html 里面的内容, 参照里面的格式，生成以HTML格式可视化保存到文件 linked_external/market_heat_analysis_{yyyyMMdd}.html

第四步：
分析一下 linked_external/index.html 里面的内容，

根据里面的格式,增加加一下 第三步生成的 linked_external/market_heat_analysis_{yyyyMMdd}.html 的内容，并链接到market_heat_analysis_{yyyyMMdd}.html

最后生成一份复盘记录，从中挑选喜欢的股票

https://zhuxingsheng.com/market/market_heat_analysis_20260302.html

不过最近股市天天吃大面。还要烧token